以太坊已經轉向以 rollup 為中心的路線圖。
原文：The Hitchhiker's Guide to Ethereum（Delphi Digital）
作者： Jon Charbonneau
編譯： zCloak Network
原用標題（譯後）：以太坊漫遊指南（下篇）
封面：William Tempest（Ethereum）
第一部分：通往 Danksharding 之路，前文內容詳見——以太坊漫遊指南（上篇）及以太坊漫遊指南（中篇）
第二部分- 歷史和狀態管理
在此快速回顧一些基礎知識：
- 歷史—— 鏈上發生過的一切。歷史不需要快速訪問，你可以把它放在一個硬盤上。從長遠來看，歷史是 N 個誠實假設中的 1 個。
- 狀態—— 所有當前賬戶餘額、智能合約等的快照。完整的節點（目前）都需要掌握狀態以驗證交易。狀態對 RAM 來說太大了，而硬盤驅動又太慢（狀態被放在 SSD 裡），高吞吐量區塊鏈的狀態不斷膨脹，其增長速度遠遠超過了我們可以在日常筆記本電腦上保存的數據量。如果日常用戶不能維護這些狀態，他們就不能完全驗證，就與去中心化背道而馳。
簡而言之，狀態非常大，所以如果你讓節點持有狀態， 那麼就會使運行一個節點變得很困難，如果運行一個節點太難，我們普通人就不會去做，所以我們需要確保這不會發生。
Calldata Gas 成本降低與總 Calldata 限制（EIP-4488）
Proto-danksharding 是一個很好的邁向 Danksharding 的過度，它滿足了許多最終需求。在合理的時間範圍內實現 Proto-danksharding 可以提前 Danksharding 到來的時間線。
一個更容易實現的應急解決方案是 EIP-4488。它雖然不那麼優雅，但解決了 Gas 費用方面的緊急問題。遺憾的是，EIP-4488 沒有實現通往 Danksharding 所需的中間步驟，所有不可避免的更改在將來仍然需要進行。如果覺得 Proto-danksharding 比我們希望的要慢一些，那麼可以通過 EIP-4488（只需要修改幾行代碼）來快速解決擁堵問題，然後 6 個月後（時間可能有變化）再使用 Proto-danksharding。
EIP-4488 有兩個主要組件：
- 將 calldata 的成本從每字節 16 gas 降到每字節 3 gas
- 每個區塊添加 1MB 的 calldata 限制，以及每個交易額外增加 300 字節（理論上最大約 1.4MB）
增加限制是為了防止最壞的情況發生—— 一個區塊中的 calldata 會達到 18 MB，遠遠超出了以太坊的承受能力。雖然 EIP-4488 增加了以太坊的平均數據容量，但由於它的 calldata 限制，以太坊突發數據容量實際上會略有下降（3000 萬 gas / 每個 calldata 字節 16 gas = 1.875 MB）。
歸因於 EIP-4488 的 calldata 和 Proto-danksharding 一個月後可被刪除的數據 blob，使得 EIP-4488 的持續負載比 Proto-danksharding 高得多。使用 EIP-4488 時，歷史數據增長將顯著加快，將成為運行節點的瓶頸。即使 EIP-4444 與 EIP-4488 同步實現，也是在一年後才刪除執行有效負載歷史，所以相較之下，顯然 Proto-danksharding 較低的持續負載更可取。
在執行客戶端中約束歷史數據（EIP-4444）
EIP-4444 允許客戶端選擇本地刪除超過一年的歷史數據（區塊頭，區塊體和收據），它強制客戶端停止在 p2p 層提供這種刪除過的歷史數據。刪除歷史數據允許客戶端減少用戶的磁盤存儲需求（目前有數百 GB，而且還在增加）。
刪除歷史數據本就非常重要，但如果實現了 EIP-4488，那麼這將是強制性的，因為 EIP-4488 實現將顯著增加歷史數據。無論怎樣，希望這能在相對較短的時間內完成。某種形式的歷史數據過期最終會被需要，所以現在是處理它的好時機。
鏈的全同步需要歷史，但是驗證新的區塊不需要（只需要狀態）。因此，一旦客戶端同步到鏈的頂端，歷史數據只有在 JSON-RPC 上明確請求或對等端試圖同步鏈的時候才會被檢索。隨著 EIP-4444 的實現，我們需要為這些找到替代解決方案。
客戶端將無法像現在一樣使用 devp2p 進行"全同步" —— 他們從一個將被視為創世區塊的弱主觀性檢查點進行"檢查點同步"。
請注意，弱主觀性內生於轉向 PoS 的過程中，不是一個新增的假設。我們需要使用有效的弱主觀性檢查點來進行同步以防止遠程攻擊的可能，這裡的假設是，客戶不會從一個無效的或舊的弱主觀性檢查點同步。這個檢查點必須存在於我們開始刪除歷史數據的時期內（即一年內），否則 p2p 層將無法提供所需的數據。
隨著越來越多的客戶端採用輕量級同步策略，網絡的帶寬使用也將減少。
恢復歷史數據
EIP-4444 在一年後刪除歷史數據， Proto-danksharding 刪除 blob 的速度更快，大約一個月後刪除。我們肯定需要這些，因為我們不能要求節點存儲所有這些數據的同時還保持去中心化：
- EIP-4488 —— 長期運行可能包括每個插槽~1MB，每年增加~2.5TB 存儲空間
- Proto-danksharding —— 目標是每個插槽~1MB，每年增加~2.5TB 存儲空間
- Danksharding —— 目標是每個插槽~16MB，每年增加~40TB 存儲空間
但這些被刪除了的歷史數據去哪裡了呢？我們不是仍然需要它們嗎？是的我們仍然需要。但請注意，丟失歷史數據只會對個別應用程序造成風險，不會對協議造成風險，所以以太坊核心協議的工作就不應該是永久地維護所有這些達成共識的數據。
那麼，誰來存儲這些數據呢？這裡有一些潛在的貢獻者:
- 個人和機構志願者
- 區塊探索者（如 etherscan.io），API 供應商和其它數據服務商
- 第三方索引協議（如 TheGraph）可以創建激勵性的市場，客戶為歷史數據和 Merkle 證明向服務器付費
- 門戶網絡（目前正在開發中）客戶端可以隨機存儲部分鏈歷史，而門戶網絡會自動將數據請求定向到節點上
- 例如 BitTorrent，每天自動生成並分發一個包含區塊 blob 數據的 7GB 文件。
- 特定於應用程序的協議，如 rollup，可以要求它們的節點存儲與其應用程序相關的歷史部分
長期數據存儲問題是一個相對容易解決的問題，因為正如前文所討論的，它是 N 個中選 1 個的信任假設，我們距離它成為區塊鏈可擴展性的終極限制還有很多年。
弱無狀態
現在我們已經很好地掌握了管理歷史的方法，但是處理狀態呢？這實際上是目前提高以太坊 TPS 的主要瓶頸。
全節點使用前狀態根來執行一個區塊中的所有交易，並檢查後狀態根是否與區塊中提供的交易相符。為了知道這些交易是否有效，他們目前需要掌握狀態，即驗證是有狀態的。
進入無狀態即無需用已掌握的狀態來做一些作用。以太坊正努力實現"弱無狀態"，意味著驗證區塊不需要狀態，但構建區塊時需要。驗證成為了一個純函數—— 給我一個完全隔離的區塊，我就可以告訴你它是否有效。基本上是這樣的:
基於 PBS ，區塊打包者仍然需要狀態，這是可以接受的—— 無論如何它們是更中心化的高資源實體。專注於去中心化驗證者，弱無狀態為區塊打包者帶來了略多一點的工作，而使驗證者的工則作少很多，這是一個很好的權衡。
你將通過驗證來實現這種神奇的無狀態執行，區塊打包者將在每個區塊中包含正確狀態訪問的證明。驗證一個區塊實際上不需要完整的狀態，而只需要該區塊中正在被讀取的或受區塊中交易影響的狀態。區塊打包者將在一個給定的區塊中包含受交易影響的狀態片段，並通過驗證人來證明他們正確地訪問了這些狀態。
舉個例子：Alice 想給 Bob 發送 1 個 ETH。為了驗證包含這個交易的區塊，我需要知道:
- 交易之前—— Alice 有 1 個 ETH
- Alice 的公鑰—— 由此得知簽名是正確的
- Alice 的隨機數—— 由此得知交易是以正確的順序發送的
- 執行交易後—— Bob 多了 1 個 ETH，Alice 少了 1 個 ETH
在弱無狀態的世界中，區塊打包者將上述見證數據和其相應的準確性證明添加到區塊中。驗證者收到區塊，執行它，並決定它是否有效。就是這樣！
以下是從驗證者角度得出的一些結論:
- 保持狀態的巨大的 SSD 需求消失了—— 這是如今擴展面臨的關鍵瓶頸
- 帶寬需求會增加一些，因為現在仍然需要下載見證數據和證明。這是 Merkle-Patricia 樹的一個小瓶頸，但不是 Verkle tries 的瓶頸。
- 你仍然執行交易以完全驗證。無狀態並不是當前擴展以太坊的瓶頸。
由於狀態膨脹不再是一個緊迫的問題，弱無狀態也允許以太坊放寬對其執行吞吐量的自我限制，所以將 gas 限制提高 3 倍是合理的。
在這一點上，大多數用戶執行將在 L2 上進行，但更高的 L1 吞吐量也會對他們有利。Rollups 依靠以太坊進行數據可用性（發佈到分片）和結算（需要 L1 執行）。隨著以太坊擴展其數據可用性層，發布證明的攤銷成本可能會佔據 rollups 成本的更大份額（特別是對於 ZK-rollup）。
Verkle Tries
我們掩蓋了這些見證的工作原理。以太坊目前使用 Merkle-Patricia 樹來表示狀態，但所需的 Merkle 證明對這些證人來說太大了，是切實不可行的。
以太坊將轉向 Verkle tries 來存儲狀態，Verkle 證明的效率要高得多，所以它們可以作為可行的見證來實現弱無狀態。
首先回顧一下 Merkle 樹是什麼：每筆交易開始時都會進行哈希計算—— 位於底部的哈希被稱為"葉子"，所有的哈希都可被稱為"節點"，每一個哈希都是是其下面兩個"子"節點的哈希。最終產生的哈希即"Merkle 根"。
這是一個用於證明包含交易的數據結構，但無需下載整個樹。例如，你只需要 Merkle 證明中的 H12、H3 和 H5678 就可以驗證交易 H4 被包含。我們有來自區塊頭的 H12345678，所以一個輕客戶端可以向一個全節點索取這些哈希，然後根據樹中的路由將這些值一起進行哈希計算。如果結果是 H12345678，那麼我們就成功證明了 H4 在樹中。
不過樹越深，到底部的路由就越長，因此你需要更多的項來證明。所以淺而寬的樹更有助於高效證明。
問題是，如果通過在每個節點下添加更多的子節點來擴寬 Merkle 樹將是非常低效的，因為需要把所有兄弟哈希放在一起，以沿著樹向上移動，因此需要為 Merkle 證明接收更多的兄弟哈希。這會使證明變得非常大。
這裡就是高效向量承諾的用武之地。請注意，Merkle 樹中使用的哈希實際上是僅能有效承諾兩個元素的向量承諾，而我們想要的是無需所有兄弟哈希來進行驗證的、可以使樹變寬並減少其深度向量承諾，這也就是我們如何獲得高效的證明大小的方法，即減少需要提供的信息量。
Verkle trie 類似於 Merkle 樹，但是它使用高效向量承諾（因此得名"Verkle"）而不是簡單的哈希來承諾其子代。因此，基本上每個節點可以擁有許多子節點，但無需所有子節點都驗證證明。無論寬度如何，這都是一個恆定大小的證明。
實際上，前文提到的 KZG 承諾也可以作為向量承諾使用，且以太坊開發者最初本就計劃在這裡使用 KZG 承諾，只是他們後來轉向了用以履行類似角色的 Pedersen 承諾。這些承諾將基於一個橢圓曲線（在本例中是 Bandersnatch），並將承諾 256 個值（比只承諾兩個元素好太多了！）。
那麼，為什麼不建立一個深且盡可能寬的樹呢？這對現在擁有緊湊證明的驗證者來說是件好事。但是這裡有一個需要實際考慮的權衡，即證明者需要能夠計算該證明，但樹越寬計算就越難。因此，這些 Verkle tries 將位於兩個極端之間，寬度為 256 個值。
狀態逾期
弱無狀態性消除了驗證者的狀態膨脹約束，但狀態並不會神奇地消失。交易的成本是有限的，但它們通過增加狀態給網絡帶來了永久的稅收。狀態增長仍然是對網絡的一種永久性拖累，需要採取一些措施來解決根本問題。
長期（比如一年或兩年）不活躍的狀態甚至會從區塊創建者需要攜帶的東西中被砍掉，而活躍的用戶不會注意到這些事情，也就不需要無用的狀態，它們可以被刪除。
如果你需要恢復逾期的狀態，你只需要出示一個證明以激活它，這又回到了 N 選 1 存儲假設，即只要有人仍然擁有完整的歷史（區塊探索者，等等），你就可以從他們那裡得到你需要的東西。
弱無狀態將削弱基礎層對狀態逾期的迫切需求，從長遠來看，特別是隨著 L1 吞吐量的增加，這是好事情。對於高吞吐量的 rollups，這將是一個更有用的工具，因為 L2 狀態將以更高指數級速率增長甚至成為高性能創建者的拖累。
第三部分：MEV
PBS 對於安全實現 Danksharding 來說非常必要，但它最初的設計其實是為了對抗 MEV 的中心化力量，畢竟如今在以太坊研究中反復出現的一個趨勢即 MEV 是目前加密貨幣經濟學的前沿和中心。
在設計區塊鏈時考慮到 MEV，對於維護安全和去中心化都至關重要。協議層的基本方法是：
- 盡可能減輕有害的 MEV（例如，單槽最終確定性，單一的秘密領導人選舉）
- 將剩餘部分民主化（例如，MEV-Boost、PBS、MEV smoothing）。
其中，剩餘部分必須能很容易地被捕獲並在驗證者中傳播，否則，由於無法與復雜的搜索者競爭而使驗證者集中心化。另外，合併後， MEV 將進一步佔領驗證者獎勵中更高的份額（質押發行量遠低於礦工獲得的通脹），所以驗證者中心化地問題不容忽視的。
當前的 MEV 供應鏈
當前的事件順序看起來是這樣的：
礦池在這裡扮演了區塊打包者的角色。MEV 檢索器通過 Flashbots 將捆綁的交易（連同他們各自的出價）轉交到礦池。礦池運營商聚合一個完整的區塊，並沿著區塊頭傳遞給各個礦工。礦工通過 PoW 在分叉選擇規則中賦予其權重來證明這一點。
Flashbots 的出現是為了防止將為審查和其它不利外部因素打開大門的跨堆棧垂直整合。當 Flashbots 開始時，礦池已經開始與交易公司達成獨家交易來提取 MEV。相反，Flashbots 為他們提供了一種聚合 MEV 競價和避免垂直整合（通過 MEV-geth 實現）的簡單方法。
合併之後礦池就會消失。家用驗證者通常不似擁有一堆量化分析師的對沖基金那樣擅長捕捉 MEV，如果不加以約束，在普通人無法與之競爭的情況下，這將中心化驗證者集的力量。但如果結構合理，該協議可以將 MEV 收入重新定向給日常驗證者的質押收益。所以我們希望有途徑可以讓家用驗證者合理地運營，這需要找能夠承擔特定的構建角色的人。
MEV-Boost
不幸的是，協議內的 PBS 在合併時根本無法做好準備。Flashbots 再次提供了一個過度解決方案：MEV-Boost 。
合併後的驗證者將默認為直接接收公共存儲池中的交易到它們的執行客戶端。他們可以將這些交易打包提交給共識客戶端然後廣播到網絡。(文章第四部分將介紹以太坊的共識和執行客戶端是如何一起工作的）。
但是父母輩和常見的驗證者並不知道如何提取我們討論的 MEV，Flashbots 為此提供了替代方案，即 MEV-boost 將嵌入你的共識客戶端，允許你外包特定的區塊構建。重要的是，此時你仍可以選擇使用自己的執行客戶端作為後備。
MEV 檢索器將繼續發揮它們今天已有的作用，運行特定的策略（統計套利、原子套利、三明治套利等），並競標他們需要納入的捆綁。然後，區塊打包者將他們看到的所有捆綁以及任何私人訂單流（例如，來自 Flashbots Protect）匯總到最佳完整區塊中，他們通過運行在 MEV-Boost 上的中繼器者把區塊頭傳遞給驗證者。Flashbots 將運行中繼者和區塊打包者，併計劃隨著時間的推移逐漸去中心化，但為其它區塊打包者開放白名單可能會慢很多。
MEV-Boost 要求驗證者信任中繼者—— 共識客戶端收到區塊頭並對其簽名，然後才顯示區塊體。中繼者的目的是向出塊者證明體區塊體是存在且有效的，如此驗證者就不必直接信任區塊打包者。
當協議內 PBS 準備就緒，它就會編碼 MEV-Boost 在這期間提供的內容。PBS 提供了同樣的權力分離，它使得的區塊打包者更容易去中心化，以及出塊者無需要信任任何人。
委員會驅動的 MEV 均勻分配
PBS 為另一個很酷的想法提供了支持—— 委員會驅動的 MEV 均勻分配。
我們看到提取 MEV 的能力是中心化驗證者集的一種力量，但對分發也是如此。從一個區塊到另一個區塊的 MEV 獎勵的高可變性，激勵著許多驗證者來均勻分配你的回報（正如我們今天在礦池中看到的，儘管在這里程度較低）。
默認的做法是區塊打包者將全額付款給實際的區塊出塊者，MEV smoothing 將把這筆付款分配給許多驗證者。一個驗證委員會將檢查被提議的區塊，並認證該區塊是否為出價最高的區塊。如果一切順利，將繼續生成區塊，且獎勵將分配給委員會和出塊者。
這也解決了帶外行賄問題，即出塊者可能會被激勵提交一個次優區塊，然後直接接受帶外賄賂，以向隱藏它們收到的帶外賄款。而這種認證（驗證委員會認證區塊是否為出價最高區塊的行為）可以使出塊者受到約束。
協議內 PBS 是實現 MEV 均勻分配的先決條件。你需要對區塊打包者市場和提交的標書有所了解。雖然這裡有幾個開放待解決的研究問題，但這依然是一個令人興奮的提議，因為它對確保驗證者去中心化來說至關重要。
單槽最終確定性
快速的最終確定性是非常棒的，等待~15 分鐘對於用戶體驗或跨鏈通信來說都是次優選擇。更重要的是，快速最終確定性是一個 MEV 重組問題。
合併後的以太坊將會提供比今天更強大的確認—— 成千上萬的驗證者認證每個區塊，以及礦工可在同一區塊高度競爭和挖礦但無需投票。如此使得鏈重組幾乎不可能實現，但仍然不是真正的最終確定性。如果最後一個區塊有一些有報酬豐厚的 MEV，你可能會引誘驗證者嘗試鏈重組，並將其竊為己有。
單槽最終確定性消除了這種威脅，逆轉一個已完成最終確定性的區塊需要至少三分之一的驗證者，且他們的質押會立即被削減（數百萬的 ETH）。
在這裡我們不過多地討論潛在的機制。只需要知道，在以太坊的路線圖中，單槽最終確定性在很久以後才會被考慮進來，以及它是一個非常開放的設計空間。
在今天的共識協議中（沒有單槽最終確定性），以太坊只需要 1/32 的驗證者來認證每個槽（即目前超過 38 萬的驗證者中，約有 12000 個驗證者來認證每個槽）。在單槽中用 BLS 簽名聚合將這種投票擴展到全部的驗證者集需要做更多的工作—— 把數十萬次投票壓縮到一個驗證中：
Vitalik 在文後鏈接 [5] 中詳解了一些有趣的解決方案。
單一秘密領袖選舉
單一秘密領袖選舉（SSLE: Single Secret Leader Election）試圖修補我們在合併後將面臨的另一個 MEV 攻擊矢量。
信標鏈驗證者名單和即將發布的領導者選舉名單都是公開的，很容易對他們進行去匿名化處理以及映射他們的 IP 地址。
更成熟的驗證者可以使用一些技巧來更好地隱藏自己，但是小型驗證者特別容易受到信息洩露和 DDOS 的影響，這很容易被 MEV 所利用。
假設你是第 n 個區塊的出塊者，我是第 n+1 個區塊的出塊者，如果我知道你的 IP 地址，我可以很便宜地向你發動能致使你超時從而無法生產區塊的 DDOS 攻擊，如此我便可以獲得我們倆的槽的 MEV ，使我的回報加倍。EIP-1559 的彈性塊大小加劇了這個問題，由於 EIP-1559 每個塊的最大 gas 是目標規格的兩倍，所以我可以把本應該是兩個塊的交易塞到屬於我的、是原來兩倍大的單個塊中。
簡而言之，家用驗證者可能會放棄的驗證，因為家用驗證者容易受到攻擊，可能會驗證失敗。SSLE 使得除了出塊者之外沒有人知道什麼時候該輪到他們來阻止這種攻擊。這在合併時還無法實現，但希望在合併後不久可以實現。
第四部分- 合併：工作原理
我認為並希望合併即將到來。
合併是無法忽視的，沒有人會對其置若罔聞，我覺得我也有可以做一些簡單的發聲：
合併後的客戶端
如今，你運行的是一個處理所有交易的單片單體客戶端（如 Go Ethereum、Nethermind 等）。具體來說，全節點做這兩件事：
- 執行：執行區塊中的每個交易，以確保有效性。採取前狀態根，執行一切，並檢查產生的後狀態根是否正確。
- 共識：驗證你處在完成了最多工作的、最重的（最高 PoW）鏈上，即中本聰共識。
它們是不可分割的，因為全節點不僅遵循最重的鏈，而且遵循最重的有效鏈。這就是為什麼他們是全節點而不是輕節點。即使在 51% 的攻擊下，全節點也不會接受無效的交易。
信標鏈目前不運行執行，只運行共識以提供給 PoS 一個測試運行環境。最終，決定一個終端總難度的時刻將是以太坊執行區塊合併到信標鏈區塊中形成一條鏈的時刻：
然而，全節點本質上將運行兩個獨立的可以互操作的客戶端：
- 執行客戶端（又名"Eth 1.0 客戶端"）：當前的 Eth 1.0 客戶端繼續處理執行。他們處理區塊，維護內存池，管理和同步狀態，撕掉 PoW 的基本特質。
- 共識客戶端（又名"Eth 2.0 客戶端"）：當前的信標鏈客戶端繼續處理 PoS 共識。他們跟踪鏈頭，廣播和認證區塊，並接收驗證者的獎勵。
客戶端收到信標鏈區塊，執行客戶端運行交易，如果一切順利共識客戶端將遵循該鏈。所有的客戶端都是可互操作的，你將能夠混合或匹配你所選擇的執行客戶端和共識客戶端。一個新的用於客戶端之間通信的引擎 API 將被引入：
或者：
合併後的共識
如今的中本共聰共識很簡單：礦工創建新的區塊，並將其添加到觀察到的最重的有效鏈上。
合併後的以太坊轉向 GASPER —— 結合 Casper FFG（最終確定性工具）和 LMD GHOST（分岔選擇規則）來達成共識。這裡簡而言之是一個側重於活性但不側重於安全性的共識。
區別在於，支持安全的共識算法（如 Tendermint）在無法獲得必要的票數（驗證者集的⅔）時就會停止。支持活性的鏈（如 PoW + 中本聰共識）無論如何都會繼續建立一個樂觀的賬本，但如果沒有足夠的票數，它們就無法獲得最終確定性。今天的比特幣和以太坊只是假設在足夠多的區塊之後不會發生重構，永遠不會獲得最終確定性。
然而，以太坊也會在票數足夠的情況下通過檢查點來階段性的實現最終確定性。每 32 個 ETH 實例就是一個獨立的驗證者，目前已經有超過 38 萬個信標鏈驗證者。週期由 32 個槽組成，所有驗證者被分離開來，以在給定的周期內對一個槽進行認證（也就是說每個槽有~12000 個認證）。緊接著，分岔選擇規則 LMD Ghost 根據這些證明來確定鏈現在的頭。每個槽（12 秒）都會增加一個新的區塊，所以周期是 6.4 分鐘。通常在兩個週期後（即每 64 個槽，儘管有時可能需要 95 個槽），就會獲得必要的票數以實現最終確定性。
結論
所有的道路都通向中心化區塊生成、去中心化無信任的區塊驗證和抗審查。以太坊的路線圖已經瞄準了這一願景。
以太坊的目標是成為統一的數據可用和結算層—— 在最大限度地去中心化和安全的基礎上實現可擴展計算
我希望你對以太坊的研究是如何交織在一起的有了更清晰的認識，它有如此多非常簡短的、正在開發的組件，它們各自都有一個非常大情景需要你去理解。
從根本上說，這一切都回到了那個獨一無二的願景。以太坊為我們提供了一條令人信服的通往大規模可擴展的道路，與此同時也珍視我們在這個領域非常關心的那些價值。
擴展閱讀
[1] A Primer on Elliptic Curve Cryptographyhttps://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
[2] Exploring Elliptic Curve Pairings ——Vitalikhttps://vitalik.ca/general/2017/01/14/exploring_ecp.html
[3] KZG polynomial commitments —— Dankradhttps://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html
[4] How do trusted setups work? —— Vitalikhttps://vitalik.ca/general/2022/03/14/trusteDankshardingetup.html
[5] 單槽最終確定性解決方案詳解—— Vitalikhttps://notes.ethereum.org/@vbuterin/single_slot_finality
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
