Glosario

Certificado, fold, omisión, depósito, secuenciador, camino forzado. Varios de estos términos significan aquí algo más estrecho que en otros sitios, y un par nombran sucesos para los que la mayoría de las cadenas no tiene palabra.

El vocabulario que este protocolo usa, en el sentido en que lo usa. Varias de estas palabras significan aquí algo más estrecho que en otros sitios, y dos de ellas — omisión y descarte — nombran eventos para los que la mayoría de las cadenas no tienen palabra porque no tienen equivalente.

Certificado#

El único tipo de transacción en Zycord. Un certificado lleva el estado que leyó y el estado que escribió, más el programa que los conecta, las firmas que lo autorizan, un depósito, un TTL y una puja en cada uno de los dos mercados de comisiones. Como lleva sus propias entradas y salidas, comprobar si es válido no requiere estado alguno.

Fold#

El bucle determinista que hace avanzar el libro mayor. Recorre los certificados de un bloque en un orden canónico — primero los fills, luego todos los certificados ordinarios, luego los certificados forzados — y para cada uno comprueba si sus reads declarados siguen cumpliéndose: si lo hacen confirma los writes, y si no, lo omite. 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, y sin aritmética de curva elíptica. Es la única etapa del sistema que no se paraleliza.

Omisión#

Lo que le ocurre a un certificado cuyas lecturas declaradas ya no se cumplen, cuyos deltas saldrían del rango de 256 bits, o que escribiría bajo una dirección gastada. No se escribe nada, se quema de su depósito una comisión de omisión fija de 1.000.000 de drops (0,01 ZCD) que no paga a nadie, el resto del depósito se devuelve, y el bloque sigue siendo válido. Paga quien nombró el depósito: el autor de un certificado ordinario, que eligió las lecturas, o el secuenciador de un fill. Un usuario nunca paga la omisión de un fill. La omisión es semántica, no un fallo: la inclusión y la aplicación son sucesos distintos, así que un productor de bloques nunca puede producir un bloque inválido por incluir un certificado obsoleto.

Descarte#

Un no-suceso que no se cobra. Un certificado cuyo depósito no puede reservarse — la celda de depósito ya está gastada, o contiene menos que el importe que el certificado reserva — se descarta: va en el bloque, no se cobra, no se marca como visto, y puede reenviarse libremente contra un depósito nuevo. Por tanto, los usuarios honestos no pierden nada por carreras sobre su propia celda de depósito.

Depósito#

La celda que responde por un certificado: una celda de saldo nativo de una dirección de usuario, el importe reservado de ella y el slot de cambio al que vuelve el resto. No existe ningún certificado sin uno, y la celda de depósito siempre lleva una firma. Omitir no debe ser gratis, o el mempool se ahoga; el depósito es lo que da un dueño a cada conflicto. Un fill deposita desde el saldo persistente de su secuenciador, que es por lo que paga el secuenciador y no el usuario cuando un fill se omite, y un certificado forzado se paga en cambio con el pago de su intent abierto. Los avalistas y los certificados avalados del whitepaper v1.0 han desaparecido; esto es lo que los sustituyó.

Celda#

El valor en un slot — un entero sin signo de 256 bits almacenado en big-endian en 32 bytes. Cero es ausencia: un slot nunca escrito y un slot escrito a cero son el mismo slot. Eso es un requisito de consenso, no una comodidad: mantiene la raíz de estado como función del estado y no de la historia que lo produjo.

Dirección de un solo uso (0x01)#

Una dirección cuya autoridad de firma se quema de forma permanente con su primer cargo. Pagar a una dirección de un solo uso recién derivada es la vía rápida sin contención, y derivar una nueva por pago es lo que hace que un pago sea invinculable con el siguiente. El coste es que “gastar solo una parte” no es algo que una dirección de un solo uso pueda hacer — véase la regla 1 del monedero.

Dirección persistente (0x02)#

Una dirección reutilizable. No puede entrar nunca en el registro de gastadas, así que no tiene superficie alguna de perjuicio por quemado. Los comercios, las direcciones de donaciones, los depósitos de un secuenciador y los pagos de minería usan una; zycordd --payout rechaza cualquier otra.

Registro de direcciones gastadas#

El conjunto de consenso permanente de direcciones de un solo uso cuya autoridad se ha quemado. Los valores de celda bajo una dirección gastada pueden podarse tras el horizonte de deshacer, pero la entrada del registro nunca — es lo que impide que la dirección se resucite. Unos 33 bytes por dirección, para siempre: el problema abierto que el protocolo reconoce, compartido estructuralmente con todo diseño de conjunto de anuladores.

Válido frente a aplicable#

Dos predicados que una cadena convencional confunde. Válido es sin estado, paralelo, y comprobable por cualquiera solo a partir de los bytes del certificado. Aplicable es con estado, secuencial, y lo decide únicamente la posición en el libro mayor. Dos certificados válidos pueden declarar el mismo valor de entrada para el mismo slot; como mucho uno puede ser aplicable.

Delta con guarda#

Una disciplina de acceso en la que un certificado afirma un predicado sobre un slot — balance ≥ 10 — sin leer el valor hacia el cálculo, y escribe un delta con signo. Cualquier número de cargos y abonos con guarda sobre el mismo slot conmutan, así que una omisión ocurre solo ante un descubierto real y no meramente porque el saldo haya cambiado. Esta única disciplina cubre transferencias, acuñaciones con tope de oferta, autorizaciones y participaciones en bóvedas, y nunca está restringida por un secuenciador: un token secuenciado sigue aceptando cada transferencia de cualquiera.

Delta puro#

Un delta con signo sin guarda. No puede entrar nunca en conflicto ni sufrir nunca una omisión. Propinas, contadores, acumuladores, recuentos de recompensas.

Lectura exacta#

La disciplina al estilo SLOAD: la lectura devuelve el valor del slot hacia el cálculo y fija el certificado a él. Lógica arbitraria, conflictos en slots calientes, y el dominio de los secuenciadores.

Secuenciador#

Un servicio fuera de la cadena que un contrato elige para serializar su tráfico de lectura exacta. El registro de cada contrato contiene una clave de secuenciador: mientras no sea cero, una lectura exacta, una guarda de igualdad o un set sobre las celdas de ese contrato necesitan la firma de esa clave; mientras sea cero, el contrato es abierto, y solo está protegido por su código. El secuenciador ejecuta los intents de los usuarios y publica los resultados como fills. Se confía en él para la disponibilidad, nunca para la seguridad: no puede cambiar lo que hace un intent, solo cuándo, y un fill construido sobre una mentira se omite a costa del secuenciador. Si deja de atender, queda el camino forzado.

Intent#

Lo que un usuario firma en lugar de un certificado para llamar a un contrato secuenciado: el destino y el calldata, un presupuesto paralelo, un nonce, una ventana de como máximo 8 bloques, la dirección persistente del secuenciador, límites sobre el resultado, el pago debido a cada secuenciador, los pagadores de un solo uso que lo financian y las salidas de cambio. Un límite es un predicado sobre una celda que la llamada escribe — final-at-least, final-at-most, delta-at-least o delta-at-most — y al menos uno debe nombrar una celda que la llamada escribió. El intent es toda la autorización del usuario, y sus pagos solo se liquidan si el fill se aplica.

Fill#

El certificado que un secuenciador publica para un intent. Su programa es el intent, su depósito sale del propio saldo persistente del secuenciador, y su id es el hash del intent, así que dos fills de un mismo intent comparten id y solo uno puede cobrarse. Los fills van primero en el orden del fold, cada uno en cuanto está listo cada pipeline en el que figura.

Recibo#

La respuesta firmada de un secuenciador a un intent, devuelta en milisegundos, mucho antes de que exista un bloque: el id del intent, el seq del pipeline y el resultado. Es una preconfirmación — la promesa del secuenciador, no la de la cadena, y definitiva solo cuando el fill se aplica. Como los recibos están firmados, dos 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; los usuarios se marchan.

Pipeline#

La cadena guarda, para cada par de clave de secuenciador y contrato, el último seq aplicado. Un fill solo entra cuando ese contador está uno por debajo de su seq, y el contador solo avanza cuando el fill se aplica, así que los fills de un secuenciador se confirman en el orden en que los firmó, sea cual sea el orden en que los recibió un productor. Un fill omitido retiene los fills construidos detrás de él hasta que el secuenciador reconstruye desde el mismo número.

Contador fence#

Un contador en el registro de cada contrato. Un fill declara el contador fence de los contratos sobre los que se construyó, y no puede entrar si alguno se ha movido. Avanza cuando un certificado forzado que entra fija una de las celdas del contrato, y cuando se escribe la celda de secuenciador del contrato — así que el camino forzado y un cambio de secuenciador invalidan cada fill construido sobre el estado que cambiaron, sin cobrar a nadie. Una lectura o un delta no lo mueven, y tampoco un certificado forzado que falló. El secuenciador reconstruye y solo pierde latencia.

Cosecuenciación#

Una llamada que cruza contratos vinculados a distintos secuenciadores entra como un único fill que lleva la firma de cada secuenciador cuyo camino exacto toca, hasta 16, cada uno con un seq en su propio pipeline y cada uno cobrando lo que el intent le asigna. Cómo se coordinan ocurre fuera de la cadena y es libre por diseño; la cadena ve un único certificado, atómico por construcción.

Directorio de secuenciadores#

Donde un secuenciador anuncia su servicio: un certificado de directorio desde su dirección persistente vincula su clave a una cadena de 1 a 256 bytes de ASCII imprimible, normalmente una URL. La entrada caduca 259.200 bloques (unos 90 días) después del TTL del certificado de anuncio salvo que se renueve, y una retirada la elimina de inmediato. El consenso almacena la cadena y nunca la interpreta — es descubrimiento, no autorización. Un nodo la sirve en /directory.

Camino forzado#

El camino lento que no necesita secuenciador. Un usuario firma un intent abierto y lo retransmite a la red; un productor de bloques ejecuta los intents abiertos que elige contra el estado de final de bloque y añade los resultados como certificados forzados, los últimos certificados del bloque. La inclusión es la aplicación: no hay cola, arrendamiento, cuota ni plazo. Un bloque lleva como máximo 16 certificados forzados, cada uno con como máximo 4.000 unidades de derivación de presupuesto paralelo (200.000 de gas de la máquina), y por eso toda salida que ofrezca un contrato debe caber en ese presupuesto. Un certificado forzado cuya llamada revierte igualmente entra, como FORCED_FAILED: sus pagadores pagan, el cambio vuelve al usuario, y no se escribe nada más.

Intent abierto#

Un intent sin secuenciador nombrado y sin cosecuenciadores, financiado por los propios pagadores de un solo uso del usuario. Viaja por el mempool como intent, no como certificado, y su pago cubre las comisiones del certificado forzado: la parte de la comisión base se quema y el resto va al productor. zcd wallet open-intent firma uno, y zcd wallet intent --fallback firma uno cuando el secuenciador no atiende el original.

cEVM#

La única máquina virtual: un dialecto de la máquina virtual de Ethereum adaptado a los certificados. El almacenamiento se declara en lugar de descubrirse, se añaden opcodes para guardas, deltas y para fijar el secuenciador de un contrato, se eliminan los opcodes que aquí no tienen referente, y NUMBER y TIMESTAMP responden desde la baliza de época. Activa desde la Era 1, con una biblioteca estándar orientada a deltas predesplegada en direcciones conocidas. Solidity y sus herramientas se trasladan.

Baliza de época#

Celdas reservadas que el protocolo escribe una vez por época: el número de época, la altura de la cabecera que la abrió, una palabra de entropía y, desde la Era 1, la hora de esa cabecera. Los programas no deben leer directamente valores ambientales como la marca de tiempo o la altura — eso haría que la ejecución fuera función de algo distinto de los reads declarados — así que leen la baliza como cualquier otro slot, idealmente con una guarda de rango. Sus valores son constantes durante toda una época. La palabra de entropía es salida del proof of work y no es apta para loterías de alto valor.

Época#

2.880 bloques — alrededor de un día con bloques de 30 segundos, y desde la transición a proof of stake 17.280 slots de 5 segundos, todavía un día. La unidad sobre la que el subsidio escalona a la baja, se mueve el objetivo de capacidad secuencial y se refresca la baliza.

TTL#

La altura antes de la cual un certificado debe confirmarse para ser válido. Acotado por consenso a 240 bloques (unas dos horas), 1.440 bloques desde la transición a proof of stake, que es lo que mantiene podable el conjunto de vistos. Incluir un certificado visto o caducado hace inválido el bloque — así que una firma es cobrable como mucho una vez, y solo en una posición que su firmante aceptó al firmar.

Gas secuencial y gas paralelo#

Las comisiones se dividen en dos mercados: uno para la mutación secuencial de estado, que es escasa, y otro para la verificación paralela, que no lo es. Una comprobación de firma, por tanto, no compite en la misma subasta que una escritura de almacenamiento, que es lo que hace barata por diseño la criptografía pesada. En ambos, 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 íntegra.

Era#

Una etapa del protocolo, condicionada por una altura compilada en las versiones públicas y, en la Era 2, por el stake medido en la cadena dentro de unos límites de altura — nunca por una fecha del calendario ni por votación. Era 0, activa desde el bloque 0: minería, activos nativos, ambos mercados de comisiones, el reparto del subsidio y la tesorería, acumulando y sellada. Era 1 en la altura 80.640 de mainnet, hacia el 4 de noviembre de 2026, y desde la altura 2.880 en la testnet pública: la cEVM, los secuenciadores, los intents y los fills, el directorio y el camino forzado. Era 2, proof of stake: las fianzas se abren en la época 182, hacia el 7 de abril de 2027; la rampa empieza cuando el stake activo mantiene el 10% del suministro durante 30 épocas, a más tardar en la época 273; la transición al stake por sí solo sigue cuando la rampa se completa. La Era S añadiría pagos confidenciales, solo tras auditorías independientes, y no forma parte de la especificación actual. Las Eras 2 y S se publican cada una como una versión propia, mediante hard fork. Las fianzas no forman parte de la Era 1.

Proof of stake#

El consenso de la Era 2, en el que el derecho a producir el siguiente bloque se sortea por stake en lugar de venderse a cambio de hashes, y el intervalo entre bloques baja de 30 a 5 segundos. Todo lo demás se mantiene: cada nodo comprueba cada certificado a partir de sus bytes, el fold y ambos mercados de comisiones no cambian, y un certificado inválido dentro de un bloque sigue haciendo inválido el bloque. El cómputo que un minero gastaba en hashes, un productor lo gasta en verificación. Entra mediante una rampa y una transición, y hasta la transición los bloques se minan. Especificado en el §11 del whitepaper.

Stake#

Moneda nativa puesta en fianza para la producción de bloques. BOND mueve saldo desde una dirección persistente a una celda de stake ligada a esa dirección, cuya clave es la clave que firma los bloques, y UNBOND lo devuelve tras un plazo de salida más largo que el horizonte de deshacer. 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. La fianza mínima es de 1.000 ZCD; una clave, un stake. Las fianzas se abren con la Era 2, en la época 182.

Pool y delegación#

Una pool es un stake que acepta delegación. DELEGATE dirige una fianza hacia la clave de una pool, desde un mínimo menor que el de una fianza productora, y el saldo nunca sale del delegador, que puede redirigirla o retirar 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, y el fold reparte su recompensa una vez por época entre la pool, con el margen que declaró, y sus delegadores, en proporción al stake. Un delegador nunca sufre slashing: si una pool incurre en doble firma, solo se quema su propia fianza. No es una pool de minería, que está fuera de la cadena y fuera del consenso.

Slot#

Bajo proof of stake, un intervalo de 5 segundos en el que puede producirse un bloque, por el productor sorteado para él con probabilidad proporcional al stake a partir de una semilla fijada en la época anterior. Una época son 17.280 slots. Un slot sin bloque queda vacío y no paga nada, y entre cadenas válidas gana la que ocupa más slots. En otros contextos un slot es una ubicación de almacenamiento, (address, word), cuyo valor es una celda.

Rampa#

La entrada de la Era 2: 90 épocas en las que todo bloque sigue minándose y lleva además la firma del stake sorteado para su altura. El staker se lleva k/180 de la parte del productor, donde k empieza en 1 y sube en uno con cada época que supera la compuerta: al menos el 90% de los bloques de la época firmados, y un stake activo de al menos el 10% del suministro. Un bloque minado sin la firma es válido y no paga a nadie: la parte de su productor y sus comisiones de prioridad se queman. La rampa empieza cuando el stake activo mantiene el 10% del suministro durante 30 épocas, y en la época 273 a más tardar. No es la rampa de emisión de 30 días; véase emisión.

Transición#

El bloque en el que termina el proof of work: el primer bloque de la época posterior a la 90.ª época que supera la compuerta de la rampa, en la época 363, hacia el 5 de octubre de 2027, a más tardar si la compuerta nunca se pausa. A partir de él, los bloques llegan en slots de 5 segundos, una época son 17.280 slots y cada bloque paga una sexta parte de la tasa de la época; los techos por bloque se dividen entre seis y todo recuento de bloques que mide tiempo se multiplica por seis, de modo que la capacidad y las duraciones por día siguen siendo las mismas. Entonces un bloque es definitivo a una profundidad de 120 bloques, 10 minutos, donde el proof of work pedía 20.

Doble firma#

Dos cabeceras firmadas por una misma clave para un mismo slot: la única falta castigada en el consenso bajo proof of stake. Como un certificado inválido, es una prueba de un solo mensaje que cualquiera puede comprobar a partir de los bytes. Un certificado de denuncia lleva las dos cabeceras, y el fold quema la propia fianza del firmante, retira su clave del conjunto activo y paga una fracción al denunciante. Nada de lo que haga un productor alcanza la moneda de nadie más: las delegaciones de una pool vuelven a sus delegadores.

Emisión#

ZCD solo existe como subsidio de bloque, y el bloque 0 no paga ninguno. La tasa empieza en 21 ZCD por bloque y baja en cada límite de época mediante aritmética entera exacta — E(n) = max(tail, E(n−1) − floor(E(n−1) / 1054)) —, reduciéndose a la mitad aproximadamente cada dos años hasta alcanzar la cola perpetua de 0,33 ZCD por bloque en la época 4.376, hacia el año 12. Los primeros 86.400 bloques (30 días) son una rampa: el bloque h paga h/86.400 de la tasa que paga el bloque 86.400, y lo que la rampa retiene, unos 907.917 ZCD, no se paga nunca. Desde la transición a proof of stake cada bloque paga una sexta parte de la tasa de la época, de modo que un día paga lo mismo. zcd emission --height N imprime el subsidio a cualquier altura.

Reparto del subsidio#

Cada subsidio de bloque, y nunca las comisiones, se reparte 94 / 3 / 3 por consenso desde el bloque 0: el 94% al productor del bloque tras una madurez de dos horas (240 bloques, 1.440 bajo proof of stake), el 3% a la dirección persistente del fundador hasta la época 1.095 (tres años) y el 3% a la tesorería, que también recibe el 3% del fundador a partir de entonces. Durante la rampa del proof of stake, el 94% del productor se divide a su vez entre el minero y el staker sorteado. Es una regla aplicada a cada bloque minado, no una asignación en la génesis: no hay premine.

Tesorería#

El saldo nativo de la dirección del protocolo. Ningún hash de clave da esa dirección, ningún certificado puede debitarla y la génesis no nombra ningún quórum. Se le acredita el 3% de cada subsidio de bloque desde el bloque 1 y el 6% desde la época 1.095. No existe ninguna vía de gasto en el protocolo: solo puede añadirse una mediante una actualización posterior, con firmantes elegidos por la comunidad y no por el fundador, y el compromiso de lanzamiento es que no llegue antes de la altura 259.200, hacia el 5 de enero de 2027.

Propuesta de custodia#

Una propuesta para revisión de la comunidad, no una regla de consenso. Sugiere cómo podría gastarse la tesorería en sus tres primeros años: cinco puestos con estatutos públicos — desarrollador principal, desarrollador revisor, minero, comunidad, representante público — con 3 de 5 para gastar, y 4 de 5, públicos durante 20.160 bloques antes de surtir efecto, para sustituir a un titular, rotar claves, gastar la reserva o modificar un estatuto. Los presupuestos son fracciones de los ingresos de la tesorería, nunca sumas fijas. Nada de ella obliga hasta que la actualización de la tesorería fije un conjunto de claves. El texto está en el documento complementario.

RandomX#

La función de proof of work, optimizada para CPU de propósito general para que el hardware corriente siga siendo competitivo; mainnet y la testnet pública ejecutan randomx-v2. Es un parámetro de consenso, no un ajuste: un binario que no puede calcular el pow_engine de una red se niega a arrancar en lugar de recurrir a otra cosa.

Raíz de estado#

El compromiso con la totalidad del estado a una altura. Un nodo la recalcula al arrancar y se niega a funcionar si la almacenada discrepa, y sirve además de guarda diferencial en producción entre nodos: dos implementaciones que llegan a raíces distintas a partir de una misma secuencia de bloques han encontrado un fallo en una de las dos.

Dónde se define normativamente cada término#

Esta página es una ayuda a la lectura. Las definiciones que obligan están en la especificación y los vectores de referencia; el razonamiento está en el whitepaper, v2.0, y su complemento, Launch, Eras and Parameters, que rige la emisión, las eras y cada valor de parámetro. La sección de vocabulario de la propia implementación está en docs/ARCHITECTURE.md.