Vitalik : Fusaka est en train de développer la fonctionnalité principale PeerDAS, visant à réaliser une Blockchain en temps réel sans avoir à télécharger l'intégralité des données.

[Vitalik : Fusaka développe la fonctionnalité principale PeerDAS, visant à réaliser une Blockchain en temps réel sans télécharger l'intégralité des données] Le fondateur d'Éthereum, Vitalik Buterin, a déclaré sur la plateforme X que pour Fusaka, la sécurité est la priorité absolue. Sa fonctionnalité principale PeerDAS tente de réaliser quelque chose d'inédit : créer une Blockchain en temps réel qui ne nécessite pas qu'aucun nœud unique télécharge toutes les données. Le fonctionnement de PeerDAS est que chaque nœud ne demande qu'un petit nombre de "blocs de données" (chunk) pour vérifier de manière probabiliste que plus de 50 % des blocs de données sont disponibles. Si plus de 50 % des blocs de données sont disponibles, alors théoriquement, le nœud peut télécharger ces blocs de données et utiliser le code d'effacement (erasure coding) pour récupérer les données restantes. Dans la première version, les données complètes du bloc doivent toujours exister à un seul endroit, il y a deux cas : (i) diffusion initiale (initial broadcasting) : lorsque les données sont publiées pour la première fois ; (ii) reconstruction des données (reconstruction) : lorsque l'éditeur a publié des blocs de données entre 50 % et 100 %. Mais ces rôles sont tous sans confiance : nous avons juste besoin d'un participant honnête pour exécuter ces tâches, même s'il y a 100 participants malhonnêtes, le protocole pourra les contourner. De plus, différents nœuds peuvent exécuter cette tâche pour différents blocs. À l'avenir, la messagerie au niveau cellule (cell-level messaging) et la construction de blocs distribués (distributed block building) permettront également de décentraliser ces deux fonctionnalités. C'est toutes de nouvelles technologies, il est sage que les développeurs principaux soient très prudents lors des tests, même s'ils y travaillent depuis des années. C'est aussi pourquoi le nombre initial de blobs augmente de manière conservatrice, puis devient plus agressif au fil du temps. Mais c'est la clé de l'extension L2 (et finalement la clé de l'extension L1, une fois que la limite de gaz L1 est suffisamment élevée pour que nous devions mettre les données d'exécution L1 dans des blobs).