Para todos / Cómo funciona
Liquidación y registro
El contenido de cada bloque se publica, en orden, bloque 0 incluido, y Ethereum siempre tiene o bien los datos o bien un compromiso sobre datos disponibles en otro lugar. Eso es lo que hace que la cadena sea comprobable y no meramente afirmada.
Dos niveles de publicación
| Nivel | Qué contiene |
|---|---|
| Capa de disponibilidad de datos | la carga completa, por bloquedireccionada por contenido, indexada por su hash; el secuenciador verifica el resumen del acuse antes de confiar en él |
| Buzón de entrada en Ethereum | un sobre compacto que nombra la cargaun compromiso por objetivo de programación de 60 s, blob o calldata elegido según precios medidos |
| Respaldo | la carga completa como calldata en Ethereumse toma siempre que la ruta de disponibilidad de datos falla, para que la cadena siga siendo derivable durante una interrupción |
Imagine una tienda que guarda cada recibo en un archivo, y una vez por minuto envía al banco un resumen sellado que dice "aquí está la huella de los recibos que acabo de archivar". El banco no puede leer los recibos a partir de la huella, pero cualquiera que entre en el archivo puede comprobar que nada se cambió. Y si el archivo alguna vez es inaccesible, la tienda envía al banco los propios recibos en su lugar. El secuenciador de Pickle es la tienda, la capa de disponibilidad de datos es el archivo, y Ethereum es el banco.
Cada bloque sellado produce una carga de derivación que lleva su lista completa de transacciones. La carga se almacena en una capa de disponibilidad de datos direccionada por contenido, indexada por su hash, y el secuenciador verifica el acuse antes de confiar en ella. Un sobre compacto que nombra esa carga se compromete después en un contrato de buzón de entrada en Ethereum. Si la ruta de disponibilidad de datos falla por cualquier razón, la carga completa se publica en Ethereum como calldata en su lugar.
Todos los bloques se publican, en orden, bloque 0 incluido. El buzón de entrada acepta anexos solo desde la clave de batcher designada y emite un evento indexado por lote; ese índice es el orden total que sigue todo verificador.
La carga lleva la lista completa de transacciones del bloque junto con el rango de bloques, el hash del padre, el hash del bloque y la marca de tiempo comprometida; la marca de tiempo se incluye porque forma parte del entorno de ejecución, no solo de la cabecera, y una réplica debe ejecutar contra el mismo reloj para sellar el mismo hash. La publicación es de dos niveles: la carga a un almacén direccionado por contenido bajo su hash con verificación del resumen en el acuse, y un sobre al buzón de entrada de la L1 por ventana de agregación. El buzón de entrada está restringido al batcher y emite un evento indexado por anexo. El instrumento de compromiso, blob o calldata, se selecciona por envío según precios medidos, ya que a este tamaño de carga el gas de ejecución domina con comisiones de blob bajas y el calldata simple gana con comisiones altas.
Qué lleva una carga
- La lista completa de transacciones del bloque, para que nada del bloque tenga que darse por cierto.
- El rango de bloques, el hash del padre y el hash del bloque, para que la réplica sepa dónde encaja y qué debe reproducir.
- La marca de tiempo comprometida, porque una transacción que leyó el reloj vio ese valor, y una réplica que ejecutara contra otro reloj sellaría otro hash.
Por qué un compromiso por ventana
Ethereum no recibe una transacción por cada bloque sellado. Los datos completos van a la capa de disponibilidad de datos por bloque; un compromiso va a Ethereum por ventana de agregación, a un objetivo de programación de 60 segundos. La agregación es lo que mantiene el coste de liquidación modelado en unos pocos millones de dólares al año en lugar de las decenas o centenas de millones que costaría un diseño de publicación por bloque. La página de límites da el rango modelado y en qué se apoya.
Verificación independiente
Cualquier operador puede ejecutar el mismo binario como réplica. No produce nada. Lee el buzón de entrada de Ethereum desde su último índice aplicado, obtiene cada carga por su dirección de contenido o decodifica el respaldo en calldata en línea, reejecuta cada transacción en orden contra la marca de tiempo comprometida, sella el bloque localmente y compara el hash con el que el secuenciador comprometió.
Ante cualquier discrepancia, una réplica se detiene de forma permanente
La divergencia es terminal por diseño: reintentar sellaría más bloques y se alejaría de la cadena canónica, enterrando la causa. Una réplica detenida es la señal de que los datos publicados y el hash comprometido no coinciden. Nada en cadena arbitra ese desacuerdo; la página del modelo de confianza dice qué se sigue de ello.
Una réplica sincronizada sirve el RPC de lectura estándar desde su propio estado derivado de forma independiente. Sus saldos, recibos y cabeceras se rederivan localmente, no son copias confiadas de las respuestas del secuenciador. El envío de transacciones se reenvía al secuenciador; una réplica no acepta nada en una mempool local.
De dónde se lee el historial
El secuenciador está optimizado para responder sobre el presente y conserva una ventana corta de bloques recientes. El historial completo se indexa en la base de datos del explorador, alimentada continuamente por el secuenciador, y es allí donde se responde todo lo histórico. Ambos están aguas abajo de las mismas cargas publicadas, y una réplica puede reconstruir cualquiera de los dos solo a partir de Ethereum y de la capa de disponibilidad de datos.