Desviaciones respecto a Ethereum

Las razones de revert no se pueden decodificar

Si necesita la razón, los datos de retorno están en el texto del mensaje y usted puede decodificarlos por su cuenta:

try {
  await client.readContract({ /* … */ });
} catch (err) {
  // "execution reverted: 0x08c379a0…"
  const hex = String(err.message).match(/0x[0-9a-fA-F]+/)?.[0];
  // Decode that hex against your own ABI's errors, or against Error(string).
}

No hay estado histórico

eth_getBalance, eth_getTransactionCount, eth_getCode y eth_getStorageAt analizan la dirección y luego leen la última instantánea publicada. El parámetro de bloque se acepta y se ignora en silencio - una petición del saldo en el bloque 100 no falla, responde con el saldo actual.

eth_call y eth_estimateGas hacen lo mismo, y además ignoran el gas, el gasPrice y el nonce que usted les envía: la simulación se ejecuta siempre con el límite de gas por bloque de 30 000 000 contra el estado más reciente.

Las etiquetas de bloque colapsan

latest, pending, safe y finalized se resuelven todas a lo mismo: la punta conservada. Y earliest se resuelve al bloque conservado más antiguo, no al bloque 0 - así que avanza a medida que la ventana se desplaza.

Los objetos EIP-1898 se aceptan: { blockNumber } o { blockHash }, con un hash resuelto a través del índice y que responde null cuando ya no se conserva. Cualquier otra cosa da -32602 "block tag".

Un cliente que distingue safe de finalized para decidir cuándo fiarse de un resultado no recibe ninguna señal de esta cadena. La finalidad aquí es la liquidación en L1 y no es visible en absoluto a través de estas etiquetas.

Raíces y blooms están a cero

Tanto en los bloques como en los recibos, stateRoot, transactionsRoot y receiptsRoot valen cero, y logsBloom son 512 caracteres cero.

Dos consecuencias. Un cliente que verifica raíces no puede verificar nada aquí. Y un cliente que prefiltra por bloom antes de ir a buscar logs no encontrará nada - filtre con eth_getLogs, que lee un índice real.

Por lo demás, las cabeceras tienen correctamente el formato Cancun, incluidos mixHash, withdrawalsRoot, blobGasUsed, excessBlobGas y parentBeaconBlockRoot. mixHash es portante en lugar de decorativo: sin él, todo cliente basado en revm, forge script incluido, rechaza la cabecera con prevrandao not set antes siquiera de simular.

Campos de recibo y de transacción

• type vale siempre "0x0", sea cual sea el sobre que usted haya enviado realmente, y una transacción informa de un único gasPrice plano - no vuelven ni maxFeePerGas, ni maxPriorityFeePerGas, ni accessList. Las transacciones tipadas se aceptan a la entrada; es la forma de la respuesta la que simplemente no refleja el tipo.
• cumulativeGasUsed es el gasUsed propio de esa transacción, no un total acumulado del bloque. Sumarlo a lo largo de un bloque no cuenta nada dos veces, pero tampoco le dice nada.
• blockHash y blockNumber valen null entre la ejecución y el sellado EVM. Un recibo existe en esa ventana, así que "el recibo no es null" no es la misma prueba que "incluido en un bloque".
• Una transacción lleva extras no estándar - raw, miniBlockNumber, miniBlockHash - y un recibo lleva los dos últimos. Son útiles y no son portables.
• eth_getBlockByNumber con fullTransactions: true puede devolver un array mixto: objetos para las transacciones cuyos recibos siguen indexados, simples cadenas de hash para las ya expulsadas.
• eth_getBlockReceipts omite en silencio los recibos expulsados, así que el array puede ser más corto que la lista de transacciones del bloque.

logIndex es por transacción

logIndex se enumera sobre los logs de su propio recibo, no sobre el bloque. Dos logs de un mismo bloque pueden tener ambos logIndex 0.

Si indexa un almacén de eventos por (blockNumber, logIndex) - la clave primaria compuesta habitual de un indexador - tendrá colisiones. Incluya transactionHash.

Pending no es un mempool

No hay un mempool público en el que estar pendiente. Un hash llega a eth_newPendingTransactionFilter y a la suscripción newPendingTransactions solo después de que la transacción se haya ejecutado e indexado.

Así que es un flujo de transacciones ya ejecutadas bajo un nombre engañoso. No se pueden vigilar las transacciones entrantes antes de que aterricen, y no hay nada que adelantar a través de esta interfaz.

Los métodos que responden con constantes

Dos métodos parecen funcionar y devuelven valores que no son mediciones. Los dos están señalados en la referencia, y los dos son más peligrosos que un método que falla:

• eth_feeHistory solo lee blockCount, ignora por completo newestBlock y rewardPercentiles, y devuelve baseFeePerGas como 0x1 repetido con gasUsedRatio como 0.0 repetido.
• eth_createAccessList devuelve { accessList: [], gasUsed: "0x0" } sin mirar ni los parámetros ni el estado.

Un tercer grupo responde con honestidad pero en vacío, porque los conceptos no se aplican: eth_accounts está siempre vacío, eth_mining es falso, eth_hashrate cero, y los cuatro métodos de uncles devuelven cero o null sin validar sus parámetros.

Los espacios de nombres que no existen

rpc_modules anuncia eth, net, web3 y pickle. Ausentes y no implementados: debug, trace, txpool y admin. Así que no hay debug_traceTransaction - para las trazas de llamadas, use el explorador, que sí las tiene.

Los métodos de firma están registrados y se niegan deliberadamente: eth_sendTransaction, eth_sign, eth_signTransaction, personal_sign y eth_coinbase responden todos -32601. El nodo no guarda ninguna clave de usuario - firme localmente y use eth_sendRawTransaction.