2.3 Parámetros de la Red
Los objetivos generales al gestionar los parámetros de la red Blockchain de Cardano son:
- Ajustar la capacidad disponible de la red de la Blockchain de Cardano Capa 1 a las demandas de tráfico actuales o futuras, incluyendo transacciones de pago, aplicaciones descentralizadas (DApps) de capa 1, gestión de sidechains y necesidades de gobernanza.
- Balancear las demandas de tráfico para diferentes grupos de usuarios, incluyendo transacciones de pago, mineros de Tokens Fungibles/No Fungibles, scripts de Plutus, desarrolladores DeFi, Operadores de Stake Pools y transacciones de votación.
Disparadores para el Cambio
Los cambios en los parámetros de la red pueden ser provocados por:
- Cambios medidos en las demandas de tráfico durante un período de 2 épocas (10 días).
- Cambios anticipados en las demandas de tráfico.
- Solicitudes de la comunidad.
Contraindicaciones
Los cambios pueden necesitar ser revertidos y/o no deberían implementarse en caso de:
-
Retrasos excesivos en la propagación de bloques.
-
Los pools de staking no pueden manejar el volumen de tráfico.
-
Los scripts no pueden completar la ejecución.
Métricas Clave
Todas las decisiones sobre cambios de parámetros deben ser informadas por:
-
Perfil de retraso en la propagación de bloques.
-
Volumen de tráfico (tamaño de bloque a lo largo del tiempo).
-
Volumen de scripts (tamaño de scripts y unidades de ejecución).
-
Puntos de referencia de costo de ejecución de scripts.
-
Puntos de referencia de retraso/difusión de propagación de bloques.
Se requieren resultados detallados de pruebas de referencia para confirmar el efecto de cualquier cambio en el rendimiento o comportamiento de la red principal antes de la implementación. Deben analizarse los efectos de diferentes combinaciones de transacciones, incluidos transacciones normales, scripts de Plutus y acciones de gobernanza.
Guardarrailes
NETWORK-01 (x - “debería”) Ningún parámetro individual de la red debería cambiar más de una vez cada dos épocas.
NETWORK-02 (x - “debería”) Solo debería cambiarse un parámetro de la red por época, a menos que estén directamente correlacionados, por ejemplo, límites de unidades de memoria por transacción y por bloque.
Cambios a Parámetros Específicos de la Red
Tamaño de Bloque (maxBlockBodySize)
El tamaño máximo de un bloque, en Bytes.
Guardarrailes
MBBS-01 (y) maxBlockBodySize no debe exceder 122,880 Bytes (120KB).
MBBS-02 (y maxBlockBodySize no debe ser menor de 24,576 Bytes (24KB).
MBBS-03 (x - “circunstancias excepcionales”) maxBlockBodySize no debe disminuirse, salvo en circunstancias excepcionales donde haya posibles problemas con la seguridad, el rendimiento o la funcionalidad.
MBBS-04 (~ - sin acceso a los 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 en un máximo de 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 adicional de ida y vuelta del Protocolo de Control de Transmisión (TCP). Cualquier aumento más allá de esto debe estar respaldado por análisis de rendimiento, simulación y pruebas de referencia.
MBBS-07 (x - “incontable”) El impacto de cualquier cambio en el maxBlockBodySize debe ser confirmado mediante un detallado benchmarking/simulación y no debe exceder los requisitos de los presupuestos de tiempo de difusión/propagación de bloques, como se describe a continuación. Cualquier aumento en el maxBlockBodySize también debe considerar los futuros requisitos para la ejecución de scripts Plutus (maxBlockExecutionUnits[steps]) en contra del objetivo total de difusión de bloques de 3 segundos con una propagación del 95% de los bloques dentro de 5 segundos. El límite del tamaño máximo de bloque puede incrementarse en el futuro si esto está respaldado por los resultados de evaluación comparativa y monitoreo.
Tamaño de la Transacción (maxTxSize)
El tamaño máximo de una transacción, en Bytes.
Guardarrailes
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 reducirse
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 aumentarse en 2,048 Bytes (2KB) o menos por época
MTS-06 (x - “debería”) maxTxSize no debería exceder 1/4 del tamaño del bloque
Límites de Unidades de Memoria (maxBlockExecutionUnits[memory], maxTxExecutionUnits[memory])
El límite del número máximo de unidades de memoria que pueden ser utilizadas por los scripts Plutus, ya sea por transacción o por bloque.
Guardarrailes
MTEU-M-01 (y) maxTxExecutionUnits[memory] no debe exceder 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 reducirse
MTEU-M-04 (x - “debería”) maxTxExecutionUnits[memory] no debería incrementarse en más de 2,500,000 unidades en cualquier época
MBEU-M-01 (y) maxBlockExecutionUnits[memory] no debe exceder 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 reducirse) en más de 10,000,000 unidades en cualquier época
MBEU-M-04 (x - incontable) El impacto de cualquier cambio en maxBlockExecutionUnits[memory] debe ser confirmado mediante una detallada evaluación comparativa/simulación y no debe exceder los requisitos de los presupuestos de tiempo de difusión/propagación, también impactados por maxBlockExecutionUnits[steps]. Cualquier aumento también debe considerar los requisitos futuros previamente acordados para el tamaño total del bloque (maxBlockBodySize) medidos en contra del objetivo total de difusión de bloques de 3 segundos con una propagación del 95% de los bloques dentro de 5 segundos. Las futuras mejoras en el rendimiento de Plutus pueden permitir que el límite por bloque se aumente, pero deben equilibrarse contra los límites generales de difusión especificados en la frase anterior y los requisitos futuros.
MEU-M-01 (~ - sin acceso a valores de parámetros existentes) maxBlockExecutionUnits[memory] no debe ser menor que maxTxExecutionUnits[memory]
Límites de Unidades de CPU (maxBlockExecutionUnits[steps], maxTxExecutionUnits[steps])
El límite del número máximo de pasos de CPU que pueden ser utilizados por los scripts Plutus, ya sea por transacción o por bloque.
Guardarrailes
MTEU-S-01 (y) maxTxExecutionUnits[steps] no debe exceder 15,000,000,000 (15MM) unidades
MTEU-S-02 (y) maxTxExecutionUnits[steps] no debe ser negativo
MTEU-S-03 (~ - sin acceso a valores de parámetros existentes) maxTxExecutionUnits[steps] no debe reducirse
MTEU-S-04 (x - “debería”) maxTxExecutionUnits[steps] no debería incrementarse 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 (40MM) unidades
MBEU-S-02 (y) maxBlockExecutionUnits[steps] no debe ser negativo
MBEU-S-03 (x - “debería”) maxBlockExecutionUnits[steps] no debería cambiarse (aumentarse o reducirse) en más de 2,000,000,000 (2MM) unidades en cualquier época (5 días)
MBEU-S-04 (x - incontable) El impacto del cambio en maxBlockExecutionUnits[steps] debe ser confirmado mediante una detallada evaluación comparativa/simulación y no debe exceder los requisitos de los presupuestos de tiempo de difusión/propagación de bloques, también impactados por maxBlockExecutionUnits[memory]. Cualquier aumento también debe considerar los requisitos futuros previamente identificados para el tamaño total del bloque (maxBlockBodySize) medidos en contra del objetivo total de difusión de bloques de 3 segundos con una propagación del 95% de los bloques dentro de 5 segundos. Las futuras mejoras en el rendimiento de Plutus pueden permitir que el límite por bloque se aumente, pero deben equilibrarse contra los límites generales de difusión especificados en la frase anterior y los requisitos futuros.
MEU-S-01 (~ - sin acceso a valores de parámetros existentes) maxBlockExecutionUnits[steps] no debe ser menor que maxTxExecutionUnits[steps]
Tamaño del Encabezado del Bloque (maxBlockHeaderSize)
El tamaño del encabezado del bloque.
Tenga en cuenta que aumentar el tamaño del encabezado del bloque puede afectar el tamaño total del bloque (maxBlockBodySize).
Guardarrailes
MBHS-01 (y) maxBlockHeaderSize no debe exceder 5,000 Bytes
MBHS-02 (y) maxBlockHeaderSize no debe ser negativo
MBHS-03 (x - “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 solo debería aumentarse normalmente si cambian los protocolos
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:
- Asegurar la seguridad de la red Cardano en términos de descentralización, protección contra ataques Sybil y del 51%, y protección contra ataques de denegación de servicio
- Permitir cambios en el lenguaje Plutus
Disparadores para el Cambio
- Cambios en el número de SPOs activos
- Cambios en el lenguaje Plutus
- Amenazas de seguridad
- Solicitudes de la comunidad
Contraindicadores
- Preocupaciones económicas, p. ej. al cambiar el número de pools de participación
Métricas Principales
- Número de pools de participación
- 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 de pools cuando la red está en el estado de equilibrio
- Principalmente un parámetro de seguridad, asegurando la descentralización mediante la división/replicación de pools
- Tiene un efecto económico así como un efecto de seguridad - también se requiere asesoramiento económico al cambiar este parámetro
- Los cambios grandes en este parámetro desencadenarán eventos masivos de redelegación
Guardarrailes
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 del Pledge (poolPledgeInfluence)
Habilita el mecanismo de protección del pledge
Proporciona protección contra ataques Sybil
- Valores más altos recompensan a los pools que tienen más pledge y penalizan a los pools que tienen menos pledge
Tiene un efecto económico así como un efecto técnico - también se requiere asesoramiento económico
- Puede establecerse en el rango de 0.0-infinito
Guardarrailes
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 cualquier período de 18 épocas (aproximadamente 3 meses)
Ventana de Retiro del Pool (poolRetireMaxEpoch)
Define el número máximo de épocas de aviso que un pool puede dar cuando planea retirarse
Guardarrailes
PRME-01 (y) poolRetireMaxEpoch no debe ser negativo
PRME-02 (x - “debería”) poolRetireMaxEpoch no debería ser inferior 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
- El colateral es adicional a los pagos de tarifas
- Si un script falla en ejecutarse, entonces el colateral se pierde
- El colateral nunca se pierde si un script se ejecuta con éxito
Proporciona seguridad contra ataques de bajo costo al hacerlos más caros en lugar de menos caros para ejecutar scripts fallidos
Guardarrailes
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 que pueden usarse como colateral al ejecutar un script Plutus
Guardarrailes
MCI-01 (y) maxCollateralInputs no debe ser inferior a 1
Tamaño Máximo del Valor (maxValueSize)
El límite en el tamaño serializado del Valor en cada salida.
Guardarrailes
MVS-01 (y) maxValueSize no debe exceder 12,288 Bytes (12KB)
MVS-02 (y) maxValueSize no debe ser negativo
MVS-03 (~ - sin acceso a valores de parámetros existentes) maxValueSize debe ser menor que maxTxSize
MVS-04 (~ - sin acceso a valores de parámetros existentes) maxValueSize no debe reducirse
MVS-05 (x - “salida sensata” está sujeto a interpretación) maxValueSize debe ser lo suficientemente grande para permitir salidas sensatas (p. ej. cualquier salida en cadena existente o salidas anticipadas que podrían ser producidas por nuevas reglas del libro mayor)
Modelos de Costo de Plutus (costModels)
Definen los costos base para cada primitiva de Plutus en términos de unidades de CPU y memoria
- Hay alrededor de 150 micro-parámetros distintos en total
Los modelos de costo se definen para cada versión del lenguaje Plutus. Una nueva versión del lenguaje puede introducir micro-parámetros adicionales o eliminar micro-parámetros existentes.
Guardarrailes
PCM-01 (x - incontable) Los valores del modelo de costo deben ser establecidos mediante evaluación comparativa en una arquitectura de referencia
PCM-02 (x - las primitivas y versiones del lenguaje no se introducen en las transacciones) El modelo de costo debe actualizarse si se introducen nuevas primitivas o se agrega una nueva versión del lenguaje Plutus
PCM-03 (~ - sin acceso a parámetros del modelo de costo de Plutus) Los valores del modelo de costo no deben ser negativos
PCM-04 (~ - sin acceso a parámetros del modelo de costo de Plutus) Se debe suministrar un modelo de costo para cada versión del lenguaje Plutus que el protocolo soporte
2.5 Parámetros de Gobernanza
Los objetivos generales al gestionar los parámetros de gobernanza son:
- Asegurar la estabilidad de la gobernanza
- Mantener una forma representativa de gobernanza como se describe en el CIP-1694
Disparadores para el Cambio
Los cambios en los parámetros de gobernanza pueden ser desencadenados por:
- Solicitudes de la comunidad
- Requisitos regulatorios
- Resultados inesperados o no deseados de la gobernanza
- Entrar en un estado de falta de confianza
Contra-indicadores
Los cambios pueden necesitar ser revertidos y/o no deberían ser promulgados en caso de:
- Efectos inesperados en la gobernanza
- Carga excesiva en la Capa 1 debido a votaciones en cadena o un número excesivo de acciones de gobernanza
Métricas Principales
Todas las decisiones sobre cambios de parámetros deben estar informadas por:
- Niveles de participación en la gobernanza
- Comportamientos y patrones de gobernanza
- Consideraciones regulatorias
- Confianza en el sistema de gobernanza
- La efectividad del sistema de gobernanza en manejar cambios necesarios
Cambios en Parámetros Específicos de Gobernanza
Depósito para Acciones de Gobernanza (govDeposit)
El depósito que se cobra al presentar una acción de gobernanza.
- Ayuda a limitar el número de acciones que se presentan
Guardarrailes
GD-01 (y) govDeposit no debe ser negativo
GD-02 (y) govDeposit no debe ser menor de 1,000,000 (1 ada)
GD-03 (y) govDeposit no debe exceder 10,000,000,000,000 (10 Millones ada)
GD-04 (x - “debería”) govDeposit debería ajustarse conforme a cambios en moneda fiduciaria
Depósito para DReps (dRepDeposit)
El depósito que se cobra al registrar un DRep.
- Ayuda a limitar el número de DReps activos
Guardarrailes
DRD-01 (y) dRepDeposit no debe ser negativo
DRD-02 (y) dRepDeposit no debe ser menor de 1,000,000 (1 ada)
DRD-03 (y) dRepDeposit no debe exceder 100,000,000,000 (100,000 ada)
DRD-04 (x - “debería”) dRepDeposit debería ajustarse conforme a cambios en moneda fiduciaria
Período de Actividad de DRep (dRepActivity)
El período (en número entero de épocas) después del cual un DRep se considera inactivo para fines de cálculo de votos, si no vota en ninguna propuesta.
Guardarraiels
DRA-01 (y) dRepActivity no debe ser menor de 13 épocas (2 meses)
DRA-02 (y) dRepActivity no debe exceder 37 épocas (6 meses)
DRA-03 (y) dRepActivity no debe ser negativo
DRA-04 (~ - sin acceso a valores de parámetros existentes) dRepActivity debe ser mayor que govActionLifetime
DRA-05 (x - “debería”) dRepActivity debería calcularse en términos humanos (2 meses, etc.)
Umbral de Acciones de Gobernanza de DRep y SPO (dRepVotingThresholds […], poolVotingThresholds […])
Umbrales sobre la participación de voto activa requerida para ratificar un tipo específico de acción de gobernanza por DReps o SPOs.
- Asegura la legitimidad de la acción
Los parámetros de umbral se enumeran a continuación:
dRepVotingThresholds:
- dvtCommitteeNoConfidence
- dvtCommitteeNormal
- dvtHardForkInitiation
- dvtMotionNoConfidence
- dvtPPEconomicGroup
- dvtPPGovGroup
- dvtPPNetworkGroup
- dvtPPTechnicalGroup
- dvtTreasuryWithdrawal
- dvtUpdateToConstitution
poolVotingThresholds:
- pvtCommitteeNoConfidence
- pvtCommitteeNormal
- pvtHardForkInitiation
- pvtMotionNoConfidence
- pvtPPSecurityGroup
Guardarrailes
VT-GEN-01 (y) Todos los umbrales deben estar en el rango del 50% al 100%
VT-GEN-02 (y) Los umbrales de parámetros económicos, de red y técnicos deben estar en el rango del 51% al 75%
VT-GEN-03 (y) Los umbrales de parámetros de gobernanza deben estar en el rango del 75% al 90%
VT-HF-01 (y) Los umbrales de acción de bifurcación dura deben estar en el rango del 51% al 80%
VT-CON-01 (y) Los umbrales de acción de actualización de Constitución o política de propuesta deben estar en el rango del 65% al 90%
VT-CC-01 (y) Los umbrales de acción del Comité Constitucional deben estar en el rango del 65% al 90%
VT-NC-01 (y) Los umbrales de acción de no confianza deben estar en el rango del 51% al 75%
Vida Útil de Acción de Gobernanza (govActionLifetime)
El período después del cual una acción de gobernanza expirará si no se promulga.
- Como número entero de épocas
Guardarrailes
GAL-01 (y) govActionLifetime no debe ser menor de 1 época (5 días)
GAL-03 (x - “debería”) govActionLifetime no debería ser menor de 2 épocas (10 días)
GAL-02 (y) govActionLifetime no debe exceder 15 épocas (75 días)
GAL-04 (x - “debería”) govActionLifetime debería calibrarse en términos humanos (por ejemplo, 30 días, dos semanas), para permitir suficiente tiempo para que se lleve a cabo la votación, etc.
GAL-05 (~ - sin acceso a valores de parámetros existentes) govActionLifetime debe ser menor que dRepActivity
Término Máximo del Comité Constitucional (committeeMaxTermLimit)
El límite en el término máximo que un miembro del comité puede servir.
Guardarrailes
CMTL-01 (y) committeeMaxTermLimit no debe ser cero
CMTL-02 (y) committeeMaxTermLimit no debe ser negativo
CMTL-03 (y) committeeMaxTermLimit no debe ser menor de 18 épocas (90 días, aproximadamente 3 meses)
CMTL-04 (y) committeeMaxTermLimit no debe exceder 293 épocas (aproximadamente 4 años)
CMTL-05 (x - “debería”) committeeMaxTermLimit no debería exceder 220 épocas (aproximadamente 3 años)
Tamaño Mínimo del Comité Constitucional (committeeMinSize)
El número mínimo de miembros que pueden incluirse en un Comité Constitucional después de una acción de gobernanza para cambiar el Comité Constitucional.
Guardarrailes
CMS-01 (y) committeeMinSize no debe ser negativo
CMS-02 (y) committeeMinSize no debe ser menor de 3
CMS-03 (y) committeeMinSize no debe exceder 10
2.6 Monitoreo y Reversión de Cambios de Parámetros
Todos los cambios de parámetros de red deben monitorearse cuidadosamente durante al menos 2 épocas (10 días)
- Los cambios deben revertirse tan pronto como sea posible si los retrasos en la propagación de bloques exceden los 4.5 segundos durante más del 5% de los bloques en cualquier ventana de 6 horas
Todos los demás cambios de parámetros deben monitorearse
- El plan de reversión debería implementarse si el efecto general sobre el rendimiento, la seguridad o la funcionalidad no es aceptable.
Se debe producir un plan específico de reversión/recuperación para cada cambio de parámetro. Este plan debe incluir:
- Qué parámetros necesitan cambiar y de qué manera para volver al estado anterior (o un estado similar)
- Cómo recuperar la red en caso de fallo catastrófico
Este plan debería seguirse si se observan problemas después del cambio de parámetro. Tenga en cuenta que no todos los cambios pueden revertirse. Se debe tener precaución adicional al realizar cambios en estos parámetros.
2.7 Parámetros de Protocolo no Actualizables
Algunos parámetros fundamentales del protocolo no pueden cambiarse mediante la acción de actualización de parámetros del protocolo. Estos parámetros solo pueden cambiarse en un nuevo archivo Genesis como parte de un hard fork. No es necesario proporcionar barreras de protección específicas para actualizar estos parámetros.
3 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE RETIRO DEL TESORO
Las acciones de retiro del tesoro especifican el destino y la cantidad de varios retiros del tesoro de Cardano.
Guardarrailes
TREASURY-01 (x) Los DReps deben definir un límite de cambio neto para el saldo del Tesoro de Cardano por período de tiempo.
TREASURY-02 (x) El presupuesto del Tesoro de Cardano no debe exceder el límite de cambio neto para el saldo del Tesoro de Cardano por período de tiempo.
TREASURY-03 (x) El presupuesto del Tesoro de Cardano debe estar denominado en ada.
TREASURY-04 (x) Los retiros del tesoro no deben ser ratificados hasta que haya un presupuesto de Cardano aprobado por la comunidad en efecto conforme a una acción de gobernanza anterior en cadena acordada por los DReps con un umbral mayor al 50% del total de votos activos.
4 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE INICIACIÓN DE BIFURCACIÓN DURA
La acción de iniciación de bifurcación dura requiere que se especifiquen tanto una nueva versión mayor como una nueva versión menor del protocolo.
Guardarrailes
HARDFORK-01 (~ - no hay acceso a los valores de parámetros existentes) La versión mayor del protocolo debe ser igual o mayor que la versión mayor que se promulgará inmediatamente antes de este cambio. Si la versión mayor del protocolo es una unidad mayor, entonces la versión menor del protocolo debe ser cero.
HARDFORK-02 (~ - no hay acceso a los valores de parámetros existentes) La versión menor del protocolo debe ser no menor a la versión menor que se promulgará inmediatamente antes de este cambio.
HARDFORK-03 (~ - no hay acceso a los valores de parámetros existentes) Al menos una de las versiones del protocolo (mayor o menor o ambas) debe cambiar.
HARDFORK-04 (x) Al menos el 85% de los pools de participación por participación activa deberían haber actualizado a una versión del nodo Cardano capaz de procesar las reglas asociadas con la nueva versión del protocolo.
HARDFORK-05 (x) Cualquier nuevo parámetro de protocolo actualizable que se introduzca con una bifurcación dura debe incluirse en este Apéndice y definirse los guardarrailes adecuados para esos parámetros.
HARDFORK-06 (x) Los ajustes para cualquier nuevo parámetro de protocolo que se introduzca con una bifurcación dura deben incluirse en el archivo Genesis correspondiente.
HARDFORK-07 (x) Cualquier parámetro de protocolo obsoleto debe indicarse en este Apéndice.
HARDFORK-08 (~ - sin acceso a parámetros del modelo de costo Plutus) Las nuevas versiones de Plutus deben ser compatibles con un modelo de costo Plutus específico de la versión que cubra cada primitiva disponible en la nueva versión de Plutus.
5 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE ACTUALIZACIÓN DEL COMITÉ CONSTITUCIONAL O DE UMBRAL
Las acciones de gobernanza de actualización del Comité Constitucional o de umbral pueden cambiar el tamaño, la composición o los umbrales de votación requeridos para el Comité Constitucional.
Guardarrailes
UPDATE-CC-01 (x) Las acciones de actualización del Comité Constitucional y/o umbral y/o término de gobernanza no deben ser ratificadas hasta que los poseedores de Ada hayan ratificado mediante una acción de gobernanza en cadena la Constitución Final.
6 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE ACTUALIZACIÓN DE LA CONSTITUCIÓN O POLÍTICAS DE PROPUESTA
La actualización de la constitución o las acciones de política de propuesta cambian el hash de la constitución en cadena y el script asociado de política de propuesta de gobernanza.
Guardarrailes
UPDATE-CONSTITUTION-01 (x) Una acción de actualización de la Constitución y/o política de propuesta de gobernanza debe presentarse para definir cualquier guardarrail necesario para los nuevos parámetros que se introduzcan mediante una acción de fork duro de gobernanza.
7 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE NO CONFIANZA
Las acciones de no confianza señalan un estado de falta de confianza en el sistema de gobernanza. No se imponen guardarrailes sobre las acciones de No Confianza.
Guardarrailes
- Ninguno
8 GUARDARRAILES Y DIRECTRICES SOBRE ACCIONES DE INFORMACIÓN
Las acciones de información no se promulgan en cadena. No se imponen guardarrailes sobre las acciones de Información.
Guardarrailes
- Ninguno
9 GUARDARRAILES DURANTE EL PERÍODO INTERINO
Período Interino
El Período Interino comienza con la Bifurcación Dura Chang y termina después de que se promulgue en cadena una Constitución Final ratificada por la comunidad. A lo largo del Período Interino, los desencadenadores técnicos y constitucionales activarán progresivamente las características del CIP-1694.
Implementación Técnica del Período Interino:
-
La Bifurcación Dura Chang habilitará tres acciones iniciales de gobernanza del CIP-1694 y permitirá establecer el marco representativo. Estas acciones son las acciones de “Información”, “Iniciación de Bifurcación Dura” y “Cambios en parámetros del protocolo”. Los poseedores de Ada podrán registrarse como DReps y delegar inmediatamente después de la bifurcación dura, pero, como se describe en el CIP-1694, la votación de DRep no estará disponible, excepto en acciones de “Información”. Los SPOs podrán votar según lo describe el CIP-1694. Las acciones de “Iniciación de Bifurcación Dura” y “Cambios en parámetros del protocolo” también serán ratificadas por el Comité Constitucional. Los poseedores de Ada podrán retirar sus recompensas de participación como de costumbre.
-
Una bifurcación dura posterior, ratificado por el Comité Constitucional y los SPOs, poco después de la Bifurcación Dura Chang, habilitará las cuatro acciones restantes de gobernanza del CIP-1694: “retiros del tesoro”, “moción de no confianza”, “actualización del comité constitucional y/o umbral y/o términos” y “actualización de la constitución o política de propuesta”. En este punto, se habilitará la votación de DReps y las recompensas de staking solo podrán retirarse si el poseedor de Ada ha delegado su voto (incluyendo las opciones de voto predefinidas de Abstenerse/No Confianza).
Guardarrailes
INTERIM-01 (x) Para proporcionar suficiente tiempo para que los DReps se registren y hagan campaña, y para que los poseedores de Ada elijan sus delegaciones de voto iniciales, deben transcurrir al menos 18 épocas (90 días, aproximadamente 3 meses) después de la Bifurcación Dura Chang antes de que se pueda ratificar la bifurcación dura posterior. Una vez que se promulgue la bifurcación dura posterior, la votación de DRep puede ocurrir según se describe en el CIP-1694.
INTERIM-02 (x) Los retiros del tesoro no deben ser ratificados hasta que haya un presupuesto del Ecosistema de la Blockchain de Cardano aprobado por la comunidad en efecto conforme a una acción de gobernanza anterior en cadena.
INTERIM-03 (x) Los retiros del tesoro deben ser coherentes con los presupuestos del Ecosistema de la Blockchain de Cardano aprobados por la comunidad.
INTERIM-04 (x) Los poseedores de Ada deben haber ratificado la Constitución Final especificada en el Apéndice II antes de ratificar cualquier otra propuesta de “actualización de la constitución”, “actualización del comité constitucional y/o umbral y/o términos” y “moción de no confianza” de gobernanza.
INTERIM-05 (x) Las acciones de “actualización de la política de propuesta” que sean consistentes con la Constitución Interina pueden ratificarse durante el período interino, siempre que la Constitución Interina en sí no se cambie.
10 LISTA DE GRUPOS DE PARÁMETROS DE PROTOCOLO
Los parámetros de protocolo están agrupados por tipo, lo que permite establecer diferentes umbrales para cada grupo.
El grupo de red incluye:
-
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 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 garantía (maxCollateralInputs)
El grupo económico incluye:
-
coeficiente mínimo de tarifa por byte (txFeePerByte)
-
constante mínima de tarifa (txFeeFixed)
-
tarifa mínima por byte para scripts de referencia (minFeeRefScriptCoinsPerByte)
-
depósito de Lovelace para clave de delegación (stakeAddressDeposit)
-
depósito de Lovelace para registro de pool (stakePoolDeposit)
-
expansión monetaria (monetaryExpansion)
-
expansión del tesoro (treasuryCut)
-
corte mínimo de recompensas fijas para pools (minPoolCost)
-
depósito mínimo de Lovelace por byte de UTxO serializado (coinsPerUTxOByte)
-
precios de unidades de ejecución de Plutus (executionUnitPrices[priceSteps/priceMemory])
El grupo técnico incluye:
-
influencia de la garantía del pool (poolPledgeInfluence)
-
época máxima de retiro del pool (poolRetireMaxEpoch)
-
número deseado de pools (stakePoolTargetNum)
-
modelos de costo de ejecución de Plutus (costModels)
-
proporción de garantía necesaria para scripts (collateralPercentage)
El grupo de gobernanza incluye todos los nuevos parámetros de protocolo que se introducen en el CIP-1694:
-
umbrales de votación de gobernanza (dRepVotingThresholds[…], poolVotingThresholds[…])
-
vida máxima de la acción de gobernanza en épocas (govActionLifetime)
-
depósito de acción de gobernanza (govActionDeposit)
-
cantidad de depósito de DRep (dRepDeposit)
-
período de actividad de DRep en épocas (dRepActivity)
-
tamaño mínimo del comité constitucional (committeeMinSize)
-
longitud máxima del término (en épocas) para los miembros del comité constitucional (committeeMaxTermLimit)
APÉNDICE II: RATIFICACIÓN DE LA CONSTITUCIÓN FINAL
Sección 1
Una serie de talleres globales para los poseedores de Ada para discutir y debatir los Artículos de una constitución final comenzarán durante la segunda mitad de 2024. Los talleres se distribuirán geográficamente para captar el amplio sentimiento en la comunidad de Cardano. Los talleres elegirán hasta un total de cien delegados, comprendiendo hasta cincuenta delegados votantes y hasta cincuenta delegados alternativos no votantes, que participarán en una Convención Constitucional. Cada delegado votante que participe en la Convención Constitucional tendrá un voto igual.
Sección 2
La Convención Constitucional se celebrará a más tardar a fines de 2024.
Sección 3
La Constitución Final será aprobada en la Convención Constitucional, donde los delegados electos para asistir a la Convención Constitucional acordarán la Constitución Final con las enmiendas que consideren apropiadas y necesarias. La Constitución Final aprobada en la Convención Constitucional se presentará como una acción de gobernanza según el CIP-1694 a más tardar el 31 de enero de 2025.