我們在2019年6月30日發布了MOLDEX α。在這里，我們將總結MOLDEX α系統架構的概述，包括以下三點。希望它對Dapps和區塊鏈的未來發展有所幫助。

· 關于DEX的智能合約

· 關于服務器端

· 關于瀏覽器錢包

MOLDEX α的結構旨在了解處理性能和非功能性要求（例如可用性，操作和可維護性），用戶角度的可設計性以及未來的UX改進。此外，考慮到與區塊鏈的兼容性，MOLDEX α配置了完整的區塊服務器。

關于DEX的智能合約

與MOLDEX α一起使用的智能合約可以用github或Etherscan確認。在MOLDEX α中，我們定義了交易函數（稍后描述），以便任何人都可以交換ERC721和ERC20（甚至與ETH交換）。

資產智能合約

在DEX智能合約方面構建通證（token）交換機制時，使用ERC20和ERC721中定義的兩個函數approve（）和transferFrom（）。

· approve（）

approve（）函數用于允許第三方（在本例中為DEX合約）從發件人的余額中轉移通證（token）（在ERC721的情況下，指定tokenId）。通證（token）存儲在允許類型映射數據結構中。

// ERC20

function approve（

address _spender，

uint256 _value

）

public

returns （bool）

{

allowed［msg.sender］［_spender］ = _value;

emit Approval（msg.sender， _spender， _value）;

return true;

}

// ERC721

function approve（address _to， uint256 _tokenId） public {

address owner = ownerOf（_tokenId）;

require（_to ！= owner）;

require（msg.sender == owner || isApprovedForAll（owner， msg.sender））; tokenApprovals［_tokenId］ = _to;

emit Approval（owner， _to， _tokenId）;

}

· transferFrom（）

transferFrom（）函數用于由第三方傳輸通證（token）（在本例中為DEX合約）。第三方（msg.sender）只能提取低于允許的余額（ERC721只能提取指定的tokenId）。

// ERC20

function transferFrom（

address _from，

address _to，

uint256 _value

）

public

returns （bool）

{

require（_value 《= balances［_from］）;

require（_value 《= allowed［_from］［msg.sender］）;

require（_to ！= address（0））;

balances［_from］ = balances［_from］.sub（_value）;

balances［_to］ = balances［_to］.add（_value）;

allowed［_from］［msg.sender］ = allowed［_from］［msg.sender］.sub（_value）;

emit Transfer（_from， _to， _value）;

return true;

}

// ERC721

function transferFrom（

address _from，

address _to，

uint256 _tokenId

）

public

{

require（isApprovedOrOwner（msg.sender， _tokenId））;

require（_from ！= address（0））;

require（_to ！= address（0））;

clearApproval（_from， _tokenId）;

removeTokenFrom（_from， _tokenId）;

addTokenTo（_to， _tokenId）;

emit Transfer（_from， _to， _tokenId）;

}

· allowance（）

allowance（）函數是一個視圖函數，它返回由approve（）函數指定的通證（token）值。在ERC721的情況下，getApproved（）函數以相同的方式準備，并且它是一個視圖函數，它返回有權從tokenId傳輸通證（token）的地址（即已批準）。

// ERC20

function allowance（

address _owner，

address _spender

）

public

view

returns （uint256）

{

return allowed［_owner］［_spender］;

}

// ERC721

function getApproved（uint256 _tokenId） public view returns （address） {

return tokenApprovals［_tokenId］;

}

資產交換流程

Taker為Token Contract執行approve（）函數，并批準轉移任意數量的moldcoin（在網站中，它表示為存款但實際上是批準的過程）。

制造商將執行Dex Contract交易功能所需的數據傳遞給服務器。Taker將執行Dex Contract的交易功能所需的數據傳遞給服務器。

在服務器端，當收集Maker和Taker的數據時，執行交易功能。在交易功能中，執行Dex Contract允許的transferFrom（）。此時，transferFrom要傳輸的通證（token）必須由approve（）函數批準。

執行transferFrom（）函數以完成從Taker到Maker的Moldcoin轉移，以及將ERC721資產從Maker轉移到Taker。

1.準備與批準功能交換

Taker方面使用Moldcoin（ERC20）購買ERC721資產。DEX智能合約批準任何數量的MOLD，使_spender成為Dex合約，以便它可以處理MOLD幣。Maker方面出售ERC721。為了允許DEX Contract發送ERC721資產，請將 Dex Contract批準為_spender。

2.發送簽名訂單數據

必要的訂單數據被發送到服務器以執行交易功能。

Maker將散列以下6個元素以生成orderHash and使用密鑰對其進行簽名。

· Dex Contract Address

· ERC721 Token Contract Address

· ERC721 Token ID

· Maker Address

· ERC20 Token Contract Address

· ERC20 Amount

Taker將散列以下兩個元素以生成tradeHash and 用密鑰簽名。

· orderHash

· Taker Address

3.執行交易功能

服務器端主要執行rawdata verification和簽名驗證。

rawdata是上面提到的訂單數據。從Maker/Taker方面，rawdata+orderHash或tradeHash將被發送到服務器端。在服務器端，哈希函數檢查rawdata的內容是否正確。此外，公鑰可以根據v，r，s的值和用私鑰簽名的原始數據唯一確定，因此我們還檢查簽名是否正確。

在Dex Contract的交易功能中，使用ecrecover（hash，v，r，s）驗證簽名。如果返回值與訂單所有者的地址不匹配，則將恢復訂單。

4.執行transferFrom功能

當Dex Contract是msg.sender時，transferFrom函數執行兩次以移動ERC20通證（token）并移動ERC721通證（token）。

使用代理智能合約

以太坊最大的好處之一是所有涉及資金轉移，所有已部署智能合約以及為一份智能合約完成的所有交易的交易都在區塊鏈上公布和不可變。這意味著無法隱藏或修改迄今為止所做的交易，并且驗證以太坊網絡上任何節點上所有交易的有效性和狀態的能力使以太坊成為一個非常強大的分布式系統。

但最大的缺點是，一旦部署了智能合約源代碼，就無法更改。使用集中式應用程序（Facebook，Airbnb等）的開發人員不斷更新以修復錯誤并引入新功能。在以太坊上運行這種傳統的發展模式是不可能的。

您無法升級已部署的智能合約的代碼，但您可以配置代理智能合約體系結構，該體系結構允許您使用新部署的智能合約，就像主邏輯已升級一樣。

由于此Dex合約也是alpha版本，因此預計將來會進行許多修訂和升級。那時，您可以通過分離和管理智能合約的存儲和邏輯部分來切換到新的智能合約版本。

初始化

1. 部署OwnedUpgradeabilityProxy

2. 部署邏輯智能合約的第一個版本

3. 調用OwnedUpgradeabilityProxy 的 upgradeToAndCall函數在代理契約方注冊邏輯契約，并初始化代理契約方。

更新

使用與先前邏輯協定相同的變量名部署新的邏輯協定

調用OwnedUpgradeabilityProxy 的 upgradeTo函數來更新邏輯契約

將實現地址分配給適當的散列字節字符串，以將變量的信息存儲在代理協定方定義的存儲槽中。

//UpgradeabilityProxy.sol

bytes32 private constant implementationPosition = keccak256（“org.zeppelinos.proxy.implementation”）;

function implementation（） public view returns （address impl） {

bytes32 position = implementationPosition;

assembly {

impl ：= sload（position）

}

}

function setImplementation（address newImplementation） internal {

bytes32 position = implementationPosition;

assembly {

sstore（position， newImplementation）

}

}

使用代理協定中定義的非結構化存儲槽來存儲升級所需的數據。

在代理契約中，通過散列任意字符串來定義為存儲邏輯契約地址提供足夠隨機存儲位置的常量。

由于常量狀態變量不占用存儲槽，因此無需擔心代理協議會意外覆蓋implementationPosition。根據Solidity如何在存儲中列出其狀態變量，此存儲槽不太可能與邏輯協定中定義的任何其他內容沖突。

通過使用此模式，沒有邏輯契約版本需要知道代理的存儲結構，但是所有未來的邏輯契約都需要繼承其更高版本聲明的存儲變量。將來升級邏輯智能合約將允許您升級現有功能并引入新功能和新存儲變量。

Zeppelin實驗室存儲庫提供的實現也使用代理契約的概念。代理智能合約的所有者是唯一可用于升級或轉移代理智能合約所有權的地址。

此代理智能合約的最大優點是邏輯智能合約方不必將其定義為代理的一部分。

注意

對于失去其功能的可擁有智能合約等構造函數也是如此。在部署邏輯協定時，只有構造函數確定的初始狀態不存儲在代理協定方中。

因此，在邏輯契約中，您需要創建初始化函數等并正確定義所有者。或者，當您使用upgradeToAndCall函數進行Update時，需要調用并初始化作為構造函數的函數。

非結構化存儲使用可靠性程序集來存儲邏輯契約的地址，因此邏輯契約方最好不需要繼承諸如可升級性的契約。除了能夠轉移所有者權限之外，您還可以定義新變量并將其存儲在存儲中。

關于服務器端配置

MOLDEX α使用無服務器架構，主要執行三個過程：靜態文件處理，API處理和批處理。

靜態文件處理

靜態文件處理用作js文件和圖像文件的存儲目標，并使用CloudFront作為CDN和S3構建，用于托管靜態網站。

使用CloudFront不僅可以啟用緩存，還可以啟用AWSShield和DDoS保護。此外，僅S3不能將SSL/TLS協議與其自己的域一起使用，但可以使用CloudFront來使用它。

如上所述，CloudFront提供了多種好處，因此我們采用了使用CloudFront的配置，而不是直接訪問S3。

API處理

ECS使您可以輕松地部署，管理和擴展運行應用程序，服務和批處理的Docker容器。由于容器操作，即使API更改，也可以保持應用程序可用性。

此外，目前不需要同時處理許多請求，但是可以在將來集中訪問的情況下輕松擴展應用程序。

訪問以太坊不是從前端操作，而是通過API處理，以減少前端不必要的處理。

批量處理

例如，執行交易功能后的交易歷史始終通過參考以太坊區塊鏈中的交易事件保持最新。

此外，如果正在批準的資產轉移到另一個地址，則批準Dex智能合約將失效。因此，有必要定期監測以太坊側的容許量。

CI/CD環境

它成為上面的通用配置圖，但是通過運行Build→test→從circleCI部署，它能夠相對平穩地進行開發。

這一次，我們采用了Golang作為API的一部分，并且有很多部分引用了Geth（go-ethereum）的實現。

關于瀏覽器錢包

目前，以太坊上的大多數Dapps使用Metamask，但MOLDEX α已經實現了應用程序的內置瀏覽器錢包，而不是使用Metamask。目的是要意識到可以被不熟悉區塊鏈的用戶使用的DEX。

我們認為對區塊鏈稍微熟悉的用戶像往常一樣增加了chrome的擴展，但大多數用戶目前不使用元掩碼甚至擴展。

我們認為Dapp和其他Dapps的理想是實現平穩和簡單的用戶體驗，以便用戶不知道它正在使用區塊鏈。為了使用一個Dapps，有一種方法（對于大多數用戶而言）您不需要安裝Metamask（在大多數用戶中），可以將錢包功能合并到應用程序中。使用MOLDEX α，粗加工時，通過整合瀏覽器錢包，登錄過一次的用戶可以使用只有密碼的應用程序。

私鑰管理

在DEX中，用戶完全負責私鑰管理，而服務器端沒有關于用戶私鑰的信息。

首次訪問MOLDEX的用戶需要使用createkey創建新帳戶或導入現有的以太坊錢包。

在MOLDEX α中，用戶的私鑰由會話管理，加密的json密鑰文件由瀏覽器的本地存儲永久管理。

當用戶離開頁面時，會刪除由會話管理的密鑰（例如，刪除選項卡），因此當您再次訪問它時，系統將提示您輸入密碼以解鎖存儲在本地存儲中的加密密鑰文件。

另一方面，由于即使當用戶離開頁面時加密的密鑰文件也存儲在本地存儲器中，當用戶再次訪問時，用戶只需輸入密碼來解鎖它并使用該應用程序。

錢包解鎖后，用戶可以自由使用該應用程序，直到會話終止。這簡化了繁瑣（且緩慢）的Metamask流程，每次彈出窗口都會出現并確認。

此外，如果您希望對瀏覽器進行加密，但又不想保留密鑰文件信息，則可以通過刪除密鑰從本地存儲中刪除密鑰文件信息。在這種情況下，您需要在再次訪問時執行導入密鑰。

使用MOLDEX α時，請確保導出密鑰文件并將其存儲在云端或安全位置。

DEX的好處

關于DEX的優點有三點。

· 隱私受到保護

· 安全性高

· 操作的可能性很低

讓我們看看這些特征是否實際上在MOLDEX α中。

使用MOLDEX α，任何人都可以在應用程序上創建一個帳戶并開始交易。此時，由于服務器端不管理用戶信息，因此實現了完全匿名的事務。

此外，由于用戶的私鑰由用戶管理，即使服務器端被黑客攻擊，也不可能移動用戶的資產（游戲項目或MOLD幣）。

此外，即使操作方也無法在服務器上非法操縱訂單，因為訂單是使用用戶的私鑰簽名的，并且簽名在Dex智能合約上得到驗證。因此，用戶可以無信任地交易MOLDEX α（無需信任服務器端）。

從上述觀點來看，可以說這個MOLDEX α是一個有用的例子，它展示了MOLDEX的世界觀，并且可以特別理解DEX的優點。

MOLDEX的未來

考慮如何在P2P上自由快速地交易數字資產，一種方法是使用分散交換（DEX）。但是，從與以太坊的合作開始，如果您嘗試將DEX轉換為服務，開發成本很高，而且比您想象的更難。此外，生成以太坊的塊所需的時間和天然氣的成本是降低用戶體驗的主要因素之一。

在未來，MOLDEX α版本旨在通過添加以下各種其他功能來實現以太坊MOLD的概念。

· 增加ERC721的資產類型

· 使ETH可以交換

· 啟用ERC1155資產的交換

· 可以查看發送和接收的交易歷史記錄

· 添加登錄登錄功能

· 制作游戲頁面

※MOLDEX α是MOLD所有者的測試版。請注意，將來可能會對規格進行重大更改。

與此同時，在MOLD，我們希望建立一個專門從事游戲的原創連鎖店，以解決Etheruem在游戲方面的問題。通過在以太坊進行MOLDEX開發以及在原有產業鏈上進行研發，我們將在快速變化的區塊鏈行業中穩步推進項目。