En 2012/3, cuando me obsesioné por primera vez con Bitcoin, era obvio para mí que había muchas más aplicaciones que la transferencia de valor para sistemas similares a Bitcoin para mejorar el mundo. El principal de ellos fue la votación descentralizada para su uso en elecciones políticas demostrablemente justas y seguras. Esto fue mucho antes de que existiera el QRL e incluso antes de los problemas relacionados con el consenso en torno a Bitcoin y el fiasco de tamaño de bloque.
Los conflictos de intereses son inevitables en cualquier ecosistema donde se crea, transfiere y almacena valor. Si hemos aprendido algo de ese período de la historia de bitcoin, es que las cadenas de bloques monetarias descentralizadas deberían ser capaces de adaptarse de manera autónoma sin depender de los desarrolladores de gatekeeper que pueden no compartir los mismos objetivos o puntos de vista de las partes interesadas (base de usuarios) de esa criptomoneda . Los cambios de consenso contenciosos solo se pueden introducir en dicho sistema siguiendo una ruta de actualización específica.
Parece lógico que el lugar donde se deben decidir las decisiones contenciosas sobre la funcionalidad de red y token sea en cadena, el único punto de verdad para todos.
(Nota: es posible que esto no detenga la posición predeterminada y más fácil para diferir decisiones contenciosas simplemente continuando el status quo).
Durante algún tiempo, el equipo central y la comunidad han estado debatiendo varias actualizaciones del sistema a través de nuestro QIP (Proceso de Mejora QRL). Este proceso en github permite a cualquiera sugerir una mejora en el ecosistema QRL existente para construir. Allí, puede producirse un diálogo seguro entre desarrolladores y usuarios en el que se pueden discutir puntos de vista técnicos, o los méritos de una actualización en particular se debaten de manera transparente. Tal discusión naturalmente incluye solo un pequeño componente de la comunidad y tiende a atraer usuarios en gran medida técnicos y excluye a usuarios interesados pero no técnicos. Aún así, es un criterio de medición burdo para decidir si una característica debe buscarse activamente o dejarse de lado.
El sistema QIP es una verdadera joya para el QRL, pero la gobernanza del proyecto se puede mejorar en el futuro.
La próxima bifurcación rígida qrl-core incluye varias características nuevas y emocionantes que incluyen mensajería efímera, capacidad de billetera de múltiples firmas (integrada en la GUI de la billetera web) y una extensión de multisig donde todos los usuarios de QRL pueden realizar y votar en encuestas de todo el libro mayor saldo cero.
¿Como funciona esto? Primero, analicemos cómo funciona nuestra configuración de multigrado QRL. Primero en el nodo o billetera web, se crea una nueva dirección multigrado utilizando un MultisigCreateTx In donde se agregan más de una dirección QRL a la dirección con ponderación signataria (piense en los derechos de voto para cada dirección). Luego de mover fondos, se crea un MultiSigSpendTx por una de las direcciones enumeradas y se declara el valor a transferir y las direcciones de destino. Finalmente, cada signatario puede hacer un MultiSigVoteTx para firmar la transacción de gastos; luego, una vez que se alcanza el umbral, los fondos se mueven (nota: el voto y el gasto de múltiples usuarios son funcionalmente idénticos). Si bien esto suena complicado, en realidad es extremadamente simple usar la GUI de clic de la billetera web.
Entonces, ¿votar …?
Para permitir la votación en todo el libro mayor, ahora se designa una dirección de multigrado "mágico" ("Q110000000000000000000000000000000000000000000000000000000000000000000000000000" para ser precisos e indescifrables). Esta dirección es especial porque en lugar de una lista limitada de direcciones QRL específicas, tiene todas las direcciones QRL con un saldo distinto de cero como signatarios válidos.
Mientras que en el backend, en realidad, son funciones multigrado modificadas: para mantener las cosas limpias, hay dos subtipos de transacciones recién presentadas que se utilizarán para votar:
ProposalCreateTxProposalVoteTx
Cualquier dirección QRL puede crear un ProposalCreateTx válido e iniciar una encuesta en todo el libro mayor. Esta transacción establece el tipo de encuesta (QIP, usuario, configuración de configuración que cambia el consenso, etc.) y permite designar un QIP específico, con una cadena de texto descriptiva opcional adicional y una caducidad de altura de bloque.
Para votar sobre una encuesta existente en todo el libro mayor, una dirección QRL simplemente crea un ProposalVoteTx suministrado con el txid ProposalCreateTx relevante y proporciona los datos de votación: apoyo, rechazo, abstención, etc.
Algunos de ustedes se habrán dado cuenta de que rastrear y catalogar encuestas y votos descentralizados en cadena en el QRL será fácil simplemente buscando la dirección mágica en el explorador, con todos los datos en forma útil y legible en la página de actualizaciones del protocolo en tiempo real.
Con solo el comportamiento anterior, es posible que cualquier usuario de QRL proponga un nuevo QIP y solicite a la comunidad y a las partes interesadas (poseedores de monedas) que voten objetivamente si debe proceder, no se requiere ningún desarrollador o equipo central, completamente descentralizado.
Los ojos de águila se preguntarán qué significa "configuración de configuración que cambia el consenso".
Una vez que las encuestas y la votación en todo el libro mayor están activas, esto abre la posibilidad de crear un comportamiento de enmienda para las reglas y el comportamiento de consenso de la red.
Los siguientes parámetros son ajustes de configuración en el cliente qrl-core. Si se cambian, potencialmente causarán una bifurcación dura y dividirán la red en una o más cadenas. Todos pueden ser potencialmente "enmendables" luego de la implementación de la votación en cadena:
Bloque-intervalo de tiempo Bloque-recompensa Emisión total Límite máximo de tamaño de bloque Límite de cambio consensual Límite de altura de bloque Vencimiento máximo Mínimo transacción mínima codificada por pares Peer_listre-org limitminimum aceptado Qrl-node versionconsensus algoritmo (¡para una versión posterior!)
Es posible utilizar los subtipos de transacción Propuesta para proponer un cambio directo de red y luego, al alcanzar un umbral satisfactorio para esa propuesta en cadena, bifurcar de forma autónoma las nuevas configuraciones de consenso del siguiente bloque. Por lo tanto, una encuesta con un voto exitoso puede alterar los parámetros de la red de manera completamente descentralizada, sin confianza y autónoma.
En efecto, las reglas existentes del sistema se trasladan a la cadena y solo pueden modificarse por consenso de votación en todo el libro mayor.
Ejemplos
Un ejemplo podría ser alterar la curva de emisión en función del consenso o hacer que los bloques sean más o menos frecuentes que en la actualidad. Otro cambio simple sería alterar peer_list para enmendar una nueva dirección IP que actúa como un nodo de descubrimiento para los nuevos participantes en la red, por ejemplo, si algunos de los primeros nodos de la red migraran a una nueva plataforma. Durante un ataque de spam de transacción de red, puede ser necesario implementar una tarifa de transacción mínima temporal; esto podría hacerse a través de una propuesta de votación y una actualización directa de la bifurcación para elevar la tarifa de transacción mínima de cero.
Futuras actualizaciones
También es posible extender estas características iniciales de enmienda automática para incluir módulos de código futuros para automatizar un cambio de algoritmo de minería u otra actualización de consenso, por ejemplo, la migración a POS a una altura de bloque determinada.
Se está publicando un QIP que lo desarrollará con más detalle y las partes interesadas podrán ayudarnos a probar estos cambios en QRL testnet en el futuro cercano.
Hard fork: una actualización de red que no es retrocompatible con los clientes existentes, con nodos heredados que se comportan de manera diferente si no se actualizan, lo que podría dar como resultado dos versiones de la cadena en el futuro.