構建 “無法作惡” 的基礎設施

中級1/16/2025, 2:31:47 AM
本文介紹了構建去中心化系統的關鍵原則,重點討論了區塊鏈中可能出現的中心化風險,並提供了像Sui的面向對象編程、可擴展基礎設施和去中心化存儲等解決方案,旨在防止權力過度集中。

很多年前,當我剛開始參與服務數十億用戶的項目時,我深刻體會到,初期的基礎設施設計決定可以徹底改變整個行業的走向。

即便是那些起初以開放、中立和去中心化為目標的平臺,也可能逐漸走向集中化。

這並非出於惡意,而是因為某些設計決策在早期就被固定下來後,技術和市場的自然演進會讓系統逐步集中化。

因此,從一開始,基礎設施的設計選擇就非常重要。

這些關鍵設計必須確保技術能夠內置公平性,並在根源上防止權力的過度集中。

熟悉的劇本

“權力總是傾向於集中化,即使沒有人刻意為之。”

這是我在負責大型互聯網項目時切身體會到的一條深刻規律。

當“去中心化行業”初現時,它似乎為我們帶來了新的希望。我們將比特幣、以太坊等視為擺脫傳統權力結構的工具。

故事很簡單:奪回權力,擺脫中間商的束縛,讓公平由代碼來保障。

然而,我們不得不承認,隨著時間的推移,那些曾讓互聯網走向集中化的力量,如今也在影響這些所謂的“去中心化”系統。

那麼,互聯網為何會走向集中化?

互聯網最初不是作為一個能夠承受核戰爭的去中心化P2P網絡誕生的嗎?

要弄清楚為何去中心化系統會逐漸受制於集中化壓力,我們需要回顧互聯網的歷史,瞭解它是如何從理想主義的起點,演變為一個高度集中化的生態的。

早期互聯網:去中心化的點對點網絡

“最初,沒有誰掌控一切,也沒有誰能獨斷專行。”

互聯網的雛形可以追溯到20世紀60年代末,由美國國防部推動的ARPANET項目開創了基礎。

來源: @DailySwig

從一開始,這個網絡的設計目標就是避免“單點故障”。即便某一部分失效,也不會導致整體癱瘓。

為了實現這一目標,網絡被精心設計成去中心化的架構。

其背後的邏輯非常明確:分佈式系統能夠應對單點故障,確保即使在設備故障或戰爭等極端情況下,通信依然可靠。

一個可以抵禦核打擊的去中心化通信網絡由此誕生。

網絡中的每個節點都是獨立的“對等體”,能夠自主發送和接收數據,無需依賴任何集中管理的權威機構。無論設備是什麼硬件或操作系統,只要能使用TCP/IP協議,就能進行數據交換。

到了70年代和80年代,大學和研究機構通過NSFNET和ARPANET連通,形成了一個真正的去中心化網絡環境——沒有人能控制全局,也沒有誰能主導規則。

這種去中心化精神還體現在技術基礎中:

TCP/IP、FTP、Telnet、Usenet新聞組和DNS的設計初衷都不是為了強化控制,而是為了開放和協作。

比如,Usenet通過去中心化的點對點方式傳播消息,而DNS採用分佈式層次結構委派命名權,但每個節點既是客戶端也是服務器。

這都彰顯了互聯網最初的核心原則:

一個開放的網絡,任何人都能接入和參與,而不是被某個大玩家壟斷規則。

然而,到了90年代初,萬維網和瀏覽器的出現改變了一切。

第一個網站頁面復現(圖片來源:CERN)

客戶端/服務器模式的崛起

蒂姆·伯納斯-李:萬維網的締造者

1989年至1991年,萬維網誕生。這一技術基於開放標準(HTTP、HTML),並被無償公開給公眾。最初的網絡環境簡單直接,任何人,只要擁有一臺調制解調器和託管工具,都能輕鬆建立自己的網站。

當時的互聯網基礎設施相對簡單,分散式架構占主導地位,無數獨立網頁相互鏈接,構成了一個鬆散的網絡聯盟。

然而,到了90年代初,情況開始發生變化。

“網頁瀏覽”成為了改變遊戲規則的“殺手級應用”。

網站逐漸轉變為在線商店、新聞平臺以及娛樂中心,而普通用戶已經很少自己運行服務器或託管頁面了。

1994年,Netscape瀏覽器的主頁,展示其吉祥物Mozilla(截圖來源:Alex Pasternack / OldWeb.today

用戶通過網頁瀏覽器(客戶端)訪問網絡,最初依賴慢速調制解調器,後來使用寬帶連接,從大型、知名的網絡服務器獲取內容。託管大量數據、建立電子商務網站或搜索引擎迅速成為趨勢。

早期搜索引擎如AltaVista和Yahoo!,以及後來的Google,幫助用戶在信息爆炸的互聯網中快速找到所需內容

網絡效應迅速顯現:用戶越多,搜索引擎的索引和廣告模型優化得越好,其市場主導地位也越牢固。

Google的PageRank算法使其成為用戶探索互聯網的首選入口。

這一趨勢吸引了資本和資源集中到大型數據中心,而那些能夠擴展並應對大規模流量的平臺最終勝出。

與此同時,互聯網服務提供商(ISP)崛起,為數以百萬計的新用戶提供接入服務。網絡基礎設施逐步向“下行優化”方向發展。

非對稱寬帶連接(如ADSL和有線網絡)成為主流,提供更快的下載速度而非上傳速度,這反映了大部分用戶以消費內容為主的需求。

隨著互聯網用戶規模的持續擴大,早期互聯網開放性和信任的設計理念也開始暴露出其侷限性。

安全機制、防火牆與集中化的演變

“自由和開放若缺乏安全保障,可能會引發濫用,最終讓我們不得不建起更高的圍牆。”

互聯網的早期協議並沒有設計成能應對海量用戶,尤其是那些帶有商業目的、試圖濫用開放性的人群。

由於缺乏有效的防護機制,垃圾信息氾濫,利用了互聯網開放的特性。

最初的網絡架構允許每臺主機與其他任何主機互聯,這在互聯網規模較小時行得通。

但隨著網絡發展,黑客攻擊和惡意活動迅速激增。

來源: emailtray.com

同樣地,在沒有公平使用帶寬的辦法時,一些應用學會了突破限制,以犧牲他人利益為代價獲取優勢。

這些設計上的缺陷將互聯網推向了更多的管控和控制。

為保護內部網絡,防火牆被引入,用於阻擋外部訪問;網絡地址轉換 (NAT)技術進一步限制了直接通信,將設備隱藏在共享IP地址之後。

這削弱了通信的點對點(P2P)特性。

位於NAT和防火牆之後的主機實際上被迫成為僅客戶端角色,不再能被外界直接訪問。

隨著時間推移,這些基礎設施決定相互強化了這種現象。

“守門人”的出現

“少數幾家公司意識到,控制數據中心並擁有大規模服務器基礎設施能帶來巨大的競爭優勢。”

從家中運行自己的服務器的複雜性和成本,加上NAT和防火牆等技術壁壘,意味著越來越少的個人能夠作為真正的點對點參與者。

換句話說,這種環境實際上促使互聯網走向了少數集中化巨頭的方向。

到了2000年代早期,少數公司意識到,控制數據中心和大規模服務器基礎設施為它們提供了巨大的競爭優勢。

它們能夠提供比網絡上隨機點更快、更可靠、更方便的服務。

這種趨勢在2000年代末達到了極致。

來源:datareportal.com

像Google這樣的搜索引擎、Amazon這樣的大型平臺、Facebook這樣的社交媒體巨頭,以及內容分發網絡(CDN)都建立了能夠以前所未有的速度和規模交付內容和應用的龐大基礎設施。

這些大公司還利用了數據與算法的“良性循環”。

它們吸引的用戶越多,收集的數據也就越多,從而能夠優化產品、個性化體驗以及更準確地投放廣告。這使它們的服務更具吸引力,吸引更多用戶和收入。

隨後,互聯網的收入模式逐漸轉向了高度依賴於目標廣告的模式。

隨著時間推移,這種反饋循環進一步集中了權力,因為小型競爭對手難以匹敵大公司在基礎設施投資和數據上的優勢。

原本可以從個人服務器或本地數據中心運行的基礎設施逐漸遷移到雲端。

像Amazon(AWS)、Microsoft(Azure)和Google Cloud這樣的巨頭如今承載了互聯網的大部分骨幹。這一轉變的發生是因為運行大規模、安全可靠的基礎設施變得如此複雜且資本密集,以至於只有少數公司能夠高效完成。

創業公司甚至一些成熟的企業發現,依賴這些大型雲服務提供商更便宜、更簡單。

內容分發網絡(如Cloudflare或Akamai)和DNS解析服務也逐漸集中到少數大公司手中。

這些託管解決方案的複雜性和成本優勢使得組織缺乏“自己動手”構建基礎設施的理由。

漸漸地,小型ISP、獨立託管和本地化路由等去中心化的支柱被一種依賴少數幾個主要中介的模式所取代。

後果:權力集中在少數人手中

“大型企業最初並非出於惡意,而是為了提升便利性、性能和盈利能力。

然而,這正是早期網絡架構設計選擇的自然結果。”

隨著互聯網的發展和集中化,權力和控制逐漸向少數幾家巨頭傾斜。

這些大型平臺不僅能設定服務條款,還能決定用戶看到或發佈什麼內容,以及如何使用或出售用戶數據。如果用戶不滿這些規則,他們幾乎別無選擇。

久而久之,這些平臺的推薦算法和內容政策逐漸成為公共話語的實際仲裁者。

諷刺的是,最初作為開放、去中心化網絡誕生的互聯網,如今反而成為少數公司把控信息流的工具。

這些企業在某些方面的影響力甚至可與政府媲美:它們可以操控公共輿論、影響商業活動,甚至左右整個開發者生態系統的運行規則。

曾經致力於實現自由連接的網絡,現在卻圍繞著這些企業運轉,顯著改變了在線體驗。

這並非是為了集中權力的某種宏大計劃,也不是源於某個“錯誤的轉折點”。

大型玩家最初並非懷有惡意;他們只是為了方便、性能和利潤進行優化。

這是早期網絡架構設計選擇的自然結果。

這些選擇並未預見到一個更廣泛、以商業為驅動的受眾如何使用系統,並將其推向初始設計參數之外。

隨著時間的推移,這些選擇累積成一個由少數公司主導的系統。

去中心化行業正在重蹈覆轍

通向中心化的道路鋪滿了“臨時”解決方案

“集中化往往並非惡意行為的結果,而是試圖修復系統問題時做出的權宜之計。”

與早期互聯網從去中心化走向集中化的歷史相似,如今的區塊鏈和所謂的“去中心化”技術也在面臨同樣的命運。

以太坊擴展性問題最能說明這一點。

高昂的費用和緩慢的吞吐量推動開發者採用 Layer-2 (L2) 解決方案:這些 rollup 將交易聚合到鏈下處理,然後在以太坊上結算。理論上,這些 L2 應該保留以太坊的無信任特性。

實際上,許多依賴於一個單一的“排序器”(一個由某家公司運營的集中式服務器,用於排序交易)。

目前,某個特定的 L2 解決方案擁有最多的活動量和總鎖定價值,但同時也是最集中的。

它的宣傳是去中心化“某天會到來”,但這話我們以前聽過。

隨著時間推移,這些“臨時”解決方案往往會變成永久的。未來的分層方法可能會出現類似模式;有些甚至可能連去中心化的承諾都懶得給出。

例如,“社交登錄”看起來很方便:它讓人們無需處理私鑰或複雜界面就能輕鬆開始使用服務。但如果這些登錄依賴於一個集中化的組件,你再次將信任交給了一家公司。

因此,當我們構建 zkLogin 時,我們選擇以無信任的方式設計並集成它。雖然過程艱難,但我們不能為了方便而妥協,允許集中化。

類似的模式也出現在 NFT 生態系統中。

一個單一的主導市場成為二級交易的主要場所,捕獲了大部分交易量,並事實上成為了默認平臺。

不久前,這個平臺決定停止在二級銷售中強制執行版稅支付。

確實,這增加了交易量,但卻損害了依賴這些版稅作為關鍵收入來源的創作者。

這清楚地展示了當集中化平臺可以隨時修改規則時會產生的後果。

它們的主導地位還延伸到交易之外,因為許多項目也依賴於它們的 API 和基礎設施。

當這個集中化平臺出現宕機時,整個生態系統都受到了影響,暴露出已經形成的深度依賴。

但為什麼這種情況總是不斷髮生呢?

因為用戶希望快速、便宜和簡單的體驗。而開發者在壓力下,往往轉向熟悉且可靠的解決方案。這些選擇確實更簡單、更快,但也可能引入削弱去中心化的控制點。

這些步驟沒有哪個一開始是為了壟斷而設計的。它們只是對技術和市場挑戰的實際迴應。

但隨著時間推移,這些“權宜之計”會嵌入系統的 DNA 中,創造出一個由少數玩家掌控關鍵點的結構。

這就是為什麼這些系統必須從一開始就為開發者設計,而不僅僅是為消費者設計。

為建設者設計,而不僅僅是消費者

“如果問消費者想要什麼,他們可能只會說‘一匹更快的馬’。” ——亨利·福特

大多數人只想要現有事物的改進版。

但如果我們總是追逐這些短期改進,結果可能是構建出一個表面去中心化但實質被少數機構控制的系統。

要想避免今天“數字巨頭”主導的情況重演,我們需要把注意力轉向未來的創新者——建設者,而不僅僅是消費者。

這就是為什麼我常告訴團隊,消費者會追求“更快的馬”,而建設者則想象“汽車”。

通過為開發者提供強大的工具和模塊,我們可以打造無需為了便利而犧牲去中心化的平臺。這樣的系統能夠避免單一實體的壟斷,確保系統收益公平分配。

因此,真正去中心化的系統需要從設計之初就植入支持去中心化的理念,即使它們將來要擴展到互聯網級別。

技術債務與設計債務的差別

“技術債務可以通過修復代碼來解決,但設計債務往往需要從頭開始。”

從我參與構建億級用戶系統的經驗中,我明白一旦一個系統變得至關重要,就很難徹底重建而不造成巨大破壞。

當數百萬用戶依賴於你係統中的某些核心邏輯時,任何重大架構調整都可能打破商業模式,甚至損害整個社區的信任。

這就是“設計債務”的最嚴重表現。

設計債務不僅是代碼優化問題,而是網絡架構中對信任、權力和價值流向的核心設計選擇。

早期區塊鏈行業曾把“擴展性三難困境”(去中心化、安全性與可擴展性無法兼得)當作天經地義。

人們在這個假設之上構建,認為它就像重力一樣不可改變。

但這一限制並非天生,而是最初設計架構的缺陷:龐大的全球共享狀態和僵化的數據模型,讓並行化和模塊化擴展無法實現。

唯一的前進方式是將所有交易捆綁在一起,迫使每個參與者無論他們在做什麼都必須爭奪同樣有限的資源。結果是什麼?在需求激增時,區塊空間的低效拍賣抬高了成本,同時未能將擁堵隔離到實際發生的位置。

在這種情況下,增加層級(如依賴於中心化排序器的 L2 或依賴於中心化存儲的壓縮資產)只是掩蓋了問題。

每次修補短期問題的嘗試,往往增加了複雜性和更多的中心化控制點,使系統進一步偏離原本的願景。

這就是設計債務如何累積成一種“技術重力”,將一切拉向中心化。

即使那些從未打算成為“守門人”的系統,最終也會因為其基本架構的要求而強化層級結構。一旦發生這種情況,返回真正去中心化和無信任狀態的道路就被既得利益和基礎設施的慣性所阻擋。

教訓很明確:必須從一開始就正確設計架構。

這意味著選擇不會將一切捆綁到單一全球狀態的數據模型,使用無需信任中介就能驗證的存儲解決方案,並選擇不依賴於少數強大中介的網絡層。

這關乎從第一天起重新想象整個技術堆棧。

從第一天起打好基礎

“唯一避免設計債務的方法就是從一開始就不要讓它產生。”

當我們談論創建“無法作惡”的基礎設施時,其核心是從最初就做出正確的架構決策。

因此,在設計 Sui 時,我們從第一步就將這些核心原則融入系統中。

這樣,開發者可以更輕鬆地構建可擴展、安全且易用的應用,而無需依賴中心化的妥協方案。

考慮編程模型本身:

Sui 的面向對象的編程模型有意脫離了許多區塊鏈所採用的賬戶模型範式。

面向對象的編程模型

Sui 設計理念的核心是面向對象的編程模型。

在一個 Web2 開發者習慣於用文件、記錄和資產等對象思維的世界中,將一切簡化為單一的賬戶模型沒有意義。

這樣做迫使開發者採用不自然的思維模式,增加了容易出錯的複雜性。

面向對象的編程模型與 Web2 工程師的思維方式自然一致。

對象作為一等公民,使得表示資產、定義規則變得簡單,同時避免了常見的漏洞(例如重入漏洞),無需複雜的樣板代碼。

這種熟悉的模型大大減少了概念上的負擔以及常見的陷阱,例如重入問題。開發者無需通過編寫樣板檢查代碼或複雜的防護措施來防止漏洞,而是依靠 Move 虛擬機在運行時層面上確保安全。

因此,代碼更加易讀、安全,也更容易理解。

這是從 Web2 面向對象的思維模式到 Web3 去信任環境的直接橋樑,這得益於從一開始就基於正確的假設設計。

通過設計擴展,而非補丁修復

但一個偉大的編程模型,如果在負載下崩潰,就毫無意義。

從一開始,Sui 就是為處理現實世界的負載而構建的。它被設計為在保持同步的原子組合性的同時水平擴展。

系統的對象模型使 Sui 對每筆交易所觸及的狀態部分有精細的理解,從而能夠實現大規模的並行執行。這與基於 EVM 的系統形成了鮮明對比,後者必須鎖定整個全局狀態。這不僅減慢了速度,還鼓勵中心化解決方案來分流交易量。

在 Sui 中,每個對象本質上都是它自己的分片。如果需要更多容量,只需添加更多計算能力以應對負載。

Pilotfish原型: https://blog.sui.io/pilotfish-execution-scalability-blockchain/

開發者無需擔心分片邏輯、跨域橋接或拼湊基礎設施以實現擴展。

隨著網絡的增長,系統可以處理更多的流量,但如何確保公平的資源分配?

如果某個熱門資產或 dApp 壟斷了狀態更新市場,就可能推高成本並降低其他用戶的體驗。

本地費用市場不再依賴單一的全球區塊空間拍賣(其中一個熱門應用程序可以抬高每個人的價格),而是讓系統以更精細的粒度對資源進行定價。

每個“對象”或分片可以擁有自己的費用市場,確保某一區域的擁堵不會蔓延並影響網絡的其他部分。

這些都被嵌入平臺的基礎設計中,確保即使需求增長,系統也不會退化為傳統的守門人模式和封閉生態。

為去中心化而設計還意味著將可驗證性內置於存儲和通信層中。

如果數據存儲依賴於單一的信任方,那麼你就回到了原點。你需要存儲解決方案,使任何人都能驗證數據完整性,而無需依賴中間人。

去中心化存儲:告別中心化主機

真正的去中心化應用不能依賴單一的雲服務提供商或集中式數據庫。

Walrus 提供了一個功能強大且可驗證的去中心化存儲層,性能堪比 AWS 和 Google Cloud 等主流中心化服務。

與其事後彌補數據驗證問題,Walrus 將數據可驗證性作為其核心設計的一部分。

通過集成一個防篡改且本質上可驗證的存儲層,Walrus 確保開發者能夠搭建網站、託管數據、開發完全去中心化的應用,避免走回中心化的老路。

簡單來說,Walrus 延續了“從根本上正確”的設計理念,將這一原則從執行層擴展到了存儲層,確保每一層的完整性。

現在,設計去中心化不僅意味著要在共識層或執行層上實現,還必須擴展到網絡本身。

網絡層不應依賴於少數強大的ISP或路由服務,這同樣是一種中心化。

一個為去中心化打造的網絡架構

在 Web3 中,網絡層往往是被忽視的一環。

傳統互聯網的路由由少數 ISP 控制,這種集中化帶來了潛在的瓶頸和安全隱患。

SCION 是一種全新的網絡協議,它打破了這一現狀,使數據路由更加安全、可靠,並減少了對集中化控制的依賴。

這種協議採用了安全、多路徑、跨域的路由設計,可以與現有互聯網並行運行。它從根本上重新定義了數據在網絡中的流動方式,在設計之初便將安全性、控制權和高效性能融入其中。

將 SCION 集成到 Sui 中,確保網絡層不會成為單點故障或集中控制的來源。

沒有任何機構能夠單方面控制數據流,用戶也無需擔心數據路由會被操控或壟斷。

通過在數據模型、存儲和網絡等各層級嵌入可驗證性和無權限特性,極大減少了集中控制的可能性。

這不是事後補充的去中心化,而是從一開始就嵌入到系統的基礎中。

這種簡單性減少了複雜性,同時防止了“方便但集中的權宜之計”的使用。最重要的是,從一開始就將基礎打好意味著不必依賴“以後再修復”的心態。

健全設計的重要性

“去中心化不是節點數量的比拼,而是通過架構設計防止權力過度集中。”

我們探討的一切要點很簡單:如果你想要一個“無法作惡”的系統,就必須從正確的架構開始。

如果從一開始就基於錯誤的假設構建,再多的代碼或聰明的修補都無濟於事。

獎勵守門人的架構、迫使每個參與者爭奪相同稀缺資源的數據模型,以及圍繞集中式樞紐設計的網絡層——最終你會滑向相同的控制和層級模式。

這就是為什麼架構基礎如此重要。

去中心化不僅僅是計算節點的數量。真正的去中心化意味著在根層設計,確保信任、公平和可驗證性無法被繞過。

這意味著構建一個系統,既不能讓少數巨鯨,也不能讓資源豐富的公司悄悄地傾斜競爭環境。這是關於確保每個參與者都有公平的機會,沒有任何一個阻塞點或細微的設計決定會演變成失控的集中化。

Sui 是一個例子,展示了當你從第一天就以這些原則設計時會發生什麼,而不是事後試圖調整。

當整個技術棧,從編程模型到共識層,再從用戶引導到數據可用性和網絡層,都強化了開放性和中立性時,你創造了一個構建者和用戶在平等條件下蓬勃發展的環境。

通過從第一原則出發,在每一層執行去中心化,你可以創建一個無論多大規模都能保持其初衷的基礎設施。

從一開始就構建得當,你無需承諾未來的修復或權宜之計。

你將擁有一個本質上公正、彈性強,並能作為下一代數字體驗基礎的網絡。

免責聲明:

  1. 本文轉載自【X】,版權歸原作者所有【@EvanWeb3】。若對本次轉載有異議,請聯繫 Gate Learn 團隊,他們會及時處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明,否則禁止複製、分發或抄襲翻譯文章。

Share

構建 “無法作惡” 的基礎設施

中級1/16/2025, 2:31:47 AM
本文介紹了構建去中心化系統的關鍵原則,重點討論了區塊鏈中可能出現的中心化風險,並提供了像Sui的面向對象編程、可擴展基礎設施和去中心化存儲等解決方案,旨在防止權力過度集中。

很多年前,當我剛開始參與服務數十億用戶的項目時,我深刻體會到,初期的基礎設施設計決定可以徹底改變整個行業的走向。

即便是那些起初以開放、中立和去中心化為目標的平臺,也可能逐漸走向集中化。

這並非出於惡意,而是因為某些設計決策在早期就被固定下來後,技術和市場的自然演進會讓系統逐步集中化。

因此,從一開始,基礎設施的設計選擇就非常重要。

這些關鍵設計必須確保技術能夠內置公平性,並在根源上防止權力的過度集中。

熟悉的劇本

“權力總是傾向於集中化,即使沒有人刻意為之。”

這是我在負責大型互聯網項目時切身體會到的一條深刻規律。

當“去中心化行業”初現時,它似乎為我們帶來了新的希望。我們將比特幣、以太坊等視為擺脫傳統權力結構的工具。

故事很簡單:奪回權力,擺脫中間商的束縛,讓公平由代碼來保障。

然而,我們不得不承認,隨著時間的推移,那些曾讓互聯網走向集中化的力量,如今也在影響這些所謂的“去中心化”系統。

那麼,互聯網為何會走向集中化?

互聯網最初不是作為一個能夠承受核戰爭的去中心化P2P網絡誕生的嗎?

要弄清楚為何去中心化系統會逐漸受制於集中化壓力,我們需要回顧互聯網的歷史,瞭解它是如何從理想主義的起點,演變為一個高度集中化的生態的。

早期互聯網:去中心化的點對點網絡

“最初,沒有誰掌控一切,也沒有誰能獨斷專行。”

互聯網的雛形可以追溯到20世紀60年代末,由美國國防部推動的ARPANET項目開創了基礎。

來源: @DailySwig

從一開始,這個網絡的設計目標就是避免“單點故障”。即便某一部分失效,也不會導致整體癱瘓。

為了實現這一目標,網絡被精心設計成去中心化的架構。

其背後的邏輯非常明確:分佈式系統能夠應對單點故障,確保即使在設備故障或戰爭等極端情況下,通信依然可靠。

一個可以抵禦核打擊的去中心化通信網絡由此誕生。

網絡中的每個節點都是獨立的“對等體”,能夠自主發送和接收數據,無需依賴任何集中管理的權威機構。無論設備是什麼硬件或操作系統,只要能使用TCP/IP協議,就能進行數據交換。

到了70年代和80年代,大學和研究機構通過NSFNET和ARPANET連通,形成了一個真正的去中心化網絡環境——沒有人能控制全局,也沒有誰能主導規則。

這種去中心化精神還體現在技術基礎中:

TCP/IP、FTP、Telnet、Usenet新聞組和DNS的設計初衷都不是為了強化控制,而是為了開放和協作。

比如,Usenet通過去中心化的點對點方式傳播消息,而DNS採用分佈式層次結構委派命名權,但每個節點既是客戶端也是服務器。

這都彰顯了互聯網最初的核心原則:

一個開放的網絡,任何人都能接入和參與,而不是被某個大玩家壟斷規則。

然而,到了90年代初,萬維網和瀏覽器的出現改變了一切。

第一個網站頁面復現(圖片來源:CERN)

客戶端/服務器模式的崛起

蒂姆·伯納斯-李:萬維網的締造者

1989年至1991年,萬維網誕生。這一技術基於開放標準(HTTP、HTML),並被無償公開給公眾。最初的網絡環境簡單直接,任何人,只要擁有一臺調制解調器和託管工具,都能輕鬆建立自己的網站。

當時的互聯網基礎設施相對簡單,分散式架構占主導地位,無數獨立網頁相互鏈接,構成了一個鬆散的網絡聯盟。

然而,到了90年代初,情況開始發生變化。

“網頁瀏覽”成為了改變遊戲規則的“殺手級應用”。

網站逐漸轉變為在線商店、新聞平臺以及娛樂中心,而普通用戶已經很少自己運行服務器或託管頁面了。

1994年,Netscape瀏覽器的主頁,展示其吉祥物Mozilla(截圖來源:Alex Pasternack / OldWeb.today

用戶通過網頁瀏覽器(客戶端)訪問網絡,最初依賴慢速調制解調器,後來使用寬帶連接,從大型、知名的網絡服務器獲取內容。託管大量數據、建立電子商務網站或搜索引擎迅速成為趨勢。

早期搜索引擎如AltaVista和Yahoo!,以及後來的Google,幫助用戶在信息爆炸的互聯網中快速找到所需內容

網絡效應迅速顯現:用戶越多,搜索引擎的索引和廣告模型優化得越好,其市場主導地位也越牢固。

Google的PageRank算法使其成為用戶探索互聯網的首選入口。

這一趨勢吸引了資本和資源集中到大型數據中心,而那些能夠擴展並應對大規模流量的平臺最終勝出。

與此同時,互聯網服務提供商(ISP)崛起,為數以百萬計的新用戶提供接入服務。網絡基礎設施逐步向“下行優化”方向發展。

非對稱寬帶連接(如ADSL和有線網絡)成為主流,提供更快的下載速度而非上傳速度,這反映了大部分用戶以消費內容為主的需求。

隨著互聯網用戶規模的持續擴大,早期互聯網開放性和信任的設計理念也開始暴露出其侷限性。

安全機制、防火牆與集中化的演變

“自由和開放若缺乏安全保障,可能會引發濫用,最終讓我們不得不建起更高的圍牆。”

互聯網的早期協議並沒有設計成能應對海量用戶,尤其是那些帶有商業目的、試圖濫用開放性的人群。

由於缺乏有效的防護機制,垃圾信息氾濫,利用了互聯網開放的特性。

最初的網絡架構允許每臺主機與其他任何主機互聯,這在互聯網規模較小時行得通。

但隨著網絡發展,黑客攻擊和惡意活動迅速激增。

來源: emailtray.com

同樣地,在沒有公平使用帶寬的辦法時,一些應用學會了突破限制,以犧牲他人利益為代價獲取優勢。

這些設計上的缺陷將互聯網推向了更多的管控和控制。

為保護內部網絡,防火牆被引入,用於阻擋外部訪問;網絡地址轉換 (NAT)技術進一步限制了直接通信,將設備隱藏在共享IP地址之後。

這削弱了通信的點對點(P2P)特性。

位於NAT和防火牆之後的主機實際上被迫成為僅客戶端角色,不再能被外界直接訪問。

隨著時間推移,這些基礎設施決定相互強化了這種現象。

“守門人”的出現

“少數幾家公司意識到,控制數據中心並擁有大規模服務器基礎設施能帶來巨大的競爭優勢。”

從家中運行自己的服務器的複雜性和成本,加上NAT和防火牆等技術壁壘,意味著越來越少的個人能夠作為真正的點對點參與者。

換句話說,這種環境實際上促使互聯網走向了少數集中化巨頭的方向。

到了2000年代早期,少數公司意識到,控制數據中心和大規模服務器基礎設施為它們提供了巨大的競爭優勢。

它們能夠提供比網絡上隨機點更快、更可靠、更方便的服務。

這種趨勢在2000年代末達到了極致。

來源:datareportal.com

像Google這樣的搜索引擎、Amazon這樣的大型平臺、Facebook這樣的社交媒體巨頭,以及內容分發網絡(CDN)都建立了能夠以前所未有的速度和規模交付內容和應用的龐大基礎設施。

這些大公司還利用了數據與算法的“良性循環”。

它們吸引的用戶越多,收集的數據也就越多,從而能夠優化產品、個性化體驗以及更準確地投放廣告。這使它們的服務更具吸引力,吸引更多用戶和收入。

隨後,互聯網的收入模式逐漸轉向了高度依賴於目標廣告的模式。

隨著時間推移,這種反饋循環進一步集中了權力,因為小型競爭對手難以匹敵大公司在基礎設施投資和數據上的優勢。

原本可以從個人服務器或本地數據中心運行的基礎設施逐漸遷移到雲端。

像Amazon(AWS)、Microsoft(Azure)和Google Cloud這樣的巨頭如今承載了互聯網的大部分骨幹。這一轉變的發生是因為運行大規模、安全可靠的基礎設施變得如此複雜且資本密集,以至於只有少數公司能夠高效完成。

創業公司甚至一些成熟的企業發現,依賴這些大型雲服務提供商更便宜、更簡單。

內容分發網絡(如Cloudflare或Akamai)和DNS解析服務也逐漸集中到少數大公司手中。

這些託管解決方案的複雜性和成本優勢使得組織缺乏“自己動手”構建基礎設施的理由。

漸漸地,小型ISP、獨立託管和本地化路由等去中心化的支柱被一種依賴少數幾個主要中介的模式所取代。

後果:權力集中在少數人手中

“大型企業最初並非出於惡意,而是為了提升便利性、性能和盈利能力。

然而,這正是早期網絡架構設計選擇的自然結果。”

隨著互聯網的發展和集中化,權力和控制逐漸向少數幾家巨頭傾斜。

這些大型平臺不僅能設定服務條款,還能決定用戶看到或發佈什麼內容,以及如何使用或出售用戶數據。如果用戶不滿這些規則,他們幾乎別無選擇。

久而久之,這些平臺的推薦算法和內容政策逐漸成為公共話語的實際仲裁者。

諷刺的是,最初作為開放、去中心化網絡誕生的互聯網,如今反而成為少數公司把控信息流的工具。

這些企業在某些方面的影響力甚至可與政府媲美:它們可以操控公共輿論、影響商業活動,甚至左右整個開發者生態系統的運行規則。

曾經致力於實現自由連接的網絡,現在卻圍繞著這些企業運轉,顯著改變了在線體驗。

這並非是為了集中權力的某種宏大計劃,也不是源於某個“錯誤的轉折點”。

大型玩家最初並非懷有惡意;他們只是為了方便、性能和利潤進行優化。

這是早期網絡架構設計選擇的自然結果。

這些選擇並未預見到一個更廣泛、以商業為驅動的受眾如何使用系統,並將其推向初始設計參數之外。

隨著時間的推移,這些選擇累積成一個由少數公司主導的系統。

去中心化行業正在重蹈覆轍

通向中心化的道路鋪滿了“臨時”解決方案

“集中化往往並非惡意行為的結果,而是試圖修復系統問題時做出的權宜之計。”

與早期互聯網從去中心化走向集中化的歷史相似,如今的區塊鏈和所謂的“去中心化”技術也在面臨同樣的命運。

以太坊擴展性問題最能說明這一點。

高昂的費用和緩慢的吞吐量推動開發者採用 Layer-2 (L2) 解決方案:這些 rollup 將交易聚合到鏈下處理,然後在以太坊上結算。理論上,這些 L2 應該保留以太坊的無信任特性。

實際上,許多依賴於一個單一的“排序器”(一個由某家公司運營的集中式服務器,用於排序交易)。

目前,某個特定的 L2 解決方案擁有最多的活動量和總鎖定價值,但同時也是最集中的。

它的宣傳是去中心化“某天會到來”,但這話我們以前聽過。

隨著時間推移,這些“臨時”解決方案往往會變成永久的。未來的分層方法可能會出現類似模式;有些甚至可能連去中心化的承諾都懶得給出。

例如,“社交登錄”看起來很方便:它讓人們無需處理私鑰或複雜界面就能輕鬆開始使用服務。但如果這些登錄依賴於一個集中化的組件,你再次將信任交給了一家公司。

因此,當我們構建 zkLogin 時,我們選擇以無信任的方式設計並集成它。雖然過程艱難,但我們不能為了方便而妥協,允許集中化。

類似的模式也出現在 NFT 生態系統中。

一個單一的主導市場成為二級交易的主要場所,捕獲了大部分交易量,並事實上成為了默認平臺。

不久前,這個平臺決定停止在二級銷售中強制執行版稅支付。

確實,這增加了交易量,但卻損害了依賴這些版稅作為關鍵收入來源的創作者。

這清楚地展示了當集中化平臺可以隨時修改規則時會產生的後果。

它們的主導地位還延伸到交易之外,因為許多項目也依賴於它們的 API 和基礎設施。

當這個集中化平臺出現宕機時,整個生態系統都受到了影響,暴露出已經形成的深度依賴。

但為什麼這種情況總是不斷髮生呢?

因為用戶希望快速、便宜和簡單的體驗。而開發者在壓力下,往往轉向熟悉且可靠的解決方案。這些選擇確實更簡單、更快,但也可能引入削弱去中心化的控制點。

這些步驟沒有哪個一開始是為了壟斷而設計的。它們只是對技術和市場挑戰的實際迴應。

但隨著時間推移,這些“權宜之計”會嵌入系統的 DNA 中,創造出一個由少數玩家掌控關鍵點的結構。

這就是為什麼這些系統必須從一開始就為開發者設計,而不僅僅是為消費者設計。

為建設者設計,而不僅僅是消費者

“如果問消費者想要什麼,他們可能只會說‘一匹更快的馬’。” ——亨利·福特

大多數人只想要現有事物的改進版。

但如果我們總是追逐這些短期改進,結果可能是構建出一個表面去中心化但實質被少數機構控制的系統。

要想避免今天“數字巨頭”主導的情況重演,我們需要把注意力轉向未來的創新者——建設者,而不僅僅是消費者。

這就是為什麼我常告訴團隊,消費者會追求“更快的馬”,而建設者則想象“汽車”。

通過為開發者提供強大的工具和模塊,我們可以打造無需為了便利而犧牲去中心化的平臺。這樣的系統能夠避免單一實體的壟斷,確保系統收益公平分配。

因此,真正去中心化的系統需要從設計之初就植入支持去中心化的理念,即使它們將來要擴展到互聯網級別。

技術債務與設計債務的差別

“技術債務可以通過修復代碼來解決,但設計債務往往需要從頭開始。”

從我參與構建億級用戶系統的經驗中,我明白一旦一個系統變得至關重要,就很難徹底重建而不造成巨大破壞。

當數百萬用戶依賴於你係統中的某些核心邏輯時,任何重大架構調整都可能打破商業模式,甚至損害整個社區的信任。

這就是“設計債務”的最嚴重表現。

設計債務不僅是代碼優化問題,而是網絡架構中對信任、權力和價值流向的核心設計選擇。

早期區塊鏈行業曾把“擴展性三難困境”(去中心化、安全性與可擴展性無法兼得)當作天經地義。

人們在這個假設之上構建,認為它就像重力一樣不可改變。

但這一限制並非天生,而是最初設計架構的缺陷:龐大的全球共享狀態和僵化的數據模型,讓並行化和模塊化擴展無法實現。

唯一的前進方式是將所有交易捆綁在一起,迫使每個參與者無論他們在做什麼都必須爭奪同樣有限的資源。結果是什麼?在需求激增時,區塊空間的低效拍賣抬高了成本,同時未能將擁堵隔離到實際發生的位置。

在這種情況下,增加層級(如依賴於中心化排序器的 L2 或依賴於中心化存儲的壓縮資產)只是掩蓋了問題。

每次修補短期問題的嘗試,往往增加了複雜性和更多的中心化控制點,使系統進一步偏離原本的願景。

這就是設計債務如何累積成一種“技術重力”,將一切拉向中心化。

即使那些從未打算成為“守門人”的系統,最終也會因為其基本架構的要求而強化層級結構。一旦發生這種情況,返回真正去中心化和無信任狀態的道路就被既得利益和基礎設施的慣性所阻擋。

教訓很明確:必須從一開始就正確設計架構。

這意味著選擇不會將一切捆綁到單一全球狀態的數據模型,使用無需信任中介就能驗證的存儲解決方案,並選擇不依賴於少數強大中介的網絡層。

這關乎從第一天起重新想象整個技術堆棧。

從第一天起打好基礎

“唯一避免設計債務的方法就是從一開始就不要讓它產生。”

當我們談論創建“無法作惡”的基礎設施時,其核心是從最初就做出正確的架構決策。

因此,在設計 Sui 時,我們從第一步就將這些核心原則融入系統中。

這樣,開發者可以更輕鬆地構建可擴展、安全且易用的應用,而無需依賴中心化的妥協方案。

考慮編程模型本身:

Sui 的面向對象的編程模型有意脫離了許多區塊鏈所採用的賬戶模型範式。

面向對象的編程模型

Sui 設計理念的核心是面向對象的編程模型。

在一個 Web2 開發者習慣於用文件、記錄和資產等對象思維的世界中,將一切簡化為單一的賬戶模型沒有意義。

這樣做迫使開發者採用不自然的思維模式,增加了容易出錯的複雜性。

面向對象的編程模型與 Web2 工程師的思維方式自然一致。

對象作為一等公民,使得表示資產、定義規則變得簡單,同時避免了常見的漏洞(例如重入漏洞),無需複雜的樣板代碼。

這種熟悉的模型大大減少了概念上的負擔以及常見的陷阱,例如重入問題。開發者無需通過編寫樣板檢查代碼或複雜的防護措施來防止漏洞,而是依靠 Move 虛擬機在運行時層面上確保安全。

因此,代碼更加易讀、安全,也更容易理解。

這是從 Web2 面向對象的思維模式到 Web3 去信任環境的直接橋樑,這得益於從一開始就基於正確的假設設計。

通過設計擴展,而非補丁修復

但一個偉大的編程模型,如果在負載下崩潰,就毫無意義。

從一開始,Sui 就是為處理現實世界的負載而構建的。它被設計為在保持同步的原子組合性的同時水平擴展。

系統的對象模型使 Sui 對每筆交易所觸及的狀態部分有精細的理解,從而能夠實現大規模的並行執行。這與基於 EVM 的系統形成了鮮明對比,後者必須鎖定整個全局狀態。這不僅減慢了速度,還鼓勵中心化解決方案來分流交易量。

在 Sui 中,每個對象本質上都是它自己的分片。如果需要更多容量,只需添加更多計算能力以應對負載。

Pilotfish原型: https://blog.sui.io/pilotfish-execution-scalability-blockchain/

開發者無需擔心分片邏輯、跨域橋接或拼湊基礎設施以實現擴展。

隨著網絡的增長,系統可以處理更多的流量,但如何確保公平的資源分配?

如果某個熱門資產或 dApp 壟斷了狀態更新市場,就可能推高成本並降低其他用戶的體驗。

本地費用市場不再依賴單一的全球區塊空間拍賣(其中一個熱門應用程序可以抬高每個人的價格),而是讓系統以更精細的粒度對資源進行定價。

每個“對象”或分片可以擁有自己的費用市場,確保某一區域的擁堵不會蔓延並影響網絡的其他部分。

這些都被嵌入平臺的基礎設計中,確保即使需求增長,系統也不會退化為傳統的守門人模式和封閉生態。

為去中心化而設計還意味著將可驗證性內置於存儲和通信層中。

如果數據存儲依賴於單一的信任方,那麼你就回到了原點。你需要存儲解決方案,使任何人都能驗證數據完整性,而無需依賴中間人。

去中心化存儲:告別中心化主機

真正的去中心化應用不能依賴單一的雲服務提供商或集中式數據庫。

Walrus 提供了一個功能強大且可驗證的去中心化存儲層,性能堪比 AWS 和 Google Cloud 等主流中心化服務。

與其事後彌補數據驗證問題,Walrus 將數據可驗證性作為其核心設計的一部分。

通過集成一個防篡改且本質上可驗證的存儲層,Walrus 確保開發者能夠搭建網站、託管數據、開發完全去中心化的應用,避免走回中心化的老路。

簡單來說,Walrus 延續了“從根本上正確”的設計理念,將這一原則從執行層擴展到了存儲層,確保每一層的完整性。

現在,設計去中心化不僅意味著要在共識層或執行層上實現,還必須擴展到網絡本身。

網絡層不應依賴於少數強大的ISP或路由服務,這同樣是一種中心化。

一個為去中心化打造的網絡架構

在 Web3 中,網絡層往往是被忽視的一環。

傳統互聯網的路由由少數 ISP 控制,這種集中化帶來了潛在的瓶頸和安全隱患。

SCION 是一種全新的網絡協議,它打破了這一現狀,使數據路由更加安全、可靠,並減少了對集中化控制的依賴。

這種協議採用了安全、多路徑、跨域的路由設計,可以與現有互聯網並行運行。它從根本上重新定義了數據在網絡中的流動方式,在設計之初便將安全性、控制權和高效性能融入其中。

將 SCION 集成到 Sui 中,確保網絡層不會成為單點故障或集中控制的來源。

沒有任何機構能夠單方面控制數據流,用戶也無需擔心數據路由會被操控或壟斷。

通過在數據模型、存儲和網絡等各層級嵌入可驗證性和無權限特性,極大減少了集中控制的可能性。

這不是事後補充的去中心化,而是從一開始就嵌入到系統的基礎中。

這種簡單性減少了複雜性,同時防止了“方便但集中的權宜之計”的使用。最重要的是,從一開始就將基礎打好意味著不必依賴“以後再修復”的心態。

健全設計的重要性

“去中心化不是節點數量的比拼,而是通過架構設計防止權力過度集中。”

我們探討的一切要點很簡單:如果你想要一個“無法作惡”的系統,就必須從正確的架構開始。

如果從一開始就基於錯誤的假設構建,再多的代碼或聰明的修補都無濟於事。

獎勵守門人的架構、迫使每個參與者爭奪相同稀缺資源的數據模型,以及圍繞集中式樞紐設計的網絡層——最終你會滑向相同的控制和層級模式。

這就是為什麼架構基礎如此重要。

去中心化不僅僅是計算節點的數量。真正的去中心化意味著在根層設計,確保信任、公平和可驗證性無法被繞過。

這意味著構建一個系統,既不能讓少數巨鯨,也不能讓資源豐富的公司悄悄地傾斜競爭環境。這是關於確保每個參與者都有公平的機會,沒有任何一個阻塞點或細微的設計決定會演變成失控的集中化。

Sui 是一個例子,展示了當你從第一天就以這些原則設計時會發生什麼,而不是事後試圖調整。

當整個技術棧,從編程模型到共識層,再從用戶引導到數據可用性和網絡層,都強化了開放性和中立性時,你創造了一個構建者和用戶在平等條件下蓬勃發展的環境。

通過從第一原則出發,在每一層執行去中心化,你可以創建一個無論多大規模都能保持其初衷的基礎設施。

從一開始就構建得當,你無需承諾未來的修復或權宜之計。

你將擁有一個本質上公正、彈性強,並能作為下一代數字體驗基礎的網絡。

免責聲明:

  1. 本文轉載自【X】,版權歸原作者所有【@EvanWeb3】。若對本次轉載有異議,請聯繫 Gate Learn 團隊,他們會及時處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明,否則禁止複製、分發或抄襲翻譯文章。
Start Now
Sign up and get a
$100
Voucher!