Les secondes couches sont d'ordinaire présentées comme une version moins chère de la chaîne du dessous, ce qui est vrai et inutile. La question intéressante est ce qu'elles font différemment pour être moins chères, parce que chacune de ces différences est aussi la source d'un risque qui n'existe pas sur la chaîne de base. Les frais sont plus bas pour des raisons, et ce sont les raisons qui nous intéressent.
Une chaîne de blocs coûte cher parce que chaque participant vérifie chaque transaction et en conserve le résultat pour toujours. Cette redondance est la sécurité, et c'est aussi le plafond de coût : aucune quantité d'ingénierie ne supprime le fait que des milliers de machines font le même travail.
Une seconde couche fait le travail une fois, ailleurs, puis inscrit sur la chaîne de base un enregistrement compressé de ce qui s'est passé. La chaîne de base n'exécute plus chaque transaction ; elle stocke assez d'information pour que le résultat puisse être reconstitué ou contesté. C'est tout le tour de passe-passe, et l'économie est proportionnelle à ce qui est laissé de côté.
Cela fait de la chaîne de base une couche de règlement plutôt qu'une couche d'exécution, ce qui est un vrai changement d'architecture et non un rustine de mise à l'échelle. Cela signifie aussi que les garanties obtenues par un utilisateur ne sont plus directement celles de la chaîne de base, mais ce que le mécanisme qui relie les deux parvient à préserver. Presque toutes les différences pratiques découlent de cette phrase.
La chaîne de base cesse d'exécuter votre transaction et se met à enregistrer qu'elle a eu lieu. Tout ce qu'une seconde couche gagne et tout ce qu'elle risque vient de cette substitution.
La première famille publie les données de transaction et suppose le résultat correct tant que personne ne prouve le contraire dans une fenêtre de contestation. N'importe qui peut soumettre la preuve qu'un état publié est faux, et si personne ne le fait pendant la fenêtre, l'état est traité comme définitif.
La seconde famille publie une preuve cryptographique que le calcul a été effectué correctement, que la chaîne de base vérifie directement. Il n'y a rien à contester puisque la correction est démontrée au lieu d'être supposée, et le caractère définitif arrive dès que la preuve est vérifiée.
L'arbitrage se joue entre hypothèses et coût. La première famille est moins chère à exploiter et hérite d'un délai plus l'exigence que quelqu'un surveille et soit en mesure de contester. La seconde supprime le délai et le surveillant, et le paie par le coût de calcul de la production des preuves, qui a beaucoup baissé et reste la contrainte qui limite ce que ces systèmes savent exécuter.
L'économie vient de deux endroits et il vaut la peine de les séparer. L'exécution est faite une fois par la couche au lieu de l'être par chaque nœud de la chaîne de base, ce qui retire l'essentiel du calcul. Cette partie est simple, et c'est celle où la plupart des explications s'arrêtent.
La seconde, plus importante, est l'amortissement. L'enregistrement écrit sur la chaîne de base couvre de nombreuses transactions à la fois, donc le coût de la chaîne de base est partagé entre tous ceux du lot. Une couche fréquentée a donc un coût par transaction plus bas qu'une couche calme, ce qui est l'inverse de l'intuition selon laquelle l'affluence rend les choses chères.
La conséquence pratique est que les frais d'une couche ne sont pas une propriété fixe de cette couche. Ils bougent avec l'affluence sur la chaîne de base, avec le taux de remplissage des lots, et avec la quantité de données que la couche choisit de publier plutôt que de conserver. Des frais relevés aujourd'hui décrivent aujourd'hui, et comparer des couches sur une seule observation compare deux instants plutôt que deux systèmes.
Quelqu'un doit décider l'ordre dans lequel les transactions sont exécutées avant que le lot soit inscrit, et dans presque toutes les secondes couches déployées aujourd'hui ce quelqu'un est un opérateur unique, tenu par l'équipe qui a construit la couche. C'est la partie qui contredit le plus l'image mentale d'un système décentralisé.
Ce qu'un séquenceur unique peut faire est borné mais réel. Il peut décider de l'ordre, ce qui compte partout où l'ordre a de la valeur. Il peut refuser d'inclure une transaction, ce qui est de la censure au sens technique étroit. Ce qu'il ne peut en général pas faire, c'est voler, parce que les transitions d'état doivent rester valides, et une transition invalide est soit réfutée soit impossible à prouver selon la famille.
La plupart des conceptions prévoient une issue de secours : un moyen de soumettre une transaction directement à la chaîne de base et d'en forcer l'inclusion si le séquenceur refuse. Il vaut la peine de savoir si la couche que vous utilisez en a une et si elle a déjà servi, parce qu'un mécanisme qui n'a jamais été employé pour de vrai est une conception, pas une garantie.
Dans la première famille, la fenêtre de contestation doit être assez longue pour qu'une partie honnête remarque un état faux et soumette une preuve, y compris pendant une période d'affluence sur la chaîne de base. C'est pourquoi les délais de retrait se comptent en jours plutôt qu'en minutes, et cette longueur est un paramètre de sécurité, pas une inefficacité.
Le délai s'applique à la sortie sans confiance, pas à toutes les sorties. Des services tiers vous avancent les fonds sur la chaîne de base immédiatement et attendent la fenêtre à votre place, en facturant le service et le capital. C'est un produit utile qui remplace une garantie de protocole par une contrepartie, ce qui est un risque différent plutôt qu'une absence de risque.
Dans la seconde famille le délai est court parce qu'il n'y a rien à contester, sans être instantané : une preuve doit être produite et vérifiée, et la production prend du temps réel et du calcul réel. L'écart entre les deux familles sur ce point précis est la différence la plus visible pour un utilisateur.
La formule est employée de façon lâche et elle a un sens précis. Ce que la chaîne de base sécurise, c'est que la couche ne peut pas rendre définitive une transition d'état invalide : elle ne peut pas vous créditer de jetons jamais déposés, ni laisser quelqu'un dépenser ce qu'il ne possède pas. C'est une garantie forte et véritable.
Ce qu'elle ne sécurise pas, c'est tout ce qui est en dehors de cette définition. Elle ne garantit pas que votre transaction soit incluse, qu'elle le soit dans l'ordre que vous préféreriez, que les contrats de la couche soient exempts de défauts, ni que l'opérateur continue de faire tourner le service. Chacun de ces points a échoué en pratique quelque part sans qu'aucun état invalide ne soit jamais devenu définitif.
Le résumé honnête est que la chaîne de base sécurise la comptabilité et non le service. C'est cette distinction qu'il faut retenir, parce qu'elle explique qu'une couche puisse être à la fois correcte et inutilisable, et pourquoi une panne sur une couche est un événement réel même si personne ne perd un solde.
La chaîne de base sécurise la comptabilité, pas le service. Une couche peut être parfaitement correcte et totalement inutilisable en même temps, et les deux sont arrivés.
Chaque couche est un environnement séparé, avec sa propre copie des actifs et ses propres réserves. Le même actif sur deux couches, ce sont deux soldes différents qui partagent un nom, et passer de l'un à l'autre suppose un pont, avec tous les modes de défaillance que les ponts connaissent.
Pour qui traite, la conséquence est que la profondeur est divisée. Un actif dont la liquidité agrégée est substantielle peut être mince sur la couche précise où vous êtes, et le prix obtenu reflète la réserve que vous avez atteinte plutôt que le marché dans son ensemble. Cet écart est le plus grand exactement quand il compte le plus, pendant les mouvements rapides.
Cela complique aussi l'arithmétique du coût. Une transaction moins chère sur une couche moins profonde peut coûter davantage au total qu'une transaction plus chère là où la profondeur se trouve, une fois compté le prix réellement obtenu. Comparer les seuls frais est l'erreur, et c'est l'erreur que le marketing de chaque couche encourage.
Publier toutes les données de transaction sur la chaîne de base est ce qui permet à quiconque de reconstituer l'état de façon indépendante, et c'est aussi le plus gros coût restant. Certains systèmes le réduisent en gardant les données ailleurs et en ne publiant qu'un engagement les concernant, ce qui est nettement moins cher.
Ce choix change le modèle de sécurité au lieu de l'optimiser. Si les données sont indisponibles, l'état ne peut pas être reconstitué par un tiers, et les utilisateurs dépendent d'un comité ou d'un réseau séparé pour continuer à les servir. Ces systèmes portent en général un nom différent pour exactement cette raison, et le nom fait un vrai travail.
Que le compromis soit acceptable dépend de ce qui est détenu et pour combien de temps. C'est un choix défendable pour une activité à gros volume et faible valeur, et un mauvais choix pour des soldes que quelqu'un compte laisser tranquilles pendant un an. L'erreur n'est pas de faire l'arbitrage, c'est de ne pas savoir lequel a été fait.
Quatre points décrivent la situation plus utilement que n'importe quelle comparaison de marques. Si le séquenceur est un opérateur unique et s'il existe un chemin d'inclusion forcée. Si les données de transaction vont sur la chaîne de base ou ailleurs. Combien de temps prend une sortie sans confiance. Et si les contrats peuvent être mis à jour, par qui, et avec quel délai.
Le dernier est sous-estimé. Beaucoup de couches peuvent être mises à jour par un portefeuille à signatures multiples, parfois avec un verrou temporel et parfois sans, et un contrat modifiable qui détient votre dépôt est un autre objet qu'un contrat immuable. L'existence d'un chemin de mise à jour n'est pas disqualifiante, son absence d'une description de sécurité l'est.
Aucun de ces points n'exige de faire confiance à un résumé. Les quatre sont publiés, les quatre sont vérifiables, et les lire prend moins de temps que la première transaction que vous passerez. Un trader capable de répondre aux quatre prend une décision ; celui qui ne le peut pas accepte les réponses qui se trouvent s'appliquer.
La décentralisation du séquenceur est le problème d'ingénierie ouvert, et plusieurs conceptions existent sans consensus arrêté sur celle qui tient à grande échelle. La difficulté est que l'ordre a de la valeur, donc distribuer le droit d'ordonner revient aussi à distribuer un revenu, et les mécanismes qui le font bien sans introduire de nouveaux délais sont encore à l'épreuve.
L'interopérabilité entre couches est le second. Passer d'une couche à une autre suppose aujourd'hui de repasser par la chaîne de base ou de faire confiance à un pont, et les standards qui permettraient aux couches de se régler directement entre elles ne sont pas encore répandus. Tant qu'ils ne le sont pas, la fragmentation décrite plus haut est un trait structurel plutôt qu'une maladie de jeunesse.
Ni l'un ni l'autre n'est une prévision sur ce qui arrivera. C'est la description de ce qui n'est pas résolu, ce qui est plus utile, parce que cela dit quelles affirmations lire avec scepticisme aujourd'hui. À une couche qui prétend avoir résolu l'un des deux, il faut demander comment, et la réponse est en général précise et vérifiable.
Deux raisons. L'exécution a lieu une fois sur la couche au lieu d'avoir lieu sur chaque nœud de la chaîne de base, et l'enregistrement inscrit sur la chaîne de base couvre de nombreuses transactions à la fois, donc ce coût est partagé dans le lot. Le second effet fait qu'une couche fréquentée a un coût par transaction plus bas qu'une couche calme.
L'une publie les données de transaction et suppose le résultat correct tant que personne ne prouve le contraire dans une fenêtre de contestation. L'autre publie une preuve cryptographique que la chaîne de base vérifie directement, donc il n'y a rien à contester. La première hérite d'un délai et a besoin d'un surveillant ; la seconde paie en coût de production des preuves.
Dans presque toutes les couches déployées aujourd'hui, un opérateur unique tenu par l'équipe qui l'a construite. Il peut décider de l'ordre et refuser d'inclure une transaction, mais il ne peut en général pas voler, parce que les transitions d'état doivent rester valides. La plupart des conceptions prévoient un moyen de forcer l'inclusion par la chaîne de base.
Dans la famille fondée sur la contestation, la fenêtre doit être assez longue pour qu'une partie honnête remarque un état faux et le prouve, y compris pendant une affluence sur la chaîne de base. C'est un paramètre de sécurité, pas une inefficacité. Des services tiers avancent les fonds immédiatement contre rémunération, ce qui remplace une garantie de protocole par une contrepartie.
Que la couche ne peut pas rendre définitive une transition d'état invalide : pas de jetons crédités sans dépôt, pas de dépense de ce qui n'existe pas. Cela ne garantit pas que votre transaction soit incluse, que les contrats de la couche soient sans défaut, ni que l'opérateur continue. La chaîne de base sécurise la comptabilité, pas le service.
Non. Ce sont deux soldes séparés qui partagent un nom, chacun avec ses propres réserves, et passer de l'un à l'autre exige un pont. La profondeur est divisée, donc un actif liquide en agrégé peut être mince sur la couche où vous êtes, et cet écart est le plus large pendant les mouvements rapides.
Publier toutes les données de transaction sur la chaîne de base permet à quiconque de reconstituer l'état indépendamment. Les systèmes qui ne publient qu'un engagement et gardent les données ailleurs sont moins chers, mais les utilisateurs dépendent alors d'un comité ou d'un réseau séparé pour les servir. Ces systèmes portent en général un autre nom, et ce nom fait un vrai travail.
Si le séquenceur est un opérateur unique et si l'inclusion forcée existe ; si les données de transaction vont sur la chaîne de base ou ailleurs ; combien de temps prend une sortie sans confiance ; et si les contrats peuvent être mis à jour, par qui et avec quel délai. Les quatre sont publiés et vérifiables.