POW:以太坊合并之后，將面臨哪些監管問題和應用層問題？_以太坊交易所app下載

隨著以太坊Merge時間節點將至，今天我們將探討以太坊合并之后會面臨哪些監管問題和應用層問題。

2022年8月16日，以太坊聯合創始人VitalikButerin在推特上參與討論「若監管通過某些協議的驗證者者對以太坊進行協議級別的審查，以太坊社區將如何反應」這一話題時表示，會將這種審查視為對以太坊的攻擊，并選擇通過更廣泛共識將這些驗證者的質押權益進行銷毀。

引起這個討論的導火索在于：近期，美國財政部海外資產控制辦公室將與TornadoCash有關的以太坊地址添加到制裁實體的名單中。但是目前對其的制裁都是處于中心化層面的操作，對于涉及到去中心化的智能合約部分，尚無法進行技術制裁。

這表明如果美國要想要徹底制裁Tornadocash，就必須要控制底層的以太坊鏈。那么就引出一個問題，假如美國政府對以太坊進行監管，會面臨什么？

如果美國政府要對以太坊進行監管，最大的可能是要求大型PoS質押服務商對以太坊進行協議級別的交易審查。這并不是驗證者「作惡」，而是驗證者對鏈上地址的「針對性制裁」。

Web3前端開發庫wagmi推出以太坊TypeScript接口viem:金色財經報道，Web3前端開發庫wagmi推出以太坊TypeScript接口viem，重點關注穩定性、開發人員體驗、捆綁包大小和性能，旨在成為Ethers.js和web3.js的替代方案。[2023/3/7 12:46:54]

簡單來說，就是監控被制裁地址發出的所有請求，并將所有包含被制裁地址事務的區塊進行拒絕出塊即可，當一個區塊無法通過66%以上權益驗證投票通過時，該區塊的所有事務請求將會進行回滾，這也就意味著被制裁的地址將無法進行任何操作，并且驗證者不會面臨任何懲罰。

截至目前，以太坊全網質押的以太幣數量大約為1300多萬ETH，而通過Lido質押的以太幣數量已經占了約30.9%，Coinbase占了約14.7%，Kraken占了約8.5%。

如果美國政府要求Lido、Coinabse、Kraken為代表的大型節點驗證者對以太坊進行協議級別的交易審查，作為具有美國法律實體的質押服務商很難拒絕類似要求。

以太坊Goerli測試網將于8月11日合并:7月19日消息，ETH中文公眾號發文稱，以太坊Goerli測試網將于8月11日合并，其中Goerli合并的TTD（終結總難度）預計將在下個月初選定，預計Bellatrix升級可能會提前到8月4日，TTD出現在8月10日。此前報道，Goerli也是以太坊最后一個測試網合并，如果一切順利，主網合并計劃在9月19日進行。[2022/7/19 2:21:47]

DuneAnalytics

針對可能出現的上述情況，在以太坊社區在Twitter上發起了一項投票討論，如果OFAC通過驗證節點對以太坊實施監管該怎么做。V神支持將上述情況視為對以太坊的攻擊，并通過更廣泛共識將這些節點的質押權益進行銷毀。

下面，我們再來聊一聊應用層的問題。

我們在上一篇曾提到：按照計劃，以太坊的Merge以「最小破壞」原則進行，使原來運行的應用客戶端可以無感地切換到PoS。也就是說，盡管是「最小破壞」，但在這個過程中，有一些小的變化仍然值得我們注意。本節就主要從應用開發的角度介紹在合并后，我們應該關注的方面。

Messari：2021年波卡開發活動增加147%，高于以太坊、Cosmos和Solana:1月4日，Messari發布關于區塊鏈開發活動的分析報告，報告顯示，2021年波卡生態開發活動增長率達到147%，高于Cosmos（56%）、Solana（2%）和以太坊（21%）。

同時，波卡生態在2021年的開發活動有87%于去年12月進行。目前，以太坊仍具備最多的活躍開發者，其每個月活開發者數量達到250名，而波卡、Cosmos和Solana基本上都擁有50名左右的月活開發者。[2022/1/4 8:24:43]

合并后，當前的Eth1和Eth2客戶端將成為以太坊的執行層和共識層。這意味著Eth1或信標鏈客戶端的節點運營商將需要運行堆棧的「另一半」以獲得完全驗證的節點。下圖顯示了合并后完整的以太坊客戶端架構。

PoW鏈并等待它達到預定義的totaldifficulty閾值，該值被稱為TERMINAL_TOTAL_DIFFICULTY。即一旦PoW鏈產生了一個帶有totaldifficulty>=TERMINAL_TOTAL_DIFFICULTY的塊，它將被視為鏈上最后的一個PoW塊。

以太坊Ropsten測試網將首先激活倫敦升級:金色財經報道，以太坊開發者Tim Beiko今日發文宣布，以太坊倫敦升級現已準備好在測試網上部署。升級將首先在Ropsten測試網的區塊10499401激活，預計將于2021年6月24日左右進行；Goerli測試網將在區塊5062605激活升級，預計時間為6月30日；Rinkeby測試網將在區塊8897988激活，預計時間為7月7日。Kovan測試網將在稍后升級，預計在主網區塊通過之后。Tim Beiko還表示，截止目前，只有測試網（Ropsten、Goerli、Rinkeby）已安排了倫敦升級。在這些網絡上成功激活升級后，將為以太坊主網設置一個升級區塊。[2021/6/19 23:48:59]

隨后，PoW塊包含的數據將成為信標鏈塊的數據組成部分，而信標鏈則可以被視作為以太坊新的PoS共識層，取代之前的PoW共識層。

同時在進行共識驗證時，信標節點將與其執行引擎通信，并要求它生成或驗證ExecutionPayloads。ExecutionPayloads包含了父哈希、狀態根、基本費用和要執行的交易列表等信息。

動態 | 域名注冊商EnCirca推出以太坊地址注冊服務:據Cointelegraph消息，7月23日，互聯網域名注冊商EnCirca宣布，開始接收以太坊域名.ETH的申請，申請截止期為今年8月10日。與傳統的域名服務系統DNS類似，EnCirca的以太坊域名服務ENS也會通過人類刻度的名稱聯通字母和數字構成的以太坊地址。這些域名看上去和傳統的URL一樣，只不過聯通的是在區塊鏈鏈上或者鏈下的以太坊網頁。[2019/7/23]

一旦這些數據被生成或驗證，信標節點將與p2p網絡上的其他節點共享它們。

而對于終端用戶和應用程序開發人員來說，這些原來PoW鏈上的ExecutionPayloads仍然是他們與以太坊進行直接交互的位置，事務仍將由執行層客戶端處理，這使得他們可以無感切換到PoS鏈。下圖顯示了這種關系：

圖源自DannyRyan

執行引擎

合并之后，執行引擎主要負責狀態管理，區塊創建和驗證功能，而不再包含與共識相關的任何操作。因此，執行引擎被進行了部分修改，這些修改在EIP-3675中進行了描述，主要包含以下三點：

首先，修改了區塊的部分數據字段。將原有區塊中幾個僅與PoW相關的字段設置為0，具體包括與挖礦相關、叔塊獎勵相關。此外，extraData的長度在主網上也將被限制為32字節。

其次，由于只有合并后的信標鏈才能進行出塊，因此執行引擎將停止處理區塊和叔塊獎勵。但交易手續費仍由其進行處理，即當執行引擎創建一個ExecutionPayload時，需確保所有交易的發起者至少能夠支付當前baseFeePerGas的費用，并且將剩余的交易手續費發送到feeReceipient。注意，feeReceipient指的是升級前的以太坊地址，而不是信標鏈驗證者地址。

最后，一旦PoS取代PoW，執行引擎將不再負責廣播區塊，但仍會通過p2p網絡進行交易的廣播。具體過程為，首先用戶將交易通過本地的RPC請求發送到共識客戶端，在那里它們將被打包到信標塊中。然后，共識客戶端將在他們的p2p網絡中廣播信標塊。

下圖表明了以太坊合并時的過程：首先停止PoW出塊，其次信標鏈塊在合并后開始持有ExecutionPayload。

圖源自DannyRyan

BLOCKHASH&DIFFICULTY操作碼更改

合并后，BLOCKHASH操作碼仍可使用，但由于它不再通過工作量證明生成對應的Hash值，所以此操作碼提供的偽隨機性將被大大減弱。

與此同時，DIFFICULTY操作碼(0x44)將會更名為RANDOM并返回由信標鏈提供的隨機數值。因此，該值將替代BLOCKHASH成為應用程序開發人員可使用的更好隨機源。

RANDOM值將存儲在ExecutionPayload中原有mixHash的位置，該值與工作量證明計算相關。升級后該值被重命名為random。

下圖解釋了合并前后DIFFICULTY和RANDOM操作碼的工作原理：

圖源自DannyRyan

合并前，我們看到?0x44操作碼返回區塊頭里的difficulty字段。合并后，負責生成隨機數的RANDOM操作碼則指向原有mixHash字段，該字段被重名為random。

出塊時間

合并將影響以太坊的平均區塊時間。目前在PoW下，平均每約13秒產出一個區塊，但實際區塊間隔時間會由于網絡擁堵的情況，而存在相當大的差異。但在PoS下，區塊間隔為固定的12秒，除非發生某些極端情況，如：驗證者離線或未及時提交區塊而錯過了某個插槽。

綜上，升級后網絡的平均出塊時間將減少近1秒，這提高了交易的速率。注意：如果智能合約中存在與特定平均出塊時間相關的邏輯，則在計算時開發人員需要考慮到這一點。

參考文獻：

《升級前夕，以太坊社區面臨監管擔憂》

《HowTheMergeImpactsEthereum’sApplicationLayer》

原文鏈接

Tags：以太坊POWULTCULT以太坊交易所app下載POWER幣PLC Ultimaculturechain

Filecoin