ZYCORD documentación
Español
ZycordDocumentaciónCómo funciona la red
Zycord (ZCD) — cómo funciona la red

Ensamblado fuera de la cadena.
Verificado en paralelo.
Confirmado en orden.

Toda blockchain grande obliga a cada nodo a reejecutar cada transacción contra un estado global. Zycord saca la ejecución fuera de la cadena: la transacción se ensambla entre servidores ajenos a ella, llega completa con todo lo que leyó y escribió, cualquier máquina la comprueba solo a partir de los bytes, y un único bucle confirma el resultado.

Three phases: construction between servers, parallel verification, sequential fold Ensamblaje — fuera de la cadena La transacción rebota entre servidores hasta cerrarse Monedero Secuenciador contrato A Secuenciador contrato B Avalista co-firma Verificación — paralela, sin estado Muchos nodos, cada uno con su porción Fold — secuencial Un bucle, compara y suma 9,9 ms por bloque de 2900 certificados
Servidores corrientes, web2, sin consenso Crece con cada núcleo que se suma a la red El único recurso escaso

La transacción es un certificado

No pide “ejecuta esto”. Declara “leí esto, escribí aquello, y aquí está la prueba”. Cualquiera recalcula y compara.

Certificate { reads: [(slot, access, operand)] // qué leí, y cómo writes: [(slot, op, value)] // qué escribo program: bytes // código u operación nativa sigs: [signature] // autoridad de gasto underwriter: (id, sig, seq) // quién asume el riesgo ttl: height // caduca si no se incluye antes fee: (seq_gas, par_gas) // dos mercados }
Válido = una función pura de los bytesFirmas correctas, avalista correcto, y reejecutar program sobre los reads produce exactamente los writes. Sin disco, sin historia.
Aplicable = lo decide la posición¿Los reads declarados siguen coincidiendo con el estado cuando al certificado le llega su turno en el bloque?
El ID excluye las firmasVolver a firmar con otro nonce da el mismo ID. El conjunto de vistos detecta la copia. A nadie se le cobra dos veces.
Tipos de acceso por slotEXACT fija el valor. GUARD solo declara “saldo ≥ x”. DELTA suma sin leer. Pagos y propinas conmutan y nunca entran en conflicto.

Dos verbos, dos etapas

Todo el diseño consiste en separar estas dos preguntas — y responder cada una en el lugar más barato.

paralelo

¿Es válido?

Se responde mirando solo el certificado. Miles a la vez, en cualquier máquina.

  • Las firmas canónicas cuadran
  • La reejecución coincide con los writes
  • Las pruebas de rango cierran (carril blindado)
  • Inválido: nunca entra en el bloque
secuencial

¿Es aplicable?

Se responde en la posición del certificado dentro del bloque, comparando bytes contra la tabla de estado.

  • Los reads siguen coincidiendo → los writes se confirman
  • Reads obsoletos → omisión, quema la comisión del avalista
  • Celda ya gastada → omisión
  • El bloque sigue siendo válido en todos los casos

El recorrido, del nacimiento al libro mayor

1

Construcción entre servidores

El monedero abre la petición. Cada contrato con actividad tiene su propio secuenciador — un servidor de aplicaciones corriente — que guarda una copia del estado, serializa quién se mueve primero y encadena cada certificado a los writes del anterior. Una transacción que toca dos contratos la co-construyen ambos secuenciadores y llega a la cadena como un único certificado atómico.

2

El avalista firma

Un avalista con fondos depositados comprueba contra estado fresco, co-firma y asume el riesgo de omisión. Cobra al remitente fuera de banda y vende, en la práctica, una preconfirmación. Quien no quiera intermediarios se avala a sí mismo con su propio depósito — siempre disponible, sin pedir permiso.

3

La red recibe y verifica en paralelo

Cada nodo comprueba la validez a partir de los bytes antes de retransmitir. Con muestreo, un comité sorteado por VRF verifica cada certificado; cualquier nodo puede comprobar cualquier cosa, y un solo mensaje basta para castigar a un avalista que dio fe de basura.

Inválido → descartado, nunca llega al bloque
4

El proponente ordena

Un comité PoS elige certificados válidos y ensambla el bloque. No ejecuta nada y no guarda estado de aplicación. Solo recuerda los ID vistos dentro de la ventana del TTL. Los certificados de la cola forzada deben incluirse en un plazo de F bloques.

5

Fold secuencial

Ordena por (underwriter, seq, id) — el proponente no elige el orden. Para cada certificado: ¿coinciden los reads con el estado? Los puntos de control se finalizan cada 32 bloques.

Aplicado — writes confirmados, comisión pagada al proponente
Omitido — comisión quemada, cargada al avalista, el bloque sigue siendo válido

Quién hace qué

Ningún rol es necesario para la seguridad de la red. Si todos desaparecen, la cola forzada mantiene el sistema con vida.

Monedero

Hace
Construye el certificado, declara reads y writes, firma
Ve
El estado público que necesita leer
Confía en
Nadie

Secuenciador

Hace
Serializa un contrato con actividad fuera de la cadena, empaqueta lotes en un solo certificado
Se confía en él para
Solo la disponibilidad. Si miente, el certificado se omite y paga el depósito
Captura
El MEV de su propia aplicación, explícitamente

Avalista

Hace
Co-firma y asume el riesgo de omisión con un depósito
Ve
Celdas vivas o gastadas — nunca el valor oculto
Pierde
Solo por una falta demostrable en los bytes (equivocación)

Nodo verificador

Hace
Comprueba la validez a partir de los bytes, retransmite, sincroniza
Necesita
Núcleos. Estado solo si va a confirmar
Coste
Baja a medida que la red crece, porque verifica una porción

Proponente (PoS)

Hace
Ordena certificados válidos, ejecuta el fold, propone el bloque
Ve
Bytes, no significado
Gana
Subsidio + comisión de prioridad de los aplicados

Privacidad sin tocar la ruta secuencial

Transacciones Confidenciales con una dirección de un solo uso, sobre un grafo público. Oculta el valor. Aplaza el vínculo con el destinatario. No es Monero, y el documento lo dice.

Qué queda oculto

  • El valor: compromiso C = vG + rH
  • El destinatario, hasta el primer gasto (dirección sigilosa)
  • El saldo de cada celda oculta — solo el propietario puede gastarla, nadie puede “preguntar”

Qué queda público

  • Que hubo un pago, y quién lo avaló
  • Qué salida se gastó, en el momento del gasto
  • Cada cruce entre el carril público y el blindado, con el valor a la vista
  • Comisiones, coinbase, pagos a contratos

La reserva blindada es una valla, no una alarma

Shielded pool with an exit guard Carril público valores en u256, aritmética comprobada Reserva blindada reserva = Σ entra − Σ sale un entero público, movido por delta blindar +v desblindar: guard reserva ≥ v Si la criptografía se rompe el valor falsificado no cruza el guard. La inflación queda atrapada en la reserva.

El fold nunca hace aritmética de curvas. Guarda 32 bytes de compromiso y compara por igualdad. Toda la criptografía pesada — pruebas de rango, la ecuación de saldo — se verifica en la etapa paralela y se paga en el mercado barato.

Por qué no hay firmas de anillo

Un anillo referencia salidas de otras personas — eso hace de la validez una función de la historia, y mata la verificación sin estado. Zycord no renuncia a esa propiedad, así que su privacidad es más débil que la de Monero por decisión, no por descuido.

La red: dos mercados de gas

Una cadena que cobra todo en una sola subasta hace que la verificación de una prueba compita con una escritura de estado. Aquí cada recurso tiene su propio precio.

Gas paralelo

Paga la verificación: firmas, reejecución, bytes, pruebas pesadas, esquemas poscuánticos.

La oferta crece con cada núcleo y cada GPU que se suma. Techo alto, precio bajo.

Gas secuencial

Paga el fold: comprobar reads, writes, arrendamientos. El único bucle que cada nodo ejecuta en orden.

Escaso. Techo elástico: como mucho una duplicación al año de bloques llenos y sanos. Nadie vota.

La red vista desde arriba

Cuatro capas que no se solapan: quién serializa, quién avala, quién verifica, quién ordena. Cada una escala con un recurso distinto.

fuera de la cadena

Secuenciadores por aplicación

Web2 corriente: websockets, colas, autoescalado. Serializan contratos con actividad y empaquetan lotes con la forma que las GPU verifican bien. Nunca custodian datos — el estado siempre se puede reconstruir solo a partir de la cadena.

fuera de la cadena

Mercado de avalistas

Los avalistas con depósito venden preconfirmación: “aplicado en segundos o paga mi depósito”. La equivocación se castiga con una prueba en los bytes; la lentitud solo cuesta reputación. La latencia nunca se convierte en confiscación.

paralelo

Comités de verificación

Sorteados por VRF para cada certificado, con un tamaño tal que la fuga de un certificado inválido sea despreciable. Cualquier nodo completo puede auditar cualquier cosa. Un mensaje basta para castigar.

secuencial

Comité PoS + fold

Propone bloques, ejecuta el fold, finaliza los puntos de control. La cola forzada obliga a la inclusión en un plazo de F bloques y garantiza la aplicación — el mecanismo que hace que la red sobreviva a cualquier operador, incluido el autor.