注：原文作者是Optimism 核心開發者Kelvin Fichter（smartcontracts）。
以下是關於Optimism 未來的帖子，包括即將到來的Bedrock 升級，Rollup 的去中心化以及關於ZK 的部分。 Bedrock 是一個Rollup 客戶端，而不是一個Optimistic Rollup 客戶端。
我最近發表了一次題為《何時？ 》的探索Optimism 未來的主題演講，由於Optimism 做的所有東西都是開放的，因此這次演講裡面有很多alpha 信息。
我想談談我在那次演講中提出的一些最重要的觀點，因為它們對於理解“為什麼Optimism 會以這種方式做事”是至關重要的。讓我們來談談Bedrock、去中心化以及ZK 的未來。
Bedrock 架構
Optimism 即將推出的Bedrock 設計是有史以來最先進的rollup 架構。這不是什麼比賽，Bedrock 在各個方面都接近理論上的最優值，包括最優的交易費用、最優網絡以及最優區塊生產。
Bedrock 之所以如此先進，是因為它非常模塊化並且是極簡的，它的設計理念是把以太坊現有的代碼變成Rollup 代碼，並且我們成功了。我們的客戶端差異是500 行代碼。
Bedrock 有一個新的L2 派生管道，使其成為了一個獨一無二的rollup 架構，在將tx 數據發佈到以太坊時擠出每一點節省的gas。 Bedrock 也是當前唯一使用以太坊引擎API 實現共識/執行客戶端分離的rollup 設計。
那這些為什麼很重要呢？
因為Bedrock 是使得Optimism 成為第一個真正去中心化的EVM Rollup 的基石。
為了使一個rollup 真正安全與去中心化，它需要有一種證明機制（故障證明或有時是“欺詐證明”），而無需任何類型的升級密鑰，可以在不長時間延遲的情況下更新證明。
這就是rollup 骯髒的真相，如果你有快速升級，即使你有故障證明，你的區塊鏈安全性仍然取決於你的升級密鑰。而在解決該問題之前，你根本無法獲得真正的rollup 級安全性。
目前，只有一種方法可以一勞永逸地解決這個問題：客戶端多樣性以及證明多樣性。
就像以太坊需要客戶端多樣性（Geth、Erigon、OE、Nethermind 等）一樣，rollup 也需要客戶端多樣性。有了客戶端的多樣性，一個漏洞就變成了一次鏈分裂，並且可以得到解決。而如果沒有客戶端多樣性，一個漏洞就有可能成為關鍵的安全事件。
Bedrock 的500 行代碼差異以及共識/執行分裂並非是偶然。這是一個深思熟慮的決定，旨在使rollup 客戶端多樣化成為可能。我們已經有了Optimistic Geth，那你知道還會有Optimistic Erigon 嗎？
我們最終還將通過故障證明的多種實現來證明多樣性。最終結果是，我們可以使用多個客戶端運行多個證明，這意味著我們可以通過查看任何證明結果是否不一致來檢測關鍵的漏洞。
客戶端和證明的多樣性是未來，它將使我們能夠安全地刪除快速升級密鑰。
但Bedrock 也是其他東西的基礎……
Bedrock 非常靈活和模塊化，我們的L2 派生管道和我們的故障證明架構，意味著Bedrock 可以輕鬆插入新的數據可用性層。這就是為什麼OP Labs 正在努力幫助交付EIP-4844 (“proto-danksharding”)。
一旦以太坊交付EIP-4844，Optimism 就可以無縫遷移到「data blobs」交易類型，用戶將能夠節省大量的gas 費用。
並且，Bedrock 是非常靈活的，它是一個Rollup 客戶端，而不是一個Optimistic Rollup 客戶端。
Optimistic 和ZK 系統的無縫過渡
與其他設計不同，Bedrock 與所使用的Rollup 證明類型完全無關，它甚至不知道證明。現在，我們正在構建一個Optimistic 證明……
但是Bedrock 也可以使用一個ZK 證明系統，我們認為Optimistic Rollup 目前相比ZK 同類產品具有優勢，而Bedrock 旨在使Optimistic 和ZK 之間的無縫過渡成為可能。
Optimism 是為未來做準備的，而Bedrock 就是未來的基礎。這並不是關於構建最好的Optimistic Rollup 或最好的ZK Rollup，而是關於構建最好的Rollup。我們不只是這麼說，我們是從頭開始這麼設計的。
如果你想了解更多信息，我強烈建議你看看《Wen?》這期演講視頻，它大約有1 個小時的時間，並且要比這篇文章中提到的要更詳細得多。
而關於這個帖子，以太坊聯合創始人Vitalik Buterin 也發表了他的看法：
“混合思路：optimistic + ZK，治理只用於判決兩者之間的漏洞。
1、發佈區塊；
2、等待24 小時時長的欺詐挑戰期；
3（a）如果沒有挑戰，則發布ZK SNARK，最終確認；
3（b）如果出現了挑戰，根據（挑戰遊戲、ZK SNARK 以及治理）的3 個選項中的2 個做出決定；