Para todos / Cómo funciona
El recorrido de una transacción
De su billetera a Ethereum en cinco pasos, la mayoría más rápidos de lo que puede ver. Esta página es la máquina; la página de confirmaciones es lo que promete cada paso.
El recorrido
Usted firma algo en su billetera y lo envía. Llega a un ordenador, el secuenciador, que lo anota para que no pueda perderse, hace el trabajo de inmediato y conoce la respuesta antes de que haya soltado el botón. Muchas veces cada segundo el secuenciador agrupa las respuestas que acaba de producir, firma el paquete y lo publica. Un poco menos a menudo, envuelve esos paquetes en un bloque que se parece exactamente a un bloque de Ethereum, que es lo que su billetera y el explorador le muestran.
Después, por separado, anota todo lo que había en ese bloque y envía una huella de la lista a Ethereum. Cualquiera puede recoger la lista, repetirla por su cuenta y comprobar que obtiene la misma respuesta. Ese último paso es lo que hace de Pickle una parte de Ethereum y no solo un ordenador rápido que dice serlo.
1. Usted la envía. Su billetera firma la transacción y la envía por JSON-RPC estándar al secuenciador, el único proceso que hace funcionar la cadena.
2. Se admite y se hace duradera. El secuenciador recupera al firmante, coloca la transacción en una cola acotada y la añade a un registro con suma de verificación en disco antes de ejecutarla, para que una transacción reconocida sobreviva a una caída.
3. Se ejecuta al instante. Un único coordinador confirma las transacciones en orden de admisión. El recibo existe antes que cualquier bloque.
4. Se preconfirma, luego se confirma. A un objetivo de programación de 10 milisegundos, las transacciones del intervalo se sellan en un minibloque firmado; a un objetivo de programación de 250 milisegundos, los minibloques del intervalo se envuelven en un bloque EVM estándar con un número que toda herramienta entiende.
5. Se compromete en Ethereum. Cada bloque sellado produce una carga con su lista completa de transacciones, almacenada en una capa de disponibilidad de datos, y un compromiso por objetivo de programación de 60 segundos se publica en un contrato de buzón de entrada en Ethereum. A partir de ellos, cualquiera que haga funcionar una réplica reejecuta cada transacción y llega al mismo estado.
La capa RPC recupera al firmante y coloca la transacción en una cola de admisión acotada con un tope por remitente; una cola llena devuelve un error en lugar de hacer crecer la memoria sin límite. Cada transacción aceptada se añade a un registro de escritura anticipada con suma de verificación y se hace duradera antes de ejecutarse, un fsync por lote. Un único coordinador de ejecución confirma en orden de admisión y nunca ejecuta al mismo remitente de forma concurrente, lo que preserva la seguridad del nonce sin un paso de reordenación de mempool. La ejecución es inmediata, así que el recibo existe antes de que se selle el bloque que lo contiene.
Un productor sella un minibloque al objetivo de programación de 10 ms: las transacciones, recibos y logs del intervalo, un hash del diferencial de estado, una marca de tiempo en microsegundos y una firma del secuenciador sobre la cabecera. Un segundo productor sella un bloque EVM con forma de Cancun al objetivo de programación de 250 ms envolviendo los minibloques del intervalo; la marca de tiempo del bloque siguiente se fija cuando se sella el anterior, así que una transacción que lea la marca de tiempo del bloque ve el valor con el que se compromete la cabecera. Cada bloque sellado emite una carga de derivación, lista completa de transacciones, rango de bloques, hash del padre, hash del bloque y marca de tiempo comprometida, hacia una capa de disponibilidad de datos direccionada por contenido, y un sobre por objetivo de programación de 60 s se compromete en el buzón de entrada de la L1, con calldata como respaldo.
Las cifras de 10 milisegundos, 250 milisegundos y 60 segundos son cada una un objetivo de programación, los intervalos a los que apunta el secuenciador. Ninguna es una garantía de latencia y ninguna es una afirmación de rendimiento.
El ciclo de vida, paso a paso
- Un cliente envía una transacción firmada por JSON-RPC estándar.
- La capa RPC recupera al firmante y coloca la transacción en una cola de admisión acotada, con un tope por remitente. Una cola llena devuelve un error en lugar de hacer crecer la memoria sin límite.
- Un único coordinador de ejecución confirma las transacciones en orden de admisión. El mismo remitente nunca se ejecuta de forma concurrente, lo que preserva la seguridad del nonce sin un paso de reordenación de mempool.
- La ejecución es inmediata. El recibo existe antes de que se selle el bloque EVM que lo contiene.
- Cada transacción aceptada se añade a un registro de escritura anticipada con suma de verificación y se hace duradera antes de ejecutarse, un fsync por lote, para que una transacción reconocida sobreviva a una caída.
Tres maneras de ejecutar
El secuenciador no ejecuta todas las transacciones de la misma manera. Reconoce tres formas y toma la ruta correcta más corta para cada una:
- Una transferencia simple de ETH toma una ruta nativa, sin arrancar siquiera la máquina virtual.
- La transferencia ERC-20 canónica toma una ruta rápida que mueve directamente la posición de saldo y emite el evento estándar, produciendo el mismo resultado que daría la máquina completa.
- Todo lo demás pasa por la EVM general, que es revm fijado al hardfork Cancun.
Las tres cobran gas estándar y reparten la comisión de la misma manera, así que no puede saber por la comisión qué ruta se tomó, y no debería necesitarlo. Las rutas rápidas existen porque la mayor parte del tráfico de una cadena son los dos tipos más simples de transacción, y es ahí donde se va el tiempo.
Por qué es determinista
Dos cosas que otras cadenas dejan al operador son aquí constantes de tiempo de compilación: el hardfork de ejecución y el precio mínimo del gas. Si fueran ajustables, cualquiera de las dos permitiría a una réplica rechazar o volver a tarificar una transacción que el secuenciador aceptó, y la derivación independiente se detendría. El mismo razonamiento fija la marca de tiempo del bloque siguiente en el sellado anterior, y convierte el intervalo de los minibloques en un parámetro de consenso y no en un ajuste por operador: una réplica tiene que estar de acuerdo en cómo se corta el flujo para reproducir los mismos hashes.
Por qué está construida así
La decisión inusual es ejecutar antes de sellar. En la mayoría de las cadenas una transacción espera al siguiente bloque y se ejecuta como parte de su construcción; aquí se ejecuta al llegar y los bloques se ensamblan después a partir de resultados que ya existen. Eso es lo que hace rápido el primer momento, y es la razón de que el minibloque exista como algo distinto del bloque: el minibloque es el secuenciador poniendo su firma sobre resultados que ya ha calculado, mientras el bloque corriente llega a su propio ritmo por detrás. Lo que garantiza cada momento está en la página de confirmaciones, y dónde acaba el registro está en la página de liquidación.