Pour tous / Comment ça marche
Règlement et registre
Le contenu de chaque bloc est publié, dans l'ordre, bloc 0 compris, et Ethereum détient toujours soit les données, soit un engagement sur des données disponibles ailleurs. C'est ce qui rend la chaîne vérifiable plutôt que simplement affirmée.
Deux niveaux de publication
| Niveau | Ce qu'il détient |
|---|---|
| Couche de disponibilité des données | la charge complète, par blocadressée par contenu, indexée par son hash ; le séquenceur vérifie l'empreinte d'acquittement avant de s'y fier |
| Boîte de réception Ethereum | une enveloppe compacte nommant la chargeun engagement par cible d'ordonnancement de 60 s, blob ou calldata choisi d'après les prix mesurés |
| Repli | la charge complète en calldata sur Ethereumpris chaque fois que la voie de disponibilité des données échoue, pour que la chaîne reste dérivable pendant une panne |
Imaginez une boutique qui garde chaque reçu dans une salle d'archives, et qui envoie à la banque, une fois par minute, un résumé scellé disant « voici l'empreinte des reçus que je viens de classer ». La banque ne peut pas lire les reçus à partir de l'empreinte, mais quiconque entre dans la salle d'archives peut vérifier que rien n'a été modifié. Et si la salle d'archives est un jour inaccessible, la boutique envoie à la banque les reçus eux-mêmes. Le séquenceur de Pickle est la boutique, la couche de disponibilité des données est la salle d'archives, et Ethereum est la banque.
Chaque bloc scellé produit une charge de dérivation portant la liste complète de ses transactions. La charge est stockée dans une couche de disponibilité des données adressée par contenu, indexée par son hash, et le séquenceur vérifie l'acquittement avant de s'y fier. Une enveloppe compacte nommant cette charge est ensuite engagée dans un contrat de boîte de réception sur Ethereum. Si la voie de disponibilité des données échoue pour quelque raison, la charge complète est postée sur Ethereum en calldata à la place.
Chaque bloc est posté, dans l'ordre, bloc 0 compris. La boîte de réception n'accepte les ajouts que de la clé de batcher désignée et émet un événement indexé par lot ; cet index est l'ordre total que suit chaque vérificateur.
La charge porte la liste complète des transactions du bloc avec la plage de blocs, le hash parent, le hash du bloc et l'horodatage engagé ; l'horodatage y figure parce qu'il fait partie de l'environnement d'exécution, pas seulement de l'en-tête, et une réplique doit exécuter contre la même horloge pour sceller le même hash. La publication est à deux niveaux : la charge vers un magasin adressé par contenu sous son hash avec vérification de l'empreinte à l'acquittement, et une enveloppe vers la boîte de réception L1 par fenêtre d'agrégation. La boîte de réception est réservée au batcher et émet un événement indexé par ajout. L'instrument d'engagement, blob ou calldata, est choisi par soumission d'après les prix mesurés, car à cette taille de charge le gas d'exécution domine quand les frais de blob sont bas et le calldata brut l'emporte quand ils sont hauts.
Ce que porte une charge
- La liste complète des transactions du bloc, pour que rien du bloc n'ait à être cru sur parole.
- La plage de blocs, le hash parent et le hash du bloc, pour que la réplique sache où il s'insère et ce qu'elle doit reproduire.
- L'horodatage engagé, parce qu'une transaction qui a lu l'horloge a vu cette valeur, et qu'une réplique exécutant contre une autre horloge scellerait un autre hash.
Pourquoi un engagement par fenêtre
Ethereum ne reçoit pas une transaction par bloc scellé. Les données complètes vont à la couche de disponibilité des données par bloc ; un engagement va à Ethereum par fenêtre d'agrégation, à une cible d'ordonnancement de 60 secondes. L'agrégation est ce qui maintient le coût de règlement modélisé à quelques millions de dollars par an plutôt qu'aux dizaines ou centaines de millions qu'une publication par bloc coûterait. La page des limites donne la fourchette modélisée et ce sur quoi elle repose.
Vérification indépendante
Tout opérateur peut faire tourner le même binaire comme réplique. Elle ne produit rien. Elle lit la boîte de réception Ethereum depuis son dernier index appliqué, récupère chaque charge par son adresse de contenu ou décode le repli calldata inline, ré-exécute chaque transaction dans l'ordre contre l'horodatage engagé, scelle le bloc localement et compare le hash à celui que le séquenceur a engagé.
À la moindre divergence, une réplique s'arrête définitivement
La divergence est terminale par conception : réessayer scellerait d'autres blocs et s'éloignerait de la chaîne canonique en enterrant la cause. Une réplique arrêtée est le signal que les données publiées et le hash engagé ne concordent pas. Rien on-chain n'arbitre ce désaccord ; la page du modèle de confiance dit ce qui en découle.
Une réplique synchronisée sert le RPC de lecture standard depuis son propre état dérivé indépendamment. Ses soldes, reçus et en-têtes sont redérivés localement, pas des copies de confiance des réponses du séquenceur. La soumission de transactions est transmise au séquenceur ; une réplique n'accepte rien dans un mempool local.
Où se lit l'historique
Le séquenceur est optimisé pour répondre sur le présent et garde une courte fenêtre de blocs récents. L'historique complet est indexé dans la base de données de l'explorateur, alimentée en continu par le séquenceur, et c'est là que tout ce qui est historique trouve réponse. Les deux sont en aval des mêmes charges publiées, et une réplique peut reconstruire l'un comme l'autre à partir d'Ethereum et de la couche de disponibilité des données seules.