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.
L'actualité du Jinse Finance rapporte que le fondateur d'Ethereum, Vitalik Buterin, a publié sur la plateforme X en déclarant que pour Fusaka, la sécurité est primordiale. 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 le téléchargement de toutes les données par un seul nœud.
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 : lorsque le publieur 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.
Ce sont toutes de nouvelles technologies, il est sage que les développeurs principaux restent super 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 avec le temps. Mais c'est la clé de l'expansion L2 (et finalement la clé de l'expansion L1, une fois que les limites de gas L1 sont suffisamment élevées pour que nous devions mettre les données d'exécution L1 dans des blobs).
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.
Le fondateur d'Ethereum, Vitalik Buterin, a déclaré sur la plateforme X que le projet Fusaka accorde une grande importance à la sécurité, et que sa fonctionnalité principale, PeerDAS, vise à créer un Blockchain en temps réel, où les nœuds n'ont besoin de demander qu'un petit nombre de blocs de données pour valider les informations. De plus, le système permet un minimum d'hypothèses de confiance, fonctionnant normalement même en présence de participants malhonnêtes. Les améliorations technologiques futures favoriseront encore la décentralisation de la construction des blocs.
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.
L'actualité du Jinse Finance rapporte que le fondateur d'Ethereum, Vitalik Buterin, a publié sur la plateforme X en déclarant que pour Fusaka, la sécurité est primordiale. 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 le téléchargement de toutes les données par un seul nœud. 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 : lorsque le publieur 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. Ce sont toutes de nouvelles technologies, il est sage que les développeurs principaux restent super 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 avec le temps. Mais c'est la clé de l'expansion L2 (et finalement la clé de l'expansion L1, une fois que les limites de gas L1 sont suffisamment élevées pour que nous devions mettre les données d'exécution L1 dans des blobs).