Por Nathan Wilcox en Electric Coin Co.
En Electric Coin Co. (ECC) estamos explorando una transición en Zcash del actual consenso proof-of-work (PoW) a un consenso proof-of-stake (PoS). Estamos proponiendo un paso en este camino que llamamos Trailing Finality Layer (TFL). Si se implanta, se combinaría con el consenso existente de Zcash; el protocolo de consenso resultante en ese punto sería un híbrido de PoW y PoS.
El objetivo general es permitir la finalidad y PoS en Zcash de una manera mínimamente perjudicial. La finalidad es una garantía de que una vez que un bloque se finaliza, ese bloque y las transacciones que contiene no se pueden deshacer. La finalidad puede reducir los retrasos en algunos casos de uso (como los tiempos de espera del depósito centralizado) y permitir nuevas mejoras como puentes más seguros entre cadenas.
Si el enfoque TFL es adoptado por la comunidad Zcash, podría permitir algunos nuevos casos de uso, como apostar ZEC para ganar recompensas de protocolo, al tiempo que minimiza la interrupción de los casos de uso existentes. La minería es un ejemplo de un proceso que se vería afectado en un modelo híbrido, ya que las recompensas de minería se reducirían mientras que el resto de la infraestructura y los procesos de minería permanecerían sin cambios.
También pretendemos minimizar la interrupción del análisis de la seguridad del consenso, ya que muchas de las propiedades de consenso existentes permanecen intactas en un modelo híbrido.
Apenas hemos empezado a definir el diseño de este protocolo híbrido PoW/PoS. Muchos detalles clave siguen siendo cuestiones abiertas, como explicamos a continuación. Al compartir nuestro enfoque en las primeras fases del proceso, pretendemos recoger e incorporar comentarios sobre la marcha, encontrar posibles colaboradores y estimular el debate sobre este enfoque.
Participa
Si estás interesado en dar tu opinión o colaborar en este proyecto, ¡ponte en contacto conmigo! Una buena oportunidad para aprender más y unirte a la conversación es asistir (en persona o virtualmente) al taller Interactive Design of a Zcash Trailing Finality Layer que impartiré en Zcon4. También puedes enviarme un correo electrónico a nathan@electriccoin.co si estás interesado. Estamos buscando colaboradores de una amplia gama de orígenes, incluyendo técnicos, producto, comunidad, y cualquier usuario de Zcash que quiera opinar a medida que evoluciona la propuesta.
Antecedentes de la transición PoS
ECC compartió previamente su justificación de por qué creemos que es en el mejor interés de los usuarios actuales y futuros de ZEC hacer la transición del protocolo a la prueba de participación en la entrada del blog ¿Debería Zcash hacer la transición de Prueba de Trabajo a Prueba de Participación? y la presentación Zcon3 "Motivaciones de la Prueba de Participación". En 2022, publicamos una descripción general de alto nivel de nuestro enfoque de investigación sobre Proof-of-Stake, un artículo complementario más detallado sobre Aproximación, Enfoque y Próximos Pasos, y ofrecimos una presentación en Zcon3 sobre los retos de diseño de alto nivel en Proof of Stake.
Un camino de transición hacia la prueba de participación
Nuestra visión de una transición a proof-of-stake incluye al menos dos grandes hitos:
- Pasar Zcash de su actual modelo proof-of-work a un sistema híbrido PoW/PoS
- Pasar Zcash de un sistema híbrido PoW/PoS a PoS puro.
Nuestra principal motivación para proponer (al menos) dos pasos es minimizar la interrupción de la usabilidad, la seguridad y el ecosistema durante cada paso.
Este enfoque de transición de PoW a híbrido a PoS fue ejecutado por Ethereum con el despliegue de Beacon Chain (híbrido) y luego The Merge (PoS puro).
Objetivos de diseño para un sistema PoW/PoS híbrido
ECC está perfeccionando el diseño de TFL con varios objetivos en mente, y potencialmente añadiremos más a medida que continuemos desarrollando esta propuesta. Actualmente:
- Queremos minimizar la interrupción de los casos de uso de monedero y la experiencia de usuario existentes. Por ejemplo, nada debería cambiar en los flujos de usuario para almacenar o transferir fondos, el formato de las direcciones, etc.
- Queremos minimizar la complejidad de los análisis de seguridad conservando, en la medida de lo posible, los resultados de los análisis existentes.
- Queremos habilitar nuevos casos de uso de PoS que permitan a los usuarios de monederos móviles blindados obtener un rendimiento de la ZEC delegada.
- Queremos habilitar puentes de confianza minimizada y otros beneficios proporcionando un protocolo con finalidad.
- Queremos mejorar la modularidad del protocolo de consenso. La modularidad tiene varios significados vagamente definidos y relacionados, por ejemplo, es posible entender algunas propiedades del consenso sólo con el conocimiento de un componente del protocolo, y es posible implementar reglas de consenso en componentes de código modular con interfaces limpias.
Trailing Finality Layer en pocas palabras
El protocolo híbrido PoW/PoS que prevemos en ECC está estructurado como el actual protocolo Zcash NU5 con una nueva capa final. Lo describimos como una capa, porque los nodos existentes y la mayor parte de su lógica seguirán funcionando en gran medida tal cual con cambios mínimos, mientras que gran parte de la nueva funcionalidad será proporcionada por nuevos componentes complementarios y protocolos de red.
El diagrama de la izquierda muestra la red Zcash actual, con un detalle que ilustra cómo se conectan dos nodos entre sí en el contexto de toda la red. El de la derecha muestra la adición del TFL tras el despliegue: cada nodo sigue teniendo su componente PoW original, pero ahora tiene un componente TFL adicional. Los componentes PoW siguen conectándose entre sí, como antes, y los componentes TFL utilizan conexiones distintas con otros componentes TFL.
Esta nueva capa proporciona a la cadena de bloques una garantía de finalización: una vez que los bloques se han minado, pueden finalizarse, lo que significa que no pueden deshacerse. Esta garantía se extiende a cualquiera de las transacciones dentro de los bloques. Es "trailing", porque esta propiedad de finalidad sigue al sistema de minería PoW "trailing behind it".
Debido a que este diseño híbrido se basa totalmente en PoW para producir nuevos bloques, este protocolo es resistente a detenerse de la misma manera que Bitcoin o el actual Zcash, aunque la garantía de finalidad puede detenerse, como describimos a continuación. Este paradigma de diseño tiene un historial teórico y práctico: se analiza en un artículo de investigación, Ebb-and-Flow Protocols, y es el mismo paradigma utilizado por Ethereum tanto en el diseño híbrido pre-Merge de la cadena Beacon como en el Ethereum actual.
Por qué importa la finalidad
El consenso PoW de Nakamoto, introducido con Bitcoin y heredado por Zcash, proporciona finalidad probabilística. Esto significa que la probabilidad de que un bloque pueda ser revertido disminuye a medida que se minan más bloques.
En nuestra opinión, el principal reto de este tipo de finalidad es que los distintos participantes reaccionan de forma independiente a las reversiones. Por ejemplo, es probable que la mayoría de los participantes prevean retrocesos de 1 bloque (que son relativamente comunes), pero a medida que el tamaño de los retrocesos aumenta, surgen tres retos:
- Las devoluciones de mayor tamaño son cada vez menos frecuentes, por lo que es posible que algunos participantes no dispongan de un proceso o una política para hacer frente a esa situación
- Los distintos participantes pueden tener políticas diferentes, por lo que, en caso de una gran reversión, el ecosistema puede fracturarse al discrepar los distintos participantes sobre cómo recuperarse
- Cuando las contrapartes exigen una tolerancia suficientemente baja a las reversiones, su interacción debe incurrir en un retraso sustancial
Ejemplo: puente de confianza minimizada
Para aclarar este punto, consideremos el valioso caso de uso de un puente de confianza minimizada: el ZEC enviado a un puente debe bloquearse mientras se emite un número equivalente de fichas proxy en otra red.
Si una reversión revierte un depósito de un puente después de que los tokens proxy se hayan emitido en otro lugar, ese ZEC ya no está bloqueado en el puente, y los tokens proxy están ahora sin respaldo. Esto rompe la clavija del puente, y muchos usuarios del puente perderán fondos simultáneamente. Si los diseñadores del puente deciden requerir suficientes bloques PoW para hacer que la probabilidad de este suceso sea astronómicamente pequeña, entonces la emisión de los tokens proxy en la otra red tendrá un retraso extremadamente grande.
Ejemplo: depósitos en intercambios
Si un usuario deposita ZEC en un intercambio centralizado, su cuenta en el intercambio se abona por el importe correspondiente. Si se produce una devolución de este depósito, la contabilidad del intercambio tiene ahora más ZEC pasivo que ZEC real.
Los intercambios intentan solucionar este problema exigiendo más bloques PoW para alcanzar una probabilidad suficientemente baja de que se produzca este suceso. Sin embargo, se trata de un acto de equilibrio: si un intercambio impone un retraso de N horas, la probabilidad sigue sin ser "astronómicamente pequeña", por lo que los usuarios se ven perjudicados por N horas y el intercambio sigue corriendo el riesgo práctico de que se produzca un exceso de responsabilidad.
Además, debido al reto número 2 anterior, los distintos intercambios exigen diferentes retrasos en los depósitos, lo que puede confundir a los usuarios y hace que los intercambios compitan por asumir más riesgos aceptando menos confirmaciones de bloques.
Finalidad
En contraste con la finalidad probabilística, un protocolo de consenso puede proporcionar una garantía de finalidad. Los protocolos que hacen esto aseguran que todos los participantes están de acuerdo en qué conjunto de bloques y transacciones son finales. La contrapartida es que la finalidad puede no avanzar en caso de interrupciones en la red. Una vez que la red se recupera, la finalidad rezagada puede "alcanzar" a los bloques PoW que se produjeron en el ínterin.1
En la práctica, esto significa que si los participantes están esperando a que una transacción se convierta en definitiva, a veces pueden tener que esperar un tiempo arbitrariamente largo.
La finalidad resuelve en cierta medida estos tres problemas:
- Los participantes ya no tienen que prever reversiones con distintas probabilidades a la hora de diseñar sus procedimientos y políticas. En su lugar, deben anticipar el riesgo de que a veces la finalidad no progrese a tiempo.
- Todos los participantes están de acuerdo en qué bloques y transacciones son definitivos, aunque pueden no estar de acuerdo en cómo reaccionar si la finalidad se bloquea durante largos periodos de tiempo.
- Ahora, los participantes pueden confiar en la garantía de finalidad para asegurarse de que sólo reaccionan ante algunas transacciones cuando no hay ninguna posibilidad de que la transacción se revierta.
En los ejemplos anteriores:
- Un puente de confianza minimizada puede confiar en la finalidad para la emisión de tokens proxy. Esto asegura que el puente nunca estará infra-colateralizado. La contrapartida es que mientras la finalidad se bloquee, las transferencias entre puentes también se bloquearán.
- Todos los intercambios pueden utilizar la misma garantía de finalidad, por lo que los usuarios pueden esperar el mismo retraso de depósito en todas partes (y es probable que sea notablemente inferior al status quo). La contrapartida es que si se paraliza la finalidad, también se paralizarán los nuevos depósitos, aunque todos los intercambios se comportarán de forma coherente a este respecto.
El resultado final para los usuarios es que algunas interacciones de gran valor (como los depósitos puente o de intercambio) serán ahora más rápidas y seguras la mayor parte del tiempo. A veces, la finalidad puede estancarse. Cuando la finalidad se reanude, se "pondrá al día" con la cadena PoW, por lo que los usuarios que no necesitan la garantía de finalidad pueden seguir utilizando este protocolo híbrido, de manera similar a como utilizan Zcash hoy en día, y no se verán afectados si la finalidad se detiene.
Estado y preguntas abiertas
Esta introducción al blog cubre la mayor parte de nuestra I+D, hasta ahora, sobre el diseño TFL. Todavía hay muchas cuestiones abiertas que necesitan ser resueltas con la colaboración y las aportaciones de la comunidad Zcash antes de que el diseño TFL esté listo como propuesta para una actualización de Zcash.
Una lista incompleta de cuestiones que aún deben resolverse incluye:
- ¿Es aceptable este enfoque general para la comunidad Zcash?
- ¿Cómo se distribuirá la nueva emisión de ZEC entre PoW, PoS y cualquier sucesor potencial del Dev Fund? Esta es una preocupación clave tanto para los mineros como para los potenciales stakers o delegados.
- ¿Cómo podemos integrar cualquier otro cambio en la mecánica de emisión, como el Fondo de Sostenibilidad Zcash?
- Toda la mecánica contable del PoS, como por ejemplo cómo funciona la vinculación, cómo funciona la delegación, qué tipos de recortes pueden ocurrir, retrasos y mecánica de retirada, etc.
- ¿Cómo interactuarían las operaciones PoS con el resto de actividades del ledger de Zcash, como los pools blindados, etc.? Esta será un área clave para entender cómo interactúan la privacidad y la participación.
- ¿Debería detenerse alguna vez la punta de la cadena para acotar el espacio entre el bloque finalizado y la punta de la cadena?
- Análisis detallados de la seguridad, incluida la seguridad económica, un análisis de casos de captura de PoW, captura de PoS, seguridad de la red (especialmente teniendo en cuenta dos protocolos/capas de red separados).
- ¿Cómo podemos garantizar que los monederos móviles blindados sean participantes de primera clase? Por ejemplo, ¿podemos garantizar que puedan delegar participaciones y gestionar posiciones de delegación de participaciones de forma segura y eficiente? Esto incluye tanto cuestiones de UX, como flujos de UI de delegación, como de implementación, como cambios en el protocolo lightwalletd.
- Cómo integrar cualquier cambio de protocolo TFL con otros cambios de protocolo propuestos de forma segura y oportuna. Ejemplos: Zcash Sustainability Fund, Zcash Shielded Assets, esfuerzos de puente, integraciones Namada, etc.
- Selección de un protocolo PoS finalizador específico. Actualmente nos estamos centrando en el uso de Tendermint y ABCI como una forma de crear rápidamente prototipos y validar el diseño.
- Prototipos, redes de prueba, arquitectura de código, etc.
A medida que abordemos las cuestiones pendientes, especialmente la interacción con otras funciones del protocolo y la coordinación con esos equipos en cuanto a plazos, podremos empezar a perfilar un calendario de implantación.
Próximos pasos
Nuestros próximos pasos para esta iniciativa de I+D de TFL son recabar la opinión de la comunidad en este blog, organizar un taller en Zcon4 y producir actualizaciones de I+D sobre las cuestiones abiertas mencionadas.
Mientras colaboramos con otros equipos de desarrollo de protocolos, nos gustaría crear un calendario provisional de despliegue que incorpore todos los demás esfuerzos de protocolo, como el Fondo de Sostenibilidad de Zcash, los Activos Blindados de Zcash y los posibles esfuerzos de puente entre cadenas.
Por último, estamos buscando otros equipos o individuos que estén interesados en colaborar en este proyecto TFL, así que si estás interesado, por favor, consulta la sección Participa más arriba.
1 En un protocolo PoS de finalización pura, las "paradas" equivalentes son en realidad paradas en toda la red. Uno de los puntos fuertes de este diseño híbrido es que no es necesario que PoW se detenga, y si no lo hace, los usuarios que no dependen de la finalidad pueden seguir utilizando la red.
Traducción del original en inglés de Electric Coin Co.
Si quieres aprender más sobre privacidad en la economía digital descentralizada, te puedes unir a la comunidad de Zcash Español en Telegram. Para conectar con el ecosistema digital de Zcash Español, visita nuestro Linktree.
