MOLDEX α 的系統架構

買賣虛擬貨幣
我們在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開發以及在原有產業鏈上進行研發,我們將在快速變化的區塊鏈行業中穩步推進專案。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;