Cours du Layer3

Penser à ce qui suit : Imaginons que nous en ayons OP_CAT et qu’il nous ait effectivement donné une introspection, des STARK + capacité de transport d’état (pour construire des rollups, des validiums, etc.), ou même d’autres opcodes qui le résolvent encore plus proprement (faites votre choix parmi OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV <insert 64-bit="" arithmetic="" opcodes="" here="">, ) À quoi ressemblerait la construction L2 idéale pour Bitcoin ? Ce que nous ne voulons pas faire : répéter le playbook d’Ethereum : 200 équipes concurrentes construisant des L2 différents, une interconnectivité/composabilité médiocre qui se disputent les mêmes utilisateurs, que voulons-nous faire ? Quelles leçons pouvons-nous tirer d’Ethereum ? Gardez à l’esprit que nous ne pouvons pas (et que nous ne voulons pas) faire des rollups basés. Le L1 est trop lent pour cela, et nous ne voulons pas d’une couche de base MEV de cette nature. Gardez également à l’esprit que nous voulons : - Un système de transaction à TPS élevé (Lightning sans canaux en gros) - Certains voudront plus d’expressivité (pour les prêts de stablecoins sans confiance, les swaps AMM, les coffres-forts, les plans d’héritage, les produits à effet de levier) Si ces deux types de systèmes doivent exister sur la même couche d’exécution, ou est-il préférable de séparer les paiements des applications avec des files d’attente de séquençage différentes (j’ai tendance à le croire) - peut-être voulons-nous aller dans une direction Celestia en faisant un zkVM L2 et tous les autres systèmes en tant que L3, des files d’attente distinctes mais une agrégation via le L2. Faire de vrais rollups pour quoi que ce soit à grande échelle est fondamentalement hors de question pour la vision de fin de partie étant donné le faible débit du L1 et les besoins en DA (et l’ajout de blobs semble très peu probable), donc nous utiliserions très probablement une saveur de validiums + couche DA externe, zk-plasmas ou des architectures basées sur la validation côté client comme Miden. De plus, nous devrions explorer si nous voulons des systèmes ZK purs ou des tests hybrides (« ZK optimiste », voir Fuel pour la référence) pour maximiser encore plus le débit. L’une d’entre elles est de laisser le marché libre gagner et de voir ce qui se passe, mais c’est ce qu’Ethereum a fait. Même si nous tirons les leçons avec nous et que les équipes essaient de se coordonner autour de solutions d’agrégation uniques dès le départ, il n’y a aucune garantie que cela fonctionnera. Nous n’avons pas non plus la possibilité d’enchâsser une couche d’exécution particulière via la L1. Pourtant, il est clair pour moi que les STARK présentent la meilleure voie pour tous les éléments suivants : - Paiements minimisés par la confiance (sans canaux, routage ou exigences de liquidité) - Expressivité (pour ceux qui le veulent) - Confidentialité (VM ZK-privacy complètes) - Réaliser tout ce qui précède sans introduire d’hypothèses cryptographiques exotiques, de configurations fiables, etc. Vous pouvez vous demander quelle est la finalité à cause de la latence du L1, mais il est clair qu’il peut être adressé à un degré satisfaisant avec des séquenceurs liés pour des pré-confs rapides. Nous avons donc tous les outils, que faisons-nous pour obtenir le meilleur résultat possible ? Bien que le BTC devrait évidemment être la monnaie de tous ces systèmes (et payer les frais/gaz), il y a la dernière (ou peut-être la première) question sur la façon de réaliser tout cela sans introduire un jeton L2 principalement contrôlé par une fondation avec trop de contrôle. Je pense qu’un système de paiement uniquement peut fonctionner sans jeton de gouvernance (avec juste un séquençage central + des sorties unilatérales contre la censure), mais j’en doute pour quoi que ce soit d’expressif. Alors que la plupart des fondations/DAO ont pour objectif la décentralisation, mettre autant de pouvoir entre les mains d’une organisation centralisée, même dans une phase d’amorçage, me semble sous-optimal si nous voulons une sorte d’approche collective dès le départ pour atténuer les risques de fragmentation. Ce serait formidable d’entendre ce que les autres pensent de personnes ayant de l’expérience dans d’autres écosystèmes comme Ethereum, Celestia, Polygon, Cosmos et également curieuses de savoir comment les équipes L2 actuelles travaillant sur Bitcoin pensent à ces questions (par exemple Alpen, Chainway, Starkware). N’hésitez pas à intervenir dans les commentaires !</insert>

Penser à ce qui suit : Imaginons que nous en ayons OP_CAT et qu’il nous ait effectivement donné une introspection, des STARK + capacité de transport d’état (pour construire des rollups, des validiums, etc.), ou même d’autres opcodes qui le résolvent encore plus proprement (faites votre choix parmi OP_TXHASH, OP_CCV, OP_MERKLEBRANCHVERIFY, OP_STARK_VERIFY, OP_M31ADD, OP_M31SUB, OP_M31MUL, OP_M31INV <insert 64-bit="" arithmetic="" opcodes="" here="">, ) À quoi ressemblerait la construction L2 idéale pour Bitcoin ? Ce que nous ne voulons pas faire : répéter le playbook d’Ethereum : 200 équipes concurrentes construisant des L2 différents, une interconnectivité/composabilité médiocre qui se disputent les mêmes utilisateurs, que voulons-nous faire ? Quelles leçons pouvons-nous tirer d’Ethereum ? Gardez à l’esprit que nous ne pouvons pas (et que nous ne voulons pas) faire des rollups basés. Le L1 est trop lent pour cela, et nous ne voulons pas d’une couche de base MEV de cette nature. Gardez également à l’esprit que nous voulons : - Un système de transaction à TPS élevé (Lightning sans canaux en gros) - Certains voudront plus d’expressivité (pour les prêts de stablecoins sans confiance, les swaps AMM, les coffres-forts, les plans d’héritage, les produits à effet de levier) Si ces deux types de systèmes doivent exister sur la même couche d’exécution, ou est-il préférable de séparer les paiements des applications avec des files d’attente de séquençage différentes (j’ai tendance à le croire) - peut-être voulons-nous aller dans une direction Celestia en faisant un zkVM L2 et tous les autres systèmes en tant que L3, des files d’attente distinctes mais une agrégation via le L2. Faire de vrais rollups pour quoi que ce soit à grande échelle est fondamentalement hors de question pour la vision de fin de partie étant donné le faible débit du L1 et les besoins en DA (et l’ajout de blobs semble très peu probable), donc nous utiliserions très probablement une saveur de validiums + couche DA externe, zk-plasmas ou des architectures basées sur la validation côté client comme Miden. De plus, nous devrions explorer si nous voulons des systèmes ZK purs ou des tests hybrides (« ZK optimiste », voir Fuel pour la référence) pour maximiser encore plus le débit. L’une d’entre elles est de laisser le marché libre gagner et de voir ce qui se passe, mais c’est ce qu’Ethereum a fait. Même si nous tirons les leçons avec nous et que les équipes essaient de se coordonner autour de solutions d’agrégation uniques dès le départ, il n’y a aucune garantie que cela fonctionnera. Nous n’avons pas non plus la possibilité d’enchâsser une couche d’exécution particulière via la L1. Pourtant, il est clair pour moi que les STARK présentent la meilleure voie pour tous les éléments suivants : - Paiements minimisés par la confiance (sans canaux, routage ou exigences de liquidité) - Expressivité (pour ceux qui le veulent) - Confidentialité (VM ZK-privacy complètes) - Réaliser tout ce qui précède sans introduire d’hypothèses cryptographiques exotiques, de configurations fiables, etc. Vous pouvez vous demander quelle est la finalité à cause de la latence du L1, mais il est clair qu’il peut être adressé à un degré satisfaisant avec des séquenceurs liés pour des pré-confs rapides. Nous avons donc tous les outils, que faisons-nous pour obtenir le meilleur résultat possible ? Bien que le BTC devrait évidemment être la monnaie de tous ces systèmes (et payer les frais/gaz), il y a la dernière (ou peut-être la première) question sur la façon de réaliser tout cela sans introduire un jeton L2 principalement contrôlé par une fondation avec trop de contrôle. Je pense qu’un système de paiement uniquement peut fonctionner sans jeton de gouvernance (avec juste un séquençage central + des sorties unilatérales contre la censure), mais j’en doute pour quoi que ce soit d’expressif. Alors que la plupart des fondations/DAO ont pour objectif la décentralisation, mettre autant de pouvoir entre les mains d’une organisation centralisée, même dans une phase d’amorçage, me semble sous-optimal si nous voulons une sorte d’approche collective dès le départ pour atténuer les risques de fragmentation. Ce serait formidable d’entendre ce que les autres pensent de personnes ayant de l’expérience dans d’autres écosystèmes comme Ethereum, Celestia, Polygon, Cosmos et également curieuses de savoir comment les équipes L2 actuelles travaillant sur Bitcoin pensent à ces questions (par exemple Alpen, Chainway, Starkware). N’hésitez pas à intervenir dans les commentaires !</insert>