Nouvelle publication de Vitalik : l'avenir possible d'Ethereum, The Surge
La feuille de route d'Ethereum contenait à l'origine deux stratégies d'extension : le sharding et les protocoles Layer2. Le sharding permet à chaque nœud de ne valider et de stocker qu'une partie des transactions, tandis que Layer2 construit un réseau au-dessus d'Ethereum, tirant parti de sa sécurité tout en conservant la plupart des données et des calculs en dehors de la chaîne principale. Avec l'avancement des recherches, ces deux voies se sont fusionnées pour former une feuille de route centrée sur le Rollup, qui demeure à ce jour la stratégie d'expansion d'Ethereum.
La feuille de route centrée sur Rollup propose une division simple : Ethereum L1 se concentre sur le fait de devenir une couche de base puissante et décentralisée, tandis que L2 prend en charge la tâche d'aider l'écosystème à s'étendre. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas motivée par la recherche de vitesses ultra-rapides et d'efficacité, mais vise à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide, conduisant l'humanité vers Mars.
Cette année, la feuille de route centrée sur les Rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données d'Ethereum L1 a considérablement augmenté, et plusieurs Rollups de la machine virtuelle Ethereum (EVM) sont entrés dans la première phase. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques internes. La diversité et la pluralité des méthodes de réalisation des fragments sont désormais une réalité. Mais comme nous l'avons vu, suivre cette voie présente également des défis uniques. Ainsi, notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups et de résoudre ces problèmes tout en préservant la robustesse et la décentralisation qui caractérisent Ethereum L1.
The Surge: Objectifs clés
À l'avenir, Ethereum pourra atteindre plus de 100 000 TPS grâce à L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum ( : confiance, ouverture, résistance à la censure );
Ethereum devrait sembler comme un écosystème unifié, et non comme 34 blockchains différentes.
Contenu de ce chapitre
Paradoxe du triangle de la scalabilité
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Compression des données
Plasma généralisé
Système de preuve L2 mature
Amélioration de l'interopérabilité entre les L2
Étendre l'exécution sur L1
Paradoxe de la trilogie de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le coût faible des nœuds fonctionnels ), la scalabilité ( avec un grand nombre de transactions traitées ) et la sécurité ( où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction ).
Il est à noter que le paradoxe du triangle n'est pas un théorème, et les publications présentant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il propose en effet un argument mathématique heuristique : si un nœud amical décentralisé (, par exemple un ordinateur portable grand public ), peut valider N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœud, ce qui signifie qu'un attaquant n'a qu'à compromettre quelques nœuds pour réaliser une transaction malveillante, ou (ii) vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée. Le but de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternaire est difficile et nécessite, dans une certaine mesure, de sortir du cadre de pensée implicite de cet argument.
Depuis des années, certaines chaînes haute performance prétendent avoir résolu le trilemme sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier qu'une certaine quantité de données est disponible et qu'un certain nombre d'étapes de calcul ont été exécutées correctement, tout en téléchargeant seulement une petite quantité de données et en effectuant très peu de calculs. Les SNARKs sont sans confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque de 51 % ne peut pas forcer des blocs invalides à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise des techniques astucieuses pour transférer la responsabilité de la disponibilité des données de surveillance aux utilisateurs de manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous n'avions que la preuve de fraude comme moyen d'étendre les capacités de calcul, Plasma était très limité en matière d'exécution sécurisée, mais avec la popularité des SNARKs( et des preuves non interactives succinctes à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, ou une bande passante de données d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, alors un transfert ERC20 est d'environ 180 octets, donc le TPS maximal des Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets ), cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.
C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné aux améliorations de compression des données Rollup, pourrait apporter environ 58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une réalisation relativement simple du "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel 4096 ) selon les paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles ( peut restaurer le blob.
Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de n'importe quel blob, et demande aux pairs dans le réseau p2p mondial qui écouteront différents sous-réseaux ) qui fourniront les blobs dont ils ont besoin sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau sans requêtes supplémentaires au niveau des pairs. La proposition actuelle est de permettre aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.
Théoriquement, nous pouvons étendre une "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximum de blobs à 256( avec un objectif de 128), alors nous pourrions atteindre un objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob ayant 512 octets par échantillon = 1 Mo de bande passante de données par slot. Cela reste juste dans notre marge de tolérance : c'est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser cela dans une certaine mesure en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela entraînera des coûts de reconstruction plus élevés.
Ainsi, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D (2D sampling), cette méthode effectue non seulement un échantillonnage aléatoire à l'intérieur des blobs, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons un ensemble de blobs dans un bloc avec un nouvel ensemble de blobs virtuels, ces blobs virtuels encodent redondamment les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin en effectuant un échantillonnage 2D, qui ne se limite pas à l'intérieur des blobs, mais effectue également un échantillonnage aléatoire entre les blobs. La propriété linéaire de l'engagement KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui comprend une nouvelle liste de blobs virtuels codés de manière redondante contenant les mêmes informations.
Il est essentiel de noter que l'extension des engagements de calcul ne nécessite pas de blob, donc cette approche est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs ont seulement besoin de posséder l'engagement KZG de blob, et ils peuvent se fier à l'échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
( que faut-il encore faire ? Quelles sont les concessions ?
Ensuite, il s'agit de finaliser la mise en œuvre et le lancement de PeerDAS. Par la suite, nous augmenterons continuellement le nombre de blobs sur PeerDAS, tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. En même temps, nous espérons qu'il y aura plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité comme les règles de choix de fork.
À un stade plus éloigné dans le futur, nous devons faire plus de travail pour déterminer la version idéale du DAS 2D et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer d'une solution KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Actuellement, il n'est pas clair quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même avec des techniques "brute force" coûteuses, c'est-à-dire en utilisant des STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien qu'en théorie, la taille d'un STARK soit O)log(n) * log###log(n() la valeur de hachage ( utilisant STIR(, en réalité, un STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin réaliste à long terme est :
Mettre en œuvre un DAS 2D idéal;
Persister à utiliser 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour la simplicité et la robustesse en acceptant une limite de données inférieure.
Abandonner DA et accepter complètement Plasma comme notre principale architecture Layer2 d'intérêt.
Veuillez noter que même si nous décidons d'étendre l'exécution directement sur la couche L1, cette option existe. Cela est dû au fait que si la couche L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, nous devrons donc utiliser sur la couche L1 les mêmes technologies que celles utilisées par Rollup) telles que ZK-EVM et DAS).
( Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour le DAS 2D sera réduite, ou du moins retardée. Si Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis aux protocoles et mécanismes de construction de blockchains distribuées : bien que le DAS soit théoriquement convivial pour la reconstruction distribuée, cela nécessite en pratique d'être combiné avec les propositions de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Compression de données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite l'évolutivité des protocoles Layer. Chaque slot de 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des molécules, mais aussi résoudre le problème des dénominateurs, en faisant en sorte que chaque transaction dans un Rollup occupe moins de bytes sur la chaîne?
Qu'est-ce que c'est, comment ça fonctionne ?
À mon avis, la meilleure explication est cette image d'il y a deux ans :
![Vitalik nouvel article : futur possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Dans la compression par zéros, chaque longue séquence de zéros est remplacée par deux octets, indiquant combien de zéros il y a. De plus, nous avons exploité des propriétés spécifiques des transactions :
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
15 J'aime
Récompense
15
4
Partager
Commentaire
0/400
CryptoTarotReader
· 07-22 16:59
Cette vague de L2 va To the moon !
Voir l'originalRépondre0
NightAirdropper
· 07-22 05:24
Le roi du foie V commence encore à dessiner BTC.
Voir l'originalRépondre0
LayerZeroHero
· 07-19 20:54
Les données ne peuvent pas s'échapper, la stratégie de division des tâches doit nécessairement mener à un rollup.
Vitalik interprète l'avenir d'Ethereum : la percée de la stratégie The Surge et le trilemme de l'extensibilité.
Nouvelle publication de Vitalik : l'avenir possible d'Ethereum, The Surge
La feuille de route d'Ethereum contenait à l'origine deux stratégies d'extension : le sharding et les protocoles Layer2. Le sharding permet à chaque nœud de ne valider et de stocker qu'une partie des transactions, tandis que Layer2 construit un réseau au-dessus d'Ethereum, tirant parti de sa sécurité tout en conservant la plupart des données et des calculs en dehors de la chaîne principale. Avec l'avancement des recherches, ces deux voies se sont fusionnées pour former une feuille de route centrée sur le Rollup, qui demeure à ce jour la stratégie d'expansion d'Ethereum.
La feuille de route centrée sur Rollup propose une division simple : Ethereum L1 se concentre sur le fait de devenir une couche de base puissante et décentralisée, tandis que L2 prend en charge la tâche d'aider l'écosystème à s'étendre. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas motivée par la recherche de vitesses ultra-rapides et d'efficacité, mais vise à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide, conduisant l'humanité vers Mars.
Cette année, la feuille de route centrée sur les Rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données d'Ethereum L1 a considérablement augmenté, et plusieurs Rollups de la machine virtuelle Ethereum (EVM) sont entrés dans la première phase. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques internes. La diversité et la pluralité des méthodes de réalisation des fragments sont désormais une réalité. Mais comme nous l'avons vu, suivre cette voie présente également des défis uniques. Ainsi, notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups et de résoudre ces problèmes tout en préservant la robustesse et la décentralisation qui caractérisent Ethereum L1.
The Surge: Objectifs clés
À l'avenir, Ethereum pourra atteindre plus de 100 000 TPS grâce à L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum ( : confiance, ouverture, résistance à la censure );
Ethereum devrait sembler comme un écosystème unifié, et non comme 34 blockchains différentes.
Contenu de ce chapitre
Paradoxe de la trilogie de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le coût faible des nœuds fonctionnels ), la scalabilité ( avec un grand nombre de transactions traitées ) et la sécurité ( où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction ).
Il est à noter que le paradoxe du triangle n'est pas un théorème, et les publications présentant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il propose en effet un argument mathématique heuristique : si un nœud amical décentralisé (, par exemple un ordinateur portable grand public ), peut valider N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœud, ce qui signifie qu'un attaquant n'a qu'à compromettre quelques nœuds pour réaliser une transaction malveillante, ou (ii) vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée. Le but de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternaire est difficile et nécessite, dans une certaine mesure, de sortir du cadre de pensée implicite de cet argument.
Depuis des années, certaines chaînes haute performance prétendent avoir résolu le trilemme sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier qu'une certaine quantité de données est disponible et qu'un certain nombre d'étapes de calcul ont été exécutées correctement, tout en téléchargeant seulement une petite quantité de données et en effectuant très peu de calculs. Les SNARKs sont sans confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque de 51 % ne peut pas forcer des blocs invalides à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise des techniques astucieuses pour transférer la responsabilité de la disponibilité des données de surveillance aux utilisateurs de manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous n'avions que la preuve de fraude comme moyen d'étendre les capacités de calcul, Plasma était très limité en matière d'exécution sécurisée, mais avec la popularité des SNARKs( et des preuves non interactives succinctes à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, ou une bande passante de données d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, alors un transfert ERC20 est d'environ 180 octets, donc le TPS maximal des Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets ), cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.
C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné aux améliorations de compression des données Rollup, pourrait apporter environ 58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une réalisation relativement simple du "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel 4096 ) selon les paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles ( peut restaurer le blob.
Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de n'importe quel blob, et demande aux pairs dans le réseau p2p mondial qui écouteront différents sous-réseaux ) qui fourniront les blobs dont ils ont besoin sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau sans requêtes supplémentaires au niveau des pairs. La proposition actuelle est de permettre aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.
Théoriquement, nous pouvons étendre une "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximum de blobs à 256( avec un objectif de 128), alors nous pourrions atteindre un objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob ayant 512 octets par échantillon = 1 Mo de bande passante de données par slot. Cela reste juste dans notre marge de tolérance : c'est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser cela dans une certaine mesure en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela entraînera des coûts de reconstruction plus élevés.
Ainsi, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D (2D sampling), cette méthode effectue non seulement un échantillonnage aléatoire à l'intérieur des blobs, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons un ensemble de blobs dans un bloc avec un nouvel ensemble de blobs virtuels, ces blobs virtuels encodent redondamment les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin en effectuant un échantillonnage 2D, qui ne se limite pas à l'intérieur des blobs, mais effectue également un échantillonnage aléatoire entre les blobs. La propriété linéaire de l'engagement KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui comprend une nouvelle liste de blobs virtuels codés de manière redondante contenant les mêmes informations.
Il est essentiel de noter que l'extension des engagements de calcul ne nécessite pas de blob, donc cette approche est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs ont seulement besoin de posséder l'engagement KZG de blob, et ils peuvent se fier à l'échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
( que faut-il encore faire ? Quelles sont les concessions ?
Ensuite, il s'agit de finaliser la mise en œuvre et le lancement de PeerDAS. Par la suite, nous augmenterons continuellement le nombre de blobs sur PeerDAS, tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. En même temps, nous espérons qu'il y aura plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité comme les règles de choix de fork.
À un stade plus éloigné dans le futur, nous devons faire plus de travail pour déterminer la version idéale du DAS 2D et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer d'une solution KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Actuellement, il n'est pas clair quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même avec des techniques "brute force" coûteuses, c'est-à-dire en utilisant des STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien qu'en théorie, la taille d'un STARK soit O)log(n) * log###log(n() la valeur de hachage ( utilisant STIR(, en réalité, un STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin réaliste à long terme est :
Veuillez noter que même si nous décidons d'étendre l'exécution directement sur la couche L1, cette option existe. Cela est dû au fait que si la couche L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, nous devrons donc utiliser sur la couche L1 les mêmes technologies que celles utilisées par Rollup) telles que ZK-EVM et DAS).
( Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour le DAS 2D sera réduite, ou du moins retardée. Si Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis aux protocoles et mécanismes de construction de blockchains distribuées : bien que le DAS soit théoriquement convivial pour la reconstruction distribuée, cela nécessite en pratique d'être combiné avec les propositions de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Compression de données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite l'évolutivité des protocoles Layer. Chaque slot de 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des molécules, mais aussi résoudre le problème des dénominateurs, en faisant en sorte que chaque transaction dans un Rollup occupe moins de bytes sur la chaîne?
Qu'est-ce que c'est, comment ça fonctionne ?
À mon avis, la meilleure explication est cette image d'il y a deux ans :
![Vitalik nouvel article : futur possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Dans la compression par zéros, chaque longue séquence de zéros est remplacée par deux octets, indiquant combien de zéros il y a. De plus, nous avons exploité des propriétés spécifiques des transactions :
Signature agrégée : nous provenons de l'ECD