例如在Uniswap v2中，只有智慧合約因素應該初始化Uniswap對。
Uniswap團隊透過一個簡單的檢查就解決了他們的問題，但是無論我在哪裡，我都能找到更多為每個專案從頭開始編寫編排解決方案的例子。
在理解此問題並開發模式的過程中，我們更好地瞭解瞭如何從多個智慧合約中構建應用程式，這使Yield更加健壯和安全。
在本文中，我將透過著名專案中的示例深入研究智慧合約編排。當您讀完它時，您將能夠檢視您自己專案的編排需求，並決定哪一種現有方法適合您。
我建立這個示例儲存庫是為了在您準備好時讓您繼續。
讓我們準備開始操作把。
背景
我已經提出，您需要將您的專案分解為一系列智慧合約，因為有兩個限制，一個是技術上的限制，一個是精神上的限制。
技術限制是在2016年11月實施的。當時，以太坊主網（包括EIP-170）實施了Spurious Dragon硬叉。此更改將已部署的智慧合約的大小限制為最大24576位元組。
沒有此限制，攻擊者便可以部署智慧合約，從而在部署期間進行無限量的計算。它不會影響儲存在區塊鏈中的任何資料，但可以用作對以太坊節點的拒絕服務攻擊。
當時限制氣體限制不允許使用這種規模的智慧合約，因此這種變化被認為是非破壞性的：
“解決方案是對可以儲存到區塊鏈中的物件的大小設定硬上限，並透過將上限設定為略高於當前氣體限制的可行值來進行無中斷操作-案例智慧合約可以使用470萬個氣體以〜23200位元組建立，通常建立的智慧合約可以達到〜18 kb。”
那是在DeFi爆炸之前。對於Yield，我們編碼了2000行智慧合約程式碼，部署後的總和將接近100 KB。我們的審計人員甚至不認為我們的專案非常複雜。
但是，我們仍然必須將專案分解為多個智慧合約。
· 複雜性與物件導向程式設計
將區塊鏈應用分解為多個智慧合約的第二個原因與技術限制無關，而與人為限制無關。
我們在一個特定的時間只能在大腦中儲存那麼多資訊。如果我們能處理以有限方式相互作用的小問題，我們的表現會比在一個單一的大問題中處理所有事物都能相互作用的問題要好。
可以說，物件導向程式設計使軟體可以達到更高的複雜度。透過定義代表某種概念的“物件”，並將變數和函式定義為物件的屬性，開發人員可以更好地從心理上解決他們要解決的問題。
Solidity使用物件導向程式設計，但在智慧合約級別。您可以將智慧合約視為具有變數和功能的物件。複雜的區塊鏈應用程式將更容易在您的腦海中描繪為一組智慧合約，每個智慧合約代表一個實體。
例如在MakerDAO中，每種加密貨幣都有單獨的智慧合約，記錄債務的另一個智慧合約，代表債務庫和外部世界之間閘道器的單獨智慧合約等。試圖在單個智慧合約中編寫所有程式碼可能是不可能的。如果可以的話，那也是很難。
將大問題分解為以有限方式互動的小問題確實有幫助。
· 部署
在下一節中，我們將研究Uniswap，MakerDAO和Yield的業務流程實現。這會很有趣的。
· 簡單的一個-Uniswap和Ownable.sol
我喜歡Uniswap v2，因為它太簡單了。他們成功的在410行智慧合約程式碼中建立了非常成功的去中心化交易所。它們只有兩種部署的智慧合約：一個factory和不限數量的交易對合約。
由於他們factory合約的設計方式，新的交易對合約的部署需要兩個步驟。首先部署智慧合約，然後使用將要交易的兩個令牌對其進行初始化。
我不知道他們是如何保護自己不受攻擊的，但他們需要確保只有建立配對交易合約的factory才能初始化該合約。為了解決這個問題，他們重新實現了Ownable模式。
如果你的案子和他們的一樣簡單，你也會成功的。如果您知道您的智慧合約只需要授予對另一個智慧合約的特權訪問權，那麼您可以使用Ownable.sol. 你甚至不需要使用像Uniswap這樣的factory。您可以讓一個使用者部署兩個智慧合約（Boss和Minion，Minion繼承自Ownable.sol），然後執行minion.transferOwnership（address（boss））。
· 最完整的一個示例-Yield
對於Yield，我們沒有設法編寫像Uniswap v2一樣簡單的解決方案。我們的核心是五個智慧合約，特權訪問關係不是一對一的。一些智慧合約具有受限制的功能，我們需要將這些功能提供給核心組中的多個智慧合約。
因此，我們只是將Ownable.sol擴充套件為具有兩個訪問層，其中之一具有多個成員：
智慧合約所有者可以將任何地址新增到特權列表（業務流程）。繼承合約可以包括onlyOrchestrated修飾符，該修飾符將限制對註冊地址的訪問。
作為附加的安全檢查，每個地址都與功能簽名一起註冊，從而縮小了在Orchestrated合同中對單個功能的訪問範圍。檢查示例儲存庫以獲取有關此內容的詳細資訊。
沒有一個函式可以撤消訪問權，因為我們會在部署過程中對智慧合約進行編排，然後所有者透過對所有智慧合約呼叫transferOwnership（address（0））放棄對自己的特權訪問。
我們自己的平臺令牌yDai將從Orchestrated繼承，並將mint限制為在部署期間設定的特定智慧合約：
這種模式相對易於實現和除錯，並允許我們實現僅應由我們控制的合約使用的函式。
· MakerDAO
MakerDAO因使用荒謬的術語而臭名昭著，這使其非常難以理解。直到我分解Yield問題之後，我才意識到他們使用的實現幾乎完全相同。
1. 智慧合約部署者是wards的原始成員。
2. wards可以依靠其他人（usr），以便他們也可以成為wards。
3. 函式可以被限制（auth），這樣只有wards才能執行它們。
舉例來說，MakerDAO的Vat.sol合約中的fold函式用於更新利率累加器，並且只能由其集合中的另一個合約呼叫（Jug.sol合約，drip函式）。如果您檢視該函式，將看到auth修飾符，這是它們用於業務流程的內容：
在某種程度上，auth和其他業務流程實現是私有和內部功能概念的擴充套件，僅用於智慧合約之間的訪問控制。
MakerDAO的實現與我們自己想到的實現非常相似。
1. 智慧合約部署者是 wards的原始成員。在收益率中它將是owner。
2. wards可以依靠其他人（usr），以便他們也可以成為wards。在Yield中，只有所有者可以將其他地址指定為特權。
3. 函式可以被限制（auth），這樣只有wards才能執行它們。在收益率中，我們說只有經過onlyOrchestrated的地址才能呼叫標記的函式。我們進一步限制對單個函式的訪問。
除了在Yield中我們使用了兩個訪問層（owner和authorized）和單個函式限制，實現是相同的。智慧合約編排是一種通用模式，可以實現一次並經常重用。
為了使稽覈員和使用者更加滿意，我們還開發了一個指令碼，該指令碼可追蹤區塊鏈事件並描繪我們智慧合約的所有權和業務流程。該指令碼可從我們的網站上線獲取，並證明除部署時設定的智慧合約外，沒有人擁有或曾經有特權訪問過它們。
畢竟，這就是智慧合約編排的重點。
結論
智慧合約的編排是一個在大多數專案中都會重複出現的問題，並且大多數專案都是從頭開始實施的。通常所實現的解決方案彼此幾乎相同。
