Avec tout le monde affirmant obtenir des temps de bloc de plus en plus bas sur les L2, j'ai pensé qu'il était temps de décrire ce qui se passe. En particulier, vérifions ce que sont les blocs L2, en quoi ils diffèrent des blocs L1 et pourquoi nous ne devrions vraiment pas nous soucier autant des temps de bloc L2, même s'ils sont une mesure d'ingénierie intéressante.
À l'époque où le terme blockchain signifiait réellement quelque chose (vers 2009), le concept de blocs a été introduit car nous avions besoin d'une unité pour un groupe de transactions soumises au consensus.
Par exemple, sur Bitcoin, chaque producteur de blocs essaie de trouver un agencement de transactions qui satisfait aux exigences de la preuve de travail, puis diffuse ce bloc sur le réseau. D'autres nœuds vérifieront que ce bloc remplit effectivement les exigences de la preuve de travail. Sur Ethereum, qui est maintenant basé sur la preuve de participation et les comptes, les producteurs de blocs calculent un hachage de l'état de la blockchain après l'exécution de chaque bloc (l'engagement de l'état), et les validateurs recomptent cette valeur pour une validation facile du bloc. Le processus global est toujours le même:
Sur les chaînes de couche 1, les blocs comptent : vous vérifiez l'intégrité de la chaîne au niveau des blocs, vous gérez les forks au niveau des blocs, etc.
TL;DR: les blocs sont un élément essentiel du consensus.
Les L2 existent parce que le consensus est lent et que la décentralisation nécessite de soutenir des ordinateurs et des réseaux lents. L'approche L2 décharge le traitement des transactions vers la machine la plus rapide disponible, puis publie un résumé d'exécution vérifiable sur L1 pour le consensus. En d'autres termes, la plupart des L2 aujourd'hui sont des systèmes centralisés qui jouent le rôle de blockchains. Et c'est parfaitement bien.
C'est là que les temps de bloc deviennent flous. Les L2 continuent de construire des blocs principalement pour la compatibilité logicielle L1, mais c'est largement artificiel. Lors de la publication de résumés sur L1, les L2 regroupent généralement plusieurs blocs ensemble pour réduire les coûts. Bien que des engagements d'état soient nécessaires occasionnellement pour les preuves de fraude/validité, ils ne sont pas nécessaires pour chaque bloc. Par conséquent, les blocs L2 sont essentiellement inutiles.
Lorsque quelqu'un affirme avoir des blocs L2 rapides, il a simplement ajusté une valeur de configuration du système pour diminuer les temps de bloc. Bien qu'ils aient toujours besoin de traiter un nombre significatif de transactions par bloc, c'est la limite.
En tant qu'utilisateur, vous vous souciez d'une chose en termes de timing : le temps de trajet aller-retour. En d'autres termes, combien de temps faudra-t-il pour que ma transaction atteigne le séquenceur L2, soit exécutée et que le résultat soit visible sur le nœud RPC que j'utilise ? Concentrons-nous sur cette dernière partie : combien de temps faut-il pour communiquer l'exécution d'une transaction aux RPC ?
Les blockchains plus lentes attendent généralement la fin d'un bloc avant de l'envoyer à leurs pairs. Solana a lancé l'idée que vous pourriez diffuser des blocs : il suffit d'envoyer les transactions aux autres validateurs dès que vous les avez traitées. Solana divise ces transactions en entrées (groupes de max. 64 transactions), qui sont elles-mêmes divisées en fragments pour être transférées sur le réseau. Nous avons unarticle approfondisur ce sujet si vous êtes curieux. Ils sont diffusés en continu depuis le nœud leader vers les autres, ce qui signifie que vous obtenez des informations sur l'exécution de vos transactions avant même que le bloc ne soit terminé.
Les L2 ont maintenant décidé de réutiliser ce mécanisme : Base, avec Flashblocks, passe d'un temps de bloc de 2 secondes à des sous-blocs plus petits de 200 ms. MegaETH a un concept de “mini-blocs”, produits toutes les 15 ms sur leur testnet (la plupart du temps). Eclipse utilise le système d'entrée/déchiquetage de Solana. De cette façon, les utilisateurs doivent moins attendre pour que leurs transactions s'exécutent. C'est assez bon pour l'UX!
Mais soyons clairs : la véritable caractéristique ici est les “intervals réduits de communication à travers le réseau.” Cela n'a rien à voir avec certains blocs étant intrinsèquement meilleurs que d'autres. Nous divisons simplement les blocs en morceaux plus petits et les diffusons en parallèle avec l'exécution. Que vous appeliez ces morceaux blocs, mini-blocs, ou fragments n'a pas d'importance. L'objectif final est une communication plus rapide, pas de meilleurs blocs.
Avec tout le monde affirmant obtenir des temps de bloc de plus en plus bas sur les L2, j'ai pensé qu'il était temps de décrire ce qui se passe. En particulier, vérifions ce que sont les blocs L2, en quoi ils diffèrent des blocs L1 et pourquoi nous ne devrions vraiment pas nous soucier autant des temps de bloc L2, même s'ils sont une mesure d'ingénierie intéressante.
À l'époque où le terme blockchain signifiait réellement quelque chose (vers 2009), le concept de blocs a été introduit car nous avions besoin d'une unité pour un groupe de transactions soumises au consensus.
Par exemple, sur Bitcoin, chaque producteur de blocs essaie de trouver un agencement de transactions qui satisfait aux exigences de la preuve de travail, puis diffuse ce bloc sur le réseau. D'autres nœuds vérifieront que ce bloc remplit effectivement les exigences de la preuve de travail. Sur Ethereum, qui est maintenant basé sur la preuve de participation et les comptes, les producteurs de blocs calculent un hachage de l'état de la blockchain après l'exécution de chaque bloc (l'engagement de l'état), et les validateurs recomptent cette valeur pour une validation facile du bloc. Le processus global est toujours le même:
Sur les chaînes de couche 1, les blocs comptent : vous vérifiez l'intégrité de la chaîne au niveau des blocs, vous gérez les forks au niveau des blocs, etc.
TL;DR: les blocs sont un élément essentiel du consensus.
Les L2 existent parce que le consensus est lent et que la décentralisation nécessite de soutenir des ordinateurs et des réseaux lents. L'approche L2 décharge le traitement des transactions vers la machine la plus rapide disponible, puis publie un résumé d'exécution vérifiable sur L1 pour le consensus. En d'autres termes, la plupart des L2 aujourd'hui sont des systèmes centralisés qui jouent le rôle de blockchains. Et c'est parfaitement bien.
C'est là que les temps de bloc deviennent flous. Les L2 continuent de construire des blocs principalement pour la compatibilité logicielle L1, mais c'est largement artificiel. Lors de la publication de résumés sur L1, les L2 regroupent généralement plusieurs blocs ensemble pour réduire les coûts. Bien que des engagements d'état soient nécessaires occasionnellement pour les preuves de fraude/validité, ils ne sont pas nécessaires pour chaque bloc. Par conséquent, les blocs L2 sont essentiellement inutiles.
Lorsque quelqu'un affirme avoir des blocs L2 rapides, il a simplement ajusté une valeur de configuration du système pour diminuer les temps de bloc. Bien qu'ils aient toujours besoin de traiter un nombre significatif de transactions par bloc, c'est la limite.
En tant qu'utilisateur, vous vous souciez d'une chose en termes de timing : le temps de trajet aller-retour. En d'autres termes, combien de temps faudra-t-il pour que ma transaction atteigne le séquenceur L2, soit exécutée et que le résultat soit visible sur le nœud RPC que j'utilise ? Concentrons-nous sur cette dernière partie : combien de temps faut-il pour communiquer l'exécution d'une transaction aux RPC ?
Les blockchains plus lentes attendent généralement la fin d'un bloc avant de l'envoyer à leurs pairs. Solana a lancé l'idée que vous pourriez diffuser des blocs : il suffit d'envoyer les transactions aux autres validateurs dès que vous les avez traitées. Solana divise ces transactions en entrées (groupes de max. 64 transactions), qui sont elles-mêmes divisées en fragments pour être transférées sur le réseau. Nous avons unarticle approfondisur ce sujet si vous êtes curieux. Ils sont diffusés en continu depuis le nœud leader vers les autres, ce qui signifie que vous obtenez des informations sur l'exécution de vos transactions avant même que le bloc ne soit terminé.
Les L2 ont maintenant décidé de réutiliser ce mécanisme : Base, avec Flashblocks, passe d'un temps de bloc de 2 secondes à des sous-blocs plus petits de 200 ms. MegaETH a un concept de “mini-blocs”, produits toutes les 15 ms sur leur testnet (la plupart du temps). Eclipse utilise le système d'entrée/déchiquetage de Solana. De cette façon, les utilisateurs doivent moins attendre pour que leurs transactions s'exécutent. C'est assez bon pour l'UX!
Mais soyons clairs : la véritable caractéristique ici est les “intervals réduits de communication à travers le réseau.” Cela n'a rien à voir avec certains blocs étant intrinsèquement meilleurs que d'autres. Nous divisons simplement les blocs en morceaux plus petits et les diffusons en parallèle avec l'exécution. Que vous appeliez ces morceaux blocs, mini-blocs, ou fragments n'a pas d'importance. L'objectif final est une communication plus rapide, pas de meilleurs blocs.