跨分片合約拖拽

Cross-shard contract yanking?

ethresear.ch

特別感謝Piper Merriam幫忙一起想出這個點子。

跨分片合約拖拽（Cross-shard Contract Yanking）屬於跨分片鎖定【1】及類似技術的通用化方案，以實現跨分片活動解決火車和酒店問題。其實，「鎖定」分片A上的合約意思是把分片上的合約狀態凍結，將狀態保存到收據中，將合約導入分片B，在該合約與分片B上的其他對象間執行些操作，然後使用另個收據將合約發送回分片A，讓其繼續存在。

想要簡化並通用化這個機制，把「鎖定」改為「拖拽（yanking）」即可。在EVM中添加個YANK（單個堆棧參數：target_shard）操作碼，YANK從狀態中刪除合約並簽發包含合約狀態及target_shard的收據；隨後在target_shard中對收據進行處理，在該分片中實例化相同合約。合約可以自由指定自己被拖拽的條件。

舉個例子，酒店預訂合約可以通過reserve()函數實現，這個函數可以預訂酒店房間，實例化代表酒店房間的合約，且該合約包含move_to_shard(uint256 shard_id)函數，允許任何人將合約拖到另個分片上。那麼，人們也可以通過預訂酒店房間，拖合約到車票預訂合約分片，然後在該分片上以原子方式預訂酒店和車票，從而解決車票酒店問題。必要時，酒店房間合約中的book()函數可以自毀酒店房間合約並簽發收據，這個收據可用來保存預訂記錄在酒店預訂主合約中。用戶在拖拽後原子預訂前消失時，任何想要預訂酒店房間的人都可以使用這個（相同的）酒店房間合約來執行此操作，甚至是將酒店房間合約拖回到原始分片。

為保證拖拽效率，被拖者的內部狀態必須很小，以便可以編碼進收據中，且拖拽的gas成本要與被拖者的總大小成正比。一般從可用性層面來說，令對許多用戶有意義的合約為可拖拽（yankable）並不是個好主意，原因是拖拽後的合約在target_shard中重新實例化之前，是不可用的。出於這兩個原因，最可能的工作流是使合約具有與上述酒店房間（合約）類似的行為，意思是合約將與個別交互相關的狀態分離出來，以便可以分別在分片間移動。

注意，跨分片消息和拖拽之間存在很好的並行，現有的CALLs和CREATEs：CALL = 同步分片內消息傳遞，CREATE = 同步分片內合約創建，CROSS_SHARD_CALL = 非同步跨分片消息傳遞，YANK = 非同步跨分片合同創建。YANK操作碼不一定必須刪除現有合約並創建收據才能在新分片上生成副本。非要這麼做時（刪除現有合約並創建收據）可能需要調用CROSS_SHARD_CREATE和self-destruct；這麼做雖體現出對稱性，卻也需要個支持在另個分片中創建一個與原始合約地址相同合約的功能。

Q&A

問：如何預防用戶相同的拖拽收據用兩次，比如在沒有任何新YANK調用的情況下在分片之間來回拖拽（狀態相同的）合約？

分片是否需要記住每個領取過（claimed）的收據，防止領取兩次的情形？（若需要，不就產生了須由分片存儲不斷增長且不可修剪的狀態嗎？）

或者還有別的機智法子？

答：有三種比較極端的選項：

1. 分片需要記住領取過的所有拖拽收據

2. 拖拽要求提供該分片中所有先前塊的Merkle證明，證明相同合約未在先前塊中被拖拽進（該分片）

3. 收據指定一個特定的區塊高度，在此期間可以領取，若合約未包含在該特定高度，則永遠消失。

但這三個選項都顯然有點荒謬，下面是正常點的：

1. 收據須在一年內領取。分片須記住收據一年。

2. 分片記住收據一周。若一周內收據未領取，那麼請求人必須每周提供一份Merkle證明，證明該收據不在上一周狀態中領取收據列表中。

【1】