萬字長文深度剖析：構建去中心化網絡有哪些具體挑戰？_WEB

本文轉自公號：老雅痞

作者：Eric Rescorla

最近，人們對通常被稱為去中心化網絡（dWeb）的東西很感興趣（盡管現在我們聽到更多的是Web3這個詞）。勾勒出這些術語之間的確切區別（假設這是有可能的）不在這篇文章的討論范圍之內（盡管Web3似乎在某種程度上涉及到區塊鏈），但這里的共同點似乎是用一個不太中心化的網絡生態系統來取代現有的相當中心化的網絡生態系統。這篇文章探討了實際建立這樣一個系統所面臨的挑戰。

面向用戶的主要內容分發平臺相對較少（Google、YouTube、Facebook、Twitter、TikTok等），它們顯然對網民傳播信息的能力具有巨大的影響力。

即使你愿意放棄在這些內容平臺上發布信息，建立任何大規模系統的最簡單方法（幾乎是唯一經濟的方法，除非你的資金非常充足）是在相對較少的基礎設施供應商之一中運行，如亞馬遜AWS、谷歌云平臺、Cloudflare、Fastly等，他們已經擁有高度可擴展的地理分布系統。

在這種情況下，去中心化可以意味著從建立那些以不太中心化的方式運作的特定內容平臺的類似物（如Mastodon或Diaspora）到在IPFS或Beaker這樣的點對點平臺上重建整個網絡的結構。自然，在第二種情況下，你也會想讓這些內容平臺有可能只是更好重現！使用一個大部分或完全的點對點系統至少不應該要求在某個地方有一堆大的服務器來使這一切運作。這第二個更加雄心勃勃的項目是這篇文章的主題。

這里要做的一個重要區分是分布式系統（通常也稱為聯合式）和去中心化系統（通常稱為點對點）之間的區別。舉個例子，網絡是一個分布式系統：它由許多不同的網站組成，由不同的實體運營，但這些網站是在服務器上運行的，運營一個網站需要自己運行一個服務器或將其外包給其他人。這些服務器必須準備好處理所有用戶的負載，這意味著它們必須在某個地方有大量的帶寬，當更多的用戶試圖連接時，可以優雅地擴展，等等。

相比之下，BitTorrent是一個去中心化的系統：它使用BitTorrent用戶本身的資源來提供數據，這意味著你不需要一個巨大的服務器來發布數據到BitTorrent網絡，即使有很多人想下載它。即使在帶寬便宜的世界里，這也有一些明顯的操作優勢，但特別是如果你想發布一些別人不愿意發布的東西，也許是因為政府的審查制度或更經常的版權原因。如果你運行一個服務器，你很難隱瞞有一百萬人剛剛連接下載了某部電影，你應該擔心版權警察來找你，但如果你只是把你的拷貝發布到BitTorrent網絡中，要想知道是誰發布的就難多了，特別是如果其他50人也這樣做的話。

請注意，有可能出現基本上是去中心化的混合系統（但它卻依賴于中心化的組件）。例如，在點對點系統中，新的對等節點通常需要連接到一些“引入服務器”來幫助他們加入網絡；這些服務器需要易于查找，并且要做到這一點，一種（盡管不是唯一的）方法就是中心化操作它們。

從歷史上看，點對點系統已經在相對有限的領域進行了部署，主要是那些與上述抵制審查的用例之外的某種部署有關。然而，人們對更廣泛的用例當然有很多興趣，包括取代網絡的大部分內容。這是一個非常困難的問題，部分原因是這種系統在本質上不如中心化或聯合式的系統有效和靈活。這篇文章探討了建立這樣一個系統所面臨的挑戰。這并不是說以更多的聯盟方式建立像Twitter或Facebook這樣的系統就沒有挑戰，但問題的規模不同（也許這是另一篇文章的主題）。

點對點架構與客戶/服務器架構的對比

與點對點架構相反的是客戶/服務器架構，也就是說，在一個系統中，各元素扮演著不對稱的角色，其中一個元素（通常屬于用戶）是 “客戶”，另一個元素（通常是與某個組織相關的某種共享資源）是 “服務器”。例如，這就是網絡的工作方式，客戶端是瀏覽器。相比之下，點對點系統被認為是對稱的。

RSS3為MetaMask開發Web3 Profile Card功能:10月30日消息，MetaMask發推介紹由RSS3開發的Web3 Profile Card功能，它能自動檢測Twitter賬戶的ENS，使用時將鼠標懸停在用戶頭像一角的Mask圖標上，可查看關注者的Web3活動。[2022/10/30 11:57:36]

然而，在實踐中，這些界限可能是相當模糊的。例如，常見的系統是在客戶端和服務器架構之間以及服務器之間使用相同的協議，第二種模式更像是典型的 “點對點 “配置。例如，郵件客戶使用SMTP發送電子郵件，但郵件服務器也使用SMTP相互發送電子郵件，發件人承擔 “客戶”的角色；顯然在這種情況下，每個 “服務器 “既是客戶又是服務器，取決于郵件流向的方向。即使在名義上是點對點的系統中，也經常使用為客戶/服務器應用而設計的協議（如TLS），在這種情況下，即使上述應用是對稱的，節點也可能為這些協議的目的承擔客戶/服務器角色。

我們都（希望）知道像網絡這樣的客戶/服務器發布系統是如何工作的，但點對點（以下簡稱P2P）發布系統是如何工作的呢？讓我們從討論最簡單的情況開始，也就是發布不透明的二進制資源（文檔、電影，等等）。本節試圖描述這樣一個系統的足夠的基礎知識，以便使本篇文章的其余部分有意義。

在客戶端/服務器系統中，要發布的資源存儲在服務器上，但在P2P系統中，沒有服務器，所以資源存儲在 “網絡中”。這在操作上的意思是，它存儲在碰巧此時在線的用戶的某個子集的電腦上。為了使其發揮作用，我們需要一套規則（即協議）來描述哪些端點存儲了特定的內容，以及當你想檢索它時如何找到它們。一個常見的設計是所謂的分布式哈希表，這基本上很抽象，其中每個資源都有一個 “鍵”（即一個地址），用來引用它，還有一個 “值”，是其實際內容。密鑰決定了哪個（些）節點負責存儲該值，并被其他節點用來存儲和/或檢索它。

作為一個直觀的疑問，請考慮下面的DHT系統。這是Chord（在計算中，Chord是一種點對點分布式哈希表的協議和算法。分布式哈希表通過將鍵分配給不同的計算機稱為“節點”來存儲鍵值對；一個節點將存儲它負責的所有鍵的值。Chord 指定如何將鍵分配給節點，以及節點如何通過首先定位負責該鍵的節點來發現給定鍵的值。Chord 是與CAN、Tapestry和Pastry一起的四種原始分布式哈希表協議之一）的過度簡化版本，它是最早的 DHT 之一，所以我們稱它為“Note”。注意，系統中的每個節點都有一個隨機生成的標識符，它是一個來自0至 2∧256 -1的數字（抱歉讀者們，我們用了LaTeX 表示法）。通常我們認為這些數字被組織成了一個環，ids 是順時針分配的，因此節點2∧256 -1 就在（之前）節點0旁邊，如下圖所示：

網絡中的每個節點（”環”）都保持著一組與環中其他節點的連接（箭頭的顏色是根據保持連接的節點而定）。我不會在這里詳細介紹這些算法，只想說讓這些算法有效地工作是制作DHT的科學的重要內容。在注釋中，我們只假設每個節點都與下一個節點（即具有下一個最高身份的節點）和其他更遠的節點有一個連接，如上圖所示。

為了與具有 id 的節點通信?, 一個節點向它所連接的節點發送一條消息?，并帶有 id?最接近但不大于,（即，如果你順時針繞圈，你連接到的節點不會位于它們之間）。節點?做同樣的事情。當你最終到達一個直接連接到的節點?時，它傳遞消息。例如，如果節點0想向節點 c發送一條消息，它將把它發送給b，然后 b 將它發送給c。當c想要回復時，它將它發送給連接到節點0的節點e ，因此直接發送它。請注意，這意味著請求/響應對需要圍繞環進行整個行程。

擁有1300萬粉絲的社交媒體網紅Scuba Jake賬號被黑客竊取，粉絲被盜金額已超1.01 BTC:金色財經報道，擁有1300萬粉絲的社交媒體網紅Scuba Jake的視頻賬號被黑客竊取，而且播放了BTC和ETH欺詐信息的虛假贈品活動，數據顯示已有粉絲上當，目前黑客已非法獲得了1.01 BTC，約合2.1萬美元，同時還將其視頻頻道名稱改為“MicroStargey US”，冒充對加密貨幣友好的美國商業情報公司 MicroStrategy。（Finbold）[2022/9/11 13:22:11]

到目前為止，我們只有一個通信系統，但是（相對）容易把它變成一個存儲系統：我們在與節點標識符相同的命名空間中為每條數據分配一個地址，并且每個節點負責存儲任何數據（位于它和前一個節點之間的地址）。因此，例如，在下圖中，節點c將負責存儲地址為k的資源，節點e將負責存儲地址為l的資源。

如果節點a想要存儲地址為k的值，它會向c 發送一條消息，要求存儲它。同樣，如果節點d想要檢索它，它會向c發送一條消息。

當然，這里有幾個明顯的問題。首先，如果節點c從網絡上掉下來會怎樣？畢竟，它是某人的個人電腦，所以他們隨時都可能關閉它。這個問題的答案自然是將數據復制到其他一些節點上，這樣一來，這些節點同時下線的概率就會適當降低。精確的復制策略也是一個復雜的話題，根據DHT的不同而不同，我們不需要在這里討論它。

第二，如果某個值既大又流行怎么辦？在這種情況下，存儲它的節點可能突然要一次性傳輸大量的數據。這很容易使某人的鏈接完全飽和，即使他們有一個快速的互聯網連接。唯一真正的解決辦法是分配負載，你可以通過兩種方式做到。首先，你可以將資源分塊（例如，將你的電影分成5分鐘的小塊），然后將每個分塊存儲在不同的地址下；這樣做的影響是，不同的節點將負責發送每個小塊，因此它們的帶寬份額也相應地減少。你也可以嘗試讓更多的節點負責流行的內容，這也會分散負載。

最后，如果每條信息都要穿越幾個節點才能被送達，這就會增加網絡的總負載，與路徑長度（節點數量）成正比，同時也會因為延遲而降低性能。處理這個問題的方法之一是讓兩個通信節點建立一個直接的連接來進行大量的數據傳輸，并使用DHT來取得聯系，這樣他們就可以做到這一點。這就大大降低了整體負荷。

在前面的描述中，我已經交待了事物的地址是如何得出的。

一種常見的設計是通過對象的內容來計算地址，例如通過散列。這就是所謂的內容可尋址存儲（CAS），在很多情況下很方便，因為它不需要DHT中的任何額外內容完整性。如果你知道該對象的哈希值，你就可以檢索它，如果哈希值出現錯誤，你就知道檢索它時出現了問題。

當然，考慮到你需要對象來計算它的哈希值，這種設計意味著你需要一些服務來把你知道名字的對象（例如，”John Wick”）映射到它們的哈希值上，所以現在我們要么有一個中心化的服務來做這個，要么我們需要建立一個點對點版本的服務，我們又回到了我們開始的地方。

另一種常見的方法是擁有從加密密鑰衍生出來的名字。例如，我們可以說，我的所有數據都存儲在我的公鑰的哈希值上（同樣，也許有一些合適的分片系統）。當數據被存儲時，我們會要求它被簽名，節點會丟棄那些簽名沒有被驗證的存儲值。這有很多優點，但其中一個關鍵的優點是，你可以讓給定地址的數據發生變化，因為地址與加密密鑰而不是內容相聯系。例如，假設被存儲的是我的網站；我可能想改變它而不想發布一個新的地址。有了與密鑰綁定的地址，這是可能的。

今日恐慌與貪婪指數為31，恐慌程度有所回升:金色財經消息，今日恐慌與貪婪指數為31（昨日為42），恐慌程度較昨日有所回升，等級仍為恐慌。注：恐慌指數閾值為0-100，包含指標：波動性（25%）＋市場交易量（25%）＋社交媒體熱度（15%）＋市場調查（15%）＋比特幣在整個市場中的比例（10%）＋谷歌熱詞分析（10%）。[2022/8/10 12:14:58]

顯然，加密鑰匙也不是很好的標識符，因為它們很難被記住，但據推測，你會在上面設置某種去中心化的命名層，例如基于區塊鏈的命名層。

任何真正的系統都需要某種方式來確保內容的完整性。與網絡不同，僅僅建立一個與存儲節點的TLS連接是不夠的，因為那只是某人的計算機，它可能會說謊（盡管你仍然可能想出于隱私原因而說謊）。相反，每個對象需要以某種方式進行完整性保護，要么讓它的地址成為它的哈希值，要么通過數字簽名。

除了內容的完整性之外，這里還有很多地方可能出錯。例如，如果負責的節點聲稱一個給定的對象（或一個你試圖路由到的節點）不存在，會發生什么？或者，如果一組節點試圖通過DDoS攻擊使網絡流量飽和怎么辦？你如何處理人們試圖存儲或檢索超過其 “公平份額”（不管那是什么）的數據。人們談論了各種方法來解決這些問題，但我們對DHT的操作經驗比我們對網絡的操作經驗規模要小，而且對故障的容忍度要高得多（如果人們突然無法從BitTorrent下載《冰雪奇緣》，迪士尼就不會損失很多錢），所以不清楚它們是否能在規模上真正安全。

現在我們有了一種存儲數據并再次找到它的方法，我們有了一個開始，可以想象如何建立一個去中心化的網絡版本。就像我們在研究網絡如何工作時一樣，讓我們從發布靜態文件開始。

回顧一下URI的結構：

我們需要做的是把這個結構映射到我們的P2P存儲系統的資源上。因此，我們最終可能會得到一個像下面這樣的URL：

起源

這個系統的一個重要的安全要求是，與不同機構相關的數據有不同的起源（背景見這里：https://educatedguesswork.org/posts/web-security-model-origin/）。如果多個用戶發布的數據有不同的起源，那么他們可以通過瀏覽器互相攻擊，這是一個明顯的問題。

note: 一開始就告訴我們需要使用 Note 而不是通過 HTTP 來檢索數據。在中間部分，我們沒有一個“host”字段告訴我們從哪里檢索普通 HTTPS URI 中的內容，而是有一個“authority”字段，它告訴我們將使用其密鑰的用戶的身份對 URL 的數據進行簽名。如上所述，我假設我們有一些方法可以將用戶友好的身份映射到鍵；有些系統沒有，這似乎對用戶很不利，但如果你愿意，可以隨意將權限視為密鑰哈希。

資源本身被存儲在一個由Hash(URL)給出的地址上（這是對我上面描述的一個小而簡單的改變），并且如上所述，由與權威相關的密鑰簽名。

如果你首先假設P2P系統的存在，這一切都很簡單。為了發布一些東西，我在DHT中的URL地址處做了一個存儲，并用我的密鑰簽名。然后我就可以把這個URL交給人們，他們可以通過計算地址，然后驗證簽名的資源，從DHT中檢索數據。請注意，由于地址是從URL而不是從內容中計算出來的，因此只需做一個新的存儲，就可以就地更新。

2022胡潤中國元宇宙潛力企業榜：阿里巴巴、愛奇藝、百度位居前三:6月15日消息，胡潤研究院今日于廣州南沙發布《2022胡潤中國元宇宙潛力企業榜》列出了元宇宙領域最具發展潛力的中國企業200強，分為四個階段：最具潛力20強、50強、100強和200強。另外還有“未來之星企業”。這是胡潤研究院首次發布該榜單。阿里巴巴、愛奇藝、百度位居前三。（胡潤百富）[2022/6/15 4:28:39]

退一步說，這確實有點像我上面描述的價值主張：任何人都可以將網站發布到網絡上，而不需要有一屋子的電腦，也不需要支付亞馬遜/谷歌/Fastly等。因此，如果你不仔細看，它似乎是完成了任務，很容易理解這種熱情。不幸的是，這個系統也有一些相當嚴重的缺點。

性能（這里指的是頁面加載的時間）是網絡瀏覽器和服務器的一個主要考慮因素。對網絡性能最重要的是檢索每個資源所需的時間。這與視頻會議或游戲不同，在視頻會議或游戲中，延遲（你的數據包到達對方的時間）或抖動（延遲的變化）真的很重要。在網絡中，這主要是指下載速度。

為了理解從客戶/服務器到點對點的轉變對性能的影響，有必要了解一下網絡和數據傳輸的工作原理。互聯網是一個分組交換的網絡，這意味著它傳輸的是1000字節左右的單獨尋址的信息。由于網絡資源通常大于1K，客戶和服務器通過建立連接來傳輸數據，連接是雙方的持久聯系，它將一組數據包映射成每一方都可以讀寫的數據流的樣子。發送方將文件分解成數據包并發送，接收方負責在收到后重新組裝。歷史上這是由TCP完成的，盡管現在看到越來越多的人使用QUIC，它的操作原理類似，至少在我們需要在這里討論的層面上是這樣的。

下圖顯示了一個使用TCP和TLS 1.3安全的HTTPS連接的開始：

增加一個連接上的HTTP請求的數量

當HTTP最初被設計時，你只能在一個連接上有一個請求。由于我在這里描述的原因，這是非常低效的，而且在很大程度上由于Jeff Mogul的工作，增加了一個功能，允許在同一個連接上發出多個請求。不幸的是，這些請求只能連續發出，這就造成了一個新的瓶頸。作為回應，瀏覽器開始在同一個網站上創建多個并行連接，這讓他們可以一次發出多個請求（由于TCP動態，有時也會搶占更大一部分的可用帶寬）。2015年，HTTP/2增加了在同一TCP連接上復用多個請求的能力，響應交錯進行，但仍有一個問題，即響應A的數據包丟失后，其他所有的響應都會停滯（這種特性稱為線頭阻塞），這在多個連接之間不會發生。最后，2021年發布的QUIC增加了多路復用功能，即使在單一的QUIC連接上也沒有線頭阻塞。

正如你所看到的，前兩次往返完全是為了建立連接而消耗的。在兩次往返之后，客戶端終于可以請求資源了，在最終獲得任何數據之前又是一次往返。根據網絡細節，每次往返的時間可能從幾毫秒到200毫秒不等，因此，在瀏覽器看到第一個字節的數據之前，可能需要600毫秒。這是一個大問題，在過去的幾年里，IETF已經花費了相當大的努力來減少網絡連接建立時間的往返次數（使用TLS 1.3和QUIC）。

一旦建立了連接，你就需要傳遞數據，這并不是一下子就能完成的。正如我之前提到的，它被分解成一個個數據包流，隨著時間的推移被發送到另一邊。這就是事情變得有點棘手的地方，因為發送方和接收方都不知道網絡的容量（即，它能承載多少比特/秒），如果發送方試圖發送得太快，那么額外的數據包就會被丟棄。為了避免這種情況，TCP（或QUIC）試圖通過逐步加快發送速度來計算出一個安全的發送速率，直到出現擁堵的跡象（例如，數據包丟失或延遲），然后再退縮。重要的是，這意味著最初你不會使用網絡的全部容量，直到連接變暖（這被稱為 “慢速啟動”），所以數據傳輸率往往會隨著時間的推移越來越快，直到達到穩定狀態。

V神：以太坊2.0最早可能于8月進行合并:5月20日消息，以太坊創始人Vitalik Buterin在2022年5月20日舉行的ETH Shanghai會議上表示，目前以太坊2.0正在進行最后的網絡測試，如果一切問題都被解決，合并最早可能在8月進行，如果出現其他狀況，也有可能在9月或10月發生。[2022/5/20 3:29:45]

所有這一切的含義是，新的連接是昂貴的，你想通過一個連接發送盡可能多的數據。事實上，在過去的30年里，HTTP的大部分發展都是在尋找方法，使單個網頁使用越來越少的連接。

這就把我們帶到了點對點系統的性能問題上。正如我上面提到的，如果你想移動大量的數據，你真的想讓客戶端直接連接到存儲數據的節點上。這帶來了幾個問題。

首先，我們有通過P2P網絡發送第一條信息的延遲，然后再返回。這通常會比直接信息慢，因為它不能采取直接路徑。然后，一般來說，不可能簡單地直接與其他人的個人電腦建立連接，因為他們通常在NAT和防火墻等網絡元素后面。所謂的 “打洞 “協議，如ICE，在許多情況下允許你建立直接連接，但它們會引入額外的延遲（至少一個往返，但往往更多）。一旦完成，你還必須建立一個加密連接，所以我們說的是額外的2次往返的地方。更糟糕的是，在很多情況下，存儲節點在拓撲上離你很遠，因此有很長的往返時間；大網站和CDN故意把存在點設在靠近用戶的地方，但這對P2P系統來說是個更難的問題。當然，即使連接已經建立，我們仍然處于緩慢啟動狀態。

這對網站來說都有點不合適，因為網站往往由大量的小文件組成。例如，谷歌的主頁通常被設計成輕量級的，目前由36個獨立的資源組成，其中最大的是811KB。如果這些資源中的每一個都單獨存儲在DHT中，那么你將會經常運行協議的低效設置階段，而幾乎不會進入高效的數據傳輸階段。這與HTTP和QUIC形成鮮明對比，它們試圖保持與服務器的連接開放，從而可以攤薄啟動階段的費用。

顯然，把網站上的一些資源捆綁到一個單一的對象中是可能的，但這也有其他問題。首先，這對瀏覽器的緩存很不利，因為這些對象中有許多會在后續的加載中被重復使用。其次，這使得與單個節點的連接成為下載過程中的限制性步驟，如果該節點（只是記得別人的電腦）沒有良好的網絡連接或暫時過載，這就很糟糕了。其結果是，我們有一個矛盾，即我們想盡量減少個人的獲取延遲，也就是通過一個單一的連接發送所有的東西，而我們想做的是為了避免單一元素的瓶頸，也就是像BitTorrent那樣一次從很多服務器上下載。

在像電影下載這樣的情況下，所有這些都不是問題，因為對象很大，所以總體吞吐量比延遲更重要。在這種情況下，你可以將你的連接并行化，并保持管道的完整。然而，這并不是網絡的情況，人們真正注意到的是頁面加載時間。據我所知，建立一個大型的P2P網絡，其加載時間的性能與網絡相當，這是一個大部分未解決的問題。

即使我們假設P2P網絡本身是安全的，即攻擊者無法破壞它，而且數據是經過簽名的，這個系統仍然有一些令人擔憂的特性。

在任何像網絡這樣的系統中，向客戶提供數據的節點會了解某個客戶對哪些數據感興趣，至少是客戶的IP地址水平。在目前的網絡中，這并不是一個理想的情況，因此有了像Tor、VPN、Private Relay等IP地址隱藏技術，但至少它在某種程度上僅限于你選擇與之互動的可識別實體（當然，網絡廣告中無處不在的跟蹤使情況相當糟糕）。

P2P系統的情況更糟糕：下載一個內容意味著聯系互聯網上或多或少的隨機計算機，告訴它你想要什么。正如我在上面指出的，你可以通過P2P網絡路由所有的流量（但它嚴重損害隱私），所以現實中你將與該節點共享你的IP地址。更糟糕的是，在大多數情況下，數據將被分散在多個節點上，這意味著很多不同的隨機人都會看到你的瀏覽行為。最后，在許多網絡中，節點有可能影響他們所負責的數據，在這種情況下，人們可以想象那些希望進行監視的實體試圖對特定種類的敏感數據負責，然后記錄誰來檢索它；事實上，這似乎已經在BitTorrent中發生了。

網絡上的大部分內容是向所有人開放的，但也有很常見的情況是，你想限制對某一數據的訪問。這可以是網站的數據，如《紐約時報》等網站的付費墻，也可以是用戶的數據，如Facebook或Gmail的數據。這些都是以明顯的方式實現的，即在服務器上有一個訪問控制列表，說明哪些用戶可以訪問每塊數據，并拒絕向未經授權的用戶提供數據。然而，這在P2P系統中是行不通的，因為沒有服務器來執行：數據只是存儲在人們的電腦上，即使網站發布了訪問控制規則，網站也不能相信存儲節點會遵守這些規則。它甚至可能被攻擊者所控制。

這個問題的傳統答案是在內容存儲到DHT之前對其進行加密。即使DHT中的數據是公開的，那也只是密碼文本。當內容是用戶的，并且他們不想與任何人分享時，這實際上是適度的工作，因為他們可以將其加密到他們知道的密鑰，然后只是將其存儲在DHT中。這甚至可以通過現有的API（如WebCrypto）來完成，而密鑰則存儲在用戶的計算機上。如果他們想與其他人分享，效果就會差很多——尤其是像Google Docs這樣的讀/寫應用程序，因為你需要對所有的訪問規則進行加密執行機制。在這方面已經有一些真正的工作，如SiRiUS和Tahoe-LAFS的加密文件系統，但這是一個復雜的問題，我不知道任何真正大規模的部署。

付費墻的問題實際上更難。例如，《紐約時報》可以對其所有內容進行加密，然后給每個訂閱者一個可以用來解密的密鑰，但是考慮到訂閱者的數量，而且只要有一個人泄露密鑰， 該密鑰泄露的可能性基本上是100%。 當然，人們也會分享《紐約時報》的密碼，但使這個問題更難的是，該密碼必須在《紐約時報》網站上使用，而且有可能檢測到不當行為，例如當20人使用同一個密碼。我不知道這里有什么真正好的純P2P解決方案。

訪問控制實際上是一個更普遍的問題的特例：許多網站（如果不是大多數的話）不僅僅是簡單地發布靜態內容，這些網站依賴于服務器端的處理，這在一個分散的系統中是很難復制的。

作為熱身，讓我們拿一個相對簡單的問題舉例，即我在網絡安全模型系列第二部分中描述的購物網站。實際上，這個網站有三個需要被復制的服務器端功能。

產品搜索

購物車維護

采購

其中第二和第三項功能實際上是相當直接的：購物車可以完全存儲在客戶端，或者，如上一節所述，由客戶端在P2P系統中自我加密存儲。購買這一塊可以通過某種加密貨幣來處理（盡管如果你想使用信用卡，事情就更復雜了）。然而，產品搜索就比較困難了。明顯的解決方案是在網絡中發布整個產品目錄，讓客戶下載，并在本地進行搜索。這顯然有一些相當不理想的性能后果：亞馬遜有海量的目錄數據，這些數據的變化非常頻繁復雜。

顯然，這在Web 2.0世界中的工作方式是，服務器只是運行計算并返回結果，在這一點上，你通常會聽到有人提出某種分布式計算系統，如Ethereum智能合約（盡管你可能不希望結果記錄在區塊鏈上）。在這種情況下，網站不是發布一個靜態資源，而是發布一個要執行的程序來返回結果（通常這些程序是用WebAssembly編寫的）。

除了明顯的問題，即這仍然需要執行程序的節點擁有所有的數據，最終用戶客戶端很難確定該節點是否正確執行了程序。即使在一個簡單的案例中，比如搜索匹配的記錄：如果這些記錄是簽名的，那么節點就不能替換他們自己的值，但他們有可能隱藏匹配的值。當然，有一些加密技術有可能使其證明計算是正確的，但它們還遠遠微不足道。所以，這并沒有一個真正偉大的解決方案。

一個購物網站實際上是一個相對簡單的案例，因為信息基本上在某些情況下是公開的，網站可能不希望他們的目錄是公開的，但有很多情況下，網站想用秘密信息進行計算。這里主要有兩種情況：

網站的秘密信息，例如Twitter的推薦算法是不公開的。

用戶的秘密信息，例如他們在約會軟件中 “向右滑動 “過的其他用戶，甚至只是用戶的個人資料細節。

在Web 2.0中，這種工作方式是，服務器知道秘密信息并將其用于計算，但不向用戶透露。但是，與搜索案例一樣，這并不容易移植到P2P案例中，因為將信息透露給隨機的人的個人電腦并不安全。

當然，有用于計算具有加密數據的特定功能的加密機制。例如，Private Set Intersection技術可以確定Alice和Bob是否都互相滑動，并且只告訴他們是否都這樣做了，但是它們很復雜，更重要的是特定于任務，因此你需要為每個應用程序提供解決方案，有時這意味著發明新的加密技術（要清楚，這遠非實現安全P2P約會系統所需的全部內容！）

這實際上是在 “受信任的 “服務器上進行的計算的加密替換的一個普遍問題。加密方法的積極一面是它們可以提供強大的安全保證，但消極的一面是，基本上每個新的計算任務都需要一些新的加密技術，這使得變化非常緩慢和昂貴。相比之下，如果你在服務器上做計算，那么改變你的計算只是一個編寫和加載到服務器上的問題。明顯的缺點是，人們必須信任服務器，但顯然很多人愿意這樣做。

有時用于解決此類功能問題的一個想法是擁有混合架構。例如，人們可能會想象通過P2P網絡提供目錄的靜態內容來實現購物網站，但必須擁有一個處理搜索并返回指向目錄相關部分的指針的服務器。你甚至可以加密每個單獨的目錄區塊，以便競爭對手很難看到你的整個目錄。你甚至可以想象建立一個約會網站！P2P和服務器技術的某種組合，用于確定您可以看到哪些配置文件以及與哪些配置文件匹配的邏輯在服務器上實現，但是（加密的）配置文件是分布式的P2P。

不過，在這一點上，你有相當大的服務器組件可以用在你的網站的關鍵路徑上，所以你主要是使用P2P網絡作為一種不是非常快的CDN（例如，見PeerCDN）。這就首先放棄了讓你的系統去中心化的大部分好處：你仍然有在某處托管你服務器的問題，這可能意味著一些云服務，在這一點上，為什么不為你的靜態內容直接使用CDN？同樣，如果你擔心審查制度，那么你需要擔心你的服務器被審查，這使得你的網站無法使用，即使P2P部分仍然有效。

我們很容易看到一個更加去中心化網絡的吸引力：誰愿意讓一群不露面的大公司來決定你能說什么或不能說什么？當然，也有很多司法機構審查人們對網絡和信息的訪問。我們很容易看到P2P內容分發系統的成功（盡管在很大程度上是為了分發其他人擁有版權的內容）并得出結論說這是解決網絡中心化問題的辦法。

不幸的是，由于上述原因，我認為這不是真正正確的結論。雖然網絡從表面上看有點像一個內容分發系統，但它實際上是一個完全不同的東西，它有更廣泛的使用案例和更嚴格的安全和性能要求。在P2P基礎上重建一些較簡單的系統是可能的，但網絡作為一個整體是一個不同的故事，即使是看起來簡單的系統，其內部也往往相當復雜。當然，網絡已經有近30年的時間發展成現在的樣子，可能有一些技術改進可以讓我們建立一個具有類似屬性的去中心化系統，但我不認為這是我們今天真正理解的事情。

Though see X in which these roles are sort of reversed. ??

Interestingly, within certain limits latency doesn’t have that much impact on how fast you can send the data because the rate control algorithms can adjust for latency. ??

Allan Schiffman used to call this a “distributed single point of failure”. ??

Or, as the nerds say, “unity”. ??

Tags：DHTITTWEBHTTdht幣行情PITTYSGeo WebCHTT幣

PEPE幣