Il y a des années, lorsque j’ai commencé à travailler sur des projets qui servaient des milliards d’utilisateurs, j’ai vu comment les choix d’infrastructure faits au début peuvent remodeler le destin de toute une industrie.

Même les plateformes lancées avec les meilleures intentions d’être ouvertes, neutres et libres de tout contrôle peuvent glisser vers des formes de centralisation.

Ce n’est pas parce que quelqu’un cherche à être “méchant”; c’est simplement l’attraction gravitationnelle naturelle de la technologie et des marchés lorsque certaines décisions de conception sont verrouillées dès le départ.

Les choix de conception de l’infrastructure sont importants dès le premier jour.

Ces choix de conception fondamentaux doivent garantir que la technologie elle-même garantit l’équité et empêche d’abord la consolidation du pouvoir.

Nous avons déjà vu ce film

«Le pouvoir a tendance à se concentrer, même si personne ne le prévoit»

C’est une vérité subtile mais profonde que j’ai apprise de première main en travaillant sur des produits Internet à grande échelle.

Lorsque « l’industrie décentralisée » est née, cela ressemblait à une seconde chance. Nous avons considéré Bitcoin, Ethereum et d’autres comme des moyens d’échapper aux anciennes structures de pouvoir.

Le récit était simple : reprendre le contrôle, éliminer les intermédiaires et laisser le code garantir l’équité.

Mais nous devons être honnêtes, au fil du temps, les mêmes pressions qui ont centralisé Internet ont également commencé à agir sur ces systèmes ‘décentralisés’.

Mais comment Internet est-il devenu centralisé ?

Le réseau Internet n’a-t-il pas été créé comme un réseau P2P décentralisé capable de résister même à une guerre nucléaire ?

Pour comprendre pourquoi ces systèmes décentralisés cèdent aux pressions centralisatrices, il faut comprendre ce qui s’est passé avec Internet.

Vous devez regarder comment il a transitionné de ses débuts idéalistes en un écosystème hautement centralisé.

L’Internet primitif : quand le pair à pair était la norme

“Au début, personne ne détenait toutes les clés, et aucun joueur unique ne dictait toutes les règles”

La première version de ce que nous appelons maintenant Internet a essentiellement commencé sous le département de la Défense des États-Unis, avec des choses comme ARPANET à la fin des années 60.

Source : @DailySwig

L’idée depuis le premier jour était d’éviter ce point de défaillance unique, de s’assurer qu’aucun endroit ne pouvait tout emporter avec lui en tombant.

Ce réseau a été délibérément conçu pour être décentralisé.

La raison était stratégique : un système distribué pouvait résister à la défaillance de nœud unique, rendant les communications plus résistantes face aux perturbations telles que les pannes d’équipement ou même les conditions de guerre.

Un réseau de communication fiable et décentralisé qui pourrait même résister à une attaque nucléaire.

Chaque nœud était un « pair » capable d’envoyer et de recevoir des données sans dépendre d’une autorité centralisée unique. Toute machine, indépendamment de son matériel ou de son système d’exploitation, pouvait « parler » TCP/IP et échanger des données.

Dans les années 70 et 80, les universités et les laboratoires de recherche se sont connectés via NSFNET et ARPANET, et soudain, vous aviez cet environnement où personne ne détenait toutes les clés et aucun acteur unique ne dirigeait toutes les opérations.

Cela s’est montré dans les fondamentaux :

TCP/IP, FTP, Telnet, Usenet newsgroups, and DNS n’étaient pas destinés à enfermer qui que ce soit à un seul endroit. Il y avait peu d’incitation à imposer des contrôles stricts ou des hiérarchies.

Usenet, par exemple, diffusait des messages de manière P2P totalement décentralisée. L’autorité de nommage déléguée DNS dans une hiérarchie distribuée, mais chaque composant agissait toujours à la fois en tant que client et en tant que serveur dans une certaine mesure.

Tout cela a renforcé ce principe original :

un réseau qui ne se limitait pas à un grand acteur qui fixe les règles, mais plutôt un système où n’importe qui pouvait se brancher et participer.

Mais au début des années 90, le World Wide Web et les navigateurs ont changé la donne.

La page recréée du premier site Web (Image : CERN)

L’essor du modèle client/serveur

Tim Berners-Lee: Le Visionnaire derrière le World Wide Web

« Lorsque la base d’utilisateurs d’Internet a augmenté, les hypothèses de conception initiales concernant la participation ouverte et la confiance mutuelle ont commencé à montrer des failles »

Le World Wide Web, introduit en 1989-1991, a été construit sur des normes ouvertes (HTTP, HTML) délibérément placées dans le domaine public. Dans sa forme la plus primitive, le Web rendait trivial pour les individus, les petites organisations ou toute personne possédant un modem et un hébergement de créer un site web.

L’infrastructure était encore largement «plate» et décentralisée, avec d’innombrables pages web indépendantes liées entre elles dans une fédération lâche.

Mais au début des années 90, quelque chose est devenu vraiment populaire.

C’est à ce moment-là que ‘Web Browsing’ est devenu l’application incontournable.

Les sites web sont devenus des vitrines, des médias d’information et des centres de divertissement. La personne moyenne ne gérait pas son propre serveur ni n’hébergeait ses propres pages.

La page d’accueil de Netscape en 1994, avec sa mascotte Mozilla, telle qu’elle apparaît dans NCSA Mosaic 3.0

[Capture d’écran: Alex Pasternack /OldWeb.today]

Ils ont utilisé des navigateurs web (clients), d’abord avec ces modems lents, puis le haut débit, pour récupérer du contenu auprès de grands serveurs web bien connus. Soudain, l’hébergement de grandes quantités de données et la mise en place de sites de commerce électronique ou de moteurs de recherche sont devenus une grande chose.

Les premiers moteurs de recherche tels que AltaVista, Yahoo! et plus tard Google ont émergé pour aider les gens à naviguer dans le monde en ligne en expansion rapide.

L’effet de réseau est devenu prononcé: plus les gens utilisaient un moteur de recherche, plus il pouvait affiner ses modèles d’indexation et de publicité, renforçant ainsi sa domination.

L’algorithme de PageRank de Google en a fait une passerelle unique vers l’immensité du web.

Cela a attiré l’argent et l’attention vers les grands centres de données, et ceux qui pouvaient augmenter leur échelle et gérer ces charges massives sont sortis gagnants.

Alors que les fournisseurs de services Internet ont émergé pour servir des millions de nouveaux utilisateurs, l’infrastructure s’est naturellement optimisée pour la fourniture en aval.

Des vitesses de téléchargement plus rapides que les vitesses de téléchargement (connexions à large bande asymétriques telles que l’ADSL ou le câble) avaient un sens économique car la plupart des utilisateurs consommaient plus qu’ils ne produisaient. Le réseau a “appris” que la plupart des points d’extrémité étaient uniquement des clients.

Et avec la montée en puissance de la base d’utilisateurs d’Internet, les hypothèses initiales de conception autour de la participation ouverte et de la confiance mutuelle ont commencé à montrer des failles.

Sécurité, pare-feux et portes fermées

«La liberté et l’ouverture sans garanties peuvent favoriser les abus qui nous obligent à construire des murs plus hauts.»

Les protocoles d’origine n’avaient pas été conçus pour gérer une foule massive et diversifiée, dont beaucoup avaient des intérêts commerciaux ou des motivations qui mettaient à l’épreuve l’ouverture du système.

Sans véritable protection, le spam est devenu un gros problème, exploitant cet environnement ouvert.

La conception originale et ouverte permettait à chaque hôte d’être accessible depuis n’importe quel autre hôte, ce qui était bien lorsque l’Internet était une petite communauté de confiance.

Mais à mesure qu’il grandissait, les attaques, les tentatives de piratage et les activités malveillantes ont explosé.

Source :emailtray.com

De même, sans moyen de garantir une utilisation équitable de la bande passante, certaines applications ont appris à repousser les limites et à tirer avantage aux dépens des autres.

Ces lacunes de conception ont poussé Internet vers davantage de réglementation et de contrôle.

Pour protéger les réseaux internes, les organisations ont déployé des pare-feu pour bloquer les connexions entrantes. La traduction d’adresse réseau (NAT) a en outre isolé les machines internes derrière une seule adresse IP partagée.

Cela a restreint la nature pair à pair des communications.

Les hôtes derrière les NAT et les pare-feu ont été effectivement contraints à un rôle de client seulement, plus directement accessibles depuis le monde extérieur.

Au fil du temps, ces décisions d’infrastructure se sont renforcées mutuellement.

L’émergence des gardiens de portail

« Une poignée d’entreprises ont réalisé que le contrôle des centres de données et la possession d’infrastructures de serveurs massives leur conféraient d’énormes avantages concurrentiels. »

La complexité et le coût de la gestion de son propre serveur depuis chez soi, associés à des obstacles techniques tels que NAT et les pare-feu, ont entraîné une participation moins importante en tant que véritables pairs.

En d’autres termes, l’environnement a pratiquement poussé le Net vers une poignée de géants centralisés.

Au début des années 2000, quelques entreprises ont réalisé que le contrôle des centres de données et la possession d’infrastructures de serveurs massives leur donnaient d’énormes avantages concurrentiels.

Ils pourraient fournir des services plus rapides, plus fiables et plus pratiques qu’un pair aléatoire sur le réseau.

Cette tendance était dopée dans les années 2000.

Source :datareportal.com

Des moteurs de recherche comme Google, des plateformes de grande envergure comme Amazon, des géants des médias sociaux comme Facebook et des réseaux de distribution de contenu ont construit d’énormes infrastructures qui ont livré du contenu et des applications à une vitesse et une échelle sans précédent.

Ces grandes entreprises ont également exploité le “cercle vertueux” des données et des algorithmes.

Plus ils attiraient d’utilisateurs, plus ils collectaient de données, ce qui leur permettait de perfectionner leurs produits, de personnaliser les expériences et de cibler les publicités de manière plus précise. Cela rendait leurs services encore plus attractifs, attirant ainsi plus d’utilisateurs et plus de revenus.

Ensuite, le modèle économique d’Internet s’est fortement orienté vers la publicité ciblée.

Au fil du temps, cette boucle de rétroaction a concentré davantage le pouvoir, les plus petits concurrents ayant du mal à rivaliser avec les investissements en infrastructure et les avantages de données des grands acteurs.

L’infrastructure qui pouvait autrefois être gérée à partir d’un serveur personnel ou d’un centre de données local est de plus en plus déplacée vers le cloud.

Des géants comme Amazon (AWS), Microsoft (Azure) et Google Cloud hébergent désormais l’infrastructure de base d’une grande partie d’Internet. Ce changement s’est produit car la gestion d’une infrastructure de grande envergure, sécurisée et fiable est devenue si complexe et nécessitant des capitaux si importants que seules quelques entreprises peuvent le faire efficacement.

Les startups et même les entreprises établies ont trouvé moins cher et plus simple de compter sur ces grands fournisseurs de cloud.

Des services tels que les CDN (comme Cloudflare ou Akamai) et les résolveurs DNS se sont également tournés vers quelques grands acteurs.

La complexité et les avantages économiques de ces solutions gérées signifiaient moins de raisons pour les organisations de «construire leur propre» infrastructure.

Progressivement, les bases décentralisées telles que les petits FAI, l’hébergement indépendant et l’acheminement localisé ont cédé la place à un modèle dans lequel la majeure partie du trafic et des services dépend d’un nombre minuscule d’intermédiaires majeurs.

Les conséquences : le pouvoir concentré entre quelques mains

Les grands joueurs n’ont pas commencé à être mauvais ; ils ont simplement optimisé la commodité, la performance et le profit.

C’était le résultat naturel des premiers choix de conception architecturale dans le réseau sous-jacent.

Avec l’échelle et la centralisation sont venus plus de pouvoir et de contrôle.

Les grandes plateformes fixent leurs propres conditions de service, déterminant ainsi le contenu que les utilisateurs peuvent voir ou publier, ainsi que la manière dont leurs données seront collectées ou vendues. Les utilisateurs avaient moins d’alternatives s’ils n’aimaient pas ces politiques.

Au fil du temps, les algorithmes de recommandation et les politiques de contenu de ces plateformes sont devenus les arbitres de facto du discours public.

Paradoxalement, ce qui a commencé comme un réseau ouvert et décentralisé qui permettait l’échange libre d’idées et de contenu a maintenant souvent acheminé l’information à travers quelques portails d’entreprise.

Maintenant, ces entreprises, à certains égards, exercent un pouvoir comparable à celui des gouvernements : elles peuvent façonner le discours public, influencer le commerce et contrôler des écosystèmes entiers de développeurs tiers.

Un réseau initialement conçu pour une interconnexion libre et de pairs tourne maintenant autour de puissants hubs d’entreprise qui peuvent façonner et contrôler une grande partie de l’expérience en ligne.

Il ne s’agissait pas d’un grand complot pour concentrer le pouvoir. Cette situation ne découlait pas non plus d’un seul “mauvais virage”.

Les grands acteurs n’ont pas commencé par être méchants ; ils se sont simplement optimisés pour la commodité, les performances et le profit. C’était le résultat naturel des premiers choix de conception architecturale dans le réseau sous-jacent.

Ces choix n’ont pas anticipé comment un public beaucoup plus large et plus commercialement orienté utiliserait le système et le pousserait au-delà de ses paramètres de conception initiaux.

Au fil du temps, ces choix se sont accumulés en un système où quelques entreprises dominent.

La même chose se produit sous nos yeux dans l’industrie décentralisée.

La route de la centralisation est pavée de solutions « temporaires »

“La tendance à la centralisation n’est pas toujours le résultat d’une intention malveillante ; souvent, c’est une tentative de résoudre les problèmes d’un système qui n’a jamais été conçu pour rester décentralisé à grande échelle.”

Tout comme les débuts d’Internet se sont éloignés de leurs idéaux pair à pair pour tomber entre les mains de quelques grands acteurs, les technologies blockchain et « décentralisées » d’aujourd’hui risquent de suivre le même chemin.

C’est plus facile à voir avec les tentatives d’Ethereum pour évoluer.

Les frais élevés et le débit lent ont incité les développeurs à adopter des solutions de couche 2 (L2) : des rollups qui regroupent les transactions hors chaîne, puis les règlent sur Ethereum. En théorie, ces L2 devraient conserver la nature sans confiance d’Ethereum.

En pratique, beaucoup dépendent d’un seul “séquenceur” (un serveur central qui ordonne les transactions) géré par une seule entreprise.

En ce moment, une solution L2 particulière a le plus d’activité et de valeur totale verrouillée, mais elle est aussi la plus centralisée,

L’argument est que la décentralisation viendra un jour, mais nous avons déjà entendu cela auparavant.

Avec le temps, ces solutions “temporaires” ont tendance à devenir permanentes. Le même schéma pourrait émerger avec les approches en couches futures ; certaines pourraient même ne pas se soucier de promettre un quelconque chemin vers la décentralisation.

Les “logins sociaux” peuvent sembler utiles: ils facilitent l’utilisation d’un service sans jongler avec des clés privées ou des interfaces compliquées. Mais si ces logins dépendent d’un composant centralisé, vous faites une fois de plus confiance à une seule entreprise pour faire ce qu’il faut.

C’est pourquoi, lorsque nous avons construit zkLogin, nous l’avons construit et intégré de manière décentralisée. C’était difficile, mais nous ne pouvons pas faire de compromis et introduire la centralisation pour plus de commodité.

Un schéma similaire est apparu dans l’écosystème NFT.

Un seul marché dominant est devenu le lieu principal pour les ventes secondaires, capturant la majeure partie du volume de transactions et devenant effectivement la plate-forme de facto.

Il n’y a pas longtemps, ce marché a décidé de ne plus appliquer de paiements de redevances sur les ventes secondaires.

Oui, cela a augmenté le volume des transactions, mais cela nuit aux créateurs qui comptaient sur ces redevances comme source de revenus clé.

Ceci est un exemple clair des conséquences lorsque les plateformes centralisées peuvent modifier les règles à tout moment.

Leur domination s’étendait également au-delà du trading, de nombreux projets dépendant également de leurs APIs et de leur infrastructure.

Lorsque cette plateforme centralisée a connu des pannes, l’ensemble de l’écosystème a ressenti l’impact, révélant la dépendance profonde qui s’était formée.

Mais pourquoi cela continue-t-il de se produire?

Parce que les utilisateurs veulent des expériences rapides, bon marché et faciles. Les développeurs, sous pression, se tournent souvent vers des solutions familières et fiables. Ces choix sont plus simples et plus rapides, mais peuvent introduire des points de contrôle qui compromettent la décentralisation.

Aucune de ces étapes ne commence par de grands plans de monopolisation. Ce ne sont que des réponses pratiques aux défis techniques et commerciaux difficiles.

Mais avec le temps, ces “pansements” deviennent intégrés dans l’ADN du système, créant une structure où quelques acteurs détiennent les clés.

C’est pourquoi ces systèmes doivent être conçus dès le départ pour les constructeurs, et non seulement pour les consommateurs.

Construction pour les constructeurs, pas seulement pour les consommateurs

« Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient dit des chevaux plus rapides. » - Henry Ford

La plupart des consommateurs veulent simplement une meilleure version de ce qu’ils ont déjà.

Mais lorsque nous ne poursuivons que ces améliorations à court terme, nous risquons de nous retrouver avec des systèmes qui semblent décentralisés en apparence, mais qui sont toujours contrôlés par quelques acteurs clés.

Si nous voulons vraiment éviter de répéter les erreurs qui ont conduit aux gardiens numériques d’aujourd’hui, nous devons nous concentrer sur les créateurs de l’avenir, les constructeurs, et pas seulement les consommateurs.

C’est pourquoi je dis toujours à mon équipe que les consommateurs demanderont toujours un cheval plus rapide ; ce sont les constructeurs qui imaginent la voiture.

0:00 / 0:38

Avec les bons éléments constitutifs, les développeurs peuvent lancer des plateformes qui ne sont pas contraintes à la centralisation pour des raisons de commodité. Ils peuvent créer des systèmes où aucune entité unique ne peut dominer ou verrouiller les utilisateurs, garantissant que les avantages se répartissent de manière plus équitable entre tous les participants.

C’est pourquoi ces systèmes doivent être conçus dès le départ pour renforcer la décentralisation, même lorsqu’ils doivent s’étendre à l’échelle d’Internet.

Tech Debt vs Design Debt

« La dette technique peut être résolue par le refactoring ; la dette de conception nécessite souvent une réinitialisation totale. »

Depuis mes premières années de travail sur des systèmes qui se sont développés jusqu’à des milliards d’utilisateurs, une leçon m’a marqué : une fois qu’un système devient critique, vous ne pouvez pas simplement tout détruire et reconstruire sans causer une perturbation massive.

Le moment où des millions d’utilisateurs comptent sur les comportements et les hypothèses ancrés de votre système, même proposer des changements architecturaux radicaux devient impossible.

Cela pourrait briser des applications, des modèles commerciaux et la confiance de communautés entières construites par-dessus.

C’est le concept de ‘dette de conception’ dans sa forme la plus grave.

Il ne s’agit pas seulement de la propreté du code ; il s’agit de choix architecturaux fondamentaux qui dictent comment la confiance, le pouvoir et la valeur circulent à travers le réseau.

Aux premiers jours de cette industrie, le soi-disant « trilemme blockchain ou de mise à l’échelle », l’idée selon laquelle on ne peut pas avoir à la fois la décentralisation, la sécurité et la mise à l’échelle, était considérée comme une loi de la nature.

Les gens ont construit sur cette supposition, croyant qu’elle était aussi inchangeable que la gravité. Mais ce n’était pas le cas.

Cela découle d’architectures initiales défectueuses : des états partagés mondiaux massifs, des modèles de données limitant la parallélisme et la mise à l’échelle modulaire impossible.

La seule façon de progresser est de regrouper toutes les transactions ensemble, obligeant chaque participant à se battre pour les mêmes ressources limitées, peu importe ce qu’ils font. Le résultat ? Des enchères inefficaces pour l’espace de bloc qui font augmenter les coûts pendant les pics de demande et qui ne parviennent pas à isoler la congestion là où elle se produit réellement.

Dans ces conditions, l’ajout de couches (comme des L2 qui dépendent de séquenceurs centralisés ou des actifs compressés qui dépendent du stockage centralisé) ne fait qu’enjoliver les fissures.

Chaque correctif visant à résoudre des problèmes à court terme ajoute souvent plus de complexité et plus de points de contrôle centralisé, s’éloignant de plus en plus de la vision originale.

C’est ainsi que la dette de conception s’accumule sous forme de “gravité technique” qui attire tout vers la centralisation.

Même les systèmes qui n’ont jamais eu l’intention d’être des gatekeepers finissent par renforcer les structures hiérarchiques car leur architecture fondamentale l’exige. Une fois que cela se produit, le chemin de retour vers un état vraiment décentralisé et sans confiance est bloqué par des intérêts enracinés et une inertie infrastructurelle.

La leçon est claire : vous devez avoir la bonne architecture dès le départ.

Cela signifie choisir des modèles de données qui ne regroupent pas tout dans un seul état global, utiliser des solutions de stockage vérifiables sans faire confiance à un intermédiaire, et choisir une couche de réseau qui ne dépend pas d’une poignée d’intermédiaires puissants.

Il s’agit de réinventer l’ensemble de la pile technologique dès le premier jour.

Obtenir les fondamentaux dès le premier jour

“La seule véritable solution pour la dette de conception est de ne pas l’accumuler en premier lieu.”

Quand nous parlons de construire une infrastructure qui ne peut pas être mauvaise, nous parlons vraiment de faire les bons choix architecturaux dès le premier jour.

C’est pourquoi, lorsque nous avons conçu Sui, nous avons voulu intégrer ces principes fondamentaux dès le premier jour.

Cela permet aux développeurs de créer des applications évolutives, sécurisées et conviviales sans se tordre les méninges ou compter sur des béquilles centralisées.

Considérez le modèle de programmation lui-même :

L’approche centrée sur l’objet de Sui est un départ délibéré des paradigmes basés sur les comptes qui ont dominé de nombreuses blockchains.

Modèle de programmation centré sur l’objet

Au cœur de la philosophie de conception de Sui se trouve le modèle de programmation centré sur l’objet.

Dans un monde où les développeurs Web2 pensent naturellement en termes d’objets, tels que des fichiers, des enregistrements et des actifs, il n’a pas de sens de réduire tout à un modèle de compte monolithique.

Le faire force les développeurs à adopter des schémas de pensée artificiels. Cela introduit de la complexité qui est propice aux erreurs.

Le modèle de programmation orienté objet s’aligne naturellement avec la façon dont les ingénieurs Web2 raisonnent déjà sur les logiciels.

Les objets servent de citoyens de première classe, ce qui rend simple la représentation des actifs, la définition des règles et l’évitement des pièges courants, tels que les bugs de réentrance, sans code fastidieux.

Ce modèle familier réduit considérablement la surcharge conceptuelle et les pièges courants tels que la réentrance. Au lieu d’écrire des vérifications de routine ou des barrières de protection complexes pour prévenir les exploitations, les développeurs font confiance à la machine virtuelle Move pour garantir la sécurité au niveau de l’exécution.

En conséquence, le code est plus lisible, sécurisé et plus facile à comprendre.

C’est un pont direct de la mentalité orientée objet de Web2 à l’environnement sans confiance de Web3, rendu possible en partant des bonnes hypothèses dès le départ.

Mise à l’échelle par conception, pas par du ruban adhésif

Mais un excellent modèle de programmation ne signifie rien s’il s’effondre sous la charge.

Depuis le début, Sui a été construit pour gérer des charges réelles. Il a été conçu pour se développer horizontalement tout en maintenant une composition atomique synchrone.

Le modèle objet du système donne à Sui une compréhension fine-grained des parties de l’état que chaque transaction touche, permettant une exécution parallèle à grande échelle. C’est un contraste frappant avec les systèmes basés sur l’EVM, qui doivent verrouiller l’ensemble de l’état global. Cela ralentit tout et encourage des solutions centralisées pour décharger le volume des transactions.

Avec Sui, chaque objet est effectivement sa propre shard. Besoin de plus de capacité? Ajoutez plus de puissance de calcul pour gérer la charge.

Le prototype Pilotfish : https://blog.sui.io/pilotfish-execution-scalability-blockchain/

Les développeurs n’ont pas à se soucier de la logique de sharding, de la création de ponts entre plusieurs domaines ou de la mise en place d’une infrastructure pour atteindre l’échelle.

Ainsi, le système peut gérer plus de trafic à mesure que le réseau se développe, mais comment assurez-vous une allocation équitable des ressources ?

Si un actif populaire ou une dApp monopolise les mises à jour d’état, cela peut faire augmenter les coûts et dégrader l’expérience pour tous les autres.

Au lieu de compter sur une seule enchère mondiale pour l’espace de bloc, où une application populaire peut augmenter les prix pour tout le monde, les marchés locaux de frais permettent au système de tarifer les ressources avec un niveau de granularité plus fin.

Chaque “objet” ou fragment peut avoir son propre marché des frais, garantissant que la congestion dans une zone ne déborde pas et ne pénalise pas les parties non liées du réseau.

Tout est intégré dans la conception fondamentale de la plateforme, garantissant que même lorsque la demande augmente, le système ne revient pas aux vieux schémas fatigués des gardiens et des jardins clos.

Concevoir pour la décentralisation signifie également intégrer la vérifiabilité directement dans les couches de stockage et de communication.

Si le stockage des données repose sur une seule partie de confiance, vous revenez à la case départ. Vous avez besoin de solutions de stockage qui permettent à n’importe qui de vérifier l’intégrité des données sans dépendre d’un intermédiaire.

Stockage vérifiable sans hôtes centralisés

Une application vraiment décentralisée ne peut pas compter sur un seul fournisseur de cloud ou une base de données centralisée.

Walrus propose une couche de stockage décentralisée et vérifiable comparable en puissance et en échelle aux offres centralisées telles que AWS ou Google Cloud.

Avec Walrus, la vérifiabilité des données n’est pas une réflexion après-coup, mais une propriété intrinsèque.

En intégrant une couche de stockage intrinsèquement vérifiable et infalsifiable, Walrus garantit que les développeurs peuvent exécuter des sites web, héberger des données et construire des applications entièrement décentralisées sans retomber dans les schémas centralisés que nous cherchions à éviter.

En d’autres termes, Walrus étend la philosophie de > de l’exécution au stockage, garantissant l’intégrité de votre application à chaque couche.

Maintenant, concevoir pour la décentralisation signifie également que cela ne devrait pas s’arrêter à la couche de consensus ou d’exécution; cela devrait s’étendre au réseau lui-même.

Les couches de réseau ne devraient pas reposer sur quelques FAI puissants ou services de routage. Cela aussi est une centralisation.

Une couche de mise en réseau construite pour la décentralisation

Le networking est un autre élément du puzzle souvent négligé dans le Web3.

Le routage traditionnel d’Internet est contrôlé par quelques FAI, ce qui introduit des points d’étranglement potentiels et des vulnérabilités.

SCION est un protocole de réseau de nouvelle génération qui remet en question ce statu quo, rendant le routage plus sécurisé, fiable et résistant au contrôle centralisé.

C’est une architecture de routage sécurisée, multipath et inter-domaines qui peut fonctionner côte à côte avec l’internet actuel. C’est une réinvention complète de la façon dont les données circulent à travers les réseaux, construite avec la sécurité, le contrôle et les performances intégrés à son cœur.

En intégrant SCION à Sui, nous nous assurons que le réseau sous-jacent n’est pas un point de défaillance ou de contrôle unique.

Aucune entité unique ne dicte le flux de données, et les utilisateurs peuvent faire confiance au fait que les routes sous-jacentes ne seront pas manipulées ou monopolisées.

En intégrant la vérifiabilité et la permissionnalité à chaque couche, y compris le modèle de données, le stockage et le réseau, vous réduisez la surface d’attaque où des points de contrôle centralisés peuvent s’établir.

Vous n’ajoutez pas la décentralisation comme une réflexion après coup ; vous l’intégrez dans les fondations.

Cette simplicité réduit la complexité et maintient la porte fermée aux contournements “pratiques” mais centralisés. Plus important encore, bien maîtriser les fondamentaux signifie ne jamais parier sur une mentalité du type “nous le réparerons plus tard”.

Tous les chemins mènent à la conception sonore

“La décentralisation ne consiste pas en un nombre de validateurs. La véritable décentralisation concerne l’architecture qui empêche le pouvoir de se concentrer en un seul endroit.”

Le point de tout ce que nous avons exploré est simple : si vous voulez un système qui ne peut pas être malveillant, vous devez commencer par la bonne architecture.

Si vous partez des mauvaises hypothèses, aucun code supplémentaire ou astuce intelligente ne vous sauvera.

Une architecture qui récompense les portiers. Un modèle de données qui force chaque acteur à concourir pour la même ressource rare. Une couche de mise en réseau conçue autour de hubs centralisés. À la fin, vous glisserez dans les mêmes vieux schémas de contrôle et de hiérarchie.

C’est pourquoi les fondations architecturales sont si importantes.

La décentralisation ne consiste pas seulement à compter le nombre de nœuds que vous avez. Une véritable décentralisation signifie concevoir au niveau racine de telle sorte que la confiance, l’équité et la vérifiabilité soient impossibles à contourner.

Il s’agit de construire des systèmes où ni une poignée de baleines ni une entreprise bien dotée ne peuvent incliner silencieusement le terrain de jeu. Il s’agit de garantir que chaque participant a une chance équitable, et qu’aucun point d’étranglement, aucune décision de conception subtile, ne peut se transformer en centralisation incontrôlée.

Sui est un exemple de ce qui se passe lorsque vous concevez en gardant à l’esprit ces principes dès le premier jour, plutôt que d’essayer de les adapter après coup.

Lorsque l’ensemble de la pile, du modèle de programmation à la couche de consensus, en passant par l’intégration de l’utilisateur, la disponibilité des données et la couche de mise en réseau, renforce l’ouverture et la neutralité, vous créez un environnement dans lequel les constructeurs et les utilisateurs prospèrent sur un pied d’égalité.

En commençant par les premiers principes et en imposant la décentralisation à chaque couche, vous pouvez créer une infrastructure qui reste fidèle à son éthos, peu importe sa taille.

Construisez-le correctement dès le départ, et vous n’aurez pas besoin de promettre des corrections futures ou des demi-mesures.

Vous disposerez d’un réseau intrinsèquement juste, résilient et prêt à servir de base à la prochaine génération d’expériences numériques.

Avertissement :

1. Cet article est reproduit à partir de [Erreur: Texte source manquant]. Tous les droits d’auteur appartiennent à l’auteur original [@EvanWeb3]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s’en chargeront rapidement.
2. Responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas des conseils en investissement.
3. L’équipe de traduction de Gate Learn effectue des traductions de l’article dans d’autres langues. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.