前言：web2.0中，資料所有權歸平臺所有，這導致時不時出現平臺資料洩漏的問題。那麼，web3.0的到來，能否實現將資料的所有權和應用邏輯進行解綁。如果能實現，具體如何實現？本文作者Kyle Samani，由“藍狐筆記”社群的“SL”翻譯。
一年前，我按照當時的理解來闡述Web3堆疊。最近又提到了Web3的投資主題，正如我所強調的，Web3的一個關鍵含義是資料所有權和應用邏輯的解綁。本文，我將解釋這種解綁中固有的具體問題，以及我們如何考慮在Web3堆疊中進行投資。
資料庫和資料在哪裡？
出於實際目的，絕大多數現在的應用都可以被看作為基於資料庫的一種UX。雖然有一些例外，例如，影片流和影片遊戲。但通常這樣看都是正確的。事實上，幾乎每個主要的消費者服務，例如Facebook、Reddit、Evernote、Twitter、Google Docs、Gmail、iMessage等，都可以簡化為基於資料庫的UX。（藍狐筆記：UX是一種使用者體驗，基於介面使用者跟產品的互動體驗。）
在Web2的模型中，應用提供者儲存和管理使用者資料，因此使用者不必自己管理。此外，Web2的應用提供者總是線上，因為他們24/7小時執行伺服器，即便使用者經常離線（例如在地鐵中、網路連線不良、電池沒電等）。而在Web3模型中，沒有一箇中心化的應用提供者，因此，關於資料所有權的正規化需要改變。
這引出了幾個問題：
1.使用者在哪裡儲存TA的資料（讓我們將使用者叫做Alice，假設她沒有維護自己的伺服器）？
2.如果Alice離線，內容傳送者如何向她傳送內容？
當然，答案必須是：將內容儲存在始終線上且可訪問的地方，並確保當Alice重新上線後，知道在哪裡可以找到發給她的內容。這種正規化同時封裝了像訊息這類P2P應用以及像新聞、社交媒體以及筆記這類傳統資料庫應用。
要執行此類操作，存在一些機械挑戰：
1.其他人（不是Alice）需要知道儲存內容和該內容的檢索，以便Alice後續可以找到並下載它。
2.Alice需要知道哪裡可以找到該索引。
3.透過該索引，Alice需要實際找到並下載底層資料本身。
4.儲存資料的人不應該能閱讀該內容（如果是私有的），或者對它審查。
透過解決這些問題，資料所有權和應用邏輯可以解綁，從而支援Web3.0走向繁榮。
在探索當代Web3.0創業家們如何解決這些問題之前，可先思考過去已經試圖解決這些問題的其他人。
之前對網際網路進行去中心化的嘗試
有一些團隊，包括但不限於Zeronet、Freenet、Scuttlebutt，他們試圖“對網際網路進行去中心化”。他們試圖做這個事情，這比我們今天知道的當代加密時代還要早。大多數這些努力專注於支援狹隘的用例。例如，可抗審查的訊息和留言板等。
如果你很好奇，你可以嘗試使用下這些系統。你會發現它們的使用者體驗有很多不足。儘管這些系統存在很多UX問題，但迄今為止，最大的問題是速度。一切都很慢。
為什們它們這麼慢？
因為它們在邏輯上全都是去中心化的。
這些系統採用了下列架構的一些變體。我將在加密和P2P的訊息應用的背景下描述它們的架構：
這些系統基於如下想法：如果Alice離線時，有人給她發訊息，他們會將其發給Bob，而Bob將代表Alice儲存該資訊。
當Alice重新上線時，她會詢問Bob在她離線時是否錯過訊息（訊息索引）。
遺憾的是，Alice得不到以下的保證：1）Bob當前線上；2）在Alice離線時，Bob一直線上；3）Bob實際上擁有她不線上時錯過的完整訊息索引。為了解決這個問題，Bob可以詢問他的對等方他們是否注意到傳送給Alice的訊息。然而，這些對等方也可能不線上，並且他們也可能只有不完整的訊息。
在這種正規化中，根本不可能保證訊息傳遞，因為它不清楚訊息應該傳遞到哪裡，且誰應該儲存訊息索引。當訊息接受者重新上線時，由於接收者不知道哪裡可以找到傳送給她的訊息列表或資料訊息的指向，這還會產生複合問題。
Scuttlebutt是專注於構建P2P社交網路的專案，它試圖透過採用類似於Facebook的雙向選擇朋友系統來解決這個問題。也就是說，一旦Alice和Bob變成朋友，他們共享彼此的朋友列表，這樣，Bob可以代表Alice索引和儲存Alice朋友們釋出的內容。這要求Alice通知她所有的朋友，而Bob是她的代理，反之亦然。然後，當Alice不線上時，她的朋友們釋出更新，Alice的朋友可以將更新傳送Bob，他能為Alice託管。
Zeronet和Freenet是更普遍化的專案，而不僅僅是P2P社交網路，它們使用類似的模型，除了沒有雙向選擇的朋友模型。這給系統增加了很多複雜性，這讓它變得更加緩慢。與Scuttlebutt模型不同，在Scuttlebutt中，朋友們同意相互幫忙定義資訊路徑，而Freenet和Zeronet的使用者則不得不隨機ping其他使用者，並詢問他們關於他們知道的資訊。這就是為什麼這些系統如此緩慢的關鍵原因。
讓我們說，在某種機緣情況下，Alice最終將其離線時錯過的各種內容索引拼湊起來。也就是說，她知道Carol給她傳送了一張照片，且Dave將該照片儲存在“dave.com/alicepic1.png”。如果Dave離線，Alice如何能訪問該照片呢？
這些都是需要重視的問題。對網際網路進行去中心化很難。
邏輯和架構的（去中心化）中心化
上述所有問題的根本原因是缺乏邏輯上的中心化儲存和索引。什麼是邏輯上的中心化儲存？要回答這個問題，它有助於理解分散式系統中的去中心化的三個向量：
1.架構的
>系統中的計算機數量
2.政治的
>能夠對系統施加影響的人數
3.邏輯的
>外部代理與系統互動的介面數
為更好理解這些概念，可以閱讀“藍狐筆記”之前釋出的文章《以太坊創始人V神：如何理解區塊鏈的“去中心化”》
Web2.0壟斷解決了上述的所有問題，因為它們依賴於邏輯上的中心化儲存。也就是說，當Alice重新上線時，她只需向中心網路伺服器發出請求，網路伺服器維持中心儲存，它儲存了自Alice下線後所有錯過的訊息。網路服務查詢它控制的包含所有使用者訊息的資料庫，然後返回正確的訊息。
這種模式的問題在於，Web2.0系統耦合了所有形式的中心化：它們不僅在邏輯上是中心化的，而且在政治上和架構上也是中心化的。
那麼，儲存系統在邏輯上中心化，但在架構和政治上可以是去中心化的麼？
幸運的是，答案是肯定的：用於基於合約儲存的IPFS和用於永久儲存的Arweave（基於合約的儲存：在Y時間段記憶體儲X位元組的資料，同時具有Z的可檢索性保證。AWS、GCP、Azure、Filecoin以及Sia都是基於合約的儲存系統。）
這個系統在邏輯上是中心化的，而在架構和政治上是去中心化的，這究竟意味著什麼？理解這個問題最好的方法是考慮一下計算機是如何從網路上的其他伺服器上檢索基本檔案（基於位置的定址），然後將其與IPFS/Arweave方法進行比較（基於內容的定址）。
在web2.0的架構中，如果Alice想要從伺服器下載圖片，Alice會轉到一個URL類似於：
Website.com/image.png。當Alice試圖訪問該URL時，到底發生了什麼？
使用DNS，Alice知道在website.com上找到伺服器的位置，她會向伺服器詢問它所託管的影象位於“/image.png”的本地檔案系統上。假設伺服器想合作，它會檢查它的/image.png的目錄，如果檔案存在，它會返回結果。
注意這個系統是多麼脆弱：如果檔案被移動、更改，或者伺服器很忙，或者伺服器因為任何原因不想合作，請求就會失敗。
這就是當今網路構建web的基礎。
而在像IPFS和Arweave這樣的基於內容的定址系統中，Alice訪問的URL是像這樣的：
mTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D。
儘管它不具有人類可讀性，但它是從內容本身衍生而來，是透過內容確定性地生成。也就是說，當被雜湊之後，世界上唯一的一片內容將產生確切的字串。IPFS和Arweave的神奇之處在於它們處理了允許計算機將QmTkzDwW...解析到網頁的所有複雜性。
（關於IPFS可參考藍狐筆記之前的文章《IPFS：基於區塊鏈的去中心化儲存網路》）
IPFS和Arweave網路上的內容儲存在很多機器上。不管內容儲存在多少臺機器上，或者這些機器位於世界上的哪個地方，這些協議都會解析像QmTkzDwW... 這樣的地址，而不管它實際儲存的內容位於何處。
這就是基於內容定址的神奇之處。它公開了一個單一邏輯介面，基於內容的地址——它將始終正確地解析，不管底層資料儲存在哪裡，儲存在多大的計算機網路上（這些計算機在架構和政治上是去中心化的）。
本文開頭提到的四個主要技術挑戰，基於內容的定址解決了其中三個（1.3.4），也就是儲存內容、讓內容下載可訪問、確保託管者無法讀取隱私資訊。但還有一點：如何知道在哪裡尋找資料？
索引
儘管IPFS和Arweave充當邏輯上的中心化，但架構和政治上是去中心化的檔案系統，這些系統並不是資料庫。也就是說，沒有辦法來查詢它們以及詢問“請告訴我在日期X和Y之間，Bob發給Alice的所有訊息”。
幸運的是，有幾種方法能解決這個問題：
第一種方式是直接在區塊鏈上儲存訊息索引。區塊鏈自身是邏輯上中心化，但架構和政治上是去中心化的資料庫。使用去中心化的服務如Graph或中心化的服務如dFuse，Alice能夠查詢儲存在區塊鏈上的索引。區塊鏈並不儲存底層資料，只是儲存資料的雜湊。雜湊只是儲存在IPFS和Arweave上的內容的指標。Graph和dFuse現在都在使用，很多應用都採用在鏈上儲存內容雜湊，而資料儲存在內容定址系統的模式。
第二種方式是利用Textile。Textile構建了一種獨特的技術，被稱為Threads，它在IPFS上充當私有、加密和個人的資料庫。因為這個資料庫是基於IPFS構建的，它在邏輯上是中心化的，但架構和政治上是去中心化的。作為邏輯上中心化的資料庫，傳送者和接收者知道從哪裡傳送和從哪裡閱讀資訊。此外，Textile近期釋出了Cafes，允許使用者構建伺服器以便於託管他們的Threads（而不是在本地託管Threads）。Textile的下一步構建一個經濟層，以激勵驗證者來為其他使用者託管cafes，這類似於Filecoin是IPFS的經濟層。
第三種方法是利用OrbitDB。OrbitDB類似於Textile的Threads，除了OrbitDB主要是為公共資料設計（例如用於構建去中心化的twitter），而Textile的Threads本地整合用於私人資訊的加密和金鑰管理（例如P2P訊息）。像Textile，OrbitDB已經上市，且OrbitDB正在底層技術基礎上開發一個經濟層。
最後一種方法是，有很多團隊，他們在構建具有不同去中心化向量的有效傳統資料庫：Fluence的構建將在用BFT保證的無須許可的環境下執行，而Bluzelle正在構建一個雙層系統，該系統具有一組政治上中心化的主節點，以及還有一組架構上去中心化的副本節點。
鑑於一些智慧合約團隊正在致力於大規模解決資料可用性問題，例如Solana的Replicators（可參考藍狐筆記之前的文章《為什麼Solana是區塊鏈開發者需要的“世界計算機”？》）。
我們對如下方案持懷疑態度：在傳統的資料庫基礎上增加BFT層。相反，我們選擇投資“加密原生”資料庫如Textile等，以及開發者API層（如The Graph和dFuse的形式）。
透過協議和上述的服務，IPFS、Filecoin、Arwearve、The Graph、dFuse、Textile以及OrbitDB，這裡有一個明晰的路徑，可供Web3.0產生成果。今天所有這些服務都已經存在，儘管在產品準備就緒和有加密經濟實戰考驗的網路規模形式方面還不成熟，但是，對於其中最重要的問題有了解決方案，為政治上和架構上去中心化的系統提供單一邏輯上的中心化介面。
還剩下什麼？
高階邏輯
現在，我們有了邏輯上中心化但架構上去中心化的儲存、索引、檢索的解決方案，我們可以考慮更高階的邏輯。例如：
Alice如何管理多個身份？例如，Alice可能不想在多個應用如Facebook/Google/Snapchat/Reddit上使用相同的公鑰。如果她想在一個介面上管理這些身份而不公開連結它們，該怎麼辦？
考慮Alice想給Bob傳送私人資訊，但將它儲存在IPFS或Arweave上，這些都是公開系統，它們需要利用PFS（完全正向保密）握手。他們如何以非同步方式設定PFS並管理所有相關的金鑰？
鑑於傳統的加密機制僅供雙方進行通訊，而系統如何支援大型人群的私人通訊（如留言板或大型聊天組）？
系統如何支援常見的UX模式，例如群組發現、使用者資料恢復以及內容移除等？
雖然這些是不同的技術挑戰，但我將所有這些視為“高階邏輯”問題。
Textile的Threads恰好地解決這些問題。很多方面，人們可以將Textile看作為IPFS的iCloud。雖然這種類比不完美，但它通常有用：iCloud抽象了跨裝置同步和應用的資料備份（提供了更好的使用者和開發者體驗），Textile提供基於IPFS之上提供各種更高階的邏輯工具，使得開發者無縫地進行應用開發，同時確保IPFS上的使用者無縫跨裝置同步和備份。
展望未來
Web3.0生態系統在很多方面都非常多樣化，包括要解決的問題型別、團隊的位置、所使用的經濟模型等。儘管沒有一個邏輯上中心化的實體在協調整個事情，但Web3.0堆疊正在一起到來，這是很了不起的。然而，這也意味著，系統中有很多熵，因此對於更高階別的主題人們很難理解。在本文中，我將其提煉如下：
從Web2.0向Web3.0過渡最大挑戰是從具有三個中心化向量（邏輯、架構和政治上）的耦合系統向邏輯上中心化但架構和政治上去中心化的系統轉變。
我們相信Web3.0將成為一種正規化轉移，將在下一個十年解鎖數萬億美元的價值。
------
風險警示：藍狐筆記所有文章都不能作為投資建議或推薦，投資有風險，投資應該考慮個人風險承受能力，建議對專案進行深入考察，慎重做好自己的投資決策。
