Cardano detalla cómo llegará Leios, que multiplicará su capacidad de procesamiento

Leios llegará con Dijkstra, la próxima bifurcación dura de Cardano. Primero se busca multiplicar entre 3 y 5 veces el límite actual de capacidad y después llegar a entre 10 y 15 veces, con cada paso sujeto a pruebas de carga y a la aprobación de la gobernanza.

Puntos clave

• Leios llega con Dijkstra. La próxima bifurcación dura de Cardano incluye Leios junto con transacciones anidadas, mejoras en las cuentas, scripts de protección, Plutus V4 y recompensas de staking que se pueden retirar libremente.
• El proceso, paso a paso. Una actualización de la constitución, la bifurcación dura, el registro de claves BLS por parte de los SPO, ejercicios de alta carga en la red principal y, posteriormente, un aumento del rendimiento mediante actualizaciones de los parámetros del protocolo.
• El dial gira un punto a la vez. Leios comienza de forma conservadora y crece mediante al menos dos actualizaciones de parámetros, cada una respaldada por lo que la red principal nos mostró en el paso anterior.
• Los SPO obtienen una nueva clave. Inmediatamente después de la bifurcación, los pools registran una clave BLS que utilizan para votar. Leios necesita que se registre aproximadamente entre el 90 y el 95 % de la participación antes de activarse.
• Primero de 3 a 5 veces, luego de 10 a 15. Leios pretende comenzar con aproximadamente de 3 a 5 veces el límite actual de 4,5 TxkB/s, y las próximas actualizaciones de parámetros apuntan a alrededor de 10 a 15 veces. Más allá de eso, la demanda, las necesidades de la comunidad y la economía marcan el ritmo.

Se prevé que Ouroboros Leios llegue con Dijkstra , la próxima bifurcación dura de Cardano. Sin embargo, esta bifurcación es solo el inicio del despliegue, no el momento en que Cardano opere repentinamente a plena capacidad de Leios. Los operadores de grupos de participación (SPO) registrarán primero nuevas claves de votación BLS. Una vez que se haya registrado suficiente participación, Leios podrá comenzar a usar bloques de respaldo. La capacidad aumentará gradualmente, sujeta a los resultados de la red principal y a la aprobación de la gobernanza.

El objetivo inicial es aproximadamente de 3 a 5 veces el límite actual de Praos de 4,5 kilobytes de transacciones por segundo (TxkB/s). Al menos dos actualizaciones posteriores de los parámetros del protocolo pretenden elevarlo a entre 10 y 15 veces el rendimiento actual. Cualquier aumento posterior dependerá de la demanda, las necesidades de los desarrolladores y la viabilidad económica de la red.

Dijkstra también incluye transacciones anidadas , mejoras en las cuentas, scripts de protección, Plutus V4, recompensas de staking que se pueden retirar libremente y un nuevo parámetro de apalancamiento de garantías. Estos cambios se implementaron con la bifurcación dura y no dependen de que Leios alcance sus objetivos de rendimiento posteriores.

El despliegue en cinco pasos

1. Actualización de la Constitución. Añadir entradas y salvaguardias para los nuevos parámetros del protocolo Dijkstra, de modo que la gobernanza pueda modificarlos tras la bifurcación.
2. Bifurcación dura de Dijkstra. Actualiza Cardano a las nuevas reglas del protocolo, incluyendo Leios y las demás características de Dijkstra.
3. Registro de claves BLS. Los SPO registran las claves necesarias para votar en los bloques de aprobación de Leios. Leios comienza a operar una vez que la participación registrada alcanza un nivel suficiente.
4. Ejercicios de carga en la red principal. Se realizan ráfagas de tráfico planificadas para medir la rapidez con la que los bloques y votos de los validadores se propagan por la red en funcionamiento.
5. El rendimiento aumenta. Utilice al menos dos actualizaciones de parámetros, respaldadas por pruebas de la red principal y votaciones de gobernanza, para aumentar la capacidad.

Se trata de hitos distintos. La bifurcación dura habilita el protocolo. El registro de claves BLS permite la votación en Leios. Las actualizaciones de parámetros posteriores modifican la capacidad de procesamiento de Leios. Estos cambios de capacidad no requieren otra bifurcación dura.

¿Por qué Praos tiene un límite de rendimiento?

Actualmente, Cardano utiliza Ouroboros Praos . En promedio, un grupo de participantes obtiene el derecho a crear un bloque cada 20 segundos aproximadamente. Para que Praos funcione según sus supuestos de seguridad comprobados, un nuevo bloque debe llegar al resto de la red antes de que se pueda crear el siguiente. La red principal permite aproximadamente cinco segundos para esta entrega.

Ocasionalmente, dos pools pueden generar bloques con pocos segundos de diferencia. Esto crea una bifurcación corta en la punta de la cadena, y la regla de selección de la cadena la resuelve cuando los nodos convergen en una rama. El presupuesto de entrega de cinco segundos ayuda a que estas bifurcaciones sean raras y breves. Si los bloques llegaran con retraso con regularidad, más bloques honestos terminarían en ramas abandonadas. El crecimiento de la cadena se ralentizaría y las transacciones tardarían más en liquidarse con el mismo nivel de confianza.

Dado que los bloques deben viajar dentro de ese presupuesto, no pueden crecer indefinidamente. El resultado es un límite máximo de rendimiento de transacciones en la red principal de aproximadamente 4,5 TxkB/s. Praos puede gestionar la demanda habitual, pero un lanzamiento concurrido, un airdrop o un movimiento del mercado pueden saturar la cola. Modificar los parámetros de Praos por sí solo solo puede aumentar el límite hasta cierto punto.

Cuando la demanda aumenta repentinamente, surge un segundo problema. El mempool de un nodo Praos almacena aproximadamente dos bloques de transacciones. Una vez que se llena, deja de aceptar nuevas. Las carteras deben reintentar el envío de transacciones hasta que haya espacio disponible. Esta espera ocurre antes de que una transacción ingrese al mempool, por lo que las mediciones de inclusión de bloques no reflejan la demora total que experimentan los usuarios.

Lo que cambia Leios

Bloques de clasificación y bloques de respaldo

Leios conserva los bloques de clasificación de Praos. Estos son los bloques que Cardano utiliza actualmente, con algunos campos de encabezado adicionales. Cuando las transacciones pendientes superan la capacidad de un bloque de clasificación, el productor puede anunciar un bloque de respaldo en dicho encabezado.

Un bloque de respaldo contiene una lista ordenada de referencias a transacciones, no las transacciones en sí. Los nodos obtienen la lista, verifican qué transacciones ya tienen en sus mempools y descargan las que faltan. Un nodo reenvía el bloque de respaldo a sus pares una vez que tiene todas sus transacciones.

Votación y certificación

Al comienzo de cada época, los pools con mayor participación toman asiento en un comité de votación para esa época. CIP-164 analiza un comité de aproximadamente 900 asientos, que representan cerca del 99 % de la participación activa. Los miembros esperan brevemente para que la red pueda detectar a un productor que haya anunciado dos bloques diferentes para el mismo espacio. Luego, validan el bloque del validador. Los miembros que consideran válidas todas las transacciones firman un voto utilizando su clave BLS.

Una vez recibidos los votos que representan al menos el 75 % de la participación activa, las firmas se pueden combinar en un certificado. Este contiene una firma agregada y un registro de los firmantes, con un tamaño de tan solo unos cientos de bytes. Un bloque de clasificación posterior incluye dicho certificado en lugar de sus propias transacciones, y las transacciones del bloque que lo avala se incorporan al libro mayor.

El tiempo es crucial. El certificado solo se puede incluir una vez que el bloque del avalista haya tenido tiempo suficiente para llegar a la red. CIP-164 funciona con un valor aproximado de 14 segundos. Si el siguiente bloque de clasificación llega demasiado pronto, el bloque del avalista se descarta. Dicho bloque de clasificación transporta las transacciones directamente, al igual que un bloque Praos, y las transacciones pendientes se pueden incluir posteriormente. El diseño prevé este mecanismo de reserva para aproximadamente la mitad de los bloques de clasificación.

El umbral de certificación del 75 % requiere una participación activa considerable para recibir y validar un bloque de respaldo. Esto permite a Leios aumentar su capacidad de transacción, manteniendo la sincronización de los bloques de clasificación con Praos y conservando las garantías de seguridad que este protocolo ofrece actualmente. Cuando el tráfico es bajo, el protocolo no anuncia los bloques de respaldo, por lo que los costos operativos se mantienen similares a los de Praos.

Cómo se ve el momento de la transacción

Leios mantiene el procesamiento secuencial de transacciones de Cardano. Las transacciones se aplican en un orden determinista, por lo que se conservan los supuestos de ordenación utilizados por los contratos inteligentes. Una transacción que se ajusta directamente a un bloque de clasificación puede incluirse con la misma rapidez que en la actualidad. Las transacciones gestionadas mediante un bloque de aprobación llegan al libro mayor en aproximadamente 45 a 60 segundos.

Ese factor temporal es solo una parte de la experiencia del usuario. La espera comienza cuando se pulsa enviar, no cuando un nodo finalmente acepta la transacción. Leios amplía la capacidad del mempool junto con la capacidad de los bloques. CIP-164 especifica espacio para al menos dos bloques de clasificación más dos bloques de aprobación de transacciones.

Esta cola más grande tiene como objetivo reducir el número de envíos rechazados durante un pico de tráfico. Una transacción aún podría esperar antes de ser incluida, pero la red puede retenerla en lugar de que la billetera la vuelva a enviar repetidamente. Cuando el tráfico supera la capacidad de procesamiento de Praos, un mayor rendimiento puede reducir el tiempo desde el envío inicial hasta la inclusión, incluso cuando un bloque de aprobación individual tarda más que un bloque de clasificación directa.

Por qué una mayor capacidad es importante para las SPO

Las comisiones por transacción cobrarán mayor importancia a medida que disminuya la Reserva de Cardano. Actualmente, más del 85 % de las recompensas por época provienen de la Reserva, y esta contribución se reduce con cada época. CIP-164 estima que los ingresos por comisiones necesitarían un tráfico sostenido de entre 50 y 70 TxkB/s para alcanzar el punto de equilibrio, lo que representa más de diez veces el rendimiento que Praos puede soportar hoy en día.

Leios crea una vía para alcanzar ese nivel de actividad. No genera demanda por sí mismo, por lo que los aumentos de capacidad posteriores también dependerán del uso real que se le dé a la red.

¿Por qué aumenta la capacidad por etapas?

La red de prueba de Leios, MusashiNet , ha proporcionado pruebas exhaustivas. La red principal introduce condiciones que una red de prueba no puede reproducir completamente: alrededor de 2700 grupos registrados, repartidos por continentes y con diferentes configuraciones de hardware y software, así como distintas conexiones, con valor real en juego.

Por lo tanto, Leios está diseñado para comenzar con una configuración de protocolo conservadora. Los controles principales incluyen la cantidad de transacciones a las que puede hacer referencia un bloque de respaldo y la cantidad de trabajo de Plutus que puede contener. La gobernanza puede aumentar o disminuir estos límites mediante actualizaciones de parámetros del protocolo sin necesidad de una bifurcación dura, siempre y cuando los cambios se mantengan dentro de los límites constitucionales.

Una vez que Leios esté operativo, el equipo planea realizar pruebas controladas de alta carga en la red principal. Los resultados mostrarán cómo se mueven los bloques de validación a través de la red en funcionamiento, con qué rapidez se procesan las votaciones del comité, si los certificados se generan de forma fiable y cuánto margen de capacidad conservan los nodos. El primer aumento de capacidad dependerá de esta información. El siguiente aumento se basará en los resultados de las pruebas de mayor carga.

Los operadores de sistemas de energía solar (SPO) verán cómo la carga aumenta gradualmente en lugar de hacerlo de golpe. Los constructores pueden planificar en función de los aumentos de capacidad anunciados, mientras que la administración conserva la facultad de aprobar o rechazar cada uno de ellos.

La hoja de ruta de gobernanza

Paso	Lo que sucede	Representantes delegados (DReps)	Operadores de fondos de participación (SPO)	Comité Constitucional
Actualización constitucional	Añade límites para los nuevos parámetros de Dijkstra.	75% de la participación	No votar	2/3 de los miembros
Horquilla dura	Cardano se traslada a Dijkstra, incluyendo a Leios.	60% de participación	51% de participación	2/3 de los miembros
Registro de claves BLS	Los pools registran las claves de votación de Leios; la activación se produce tras un registro suficiente.	No votar	Cada piscina registra su clave	No votar
Ejercicios de carga de la red principal	Las ráfagas programadas de alta carga ponen a prueba la difusión en tiempo real y la votación.	No votar	No votar	No votar
Aumento del rendimiento (al menos dos)	Aumenta los límites de Leios mediante cambios de parámetros.	67% de participación	51% de participación	2/3 de los miembros

Cuando no se requiere votación, el trabajo en cuestión es de carácter operativo y no una acción de gobernanza independiente.

1. Actualización de la Constitución

Antes de que la gobernanza pueda cambiar un parámetro del protocolo, la Constitución debe nombrar ese parámetro y definir el rango seguro para futuros cambios. Dijkstra introduce nuevos parámetros, incluidos los que controlan el rendimiento de Leios. Cada uno necesita una entrada y límites de seguridad .

El plan consiste en enviar la actualización constitucional antes de la bifurcación dura. De esta forma, una vez que Dijkstra esté en la red principal, se podrá proponer el primer aumento de rendimiento en cuanto las pruebas proporcionen suficiente evidencia. El Comité de Parámetros de Intersect desarrolla las medidas de seguridad, el equipo de Plutus actualiza el script de dichas medidas y la propuesta se envía a la cadena de bloques.

La aprobación requiere que los Representantes de los Representantes de los Miembros del Comité (DReps) representen el 75 % de los intereses y dos tercios del Comité Constitucional. Los DReps deben revisar el borrador durante la consulta, cuestionar cualquier límite con el que no estén de acuerdo y votar cuando se presente la propuesta.

2. Horquilla dura de Dijkstra

La bifurcación dura es una actualización coordinada de la red. Los nodos adoptan las nuevas reglas en el mismo límite de época después de que la comunidad aprueba el cambio en la cadena. Desde Plomin, las bifurcaciones duras de Cardano requieren la votación de la gobernanza de la comunidad.

Leios es una parte de Dijkstra. El lanzamiento también incluye:

• Transacciones anidadas: una transacción puede contener otras. Esto permite realizar intercambios atómicos sin un contrato de intercambio descentralizado (DEX), pagar comisiones con tokens distintos de ada y utilizar DApps que cubran las comisiones de los usuarios.
• Mejoras en la cuenta: ahora se pueden enviar ada directamente a una dirección de cuenta, lo que permite a las carteras y a los procesadores de lotes cobrar una fracción del mínimo actual de 1 ada.
• Scripts de protección: las comprobaciones compartidas pueden ejecutarse una sola vez por transacción, en lugar de ser pagadas repetidamente por las DApps.
• Plutus V4: la actualización de contratos inteligentes que pone estas funcionalidades a disposición de los desarrolladores.
• Recompensas de staking que se pueden retirar libremente: los poseedores de ada pueden retirar sus recompensas cuando lo deseen, y la delegación de DRep se convierte en una elección deliberada independiente.
• Apalancamiento de las promesas: un nuevo parámetro vincula las recompensas de un pool con la cantidad que promete su operador.

La bifurcación dura requiere que los DReps representen el 60 % de la participación, los SPO el 51 % y dos tercios del Comité Constitucional. Los SPO deben actualizar a un nodo compatible con Dijkstra y votar. Los exchanges, monederos, mantenedores de SDK, indexadores y equipos de DApps deben probar la nueva versión en redes de prueba públicas. Los DReps votan sobre la actualización.

3. Registro de claves BLS

Los SPO ya utilizan una clave VRF y una clave KES. Leios introduce una clave BLS para votar en los bloques de avalistas. Las firmas BLS se pueden combinar en una firma agregada, lo que mantiene los certificados del comité compactos incluso cuando han votado cientos de grupos.

Tras la bifurcación dura, cada SPO genera una clave BLS y envía un certificado de registro de pool actualizado que contiene la clave y la prueba de que el operador controla el secreto correspondiente. La clave se activa en el siguiente límite de época. Los pools rotarán estas claves periódicamente, aproximadamente con la misma periodicidad trimestral que las claves KES. Los SPO de MusashiNet ya siguen este proceso.

Un certificado Leios requiere votos del 75 % de la participación activa. Los pools sin clave BLS aún pueden generar bloques Praos, pero no pueden votar en los bloques de validación de Leios. Para compensar los pools que están fuera de línea o que votan lentamente, el registro debe superar cómodamente el 75 %. La estimación actual es de aproximadamente entre el 90 % y el 95 % de la participación delegada, lo que corresponde a entre los 500 y 900 pools más importantes. El requisito exacto de activación depende de los parámetros del protocolo, que aún se están definiendo.

No existe una votación separada del Comité de Registro de Delegados (DRep) ni del Comité Constitucional para el registro de BLS. Los SPO deben registrar sus claves tan pronto como se produzca la bifurcación. Los delegadores pueden consultar a su grupo si su clave está registrada.

4. Ejercicios de carga de la red principal

Una vez que se hayan registrado suficientes claves BLS, Leios podrá operar cuando la acumulación de transacciones supere la capacidad de un bloque de clasificación. El equipo también planea generar picos programados de alto tráfico de transacciones para observar el protocolo en condiciones parcialmente controladas. Estos picos impulsarán el tráfico más allá de la capacidad del bloque de clasificación y activarán los bloques de aprobación, las votaciones del comité y la emisión de certificados.

Las principales métricas son el tiempo que tarda un bloque de avalistas en propagarse por la red principal y el tiempo que tardan en recibirse los votos de cientos de grupos. Ambos deben ajustarse cómodamente a los límites de tiempo del protocolo. Los ejercicios también mostrarán si los certificados se generan de forma fiable y si los nodos conservan suficiente margen de capacidad. Esta información se utilizará para decidir si el primer aumento de capacidad es apropiado.

Estos ejercicios no requieren en sí mismos votos del DRep, el SPO ni del Comité Constitucional.

5. El rendimiento aumenta

Leios comienza con una configuración que apunta a un rendimiento de entre 3 y 5 veces superior al actual. Si las pruebas de carga confirman que los bloqueos y votos de los avalistas se propagan con tiempo suficiente, se prevén al menos dos actualizaciones de parámetros para aumentar el rendimiento hasta alcanzar entre 10 y 15 veces el límite de Praos. Cada propuesta deberá incluir mediciones realizadas al nivel de capacidad anterior.

Cada aumento constituye una acción de gobernanza y debe ajustarse a las salvaguardias ya ratificadas. Requiere el apoyo de los DReps que representen el 67 % de las participaciones, los SPO que representen el 51 % de las participaciones y dos tercios del Comité Constitucional. Los DReps y los SPO deben revisar la documentación adjunta a cada propuesta antes de votar. Los constructores deben respetar los límites aprobados al planificar los lanzamientos.

Más allá de esos primeros incrementos, los cambios posteriores dependerán de la demanda, las prioridades de la comunidad y las condiciones económicas. La gobernanza puede aumentar la capacidad cuando la evidencia lo justifique, o mantenerla en el nivel actual.

¿Qué hacer a continuación?

Para los SPO, la preparación inmediata consiste en ejecutar un nodo compatible con Dijkstra, participar en la votación de la bifurcación dura y registrar una clave BLS tras la actualización. Los DReps tendrán la actualización constitucional, la bifurcación dura y los cambios de parámetros posteriores para evaluar. Los monederos, exchanges, SDK, indexadores y equipos de DApps deben probar la versión de Dijkstra en redes de prueba públicas y hacer un seguimiento de la capacidad que la gobernanza aprueba.

Leios se está acercando a la red principal por etapas. El protocolo viene con la bifurcación dura, el registro BLS permite votar y los resultados de la red principal determinarán cuándo se podrá aumentar la capacidad.