Zycord: una red entre pares de transiciones de estado autocertificadas

Zycord: una red entre pares de transiciones de estado autocertificadas.
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Este artículo es completo y autocontenido. Sustituye a la v1.0 [0]; §15 expone la relación. El lanzamiento, la emisión, las eras y la tabla completa de parámetros están en el documento complementario, Zycord: lanzamiento, eras y parámetros.

Versiones. El texto que sigue es la v2.0 del artículo, íntegra, seguida en esta página por su documento complementario, también v2.0. Ambos se sirven como PDF, cada uno con una firma separada hecha con la clave del proyecto E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29: el artículo (firma) y el complemento (firma). Todas las versiones están archivadas en doi:10.5281/zenodo.22167489, que resuelve a la más reciente; la v1.0 sustituida es doi:10.5281/zenodo.22167490. El complemento está archivado bajo su propio doi:10.5281/zenodo.23383987.

1. Introducción#

Un nodo de una cadena de bloques hace tres trabajos que no tienen nada en común: disemina datos, verifica cómputo y muta estado. Los datos escalan con el ancho de banda. La verificación escala con los núcleos, y es vergonzosamente paralela si las transacciones pueden comprobarse de forma independiente. La mutación de estado es el único recurso genuinamente secuencial: en algún lugar debe existir un único historial autoritativo de escrituras.

Zycord separa los tres. Una transacción pasa a ser un certificado que lleva consigo sus propias entradas y salidas, de modo que verificarlo es una función pura de sus bytes y nunca toca el libro mayor. El trabajo de la cadena se reduce a ordenar certificados y ejecutar sobre ellos un fold determinista: un bucle de comparaciones y sumas que toca el estado exactamente una vez por certificado. Los conflictos no invalidan bloques; hacen que se omitan certificados individuales, y cada omisión se cobra a una parte que aceptó el riesgo. La concurrencia no se descubre en tiempo de ejecución; la declara, slot a slot, el autor del contrato. El linaje es execute-order-validate [3], el ordenamiento determinista [4], la ejecución paralela optimista [5] y la separación entre la diseminación y el ordenamiento [6].

La validez se ejecuta una vez por certificado, en paralelo, antes de que exista ningún bloque. El fold se ejecuta una vez por bloque, en orden, y nunca ejecuta.

El diseño descansa sobre dos universos que pueden compartir un ejecutable pero que nunca deben confundirse:

Las reglas de consenso solo verifican. Su propósito es que ningún usuario pierda fondos sin autorizarlo, que nadie debite un saldo que no controla y que ningún atacante pueda vaciar, bloquear o ralentizar la red. Cómo opera un secuenciador, cómo se comunican los secuenciadores entre sí y cuánto cobran quedan fuera del consenso. Lo que está en cadena es la liquidación: el pago a un secuenciador viaja dentro del intent que firmó el usuario, y solo se paga si el certificado se aplica.

Las secciones siguientes definen el certificado (§2), el fold (§3), el acceso a estado tipado (§4), los activos nativos (§5), la máquina virtual (§6), los secuenciadores (§7), el camino forzado (§8), los dos mercados de comisiones (§9), la red (§10), el proof of stake (§11), la ruta más allá de la verificación completa (§12), los riesgos aceptados (§13), la conformidad (§14) y la relación con la v1.0 (§15).

2. Certificados de transición de estado#

El certificado es el único tipo de transacción. Se codifica en SSZ, lo que da una única codificación canónica en bytes; la decodificación impone la forma canónica, de modo que un certificado decodificado es estructuralmente válido por construcción y ninguna regla posterior vuelve a comprobar su forma.

Dos resúmenes responden a dos preguntas. El id del certificado es el hash del certificado con una lista de firmas vacía: nombra lo que el certificado autoriza. El hash del ejemplar cubre la codificación completa, firmas incluidas: nombra un conjunto concreto de bytes. Las firmas quedan fuera del id porque la firma es aleatorizada; cada nonce produce otra firma válida sobre el mismo cuerpo, y un id que las cubriera daría a una sola autorización una cantidad no acotada de identidades facturables. El id indexa el conjunto de vistos, el orden del fold y toda la deduplicación. Un fill y un certificado forzado toman como id el hash de su intent (§7, §8); la puja de un fill queda sellada por la firma de su secuenciador. El hash del ejemplar es aquello con lo que se compromete la raíz de certificados de un bloque, de modo que un id de bloque determina los bytes que el bloque lleva. La puja de comisión está dentro del id y va firmada: una puja fuera del id es una puja que cualquiera en tránsito podría reescribir. Toda firma firma un mensaje que vincula el id de cadena y la raíz de consenso del conjunto de parámetros, de modo que un certificado no puede repetirse en otra red.

La validez es sin estado. Un certificado es válido cuando, a partir solo de sus bytes:

1. se decodifica canónicamente, nombra esta cadena y toda lista está dentro de su límite;
2. toda firma verifica bajo Ed25519 estricto (codificaciones canónicas, claves libres de torsión), y el conjunto de firmas es mínimo además de suficiente;
3. reejecutar el programa contra las lecturas declaradas produce exactamente las escrituras declaradas;
4. toda escritura que necesita autorización la tiene, y la celda de depósito lleva una firma de forma incondicional;
5. el depósito es una celda de saldo nativo de una dirección de usuario y cubre el peor caso del certificado;
6. el certificado es autoconsistente: ninguna escritura contradice una lectura del mismo slot, ninguna dirección de un solo uso debitada escapa a quedar marcada como gastada, y no se escribe ningún valor en una dirección gastada;
7. no escribe ninguna celda de protocolo;
8. toda dirección que nombra lleva un byte de versión definido;
9. en un contrato cuya clave de secuenciador no es cero, el camino de lectura exacta lleva la firma de esa clave (§7), salvo en un certificado forzado (§8);
10. una escritura de metadatos declara una lectura exacta de cada celda que sobrescribe, al valor que la celda tenía cuando se construyó el certificado.

Cualquier máquina comprueba esto: un pool de hilos, otro ordenador, una GPU, sin base de datos y sin sincronización. Las comprobaciones de firma son independientes entre sí, de modo que pueden agruparse por lotes entre certificados. Esta es la propiedad sobre la que se construye todo lo demás.

La validez no basta para la ejecución. Dos certificados válidos pueden declarar el mismo valor de entrada para el mismo slot; a lo sumo uno puede surtir efecto. Por eso la noción clásica de validez de una transacción se divide en dos: válido (sin estado, paralelo, comprobable por cualquiera) y aplicable (con estado, secuencial, decidido solo por la posición en el libro mayor). Un certificado inválido nunca entra en una mempool honesta, y uno incluido en un bloque hace inválido el bloque.

3. El libro mayor como un fold#

Un bloque es una cabecera, una lista ordenada de hashes de ejemplares de certificados y los propios cuerpos de los certificados. Los cuerpos son datos de la cadena: un bloque solo es válido si sus cuerpos están disponibles. El productor de un bloque no ejecuta nada. Ordena certificados cuya validación ya ha visto, resuelve el proof of work [13] (o, bajo proof of stake, firma el slot para el que fue sorteado, §11) y lleva el conjunto de ids de certificados vistos dentro de la ventana de TTL, porque incluir uno dos veces hace inválido el bloque.

El estado de la cadena es un fold sobre los certificados ordenados. Para cada certificado, en orden, el fold reserva el depósito, comprueba cada lectura declarada contra el estado actual, prepara las escrituras con aritmética comprobada y luego consolida u omite:

• APPLIED — toda lectura declarada se sostiene, así que las escrituras aterrizan y la comisión se liquida al coste real.
• SKIPPED — una lectura ya no se sostiene (STALE), un delta saldría del rango [0, 2²⁵⁶) (OVERFLOW), o una escritura cae bajo una dirección gastada (SPENT). No se escribe nada. Se quema una comisión de omisión fija con cargo al depósito y el resto se devuelve.
• FORCED_FAILED — un certificado forzado (§8) cuya llamada revirtió o rebasó sus cotas. Se debita y se quema a sus pagadores, el cambio vuelve al usuario, no se escribe nada más y el id se marca como visto.
• DROPPED — no se pudo cobrar el certificado en absoluto (la celda de depósito carece de fondos o está gastada), de modo que se lleva, se marca como visto y no se cobra. No le paga nada a su productor y le cuesta espacio del techo. Un fill en la misma situación invalida en cambio el bloque (más abajo), porque descartarlo consumiría el intent del usuario sin que se pagara a nadie.

Orden canónico. El fold ordena los certificados de un bloque en tres clases y no deja al productor ninguna discrecionalidad. Primero los fills (§7), cada uno tomado en cuanto está listo todo pipeline en el que figura, con los empates resueltos por (sequencer key, contract, seq, id). Después todos los demás certificados por (deposit address, Seq, id). Por último los certificados forzados (§8), por id. Todo nodo deriva un estado idéntico a partir de una secuencia idéntica de bloques.

Las escrituras se comprueban antes de que aterrice ninguna de ellas. Un abono a una dirección cuya autoridad ha sido quemada falla de forma ruidosa en lugar de resucitar la celda; un delta que se desbordaría hace fallar el certificado entero. El registro permanente de direcciones gastadas existe exactamente para esto.

La omisión es semántica, no fallo. La inclusión y la aplicación son eventos distintos. Un productor nunca puede producir un bloque inválido por incluir un certificado que resultó obsoleto; el certificado se omite y paga el depositante. El depositante eligió las lecturas, así que el depositante responde por ellas.

Una firma, a lo sumo un cobro. Tanto los certificados aplicados como los omitidos se marcan como vistos. Incluir un certificado visto o caducado, o uno que puja por debajo de la comisión base del bloque en cualquiera de los dos mercados, hace inválido el bloque, de modo que ningún productor puede volver a incluir ni retrasar deliberadamente los certificados de otros para cosechar sus depósitos. Los TTL están acotados por consenso, de modo que el conjunto de vistos sigue siendo podable.

Las condiciones sin nadie a quien cobrar invalidan el bloque. Algunos fallos no tienen culpable: un fill cuyo contador de secuenciador está fuera de orden, cuyo contador fence (§7) se ha movido, cuyo pagador ya está gastado o cuyo depósito no puede reservarse; un certificado forzado cuyas lecturas no se sostienen. Incluir un certificado así hace inválido el bloque y no se cobra nada. El productor, que construyó el bloque a partir del estado que mantiene, es la parte que podía haberlo sabido.

Exactamente un toque de estado por certificado. El fold realiza comparaciones, sumas y escrituras sobre un conjunto de trabajo clave-valor caliente: sin ejecución de código, sin verificación de firmas, sin reejecución, sin aritmética de curva elíptica. Todo eso ocurrió en paralelo durante la comprobación de validez. El id del certificado también se calcula ahí y se lleva al fold.

Igualdad de valores, no versiones. La aplicabilidad compara los valores de lectura declarados, no contadores de versión. Un slot que cambió y volvió a cambiar a su valor anterior sigue siendo aplicable, de modo que el sistema omite estrictamente menos a menudo que el control de concurrencia basado en versiones.

El prólogo y el epílogo propios del fold. Antes de los certificados, en un límite de época, el fold escribe las celdas de la baliza (§4). Después de ellos, reparte el subsidio del bloque y rota el anillo de madurez del coinbase (documento complementario), registra el gas aplicado para el controlador de comisiones (§9) y, en un límite de época, calcula la raíz de estado de la época, que debe ser igual a la de la cabecera. Solo devuelve un error ante la invalidez del bloque; un problema con un certificado es un resultado, nunca un error.

4. Celdas y acceso a estado tipado#

Una celda es el valor en un slot (address, word): un entero sin signo de 256 bits, big-endian en 32 bytes. Las celdas ausentes se leen como cero. Junto a las celdas, el protocolo mantiene un registro de direcciones gastadas, un conjunto permanente de direcciones de un solo uso cuya autoridad de firma ha sido quemada.

Una dirección es version ‖ blake3(tag ‖ version ‖ payload)[:31], excepto la dirección de protocolo, que es el byte de versión 0x00 seguido de ceros:

De un solo uso frente a persistente es una política del monedero expuesta como un bit de la dirección, no dos libros mayores [7]. Los monederos usan por defecto una dirección de un solo uso nueva por cada pago entrante, de modo que pagar a una dirección recién derivada es el camino rápido sin contención, y una celda gastada es compactable una vez que el bloque que la gastó queda enterrado más allá del horizonte de deshacer. Quien quiera una cuenta usa la versión persistente. Las recompensas de minería corresponden a una dirección persistente: el consenso acepta cualquiera de los dos tipos como dirección de pago, pero una dirección de un solo uso quema todas las recompensas que contiene en el momento en que se gasta, y el nodo la rechaza por ese motivo.

El acceso tipado es de donde viene el paralelismo. Un fold que solo admitiera lecturas exactas serializaría todo contrato popular: mil certificados tocando un mismo fondo darían una aplicación y 999 omisiones. En su lugar, una lectura declara cómo restringe una celda y una escritura declara qué hace con ella:

Solo EXACT queda obsoleto. Cualquier número de débitos y abonos con guarda sobre un mismo slot conmutan: se aplican en cualquier orden, y solo se produce una omisión cuando una guarda falla de verdad (un descubierto real), no cuando el saldo simplemente cambió. Una disciplina por slot y por certificado: un set y un delta no coexisten en el mismo slot. La regla que mantiene sólido el modelo es que los valores con guarda nunca fluyen hacia el cómputo: una aserción no devuelve nada y un delta no lee nada, de modo que la reejecución sigue siendo una función pura de las lecturas exactas declaradas. Esta única disciplina cubre transferencias, acuñaciones con suministro limitado, autorizaciones de gasto, propinas y participaciones de bóvedas, que son la inmensa mayoría de las escrituras en cadena. El linaje son las transacciones escrow, el transactional boosting y los CRDT [8][9][10]; Zycord hace de la conmutatividad el contrato de concurrencia entre nodos.

Celdas de un solo uso. Una dirección que nunca ha aparecido en cadena está en el estado ∅; una primera escritura la mueve a almacenada; el certificado que la marca como gastada, firmado por su clave, la mueve a gastada, de forma permanente. La entrada del registro que anota el gasto nunca se compacta: es lo que impide que la dirección resucite.

El cero es ausencia. Un slot nunca escrito y un slot escrito a cero son el mismo slot: escribir cero borra la celda. Esto es un requisito de consenso. Permite que una guarda o una lectura exacta nombre 0 sin preguntar si el slot existe, y mantiene la raíz de estado como función del estado y no del historial que lo produjo.

La baliza de época. Los programas no deben leer valores ambientales directamente. El protocolo escribe la altura de la cabecera que abrió la época actual, y a partir de la era de la máquina también su tiempo, en celdas reservadas, una vez por época, y los programas las leen como cualquier otro slot. Esto da conciencia del tiempo sin obsolescencia por bloque; ambos valores son constantes durante toda la época, un día en mainnet: 2.880 bloques bajo proof of work, 17.280 bajo proof of stake (§11).

5. Activos sin máquina#

La era de lanzamiento necesita una economía antes de necesitar un ordenador. Zycord ofrece activos nativos como operaciones de certificado desde el bloque 0, sin intervención de ninguna máquina virtual:

• TRANSFER — hasta 32 movimientos de (asset, from, to, amount) en un certificado, dentro de sus límites de lecturas y escrituras, cada uno una guarda balance ≥ Δ emparejada con dos deltas. Un abono dirigido a un delta puro o a una celda de un solo uso nueva es la propina, de modo que dar propina no necesita un opcode propio. A una dirección de contrato solo se le puede abonar la moneda nativa, y nunca a la dirección de un precompilado (§6), de la que nada podría sacar el valor.
• ISSUE — crea un id de activo con un límite de suministro en una celda de escritura única.
• MINT — con guarda: minted + Δ ≤ cap.
• RETIRE — quema hasta 64 direcciones de un solo uso, cada una autorizada por su propietario y dentro de los límites del certificado, sin mover valor: sin lecturas, una escritura pura que marca cada celda como gastada. El gasto propiamente dicho es automático dentro de una transferencia. La retirada es la primitiva de compactación y de privacidad: el beneficiario borra una dirección de un solo uso una vez que ha cumplido su función.

Un streamer que recibe diez mil propinas en un bloque le cuesta al fold diez mil sumas conmutativas: cero conflictos, cero omisiones, sin secuenciador, sin máquina. El calendario de suministro de la moneda nativa y el límite de todo activo emitido viven aquí, impuestos por la aritmética comprobada de §3.

Un pago se liquida así. El monedero del remitente elige una celda de un solo uso que posee, declara una guarda sobre ella, la debita, la marca como gastada, abona la dirección de un solo uso nueva del destinatario y envía el cambio a una dirección de un solo uso nueva propia. Dos certificados que compiten por gastar la misma celda de un solo uso a través de dos nodos distintos son ambos válidos; se aplica exactamente uno, y el otro se omite y se cobra al depósito que nombró.

6. La máquina: cEVM#

Zycord ejecuta una sola máquina virtual, la cEVM, un dialecto de la máquina virtual de Ethereum [2] adaptado a los certificados. La elección es deliberada: el presupuesto de novedad del proyecto se gasta en el modelo de estado, de concurrencia y económico, y la máquina debe ser lo más familiar del sistema. Solidity, sus compiladores, auditores y herramientas se trasladan sin cambios. Toda la divergencia del dialecto es una lista de eliminaciones, dos reasignaciones, seis adiciones y cuatro cambios de precio.

El almacenamiento se declara, no se descubre. Un certificado lleva las lecturas que consumió su ejecución y las escrituras que produjo, y la validez las compara con una reejecución. Cuatro familias de opcodes llegan a una celda: SLOAD y SSTORE en la disciplina exacta, y las familias de aserción y de delta en la conmutativa. Un marco llamado puede añadir como máximo 16 entradas al conjunto declarado, de modo que un llamado no puede agotar los límites que necesita quien lo llama; la entrada que lo excedería aborta ese marco y ningún otro.

Añadidos, en bytes que ningún fork de la EVM ha asignado nunca: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. El predicado y el signo están en el opcode, nunca en la pila. Una guarda no devuelve nada, de modo que ninguna rama puede depender de si se cumple; el neto de un delta se toma sobre los enteros y nunca módulo 2²⁵⁶. SETSEQ(key) establece la celda de secuenciador del contrato cuyo contexto se está ejecutando y de ningún otro; una clave cero o malformada es un fallo de derivación que invalida el certificado entero.

Reasignados: NUMBER y TIMESTAMP responden a partir de lecturas exactas de las celdas de la baliza de época, de modo que ambos son constantes durante toda la época, y un contrato portado que usa block.timestamp para un plazo está decidiendo contra un tiempo con hasta 24 horas de retraso.

Eliminados (13): BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM no tienen referente; GASPRICE y BASEFEE nombran celdas por bloque cuya lectura exacta es obsoleta por construcción; BALANCE y SELFBALANCE forzarían una lectura exacta de un saldo nativo; ORIGIN no tiene remitente que nombrar; SELFDESTRUCT permitiría que una celda de hash de código volviera a cero.

Con nuevo precio: SLOAD y SSTORE tienen un coste fijo igual al de acceso caliente; el recargo por acceso frío se elimina en todas partes; KECCAK256 sube a 720 de gas más 144 por palabra, medido contra la implementación propia de esta máquina, el único cambio de precio que eleva un cargo. Los opcodes de aserción y de delta cuestan la misma cantidad de acceso caliente que SLOAD.

Los precompilados son un conjunto cerrado de cinco: sha256, identity, modexp, ed25519_verify y blake3.

Dos contadores. El gas secuencial se deriva de los recuentos declarados de lecturas, escrituras y registro, y la máquina nunca lo mide. El contador paralelo es lo que cuenta el intérprete, contra un presupuesto que el certificado declara en unidades de derivación; excederlo a profundidad 0 invalida el certificado.

El código viaja en el certificado. El código de un contrato vive en una celda de hash de código de escritura única, de modo que no hay redespliegue, y un despliegue es una llamada con destino cero. La imagen de ejecución se lleva en el certificado y se resuelve mediante una lectura exacta declarada de la celda de hash de código, nunca solo por la dirección. Un blob tiene como máximo 24.576 bytes.

El registro de un contrato son cinco celdas: el hash del código, el desplegador, la clave de secuenciador, el administrador y el contador fence (§7). La celda de administrador contiene una dirección; cero significa que el desplegador es el administrador, y 32 bytes de 0xff significan que se ha renunciado al rol, de forma irreversible. El administrador establece la clave de secuenciador mediante un certificado de registro y transfiere el rol o renuncia a él mediante un certificado de cambio de administrador; ambos declaran lecturas exactas de las celdas de desplegador y de administrador, de modo que un certificado de un administrador sustituido o que ha renunciado se omite. El código de un contrato nunca establece un administrador; mueve su propio secuenciador con SETSEQ, que es también como obtiene uno un contrato creado por una factoría.

La biblioteca estándar. Un token, un bote de propinas y un escrow, escritos con los deltas como base, están predesplegados en direcciones conocidas en el bloque que activa la máquina, junto con el envoltorio de deltas al que llaman. Un contrato de Ethereum portado que evite los opcodes y los precompilados eliminados funciona correctamente desde el primer día en modo todo exacto, serializado por un secuenciador si está caliente; el paralelismo es opcional por slot, normalmente un pequeño diff que pasa un mapa de saldos de load/store a assert/delta.

7. Secuenciadores#

Los deltas con guarda disuelven la contención de los pagos. Lo que queda es la lógica de lectura exacta sobre estado caliente, un libro de órdenes, un creador de mercado automatizado, donde dos usuarios honestos construyendo contra la misma celda seguirán produciendo una omisión, y donde los contratos que leen estado para decidir qué escribir no pueden aplicarse en un orden arbitrario. La respuesta del protocolo es dejar que el contrato elija su serializador.

Vinculación. El registro de todo contrato (§6) contiene una clave de secuenciador. Un contrato cuya clave no es cero está secuenciado: un certificado solo puede leer de forma exacta, poner una guarda de igualdad o hacer un set sobre una de sus celdas con la firma de esa clave. Un contrato cuya clave es cero está abierto: cualquiera puede tomar su camino exacto con un certificado propio, y el contrato solo está protegido por su código. La clave la establece en el despliegue el desplegador, más tarde el administrador, o el propio código del contrato mediante SETSEQ, que es como una gobernanza sustituye a un secuenciador sin administrador. La vinculación puede nombrar cualquier clave; una clave que nadie sirve no es un error de consenso, simplemente el contrato queda inutilizable hasta que alguien la sirva o el camino forzado (§8) la cambie. Los deltas con guarda conmutan y nunca se restringen, de modo que un token secuenciado sigue aceptando cualquier transferencia de cualquiera.

El directorio. Un secuenciador anuncia dónde responde su servicio con un certificado de directorio: su clave y una cadena de 1 a 256 bytes de ASCII imprimible, normalmente una URL, anunciada desde una dirección persistente. La entrada caduca 90 días después del TTL del certificado que la anunció salvo que se renueve, y un certificado de retirada la elimina de inmediato. El consenso almacena la cadena y nunca la interpreta. El directorio es descubrimiento, no autorización: los monederos lo leen para saber a quién preguntar.

Intents. Un usuario no construye un certificado contra un contrato secuenciado. El usuario firma un intent: el destino y los calldata, un presupuesto paralelo, un nonce, una ventana de NotBefore a TTL con TTL − NotBefore como máximo de 8 bloques, la dirección persistente del secuenciador, un conjunto de cotas sobre el resultado, el pago debido al secuenciador, los pagos debidos a los cosecuenciadores, si los hay, pagadores de un solo uso que lo financian todo y salidas de cambio. Una cota es un predicado sobre una celda que escribe la llamada, final-at-least, final-at-most, delta-at-least o delta-at-most, y al menos una cota debe nombrar un slot que la llamada escribió. El intent es toda la autorización del usuario; el secuenciador no puede cambiar lo que hace, solo cuándo.

Fills. El secuenciador ejecuta el intent sobre su propia vista del estado, la punta de la cadena más todos los fills que ya ha construido, y publica el resultado como un fill: un certificado cuyo programa es el intent, cuyo depósito sale del saldo persistente propio del secuenciador y cuyo id es el hash del intent, de modo que dos fills de un mismo intent comparten id y solo uno puede cobrarse. Del secuenciador solo se confía su vivacidad, nunca la seguridad: si miente sobre las entradas, el fill simplemente se omite frente al fold canónico, y la mentira cuesta el depósito del secuenciador, no los fondos del usuario.

Recibos. Un secuenciador responde a un intent firmado en milisegundos, mucho antes de que exista un bloque: ejecuta el intent, firma el fill y devuelve al monedero el fill, o un recibo firmado que nombra el id del intent, el seq del pipeline y el resultado. Esto es una preconfirmación. Es la promesa del secuenciador y no la de la cadena; pasa a ser definitiva cuando el fill se aplica. Como todo recibo va firmado, la mala conducta es evidencia: dos recibos de una misma clave que dan un mismo seq a intents distintos, o a un mismo intent resultados distintos, son una prueba que cualquiera puede comprobar a partir de los bytes. El consenso no lo castiga. Lo castiga el mercado. El formato del recibo, el precio, la identidad y la reputación están fuera de cadena y son libres por diseño, de modo que los usuarios eligen entre un secuenciador más barato, uno identificado públicamente o uno anónimo, y abandonan al que sorprenden en doble firma.

Pipelines. La cadena mantiene, para cada par (sequencer key, contract), el último seq aplicado. Un fill declara un seq para cada pipeline en el que figura y solo puede entrar cuando el contador está en seq − 1; los contadores solo avanzan cuando el fill se aplica. Un fill omitido deja por tanto su contador donde estaba: los fills construidos detrás de él no pueden entrar, y el secuenciador reconstruye a partir del mismo número. Dos fills con un mismo seq: entra el primero en el orden del fold, el segundo no puede. El pipeline de un secuenciador se consolida en el orden en que lo firmó, sea cual sea el orden en que lo recibió un productor, y un productor que mezcla los pipelines de varios secuenciadores no tiene elección sobre el resultado.

El contador fence. Todo contrato mantiene un contador, fid, en su registro. Un fill declara el fid de cada contrato que lee de forma exacta o sobre el que hace un set; una discrepancia significa que el fill no puede entrar. El contador avanza en uno cuando un certificado forzado (§8) que se aplica hace un set sobre una celda del contrato, y cuando se escribe la celda de secuenciador del contrato. Una lectura o un delta no lo hace avanzar: una lectura no cambia nada, y un delta conmuta con cualquier guarda o delta que aplique un fill. Un fill que lee de forma exacta una celda que otros mueven por delta responde de esa lectura como cualquier certificado, y su secuenciador paga la omisión si la celda se movió. Así es como el camino forzado y un cambio de secuenciador invalidan todo fill construido sobre el estado que eludieron, sin cobrar a nadie: el secuenciador ve moverse el fence, reconstruye y vuelve a publicar, perdiendo solo latencia.

Cosecuenciación. Una llamada que cruza contratos vinculados a secuenciadores distintos llega a la cadena como un único fill que lleva la firma de cada secuenciador cuyo camino exacto toca, dentro del límite de 16 firmas del certificado, cada uno contado contra el techo de firmas del bloque y en el gas paralelo, cada uno con un seq en su propio pipeline, cada uno cobrando lo que el intent le asigna. La coordinación, quién lidera, cómo se hacen las reservas, cuánto cobra cada uno, está fuera de cadena y es libre por diseño; la cadena ve un único certificado, atómico por construcción. Un fill conjunto que nunca se publica bloquea solo los pipelines en los que figura; una vez pasada su ventana, cada firmante reutiliza el número que firmó.

Quién paga una omisión. Cuando un fill entra y una lectura está obsoleta o una escritura se desborda, no se escribe nada, no se paga a nadie, y quien se equivocó paga la comisión de omisión: decide la primera lectura o escritura que falló en el orden del certificado, y la factura va al secuenciador que se declaró para ese contrato si el contrato está en el camino exacto del fill y el registro de la cadena coincide; en cualquier otro caso va al líder, el secuenciador cuyo depósito nombra el fill. Cada secuenciador listado tiene una reserva tomada en la posición del fill exactamente para esto. El usuario nunca paga una omisión. El pago del usuario a cada secuenciador solo se liquida cuando el fill se aplica.

Qué es un secuenciador. Un servidor corriente operado por el equipo de la aplicación, con la maquinaria que prefiera: un único proceso, un rollup, una federación. Ve primero el flujo de órdenes de su aplicación y es, por tanto, el lugar natural del valor extraíble de esa aplicación; el diseño lo hace explícito y permite que la aplicación capture ese valor en lugar de dejarlo escapar hacia los productores de bloques, mientras el camino forzado acota el poder que esto implica. Los contratos pesados se vuelven viables, la criptografía, toda la lógica de un juego, un sistema entero en un contrato, porque la ejecución pesada ocurre fuera de cadena en la construcción y la cadena la verifica en paralelo. La construcción es un mercado competitivo: un secuenciador más barato o más fiable atrae usuarios, y cada nodo que ofrece construcción añade capacidad.

8. El camino forzado: la inclusión es aplicación#

Un contrato cuya única puerta es su secuenciador es una cárcel si el secuenciador censura, cobra de más o desaparece. Todo usuario dispone por ello de un camino lento que no necesita el permiso de nadie.

El usuario firma un intent abierto: un intent exactamente como en §7, sin secuenciador nombrado y sin cosecuenciadores, financiado por los pagadores de un solo uso propios del usuario, y lo retransmite a la red. Viaja en la mempool como intent, no como certificado. El productor del bloque, que mantiene el estado completo y ya ha liquidado todos los certificados ordinarios del bloque, calcula el estado de final de bloque y ejecuta los intents abiertos que elige contra ese estado, en orden de id de intent, y añade los certificados forzados resultantes como los últimos certificados del bloque. El id de un certificado forzado es el hash de su intent, como lo es el de un fill. La inclusión es aplicación: no hay cola, arrendamiento, cuota ni plazo. Un certificado forzado cuyas lecturas declaradas no se sostienen contra el estado en el que se colocó no puede entrar en el bloque en absoluto; lo construyó el productor, así que el productor es la parte que podía haberlo sabido.

Acotado por construcción. Un bloque lleva como máximo 16 certificados forzados, y cada uno declara como máximo 4.000 unidades de derivación de presupuesto paralelo (200.000 de gas de máquina). Toda salida que ofrece un contrato, retirada de fondos, cancelación, retirada, transferencia, debe caber en ese presupuesto; la regla para los autores de contratos es que una retirada de fondos cabe en el presupuesto forzado. A plena ocupación, el camino forzado toma un tercio del techo paralelo de génesis y el tráfico ordinario conserva el resto.

Una llamada que falla igualmente aterriza. Un certificado forzado cuya llamada revierte, rebasa sus cotas o se queda sin gas entra en su forma fallida, FORCED_FAILED: se debita y se quema a sus pagadores, el cambio vuelve al usuario, el id se marca como visto y no se escribe nada más. La validez acepta la forma fallida solo cuando reejecutar la llamada contra las lecturas declaradas efectivamente falla. Esto es lo que hace el camino resistente al abuso: un atacante que retransmite intents abiertos que no pueden tener éxito paga por cada uno, y un usuario cuyo intent es correcto no puede quedar desatendido por su culpa, porque al productor se le paga por lo que incluye y prefiere el excedente.

El fence. Un certificado forzado que se aplica y hace un set sobre una celda de un contrato hace avanzar el contador fence de ese contrato (§7), de modo que ningún fill construido sobre el estado que cambió puede entrar. Un certificado forzado que solo lee un contrato secuenciado, de forma exacta o mediante guardas, o que solo mueve deltas en él, deja el fence intacto, y lo mismo hace uno que aterriza en su forma fallida; los fills pendientes siguen entrando, y solo se omite uno que leyó de forma exacta una celda que el certificado forzado movió (§7). El secuenciador pierde latencia, nada más, y un usuario que fuerza una transacción por bloque sobre un contrato caliente paga cada vez el precio forzado.

Pago. El pago del intent cubre las comisiones del certificado a las comisiones base del bloque; la parte de comisión base se quema y el resto se suma a las propinas del productor. El productor recibe lo que recibiría un secuenciador.

Ningún estado queda huérfano. Un contrato cuyo secuenciador ha desaparecido sigue vivo a través de sus métodos de delta, que no necesitan secuenciador, y a través del camino forzado, por el que sus usuarios retiran fondos y por el que su propio código, o el administrador, puede llamar a SETSEQ o a un registro y vincularlo a un nuevo secuenciador. La censura se invierte: le cuesta al censor, en comisiones perdidas y en usuarios que lo rodean, y no le cuesta nada a la red. Ningún operador es portante para la seguridad.

9. Dos mercados: gas secuencial y gas paralelo#

Una cadena consume tres recursos de clases de escalabilidad distintas, datos, verificación y mutación, y ponerles precio en un único mercado significa que una comprobación de firma compite en subasta con una escritura de almacenamiento. Zycord divide la comisión en dos mercados independientes, cada uno con su propio objetivo, techo y comisión base mantenidos en el estado de consenso:

El gas secuencial pone precio a la mutación de estado, el recurso escaso, el único bucle que todo nodo ejecuta en orden. El gas paralelo pone precio a la verificación, que crece con cada núcleo y cada GPU que se suma a la red, y su techo se fija alto y barato. La consecuencia es un objetivo de diseño enunciado como invariante: la criptografía pesada no impacta en la red, por construcción económica. Un certificado que verifica una prueba grande pero escribe dos slots paga casi todo en el mercado barato.

Ambos mercados tienen la forma de EIP-1559 [12], cada uno en su propia unidad: la comisión base se quema y la comisión de prioridad paga al productor, en los certificados que se aplican, y solo en esos. La comisión de un certificado omitido se quema por completo y no paga a nadie. Esta es la regla portante del modelo económico. Si una omisión diera propina, la parte que elige el contenido de un bloque cobraría por orquestar los fallos de otros. Quemar lo invierte: una omisión consume espacio del techo y no rinde nada, de modo que un productor que maximiza sus ingresos está maximizando la aplicación y se opone activamente a causar omisiones.

Solo el gas aplicado mueve las comisiones base. Por bloque se cuentan tres cantidades: el gas incluido (todo certificado, sea cual sea su resultado) acota los techos; el gas aplicado (solo lo que se aplicó) mueve las comisiones base; los bytes del bloque acotan el techo de bytes. Una omisión es un intento fallido de usar la cadena, no evidencia de demanda de ella; si el gas incluido moviera la comisión, un saboteador podría llenar bloques con certificados que entran en conflicto entre sí a la comisión de omisión fija y expulsar a todos por precio a coste constante.

El techo secuencial es elástico. El objetivo secuencial T es estado de consenso desde el bloque 0, no una constante, y lo mueve un controlador por época:

• Dentro de un bloque, el techo blando es 2T y el límite duro es 4T. Un productor que hace una ráfaga entre ambos pierde una parte cuadrática de sus propios ingresos, parte del subsidio más las comisiones del bloque, y nunca la parte de nadie más.
• Entre épocas, T sigue a la demanda: el doble de la mediana inferior del gas aplicado en la época, acotado entre T − T/1024 y T + T/512, con un mínimo en el valor de génesis y un máximo en la capacidad de génesis (documento complementario). El crecimiento se retiene cuando la compuerta de salud indica que la red no está sana: cabeceras competidoras citadas en más del 2% de los bloques de la época.
• El número de certificados, el número de firmas y el límite de bytes escalan con T desde sus valores de génesis, hasta capacidades estáticas (2²⁵ certificados, 8 MB).

Los certificados omitidos queman sus comisiones y no registran nada, de modo que la única manera de elevar el techo es ganar aplicación: un uso sostenido, sin conflictos y que quema comisión base. Forzar el crecimiento le cuesta a un atacante exactamente lo que la adopción orgánica le cuesta a todos los demás. El mercado paralelo no necesita nada de este cuidado: su objetivo y su techo están fijados en un múltiplo constante, 3×, del objetivo y el techo secuenciales, es decir 3T y 6T, y heredan su crecimiento. El linaje es la mediana de penalización de Monero [15] y el trabajo sobre límites adaptativos [16].

El margen de construcción. El mismo mercado paralelo paga a los secuenciadores por el trabajo de dar forma: un secuenciador que agrega muchas transacciones en un certificado paga una única puja paralela por él y cobra a sus usuarios por transacción, dentro del intent.

10. Red#

Los cuerpos son datos de la cadena. Los cuerpos de los certificados de un bloque deben poder recuperarse para que el bloque sea válido, de modo que el estado siempre es reconstruible solo a partir de la cadena y ningún operador, secuenciador incluido, es nunca custodio de datos. Los certificados son mayores que las transacciones clásicas porque llevan sus lecturas y escrituras; las mitigaciones son estructurales: los fills cortocircuitan las escrituras internas, las celdas de un solo uso gastadas se compactan una vez enterradas más allá del horizonte de deshacer, y un nodo puede podar los cuerpos por debajo de un mínimo que anuncia a sus pares.

Transporte. TCP, luego TLS 1.3 con identidades de par Ed25519 en certificados autofirmados: el canal queda vinculado a una clave, y no se afirma nada más. Todo mensaje es una trama de 5 bytes, longitud y tipo, y la longitud se comprueba contra el techo propio del tipo antes de cualquier asignación. Un tipo añadido por una compilación más reciente se lee y se descarta bajo un límite pequeño en lugar de cerrar la conexión.

La retransmisión es por hash primero. Los certificados se difunden por gossip de forma independiente y se comprueba su validez, sin estado y en paralelo, al llegar. Un nodo de retransmisión no necesita estado para acotar el coste de filtrar spam: la validez sin estado es comprobable a partir de los bytes, y un nodo que mantiene estado también rechaza un certificado cuyo depósito no puede cubrirlo. La retransmisión trata ejemplares, no ids: un certificado cuyas firmas fallan le cuesta a ese ejemplar, y no se anota nada contra el id, porque un ejemplar posterior de la misma autorización puede ser bueno. Los bloques se retransmiten como cabeceras más listas de hashes contra la mempool [11], de modo que la latencia de propagación no escala con el contenido del bloque, y el receptor verifica el trabajo de la cabecera antes de descargar ningún cuerpo.

La sincronización elige por trabajo verificado. Un nodo que se pone al día prefiere el par cuyas cabeceras han demostrado realmente más trabajo frente al par que afirma la mayor altura. Las cabeceras se validan como cadena antes de descargar los cuerpos; una rama competidora solo se adopta cuando conecta dentro del horizonte de deshacer y lleva más trabajo que la cadena a la que sustituye (bajo proof of stake, más slots, §11). Los checkpoints fijados, incrustados en la versión publicada y aceptados solo cuando un bloque tiene al menos una época de antigüedad, rechazan una cadena que los contradiga por pesada que sea, como defensa de la era de lanzamiento contra la reescritura de la historia; un operador puede añadir un checkpoint fijado mediante un flag.

Los pares reciben una puntuación, por identidad: un mensaje inválido cuesta 20, una violación del protocolo 50, un cuerpo no servido 10, una petición excesiva 5; un mensaje útil gana 1; un par queda vetado en −100. Las comprobaciones caras, épocas de clave y evaluaciones de proof of work, se presupuestan por par y se reembolsan cuando el bloque resulta útil, de modo que un atacante no puede hacer que un nodo muela trabajo en anuncios que no llevan a ninguna parte.

Citas. Una cabecera puede citar hasta cuatro cabeceras competidoras recientes a la altura de su padre, sin pago: citar requiere proof of work real, mientras que suprimir la señal requeriría que casi todos los productores la omitieran. La tasa de forks citada es la señal de salud que lee el controlador de comisiones (§9).

La interfaz del nodo. Las lecturas se sirven por HTTP, enlazado a localhost por defecto; enviar certificados, intents abiertos y tarjetas de servicio firmadas son las únicas escrituras. Las lecturas tienen límite de frecuencia por cliente, con un token de confianza para eximir a las herramientas propias del operador. Un endpoint Stratum en el dialecto que hablan los mineros de CPU habituales permite que un nodo mine con software externo.

11. Proof of stake#

Esta sección especifica el consenso de la era en la que la producción de bloques pasa del proof of work al stake. Las reglas de §2 a §10 se mantienen sin cambios salvo donde esta sección diga lo contrario; el calendario y todos los valores están en el documento complementario. Las constantes marcadas como abiertas las fija la versión de la era.

Qué cambia. Dos cosas. El derecho a producir el siguiente bloque, que el proof of work vende a cambio de hashes, se sortea por stake; y el intervalo entre bloques baja de 30 a 5 segundos. Todo lo demás se mantiene: cada regla de validez de §2 la comprueba cada nodo, para cada certificado, a partir de los bytes; el fold es el mismo; los dos mercados de gas son los mismos; un certificado inválido dentro de un bloque hace inválido el bloque. La regla de citas de §10 se mantiene, con la firma de slot de la cabecera citada en lugar de su trabajo. La superficie que abre esta era es la de un proof of stake, y ninguna otra.

Adónde va el cómputo. Un minero de proof of work gasta cómputo en hashes, que compran seguridad y nada más. Un productor en esta era gasta el mismo cómputo en verificación: comprobar firmas, reejecutar programas, derivar certificados, en paralelo, antes de ordenarlos. El trabajo por el que paga la red pasa a ser el trabajo que la red necesita. Un ordenador corriente verifica miles de certificados por bloque; un productor con más núcleos sigue el ritmo a medida que crece el volumen. La verificación paralela pone el techo muy por encima de lo que consume el bucle secuencial; lo que hay más allá está en §12.

Stake. Un participante pone en fianza moneda nativa con una operación nativa, BOND, que mueve saldo desde una dirección persistente a una celda de stake ligada a esa dirección. Las celdas de stake son celdas de protocolo: el certificado autoriza el movimiento y el fold realiza la escritura, como hace con los contadores de los secuenciadores. La clave de esa dirección es la clave que firma los bloques. Un stake pasa a estar activo una época después de ponerse en fianza, de modo que no pueden crearse y desecharse stakes en serie; UNBOND devuelve el saldo tras un plazo más largo que el horizonte de deshacer. El mínimo lo fija el documento complementario. Una clave, un stake.

El sorteo. Los bloques ocupan slots de un intervalo fijo. Para cada slot se sortea un productor del conjunto de stakes activos en la apertura de la época, con probabilidad proporcional al stake, a partir de una semilla que la cadena fijó durante la época anterior y escribió en las celdas de la baliza (§4); los productores de los bloques que fijan la semilla no deben poder sesgarla. La cabecera lleva el slot y la firma del productor sorteado en lugar del proof of work; una cabecera firmada por otra clave, o fuera de su slot, es inválida. Un slot sin bloque queda vacío, y el siguiente productor sorteado construye sobre el último bloque que conoce. El sorteo es una función de un estado fijado antes de que se abra la época, de modo que cada nodo lo deriva por sí solo, y no se intercambia ningún mensaje de consenso más allá del propio bloque. El linaje es la lotería de líderes de slot de Ouroboros [17] y el calendario de líderes por época de Solana [21]; ocultar al líder tras una función aleatoria verificable [31], como hace Praos [18], es la alternativa si la denegación de servicio contra productores conocidos se convierte en un problema.

Elección de cadena. Donde §10 elige por trabajo verificado, esta era elige por longitud: entre las cadenas válidas, la que ocupa más slots [17]; entre dos de igual longitud, aquella cuyo primer bloque tras la bifurcación está en el slot más temprano. El horizonte de deshacer y los checkpoints fijados de §10 se mantienen y son la defensa contra la reescritura con claves que ya retiraron su fianza: un nodo que se une a la red acepta la historia que fija su versión, y ninguna cadena más larga la contradice.

Recompensa. El subsidio del bloque y las comisiones de prioridad van al productor sorteado, como iban al minero, a través del mismo anillo de madurez; la parte quemada sigue quemada. Los ingresos esperados de un participante son proporcionales a su stake, y el coste de cobrarlos es la verificación de los certificados que incluye. Un bloque inválido se rechaza y no paga nada a quien lo firmó.

Doble firma. Solo una falta se castiga en el consenso: dos cabeceras firmadas por una misma clave para un mismo slot. Como un certificado inválido, es una prueba de un solo mensaje, comprobable por cualquiera a partir de los bytes. Un certificado de denuncia lleva las dos cabeceras; el fold quema la propia fianza del firmante, retira la clave del conjunto activo y paga al denunciante una fracción abierta. Una denuncia se acepta hasta que se completa la salida del stake. Ninguna otra conducta se castiga en el consenso, y ninguna conducta de un productor alcanza la moneda de nadie más. El precedente es el slashing de proponentes de la beacon chain de Ethereum [19].

Pools. Una pool es un stake que acepta delegación. Cualquier dirección persistente puede constituir una fianza y, mediante una operación nativa DELEGATE, dirigirla hacia la clave de una pool; una fianza que solo delega tiene un mínimo menor que una que produce. El saldo nunca sale del delegador, que lo redirige o retira la fianza con el mismo plazo de salida. El peso de una pool en el sorteo es su propia fianza más lo que se le delega. La recompensa de los bloques que produce una pool la reparte el fold una vez por época, fuera del camino por bloque, entre la pool, con un margen que declara al registrarse, y sus delegadores, en proporción al stake. Ante una doble firma se quema la propia fianza de la pool y sus delegaciones vuelven a sus delegadores. Cómo se reparte la verificación dentro de una pool es asunto de la pool: cada miembro verifica la parte que recibe, un certificado puede ir a más de un miembro, y el operador coteja las respuestas, ensambla el bloque y lo firma con la clave sorteada. Todo esto es construcción, fuera del consenso y libre por diseño (§1): la cadena ve una tabla de delegaciones, una cabecera firmada por una clave y un bloque cuyos certificados todo nodo completo vuelve a verificar. Un nodo pequeño aporta los núcleos que tiene; un poseedor que solo tiene moneda aporta stake. El linaje son las stake pools de Cardano [20], que tampoco aplican nunca slashing a los delegadores.

La rampa. La era entra en tres pasos, cada uno una regla de consenso.

1. Fianzas. Se aceptan BOND, UNBOND y DELEGATE. El proof of work sigue produciendo todos los bloques y recibiendo toda la parte del productor.
2. Rampa, durante 90 épocas. Todo bloque sigue minándose, y lleva la firma del stake sorteado para su altura, en la cabecera, fuera de la preimagen del proof of work; el id del bloque la cubre, de modo que un bloque firmado y su copia sin firmar son dos bloques, y a igual trabajo gana el firmado. La elección de cadena sigue siendo por trabajo, y dos firmas a una misma altura no son doble firma. La parte del subsidio del productor se divide entre el minero y el staker: un contador k empieza en 1 y sube en uno con cada época que supera la compuerta, y el staker se lleva k/180, de modo que el trabajo conserva al menos la mitad hasta la transición. Un bloque llevado sin la firma es válido y no paga a nadie: la parte del subsidio de su productor y sus comisiones de prioridad se queman, de modo que un minero no gana nada dejando fuera al staker, y un staker no gana nada ausentándose. Una época supera la compuerta cuando al menos el 90% de sus bloques llevaron la firma y el stake activo, delegaciones incluidas, mantuvo al menos el 10% del suministro. La rampa empieza cuando el stake activo alcanza el 10% del suministro durante 30 épocas o, a más tardar, en la época que fija el documento complementario, con el stake que exista. Ningún bloque lo produce solo el stake antes de que el stake haya firmado, en producción, nueve de cada diez bloques durante 90 épocas. El precedente es el híbrido de Decred, en el que los bloques minados llevan votos de stake y el subsidio se reparte entre ambos [22], y The Merge, en el que el stake mantuvo su propia cadena durante casi dos años antes de asumir la producción de bloques [23].
3. Transición. El primer bloque de la época posterior a la 90.ª época que supera la compuerta es el slot 0: el proof of work termina, el intervalo pasa a ser de 5 segundos y la época pasa a ser de 17.280 slots. Lo que una época paga en subsidio no cambia; cada bloque paga una sexta parte, y un slot vacío no paga nada. Los techos por bloque (§9), con sus mínimos y sus topes, y el recuento del camino forzado (§8) se dividen entre seis, redondeando hacia abajo, de modo que la capacidad por día es la misma en el instante de la transición, y el controlador por época continúa desde ahí. Toda constante contada en bloques que mide tiempo (madurez, TTL máximo, ventana del intent, horizonte de deshacer, ventana del tiempo mediano, vida de una entrada del directorio) se multiplica por seis, y una madurez o un TTL fijados antes de la transición se convierten en el bloque de la transición.

Finalidad. Un bloque es definitivo por profundidad, como bajo proof of work. Los servicios financieros deberían esperar 10 minutos: 120 bloques, donde el proof of work pedía 20. Los bloques con más de una época de antigüedad pueden fijarse como checkpoints.

12. Más allá de la verificación completa#

En las eras del proof of work y del proof of stake, cada nodo verifica cada certificado. El cómputo no es el límite: la verificación es paralela, y los techos de §9 se vuelven a fijar en los límites de era hasta la anchura estructural de la lista de certificados, 2²⁵ por bloque. Lo que limita antes de ese muro son los datos: el ancho de banda para recibir cada cuerpo y el almacenamiento para guardar cada cuerpo y cada entrada del registro de gastadas. Esta sección dice lo que se sabe de la ruta más allá de ese punto y la deja para una era posterior, activada bajo demanda, cuando el volumen diario se acerque a lo que verifica un nodo corriente. Es una dirección, no una especificación: los problemas tienen varias soluciones con distintos compromisos, la red atiende toda la demanda que encontrará durante mucho tiempo sin ninguna de ellas, y prepararse en detalle para un futuro lejano no vale más que dejar la ruta señalizada para quien la recorra. Nada de lo anterior cambia. La validez como función de los bytes, el fold, el acceso tipado, los dos mercados, los secuenciadores y el camino forzado siguen como están. Lo único que cambia es quién verifica cada certificado.

Lo que permite el certificado. En las cadenas de reejecución, Ethereum, Solana y las que derivan de ellas, todo validador ejecuta cada transacción contra el estado global, la verificación hereda los límites del estado, y la respuesta histórica han sido máquinas más grandes, es decir, menos nodos. La ejecución paralela dentro del nodo, con listas de acceso declaradas como en Solana [21], hace más rápida cada máquina y no cambia quién necesita una. Cardano se acercó más: en el modelo UTXO extendido la validación es determinista y local [24], pero los scripts se ejecutan en cada nodo y el estado compartido entra en contención, lo que el modelo resuelve llevando la serialización a batchers fuera de cadena, que la cadena no reconoce. Los rollups, tanto optimistas como de validez [25][26], sacaron la ejecución de la cadena base y la dejaron verificando: esa es la división correcta, pagada con una segunda capa, un puente, un único secuenciador cuyo camino forzado espera tras un retraso y, según el tipo, una semana de disputa interactiva o un probador que cuesta órdenes de magnitud más que ejecutar. Un certificado de Zycord es un lote de rollup que la cadena base comprueba a partir de sus propios bytes y nunca ejecuta contra su estado, y por esa razón no necesita una segunda capa: no hay puente porque hay un único estado; no hay disputa porque un certificado inválido es su propia prueba de fraude, en un solo mensaje; no hay probador porque verificar cuesta lo que cuesta ejecutar; el secuenciador es por contrato, el camino forzado aterriza en el bloque siguiente, y dos contratos bajo secuenciadores distintos se componen en un único certificado atómico (§7), donde dos rollups necesitan un puente. Y donde la respuesta al crecimiento es el sharding, la trayectoria original de Ethereum, Near [27], las parachains [28], que particiona el estado y pierde la atomicidad entre particiones, la partición de Zycord, cuando llegue, particiona la verificación y no el estado: el estado sigue siendo uno, el fold sigue siendo uno y todo certificado sigue siendo atómico, porque quién verifica un certificado es una elección libre cuando la validez es una función de los bytes.

Verificación muestreada. Con stake en fianza, la responsabilidad de verificar un certificado puede asignarse por sorteo a un subconjunto de stakes en lugar de recaer en todos ellos. Un certificado entra en un bloque con las atestaciones de su comité; cualquier nodo sigue siendo libre de verificar lo que quiera; un certificado inválido sigue siendo su propia prueba de fraude, un solo mensaje, sin estado y sin juego interactivo [29]; y lo que la era añade es el slashing de quien atestó. El tamaño del comité, la forma de la atestación, la ventana de impugnación y lo que ocurre con lo que se aplicó sobre un certificado anulado son la especificación de esa era, y quedan abiertos. El efecto es invertir la curva: la capacidad crece con cada nodo que se une, porque cada uno verifica una parte menor, y el comité crece con el conjunto.

El cono de verificación. Quien recibe un certificado no necesita la cadena entera para confiar en él. Las lecturas se declaran, de modo que el conjunto de certificados del que depende es enumerable a partir de la cadena: para cada celda leída, los certificados que la escribieron desde la última raíz de estado de época, y los de esos, recursivamente. Ese cono, reverificado a partir de los bytes y anclado en una raíz de época con la que se compromete la cabecera (§3), es una verificación completa de lo que le importa al receptor, hecha en segundos, en tiempo de red, sin circuito y sin prueba especial. Un exchange que recibe un depósito verifica el cono del depósito, no la red; bajo verificación muestreada, lo que queda es esperar a que pasen las reorganizaciones y la ventana de impugnación, que es lo que ya hace hoy. Una prueba de que una celda tenía un valor dado en la raíz de época es el único objeto nuevo que esto requiere, y su forma está abierta; el linaje es la verificación simplificada de pagos [1].

Almacenamiento. Lo que la red ya hace: las celdas de un solo uso gastadas se compactan más allá del horizonte de deshacer (§4), y un nodo poda los cuerpos por debajo de un mínimo que anuncia (§10). Lo que queda como caso de estudio: un registro de gastadas por época, en el que las direcciones de un solo uso caducan y el registro se cierra; un acumulador en lugar del registro [30]; y la conservación de los cuerpos antiguos por una fracción de los nodos, con la raíz de época como garantía de que lo que se conserva es lo que se gastó.

Ancho de banda. Dos rutas. La primera es la topología que el diseño ya tiene: monedero, secuenciador, productor. Un fill no necesita inundar la red; va del secuenciador a los productores, y todos los demás reciben el hash, como la retransmisión ya hace con los bloques (§10). La segunda es separar la cabeza de un certificado de su cuerpo. La cabeza es lo que toca el fold: id, lecturas, escrituras, depósito y puja. El cuerpo es lo que consume la verificación: programa, calldata, firmas. Bajo verificación muestreada, un productor necesita el cuerpo solo de los certificados que le toca verificar por sorteo y la cabeza de todos los demás, y su ancho de banda cae en órdenes de magnitud. El bloque sigue comprometiéndose con el hash del ejemplar completo, y los cuerpos siguen siendo datos de la cadena, servidos por quien los verificó y por quien los archiva; cómo se garantiza su disponibilidad cuando no todos los nodos los guardan es la pregunta que la era debe responder antes de existir [29].

13. Riesgos aceptados#

Consecuencias de las reglas que se aceptan tal como están. Cada una está acotada, o recae en una parte que la eligió; ninguna permite a nadie quedarse con el valor nativo de un tercero.

1. Un contrato cuyo secuenciador, cuyo administrador y cuyo código de cambio de secuenciador han desaparecido todos solo puede abandonarse por el camino forzado: lento y más caro, pero vivo.
2. Con bloques vacíos, ambas comisiones base acaban detenidas en 7, por encima de su mínimo de 1: por debajo de 8, el paso descendente se redondea a cero. Mover ese punto de reposo requiere un cambio de parámetro en un límite de era.
3. Aproximadamente un bloque de sabotaje pagado mediante comisiones sobre un contrato caliente: los certificados forzados propios del productor colocados alrededor de los de un usuario, acotados por las cotas del usuario, y un certificado forzado por bloque que obliga al secuenciador a reconstruir su pipeline.
4. Un contrato abierto, con clave de secuenciador cero, solo está protegido por su código, y el autor de un certificado contra él paga sus propias omisiones: el autor eligió las lecturas.
5. Un activo no nativo abonado a una dirección de un solo uso por cualquiera que no sea el certificado que la quema queda congelado por la quema, que solo mueve el saldo nativo y las celdas que escribe ese certificado. Comprobar los saldos de activos de una dirección antes de quemarla es una regla del monedero, no del protocolo.
6. Un certificado que solo mueve deltas no hace avanzar el fence (§7); un fill construido antes que él que lee de forma exacta una celda que ese certificado movió se omite en un bloque posterior, con cargo al secuenciador. Un secuenciador lo evita no leyendo de forma exacta una celda que su contrato permite a cualquiera mover por delta.
7. Sabotaje residual contra el ejecutor del camino forzado: un atacante con muchos pagadores puede retransmitir intents abiertos que ningún certificado puede llevar, como uno cuyo pagador no alcanza a cubrir el pago. Una llamada que simplemente revierte o rebasa sus cotas no está entre ellos: aterriza en su forma fallida y paga (§8). Cada intent no transportable le cuesta al ejecutor una construcción; la copia se expulsa entonces y se pone en cuarentena, y un reemplazo sobre el mismo pagador debe pagar estrictamente más.
8. Un cofirmante no bloquea ninguna celda. Un fill conjunto que firmó ocupa un lugar en su pipeline hasta que el fill se lleva o pasa su ventana (§7). Un fill conjunto que no se lleva a tiempo puede encontrarse con otros fills sobre esas celdas; el que entre en segundo lugar en el fold se omite, con cargo a su propio depositante.
9. En un contrato abierto, el certificado cuya dirección de depósito se ordena primero gana una carrera de lecturas exactas, y generar direcciones por fuerza bruta es barato; un contrato con estado exacto disputado elige un secuenciador, cuyo pipeline fija el orden.
10. Una llamada simple sobre el camino exacto de un contrato abierto declara la celda de secuenciador del contrato como lectura exacta de cero. Si el contrato obtiene una clave antes de que el certificado aterrice, la lectura queda obsoleta y la llamada se omite, con cargo a quien llama; el monedero avisa antes de construir una llamada así.
11. La comisión de omisión es fija, de modo que cuando las comisiones base son altas una omisión cuesta menos que una aplicación; probar varias variantes de un mismo certificado es barato, y cada nodo verifica cada una de ellas.
12. El ancho de banda y el almacenamiento con alto rendimiento son un problema abierto declarado, no uno resuelto: los cuerpos son datos de la cadena, todo nodo lleva cada byte, una llamada a la máquina lleva el código que ejecuta, y el registro de gastadas crece una entrada por cada gasto de un solo uso. La ruta está en §12.
13. Bajo proof of stake (§11), la seguridad de la cadena es la de un proof of stake convencional: cuesta lo que cueste reunir una mayoría del peso del sorteo, delegaciones incluidas. La rampa empieza en su plazo límite con el stake que exista, y la compuerta es lo que impide que la transición se complete sin un stake vivo que mantenga una décima parte del suministro; una décima parte del stake, ausente, la pausa. La doble firma de una pool solo le cuesta su propia fianza, sea lo que sea lo que se le haya delegado; los delegadores eligen su pool sabiéndolo. La reescritura de largo alcance con claves que ya retiraron su fianza solo la impiden los checkpoints fijados (§10), que un nodo que se une acepta de su versión y no deriva de la cadena.

14. Conformidad#

Las reglas son la especificación de la arquitectura, los vectores de referencia son el protocolo, y donde dos cualesquiera de ellos discrepen gana el más preciso y la discrepancia es un error. El protocolo vive en un directorio spec/ publicado: los archivos de parámetros, el registro de ids de cadena, los checkpoints fijados, las imágenes de la biblioteca predesplegada y tres corpus de vectores:

• vectores de fold: (pre-state, block) → (post-state | invalid, outcomes, fees); un vector inválido registra la única regla que incumple;
• vectores de derivación: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), o la regla que rechaza el certificado antes de llegar a la máquina;
• vectores de dificultad: (parameters, headers) → next target, con un veredicto sobre una cabecera candidata; bajo proof of stake, (stake set, seed, slot) → drawn key.

Los vectores se generan, nunca se editan a mano. La regeneración pasa por el fold de referencia, reproduce el resultado a través de él y luego reproduce el JSON consolidado a través de un segundo fold, deliberadamente ingenuo, que no comparte código con el primero; una regeneración con la que el segundo fold discrepe falla. Una regeneración que cambia un vector existente es un cambio de consenso y se revisa como tal. Una implementación es conforme cuando reproduce el id de génesis y supera los vectores; entonces es un par, no un fork.

15. Relación con la v1.0#

Este artículo sustituye por completo a la v1.0 [0]. Donde ambos difieren, este artículo es el protocolo y la v1.0 no debe leerse junto a él. La tesis no cambia: certificados autocertificados, un fold que nunca ejecuta, acceso a estado tipado y dos mercados de comisiones. Los cambios que siguen se descubrieron al implementar el diseño; cada uno eliminó superficie de consenso y clases de error.

16. Conclusión#

Zycord ordena certificados en lugar de ejecutar transacciones: validez comprobable por cualquiera, en cualquier lugar, en paralelo, solo a partir de los bytes; estado que avanza mediante un fold que solo compara y suma; conflictos omitidos, con precio y cobrados a la parte que los eligió; concurrencia declarada en lugar de descubierta; aplicaciones confirmadas en milisegundos por secuenciadores de los que se confía su vivacidad y nunca la seguridad; un camino forzado que mantiene accesible todo contrato; y un consenso que, una vez distribuida la moneda, gasta su cómputo en verificación en lugar de en hashes. La verificación escala hacia fuera con hardware que la red no posee. La consolidación sigue siendo secuencial, y casi gratuita.

Referencias#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Sustituido por este artículo.
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. 2013.
[3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018.
[4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012.
[5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022.
[6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022.
[7] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Documentación del Monero Research Lab.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (slashing de proponentes). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: lanzamiento, eras y parámetros#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Este documento es el complemento de Zycord: una red entre pares de transiciones de estado autocertificadas, v2.0 ("el artículo"). El artículo define los mecanismos. Este documento expone cómo se lanzó la mainnet, cómo se emite la moneda, qué activa cada era y el valor de cada parámetro. Sustituye por completo a los §13 y §14 del artículo v1.0; donde difieran, rige este documento.

1. Lanzamiento#

Génesis de la mainnet: 2026-10-07 00:00 UTC (1791331200), id de cadena 1.

• Bloques cada 30 segundos bajo proof of work; cada 5 segundos desde la transición a proof of stake (§6). Proof of work: RandomX v2, minable con CPU. Dificultad: LWMA sobre una ventana de 90 bloques.
• El bloque 0 no contiene ningún certificado, ninguna dirección ni ninguna clave. No existe moneda antes del bloque 0. El génesis es reproducible a partir de fuentes publicadas.
• Sin ronda de inversores y sin claves de administración. Ninguna ruta de código permite a ninguna clave pausar, actualizar, acuñar, censurar ni reorganizar.

El compromiso de lanzamiento. El conjunto de parámetros lleva un compromiso con un mensaje de lanzamiento secreto. El bloque 1 debe abrir ese compromiso en su cabecera, de modo que solo el poseedor del mensaje puede producir el bloque 1, y nadie más puede acumular trabajo sobre una cadena que empiece antes del génesis anunciado; la rampa de emisión hace que cualquier ventaja inicial valga poco. Desde el bloque 2 en adelante, cualquier minero puede construir.

Los ids de cadena se anotan en un registro. El registro, con el id de génesis que lleva cada red activa, está incrustado en todo binario y se comprueba al arrancar: el nodo rechaza un id retirado, y un conjunto de parámetros que daría a un id registrado un génesis distinto. Un nodo se niega a arrancar con un motor de trabajo distinto del que declara la red.

2. Emisión#

El subsidio decae suavemente hasta una cola perpetua. La tasa es constante dentro de una época de un día y desciende un escalón en cada frontera de época, mediante aritmética entera exacta sobre cuatro constantes:

E(0) = E0
E(n) = max(tail, E(n−1) − floor(E(n−1) / Q))

con E0 = 21 ZCD por bloque, Q = 1054 y tail = 0,33 ZCD por bloque, al intervalo de proof of work de 30 segundos. La tasa se reduce a la mitad aproximadamente cada dos años. No hay números de coma flotante ni tabla. El bloque génesis no paga coinbase. La cola comienza en la época 4.376, hacia el año 12, con 61.836.900,03 ZCD programados: los 62.744.838,47 a los que suma el calendario, menos la rampa de lanzamiento y el bloque génesis. Esas cifras son lo que produzca la recurrencia; ningún nodo calcula nunca una forma cerrada. Un ZCD son 100.000.000 drops.

Un arranque lento. Los primeros 86.400 bloques (30 días) son una rampa: el bloque h paga E(30) · h / 86,400, la tasa de la época en la que termina la rampa, redondeado hacia abajo, de modo que la recompensa sube en línea recta desde casi cero hasta el calendario. Lo que la rampa retiene, unos 907.917 ZCD, no se paga nunca después.

El cambio de intervalo. A partir de la transición a proof of stake (§6), la época son 17.280 slots y el subsidio por bloque es E(n)/6, redondeado hacia abajo en drops; la recurrencia no cambia. Lo que paga un día de slots completos es lo mismo con ambos intervalos: 21 ZCD por bloque en la curva de génesis equivalen a 3,5 por bloque de 5 segundos, y la cola de 0,33 equivale a 0,055. La cola comienza en la misma época, 4.376. El redondeo retiene menos de una milésima de ZCD por época y no se paga nunca después.

La cola paga a quien asegure la era vigente sin reclutar a los mercados de comisiones. En sentido contrario actúan la quema de la comisión base de ambos mercados y la quema de cada certificado omitido (artículo §9), de modo que la emisión neta es la cola menos la quema y puede ser negativa bajo carga. Como fracción del suministro, la cola tiende a cero.

3. Reparto del subsidio#

Todo subsidio de bloque se reparte 94 / 3 / 3 por consenso desde el bloque 0. El reparto se aplica solo al subsidio, nunca a las comisiones, y de forma idéntica a todo bloque. Durante la rampa del proof of stake (§6), el 94% del productor se divide a su vez entre el minero y el staker sorteado, según la fracción que haya alcanzado la rampa.

No hay premine: el reparto es una regla aplicada a todo bloque minado, no una asignación en el génesis. A lo largo de sus tres años, la parte del fundador suma menos del 2% del suministro previo a la cola. Un productor que rebasa con una ráfaga el techo blando (artículo §9) solo pierde de su propia parte; las partes de la tesorería y del fundador se toman del subsidio sin reducir.

4. Tesorería#

La celda de la tesorería es el saldo nativo de la dirección de protocolo. Ninguna clave genera por hash esa dirección, ningún certificado puede debitarla y el génesis no nombra ningún quórum. Acumula desde el bloque 1, y esta versión no lleva ningún camino de gasto en absoluto. Un camino de gasto lo define una actualización, no antes de la altura 259.200 (hacia el 5 de enero de 2027), con firmantes elegidos por la comunidad y no por el fundador. Hasta entonces, la celda es un entero público que cualquiera puede auditar y nadie puede tocar.

5. Custodia: los tres primeros años (propuesta)#

Estado. Esta sección es una orientación para revisión de la comunidad. Nada de lo que contiene es una regla de consenso hasta que la actualización de la tesorería de §4 fije un conjunto de claves, y los detalles solo se especifican después de que se acepte la orientación.

Lo que recibe la tesorería. Unos 533.000 ZCD en el año 1, 396.000 en el año 2 y 280.000 en el año 3: unos 1,21 millones en total. A partir del año 4 también toma el 3% del fundador (§3), para unos 396.000 ese año en total. Lo que esto permite pagar depende de un precio que nadie conoce, y un mercado poco líquido no puede absorber ventas grandes, de modo que el plan debe funcionar en el extremo bajo:

Por eso, cada importe que sigue es una parte de los ingresos de la tesorería, nunca una cifra en dólares ni en ZCD.

Cinco puestos. El puesto se define antes que su titular. Cada puesto tiene una carta pública: sus funciones, sus entregables, cómo rinde cuentas y cuánto se le paga. Cualquiera puede presentar su candidatura. Quien ocupe el puesto sirve a la carta, como bajo un contrato.

Decisiones.

• Un gasto necesita 3 de 5.
• Sustituir a un titular, rotar claves, gastar la reserva o modificar una carta necesita 4 de 5, y es público durante 7 días antes de surtir efecto.
• Los mandatos duran un año y son renovables. Las candidaturas son públicas durante 30 días. Los cinco primeros titulares son el conjunto de claves fijado por la actualización que adopten los operadores de nodos; un hard fork posterior puede volver a fijarlo.

La paga es participación, no salario. La parte de un puesto se acumula bloqueada y se libera cada seis meses, contra un informe publicado y los votos de 3 de los otros 4 titulares. Ningún titular vota sobre la liberación de su propia paga. Lo que no se libera vuelve a la reserva. La paga de los puestos la fijan las cartas y no se establece mediante una votación de gasto. Un tope por puesto, medido a precio de mercado en la fecha de liberación, envía cualquier exceso a la reserva.

Presupuesto, como partes de los ingresos.

La infraestructura tiene prioridad: los nodos, las semillas, el explorador y los servidores de compilación cuestan hoy unos US$ 500 al mes. El reembolso se convierte al precio de mercado del día en que se paga. La parte cubre ese coste a unos US$ 0,06 por ZCD en el año 1, US$ 0,08 en el año 2 y US$ 0,11 en el año 3; por debajo, el déficit se arrastra sin intereses y se paga cuando la parte lo permita.

El fundador. El 3% del subsidio del fundador (§3) recompensa el trabajo realizado hasta el lanzamiento y en él. Es independiente del puesto de desarrollador principal, que se paga como cualquier otro puesto por el trabajo continuado. El fundador posee una clave de cinco y no vota sobre la liberación de la paga de ese puesto.

Lo que impone el consenso. Una vez que llegue la actualización: el gasto con 3 de 5 y la rotación con 4 de 5 con su plazo. Todo lo demás de esta sección es una norma. Lo que impone una norma es que todo gasto es un certificado ordinario, público y contable solo a partir de la cadena.

Abierto. El tope por puesto. La forma jurídica bajo la que firma el representante público. Si el bloqueo de seis meses lo impone un contrato escrow de la biblioteca estándar una vez que la máquina esté activa.

6. Eras#

Las eras son constantes de altura compiladas en versiones públicas. Un bloque por debajo de una compuerta que lleva un programa que esa compuerta habilita es inválido, y esa comprobación de altura es lo único que separa las eras, salvo la rampa y la transición de la era 2, que las desencadena el estado dentro de unos límites de altura. Una era nueva puede añadir reglas y tipos de registro; nunca cambia lo que significa un bloque existente por debajo de su altura de activación.

Las Eras 2 y S se publican cada una como su propia versión mediante hard fork, con una especificación, una devnet adversarial y revisión. La era 2 abre las fianzas por altura, inicia su rampa por stake con un plazo límite y hace la transición cuando la rampa se completa: lo más pronto que puede producirse la transición es la época 303 (mes 10), y el plazo límite del inicio garantiza que la rampa esté en marcha al final del mes 9. Para el umbral del 10%, el stake es el stake activo con sus delegaciones y el suministro es la moneda emitida, ambos en la apertura de la época. La compuerta puede pausar la transición más allá de la época 363; lo que no puede hacer es impedir que empiece.

Stake. La fianza mínima es de 1.000 ZCD, y un stake participa una época después de ponerse en fianza. Una fianza que solo delega tiene un mínimo menor, fijado por la versión de la era, y nunca sale de la custodia del delegador. El mínimo está en ZCD y no en dólares porque ninguna regla puede leer un precio; se revisa en los límites de era a medida que crece el techo de bloque.

La era 0 es deliberadamente diminuta y la era 1 se reduce a lo que el diseño necesita: sin claves de administración no hay botón de pausa, de modo que cada línea de consenso es una línea que puede matar la red sin remedio. El código de consenso inalcanzable es código de consenso inauditable y no se publica. Una era que no demuestre que vale su complejidad nunca se activa.

La transición es abordable porque el fold es agnóstico respecto a quién ordena: la era 2 cambia de quién es la firma que va en la cabecera.

Compuerta de la era 1. El bloque de la compuerta escribe las constantes compiladas de la era en celdas de protocolo, de modo que la raíz de estado se compromete con ellas a partir de entonces. En los primeros 240 bloques tras la compuerta, un certificado que ejecuta SETSEQ debe llevar un TTL de al menos 240 bloques más allá de la compuerta y esperar a que entre en rango.

La era 2 y las alturas que miden tiempo. Tras la transición, la altura avanza seis veces más rápido. Toda constante de génesis que en realidad es una duración (el fin de la parte del fundador, la madurez del coinbase, el TTL máximo, la ventana del intent, la profundidad de deshacer, la ventana del tiempo mediano, la vida de una entrada del directorio) la lee la era 2 en la unidad que mide: la altura 3.153.600 son 1.095 épocas de 2.880, y la era termina la parte del fundador en la época 1.095. La tabla de parámetros de génesis no cambia, porque la raíz de consenso recorre todos los parámetros y mover uno movería el id de génesis de toda red activa; las constantes de la era se compilan, como las de la era 1.

7. Parámetros#

El conjunto de parámetros se congela en el génesis, se incrusta en todo binario en tiempo de compilación y solo puede modificarse mediante hard fork. Su raíz de consenso entra en toda firma. zcd params imprime los valores compilados de una compilación; zcd genesis imprime la red, el id de cadena, el hash de parámetros, el id de génesis y la raíz de estado.

Las constantes de la era 1 se compilan, no son parámetros, porque la raíz de consenso recorre todos los parámetros y añadir uno movería el id de génesis de toda red activa.

Las constantes de la era 2 se compilan por la misma razón.