深度解讀以太坊2.0第二階段：如何轉移你的錢_以太坊:UNT

金色財經比特幣5月20訊本文作者是ConsenSys研究員威爾·維拉紐瓦，他此前曾擔任以太坊及ERC20代幣支付公司BountiesNetwork聯合創始人兼首席科技官。最近，威爾·維拉紐瓦對“V神”VitalikButerin提出的以太坊2.0第二階段提案進行了解讀，金色財經將其全文編譯如下：

以太坊聯合創始人“V神”VitalikButerin最近圍繞了以太坊2.0第二階段提出了一個公開提案和額外的抽象概念。事實上，外界已經有很多對此進行解讀的文章，但筆者希望從更高層次上對“V神”的提案進行總結，并讓人們以一種“廣度優先”的方式去探索全新的思維空間。

首先，與業內普遍存在的一些看法不同，以太坊升級從“0階段”到“2階段”并不需要按順序進行，每個階段其實是可以并行處理的。

一般來說，閱讀本文可能需要對以太坊2.0升級有一些基本的了解，如果你還是一個“區塊鏈小白”，那么金色財經建議你可以先研究下面這些材料，或許對理解以太坊這次最重要的升級工作有所幫助：

https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/

https://media.consensys.net/exploring-the-ethereum-2-0-design-goals-fd2d901b4c01

https://media.consensys.net/state-of-ethereum-protocol-2-the-beacon-chain-c6b6a9a69129

https://github.com/ethereum/wiki/wiki/Sharding-roadmap

https://www.youtube.com/watch?v=S262StTwkmo

為了支持初始發布，以太坊2.0開發工作被拆分成了三個階段：

1、“0階段”側重于構建信標鏈，并為另外兩個階段打下核心部分的基礎，比如網絡、簽名方案、隨機性等等。

2、“1階段”專注于開發獨立運行的1024分片鏈的機制。

3、“2階段”的重點是執行引擎、交易思想空間、賬戶模型等。從本質上來說，這一階段將會把以太坊2.0帶入到實際應用之中，同時也將開啟狀態執行和計算。

在“V神”的第一個提案里，我們可以看到他可能受到了以太坊核心開發人員CaseyDetrio的一些影響，“V神”提出了一種與人們最初假設完全不同的方法，他希望構建一個“輕量級第1層”協議，然后重點關注分片鏈中的第2層。實際上，第2層并不代表擴容方案Plasma或狀態通道，而是專注于以一種更通用、更開放形式運行的分片鏈。這種方法是一種普遍的范式轉化，因此可能需要你具備一些專業知識才能真正消化并掌握。然而，“V神”最新提案的優勢在于為以太坊網絡提供了高度靈活性，而隨著研究的不斷深入，未來以太坊區塊鏈如果要引入新的變化也會變得更加簡單。事實上，這與以太坊1.0形成了鮮明的對比，因為以太坊1.0將整個系統鎖定在一個模型里面，所以所有系統更新或改變都只能在協議范圍內進行，具有較大的局限性。在對更基礎的知識有了理解之后，本文最后部分會深入探討這個新系統的優點和缺點。

在開始全面展開本文全部內容之前，筆者會首先解釋如何將你的資金從舊系統轉移到分片鏈上。下面，就讓金色財經和大家一起開始看看威爾·維拉紐瓦是如何開始的吧。

從以太坊1.0移入以太坊2.0

為了將你的以太坊從舊的以太坊1.0區塊鏈遷移到以太坊2.0區塊鏈中，你需要先通過把自己的以太幣存入在舊區塊鏈智能合約里燃燒掉。新區塊鏈具有協議和投票期，以識別你的存款，并將你的以太幣重新移入信標鏈中。除了在舊區塊鏈的智能合約里存入以太幣之外，你不需要做任何其他事情。當前協議的投票/包容系統將自動將你的資金帶入到信標鏈。隨著時間的推移，舊的區塊鏈將會變得越來越不活躍，新系統就會逐步將另一個系統給淘汰掉。但是，這種轉變最終究竟會以什么形式呈現目前仍在討論之中。

在現有規范中，只要你存入至少32ETH，那么就會自動成為驗證人/權益人。但是，大多數人可能希望將他們的以太幣帶入到分片鏈里，以便能在很多應用程序、合約或錢包里使用。在“V神”的提案中，你可以通過多個步驟完成此操作。但最重要的是，你首先要了解在任何分片鏈中都沒有原生以太幣的概念。這個想法，其實就是分片鏈內第2曾結構開始浮出水面的地方。因此在深入討論如何將以太幣帶入分片鏈之前，我們需要先介紹一些背景知識。

信標鏈合約

現在，存儲智能合約的信標鏈已經被稱作為“信標鏈合約”，這些合約與你在以太坊1.0上應用程序部署的常規智能合約類似，也都會在分片鏈中上線。相比之下，信標鏈合約將代表整個執行環境或交易框架。舉個例子，你可以擁有一個不同的信標鏈合約，它可以代表以太坊的不同實現或框架。一個可以代表基于賬戶的以太坊交易/存儲模型，而另一個，則可以代表基于未花費交易輸出的以太坊模型。在實際應用的過程中，其實并不應該有太多信標鏈合約，而是應該保持較少的數量——特別是在開始階段。

但是，在構建這個新系統的思維模型的時候要特別謹慎。在上面的解釋中，您可以假設每個信標鏈合約會代表不同的虛擬機，但這種假設其實是不正確的。相反，合約定義/強制執行狀態、以及純函數有些類似于當前以太坊1.0上的預編譯。通過這篇文章，你會發現這個模型應該更有意義。

在如今很多關于以太坊2.0的討論中，執行人和執行環節也可以作為一個整體用于指代信標鏈合約。

接受一個框架

現在我們已經有了一點背景知識了，讓我們繼續這趟深入了解以太坊2.0的旅程把。好了，我們已經決定把自己的以太幣帶入到基于可接受賬戶的以太坊模型里。我們可以說，這個模型是在信標鏈合約0中被定義的。此外，我們已經將以太幣從以太坊1.0帶入到了信標鏈，這個模型中會有一個驗證人/staking賬戶，但我們會選擇不去成為一個活躍的驗證人。相反，我們希望自己的以太幣能夠從表層滲透到一個特定的分片。在這種情況下，我們更愿意說自己對于帶入到分片5更感興趣。

為了把我們的以太幣帶入到分片4，我們需要將信標鏈以太幣轉換成為信標鏈合約0.值得慶幸的是，一個新的交易類型會被引入到名為“withdrawToContract”的信標鏈中。我們可以在此調用新增額外的數據。在我們的例子中，我們會把包含之前發送以太幣的分片地址添加到分片號碼5里，我們需要發送的數據也會在信標鏈合約中被定義。

{

#你在信標鏈中持有以太幣的賬戶

"validator_index":uint64,

"data":{

shard:5,

address:address

},

"pubkey":BLSPubkey,

"signature":BLSSignature

}

在現實中，該數據會被發布到信標鏈中的一個接收方中，而且還會通過區塊提議人被包含在信標鏈區塊數據里。基本上，信標鏈存儲每個區塊的接收列表。

現在，我們的以太幣已經被鎖定了，而且可以在分片5中使用這些以太幣。在深入了解索要這些以太幣的過程之前，依然還是需要再深入了解更多背景信息，因為我們必須要知道更多分片鏈和信標鏈合約之間的關系。

分片鏈合約和狀態執行

如上所述，分片鏈并沒有原生以太幣的概念。事實上，你需要把自己的以太幣鎖定到信標鏈和閱歷，然后在分片鏈上使用。想要理解這個過程，最好的辦法就是分析理解分片鏈和信標鏈合約之間的關系。從本質上來說，分片鏈機器狀態執行函數將是信標鏈合約中定義框架的反映和集合。

在每個分片鏈區塊里，會生成一個全局狀態。分片鏈中的狀態會始終直接映射到信標鏈合約，讓我們先從“V神”使用的示例開始：

{

#你所認為的實際“狀態”

"objects":,2**64],

#Receipts

"receipts":,

"next_receipt_index":uint64,

#Currentslot

"slot":uint64,

...

}

對象列表中的每個索引都會被映射到每個信標鏈合約索引之中，如果有兩個信標鏈合約，那么對象就只會有兩個實體。乳溝基于賬戶的以太坊是信標鏈合約0，而未支付交易輸出是合約1，那么索引0和索引1將會分別映射每一個狀態。Slot只是分片上區塊編號的另一個名字，在每個索引中，我們會有，這只是一個擔憂22??密鑰選項的密鑰價值存儲。每個StateObject都包含以下域：

{

#以便將來兼容的版本號

"version":uint64,

#Contents

"storage":bytes,

#StateObjectcanberemovedifitexpires(ie.now>ttl)

"ttl":uint64

}

我們稍后會聊聊上面代碼里的“ttl”，它代表了狀態到期，以及圍繞租金的更多討論。存儲只是一個任意的字節數組，它將由信標鏈合約中規定的框架構成或定義。然而，最近有研究提出了一個全新的方法，我們可能甚至根本不需要節點來存儲狀態，這可能意味著在協議層并不需要嚴格地定義“ttl”。這個問題其實可以展開很多內容.......但是現在，還是讓我們先把以太幣轉移到分片鏈上吧！

將以太幣轉移到分片鏈

信標鏈合約有一個叫做“depositToShard”的函數代碼，如下：

defdepositToShard(state:BeaconState,

receipt:WithdrawalReceipt,

proof:WithdrawalReceiptRootProof):

#VerifyMerkleproofofthewithdrawalreceipt

assertverify_withdrawal_receipt_root_proof(

get_recent_beacon_state_root(proof.root_slot),

receipt,

proof

)

#Interpretreceiptdataasanobjectinourownformat

receipt_data=deserialize(receipt.withdrawal.data,FormattedReceiptData)

#Checkthatthisfunctionisbeingexecutedontherightshard

assertreceipt_data.shard_id==getShard()

#Checkthattheaccountdoesnotexistyet

assertgetStorageValue(hash(receipt_data.pubkey))==b''

#Setitsstorage

setStorage(hash(receipt_data.pubkey),serialize(EthAccount(

pubkey=receipt_data.pubkey,

nonce=0,

value=receipt.amount

)))

上述代碼里的評論應該是提供了一些背景數據，所以在此我們并不需要做較為深入的解讀。基本上，我們只要提交打印在信標鏈上的原始提款收據就可以了。這個函數是在分片中執行的，同時還會執行Merkle可信樹校樣來確保收據有效。如果有效的話，你就可以做好準備，因為帶有你賬戶的數據已經被寫入到新存儲里了。

EthAccount{

pubkey:BLSPubkey,

nonce:0,

value:32eth

}

轉移資金

到了這一階段，我們已經在分片鏈上有了一個賬戶，那么接下來的工作就是要把一些我們的錢轉移到另一個賬戶里。其實這并不難，只需要在信標鏈和閱歷添加另一個函數代碼：

deftransfer(sender:bytes32,

nonce:uint64,

target:bytes32,

amount:uint64,

signature:BLSSignature):

sender_account=deserialize(getStorageValue(sender),EthAccount)

target_account=deserialize(getStorageValue(target),EthAccount)

assertnonce==sender_account.nonce

assertsender_account.value>=amount

assertbls_verify(

pubkey=sender_account.pubkey,

message_hash=hash(nonce,target,amount),

signature=signature

)

setStorage(sender,EthAccount(

pubkey=sender_account.pubkey,

nonce=sender_account.nonce1,

value=sender_account.value-amount

))

setStorage(target,EthAccount(

pubkey=target_account.pubkey,

nonce=target_account.nonce,

value=target_account.valueamount

))

需要再次提醒的是，這里其實并不需要你做太深入的理解，因為這個函數只會減少舊賬戶的余額并增加新收款賬戶的余額。但需要記住的是，這些函數都是在分片的共識層上執行的。此處會使用BLSSignature簽名模式來確保與信標鏈上的當前工作一致，但同時，這里也可以使用其他簽名模式。實際上，如果沒有供接收賬戶使用的存儲，那么應該需要額外的代碼來創建新賬戶。我們的圖表獲得了一個不錯的更新。

到了這里，不妨讓我們先來回顧一下此前完成了哪些工作吧。

回顧截至目前的工作

到目前為止，我們已經拿走了以太幣，并且將其從以太坊1.0區塊鏈中轉移到了以太坊2.0信標鏈中。我們還會把這些以太幣歲定在一個信標鏈合約之中，這個合約將讓我們在分片5上使用這些以太幣。最后，我們會把我們的一些以太幣轉移到該分片的另一個賬戶里。

現在，事情開始變得更簡單了。

當前框架僅代表具有余額的基本賬戶模型，我們當然可以讓它變得更復雜，而且還能在其中納入智能合約和復雜的狀態執行，但先讓我們緩一緩。我想再給大家普及一些基礎知識，之后再討論更復雜的交易模型。

費用市場

在這篇文章中，我們已經說過分片鏈沒有任何原生以太幣的概念。實際上，根據你所在的框架或信標鏈合約，你的以太幣會以不同的方式進入分片鏈。而這，很可能會引發其他一些問題。比如，假設沒有原生代幣，區塊生產者該如何獲得報酬？在我們的示例中，這個框架與信標鏈以太幣1:1錨定的。因此，區塊生產者可能不介意接受以太幣、或是信標鏈合約中定義的其他代幣。然而，這么一來又會產生更多的問題。

這是否意味著區塊生產者需要接受已建立的每個執行環節或框架？區塊生產者是否為了確保交易是值得的，需要在每個信標鏈合約框架上建立驗證、轉換和安全分析？對于區塊生產者來說，這些問題會讓事情變得非常麻煩，而且效率也會變得很低。

這個主題非常有趣，而且“V神”隨后也深入探討了這些問題。總的來說，以太坊2.0會帶來一些范式轉換，責任會轉移到許多中繼器，而不是過去管理內存池網絡的節點。

如果你希望包含交易，那么可以把你的交易廣播到中繼器網絡——與當前向運行內存池的節點進行廣播的過程不同。這些中繼器將負責組織、訂購和驗證他們收到的交易，并且從中挑選最有利可圖的交易，而那些支付費用最高的交易會最先被驗證。在一組交易被組織進入到一個暫定的區塊之后，中繼器將會估算其gas支出會有多少。在這種情況下，如果區塊生產者包括了自己的交易集合，那么在中繼器將愿意為區塊生產者支付固定的費用；如果不包括的話，區塊生產者就可以直接從運營者那里直接收取費用。在此，我們暫時不會考慮太多實際實際投產實施時的細節問題，比如為了償還區塊生產者，可能會直接添加一個函數到主以太坊信標鏈合約里或一個分片鏈里。但現在，我們暫時不去考慮這些，而是通過一個例子來簡化基本國策。

我們假設用戶在信標鏈合約0下的基本交易非常簡單，如下所示：

{

'to':address,

'from':address,

'amount':uint64,

'gas_price':uint64,

'signature':bytes

}

此時我們假設中繼器提交了一個區塊提案BlockProposal(他們已經組織了自己的交易清單):

{

'transactions':,

'signature':bytes,

'fee':uint64

}

反過來，我們再將在信標鏈合約中包含一個額外的函數代碼：

defprocess_block(block:BlockProposal):

assertverify_signature(block,block.signature)

fortransactionintransactions:

process_transfer(transaction)

其中process_transfer的函數代碼如下:

defproccess_transfer(tx):

assertverify_signature(tx,tx.signature)

to=get_storage(tx.to)

to.balance=tx.amount

gas_fee=TRANSFER_GAS*tx.gas_price

from=get_storage(tx.from)

from.balance-=(tx.amountgas_fee)

relayer=get_storage(get_relayer())

relayer.balance=gas_fee

set_storage(tx.to,to)

set_storage(tx.from,from)

set_storage(get_relayer(),relayer)

由于圍繞交易費用和gas費用支出的實際賬戶抽象模型仍在不斷發展，我們將保持基本費用的簡單表達：TRANSFER_GAS。

很快，我們將進一步討論如何擴展這個模型來處理生產環境下的代碼執行和賬戶抽象。此外，上面還跳過了一個小細節——筆者并未描述process_transfer函數是如何正確執行的，這個問題我們會稍后討論，先讓我們再添加一層復雜性，并且深入討論一下如何從分片鏈中徹底去除“狀態”這個概念。

分片鏈不需要狀態

為了更深入地理解分片鏈不需要“狀態”這個概念，你可以先學習一下“V神”之前發布的提案，其中他介紹了下面兩個想法：

1、我們之前描述的“狀態”或“對象”字段并不需要在分片節點內維護，但是這些概念可能依然會存在于以太坊2.0里。但是，這些概念將存在于應用層而不是共識層了，對“插入”到某些特定執行環境不感興趣的節點沒有知道這些概念的必要。

2、信標鏈上的“簽入”和跨鏈連接會被壓縮狀態簽入。

這個概念，會讓之前圍繞存儲ttl、poking、以及到期的討論變得毫無用處。由于沒有“狀態”被存儲起來，因此在以太坊2.0里可能并不需要考慮協議到期問題，但是為了減少中繼器網絡上的存儲要求，我們仍然需要“分片鏈不需要狀態”這個概念。

筆者暫時不想深入研究無狀態客戶的概念，因為這個問題是非常復雜的，如果要討論話肯定需要專門再寫一篇文章了。但是，我們在此會對這個問題做出一個比較簡短的總結。在上面的例子中，你會注意到我們使用了get_storage函數，該函數很可能會映射到一個runtime函數，該函數會把存儲在本地數據庫運行節點里的一個值連接到ewasm或Web聚合環境中，這時將會與以太坊虛擬機操作碼SLOAD保持一致。

一個無狀態系統意味著你不需要在節點中維護存儲或“狀態”信息，事實上，此時你可以在交易數據中包含所有函數需要訪問的存儲。從本質上來說，這些交易其實會提交自己的數據庫，而且還包含了這個數據庫證明。例如，如果我們將以下內容作為關聯我們信標鏈合約0的執行環節存儲：

[

...,

EthAccount{

nonce:3,

value:1232,

pub_key:BLSPubkey

},

EthAccount{

nonce:12,

value:22,

pub_key:BLSPubkey

},

...

]

我們可以假設有大量實體，然后將存儲列表“Merkle化”，這樣我們就可以從數據中生成Merkle根哈希。接下來，我們可以只存儲Merkle根數據，而不是把整個“狀態”數據存儲在每一個分片之中，比如我們可以只包含witness_data數據，而不僅僅是在交易中包含簽名。witness_data數據將包含簽名和Merkle分支組合，以證明賬戶的當前狀態和交易的接收賬戶，我只需要為交易訪問的狀態值提供Merkle分支就可以了。在資金轉移中，你只需要確認自己的賬戶狀態和接收賬戶的狀態，節點也不再需要保留當前活動存儲的海量數據庫了。相反，節點現在可以將每個交易中的witness_data數據當做是數據庫。“無狀態客戶”這個概念很有吸引力，我建議大家可以閱讀這篇文章深入了解一下。

你或許會問，如果節點不再追蹤存儲，是否意味著需要用戶自己去追蹤它呢？或者，用戶會將交易存儲直接保存在本地？如果他們丟失了數據而且無法再提高witness_data會發生什么狀況？是否意味著用戶從此就無法獲得資金和自己的賬戶了呢？

上面這些問題都非常好，而筆者給出的答案也會很酷——為提交擬議區塊給區塊生產者的中繼器提供激勵機制，讓他們去保存存儲。其他類型的節點也可以作為獨立第三方存在，此外用戶還可以在本地存儲自己的狀態，只有當他們本地存儲丟失的時候才有必要請求第三方或中繼器的幫助，此時第三方或中繼器可以收取適當的費用提供此服務。從本質上來說，存儲和存儲費用可以完全從核心協議中刪除，所有核心協議需求都是Merkle哈希或是其他壓縮值。為了繼續保持靈活性，我們可以根據執行環節或每個信標鏈合約來定義見證格式。

使用全新的無狀態解決方案還有另一個好處，那就是我們可以在信標鏈跨鏈連接中檢查這些狀態根，也將帶來巨大的好處，為什么呢？讓我們繼續分析下去。

信標鏈跨鏈連接

每隔6分鐘，每個分片鏈的當前區塊哈希就會被檢入到信標鏈中，這個數據檢入動作被稱為跨鏈連接，這個操作可以建立不可改變性。實質上，當單獨的分片之間存在通信、或者信標鏈需要驗證特定分片上的接收人時，它可以等待通過等待跨鏈出現在信標鏈上來確立不可改變性。此時，Merkle證明將會被一直生成，以確定該分片上的所有收據或交易確實發生。這里，我們先稍微討論一下有關跨鏈分片通信的細節。

在全新的無狀態模式里，我們可以使當前階段0和階段1中的實現變得更加高效，因為在新模式里不再需要單獨改組委員會。

為了更加深入地解釋這個問題，我們在此將做進一步分析。

最初的階段0規范創建了一個證明人永久委員會和一個證明人階段委員會。作為驗證人或權益人，你將會有兩個任務，一個任務是作為階段委員會的成員去驗證插入信標鏈的slot，另一個是作為永久委員會的成員去驗證插入分配了的slot。永久委員會將會在很長一段時間內來管理分片鏈上的證明、投票和驗證工作，直到一個分片鏈上的交易全部轉移到另一個分片上；另一方面，階段委員會將在一個時期內的一個時段內投票支持特定分片上的跨鏈和不可變性。該委員會會在每個時間段進行改組，每次改組之后都會驗證一個獨立分片鏈跨鏈。

現在你會發現，我們已經不需要在分片鏈上維護存儲了，此時就可以把這兩個委員會進行合并。最初這兩個委員會是分開的，因為一個全節點在某個持續時間段之后可能需要數天/小時才能驗證新分片。在無狀態客戶模式中，我們可以把這段時間大幅減少，現在每隔1-2個小時就能改組一次，這樣也會帶來一些其他好處，比如：

1、減少分片鏈上的改組時間，可以為我們提供更好的安全性和便捷性；

2、跨鏈/信標鏈委員會的改組時間更長的話，也會為我們帶來更多網絡穩定性，并且減少每隔6分鐘同步更新一次客戶端的負擔。

跨分片交易

實際上，跨分片交易很大程度上已經超出了本文涉及的業務范圍，我們正在編寫一些概念證明，并希望在這一領域里積極展開研究，預計很快就會關于這個主題的分析文章，這里先推薦兩篇比較不錯的博客文章：

https://ethresear.ch/t/fast-cross-shard-transfers-via-optimistic-receipt-roots/5337

https://ethresear.ch/t/phase-2-pre-spec-cross-shard-mechanics/4970

需要注意的一點是，在大多數情況下，你不需要真的等待6分鐘來確認每個分片鏈把當前區塊哈希檢入到信標鏈中，樂觀地看，其實你可以將多個分片上的交易組合在一起檢入。

拓展到完整狀態執行

當做到了這一步，恭喜你！你已經吸收了很多有價值的信息了。但走到這一步，也意味著你真的需要認真讀一讀“V神”的提案。當然，如果你不想花太多力氣研讀，也可以直接看看“V神”的結論，其中覆蓋了他提案的優點和缺點。在此，筆者將給出一個簡短的分析解讀。

以太坊2.0中的執行環節將在ewasm上運行，ewasm是Web聚合的一個子集，旨在與能夠映射到特定op_codes的節點runtime函數一起運行。Web聚合運行和op_codes都會被計量，執行引擎也將為區塊計算代碼被執行需要多少gas費用。為了更深入地了解gas機制如何運作，其術語賬戶抽象解讀會指導你朝著正確的方向發展。此外，每個執行環節或信標鏈合約都可以構建自己的賬戶抽象gas機制。

但首先，讓我們先來看看它會是什么樣子。

EthAccount可能會添加一個額外的域，代碼：

EthAccount{

pubkey:BLSPubkey,

nonce:0,

value:uint64,

code:bytes

}

雖然這里會有一些變化，但其實并不會區分合約賬戶和外部擁有賬戶。在當前的以太坊1.0中，一個錢包管理的賬戶存儲和一個已部署的合約存儲還是有所不同的，你可以點擊此處了解更多信息。

接下來，你必須要更新我們之前描述的process_block函數，此時可能需要一系列包裝函數來創建適當的調用環境，包括設置tx.sender，tx.executor等。另外，你還可以定義賬戶抽象、gas限制規則等。“V神”的提案里包含了一組EEI函數，該函數可以添加到執行環境或信標鏈合約中。在process_block和包裝函數集中，你將使用：

executeCode(code:bytes,data:bytes)->bytes

包裝函數可能會從適當的EthAccount中自動抽象和加載代碼。

通過位閾進行雙重支付保護

第二階段提案有一部分是將信標鏈和分片鏈添加到一個交易接收方列表里，這個交易接收方是非常重要的，比如我們會使用depositToShard函數調用信標鏈里的交易接收方信息。此外，分片鏈還會將交易接收方信息存儲在區塊里，分片鏈接收方信息將用于以下兩個目的：

1、通過merkle證明驗證跨分片交易

將資金發送到接收方分片需要在源分片上燒掉資金，接收方分片需要運行一個驗證，確保資金的確已經被燒毀了；

2、驗證資金已經返回到信標鏈里

除了最初通過depositToShard索取資金的機制之外，還應用與上述相同的機制。

分片鏈上的aReceipt結構代碼如下：

{

#Uniquenonce

"receipt_index":uint64,

#ExecutionScript(beaconchaincontractindex)thatthereceiptiscreatedby

"executor":uint64,

#Addressthatitisintendedfor

"target":bytes32,

#Data

"data":bytes

}

這些方法中存在的一個主要問題，就是不會兩次使用一個接收方——特別是在無狀態模式中。由于你不能再每個區塊上包含“排除證明”——這是不可能的，所以就必須采用另一種方式。“V神”在提案中創建了一個check_and_set_bitfield函數，旨在追蹤已經使用過的接收方，該函數如下：

check_and_set_bitfield_bit(bitfield_id:uint64,bit:uint64)

上述函數中的“id”將映射接收方索引，每個分片鏈和信標鏈在每個已發布的接收方上遞增接收方索引。“bitargument”將映射到一個輔助標識符，信標鏈接收方可以通過“bit=0”來追蹤，每個分片鏈可以通過“bit=SHARD_COUNT1”來追蹤。擁有輔助標識符很重要，因為每個分片鏈和信標鏈在接收方索引上總發生沖突。調用該函數可以將位閾塊中的bit設置為1，如果它已經為1，則會聲明錯誤。這意味著已經該接收方已經被消費了且正在嘗試進行雙重支付。

總結

不可否認，這篇文章的內容非常多，希望它能夠幫助你更深入地了解目前、以及未來不斷發展的以太坊第二階段規范。“V神”的最新提案也是一個不錯的輔助資源，如果你能仔細閱讀一下或許對于理解整個以太坊2.0也非常有幫助。

最后，我將列出“V神”總結的提案優點和缺點，你可以將其和第1層協議級別嚴格設置的規則對比一下。

優點：

1、共識分叉的風險更小；

2、更快的升級更新部署時間；

3、沒有硬分叉治理政策，未來更容易升級環境；

4、在不同客戶電子實現代碼編寫和代碼重復的操作更少；

5、能夠在同一基礎層上并行測試不同的方法。

缺點：

1、執行環境/信標鏈合約必須要仔細審核，以確保沒有錯誤/問題；

2、硬分叉“”雖然少了，但是標準化“”卻更多了；

3、共識層、第2層、中繼網絡和次級環境的整體復雜性風險變得更大了。

文章編譯自Medium

Tags：以太坊UNTCOUACC以太坊最新價格IDOHunt appanticounterfeitchainPayaccept

MATIC