- 原文標題：《Our Pragmatic Path to Decentralization》
- 撰文：Optimism PBC
- 編譯：Zombit
在討論第二層擴展協議（Layer 2 protocols）的時候，有個殘酷的事實往往沒有實現：每個主要的 Layer 2 項目都需要一個的可信方負責執行協議升級。目前，這幾乎是所有 Layer 2 的主要中心化問題，包括我們。如果升級密鑰（Upgrade Keys）出現問題，那麼 Layer 2 協議中所有存入的資產都將面臨風險。
擁有以太坊跨鏈資產的替代性底層公鏈（Layer 1）也容易受到類似的破壞性攻擊，依靠 Layer 1 的安全保障來避免這種情況是 Layer 2 願景的一個關鍵點。但我們還沒有完全達到目的，在某種意義上，每個人都還在賣夢想。
讓我們來談談導致 Layer 2 項目在「升級密鑰」方面的風險，以太坊本身是如何避免這些陷阱的，以及我們能夠如何效仿。
Layer 2 的中心化情形
你的安全性強度僅取決於最薄弱的那一環。如果你的密碼是 「passwordpasswordpassword」，再好的加密技術也救不了你。那麼，Layer 2 領域當中最薄弱的那一環是什麼？
你猜對了，是「升級密鑰」。每一個主要的 Layer 2 在他們的 Layer 1 合約上都有某種形式的即時升級能力，這是好的，因為它允許項目的改進和漏洞修復，但它最終也意味著一個受信任的第三方對 Layer 2 餘額有單方面的發言權。
但這就衍生了一個問題：如果到頭來，升級的重要性可以簡單地凌駕於安全性之上，那麼擁有容錯證明（fault proof）或有效性證明（validity proof）的意義何在？
無論建造得多麼堅固，基礎薄弱的城堡仍然可能倒塌。
我們並不是說要無視 Layer 2 團隊為推動去中心化可擴展性技術的發展所做的努力，我們已經取得了巨大的進步，只要看看我們最近所推出有史以來第一個用於下一代容錯證明的漏洞賞金就知道了。相反地，這是一個提醒，當今沒有一個主要 Layer 2 產品有完備的容錯/有效性證明。
這種過渡階段是需要的，生產這些複雜的協議是不容易的，但我們也需要討論放棄密鑰和實現真正去中心化的 Layer 2 願景的務實路徑。
為什麼 Layer 2 不是去中心化的？
一個必要之惡
開始探討解決方案之前，讓我們先確定問題：所有 Layer 2 都有升級密鑰的原因是，編寫複雜、無漏洞的代碼是非常困難的，每寫一行新的代碼就多一次出現漏洞的機會。
在密碼學領域，一個關鍵的漏洞就可以讓一個專案癱瘓，我們必須非常小心。這意味著簡潔、簡單的代碼需求，減少代碼是 Optimism 理念的核心，也是我們升級 EVM（以太坊虛擬機）的主要動力。（即使如此，漏洞還是會被遺漏）。
事實是，去中心化 Layer 2 中的任何關鍵漏洞都是災難性的：根據設計，智能合約將基於 Layer 1 的所有「安全性」來執行，如果沒有升級密鑰作為最終辦法，一般來說將沒有追索權，其設計了一種難以置信的高標準。
研究以太坊
以太坊本身就是研究去中心化安全性的一個很好的案例，我們可以用它來判斷編寫一個沒有漏洞的 Layer 2 的難度。縱觀歷史，以太坊有很多漏洞，這些漏洞被寫入、找到和修復，有時還會不小心引起硬分叉（相信我們，這不好玩）。
儘管有多個關鍵漏洞，但以太坊在其整個生命週期中一直保持高度可用性。在上海 DoS 攻擊期間，當時僅運行兩年的以太坊是最接近真正停止運作的一次。鑑於區塊鏈中斷在當今仍很常見，這是一個令人印象深刻的壯舉。
在這一點上，我們可以非常有信心，以太坊 Layer 1 不會癱瘓或被破壞。我們需要對 Layer 2 達到同樣的信心水準，以便能夠放棄升級密鑰。那麼以太坊的秘密是什麼？當我們努力確保 Layer 2 的安全時，我們能跟隨它的腳步嗎？
去中心化的務實路徑
以太坊在最小化安全性和最大化正常運行時間方面的成功並不只是運氣好，這歸功於以太坊策略性地創建了一個多客戶端生態系統，並擁有多種不同的互操作性實現方式。
達成這種安全性的方法建立在漏洞與實作之間是不相關的情況下，換句話說：如果一個實作出現一種特定的漏洞，另一個實作可能不會遭受完全相同的漏洞。這樣一來，即使出現執行失敗，你也可以剔除有漏洞的客戶端，而選擇正常運行的客戶端，這種冗餘（Redundancy）是以太坊高度可用性保證的關鍵。
單一客戶端可能執行失敗，但以太坊網路仍維持正常狀態
我們可以跟隨以太坊的腳步，在 Layer 2 使用非常類似的方法。我們可以為 Layer 2 創建一個多客戶端的生態系統，就像我們在 Layer 1 中一樣，而不是單一實作客戶端、一個容錯證明或一個零知識證明（Zero-knowledge proof）。這確保了關鍵的漏洞不會導致整個網路癱瘓。
採用多客戶端架構的去中心化 Optimism
我們設計 Optimism 是為了堅持以太坊的理念，不僅從社會影響層面，還包含技術層面。從我們編寫 Optimism：Bedrock 版本的第一天開始，我們就為以太坊 2.0 合併 API 的使用來構建它，這使得我們能夠輕鬆地與多個客戶端整合。
事實上，我們的目標是將一個標準的以太坊客戶端轉變為 Optimism 客戶端所需的代碼降至低於 1000 行，透過 EVM 等效性（EVM equivalence，與以太坊虛擬機規範完全符合），我們還將容錯證明和 Rollup 客戶端的實作模組化為獨立的軟體片段，綜合這些方法，讓我們能夠混合和匹配證明和客戶端，最大化地增加冗餘！
ZK Rollups：額外的安全層
我們經常被問及一個問題：「你們會採用零知識證明技術嗎？」答案是可能的，但不是你想像的那樣。前面的路還很長，但如果 ZK 技術變得足夠強大，能夠支援 EVM 等效性，那麼就有可能在多客戶端生態系統當中將其作為另一個客戶端添加，這並不意味著放棄我們目前的架構或核心功能，但它確實意味著另一個安全層。
因此，雖然 ZK 技術令人振奮，但我們不需要等待獲得一個低成本、高安全性、EVM 等效的 Layer 2。現在已經以 Optimism 的形式運作，一旦 ZK 技術成熟，它可以直接融入我們的架構當中。
推出
目前，我們正在深入 Bedrock 的開發核心，這將使我們的 EVM 等效性 Rollup 的詳細規格產生，以及第一個 Rollup 客戶端和 MIPS 容錯證明「Cannon」。屆時，多客戶端旅程就開始了。
我們的目標是與外部團隊合作，並激勵他們創建其他客戶端，這不會是一個快速的過程，但 Redrock 已經被建立起來，代碼最小化是最重要的部分。要把這些整合到一個多客戶端證明系統中，需要遵循 Hydra 框架。屆時，我們將獲得移除升級密鑰的必要信心。
總結
1. 形成一個 Optimists 委員會。
2. 發布 Bedrock，實現多客戶端架構。
3. 激勵/支援替代性 Optimism 客戶端。
4. 發送多客戶端證明合約。
5. 把我們的升級密鑰扔進末日火山。
