Interprétation de l'importance de la décentralisation de Rollup sous plusieurs angles

Auteur original : Shivanshu Madan

Compilation originale : Luffy, Foresight News

Une grande partie de la discussion sur Crypto Twitter tourne récemment autour de la décentralisation L2. Le Rollup que nous construisons est-il suffisamment décentralisé ? Sont-ils déjà sur la voie de la décentralisation ? Est-ce que ça importe?

Je vais explorer ces thèmes dans cet article. Avant de creuser, si vous ne savez pas déjà comment fonctionnent vraiment les Rollups, je vous suggère de lire rapidement cet article : Rollups pour les nuls.

L'idée de Rollup est en fait assez simple : elle veut que les participants hors chaîne effectuent des transactions qui peuvent ensuite être facilement vérifiées en chaîne. Avec Rollup, la "confiance" de la couche de base est étendue aux activités en dehors de sa blockchain. En retour, Rollup paie une somme modique (loyer) pour utiliser cette fiducie.

Avons-nous donc besoin d'un Rollup décentralisé ?

La réponse intuitive est : absolument nécessaire ! C'est l'esprit de la blockchain.

Cependant, je crois aussi que la réponse à cette question n'est pas un simple oui ou non. Au contraire, elle englobe de multiples aspects, qui doivent être analysés individuellement. Dans ce qui suit, j'explorerai cette question sous trois angles : la philosophie, la technologie et l'économie.

Perspective philosophique

Commençons par élever la conversation à un niveau supérieur : pourquoi nous soucions-nous de la décentralisation ?

Parce que nous voulons un avenir sans autorisation qui favorise l'innovation ouverte. Nous voulons que les utilisateurs puissent créer de nouvelles choses sans aucune restriction et sans avoir besoin de faire confiance à une seule entité.

Dans la courte histoire de la blockchain, de nombreux développeurs anonymes ont construit des choses incroyables. En fait, Bitcoin lui-même a été créé par une entité anonyme, et il pourrait bientôt devenir la monnaie de paiement mondiale utilisée par la majeure partie du monde. C'est le pouvoir de l'innovation sans autorisation !

La blockchain nous permet de travailler avec des personnes qui n'ont rien en commun et nous savons qu'il n'y a aucun moyen pour elles de briser cette confiance.

—— Preston Evans

La fondation décentralisée de réseaux sans confiance comme Bitcoin et Ethereum nous permet de construire un tel avenir. Évidemment, toute chaîne ayant une relation de confiance avec ces blockchains, comme Rollup, devrait également être décentralisée !

En fait, cela soulève une question intéressante et importante :

Si Rollup n'est pas décentralisé, cela signifie-t-il qu'Ethereum n'est pas décentralisé ?

Une façon légèrement optimiste de voir cela est que dans un monde sans autorisation, les Rollups devraient être autorisés à créer tout ce qu'ils veulent, y compris (mais sans s'y limiter) les chaînes autorisées, et les utilisateurs de ce Rollup seraient toujours en mesure de tirer parti de la sécurité de la couche sous-jacente. . Tant que la couche de base est décentralisée et que Rollup est "entièrement implémenté" (nous parlerons plus de "l'implémentation complète" dans la section technique), même les chaînes autorisées devraient pouvoir être utilisées en toute sécurité.

Mais la réalité est que la plupart des Rollups n'ont pas encore atteint le stade de la mise en œuvre complète et qu'ils n'offrent pas aux utilisateurs le niveau de sécurité et de confiance dont ils ont besoin.

Alors, quelle est la bonne implémentation de Rollup ? Voyons:

Point de vue technique

Pour vraiment comprendre les problèmes de décentralisation et de sécurité de Rollup, nous devons l'examiner à partir des premiers principes. Peu de gens peuvent mieux expliquer les premiers principes de la blockchain que Sreeram Kannan.

La blockchain est un grand livre distribué, et différents nœuds du réseau suivent des règles de protocole prédéterminées pour obtenir un consensus sur l'état du grand livre. Selon la façon dont ces nœuds voient le réseau, ils peuvent avoir des règles différentes pour confirmer l'état correct de leur propre réseau de grand livre.

Surtout dans Rollup, les nœuds complets et les clients légers ont des règles de confirmation différentes. Dans le Smart Contract Rollup (SCR) traditionnel, le Smart Contract (pont de vérification) a ses propres règles de confirmation. S'il n'y a pas d'événements indésirables, ces règles de confirmation finissent par coïncider dans ce que l'on appelle les "régions de cohérence". Comme son nom l'indique, dans une zone de consensus, tous les participants ont la même vue du réseau (et le même historique dans le grand livre).

Si toutes les règles de confirmation sont sûres, aucune mauvaise chose ne se produira. Comme Sreeram l'a partagé dans le post ci-dessus, 5 propriétés définissent principalement la sécurité de ces règles de confirmation.

• Croissance du grand livre - La chaîne de cumul devrait continuer à croître (vivacité)
• Résistant à la censure - tous les utilisateurs doivent pouvoir inclure n'importe quelle transaction dans la couche de base
• Résistant à la restructuration - les transactions ne peuvent pas être retirées une fois terminées
• Disponibilité des données - les données de transaction doivent être publiées quelque part
• Validité - les transactions et les transitions d'état doivent être valides

Les 2 premières propriétés définissent l'état "en direct" du système, tandis que les 3 dernières propriétés définissent l'état "sûr".

Examinons ces problèmes du point de vue de différents participants au Rollup et voyons lesquels peuvent être atténués sans décentralisation.

Différents acteurs s'appuient sur différents mécanismes de sécurité et de vivacité

Noeud complet :

Si vous exécutez un nœud complet, vous avez accès aux données publiées et pouvez les vérifier directement. Vous pouvez ensuite utiliser ces données pour exécuter vous-même des transactions et déterminer la validité des transactions et l'état final du Rollup après ces transactions.

Les conditions de sécurité restantes sont donc l'activité et la résistance à la recombinaison. Pour la résistance à la réorganisation, les nœuds complets s'appuient sur les validateurs de la chaîne de base et le protocole de consensus qu'elle utilise, tandis que pour la vivacité, les nœuds complets s'appuient sur l'implémentation Sequencer et Rollup.

Client léger :

La plupart des utilisateurs interagissent avec la blockchain en utilisant des clients légers pour récupérer les données de la blockchain. Il existe plusieurs types de nœuds légers :

• Validateurs d'état - vérifient la validité des transitions d'état
• Vérificateur de disponibilité des données - Vérifier la disponibilité des données
• Validateurs de consensus - vérifient la preuve de consensus de la couche de base
• Validateur complet - Valide tout ce qui précède

Si vous exécutez un client léger de validateur complet, vous pouvez vérifier si les données sont disponibles via l'échantillonnage de la disponibilité des données, vérifier la validité des transitions d'état via des preuves de validité ou des preuves de fraude, et vérifier si l'état suit le consensus de la couche de base (dans Ethereum ci-dessus , peut se faire en suivant le comité de synchronisation).

Ensuite, la condition de sécurité restante est la vivacité, et le client léger dépend du séquenceur et de l'implémentation de Rollup.

Contrat intelligent intégré (pont de vérification) :

Dans le SCR traditionnel, la "règle de confirmation" d'un contrat intelligent consiste à appliquer les 5 propriétés de sécurité :

• Croissance du grand livre grâce au protocole de remplacement du séquenceur
• Résister à la censure en imposant l'inclusion
• S'appuie sur l'état précédent pour l'anti-recombinaison
• Réaliser la disponibilité des données en soumettant DA à la couche de base *Validité vérifiée par preuve de validité/fraude

Les nœuds complets SCR s'appuient sur des contrats intelligents pour appliquer les propriétés de vivacité. Ils tirent leur résistance à la réorganisation de la couche de base.

Les nœuds légers s'appuient sur des contrats intelligents pour améliorer les propriétés de vivacité et absorber la DA et la résistance à la réorganisation de la couche de base. Ils peuvent vérifier les preuves de validité par eux-mêmes ou via des contrats intelligents.

Le consensus du SCR est de suivre la chaîne canonique définie par le smart contract.

Qu'en est-il des cumuls souverains ?

Les cumuls souverains n'ont pas de contrats intelligents (ponts de validation) pour faire respecter les conditions de validité ou de vivacité. Au lieu de cela, ils prouveront qu'ils "roulent" vers les nœuds Rollup en aval. Ces nœuds dépendent toujours de la disponibilité des données et de la résistance à la réorganisation de la couche de base.

Comme dans SCR, dans Sovereign Rollup, les nœuds ont besoin d'un mécanisme pour appliquer la propriété de vivacité. Pour définir la chaîne canonique, ils ont opté pour des mécanismes indépendants comme la diffusion de preuves p2p.

Qu'est-ce que tout cela a à voir avec la décentralisation ?

Qu'il s'agisse d'un smart contract Rollup ou d'un souverain Rollup, la propriété de vivacité provient de la bonne implémentation du Rollup. Comme nous l'avons vu plus haut, une implémentation correcte de Rollup doit inclure deux éléments importants :

• Mécanisme d'inclusion obligatoire ;
• Protocole de remplacement du séquenceur.

Les mécanismes d'inclusion obligatoire contribuent à accroître la résistance à la censure. Ce mécanisme permet aux utilisateurs de "forcer l'inclusion" de leurs transactions directement dans la couche de base. Tout utilisateur du Rollup peut alors forcer le retrait de ses fonds vers la couche de base. Par conséquent, même s'il n'y a qu'un seul nœud d'interclassement centralisé, il ne peut pas censurer les utilisateurs tant qu'il existe un mécanisme d'inclusion obligatoire mature.

Mais est-ce suffisant ?

Même si les utilisateurs sont libres de quitter, cela pourrait signifier que L2 n'a pas beaucoup d'incitation à continuer à fonctionner si la plupart des utilisateurs reviennent à L1. De plus, le mécanisme d'inclusion obligatoire a généralement un long temps d'attente et peut être assez coûteux à mettre en œuvre pour l'utilisateur moyen. La résistance à la censure fournie par ce mécanisme n'est pas entièrement pratique (ou en temps réel), on peut l'appeler "censure faible".

Ensuite, nous avons l'attribut d'activité final - la croissance du grand livre.

Si le donneur d'ordre centralisé fait quelque chose de mal, il peut arrêter la croissance de la chaîne Rollup en arrêtant simplement la production de blocs. Si cela se produit, l'utilisateur ne peut rien faire pour remettre le Rollup en ligne.

Pour résoudre ce problème, nous avons besoin d'un protocole de remplacement de trieur.

L'idée du protocole de remplacement de séquenceur est que si un séquenceur se comporte de manière malveillante, Rollup est capable de démarrer un nouveau séquenceur via la gouvernance. L'un des moyens d'y parvenir consiste à remplacer les nœuds de commande centralisés par des protocoles de commande décentralisés. Si le donneur d'ordre est décentralisé et ne monopolise pas la construction de blocs de Rollup, il sera alors presque impossible de bloquer la chaîne Rollup.

Ainsi, alors que les fonds des utilisateurs sont toujours en sécurité dans les Rollups via le mécanisme d'inclusion obligatoire, la création d'un protocole de remplacement de commande robuste aide à maintenir les Rollups en vie et offre une résistance pratique et en temps réel à la censure.

C'est tout?

pas complètement. D'un point de vue technique, il y a encore un aspect à considérer :

Et si les contrats intelligents eux-mêmes pouvaient être mis à niveau par le comité central de Rollup ? Disons que Rollup est actuellement correctement implémenté, mais demain le comité convient que nous n'avons plus besoin de contrats intelligents, mais plutôt de diffuser des preuves de l'état Rollup sur le réseau p2p.

Si, en tant qu'utilisateur de Rollup, vous n'êtes pas d'accord avec une telle mise à niveau, vous devriez pouvoir quitter Rollup avant la mise en œuvre de la mise à niveau (bien que ce ne soit pas une bonne expérience utilisateur et peut ne pas être bon pour l'entreprise). Cela peut être réalisé grâce à des "mises à jour de gouvernance retardées", comme une "période de notification", après laquelle les mises à niveau seront mises en œuvre. Les utilisateurs qui n'acceptent pas les mises à jour peuvent se retirer dans le délai de préavis.

L'extrême de la décentralisation est d'avoir des contrats intelligents complètement immuables. Ces contrats ne sont régis par aucun portefeuille multi-signatures ou autre comité, et une fois déployés, ils ne peuvent jamais être mis à niveau.

Bien sûr, cela a ses propres problèmes. S'il y a des bogues dans le code, ou si un événement majeur nécessite la mise à jour du contrat intelligent, la seule option pour Rollup est de bifurquer vers le nouveau contrat intelligent, tandis que les fonds des utilisateurs sont bloqués dans l'ancien contrat.

Malheureusement, l'état actuel de Rollup est loin de la mise en œuvre complète dont nous avons discuté ci-dessus. La plupart des Rollups sont encore en phase "d'exploration", essayant de les mettre en œuvre correctement.

Selon L2 BEAT, Fuel v1 et DeGate sont les deux seuls cumuls qui ont mûri pour atteindre toutes les conditions d'activité et de sécurité.

Perspective économique

Enfin, examinons l'économie du Rollup du point de vue des utilisateurs et des opérateurs de Rollup :

• Expérience utilisateur : les utilisateurs doivent bénéficier de prix avantageux et ne pas avoir à attendre trop longtemps pour les transactions ;
• Rollup Profit : les séquenceurs et les détenteurs de jetons doivent être rentables.

L'expérience utilisateur est optimisée lorsque les utilisateurs reçoivent des services de transaction rapides et bon marché.

La vitesse à laquelle les transactions sont finalisées dépend de la vitesse à laquelle la couche de base est finalisée. Les transactions peuvent être considérées comme définitives lorsque les données sur L1 sont finalisées. Cependant, les utilisateurs exécutant des nœuds complets peuvent également obtenir une finalité instantanée en exécutant simplement des transactions et en déterminant l'état final.

Mais il n'est pas pratique pour tout le monde d'exécuter un nœud complet. Par conséquent, un trieur centralisé est utile car il peut fournir aux utilisateurs une "confirmation en douceur" que leur transaction est incluse dans un bloc et sera finalisée. C'est suffisant pour la plupart des cas d'utilisation. Cependant, il s'appuie sur des institutions centralisées qui peuvent prendre des mesures défavorables.

Alors que certaines solutions de protocole alternatif de commande renoncent à cette propriété (car désavantageuse pour les utilisateurs), d'autres solutions, telles que le schéma de consensus PoS externe Espresso, peuvent fournir des garanties de pré-confirmation similaires sans le risque d'une commande centralisée.

Qu'en est-il des coûts d'utilisation ?

Le coût explicite d'une transaction Rollup est généralement :

Coût du gaz L2 = Coût du gaz L1 + Frais de séquenceur. Les trieurs centralisés rationnels veulent toujours maximiser leurs profits, quitte à répercuter des coûts plus élevés sur les utilisateurs. Cependant, il convient de noter que cela ne peut pas non plus nécessairement être résolu par un mécanisme de tri décentralisé. Même les nœuds PoS d'un ordonnateur décentralisé veulent maximiser leurs propres profits.

En fait, cela crée un problème d'inadéquation, où Rollup peut ne pas vouloir remettre les bénéfices à des séquenceurs externes.

Rollup Profit : En plus des frais de séquenceur, Rollup peut également générer des bénéfices en extrayant le MEV des transactions des utilisateurs. Cette MEV est souvent difficile à attribuer car il est difficile de savoir si le donneur d'ordre inclut certaines de ses propres transactions en amont dans le package de transactions.

Si Rollup est remplacé par un consensus PoS externe, ils remettront ce MEV à un opérateur externe.

Il convient de noter que ces deux problèmes de Rollup cédant des revenus à des mécanismes externes peuvent être résolus par des "accords de transaction" entre Rollup et des mécanismes externes.

Cependant, comme expliqué dans l'exposé de Jon Charbonneau lors du Sommet modulaire et du post suivant, une meilleure idée pourrait être de confier la commande de la gouvernance Rollup à un ensemble de nœuds validés. Ces nœuds peuvent être stratégiquement choisis pour être dispersés géographiquement, et la gouvernance peut simplement expulser les mauvais acteurs.

Cela pourrait être une solution qui fait d'une pierre deux coups, car elle permet à Rollup de conserver ses bénéfices en interne, tout en atténuant les inconvénients des trieurs centralisés.

Mais au contraire, dans le cas d'une rotation limitée du séquenceur, le séquenceur peut avoir un comportement à courte vue, ce qui peut conduire à une tarification monopolistique/des prix abusifs, nuisant davantage aux intérêts des utilisateurs sacrifiés de Rollup.

Dans tous les cas, pour que Rollup soit rentable pour les utilisateurs, un protocole de remplacement du trieur est nécessaire.

en conclusion

Quelle que soit la voie empruntée par Rollup, il est crucial qu'il vise une implémentation complète avec un protocole de remplacement de séquenceur mature, une inclusion obligatoire et des mécanismes de mise à jour de la gouvernance des décalages. S'il existe un mécanisme d'inclusion obligatoire et de retard des mises à jour, les fonds des utilisateurs seront en sécurité, que le trieur soit centralisé ou non.

Cependant, un protocole de remplacement de séquenceur robuste peut améliorer les garanties de vivacité et potentiellement améliorer l'économie pour les utilisateurs de Rollup.