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