
Auteur : Jerry Luo de Kernel Ventures
Réviseurs : Kernel Ventures Mandy, Kernel Ventures Joshua
TLDR :
Les premières chaînes publiques exigeaient que tous les nœuds du réseau maintiennent la cohérence des données afin de garantir la sécurité et la décentralisation. Cependant, avec le développement de l’écosystème blockchain, la pression du stockage continue d’augmenter, conduisant à une tendance aux opérations centralisées des nœuds. À ce stade, la couche 1 doit résoudre de toute urgence le problème des coûts de stockage causé par la croissance du TPS.
Face à ce problème, les développeurs doivent proposer de nouvelles solutions de stockage de données historiques tout en prenant en compte la sécurité, le coût de stockage, la vitesse de lecture des données et la polyvalence de la couche DA.
Dans le processus de résolution de ce problème, de nombreuses nouvelles technologies et nouvelles idées ont émergé, notamment Sharding, DAS, Verkle Tree, les composants intermédiaires DA, etc. Ils ont essayé d'optimiser la solution de stockage de la couche DA en réduisant la redondance des données et en améliorant l'efficacité de la vérification des données.
Les solutions DA actuelles sont grossièrement divisées en deux catégories en fonction de l'emplacement de stockage des données, à savoir la chaîne principale DA et la DA tierce. La chaîne principale DA commence dans la perspective d'un nettoyage régulier des données et d'un partitionnement des données pour réduire la pression de stockage des nœuds. Les exigences de conception DA tierces visent toutes les services de stockage et proposent des solutions raisonnables pour de grandes quantités de données. Par conséquent, l’accent est mis principalement sur le compromis entre la compatibilité mono-chaîne et la compatibilité multi-chaînes, et trois solutions sont proposées : DA dédié à la chaîne principale, DA modulaire et DA à chaîne publique de stockage.
Les chaînes publiques de type paiement ont des exigences extrêmement élevées en matière de sécurité des données historiques et conviennent à l'utilisation de la chaîne principale comme couche DA. Cependant, pour les chaînes publiques qui fonctionnent depuis longtemps et dont le réseau est géré par un grand nombre de mineurs, il serait plus approprié d'adopter un DA tiers qui n'implique pas la couche consensus et prend en compte la sécurité. Les chaînes publiques complètes sont plus adaptées à l'utilisation du stockage DA dédié à la chaîne principale avec une plus grande capacité de données, un coût et une sécurité inférieurs. Mais compte tenu des besoins du DA inter-chaînes, le DA modulaire est également une bonne option.
D’une manière générale, la blockchain évolue dans le sens d’une réduction de la redondance des données et d’une division du travail multi-chaînes.
1. Origines
En tant que registre distribué, la blockchain doit stocker des données historiques sur tous les nœuds pour garantir la sécurité et une décentralisation suffisante du stockage des données. Étant donné que l'exactitude de chaque changement d'état est liée à l'état précédent (source de la transaction), afin de garantir l'exactitude des transactions, une blockchain doit en principe stocker tous les enregistrements historiques depuis la première transaction jusqu'à la transaction en cours. En prenant Ethereum comme exemple, même si la taille moyenne des blocs est estimée à 20 Ko, la taille totale actuelle des blocs Ethereum a atteint 370 Go. En plus du bloc lui-même, un nœud complet doit également enregistrer le statut et les reçus de transaction. . En comptant cette partie, la capacité de stockage totale d'un seul nœud a dépassé 1 To, ce qui concentre le fonctionnement du nœud sur quelques personnes.

Dernière hauteur de bloc d'Ethereum, source de l'image : Etherscan
La récente mise à niveau d’Ethereum Cancun vise à augmenter le TPS d’Ethereum à environ 1 000. D’ici là, la croissance annuelle du stockage d’Ethereum dépassera la somme de sa capacité de stockage actuelle. Parmi les différentes chaînes publiques hautes performances devenues populaires récemment, la vitesse de transaction de dizaines de milliers de TPS peut générer des centaines de Go de nouvelles données en moyenne chaque jour. La méthode de redondance des données commune à l'ensemble du nœud du réseau est évidemment incapable de s'adapter à une telle pression de stockage. La couche 1 doit trouver une solution adaptée pour équilibrer la croissance du TPS et le coût de stockage du nœud.
2. Indicateurs de performance du DA
2.1 Sécurité
Par rapport aux structures de stockage de bases de données ou de listes chaînées, la non-falsification de la blockchain vient de la capacité de vérifier les données nouvellement générées via des données historiques. Par conséquent, garantir la sécurité des données historiques est la première question à prendre en compte dans le stockage de la couche DA. Lorsque nous évaluons la sécurité des données des systèmes blockchain, nous l'analysons souvent à partir de la quantité de redondance des données et de la méthode de vérification de la disponibilité des données.
Quantité de redondance : en ce qui concerne la redondance des données dans le système blockchain, elle peut principalement jouer les rôles suivants : Premièrement, si le nombre de redondances dans le réseau est plus important, lorsque le vérificateur doit vérifier l'état du compte dans un certain bloc historique pour verify Lorsqu'une transaction est en cours de vérification, elle peut obtenir le plus grand nombre d'échantillons pour référence et sélectionner les données enregistrées par la plupart des nœuds. Dans les bases de données traditionnelles, étant donné que les données ne sont stockées que sous forme de paires clé-valeur sur un certain nœud, les modifications des données historiques ne peuvent être effectuées que sur un seul nœud, et le coût de l'attaque est extrêmement faible, en théorie, plus il est élevé. Il y aura davantage de licenciements, moins les données seront vraisemblables, plus le degré de crédibilité sera élevé. Dans le même temps, plus les nœuds sont stockés, moins les données risquent d'être perdues. Cela peut également être comparé au serveur centralisé qui stocke les jeux Web2. Une fois tous les serveurs backend arrêtés, le serveur sera complètement arrêté. Cependant, plus c'est mieux, car chaque élément de redondance apportera de l'espace de stockage supplémentaire. Une redondance excessive des données entraînera une pression de stockage excessive sur le système. Une bonne couche DA doit choisir une approche redondante qui équilibre la sécurité et l'efficacité du stockage.
Vérification de la disponibilité des données : le nombre de redondances garantit qu'il y a suffisamment d'enregistrements de données dans le réseau, mais l'exactitude et l'exhaustivité des données à utiliser doivent être vérifiées. La méthode de vérification couramment utilisée dans la blockchain actuelle est l'algorithme d'engagement cryptographique, qui conserve un petit engagement cryptographique à enregistrer sur l'ensemble du réseau. Cet engagement est obtenu en mélangeant les données de transaction. Lorsque vous souhaitez tester l'authenticité d'une certaine donnée historique, vous devez restaurer l'engagement cryptographique à travers les données et vérifier si l'engagement cryptographique obtenu par cette restauration est cohérent avec les enregistrements de l'ensemble du réseau. , la vérification est réussie. Les algorithmes de vérification cryptographique couramment utilisés incluent Merkle Root et Verkle Root. L'algorithme de vérification de la disponibilité des données de haute sécurité ne nécessite qu'une petite quantité de données de vérification et peut vérifier rapidement les données historiques.
2.2 Frais de stockage
Dans l’optique d’assurer une sécurité de base, le prochain objectif principal que la couche DA doit atteindre est de réduire les coûts et d’augmenter l’efficacité. La première consiste à réduire les coûts de stockage, quelles que soient les différences de performances matérielles, c'est-à-dire à réduire l'utilisation de la mémoire provoquée par le stockage des données de taille unitaire. À ce stade, les principaux moyens de réduire les coûts de stockage dans la blockchain sont d'adopter la technologie de partitionnement et d'utiliser un stockage basé sur les récompenses pour garantir que les données sont efficacement stockées et réduire le nombre de sauvegardes de données. Cependant, il n'est pas difficile de voir à partir des méthodes d'amélioration ci-dessus qu'il existe une relation de jeu entre le coût du stockage et la sécurité des données. La réduction de l'occupation du stockage signifie souvent une diminution de la sécurité. Par conséquent, une excellente couche DA doit parvenir à un équilibre entre le coût du stockage et la sécurité des données. De plus, si la couche DA est une chaîne publique distincte, elle doit réduire les coûts en minimisant le processus intermédiaire d'échange de données. Dans chaque processus de transfert, les données d'index doivent être laissées pour les appels de requête ultérieurs. processus, plus il restera de données d’index et le coût de stockage augmentera. Enfin, le coût du stockage des données est directement lié à la pérennité des données. De manière générale, plus le coût de stockage des données est élevé, plus il est difficile pour la chaîne publique de stocker les données de manière persistante.
2.3 Vitesse de lecture des données
Après avoir réduit les coûts, l’étape suivante consiste à accroître l’efficacité, c’est-à-dire la capacité d’appeler rapidement des données hors de la couche DA lorsqu’elles doivent être utilisées. Ce processus comporte deux étapes. La première consiste à rechercher des nœuds qui stockent des données. Ce processus s'adresse principalement aux chaînes publiques qui n'ont pas atteint la cohérence des données sur l'ensemble du réseau. Si la chaîne publique parvient à synchroniser les données pour les nœuds sur l'ensemble du réseau. peut être ignoré. La consommation de temps d’un processus. Deuxièmement, dans les systèmes de blockchain traditionnels actuels, notamment Bitcoin, Ethereum et Filecoin, la méthode de stockage des nœuds est la base de données Leveldb. Dans Leveldb, les données sont stockées de trois manières. Premièrement, les données écrites immédiatement seront stockées dans des fichiers de type Memtable. Lorsque le stockage Memtable est plein, le type de fichier passera de Memtable à Immutable Memtable. Les deux types de fichiers sont stockés en mémoire, mais les fichiers Immutable Memtable ne peuvent plus être modifiés, seules les données peuvent en être lues. Le stockage à chaud utilisé dans le réseau IPFS stocke les données dans cette partie. Lorsqu'il est appelé, il peut être rapidement lu à partir de la mémoire. Cependant, la mémoire mobile d'un nœud ordinaire est souvent de niveau Go et il est facile d'écrire lentement. et lorsqu'un nœud tombe en panne ou qu'une autre situation anormale se produit, les données dans la mémoire seront définitivement perdues. Si vous souhaitez que les données soient stockées de manière persistante, vous devez les stocker sous la forme d'un fichier SST sur un disque SSD. Cependant, lors de la lecture des données, vous devez d'abord les lire dans la mémoire. ce qui réduit considérablement la vitesse d’indexation des données. Enfin, pour les systèmes qui utilisent le stockage partagé, la restauration des données nécessite l'envoi de requêtes de données à plusieurs nœuds et leur restauration. Ce processus réduira également la vitesse de lecture des données.

Méthode de stockage de données Leveldb, source de l'image : Manuel Leveldb
Polyvalence de la couche 2.4 DA
Avec le développement de DeFi et divers problèmes liés au CEX, les exigences des utilisateurs en matière de transactions inter-chaînes d'actifs décentralisés augmentent également. Quel que soit le mécanisme inter-chaînes de verrouillage de hachage, de notaire public ou de chaîne de relais, la détermination simultanée des données historiques sur les deux chaînes ne peut être évitée. La clé de ce problème réside dans la séparation des données sur les deux chaînes, et une communication directe ne peut pas être réalisée dans différents systèmes décentralisés. Par conséquent, une solution est proposée à ce stade en modifiant la méthode de stockage de la couche DA, qui non seulement stocke les données historiques de plusieurs chaînes publiques sur la même chaîne publique de confiance, mais doit uniquement appeler les données sur cette chaîne publique lors de la vérification. . Cela nécessite que la couche DA soit capable d'établir des méthodes de communication sécurisées avec différents types de chaînes publiques, ce qui signifie que la couche DA a une bonne polyvalence.
3. Exploration des technologies liées à l'AD
3.1 Partage
Dans un système distribué traditionnel, un fichier n'est pas stocké sous une forme complète sur un certain nœud. Au lieu de cela, les données d'origine sont divisées en plusieurs blocs et un bloc est stocké dans chaque nœud. Et les blocs ne sont souvent pas stockés sur un seul nœud, mais laisseront des sauvegardes appropriées sur d'autres nœuds. Dans les systèmes distribués grand public existants, ce nombre de sauvegardes est généralement défini sur 2. Ce mécanisme de fragmentation peut réduire la pression de stockage d'un seul nœud, étendre la capacité totale du système à la somme de la capacité de stockage de chaque nœud et en même temps assurer la sécurité du stockage grâce à une redondance de données appropriée. Le schéma de Sharding adopté dans la blockchain est généralement similaire, mais les détails spécifiques seront différents. Tout d'abord, étant donné que chaque nœud de la blockchain n'est pas digne de confiance par défaut, le processus de mise en œuvre du Sharding nécessite une quantité de sauvegarde de données suffisamment importante pour pouvoir juger ultérieurement de l'authenticité des données. Le nombre de sauvegardes pour ce nœud doit donc être bien supérieur à 2. . Idéalement, dans un système blockchain utilisant ce schéma de stockage, si le nombre total de nœuds de vérification est T et le nombre de fragments est N, alors le nombre de sauvegardes devrait être T/N. Le deuxième est le processus de stockage des blocs. Il y a moins de nœuds dans les systèmes distribués traditionnels, donc un nœud s'adapte souvent à plusieurs blocs de données. Tout d'abord, les données sont mappées sur l'anneau de hachage via un algorithme de hachage cohérent, puis chaque nœud stocke les données. blocs numérotés dans une certaine plage, et peut accepter qu'un nœud n'attribue pas de tâches de stockage pendant un certain stockage. Sur la blockchain, l'attribution d'un bloc à chaque nœud n'est plus un événement aléatoire mais un événement inévitable. Chaque nœud sélectionnera au hasard un bloc pour le stockage. Ce processus combine les données d'origine avec le bloc et les propres informations du nœud. le hachage des données est complété en prenant le module du nombre de fragments. En supposant que chaque élément de données est divisé en N blocs, la taille de stockage réelle de chaque nœud n'est que de 1/N de celle d'origine. En définissant N de manière appropriée, un équilibre entre l'augmentation du TPS et la pression de stockage des nœuds peut être atteint.

Méthode de stockage des données après Sharding, source de l'image : Kernel Ventures
3.2 DAS (échantillonnage de la disponibilité des données)
La technologie DAS est basée sur une optimisation plus poussée des méthodes de stockage Sharding. Pendant le processus de Sharding, en raison du simple stockage aléatoire des nœuds, un certain bloc peut être perdu. Deuxièmement, pour les données fragmentées, il est également très important de confirmer l’authenticité et l’intégrité des données lors du processus de restauration. Dans DAS, ces deux problèmes sont résolus grâce au code Eraser et à l'engagement polynomial KZG.
Code Eraser : Compte tenu du grand nombre de nœuds de vérification dans Ethereum, la probabilité qu'un certain bloc ne soit stocké par aucun nœud est presque nulle, mais en théorie, il existe toujours la possibilité qu'une situation aussi extrême se produise. Afin d'atténuer cette éventuelle menace de perte de stockage, dans ce schéma, les données originales ne sont souvent pas directement divisées en blocs pour le stockage. Au lieu de cela, les données originales sont d'abord mappées sur les coefficients d'un polynôme d'ordre n, puis 2n est. pris à partir des points polynomiaux et laissez le nœud en sélectionner un au hasard pour le stockage. Pour ce polynôme d'ordre n, seuls n+1 points sont nécessaires pour le restaurer. Par conséquent, seule la moitié des blocs doivent être sélectionnés par les nœuds, et nous pouvons restaurer les données d'origine. Grâce au code Eraser, la sécurité du stockage des données et la capacité de récupération des données du réseau sont améliorées.
Engagement polynomial KZG : une partie très importante du stockage des données est la vérification de l'authenticité des données. Dans un réseau qui n'utilise pas le code Eraser, diverses méthodes peuvent être utilisées dans le processus de vérification. Cependant, si le code Eraser ci-dessus est introduit pour améliorer la sécurité des données, une méthode plus appropriée consiste à utiliser l'engagement polynomial KZG. L'engagement polynomial KZG peut vérifier directement le contenu d'un seul bloc sous forme de polynômes, éliminant ainsi le processus de réduction des polynômes en données binaires. Le formulaire de vérification est généralement similaire à Merkle Tree, mais ne nécessite pas de données de nœud de chemin spécifiques, uniquement KZG. Root Son authenticité peut être vérifiée avec les données de bloc.
3.3 Méthode de vérification des données de la couche DA
La vérification des données garantit que les données appelées depuis le nœud n'ont pas été falsifiées et n'ont pas été perdues. Afin de minimiser la quantité de données et les coûts de calcul requis dans le processus de vérification, la couche DA utilise actuellement une structure arborescente comme méthode de vérification principale. La forme la plus simple consiste à utiliser Merkle Tree pour la vérification, qui est enregistrée sous la forme d'un arbre binaire complet. Il vous suffit de conserver une racine Merkle et la valeur de hachage du sous-arbre de l'autre côté du chemin du nœud pour vérifier. le temps de vérification est compliqué. Le degré est de niveau O (logN) (si logN n'ajoute pas la base, la valeur par défaut est log2 (N)). Bien que le processus de vérification ait été considérablement simplifié, le volume global de données du processus de vérification augmente toujours avec l'augmentation des données. Afin de résoudre le problème de l'augmentation du volume de vérification, une autre méthode de vérification, Verkle Tree, est proposée à ce stade. En plus de stocker la valeur, chaque nœud de Verkle Tree est également livré avec un engagement vectoriel Grâce à la valeur du nœud d'origine et à cette preuve d'engagement, l'authenticité des données peut être rapidement vérifiée sans appeler les valeurs d'une autre sœur. nœuds, ce qui fait que chaque Le nombre de calculs de vérification est uniquement lié à la profondeur de l'arbre de Verkle et est une constante fixe, ce qui accélère considérablement la vitesse de vérification. Cependant, le calcul du Vector Commitment nécessite la participation de tous les nœuds frères sur la même couche, ce qui augmente considérablement le coût d'écriture et de modification des données. Cependant, pour les données telles que les données historiques qui sont stockées de manière permanente et ne peuvent pas être falsifiées et doivent uniquement être lues mais pas écrites, Verkle Tree est extrêmement approprié. De plus, Merkle Tree et Verkle Tree eux-mêmes ont des variantes sous forme K-ary. Leurs mécanismes de mise en œuvre spécifiques sont similaires, sauf que le nombre de sous-arbres sous chaque nœud est modifié. Une comparaison de leurs performances spécifiques peut être vue dans le tableau ci-dessous.

Comparaison des performances temporelles des méthodes de vérification des données, source d'image : Verkle Trees
3.4 Middleware général DA
L’expansion continue de l’écosystème blockchain a entraîné une augmentation continue du nombre de chaînes publiques. En raison des avantages et du caractère irremplaçable de chaque chaîne publique dans leurs domaines respectifs, il est presque impossible pour les chaînes publiques de couche 1 de s'unifier en peu de temps. Cependant, avec le développement de DeFi et divers problèmes liés au CEX, les besoins des utilisateurs en matière d’actifs de trading inter-chaînes décentralisés augmentent également. Par conséquent, le stockage de données multi-chaînes sur la couche DA, capable d'éliminer les problèmes de sécurité dans les interactions de données entre chaînes, a reçu de plus en plus d'attention. Cependant, pour accepter les données historiques de différentes chaînes publiques, la couche DA doit fournir un protocole décentralisé pour un stockage et une vérification standardisés des flux de données. Par exemple, kvye, un middleware de stockage basé sur Arweave, prend l'initiative de capturer les données de la chaîne. et toutes les données de la chaîne sont stockées dans Arweave sous une forme standard afin de minimiser les différences dans le processus de transmission des données. Relativement parlant, la couche 2, qui fournit spécifiquement le stockage de données de la couche DA pour une certaine chaîne publique, interagit avec les données via des nœuds partagés internes. Bien qu'elle réduise le coût de l'interaction et améliore la sécurité, elle présente des limites relativement importantes et ne peut fournir des données qu'à un public spécifique. les chaînes fournissent des services.
4. Solution de stockage de couche DA
4.1 Chaîne principale DA
4.1.1 DankSharding de classe
Ce type de solution de stockage n'a pas encore de nom défini, et le représentant le plus important est DankSharding sur Ethereum, cet article utilise donc la classe DankSharding pour faire référence à ce type de solution. Ce type de solution utilise principalement les deux technologies de stockage DA évoquées ci-dessus, Sharding et DAS. Tout d'abord, les données sont divisées en partages appropriés via Sharding, puis chaque nœud extrait un bloc de données sous forme de DAS pour le stockage. S'il y a suffisamment de nœuds dans l'ensemble du réseau, nous pouvons choisir un plus grand nombre de fragments N, de sorte que la pression de stockage de chaque nœud ne soit que de 1/N de celle d'origine, obtenant ainsi une expansion N fois de l'espace de stockage global. Dans le même temps, afin d'éviter une situation extrême dans laquelle un certain bloc n'est stocké dans aucun bloc, DankSharding encode les données à l'aide d'Eraser Code, et seule la moitié des données peut être complètement restaurée. La dernière étape est le processus de vérification des données, qui utilise la structure arborescente de Verkle et l'engagement polynomial pour obtenir une vérification rapide.
4.1.2 Stockage à court terme
Pour le DA de la chaîne principale, une des méthodes de traitement de données les plus simples consiste à stocker des données historiques à court terme. Essentiellement, la blockchain joue le rôle d'un grand livre public, permettant aux modifications apportées au contenu du grand livre d'être observées par l'ensemble du réseau, sans avoir besoin d'un stockage permanent. En prenant Solana comme exemple, bien que ses données historiques soient synchronisées avec Arweave, le nœud du réseau principal ne conserve que les données de transaction des deux derniers jours. Sur la chaîne publique basée sur les enregistrements de compte, les données historiques conservent à chaque instant le statut final du compte sur la blockchain, ce qui est suffisant pour fournir une base de vérification des modifications au moment suivant. Pour les projets ayant des besoins particuliers en données avant cette période, ils peuvent les stocker eux-mêmes sur d'autres chaînes publiques décentralisées ou par un tiers de confiance. En d’autres termes, ceux qui ont des besoins supplémentaires en données doivent payer pour le stockage des données historiques.
4.2 DA tiers
4.2.1 DA spécifique à la chaîne principale : EthStorage
DA spécifique à la chaîne principale : la chose la plus importante à propos de la couche DA est la sécurité de la transmission des données. La plus sécurisée à ce stade est le DA de la chaîne principale. Cependant, le stockage de la chaîne principale est soumis aux limitations de l'espace de stockage et à la concurrence pour les ressources. Par conséquent, lorsque la quantité de données sur le réseau augmente rapidement, un DA tiers sera un meilleur choix si l'on veut parvenir à un stockage à long terme des données. Si le DA tiers a une compatibilité plus élevée avec le réseau principal, il peut réaliser le partage de nœuds et il bénéficiera également d'une sécurité plus élevée pendant le processus d'interaction des données. Par conséquent, dans le cadre de la prise en compte de la sécurité, le DA spécifique à la chaîne principale présentera d'énormes avantages. En prenant Ethereum comme exemple, une exigence de base pour un DA spécifique à la chaîne principale est d'être compatible avec EVM et d'assurer l'interopérabilité avec les données et les contrats Ethereum. Les projets représentatifs incluent Topia, EthStorage, etc. Parmi eux, EthStorage est actuellement le plus développé en termes de compatibilité, car en plus de la compatibilité au niveau EVM, il a également spécialement mis en place des interfaces pertinentes pour se connecter aux outils de développement Ethereum tels que Remix et Hardhat pour obtenir une compatibilité au niveau. Niveau de l’outil de développement Ethereum.
EthStorage : EthStorage est une chaîne publique indépendante d'Ethereum, mais les nœuds qui y fonctionnent sont supérieurs aux nœuds Ethereum, c'est-à-dire que les nœuds exécutant EthStorage peuvent également exécuter Ethereum en même temps. Grâce aux codes d'opération sur Ethereum, vous pouvez y accéder directement. EthStorage. EthStorage effectue des opérations. Dans le modèle de stockage d'EthStorage, seule une petite quantité de métadonnées est conservée sur le réseau principal Ethereum à des fins d'indexation, créant ainsi une base de données décentralisée pour Ethereum. Dans la solution actuelle, EthStorage implémente l'interaction entre le réseau principal Ethereum et EthStorage en déployant un contrat EthStorage sur le réseau principal Ethereum. Si Ethereum souhaite stocker des données, il doit appeler la fonction put() dans le contrat. Les paramètres d'entrée sont des variables à deux octets key et data, où data représente les données à stocker, et key est leur emplacement dans le réseau Ethereum. L'identification peut être considérée comme similaire à l'existence de CID dans IPFS. Une fois la paire de données (clé, données) stockée avec succès dans le réseau EthStorage, EthStorage générera un kvldx et le renverra au réseau principal Ethereum, et correspondra à la clé sur Ethereum. Cette valeur correspond à l'adresse de stockage des données sur Ethereum. EthStorage, donc c'est à l'origine possible. Le problème de la nécessité de stocker de grandes quantités de données devient désormais le stockage d'une seule paire (clé, kvldx), réduisant ainsi considérablement le coût de stockage du réseau principal Ethereum. Si vous devez appeler des données précédemment stockées, vous devez utiliser la fonction get() dans EthStorage et entrer le paramètre key. Vous pouvez rechercher rapidement les données sur EthStorage via kvldx stocké dans Ethereum.

Contrat EthStorage, source de l'image : Kernel Ventures
En ce qui concerne la manière dont les nœuds stockent spécifiquement les données, EthStorage s'appuie sur le modèle Arweave. Premièrement, un grand nombre de paires (k, v) d'ETH sont fragmentées. Chaque fragment contient un nombre fixe de paires de données (k, v). Il existe également une limite sur la taille spécifique de chaque paire (k, v). De cette manière, l'équité de la charge de travail ultérieure pour les mineurs dans le processus de récompense du stockage est garantie. Pour l'émission des récompenses, il faut d'abord vérifier si le nœud stocke des données. Au cours de ce processus, EthStorage divisera un fragment (taille au niveau de la To) en plusieurs morceaux et conservera une racine Merkle sur le réseau principal Ethereum pour vérification. Ensuite, le mineur doit d'abord fournir un nonce pour générer les adresses de plusieurs morceaux via un algorithme aléatoire avec le hachage du bloc précédent sur EthStorage. Le mineur doit fournir les données de ces morceaux pour prouver qu'il stocke bien l'intégralité du Sharding. Mais ce nombre occasionnel ne peut pas être sélectionné arbitrairement, sinon le nœud sélectionnera un nombre occasionnel approprié qui correspond uniquement à son fragment stocké et réussira la vérification. Par conséquent, ce nombre occasionnel doit être tel que la valeur de difficulté du fragment généré puisse répondre aux exigences du réseau après le mélange. et hachage, et seul le premier nœud à soumettre la preuve d'accès occasionnel et aléatoire peut obtenir la récompense.
4.2.2 DA modulaire : Celestia
Module Blockchain : à ce stade, les transactions devant être effectuées par la chaîne publique de couche 1 sont principalement divisées en quatre parties suivantes : (1) Concevoir la logique sous-jacente du réseau, sélectionner les nœuds de vérification d'une certaine manière, écrire des blocs et allouer récompenses pour les responsables du réseau ; (2) Regrouper et traiter les transactions et publier les transactions associées ; (3) Vérifier les transactions à télécharger sur la chaîne et déterminer le statut final (4) Stocker et conserver les données historiques sur la blockchain ; Selon les différentes fonctions réalisées, on peut diviser la blockchain en quatre modules, à savoir la couche consensus, la couche d'exécution, la couche de règlement et la couche de disponibilité des données (couche DA).
Conception de blockchain modulaire : Depuis longtemps, ces quatre modules ont été intégrés dans une chaîne publique. Une telle blockchain est appelée blockchain unique. Cette forme est plus stable et plus facile à maintenir, mais elle exerce également une pression énorme sur une seule chaîne publique. En fonctionnement réel, ces quatre modules se contraignent mutuellement et se disputent les ressources limitées de calcul et de stockage de la chaîne publique. Par exemple, pour augmenter la vitesse de traitement de la couche de traitement, cela entraînera une plus grande pression de stockage sur la couche de disponibilité des données. Pour assurer la sécurité de la couche d'exécution, un mécanisme de vérification plus complexe est nécessaire mais ralentit la vitesse de traitement des transactions. Par conséquent, le développement des chaînes publiques se heurte souvent à des compromis entre ces quatre modules. Afin de surmonter le goulot d'étranglement lié à l'amélioration des performances de la chaîne publique, les développeurs ont proposé une solution modulaire de blockchain. L'idée centrale de la blockchain modulaire est de séparer un ou plusieurs des quatre modules mentionnés ci-dessus et de les implémenter sur une chaîne publique distincte. De cette manière, la chaîne publique ne peut se concentrer que sur l’amélioration de la vitesse des transactions ou de la capacité de stockage, dépassant ainsi les limitations précédentes des performances globales de la blockchain dues à des lacunes.
DA modulaire : la méthode complexe consistant à séparer la couche DA de l'activité blockchain et à la confier à une chaîne publique est considérée comme une solution réalisable aux données historiques croissantes de la couche 1. L'exploration dans cette zone en est encore à ses débuts à ce stade, et le projet le plus représentatif à l'heure actuelle est Celestia. En termes de méthode de stockage spécifique, Celestia s'appuie sur la méthode de stockage de Danksharding, qui divise également les données en plusieurs blocs, et chaque nœud en extrait une partie pour le stockage et utilise l'engagement polynomial KZG pour vérifier l'intégrité des données. Dans le même temps, Celestia utilise un code d'effacement RS bidimensionnel avancé pour réécrire les données originales sous la forme d'une matrice k*k. Au final, seulement 25 % des données originales peuvent être récupérées. Cependant, le stockage par partage de données multiplie simplement la pression de stockage de l'ensemble du nœud du réseau par un coefficient sur le volume total de données. La pression de stockage du nœud et le volume de données maintiennent toujours une croissance linéaire. Alors que la couche 1 continue d’améliorer sa vitesse de transaction, la pression de stockage des nœuds pourrait encore un jour atteindre un niveau critique inacceptable. Afin de résoudre ce problème, le composant IPLD est introduit dans Celestia pour le traitement. Les données de la matrice k*k ne sont pas stockées directement sur Celestia, mais sont stockées dans le réseau LL-IPFS, et seul le code CID des données sur IPFS est conservé dans le nœud. Lorsqu'un utilisateur demande une donnée historique, le nœud enverra le CID correspondant au composant IPLD et les données d'origine seront appelées sur IPFS via ce CID. Si les données existent sur IPFS, elles seront renvoyées via le composant et le nœud IPLD ; si elles n'existent pas, les données ne peuvent pas être renvoyées ;

Méthode de lecture des données Celestia, source d'image : Celestia Core
Celestia : En prenant Celestia comme exemple, nous pouvons avoir un aperçu de l'application de la blockchain modulaire pour résoudre le problème de stockage d'Ethereum. Le nœud Rollup enverra les données de transaction packagées et vérifiées à Celestia et stockera les données sur Celestia. Au cours de ce processus, Celestia stockera uniquement les données sans trop de conscience. Enfin, le nœud Rollup sera basé sur la taille de l'espace de stockage correspondant. Les jetons Tia seront payés à Celestia à titre de frais de stockage. Le stockage dans Celstia utilise DAS et des codes d'effacement similaires à ceux d'EIP4844, mais les codes d'effacement polynomiaux d'EIP4844 sont mis à niveau et des codes d'effacement RS bidimensionnels sont utilisés pour améliorer à nouveau la sécurité du stockage. données de transaction complètes. Il s’agit essentiellement d’une chaîne publique de points de vente avec de faibles coûts de stockage. Si elle doit être utilisée pour résoudre le problème de stockage des données historiques d’Ethereum, de nombreux autres modules spécifiques sont nécessaires pour coopérer avec Celestia. Par exemple, en termes de rollup, un mode de rollup fortement recommandé sur le site officiel de Celestia est Sovereign Rollup. Différent du Rollup commun sur Layer2, il calcule et vérifie uniquement les transactions, c'est-à-dire complète les opérations de la couche d'exécution. Sovereign Rollup inclut l'ensemble du processus d'exécution et de règlement, ce qui minimise le traitement des transactions sur Celestia. Lorsque la sécurité globale de Celestia est plus faible que celle d'Ethereum, cette mesure peut maximiser la sécurité du processus global de transaction. En termes d'assurer la sécurité des données appelées par Celestia, le réseau principal d'Ethereum, la solution la plus courante à l'heure actuelle est le contrat intelligent de pont à gravité quantique. Pour les données stockées sur Celestia, il générera une racine Merkle (preuve de disponibilité des données) et la conservera sur le contrat de pont gravitationnel quantique du réseau principal Ethereum. Chaque fois qu'Ethereum appellera les données historiques sur Celestia, son résultat de hachage sera comparé. avec Merkle Root est utilisé à des fins de comparaison, et si cela correspond, cela signifie qu'il s'agit bien de données historiques réelles.
4.2.3 Stockage de la chaîne publique DA
En termes de principes techniques DA de la chaîne principale, de nombreuses technologies similaires au Sharding sont empruntées à la chaîne publique de stockage. Parmi les DA tiers, certains utilisent directement la chaîne publique de stockage pour effectuer certaines tâches de stockage. Par exemple, les données de transaction spécifiques dans Celestia sont placées sur le réseau LL-IPFS. Dans la solution DA tierce, en plus de créer une chaîne publique distincte pour résoudre le problème de stockage de la couche 1, un moyen plus direct consiste à connecter directement la chaîne publique de stockage à la couche 1 pour stocker les énormes données historiques sur la couche 1. Pour les blockchains hautes performances, le volume de données historiques est encore plus important. Lorsqu'elle fonctionne à pleine vitesse, le volume de données de la chaîne publique hautes performances Solana est proche de 4 PG, ce qui dépasse complètement la plage de stockage des nœuds ordinaires. La solution choisie par Solana est de stocker les données historiques sur le réseau de stockage décentralisé Arweave et de ne conserver que 2 jours de données sur les principaux nœuds du réseau pour vérification. Afin d'assurer la sécurité du processus stocké, Solana et Arweave Chain ont spécialement conçu un protocole de pont de stockage, Solar Bridge. Les données vérifiées par le nœud Solana seront synchronisées avec Arweave et la balise correspondante sera renvoyée. Ce n'est que grâce à cette balise que le nœud Solana peut consulter à tout moment les données historiques de la blockchain Solana. Sur Arweave, il n'est pas nécessaire que tous les nœuds du réseau maintiennent la cohérence des données et l'utilisent comme seuil pour participer au fonctionnement du réseau. Au lieu de cela, le stockage des récompenses est adopté. Tout d’abord, Arweave n’utilise pas une structure de chaîne traditionnelle pour construire des blocs, mais s’apparente davantage à une structure de graphe. Dans Arweave, un nouveau bloc pointera non seulement vers le bloc précédent, mais pointera également de manière aléatoire vers un bloc de rappel généré. L'emplacement spécifique du bloc de rappel est déterminé par le résultat de hachage de son bloc précédent et sa hauteur de bloc. L'emplacement du bloc de rappel est inconnu jusqu'à ce que le bloc précédent soit extrait. Cependant, lors du processus de génération d'un nouveau bloc, le nœud doit disposer des données de bloc de rappel pour utiliser le mécanisme POW afin de calculer le hachage de la difficulté spécifiée. Seul le premier mineur à calculer le hachage qui répond à la difficulté peut obtenir la récompense. ce qui encourage les mineurs à stocker autant de données historiques que possible. Dans le même temps, moins il y a de personnes qui stockent un certain bloc historique, les nœuds auront moins de concurrents lors de la génération de cas occasionnels qui répondent à la difficulté, encourageant les mineurs à stocker moins de blocs dans le réseau.Enfin, afin de garantir que les nœuds stockent en permanence les données dans Arweave, il introduit le mécanisme de notation des nœuds de WildFire. Les nœuds auront tendance à communiquer plus rapidement avec des nœuds capables de fournir plus de données historiques, tandis que les nœuds avec des notes inférieures sont souvent incapables d'obtenir les dernières données de bloc et de transaction dès que possible et ne peuvent donc pas profiter de la concurrence POW.

Méthode de construction des blocs Arweave, source de l'image : Arweave Yellow-Paper
5. Comparaison complète
Nous comparerons ensuite les avantages et les inconvénients des cinq solutions de stockage en fonction des quatre dimensions des indicateurs de performance DA.
Sécurité : La plus grande source de problèmes de sécurité des données est la perte causée lors du processus de transmission des données et la falsification malveillante de la part de nœuds malhonnêtes. Dans le processus inter-chaînes, en raison de l'indépendance et de l'état des deux chaînes publiques, la sécurité de la transmission des données est primordiale. zones les plus durement touchées. De plus, la couche 1, qui nécessite actuellement une couche DA dédiée, bénéficie souvent d'un groupe de consensus fort et sa propre sécurité sera bien supérieure à celle des chaînes publiques de stockage ordinaires. Par conséquent, la solution DA de la chaîne principale offre une sécurité plus élevée. Après avoir assuré la sécurité de la transmission des données, l’étape suivante consiste à assurer la sécurité des données d’appel. Si seules les données historiques à court terme utilisées pour vérifier les transactions sont prises en compte, les mêmes données sont sauvegardées sur l'ensemble du réseau dans le réseau de stockage temporaire. Dans une solution de type DankSharding, le nombre moyen de sauvegardes de données n'est que de 1/N. En fonction du nombre de nœuds dans l'ensemble du réseau, une plus grande redondance des données peut rendre les données moins susceptibles d'être perdues et peut également fournir davantage d'échantillons de référence lors de la vérification. Par conséquent, le stockage temporaire offrira une sécurité des données relativement plus élevée. Dans la solution DA tierce, le DA spécifique à la chaîne principale utilise des nœuds publics avec la chaîne principale, et les données peuvent être directement transmises via ces nœuds relais pendant le processus inter-chaînes, elle aura donc une sécurité relativement plus élevée que les autres solutions DA. .
Coûts de stockage : le facteur le plus important affectant les coûts de stockage est la quantité de redondance des données. Dans la solution de stockage à court terme de la chaîne principale DA, elles sont stockées sous forme de synchronisation des données de l'ensemble des nœuds du réseau. Toutes les données nouvellement stockées doivent être sauvegardées dans l'ensemble des nœuds du réseau, ce qui entraîne le coût de stockage le plus élevé. Le coût de stockage élevé détermine à son tour que cette méthode ne convient qu'au stockage temporaire dans des réseaux à TPS élevé. La seconde est la méthode de stockage du Sharding, y compris le Sharding dans la chaîne principale et le Sharding dans un DA tiers. Étant donné que la chaîne principale comporte souvent plus de nœuds, un bloc correspondant aura également plus de sauvegardes, de sorte que la solution Sharding de la chaîne principale aura des coûts plus élevés. Le coût de stockage le plus bas est la chaîne publique de stockage DA qui adopte une méthode de stockage avec récompense. Dans le cadre de ce schéma, la quantité de redondance des données fluctue souvent autour d'une constante fixe. Dans le même temps, un mécanisme d'ajustement dynamique est également introduit dans la chaîne publique de stockage DA pour inciter les nœuds à stocker moins de données sauvegardées en augmentant les récompenses pour assurer la sécurité des données.
Vitesse de lecture des données : la vitesse de stockage des données est principalement affectée par l'emplacement de stockage des données dans l'espace de stockage, le chemin de l'index des données et la répartition des données dans les nœuds. Parmi eux, l'emplacement de stockage des données sur le nœud a un plus grand impact sur la vitesse, car le stockage des données en mémoire ou sur SSD peut entraîner une différence de vitesse de lecture des dizaines de fois. Le stockage de la chaîne publique DA utilise principalement le stockage SSD, car la charge sur cette chaîne inclut non seulement les données de la couche DA, mais également les données personnelles nécessitant une utilisation élevée de la mémoire, telles que des vidéos et des images téléchargées par les utilisateurs. Si le réseau n'utilise pas le SSD comme espace de stockage, il sera difficile de supporter une pression de stockage énorme et de répondre aux besoins de stockage à long terme. Deuxièmement, pour les DA tiers et les DA de chaîne principale qui utilisent la mémoire pour stocker des données, le DA tiers doit d'abord rechercher les données d'index correspondantes dans la chaîne principale, puis transférer les données d'index à travers la chaîne vers le tiers. -party DA et renvoyez-le via les données du pont de stockage. En revanche, la chaîne principale DA peut interroger directement les données des nœuds et a donc une vitesse de récupération des données plus rapide. Enfin, au sein de la chaîne principale DA, la méthode Sharding nécessite d'appeler Block à partir de plusieurs nœuds et de restaurer les données d'origine. Par conséquent, par rapport au stockage à court terme sans stockage fragmenté, la vitesse sera plus lente.
Universalité de la couche DA : L'universalité DA de la chaîne principale est proche de zéro, car il est impossible de transférer des données d'une chaîne publique avec un espace de stockage insuffisant vers une autre chaîne publique avec un espace de stockage insuffisant. En DA tiers, la polyvalence d'une solution et sa compatibilité avec une chaîne principale spécifique sont des indicateurs contradictoires. Par exemple, dans la solution DA spécifique à la chaîne principale conçue pour une certaine chaîne principale, de nombreuses améliorations ont été apportées au niveau du type de nœud et du consensus du réseau pour s'adapter à la chaîne publique. Par conséquent, ces améliorations joueront un rôle dans la communication. avec d'autres chaînes publiques, un énorme obstacle. Au sein du DA tiers, la chaîne publique de stockage DA est plus performante en termes de polyvalence que le DA modulaire. La chaîne publique de stockage DA dispose d'une communauté de développeurs plus large et de davantage d'installations d'expansion, qui peuvent s'adapter aux conditions des différentes chaînes publiques. Dans le même temps, la chaîne publique de stockage DA acquiert des données plus activement via la capture de paquets, plutôt que de recevoir passivement des informations transmises par d'autres chaînes publiques. Par conséquent, il peut coder les données à sa manière, réaliser un stockage standardisé des flux de données, faciliter la gestion des informations de données provenant de différentes chaînes principales et améliorer l'efficacité du stockage.

Comparaison des performances des solutions de stockage, source de l'image : Kernel Ventures
6. Résumé
La blockchain actuelle subit une transformation de Crypto vers le Web3 plus inclusif. Ce processus n'apporte pas seulement une richesse de projets sur la blockchain. Afin de permettre le fonctionnement simultané d'autant de projets sur Layer1 tout en garantissant l'expérience des projets Gamefi et Socialfi, Layer1 représenté par Ethereum a adopté des méthodes telles que Rollup et Blobs pour améliorer le TPS. Parmi les nouvelles blockchains, le nombre de blockchains performantes augmente également. Mais un TPS plus élevé signifie non seulement des performances plus élevées, mais également une plus grande pression de stockage sur le réseau. Pour les données historiques massives, diverses méthodes DA basées sur la chaîne principale et sur des tiers sont actuellement proposées pour s'adapter à l'augmentation de la pression de stockage en chaîne. Chaque méthode d’amélioration présente des avantages et des inconvénients et a des applicabilités différentes dans différentes situations.
Les blockchains axées sur le paiement ont des exigences extrêmement élevées en matière de sécurité des données historiques et ne recherchent pas un TPS particulièrement élevé. Si ce type de chaîne publique est encore en phase de préparation, une méthode de stockage de type DankSharding peut être adoptée, ce qui permet d'obtenir une augmentation considérable de la capacité de stockage tout en garantissant la sécurité. Cependant, s’il s’agit d’une chaîne publique comme Bitcoin qui a déjà pris forme et comporte un grand nombre de nœuds, il existe d’énormes risques d’améliorations irréfléchies au niveau de la couche de consensus. Par conséquent, la chaîne principale dédiée au DA avec une plus grande sécurité dans le stockage hors chaîne. peut être utilisé pour équilibrer les problèmes de sécurité et de stockage. Mais il convient de noter que les fonctions de la blockchain ne sont pas statiques mais en constante évolution. Par exemple, les premières fonctions d'Ethereum se limitaient principalement aux paiements et au simple traitement automatisé des actifs et des transactions à l'aide de contrats intelligents. Cependant, à mesure que le paysage de la blockchain continue de s'étendre, divers projets Socialfi et Defi ont progressivement été ajoutés à Ethereum. dans une direction plus globale. Récemment, avec l'explosion de l'écologie d'inscription sur Bitcoin, les frais de transaction du réseau Bitcoin ont augmenté de près de 20 fois depuis août. Cela reflète le fait que la vitesse de transaction du réseau Bitcoin à ce stade ne peut pas répondre à la demande de transaction et que les traders ne peuvent que le faire. L'augmentation des frais permet de traiter les transactions le plus rapidement possible. Désormais, la communauté Bitcoin doit faire un compromis, soit accepter des frais élevés et des vitesses de transaction lentes, soit réduire la sécurité du réseau pour augmenter les vitesses de transaction tout en allant à l'encontre de l'intention initiale du système de paiement. Si la communauté Bitcoin choisit cette dernière solution, face à la pression croissante des données, la solution de stockage correspondante devra également être ajustée.

Les frais de transaction sur le réseau principal Bitcoin fluctuent, source de l'image : OKLINK
Pour les chaînes publiques dotées de fonctions complètes, elles recherchent davantage le TPS, et la croissance des données historiques est encore plus importante. Il est difficile de s'adapter à la croissance rapide du TPS à long terme en adoptant une solution de type DankSharding. Par conséquent, une méthode plus appropriée consiste à migrer les données vers un DA tiers pour le stockage. Parmi eux, le DA spécifique à la chaîne principale présente la compatibilité la plus élevée et peut présenter plus d'avantages si seuls les problèmes de stockage d'une seule chaîne publique sont pris en compte. Mais aujourd’hui, alors que les chaînes publiques de couche 1 sont florissantes, le transfert d’actifs entre chaînes et l’interaction de données sont devenus une quête commune de la communauté blockchain. Si le développement à long terme de l'ensemble de l'écosystème blockchain est pris en compte, le stockage des données historiques de différentes chaînes publiques sur la même chaîne publique peut éliminer de nombreux problèmes de sécurité dans le processus d'échange et de vérification des données. Par conséquent, la différence entre DA modulaire et stockage. La chaîne publique DA pourrait être un meilleur choix. Sous le principe d'une grande polyvalence, le DA modulaire se concentre sur la fourniture de services de couche DA blockchain, en introduisant des données historiques de gestion des données d'index plus raffinées, qui peuvent raisonnablement classer différentes données de la chaîne publique et stocker les données de la chaîne publique. Cependant, la solution ci-dessus ne prend pas en compte le coût de l'ajustement de la couche de consensus sur la chaîne publique existante. Ce processus est extrêmement risqué, une fois que des problèmes surviennent, cela peut conduire à des vulnérabilités systémiques et entraîner la perte du consensus communautaire. Par conséquent, s’il s’agit d’une solution transitoire pendant le processus d’expansion de la blockchain, le stockage temporaire le plus simple de la chaîne principale peut être plus approprié. Enfin, la discussion ci-dessus est basée sur les performances lors de l'exploitation réelle. Cependant, si l'objectif d'une certaine chaîne publique est de développer sa propre écologie et d'attirer davantage de parties et de participants au projet, elle peut également préférer les projets soutenus et financés par ses propres moyens. fondation. . Par exemple, lorsque les performances globales sont équivalentes voire légèrement inférieures à celles des solutions de stockage en chaîne publique, la communauté Ethereum aura également tendance à se tourner vers les projets Layer 2 soutenus par la Fondation Ethereum comme EthStorage pour continuer à développer l'écosystème Ethereum.
Dans l’ensemble, les fonctions de la blockchain actuelle deviennent de plus en plus complexes, ce qui entraîne également des besoins en espace de stockage plus importants. Lorsqu'il y a suffisamment de nœuds de vérification de couche 1, les données historiques n'ont pas besoin d'être sauvegardées par tous les nœuds de l'ensemble du réseau. Ce n'est que lorsque le nombre de sauvegardes atteint une certaine valeur qu'une sécurité relative peut être garantie. Dans le même temps, la division du travail dans la chaîne publique est devenue de plus en plus détaillée. Layer1 est responsable du consensus et de l'exécution, Rollup est responsable du calcul et de la vérification, et une blockchain distincte est utilisée pour le stockage des données. Chaque partie peut se concentrer sur une certaine fonction sans être limitée par les performances des autres parties. Cependant, quelle quantité stocker ou quelle proportion de nœuds stocker les données historiques peut atteindre un équilibre entre sécurité et efficacité, et comment garantir une interopérabilité sûre entre les différentes blockchains. Cela nécessite que les développeurs de blockchain réfléchissent et continuent. Pour les investisseurs, vous pouvez prêter attention au principal projet DA spécifique à la chaîne sur Ethereum, car Ethereum compte déjà suffisamment de partisans à ce stade et n'a pas besoin de s'appuyer sur d'autres communautés pour étendre son influence. Ce qui est plus nécessaire, c'est d'améliorer et de développer votre propre communauté et d'attirer davantage de projets dans l'écosystème Ethereum. Cependant, pour les chaînes publiques en position de rattrapage, telles que Solana et Aptos, la chaîne unique elle-même n'a pas une écologie aussi complète, elle peut donc être plus encline à unir ses forces avec d'autres communautés pour construire une vaste écologie inter-chaînes. pour étendre son influence. Par conséquent, pour la couche 1 émergente, l’AD tiers général mérite plus d’attention.
Kernel Ventures est un fonds de capital-risque crypto piloté par la communauté de recherche et développement avec plus de 70 investissements de démarrage axés sur l'infrastructure, les middlewares, les dApps, en particulier ZK, Rollup, DEX, les blockchains modulaires et l'intégration de zones verticales pour des milliards d'utilisateurs de crypto dans l'avenir, comme l'abstraction des comptes, la disponibilité des données, l'évolutivité, etc. Au cours des sept dernières années, nous nous sommes engagés à soutenir la croissance des principales communautés de développement et des associations universitaires blockchain à travers le monde.
les références
Celestia : La mer étoilée de la blockchain modulaire : https://foresightnews.pro/article/detail/15497
Utilisation du DHT et travaux futurs :https://github.com/celestiaorg/celestia-node/issues/11
Celestia-core:https://github.com/celestiaorg/celestia-core
Laboratoires Solana:https://github.com/solana-labs/solana?source=post_page-----cf47a61a9274------------------------ ---------
Annonce du SOLAR Bridge:https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2
leveldb-handbook:https://leveldb-handbook.readthedocs.io/zh/latest/sstable.html
Arbres Kuszmaul J. Verkle[J]. Arbres Verkle, 2019, 1 : 1.:https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf
Site officiel d'Arweave : https://www.arweave.org/
Livre jaune Arweave : https://www.arweave.org/white-paper.pdf
