Diferencias entre Scroll y Ethereum

Ciertos detalles técnicos difieren entre el EVM de Ethereum mainnet y el diseño de una zkEVM modificado por Scroll. A continuación puedes ver esas diferencias tal y como existen en Scroll Sepolia.

Los colaboradores de código abierto y los desarrolladores de infraestructura pueden ponerse en contacto con nuestro equipo para obtener ayuda adicional.

Opcodes de la EVM

Los precompilados de la EVM

Los precompilados SHA2-256 (address 0x2), RIPEMD-160 (address 0x3), y blake2f (address 0x9) actualmente no estan soportados. Las llamadas a estos contratos precompilados se revertirán. Planeamos habilitar estos tres precompilados en un futuro hard fork.

El precompilado modexp esta habilitado pero solo soporta entradas con un tamaño igual o menor a 32 bytes (i.e. u256).

El precompilado ecPairing esta soportado, pero el número de puntos (sets, pairs) esta limitado a 4, en lugar de 6.

Los todos otros precompilados EVM estan habilitados: ecRecover, identity, ecAdd, ecMul.

State Account

Campos Adicionales

Hemos añadido 2 campos adicionales al objeto StateAccount actual: PoseidonCodehash y CodeSize.

type StateAccount struct {
  Nonce    uint64
  Balance  *big.Int
  Root     common.Hash // merkle root of the storage trie
  KeccakCodeHash []byte // still the Keccak codehash
  // added fields
  PoseidonCodeHash []byte // the Poseidon codehash
  CodeSize uint64
}

CodeHash

En relación con esto, mantenemos dos tipos de codehash para cada bytecode de contrato: hash de Keccak y hash de Poseidon.

KeccakCodeHash se mantiene para conservar la compatibilidad con EXTCODEHASH. PoseidonCodeHash se utiliza para verificar la corrección de los bytecodes cargados en la zkEVM, donde el hasheo de Poseidon es mucho más eficiente.

CodeSize

A la hora de verificar el “EXTCODESIZE”, resulta costoso cargar todos los datos del contrato en la zkEVM. En su lugar, almacenamos el tamaño del contrato durante la creación del mismo. De esta manera, no necesitamos cargar el código - una storage proof es suficiente para verificar este opcode.

Tiempo de Bloques

Scroll apunta a tener un tiempo de bloque constante de 3 segundos. Esto es más corto y consistente que los 12 segundos utilizados en Ethereum en condiciones ideales.

Esto se eligió por dos razones:

• Tener un tiempo de bloque más rápido y constante se traduce en una respuesta más rápida y una mejor experiencia de usuario.
• A medida que optimizamos los circuitos de la zkEVM en nuestras redes de prueba, incluso si mantenemos un límite de gas menor por bloque o lote, podemos alcanzar un rendimiento superior al de Ethereum.

EIPs Futuros

Seguimos de cerca todas las EIP emergentes adoptadas por Ethereum y las adoptamos cuando es conveniente. Si estás interesado en más detalles, ponte en contacto con nosotros en nuestro foro de la comunidad o en Scroll Discord.

Comisiones de Transacciones

La comisión aplicada a las transacciones de Scroll consta de dos partes:

• Comisión de gas en L2: similar a L1, el importe de la comisión de ejecución en L2 es igual a L2_gas_price * L2_gas_used, cubriendo los siguientes costos:
  • Costo de ejecución y almacenamiento del secuenciador en L2
  • Costo de verificación y finalización de la prueba de validez en L1
  • Costo del prover
• Comisión de datos en L1: comisión adicional sobre la comisión de gas en L2. La comisión de datos en L1 sólo se cobra a las transacciones iniciadas en L2, no a las iniciadas en L1. La tarifa cubre el costo del envío de datos a L1 para la disponibilidad de datos. Dado que agrupamos los datos y los guardamos en L1 (el concepto del rollup), la comisión de transferencia a L1 se calcula en función del tamaño de los datos de la tx.

Para obtener más información, consulta Comisiones de Transacciones en Scroll.