Historique et rétention

Ce que le nœud conserve

La fenêtre de blocs est dérivée plutôt que fixe : keep_evm_blocks() = 120_000 / EVM_BLOCK_MS, soit 480 blocs à la cadence par défaut. Les logs sont évincés avec leur bloc. Les reçus et les corps de transactions ont leur propre plafond premier entré premier sorti et peuvent disparaître avant leur bloc.

Les lectures sont servies depuis un instantané publié en copie sur écriture et ne prennent jamais le verrou d'exécution, ce qui fait qu'un eth_call lent ne peut pas bloquer la production de blocs et qu'un bloc bloqué ne peut pas bloquer les lectures. C'est la conception qui rend la fenêtre acceptable : le nœud optimise pour servir le présent rapidement, et confie l'historique à quelque chose de bâti pour ça.

Comment cela échoue

Trois motifs qui ont l'air corrects et ne le sont pas :

• Interroger un reçu avec un long délai de reprise. Attendez assez longtemps entre deux tentatives et le reçu peut être évincé entre deux sondages. Il existe dans les 10 ms environ après l'envoi - sondez tôt et souvent, pas patiemment.
• Reprendre l'historique depuis le bloc 0. earliest est le plus ancien bloc conservé, et il avance pendant que vous travaillez. Une boucle de reprise qui le poursuit n'atteint jamais un point de départ fixe.
• Réconcilier un registre chaque nuit. Le temps qu'un travail nocturne tourne, tous les blocs qu'il voulait ont disparu.

Quoi faire à la place

L'historique complet existe - il est diffusé du séquenceur vers le Postgres derrière l'explorateur, qui est bâti pour être une archive. Donc :

• Pour le présent - les dernières secondes - utilisez le nœud. Les abonnements et eth_getLogs sur une plage étroite sont ce en quoi il est rapide.
• Pour le passé, lisez l'explorateur. Il a aussi les traces d'appels, que le nœud n'expose pas du tout puisqu'il n'y a pas d'espace de noms debug.
• Pour tenir votre propre historique, abonnez-vous et persistez à mesure que les événements arrivent, plutôt que de les demander plus tard. Le flux de mini-blocs est la source la plus fidèle ; un gestionnaire lent en est éjecté, donc poussez vers une file et traitez ailleurs.

// Right: capture as it happens, persist immediately.
socket.send(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "eth_subscribe",
  params: ["logs", { address: MY_CONTRACT }],
}));

// Wrong on this chain: a range that has already scrolled out of the window
// returns an empty array rather than an error, so this looks like "no events".
await client.getLogs({ address: MY_CONTRACT, fromBlock: 0n, toBlock: "latest" });

Et si vous indexez un magasin d'événements sur (blockNumber, logIndex), incluez le hash de la transaction : ici logIndex est énuméré par transaction, donc cette paire n'est pas unique.

Les reçus à travers un redémarrage