作者：成都鏈安原文： 《跨鏈橋安全研究(三) | 多邊形戰士Polygon安全透析，如何預防“潘多拉魔盒”的開啟？ 》
歡迎大家來到成都鏈安出品的“跨鏈橋安全研究”系列文章，在上一篇文章裡（跨鏈橋安全研究(二) | 首次去中心化搶劫Nomad跨鏈橋事件帶給我們什麼啟發？） ，我們詳細對Nomad跨鏈橋協議進行專業的技術分析。
今天，成都鏈安安全研究團隊將對多邊形戰士Polygon安全透析，請繼續往下看。
1_Polygon是誰？
Polygon是以太坊的layer2擴容方案，其願景是建造以太坊的區塊鏈互聯網。 Polygon提供了一個通用框架，允許開發人員利用以太坊的安全性創建定制的，專注於應用程序的鏈，並提供一個互操作性網絡，結合了各種不同的擴展方案，如：zk-rollup、 PoS等。其中，Polygon PoS是目前Polygon上最成熟和廣為人知的擴容方案。它利用側鏈進行交易處理，實現提升交易速度並節省Gas消耗的目的，網絡結構主要包含以下三層：
Ethereum層：
以太坊主網上的一系列合約，主要包括：Staking、Checkpoint、Reward合約，負責PoS權益相關的質押管理功能，包括：提供MATIC原生代幣的質押功能，使得任何質押該代幣的人可以作為驗證者加入系統；驗證Polygon網絡的轉態轉換獲得質押獎勵；懲罰驗證者的雙重簽名、驗證者停機等不合法行為；保存checkpoint。
Heimdall層：
權益證明驗證節點層，包括一組PoS Heimdall節點，負責將Polygon網絡的檢查點提交給以太坊主網，同時監聽部署在以太坊上的一組質押合約。主要流程為：首先選擇驗證者池中的一部分活躍的驗證者作為塊生產者，它們將負責在Bor層創建區塊並廣播；接著根據Bor提交的檢查點，驗證Merkle根哈希並附加簽名；最後，提議者將負責收集指定檢查點的所有驗證者簽名，如果簽名數量達到2/3以上，則在以太坊上提交該檢查點。
Bor層：
出塊節點層，包括一組由Heimdall層上的驗證者委員會定期選取的區塊生產者，它們是一個驗證者子集，負責將Polygon側鏈上的交易聚合併生成區塊。該層會定期向Heimdall層發布檢查點（checkpoint），其中檢查點代表Bor鏈上的一個快照，如下圖所示。
2_Polygon互操作性
2.1 檢查點（checkpoint）
檢查點機制是一種將Bor層的數據同步到以太坊上的機制，其中同步的數據是檢查點，即在一個檢查點間隔的時間段內包含的Bor層區塊數據快照，源碼如下：
Proposer：提議者，它也是由驗證者選取的，區塊生產者和提議者都是驗證者的子集，且他們的責任取決於其在整個池子中的股權比例
RootHash：是由StartBlock到EndBlock之間的Bor塊生成的Merkle Hash
以下是編號1到n的Bor塊生成RootHash值的偽碼：
綜上，該值是Bor區塊頭中的區塊號number、區塊時間戳time、交易樹根Hash值tx hash、收據樹根Hash值receipt hash計算得到的keccak256哈希值構成的Merkel tree的根哈希值。
AccountRootHash：需要將每個檢查點發送到以太坊上的驗證者相關賬戶信息的Merkle Hash，單個賬戶信息的哈希值計算方式如下：
由賬戶Merkle tree根哈希值生成AccountRootHash的方式與RootHash值相同。
2.2 StateSync
狀態同步機制（StateSync）是指將以太坊數據同步到Polygon Matic鏈，主要分為以下幾個步驟：
1）首先以太坊上的合約會觸發StateSender.sol中的syncState()函數進行狀態同步
2）syncState()函數將發出一個event事件，如下：
3）Heimdall層的所有驗證者都會收到該事件，其中一個驗證者會將該交易打包到heimdall區塊中，並添加到待處理的狀態同步列表中；
4）bor層節點會通過API獲取到上述待同步列表，交給bor層的合約進行進一步的業務邏輯處理。
2.3 Polygon Bridge
Polygon Bridge實現了Polygon和Ethereum之間的雙向跨鏈通道，使得用戶可以在兩個不同鏈平台之間更為方便地轉移代幣而不會產生第三方威脅和市場流動性限制。 Polygon Bridge有PoS和Plasma兩種類型，二者在Polygon和Ethereum之間的資產轉移都有以下相同之處：
1）首先需要將Ethereum上的代幣映射到Polygon，如下圖所示：
2）同樣採用雙向錨定技術（Two-way Peg），即
a：從以太坊上轉移的代幣資產都會先在Ethereum上被鎖定，且相同數量的映射代幣會在Polygon上被鑄造；
b：為了將代幣資產提取到Ethereum，首先需要將這些映射代幣在Polygon上burn掉，之後再解鎖鎖定在Ethereum上的資產；
下圖為PoS Bridge和Plasma Bridge的對比：
由上圖可知，安全性方面，PoS Bridge依賴於外部驗證者集合的安全性，而Plasma依賴於Ethereum主鏈的安全性。同時在用戶進行跨鏈資產轉移時（如將代幣從Polygon轉移到Ethereum），PoS僅需要一個檢查點的間隔時間，大約20分鐘到3小時；而Plasma則需要一個7天的爭議挑戰期。同時PoS支持更多的標準代幣，而Plasma僅支持三種類型，包括：ETH、ERC20、ERC721。
3_跨鏈消息傳遞—PoS Bridge
PoS Bridge主要包含兩個功能：Deposit和Withdrawals，其中Deposit指的是將用戶在以太坊上的資產轉移到Polygon，Withdrawals則指的是將資產從Polygon提取到以太坊上。
Deposit
下面以用戶Alice使用PoS Bridge將其以太坊賬戶上的代幣資產發送到其在Polygon賬戶中為例進行介紹：
1、如果用戶想轉移的代幣資產為ERC20、ERC721、ERC1155類型，則首先需要用戶將要轉移的代幣通過approve函數授權。如下所示：通過調用以太坊上token合約中的approve方法將對應數量的token授權給erc20Predicate合約。
其中approve函數有兩個參數：
- spender：用戶授權允許花費代幣的目標地址
- amount：可以被花費的代幣數量
2、上述授權交易被確認後，用戶接著通過調用RootChainManager合約的depositFor()方法將代幣鎖定到以太坊上的erc20Predicate合約中。此處，如果轉移的資產類型是ETH，則調用depositEtherFor()。具體如下：
其中depositFor函數有三個參數：
- user：接收Polygon上deposit代幣的用戶地址
- rootToken：以太坊主鏈上的token地址
- depositData： ABI編碼後的代幣數量
以下是RootChainManager合約中depositFor函數的具體代碼：
分析源碼可知，該函數首先獲取到token對應的predicate合約地址，接著調用其lockTokens()函數將token鎖定在該合約中。最後_stateSender將調用syncState()進行狀態同步，該函數只有admin設置的狀態發送者（state sender）才能調用。
3、StateSender.sol中的syncState()函數將提交事件StateSynced，具體為：
其中第一個參數為該log的序號索引，第二個參數用於校驗調用者是否是已註冊的合法合約地址，第三個是需要進行狀態同步的數據。該交易會被添加到Heimdall塊中，並被添加到掛起的狀態同步列表中。
4、接著Polygon Matic鏈上的bor節點通過API獲取到狀態同步列表中的StateSynced事件後，該鏈上的ChildChainManager合約會調用onStateReceive()函數，該函數用於接收從以太坊上傳過來的同步數據，根據狀態同步的業務邏輯類型進行下一步處理：
data：包括bytes32類型的syncType、bytes類型的syncData。其中，syncType代表業務類型，包括deposit和mapping代幣映射；當syncType為mapping時，syncData為編碼後的rootToken地址、childToken地址和bytes32類型的tokenType；當syncType為deposit時，syncData為編碼後的user地址、rootToken地址和bytes類型的depositData。 depositData在REC20中是數量，ERC721中指的是tokenId。
5、由於此處進行的是Deposit業務，所以接著會調用_syncDeposit()函數。該函數會首先將syncData按照對應格式解碼，得到對應的rootToken、user地址、depositData。接著校驗rootToken在polygon上是否有對應的映射代幣childToken，如果有則調用childToken的deposit()函數。
6、此處我們以ERC20的代幣合約為例，介紹映射代幣合約如何deposit。該函數將mint對應數量的代幣到用戶賬戶中。
該函數有兩個參數：
- user：正在進行存款的用戶地址
- depositData：用ABI編碼的amount
Withdrawals
下面以用戶Alice使用PoS Bridge將其在Polygon賬戶中存放的資金提取到以太坊賬戶為例進行介紹：
1、當用戶withdraw時，需要首先在Polygon鏈上通過調用映射token合約的withdraw()函數，burn掉對應數量的映射代幣。
withdraw僅包含一個參數：將要被burn掉的token數量。對應的token合約中的withdraw()函數如下：
2、上述交易將經過大約20分鐘到3小時將被包含到checkpoint中，被驗證者提交到以太坊。
3、一旦交易被添加到檢查點中並提交到了以太坊，將調用以太坊上的RootChainManager合約的exit()函數，該函數將通過驗證提交的檢查點內容確認在Polygon上withdraw交易的有效性，並觸發對應的Predicate合約解鎖用戶deposit的代幣。
其中，傳入該函數的Proof證明inputData包括以下數據：
- headerNumber：包含了withdraw交易的檢查點區塊header
- blockProof：證明子鏈中的區塊頭是提交的merkle root的葉子節點
- blockNumber：子鏈上包含withdraw交易的區塊號
- blockTime： withdraw交易的區塊時間戳
- txRoot：區塊交易樹的root值
- receiptRoot：區塊收據樹的root值
- receipt： withdraw交易的收據
- receiptProof： withdraw交易收據的默爾克證明
- branchMask：收據樹中32位表示的收據路徑
- receiptLogIndex：從收據樹中讀取的日誌索引
下面是該函數的核心邏輯，主要包括三部分：第一部分是校驗withdraw交易收據的有效性，第二部分是校驗檢查點是否包含了交易區塊，第三部分是調用predicate合約中的exitTokens ()函數將鎖定的代幣發送給用戶。
4、以ERC20Predicate合約為例，即從log中解碼出接收者、發送者、發送代幣數量後，將給定數量的代幣發送給用戶。
由PoS Bridge跨鏈消息傳遞過程源碼分析可知，整個過程的函數調用都只有驗證者指定的角色才能調用，所以跨鏈的安全性僅由PoS保證（公證人）。
4_跨鏈消息傳遞—Plasma Bridge
Plasma Bridge同樣包含兩個功能：Deposit和Withdrawals，具體流程如下圖所示：
Polygon Plasma與我們跨鏈橋系列第一篇文章介紹的比特幣Plasma MVP實現略有差別，主要採用基於賬戶模型的Plasma MoreVP。該算法與Plasma相比，主要在withdraw部分做了部分改進。
由於ERC20、ERC721的代幣傳輸，是通過類似比特幣UTXO的event日誌實現的，所以我們首先介紹一下該事件：
- input1：轉賬前發送者的賬戶餘額
- input2：轉賬前接收者的賬戶餘額
- output1：轉賬後發送者的賬戶餘額
- output2：轉賬後接收者的賬戶餘額
其次，原先的Plasma MVP，由於區塊是由單個（Operator）或者少數的區塊生產者生成，因此在Polygon上存在以下兩種攻擊場景：
Operator作惡：
上一篇文章（ 跨鏈橋安全研究(二) | Nomad跨鏈橋）提到，當用戶的交易被Operator打包為Plasma區塊後，存在鏈下數據的不可用性問題。因此，用戶在進行exit交易時，如果從較舊的交易開始退出，Operator可以使用其最近的一筆交易對其發起挑戰，則會挑戰成功。同時，由於Plasma中採用了PoS的檢查點機制，Operator如果勾結驗證者作惡，甚至可以偽造一些狀態轉換並提交到以太坊。
用戶作惡：
用戶在發起exit交易後，繼續在Polygon上花費代幣，類似於跨鏈的雙花。
綜上，Polygon的Plasma MoreVp算法採用了另一種計算退出優先級的算法，即從最近的交易開始退出。該方式由於使用了類似UTXO的LogTransfer事件，只要用戶的合法交易使用了正確的input1、input2，即使Operator一些惡意交易打包在用戶交易之前，由於用戶交易僅來自有效的input，所以也能被正確處理。相關偽代碼如下：
Deposit
下面以用戶Alice使用Plasma Bridge將其以太坊賬戶上的代幣資產發送到其在Polygon賬戶中為例進行介紹：
1、首先用戶同樣需要將其需要轉移的代幣資產通過approve函數授權給主鏈（Ethereum）上的Polygon合約depositManager。
2、同樣等到授權交易被確認後，用戶調用erc20token.deposit()函數，觸發depositManager合約的depositERC20ForUser()函數，存入用戶的ERC20代幣資產。
3、當以太坊主網確認了該deposit交易，接下來會創建一個僅包含這筆交易的區塊，並將其採用狀態同步機制發送到Polygon網絡上的childChain合約中，mint相同數量的映射幣並存入用戶在Polygon上的賬戶。
注：由childChain合約源碼分析可知，Plasma僅支持三種類型，包括：ETH、ERC20、ERC721。
Withdraw
當用戶想使用Plasma bridge從Polygon上提取資產到以太坊上，會經歷以下幾個步驟：
1、用戶通過調用Polygon上映射幣的withdraw()函數，burn掉Polygon鏈上的映射代幣資產：
也可以調用Polygon上的Plasma Client的withdrawStart()接口實現。
2、用戶可以調用ERC20Predicate合約中startExitWithBurntTokens()函數，該函數首先會調用WithdrawManager.verifyInclusion()校驗checkpoint是否包含withdraw交易和對應的收據，代碼如下：
驗證通過後，將調用WithdrawManager.addExitToQueue()將其按照優先級排序插入到消息隊列中：
最後，addExitToQueue()調用_addExitToQueue()鑄造一個NFT作為退款憑證：
3、用戶等待7天的挑戰期
4、挑戰期完成，可以調用WithdrawManager.processExits()函數將代幣發送給用戶。
該函數主要分為兩個步驟：首先確認消息隊列中的withdraw交易是否已經過了7天挑戰期，如果已經超過挑戰期則將其該交易移除隊列：
接著，判斷退款憑證NFT是否在挑戰期內被刪除，未被刪除則將該NFT銷毀並將對應資產退還給用戶：
5_Polygon Plasma Bridge 雙花漏洞
2021 年10 月5 日，白帽子Gerhard Wagner提交了一個Polygon漏洞，該漏洞可能導致雙花攻擊，涉及到的金額為8.5億美元，白帽子因此獲得了Polygon官方的2,000,000 美元漏洞賞金。
在前文Plasma Bridge的介紹中我們知道，完整的一次Withdraw交易過程為：
-用戶在Polygon上發起Withdraw交易，該交易會burn掉用戶在Polygon的代幣；
-經過一個檢查點間隔（大約30分鐘），等待該withdraw交易被包含到檢查點中；
-超過2/3的驗證者簽名後將其提交到以太坊，此時用戶調用ERC20PredicateBurnOnly合約中的startExitWithBurntTokens()校驗checkpoint是否包含burn交易；
-校驗通過，則鑄造一個NFT退款憑證發給用戶
-用戶等待7天挑戰期
-調用WithdrawManager.processExits()銷毀NFT，並退款給用戶
注意： Polygon為了防止交易重放（雙花攻擊），使用NFT作為退款憑證，來唯一標識一筆Withdraw交易。但是，由於NFT的ID生成缺陷，造成了攻擊者可以構造參數利用同一筆有效的Withdraw交易，生成多個不同ID的NFT，再利用這些NFT進行退款交易，從而實現“雙花攻擊”。
下面將對如何如何生成NFT進行詳細介紹：
1、由上文中的源碼解析可知，addExitToQueue()會調用_addExitToQueue()鑄造一個NFT：
由傳參分析可知，exitid = priority，則NFT的ID即為Plasma Bridge中的age優先級左移一位生成。
2、上文的源碼解析可知，age是WithdrawManager.verifyInclusion()函數的返回值，該函數會首先校驗withdraw交易的有效性，校驗通過則生成對應的age。其中，校驗的邏輯中使用了可控參數data解碼出的值branchMaskBytes：
同時生成age時也使用了該值：
3、跟踪交易驗證邏輯中的調用的MerklePatriciaProof.verify()函數，發現該函數調用_getNibbleArray()對branchMaskBytes進行了轉碼操作：
4、繼續跟踪該解碼函數，該函數對branchMaskBytes轉碼時存在丟棄部分值的情況，這種數值丟失的方式會造成不同的值轉碼後獲得同樣的解碼值。具體為：如果傳入的hp編碼後的值b的第一個十六進制位（半個字節）是1或3，就解析第二個十六進制位。否則，就直接忽略第一個字節。
那麼如果攻擊者構造一個branchMaskBytes參數，使得其第一個十六進制位不等於1和3，則共有14*16 = 224種方式，能夠獲得相同的轉碼後的值。
具體的攻擊流程為：
-通過Polygon Plasma向Polygon存入大量ETH/代幣
-在Polygon上發起Withdraw交易，等待7天的挑戰期
-修改withdraw交易中branchMaskBytes參數的第一個字節（同一有效交易最多可以重新提交223次），重複發起Withdraw交易
綜上，該漏洞主要是由於生成防止重放的退款憑證NFT的ID算法設計存在問題，導致相同的退款交易可以生成不同的NFT，造成雙花攻擊。事實證明，編碼分支掩碼的第一個字節應該始終是0x00. 修復方法是檢查編碼的分支掩碼的第一個字節是否是0x00並且不要將其視為不正確的掩碼。
好了，今天的分享就結束了，下一期，成都鏈安安全研究團隊將介紹另一個跨鏈項目的安全研究，盡請期待。
