LazyTower append 一個 item 的 amortized cost 是 O(1).

Proof 的 circuit complexity 是 O(log N). Verification cost 是 O(1).

核心觀念

Items 會從最底下的 level 被 append. 如果一層滿了, 就把整層 digest() 起來並 append 到上層. 這樣下層就又有空間可以容納新的 items. 我們以 width = 4 的 tower 為例, 請看影片:

藉由儲存

digest([0, 1, 2, 3])

這個值, 我們可以在之後證明 item 0 1 2 3 曾經被 append 過.

藉由儲存

digest([digest([0, 1, 2, 3]),
        digest([4, 5, 6, 7]),
        digest([8, 9, 10, 11]),
        digest([12, 13, 14, 15])])

這個值, 我們可以在之後證明 item 0 … 15 曾經被 append 過.

我們可以觀察到, tower 裡面儲存的每一格都是一個 Merkle root. 分別固定了 4⁰, 4¹, 4² … 個 item.

這一點可以從以下影片看的更清楚:

Cost

平均來說, 最下層在每 1 次 append item 會被修改到一次.
上一層在每 4 次 append item 會被修改到一次.
再上一層在每 16 次 append item 會被修改到一次.

由於每一層的寬度都相同, 操作也一樣, 所以如果最下層 append 的 cost (save 或 load+hash) 不會超過一個 constant C 的話, 每一個單層修改的 cost 也都不會超過同一個 C.

這樣平均來說, 一次 append 的 cost 不會超過

1 * C  +  1/4 * C  +  1/16 * C  + ...
= 1.333 C

Privacy

當我們想證明某個 item 曾經被 append 過, 但是又不想直接揭露是哪個 item 時, 可以用 zero-knowledge proof 來證明其 membership.

我們可以用傳統的 Merkle proof 證明一個 item 屬於 tower 中的某個單一的 root. 比方說: “我的 item 隱藏在 level 10 的第二個 root 的 4¹⁰ 個 item 之中”.

如果我們只 load 一個 root 來證明 membership 的話, 雖然不會一下暴露是明確的哪一個 item, 但範圍就會從全部的可能幾千萬個縮小到這個 root 下的 4¹⁰ 個了. 當我們希望保留完整的 privacy 時, 則應該把 tower 中所有的 roots 都 load 起來, 再證明其 membership. 但這樣需要 O(log N) 的 cost, 並不理想.

我們能不能用一個單一的值來 “固定” 這些 roots, 使得證明 membership 時只要 load 一個值就好呢? 也就是說, 我只要 load 這個值, 則當別人舉出一個 root 時, 我就可以確認這個 root 是原本 tower 眾多 root 中的一個呢?

我們分成 “水平/垂直” 兩階段來改進.

改進一: 水平的 level digests

前面提到, 當一個 level 裝滿時, 我們會將其 digest 起來存到上層去, 比方說用 digest([0, 1, 2, 3]) 這個值來 “固定” 0, 1, 2, 3. 如果我們選用的 digest function 可以 incremental 地計算, 則我們可以儲存最新的 digest 就好, 不用儲存 array of roots. 比方說, 我們可以採用 Merkle-Damgård construction, 搭配一個 ZK-friendly 的 hash function (如Poseidon hash):

digest([a]) = a
digest([a, b]) = H(a, b)
digest([a, b, c]) = H(H(a, b), c)
digest([a, b, c, d]) = H(H(H(a, b), c), d)
digest([a, b, c, d, e]) = H(H(H(H(a, b), c), d), e)
...

因為每一層都只會從最後面 append, 所以每次都是固定 load / hash / save / update length. 可以 incrementally 而不用從頭計算.

這樣在證明時, 每一層也只要 load 單一一個 level digest 就好.

但這樣我們仍然有 O(log N) 個值要 load 進 circuit 裡. 還有改進的空間嗎?

改進二: 垂直的 digest of digests

對於每個 level 的 digests, 我們可以垂直由上往下計算一個 digest of digests. 用這個值來固定所有 digests.

把頻繁更動的底層放在尾端, 這樣就可以藉由儲存 prefix 的結果來達成局部更新. 不用每次從頭計算.

也就是說, 我們會儲存這些值:

digest([d4]) = d4
digest([d4, d3]) = H(d4, d3)
digest([d4, d3, d2]) = H(H(d4, d3), d2)
digest([d4, d3, d2, d1]) = H(H(H(d4, d3), d2), d1)
digest([d4, d3, d2, d1, d0]) = H(H(H(H(d4, d3), d2), d1), d0)

當最下層的 d0 變了的時候, 我們可以不用整個重算 H(H(H(H(d4, d3), d2), d1), d0), 可以 load 先前儲存的 H(H(H(d4, d3), d2), d1), 再從後面局部更新 d0 進去.

當最下層的 d1 d0 變了的時候, 我們可以不用整個重算 H(H(H(H(d4, d3), d2), d1), d0), 可以 load H(H(d4, d3), d2), 再從後面局部更新 d1 d0 進去.

單一一層更新的 cost 也會是 constant. (load / hash / save)

One to Rule Them All

於是我們得到了一個 digest of digests, 可以固定每個 level 的 digest. 每個 level digest 又固定了該 level 的 roots. 每個 root 又固定了那棵 tree 的 leaves, 也就是當初加進去的 items.

這樣在證明時, 我們只要 load O(1) 的資料就好了.

1. 每層的 cost 仍然可以用一個共用的 constant bound 住
2. 越上層修改的頻率越低 (exponentially)

因此新增 item 的 amortized cost 仍然是 O(1).

實作

以下我們觀察實作的結果.

我們可以看到, 新增 item 的平均 gas 的確很快收斂到 constant. (21000 included)

而使用 width 較大的 tower, 平均的 gas 也較低, 但有其極限.

和 Incremental Merkle Tree 相比, 即便要容納大量的 items, 使用者也不用擔心 gas 上升. 甚至也不用在一開始就決定容量上限.

雖然提高 width 能稍微降低 gas, 但也會增加證明時的 circuit complexity.

Deploy 時通常會將 gas 和 circuit complexity 一起考慮. Width 取 4 到 7 是不錯的選擇.

結語

LazyTower 平均花費的 gas 是 O(1), Circuit complexity 為 O(log N), 且不用一開始就決定容量. 使用 Merkle Tree 的專案都可以考慮使用 LazyTower.

Acknowledgement

我在 2023 年初有了初步的想法. 感謝 Ethereum Foundation 的 grant 讓我完成實作. 也感謝 reviewer 們的幫助!

實作目前由 PSE team 維護. 採 open source license 釋出.

• Javascript: https://github.com/privacy-scaling-explorations/zk-kit
• Solidity: https://github.com/privacy-scaling-explorations/zk-kit.solidity
• Circom: https://github.com/privacy-scaling-explorations/zk-kit.circom

感謝 Taipei Ethereum Meetup 的 Martinet Lee 的審閱.

英文版: https://ethresear.ch/t/lazytower-an-o-1-replacement-for-incremental-merkle-trees/21683

LazyTower: An O(1) Replacement for Incremental Merkle Trees was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

平常的丟銅板

(一陣討論之後)

A: … 那不然來丟銅板好了, 猜錯請客.

B: 好喔. 你猜我丟.

A: 我猜… 正面.

B: (丟) 反面.

A: 好吧, 我請客.

隔牆丟銅板

上面是平常的版本. 如果場景改成 A B 中間隔著一道牆呢?

B: 好喔. 你猜我丟.

A: (喊過去) 我猜正面!

B: (喊回去) 我丟出反面!

A: (…好像哪裡怪怪的)

這裡有個問題: 要是 B 壞心, A 猜正面 B 就說反面, A 猜反面 B 就說正面, 那不是永遠都是 A 請客了? 😅

來換個方法.

B: 好喔. 你猜我丟.

A: (把 “正面” 寫在紙條上, 鎖在小盒子裡, 從牆頭丟過去)

B: (喊回去) 我丟正面!

A: (把鑰匙丟過牆頭) “看來你要請客囉!”

B: (打開盒子看到 “正面”)

B: 好啦好啦! 我請客!

或者也可能是:

A: (把裝著 “正面” 的小盒子丟過去)

B: (喊回去) 我丟反面!

A: (把鑰匙丟過牆頭) “好啦好啦! 我請客!”

為什麼這時候 A B 都甘願了?

A 想: 先前我不甘願, 是因為 B 先知道我猜什麼的話, 就可以和我唱反調, 讓結果傾向對他有利的那邊. 但是現在他看不到我猜什麼了, 也就不知道要傾向哪一邊, 所以我願意接受這個玩法.

這個 “看不到” 的特性, 我們把它叫做 “hiding”.

B想: A 猜什麼已經先鎖在盒子裡了. 只要盒子沒有機關 (比方說 A 聽到正面就丟個能開出正面的鑰匙過來, 聽到反面就丟個能開出反面的鑰匙過來), 不會變來變去, 那我也願意接受這過玩法.

這個 “不會變來變去” 的特性, 我們把它叫做 “binding”.

A 把箱子丟過去, 這個動作我們把它叫 commit, 而裝著紙條的箱子叫做 commitment.

A 把鑰匙丟過去, B 打開相信了某件事, 這件事的內容(“A猜正面”)叫做 opening, 而鑰匙則是 proof.

隔網路丟銅板

場景再改一改: 如果 A 和 B 不是隔著牆, 而是隔著網路呢?

這時候 “盒子” 就有很多種設計了. 我們先想一個基本的: hash.

正面 0, 反面 1.

如果 A 只是直接拿 hash(0), hash(1) 給 B 看, 固定就是那兩個值的話, B 一看就知道了, 這樣沒有 hiding 的效果. 所以可以讓 A 先從很大的範圍 random 取個整數 x, 偶數正面奇數反面, 把 hash(x) 當成 commitment 送給 B. 這樣 B 拿到範圍也很大的 hash(x) 時, 應該猜不出 x 的奇偶 (hiding), 也就不能作怪.

再來 B 投了銅板之後, A 把 x 傳給 B, 讓 B 去 hash 確認. B 為什麼會甘願呢? 因為 B 相信目前沒有人能夠輕易地找出另一個 x’, 讓 x’ 也 hash 到原先的 hash(x), 也就是 A 沒辦法在聽到 B 說什麼之後又變來變去 (binding), 所以 B 也甘願.

另一種方法是: A 拿 0 或 1 配上一個 random number 一起去 hash, 將來再把 0 1 和 random number 開給 B 看, 也有一樣的效果.

Merkle Tree: Hash 又 Hash

再推遠一點: 前面 A 給 B 一個 commitment 之後, 後來可以讓 B 願意相信單一某件事 (單個 opening). 那, 有沒有辦法讓 B 相信多件事呢? (多個 opening)

假設 A 想後來讓 B 相信 p q r s. 最簡單的就是先把 hash(p, q, r, s) 送給 B, 之後再把 p q r s 給 B 看, B 就會相信. 但是有些應用我們不想讓 B 一次知道那麼多, 或者 p q r s 很多很大, 不想傳那麼巨量的資料給 B 的話, 我們可以改用另一個設計: Merkle Tree.

A 先拿 ROOT 當成 commitment 送給 B.

之後如果 A 想讓 B 相信 q , 那 A 可以提供 q, HP, HHRHS 給 B. 讓 B 自己先計算出 HQ, HHPHQ . 然後從上往下看:

A: 我說 HHPHQ 沒有變來變去, 你相信嗎?

B: 嗯… 我相信. 因為目前沒有人可以在固定 hash(y, z) 的值的狀況下, 給出另一組 y’ z’ 讓他也 hash 到 hash(y, z). 所以在固定 ROOT 的值的狀況下, 現在的 HHPHQ 和 HHRHS 應該是你先前算好沒有變來變去的. 好, 我相信 HHPHQ.

A: 那我說 HQ 沒有變來變去, 你相信嗎?

B: 嗯… 我相信. 因為目前沒有人可以在固定 hash(y, z) 的值的狀況下, 給出另一組 y’ z’ 讓他也 hash 到 hash(y, z). 所以在固定 HHPHQ 的值的狀況下, 現在的 HP 和 HQ 應該是你先前算好沒有變來變去的. 我相信 HQ.

A: 那我說 q 沒有變來變去, 你相信嗎?

B: 嗯… 我相信. 因為目前沒有人可以在固定 hash(x) 的值的狀況下, 給出另一個 x’ 讓他也 hash 到 hash(x). 所以固定了 HQ, 我相信 q 沒有變來變去.

所以, 如果有 N 個資訊想要將來讓 B 相信, A 可以把這個 hash 又 hash 的 tree 的 root 給 B 當成 commitment 固定住. 將來 A 想要和 B 開箱下面某個單一值的時候, 不用把所有底下的值 (p q r s) 都露給 B 看, B 就會願意相信 A, 且 A 給的 proof 只要大約 log(N) 的大小.

多項式

數學家還弄出了這樣的東西 (比方說 KZG10 演算法): 如果 A 想要讓 B 將來相信 x1, x2 … xN 能對應到 y1, y2 … yN, 那麼 A 可以造出一個穿過 (x1, y1), (x2, y2) … (xN, yN) 的多項式 P, 也就是 P(x1) = y1, P(x2) = y2 … P(xN) = yN, 然後給 B 一個關於這個多項式的 commitment 固定住. 將來有需要的時候, A 可以單獨開某個點, 讓 B 願意相信比方說 P(x3) = y3, 而且 B 不會因此知道其他點的資訊.

這邊 A 給的 commitment 和 Merkle tree 的做法一樣好, 是和 N 無關的常數大小. 而 A 每次給 B 的 proof 則比 Merkle tree 的 log(N) 厲害, 只要常數大小的資料就可以做到. 甚至一次開多個點所需的額外 proof 也只要常數大小. 因此對一些很計較大小的場合特別有用.

尾聲

從丟銅板的例子中, 我們可以體會到 hiding / binding 的動機, 也看到一些不同 commitment 方式的實作. 希望這個例子將來可以幫助你回想起這些觀念.

(感謝 吳秉宸 與 Chih-Cheng Liang 的審閱與建議)

參考資料:

Blum81: Coin Flipping by Telephone: A Protocol for Solving Impossible Problems

Manuel Blum

KZG10: Constant-Size Commitments to Polynomials and Their Applications

淺談 Commitment was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

在上一篇中, 我們實驗了如何用 CREATE2 原地換 code. 這篇我們則用 CREATE2 搭配 CREATE 來原地換 code (不用 assembly).

觀念

廣泛地說, 能原地換 code 的條件是:

1. 有自爆能力: contract 直接呼叫 SELFDESTRUCT, 或透過不論幾層 CALLCODE / DELEGATECALL 呼叫到 SELFDESTRUCT, 就有能力自爆.
2. 能重複 deploy 到同一個 address: contract 如果有個祖先是用 CREATE2 生出來的, 而自己和中間的祖先都可自爆的話, 即便這些 contract 只是用普通 CREATE 生出來的, 也會因為 parent 的 nonce 被自爆重置而可以重複 deploy 到相同的 address, 產生原地換 code 的效果.

觀念細節

以上圖為例: contract C2 含有 SELFDESTRUCT 所以可以直接自爆, 而 C1 C3 因為能讓 SELFDESTRUCT 在其 address 發生, 所以即便 contract 裡面沒有 SELFDESTRUCT 也能間接自爆.

自爆後, 要怎麼重複 deploy 到同一個 address 呢? 我們回顧一下決定 contract address 的規則:

傳統 CREATE / contract creation transaction 的 new contract address:
    function addr(sender_address, nonce)

CREATE2 的 new contract address:
    function addr(sender_address, salt, init_code)

上圖中, C0 生 C1 用的是 CREATE2, 所以第二次只要指定和上次一樣的 init code 和 salt, 就能從 addr0 再次用 CREATE2 deploy 到 addr1. (重要的起點)

上圖中, C1 生 C2 用的是 CREATE. 由於 CREATE 只看 sender address 和 nonce, 而 addr1 的 nonce 會在自爆後重置, 所以只要 addr1 的 nonce 又遞增到和當初生 C2 時相同的值, 就可以從 addr1 再次用 CREATE deploy 到 addr2.

同理, 也可以從 addr2 再次用 CREATE deploy 到 addr3.

C1 C2 C3 重生的內容都可以和原來不一樣.

而且因為影響 CREATE address 的是 nonce 而不是 init code, 所以重新 deploy 時可以用完全不同的 init code. 也就是在 Solidity 中第二次只要 new 不同的 contract, 就能達到原地換 code 的效果.

實作

自爆 (SELFDESTRUCT)

上一篇我們用的是直接自爆. 這邊我們確認一下多層 Delegate Call 間接自爆的效果:

用這段 code 驅動: 先 deploy DCDCBomb 並給它 value 42, 再 trigger fallback() 間接自爆.

從輸出來觀察 contract DCDCBomb account 的變化:

可以看到 DCDCBomb 的 nonce / balance / storage / code 全都被間接呼叫的 SELFDESTRUCT 清空了, 相當乾淨.

重複 deploy 到同一個 address 並換 code

前面驗證過了間接自爆, 下面的 code 就回到簡單直接自爆, 把重點放在怎麼重複 deploy 到同一個 address 上.

我們用 Solidity 實驗如下圖中置換 C2 成 Cafe, C3 成 Babe 的場景:

1. 生成 C1 -> C2 -> C3
2. 讓 C1 C2 C3 自爆
3. 生成 C1 -> Cafe -> Babe 在相同的 addresses 上

仔細觀察 Step 3.

先從 C0 重新 CREATE2 回 C1 : 在上文中我們已經實驗過用 CREATE2 原地換 code, 這次就僅用 CREATE2 生回相同的內容 (所以不用 assembly).重複給一樣的 init code 和 salt, 就能再生到 addr1. 我們可以在 Solidity 中用這樣的句型來叫用 CREATE2 :

new C1{salt: 0}()

再來把 C2 換成 Cafe: 因為 CREATE 看 nonce 不看 init, 而 addr1 的 nonce 被自爆重置了, 所以這邊簡單把 new C2() 改成 new Cafe() 就能把 addr2 的 code 從 C2 原地換成 Cafe.

把 C3 換成 Babe 也是一樣的道理: addr2 的 nonce 被重置了, 所以把 new C3() 改成 new Babe() 就能把 addr3 的 code 從 C3 原地換成 Babe.

用這段 code 執行上面的 contract, 就可以看到 contract C1 C2 C3 被建立, 被清空, 最後又在原地替換成 contract C1 Cafe Babe:

換 code 的影響與應對

從以上的例子可以看到, 不光是 CREATE2 生出的 contract 會被原地換 code, 只要滿足自爆和重生的條件, 連 CREATE 生出來的也有機會換 code.

那麼, 如果我們仔細檢查了某 address 的 source code 是個自動販賣機, 會不會真正投錢進去之後, 才發現把錢丟進了吃角子老虎裡面了呢?

的確有可能.

Caller 端應對的方法:

方法一: 靠 trust: “他們家大業大聲譽好, 一定不會亂搞的!” (?)

方法二: 仔細檢查 contract 是否能自爆和原地重生, 兩個條件少一個就換不動 code. (檢查起來不見得輕鬆)

方法三: call contract 前, 在同一個 transaction 中呼叫 EXTCODEHASH 來比對, code hash 符合檢閱過的版本才呼叫. 這樣就算在同一個 block 的前一個 transaction 中被偷換 code 了也能當場發現. (但仍要留心 code 之外的 nonce / balance / storage 可能被重置過)

而從 contract 撰寫者的角度來看, CREATE2 給了原地升級的方便, 但同時也提高了取信 caller 的難度. 在 governance 面要更加注意.

尾聲

本文對 CREATE2 和 CREATE 做了些實驗以幫助理解. 沒有討論 CREATE2 換 code 之外的面向(如 state channel), 觀念也沒有超出下面幾篇的範圍. 有興趣可以繼續閱讀下面的幾篇好文.

全部的 code 在這裡.

(感謝 Peter Lai 的審閱與建議)

• EIP-1014: Skinny CREATE2
• Potential security implications of CREATE2? (EIP-1014)
• EIP-1014 產生可控的智能合約地址
• The State of Smart Contract Upgrades - OpenZeppelin blog
• The Promise and the Peril of Metamorphic Contracts
• Defend against “Wild Magic” in the next Ethereum upgrade
• Ethereum quirks

(舊文) 用 CREATE2 搭配 CREATE 原地換 Code was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ethereum 自從引入 opcode CREATE2 後, 同一個 address 可能會換上不一樣的 code. 我們來實驗看看, 如何用 CREATE2 生成 / 自爆(SELFDESTRUCT) / 再原地換上新的 code.

New Contract Address

EIP-1014 這麼說:

Specification

Adds a new opcode (CREATE2) at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE (0xf0), except using keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.

CREATE2 多了第四個參數 salt. 而 address 也多了對應的新規則 (重要):

傳統 CREATE / contract creation transaction 的 new contract address:
    function addr(sender_address, nonce)

CREATE2 的 new contract address:
    function addr(sender_address, salt, init_code) 

以往 CREATE / contract creation transaction 因為 nonce 一直遞增, 所以無法重複生在同一個 address.
而 CREATE2 沒有用到 nonce! 所以只要我們從同一個 sender 送出 CREATE2 並帶著相同的 salt 和 init_code, 就可以把新的 contract 重複生到同一個 address 上.

SELFDESTRUCT 自爆

在 CREATE2 重複生到同一個 address 前, contract 要先自爆來空出位子. 這需要該 contract 直接呼叫 opcode SELFDESTRUCT, 或者間接 CALLCODE / DELEGATECALL 到其他含有 SELFDESTRUCT 的 contract.

相同的 init, 不同的 contract body

雖然我們想換掉 contract body (code), 但是因為 init code 變了 address 就會跟著變, 所以我們必須重用同一段 init code, 並在前後兩次產生不同的 contract body.

平常 Solidity compile 出來的 init code 是將夾帶的唯一一份 contract body 用 CODECOPY 的方式複製出來, 所以同一份 init code 會生出同一份 body.

然而 Ethereum 本身並沒有這樣的限制. 生出怎樣的 body 不光取決於 init code 的 binary 而已, 也取決於執行 init 時的 environment 和 state:

錯誤的想像:
    function body(init_code)

正確的想像:
    function body(init_code, environment, state)

所以如果 init 參考了 environment (如 value / time / block number), 或者參考了 state (如呼叫別的 contract 的 function 來下載 body, 或動態 EXTCODECOPY 不同的 contract 來用), 即使 init 沒變, 仍然可以生出不同的 body !

實作

我們需要準備兩段 code: 會生出不同 body 的 init, 和發送這段 init 的 CREATE2 factory contract.

實作細節建議先參考前一篇文章: Init.

Init

CREATE2 有個不會影響 address 又容易操控的參數: value (endowment). 為了 demo, 這裡選擇不參考 state, 而是在 init 中參考 value 來動態決定 body:

如果 value 是 0, 就生出 bomb contract body “0x3DFF”. 這個 contract 收到任何 message 都會 0xFF SELFDESTRUCT. (並把餘額送到指定的 address 0)

如果 value 不是 0, 就生出另一個 contract body “0xCafeBabe”:

用嵌在 JavaScript 中的這段 assembler 編一下, 會得到 bytecode 34600F57613DFF6000526002601EF35B63CAFEBABE6000526004601CF3 .

如果有裝 geth, 可以用 geth 的 command line evm 餵不同的 value 先測看看 (搭配這份 state):

Factory

有了 init code, 再來需要寫個 factory contract, 用 CREATE2 把上面這段 init 發送到 new contract address 去執行.

回頭想想, 平常 address 0 雖然沒有實際的 code, 但是概念上就像個通用的 factory contract: 只要我們用 sendTransaction 把 init 當 data 送給它, 它就會把 init 送到目的地去執行(並傳送 value).

我們也來刻意模仿這個行為, 寫個半通用的 factory contract: 只要我們用 sendTransaction 把 init 當 data 送給它, 它就會把 init 透過 CREATE2 送到目的地去執行(並傳送 value).

RUN !

Init 和 factory 準備好, 就可以來 生成 / 自爆 / 再生成新的 code 了:

執行結果:

可以看到在生成/自爆之後, 因為用了 CREATE2, 所以第二次還是會 deploy 到同一個 address, 而此 address 的 code 也從 0x3dff 換成了 0xcafebabe !

Etherscan 也會在 contract tab 加上紅字 “ReInit” 和文字說明來提醒使用者這個 contract 被換了 code :

最後驗證一下我們的理解:

尾聲

從上面的例子可以看到, 如果:

1. contract 有能力 SELFDESTRUT
2. 可以重複 deploy 到同一個 address (因為引入了 CREATE2)

則這個 contract 就可以原地換 code.

完整的程式碼在這裡.

下一篇, 我們將繼續討論換 code 造成的影響, 以及如何用 CREATE 原地換 code.

(感謝 NIC Lin 與 Ping Chen 的審閱與建議)

(舊文) 用 CREATE2 原地換 Code was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. 發送 contract creation transaction, 也就是 “to” address 為 0 的 transaction
2. 呼叫 opcode CREATE
3. 呼叫 opcode CREATE2

這三種方式都能給定一段要在新的 contract address 執行的, 只跑唯一一次的初始化 code, 也就是 init. Contract creation transaction 會把整個 “data” 當成 init, 而 CREATE / CREATE2 則是用參數指定 init.

Init

Yellow paper 這樣說:

init is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call

Init code 就像傳統 OS 的應用程式 installer 一樣, 負責安裝和初始化. 不過 init 不是把程式寫到硬碟裡, 而是把要裝的 body 寫到 memory 中, 再透過 RETURN opcode 指給 EVM 看. EVM 會在 init return 後把這段被指的 memory 寫成將來每次跑的 contract body.

我們來寫一段產生 contract body 只有一個 byte 0x42 的 init code:

寫一個非常陽春的, 可嵌入在 JavaScript 中的 assembler 來轉上面的 code:

asm(`PUSH1 42 …`) 出來的 bytecode 會是 “604260005360016000F3” .

如果有裝 geth, geth 有送一個 command line 版的 evm, 可以把上面的 bytecode 丟進去測:

看起來沒問題. 用 sendTransaction 的 data 發送看看:

執行結果:

getCode() 回來的確是 0x42, 成功了! (goerli)

CODECOPY

上面的範例只 deploy 了一個 byte 0x42. 如果想要 deploy 更長的 code, 常見的做法是: 寫一段 deployer, 把 body 黏在後面, deployer 用 opcode CODECOPY 把整段 body 複製進 memory 中, 再用 RETURN 指給 EVM 看.

舉例來說, deploy 一份 4 bytes 的 body “0xCafeBabe” 可以這樣做:

Solidity compiler 也是用 CODECOPY 這個做法:

一個便於實驗的 deployer

上面我們的 deployer 寫死了 body 4 這個長度. 如果不想每次改 body 就手動改長度的話, 可以用 CODESIZE =deployer + body 減去固定的 deployer 長度, 來得到接在後面的變動的 body 長度:

我們常常需要用 PUSH1 00 來 push 一個 0 到 stack 上. 為了榨取一點 gas, 只要還沒 CALL 其他的 contract, 我們就可以用 opcode RETURNDATASIZE (0x3D) 來達成 push 0 的效果. 細心的你可能已經發現到, 在上面的 assembler 中我們定義了 “_MYZERO_” , 一樣是對應到 0x3D, 但取個名字讓放 0 的意圖更明顯.

有了這段 deployer, 我們就可以直接在後面黏上任何長度的 body, 這樣做各種實驗都會方便許多:

var deployer = "600B380380600B3D393DF3";

deploy(deployer + “CafeBabe”);
deploy(deployer + “000000000000DeadBeef”);

尾聲

Init code 像是 installer 一樣, 不論是用動態生成的還是用 copy 的, 只要能把 memory 填好 RETURN 給 EVM, 就能 deploy 成 contract body.

完整的 code 和 輸出 請看連結.

下一篇, 我們將實驗如何用 CREATE2 原地換 code.

(感謝 NIC Lin 的審閱與建議)

Init was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.