ECOSISTEMA DE LA BLOCKCHAIN DE CARDANO CONSTITUCIÓN PROVISIONAL
NOTAS INTRODUCTORIAS
Esta es una constitución provisional mínima viable que contiene las disposiciones y salvaguardias necesarias para que CIP-1694 entre en vigor. Se pretende que sea temporal. La Constitución Final debe ser ratificada por los poseedores de Ada. Se espera que dicha ratificación ocurra a finales de 2024 o principios de 2025. Por lo tanto, la Constitución Final puede diferir, potencialmente de manera significativa, de esta Constitución Provisional, según los deseos de la comunidad de Cardano. Durante 2024, se realizarán una serie de talleres en todo el mundo para permitir que la comunidad de Cardano participe en el proceso de completar la Constitución Final. Además, la Constitución Final requerirá la aprobación de los poseedores de Ada antes de entrar en vigor. Se espera que dicha aprobación ocurra a principios de 2025. Sin embargo, dado que la gobernanza en cadena se implementará durante 2024, requiriendo una constitución y un comité constitucional robustos antes de que se haya ratificado la Constitución Final, esta Constitución Provisional debe contener las disposiciones y salvaguardias necesarias para apoyar y dar efecto a las necesidades y requisitos de CIP-1694, asegurando que los principios identificados en esta Constitución Provisional no se vean comprometidos, hasta la fecha en que se ratifique la Constitución Final.
Al abordar esta Constitución Provisional, debe recordarse que no es una constitución solo para una blockchain, sino para un ecosistema blockchain, un esfuerzo mucho más ambicioso. En consecuencia, cómo se aprueban las acciones de gobernanza, aunque extremadamente importante, no es el único enfoque de esta Constitución Provisional. Más bien, esta Constitución Provisional proporciona la base y el marco fundamental a través del cual todos los actores en el ecosistema de la Blockchain de Cardano pueden unirse para gobernarse a sí mismos y formar enfoques radicalmente nuevos para la interacción y la colaboración humanas. Por necesidad, esta Constitución Provisional reconoce el papel del Comité Constitucional y lo empodera, confirma el derecho de la comunidad de Cardano a participar en cuerpos colectivos para la colaboración, da efecto a la gobernanza en cadena y empodera a los representantes delegados (referidos como DReps) para actuar como la voz de los poseedores de Ada en la votación en cadena. La Constitución Provisional también reconoce la necesidad de salvaguardar el acceso y el uso de los fondos del tesoro de Cardano durante un período interino mediante la inclusión de las Salvaguardias de Cardano en esta Constitución Provisional.
PREÁMBULO
Al inicio del ecosistema de la Blockchain de Cardano, tres entidades pioneras, IOHK, Emurgo y la Fundación Cardano, se unieron para fomentar el surgimiento de una nueva blockchain, la Blockchain de Cardano, sentando las bases para una red descentralizada que empoderaría a los individuos y promovería la colaboración y la innovación. Sus esfuerzos pioneros han marcado el camino para una blockchain diseñada para asegurar un entorno justo y transparente donde todos los participantes puedan contribuir al crecimiento y éxito del ecosistema de la Blockchain de Cardano.
Con el tiempo, el ecosistema de la Blockchain de Cardano se ha expandido significativamente, y ahora, el ecosistema de la Blockchain de Cardano, compuesto por miles de poseedores de Ada, individuos, constructores, desarrolladores, empresas, pools de participación, usuarios de la Blockchain de Cardano y otros, opera de manera verdaderamente descentralizada, fortaleciendo aún más la resiliencia y autonomía del ecosistema de la Blockchain de Cardano. A medida que el ecosistema de la Blockchain de Cardano continúa creciendo, se ha vuelto imperativo adaptar y evolucionar su modelo de gobernanza de manera similar, reflejando los principios de descentralización, participación comunitaria, inclusividad y colaboración que han sido la piedra angular del ecosistema de la Blockchain de Cardano desde su inicio.
Reconociendo la necesidad de un marco de gobernanza más robusto y dinámico, y uno que utilice la tecnología blockchain en el proceso de gobernanza siempre que sea posible y beneficioso, la comunidad de Cardano, como miembros de este ecosistema descentralizado de la Blockchain de Cardano, establece por la presente esta Constitución Provisional de Cardano. Servirá como un conjunto de principios guía para la operación y gobernanza de nuestros esfuerzos colectivos, fomentando un entorno donde todos los participantes puedan contribuir al mejoramiento del ecosistema de la Blockchain de Cardano en su conjunto.
Juntos, la comunidad de Cardano se compromete a defender los principios de esta Constitución Provisional y a trabajar juntos hacia la mejora continua, el crecimiento y el éxito de nuestro ecosistema de blockchain descentralizado conocido como la Blockchain de Cardano.
Esta Constitución Provisional servirá como la encarnación de los principios rectores para la operación y gobernanza del ecosistema descentralizado de la Blockchain de Cardano, proporcionando una base que se adaptará y evolucionará con el tiempo para satisfacer las necesidades continuas de la comunidad de Cardano. Se espera que todos los miembros de la comunidad de Cardano cumplan con esta Constitución Provisional y tengan derecho a participar en sus procesos de gobernanza, incluyendo la realización de una Constitución Final que será ratificada por los poseedores de Ada, y se les anima a trabajar en colaboración hacia el mejoramiento del ecosistema de la Blockchain de Cardano en su conjunto, contribuyendo a su crecimiento, sostenibilidad y éxito.
ARTÍCULO I PRINCIPIOS DEL ECOSISTEMA DE LA BLOCKCHAIN DE CARDANO
Sección 1
Al adoptar una constitución, el ecosistema de la Blockchain de Cardano establecerá un marco de gobernanza robusto, asegurando que las decisiones se tomen en el mejor interés de la comunidad de Cardano. La comunidad de Cardano defenderá los principios de transparencia, apertura y gobernanza responsable, promoviendo una cultura de confianza y colaboración.
Sección 2
La Blockchain de Cardano será gobernada mediante un modelo de toma de decisiones basado en votaciones, fomentando la inclusividad, la diversidad de opiniones, la innovación y la adaptabilidad. Todos los poseedores de Ada tendrán la oportunidad de contribuir a la gobernanza y dirección del ecosistema descentralizado de la Blockchain de Cardano.
Sección 3
La Blockchain de Cardano operará de acuerdo con las Salvaguardias de la Blockchain de Cardano establecidas en el Apéndice de Salvaguardias de esta Constitución Provisional.
ARTÍCULO II LA COMUNIDAD DE LA BLOCKCHAIN DE CARDANO
Sección 1
No se requerirá una membresía formal para usar, participar y beneficiarse de la Blockchain de Cardano. En cambio, todos los poseedores de Ada, todos los desarrolladores de, todos aquellos que construyen en, y todos aquellos que de otra manera apoyan, mantienen o usan la Blockchain de Cardano son beneficiarios del ecosistema de la Blockchain de Cardano y, como tales, son colectivamente miembros de la comunidad de Cardano. Todos los miembros de la comunidad de Cardano son por lo tanto beneficiarios de esta Constitución Provisional, tienen derecho a sus derechos, privilegios y protecciones y, como tales, se espera que apoyen y defiendan esta Constitución Provisional.
Sección 2
Los miembros de la comunidad de Cardano que poseen ada tienen derecho a acceder y participar en los procesos de toma de decisiones en cadena del ecosistema de la Blockchain de Cardano, incluyendo votar y participar en la gobernanza en cadena con respecto a la Blockchain de Cardano.
Sección 3
Los miembros de la comunidad de Cardano tienen la responsabilidad de mantener la integridad del ecosistema de la Blockchain de Cardano siguiendo esta Constitución Provisional, operando la red de la Blockchain de Cardano, participando en actividades de gobernanza de la Blockchain de Cardano y resolviendo disputas de manera justa y transparente.
Sección 4
La comunidad de Cardano tiene derecho y se le anima, a través de las disposiciones de esta Constitución Provisional, a colaborar en el desarrollo, mantenimiento y construcción de aplicaciones para la comunidad de Cardano, y a formar organizaciones y entidades temporales y permanentes según lo considere deseable o apropiado en apoyo del ecosistema de la Blockchain de Cardano.
ARTÍCULO III GOBERNANZA PARTICIPATIVA
Sección 1
El ecosistema de la Blockchain de Cardano será gobernado por un modelo de gobernanza descentralizado y en cadena, utilizando, en la medida de lo posible y beneficioso, contratos inteligentes y otras herramientas basadas en blockchain para facilitar la toma de decisiones y asegurar la transparencia. La votación en la cadena para acciones de gobernanza seguirá el proceso descrito en CIP-1694 y las Salvaguardias de la Blockchain de Cardano.
Sección 2
Tres cuerpos de gobernanza independientes participarán en la votación para acciones de gobernanza en cadena para proporcionar controles y balances para la Blockchain de Cardano, consistiendo en Representantes Delegados (DRep), Operadores de Pool de Participación (SPO) y el Comité Constitucional (CC).
Sección 3
Las decisiones de gobernanza en cadena se tomarán a través de un proceso de toma de decisiones colectiva, con requisitos de umbral de consenso específicos según lo requerido por el CIP-1694. Todas las acciones de gobernanza en cadena serán votadas de acuerdo con el CIP-1694 y las Salvaguardias de la Blockchain de Cardano.
Sección 4
Todos los poseedores de Ada tendrán derecho a votar en los procesos de toma de decisiones de acciones de gobernanza en cadena, sujeto a cualquier restricción o requisito previsto en esta Constitución Provisional, incluyendo el CIP-1694 y las Salvaguardias de la Blockchain de Cardano. Los derechos de votación son proporcionales al Ada que se posee.
Todos los poseedores de Ada tendrán el derecho de proponer cambios a la estructura de gobernanza del ecosistema de la Blockchain de Cardano de acuerdo con el CIP-1694 y las Salvaguardias de la Blockchain de Cardano.
Sección 5
Existe una forma especial de acción de gobernanza para permitir que se evalúe el sentimiento de la comunidad sin comprometerse a ningún cambio en la cadena. Las acciones de “Información” no tienen efecto en la cadena más allá de registrar los votos sobre la acción.
Sección 6
Cualquier acción de gobernanza presentada a los poseedores de Ada para su aprobación deberá tener un formato estandarizado y legible, incluyendo una URL y un hash vinculado a contenido documentado fuera de la cadena. Se deberá proporcionar una justificación suficiente para justificar el cambio solicitado en la Blockchain de Cardano. La justificación deberá incluir, como mínimo, un título, un resumen, la razón de la propuesta y los materiales de apoyo relevantes.
Cualquier propuesta de acción de gobernanza que alcance la etapa de gobernanza en la cadena deberá ser idéntica en contenido a la versión final fuera de la cadena de dicha propuesta de acción de gobernanza.
Las acciones de gobernanza para la Iniciación de Hard Fork y Cambio de Parámetros de Protocolo deberán someterse a una revisión técnica suficiente y escrutinio según lo estipulado por las Salvaguardias de la Blockchain de Cardano para asegurar que la acción de gobernanza no ponga en peligro la seguridad, funcionalidad o rendimiento de la Blockchain de Cardano. Las acciones de gobernanza deben abordar su impacto esperado en el ecosistema de la Blockchain de Cardano.
Todos los poseedores de Ada tendrán el derecho de asegurar que el proceso para participar, presentar y votar en acciones de gobernanza sea abierto y transparente y esté protegido de influencias indebidas y manipulaciones.
Sección 7
Se espera que la comunidad de Cardano apoye la creación, el mantenimiento y la administración continua de procesos de gobernanza fuera de la cadena según sea necesario para dar efecto a los requisitos del CIP-1694 y para asegurar que haya conciencia y oportunidad para debatir y dar forma a todas las futuras acciones de gobernanza.
Sección 8
Cualquier acción de gobernanza que solicite ada del tesoro de Cardano en exceso de 1,000,000 ada deberá requerir una asignación de ada como parte de dicha solicitud de financiamiento para cubrir el costo de auditorías independientes periódicas y la implementación de métricas de supervisión sobre el uso de dicho ada.
ARTÍCULO IV REPRESENTANTES DELEGADOS
Sección 1
Para participar en acciones de gobernanza, los titulares de ada pueden registrarse como DReps y votar directamente en dichas acciones de gobernanza o pueden delegar sus derechos de voto a otros DReps registrados que votarán en su nombre.
Sección 2
Cualquier titular de Ada tendrá la opción de registrarse como un DRep. Cualquier titular de Ada podrá delegar su participación en la votación a uno o más DReps registrados, incluyendo a sí mismos. Los DReps pueden ser individuos o grupos coordinados. Los DReps tienen derecho a emitir votos directamente para acciones de gobernanza en cadena y representan a aquellos titulares de Ada que les delegan sus derechos de voto. Este sistema de votación consagrará un modelo de democracia líquida donde los titulares de Ada pueden seleccionar sin problemas entre DReps, registrarse como un DRep y cambiar su delegación en cualquier momento.
Se espera que la comunidad de Cardano apoye la creación, el mantenimiento y la administración continua de herramientas que permitan a los titulares de Ada explorar y evaluar candidatos a DRep y seleccionar DReps según los criterios que consideren relevantes.
Sección 3
Los DReps pueden ser compensados por sus esfuerzos para fomentar la creación de un cohorte de gobernanza profesional para el ecosistema de la Blockchain de Cardano. Los DReps deberán asegurar que cualquier compensación recibida en relación con sus actividades como DRep sea divulgada.
ARTÍCULO V OPERADORES DE STAKE POOL
Los SPOs tendrán un papel específico en la aprobación de acciones críticas de gobernanza en cadena que requieren supervisión adicional e independencia, votando por separado e independientemente de los DReps según lo establecido en el CIP-1694 y en las Guías de la Blockchain de Cardano. Los SPOs participarán en los procesos de iniciación de hard fork como operadores de los nodos que participan en el mecanismo de consenso de la Blockchain de Cardano. Los SPOs actuarán como un control sobre el poder del Comité Constitucional en circunstancias excepcionales votando sobre acciones de gobernanza de “Moción de no confianza” y “Actualizar comité/umbral”.
ARTÍCULO VI COMITÉ CONSTITUCIONAL
Sección 1
Se establecerá un Comité Constitucional como la rama del proceso de gobernanza en cadena de Cardano que asegura que las acciones de gobernanza sean consistentes con esta Constitución Provisional. El Comité Constitucional estará compuesto por un conjunto de titulares de Ada que son colectivamente responsables de asegurar que las acciones de gobernanza en cadena, antes de ser implementadas en cadena, sean constitucionales. El Comité Constitucional estará limitado a votar sobre la constitucionalidad de las acciones de gobernanza. Los miembros del Comité Constitucional serán titulares de Ada y se espera que tengan la experiencia adecuada, considerando sus contribuciones pasadas y su participación en el ecosistema de la Blockchain de Cardano.
Sección 2
Inicialmente, el Comité Constitucional estará compuesto por siete miembros. Los miembros iniciales del Comité Constitucional servirán un mandato inaugural de 73 épocas a partir de la fecha del hard fork Chang. Posteriormente, a través de una acción de gobernanza en cadena, los titulares de Ada pueden ajustar el número de miembros en el Comité Constitucional de acuerdo con las Guías de la Blockchain de Cardano. La comunidad de Cardano establecerá un proceso para la elección de los miembros del Comité Constitucional y, sujeto a las Guías de la Blockchain de Cardano, determinará el tamaño del Comité Constitucional de vez en cuando, asegurando que haya, en todo momento, un número suficiente de miembros del Comité Constitucional para asegurar la integridad de la Blockchain de Cardano. Las duraciones de los mandatos para los miembros del Comité Constitucional se establecerán de acuerdo con las Guías de la Blockchain de Cardano.
Sección 3
Ninguna acción de gobernanza, aparte de una “Moción de no confianza” o “Actualizar comité constitucional/umbral”, podrá ser implementada en cadena a menos que el Comité Constitucional haya determinado y afirmado primero a través de una acción en cadena que dicha propuesta no viola esta Constitución Provisional.
El Comité Constitucional se considerará en uno de los siguientes dos estados en todo momento: un estado de confianza o un estado de no confianza. En un estado de no confianza, los miembros del entonces Comité Constitucional en funciones deben ser reinstalados o reemplazados utilizando la acción de gobernanza de “Actualizar comité/umbral” antes de que cualquier otra acción de gobernanza pueda avanzar.
Sección 4
Los procesos del Comité Constitucional serán transparentes. El Comité Constitucional publicará cada decisión. Cuando vote en contra de una propuesta, el Comité establecerá la base para su decisión con referencia a Artículos específicos de esta Constitución que están en conflicto con una propuesta dada.
Sección 5
Se espera que la comunidad de Cardano apoye la creación, el mantenimiento y la administración continua de herramientas según sea necesario y apropiado para que el Comité Constitucional pueda realizar sus funciones requeridas.
ARTÍCULO VII ENMIENDAS
Sección 1
Las enmiendas a esta Constitución Provisional, incluyendo el Apéndice de Guías de la Blockchain de Cardano, deberán ser aprobadas por un proceso de toma de decisiones colectiva, requiriendo una acción de gobernanza en cadena que satisfaga el umbral de aprobación aplicable.
ARTÍCULO VIII PERÍODO INTERINO
Sección 1
El Período Interino será un período temporal que continuará hasta la fecha en que la Constitución Final haya sido ratificada por los titulares de Ada de acuerdo con la Ratificación de la Constitución Final según lo establecido en el Apéndice II.
Sección 2
El proceso para la transición de esta Constitución Provisional a la Constitución Final se contiene en el Apéndice II.
APÉNDICE I: GUÍAS DE LA BLOCKCHAIN DE CARDANO
1 INTRODUCCIÓN
Para implementar la gobernanza en cadena de la Blockchain de Cardano conforme al CIP-1694, es necesario establecer guías sensatas que permitan que la Blockchain de Cardano continúe operando de manera segura y sostenible.
Este Apéndice establece las guías que deben aplicarse a las acciones de gobernanza en cadena de la Blockchain de Cardano, incluyendo cambios en los parámetros del protocolo y límites en los retiros del tesoro. Estas guías cubren tanto límites esenciales e intrínsecos en configuraciones, como recomendaciones que se basan en la experiencia, medición y objetivos de gobernanza.
Estas guías están diseñadas para evitar problemas inesperados con la operación de la Blockchain de Cardano. Están destinadas a guiar la elección de configuraciones de parámetros sensatas y evitar problemas potenciales con la seguridad, el rendimiento o la funcionalidad. Como se describe a continuación, algunas de estas guías son automatizables y se harán cumplir mediante un script en cadena o reglas integradas en el libro mayor.
Estas guías se aplican al entorno de red principal de la Blockchain de Cardano Layer 1. No están destinadas a aplicarse a entornos de prueba o a otras blockchains que utilicen el software de la Blockchain de Cardano.
No todos los parámetros de la Blockchain de Cardano pueden considerarse independientemente. Algunos parámetros interactúan con otras configuraciones de manera intrínseca. Donde se conocen, estas interacciones se abordan en este Apéndice.
Si bien las guías en este Apéndice reflejan actualmente el estado actual del conocimiento técnico, este Apéndice debe tratarse como un documento vivo. Las mejoras en la implementación, nuevas simulaciones o resultados de evaluación del rendimiento para la Blockchain de Cardano pueden permitir que algunas de las restricciones contenidas en estas guías se relajen (o, en algunas circunstancias, se requiera que se endurezcan) en su momento. También pueden ser necesarias guías adicionales donde, por ejemplo, se introduzcan nuevos parámetros de protocolo. Las guías establecidas en este Apéndice pueden ser enmendadas de vez en cuando conforme a una acción de gobernanza en cadena que satisfaga el umbral de votación aplicable. Cualquier enmienda a cualquier guía se requerirá y se considerará una enmienda a la propia Constitución.
Terminología y Orientación
Debería/No debería. Donde este Apéndice dice que un valor “no debería” establecerse por debajo o por encima de algún valor, esto significa que la guía es una recomendación o directriz, y el valor específico podría estar abierto a discusión o alteración por un grupo adecuadamente experto reconocido por la comunidad de Cardano a la luz de la experiencia con el sistema de gobernanza de la Blockchain de Cardano o la operación de la Blockchain de Cardano.
Debe/No debe. Donde este Apéndice dice que un valor “no debe” establecerse por debajo o por encima de algún valor, esto significa que la guía es un requisito que será aplicado por las reglas del libro mayor de la Blockchain de Cardano, tipos u otros mecanismos integrados donde sea posible, y que si no se sigue podría causar una falla del protocolo, una violación de seguridad u otro resultado indeseable.
Evaluación Comparativa. La evaluación comparativa se refiere a la evaluación cuidadosa del rendimiento a nivel del sistema que está diseñada para mostrar a-priori que, por ejemplo, el 95% de los bloques se difundirán a través de una red global de nodos de la Blockchain de Cardano dentro del intervalo de tiempo requerido de 5 segundos en todos los casos. Esto puede requerir la construcción de flujos de trabajo de prueba específicos y la ejecución en una gran red de prueba de nodos de Cardano, simulando una red global de la Blockchain de Cardano.
Análisis de Rendimiento. El análisis de rendimiento se refiere a proyectar el rendimiento teórico, la evaluación comparativa empírica o los resultados de simulación para predecir el comportamiento real del sistema. Por ejemplo, los resultados de rendimiento obtenidos de pruebas en un entorno de prueba controlado (como una colección de centros de datos con propiedades de red conocidas) pueden extrapolarse para informar el comportamiento probable del rendimiento en un entorno real de la red de la Blockchain de Cardano.
Simulación. La simulación se refiere a la ejecución sintética que está diseñada para informar decisiones de rendimiento/funcionalidad de manera repetible. Por ejemplo, el módulo IOSim de la Blockchain de Cardano permite simular la operación de la pila de red de manera controlada y repetible, permitiendo detectar problemas antes del despliegue del código.
Monitoreo del Rendimiento. El monitoreo del rendimiento implica medir el comportamiento real de la red de la Blockchain de Cardano, por ejemplo, utilizando sondas de tiempo para evaluar los tiempos de ida y vuelta, o bloques de prueba para evaluar la salud general de la red. Complementa la evaluación comparativa y el análisis de rendimiento al proporcionar información sobre el comportamiento real del sistema que no puede obtenerse utilizando cargas de trabajo simuladas o análisis teóricos.
Revertir Cambios. Cuando el monitoreo del rendimiento muestra que el comportamiento real de la red después de un cambio es inconsistente con los requisitos de rendimiento para la Blockchain de Cardano, entonces el cambio debe revertirse a su estado anterior si eso es posible. Por ejemplo, si el tamaño del bloque se incrementa de 100KB a 120KB y el 95% de los bloques ya no se difunden dentro de los 5 segundos, entonces se debe realizar un cambio para revertir el tamaño del bloque a 100KB. Si esto no es posible, entonces se deben realizar uno o más cambios alternativos que aseguren que se cumplan los requisitos de rendimiento.
Niveles de Severidad. Los problemas que afectan a la red de la Blockchain de Cardano se clasifican por nivel de severidad, donde:
-
La severidad 1 es un incidente o problema crítico con un impacto muy alto en la seguridad, el rendimiento o la funcionalidad de la red de la Blockchain de Cardano.
-
La severidad 2 es un incidente o problema mayor con un impacto significativo en la seguridad, el rendimiento o la funcionalidad de la red de la Blockchain de Cardano.
-
La severidad 3 es un incidente o problema menor con un impacto bajo en la seguridad, el rendimiento o la funcionalidad de la red de la Blockchain de Cardano.
Requisitos de Rendimiento Futuro. El desarrollo planificado, como nuevos mecanismos para el almacenamiento fuera de la memoria, puede impactar la difusión de bloques u otros tiempos. Al cambiar los parámetros, es necesario considerar estos requisitos de rendimiento futuro así como la operación actual de la Blockchain de Cardano. Hasta que el desarrollo esté completo, los requisitos serán conservadores; luego pueden relajarse para tener en cuenta el comportamiento temporal real.
Comprobación Automatizada (“Script Guardarrail”)
Un hash de script se asocia con el hash de la constitución cuando se promulga una acción de gobernanza de Actualización de la Constitución o política de propuestas. Actúa como una salvaguardia adicional a las reglas y tipos del libro mayor, filtrando acciones de gobernanza no conformes.
El script de guías solo afecta dos tipos de acciones de gobernanza:
-
Acciones de Actualización de Parámetros, y
-
Acciones de Retiro del Tesoro.
El script se ejecuta cuando cualquiera de estos tipos de acción de gobernanza se envía en cadena. Esto evita escenarios donde, por ejemplo, un script erróneo podría impedir que la cadena implemente una acción de Hard Fork, resultando en un bloqueo. Existen tres situaciones diferentes que se aplican al uso del script.
Símbolo y Explicación
- (y) El script puede usarse para hacer cumplir la guía.
- (x) El script no puede usarse para hacer cumplir la guía.
- (~ - razón) El script no puede usarse para hacer cumplir la guía por la razón dada, pero los cambios futuros del libro mayor podrían permitir esto.
Las guías pueden superponerse: en este caso, se aplicará el conjunto de guías más restrictivo.
Donde un parámetro no esté explícitamente listado en este documento, el script no debe permitir ningún cambio en el parámetro.
Por el contrario, donde un parámetro esté explícitamente listado en este documento pero no se especifiquen guías verificables, el script no debe imponer ninguna restricción sobre los cambios en el parámetro.
2 GUÍAS Y DIRECTRICES SOBRE ACCIONES DE ACTUALIZACIÓN DE PARÁMETROS DEL PROTOCOLO
A continuación se presentan guías y directrices para cambiar configuraciones de parámetros actualizables del protocolo a través de la acción de gobernanza de actualización de parámetros del protocolo, de modo que la Blockchain de Cardano nunca esté en un estado irrecuperable como resultado de tales cambios.
Nota que hay al menos cinco fuentes diferentes de nombres de parámetros, y estos no siempre son consistentes:
-
El nombre utilizado en el archivo Genesis.
-
El nombre utilizado en acciones de gobernanza de actualización de parámetros del protocolo.
-
El nombre utilizado internamente en las reglas del libro mayor.
-
El nombre utilizado en la especificación formal del libro mayor.
-
El nombre utilizado en trabajos de investigación.
Donde estos nombres de parámetros difieran, este Apéndice utiliza la segunda convención.
Guardarrailes
PARAM-01 (y) Cualquier parámetro del protocolo que no esté explícitamente nombrado en este documento no debe ser cambiado por una acción de gobernanza de actualización de parámetros.
PARAM-02 (y) Donde un parámetro del protocolo esté explícitamente listado en este documento pero no se especifiquen guías verificables, el script de guías no debe imponer ninguna restricción sobre los cambios en el parámetro. Las guías verificables se muestran con un (y).
2.1 Parámetros Críticos del Protocolo
Parámetros Críticos para la Operación de la Blockchain
-
tamaño máximo del cuerpo del bloque (maxBlockBodySize)
-
tamaño máximo de la transacción (maxTxSize)
-
tamaño máximo del encabezado del bloque (maxBlockHeaderSize)
-
tamaño máximo de un valor de activo serializado (maxValueSize)
-
unidades máximas de ejecución/memoria de script en un solo bloque (maxBlockExecutionUnits[steps/memory])
-
coeficiente de tarifa mínima (txFeePerByte)
-
constante de tarifa mínima (txFeeFixed)
-
tarifa mínima por byte para scripts de referencia (minFeeRefScriptCoinsPerByte)
-
depósito mínimo de Lovelace por byte de UTxO serializado (utxoCostPerByte)
-
depósito de acción de gobernanza (govDeposit)
Guardarrailes
PARAM-03 (y) Los parámetros críticos del protocolo requieren un voto de los SPO además de un voto de los DRep: los SPO deben decir “sí” con un apoyo colectivo de más del 50% de toda la participación activa en la producción de bloques. Esto se aplica por las guías sobre el umbral de votación de los operadores de stake pools.
PARAM-04 (x) Normalmente deben pasar al menos 3 meses entre la publicación de una propuesta fuera de cadena para cambiar un parámetro crítico del protocolo y la presentación de la correspondiente acción de gobernanza en cadena. Esta guía puede relajarse en caso de un problema de severidad 1 o severidad 2 en la red tras una cuidadosa discusión y evaluación técnica.
Parámetros Críticos para el Sistema de Gobernanza
-
depósito de clave de delegación en Lovelace (stakeAddressDeposit)
-
depósito de registro de pool en Lovelace (stakePoolDeposit)
-
corte mínimo de recompensas fijas para pools (minPoolCost)
-
monto del depósito de DRep (dRepDeposit)
-
tamaño mínimo del Comité Constitucional (committeeMinSize)
-
límite máximo de mandato (en épocas) para los miembros del Comité Constitucional (committeeMaxTermLimit)
Guardrails
PARAM-05 (y) Los DReps deben votar “sí” con un apoyo colectivo de más del 50% de toda la participación activa en la votación. Esto se aplica por las guías sobre los umbrales de votación de los DReps.
PARAM-06 (x)
Normalmente deben pasar al menos 3 meses entre la publicación de una propuesta fuera de cadena para cambiar un parámetro que sea crítico para el sistema de gobernanza y la presentación de la correspondiente acción de gobernanza en cadena. Esta guía puede relajarse en caso de un problema de severidad 1 o severidad 2 en la red tras una cuidadosa discusión y evaluación técnica.
2.2 Parámetros Económicos
Los objetivos generales al gestionar los parámetros económicos son:
- Habilitar la sostenibilidad económica a largo plazo para el ecosistema de la Blockchain de Cardano.
- Asegurar que los operadores de stake pools sean adecuadamente recompensados por mantener la Blockchain de Cardano.
- Asegurar que los titulares de Ada sean adecuadamente recompensados por usar la participación de manera constructiva, incluyendo cuando delegan ada para la producción de bloques.
- Equilibrar los incentivos económicos para diferentes partes interesadas del ecosistema de la Blockchain de Cardano, incluyendo, pero no limitado a, los Operadores de Stake Pools, los titulares de Ada, los usuarios de DeFi, los usuarios de infraestructura, los desarrolladores (por ejemplo, DApps) y los intermediarios financieros (por ejemplo, exchanges).
Disparadores para el Cambio
-
Cambios significativos en el valor fiat de Ada resultando en problemas potenciales con la seguridad, el rendimiento o la funcionalidad.
-
Cambios en los volúmenes o tipos de transacciones.
-
Solicitudes o sugerencias de la comunidad.
-
Situaciones de emergencia que requieran cambios en los parámetros económicos.
Contraindicadores
Los cambios en los parámetros económicos no deben hacerse de forma aislada. Necesitan tener en cuenta:
-
Factores económicos externos.
-
Preocupaciones de seguridad de la red.
Métricas Clave
-
Valor fiat de Ada resultando en problemas potenciales con la seguridad, el rendimiento o la funcionalidad.
-
Volúmenes y tipos de transacciones.
-
Número y salud de los stake pools.
-
Factores económicos externos.
Cambios a Parámetros Económicos Específicos
Tarifa de transacción por byte (txFeePerByte) y tarifa fija de transacción (txFeeFixed)
Define el costo para transacciones básicas en Lovelace:
tarifa(tx) = txFeeFixed + txFeePerByte x nBytes(tx)
Guardarrailes
TFPB-01 (y) txFeePerByte no debe ser inferior a 30 (0.000030 ada). Esto protege contra ataques de denegación de servicio de bajo costo.
TFPB-02 (y) txFeePerByte no debe exceder 1,000 (0.001 ada). Esto asegura que se puedan pagar las transacciones.
TFPB-03 (y) txFeePerByte no debe ser negativo.
TFF-01 (y) txFeeFixed no debe ser inferior a 100,000 (0.1 ada). Esto protege contra ataques de denegación de servicio de bajo costo.
TFF-02 (y) txFeeFixed no debe exceder 10,000,000 (10 ada). Esto asegura que se puedan pagar las transacciones.
TFF-03 (y) txFeeFixed no debe ser negativo.
TFGEN-01 (x - “debería”) Para mantener un nivel consistente de protección contra ataques de denegación de servicio, txFeeFixed y txFeeFixed deberían ajustarse siempre que se ajusten los precios de ejecución de Plutus (executionUnitPrices[steps/memory]).
TFGEN-02 (x - no cuantificable) Cualquier cambio a txFeeFixed o txFeeFixed debe considerar las implicaciones de reducir el costo de un ataque de denegación de servicio o aumentar la tarifa máxima de transacción para que sea imposible construir una transacción.
Costo de UTxO por byte (utxoCostPerByte)
Define el costo para el almacenamiento en UTxOs
-
Establece un umbral mínimo en ada que se mantiene dentro de un solo UTxO (~1 ada mínimo, podría ser >= 50 ada en el peor de los casos)
-
Proporciona protección contra ataques de denegación de servicio de bajo costo en el almacenamiento de UTxO. Este ataque se ha ejecutado en otras cadenas, no es teórico. La protección DoS disminuye en línea con la memoria libre del nodo (proporcional al crecimiento de UTxO).
-
Ayuda a reducir los costos de almacenamiento a largo plazo.
-
Proporciona un incentivo para devolver UTxOs cuando ya no se necesitan. Debería exceder significativamente el costo mínimo de tx (~ 0.15 ada).
Guardarrailes
UCPB-01 (y) utxoCostPerByte no debe ser inferior a 3,000 (0.003 ada).
UCPB-02 (y) utxoCostPerByte no debe exceder 6,500 (0.0065 ada).
UCPB-03 (y) utxoCostPerByte no debe ser cero.
UCPB-04 (y) utxoCostPerByte no debe ser negativo.
UCPB-05 (x - “debería”) Los cambios deben tener en cuenta i) El costo aceptable del ataque ii) El tiempo aceptable para un ataque (se asume al menos una época) iii) La configuración de memoria aceptable para los usuarios de nodos completos (se asume 16GB para billeteras o 24GB para stake pools) iv) Los tamaños de UTxOs (~200B por UTxO mínimo, hasta alrededor de 10KB) y v) El uso total actual de memoria del nodo.
Depósito de dirección de stake (stakeAddressDeposit)
Asegura que las direcciones de stake se retiren cuando ya no se necesitan
-
Ayuda a reducir los costos de almacenamiento a largo plazo.
-
Ayuda a limitar los costos de CPU y memoria en el libro mayor.
La razón para el depósito es incentivar que los recursos de memoria escasos se devuelvan cuando ya no se requieren. Reducir el número de direcciones de stake activas también reduce los costos de procesamiento y memoria en el límite de la época al calcular instantáneas de stake.
Guardarrailes
SAD-01 (y) stakeAddressDeposit no debe ser inferior a 1,000,000 (1 ada).
SAD-02 (y) stakeAddressDeposit no debe exceder 5,000,000 (5 ada).
SAD-03 (y) stakeAddressDeposit no debe ser negativo.
Depósito de stake pool (stakePoolDeposit)
Asegura que los stake pools sean retirados por el operador del stake pool cuando ya no los necesiten
- Ayuda a reducir los costos de almacenamiento a largo plazo.
La razón para el depósito es incentivar que los recursos de memoria escasos se devuelvan cuando ya no se requieren. Las recompensas y los cálculos de instantáneas de stake también se ven afectados por el número de stake pools activos.
Guardarrailes
SPD-01 (y) stakePoolDeposit no debe ser inferior a 250,000,000 (250 ada).
SPD-02 (y) stakePoolDeposit no debe exceder 500,000,000 (500 ada).
SPD-03 (y) stakePoolDeposit no debe ser negativo.
Costo Mínimo de Pool (minPoolCost)
Parte del mecanismo de recompensas
- El costo mínimo de pool se transfiere a la dirección de recompensas del pool antes de que se paguen las recompensas de los delegadores.
Guardarrailes
MPC-01 (y) minPoolCost no debe ser negativo.
MPC-02 (y) minPoolCost no debe exceder 500,000,000 (500 ada).
MPC-03 (x - “debería”) minPoolCost debería establecerse en línea con el costo económico para operar un pool.
Corte del Tesoro (treasuryCut)
Parte del mecanismo de recompensas
-
La porción del corte del tesoro de la expansión monetaria se transfiere al tesoro antes de que se paguen las recompensas del pool.
-
Puede establecerse en el rango 0.0-1.0 (0%-100%).
Guardarrailes
TC-01 (y) treasuryCut no debe ser inferior a 0.1 (10%).
TC-02 (y) treasuryCut no debe exceder 0.3 (30%).
TC-03 (y) treasuryCut no debe ser negativo.
TC-04 (y) treasuryCut no debe exceder 1.0 (100%).
TC-05 (~ - sin acceso a historial de cambios) treasuryCut no debe cambiarse más de una vez en cualquier período de 36 épocas (aproximadamente 6 meses).
Tasa de Expansión Monetaria (monetaryExpansion)
Parte del mecanismo de recompensas
- La expansión monetaria controla la cantidad de reservas que se utiliza para recompensas en cada época.
Gobierna la sostenibilidad a largo plazo de Cardano.
- Las reservas se van agotando gradualmente hasta que no se suministran más recompensas.
Guardarrailes
ME-01 (y) monetaryExpansion no debe exceder 0.005.
ME-02 (y) monetaryExpansion no debe ser inferior a 0.001.
ME-03 (y) monetaryExpansion no debe ser negativo.
ME-04 (x - “debería”) monetaryExpansion no debería variar en más de +/- 10% en cualquier período de 73 épocas (aproximadamente 12 meses).
ME-05 (x - “debería”) monetaryExpansion no debería cambiarse más de una vez en cualquier período de 36 épocas (aproximadamente 6 meses).
Precios de Ejecución de Scripts Plutus (executionUnitPrices[priceSteps/priceMemory])
Definen las tarifas para ejecutar scripts Plutus
Proporciona un retorno económico por la ejecución de scripts Plutus.
Proporciona seguridad contra ataques DoS de bajo costo.
Guardarrailes
EIUP-PS-01 (y) executionUnitPrices[priceSteps] no debe exceder 2,000 / 10,000,000.
EIUP-PS-02 (y) executionUnitPrices[priceSteps] no debe ser inferior a 500 / 10,000,000.
EIUP-PM-01 (y) executionUnitPrices[priceMemory] no debe exceder 2,000 / 10,000.
EIUP-PM-02 (y) executionUnitPrices[priceMemory] no debe ser inferior a 400 / 10,000.
EIUP-GEN-01 (x - “similar a”) Los precios de ejecución deben establecerse para que i) el costo de ejecutar una transacción con pasos máximos de CPU sea similar al costo de una transacción de tamaño máximo sin script y ii) el costo de ejecutar una transacción con unidades máximas de memoria sea similar al costo de una transacción de tamaño máximo sin script.
EIUP-GEN-02 (x - “debería”) Los precios de ejecución deberían ajustarse siempre que se ajusten las tarifas de transacción (txFeeFixed/txFeePerByte). El objetivo es asegurar que el retraso en el procesamiento sea similar para las transacciones “completas”, independientemente de su tipo. Esto ayuda a asegurar que se cumplan los requisitos en los tiempos de difusión/propagación de bloques.
Tarifas de Transacción por Byte para un Script de Referencia (minFeeRefScriptCoinsPerByte)
Define el costo por utilizar scripts de referencia Plutus en Lovelace.
Guardarrailes
MFRS-01 (y) minFeeRefScriptCoinsPerByte no debe exceder 1,000 (0.001 ada).
- Esto asegura que las transacciones puedan ser pagadas.
MFRS-02 (y) minFeeRefScriptCoinsPerByte no debe ser negativo.
MFRS-03 (x - “debería”) Para mantener un nivel consistente de protección contra ataques de denegación de servicio, minFeeRefScriptCoinsPerByte debería ajustarse siempre que se ajusten los precios de Ejecución de Plutus (executionUnitPrices[steps/memory]) y siempre que se ajuste txFeeFixed.
MFRS-04 (x - no cuantificable) Cualquier cambio en minFeeRefScriptCoinsPerByte debe considerar las implicaciones de reducir el costo de un ataque de denegación de servicio o aumentar la tarifa máxima de transacción.