Merkle Bridge的目標是成為一個簡單輕巧的協(xié)議,用于在區(qū)塊鏈之間資產(chǎn)轉(zhuǎn)移，同時提供分布式的監(jiān)管和審查阻力。第一個應用程序是將Aergo ERC2
Merkle Bridge的目標是成為一個簡單輕巧的協(xié)議,用于在區(qū)塊鏈之間資產(chǎn)轉(zhuǎn)移，同時提供分布式的監(jiān)管和審查阻力。第一個應用程序是將Aergo ERC20代幣轉(zhuǎn)移到Aergo的主網(wǎng)原生代幣。一旦部署了網(wǎng)橋，任何以太坊或Aergo資產(chǎn)都將可以在這些網(wǎng)絡之間直接轉(zhuǎn)移。在本文中，我們將介紹該協(xié)議的一些技術細節(jié)。
我們可以用以下兩種方式錨定(2WP)的資產(chǎn)轉(zhuǎn)移：首先在區(qū)塊鏈A上存入代幣，然后要將代幣轉(zhuǎn)移到區(qū)塊鏈B上，必須先將區(qū)塊鏈A上代幣進行鎖定，并以1：1的比例在區(qū)塊鏈B上鑄造一個副本，最后副本區(qū)塊鏈B上銷毀后，才能解鎖區(qū)塊鏈A上的鎖定代幣。
維持固定匯率的簡單方法是將資產(chǎn)鎖定在單個密鑰或多重簽名合同中(大多數(shù)交易所如何存儲資金)。
第一種情況(單個密鑰)不安全，因為密鑰可能會被盜或丟失。
第二種情況(multisig)更安全，但是轉(zhuǎn)讓費用昂貴，因為它們每次轉(zhuǎn)讓都需要鏈上進行2/3簽名驗證。讓每個傳輸進行多重簽名處理也意味著很容易審查單個用戶的傳輸。還有其他更安全和無需信任的方法，例如ETH-ETC的平橋，但需要資本鎖定才能進行抵押和削減。
我們的目標是實現(xiàn)允許20多個驗證者的分散資金鎖定/解鎖，但同時通過設計一種簡單的協(xié)議(無需橋接操作員來處理單個轉(zhuǎn)賬)，將橋接轉(zhuǎn)賬費用保持在較低水平。
Merkle橋設計
Aergo Merkle橋可實現(xiàn)分散式保管和資產(chǎn)的有效鑄造。
權(quán)限證明(PoA)側(cè)鏈通常使用其狀態(tài)根在公共鏈上的錨定來提供可驗證的真相來源。Merkle橋使用這些錨定狀態(tài)根來允許用戶提交側(cè)鏈狀態(tài)的證明。
資金保管
這種設計的安全性取決于錨定根的有效性。固定的區(qū)塊鏈狀態(tài)根包含鎖定和已用余額的信息，因此任何無效的狀態(tài)根都可用于竊取鎖定的用戶資金。
為了確保狀態(tài)根的有效性，錨定使用類似于multisig oracle的簡單形式的DAO(分散式自治組織)。該DAO的成員稱為驗證者。
驗證者有以下職責：
· 在將要錨定的根源上達成共識(因此它們必須是具有信譽的已知實體，以確保有效的錨定)。
· 同意驗證者集更新建議(使用2/3當前驗證者的簽名添加或刪除驗證者)。
· 同意Merkle橋設置更新建議(還需要獲得2/3驗證者的批準).
操作方式
提案人(愿意支付錨定費的人)會定期在橋接鏈上發(fā)布橋接合約的狀態(tài)根。僅在狀態(tài)根已由2/3驗證者簽名的情況下才會記錄。
然后，用戶錢包可以通過使用錨定狀態(tài)根驗證其鎖定資產(chǎn)的Merkle證明來獨立鑄造目標橋合約上的資產(chǎn)。
鎖定并跟蹤帳戶的總代幣余額。創(chuàng)建了包含此余額的Merkle證明，并且可以在橋的另一側(cè)鑄造該代幣余額。鑄造記錄了總的造幣余額，因此帳戶造幣的金額永遠不會超過存入的金額。燒毀和解鎖余額也是使用相同的過程。
這種設計使合約的存儲管理和操作變得簡單，因為它不需要記錄傳輸隨機數(shù)或返回值。 局限性在于，隨著用戶數(shù)量和固定代幣數(shù)量的增長，Merkle證明的大小會增加(合約狀態(tài)樹會更深)，從而使轉(zhuǎn)移變得更加昂貴。
使用Merkle Bridge將ERC20代幣從以太坊轉(zhuǎn)移到Aergo
優(yōu)點：
· 驗證者實現(xiàn)起來很簡單，因為它們只需要簽署它們認為有效的最終狀態(tài)根(通過在橋的兩邊運行完整的節(jié)點)。驗證者不需要監(jiān)視和驗證用戶的轉(zhuǎn)移。
· 用戶錢包直接通過網(wǎng)橋合同進行轉(zhuǎn)賬，不需要驗證者批準。
· 錨定周期是靈活的，狀態(tài)根可以由許多驗證器(20 +)簽名。
· 如果沒有超過2/3驗證者共同認可并廣播無效的側(cè)鏈狀態(tài)根，則不能任意審查代幣傳輸。
· 可以進行小額轉(zhuǎn)賬，并且可以隨時鑄造/解鎖總存款余額。
· 鏈上的Merkle證明驗證比簽名驗證便宜。
· 任何新資產(chǎn)都可以通過網(wǎng)橋進行轉(zhuǎn)移，而無需獲得驗證者的批準(由于在鑄造時會部署新的固定合約，因此第一次轉(zhuǎn)移的成本會更高)。
· 可以通過一次交易完成對另一個鏈上同一帳戶的多次轉(zhuǎn)賬，提取發(fā)送到該帳戶的總鎖定余額。
局限性：
· 一旦啟動，傳輸就應該在網(wǎng)橋的另一端完成(沒有超時限制)，但這意味著無法取消傳輸。
· 如果超過1/3的驗證者停止合作，網(wǎng)橋?qū)o限期暫停(不可能有新的取款)。
部署
在此存儲庫中可以找到2個Aergo區(qū)塊鏈之間的Merkle橋的POC實現(xiàn)：https://merkle-bridge.readthedocs.io
以太坊和Aergo區(qū)塊鏈之間的Merkle橋的POC實現(xiàn)可以在以下存儲庫中找到：https://eth-merkle-bridge.readthedocs.io
在此存儲庫中可以找到用于在以太坊和Aergo之間轉(zhuǎn)移資產(chǎn)的Javascript SDK：https://github.com/aergoio/eth-merkle-bridge-js?source=post_page-----32bd0f06c308----------------------
橋的操作員
他們要為橋接的每個區(qū)塊鏈運行一個完整節(jié)點。 每隔固定的時間間隔(每10分鐘?)，他們將獲得最新的最終狀態(tài)根，并將其注冊在橋合約的Root和Height狀態(tài)變量中的相反區(qū)塊鏈上。
橋操作員有2種類型：廣播set_root()事務的建議者和為建議者請求的兩個橋接鏈狀態(tài)根簽名的驗證器任何人都可以是提議者：橋合約只允許在錨定期之后發(fā)生且具有有效簽名的狀態(tài)根更新。驗證者的數(shù)量可以根據(jù)所需的multisig安全性而變化，如果請求的狀態(tài)根有效，驗證者會對其進行簽名。
function newAnchor(
bytes32 root,
uint height,
uint[] memory signers,
uint8[] memory vs,
bytes32[] memory rs,
bytes32[] memory ss
) public {
require(height > _anchorHeight + _tAnchor, "Next anchor height not reached");
bytes32 message = keccak256(abi.encodePacked(root, height, _nonce, _contractId, "R"));
validateSignatures(message, signers, vs, rs, ss);
_anchorRoot = root;
_anchorHeight = height;
_nonce += 1;
emit anchorEvent(root, height);
}
操作員調(diào)用newAnchor(…)來錨定新的狀態(tài)根
橋驗證者集更新：
如果2/3的當前驗證者同意新的驗證者集，則可以定義新的驗證者集。
function validatorsUpdate(
address[] memory newValidators,
uint[] memory signers,
uint8[] memory vs,
bytes32[] memory rs,
bytes32[] memory ss
) public {
// validators should not sign a set that is equal to the current one to prevent spamming
bytes32 message = keccak256(abi.encodePacked(newValidators, _nonce, _contractId, "V"));
validateSignatures(message, signers, vs, rs, ss);
_validators = newValidators;
_nonce += 1;
emit newValidatorsEvent(newValidators);
}
橋驗證者集更新
版本2
在Merkle橋的版本2中，簽名驗證將在單獨的Oracle合約中重構(gòu)，該合約將對橋合約具有完全控制權(quán)。這樣可以升級oracle合同的共識機制，并為用戶轉(zhuǎn)移保留相同的橋接合約。 橋的安全屬性保持不變。
用戶資產(chǎn)轉(zhuǎn)移：
要傳輸代幣，用戶會將其鎖定在橋接合約中，并等待目標區(qū)塊鏈上的下一個錨。
function lock(
string memory receiver,
uint amount,
IERC20 token
) public returns (bool) {
// Add locked amount to total
bytes memory accountRef = abi.encodePacked(receiver, token);
_locks[accountRef] += amount;
// Pull token from owner to bridge contract (owner must set approval before calling lock)
// using msg.sender, the owner must call lock, but we can make delegated transfers with sender
// address as parameter.
require(token.transferFrom(msg.sender, address(this), amount), "Failed to burn");
emit lockEvent(token, receiver, amount);
return true;
}
lock(…)記錄用戶存入的總余額。
用戶錢包將讀取目標區(qū)塊鏈上的新錨定狀態(tài)根(Root，Height)，并向該節(jié)點請求Merkle證明，包括該狀態(tài)根的鎖定余額。用戶的鎖定平衡被記錄在鎖狀態(tài)映射，其中鍵是用于一個令牌帳戶參考。 帳戶參考是用戶地址和令牌地址的串聯(lián)。 然后可以使用鎖定令牌的Merkle證明在目標區(qū)塊鏈上進行薄荷交易。 用戶的造幣金額不能超過合同所存入和記錄的總金額。
function mint(
address receiver,
uint balance,
string memory tokenOrigin,
bytes32[] memory mp, // bytes[] is not yet supported so we use a bitmap of proof elements
bytes32 bitmap,
uint8 leafHeight
) public returns(bool) {
require(balance>0, "Balance must be positive");
bytes memory accountRef = abi.encodePacked(receiver, tokenOrigin);
require(verifyMp("_sv__locks-", accountRef, balance, mp, bitmap, leafHeight), "Failed to verify lock proof");
uint mintedSoFar = _mints[accountRef];
uint amountToTransfer = balance - mintedSoFar;
require(amountToTransfer>0, "Lock tokens before minting");
MintedERC20 mintAddress = _bridgeTokens[tokenOrigin];
if (mintAddress == MintedERC20(0)) {
// first time bridging this token
mintAddress = new MintedERC20();
_bridgeTokens[tokenOrigin] = mintAddress;
_mintedTokens[address(mintAddress)] = tokenOrigin;
emit newMintedERC20(tokenOrigin, mintAddress);
}
_mints[accountRef] = balance;
require(mintAddress.mint(receiver, amountToTransfer), "Failed to mint");
emit mintEvent(mintAddress, receiver, amountToTransfer);
return true;
}
mint(…)驗證存款的Merkle證明并鑄造正確數(shù)量的代幣。 如果從未鑄造過令牌，則部署新的固定代幣合約。
如果橋的操作員在用戶產(chǎn)生余額之前錨定了新的狀態(tài)根，則用戶的錢包可以為新錨定的狀態(tài)根簡單地創(chuàng)建新的Merkle證明。
用戶的錢包在原始區(qū)塊鏈上解鎖代幣之前，會重復類似的燒毀代幣的過程。
有關Merkle橋合約中的Merkle證明驗證的詳細信息，請參閱：
[http://bitoken.world/?p=297](以太坊Patricia樹的Merkle證明驗證 "http://bitoken.world/?p=297")
相關作品
Merkle Bridge采取的方法是盡可能使用最簡單，最可靠的設計，以使驗證者無需就用戶轉(zhuǎn)移達成共識，而是將所有資源集中在他們錨定的區(qū)塊鏈狀態(tài)根的有效性上。此外，用戶沒有完成轉(zhuǎn)賬的時間限制，并且可以通過一次交易完成對同一帳戶的多次轉(zhuǎn)賬。這是與以下協(xié)議的主要區(qū)別：
ICS(鏈間標準)
其他項目，如cosmos ibc，則采用不同的方法，將所有單個跨鏈資產(chǎn)傳輸抽象為數(shù)據(jù)包(也可以支持契約調(diào)用)，并且peg區(qū)域驗證器在這些數(shù)據(jù)包上達成共識。這是一種非常有趣的方法，可以減少對跨鏈資產(chǎn)的信任，但當peg驗證器鎖定的資金的價值超過所涉原子的價值時，這種設計也最終依賴于驗證器的聲譽時，就會產(chǎn)生問題。
需要注意的是，為了連接比特幣和EOS這樣的區(qū)塊鏈，將存款事件轉(zhuǎn)發(fā)到傳輸代幣上是必要的，而EOS并不是Merkelize狀態(tài)。
Plasma
Merkle橋的設計靈感來自對Plasma的研究，并解決了在Plasma上運行合約的問題。Merkel橋并不是Plasma的，因為它不具有相同的安全性：沒有退出提示可以挑戰(zhàn)來自側(cè)鏈的退出，并且提款必須在側(cè)鏈上進行。 Merkle橋的安全性取決于錨定驗證者的分散性。
由于可以為單個狀態(tài)根進行無限數(shù)量的傳輸，因此該狀態(tài)根所需的簽名數(shù)量可能很高。用戶無需關注區(qū)塊鏈上的無效提款和大規(guī)模退出情況，而應該信任去中心化的驗證者。同樣在POA企業(yè)側(cè)鏈的情況下，我們通常會假設共識安全性，因此可以在側(cè)鏈上初始化提款是可以接受的，并且側(cè)鏈運營商不需要監(jiān)視父級掛鏈的退出。
結(jié)論
Merkle橋由一個簡單的DAO(multisig oracle)組成，用于驗證錨，更新驗證者集和橋設置。用戶錢包可以獨立創(chuàng)建其鎖定/燒毀余額的Merkle證明，以進行跨鏈轉(zhuǎn)移，而無需驗證者觀看轉(zhuǎn)移事件。
EthAergo網(wǎng)橋?qū)⒂糜谠贏ergo和以太坊主網(wǎng)之間發(fā)送AergoERC20和任何其他代幣。
AERGO-AERGO橋接器將被企業(yè)側(cè)鏈的用戶用于以一種成本高效和安全的方式在AERGO主網(wǎng)之間轉(zhuǎn)移他們的資產(chǎn)。
這使MakerDAO的DAI穩(wěn)定幣和其他任何ERC20等令人興奮的應用程序都可以供Aergo主網(wǎng)用戶使用，并由Merkle橋錨定保護。（鏈三豐）
