我們在2019年6月30日發(fā)布了MOLDEX α。在這里，我們將總結(jié)MOLDEX α系統(tǒng)架構(gòu)的概述，包括以下三點(diǎn)。希望它對Dapps和區(qū)塊鏈的未來發(fā)展有所幫助。

· 關(guān)于DEX的智能合約

· 關(guān)于服務(wù)器端

· 關(guān)于瀏覽器錢包

MOLDEX α的結(jié)構(gòu)旨在了解處理性能和非功能性要求（例如可用性，操作和可維護(hù)性），用戶角度的可設(shè)計性以及未來的UX改進(jìn)。此外，考慮到與區(qū)塊鏈的兼容性，MOLDEX α配置了完整的區(qū)塊服務(wù)器。

關(guān)于DEX的智能合約

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

資產(chǎn)智能合約

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

· approve（）

approve（）函數(shù)用于允許第三方（在本例中為DEX合約）從發(fā)件人的余額中轉(zhuǎn)移通證（token）（在ERC721的情況下，指定tokenId）。通證（token）存儲在允許類型映射數(shù)據(jù)結(jié)構(gòu)中。

// 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（）函數(shù)用于由第三方傳輸通證（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（）函數(shù)是一個視圖函數(shù)，它返回由approve（）函數(shù)指定的通證（token）值。在ERC721的情況下，getApproved（）函數(shù)以相同的方式準(zhǔn)備，并且它是一個視圖函數(shù)，它返回有權(quán)從tokenId傳輸通證（token）的地址（即已批準(zhǔn)）。

// 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］;

}

資產(chǎn)交換流程

Taker為Token Contract執(zhí)行approve（）函數(shù)，并批準(zhǔn)轉(zhuǎn)移任意數(shù)量的moldcoin（在網(wǎng)站中，它表示為存款但實(shí)際上是批準(zhǔn)的過程）。

制造商將執(zhí)行Dex Contract交易功能所需的數(shù)據(jù)傳遞給服務(wù)器。Taker將執(zhí)行Dex Contract的交易功能所需的數(shù)據(jù)傳遞給服務(wù)器。

在服務(wù)器端，當(dāng)收集Maker和Taker的數(shù)據(jù)時，執(zhí)行交易功能。在交易功能中，執(zhí)行Dex Contract允許的transferFrom（）。此時，transferFrom要傳輸?shù)耐ㄗC（token）必須由approve（）函數(shù)批準(zhǔn)。

執(zhí)行transferFrom（）函數(shù)以完成從Taker到Maker的Moldcoin轉(zhuǎn)移，以及將ERC721資產(chǎn)從Maker轉(zhuǎn)移到Taker。

1.準(zhǔn)備與批準(zhǔn)功能交換

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

2.發(fā)送簽名訂單數(shù)據(jù)

必要的訂單數(shù)據(jù)被發(fā)送到服務(wù)器以執(zhí)行交易功能。

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

· 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.執(zhí)行交易功能

服務(wù)器端主要執(zhí)行rawdata verification和簽名驗(yàn)證。

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

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

4.執(zhí)行transferFrom功能

當(dāng)Dex Contract是msg.sender時，transferFrom函數(shù)執(zhí)行兩次以移動ERC20通證（token）并移動ERC721通證（token）。

使用代理智能合約

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

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

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

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

初始化

1. 部署OwnedUpgradeabilityProxy

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

3. 調(diào)用OwnedUpgradeabilityProxy 的 upgradeToAndCall函數(shù)在代理契約方注冊邏輯契約，并初始化代理契約方。

更新

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

調(diào)用OwnedUpgradeabilityProxy 的 upgradeTo函數(shù)來更新邏輯契約

將實(shí)現(xiàn)地址分配給適當(dāng)?shù)纳⒘凶止?jié)字符串，以將變量的信息存儲在代理協(xié)定方定義的存儲槽中。

//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）

}

}

使用代理協(xié)定中定義的非結(jié)構(gòu)化存儲槽來存儲升級所需的數(shù)據(jù)。

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

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

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

Zeppelin實(shí)驗(yàn)室存儲庫提供的實(shí)現(xiàn)也使用代理契約的概念。代理智能合約的所有者是唯一可用于升級或轉(zhuǎn)移代理智能合約所有權(quán)的地址。

此代理智能合約的最大優(yōu)點(diǎn)是邏輯智能合約方不必將其定義為代理的一部分。

注意

對于失去其功能的可擁有智能合約等構(gòu)造函數(shù)也是如此。在部署邏輯協(xié)定時，只有構(gòu)造函數(shù)確定的初始狀態(tài)不存儲在代理協(xié)定方中。

因此，在邏輯契約中，您需要創(chuàng)建初始化函數(shù)等并正確定義所有者?；蛘?，當(dāng)您使用upgradeToAndCall函數(shù)進(jìn)行Update時，需要調(diào)用并初始化作為構(gòu)造函數(shù)的函數(shù)。

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

關(guān)于服務(wù)器端配置

MOLDEX α使用無服務(wù)器架構(gòu)，主要執(zhí)行三個過程：靜態(tài)文件處理，API處理和批處理。

靜態(tài)文件處理

靜態(tài)文件處理用作js文件和圖像文件的存儲目標(biāo)，并使用CloudFront作為CDN和S3構(gòu)建，用于托管靜態(tài)網(wǎng)站。

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

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

API處理

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

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

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

批量處理

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

此外，如果正在批準(zhǔn)的資產(chǎn)轉(zhuǎn)移到另一個地址，則批準(zhǔn)Dex智能合約將失效。因此，有必要定期監(jiān)測以太坊側(cè)的容許量。

CI/CD環(huán)境

它成為上面的通用配置圖，但是通過運(yùn)行Build→test→從circleCI部署，它能夠相對平穩(wěn)地進(jìn)行開發(fā)。

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

關(guān)于瀏覽器錢包

目前，以太坊上的大多數(shù)Dapps使用Metamask，但MOLDEX α已經(jīng)實(shí)現(xiàn)了應(yīng)用程序的內(nèi)置瀏覽器錢包，而不是使用Metamask。目的是要意識到可以被不熟悉區(qū)塊鏈的用戶使用的DEX。

我們認(rèn)為對區(qū)塊鏈稍微熟悉的用戶像往常一樣增加了chrome的擴(kuò)展，但大多數(shù)用戶目前不使用元掩碼甚至擴(kuò)展。

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

私鑰管理

在DEX中，用戶完全負(fù)責(zé)私鑰管理，而服務(wù)器端沒有關(guān)于用戶私鑰的信息。

首次訪問MOLDEX的用戶需要使用createkey創(chuàng)建新帳戶或?qū)氍F(xiàn)有的以太坊錢包。

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

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

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

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

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

使用MOLDEX α?xí)r，請確保導(dǎo)出密鑰文件并將其存儲在云端或安全位置。

DEX的好處

關(guān)于DEX的優(yōu)點(diǎn)有三點(diǎn)。

· 隱私受到保護(hù)

· 安全性高

· 操作的可能性很低

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

使用MOLDEX α，任何人都可以在應(yīng)用程序上創(chuàng)建一個帳戶并開始交易。此時，由于服務(wù)器端不管理用戶信息，因此實(shí)現(xiàn)了完全匿名的事務(wù)。

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

此外，即使操作方也無法在服務(wù)器上非法操縱訂單，因?yàn)橛唵问鞘褂糜脩舻乃借€簽名的，并且簽名在Dex智能合約上得到驗(yàn)證。因此，用戶可以無信任地交易MOLDEX α（無需信任服務(wù)器端）。

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

MOLDEX的未來

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

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

· 增加ERC721的資產(chǎn)類型

· 使ETH可以交換

· 啟用ERC1155資產(chǎn)的交換

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

· 添加登錄登錄功能

· 制作游戲頁面

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

與此同時，在MOLD，我們希望建立一個專門從事游戲的原創(chuàng)連鎖店，以解決Etheruem在游戲方面的問題。通過在以太坊進(jìn)行MOLDEX開發(fā)以及在原有產(chǎn)業(yè)鏈上進(jìn)行研發(fā)，我們將在快速變化的區(qū)塊鏈行業(yè)中穩(wěn)步推進(jìn)項(xiàng)目。