開發者必看！以太坊ERC-4337實戰解密，多鏈同步難題有解了？

---

Layer2 與 Layer1 的同步挑戰

今天 ETH Taipei 邀請 imToken Labs 的開發者 Alfred Lu 就 ERC-4337 進行分享，當我們探討以太坊 Layer2（第二層）解決方案實現 ERC-4337 標準時，經常會遇到同步問題。許多開發者潛意識中認為 ERC-4337 在以太坊主網和各 Layer2 上的實現應該完全一致，但實際情況並非如此。

技術差異、協議不同和同步變化都可能導致實現上的不一致。例如，使用者需要處理不同的 EIP、不同的合約結構與執行機制，這意味著你無法簡單地同時向兩個網路發送相同的交易來操作兩個網路上的帳戶。

過去從 EOA（外部擁有帳戶）的角度看，我們在不同鏈上共享相同的地址和相同的協議，即使狀態沒有同步，相同的私鑰仍能確保帳戶的授權一致性。但在 ERC-4337 帳戶時代，不僅資產配置不同，帳戶地址可能不同，授權方法也會有差異，擁有權狀態可能不同步。

這種同步問題在所有權變更時尤為明顯。當使用者想要更改帳戶所有權時，如何確保在所有鏈上同步更新？這通常涉及調用「轉移所有權」功能來修改智能合約帳戶中的所有權存儲變數。

但如果該更改只在一條鏈上生效而在另一條鏈上沒有更新，會發生什麼情況？這個問題在兩種情境下特別突出：當更改簽名驗證方法（例如從 passkey 切換到多重簽名）時，以及當使用者控制金鑰丟失需要恢復帳戶時。關鍵問題是：是否有平台可以自動更新授權，使多鏈帳戶管理更容易？

---

地址不一致性問題

為什麼地址問題會成為一個重要議題？這是因為從 EOA 的角度來看，使用者期望他們在不同鏈上的帳戶地址保持一致。如果使用者沒有意識到這一點，可能會將資產發送到他們無法控制的接收地址，導致資產風險。某些 dApp 也假設在兩個節點之間有相同的地址，如果使用者沒有仔細檢查接收地址，同樣會造成交易風險。此外，當使用者註冊 ENS（以太坊名稱服務）時，也應該仔細檢查註冊地址。

地址差異主要是由於不同鏈之間的協議差異造成的，例如：Layer2 是否以完全兼容的方式遵循 Layer1 硬分叉，Layer2 是否支持某些操作碼，以及是否支持成為合約的 EIP。不僅 Layer2 會導致差異，Layer1 也可能不支持某些 Layer2 特有的功能，如 danksharding 使用不同的編碼方法等。

過去這不是一個嚴重問題，因為像 Merge 這樣的更新只影響少數智能合約，但新的操作碼如 PUSH0（由一些硬分叉引入）幾乎會影響以太坊上的每個合約，而 ERC-4337 更強調了一致地址的重要性。一些 EIP 如 EIP-3855 引入了 PUSH0 操作碼，某些鏈和工具最初可能不支持這些操作碼。如果想避免生成 PUSH0，開發者應指定 EVM 版本和編譯器版本以維持地址一致性，即使高級代碼是一致的。EIP-1153 也引入了新的操作碼，但影響不如 PUSH0 廣泛，因為當前的 Solidity 編譯器不允許將暫態存儲作為數據存儲。

---

實用解決方案與未來發展

如何解決這些問題？對於多鏈帳戶管理，開發者可以嘗試「一次簽名」的方法，讓使用者只需簽名一次，便可在多條鏈上進行操作，而不必為每條鏈簽署多個使用者操作。目前有兩種實現方式：

• Coinbase 的方法，忽略使用者操作哈希中的鏈 ID 欄位；

• Zerodev 方法，將多個操作哈希組合成單一 Merkle 根，使用者只需對這個 Merkle 根簽名即可。

這兩種方法都繞過了簽名驗證中的鏈 ID 限制，但方式不同：Coinbase 方法忽略了哈希中的鏈 ID 欄位，而 Zerodev 方法則在簽名中包含所有可能的鏈 ID。

另一個解決方案是錢包提供者的支持。如果使用網頁版錢包，需要數據庫來檢查使用者當前的認證方式，因為網頁認證需要記錄域名和設備信息。例如，如果在鏈 A 上有註冊而在鏈 B 上沒有，域名需要這個數據庫來記錄註冊情況。錢包還可以提供「一鍵同步」功能，識別所有鏈上的操作成員，幫助使用者了解他們應該做什麼。

對於地址問題，最簡單的解決方案是固定 EVM 版本和 Solidity 版本。例如，為了防止生成 PUSH0 操作碼，可以指定 0.8.9 作為以太坊虛擬機編譯器版本，並指定 Paris 作為目標版本。

你可能需要像 evm-diff 這樣的工具來了解 Layer2 之間的差異。但隨著硬分叉和新操作碼的增加，決策標準只會越來越多。長期解決方案是不要假設你的帳戶在所有鏈上都有相同的地址，這應該成為一個基本的心態轉變。開發者可以通過使用 ENS（以太坊名稱服務）來增強使用者體驗。

---

預付 Gas Fee 與服務可用性問題

對於預付 Gas Fee （paymaster gas）問題，ERC-4337 在 Layer2 上的實現更為複雜，因為 Layer2 交易費包括 Layer1 成本和 Layer2 成本。在探討如何從 Layer2 角度獲取合理的預付 Gas Fee 前，我們先了解 ERC-4337 中的打包交易（bundled transaction）機制。

在 ERC-4337 中，打包者（Bundler）通過調用入口點合約的 handleOps 函數發送使用者操作，這是一個包含驗證階段和執行階段的常規交易。這些 Gas 成本應由打包者支付，打包者再通過 PVG（pre-verification gas）欄位向使用者的合約收費。

PVG 包括兩部分：第一部分是在入口點合約中處理使用者操作的成本，如交易費用、存儲使用和代碼複制，以及記憶體使用成本（如果操作數據較多，需要支付更多的記憶體擴展成本）；第二部分是額外費用，可能包括為優先處理使用者操作而支付的補貼，以及讓打包者優先處理其交易的費用。這兩部分都必須考慮 Layer1 安全費用。

從長遠來看，RIP-7560 可以簡化計算，它定義了 post-runbundler 交易並用 builderFee 替代了 PVG 欄位，builderFee 代表 Layer1 費用，而 PVG 的內在部分則設置為基於常數的成本。但短期內，如果希望產品更穩定並獲得最佳收益，建立自己的打包器或與打包器建立業務夥伴關係可能是更好的選擇，因為 PVG 計算複雜，你可能會收取不合理的 Gas Fee 。

儘管面臨這些挑戰，ERC-4337 的實現正逐步推進。隨著基礎設施提供者、開發者和錢包團隊的共同努力，我們相信以太坊生態系統將朝著更智慧、更便捷的方向發展。