Le 6 juin 2023, OP Mainnet est passé à Bedrock, et l'ensemble du processus de migration a été conçu pour être vérifiable et reproductible.

Ce n'était pas une mince affaire, nécessitant des contributions de la part des membres de la communauté à travers le Collectif entier. La migration réussie vers Bedrock a marqué le début d'une nouvelle ère pour Optimism, une ère dans laquelle nous pouvons accélérer nos progrès vers la décentralisation technique et la réalisation de la vision de la Superchain.

Il y a beaucoup de choses à célébrer concernant la migration, mais il y a un détail en particulier que l'équipe d'OP Labs est fière de partager, c'est que l'ensemble du processus de migration a été conçu pour être vérifiable et reproductible !

Cet article de blog récapitule le travail effectué par les ingénieurs d'OP Labs pour préparer le jour de la migration, et explique comment exécuter le script de migration et confirmer que la mise à niveau s'est déroulée comme prévu.

La migration a été réalisée à l'aide d'un outil de migration open-source bien documenté et audité, conçu par l'équipe d'OP Labs. Cet outil a pris la base de données de l'ancien réseau et l'a convertie dans un format compatible avec le réseau Bedrock.

En pratique, la mise à niveau a consisté à migrer l'ERC-20 Wrapped Ether vers l'Ether natif et à configurer des pré-déploiements, qui fonctionnent de manière similaire aux précompilations d'Ethereum et sont utilisés pour des opérations spéciales telles que le bridging ou le minting.

L'équipe a répété pendant des semaines, en suivant dans les moindres détails ce qui devait se passer à chaque étape du processus. Chaque élément de la liste de contrôle de la migration a été méticuleusement spécifié afin que l'exécution ne demande qu'un minimum d'effort. L'objectif était de rendre le processus aussi "ennuyeux" que possible afin d'éviter les erreurs d'opérateur qui pourraient survenir si l'on devait trop réfléchir au processus sur le moment. Chaque réseau de répétition a fonctionné sur un shadow fork, de la même manière que les développeurs de Ethereum L1 se sont entraînés pour la mise à jour the merge.

Le processus de migration a fait l'objet d'un audit Sherlock au cours duquel des problèmes ont été détectés et corrigés. Un exemple de problème découvert par le processus d'audit était un bug qui pouvait permettre à un utilisateur d'interrompre le retrait à mi-chemin en écrivant un état malveillant dans le stockage utilisé comme entrée par l'outil de migration. Avant la migration, l'équipe a passé le code au peigne fin à la recherche de tout autre problème, aussi mineur soit-il. Le jour de la migration, la diligence de l'équipe a prévalu, puisque la mise à niveau s'est déroulée sans heurts et que le séquenceur a été rétabli en trois heures.

La procédure nécessitait certains fichiers d'entrée, obtenus par synchronisation d'un nœud existant. Après la synchronisation, le nœud hérité a produit les fichiers témoins requis, et l'outil de migration les a utilisés pour vérifier le bon déroulement de la migration complète. Grâce à cette configuration, toute personne capable de synchroniser un nœud existant peut utiliser le script de migration pour vérifier que la migration s'est déroulée comme nous l'avions annoncé !

Nous avons conçu le résultat de la migration de manière à ce qu'il soit vérifiable, pour une plus grande transparence. La sortie génère une racine d'état unique correspondant à une migration réussie. Toute divergence ou modification des informations au cours de la migration entraînerait la production d'une racine d'état incorrecte. Par conséquent, la racine d'état sert de test vérifiable de la fidélité du processus de migration.

Le code nécessaire à la migration est disponible dans le dépôt optimism-legacy. Nous l'avons séparé du dépôt OP Mainnet pour simplifier les mises à jour de la base de code principale.

Afin d'exécuter le script de migration, vous avez d'abord besoin d'un fichier "témoin" spécial, qui peut être généré par la synchronisation avec un nœud l2geth existant. La variable d'environnement L2GETH_STATE_DUMP_PATH doit être définie à cet effet.

Une fois que vous disposez d'un système hérité entièrement synchronisé, vous pouvez exécuter la commande suivante à partir du paquet op-chain-ops. Veillez à examiner attentivement tous les arguments et toutes les variables d'environnement, car ils peuvent nécessiter des ajustements en fonction de votre configuration.

INPUT_DATA=$MONOREPO_BASE/packages/migration-data/data DEPLOY_CONFIG=$MONOREPO_BASE/packages/contracts-bedrock/deploy-config/mainnet.json DEPLOYMENTS=$MONOREPO_BASE/packages/contracts/deployments,$MONOREPO_BASE/packages/contracts-periphery/deployments,$MONOREPO_BASE/packages/contracts-bedrock/deployments DB_PATH=/mnt/geth

go run cmd/op-migrate/main.go \
 --l1-rpc-url "$L1_RPC" \
 --ovm-addresses $INPUT_DATA/ovm-addresses.json \
 --ovm-allowances $INPUT_DATA/ovm-allowances.json \
 --ovm-messages $INPUT_DATA/ovm-messages.json \
 --witness-file $DB_PATH/l2geth-state \
 --db-path $DB_PATH \\
 --deploy-config $DEPLOY_CONFIG \
 --network mainnet \
 --hardhat-deployments $DEPLOYMENTS \
 --rollup-config-out=$MONOREPO_BASE/rollup.json

Le fichier témoin comprend des informations sur tous les comptes qui détenaient de l'Ether, afin que celui-ci puisse être transféré de sa représentation ERC20 au format natif. Il contient également des informations sur les comptes qui ont initié des retraits afin de garantir que ces transactions puissent passer en toute transparence au nouveau système de retrait. Ainsi, les utilisateurs n'auront pas à recommencer leur retrait après la mise à niveau du réseau.

Si vous n'êtes pas en mesure de synchroniser complètement un système existant, vous devriez quand même pouvoir télécharger la base de données au bloc juste avant ou juste après la migration à l'aide de la commande suivante :

wget https://datadirs.optimism.io/mainnet-bedrock.tar.zst

Vous saurez que la migration a été reproduite avec succès si vous pouvez démarrer op-geth sur la base de données migrée et la synchroniser avec le dernier point du réseau.

💡 Pour une expérience plus conviviale de la synchronisation, nous avons apporté quelques améliorations via cette PR.

La mise à niveau vers Bedrock a transformé l'OP Stack en un système plus souple et plus modulaire. OP Mainnet peut désormais prendre en charge plusieurs clients et plusieurs systèmes de preuve, et les coûts des données ont été considérablement réduits. Bedrock a également posé les bases de la vision de la Superchain. Elle nous prépare à un avenir où plusieurs chaînes fusionneront, ce qui nous permettra de faire face à une croissance sans précédent dans un écosystème blockchain harmonieux.

Si vous souhaitez contribuer à cette vision, commencez par voir ce que permet l'OP Stack.

🚀

Le 6 juin 2023, OP Mainnet est passé à Bedrock, et l'ensemble du processus de migration a été conçu pour être vérifiable et reproductible.

Ce n'était pas une mince affaire, nécessitant des contributions de la part des membres de la communauté à travers le Collectif entier. La migration réussie vers Bedrock a marqué le début d'une nouvelle ère pour Optimism, une ère dans laquelle nous pouvons accélérer nos progrès vers la décentralisation technique et la réalisation de la vision de la Superchain.

Il y a beaucoup de choses à célébrer concernant la migration, mais il y a un détail en particulier que l'équipe d'OP Labs est fière de partager, c'est que l'ensemble du processus de migration a été conçu pour être vérifiable et reproductible !

Cet article de blog récapitule le travail effectué par les ingénieurs d'OP Labs pour préparer le jour de la migration, et explique comment exécuter le script de migration et confirmer que la mise à niveau s'est déroulée comme prévu.

La migration a été réalisée à l'aide d'un outil de migration open-source bien documenté et audité, conçu par l'équipe d'OP Labs. Cet outil a pris la base de données de l'ancien réseau et l'a convertie dans un format compatible avec le réseau Bedrock.

En pratique, la mise à niveau a consisté à migrer l'ERC-20 Wrapped Ether vers l'Ether natif et à configurer des pré-déploiements, qui fonctionnent de manière similaire aux précompilations d'Ethereum et sont utilisés pour des opérations spéciales telles que le bridging ou le minting.

L'équipe a répété pendant des semaines, en suivant dans les moindres détails ce qui devait se passer à chaque étape du processus. Chaque élément de la liste de contrôle de la migration a été méticuleusement spécifié afin que l'exécution ne demande qu'un minimum d'effort. L'objectif était de rendre le processus aussi "ennuyeux" que possible afin d'éviter les erreurs d'opérateur qui pourraient survenir si l'on devait trop réfléchir au processus sur le moment. Chaque réseau de répétition a fonctionné sur un shadow fork, de la même manière que les développeurs de Ethereum L1 se sont entraînés pour la mise à jour the merge.

Le processus de migration a fait l'objet d'un audit Sherlock au cours duquel des problèmes ont été détectés et corrigés. Un exemple de problème découvert par le processus d'audit était un bug qui pouvait permettre à un utilisateur d'interrompre le retrait à mi-chemin en écrivant un état malveillant dans le stockage utilisé comme entrée par l'outil de migration. Avant la migration, l'équipe a passé le code au peigne fin à la recherche de tout autre problème, aussi mineur soit-il. Le jour de la migration, la diligence de l'équipe a prévalu, puisque la mise à niveau s'est déroulée sans heurts et que le séquenceur a été rétabli en trois heures.

La procédure nécessitait certains fichiers d'entrée, obtenus par synchronisation d'un nœud existant. Après la synchronisation, le nœud hérité a produit les fichiers témoins requis, et l'outil de migration les a utilisés pour vérifier le bon déroulement de la migration complète. Grâce à cette configuration, toute personne capable de synchroniser un nœud existant peut utiliser le script de migration pour vérifier que la migration s'est déroulée comme nous l'avions annoncé !

Nous avons conçu le résultat de la migration de manière à ce qu'il soit vérifiable, pour une plus grande transparence. La sortie génère une racine d'état unique correspondant à une migration réussie. Toute divergence ou modification des informations au cours de la migration entraînerait la production d'une racine d'état incorrecte. Par conséquent, la racine d'état sert de test vérifiable de la fidélité du processus de migration.

Le code nécessaire à la migration est disponible dans le dépôt optimism-legacy. Nous l'avons séparé du dépôt OP Mainnet pour simplifier les mises à jour de la base de code principale.

Afin d'exécuter le script de migration, vous avez d'abord besoin d'un fichier "témoin" spécial, qui peut être généré par la synchronisation avec un nœud l2geth existant. La variable d'environnement L2GETH_STATE_DUMP_PATH doit être définie à cet effet.

Une fois que vous disposez d'un système hérité entièrement synchronisé, vous pouvez exécuter la commande suivante à partir du paquet op-chain-ops. Veillez à examiner attentivement tous les arguments et toutes les variables d'environnement, car ils peuvent nécessiter des ajustements en fonction de votre configuration.

INPUT_DATA=$MONOREPO_BASE/packages/migration-data/data DEPLOY_CONFIG=$MONOREPO_BASE/packages/contracts-bedrock/deploy-config/mainnet.json DEPLOYMENTS=$MONOREPO_BASE/packages/contracts/deployments,$MONOREPO_BASE/packages/contracts-periphery/deployments,$MONOREPO_BASE/packages/contracts-bedrock/deployments DB_PATH=/mnt/geth

go run cmd/op-migrate/main.go \
 --l1-rpc-url "$L1_RPC" \
 --ovm-addresses $INPUT_DATA/ovm-addresses.json \
 --ovm-allowances $INPUT_DATA/ovm-allowances.json \
 --ovm-messages $INPUT_DATA/ovm-messages.json \
 --witness-file $DB_PATH/l2geth-state \
 --db-path $DB_PATH \\
 --deploy-config $DEPLOY_CONFIG \
 --network mainnet \
 --hardhat-deployments $DEPLOYMENTS \
 --rollup-config-out=$MONOREPO_BASE/rollup.json

Le fichier témoin comprend des informations sur tous les comptes qui détenaient de l'Ether, afin que celui-ci puisse être transféré de sa représentation ERC20 au format natif. Il contient également des informations sur les comptes qui ont initié des retraits afin de garantir que ces transactions puissent passer en toute transparence au nouveau système de retrait. Ainsi, les utilisateurs n'auront pas à recommencer leur retrait après la mise à niveau du réseau.

Si vous n'êtes pas en mesure de synchroniser complètement un système existant, vous devriez quand même pouvoir télécharger la base de données au bloc juste avant ou juste après la migration à l'aide de la commande suivante :

wget https://datadirs.optimism.io/mainnet-bedrock.tar.zst

Vous saurez que la migration a été reproduite avec succès si vous pouvez démarrer op-geth sur la base de données migrée et la synchroniser avec le dernier point du réseau.

💡 Pour une expérience plus conviviale de la synchronisation, nous avons apporté quelques améliorations via cette PR.

La mise à niveau vers Bedrock a transformé l'OP Stack en un système plus souple et plus modulaire. OP Mainnet peut désormais prendre en charge plusieurs clients et plusieurs systèmes de preuve, et les coûts des données ont été considérablement réduits. Bedrock a également posé les bases de la vision de la Superchain. Elle nous prépare à un avenir où plusieurs chaînes fusionneront, ce qui nous permettra de faire face à une croissance sans précédent dans un écosystème blockchain harmonieux.

Si vous souhaitez contribuer à cette vision, commencez par voir ce que permet l'OP Stack.

🚀