Diferenças com a Ethereum

As razões de revert são indecodificáveis

Se você precisa da razão, os dados de retorno estão no texto da mensagem e você pode decodificá-los por conta própria:

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).
}

Não há estado histórico

eth_getBalance, eth_getTransactionCount, eth_getCode e eth_getStorageAt analisam o endereço e depois leem o último instantâneo publicado. O parâmetro de bloco é aceito e ignorado em silêncio - um pedido de saldo no bloco 100 não dá erro, ele responde com o saldo de agora.

eth_call e eth_estimateGas fazem o mesmo, e ainda por cima ignoram o gas, o gasPrice e o nonce que você lhes envia: a simulação roda sempre no limite de gas por bloco de 30.000.000 contra o estado mais recente.

As etiquetas de bloco colapsam

latest, pending, safe e finalized resolvem todas para a mesma coisa: a ponta conservada. E earliest resolve para o bloco conservado mais antigo, e não para o bloco 0 - portanto ele avança à medida que a janela desliza.

Os objetos EIP-1898 são aceitos: { blockNumber } ou { blockHash }, com um hash resolvido pelo índice e respondendo null quando ele não é mais conservado. Qualquer outra coisa dá -32602 "block tag".

Um cliente que distingue safe de finalized para decidir quando confiar num resultado não recebe sinal algum desta cadeia. A finalidade aqui é a liquidação na L1 e não é de forma alguma visível através dessas etiquetas.

Raízes e blooms estão a zero

Tanto nos blocos quanto nos recibos, stateRoot, transactionsRoot e receiptsRoot valem zero, e logsBloom são 512 caracteres zero.

Duas consequências. Um cliente que verifica raízes não consegue verificar nada aqui. E um cliente que pré-filtra por bloom antes de ir buscar logs não vai encontrar nada - filtre com eth_getLogs, que lê um índice de verdade.

Os cabeçalhos estão, no mais, corretamente no formato Cancun, incluindo mixHash, withdrawalsRoot, blobGasUsed, excessBlobGas e parentBeaconBlockRoot. mixHash é portador e não decorativo: sem ele, todo cliente baseado em revm, forge script incluído, rejeita o cabeçalho com prevrandao not set antes mesmo de simular.

Campos de recibo e de transação

• type vale sempre "0x0", qualquer que seja o envelope que você de fato enviou, e uma transação reporta um único gasPrice plano - nem maxFeePerGas, nem maxPriorityFeePerGas, nem accessList voltam. As transações tipadas são aceitas na entrada; é a forma da resposta que simplesmente não reflete o tipo.
• cumulativeGasUsed é o gasUsed próprio daquela transação, e não um total corrente do bloco. Somá-lo ao longo de um bloco não conta nada duas vezes, mas também não lhe diz nada.
• blockHash e blockNumber valem null entre a execução e o selamento EVM. Um recibo existe nessa janela, portanto "o recibo não é null" não é o mesmo teste que "incluído num bloco".
• Uma transação carrega extras não padronizados - raw, miniBlockNumber, miniBlockHash - e um recibo carrega os dois últimos. Eles são úteis e não são portáveis.
• eth_getBlockByNumber com fullTransactions: true pode devolver um array misto: objetos para as transações cujos recibos ainda estão indexados, simples cadeias de hash para aquelas já despejadas.
• eth_getBlockReceipts omite em silêncio os recibos despejados, portanto o array pode ser mais curto do que a lista de transações do bloco.

logIndex é por transação

logIndex é enumerado sobre os logs do próprio recibo, e não sobre o bloco. Dois logs de um mesmo bloco podem ambos ter logIndex 0.

Se você indexar um armazenamento de eventos por (blockNumber, logIndex) - a chave primária composta habitual de um indexador - você terá colisões. Inclua transactionHash.

Pending não é um mempool

Não há mempool público onde estar pending. Um hash só chega ao eth_newPendingTransactionFilter e à inscrição newPendingTransactions depois que a transação foi executada e indexada.

É portanto um fluxo de transações executadas sob um nome enganoso. Você não pode espreitar as transações que chegam antes que elas aterrissem, e não há nada a antecipar através desta interface.

Os métodos que respondem com constantes

Dois métodos parecem funcionar e devolvem valores que não são medições. Os dois estão sinalizados na referência, e os dois são mais perigosos do que um método que dá erro:

• eth_feeHistory lê apenas blockCount, ignora inteiramente newestBlock e rewardPercentiles, e devolve baseFeePerGas como 0x1 repetido, com gasUsedRatio como 0.0 repetido.
• eth_createAccessList devolve { accessList: [], gasUsed: "0x0" } sem olhar nem para os parâmetros nem para o estado.

Um terceiro grupo responde honestamente mas a vazio, porque os conceitos não se aplicam: eth_accounts está sempre vazio, eth_mining falso, eth_hashrate zero, e os quatro métodos de tios devolvem zero ou null sem validar seus parâmetros.

Os espaços de nomes que não existem

rpc_modules anuncia eth, net, web3 e pickle. Ausentes e não implementados: debug, trace, txpool e admin. Não há portanto debug_traceTransaction - para os rastros de chamadas, use o explorador, que os tem.

Os métodos de assinatura estão registrados e recusam deliberadamente: eth_sendTransaction, eth_sign, eth_signTransaction, personal_sign e eth_coinbase respondem todos -32601. O nó não detém chave de usuário alguma - assine localmente e use eth_sendRawTransaction.