金色硬核 | 去中心化的四個層級

2021-10-12 18:10:47

最近的Facebook中斷事故使許多web2用戶意識到他們的核心互聯網服務的基礎是多么脆弱。

大多數web2服務默認是中心化的，但Facebook的運營被證明是中心化的，以至於當系統的一個部分出現故障時，工程師們被封鎖了一切——甚至調試工具。

在Facebook工程團隊的一名成員發布的事件報告中，有一段特別有說服力的段落寫道：

…當我們的工程師努力弄清楚發生了什么以及為什么會發生時，他們面臨兩個巨大的障礙：首先，由於他們的網絡出現故障，無法通過我們的正常方式訪問我們的數據中心，其次，DNS 完全丟失讓我們無法使用通常用來調查和解決此類中斷的許多內部工具。

互聯網並不總是這樣。在早期，它更加去中心化。由於沒有AWS、Azure或谷歌雲平臺，網站大多運行在單獨的服務器上。這意味着一次中斷無法一舉中斷數百萬項服務，並且來自一個提供商的規則更改無法強制實施大規模審查。

今天，谷歌、微軟和亞馬遜共同托管60%的互聯網，僅亞馬遜就佔到33%，包括了最受歡迎和最依賴的web2服務，如Netflix、Spotify、Twitch、Facebook、Slack和Reddit——更不用說互聯網銀行和政府門戶網站等重要服務。

為什么會變成這個樣子？开發人員被教導以中心化的方式做事——使用這些公司的API，部署 AWS。中心化服務是賺錢的工具，它們擁有最大的營銷影響力。

开發人員可以選擇是為繼續壟斷我們的互聯網做出貢獻，還是尋求新選擇以防止停機、抵制審查和捕捉網絡原始精神。在本文中，我們將了解一些流行的web2和web3架構，以及它們如何實現或未能實現去中心化。

一切都中心化

當應用程序的後端和前端都中心化時，它具有列表中任何架構中最多的故障點。後端和前端都使用一臺服務器，即使它們保持在线狀態，如果它所依賴的API出現故障，整個應用程序也可能會宕機。

一個例子：Stripe。其PHP托管在AWS上，連接到Google身份驗證API進行登錄。

在Arweave上存儲數據的中心化服務器

Arweave可以像任何其他數據庫一樣運行——它甚至可以使用graphQL或ardb進行查詢，這使得應用程序可以輕松地從blockweave事務的完整歷史記錄中快速加載他們需要的內容。如果在 Arweave上存儲數據的中心化應用服務器出現故障，仍然可以從Arweave查詢應用程序數據，就好像其API仍在運行一樣。

一個例子：ArDrive。主要後端數據存儲在Arweave上，一些服務和前端由Google Cloud和 Fastly提供。

去中心化的後端，中心化的前端

當應用程序的後端由區塊鏈提供服務時，即使前端是一個故障點，也不會出錯。無論是僅僅因為它托管在中心化服務器上而容易受到攻擊，還是因為托管它的實體可以響應刪除請求或以其他方式對其進行審查而容易受到攻擊，仍然可以說，它仍然是“窒息的喉嚨”。這種設置在 Uniswap等DeFi應用程序中很常見。

一個例子：Uniswap。今年早些時候，Uniswap Labs改變了前端以隱藏大約100個代幣，成為頭條新聞。在這種情況下，前端比後端更容易拯救，而且由於Uniswap和其他web3應用程序經常為此目的使用智能合約，永久網絡檔案管理員能夠克隆Uniswap以前的用戶界面並將其永久托管在Arweave上。