Explication détaillée du processus OP Stack Rollup et du code correspondant
TechFlow SélectionTechFlow Sélection
Explication détaillée du processus OP Stack Rollup et du code correspondant
OP Stack est une pile de développement standardisée, partagée et open source qui sous-tend Optimism et est maintenue par le collectif Optimism.
Dédié à des analyses Web3 approfondiesRédaction : Rayer
Optimism Bedrock est la version actuelle de l'OP Stack. La version Bedrock fournit les outils nécessaires pour lancer une blockchain Optimistic Rollup de qualité en production. À ce stade, les API des différentes couches de l'OP Stack restent étroitement couplées à la configuration du Rollup du Stack.
Le rollup principal de l'Op-stack repose sur deux services.
-
op-batcher : responsable de lire périodiquement les transactions présentes sur le sequencer et de les regrouper (rollup) vers la couche de disponibilité des données (DA) de la chaîne.
-
op-proposer : responsable de soumettre l'état des transactions au contrat.
Architecture du Rollup
op-batcher
Diagramme de flux d'exécution d'op-batcher
Logique d'exécution de loadBlocksInfoState
loadBlocksInfoState se charge de lire tous les blocs depuis le dernier bloc lu précédemment, c'est-à-dire les blocs encore non lus.
Son processus global est le suivant :
Code source :
loadBlocksIntoState effectue les actions suivantes :
1. Récupérer l'état de synchronisation du sequencer.
Ligne 153 : appel de la fonction calculateL2BlockRangeToStore.
-
calculateL2BlockRangeToStore récupère et détermine le numéro de bloc de départ et de fin L2 à soumettre. Le bloc initial correspond au bloc L2 sécurisé le plus haut actuel, tandis que le bloc final correspond au bloc L2 le plus haut mais encore non sécurisé.
Ligne 164 : une fois obtenus les blocs de début et de fin à soumettre, on récupère les informations des blocs à partir du bloc initial, en appelant la fonction loadBlockIntoState pour récupérer chaque bloc.
-
loadBlockIntoState vérifie les informations du bloc ainsi que celles de geth ; s'il n'y a pas d'erreur, ligne 200, elle appelle la fonction
AddL2Blockpour ajouter le bloc à la liste blocks []*types.Block du channelManager.
Lignes 165 à 168 : vérification si un bloc doit être resoumis. Si oui, l.lastStoredBlock est réinitialisé à eth.BlockID{} ; sinon, ligne 173, l.lastStoredBlock est mis à jour avec eth.ToBlockID(block), et latestBlock prend la valeur du bloc courant.
Ligne 177 : L2BlockToBlockRef extrait les informations de base L2BlockRef à partir de la source de référence du bloc L2, revenant aux données de genèse si nécessaire selon le numéro de bloc.
Logique d'exécution de publishStateToL1
publishStateToL1 soumet toutes les transactions en file d'attente à la couche L1 jusqu'à ce qu'il n'y ait plus de transaction ou qu'une erreur survienne.
Code source :
1. publishStateToL1 boucle pour envoyer chaque transaction en file d'attente vers le réseau Layer1.
Ligne 377 : appel de publishTxToL1.
publishTxToL1 contient la logique de soumission d'une transaction unique à L1. Cette méthode collecte les données à soumettre, construit la transaction et l'envoie au réseau Layer1, puis place la transaction envoyée dans le canal receiptCh chan TxReceipt[T].
-
Ligne 429 :
l1Tip: récupère le tip (sommet) actuel de L1 sous forme de L1BlockRef. On suppose que le contexte transmis est un contexte de cycle de vie, donc il est encapsulé avec un délai d'expiration réseau interne. -
Ligne 434 :
recordL1Tip: remplace l'ancien L1BlockRef par le nouveau L1BlockRef obtenu via l1Tip. -
Ligne 437 :
TxData: collecte les données des transactions à rollup. TxData renvoie les données de la prochaine transaction à soumettre à L1. Actuellement, chaque transaction utilise une seule trame. Si le canal en attente est plein, seul le reste des trames du canal est retourné, jusqu'à ce que l'envoi complet réussisse sur L1. S'il n'y a aucune trame en attente, elle renvoie io.EOF. -
Ligne 447 :
sendTransactionenvoie la transaction à la couche 1 et met à jour son statut dans le canal receiptCh chan TxReceipt[T] ; sendTransaction crée une transaction à partir des « données » fournies et la soumet à l'adresse de réception des batches. Elle utilise actuellement le « txmgr » sous-jacent pour gérer l'envoi des transactions et la gestion des frais. Il s'agit d'une méthode bloquante qui ne doit pas être appelée simultanément.
handleReceipt
handleReceipt récupère l'état du traitement des transactions depuis le canal et supprime les transactions traitées avec succès de ce canal.
Code source :
op-proposer
Diagramme de flux
Flux d'exécution détaillé
FetchNextOutputInfo
FetchNextOutputInfo : récupère la sortie (output) des blocs sur L2 afin de faciliter leur assemblage et soumission ultérieure. La structure de sortie retournée est la suivante :
type OutputResponse struct {
Version Bytes32 json:"version"
OutputRoot Bytes32 json:"outputRoot"
BlockRef L2BlockRef json:"blockRef"
WithdrawalStorageRoot common.Hash json:"withdrawalStorageRoot"
StateRoot common.Hash json:"stateRoot"
Status *SyncStatus json:"syncStatus"
}
Code source :
-
Ligne 224 : NextBlockNumber : récupère l'intervalle de blocs à soumettre lors du prochain batch. Cet intervalle est calculé comme suit : latestBlockNumber() + SUBMISSION_INTERVAL. La valeur de SUBMISSION_INTERVAL peut être spécifiée lors du déploiement du contrat L2OutputOracle.
-
Ligne 230 : appel de
FetchCurrentBlockNumberpour obtenir le numéro du bloc actuel. -
Lignes 236 à 241 : après vérification que nextCheckpointBlock respecte les règles, appel de
FetchOutputpour récupérer sur L2 le stateRoot à soumettre.
Code de FetchCurrentBlockNumber :
Ligne 254 : SyncStatus : récupère les états et informations de blocs SafeL2 et FinalizedL2 de L2.
Code de FetchOutput :
Ligne 279 : OutputAtBlock : récupère l'output selon la hauteur du bloc, incluant le stateRoot. En réalité, cela appelle eth_getProof pour calculer et obtenir le stateRoot. Le flux d'appel du code peut être consulté sur le schéma ci-dessus. Remarque : ici, le stateRoot n'est pas soumis pour chaque bloc individuellement, mais plutôt calculé pour un groupe de blocs selon la valeur configurée de SUBMISSION_INTERVAL, avant d'être soumis au contrat L2OutputOracle.
send Transaction
-
sendTransaction : utilise l'output pour construire la transaction de soumission du stateRoot, puis envoie cette transaction à la chaîne de niveau 1. Voici les détails des données empaquetées dans la transaction :
return abi.Pack(
"proposeL2Output",
output.OutputRoot,
new(big.Int).SetUint64(output.BlockRef.Number),
output.Status.CurrentL1.Hash,
new(big.Int).SetUint64(output.Status.CurrentL1.Number)
)
Code source :
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@UpchainDAO
