Modification du partage sécurisé des données

原文：Partagement de données de sécurité variables —— polynie
Traducteur : Evelyn｜W3.Hitchhiker
Avertissement : tout ici est une pensée purement spéculative, il y a de nombreuses simplifications excessives, rien de tout cela ne doit être pris au sérieux, j'espère juste qu'il y a matière à réflexion.
La belle idée de Danksharding est la suivante : seul le constructeur (ce qui est de toute façon une hypothèse honnête et minoritaire) devra faire fonctionner le matériel coûteux. Au fil du temps, les cumuls évoluent jusqu'à des millions de TPS à un coût très minime pour les validateurs, les utilisateurs et tout le monde. Le problème est que cette vision ambitieuse prendra du temps à se concrétiser. Cela pourrait prendre entre 2 et 5 ans, selon à qui je demande bien sûr. Bien que l’espace cryptographique ait toujours souffert d’une erreur de planification extrême, les choses s’améliorent définitivement, mais je refuse de faire confiance à une feuille de route jusqu’à ce que je puisse voir émerger un prototype entièrement fonctionnel.
EIP-4844 est une énorme amélioration et je pense qu'il sera plus que suffisant pour toutes les applications et transactions de valeur nécessitant une haute sécurité dans un avenir prévisible, et permettra aux cumuls d'augmenter de 100 fois l'activité actuelle ~ 1 000 fois. Cependant, il existera différentes catégories d'applications gourmandes en données qui pourront nécessiter « des millions de TPS » sans nécessiter une sécurité élevée.
Dans le même temps, il est clair que les développeurs n’ont pas l’intention d’attendre un danksharding complet. Aujourd’hui, parmi les 15 meilleurs projets de L2Beat, 7 ne sont pas des rollups, mais des validiums et des chaînes optimistes utilisant des couches externes de disponibilité des données. (Ici, je suppose que vous connaissez ces structures et savez pourquoi elles sont toujours meilleures que les sidechains, etc.) StarkEx (6 validiums maintenant !), Arbitrum et Metis ont déjà des couches de disponibilité de données externes tandis que StarkNet, zkSync, Polygon et d'autres sociétés le sont ; créer des couches de disponibilité des données en interne, sans parler d'EigenDA ou de Celestia. Ces solutions hybrides ne nécessitent ni EIP-4844 ni danksharding complet pour maintenir les frais de transaction à un niveau bas, et surtout, elles sont déjà là.
Une solution consiste à les laisser faire leur travail et les utilisateurs choisiront l'option validium la moins sécurisée s'ils en ont besoin (mais toujours supérieure à alt-L1). La magie de Volitions réside dans le fait que les utilisateurs peuvent choisir par transaction ou par utilisateur.
Mais une autre approche est la suivante : comment pouvons-nous améliorer la couche de disponibilité des données externes ?
Bien que ce soit loin d’être un échantillon représentatif, 20 % des validateurs Ethereum dépassent aujourd’hui la fourchette typique. Pendant ce temps, 45 % préfèrent avoir des exigences très prudentes en matière de bande passante et de trafic. Avec EIP-4844, nous optimisons pour ces 45 %, mais les 55 % restants continueront à fonctionner sur une bande passante sous-utilisée. L’idée est donc d’utiliser cette bande passante libre en ajoutant un simple partage de données, où l’ensemble des validateurs sera divisé. Je ne connais rien à l'ingénierie, mais je crois Dankrad sur parole selon lequel c'est "trivial".
Avec EIP-4844, nous disposons d'une nouvelle couche de disponibilité des données. Je l'appelle le fragment de données numéro 0 (DS0). DS0 est obligatoire et garanti par l’ensemble complet des validateurs Ethereum.
Ici, nous pouvons avoir plus de fragments de données (S1, DS2... etc.) qui peuvent s'inscrire auprès des validateurs. Par conséquent, 30 % du camp de 2 To à 10 To ci-dessus peut exécuter 2 ou 3 fragments de données. Ainsi, alors que DS0 est garanti à 100 % par l’ensemble des validateurs Ethereum, DS1 est à 55 %, DS2 à 50 %, et ainsi de suite. Maintenant que nous avons ces validateurs hyper-spécifications en cours d'exécution (qui pensaient apparemment à tort qu'il s'agissait de validateurs Solana) qui sont à l'aise avec un trafic de plus de 20 To ou une bande passante de plus de 100 Mbps, ces 20 % sont également capables d'exécuter plus de fragments. Ainsi, votre dernier fragment de données (DS16) ne fournit que 10 % de la sécurité Ethereum. Bien sûr, je donne l’impression que cela semble décontracté, mais selon la structure du comité Beacon Chain, il peut y avoir des divisions claires. Mais l’essentiel est que DS0 est doté d’une sécurité à 100 % (tous les cumuls seront donc HRE). DS1 est sûr à 50 %, DS10 est sûr à 25 %, DS16 est sûr à 10 %, et ainsi de suite, pour un nouveau type de construction, on se situe entre le rollup complet (DS0 / 100 % sûr) et la chaîne validité/optimiste.
En réalité, alors que de nombreux validiums et couches de données sont mis en ligne, la sécurité requise pour chaque application, utilisateur et cas d'utilisation est un spectre. Il n’est pas nécessaire que tout soit garanti par des centaines de milliards de dollars de sécurité économique.
Mais le fait est que si nous supposons que 30 % de l'offre d'ETH est mise en jeu, même le DS16 à « sécurité minimale » est toujours soutenu par 5 milliards de dollars de sécurité économique, même dans ce marché baissier, et cela reste la plage de sécurité la plus élevée de niveau alt-L1. . Il est également important de se rappeler que ce périmètre de sécurité concerne uniquement la disponibilité des données. Les preuves de validité et les preuves de fraude sont toujours vérifiées en toute sécurité ! Ainsi, même un demi-rollup/moitié-validium d'un DS16 offre une sécurité nettement meilleure qu'un alt-L1 de premier plan.
Cela peut encore constituer une amélioration significative par rapport à l’option de couche de données externe. Certes, les transactions financières de grande valeur choisiront d'être réglées sur DS0, mais certains NFT de valeur moyenne peuvent ne nécessiter que DS8, et pour les applications de jeu de valeur nulle, même DS16 peut être redondant. Comme mentionné ci-dessus, dans un cadre volontaire, chaque application peut choisir le niveau de sécurité dont elle a besoin en fonction de ses propres circonstances.
Qu’en est-il des utilisateurs du rollup ? Ils n'ont besoin que d'exécuter les fragments de données qui leur sont associés, la configuration système requise ne sera donc pas différente de celle de l'EIP-4844. C'est pourquoi même s'il existe des compromis en matière de sécurité, il n'y a aucun compromis en matière de décentralisation par rapport à EIP-4844. (À moins qu'il ne s'agisse d'un gigarollup réparti sur plusieurs fragments de données - mais c'est quelque chose dont ses utilisateurs seront bien conscients)
Pour être clair, je ne m'attends pas à ce que ces choses se produisent, ce ne sont que les divagations d'un blogueur amateur fou et non technique. La voie de moindre résistance consiste à arriver à l’EIP-4844 en 2023, et une fois saturé dans quelques années, les cas d’utilisation gourmands en données se propageront à de nombreuses couches de données externes, et les données seront toutes hautement marchandisées et enrichies. Finalement, au fil des années, le danksharding a été mis en ligne et est devenu la meilleure solution. Mais peut-être que quelqu'un lira ceci et trouvera une meilleure idée pour combler l'énorme écart entre 4844 et le partage complet...