Zycord: una red entre pares de transiciones de estado autocertificadas

Zycord: una red entre pares de transiciones de estado autocertificadas. Por Simstoshi, v1.0, 2026. Cada transacción lleva consigo el estado que leyó y el estado que escribió, de modo que verificarla es una función pura de sus bytes — sin disco, sin historial, sin confianza y sin límite al paralelismo.

Cite este documento. El registro de referencia archivado y versionado es doi:10.5281/zenodo.22167490. Este sitio sirve un PDF, con una firma separada hecha con la clave del proyecto E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29. El texto de abajo es ese documento, íntegro.

1. Introducción#

Un nodo de una cadena de bloques hace hoy 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: 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.

Los diseños existentes enredan los tres. En el modelo dominante, un nodo no puede verificar una transacción sin mantener el estado global, de modo que la verificación hereda los límites de escalado del estado; y, como un único mercado de gas pone precio a los tres recursos conjuntamente, una comprobación de firma compite en la misma subasta que una escritura de almacenamiento. Las cadenas recientes de alto rendimiento paralelizan la ejecución dentro del nodo, pero cada nodo sigue reejecutándolo todo, y la restricción vinculante pasa a ser la E/S de estado. La respuesta han sido máquinas cada vez más grandes, es decir, cada vez menos nodos.

Este artículo toma el camino opuesto. No paralelizamos la ejecución contra un estado compartido; sacamos el estado del camino paralelo por completo. Una transacción pasa a ser un certificado que lleva consigo sus propias entradas y salidas. Verificarlo es una función pura de sus bytes. 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 factura a un avalista con fianza. La concurrencia no se descubre en tiempo de ejecución; la declara, slot a slot, el autor del contrato.

Las secciones siguientes definen el certificado (§2), el fold (§3), el acceso a estado tipado (§4), la economía del aval (§5), los secuenciadores de aplicación (§6), la resistencia a la censura (§7), el mercado dual de comisiones (§8), las pruebas de fraude y el camino hacia el muestreo (§9), la máquina virtual (§10), los activos nativos sin máquina (§11), los pagos confidenciales (§12), la red (§13), el lanzamiento en tres eras y su tesorería (§14) y las mediciones de la implementación de referencia (§15).

2. Certificados de transición de estado#

Un certificado es el único tipo de transacción en Zycord:

Certificate {
    reads:   [(slot, access, operand)]   // declared inputs
    writes:  [(slot, op, value)]         // declared outputs
    program: bytes                       // code or native-op reference
    sigs:    [signature]                 // spending authority
    underwriter: (id, sig, seq)          // who insures it (§5)
    ttl:     height                      // valid if committed by this height
    fee:     (seq_gas_bid, par_gas_bid)  // two markets (§8)
}

Un slot es (address, word). Un certificado es válido si pasan tres comprobaciones, ninguna de las cuales requiere estado alguno:

1. cada sig autoriza las celdas que gasta;
2. la firma del avalista está bien formada sobre (certificate, ttl);
3. reejecutar program contra los reads declarados produce exactamente los writes declarados. Las firmas deben ser canónicas, y esto es una regla de consenso y no la buena educación de una biblioteca. El id de un certificado es el hash de sus campos autorizadores — reads, writes, program, underwriter, ttl y las pujas de comisión. Las firmas no están entre ellos, y el párrafo siguiente dice por qué. El conjunto de vistos indexado por ese id es toda la defensa contra la repetición. La comisión es un campo autorizador y no una preferencia de retransmisión, y la distinción es monetaria: una puja es el firmante consintiendo un coste, así que una puja fuera del id sería una puja que cualquiera en tránsito podría reescribir — inflada para quemar el saldo del remitente vía la comisión base, o puesta a cero para mantener el certificado fuera de todo bloque. Lo que paga un certificado es parte de lo que su firmante autorizó, y el id así lo dice. Lo que compra la canonicidad es más estrecho que un id y sigue siendo una regla de consenso: un esquema que admita dos codificaciones de una firma admite dos ejemplares de un certificado, y dos implementaciones que discrepen sobre cuál de ellos verifica se han bifurcado sobre un certificado que ninguna puede declarar inválido. La regla que cierra eso es una sola frase: una codificación de firma no canónica es inválida, y una implementación cuyo verificador acepte una no es una implementación de este protocolo. Los esquemas sólidos ya rechazan tales codificaciones; la razón para dejarlo por escrito es que los que no lo hacen también son populares, y una implementación independiente que recurriera a uno de ellos divergiría de un modo que ninguna prueba propia revelaría.

Las demostraciones aleatorizadas son la excepción, y la excepción es estructural, no una cuestión de codificación. Una prueba de rango (§12) es aleatorizada: para un enunciado el probador elige nonces, de modo que un enunciado tiene una cantidad no acotada de pruebas válidas, todas canónicas, y no hay codificación no canónica que rechazar. Dos pruebas válidas de un enunciado no son dos codificaciones de una prueba; son dos pruebas, y el beneficiario — que posee la apertura — siempre puede producir una nueva. La canonicidad, por tanto, no las alcanza. Una firma es una de estas, y esto es fácil pasarlo por alto porque no es una de las exóticas. Ed25519 es una prueba de conocimiento de Schnorr: el firmante elige un nonce, y cada nonce da una firma distinta sobre el mismo mensaje, cada una válida y cada una perfectamente canónica. La derivación determinista del nonce es una regla para firmantes que ningún verificador puede comprobar y que ninguna regla de codificación puede imponer, porque todo punto de nonce es un punto codificable canónicamente como cualquier otro. Así que una autorización tiene una cantidad no acotada de firmas, y un id que las cubriera tendría una cantidad no acotada de valores — cada uno producible por cualquiera de los firmantes exigidos por el certificado, arrastrando intactas las firmas de los demás, y cada uno facturable en un bloque propio. El modelo de amenaza es más estrecho que el de una prueba y la conclusión es la misma: una prueba puede volver a aleatorizarse por un beneficiario que no posee ninguna clave, mientras que una segunda firma necesita una clave que el certificado ya exige. El id cierra la brecha por construcción: se compromete con lo que un certificado autoriza y nunca con lo que meramente demuestra, de modo que firmas y pruebas viajan por igual fuera de la preimagen del id. Volver a firmar o volver a aleatorizar da el mismo id, el conjunto de vistos detecta el duplicado, y un bloque que lleve ambos es inválido. Esto divide los campos de un certificado en dos clases — autorización, que el id cubre y las firmas firman, y evidencia, que ninguno de los dos cubre. La división no es un asunto de §12 a la espera de los pagos confidenciales; es portante desde el bloque 0, donde la única evidencia que lleva un certificado son sus firmas. Un verificador comprueba la evidencia a partir de los bytes en la etapa paralela y luego la descarta; solo la autorización sobrevive hasta el id, el conjunto de vistos y el fold.

La división crea una obligación que el id ya no lleva, y se nombra aquí en lugar de descubrirse en producción. La evidencia fuera de la preimagen del id es evidencia que cualquiera en tránsito puede sustituir: se toma un certificado, se cambia su prueba por basura y se propaga — mismo id, ejemplar ahora inválido. Dos reglas cierran los dos agujeros que esto abre. Primera, un bloque se compromete con la evidencia que lleva. La lista de certificados del bloque es una lista de hashes de ejemplar — una hoja por certificado, sobre su codificación completa, evidencia incluida — de modo que «este bloque es válido» sigue siendo una afirmación sobre bytes que el propio bloque fija. El id responde si esta autorización ya se ha facturado, el hash de ejemplar responde si estos bytes lo demuestran, y las dos preguntas nunca comparten clave. Una sola hoja basta mientras la evidencia sea inseparable de la codificación, como lo es mientras la evidencia sean firmas; cuando las pruebas de §12 la conviertan en un campo propio, la hoja pasa a ser el par (id, hash de evidencia), y el compromiso es el mismo compromiso. Lo que nunca debe llegar a ser es una lista de ids: eso no se comprometería con ninguna evidencia en particular y, dado que la raíz de la lista de certificados es un campo de la cabecera y la cabecera es la preimagen del proof of work, cambiar la evidencia no costaría entonces nada y dejaría el trabajo en pie. Este es el precedente de las transacciones con compromiso al testigo, y se sigue por la razón por la que se inventó: un id que cubría la evidencia era maleable, y un id que ignora una evidencia sin compromiso es ciego. Segunda, la retransmisión trata con ejemplares, no con ids: un nodo que recibe un ejemplar cuya evidencia no verifica descarta ese ejemplar sin perjuicio para el id — el id no se marca, no se cachea como inválido, y un ejemplar posterior que sí verifique se retransmite con normalidad. Una copia mutilada le cuesta a quien la mutiló el ancho de banda de enviarla y no le cuesta nada al certificado. La ceguera del proponente sobrevive intacta: incluye ejemplares que su propia comprobación sin estado aceptó, de modo que no se le puede inducir a incluir una prueba mutilada más de lo que se le podría inducir a incluir una firma mala, y la afirmación de §3 conserva el significado que tenía.

La validez es una función pura de los bytes del certificado. Cualquier máquina puede comprobarla, en un pool de hilos, en otro ordenador, en una GPU, sin base de datos, sin historial y sin sincronización. Las comprobaciones de firma se agrupan por lotes entre certificados; los certificados del mismo programa se agrupan en cargas de trabajo de instrucción única y múltiples hilos (§6); las pruebas de rango (§12) se agrupan con coste marginal logarítmico. Esta es la propiedad sobre la que se construye todo lo demás en el artículo.

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 dividimos en dos la noción clásica de validez de una transacción: válido (sin estado, paralelo, comprobable por cualquiera) y aplicable (con estado, secuencial, decidido solo por la posición en el libro mayor). La sección siguiente define el segundo predicado.

3. El libro mayor como un fold#

Un bloque contiene una cabecera, una lista ordenada de hashes 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 (§13). El proponente de un bloque no ejecuta nada y no mantiene estado de aplicación; ordena bytes cuya validez puede comprobar a partir de los propios bytes. No es del todo sin estado, y vale la pena nombrar la excepción en lugar de redondearla: debe llevar el conjunto de ids de certificados vistos dentro de la ventana del TTL, porque incluir uno dos veces invalida el bloque y a nadie se le puede inducir a eso por accidente. Ese conjunto está acotado por el TTL y es podable, y por eso el TTL es un parámetro de consenso y no una preferencia de retransmisión. La propuesta es deliberadamente barata y tonta, no deliberadamente ciega.

El estado de la cadena se define como un fold sobre los certificados ordenados:

apply_block(S, B):
    assert bodies_available(B)
    assert ∀c: height ≤ c.ttl ∧ ¬seen(c.id)     // an expired or replayed certificate
                                                 // makes the BLOCK invalid: a signature
                                                 // is billable at most once, and never at
                                                 // a position its signer could not avoid
    C ← sort(B.certs, key = (underwriter.id, underwriter.seq, c.id))
    for c in C:
        if leased(S, c):     bill(c, LEASED); mark_seen(c.id, c.ttl); continue  // §7; Era 1 only
        ok ← true
        for (slot, access, x) in c.reads:
            EXACT:  ok ← ok ∧ (S[slot] = x)
            GUARD:  ok ← ok ∧ pred_x(S[slot])
        if ¬ok:              bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        w ← stage(S, c.writes)   // a target whose address is spent, or a delta that would
                                 // over- or underflow, fails HERE — nothing has landed yet
        if w = ⊥:            bill(c, STALE);  mark_seen(c.id, c.ttl); continue
        commit(S, w); settle_fees(c); mark_seen(c.id, c.ttl)

Las escrituras se comprueban, y se comprueban antes de que aterrice ninguna de ellas. Borradores anteriores de este esbozo aplicaban el conjunto de escrituras sin condiciones, lo que se leía como si un abono pudiera resucitar una celda gastada y como si un delta pudiera desbordarse. Ni lo uno ni lo otro es cierto y ambos serían fatales, así que el paso de preparación está ahora en el esbozo en lugar de dejarse a la especificación. La aritmética se comprueba allí donde aparece: un delta que llevaría más allá de 2²⁵⁶ o por debajo de cero omite el certificado en lugar de desbordarlo, que es también por lo que los topes de suministro de §11 se sostienen bajo emisiones concurrentes ilimitadas. Una escritura a una dirección cuya autoridad ha sido quemada falla ruidosamente en lugar de desvanecerse — para eso sirve el registro permanente de gastadas, y es el origen de la única excepción al teorema de atribución de §5.

**leased es maquinaria de la Era 1 y no está presente en el génesis.** Se muestra aquí porque esta sección especifica el fold de todo el protocolo, pero la era de lanzamiento no tiene arrendamientos, ni cola forzada, ni cofirmantes a los que defender con ellos, de modo que la rama es inalcanzable en el binario del génesis — y el código de consenso inalcanzable es código de consenso inauditable, así que no se distribuye. Se señala una cuestión abierta en lugar de taparla: tal como está escrito, LEASED factura un certificado en una posición que su firmante no podría haber previsto, que es exactamente lo que prohíbe la afirmación cuatro líneas más arriba. O bien ese resultado no debe facturar, o bien debe invalidar el bloque. La elección corresponde a la era que introduce los arrendamientos, y queda registrada aquí para que esa era no pueda heredar la contradicción en silencio.

Propiedades que vale la pena enunciar explícitamente:

La omisión es semántica, no fallo. Un certificado cuyas lecturas ya no se sostienen se omite, su comisión de omisión se factura a su avalista (§5), y el bloque sigue siendo válido. La inclusión y la aplicación son eventos distintos. Esto es lo que permite que el proponente sea ciego: nunca puede producir un bloque inválido por incluir un certificado obsoleto.

Determinismo. Todo nodo deriva un estado idéntico a partir de una secuencia de bloques idéntica. La clave de ordenación (underwriter, seq, certificate id) es un orden total sobre el contenido del bloque, de modo que el fold es insensible a cómo un proponente entrelace certificados de distintos avalistas — y no le deja al proponente discrecionalidad alguna, ni siquiera entre dos certificados que un mismo avalista firmó con el mismo seq. La propia canalización de un avalista (seq ascendente) se confirma en el orden en que se firmó, sea cual sea el orden en que el proponente la envió.

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. Todo eso ya ocurrió, en paralelo, durante la comprobación de validez.

Y nada de aritmética de curva elíptica. Los pagos confidenciales (§12) meten compromisos de Pedersen en los valores de los slots, y un compromiso es un punto de curva. El esquema es homomórfico y la suma de dos compromisos tiene sentido, lo que invita al fold a sumarlos. El fold se niega. Una suma de puntos cuesta cientos de nanosegundos frente a ~1 ns de una suma u256, y una sola operación de curva elíptica en la única etapa secuencial gastaría el presupuesto que esta arquitectura protege. El fold solo almacena bytes de compromiso en celdas nuevas y los compara por igualdad — ambas operaciones de memoria; toda la aritmética de curva ocurre en la etapa paralela o en el monedero del propietario (§12). La misma disciplina rige el hashing, más abajo.

Una pieza de criptografía no queda eliminada, y afirmar lo contrario sería demasiado cómodo: el id de un certificado es un hash de sus campos autorizadores (§2), y el conjunto de vistos está indexado por ese id, así que alguien tiene que calcularlo. Lo que importa es dónde, y la respuesta es que no tiene por qué ser aquí. El id depende de los bytes del certificado y de nada más — ni estado, ni ordenación, ni posición — así que se calcula junto a las comprobaciones de firma en la etapa paralela y se lleva al fold, igual que el propio certificado. Una implementación que en su lugar lo recalcule en el bucle secuencial se encontrará con que el hashing domina una etapa que se supone que trata de memoria, lo cual es un error que vale la pena nombrar porque es fácil de cometer. Queremos ser precisos sobre qué se elimina aquí y qué no. El fold sigue realizando acceso aleatorio sobre el estado completo, un toque por slot declarado, y un nodo que confirma sigue manteniendo ese estado. Lo que abandona el camino secuencial es todo lo que rodea al acceso en una cadena convencional — interpretación, comprobaciones de firma, hashing, autenticación por operación de un almacén merkleizado — de modo que el estado puede vivir en una tabla plana y la única etapa secuencial del sistema es un bucle apretado sobre memoria. El fold de referencia sostiene 883 000 operaciones de slot por segundo y por núcleo en un escritorio x86 de diez núcleos (§15), y es la única etapa que no paraleliza.

Igualdad de valores, no versiones. La aplicabilidad compara los valores de lectura declarados, no contadores de versión. Como la ejecución es una función pura del conjunto de lecturas, un slot que cambió y volvió a cambiar a su valor anterior (el caso ABA) sigue siendo aplicable: aplicar el certificado ahora es semánticamente idéntico a haberlo ejecutado entonces. El sistema omite, por tanto, estrictamente menos a menudo que un control de concurrencia basado en versiones. Para slots cuyo valor es un compromiso, la comparación es la igualdad de bytes del compromiso: opaca, exacta e igual de barata, una vez impuestas las condiciones de canonicidad de §4.

Repetición y facturación única. El id de un certificado es el hash de lo que autoriza y nunca de las firmas que demuestran la autorización (§2), y tanto los certificados aplicados como los omitidos con cargo se marcan como vistos. La distinción es lo que convierte la regla en regla: un firmante que vuelve a firmar un mismo cuerpo con un nonce nuevo produce el mismo id, así que el conjunto de vistos detecta la copia en lugar de facturarla. Incluir un certificado ya visto o caducado invalida el bloque — de modo que una firma es facturable a lo sumo una vez, y solo en una posición que su firmante aceptó al firmar. Sin esta regla, un productor de bloques podría reincluir o retrasar deliberadamente certificados ajenos para quemar los fondos de sus avalistas. Los TTL están acotados por consenso, así que el conjunto de vistos sigue siendo podable.

4. Acceso a estado tipado#

Un fold que solo admitiera lecturas exactas serializaría todo contrato popular: mil certificados tocando un mismo fondo de un AMM darían una aplicación y 999 omisiones. La respuesta de Zycord es que la concurrencia la declara el autor del contrato, slot a slot, en el propio formato del certificado. Hay tres disciplinas de acceso:

Exacta. Al estilo de SLOAD: la lectura devuelve el valor del slot al cómputo y fija el certificado a ese valor. Lógica arbitraria; conflictos en los slots calientes; el dominio de los secuenciadores de aplicación (§6).

Delta con guarda. El certificado afirma un predicado sobre el slot — balance ≥ 10 — sin leer el valor hacia el cómputo, y escribe un delta con signo — balance += −10. El fold comprueba el predicado contra el estado actual y aplica el delta. Cualquier número de débitos y abonos con guarda sobre el 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 meramente cambió. Esta única disciplina cubre transferencias, emisiones con tope de suministro, autorizaciones de gasto y participaciones en bóvedas, es decir, la abrumadora mayoría de las escrituras en cadena.

Delta puro. Un delta con signo y sin guarda. Nunca puede entrar en conflicto y nunca se omite. Propinas, contadores, acumuladores, recuentos de recompensas.

La regla que mantiene sólido el modelo: los valores con guarda no deben fluir hacia el cómputo. Una aserción no devuelve nada; un delta no lee nada. La reejecución sigue siendo, por tanto, una función pura de las lecturas declaradas, y se preserva la validez sin estado (§2). El linaje de esta idea es antiguo y sólido: las transacciones escrow en bases de datos, el transactional boosting, los CRDT [9][10][11]. Pero las cadenas existentes, en el mejor de los casos, explotan la conmutatividad dentro del planificador de un nodo; Zycord la convierte en el contrato de concurrencia entre nodos, impuesto por el formato del certificado y con precio fijado por la economía del aval.

Una segunda regla del mismo rango, forzada por §12: ningún slot que contenga un valor oculto admite una guarda de terceros. Una guarda cuyo resultado es públicamente observable — aplicada u omitida — sobre un saldo que se supone secreto es un oráculo de saldos: se envía balance ≥ x, se observa el fold, se bisecciona, y log₂(saldo) intentos leen el número sin abrir jamás el compromiso. La solución es estructural, no estadística. El valor oculto vive solo en celdas de un solo uso gastables mediante la firma de su propietario; la disciplina de delta con guarda, cuyo sentido entero es que extraños puedan tocar un slot sin peligro, queda reservada a slots cuyos valores son públicos. Los pagos de tipo pull — autorizaciones de gasto, suscripciones, barridos de bóvedas — existen por tanto solo en el raíl transparente (§12).

Imponer esa regla exige que el fold pueda distinguir un slot oculto de uno público, y en una tabla plana no puede hacerlo por inspección: un compromiso comprimido y un saldo u256 son ambos 32 bytes. Una celda de valor oculto no es, por tanto, una celda ordinaria que resulta contener un compromiso; es una clase de celda distinta, creada solo por la operación blindada nativa (§12) y residente en una región reservada y derivable del espacio de direcciones, de modo que la disciplina de un slot es una función de su dirección y comprobable desde los bytes como todo lo demás. Sin esto, un delta con guarda dirigido — por error o por malicia — a un slot de compromiso haría que el fold sumara un u256 a la codificación de un punto de curva: las comprobaciones aritméticas pasan, el resultado no es un compromiso, y la celda se vuelve ingastable. Valor destruido en silencio, sin que nada falle en el fold, es precisamente lo que el paso de preparación de §3 existe para impedir, y la clase de celda es lo que le permite impedir también este caso.

Dos primitivas más completan el modelo:

Celdas de escritura única. Una dirección que nunca ha aparecido en cadena está en el estado ∅; una primera escritura la mueve a almacenada; una firma de su clave la mueve a gastada, de forma permanente. Escribir en una celda nueva está libre de conflictos por definición, así que pagar a una dirección recién derivada es el camino rápido sin contención. Esta es la herencia quimérica de la red [8]: celdas persistentes al estilo de cuentas para los contratos, celdas de un solo uso al estilo UTXO para los pagos, en un mismo libro mayor. Los valores bajo una celda gastada son compactables una vez que el bloque que la gastó queda enterrado más allá del horizonte de reorganización — una profundidad en confirmaciones, no un mecanismo de finalidad, ya que la era de lanzamiento no tiene finalidad que esperar. La entrada del registro que anota la dirección como gastada no se compacta nunca: es lo que impide que la dirección resucite, y es el problema abierto honesto del protocolo, compartido con todo diseño de conjunto de anuladores. Las salidas sigilosas de §12 circulan por este raíl sin cambios, y hacen crecer el registro exactamente al ritmo al que ya lo hacen los pagos transparentes: una entrada por gasto, oculto o no.

El cero es ausencia. Un slot que nunca se ha escrito y un slot escrito a cero son el mismo slot: escribir cero borra la celda, y leer una celda ausente da cero. Esto no es una comodidad de implementación sino un requisito de consenso, y es portante por partida doble. Es lo que permite que una guarda o una lectura exacta nombren 0 sin preguntar si el slot existe — no hay una tercera respuesta que desambiguar. Y es lo que mantiene la raíz de estado como función del estado y no del historial que lo produjo: si una celda vaciada perdurara como un cero explícito, dos nodos que hubieran llegado a saldos idénticos por rutas distintas se comprometerían con raíces distintas, lo que es una división de la cadena llegada por contabilidad.

Esto restringe §12, con un filo afilado. Un compromiso de Pedersen vG + rH no es en general la cadena cero, así que un saldo oculto no pasa a ser ausente por aritmética y nadie salvo el propietario puede saber que está vacío; los slots ocultos persistentes serían incompactables para siempre, que es una razón más por la que el raíl blindado son solo celdas de un solo uso, que mueren al ser gastadas — una transición que el cero-es-ausencia nunca necesitó proporcionar. El filo es que v = 0, r = 0 es el elemento neutro del grupo, y en una codificación Ristretto el elemento neutro son treinta y dos bytes cero — precisamente la cadena que significa ausente. Un compromiso nunca debe colisionar con el borrado, de modo que el elemento neutro no es un compromiso válido: la operación blindada lo rechaza a la entrada, junto a las comprobaciones de codificación canónica que un punto de curva ya necesita (elementos de cuerpo no canónicos, componentes de torsión), y la H de referencia es un punto NUMS con una derivación publicada. «La igualdad de bytes es exacta» (§3) es una afirmación sobre puntos solo una vez que esto se cumple.

La baliza de época. Los programas no deben leer valores ambientales (marca de tiempo, altura) directamente; eso haría que la ejecución fuera función de algo distinto de las lecturas declaradas. En su lugar, el protocolo escribe una baliza de época en un slot reservado una vez por época, y los programas la leen como cualquier otro slot, idealmente con una guarda de rango (epoch ∈ [e, e+2]), lo que proporciona conciencia del tiempo sin obsolescencia por bloque.

5. Certificados avalados: todo conflicto tiene dueño#

La omisión no debe ser gratuita, o la mempool se ahoga: un atacante podría publicar miles de certificados válidos contra la misma entrada, llenar bloques y pagar por uno. Pero los certificados omitidos nunca tocaron el saldo del remitente, así que no hay nada que cobrarle al remitente; el slot de la comisión es exactamente la entrada obsoleta. La respuesta de Zycord: ningún certificado existe sin un avalista, una parte cuyos fondos con fianza responden por él.

Hay tres maneras de estar avalado, un mecanismo bajo tres apariencias:

1. Autoavalado. El remitente adjunta un pequeño depósito desde una celda libre de cargas. Nada se arrienda por adelantado: el fold reserva el depósito en la posición del certificado dentro del bloque (el esbozo de §3 omite esta fontanería), y un certificado que llega a la aplicación con su depósito ya consumido se descarta — no se factura, no se marca como visto, y puede reenviarse libremente contra un depósito nuevo — de modo que los usuarios honestos no pierden nada por carreras sobre su propia celda de depósito. Una omisión con el depósito intacto quema parte de él. Publicar, en cambio, no cuesta nada, así que la mempool está acotada por la política de retransmisión y no por el consenso: los nodos limitan cuánto guardan por avalista, la misma división del trabajo que toda mempool desde la de Bitcoin. Este es el suelo sin permisos: cualquiera puede transaccionar siempre sin contraparte. Es también el único modo en la era de lanzamiento (§14), lo que mantiene mínimo el génesis. La celda de depósito es pública y es del remitente, lo que convierte el autoaval en un identificador persistente grapado a todo certificado que firma. Para los pagos transparentes eso no revela nada que el pago no revele ya; para un pago blindado (§12) deshace la salida sigilosa que paga, y §12 recurre a la cofirma exactamente por esta razón.
2. Cofirmado. Un avalista con fianza comprueba el certificado contra estado fresco, cofirma (certificate, ttl, seq) y asume la responsabilidad por omisión. A cambio puede cobrarle al remitente fuera de banda, y su cofirma es un producto: una preconfirmación respaldada por el capital propio del avalista. Nada en este papel exige ver qué mueve un certificado: la obsolescencia es una propiedad de las celdas — vivas o gastadas — y no de los importes, así que un avalista pone precio a un certificado blindado igual que a uno transparente, sin que se le confíe el valor.

Dos cosas que esa promesa no debe difuminar, porque el artículo ya las ha difuminado antes. La respuesta del protocolo ante una omisión es quemar la comisión de omisión con cargo al depósito del avalista — una penalización, pagada a nadie, que es lo que impide que alguien saque provecho de provocar omisiones. Compensar al remitente es otra transacción distinta: es la promesa comercial del avalista, y este diseño todavía no la especifica como mecanismo de consenso. Convertirla en tal no es cuestión de redacción — necesita un valor de póliza declarado en la cofirma, un beneficiario nombrado que no sea el remitente (o el producto es una invitación al fraude de seguros) y la exposición agregada registrada en cadena para que una fianza no pueda venderse dos veces. Hasta que eso exista, «mi fianza paga» es una afirmación que hace un avalista y a la que un mercado pone precio, no una regla que el fold imponga, y el artículo lo dice en lugar de dejar que la ambigüedad venda el producto.

1. Forzado. El camino de la resistencia a la censura (§7), avalado por un depósito del usuario y, de forma única, con garantía de aplicarse. La economía es asimétrica entre dos clases de mala conducta, y la asimetría es la clave:

Las faltas objetivas se penalizan. Si un mismo avalista cofirma dos certificados cuyas lecturas exactas entran en conflicto (mismo slot, mismo valor declarado, TTL solapados), las dos firmas son una prueba autocontenida y en cadena de equivocación; cualquiera puede presentarlas, y la fianza se penaliza. Del mismo modo, un avalista que cofirme un certificado que no supera la validez sin estado (una firma mala, una ejecución incorrecta) es penalizado por pura reejecución: el certificado es la prueba de fraude (§9).

Las faltas subjetivas no se penalizan nunca. Dos avalistas distintos compitiendo por el mismo slot no han cometido ninguna falta demostrable; el que queda después en el orden del fold se come una pequeña comisión de omisión, nada más. Los avalistas lentos, desconectados o poco fiables pierden elegibilidad y reputación, no fondos. Las redes mueren cuando la latencia se convierte en confiscación; Zycord solo confisca lo que puede demostrarse a partir de los bytes.

Y la factura recae en una parte que el certificado nombra. El título de esta sección es un teorema y no un eslogan, y vale la pena enunciarlo con sus aristas. Una omisión facturada es siempre exactamente una de tres cosas: la lectura o escritura que falla está bajo una dirección cuya clave firmó el certificado; o es una emisión compitiendo con otra emisión del emisor declarado del mismo activo, que también firmó; o es un abono a una dirección de un solo uso cuyo propio titular la retiró (RETIRE, §11) después de firmarse el certificado. Ninguna parte que el certificado no nombre puede provocar que se le facture. Solo el tercer caso separa la factura de la causa, y está acotado por construcción: solo las celdas de un solo uso pueden retirarse, de modo que un beneficiario que publica una dirección persistente no presenta superficie alguna; un certificado puede retirar como mucho un número fijo de direcciones (§13), lo que limita cuántos pagos en vuelo puede tocar una ráfaga de retiradas; y la comisión de omisión se quema en lugar de pagarse, así que nadie saca provecho de provocarla.

El dimensionado de la fianza se sigue de una desigualdad: la fianza de un avalista debe superar la responsabilidad máxima por omisión que puede acumular dentro de una ventana de TTL, y la retirada de la fianza debe tardar más que la ventana de prueba de fraude, para que nadie pueda portarse mal, retirar y desaparecer.

6. Secuenciadores de aplicación#

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 fondo de un AMM — donde dos avalistas honestos compitiendo seguirán produciendo omisiones. La respuesta del protocolo es dejar que el contrato elija su serializador: un contrato puede registrar, en cadena, la clave de un secuenciador con fianza, tras lo cual solo los certificados cofirmados por ese secuenciador pueden tomar el camino de lectura exacta del contrato.

El secuenciador es un servidor ordinario operado por el equipo de la aplicación — websockets, colas, autoescalado, cualquier maquinaria de la web 2 — y se confía en él para la disponibilidad únicamente, nunca para la seguridad. No puede falsificar estado: si miente sobre las entradas durante la construcción, el certificado simplemente se omite frente al fold canónico, y la mentira le cuesta su fianza. Lo que sí aporta:

Serialización. Arrienda slots a los certificados en vuelo con TTL cortos y encadena cada certificado sobre las salidas declaradas del anterior (numera sus cofirmas con seq; el orden total del fold garantiza que su canalización se confirme en orden, sin importar cómo baraje el proponente). La contención de slots calientes se convierte en un problema de planificación fuera de cadena, invisible para la cadena.

Certificados por lotes. N transacciones que pasan por el mismo camino de código se pliegan en un solo certificado con lecturas/escrituras agregadas, las escrituras intermedias internas se cortocircuitan, y N subejecuciones que verifican como una única carga de trabajo SIMT. Aquí es donde la tesis de la GPU se concreta: la entidad que serializa es también la entidad que empaqueta el trabajo con la forma que quiere el hardware paralelo, y se le paga por hacerlo a través del mercado de gas paralelo (§8).

Componibilidad atómica. Una transacción que abarca dos aplicaciones la construyen conjuntamente fuera de cadena ambos secuenciadores (una confirmación en dos fases sobre arrendamientos de slots) y aterriza en cadena como un solo certificado con ambas cofirmas, atómico por construcción. La coordinación entre aplicaciones ocurre donde coordinar es barato; la cadena solo ve el resultado.

La revelación honesta: un secuenciador ve primero el flujo de órdenes de su aplicación y es, por tanto, el escenario natural del MEV de esa aplicación. Zycord hace explícito el intercambio: la aplicación captura su propio MEV en lugar de filtrarlo a los proponentes de bloques, y §7 acota el poder que eso implica. El mismo camino forzado que garantiza la salida disciplina también la extracción: un usuario a quien no le guste el trato de un secuenciador puede rodearlo por completo, pagando solo latencia.

7. Inclusión forzada con aplicación garantizada#

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

Un usuario (o cualquier retransmisor) reconstruye el estado a partir del fold público, construye un certificado, le adjunta un depósito y lo envía a la cola forzada. Los proponentes deben incluir los certificados en cola dentro de F bloques (§13). En su posición de inclusión, el fold comprueba sus lecturas contra el estado actual; si se sostienen, el fold concede un arrendamiento determinista sobre sus slots y programa la aplicación D bloques más adelante. Durante el arrendamiento, los certificados cofirmados que toquen esos slots se ordenan después de él. El certificado forzado, por tanto, no puede omitirse: la admisión implica la aplicación.

El periodo de gracia D es para la canalización en vuelo del secuenciador honesto — la parte de ella que no toca los slots arrendados. Todo lo que sí los toque se ordena después del certificado forzado, tanto lo cofirmado como lo autoavalado, que es lo que hace que «no puede omitirse» sea cierto y no una aspiración: un certificado cuyas lecturas están protegidas durante todo el periodo de gracia no puede quedar obsoleto durante él. Como las escrituras están declaradas, el estado posterior a la aplicación es predecible, de modo que un secuenciador encadena sobre un certificado forzado aún no aplicado con total certeza.

Un arrendamiento solo puede cubrir slots sobre los que el certificado tiene autoridad. Esta es una restricción que el mecanismo no da gratis y sin la cual el resto del diseño no sobreviviría. Declarar una lectura no requiere firma — solo las escrituras derivan autorización — así que, sin esta regla, cualquiera podría encolar un certificado forzado que declarase lecturas sobre los slots de otra persona y congelarlos durante D bloques al precio de un depósito. La cuota por contrato tampoco lo acota, ya que los pagos nativos no pertenecen a ningún contrato. Un arrendamiento es, por tanto, admisible solo sobre slots que el certificado tiene derecho a escribir, que es la misma prueba de autoridad que el fold ya aplica, empleada un paso antes.

Otras cotas contra el hostigamiento: una cuota por contrato y por época; un depósito que cubra el coste impuesto; los slots arrendados rechazan nuevas entradas forzadas hasta que se liberen.

Dos consecuencias elevan esto de característica a mecanismo de supervivencia. Primera, la censura se invierte: le cuesta al censor (comisiones perdidas, usuarios que lo rodean) y no le cuesta nada a la red. Segunda, un contrato cuyo secuenciador desaparece — o una cadena cuya clase entera de avalistas es atacada — degrada a modo solo forzado: lento, caro y vivo. Ningún estado queda nunca huérfano, y ningún operador es portante para la seguridad. Para una red diseñada para sobrevivir a su fundador, esta es la propiedad que importa.

8. Dos mercados: gas secuencial y gas paralelo#

Una cadena consume tres recursos de clases de escalabilidad distintas — datos, verificación, mutación — y ponerles precio en un solo mercado significa que la verificación de una prueba de conocimiento cero compite en subasta con una escritura de almacenamiento. Zycord divide la comisión en dos mercados independientes:

El gas secuencial pone precio a las operaciones del fold: comprobaciones de lectura, escrituras, arrendamientos. Es el recurso escaso, el único bucle que todo nodo ejecuta en orden, y se le pone precio en consecuencia.

El gas paralelo pone precio a la verificación: comprobaciones de firma, unidades de reejecución, bytes y precompilados pesados (verificación de pruebas, agregación de firmas, esquemas poscuánticos). Es abundante, su oferta crece con cada núcleo y cada GPU que se suman a la red, y su techo por bloque se fija alto y barato.

Ambos mercados tienen la forma de EIP-1559 [15], cada uno en su propia unidad: la comisión base se quema y la comisión de prioridad paga al productor del bloque — sobre los certificados que se aplican, y solo sobre esos. La comisión de un certificado omitido se quema por completo y no paga a nadie, y eso no es un detalle del esquema de comisiones sino la regla portante de todo el modelo económico. Si una omisión diera propina, se estaría pagando a la parte que elige qué contiene un bloque por orquestar los fracasos ajenos, y la forma más barata de ganar sería cultivar omisiones en lugar de incluir trabajo. Quemar lo invierte: una omisión consume espacio del techo y no rinde nada, de modo que un productor que maximiza ingresos está maximizando la aplicación, y no es meramente indiferente a provocar omisiones sino que está activamente en contra. Quemar la comisión base secuencial hace deflacionaria la congestión en el único bucle escaso (§14.2). Quemar la comisión base paralela mantiene al proponente indiferente ante cuáles certificados pesados llenan el carril barato, de modo que la prioridad en el carril de verificación no puede venderse por debajo de la mesa. La división sigue la dirección de los diseños de comisiones multidimensionales [18], llevada hasta mercados completamente separados. Lo que ninguno de los dos mercados decide es cuánto recurso escaso debería haber; eso es un techo, y §8.1 da la regla que lo mueve.

La consecuencia es el objetivo de diseño enunciado como invariante: la criptografía pesada no impacta a 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. Zycord queda así posicionada como la capa de liquidación donde resultan económicos los protocolos criptográficos demasiado pesados para las cadenas de un solo mercado. El mismo mercado paga a los secuenciadores por dar forma al trabajo: un secuenciador agrega N transacciones en un certificado por lotes, paga una puja paralela por él y cobra a sus usuarios por N — el margen es la comisión por dar al trabajo forma SIMT (§6).

8.1 El techo secuencial elástico#

Un mercado de comisiones pone precio a la escasez; no decide cuánta escasez debería haber. Las dos respuestas previas a esa pregunta fracasaron ambas, en direcciones opuestas. Un techo fijo convierte la adopción en una subasta que los usuarios pierden: cuando los bloques de Bitcoin se llenaron, las comisiones superaron los 50 dólares y los pagos ordinarios quedaron sencillamente excluidos de la cadena por precio, en beneficio exclusivo de quien vendía el espacio. Un techo abierto sin demanda fracasa por el otro lado: sus bifurcaciones de bloques grandes compraron una capacidad que nadie usó y la pagaron en seguridad, porque lo que produce comisiones es el volumen, no el espacio. El techo de Zycord no es, por tanto, ni fijo ni votado — una red cuyo autor no estará ahí para bifurcarla no puede tratar el crecimiento rutinario como un evento de gobernanza, y una votación es un asidero: los mineros se benefician de restringir la oferta, y los grandes operadores de expandirla más allá de lo que los nodos pequeños pueden seguir. El techo es una función de consenso de la demanda medida, presente en el génesis desde el bloque 0, y no lo mueve nadie.

La regla tiene tres partes, una por escala temporal. Dentro de un bloque, cada mercado tiene un objetivo T y una cota elástica dura 2T; la comisión base avanza hacia el equilibrio en una fracción acotada por bloque, con la forma de EIP-1559 de §8 — acotada porque se sabe que el ajuste no acotado oscila en lugar de converger. Entre épocas, el objetivo secuencial sigue a la demanda: T ← clamp(2·median_applied(e), T − T/Δ, T + T/Γ), con suelo en su valor del génesis — donde median_applied cuenta el gas secuencial únicamente de los certificados aplicados. Los certificados omitidos queman sus comisiones y no registran nada, así que la única forma de subir el techo es lograr la aplicación: 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, es decir, el mecanismo no puede distinguirlos y no necesita hacerlo. El crecimiento está además condicionado a una señal de salud de la época — la tasa observada de cabeceras en competencia se mantiene por debajo de un umbral (Era 0), los puntos de control se finalizan según lo previsto (a partir de la Era 1) — de modo que la capacidad nunca adelanta a lo que la propagación transporta de forma demostrable. Un bloque huérfano es precisamente el evento que la cadena no registra, así que la señal se importa de la única manera honesta: las cabeceras pueden citar cabeceras recientes en competencia, sin pago; citar requiere proof of work real, mientras que suprimir la señal requiere que casi todos los proponentes omitan citas que cualquier proponente honesto restaura por sí solo. La asimetría inclina la compuerta hacia la cautela, que es la dirección en la que debe inclinarse una compuerta. Por bloque, una válvula de ráfaga: un proponente puede superar 2T hasta 4T, perdiendo cuadráticamente lo que el bloque le acredita — su parte del subsidio más las comisiones del bloque, frente al calendario de §14.2, como un déficit permanente que no se redirige a nadie — con la penalización calculada sobre el gas secuencial total, aplicado y omitido por igual, para que el exceso no pueda rellenarse con conflicto fabricado a precio de saldo. La base es el ingreso del productor y no solo su subsidio porque ambos no decaen a la vez: el subsidio cae hasta cerca del 1,6 % de su valor del génesis en la curva de §14.2, mientras que el ingreso por comisiones para el que se compra una ráfaga no cae en absoluto, de modo que un disuasorio denominado solo en subsidio deja de disuadir exactamente allí donde la oportunidad es mayor. Una propiedad permanente tiene que tener un precio en algo que siga al beneficio, que es el argumento que hace EIP-1559 para acoplar un cargo al valor que gana la manipulación. En el génesis esto casi no cambia nada, ya que las comisiones son casi nulas. La parte de la tesorería de §14.1 se toma del subsidio sin reducir y no se pierde nunca, porque la ráfaga es una elección del productor y la tesorería no es parte en ella. Los picos genuinos compran paso de inmediato e informan al controlador de época; el spam compra una penalización. El precedente es el mecanismo de mediana con penalización de Monero [19], con su bloqueo documentado — el crecimiento se congela cuando la unidad de trabajo típica se acerca a la mediana — evitado por construcción, ya que los certificados por lotes (§6) mantienen pequeña la unidad típica frente al objetivo, y las cotas de tasa siguen el linaje de los límites adaptativos [20]. El techo paralelo no necesita nada de este cuidado: está fijado como un múltiplo alto y fijo del objetivo secuencial y hereda su crecimiento, que es el invariante de §8 reformulado como capacidad.

Léase el tira y afloja a partir del mecanismo. La comisión del usuario gravita hacia el suelo, porque la congestión sostenida es, por definición, la señal que sube el techo y la vuelve a bajar — el equilibrio de subasta permanente de Bitcoin es inalcanzable. Al productor le paga el subsidio mientras la red es joven y el volumen en la madurez, nunca la escasez; la quema hace que todo episodio de congestión revierta a la moneda que el productor posee, y §8 ya hizo de la aplicación, y no de la exclusión, la estrategia que maximiza ingresos. Una honestidad, por partida doble: la elasticidad solo garantiza que la capacidad nunca sea la razón por la que se estanca la adopción — no fabrica demanda, como demostraron las bifurcaciones de bloques grandes — y un techo que crece deja crecer el estado, y por eso las escrituras a slots nuevos cuestan más en gas secuencial que los deltas: la tabla plana en la que vive el fold no se expande más rápido que el techo que la alimenta. De ahí se sigue una regla de calibración, que se enuncia porque su incumplimiento es silencioso: la razón entre el objetivo secuencial del génesis y el techo de bytes debe quedar por debajo de la densidad del tráfico para el que se construye la red, de modo que un bloque lleno de pagos ordinarios suba la comisión base en lugar de bajarla. Un mercado que responde al revés ante su propia carga de diseño no pone precio a nada, y la razón se fija a partir de tráfico medido antes del congelamiento.

Capacidad a lo largo de las eras. Los techos de número de certificados y de bytes escalan con el objetivo secuencial en lugar de quedar fijos a su lado: en el génesis los tres quedan dentro de un factor de dos entre sí, de modo que uno fijo se convierte en el límite real tras una sola duplicación y deja al elástico como adorno. Detrás de ellos están las capacidades estáticas: el ancho de la lista de certificados, que fija la profundidad merkle de un bloque, y la capacidad en bytes que un bloque puede alcanzar, junto a las constantes de transporte que hay debajo — un bloque viaja en fragmentos, así que ningún mensaje de red por sí solo acota un bloque. El ancho de la lista se dimensiona en el génesis para toda la curva (2²⁵ certificados; volver a fijarlo más tarde pondría dos anchos merkle en una misma cadena, y el relleno virtual hace que el margen sea gratuito). La capacidad en bytes se dimensiona para la red de lanzamiento y se vuelve a fijar en las fronteras entre eras — que ya son bifurcaciones duras (§14) — frente a la propagación que la compuerta de salud ha medido; nunca dentro de una era, nunca por votación. La curva a la que sirve esta escalera se sigue de Γ: el objetivo se compone como mucho 2× por año de bloques llenos y sanos, de modo que el techo del génesis de ~90 certificados aplicados por segundo (un bloque de §15 por intervalo de 30 segundos) alcanza ~11 000 por segundo en siete años de demanda sostenida, ~90 000 en diez, y en menos de catorce el ~1,1 millones por segundo que fija el ancho de lista de 2²⁵ — el único muro que ninguna era mueve y, por tanto, el final de la escalera y no un peldaño de ella. La unidad son certificados, no pagos: un certificado lleva un pago, o los N que un secuenciador agrupó en él (§6), así que cada cifra es un suelo para las transacciones y no una afirmación sobre ellas. Las condiciones son exactamente tres, cada una ya un mecanismo descrito arriba: la demanda debe sostener bloques llenos, porque el gas aplicado es la única entrada que sube T; la propagación debe mantener abierta la compuerta de salud, porque el crecimiento se retiene la época en que se cierra; y las refijaciones deben caer en las eras, porque entre ellas el muro es la capacidad en bytes. El cómputo no es una condición — el fold supera el extremo lejano de la curva en un único núcleo medido (§15), y la verificación escala con hardware que la red no posee (§2). El ancho de banda sí lo es: los cuerpos son datos de la cadena (§13) y el muestreo (§9) divide la verificación, nunca los datos, así que todo nodo transporta todos los bytes, y un productor en lo alto de la curva es de clase centro de datos solo por ancho de banda — un estado final aceptado para los productores, y para nadie más, ya que el coste por nodo de la verificación se mueve en el sentido contrario (§9). Antes de que ate el ancho de banda, ata el estado: el registro de gastadas (§4) crece una entrada por cada gasto de un solo uso, del orden de 10² terabytes al año a 10⁵ certificados por segundo, lo que convierte el problema abierto declarado en §4 de una cuestión pendiente en trabajo que la curva programa.

Constantes (génesis, ilustrativas, como en §13): divisor de crecimiento Γ = 512 por época (el techo puede como mucho duplicarse por año de bloques llenos); divisor de decaimiento Δ = 1024 (la capacidad ociosa se reduce a la mitad en ~2 años, nunca por debajo del génesis); cota de ráfaga 4T, con pérdida de la parte del subsidio del productor y de las comisiones del bloque en la cota (la parte de la tesorería de §14.1 se toma del subsidio sin reducir y no se pierde nunca, porque la ráfaga es una elección del productor y la tesorería no es parte en ella); compuerta de salud: cabeceras en competencia citadas ≤ 2 % de los bloques por época; capacidad de la lista de certificados 2²⁵ (estructural, según lo anterior); techo de bytes 2,5 MB en el génesis, escalando con el objetivo hasta una capacidad estructural en bytes de 8 MB (refijada en las eras); techo de firmas por bloque 6000 en el génesis, escalando con el objetivo, comprobado antes de verificar ninguna firma — una cota sobre la verificación, mantenida aparte del precio del gas paralelo porque un solo parámetro no puede a la vez acotar el trabajo y poner precio al mercado.

9. Pruebas de fraude instantáneas y el camino hacia el muestreo#

Como la validez es una función pura de los bytes de un certificado, un certificado inválido es su propia prueba de fraude. Cualquiera que lo reejecute puede refutarlo en un solo mensaje, de inmediato, sin estado y sin un juego interactivo de bisección. En la configuración de lanzamiento la cuestión es discutible en el mejor sentido: todo nodo verifica todo certificado antes de aceptar un bloque, así que un certificado inválido nunca sobrevive lo bastante como para necesitar una impugnación. La ventana cobra sentido una vez que la verificación se muestrea, y allí es un parámetro de propagación y no un protocolo de disputa: un puñado de bloques para que un mensaje cruce la red, con cargo al avalista que atestiguó el certificado (§5). Compárense las alternativas: los rollups optimistas necesitan disputas interactivas de una semana porque disputar requiere el estado en el paso disputado; los sistemas basados en pruebas evitan las disputas pero pagan por probadores que cuestan órdenes de magnitud más que la ejecución. Las pruebas de fraude de Zycord cuestan lo que cuesta la verificación: ~1× reejecución.

Esto abre el camino de escalado que las cadenas de reejecución no pueden tomar. La red no necesita, en principio, que todo nodo verifique todo certificado para siempre. Con las fianzas de los avalistas en su sitio, la verificación puede muestrearse: un comité seleccionado por VRF por certificado, dimensionado de modo que la probabilidad de un certificado inválido no verificado sea despreciable, con cualquier nodo completo libre de comprobar lo que quiera y un solo mensaje suficiente para penalizar. En el génesis, todo el mundo verifica todo; es barato y paralelo. El muestreo es hoja de ruta, no lanzamiento. Pero es la hoja de ruta que invierte la curva del sector: el coste por nodo cae a medida que la red crece, mientras que en el paradigma de reejecución el coste por nodo crece con el rendimiento hasta que solo quedan centros de datos.

10. La máquina: cEVM#

Zycord ejecuta una sola máquina virtual: la cEVM, un dialecto de la EVM de Ethereum [2] adaptado a los certificados. La elección es deliberada. El presupuesto de novedad del proyecto se gasta en el estado, la concurrencia y el modelo económico; la máquina debería ser lo más familiar del sistema. Solidity, sus compiladores, auditores y herramientas se trasladan sin cambios.

Diferencias respecto de la EVM estándar:

• SLOAD compila a una lectura exacta (declarada en el certificado); SSTORE, a una escritura SET.
• Los nuevos opcodes SASSERT(slot, pred) y SDELTA(slot, ±v) exponen los deltas con guarda y puros. Un SASSERT no apila nada — las guardas no devuelven valores (§4).
• TIMESTAMP y NUMBER leen el slot de la baliza de época; no hay ninguna otra entrada ambiental.
• La medición de gas es dual (§8): los opcodes de almacenamiento miden gas secuencial; el cómputo, el calldata y los precompilados miden gas paralelo.
• El formato de transacción es el certificado. Los contratos de Ethereum se portan a nivel de código fuente; no se afirma que haya compatibilidad de monederos en crudo, y no fingimos lo contrario. Un contrato portado se ejecuta en modo todo-exacto: correcto desde el primer día, serializado a través de un secuenciador si está caliente. El paralelismo es opcional slot a slot, normalmente un diff pequeño (el mapa de saldos de un token pasa de SLOAD/SSTORE a SASSERT/SDELTA en ~30 líneas). Para que la característica insignia sea visible desde el primer bloque de la era de la VM en lugar de esperar a los portados, la máquina se activa junto a una biblioteca estándar nativa — token, bote de propinas, escrow, vesting y una referencia híbrida de libro de órdenes y AMM — escrita con los deltas por delante y predesplegada en direcciones conocidas.

11. Activos sin máquina#

La era de lanzamiento necesita una economía antes de necesitar un ordenador. Por eso Zycord incorpora activos nativos como operaciones de certificado desde el bloque 0, sin VM alguna: ISSUE (crear un id de activo con un tope de suministro en una celda de escritura única), MINT (con guarda: minted + Δ ≤ cap), TRANSFER (guarda balance ≥ Δ, deltas emparejados; 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 gasta ningún opcode propio) y RETIRE (quemar una dirección sin gastarla: sin lecturas, sin valor movido, una escritura pura que marca la celda como gastada — el gasto propiamente dicho es automático dentro de TRANSFER). RETIRE se gana su sitio por partida doble. Es la primitiva de compactación y de privacidad, que permite a un beneficiario borrar una dirección de un solo uso en cuanto ha cumplido su función; y es la operación tras la única excepción al teorema de atribución de §5 — el tercer caso existe porque existe la retirada, y por eso el formato del certificado limita el número de direcciones retiradas por certificado (§13) y por eso el teorema se enuncia con esa arista y no rodeándola. El conjunto es cerrado: estas cuatro son todo el conjunto de instrucciones del génesis, cualquier otra operación — la fianza incluida — llega con el conjunto de reglas de una era posterior (§14), y el teorema de atribución de §5 se demuestra exactamente contra esta superficie.

Un creador de contenidos 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. Las culturas de propinas de cadenas anteriores vivían a merced de las API de las plataformas y murieron con ellas; aquí la propina es una primitiva del protocolo. Es también, y no por casualidad, una prueba de esfuerzo continua de la afirmación central del sistema. Los topes de suministro de la moneda nativa viven aquí, en el raíl transparente, impuestos por la aritmética comprobada de §3, y §12 los deja intactos.

12. Pagos confidenciales#

Las secciones anteriores tratan el importe de un pago como público. Esta sección añade la opción de ocultarlo, y de ocultar al destinatario tras una dirección de un solo uso, preservando las propiedades de las secciones anteriores. El diseño es más estrecho que los sistemas de los que deriva: cada restricción que sigue cierra un ataque que un diseño más general respondería con maquinaria más pesada.

Qué queda oculto y qué no. Un pago blindado oculta su importe y aplaza el vínculo con su destinatario. Seamos exactos con «aplaza»: una salida sigilosa nueva es no vinculable en el momento en que se recibe, pero, al no haber anillo, gastarla más tarde nombra la salida que se gasta, y nombrar la salida revela qué pago anterior la financió. La no vinculabilidad se sostiene hasta el primer gasto y ahí termina; es un retardo, no un borrado. Tampoco oculta el diseño la posición del remitente en el grafo: los certificados se firman, se avalan y se ordenan en público, de modo que un observador ve que hubo un pago y quién lo avaló — no el importe, y no, hasta que un gasto lo revele, cuál de las salidas de un destinatario fue a dónde. La descripción honesta es transacciones confidenciales con direcciones de destinatario de un solo uso sobre un grafo público, y el grafo desanonimiza retroactivamente a medida que se gastan las salidas. La ambigüedad del lado del remitente — firmas en anillo, pruebas de pertenencia sobre salidas históricas — queda fuera del alcance: un anillo referencia salidas de otras personas, lo que hace de la validez una función del historial, y la ausencia de estado de §2 es la propiedad a la que el protocolo no renuncia. El modelo de amenaza de Monero exige un protocolo distinto.

La salida blindada. Un pago blindado escribe una celda de escritura única nueva (§4) cuya dirección es una dirección sigilosa: el remitente deriva, a partir de la clave de visualización publicada del destinatario y de una clave efímera propia, una dirección de un solo uso que solo el destinatario puede reconocer y que solo la clave de gasto del destinatario puede firmar. El valor de la celda es un compromiso de Pedersen C = vG + rH; junto a él viajan una prueba de rango de que v ∈ [0, 2⁶⁴) y el par (v, r) cifrado con la clave de visualización del destinatario, más una etiqueta de visualización de un byte que permite a un monedero que escanea descartar pronto la mayoría de las salidas ajenas. Las primitivas son transacciones confidenciales con direccionamiento sigiloso: la mitad de RingCT que oculta importes, sin el anillo, cada una con despliegue establecido en producción.

La validez sigue siendo una función de los bytes. La comprobación de balance de un certificado blindado es la ecuación de compromisos: los compromisos de entrada declarados menos los compromisos de salida declarados igualan fee·G, con la comisión pública (véase el fondo más abajo). La ecuación, las pruebas de rango y las firmas se comprueban todas a partir únicamente de los bytes del certificado, en la etapa paralela y por lotes: la verificación de Bulletproofs se amortiza logarítmicamente en un lote, y nada de ello toca el estado. Un certificado inflacionario falsificado — uno cuyos compromisos no cuadran bajo una suposición rota o un verificador roto — sigue siendo válido o inválido puramente por sus bytes, y el fold nunca lo vuelve a comprobar; esto es la división válido/aplicable de §2 funcionando según lo diseñado, no una excepción a ella, y la regla del fondo que sigue es lo que impide que una rotura de solidez sea ilimitada. Aquí es también donde el mercado dual de comisiones (§8) deja de ser un argumento de eficiencia y pasa a ser un argumento habilitante: en una cadena con un solo mercado de gas, las transacciones confidenciales son caras porque un milisegundo de verificación de pruebas compite en la misma subasta que una escritura de almacenamiento, mientras que aquí la verificación recae por completo en par_gas — barato por diseño — y el mercado secuencial no la ve nunca.

El fold almacena bytes. En la aplicación, un pago blindado es el certificado más barato que ve el fold: su celda de salida es nueva, así que no puede entrar en conflicto (el camino rápido sin contención de §4); sus celdas de entrada están vivas o gastadas, una consulta al registro; y la escritura almacena 32 bytes de compromiso. Ninguna aritmética de curva entra en la etapa secuencial (§3). La alternativa que la regla excluye es un «slot de acumulación» persistente al que extraños abonan de forma homomórfica, que falla en tres frentes: mete la suma de curva elíptica en el bucle secuencial (§3); crea un identificador público reutilizado, la heurística de propiedad común que la dirección sigilosa pretende evitar; y un saldo persistente oculto invita a las guardas de terceros que §4 prohíbe. La acumulación ocurre en el monedero: un destinatario posee muchas salidas de un solo uso, todas reconocibles con una sola clave de visualización, y las consolida gastando varias de sus propias celdas en una celda nueva, un certificado blindado ordinario, a la cadencia que prefiera, con la baliza de época (§4) como reloj. La suma que un slot persistente mantendría en cadena la mantiene el propietario fuera de cadena — y la consolidación no está libre de rastro: declarar varias entradas en un mismo certificado es un evento público de propiedad común, más débil que un identificador reutilizado pero real, de modo que la política del monedero es minimizarlo y no mezclar nunca orígenes no relacionados en una misma consolidación.

Gastos solo por el propietario, y qué prohíbe eso. Un valor oculto solo es gastable mediante la firma de su propietario sobre su propia celda. No hay guardas de terceros contra saldos ocultos (§4) y, por tanto, no hay pagos de tipo pull en el raíl blindado: ni autorizaciones de gasto, ni suscripciones, ni bóvedas que barran los fondos blindados de un usuario. Esos patrones permanecen en el raíl transparente, y la frontera entre los raíles tiene el ancho de un certificado. La restricción elimina el oráculo de saldos: si ningún extraño puede enviar una conjetura contra un saldo y leer la omisión, el oráculo no tiene operador.

El fondo blindado es un entero público que el fold impone. Las comisiones son públicas. El coinbase es público. Los pagos a slots de contratos son públicos. Todo cruce entre los raíles transparente y blindado mueve un v públicamente visible — un certificado de blindaje abre v a la entrada, y uno de desblindaje abre v a la salida. El total del fondo vive, por tanto, en un slot reservado, en claro, movido solo por delta con guarda (§4): blindar lo abona, pool += v; desblindar pone la guarda pool ≥ v y lo carga, pool += −v; la comisión de un certificado blindado lo carga igualmente. El slot es exactamente Σ entradas − Σ salidas, y la disciplina de delta con guarda permite que cruces ilimitados conmuten sin contención.

Esto hace del fondo una valla, no una alarma. Ocultar importes cambia la aritmética u256 comprobada de §3 por la solidez computacional de una suposición de logaritmo discreto, y una rotura — de la suposición o, mucho más plausiblemente, de un verificador — falsifica compromisos dentro del fondo. Pero un compromiso falsificado no lleva texto en claro, y el valor solo sale del fondo desblindándose, lo que carga el slot público bajo su guarda. El slot solo subió con blindajes reales, así que un desblindaje que lo llevaría por debajo de cero se omite: el valor falsificado no puede cruzar la guarda. La inflación no vacía el fondo; no consigue salir de él. El radio de acción de un fallo criptográfico queda acotado, por una regla del fold y no por la vigilancia de un auditor, al contenido real del fondo, y el modo de fallo no es un vaciado silencioso sino una carrera visible y en tiempo real en la que los últimos tenedores honestos en desblindar no pueden hacerlo — malo, acotado y observable, que es la contención que un sistema sin equipo de respuesta a emergencias debe tener por construcción. El precedente es concreto: el fallo de falsificación de Zcash Sprout fue sobrevivible porque su fondo blindado era una cantidad acotada y auditable; aquí esa cantidad no es meramente auditable sino portante dentro del fold. Los topes de suministro nativos de §11 viven en el raíl transparente y siguen impuestos por aritmética comprobada, intactos.

El fondo tiene un coste de privacidad, y merece constar: los cruces de frontera exponen importes públicos exactos, y los importes distintivos correlacionan. Un observador que vea salir v del fondo poco después de que entrara v + fee ha aprendido algo que ningún compromiso ocultó. Las denominaciones estándar en la frontera mitigan esto, y los monederos las usan por defecto; el protocolo no las impone, porque una regla de consenso no puede distinguir un importe distintivo de uno legítimo. La vinculabilidad bajo análisis de tráfico se enuncia, con su mitigación, en lugar de negarse.

El avalista es metadato, y la privacidad y la resistencia a la censura no coexisten en un mismo certificado. Un certificado blindado autoavalado nombra la celda de depósito pública del remitente, lo que vuelve a vincular lo que la dirección sigilosa desvinculó (§5); el tráfico blindado circula por ello con aval cofirmado, donde el id de un avalista agrega a muchos remitentes y la multitud es la cobertura. El avalista pone precio a la vigencia de las celdas, no a los valores (§5), así que no llega a conocer el importe — pero conoce todo lo demás que el certificado es: el remitente al que debe cobrar fuera de banda y, por tanto, identificar, las celdas que se gastan, las salidas sigilosas que se crean y el momento. Eso es precisamente lo que quiere una citación judicial, y con la desanonimización retroactiva de más arriba se compone hacia delante a través del grafo público. Es también un punto estructural de KYC, porque el único modo privado tiene un operador conocible. Esto expone una limitación que el artículo enuncia sin rodeos en lugar de taparla: los dos modos de aval son el cofirmado (privado, pero con permiso — un avalista puede rechazarte) y el autoavalado o forzado (sin permiso, pero autoidentificativo). El camino forzado de §7 garantiza que un usuario censurado siempre pueda transaccionar; no garantiza que pueda transaccionar en privado. Un usuario rechazado por todos los avalistas conserva el derecho a gastar y pierde la privacidad en el mismo movimiento — y ese es exactamente el usuario para quien la privacidad importaba. El raíl blindado hereda la resistencia a la censura de §7 solo a costa de su propia privacidad; las dos propiedades no se sostienen en un mismo certificado.

Una era, no el génesis. Dos argumentos independientes fijan el calendario. En la práctica, los certificados blindados usan avalistas cofirmantes, que existen a partir de la Era 1. Por el principio de §3, el código de consenso inalcanzable es código de consenso inauditable y no se distribuye: el binario del génesis no contiene compromisos, ni verificador de pruebas de rango, ni slot del fondo — nada cuyo único invocador sea una era futura. La era blindada no es puramente aditiva, y el artículo lo dice: el tipado de celdas ocultas y la prohibición de guardas de terceros de §4 tocan el camino de guardas del fold, que es superficie crítica del génesis, así que la era modifica además de añadir, y su activación es una bifurcación dura auditada como el cambio crítico para el consenso que es. Una era que no demuestre valer su complejidad sencillamente no se activa nunca, y la cadena del génesis no ha perdido nada por no contenerla.

Costes, dichos sin rodeos. Un certificado blindado ocupa de 3 a 5 veces el tamaño de uno transparente — uno o dos kilobytes, dominados por la prueba de rango incluso tras la agregación por lotes — que el bloque dinámico (§8) absorbe económicamente y que la diseminación de §13 paga en ancho de banda. Los destinatarios descubren los pagos escaneando: cada nueva salida blindada se prueba contra la clave de visualización del monedero, un coste O(n) en el volumen de la red que las etiquetas de visualización reducen mediante un rechazo temprano sobre un byte, un factor constante acotado por la derivación del secreto compartido que lo precede. El escaneo es la principal carga de experiencia de usuario del raíl blindado; el escaneo delegado que no entrega la clave de visualización es un problema abierto que este diseño hereda en lugar de resolver. La política de retransmisión también debe cambiar en este raíl, y no de forma opcional: publicar un certificado es gratis (§5, §13) mientras que verificar un Bulletproof no lo es, de modo que un retransmisor que ejecute el verificador antes de imponer coste alguno al publicador es un amplificador de denegación de servicio — el raíl blindado exige una retransmisión que compruebe lo barato antes que lo caro (primero la firma y la vigencia declarada, la prueba al final, con cuota por avalista), lo que convierte el «acotada por la política de retransmisión» de la mempool de un valor por defecto en un requisito.

Cuestiones abiertas que esta sección deja a un borrador posterior, señaladas en lugar de enterradas. Si el raíl blindado lleva solo la moneda nativa o también los activos de §11: un único generador H hace que vG + rH se comprometa con un escalar y no con un par (activo, valor), de modo que un raíl blindado multiactivo necesita generadores por activo (Confidential Assets), lo que cambia el tamaño de las pruebas y la cifra de «3 a 5×» de más arriba; hasta que se decida, el raíl es solo de moneda nativa por regla, no por omisión. Si RETIRE (§11) actúa sobre celdas blindadas: si lo hace, el valor puede salir del fondo sin un desblindaje público, de modo que el slot del fondo pasa a ser una cota superior (Σ entradas − Σ salidas ≥ contenido) y la dirección de la detección de inflación debe reformularse como una desigualdad; si no lo hace, el raíl blindado pierde su recolector de basura y se acumulan salidas que no pueden abrirse (véase más abajo). Si el (v, r) cifrado vive en el cuerpo del certificado (barato ahora, irrecuperable si los cuerpos se podan, lo que echa por tierra la restauración del monedero solo con la semilla) o en el valor de la celda (cuesta estado por salida, desaparece cuando la celda se gasta y encaja con «la acumulación ocurre en el monedero»). Y si un avalista puede afianzar a un tercero cobrando dentro del certificado en valor público, lo que eliminaría el requisito de identidad de más arriba y es la vía más prometedora para superar la limitación privacidad/censura — estas son cuestiones de diseño, no de redacción, y se nombran aquí para que el próximo borrador no pueda heredarlas en silencio.

13. 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; el estado es, por tanto, siempre reconstruible solo a partir de la cadena, y ningún operador — el secuenciador incluido — es nunca custodio de datos. Los certificados son mayores que las transacciones clásicas (llevan lecturas y escrituras), y las mitigaciones son estructurales: los certificados por lotes cortocircuitan las escrituras internas (§6), y las celdas de un solo uso gastadas se compactan una vez enterradas más allá del horizonte de reorganización (§4).

Una tercera mitigación es prospectiva y se nombra como tal en lugar de darse por supuesta: una lectura podría referenciar la escritura de un certificado anterior mediante (cert_id, index) en vez de repetir el valor — el truco de los UTXO. No forma parte del protocolo aquí descrito, y no pasará a formar parte de él hasta que una pregunta tenga respuesta, porque la pregunta es de consenso y no de codificación: a qué se resuelve una referencia cuando el certificado que nombra fue omitido, o nunca llegó a incluirse. Una referencia que se resuelve en silencio al valor actual ya no es una lectura declarada, y con ella muere la validez sin estado; una que falla se lleva por delante certificados cuya propia autorización nunca estuvo en duda. Una compresión que cuesta la propiedad sobre la que descansa todo el diseño no es una compresión que valga la pena tener, así que el campo está ausente hasta que la semántica quede resuelta.

La retransmisión va primero por hash. Los certificados se difunden de forma independiente y se les comprueba la validez (sin estado, en paralelo) al llegar; los bloques se retransmiten como cabeceras más listas de hashes contra la mempool, al estilo de los bloques compactos [13], de modo que la latencia de propagación no escala con el contenido del bloque. Un nodo de retransmisión no necesita estado alguno para filtrar el spam por completo — la validez sin estado más la firma del avalista son comprobables a partir de los bytes, lo que hace que operar infraestructura de retransmisión sea casi gratis en el raíl transparente. El raíl blindado (§12) es la excepción con precio: su comprobación sin estado incluye una verificación de prueba de rango que cuesta tres órdenes de magnitud más que una firma, así que allí el valor por defecto de publicar gratis se convierte en un amplificador, y la retransmisión queda sujeta a la disciplina de comprobar lo barato antes que lo caro y a las cuotas por avalista que §12 convierte en requisito y no en preferencia. La retransmisión de un raíl es casi gratis; la del otro es barata solo porque su política es obligatoria.

Parámetros (génesis, ilustrativos). Bloques de 30 segundos; TTL de certificado por defecto 240 bloques (~2 h); direcciones retiradas por certificado ≤ 64; época de 2880 bloques (~1 día); retardo de aplicación forzada D = 4 bloques; cota de inclusión forzada F = 16 bloques; ventana de participación para activar era K = 14 épocas (~2 semanas); parte de la tesorería 300 puntos básicos (3 %) del subsidio de bloque desde el bloque 0, celda sellada hasta la Era 2 y después 3 de 5 sobre un conjunto de claves fijado por bifurcación dura, retardo de rotación de claves R = 20 160 bloques (~7 días) (§14.1); constantes de emisión en §14.2.

14. Lanzamiento: tres eras, cero premine#

Zycord se lanza sin premine, sin asignación al fundador, sin ronda de inversores y sin claves de administración. El génesis es reproducible a partir de fuentes publicadas. Primero se ejecuta una testnet; solo cuando es estable se anuncia una fecha de mainnet, en abierto y con antelación, de modo que el bloque 0 sea alcanzable por cualquiera que lo desee. Lo que se impone al autor es la ausencia de privilegio, y eso es comprobable línea a línea en el génesis. Las actualizaciones ocurren por consenso social y bifurcación dura.

Este artículo es el argumento. Las reglas son la especificación de la arquitectura, los vectores de referencia son el protocolo, y cuando dos cualesquiera de ellos discrepan gana el más preciso y la discrepancia es un error. Junto a ellos se publica el registro de este diseño siendo atacado — sucesivas lecturas adversarias, los hallazgos que produjeron, los que cambiaron las reglas y los que fueron rebatidos y por qué. Ese registro se publica íntegro y sin editar, incluidas las revisiones que encontraron defectos reales y los instrumentos que informaron de éxito mientras no medían nada. Para un proyecto cuyo autor no lo avalará en persona, un diseño sin historial visible de haber sido atacado se lee como un diseño que nadie atacó, y no hay forma de recuperar lo que ocultarlo costaría.

«Sin editar» es una promesa sobre los hallazgos, y vale la pena decir exactamente qué cubre, porque el registro se republica como archivos y no como un repositorio vivo. Todo hallazgo, toda medición, todo argumento y toda alternativa descartada sobreviven tal como se escribieron, incluidos los que estaban equivocados y los instrumentos que informaron de éxito mientras no medían nada; nada se adelgaza, se suaviza, se fusiona ni se descarta. Se hacen dos clases de cambios y solo dos. La primera es la redacción de identidades — nombres, alias, direcciones, nombres de máquina y rutas locales, que no dicen nada sobre el diseño. La segunda es la autocontención: un puntero a un gestor de incidencias o a un historial de commits que el árbol publicado no contiene se sustituye por el razonamiento que representaba, enunciado en línea. Un lector que solo tenga estos archivos puede así seguir cada afirmación, que es para lo que servía la promesa; un puntero que no resuelve a nada respetaría la letra de «sin editar» y perdería todo su propósito.

El proof of stake no puede lanzarse de forma justa — la participación inicial tiene que venir de algún sitio, y toda vía clásica (venta, premine, asignación) o bien concentra la red o bien identifica a su autor. El proof of work se emplea, por tanto, como mecanismo de distribución con fecha de caducidad, no como consenso permanente:

Notas de diseño sobre la transición. La Era 0 es deliberadamente diminuta. Al no haber claves de administración no hay botón de pausa, así que cada línea del génesis es una línea que puede matar la red sin remedio; el fold (§3) más las operaciones nativas (§11) son toda la superficie crítica para la seguridad (lo bastante pequeña como para que este artículo contenga su especificación completa), y se distribuyen auditadas y simuladas de forma adversaria. La minería con CPU (RandomX) encaja con el perfil demográfico: minar en el portátil que ya se tiene. También invita a las botnets; toda moneda minable con CPU ha luchado contra ellas, y no esperamos ser la excepción. Aceptamos ese intercambio con los ojos abiertos: una distribución sesgada por botnets sigue siendo más amplia que una decidida en una venta, y mantener competitivo el hardware honesto de consumo es todo el propósito de diseño de RandomX [14]. La cofirma está viva desde el momento en que los avalistas pueden registrarse; la finalidad por puntos de control no lo está hasta que la participación se sostenga, y nombramos la brecha en lugar de ocultarla: la fianza pone precio a las omisiones, nunca a las reorganizaciones, así que ninguna regla del protocolo impide que un avalista venda preconfirmaciones en esa brecha — lo que ninguna regla puede hacer es que la venta sea honesta. «Se aplica en segundos o paga mi fianza» solo es avalable una vez que las reorganizaciones profundas están descartadas, de modo que el producto de preconfirmación asegurada sigue a la finalidad como honestidad de mercado y no como ley del protocolo. A los atestiguadores se les paga con emisión desde el momento en que se activa la superposición — ambas transiciones híbridas previas hicieron esto (Decred paga a los votantes de PoS una parte de cada recompensa de bloque [17]; los validadores de la beacon chain de Ethereum ganaron emisión durante dos años antes de proponer bloques en mainnet) — y el reparto 77/20/3, favorable al productor, se limita a la fase de distribución, ya que ese mismo precedente muestra que un reparto favorable al minero es el estado permanente equivocado: el descenso lo retira. La Era 1 divide su disparador, y la división es portante: el conjunto de instrucciones se activa por altura — primero BOND, después el registro de avalistas y secuenciadores y la cEVM, dos alturas que los parámetros del génesis mantienen distintas y ordenadas — mientras que la superposición de finalidad solo se activa una vez que la participación afianzada ≥ 1 % del suministro se ha sostenido durante K épocas, porque la participación no puede medirse antes de que exista la operación que la crea. La Era 2 mantiene un disparador doble (altura y participación sostenida), de modo que la red ni transiciona con una participación trivial ni permite que los mineros establecidos la bloqueen para siempre; las alturas son umbrales, no fechas, y no se promete calendario alguno. Una salvedad que enunciamos en lugar de enterrar: en el suelo de activación del 1 %, bloquear la finalidad requiere un tercio de eso (0,33 % del suministro), así que la finalidad sobre la que descansan las primeras preconfirmaciones aseguradas es ella misma joven. El requisito de sostener K épocas eleva el listón con el tiempo, la fuga por inactividad hace caro mantener un bloqueo, y se espera que los avalistas pongan precio a una finalidad joven en pólizas jóvenes; la seguridad más profunda llega con una participación más profunda, no por declaración. La Era 1 es la cadena en la sombra: el conjunto de validadores finaliza en producción durante toda la era — fianzas reales, penalizaciones reales — antes de proponer un solo bloque, la propiedad que hizo segura la única transición PoW→PoS exitosa a escala. Es también un estado de reposo, no un pasillo: si la participación nunca sostiene el umbral de la Era 2, la red sigue siendo un híbrido funcional indefinidamente. El descenso gradual de la recompensa, en lugar de un precipicio, le niega su momento a un movimiento de bifurcación por parte de los mineros, y el descenso es abortable: si los puntos de control no logran finalizarse durante dos épocas consecutivas, se pausa en su nivel actual hasta que la finalidad se reanude. Los mineros no pueden comprar la pausa: bloquear la finalidad requiere un tercio de la participación afianzada, que la fuga por inactividad va desangrando hasta que la finalidad vuelve, así que el ataque cuesta más de lo que paga la recompensa pausada. Los mineros de la Era 0 que afiancen su coinbase reciben prioridad — no monedas adicionales — en las primeras rotaciones de secuenciadores, lo que convierte a la comunidad minera en la comunidad de operadores en lugar de descartarla.

El disparador de la era blindada tiene deliberadamente una forma distinta de los demás. Las alturas y los umbrales de participación son hechos que un nodo mide; que un verificador criptográfico esté listo no lo es, así que el disparador es en su lugar una lista de comprobación que una bifurcación dura debe poder citar: auditorías publicadas, épocas de testnet servidas, vectores en el artefacto. La forma importa más que los ítems. Esta red no tiene equipo de respuesta a emergencias — el fallo de falsificación de Zcash fue sobrevivible en parte porque una organización con personal publicó una corrección en días, y aquí nada puede prometer eso — así que la activación de la era está diseñada para crear a sus mantenedores en lugar de darlos por supuestos: una comunidad que no puede producir dos auditorías independientes ni dotar de personal una testnet adversaria es una comunidad que no puede mantener un verificador de consenso, y la lista de comprobación hace visible la segunda incapacidad como un fallo de la primera, antes de la activación en lugar de después de una rotura. La regla del fold de §12 acota lo que puede costar un fallo que sobreviva; la lista de comprobación acota cuán poco examinado puede estar un verificador en el momento en que empieza a costar algo. Ninguna sustituye a la otra, y la era se distribuye con ambas o no se distribuye.

El descenso es una redivisión y no una reducción: la parte que cede el proof of work la toman los proponentes de proof of stake, de modo que el calendario de subsidios de §14.2 no se ve afectado por en qué punto de su transición esté la red. Esto es lo que permite que el calendario siga siendo una función pura de la altura, computable por cualquier nodo a partir de cuatro constantes sin consultar el libro mayor.

La transición es manejable por una razón arquitectónica que vale la pena enunciar: al fold le da igual quién ordene. Un minero de PoW ya es el proponente ciego que el diseño requiere; la Era 2 cambia de quién es la firma que hay en la cabecera y ni una sola regla de la semántica del estado. No hay ningún motor de ejecución que haya que llevar al otro lado de la frontera.

Una frontera entre eras es también donde se mueve la capacidad: la capacidad en bytes de §8.1 y las constantes de transporte que hay debajo se vuelven a fijar ahí, frente a la propagación medida en la red en marcha, de modo que el crecimiento rutinario viaja en las actualizaciones que este calendario ya contiene en lugar de convertirse en un evento de gobernanza propio.

14.1 La tesorería#

El tres por ciento de cada subsidio de bloque se abona a la celda de la tesorería; el noventa y siete por ciento paga el consenso — el productor del bloque y, a partir de la Era 1, los atestiguadores de puntos de control (§14). La parte queda fijada en el génesis, se aplica desde el bloque 0 y se aplica de forma idéntica a todos los bloques. Las comisiones no se tocan nunca (la tesorería no tiene derecho alguno sobre los mercados de §8), así que el coste recae en la emisión, repartido entre todos los tenedores en proporción a lo que poseen.

La celda está sellada hasta la Era 2. Acumula desde el bloque 0 y ninguna clave la abre antes de entonces: sin quórum en el génesis, sin dirección, sin clave del autor, sin vía de emergencia. En el bloque 0 no hay una comunidad madura que sostenga las claves. Si no llega ninguna, la celda no se abre nunca y las monedas no se emiten nunca. La regla de acumulación está en el génesis desde el primer bloque para que nunca sea un cambio; en la Era 2 no ocurre nada nuevo salvo que una regla acordada pasa a ser operativa.

Nada de esto es un premine, y la diferencia es comprobable y no retórica. Un premine es una asignación: monedas, una dirección y una clave que existen en el génesis y pertenecen a alguien. El génesis aquí no contiene ninguna de las tres cosas. Ninguna moneda de la tesorería es gastable, no se designa ninguna dirección, no existe ninguna clave y no se nombra a ninguna parte; lo que el génesis contiene es una regla, aplicada de forma idéntica a todos los bloques jamás minados, más una segunda regla sobre cómo puede algún día fijarse un quórum sobre el resultado acumulado. Que ese día llegue no lo decide el autor. Como el conjunto de claves se fija por bifurcación dura, el mecanismo de selección es el que usa todo cambio de consenso: alguien propone cinco tenedores públicamente identificados, los operadores de nodos adoptan la bifurcación que los fija o se niegan a ejecutarla, y un quórum candidato que no logre convencer a la red de ejecutar su bifurcación no tiene claves de nada. No hay votación que capturar, ni registro de contribuyentes que manipular, ni momento alguno en el que la voz del autor pese más que la de cualquier otro operador de nodo.

A partir de la Era 2, la celda solo se carga mediante un certificado que lleve tres firmas de cinco sobre un conjunto de claves fijado por bifurcación dura. Los gastos son certificados ordinarios: públicos, definitivos y contables solo a partir de la cadena. El quórum se extrae de contribuyentes activos en el momento de la apertura y públicamente identificados antes de que el conjunto surta efecto; cada clave está en manos de una parte distinta, ninguna bajo control común. Un gasto válido de 3 de 5 puede, en su lugar, nombrar cinco claves de reemplazo, efectivas tras R bloques, durante los cuales la rotación es pública y el conjunto antiguo sigue vigente: la rotación lleva el umbral de un gasto y la visibilidad de un gasto.

Las Eras 0 y 1 se financian con donaciones: propuestas públicas antes del pago, hitos y presupuesto por adelantado, desembolso contra trabajo entregado, importes no gastados devueltos al fondo. El quórum hereda esa disciplina cuando la celda se abre. Es una norma y no una regla de consenso; lo que la hace cumplir es que toda desviación es visible en el libro mayor.

La parte no caduca. Es una fracción de la emisión y no una cantidad de monedas, de modo que decae con el subsidio de §14.2 y persiste en la cola como un flujo nominal fijo; como fracción del suministro tiende a cero. Eliminarla cuesta lo que cuesta cualquier cambio de consenso: una bifurcación dura. A partir de la Era 2, el 3 de 5 es el único quórum de confianza del protocolo.

14.2 Emisión#

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

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

donde L es la época en bloques, Q el divisor de decaimiento, E₀ el subsidio del génesis y E(n) el subsidio por bloque a lo largo de la época n. Esas cuatro — L, Q, E₀, tail — son las constantes; C, el suministro previo a la cola al que suma el calendario, se deriva de ellas ejecutando la recurrencia y no es una entrada suya. Revisiones anteriores escribían la primera línea como E(0) = C / (L · Q), lo que se lee como si C fuera una constante de la que se divide el subsidio; es la forma cerrada del decaimiento geométrico infinito, y el calendario finito de más abajo no suma eso. No hay coma flotante ni tabla que equivocar, ni precipicios de halving: el escalón es lo bastante pequeño como para que ningún bloque llegue a ver uno, el mismo razonamiento que hace de la recompensa de la Era 2 un descenso gradual. Una vez que la fórmula cae por debajo de la cola, el subsidio es una cantidad fija por bloque, para siempre.

El calendario es una función pura de la altura. No consulta cuánto se pagó realmente, lo que significa que un bloque que paga menos que el calendario — un coinbase debido a una dirección cuyo tenedor la quemó, por ejemplo — es un déficit permanente frente a C y no una deuda que la curva devuelva más tarde. C es, por tanto, la cifra a la que suma el calendario, no un tope que garantice alcanzar.

La cola existe porque la seguridad es un gasto permanente: paga a quien asegure la era vigente — mineros, luego mineros y atestiguadores, luego validadores — sin reclutar los mercados de comisiones de §8. Está dimensionada de modo que la emisión anual de cola empiece por debajo del 1 % del suministro en circulación; como el numerador es fijo y el suministro crece, ese porcentaje solo puede caer. En su contra corre la quema de la comisión base secuencial de §8, así que la emisión neta es la cola menos la quema y puede ser negativa bajo carga. El reparto 97/3 de §14.1 se aplica a todos los subsidios, la cola incluida.

Constantes (génesis, ilustrativas, como en §13): época L = 2880 bloques; divisor de decaimiento Q = 1054; subsidio del génesis E₀ = 21 por bloque; cola 0,33 por bloque. Con bloques de 30 segundos, esto da un factor anual de 0,70702, es decir, que la tasa de emisión se reduce a la mitad cada dos años — y exactamente, no de forma aproximada: E(730) = 10.50230028 frente a E₀ = 21. La fórmula cae por debajo de la cola en la época 4376, altura 12 602 880, ≈ año 12, así que el brazo decreciente recorre las épocas 0 a 4375 y C, el suministro al que suma, es 62 744 838,47. De eso, se emiten realmente 62 744 817,47: la diferencia son los 21 del bloque génesis, que no paga coinbase alguno porque no hay minero a quien pagar y un génesis reproducible no debe acreditar una dirección. La emisión anual de cola es entonces ≈347 000, o el 0,55 % del suministro emitido, y desciende desde ahí. **La forma cerrada L · E₀ · Q = 63 745 920 es una cota superior de C, no su valor**, y la diferencia no es un error de redondeo: ese producto es la suma del decaimiento geométrico infinito, mientras que el calendario es finito, trunca en cada escalón y se detiene en la cola. Supera C en 1 001 081,53, o el 1,60 %. Cítese la suma y nunca la forma cerrada. La conformidad consiste en reproducir la recurrencia — ningún nodo calcula nunca C, ni ninguna otra cifra de este párrafo, a ninguna altura.

15. Mediciones#

Un diseño cuya afirmación central es una asimetría de rendimiento le debe cifras al lector. Las que siguen proceden de la implementación de referencia y pueden volver a derivarse de su código fuente publicado. Hardware: una CPU de escritorio x86 de diez núcleos. Las cifras son medianas sobre 5 ejecuciones.

• Rendimiento del fold: 883 000 operaciones de slot por segundo y por núcleo sobre un conjunto de trabajo de 100 000 slots, es decir, 294 000 certificados aplicados por segundo a 3 slots por certificado.
• Verificación sin estado: 1470 certificados por segundo y por núcleo de CPU, y 5220 por segundo repartidos en 10 núcleos — la razón entre ambas es la afirmación sobre el paralelismo, medida en lugar de asegurada.
• Verificación de firmas: 1500 por segundo, individuales, con las comprobaciones de orden pequeño y de torsión incluidas.
• De extremo a extremo: un bloque de 2900 certificados se valida en 1963 ms y se pliega en 9,9 ms. Se informa de ambas cifras por separado porque son las dos mitades del argumento: la primera escala con núcleos que la red no posee, la segunda es el único bucle que sí posee.

La medición del fold es una resta, y decirlo forma parte de informar de ella: confirmar un bloque ejecuta juntas las comprobaciones sin estado y el fold secuencial, así que la cifra del fold es el conjunto menos las comprobaciones cronometradas por separado. Ambas mitades están en el artefacto.

Informamos solo de lo que ejecuta la implementación de referencia, lo que impone dos límites que vale la pena nombrar en lugar de dejar que los descubra el lector. La verificación de firmas se mide de una en una: la verificación por lotes es una técnica real y un encaje obvio, pero es criptografía crítica para la seguridad que este proyecto no ha escrito, y una cifra sobre código que no existe no es una medición. Las cifras de GPU y SIMT que anticipan §2 y §6 corresponden a los certificados por lotes del secuenciador, que llegan con la Era 1. Ambas son expectativas de diseño. Ninguna es portante para las cifras de arriba: la afirmación sobre el paralelismo descansa en que los certificados sean comprobables de forma independiente, algo que el agrupamiento por lotes haría más rápido y no puede hacer cierto.

16. Trabajo relacionado#

La canalización de Zycord — ejecutar primero, ordenar a ciegas, validar al confirmar — tiene un antepasado en entornos con permisos: el execute-order-validate de Hyperledger Fabric [3], cuyas debilidades documentadas son su tasa de abortos bajo contención y su dependencia de políticas institucionales de respaldo. Las aportaciones de Zycord respecto de ese linaje son (i) la aplicabilidad por igualdad de valores con la omisión como semántica de primera clase y tolerante al caso ABA; (ii) la atribución económica del conflicto — un aval con fianza que hace la equivocación objetivamente penalizable y la obsolescencia un servicio con precio y asegurable, que es lo que le faltaba a execute-order-validate para prescindir de permisos; y (iii) la inclusión forzada con aplicación garantizada, allí donde las salidas de emergencia de los rollups garantizan solo la inclusión. Los conjuntos deterministas de lecturas y escrituras predeclarados descienden de Calvin [4] y aparecen en las listas de acceso de Solana [16]; los métodos escrow conmutativos se remontan a O'Neil [9] y viven hoy dentro de planificadores de un solo nodo, como los agregadores de Aptos sobre Block-STM [5] — Zycord traslada el contrato de conmutatividad al espacio entre nodos y le pone precio. Los sistemas de EVM paralela [5] y las cadenas de ejecución diferida siguen reejecutando en todas partes y chocan con el muro de la E/S de estado; Narwhal [6] separa la diseminación de datos de la ordenación, como hacían nuestros primeros diseños; los objetos propios de Sui son paralelos a nuestras celdas de escritura única; la división pending/base de Zether [7] inspiró la disciplina de delta con guarda (y regresa, junto a las raíces de privacidad del libro mayor quimérico [8], en los pagos confidenciales de §12 — el primer inquilino del carril de criptografía pesada, con importes ocultos y direcciones de un solo uso cuyo precio recae en el gas paralelo en lugar de estar integrado en la capa base). Las superposiciones de finalidad encadenada siguen a Casper FFG [12].

17. Conclusión#

Hemos propuesto una red que 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 lo bastante simple como para especificarlo en una página; conflictos omitidos, con precio y con dueño; concurrencia declarada en lugar de descubierta; censura sobrevivible por construcción; y un lanzamiento que distribuye la moneda antes de pedirle a nadie que confíe en un conjunto de validadores. La verificación escala hacia fuera con hardware que la red no posee. La confirmación sigue siendo secuencial — y casi gratuita.

Zycord no persigue el trabajo. Se queda quieta, y la red hace el trabajo.

Referencias#

[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008. [2] V. Buterin. Ethereum: A Next-Generation Smart Contract 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] B. Bünz, S. Agrawal, M. Zamani, D. Boneh. Zether: Towards Privacy in a Smart Contract World. Financial Cryptography 2020. [8] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262. [9] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986. [10] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008. [11] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011. [12] V. Buterin, V. Griffith. Casper the Friendly Finality Gadget. 2017. [13] M. Corallo. BIP 152: Compact Block Relay. 2016. [14] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019. [15] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019. [16] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017. [17] Decred Documentation: Issuance. docs.decred.org — reparto de la recompensa de bloque entre mineros de PoW, votantes de PoS y tesorería. [18] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022. [19] Monero: Dynamic Block Weight and Penalty. documentación del Monero Research Lab; véase también JollyMort, Monero Dynamic Block Size and Dynamic Minimum Fee, 2017. [20] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.