Pour tous / Comment ça marche
Le trajet d'une transaction
De votre portefeuille à Ethereum en cinq étapes, la plupart plus rapides que ce que vous pouvez voir. Cette page est la machine ; la page des confirmations est ce que chaque étape promet.
Le trajet
Vous signez quelque chose dans votre portefeuille et vous l'envoyez. Cela arrive sur un ordinateur, le séquenceur, qui le note pour qu'il ne puisse pas être perdu, fait le travail tout de suite, et connaît la réponse avant que vous ayez lâché le bouton. Plusieurs fois par seconde, le séquenceur regroupe les réponses qu'il vient de produire, signe le paquet et le publie. Un peu moins souvent, il enveloppe ces paquets dans un bloc qui ressemble exactement à un bloc Ethereum, celui que votre portefeuille et l'explorateur vous montrent.
Ensuite, séparément, il écrit tout ce que contenait ce bloc et envoie une empreinte de la liste à Ethereum. N'importe qui peut récupérer la liste, la rejouer et vérifier qu'il obtient la même réponse. Cette dernière étape est ce qui fait de Pickle une partie d'Ethereum plutôt qu'un simple ordinateur rapide qui l'affirme.
1. Vous l'envoyez. Votre portefeuille signe la transaction et la soumet en JSON-RPC standard au séquenceur, le processus unique qui fait tourner la chaîne.
2. Elle est admise et rendue durable. Le séquenceur retrouve le signataire, place la transaction dans une file bornée, et l'ajoute à un journal vérifié par somme de contrôle sur disque avant de l'exécuter, pour qu'une transaction acquittée survive à une panne.
3. Elle s'exécute tout de suite. Un coordinateur unique valide les transactions dans l'ordre d'admission. Le reçu existe avant tout bloc.
4. Elle est préconfirmée, puis confirmée. À une cible d'ordonnancement de 10 millisecondes, les transactions de l'intervalle sont scellées dans un mini-bloc signé ; à une cible d'ordonnancement de 250 millisecondes, les mini-blocs de l'intervalle sont enveloppés dans un bloc EVM standard portant un numéro que tout outil comprend.
5. Elle est engagée sur Ethereum. Chaque bloc scellé produit une charge portant la liste complète de ses transactions, stockée dans une couche de disponibilité des données, et un engagement par cible d'ordonnancement de 60 secondes est posté dans un contrat de boîte de réception sur Ethereum. À partir de là, quiconque fait tourner une réplique ré-exécute chaque transaction et arrive au même état.
La couche RPC retrouve le signataire et place la transaction dans une file d'admission bornée avec un plafond par expéditeur ; une file pleine renvoie une erreur plutôt que de faire croître la mémoire sans limite. Chaque transaction acceptée est ajoutée à un journal d'écriture anticipée vérifié par somme de contrôle et rendue durable avant de s'exécuter, un fsync par lot. Un coordinateur d'exécution unique valide dans l'ordre d'admission et n'exécute jamais le même expéditeur en parallèle, ce qui préserve la sûreté des nonces sans étape de réordonnancement de mempool. L'exécution est immédiate, donc le reçu existe avant que le bloc qui le contient soit scellé.
Un producteur scelle un mini-bloc à la cible d'ordonnancement de 10 ms : les transactions, reçus et logs de l'intervalle, un hash de différentiel d'état, un horodatage à la microseconde et une signature du séquenceur sur l'en-tête. Un second producteur scelle un bloc EVM au format Cancun à la cible d'ordonnancement de 250 ms enveloppant les mini-blocs de l'intervalle ; l'horodatage du bloc suivant est fixé au scellement du précédent, donc une transaction qui lit l'horodatage du bloc voit la valeur que l'en-tête engage. Chaque bloc scellé émet une charge de dérivation, liste complète des transactions, plage de blocs, hash parent, hash du bloc et horodatage engagé, vers une couche de disponibilité des données adressée par contenu, et une enveloppe par cible d'ordonnancement de 60 s est engagée dans la boîte de réception L1, avec le calldata en repli.
Les chiffres de 10 millisecondes, 250 millisecondes et 60 secondes sont des cibles d'ordonnancement, les intervalles que vise le séquenceur. Aucun n'est une garantie de latence et aucun n'est une affirmation de débit.
Le cycle de vie, étape par étape
- Un client soumet une transaction signée en JSON-RPC standard.
- La couche RPC retrouve le signataire et place la transaction dans une file d'admission bornée, avec un plafond par expéditeur. Une file pleine renvoie une erreur plutôt que de faire croître la mémoire sans limite.
- Un coordinateur d'exécution unique valide les transactions dans l'ordre d'admission. Le même expéditeur n'est jamais exécuté en parallèle, ce qui préserve la sûreté des nonces sans étape de réordonnancement de mempool.
- L'exécution est immédiate. Le reçu existe avant que le bloc EVM qui le contient soit scellé.
- Chaque transaction acceptée est ajoutée à un journal d'écriture anticipée vérifié par somme de contrôle et rendue durable avant de s'exécuter, un fsync par lot, pour qu'une transaction acquittée survive à une panne.
Trois façons d'exécuter
Le séquenceur n'exécute pas chaque transaction de la même façon. Il reconnaît trois formes et prend pour chacune le chemin correct le plus court :
- Un simple transfert d'ETH prend un chemin natif, sans démarrer la machine virtuelle du tout.
- Le transfert ERC-20 canonique prend un chemin rapide qui déplace directement l'emplacement de solde et émet l'événement standard, avec le même résultat que la machine complète.
- Tout le reste passe par l'EVM générale, qui est revm figé sur le hardfork Cancun.
Les trois facturent du gas standard et répartissent le frais de la même manière, donc vous ne pouvez pas dire d'après le frais quel chemin a été pris, et vous ne devriez pas en avoir besoin. Les chemins rapides existent parce que l'essentiel du trafic d'une chaîne est constitué des deux types de transaction les plus simples, et c'est là que va le temps.
Pourquoi c'est déterministe
Deux choses que d'autres chaînes laissent à l'opérateur sont ici des constantes de compilation : le hardfork d'exécution et le prix minimum du gas. Rendues réglables, l'une ou l'autre permettrait à une réplique de rejeter ou de re-tarifer une transaction que le séquenceur a acceptée, et la dérivation indépendante s'arrêterait. Le même raisonnement fixe l'horodatage du bloc suivant au scellement précédent, et fait de l'intervalle des mini-blocs un paramètre de consensus plutôt qu'un réglage par opérateur : une réplique doit s'accorder sur la façon de découper le flux pour reproduire les mêmes hashs.
Pourquoi c'est construit ainsi
La décision inhabituelle est d'exécuter avant de sceller. Sur la plupart des chaînes, une transaction attend le bloc suivant et s'exécute pendant sa construction ; ici elle s'exécute à l'arrivée et les blocs sont assemblés ensuite à partir de résultats qui existent déjà. C'est ce qui rend le premier moment rapide, et c'est pourquoi le mini-bloc existe séparément du bloc : le mini-bloc est le séquenceur qui pose sa signature sur des résultats qu'il a déjà calculés, tandis que le bloc ordinaire arrive à son propre rythme derrière. Ce que chaque moment garantit est sur la page des confirmations, et où finit le registre est sur la page du règlement.