介紹應用程式開發人員需要能夠在以太坊2平臺上建立在不同執行環境中具有不同分片合約的程式。應用程式開發人員需要能夠使用他們習慣於與以太坊1平臺一起使用的同步原子可組合程式設計技術。這篇文章提出了一種可以做到這一點的技術。例如在下圖中，使用跨分片呼叫來獲取oracle的值。如果返回的值低於一定數量，則使用“跨分片”呼叫來購買商品。
這種跨分片交易技術依賴於新增到執行環境（EE）中的以下功能：
新增到交易收據中的系統事件訊息，可以透過信標鏈交叉連結從其他分片上的其他EE引用。在EE中，當作為事務目標的函式呼叫結束時，EE會生成系統事件訊息。系統事件訊息與合約程式碼可能產生的應用程式事件訊息不同。合約程式碼不能產生偽造系統事件訊息的事件。
實時引數檢查：當合約程式碼呼叫進行跨分片函式呼叫時，請檢查實際分片，EE，合約，函式和引數是否與預期被呼叫的那些相匹配。
合約可鎖定性：部署合約時，需要將其指定為可以鎖定（可鎖定）或不能鎖定（不可鎖定）。執行交易細分時，任何具有狀態更新的合約都必須被鎖定。如果將合約部署為不可鎖定，則無法將其鎖定，並且事務將失敗。
臨時狀態儲存和合約鎖定：當合約作為跨分片事務的一部分進行更新時，其更新狀態儲存在臨時儲存中，並且合約被鎖定。如果提交了跨分片事務，則臨時狀態將替換合約狀態並且合約將被解鎖。如果忽略交跨分片事務，則臨時狀態將被丟棄，合約將被解鎖。
新的事務型別：EE需要支援本建議後面描述的事務型別。示例理解這項技術的最好方法是透過一個例子。想象一下下面顯示的呼叫圖。下面寫入（沒有更新）的段事務是讀取狀態並返回值的函式呼叫。下面寫入（更新）的段事務是寫入狀態並返回值的函式呼叫。
下圖顯示了執行此複雜的跨分片事務的事務。在該圖中，區塊由方形框表示，交易由圓角框表示。編號為N-1的分片區塊的已簽名狀態根會饋入編號為N的信標鏈塊，稱為交叉連結。編號為N的信標鏈塊中所有分片塊的交叉連結都可用於編號為N的分片塊。虛線表示從分片塊將交叉連結提交到信標鏈區塊中，以及它們可用於信標鏈塊中的分片塊。實線表示應用程式將事務提交到事務池中，然後將其包含在分片塊中。
逐步處理：
1. 應用程式將開始事務提交給Shard 1。這將為跨共享事務保留跨共享事務Id，並指定組成跨共享事務的根事務和事務段的呼叫圖。
2. 應用程式將葉事務段提交給Shard 3、5、6和7。事務執行可以更新狀態並返回值的函式呼叫。執行事務的EEs會發出系統事件，其中包含有關事務呼叫和函式呼叫的資訊，包括錯誤狀態和返回結果。在本例中，假設只有Shard 7有任何狀態更新。
3. 該應用程式等待產生一個信標鏈塊，該信標鏈塊包括包含提交事務的Shard塊的交叉鏈路。
4. 應用程式將事務段提交給Shard 2以執行函式呼叫。該事務包括來自在Shard 3和Shard 5上執行的事務的系統事件資訊，以及顯示該資訊與作為在Shard上執行的塊的一部分的事務相關的Merkle證明。Merkle根可以與分片的信標區塊中的交叉連結進行比較。在本例中，假設Shard 2上的事務不會導致狀態更新。
5. 在將事務段提交給Shard 2的同時，應用程式將事務段提交給Shard 4以執行函式呼叫。事務包括在shard 6和shard 7上執行的事務的系統事件資訊和Merkle證明。在本例中，假設此事務導致Shard 4上的狀態更新。
6. 該應用程式等待產生一個信標鏈區塊，該信標鏈區塊包括包含提交事務的Shard塊的交叉鏈路。
7. 應用程式提交根事務，以及Shard 2和4上事務段的系統事件資訊和Merkle證明。發出系統事件資訊，指示應提交整個跨分片事務。
8. 該應用程式等待產生一個信標鏈區塊，該信標鏈區塊包括包含提交事務的Shard塊的交叉鏈路。
9. 該應用程式在Shard 4和7上提交訊號交易以解鎖Shard 4和7上的合約。
10. 應用程式在Shard 1上提交清理交易，以從未清唯一ID列表中刪除交叉分片交易ID。
交易型別跨分片事務包含多種事務型別。初始事物初始事物指示跨分片事務的開始。此事務用於保留每個shard和每個EE的“唯一”跨shard事務Id，並註冊根事務和事務段的整體呼叫圖。交易欄位包括：跨分片交易ID.超時區塊編號。根事務資訊（分片，EE，函式呼叫和引數）。對於從作為該交易結果執行的程式碼中呼叫的每個交易細分： 帶有Shard、EE、Contract Address、Function Name、被呼叫函式的引數值的日誌訊息 返回結果 是否進行狀態更新和交易是否導致合約鎖定。 將指定行的Merkle證明合併到交叉連結。 請注意，事務列表必須按照期望呼叫函式的順序進行。事務處理：
如果使用跨分片事務Id，則失敗。
檢查超時區塊號是否為合適的值。
註冊跨分片事務Id.
發出包含以下內容的啟動系統事件：
Tx Origin/Msg Sender：簽署交易的帳戶。
跨分片事務Id
從根事務開始的交叉分片函式呼叫/事務段的分層呼叫圖。對於每個呼叫，包括：
Shard
EE
Contract address
Data: 函式名字和引數
根交易（Root Transaction）根事務包含函式呼叫，該函式呼叫是跨分片事務的整體呼叫圖的入口。此事務型別指示程式碼應按照正常的事務段執行（請參見下文），並且應提交或忽略所有分片上的所有鎖定合約。如果事務在超時塊之前成功完成，則作為跨碎片事務一部分的所有事務段的結果，所有狀態更新都應提交。如果任何事務段失敗，或者如果在超時後提交事務，則應丟棄所有事務段更新。交易欄位包括：
跨分片事務Id
要呼叫的Shard、EE、Contract、函式和引數。
啟動事務日誌訊息和Merkle證明（注：包括超時塊號）
對於從該事務執行的程式碼中呼叫的每個事務段：
帶有Shard、EE、Contract Address、Function Name、被呼叫函式的引數值的日誌訊息
返回結果
是否有狀態更新，並且事務已導致鎖定的協定。
對特定區塊的交聯進行Merkle證明。
注意，事務列表必須按照預期呼叫函式的順序。事務處理：
1. 驗證“初始事務”和每個事務段的日誌資訊，檢查Merkle證明，直到“分片交叉連結”。
2. 如果區塊編號在超時之後，或者任何“事務段”日誌指示錯誤，則發出指示錯誤的系統事件。
3. 檢查事務是否已由啟動事務日誌指示的同一實體提交。
4. 驗證“初始事務”事件中的呼叫圖是否與傳入的事務段呼叫匹配。
5. 使用事務段的快取返回值執行程式碼。
6. 檢查程式碼呼叫的事務段是否與開始事務日誌中預期呼叫的事務段匹配。
7. 狀態更新被放入臨時儲存，合約被鎖定。
8. 當這個shard的入口點函式呼叫完成時，發出一個系統事件訊息，該訊息與為根事務描述的訊息相同。
信令事務這些事務用於解除由事務段鎖定的合約的鎖定。此交易包括：
根事務日誌資訊和顯示根事務已成功完成或已失敗/超時的Merkle證明。
此分片日誌和Merkle證明的事務段，顯示哪些合約被鎖定。事務處理：
1. 如果根事務日誌指示“提交”，則應用臨時更新並解鎖合約。
2. 如果根事務日誌指示“忽略”，則放棄臨時更新並解鎖合約。這些交易應該是免費的，或者甚至應該給予鼓勵，以確保參與者在失敗/鎖定合約的實體停止參與時提交此交易。無效的信令交易應懲罰使用者。懲罰不應太重，因為信標鏈重組可能導致無效的信令交易。
清除交易（Clean Transaction）從未完成的唯一ID列表中刪除唯一ID。交易欄位包括：
初始交易日誌和證明（指示交叉分片交易的呼叫圖），
根事務日誌和證明
交易細分日誌和Merkle證明（表明已鎖定哪些合約），
信令事務日誌和Merkle證明（表明呼叫了適當的信令事務）。應激勵有效清除交易，以確保參與者提交了此交易。但是無效的清除事務應該懲罰使用者。懲罰不應是繁重的，因為信標鏈重組可能導致無效的清除交易。
其他交易除上述交易型別外，EE需要支援的其他交易包括：
部署可鎖定的合約。
部署不可鎖定的合約。
在某些情況下，可以建立專門的事務型別來消除對“start”和“clean”事務的需求。例如如果有一個根事務和一個執行跨碎片讀取並且不更新狀態的事務段，則可能可以建立不需要啟動和清除事務的專用根事務。目前正在進一步考慮。
跨分片處理要進行跨碎片交易，應用程式將執行以下操作。請注意，使用者的應用程式並沒有做很多事情，大多數複雜性將由庫包裝程式（如Web3J）處理。
1. 使用動態程式分析（程式碼模擬）確定事務的呼叫圖和引數值。
2. 提交開始交易。這可以與下一步並行進行，也可以在下一步之前的一個插槽中完成。
3. 提交葉事務段。“leaf”事務是指其函式呼叫不呼叫其他跨碎片函式的事務。
4. 等待一個區塊以釋出交叉連結。
5. 提交包含呼叫其他事務段的函式的事務段。對巢狀事務的每個“層”重複此操作。
6. 等待一個區塊以釋出交叉連結。
7. 提交根事務。
8. 等待一個區塊以釋出交叉連結。
9. 提交更新狀態下執行事務段的所有分片上的所有信令事務。
實時引數檢查實時引數檢查用於確保在執行合約程式碼時，傳遞給跨分片函式呼叫的引數的實際值與已簽名的交易段中的引數值匹配。回想一下，在執行事務時，“事務段”的引數值在系統事件中釋出，並且應用程式將此資訊饋送到“事務段”或“根事務”中，以呼叫它們所代表的函式。這意味著當程式碼執行時，EE可以訪問來自Transaction Segments的跨分片函式呼叫的預期引數值。圖顯示了在另一個返回值的shard（sh2.ee2.conC.func（））上呼叫函式的示例約定程式碼，然後根據state1的值，可以在另一個不返回值的shard（sh2.ee4.conD.func（））上呼叫函式。
當應用程式建立用於呼叫funcC和funcD的事務段時，它需要模擬程式碼執行。例如如果_param1將為5，state1為2，state2為3，並且在引數為5的情況下funcC將返回10，則需要建立事務段，並將引數值5傳遞給funcB，將5傳遞給funcC ，並將13傳遞給funcD。請注意，如果state1為1，則事務段將僅針對對funcB和funcC的呼叫進行構造，因為funcD將永遠不會被呼叫。
安全與活性（Safety & Liveness）以下內容介紹了一組可能的失敗方案，並描述瞭如何處理該方案。根交易失敗如果根事務因任何原因失敗，則會建立一個系統事件，該事件指示所有事務段的所有更新都應該被丟棄。基於此係統事件，可以使用信令事務來解鎖所有EE中所有碎片上的所有合約。根事務可能失敗，因為：
根事務中的程式碼可能會引發錯誤。
傳遞到根事務中的系統事件訊息可能表示事務段之一發生錯誤。
呼叫交叉分片函式的引數與函式呼叫的事務段的系統事件訊息中的引數值不匹配。
交叉事務處理塊超時後提交根事務。事務段失敗如果事務段由於任何原因失敗，則會建立一個系統事件，指示它失敗。此係統事件可以傳遞到根事務，以導致整個跨分片事務失敗。事務段可能會失敗，因為：
事務段中的程式碼可能引發錯誤。
傳遞到事務段的系統事件訊息可能指示某個從屬事務段發生錯誤。
使用跨分片函式呼叫的引數與函式呼叫的事務段的系統事件訊息中的引數值不匹配。
在跨分片事務塊超時後提交事務段。無效的Merkle證明或無效的系統事件該應用程式可能會提交無效的Merkle證明或無效的System Event訊息，從而使System Event訊息與Merkle Proof結合使用的雜湊不會產生與Cross Link的狀態根匹配的Merkle根。
在這種情況下，相關事務將失敗。應用程式未提交事務段應用程式可能會看到從屬事務段失敗，並決定不再提交任何其他事務段，根事務或信令事務。為了解決這個問題，另一個使用者可以等待跨分片事務超時，並提交一個根事務以使整個跨分片事務失敗（這是免費的），並提交信令事務（將獎勵呼叫者）和清除事務（將獎勵呼叫者）以解鎖所有鎖定的合約並移除跨分片事務Id。應用程式不提交根事務應用程式可以看到一個從屬事務段失敗，並決定不提交根事務或傳送事務訊號。為了解決這個問題，另一個使用者可以等待跨分片事務超時，並提交一個根事務以使整個跨分片事務失敗（這是免費的），並提交信令事務（將獎勵呼叫者）和清除事務（將獎勵呼叫者）以解鎖所有鎖定的合約並移除跨分片事務Id。
重放攻擊(Replay Attacks)根事務和事務段與用於簽署“開始事務”的帳戶相關聯，但在交叉分片超時已過期的失敗情況下除外。該帳戶的交易將具有一個帳戶隨機數，這將阻止重放。嘗試重放“根事務”和“事務段”的其他使用者將失敗，因為他們將無法使用簽署了“初始事務”的私鑰對事務進行簽名。
拒絕服務（DOS）攻擊攻擊者可能提交帶有正確資料的清除交易，並帶有一個錯誤的Merkle證明。攻擊者可能會重複提交交易，以試圖在以太坊客戶端上進行大量處理。一個大的呼叫圖將導致以太坊客戶需要處理許多Merkle證明。透過對無效的清除交易進行處罰來阻止這種行為。
此外，任何使用者提交有效的清除交易都會獲得少量獎勵。信標鏈分叉如果信標鏈分叉，則需要根據修訂的交叉連結重播所有分片上分片塊的事務。一些重播的事務可能期望不再存在交叉連結，因此這些事務將失敗而不是透過。在這種情況下，交叉分片事務將失敗，並且任何狀態更新的臨時狀態都將被丟棄。
終結性一旦最後一次信令交易完成後的檢查點，交叉分片交易將是最終的。這通常是一個時期中的第一個信標區塊。一旦檢查點是最終的，所有先前的區塊都是最終的，並且隱含地所有先前的交叉連結將是最終的，因此所有分片塊都是最終的。
酒店列車示例（包括ERC20）旅館和火車問題是一個場景的示例，其中涉及旅行社，該旅行社需要確保跨越三個分片的複雜多合約交易的原子性。旅行社需要確保他們既預訂酒店房間又預訂火車座位，或者既不預訂酒店房間，也不預訂火車座位，因此避免了成功預訂酒店房間但火車預訂失敗的情況，反之亦然。
此外只有在進行預訂後，才需要透過ERC20代幣付款。最後的要求是，交易必須以其他使用者可以預訂酒店房間和火車座位並同時付款的方式進行。想象一下，其中涉及三個分片：旅行社在shard 1上執行，旅館在shard 3上執行，火車在shard 4上執行。還有第二個在shard 2上執行的旅行社。這是下面的示意圖。
酒店被表示為一個不可鎖定的router contract和多個可鎖定的酒店room contracts。酒店向旅行社發放ERC 20代幣，用於支付酒店客房費用。ERC 20合約包括router contract和每個帳戶的一個或多個付款槽合約。類似地，火車由不可鎖定的router contract和多個可鎖定的火車seat contracts表示。為了預訂房間，旅行社建立了交叉分片功能呼叫（事務段），用於預訂酒店房間和火車座位並支付費用。
酒店router contract的工作原理是找到一個合適的房間，該房間在請求的當天可用，但目前尚未預訂，然後預訂該房間。搜尋房間時，程式碼將跳過當前鎖定的room contracts。同樣在支付房間費用時，ERC的router contract需要將錢從旅行社的賬戶轉到酒店的賬戶。
它透過為酒店找到一個沒有上鎖的付款槽合約來實現這一點。如果能夠以程式設計方式確定哪些合約已被鎖定，從而避免合約被鎖定，則可以編寫酒店，火車和ERC20合約，以便兩家旅行社可以同時執行預訂而不會遇到鎖定的合約。其他注意事項帳戶隨機數（Account Nonces）：帳戶隨機數被視為處於可鎖定狀態。這樣當一個帳戶提交一筆交易，並且交易現值增加時，該帳戶就不會被鎖定。
ETH轉移（Ether Transfer）:目前該方案只關注函式呼叫。用這種技術可以在分片之間進行ETH轉移。為所有分片上的Gas付費：如果使用者可以在一個碎片上使用Ether，並使用它為跨分片事務執行的所有分片上的Gas付費，那就太好了。這種技術目前還不能做到這一點。
也許當ETH轉移被解決時，這是可能的。事務大小（Transaction size）：此提案中的交易通常包含多個Merkle證明和其他資料。需要分析對交易規模的可能影響。以太坊1.x：假設以太坊1.x在分片中的EE中，所有現有合約都可以標記為不可鎖定。EE可以支援本文中描述的功能。可以新增其他EVM操作碼以允許跨分片函式呼叫。應用程式程式碼（Application code）：我聽到您說，“在應用程式中聽起來很複雜。這種技術難道不應該簡化應用程式開發嗎？” 答案是，絕大多數複雜性將被吸收到Web3J之類的庫中。合約程式碼和其他應用程式程式碼應簡單明瞭。
文章來源：https://ethresear.ch/t/atomic-cross-shard-function-calls-using-system-events-live-parameter-checking-contract-locking/7114參與抽獎
