Traducción al español de la Constitución del Ecosistema Cardano

Español Educación
1

Comparto una traducción al castellano de la Cardano Blockchain Ecosystem Constitution, vigente desde la época 609.

La traducción fue realizada con asistencia de inteligencia artificial mediante Google Gemini. Mi objetivo es facilitar el acceso al documento para la comunidad hispanohablante, no crear una versión oficial ni realizar una interpretación jurídica del texto.

Aunque revisaré el contenido para detectar errores evidentes, pueden existir imprecisiones, diferencias terminológicas o matices perdidos durante la traducción. En caso de duda o discrepancia, debe considerarse siempre como referencia el documento original en inglés.

Las correcciones, observaciones y sugerencias de la comunidad son bienvenidas.

CONSTITUCIÓN DEL ECOSISTEMA DE LA BLOCKCHAIN DE CARDANO

PREÁMBULO

Cardano es un ecosistema descentralizado de tecnología blockchain, contratos inteligentes y gobernanza comunitaria, comprometido con la mejora de los sistemas económicos, políticos y sociales para todas las personas, en todas partes. Al ofrecer esta infraestructura fundamental, Cardano empodera a las personas y a las comunidades para que gestionen su identidad, valor y gobernanza, fomentando el surgimiento de aplicaciones descentralizadas, empresas y estados red.

A través del procesamiento imparcial de datos inmutables, nosotros, los participantes de la Comunidad de Cardano, conformada por individuos, organizaciones, contribuyentes y otros, elegimos seguir los pasos de los pioneros de Internet y de las criptomonedas, quienes forjaron por primera vez los lazos de comunidad a través de tecnologías digitales. Nos guían nuestros principios y dogmas compartidos mientras ejercemos nuestro autogobierno equilibrando la toma de decisiones descentralizada con la rendición de cuentas y salvaguardando la seguridad de la Blockchain de Cardano.

Reconociendo la necesidad de un marco de gobernanza más robusto y dinámico, que no se base ni dependa de los sistemas de gobernanza tradicionales de los estados-nación, sino que se base en el autogobierno de la Comunidad de Cardano, utilizando, siempre que sea posible y beneficioso, la tecnología blockchain en el proceso de gobernanza, establecemos por la presente esta Constitución de Cardano para gobernar el ecosistema de la Blockchain de Cardano, garantizar la continuidad de la Blockchain de Cardano y proteger los derechos de quienes la utilizan y los derechos de los propietarios de ada.

Con estos propósitos en mente, nosotros, la Comunidad de Cardano, afirmamos nuestra intención de acatar esta Constitución para poder participar en la gobernanza del ecosistema de la Blockchain de Cardano. Invitamos a todos los que comparten nuestros valores a unirse a nosotros durante el tiempo que deseen, respetando siempre la libertad de tomar otro camino.

TÉRMINOS DEFINIDOS

  1. Stake de Votación Activo (Active Voting Stake): La cantidad total de lovelace que está delegada a DReps o SPOs activos. Este stake (participación) se utiliza como base para calcular los umbrales de votación y juzgar los resultados de las acciones de gobernanza propuestas. Excluye el stake delegado a DReps inactivos, la opción de voto de abstención predefinida, el stake no registrado y el stake registrado no delegado.

  2. Comunidad de Cardano: El grupo colectivo de todas las personas y organizaciones que, al adoptar los principios y objetivos compartidos establecidos en la Constitución del Ecosistema de la Blockchain de Cardano, poseen ada, desarrollan, construyen, apoyan, mantienen, contribuyen a y utilizan la Blockchain de Cardano.

  3. Miembro de la Comunidad de Cardano: Cualquier participante, individuo u organización en la Comunidad de Cardano, incluyendo el CC.

  4. Comité Constitucional (CC): El órgano rector y sus escaños elegidos encargados de garantizar que las acciones de gobernanza aplicables entren en vigor en la Blockchain de Cardano solo si están alineadas con los principios y disposiciones establecidos en la Constitución del Ecosistema de la Blockchain de Cardano.

  5. Miembro del Comité Constitucional (Miembro del CC): Una persona, ya sea un individuo u organización, que sirve como miembro del Comité Constitucional.

  6. Representante Delegado (DRep): El individuo o entidad registrada para votar con respecto a acciones de gobernanza on-chain en su propio nombre o en nombre de otros propietarios de ada.

  7. Límite de Cambio Neto (Net Change Limit): La cantidad o porcentaje máximo permitido de lovelace que puede retirarse del Tesoro de Cardano en un período determinado.

  8. Operador de Stake Pool (SPO): Un individuo o entidad que controla la(s) clave(s) en frío de un nodo productor de bloques de un Stake Pool.

  9. Stake Pool: El nodo productor de bloques de un Operador de Stake Pool, identificado por un ID de Stake Pool único, que agrega el stake de los Delegadores aplicables, forja y valida Bloques, y facilita las contribuciones del SPO a la seguridad, descentralización, mecanismo de consenso y proceso de gobernanza de la Blockchain de Cardano.

  10. Receptor de Retiros del Tesoro: Una persona o entidad que se indica como el receptor de ada del Tesoro de Cardano en la acción relevante de “Retiros del Tesoro” (Treasury Withdrawals).

ARTÍCULO I. DOGMAS Y GUARDRAILS DE LA BLOCKCHAIN DE CARDANO

Sección 1: Dogmas Rectores

Los siguientes Dogmas guiarán a todos los miembros de la Comunidad de Cardano y las acciones de gobernanza propuestas se evaluarán de acuerdo con estos Dogmas. El orden en que aparecen los Dogmas a continuación no pretende representar una prioridad entre ellos.

  • DOGMA 1: Las transacciones en la Blockchain de Cardano no serán ralentizadas ni censuradas y se procesarán de manera expedita para su propósito previsto.

  • DOGMA 2: El costo de las transacciones en la Blockchain de Cardano será predecible y no irrazonable.

  • DOGMA 3: Cualquier persona que desee desarrollar e implementar aplicaciones en la Blockchain de Cardano no se le impedirá irrazonablemente desarrollar e implementar dichas aplicaciones según lo previsto.

  • DOGMA 4: Las contribuciones de la Comunidad de Cardano en la Blockchain de Cardano serán reconocidas, registradas y evaluadas de manera justa a través del reparto de recompensas con los SPOs, compensación potencial a los DReps y miembros del CC, y una tokenomics apropiada.

  • DOGMA 5: La Blockchain de Cardano no bloqueará el valor ni los datos de un propietario de ada sin su consentimiento.

  • DOGMA 6: La Blockchain de Cardano no impedirá irrazonablemente la interoperabilidad.

  • DOGMA 7: La Blockchain de Cardano preservará de manera segura cualquier valor e información almacenados en ella.

  • DOGMA 8: La Blockchain de Cardano no gastará recursos de manera irrazonable.

  • DOGMA 9: Todos los usuarios de la Blockchain de Cardano serán tratados de manera justa e imparcial, teniendo en cuenta los deseos colectivos de la Comunidad de Cardano, en consonancia con la sostenibilidad y viabilidad a largo plazo de la Blockchain.

  • DOGMA 10: El sistema monetario de la Blockchain de Cardano promoverá la estabilidad financiera. Esto incluirá buscar preservar el valor y la utilidad de ada como medio de intercambio, reserva de valor y unidad de cuenta. El suministro total de ada no superará los 45.000.000.000 (45.000.000.000.000.000 lovelace).

Sección 2: Implementación de los Guardrails (Límites de Seguridad)

  1. La Blockchain de Cardano operará de acuerdo con el Apéndice de Guardrails de la Blockchain de Cardano adjunto a esta Constitución. La Comunidad de Cardano puede codificar digitalmente ciertos Guardrails de modo que se programen e implementen directamente en la Blockchain de Cardano utilizando un Script de Guardrails on-chain o reglas de libro mayor (ledger) incorporadas.

  2. En caso de que existan inconsistencias entre un Guardrail tal como se establece en el Apéndice de Guardrails y cualquier Guardrail que haya sido programado e implementado en la Blockchain de Cardano, prevalecerá la versión de dicho Guardrail que se haya implementado directamente en la Blockchain de Cardano a menos y hasta que sea reemplazada o revisada de conformidad con una acción de gobernanza on-chain. El CC buscará conciliar dichas inconsistencias fomentando una acción de gobernanza on-chain apropiada.

ARTÍCULO II. COMUNIDAD Y GOBERNANZA

Sección 1: La Comunidad de Cardano

  1. No se requerirá membresía formal para usar, participar y beneficiarse de la Blockchain de Cardano. Los miembros de la Comunidad de Cardano tienen derecho a los derechos, privilegios y protecciones de esta Constitución, y en consecuencia se espera que apoyen y defiendan esta Constitución, mantengan la integridad del ecosistema, participen en la gobernanza y resuelvan las disputas de manera transparente.

  2. Se anima a los miembros de la Comunidad de Cardano a colaborar en el desarrollo de aplicaciones y a formar organizaciones que apoyen a la Blockchain de Cardano y a su Comunidad.

Sección 2: Derechos de Participación de los propietarios de ada

  1. Los propietarios de ada tienen derecho a acceder y participar en los procesos de toma de decisiones on-chain del ecosistema de la Blockchain de Cardano, lo que incluye votar, proponer cambios a la estructura de gobernanza de acuerdo con los Guardrails, y participar de otras maneras en las acciones de gobernanza on-chain.

  2. Los propietarios de ada pueden participar directamente en las acciones de gobernanza registrándose ellos mismos como DReps o delegando sus derechos de voto a otros DReps registrados.

  3. A cualquier propietario de ada se le permitirá registrarse como DRep. Un DRep puede actuar en interés de uno o más propietarios de ada.

  4. A cualquier propietario de ada se le permitirá delegar su stake de votación a uno o más DReps registrados, incluidos ellos mismos.

  5. A los propietarios de ada se les permitirá cambiar la delegación de su stake de votación en cualquier momento.

  6. Los propietarios de ada que utilizan custodios de terceros u otros designados para mantener sus ada pueden autorizar, o pueden retener la autorización, para que dichos terceros voten en su nombre y deleguen los derechos de voto del propietario de ada a DReps registrados en nombre del propietario.

  7. Los propietarios de ada tienen derecho a un proceso para participar, enviar y votar acciones de gobernanza on-chain que sea abierto, transparente y esté protegido contra influencias indebidas y manipulación.

Sección 3: Marco de Gobernanza Descentralizada

  1. La Blockchain de Cardano se rige por un modelo descentralizado y on-chain que, donde es beneficioso, utiliza contratos inteligentes y otras herramientas blockchain para facilitar la toma de decisiones y garantizar la transparencia.

  2. Tres cuerpos de votación independientes (DReps, SPOs y el CC) participan en la votación on-chain; cualquier persona que tenga múltiples roles debe revelar públicamente dichas superposiciones antes de participar en cualquier acción de gobernanza on-chain.

Sección 4: Representantes Delegados (DReps)

  1. Los DReps tienen un poder de voto igual al número de lovelace delegados a ellos.

  2. Los DReps pueden votar en todos los tipos de acciones de gobernanza.

  3. Los DReps deberán garantizar que cualquier compensación recibida en relación con sus actividades como DRep se divulgue públicamente de manera oportuna a través de los canales de comunicación de gobernanza relevantes.

  4. Los DReps no ofrecerán ni proporcionarán compensación a un propietario de ada a cambio de ser designados como DRep o por votar en su nombre.

Sección 5: Operadores de Stake Pool (SPOs)

  1. Los SPOs votarán sobre las siguientes acciones de gobernanza: “Falta de Confianza” (No Confidence), “Actualizar Comité” (Update Committee), “Iniciación de Hard Fork” (Hard Fork Initiation), “Actualización de Parámetros” (Parameter Update) que afecten a parámetros relevantes para la seguridad, y acciones de “Info”.

Sección 6: Estándares de las Acciones de Gobernanza

  1. Para garantizar la transparencia en la gobernanza on-chain, las acciones de gobernanza propuestas deberán seguir un formato estandarizado y legible antes de registrarse o promulgarse on-chain. Este formato incluirá una URL que aloje un documento que describa contexto adicional para la acción de gobernanza propuesta, y el hash de este documento. El documento alojado en dicha URL deberá ser inmutable e incapaz de ser alterado después de su presentación, y el contenido de toda Acción de Gobernanza on-chain debe ser idéntico a la versión final off-chain de la acción propuesta.

  2. Cada propuesta deberá proporcionar una justificación suficiente, incluyendo como mínimo: un título, resumen, justificación y materiales de apoyo relevantes.

  3. Las acciones de “Iniciación de Hard Fork” y “Actualización de Parámetros” se someterán a suficiente revisión técnica y escrutinio según lo ordenado por los Guardrails para garantizar que la acción de gobernanza no ponga en peligro la seguridad, funcionalidad, rendimiento o sostenibilidad a largo plazo de la Blockchain de Cardano.

Sección 7: Estándares para las Acciones de “Retiros del Tesoro”

Una acción de “Retiros del Tesoro” (Treasury Withdrawals) debe, además de los requisitos de la Sección 6, cumplir con todos los siguientes requisitos:

  1. Las acciones de “Retiros del Tesoro” deben especificar los términos del retiro. Esto incluirá: el propósito del retiro, el período de entrega de las actividades propuestas para las que se utilizará el retiro, los costos y gastos relevantes de las actividades propuestas, y las circunstancias bajo las cuales el retiro podría ser reembolsado al Tesoro de Cardano.

  2. Las acciones de “Retiros del Tesoro” divulgarán si el posible receptor de la acción de “Retiros del Tesoro” ha recibido ada del Tesoro de Cardano en los últimos 24 meses.

  3. Se debe establecer un Límite de Cambio Neto. Las acciones de “Retiros del Tesoro” no deben superar el Límite de Cambio Neto para ese período.

  4. Las acciones de “Retiros del Tesoro” requerirán 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.

  5. Las acciones de “Retiros del Tesoro” designarán a uno o más administradores responsables de monitorear cómo se utilizan los fondos y garantizar que se logren los entregables.

  6. Cualquier ada recibido de un retiro del tesoro de la Blockchain de Cardano, siempre que dicho ada esté en manos de un administrador antes de su posterior desembolso al Receptor del Retiro del Tesoro, debe mantenerse en una o más cuentas separadas que puedan ser auditadas por la Comunidad de Cardano, y dichas cuentas no se delegarán a un SPO, sino que deben delegarse a la opción de voto de abstención predefinida.

ARTÍCULO III. COMITÉ CONSTITUCIONAL

Sección 1: Rol y Alcance

  1. Se establecerá un CC como la rama del proceso de gobernanza on-chain de Cardano que asegura que las acciones de gobernanza a promulgarse on-chain sean consistentes con esta Constitución.

  2. Cada miembro del CC tendrá un voto.

  3. Ninguna acción de gobernanza (que no sea una acción de “Falta de Confianza” o “Actualizar Comité”) puede implementarse on-chain sin la afirmación de un porcentaje requerido de los miembros del CC.

  4. El CC se limitará a votar sobre la constitucionalidad de las acciones de gobernanza, incluidas las acciones propuestas o contempladas contenidas dentro de las acciones de “Info”.

Sección 2: Composición y Mandatos

  1. El CC estará compuesto por la cantidad de miembros y cumplirá mandatos de tal duración que sean suficientes para asegurar la integridad continua de la Blockchain de Cardano, según lo determinen periódicamente los propietarios de Ada.

  2. Para asegurar la continuidad en la operación del CC, los mandatos de los miembros del CC estarán escalonados.

Sección 3: Proceso de Elección, Falta de Confianza y Remoción

  1. Se considerará que el CC se encuentra en uno de los siguientes dos estados en todo momento: un estado de confianza o un estado de falta de confianza. En un estado de falta de confianza, los miembros del CC vigente deben ser reinstalados o reemplazados utilizando la acción de “Actualizar Comité” antes de que cualquier otra acción de gobernanza on-chain, aparte de las acciones de “Info”, pueda avanzar.

  2. La Comunidad de Cardano establecerá y hará público un proceso periódico para la elección de los miembros del CC de acuerdo con los requisitos de los Guardrails.

  3. En el caso de un voto de falta de confianza o la remoción de algunos miembros del CC mediante la acción de “Actualizar Comité”, se llevará a cabo una elección lo antes posible.

Sección 4: Transparencia y Conducta

  1. Los procesos del CC serán transparentes, y el CC publicará cada decisión.

  2. Al votar que una acción de gobernanza que se propone ejecutar on-chain es inconstitucional, cada miembro del CC que emita dicho voto expondrá las bases de su decisión haciendo referencia a los Artículos específicos de esta Constitución o a las disposiciones del Apéndice de Guardrails de la Blockchain de Cardano que estén en conflicto con una propuesta determinada.

  3. Los miembros del CC pueden ser compensados por sus esfuerzos como miembros y se asegurarán de que cualquier compensación recibida en relación con dichas actividades sea divulgada de manera oportuna a través de los canales de comunicación de gobernanza relevantes.

ARTÍCULO IV. PROCESO DE ENMIENDA

Sección 1: Reglas de Enmienda

Las enmiendas a esta Constitución, incluido el Apéndice de Guardrails de la Blockchain de Cardano, requerirán aprobación mediante una acción de gobernanza on-chain respaldada por al menos el 65% del stake de votación activo en ese momento, a menos que se estipule expresamente un umbral diferente en el Apéndice de Guardrails de la Blockchain de Cardano para la enmienda de un Guardrail en particular, en cuyo caso se aplicará ese umbral.

(Nota: A continuación sigue la traducción de los Apéndices I y II. Debido a la gran longitud del documento original, he traducido todo de forma continua manteniendo el máximo rigor técnico.)

APÉNDICE I. GUARDRAILS DE LA BLOCKCHAIN DE CARDANO

1. Introducción

Para implementar la gobernanza on-chain de la Blockchain de Cardano, es necesario establecer Guardrails sensatos que permitan a la Blockchain de Cardano continuar operando de manera segura y sostenible.

Este Apéndice establece Guardrails que deben aplicarse a las acciones de gobernanza on-chain de la Blockchain de Cardano, incluidos los cambios en los parámetros del protocolo y los límites sobre los retiros del tesoro. Estos Guardrails cubren tanto los límites esenciales e intrínsecos de las configuraciones como las recomendaciones basadas en experiencia, investigación, mediciones y objetivos de gobernanza.

Estos Guardrails están diseñados para evitar problemas imprevistos y previsibles en la operación de la Blockchain de Cardano. Su intención es guiar la selección de configuraciones de parámetros sensatas y evitar posibles problemas con la seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo. Como se describe a continuación, algunos de estos Guardrails son automatizables y se aplicarán a través de un Script de Guardrails on-chain o reglas de libro mayor incorporadas.

Estos Guardrails se aplican únicamente al entorno de la red principal (mainnet) Capa 1 (Layer 1) de la Blockchain de Cardano. No están pensados para aplicarse a entornos de prueba (testnets) ni a otras blockchains que utilicen el software de la Blockchain de Cardano.

No todos los parámetros para la Blockchain de Cardano pueden considerarse de manera independiente. Algunos interactúan con otras configuraciones de manera intrínseca. Donde son conocidas, estas interacciones se abordan en este Apéndice.

Aunque los Guardrails en este Apéndice reflejan actualmente el estado actual del conocimiento técnico, este documento debe tratarse como un documento vivo. Las mejoras en la implementación, nuevas simulaciones o resultados de evaluaciones de rendimiento para la Blockchain de Cardano podrían permitir relajar o ajustar algunas de las restricciones contenidas aquí en el momento oportuno.

También pueden necesitarse Guardrails adicionales cuando, por ejemplo, se introducen nuevos parámetros de protocolo o se eliminan los existentes.

Enmienda, Adición o Depreciación de Guardrails

Los Guardrails pueden ser modificados ocasionalmente mediante una acción de gobernanza on-chain que cumpla con el umbral de votación aplicable. Toda enmienda a cualquier Guardrail requerirá y se considerará una enmienda a la Constitución misma. Cada Guardrail tiene una etiqueta única. Si se enmienda el texto de un Guardrail, el existente quedará obsoleto y se usará una nueva etiqueta. Del mismo modo, si se deprecia un Guardrail, su etiqueta nunca se reutilizará. En todos los casos, los Guardrails aplicables serán aquellos vigentes en el momento en que se envía la acción de gobernanza.

Terminología y Orientación

(El texto define términos como Blockchain de Cardano, Bloque, Protocolo, Parámetros de Protocolo, Slot, Época (Epoch), lovelace, ada, Delegador, Stake de Producción de Bloques Activo, On-chain, Off-Chain, Acción de Gobernanza, Hard Fork, Guardrails, Script de Guardrails, y los distintos tipos de acciones de gobernanza. También define términos de rendimiento como Benchmarking, Análisis de rendimiento, Simulación, Monitoreo de rendimiento, Reversión de cambios y Niveles de gravedad, y términos de obligación como Esperado (Expected), Debería/No debería (Should/Should not) y Debe/No debe (Must/Must not).)

Verificación Automatizada (“Script de Guardrails”)

Un hash de script se asocia con el hash de la Constitución cuando se promulga una acción de gobernanza de Nueva Constitución o Script de Guardrails. El Script de Guardrails solo afecta dos tipos de acciones de gobernanza: “Actualización de Parámetros” y “Retiros del Tesoro”. Hay símbolos clave:

  • (y) El Script de Guardrails puede usarse para hacer cumplir el Guardrail.

  • (x) No puede usarse para hacer cumplir el Guardrail.

  • (~ - razón) No puede usarse por la razón dada, pero cambios futuros podrían habilitarlo.

Si los Guardrails se superponen, se aplica el más restrictivo. Si un parámetro no se menciona explícitamente, el script no debe permitir ningún cambio. Si se menciona pero no hay guardrails verificables, el script no debe imponer restricciones.

2. Guardrails y Directrices sobre las acciones de “Actualización de Parámetros” (“Parameter Update”)

A continuación, se presentan los Guardrails y directrices para cambiar las configuraciones de los parámetros de protocolo actualizables mediante la acción de “Actualización de Parámetros” de manera que la Blockchain de Cardano nunca se encuentre en un estado irrecuperable como resultado de dichos cambios.

Ten en cuenta que, para evitar ambigüedades, este Apéndice utiliza el nombre del parámetro que se emplea en las acciones de “Actualización de Parámetros” en lugar de cualquier otra convención.

GUARDRAILS

  • PARAM-01 (y) Cualquier parámetro de protocolo que no esté explícitamente nombrado en este documento no debe ser cambiado por una acción de “Actualización de Parámetros”.

  • PARAM-02a (y) Cuando un parámetro de protocolo se enumera explícitamente en este documento pero no se especifican Guardrails verificables, el Script de Guardrails no debe imponer ninguna restricción a los cambios en el parámetro. Los Guardrails verificables se indican con un (y).

2.1. Parámetros Críticos del Protocolo

Los siguientes parámetros de protocolo son críticos desde el punto de vista de la seguridad.

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 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 de script/memoria 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)

GUARDRAILS

  • PARAM-03a (y) Un parámetro que es crítico para la operación de la blockchain requiere el voto de un SPO además del voto de un DRep: Los SPOs deben decir “sí” con un respaldo colectivo de más del 50% de todo el stake de producción de bloques activo. Esto es aplicado por los Guardrails en el umbral de votación del stake pool.

  • PARAM-04a (x) Normalmente deben pasar al menos 90 días entre la publicación de una propuesta off-chain para cambiar un parámetro crítico para la operación de la blockchain y el envío de la correspondiente acción de gobernanza on-chain. Este Guardrail puede flexibilizarse en caso de un problema de red de Gravedad 1 o Gravedad 2 tras una cuidadosa discusión y evaluación técnica.

Parámetros Críticos para el Sistema de Gobernanza

  • depósito en lovelace de clave de delegación (stakeAddressDeposit)

  • depósito en lovelace de registro de pool (stakePoolDeposit)

  • corte fijo mínimo de recompensas para pools (minPoolCost)

  • cantidad de depósito de DRep (dRepDeposit)

  • tamaño mínimo del Comité Constitucional (committeeMinSize)

  • duración máxima del mandato (en épocas) para los miembros del Comité Constitucional (committeeMaxTermLength)

GUARDRAILS

  • PARAM-05a (y) Los DReps deben votar “sí” con un apoyo colectivo de más del 50% de todo el stake de votación activo. Esto es aplicado por los Guardrails en los umbrales de votación de los DReps.

  • PARAM-06a (x) Normalmente deben pasar al menos 90 días entre la publicación de una propuesta off-chain para cambiar un parámetro crítico para el sistema de gobernanza y el envío de la correspondiente acción de gobernanza on-chain. Este Guardrail puede flexibilizarse en caso de un problema de red de Gravedad 1 o Gravedad 2 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:

  1. Permitir la sostenibilidad económica a largo plazo para la Blockchain de Cardano.

  2. Garantizar que los stake pools sean recompensados adecuadamente por mantener la Blockchain de Cardano.

  3. Garantizar que los propietarios de ada sean recompensados adecuadamente por utilizar el stake de manera constructiva, incluso al delegar ada para la producción de bloques.

  4. Equilibrar los incentivos económicos para los diferentes interesados del ecosistema de la Blockchain de Cardano, incluidos, entre otros, los Operadores de Stake Pool, propietarios de ada, usuarios de DeFi, usuarios de infraestructura, desarrolladores (por ejemplo, DApps) e intermediarios financieros (por ejemplo, exchanges).

Desencadenantes de Cambio

  1. Cambios significativos en el valor fiduciario (fiat) de ada que resulten en problemas potenciales de seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo.

  2. Cambios en los volúmenes o tipos de transacciones.

  3. Solicitudes o sugerencias de la Comunidad.

  4. 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. Deben tener en cuenta:

  • Factores económicos externos.

  • Preocupaciones de seguridad de la red.

Métricas Principales

  • Valor fiduciario de ada que resulte en problemas potenciales de seguridad, rendimiento, funcionalidad o sostenibilidad a largo plazo.

  • 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 de transacción fija (txFeeFixed) Define el costo para transacciones básicas en lovelace: fee(tx) = txFeeFixed + txFeePerByte x nBytes(tx)

GUARDRAILS

  • TFPB-01 (y) txFeePerByte no debe ser inferior a 30 (0.000030 ada). Esto protege contra ataques de denegación de servicio (DoS) de bajo costo.

  • TFPB-02 (y) txFeePerByte no debe exceder 1,000 (0.001 ada). Esto garantiza que las transacciones puedan pagarse.

  • 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 DoS de bajo costo.

  • TFF-02 (y) txFeeFixed no debe exceder 10,000,000 (10 ada). Esto garantiza que las transacciones puedan pagarse.

  • TFF-03 (y) txFeeFixed no debe ser negativo.

  • TFGEN-01 (x - “debería”) Para mantener un nivel constante de protección contra ataques de denegación de servicio, txFeeFixed y txFeePerByte deberían ajustarse siempre que se ajusten los precios de Ejecución de Plutus (executionUnitPrices[steps/memory]).

  • TFGEN-02 (x - “no cuantificable”) Cualquier cambio en txFeeFixed o txFeePerByte 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 resulte imposible construir una transacción.

Costo de UTxO por byte (utxoCostPerByte) Define el depósito (en lovelace) que se cobra por cada byte de almacenamiento que se guarda en un UTxO. Este depósito se devuelve cuando el UTxO ya no está activo.

  • Establece un umbral mínimo de ada que se mantiene dentro de un solo UTxO.

  • Proporciona protección contra ataques de denegación de servicio de bajo costo en el almacenamiento de UTxO. 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 para los usuarios del nodo proporcionando un incentivo para devolver UTxOs cuando ya no se necesitan, o para fusionar UTxOs.

GUARDRAILS

  • 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-05a (x - “debería”) Los cambios deberían tener en cuenta:

    1. El costo aceptable del ataque.

    2. El tiempo aceptable para un ataque.

    3. La configuración de memoria aceptable para usuarios de nodos completos.

    4. Los tamaños de los UTxOs.

    5. El uso total de memoria actual del nodo.

Depósito de dirección de stake (stakeAddressDeposit) Asegura que las direcciones de stake se retiren cuando ya no se necesiten.

  • Ayuda a reducir los costos de almacenamiento a largo plazo.

  • Ayuda a limitar los costos de CPU y memoria en el libro mayor. La lógica del depósito es incentivar la devolución de recursos de memoria escasos cuando ya no son requeridos. 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 capturas de pantalla (snapshots) del stake.

GUARDRAILS

  • 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 este ya no los necesite.

  • Ayuda a reducir los costos de almacenamiento a largo plazo. La lógica del depósito es incentivar la devolución de recursos de memoria escasos. Los cálculos de recompensas y de las instantáneas del stake también se ven afectados por la cantidad de stake pools activos.
GUARDRAILS

  • 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 del pool (minPoolCost) Parte del mecanismo de recompensas.

  • El costo mínimo del pool se transfiere a la dirección de recompensas del pool antes de que se pague cualquier recompensa a los delegadores.
GUARDRAILS

  • 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 de operar un pool.

Corte del tesoro (treasuryCut) Parte del mecanismo de recompensas.

  • La porción de corte del tesoro proveniente de la expansión monetaria se transfiere al tesoro antes de pagar cualquier recompensa del pool.

  • Se puede establecer en el rango 0.0-1.0 (0%-100%).

GUARDRAILS

  • 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 al historial de cambios) treasuryCut no debe cambiarse más de una vez en ningún 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 utilizan para recompensas cada época. Gobierna la sostenibilidad a largo plazo de la Blockchain de Cardano.

  • Las reservas se agotan gradualmente hasta que no se suministran más recompensas.

GUARDRAILS

  • 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 más de +/- 10% en ningún período de 73 épocas (aproximadamente 12 meses).

  • ME-05 (x - “debería”) monetaryExpansion no debería cambiarse más de una vez en ningún período de 36 épocas (aproximadamente 6 meses).

Precios de Ejecución de Scripts Plutus (executionUnitPrices[priceSteps/priceMemory]) Definen las tarifas por ejecutar scripts Plutus.

  • Ofrece un retorno económico por la ejecución de scripts Plutus.

  • Proporciona seguridad contra ataques DoS de bajo costo.

GUARDRAILS

  • 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 configurarse para que:

    1. el costo de ejecutar una transacción con los pasos máximos de CPU sea similar al costo de una transacción de tamaño máximo sin scripts y

    2. el costo de ejecutar una transacción con unidades de memoria máximas sea similar al costo de una transacción de tamaño máximo sin scripts.

  • 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 “llenas”, sin importar su tipo. Esto ayuda a garantizar que se cumplan los requisitos en los tiempos de difusión/propagación de bloques.

Tarifa de transacción por byte para un script de referencia (minFeeRefScriptCoinsPerByte) Define el costo en lovelace de usar scripts de referencia Plutus.

GUARDRAILS

  • MFRS-01 (y) minFeeRefScriptCoinsPerByte no debe exceder 1,000 (0.001 ada).

  • 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 DoS o de aumentar la tarifa máxima de transacción.

2.3. Parámetros de Red

Los objetivos generales al gestionar los parámetros de la red de la Blockchain de Cardano son:

  1. Adaptar la capacidad de red disponible de la Capa 1 a las demandas de tráfico actuales o futuras, incluidas las transacciones de pago, las DApps de capa 1, la gestión de cadenas laterales (sidechains) y las necesidades de gobernanza.

  2. Equilibrar las demandas de tráfico para diferentes grupos de usuarios, incluidas transacciones de pago, mineros de Tokens Fungibles/No Fungibles, scripts Plutus, desarrolladores de DeFi, Operadores de Stake Pool y transacciones de votación.

Desencadenantes de Cambio

Los cambios a los parámetros de red pueden ser desencadenados por:

  1. Cambios medidos en las demandas de tráfico durante un período de 2 épocas (10 días).

  2. Cambios anticipados en las demandas de tráfico.

  3. Solicitudes de la Comunidad de Cardano.

Contraindicadores

Los cambios pueden necesitar ser revertidos y/o no deberían promulgarse en caso de:

  • Retrasos excesivos en la propagación de bloques.

  • Stake pools que no pueden manejar el volumen de tráfico.

  • Scripts que no pueden completar su ejecución.

Métricas Principales

Todas las decisiones sobre cambios de parámetros deben informarse mediante:

  • El perfil de retraso en la propagación de bloques.

  • El volumen de tráfico (tamaño de bloque a lo largo del tiempo).

  • El volumen de scripts (tamaño de los scripts y unidades de ejecución).

  • Benchmarks de los costos de ejecución de scripts.

  • Benchmarks de retraso en la propagación/difusión de bloques.

Se requieren resultados detallados de benchmarking para confirmar el efecto de cualquier cambio en el rendimiento o comportamiento de la mainnet antes de su promulgación. Se deben analizar los efectos de diferentes combinaciones de transacciones, incluidas las normales, los scripts Plutus y las acciones de gobernanza.

GUARDRAILS

  • NETWORK-01 (x - “debería”) Ningún parámetro de red individual debería cambiar más de una vez por cada dos épocas.

  • NETWORK-02 (x - “debería”) Solo debería cambiarse un parámetro de red por época a menos que estén directamente correlacionados, por ejemplo, los límites de unidades de memoria por transacción y por bloque.

Cambios a Parámetros de Red Específicos

Tamaño del bloque (maxBlockBodySize) El tamaño máximo de un bloque, en bytes.

GUARDRAILS

  • MBBS-01 (y) maxBlockBodySize no debe exceder 122,880 bytes (120KB).

  • MBBS-02 (y) maxBlockBodySize no debe ser inferior a 24,576 bytes (24KB).

  • MBBS-03a (x - circunstancias excepcionales) maxBlockBodySize no debe disminuirse, salvo en circunstancias excepcionales donde haya problemas potenciales con la seguridad, el rendimiento, la funcionalidad o la sostenibilidad a largo plazo.

  • MBBS-04 (~ - sin acceso a valores de parámetros existentes) maxBlockBodySize debe ser lo suficientemente grande como para incluir al menos una transacción (es decir, maxBlockBodySize debe ser al menos maxTxSize).

  • MBBS-05 (x - “debería”) maxBlockBodySize debería cambiarse como máximo en 10,240 bytes (10KB) por época (5 días), y preferiblemente en 8,192 bytes (8KB) o menos por época.

  • MBBS-06 (x - “debería”) El tamaño del bloque no debería inducir un viaje de ida y vuelta adicional del Protocolo de Control de Transmisión (TCP). Cualquier aumento más allá de esto debe estar respaldado por un análisis de rendimiento, simulación y benchmarking.

  • MBBS-07 (x - “no cuantificable”) El impacto de cualquier cambio en maxBlockBodySize debe ser confirmado mediante benchmarking/simulación detallados y no exceder los requisitos de los presupuestos de tiempo de propagación/difusión de bloques. Cualquier aumento también debe considerar los futuros requerimientos para la ejecución de scripts Plutus frente al objetivo total de difusión de bloques de 3s con un 95% de propagación en 5s.

Tamaño de transacción (maxTxSize) El tamaño máximo de una transacción, en bytes.

GUARDRAILS

  • MTS-01 (y) maxTxSize no debe exceder 32,768 bytes (32KB).

  • MTS-02 (y) maxTxSize no debe ser negativo.

  • MTS-03 (~ - sin acceso a valores de parámetros existentes) maxTxSize no debe disminuirse.

  • MTS-04 (~ - sin acceso a valores de parámetros existentes) maxTxSize no debe exceder maxBlockBodySize.

  • MTS-05 (x - “debería”) maxTxSize no debería incrementarse en más de 2,560 bytes (2.5KB) en cualquier época, y preferiblemente debería incrementarse en 2,048 bytes (2KB) o menos por época.

  • MTS-06 (x - “debería”) maxTxSize no debería superar 1/4 del tamaño del bloque.

Límites de Unidades de Memoria (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory]) El límite en el número máximo de unidades de memoria que pueden utilizar los scripts Plutus, ya sea por transacción o por bloque.

GUARDRAILS

  • MTEU-M-01 (y) maxTxExecutionUnits[memory] no debe exceder los 40,000,000 unidades.

  • MTEU-M-02 (y) maxTxExecutionUnits[memory] no debe ser negativo.

  • MTEU-M-03 (~ - sin acceso a valores de parámetros existentes) maxTxExecutionUnits[memory] no debe disminuirse.

  • MTEU-M-04 (x - “debería”) maxTxExecutionUnits[memory] no debería aumentarse en más de 2,500,000 unidades en ninguna época.

  • MBEU-M-01 (y) maxBlockExecutionUnits[memory] no debe exceder los 120,000,000 unidades.

  • MBEU-M-02 (y) maxBlockExecutionUnits[memory] no debe ser negativo.

  • MBEU-M-03 (x - “debería”) maxBlockExecutionUnits[memory] no debería cambiarse (aumentarse o disminuirse) en más de 10,000,000 unidades en CUALQUIER época.

  • MBEU-M-04a (x - “no cuantificable”) El impacto de cualquier cambio debe ser confirmado mediante benchmarking/simulación y no exceder los requerimientos de propagación. Cualquier aumento debe considerar el límite de difusión de 3s/5s y requerimientos futuros.

  • MEU-M-01 (~ - sin acceso a valores de parámetros existentes) maxBlockExecutionUnits[memory] no debe ser inferior a maxTxExecutionUnits[memory].

Límites de Unidades CPU (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps]) El límite en el número máximo de pasos de CPU que pueden usar los scripts Plutus.

GUARDRAILS

  • MTEU-S-01 (y) maxTxExecutionUnits[steps] no debe exceder 15,000,000,000 (15Bn) unidades.

  • MTEU-S-02 (y) maxTxExecutionUnits[steps] no debe ser negativo.

  • MTEU-S-03 (~ - sin acceso a parámetros existentes) maxTxExecutionUnits[steps] no debe disminuirse.

  • MTEU-S-04 (x - “debería”) maxTxExecutionUnits[steps] no debería aumentarse en más de 500,000,000 (500M) unidades en cualquier época (5 días).

  • MBEU-S-01 (y) maxBlockExecutionUnits[steps] no debe exceder 40,000,000,000 (40Bn) unidades.

  • MBEU-S-02 (y) maxBlockExecutionUnits[steps] no debe ser negativo.

  • MBEU-S-03 (x - “debería”) maxBlockExecutionUnits[steps] no debería cambiarse por más de 2,000,000,000 (2Bn) unidades en cualquier época.

  • MBEU-S-04a (x - “no cuantificable”) El impacto del cambio debe confirmarse por benchmarking para no exceder presupuestos de tiempo de difusión/propagación (3s, 95% en 5s).

  • MEU-S-01 (~ - sin acceso a parámetros existentes) maxBlockExecutionUnits[steps] no debe ser menor a maxTxExecutionUnits[steps].

Tamaño del encabezado de bloque (maxBlockHeaderSize) El tamaño del encabezado del bloque.

GUARDRAILS

  • MBHS-01 (y) maxBlockHeaderSize no debe exceder 5,000 bytes.

  • MBHS-02 (y) maxBlockHeaderSize no debe ser negativo.

  • MBHS-03 (x - el encabezado válido más grande está sujeto a cambio) maxBlockHeaderSize debe ser lo suficientemente grande para el encabezado válido más grande.

  • MBHS-04 (x - “debería”) maxBlockHeaderSize normalmente solo debería incrementarse si el protocolo cambia.

  • MBHS-05 (x - “debería”) maxBlockHeaderSize debería estar dentro de la ventana de congestión inicial de TCP (3 o 10 MTUs).

2.4. Parámetros Técnicos/de Seguridad

Los objetivos generales al gestionar los parámetros técnicos/de seguridad son:

  1. Garantizar la seguridad de la red en términos de descentralización y protección contra acciones adversas.

  2. Permitir cambios en el lenguaje Plutus.

Desencadenantes de Cambio

  1. Cambios en el número de SPOs activos.

  2. Cambios al lenguaje Plutus.

  3. Amenazas de seguridad.

  4. Solicitudes de la Comunidad de Cardano.

Contraindicadores

  • Preocupaciones económicas, por ejemplo, al cambiar el número de stake pools.

Métricas Principales

  • Número de stake pools.

  • Nivel de descentralización.

Cambios a Parámetros Técnicos/de Seguridad Específicos

Número Objetivo de Stake Pools (stakePoolTargetNum) Establece el número objetivo de stake pools.

  • El número esperado cuando la red está en equilibrio.

  • Parámetro de seguridad principalmente, garantizando descentralización.

  • Grandes cambios provocarán eventos masivos de re-delegación.

GUARDRAILS

  • SPTN-01 (y) stakePoolTargetNum no debe ser inferior a 250.

  • SPTN-02 (y) stakePoolTargetNum no debe exceder 2,000.

  • SPTN-03 (y) stakePoolTargetNum no debe ser negativo.

  • SPTN-04 (y) stakePoolTargetNum no debe ser cero.

Factor de Influencia de Promesa (poolPledgeInfluence) Habilita el mecanismo de protección del “pledge” (promesa). Protege contra ataques Sybil.

GUARDRAILS

  • PPI-01 (y) poolPledgeInfluence no debe ser inferior a 0.1.

  • PPI-02 (y) poolPledgeInfluence no debe exceder 1.0.

  • PPI-03 (y) poolPledgeInfluence no debe ser negativo.

  • PPI-04 (x - “debería”) poolPledgeInfluence no debería variar en más de +/- 10% en un período de 18 épocas (aprox. 3 meses).

Ventana de Retiro del Pool (poolRetireMaxEpoch) El número máximo de épocas de anticipación que un pool puede dar al planear su retiro.

GUARDRAILS

  • PRME-01 (y) poolRetireMaxEpoch no debe ser negativo.

  • PRME-02 (x - “debería”) poolRetireMaxEpoch no debería ser menor a 1.

Porcentaje de Colateral (collateralPercentage) Define cuánto colateral debe proporcionarse al ejecutar un script Plutus como porcentaje del costo normal de ejecución.

GUARDRAILS

  • CP-01 (y) collateralPercentage no debe ser inferior a 100.

  • CP-02 (y) collateralPercentage no debe exceder 200.

  • CP-03 (y) collateralPercentage no debe ser negativo.

  • CP-04 (y) collateralPercentage no debe ser cero.

Número máximo de entradas de colateral (maxCollateralInputs) Define el número máximo de entradas (inputs) que pueden usarse para colateral al ejecutar un script Plutus.

GUARDRAILS
  • MCI-01 (y) maxCollateralInputs no debe ser menor a 1.

Tamaño de Valor Máximo (maxValueSize) El límite en el tamaño serializado del Valor (Value) en cada salida (output).

GUARDRAILS

  • MVS-01 (y) maxValueSize no debe exceder 12,288 bytes (12KB).

  • MVS-02 (y) maxValueSize no debe ser negativo.

  • MVS-03 (~ - sin acceso a parámetros existentes) maxValueSize debe ser menor que maxTxSize.

  • MVS-04 (~ - sin acceso a parámetros existentes) maxValueSize no debe reducirse.

  • MVS-05 (x - sujeto a interpretación) maxValueSize debe ser lo bastante grande para permitir salidas sensatas.

Modelos de Costos Plutus (costModels) Definen los costos base para cada primitiva Plutus en CPU y memoria.

GUARDRAILS

  • PCM-01 (x - “no cuantificable”) Los valores deben establecerse mediante benchmarking en una arquitectura de referencia.

  • PCM-02 (x) El modelo de costos debe actualizarse si se introducen nuevas primitivas o versiones de Plutus.

  • PCM-03a (~) Los valores normalmente no deberían ser negativos.

  • PCM-04 (~) Debe suministrarse un modelo de costos para cada versión de Plutus que soporte el protocolo.

2.5. Parámetros de Gobernanza

Los objetivos generales:

  1. Garantizar la estabilidad de la gobernanza.

  2. Mantener una forma representativa de gobernanza.

Desencadenantes de Cambio

  1. Solicitudes de la comunidad.

  2. Requisitos regulatorios.

  3. Resultados de gobernanza inesperados.

  4. Entrar en un estado de falta de confianza.

Contraindicadores

  • Efectos inesperados en la gobernanza.

  • Carga excesiva de Capa 1 por votación o exceso de acciones.

Métricas Principales

  • Niveles de participación.

  • Comportamientos y patrones.

  • Consideraciones regulatorias.

  • Confianza en el sistema.

Cambios a Parámetros de Gobernanza Específicos

Depósito para Acciones de Gobernanza (govDeposit) El depósito cobrado al enviar una acción.

GUARDRAILS

  • GD-01 (y) govDeposit no debe ser negativo.

  • GD-02 (y) govDeposit no debe ser inferior a 1,000,000 (1 ada).

  • GD-03a (y) govDeposit no debe exceder 10,000,000,000,000 (10 millones de ada).

  • GD-04 (x - “debería”) govDeposit debería ajustarse en línea con cambios fiduciarios.

Depósito para DReps (dRepDeposit)

GUARDRAILS

  • DRD-01 (y) dRepDeposit no debe ser negativo.

  • DRD-02 (y) dRepDeposit no debe ser inferior a 1,000,000 (1 ada).

  • DRD-03 (y) dRepDeposit no debe exceder 100,000,000,000 (100,000 ada).

  • DRD-04 (x - “debería”) Debería ajustarse a los cambios fiduciarios.

Período de Actividad DRep (dRepActivity) El período (en épocas) tras el cual un DRep se considera inactivo si no vota.

GUARDRAILS

  • DRA-01 (y) dRepActivity no debe ser inferior a 13 épocas (65 días).

  • DRA-02 (y) dRepActivity no debe exceder 37 épocas (185 días).

  • DRA-03 (y) dRepActivity no debe ser negativo.

  • DRA-04 (~) Debe ser mayor a govActionLifetime.

  • DRA-05 (x - “debería”) Debería calcularse en términos humanos.

Umbrales de Acción de Gobernanza (dRepVotingThresholds[…], poolVotingThresholds[…]) Umbrales sobre el stake de votación activo requerido para ratificar una acción.

GUARDRAILS

  • VT-GEN-01 (y) Todos los umbrales deben ser mayores al 50% y menores o iguales al 100%.

  • VT-GEN-02a (y) Parámetros económicos, de red y de seguridad deben estar entre 51%-75%.

  • VT-GEN-03 (y) Umbrales de gobernanza entre 75%-90%.

  • VT-HF-01 (y) Acciones “Hard Fork Initiation” entre 51%-80%.

  • VT-CON-01 (y) Acciones de “Nueva Constitución” entre 65%-90%.

  • VT-CC-01 (y) Acciones “Update Committee” entre 51%-90%.

  • VT-NC-01 (y) Acciones “No Confidence” entre 51%-75%.

Tiempo de vida de la Acción de Gobernanza (govActionLifetime)

GUARDRAILS

  • GAL-01 (y) govActionLifetime no debe ser inferior a 1 época (5 días).

  • GAL-03 (x - “debería”) No debería ser inferior a 2 épocas (10 días).

  • GAL-02 (y) govActionLifetime no debe exceder 15 épocas (75 días).

  • GAL-04 (x - “debería”) Calibrado en términos humanos.

  • GAL-05 (~) Debe ser menor a dRepActivity.

Mandato Máximo del Comité Constitucional (committeeMaxTermLength)

GUARDRAILS

  • CMTL-01a (y) No debe ser cero.

  • CMTL-02a (y) No debe ser negativo.

  • CMTL-03a (y) No inferior a 18 épocas (90 días).

  • CMTL-04a (y) No exceder 293 épocas (aprox. 4 años).

  • CMTL-05a (x - “debería”) No exceder 220 épocas (aprox. 3 años).

Tamaño Mínimo del Comité Constitucional (committeeMinSize)

GUARDRAILS

  • CMS-01 (y) No debe ser negativo.

  • CMS-02 (y) No inferior a 3.

  • CMS-03 (y) No exceder 10.

2.6. Monitoreo y Reversión de Cambios de Parámetros

Todos los cambios en parámetros de red deben ser monitoreados cuidadosamente por no menos de 2 épocas (10 días).

  • Los cambios deben revertirse lo antes posible si los retrasos de propagación superan 4.5s para más del 5% de los bloques sobre cualquier ventana rodante de 6 horas. Se debe producir un plan específico de recuperación/reversión para cada cambio que incluya qué parámetros cambiar y cómo recuperarse en caso de falla desastrosa.

2.7. Parámetros de Protocolo No Actualizables

Algunos parámetros fundamentales no pueden ser cambiados por la acción de “Actualización de Parámetros”. Solo pueden cambiarse en un nuevo archivo Génesis como parte de un hard fork. No es necesario proporcionar guardrails específicos para estos.

3. Guardrails y Directrices sobre acciones de “Retiros del Tesoro” (“Treasury Withdrawals”)

GUARDRAILS

  • TREASURY-01a (x) Un Límite de Cambio Neto por período debe ser acordado por los DReps mediante una acción on-chain con un umbral superior al 50%.

  • TREASURY-02a (x) Los retiros no deben exceder el Límite de Cambio Neto.

  • TREASURY-03a (x) Los retiros deben denominarse en ada.

4. Guardrails y Directrices sobre acciones de “Iniciación de Hard Fork”

La acción requiere que se especifique tanto una nueva versión de protocolo principal (mayor) como una menor como números enteros positivos.

GUARDRAILS

  • HARDFORK-01 (~) La versión principal debe ser la misma o una mayor que la vigente. Si es una mayor, la menor debe ser cero.

  • HARDFORK-02a (~) A menos que la principal cambie, la versión menor debe ser mayor a la vigente.

  • HARDFORK-03 (~) Al menos una de las versiones (principal o menor o ambas) debe cambiar.

  • HARDFORK-04a (x) Al menos el 85% de los stake pools por stake activo deberían haber actualizado a un nodo capaz de procesar las reglas de la nueva versión.

  • HARDFORK-05 (x) Cualquier parámetro nuevo introducido debe incluirse en este Apéndice con guardrails adecuados.

  • HARDFORK-06 (x) Las configuraciones de nuevos parámetros deben incluirse en el archivo Génesis apropiado.

  • HARDFORK-07 (x) Cualquier parámetro depreciado debe indicarse.

  • HARDFORK-08 (~) Las nuevas versiones Plutus deben estar respaldadas por un modelo de costos específico de la versión.

5. Guardrails y Directrices sobre acciones de “Actualizar Comité”

GUARDRAILS
  • UPDATE-CC-01a (x) Estas acciones no deben ser ratificadas hasta que los propietarios de ada hayan ratificado esta Constitución mediante una acción on-chain.

6. Guardrails y Directrices sobre acciones de “Nueva Constitución”

GUARDRAILS

  • NEW-CONSTITUTION-01a (x) Debe presentarse esta acción para definir los guardrails requeridos para nuevos parámetros introducidos vía Hard Fork.

  • NEW-CONSTITUTION-02 (x) Si se especifica, el nuevo Script de Guardrails debe ser coherente con esta Constitución.

7. Guardrails y Directrices sobre acciones de “Falta de Confianza”

No se imponen guardrails a las acciones de “Falta de Confianza” (No Confidence).

  • Ninguno.

8. Guardrails y Directrices sobre acciones de “Info”

Las acciones de “Info” no se promulgan on-chain. No se imponen guardrails.

  • Ninguno.

9. Lista de Grupos de Parámetros de Protocolo

Los parámetros de protocolo se agrupan por tipo, permitiendo que se establezcan diferentes umbrales para cada grupo.

El grupo de parámetros de red consiste en:

  • tamaño máximo del cuerpo del bloque (maxBlockBodySize)

  • tamaño máximo de 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 de script en una sola transacción (maxTxExecutionUnits[steps])

  • unidades máximas de ejecución de script en un solo bloque (maxBlockExecutionUnits[steps])

  • número máximo de entradas de colateral (maxCollateralInputs)

El grupo de parámetros económicos consiste en:

  • coeficiente de tarifa mínima (txFeePerByte)

  • constante de tarifa mínima (txFeeFixed)

  • tarifa mínima por byte para scripts de referencia (minFeeRefScriptCoinsPerByte)

  • depósito en lovelace de clave de delegación (stakeAddressDeposit)

  • depósito en lovelace de registro de pool (stakePoolDeposit)

  • expansión monetaria (monetaryExpansion)

  • expansión del tesoro (treasuryCut)

  • corte fijo mínimo de recompensas para pools (minPoolCost)

  • depósito mínimo de lovelace por byte de UTxO serializado (coinsPerUTxOByte)

  • precios de unidades de ejecución Plutus (executionUnitPrices[priceSteps/priceMemory])

El grupo de parámetros técnicos/de seguridad consiste en:

  • influencia de promesa del pool (poolPledgeInfluence)

  • época máxima de retiro del pool (poolRetireMaxEpoch)

  • número deseado de pools (stakePoolTargetNum)

  • modelos de costos de ejecución Plutus (costModels)

  • proporción de colateral necesario para scripts (collateralPercentage)

El grupo de parámetros de gobernanza consiste en:

  • umbrales de votación de gobernanza (dRepVotingThresholds[…], poolVotingThresholds[…])

  • tiempo de vida máximo de la acción de gobernanza en épocas (govActionLifetime)

  • depósito de acción de gobernanza (govDeposit)

  • cantidad de depósito de DRep (dRepDeposit)

  • período de actividad de DRep en épocas (dRepActivity)

  • tamaño mínimo del Comité Constitucional (committeeMinSize)

  • duración máxima del mandato (en épocas) para los miembros del Comité Constitucional (committeeMaxTermLength)

APÉNDICE II. ORIENTACIÓN DE APOYO

Este Apéndice II tiene como objetivo proporcionar orientación en la interpretación de la Constitución, y el Comité Constitucional deberá considerar este Apéndice II como lo estime pertinente y útil para llevar a cabo sus deberes constitucionales.

1. Notas de Contextualización (Framing Notes)

La Blockchain de Cardano se estableció en 2017. En julio de 2020 se expandió para incluir validadores de bloques independientes y en septiembre de 2024 se introdujo un sistema de gobernanza on-chain. Esta Constitución describe los derechos y responsabilidades de los actores de gobernanza en el sistema descentralizado que representan a los propietarios de ada; ada es el token de gobernanza de la Blockchain de Cardano. La Blockchain de Cardano es un ecosistema descentralizado de tecnología blockchain, contratos inteligentes y gobernanza comunitaria.

Al abordar esta Constitución, la Comunidad de Cardano reconoce que no se trata de una constitución solo para una blockchain, sino más bien de una constitución para un ecosistema de blockchain. En consecuencia, la forma en que se aprueban las acciones de gobernanza, si bien es extremadamente importante, no es el único enfoque de esta Constitución. Más bien, esta Constitución proporciona la base y el marco fundamental mediante el cual todos los participantes de la Comunidad de Cardano pueden unirse para autogobernarse y formar nuevos enfoques para la interacción y colaboración humanas.

Por necesidad, esta Constitución reconoce el papel y empodera al Comité Constitucional, confirma el derecho de la Comunidad de Cardano a participar en cuerpos colectivos para la colaboración, da efecto a la gobernanza on-chain, y empodera a los DReps -incluidos los propietarios de ada que actúan directamente como DReps- para actuar como la voz de los propietarios de ada en la votación on-chain.

La Constitución también reconoce la necesidad de salvaguardar el acceso y el uso de los fondos del tesoro de la Blockchain de Cardano mediante la inclusión de los Guardrails de la Blockchain de Cardano en esta Constitución.

2. Otra Orientación

Los redactores de la Constitución, junto con otros participantes de la Comunidad de Cardano, han publicado y en el futuro pueden publicar orientación para la interpretación de la Constitución, incluyendo, entre otros, un folleto de definiciones que ha sido publicado de manera contemporánea con la ratificación on-chain de la Constitución. Siempre que dicha orientación publicada haya sido convertida en hash e introducida en la Blockchain de Cardano a través de una acción de “Info”, al Comité Constitucional no se le impedirá considerar y utilizar dicha orientación como lo considere apropiado.

2 Likes