数年前、数十億人のユーザーにサービスを提供するプロジェクトに取り組み始めたとき、初期のインフラ選択がある業界全体の運命を変えることができることを目の当たりにしました。

最初はオープンで中立で制御のないプラットフォームとして立ち上げられたものでも、中央集権の形態に滑り込むことがあります。

「悪」を目指しているわけではないのです。ただ、特定の設計上の決定が最初からロックされている場合、技術と市場の自然な引力が働くだけです。

インフラストラクチャの設計選択は最初の日から重要です。

これらの核心的な設計選択は、技術自体が公平性を強制し、まず最初に権力の集中を防止することを保証しなければなりません。

以前にこの映画を見たことがあります

「力は計画されていなくても集中する傾向があります」

大規模なインターネット製品の開発に携わりながら、私は直接に学んだ、微妙でありながら深い真実です。

「分散化業界」が誕生したとき、それは第二のチャンスのように思われました。私たちはBitcoinやEthereumなどを、古い権力構造からの脱出手段として見ました。

物語はわかりやすかった: コントロールを取り戻し、中間業者を排除し、コードに公平さを保証させる。

しかし、正直でなければなりませんが、時間の経過とともに、インターネットを中央集権化した同じ圧力が、これらの「分散型」システムにも作用し始めました。

しかし、インターネットはどのように中央集権化されたのでしょうか？

インターネットは分散型のP2Pネットワークとして始まったはずで、核戦争にも耐え得るものだったのではないでしょうか？

これらの分散システムが中央集権化の圧力に屈する理由を理解するためには、インターネットで何が起こったかを理解する必要があります。

その理想的な始まりから高度に中央集権化されたエコシステムに移行した方法を見る必要があります。

The Early Internet: When Peer-to-Peer Was the Norm

「最初に、誰もすべての鍵を握っておらず、1人のプレイヤーがすべての決定を下していたわけではありませんでした」という意味でした。

現在インターネットと呼ばれるものの初期バージョンは、アメリカ国防総省の管轄下で始まりました。ARPANETなどが1960年代後半に登場しました。

ソース: @DailySwig

最初からの全体の考えは、単一障害点を避け、1か所の障害が他のすべてを引きずり込まないようにすることでした。

このネットワークは意図的に分散化されるように設計されました。

その理論は戦略的でした: 分散システムは任意の単一ノードの障害に耐えることができ、装置の故障や戦時条件などの障害に対して通信がより強固になります。

信頼性の高い分散型通信ネットワークは、核攻撃にすら耐えることができます。

各ノードは、単一の中央集権的な権限に頼らずにデータの送受信が可能な「ピア」でした。ハードウェアやオペレーティングシステムに関係なく、どのマシンでもTCP/IPを「話」し、データを交換することができました。

70年代と80年代には、大学や研究所がNSFNETやARPANETを通じて連携し、突然、誰もがすべてのキーを持っておらず、1人のプレイヤーがすべての指示を出していない環境ができました。

それは基本的なものに現れました:

TCP/IP、FTP、Telnet、Usenetニュースグループ、およびDNSは、誰かを一つの場所に閉じ込めることについてではありませんでした。厳格な制御や階層を課す動機はほとんどありませんでした。

例えば、Usenetは完全に分散型のP2P方式でメッセージを拡散させました。DNSは分散階層で命名権限を委任していますが、すべてのコンポーネントがある程度クライアントとサーバの役割を果たしています。

それはすべて元の原則を強化しました:

ルールを設定する1つの大きなプレイヤーについてだけではなく、誰でも接続し参加できるシステムのネットワーク

しかし、90年代初頭には、ワールドワイドウェブとブラウザがゲーム全体を変えました。

最初のウェブサイトの再現ページ（画像：CERN）

クライアント/サーバーモデルの台頭

Tim Berners-Lee: 世界広範なウェブのビジョナリー

「インターネットの利用者数が急増するにつれて、元の設計の前提としてのオープンな参加と相互の信頼が亀裂を見せ始めました」

1989年から1991年にかけて導入されたWorld Wide Webは、公共ドメインに故意に配置されたオープンスタンダード(HTTP、HTML)の上に構築されました。初期の形態では、Webはモデムとホスティングを持つ個人、小規模な組織、または誰でもウェブサイトを立ち上げることができるようになりました。

インフラストラクチャはまだ主に「フラット」で分散しており、無数の独立したウェブページが緩やかに連携している。

しかし、90年代初頭には何かが本当に人気になりました。

これが’Web Browsing’が”キラーアプリ”になった時です。

ウェブサイトは店舗、ニュースメディア、エンターテイメントハブとなりました。一般の人々は自分自身のサーバーを運営したり、自分自身のページをホストしたりしていませんでした。

1994年のNetscapeのホームページで、そのマスコットのMozillaがNCSA Mosaic 3.0で見られます

[スクリーンショット：Alex Pasternack /OldWeb.today]

彼らは最初にそれらの遅いモデム、次に広帯域のあるウェブブラウザ（クライアント）を使って、大規模でよく知られたウェブサーバからコンテンツを取得しました。突然、膨大な量のデータをホスティングし、eコマースサイトや検索エンジンを設立することが大きなことになりました。

初期の検索エンジンであるAltaVista、Yahoo!、そして後にGoogleが登場し、急速に拡大するオンライン世界をナビゲートするのを助けました。

ネットワーク効果は顕著になりました：多くの人々が検索エンジンを使用するほど、それはより洗練された索引付けと広告モデルを作り上げ、その支配力を強化していきました。

GoogleのPageRankアルゴリズムは、それをウェブの広大さへの唯一のゲートウェイに変えました。

それにより、資金と注意がビッグデータセンターに流れ、大量の負荷を処理しスケーリングできる者が最も成功しました。

数百万人の新しいユーザーに対応するために登場したインターネットサービスプロバイダーは、インフラストラクチャが自然にダウンストリームの配信に最適化されました。

アップロード速度よりもダウンロード速度が速い（ADSLやケーブルなどの非対称ブロードバンド接続）は、ほとんどのユーザーが生産するよりも消費することが多いため、経済的に妥当でした。ネットワークは、ほとんどのエンドポイントがクライアントのみであることを「学習しました」。

そして、インターネットの利用者数が急増するにつれて、オリジナルの設計におけるオープンな参加と相互信頼に関する仮定が欠点を示し始めました。

セキュリティ、ファイアウォール、および閉鎖されたゲート

「保障のない自由と公開は、私たちにより高い壁を築かせる虞がある。」

元のプロトコルは、多くのビジネス利害関係やシステムのオープン性を試す動機を持つ多様な群衆を扱うために構築されていなかった。

実際の保護措置がないため、スパムは大きな問題となり、オープンな環境を悪用しています。

インターネットが小規模な信頼できるコミュニティであった時代には、オリジナルでオープンな設計により、すべてのホストが他のすべてのホストから到達可能であったため、これは問題ありませんでした。

しかし、拡大するにつれて、攻撃、ハッキング試行、および悪意のある活動が膨らんでいった。

ソース:emailtray.com

同様に、帯域幅の使用を公平に保つ方法がないと、一部のアプリケーションは限界まで押し上げ、他者の費用で利益を得る方法を学んでしまいました。

これらの設計上のギャップは、インターネットをさらなる規制とコントロールに向かわせました。

内部ネットワークを保護するために、組織はファイアウォールを展開して受信接続をブロックしました。ネットワークアドレス変換（NAT）は、内部のマシンを共有IPアドレスの背後にさらに隔離しました。

これによりピア・ツー・ピアの性質が制限されました。

NATおよびファイアウォールの背後にあるホストは、実質的にクライアント専用の役割に追いやられ、もはや外部から直接アドレス指定できなくなりました。

時間とともに、これらのインフラストラクチャの決定は互いに補強されました。

ゲートキーパーの出現

「一握りの企業が、データセンターを制御し、巨大なサーバーインフラを所有することが、彼らに非常に大きな競争上の優位性をもたらすことに気づいた。」

自宅から自分のサーバーを運用する複雑さとコストは、NATやファイアウォールなどの技術的な障壁と相まって、真のピアとして参加する個人が少ないことを意味しました。

言い換えると、環境はほぼネットを中央集権的な巨大企業に向かわせました。

2000年代初頭には、わずかな数の企業が、データセンターの制御と大規模なサーバーインフラを所有することで、非常に大きな競争上の優位性を持つことに気付きました。

彼らはネットワーク上のランダムなピアよりも、より速く、信頼性の高い、より便利なサービスを提供することができる。

この傾向は2000年代後半にステロイドを使用していました。

ソース:datareportal.com

Googleのような検索エンジン、Amazonのような大規模プラットフォーム、Facebookのようなソーシャルメディア巨大企業、およびコンテンツ配信ネットワークは、前例のない速度とスケールでコンテンツとアプリケーションを提供するために、巨大なインフラストラクチャを構築しました。

これらの大手企業は、データとアルゴリズムの「善循環」にも参入しました。

彼らが引き寄せたユーザーが多ければ多いほど、彼らはより多くのデータを収集し、それによって彼らの製品を洗練させ、体験を個人化し、広告をより正確にターゲットにできた。これによって彼らのサービスはさらに魅力的になり、より多くのユーザーと収益を引き寄せた。

その後、インターネットの収益モデルは重点的にターゲット広告に変化しました。

このフィードバックループは、時間とともに、より小さい競合他社が大手プレーヤーのインフラ投資とデータの利点に対抗するのに苦労したため、さらに権力を集中させました。

個人のサーバーやローカルデータセンターから実行できていたインフラストラクチャが、ますますクラウドに移行しています。

Amazon（AWS）、Microsoft（Azure）、Google Cloudなどの巨大な企業が、今やインターネットのバックボーンをホストしています。この変化は、大規模で安全かつ信頼性のあるインフラを運用することが非常に複雑で資本集約的になったため、わずかな企業しか効率的に行えなくなったためです。

スタートアップや既存の企業でも、これらの大手クラウドプロバイダーに頼ることが安価で簡単だとわかりました。

CDN（CloudflareやAkamaiなど）やDNSリゾルバなどのサービスも、いくつかの大手プレイヤーに引き寄せられました。

これらの管理されたソリューションの複雑さとコストの利点は、組織が独自のインフラストラクチャを構築する理由が少なくなったことを意味します。

徐々に、小規模のISP、独立したホスティング、地域密着型のルーティングなど、分散型の基盤は次第に、ほとんどのトラフィックやサービスがわずかな大手の仲介業者に依存するモデルに変わっていきました。

余波：少数の手に権力が集中

「大物たちは悪いことを始めたわけではありません。彼らは便利さ、パフォーマンス、利益を最適化するために行動していただけです。」

それは基礎ネットワークの初期の建築設計の選択肢の自然な結果でした。

規模と中央集権化がもたらしたのは、より多くの力と制御力でした。

大規模なプラットフォームは、利用者が見たり投稿したりするコンテンツや、データの収集や販売方法を独自に決めていました。もし利用者がこれらのポリシーが気に入らない場合、選択肢が少なかったです。

これらのプラットフォームの推奨アルゴリズムやコンテンツポリシーは、実質的な公共の議論の調停者となりました。

矛盾していることに、アイデアやコンテンツの自由な交換を可能にするオープンで分散化されたネットワークとして始まったものが、今ではしばしば情報を数社の企業ゲートウェイを通じて集めることが多い。

今やこれらの企業は、ある面では政府と同等の権力を持ちます：彼らは公共の議論を形作り、商業に影響を与え、第三者開発者のエコシステム全体をコントロールすることができます。

元々は自由な形式でピアレベルの相互接続を目指して設計されたネットワークは、現在は強力な企業ハブの周りを周回し、オンライン体験の大部分を形作り、制御することができます。

これは権力を集中させるための大きな計画ではありませんでした。また、この状況は単一の「間違い」によって生じたものでもありません。

大物は悪意を持って始まったわけではありません。彼らは単に便利さ、パフォーマンス、利益の最適化を追求しました。それは基盤となるネットワークの初期の設計選択の自然な結果でした。

これらの選択肢は、より幅広い商業的な観客がシステムを使用し、初期の設計パラメータを超えることを予期していませんでした。

これらの選択肢は時間の経過とともに、一部の企業が支配するシステムに蓄積されました。

同じことが分散化産業で私たちの目の前で起こっています。

中央集権への道は「一時的な」解決策で舗装されています

「集中化への傾斜は常に悪意のある意図の結果ではありません。しばしば、規模において分散化を維持するために構築されていないシステムの問題を解決しようとする試みです。」

初期のインターネットがピア・ツー・ピアの理想から逸脱して、わずかな大手プレーヤーの手に落ちたように、今日のブロックチェーンや「分散型」テクノロジーも同じ道をたどるリスクがある。

これは、Ethereum がスケーリングを試みる際に最も簡単に見ることができます。

高い手数料と遅いスループットは、開発者たちをレイヤー2（L2）ソリューションの採用に駆り立てました。これは、オフチェーンでトランザクションをバンドルし、それをイーサリアム上で解決するものです。理論上、これらのL2はイーサリアムの信頼性を保持するはずです。

実際には、多くの人が1つの会社によって運営される単一の「シーケンサー」（取引を順番に並べ替える中央サーバー）に依存しています。

ただし、現在、特定のL2ソリューションが最も活発であり、総ロックされた価値が最も高い状況ですが、最も中央集権的でもあります。

そのポイントは、分散化はいつか訪れるというものですが、以前にも聞いたことがあります。

時間が経つと、これらの「一時的な」解決策は永久的なものになる傾向があります。同じパターンは将来のレイヤー化アプローチでも現れるかもしれず、分散化への道筋を約束することさえしないものもあります。

「ソーシャルログイン」は便利に見えるかもしれませんが、秘密鍵や複雑なインターフェースを扱うことなくサービスを利用できるようにする一方で、これらのログインが中央集権化されたコンポーネントに依存している場合、再び1つの企業に正しいことをすることを信頼することになります。

そのため、zkLoginを構築する際には、信頼性のある方法で構築し統合しました。これは困難でしたが、便宜のために中央集権を導入することはできません。

NFTエコシステムでも同様のパターンが現れました。

単一の主要なマーケットプレイスが二次市場の主要な場となり、取引量の大部分を獲得し、事実上のプラットフォームとなりました。

このマーケットプレイスは、間もなく二次販売のロイヤリティ支払いを停止することを決定しました。

はい、取引高は増加しましたが、それによって収入の主要な源泉として依存していたクリエイターたちを困らせてしまいました。

これは、中央集権化プラットフォームがいつでもルールを変更できるときに、その結果が明らかに示されている例です。

その支配は取引にとどまらず、多くのプロジェクトも彼らのAPIとインフラに依存していました。

この中央集権化されたプラットフォームが障害を起こしたとき、全体のエコシステムに影響が及び、形成されていた深い依存関係が露呈されました。

でもなぜこれが続いて起こるのですか？

ユーザーは、迅速で安価で簡単な体験を求めています。プレッシャーの中で、開発者はしばしば馴染みのある信頼性のある解決策に頼ります。これらの選択肢はシンプルで高速ですが、分散を損なうコントロールポイントを導入する可能性があります。

これらの手順のいずれも、独占化するための大きな計画として始まるわけではありません。それらは単なる実践的な対応であり、厳しい技術的、市場的な課題への対応です。

しかし、時間の経過とともに、これらの「バンドエイド」はシステムのDNAに組み込まれ、少数のプレイヤーが鍵を握る構造が作られます。

だから、これらのシステムは、消費者だけでなく、ビルダーのためにも、最初から設計されなければならないのです。

ビルダーのために建設中、単なる消費者ではありません

「もし私が人々に何を望んでいるか尋ねたら、彼らはもっと速い馬だと答えたでしょう。」- ヘンリー・フォード

ほとんどの消費者は、既に持っているものの改良版を求めています。

しかし、これらの短期的な改善だけを追求すると、表面上は分散化されて見えるシステムでも、依然として数人の主要なプレーヤーが糸を引いている可能性があります。

今日のデジタルゲートキーパーの誤りを繰り返さないためには、単に消費者だけでなく、未来の創造者、ビルダーに焦点を当てる必要があります。

これが私がいつもチームに伝える理由です。消費者は常に速い馬を求めるでしょう。それは車を想像するビルダーたちです。

0:00 / 0:38

適切なビルディングブロックを持つことで、開発者は利便性のために中央集権化に追い込まれることなく、プラットフォームを立ち上げることができます。彼らは、単一のエンティティが支配したりユーザーをロックしたりすることのないシステムを作成することができ、利益がすべての参加者により均等に流れることを保証します。

だから、これらのシステムは、インターネットレベルにスケールする必要がある場合でも、分散化を強化するために最初から設計されなければなりません。

テクニカルデット vs デザインデット

「テックデットはリファクタリングで修正できます。一方、デザインデットは完全なリセットを要求することがしばしばあります。」

数十億人のユーザーにスケーリングするシステムで働いていた若い頃から、一つの教訓が私に残りました。システムがミッションクリティカルになると、壊して全てを再構築することはできず、大規模な混乱を引き起こすことなくはできません。

数百万人のユーザーがシステムの確立された動作や前提に依存している瞬間には、極端なアーキテクチャの変更を提案すること自体が不可能です。

それはアプリケーション、ビジネスモデル、そしてそれらを基盤としたコミュニティ全体の信頼を崩壊させる可能性があります。

これは最も深刻な「デザインデット」の概念です。

これは単なるコードの整理についてだけではありません。それは信頼、権力、そして価値がネットワークを通じてどのように流れるかを決定する基本的な建築的選択についてです。

この業界の初期には、いわゆる「ブロックチェーンまたはスケーラビリティの三難問題」という考えがありました。それは、一度に分散、セキュリティ、スケーラビリティをすべて実現することはできないという法則のように扱われていました。

人々はその前提の上に構築され、それが重力と同じくらい変わらないものだと信じていました。しかし、それはそうではありませんでした。

それは欠陥のある初期アーキテクチャに由来しています：大規模なグローバル共有状態、並列処理とモジュラースケーリングが不可能な制限されたデータモデル。

前進する唯一の方法は、すべての取引を一緒にまとめて、参加者全員が同じ限られたリソースを求めて戦わなければならないようにすることです。それによる結果は？需要の急増時にコストを押し上げ、混雑が実際に発生している場所に絞り込むことができず、効率の悪いブロックスペースのオークションです。

これらの条件の下では、（中央集権的なシーケンサーに依存するL2や、中央集権的なストレージに依存する圧縮アセットなどの）レイヤーの追加は、亀裂を埋めるだけでした。

短期的な問題を修正するための各パッチは、しばしばより多くの複雑さと集中管理ポイントを追加し、元のビジョンからより遠ざかっている。

これは、設計上の負債が中央集権化に向かってすべてを引き寄せる「技術的重力」の形に蓄積される方法です。

ゲートキーパーになるつもりのなかったシステムでも、その基本的なアーキテクチャが要求するため、階層構造を強化する結果になることがあります。それが起こると、真に分散化され、信頼性のない状態に戻る道は、既得権益とインフラストラクチャの慣性によって阻まれます。

教訓は明確です：最初からアーキテクチャを正しくする必要があります。

それは、すべてを単一のグローバル状態にまとめないデータモデルを選択し、中間者を信頼せずに検証可能なストレージソリューションを使用し、強力な中間者の少数に依存しないネットワーキングレイヤーを選択することを意味します。

それは最初から完全にテックスタックを再考することです。

最初の日から基本を正しくする

「デザインデットの唯一の真の治療法は、最初にそれを蓄積しないことです。」

私たちが「悪意のあることができないインフラストラクチャを構築する」と言うとき、私たちは実際には最初の日から正しいアーキテクチャの選択について話しているのです。

そのため、Suiを設計する際には、最初の日からそれらの基本的な原則を取り入れたいと考えました。

これにより、開発者は曲がりくねったり中央集権的な支えに頼ることなく、スケーラブルで安全で使いやすいアプリケーションを構築することができます。

プログラミングモデル自体を考慮してください:

Sui’s object-centric approachは、多くのブロックチェーンを支配してきたアカウントベースのパラダイムから意図的に逸脱しています。

オブジェクト中心のプログラミングモデル

Suiの設計哲学の中心には、オブジェクト中心のプログラミングモデルがあります。

Web2の開発者が自然にファイル、レコード、資産などのオブジェクトとして考える世界では、すべてを一つのモノリシックなアカウントモデルにまとめることは意味がありません。

それによって、開発者は自然でない思考パターンに追いやられます。エラーの温床となる複雑さが導入されます。

オブジェクト中心のプログラミングモデルは、Web2エンジニアがすでにソフトウェアについて考える方法と自然に一致しています。

オブジェクトは第一級の市民として機能し、資産を表現したり、ルールを定義したり、複雑な雛形コードなしで再入障害のような一般的な落とし穴を避けたりすることが簡単になります。

この馴染みのあるモデルは、再入性のような概念的なオーバーヘッドや一般的な落とし穴を劇的に減らします。開発者は、悪用を防ぐための定型チェックや複雑なガードレールを書く代わりに、Move VMによってランタイムレベルで安全性を保証します。

結果として、コードはより読みやすく、安全で、理解しやすくなります。

Web2のオブジェクト指向の考え方からWeb3の信頼できない環境への直接の橋渡しであり、適切な前提条件から始めることで実現可能になりました。

ダクトテープではなく設計によるスケーリング

しかし、優れたプログラミングモデルは、負荷下で崩れる場合には何も意味しません。

最初から、Suiは現実世界の負荷を処理するために構築されました。同期的な原子性の組み合わせを維持しながら、水平にスケーリングするために設計されています。

システムのオブジェクトモデルは、各トランザクションが触れる状態の部分を細かく理解することで、規模で並列実行を可能にします。これは、全体のグローバル状態をロックする必要があるEVMベースのシステムとは真っ向から対照的です。これにより、すべてが遅くなり、トランザクション量をオフロードするために中央集権化されたソリューションが奨励されます。

Suiでは、各オブジェクトが実質的に独自のシャードとなります。容量を増やす必要がありますか？負荷を処理するために、より多くの計算能力を追加してください。

ザ・パイロットフィッシュ・プロトタイプ:https://blog.sui.io/pilotfish-execution-scalability-blockchain/

開発者は、スケーリングを実現するためにシャーディングロジックや複数のドメインを結ぶこと、またはインフラストラクチャを手作りする必要はありません。

ネットワークが成長するにつれて、システムがより多くのトラフィックを処理できるようになりますが、どのようにして公正なリソース割り当てを確保するのでしょうか？

人気のあるアセットまたはdAppが市場で状態の更新を独占すると、コストが上昇し、他のすべての人にとって体験が低下する可能性があります。

一つのホットなアプリケーションがすべての人の価格を引き上げることができる単一の、グローバルなブロックスペースのオークションに頼らず、ローカル料金市場はシステムがより細かいレベルの粒度でリソースの価格を設定することを可能にします。

各「オブジェクト」またはシャードは独自の手数料市場を持つことができ、1つのエリアでの輻輳がネットワークの無関係な部分に波及してペナルティを課さないようにします。

それはプラットフォームの基本設計にすべて組み込まれており、需要が増えても、システムはゲートキーパーや閉じられた庭園の古いパターンに戻らないようになっています。

分散化の設計は、ストレージと通信レイヤーに検証機能を組み込むことも意味します。

データストレージが単一の信頼できる当事者に依存している場合、最初からやり直しになります。誰もが中間者に依存せずにデータの整合性を検証できるストレージソリューションが必要です。

中央集権的なホストなしで検証可能なストレージ

真に分散化されたアプリケーションは、単一のクラウドプロバイダや集中型データベースに依存することはできません。

Walrusは、AWSやGoogle Cloudのような中央集権的な提供に匹敵する、分散型で検証可能なストレージレイヤーを提供します。

Walrusでは、データの検証可能性は単なる付け足しではなく、本質的な特性となっています。

ストレージレイヤーを統合することで、ウォルラスは開発者がウェブサイトを実行し、データをホストし、中央集権的なパターンに逆戻りすることなく、完全に分散型のアプリケーションを構築できるようにし、それが本来検証可能で改ざんできない仕組みを備えています。

言い換えれば、ウォルラスは実行からストレージへの「構築による正確さ」の哲学を拡張し、すべてのレイヤーでアプリケーションの整合性を確保します。

今、分散化のための設計は、合意または実行レイヤーで止まるべきではなく、ネットワーク自体にまで拡張すべきです。

ネットワーキングレイヤーは、わずかな強力なISPやルーティングサービスに依存すべきではありません。それは中央集権化でもあります。

分散化のために構築されたネットワーキングレイヤー

ネットワーキングは、Web3ではしばしば見落とされるパズルの一部です。

従来のインターネットルーティングは、わずかなISPによって制御されており、潜在的なボトルネックや脆弱性が導入されています。

SCIONは、この現状に挑戦する次世代のネットワーキングプロトコルであり、ルーティングをより安全で信頼性があり、中央集権的な制御に対して抵抗力のあるものにしています。

今日のインターネットと並行して実行できる、セキュアでマルチパスのインタードメインルーティングアーキテクチャです。ネットワーク間でデータが移動する方法を完全に再構想し、セキュリティ、コントロール、パフォーマンスをその中核に組み込んで構築されています。

SCIONをSuiに統合することで、基盤となるネットワークが単一の障害点や制御ではないことを確認しています。

単一のエンティティがデータフローを独占することはありません。ユーザーは、基盤となるルートが操作や独占されないことを信頼することができます。

各層（データモデル、ストレージ、ネットワーキングを含む）に検証可能性と許可なしを統合することで、中央統制のポイントが発生する可能性のある領域を減らすことができます。

あなたは分散化をあと付けではなく、基盤に埋め込んでいます。

このシンプルさにより、複雑さが減少し、そして「便利」だが中央集権的な回避策を閉ざすことができます。何よりも、基本を正しく押さえることは、決して「後で修正する」という考え方に賭けることを意味します。

すべての道はサウンドデザインに戻ります

「分散化は検証者の数ではありません。真の分散化は、権力が一箇所に集中するのを防ぐアーキテクチャに関わるものです。」

私たちが探求してきたすべてのポイントはシンプルです: もし悪意を持たないシステムが欲しいのであれば、正しいアーキテクチャから始める必要があります。

間違った前提条件から始めた場合、余分なコードや巧妙なトリックでも救われません。

ゲートキーパーを報酬するアーキテクチャ。すべてのアクターが同じ希少なリソースを競争せざるを得ないデータモデル。中央集権的なハブに基づいたネットワーキング層。最終的には、制御と階層の古いパターンに戻ってしまいます。

これがなぜ建築の基礎が非常に重要なのかです。

分散化は単にノードの数を数えることだけではありません。真の分散化とは、信頼性、公正さ、検証可能性を回避することが不可能なように、根本的なレベルで設計することを意味します。

それは、一握りのクジラやリソース豊富な企業が静かに競技場を傾けることができないシステムを構築することを意味します。それは、すべての参加者が公正なチャンスを持ち、どのような制約点や微妙なデザインの決定も中央集権化に発展することはありません。

Suiは、これらの原則を考慮して最初の日から設計するとどうなるかの一例です。後からそれらを後付けしようとするのではなく、最初から設計するという考え方です。

プログラミングモデルからコンセンサスレイヤー、ユーザーのオンボーディングからデータの利用可能性とネットワーキングレイヤーまで、スタック全体が開放性と中立性を強化すると、ビルダーやユーザーが平等な条件で繁栄する環境が作られます。

最初の原則から始め、すべてのレイヤーで分散化を徹底することで、どれだけ大きくなってもそのエショスに忠実なインフラストラクチャを作ることができます。

最初から正しく構築すれば、将来の修正や半ばの手段を約束する必要はありません。

公正で弾力があり、次世代のデジタル体験の基盤として役立つネットワークを持つことになります。

免責事項:

1. この記事は[から転載されましたX]. すべての著作権は元の著者に帰属します [@EvanWeb3]. この転載に異議がある場合は、お問い合わせください。gate学習チームが速やかに対処します。
2. 責任の免責事項：この記事で表現される意見は、著者個人の意見であり、投資アドバイスを構成するものではありません。
3. gate Learnチームは、記事の翻訳を他の言語に行っています。特に言及されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。