鏈聞ChainNews
公眾號ID：chainnewscom
作者：Kyle Samani，Multicoin Capital 聯合創始人
編譯：詹涓
一年前我寫文章詮釋了當時我所理解的 Web3 堆疊。最近，我撰寫了《論百萬億美元加密貨幣市場中三個核心投資主題》(Crypto Mega Theses)，詳細介紹了關於 Web3 的投資觀點。正如我所強調的那樣，Web3 的一個關鍵含義是資料所有權和應用程式邏輯分離。
連結：論百萬億美元加密貨幣市場中三個核心投資主題
https://www.chainnews.com/articles/434571412792.htm
在本文中，我將解釋在 Web3 分離中所導致的特殊問題，以及我們如何考慮在 Web3 堆疊中進行投資。
Kyle Samani，Multicoin Capital 聯合創始人
資料庫和資料在哪裡？
實際上，絕大多數現代應用程式都可以看作是資料庫之上的使用者體驗 (UX)。雖然有一些例外（如影片流媒體和影片遊戲），但這通常是成立的。幾乎所有主要的 C 端服務，例如 Facebook、Reddit、Evernote、Twitter、Google Docs、Gmail、 iMessage 等，都可以簡化為資料庫之上的 UX。
在 Web2 模型中，應用程式提供者儲存和管理使用者資料，這樣使用者就不必這樣做。此外，Web2 應用程式提供商總是線上的，因為他們時刻都在執行伺服器，而使用者經常離線（搭乘地鐵、網路連線不佳、電池有問題之類）。
而在 Web3 模型中，沒有中心化的應用程式提供商，因此整個資料所有權正規化都需要做出相應的更改。
這就引出了兩個問題：
假設使用者（我們姑且稱她為 Alice）沒有維護自己的伺服器，那麼 Alice 將資料儲存在哪裡 ?
在 Alice 離線的情況下，內容傳送者如何將內容傳送給 Alice？
當然，答案必須是：將內容儲存在始終線上且可訪問的地方，並確保在 Alice 重新上線時，她知道在哪裡能找到傳送給自己的內容。這個正規化同時囊括了點對點應用（如聊天工具）和傳統資料庫應用（如報紙、社交媒體和筆記應用程式）。
要實現這一點，有幾個操作方面的挑戰：
Alice 以外的人需要知道如何儲存內容、該內容的索引放在何處，以便 Alice 以後可以找到並下載它。
Alice 需要知道哪裡可以找到索引。
有了這個索引，Alice 需要自己找到，並下載資料本身。
無論是誰在儲存資料，都不應該能夠讀取內容（如果是私有的），或者對其進行審查。
透過解決這些問題，可以將資料所有權和應用程式邏輯分離，從而使 Web3 蓬勃發展。
在探索當代 Web3 創業者們是如何解決這些問題之前，有必要考慮一下在過去，人們是如何嘗試解決這些問題的。
去中心化網際網路曾經作出的嘗試
有一些團隊，包括但不限於 Zeronet、Freenet 和 Scuttlebutt，已經嘗試過他們口中所說的「去中心化網際網路」。在我們今天所知的現代加密時代之前，他們就試圖這麼做過。這些嘗試主要聚焦在狹窄的用例上，例如，專門適用於專制政權國家使用者的抗審查的訊息傳輸工具和留言板。
如果你對此感到好奇，我建議你試用下這些系統，你會發現它們的在體驗上還有很多需要改進的地方。互動體驗方面的問題顯而易見，此外，到目前為止，這類系統最大的問題還是速度。一切都慢得要命。
這到底是怎麼回事？它們為什麼這麼慢？
因為它們在邏輯上都是去中心化的。
這些系統採用了以下體系結構的一些變體。我以某個加密點對點聊天工具為例，試著描述它們的架構：
這些系統基於這樣一種邏輯，如果有人在 Alice 離線時向她傳送訊息，他們將把訊息傳送給 Bob，Bob 將代表 Alice 儲存該訊息。
在 Alice 回到網上時，她會問 Bob 她離線時是否錯過了什麼（訊息索引）。
遺憾的是，Alice 不能保證 1) Bob 現在線上，2) Bob 線上時 Alice 卻不線上，3) Bob 實際上擁有她離線時錯過的所有訊息的索引。
為了解決這個問題，Bob 可以詢問他的對等點，是否知道傳送給 Alice 的任何訊息。然而，這些對等點可能也處於或已經處於離線狀態，而且它們擁有的資訊也可能不完整。在此範例中，根本不可能保證訊息傳遞，因為不清楚應該在何處傳遞訊息，以及誰應該儲存訊息索引。當收件人重新聯機時，這會產生複雜的問題，因為收件人不知道在哪裡可以找到傳送給她的訊息列表或資料訊息引用。
專注於建立 P2P 社交網路的 Scuttlebutt 試圖透過在好友系統中採用類似 Facebook 的雙重選擇來解決這個問題。也就是說，一旦 Alice 和 Bob 成為朋友，他們彼此分享朋友列表，這樣 Bob 就可以索引和儲存 Alice 的朋友代表 Alice 釋出的內容。這要求 Alice 得通知她所有的朋友，Bob 是她的代理人，反之亦然。然後，當 Alice 離線時，Alice 的朋友釋出更新，Alice 的朋友可以將更新傳送給 Bob，Bob 可以為 Alice 託管更新。
Zeronet 和 Freenet 比 P2P 社交網路更加一般化，它們使用了類似的模型，只是在好友模型中沒有雙重選擇。這給系統增加了相當多的複雜性，並且把速度拖得更慢。與 Scuttlebutt 這種朋友們同意為確定的資訊路徑互相幫助的模型不同，Freenet 和 Zeronet 的使用者必須隨機聯絡其他使用者，詢問他們知道哪些資訊。這就是為什麼這些系統如此緩慢的關鍵所在。
假設 Alice 終於把她離線時錯過的所有東西的索引拼湊起來了。也就是說，她知道 Carol 給她發了一張照片，而 Dave 把照片儲存在「dave.com/alicepic1.png」。如果 Dave 此時離線，Alice 如何訪問照片？
這些問題並非小事。讓網際網路去中心化是很困難的。
邏輯和架構（去）中心化
上述所有問題的根本原因是缺乏邏輯中心化的儲存和索引。什麼是邏輯中心化儲存？為了回答這個問題，最好先理解分散式系統中去中心化的三個向量：
架構：系統中計算機的數量
政治：能夠對系統施加影響的人數
邏輯：外部代理與系統互動的介面數目
推薦大家閱讀 Vitalik Buterin 的這篇文章（https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274）可以更好地解釋這些概念。
Web2 壟斷解決了上一節所述的所有問題，因為它們依賴邏輯上中心化的儲存。也就是說，當 Alice 重新聯機時，她只需要詢問維護中心化儲存的中心化網路服務，自上次聯機以來她錯過了哪些訊息。網路服務查詢它控制的包含所有使用者訊息的資料庫，並返回正確的訊息。
這個模型的問題是，這些 Web2 系統將所有形式的中心化捆綁在一起：它們在邏輯上是中心化的，在政治上是中心化的，在架構上也是中心化的（除了用於伸縮目的）。
那麼，是否存在邏輯上中心化、但在架構和政治上去中心化的儲存系統呢？
幸運的是，答案是一個響亮的「是」：星際檔案系統 (IPFS) 用於基於合約的儲存，Arweave 用於永久儲存（基於合約的儲存：在保證 Z 可檢索的前提下，為 Y 段時間儲存 X 位元組的資料。AWS、GCP、Azure、Filecoin 和 Sia 都是基於合約的儲存系統）。
系統在邏輯上是中心化的，但在結構和政治上是去中心化的，這究竟意味著什麼？理解這一點的最佳方法是考慮計算機如何從當今網路上的另一臺伺服器上檢索基本檔案（基於位置的定址），然後將其與 IPFS/Arweave 方法（基於內容的定址）進行比較。
在 Web2 體系結構中，如果 Alice 想從伺服器下載圖片，她將轉到一個類似於 website.com/image.png 的 URL。當 Alice 嘗試去那個 URL 時會發生什麼？
使用域名解析服務（DNS），Alice 知道在 website.com 上在哪裡可以找到伺服器，她將向伺服器詢問它託管在本地檔案系統上的映像，地址是「/image.png」。假設伺服器想要合作，它將檢查目錄中的 /image.png，如果檔案存在，則返回該檔案。
請注意這個系統是多麼脆弱：如果檔案移動、更改、伺服器繁忙或伺服器由於任何原因不合作，請求將失敗。
這就是目前網路構建的基礎。
在 IPFS 和 Arweave 中使用的基於內容的定址系統中，Alice 訪問的 URL 是這樣的：QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D。
雖然它不是人類可讀的，但它由它所派生的內容確定性地生成。也就是說，在全網中只有一個單一的內容，在雜湊後，會產生那個精確的字串。IPFS 和 Arweave 的神奇之處在於，它們可以處理所有的複雜性，使計算機能夠解析 QmTkzDwW……，並引領使用者進入這個網頁。
如果您想了解更多 IPFS 的工作原理，這個由六部分組成的系列是一個很好的起點。
（https://hackernoon.com/understanding-ipfs-in-depth-1-5-a-beginner-to-advanced-guide-e937675a8c8a）
IPFS 和 Arweave 網路上的內容儲存在許多機器上。但無論內容儲存在多少臺機器上，或者這些機器位於世界的哪個位置，這些協議都解析類似 QmTkzDwW 這樣的地址——與實際內容儲存在哪裡無關。
這就是基於內容定址的神奇之處。它提供了一個邏輯介面——基於內容的地址，無論底層資料儲存在架構和政治上去中心化、龐大無比的計算機網路的哪個位置，它總是能夠正確地解析。
在本文開頭概述的四個主要技術挑戰中，基於內容的定址解決了第 1、第 3 和第 4 條（儲存內容，使內容可供下載，並確保主機不能讀取私有資訊）。但是第 2 條呢？去哪裡查詢資料？
索引
儘管 IPFS 和 Arweave 在邏輯上是中心化的，而在架構上和政治上是去中心化的檔案系統，但這些系統不是資料庫。也就是說，無法查詢它們並詢問「請顯示在日期 X 和日期 Y 之間 Bob 傳送給 Alice 的所有訊息。」
好在有幾種方法可以解決這個問題。
一種方法是直接儲存區塊鏈上訊息的索引。區塊鏈本身是在邏輯上中心化、但在架構和政治上是去中心化的資料庫。使用像 Graph 這樣的去中心化服務或像 dFuse 這樣的中心化服務，Alice 可以查詢儲存在區塊鏈上的索引。區塊鏈不儲存底層資料，而只是資料的雜湊。該雜湊只是指向儲存在 IPFS 或 Arweave 中的內容的指標。Graph 和 dFuse 現在都是實時的，許多應用程式都採用了這種將在鏈上儲存雜湊的模型，這些雜湊指向儲存在內容定址系統中的資料。
第二種方法是利用 Textile。Textile 建立了一種稱為 Threads 的獨特技術，在 IPFS 之上充當一個私有的、加密的個人資料庫。因為這個資料庫是基於 IPFS 構建的，所以它在邏輯上是中心化的，但在架構和政治上去中心化。作為邏輯中心化的資料庫，傳送方和接收方知道從哪裡傳送和讀取資訊。此外，Textile 最近推出了 Cafes，使使用者能夠建立伺服器來託管 Threads （而不是在本地託管）。Textile 的下一步是建立一個經濟層，以激勵驗證器為其他使用者提供 Cafes 託管，這類似於 Filecoin 是 IPFS 的經濟層。
第三種方法是利用 OrbitDB。OrbitDB 類似於 Textile 的 Threads，只是 OrbitDB 主要是為公共資料設計的（例如，用於構建去中心化的 Twitter），而 Textile 的 Threads 從本質上就為私有資訊（例如點對點聊天工具）整合了加密和金鑰管理。和 Textile 一樣，OrbitDB 現在也已投入使用，OrbitDB 團隊正在底層技術的基礎上開發一個經濟層。
最後，Fluence 和 Bluzelle 等團隊正在構建有效的傳統資料庫，這些資料庫使用拜占庭容錯 (BFT) 保證下在無許可環境中執行。
考慮到智慧合約團隊正在大規模解決資料可用性問題（如 Solana 的 Replicators），我們對在傳統資料庫之上新增 BFT 層的想法持懷疑態度。相反，我們選擇投資的是 Textile 這類 「加密貨幣原生」資料庫和以 Graph 和 dFuse 為代表的開發人員 API 層。
有了上面描述的協議和服務，例如 IPFS、Filecoin、Arweave、the Graph、dFuse、Textile 和 OrbitDB，Web3 就有了明確的實現路徑。所有這些服務目前都已經能夠使用，不過還不全然是生產就緒、達到了網路規模、並且經過了實戰驗證。
然而，對於最重要的問題已經有了解決方案——為政治上和架構上去中心化的系統提供一個邏輯上中心化的介面。
還有什麼遺漏的嗎？
更高階的邏輯
既然我們有了邏輯中心化但架構去中心化的儲存、索引和檢索的解決方案，我們就可以考慮更高階的邏輯了。
舉幾個例子：
Alice 如何管理多個身份？比方說，Alice 可能不想在 Facebook/谷歌 /Snapchat/Reddit 上使用相同的公鑰。如果她想在一個單獨的介面中管理這些身份而不公開連結，又該怎麼辦呢？
假設 Alice 希望向 Bob 傳送私人資訊，但要將資訊儲存在 IPFS 或 Arweave 上（按定義它們屬於公共系統），他們需要利用完美前向保密 (perfect forward secrecy，PFS) 握手。如何以非同步方式設定 PFS 並管理所有關聯的金鑰？
鑑於傳統的加密方案只適用於兩方通訊，系統如何支援大型群組，比如留言板或大型聊天組的私人通訊呢？
系統如何啟用常見的互動模式，如群組發現、使用者資料恢復、內容刪除等？
雖然這些都是不同的技術挑戰，但我大致上將所有這些問題歸類為「更高階的邏輯」問題。
Textile 的 Threads 恰好解決了這類問題。在許多方面，人們可以將 Textile 看作是在 IPFS 上的 iCloud。
雖然這個比喻並不完美，但還算好懂：就像 iCloud 為應用程式抽象跨裝置同步和資料備份（提供更好的使用者和開發人員體驗）一樣，Textile 在 IPFS 之上提供了所有更高階的邏輯工具，使開發人員可以無縫地進行應用程式開發，同時確保 IPFS 上的使用者無縫跨裝置同步和備份。
展望未來
Web3 的生態系統在很多方面都非常多樣化，包括正在解決的問題的型別、團隊的位置、所使用的經濟模型等。儘管沒有一個邏輯上中心化的實體來協調整個事情，但是 Web3 堆疊正在走到一起，這一點非常了不起。
然而，這也意味著系統中存在大量的熵，因此很難理解更高層次的主題。在這篇文章中，我總結如下：
從 Web2 到 Web3 的過渡中，最大的挑戰是從將所有三個中心化的向量（邏輯、架構和政治）解綁，過渡到在邏輯上中心化但在政治和架構上去中心化的系統。
我們相信 Web3 將是一個正規化的轉變，在未來的十年裡，它將釋放出數萬億美元的價值，我們希望支援最優秀的創業者建立基礎的 Web3 基礎設施。
