OpenSea 新協議 Seaport 源碼解析_SEA

近期，NFT 市場 OpenSea 宣布推出全新 Web3 市場協議 Seaport 協議，用于安全高效地買賣 NFT。本文將深度分析其關鍵業務實現和接口實現。SeaPort官方文檔 https://docs.opensea.io/v2.0/reference/seaport-overview ， 可配合查閱，進一步加深理解。

Uniswap 用開源去中心化交易改變了加密貨幣交易的游戲規則，這是我們現在所知的 2020 年 DeFi Summer的開始，也帶來了 DEX 和 DeFi 的大規模增長和創新 。OpenSea的新協議Seaport或許也有改變NFT交易游戲規則的潛力，這也是我們分析Seaport協議的原因。

Seaport 是一個市場合約，用于安全有效地創建和執行 ERC721 和 ERC1155 代幣的訂單。 每個訂單包含任意數量的供應商愿意提供的物品（“報價(offer)”）以及任意數量的必須連同其各自的接收者一起接收的物品（“對價(consideration)”）。Seaport 協議的 6 大關鍵點，以及它對 NFT 領域的意義：（1）開源代碼：有了 Seaport 協議，任何人都可以使用該協議構建一個 NFT 市場，因為它是去中心化和開源的。在未來幾年，我們應該會看到更多的 NFT 市場建立起來。更多的競爭=更好+更快的創新（2）去中心化：OpenSea 說這個協議沒有合約所有者，任何人都可以更新或生成代碼。（3）交易新范式：與一些平臺只能用加密貨幣換取 NFT 不同，Seaport 協議允許用戶以一系列新方式獲取 NFT，投標人（或報價者）可以捆綁不同的資產（如提供 ETH/ERC20/ERC721/ERC1155 資產）以換取 NFT。（4）交易特定的 NFT：當交易 NFT 時，你也可以設置 NFT 必須具備的特定“條件”。（5）荷蘭式拍賣列表：在 Seaport 協議中，你可以設置一個開始和結束價格，表明你希望拍賣持續多長時間。該列表將降低（或提高）價格，直到找到買家（或拍賣時間到）。（6）更高的安全性：OpenSea 正在進行為期兩周的協議審計競賽，獎金總額為 100 萬美元。任何開發人員都可以審核代碼，提交他們發現的評審和錯誤，并獲得獎勵。

每一個訂單都包含11個關鍵組件：

offerer 訂單的報價者提供了所有的供應代幣并且必須親自執行訂單（即 msg.sender == offerer ）或者通過簽名（標準的65字節 ECDSA，64字節 EIP-2098 或 EIP-1291 isValidSignature 檢查）或列舉鏈上訂單（即調用 validate）來批準訂單。

zone 訂單的區域是附加到訂單的可選輔助帳戶，具有兩個額外的權限：

該區域可以通過調用 cancel來取消命名為該區域的訂單。（注意，報價者仍可以取消他們自己的訂單，可以單獨取消，也可以通過調用 incrementNonce 立刻取消由其當前 nonce 簽名的所有訂單）。

“受限”訂單（有訂單類型聲明）必須由區域或報價者執行，或者必須通過調用區域上的 isValidOrder 或 isvalidOrderIncludingExtraData 視圖函數來獲得批準。

offer 報價包含可以從報價者帳戶轉移的一系列代幣，其中每個代幣由以下組件組成：

itemType 指定代幣類型，有效類型包括 Ether（或者其他指定鏈的原生代幣）、ERC20、ERC721、ERC1155、ERC721、有“條件(criteria)”的 ERC721 以及有“條件(criteria)”的 ERC1155。

Opera加密瀏覽器集成Coin98:金色財經報道，Opera加密瀏覽器宣布集成Coin98，用戶將能直接訪問 Coin98 的多鏈 NFT、DEX、跨鏈橋、資產交換以及加密貨幣Staking和借貸服務，旨在進一步推動 Dapp、游戲和元宇宙發展，推動加密貨幣和Web3采用。[2022/7/7 1:58:40]

token 指定代幣合約的賬戶地址（空地址用于以太幣或其他原生代幣）。

identifierOrCriteria 表示 ERC721 或 ERC1155 代幣標識符，或者在基于條件的代幣類型的情況下，表示由代幣的有效代幣標識符集合組成的 merkle 根。對于 Ether 和 ERC20 類型 ，該值會被忽略，并且對于基于條件的代幣類型，可以將值設置為 0 以允許任何標識符。

startAmount 表示如果在訂單激活時完成訂單所需要的相關代幣的數量。

endAmount 表示如果在訂單到期時執行訂單所需要的相關代幣的數量。如果此值與 startAmount 不同，則根據訂單激活后經歷的時間線性計算出實際的數量。

consideration 包含為完成訂單而必須接收的代幣數組。它包含所有與所提供代幣相同的組件，并且還包括一個用于接收每個代幣的 recipient 組件。該數組可以由執行者在訂單執行時進行擴展，以支持“小費”（例如中繼費或推薦費）。

orderType 訂單類型，根據兩個不同的偏好，指定訂單的四種類型之一，：

FULL 表示不支持部分填充，而 PARTIAL 允許填充訂單中的一部分，注意每個代幣必須被提供的分數完全整除（即除法后沒有余數）。

OPEN 表示任意賬戶都可以提交執行訂單的調用，而 RESTRICTED 則需要訂單必須由報價者或訂單所在區域執行，或者在區域上調用 isValidOrder 或 isValidOrderIncludingExtraData 視圖函數時返回表示訂單被批準的神奇的值。

startTime 表示訂單激活時的區塊鏈時間。

endTime 表示訂單到期的區塊鏈時間。該值與 startTime 與每個代幣的 startAmount 和 endAmount 一起使用以得出它們的當前數量。

zoneHash 表示一個任意的 32 字節值，當執行受限訂單時，該值將提供給區域，該區域在確定是否是授權訂單時可以使用該值。

salt 表示訂單的任意熵源。

conduitKey 是一個 bytes32 類型的值，表示在執行轉移時應將哪個渠道(conduit)（如果有）用作代幣批準的來源。默認情況下（即當 conduitKey 設置為零哈希時），報價方將直接向 Seaport 授予 ERC20、ERC721 和 ERC1155 代幣批準，以便它可以在執行期間執行訂單指定的任何轉移。相反，選擇使用渠道的報價者將授予與提供的渠道密鑰相對應的渠道合約的代幣批準，然后 Seaport 指示該渠道轉移相應的代幣。

nonce 表示必須與給定報價者的當前隨機數匹配的值。

訂單通過以下4種方式中的一種來執行：

調用兩個“標準”函數 fulfillOrder 和 fulfillAdvancedOrder 中的一個，并且構造第二個隱含訂單，同時其調用者作為報價者(offerer)，已執行訂單的對價(consideration)作為報價(offer)，已執行訂單的報價作為對價（使用“高級”訂單包含應與一組“條件解析器”一起填寫的部分，這些“條件解析器”為已執行訂單上的每個基于條件的代幣指定一個標識符和相應的包含證明）。所有報價代幣將從訂單報價者轉移到執行者，然后所有對價代幣將從執行者轉移到指定的接收者。

Ethereum、OpenSea、LooksRare位列近30天公鏈和DAPP收入排行榜前三:金色財經消息，據Tokenterminal數據顯示，Dapp和公鏈在過去30天累計協議收入數據表現差異很大。Ethereum錄得5.37億美元，排名第一。第二位是OpenSea，錄得7000萬美元。第三名是LooksRare，錄得3400萬美元。這也意味著，NFT交易平臺是行業里最賺錢的應用。更多數據顯示，第四被Avalanche奪走，排名第五的項目是錢包Metamask。第六是最近很火的ENS。這也意味著，DeFi項目跌出前五。入圍前十的項目有MakerDAO，Curve和Pancakeswap。[2022/5/23 3:34:50]

調用"基本"函數 fulfillBasicOrder，并提供六種基本路線類型（ETH_TO_ERC721、ETH_TO_ERC1155、ERC20_TO_ERC721、ERC20_TO_ERC1155、ERC721_TO_ERC20 以及 ERC1155_TO_ERC20）中的一種，將從組件子集派生要執行的訂單，假設相關訂單符合以下條件：

該訂單僅包含一個報價代幣，并且包含至少一個對價(consideration)代幣。

該訂單僅包含一個 ERC721 或 ERC1155 代幣，并且該代幣不是基于條件的。

訂單的報價者是第一個對價代幣的接收者。

所有其他代幣都具有相同的以太幣（或其他原生代幣）或 ERC20 項目類型和代幣。

該訂單不提供以以太幣（或其他原生代幣）作為其項目類型的項目。

每個項目上的 startAmount 必須與該項目的 endAmount 匹配（即項目不能有升序/降序數量）。

所有“忽略”的項目字段（即 token 和原生代幣項目中的 identifierOrCriteria 以及 ERC20 項目中的 identifierOrCriteria）都設置為空地址或零。

如果訂單中有 ERC721 項目，則該項目的數量為.1

如果訂單有多個對價(consideration)項目，且除了第一個對價項目以外的所有對價項目與報價項目的項目類型相同，報價項目數量不小于除了第一個對價項目數量外的所有對價項目數量之和。

調用兩個“可用執行”函數（fulfillAvailableOrders 和 fulfillAvailableAdvancedOrders）中的一個，并且提供一組訂單與一組執行聲明，其中的執行聲明指定哪些報價項目可以聚合到不同的轉移中，相應地哪些對價項目可以聚合在一起，以及其中已經取消的訂單是因為時間無效，或者已經完全成交的訂單將被跳過，而不會導致其余可用訂單回滾。此外，一旦鎖定 maximumFulfilled 可用訂單，剩余的所有訂單都將被跳過。與標準執行函數類似，所有報價項目將從各自的報價者轉移到執行者，然后所有對價項目將從執行者轉移到指定的接收者。

調用兩個“匹配”函數（matchOrders 和 matchAdvancedOrders）中的一個，并且提供一組明確的訂單以及一組執行，該執行指定了哪些報價項目應用于哪些對價項目（并且“高級”案例以類似的方式運行標準方法，但支持通過提供的分子 numerator 和分母 denominator 小數值以及可選的 extraData 參數進行部分填充，當執行受限訂單類型時，這些參數將作為調用區域上的 isValidOrderIncludingExtraData 視圖函數的一部分提供）。 請注意，以這種方式執行的訂單沒有明確的執行者； 相反，Seaport 將簡單地確保每個訂單的需求一致。

NFT市場OpenSea交易額超230億美元:金色財經報道，據dappradar數據顯示，NFT市場OpenSea交易額超230億美元達235億美元。NFT市場交易總額排名前五的項目為：OpenSea（235億美元）、LooksRare（181.6億美元）、AxieInfinity（41.7億美元）、CryptoPunks（26.6億美元）、NBATopShot（8.85億美元）。[2022/3/20 14:07:22]

雖然標準方法在技術上可用于執行任何訂單，但在某些情況下存在關鍵的效率限制：

與簡單的“熱路徑(hot path)”的基本方法相比，它需要額外的調用數據。

它要求執行者批準每個對價項目，即使對價項目可以使用報價項目來執行（在執行為 ERC721 或 ERC1155 項目提供 ERC20 項目并且還包括具有相同的考慮對價的訂單時通常是這種情況用于支付費用的 ERC20 項目類型）。

它可能導致不必要的轉移，而在“匹配”情況下，這些轉移可以減少到更小的集合。

創建報價時，應檢查以下要求以確保訂單可以執行：

報價者應在所有報價項目中有足夠的余額。

如果訂單未指明使用渠道，則報價者應為所有提供的 ERC20、ERC721 和 ERC1155 項目的 Seaport 合約設置足夠的批準。

如果訂單確實指明了使用渠道，則報價者應為所有提供的 ERC20、ERC721 和 ERC1155 項目的相應渠道合約設置足夠的批準。

執行基本訂單時，需要檢查以下要求以確保訂單可以執行：

需要執行上述檢查以確保報價者仍有足夠的余額和批準。

執行者應該對所有對價項目有足夠的余額，除了那些項目類型與訂單提供的項目類型相匹配的項目——例如，如果執行的訂單提供 ERC20 項目，并且要求向報價者提供 ERC721 項目并且向另一個接受者提供相同的 ERC20 項目，那么執行者需要擁有 ERC721 項目，但不需要擁有 ERC20 項目，因為它將來自報價者。

如果執行者不選擇使用渠道，他們需要為已執行訂單上所有的 ERC20、ERC721 和 ERC1155 對價項目設置足夠的 Seaport 合約批準，項目類型與訂單提供的項目類型匹配的 ERC20 項目除外。

如果執行者確實選擇使用渠道，則他們需要為已執行訂單上的所有 ERC20、ERC721 和 ERC1155 對價項目為其各自的渠道設置足夠的批準，項目類型與訂單提供的項目類型匹配的 ERC20 項目除外.

如果已執行的訂單將以太幣（或其他原生代幣）指定為對價項目，則執行者必須能夠將這些項目的總金額提供為 msg.value

執行標準訂單時，需要檢查以下要求以確保訂單可以執行：

需要執行上述檢查以確保報價者有足夠的余額和批準。

在收到所有的報價項目后，執行者應該對所有的報價項目有足夠的余額——例如，如果執行的訂單提供了 ERC20 項目，并且需要向報價者提供 ERC721 項目，并且向另一個接收者提供相同的 ERC20 項目，其數量小于或等于提供的數量，執行者不需要擁有 ERC20 項目，因為它將最先從報價者處接收到。

如果執行者不選擇使用渠道，他們需要為已執行訂單上的所有 ERC20、ERC721 和 ERC1155 對價項目的 Seaport 合約設置足夠的批準。

Open Meta Association 將于明年 1 月推出專注開放元宇宙的 Open Meta DAO:11月18日消息，Open Meta Association 計劃于 2022 年 1 月正式推出 Open Meta DAO，并將其治理代幣 DAO 分發給創始成員。該 DAO 將專注于開發基于 Web3 基礎設施的開放元宇宙，以加速元宇宙的增長和采用。

注，Open Meta Association 在 2021 年 6 月以 1 億美元估值的代幣預售籌集了 450 萬美元，以創建 Open Meta DAO。[2021/11/18 22:00:10]

如果執行者確實選擇使用渠道，則他們需要為已執行訂單上的所有 ERC20、ERC721 和 ERC1155 對價項目其各自的渠道設置足夠的批準。

如果已執行的訂單將以太幣（或其他原生代幣）指定為對價項目，則執行者必須能夠將這些項目的總數量提供為 msg.value

在執行一組匹配訂單時，需要檢查以下要求以確保訂單可以執行：

作為執行的一部分執行，執行采購 ERC20、ERC721 或 ERC1155 項目的每個帳戶必須在觸發執行時在 Seaport 或指定的渠道上具有足夠的余額和批準。請注意，先前的執行可能會為后續執行提供必要的余衡。

涉及以太幣（或其他原生代幣）的所有執行的總和必須以 msg.value 的形式提供. 請注意，提供者和接收者是同一帳戶的執行將從最終執行集中被過濾掉。

在構建訂單時，報價者可以選擇通過設置適當的訂單類型來啟用部分成交。然后，支持部分執行的訂單可以在相應訂單的某一部分中執行，從而允許后續執行繞過簽名驗證。總結一下部分填充的幾個關鍵點：

當創建支持部分成交的訂單或確定這些訂單要成交的部分時，訂單上的所有項目（報價和對價）數量必須能被提供的部分項目數量完全整除（即除法后沒有余數）。

如果要填寫的所需部分會導致要填寫的訂單數量超過全部訂單金額，則該部分將減少為剩余要填寫的數量。這適用于部分填充嘗試和完全填充嘗試。如果不需要這種行為（即填充應該是“全部或無”），則執行者可以使用“基本”訂單方法（如果可用）（這需要填寫全部訂單數量），或使用“匹配” 訂單方法，并明確提供一個要求收到全部所需金額的訂單。

舉例來說：如果一個執行者嘗試執行訂單的 1/2，但另一個執行者首先執行訂單的 3/4，則原始執行者最終將執行訂單的 1/4。

如果部分可成交訂單上的任一項目指定了不同的 startAmount 和 endAmount（例如，它們是遞增數量或遞減數量的項目），則在確定當前價格之前，該分數將應用于這兩個數量。這確保了在構建訂單時可以選擇完全可分的金額，而不依賴于最終完成訂單的時間。

部分成交可以與基于條件的項目進行組合，以支持構建提供或接收多個項目的訂單，否則這些項目將無法部分成交（例如 ERC721 項目）。

舉個例子：報價者可以創建一個部分可成交的訂單，為給定集合中最多 10 個 ERC721 項目提供最多 10 個 ETH；然后，任何執行者都可以執行該訂單的一部分，直到它被完全執行（或取消）。

當通過 fulfillOrder 或 fulfillAdvancedOrder 來執行訂單時：

OpenPayd發布針對數字貨幣業務的銀行和支付解決方案:以API為主導的銀行即服務提供商OpenPayd今天發布其針對數字貨幣業務的銀行和支付解決方案。OpenPayd的銀行即服務平臺通過單個API為加密業務提供訪問：

1. 加密友好銀行：多貨幣支付賬戶（支持25種以上貨幣），可選擇連接虛擬IBAN，使加密業務能夠擴展其價值鏈，并為客戶提供收款、兌換和結算服務。

2. 簡化的加密貨幣購買：客戶可以使用其首選的借記卡、信用卡或銀行電匯立即安全購買數字貨幣。

3. 法定貨幣和數字貨幣兌換：OpenPayd實現法定貨幣和加密貨幣的無縫兌換。

4. 自動化支付：將OpenPayd平臺集成到現有的財務和資金管理系統中，以簡化支付流程管理。（Cryptoninjas）[2020/7/7]

計算訂單哈希值

計算報價項目和對價項目的哈希值

檢索報價者的當前計數器

執行初始化校驗

確保當前時間在訂單有效時間內

確保調用者對于當前訂單類型是有效的； 如果訂單類型收到限制且調用者不是 offerer 或者 zone，調用 zone 判斷訂單是否有效

檢索并更新訂單狀態

確保訂單未被取消

確保訂單沒有被全部執行

如果訂單是部分執行的，如有必要，減少提供的執行數量，以免訂單被過度執行

若訂單簽名尚未驗證，則驗證訂單簽名

根據偏好 + 可用金額 (preference + available amount) 確定要執行的分數

更新訂單狀態（已驗證+執行分數）

確定每個項目的金額

比較初始金額 startAmount 和結束金額 endAmount

若相等，將執行分數應用于該金額，確保結果是整數，然后使用該結果

若不等，對這兩個金額都應用執行分數，確保兩個結果都是整數，然后根據當前時間找到這兩個結果的現行擬合值

應用條件解析器

確保每一個條件解析器都應用于一個基于條件的訂單項目

如果項目具有一個非零的條件根值(a non-zero criteria root)，確保為每個項目提供的標識符是有效的

更新每個項目的類型和標識符

確保所有剩余的項目都不是基于條件的項目

觸發 OrderFulfilled 事件

包括更新的項目（即在金額調整和條件解決之后）

將報價項目（代幣）由報價者轉移到調用者

使用渠道或 Seaport 直接獲得批準，具體取決于訂單的類型

將對價項目（代幣）有調用者轉移到對應的接受者

使用渠道或 Seaport 直接獲得批準，具體取決于執行者聲明的偏好

當通過 matchOrders 或者 matchAdvancedOrders 來匹配一組訂單時，步驟 1 到 6 幾乎完全相同，但針對每個提供的訂單執行。從這里開始，執行與上面的標準執行不同：

應用執行

確保每次執行都涉及一個或多個報價項目和一個或多個對價項目，所有這些項目都具有相同的類型和代幣，并且每個報價項目具有相同的批準源以及每個對價項目具有相同接受者

將每個報價項目和對價項目的金額減少到零，并跟蹤其總減少金額

比較每個項目的總金額，并將剩余金額加回相應訂單一側（報價項目或對價項目）的第一個項目

為每個成交返回一個執行

掃描每個對價項目并確保沒有一個對價項目仍然有非零的剩余金額

作為每次執行的一部分進行轉賬

根據原始訂單類型，直接使用渠道或 Seaport 獲得批準

忽略 to == from 或 amount == 0 時的每次執行（注意：當前實現不執行最后一次優化）

Seaport 是一個通用的 ETH/ERC20/ERC721/ERC1155 市場。它最大限度地減少了外部調用，并為普通路由提供了輕量級的方法，以及更靈活的方法來組合高級訂單。

ConsiderationInterface 包含 Seaport 的所有外部函數接口。

執行基本訂單，僅支持Ether（或指定鏈的原生代幣）與 ERC721 之間的交易。

提取訂單類型和基本訂單路由，并且對其進行校驗

準備執行基本訂單（1）添加重入鎖（2）校驗時間正確（3）檢驗參數正確（4）計算并校驗訂單的哈希值（5）更新訂單狀態

若使用了渠道，則根據訂單路由導出渠道

根據訂單路由，執行原生代幣以及ERC721代幣的轉賬，完成訂單

刪除重入鎖

fulfillOrder 執行普通訂單，不支持訂單部分執行，不支持條件解析器；普通訂單作為特殊的高級訂單進行執行。

fulfillAdvancedOrder 執行高級訂單。

添加重入鎖

_validateOrderAndUpdateStatus：根據參數，驗證訂單，更新狀態并計算訂單哈希值 orderHash 、需要執行訂單的分子 numerator 和分母 denominator（1）時間校驗：startTime <= block.time <= endTime（2）分子與分母校驗：

numerator <= denominator && denominator != 0;

若 numerator == denominator ，需要支持部分執行(Support Partial Fills)

（3）對價項目長度校驗以及計算訂單哈希值 orderHash :

訂單長度校驗：orderParameters.consideration.length >= orderParameters.totalOriginalConsiderationItems，即參數中 consideration 數組實際長度要大于或等于參數中直接傳遞的原始對價項目總數

計算訂單哈希值 orderHash

（4）校驗高級訂單的有效性：訂單類型為 2 或 3 要求 zone 或 offerer 是 caller 或 者 zone 批準。（5）校驗訂單狀態 orderStauts = _orderStatus[orderHash]，保證訂單沒有被取消并且是可執行的

訂單未取消，即：保證 orderStauts.isCancelled == false

訂單可執行，即：若 orderStatus.numerator != 0，保證 orderStatus.numerator < orderStatus.denominator。

（6）校驗訂單簽名，即若orderStatus.isValidated == false，則調用 _verifySignature 函數（7）計算需要執行訂單的分子 fillNumerator 和分母 fillDenominator（8）更新狀態變量 orderStatus

_applyCriteriaResolvers：用條件解析器，對每個生成的訂單類型以及條件解析器的綁定進行校驗，確保提交的待執行訂單是有效的

_applyFractionsAndTransferEach：以指定的分數值執行每個項目的轉賬

_emitOrderFulfilledEvent：發出一個表明訂單已完成的事件。

fulfillAvailableOrders 執行可用普通訂單，不支持訂單部分執行，不支持條件解析器；可用普通訂單作為特殊的可用高級訂單進行執行

fulfillAvailableAdvancedOrders 執行可用的高級訂單

_validateOrdersAndPrepareToFulfill：校驗訂單（若有無效訂單則跳過）、更新其狀態、通過先前填充的分數減少金額、應用條件解析器并觸發 OrderFulfilled 事件。（1）添加重入鎖（2）聲明并設置一個錯誤緩沖區變量，指明任何本地報價項目的狀態。（3）循環遍歷每一個訂單，校驗訂單，更新每一個訂單中的參數：

循環遍歷訂單中的每一個報價項目，更新報價項目中的 startAmount 和 endAmount

循環遍歷訂單中的每一個對價項目，更新對價項目中的 startAmount 和 endAmount

（4）校驗錯誤緩沖區變量（5）_applyCriteriaResolvers：應用條件解析器，對每個生成的訂單類型以及條件解析器的綁定進行校驗，確保提交的待執行訂單是有效的聚合已使用的報價和對價項目并執行轉賬（6）觸發 OrderFulfilled 事件

_executeAvailableFulfillments：完全或部分執行通過了校驗的訂單，每個訂單具有任意數量的要約和考慮項目，并執行轉移。 任何當前未激活、已完全成交或已取消的訂單都將被忽略。 然后，剩余的報價和考慮項目將在可能的情況下聚合，如所提供的報價和考慮組件數組所示，并且聚合的項目將分別轉移到履行者或每個預期的接收者。 請注意，失敗的項目轉移或訂單格式問題將導致整個批次失敗。（1）為每一個訂單的報價和對價項目的執行分配一個 Execution 結構，構造為一個 Execution 結構數組 executions ，任何當前未激活、已完全成交或已取消的無效訂單都將被忽略。（2）校驗 executions 的長度（3）對 executions 中的每一個 Execution 結構對象進行校驗，過濾掉當前未激活、已完全成交或已取消的所有訂單。（4）_performFinalChecksAndExecuteOrders：對高級訂單以及 executions 進行最后的校驗，然后執行訂單，完成執行轉賬，刪除重入鎖。

matchOrders ：對普通訂單中的報價和對價項目按參數 fulfillments 提供的報價組件分配給對價組件的條件求進行匹配然后執行，不支持訂單部分執行，不支持條件解析器；普通訂單作為特殊的高級訂單進行處理

matchAdvancedOrders：對高級訂單中的報價和對價項目按參數 fulfillments 提供的報價組件分配給對價組件的要求進行匹配然后執行

_validateOrdersAndPrepareToFulfill：校驗訂單（若有無效訂單則回滾）、更新其狀態、通過先前填充的分數減少金額、應用條件解析器并觸發 OrderFulfilled 事件。若有無效訂單，則回滾。

_fulfillAdvancedOrders：在驗證、調整金額和應用條件解析器之后，執行高級訂單（1）為每一個訂單的報價和對價項目的執行分配一個 Execution 結構，構造為一個 Execution 結構數組 executions （2）循環遍歷參數 fulfillments ，將 executions 中的每一個元素對應到fulfillments 的每一個元素，若報價人者（offerer）和接受者（recipient）是相同的，則跳過。（3）_performFinalChecksAndExecuteOrders：對高級訂單以及 executions 進行最后的校驗，然后執行訂單，完成執行轉賬，刪除重入鎖。

Tags：ORDSEAFILERC20ordi幣實時價格BOpenSeaSFIL價格erc20幣是什么意思

火必下載