CAP-12 propone cambios a la Constitución de Cardano para Dijkstra

CAP-12, una enmienda propuesta que abarca los parámetros del protocolo Dijkstra, está abierta a consulta pública. La actualización del 2 de octubre de Intersect describió la propuesta junto con los preparativos para Node 11.2, con un prelanzamiento que se espera pronto para los equipos de carteras y de infraestructura.

Parámetros de Dijkstra en la Constitución de Cardano

La Constitución de Cardano permite que las acciones de Actualización de Parámetros cambien solo configuraciones enumeradas explícitamente en el Apéndice I. Sin la enmienda, los nuevos parámetros de Dijkstra permanecerían fijos en sus valores iniciales a pesar de ser técnicamente ajustables.

CAP-12 abarca la protección de scripts de referencia, Ouroboros Leios, Ouroboros Peras y la economía de los stake pools. Su alcance incluye la capacidad y los ajustes de temporización de Leios, el margen mínimo del pool y el apalancamiento máximo del pledge.

Para cada parámetro, la propuesta describe su función, asigna su grupo de votación y define límites para cambios futuros. El grupo determina el umbral de aprobación para los DReps, representantes a quienes los tenedores de ADA delegan el poder de voto. Los parámetros críticos para la seguridad también requieren la aprobación de los operadores de stake pool.

Un Guardrails Script actualizado impondría automáticamente las restricciones que pueden verificarse en cadena. La enmienda añade disposiciones sin cambiar ni eliminar el texto constitucional existente.

Node 11.2 prepara pruebas de integración de Dijkstra

La secuencia de lanzamientos para Node 11.2 está en marcha, según Intersect. El prelanzamiento previsto contendrá la mayor parte del conjunto de funciones de Dijkstra, incluido el nuevo formato de bloque y el contexto de Plutus V4, que define la información disponible para los scripts de contratos inteligentes.

Los equipos de carteras y herramientas podrán probar integraciones y evaluar los cambios en el comportamiento del protocolo, las API y la funcionalidad. La versión excluirá Leios y no estará lista para activar el hard fork.

Los proveedores de carteras de hardware también tienen trabajo de preparación relacionado con claves criptográficas y requisitos de registro de stake pool para Leios. Esos requisitos van más allá del contenido de la próxima versión de pruebas.

Guardrails pendientes y activación posterior

Los guardrails propuestos vinculan los cambios en la capacidad de Leios con pruebas comparativas y simulaciones que demuestran que los nodos pueden procesar y distribuir datos dentro del tiempo requerido.

CAP-12 también distingue entre etapas de activación. El apalancamiento máximo del pledge, un parámetro del pool vinculado a los compromisos de ADA propios de los operadores, inicialmente no tendría un valor configurado. Habilitarlo requeriría una acción de gobernanza posterior. Peras y el margen mínimo del pool están pensados para un hard fork posterior dentro de la era Dijkstra.

La propuesta sigue en consulta, con una revisión inicial por parte de un editor prevista. Los límites numéricos para la capacidad de Endorser Block y la temporización de Leios figuran entre los valores que aún aparecen como "PENDING" en el borrador.