Bytom DAPP 開發流程

從目前已經發布的DAPP來看，DAPP架構大體能夠分紅3種類型：插件錢包模式、全節點錢包模式和兼容模式。

• 插件錢包模式是藉助封裝了錢包的瀏覽器插件經過RPC協議與區塊鏈節點通訊，插件在運行時會將Web3框架注入到DAPP前端頁面中，而後DApp經過Web3來與區塊鏈節點通訊。
• 全節點錢包模式須要項目方同步並持有一個區塊鏈節點，並對外提供一個瀏覽器環境與用戶進行交互。
• 兼容模式能夠在插件錢包和全節點錢包下同時使用，即上述兩種方式能夠自由切換，安全性能相對較高。

接下來介紹的比原鏈DAPP的架構模式跟帳戶模型DAPP的插件錢包模式有些類似，都是由DAPP前端、插件錢包和合約程序共同組成，其中插件錢包須要鏈接去中心化的區塊鏈服務器blockcenter，該服務器主要是爲了管理插件錢包的相關信息。此外，比原鏈是UTXO模型的區塊鏈系統，合約程序存在於無狀態的UTXO中，若是要實現這樣一個具體的DAPP，就須要在前端和後端多作一些邏輯的處理。

1. 編寫、編譯並實例化智能合約

編寫智能合約

比原鏈的虛擬機是圖靈完備的，理論上能夠實現任意圖靈計算機能實現的操做。而Equity做爲比原鏈的智能合約語言，使用Equity語言能夠實現許多典型的金融模型案例，可是爲了解決停機問題，比原鏈也設置了手續費的上限，所以用戶在設計合約的時候作一下權衡。

合約模板結構以下：

contract contract_name(...) locks valueAmount of valueAsset {
  clause clause_name(...) {
    ...
    lock/unlock ...
  }
  ...
}

Equity語法結構簡單，語句意思明確，有開發經驗的童鞋一看基本能明白合約的意思。編寫智能合約能夠參考Equity合約介紹，文檔中對Equity語言的語法和編譯方法都作了詳細的介紹。此外，文檔還對一些典型的模板合約進行了介紹，開發者能夠本身需求進行參考。

編譯並實例化合約

編譯合約目前支持兩種方式，一種是使用Equity編譯工具，另外一種是調用比原鏈中編譯合約的RPC接口compile; 而合約實例化是爲了將合約腳本按照用戶設定的參數進行鎖定，編譯並實例化合約能夠參考編譯並實例化合約的上半部分說明，該文檔不只介紹了合約的參數構造說明，還對編譯合約的步驟進行詳細說明。而編譯器以及相關工具位於Equity編譯器中，是使用go語言開發的，用戶能夠下載源代碼並編譯使用。

工具編譯和實例化示例以下：

// compile
./equity [contract_name] --bin

// instance
./equity [contract_name] --instance [arguments ...]

2. 部署合約

部署合約即發送合約交易，調用比原鏈的build-transaction接口將指定數量的資產發送到合約program中，只需將輸出output中接收方control_program設置爲指定合約便可。用戶能夠參考合約交易說明中的鎖定合約章節，交易的構造按照文檔中介紹進行參考便可。若是合約交易發送成功，而且交易已經成功上鍊，即可以經過調用API接口list-unspent-outputs來查找該合約的UTXO。

部署合約交易模板大體以下：

{
  "actions": [
    // inputs
    {
    // btm fee
    },
    {
    amount, asset, spend_account
    // spend user asset
    },

    // outputs
    {
    amount, asset, contract_program
    // receive contract program with instantiated result
    }
  ],
  ...
}

3. 搭建DAPP架構

Bytom的blockcenter服務器是官方開發的去中心化插件錢包服務器，開發者能夠按照相關API接口來調用便可。比原鏈的DAPP整體框架模型以下：

DAPP前端

搭建DAPP前端主要包含兩個方面：一個是前端與插件錢包的交互，另外一個是前端的邏輯處理、以及與緩衝服務器的交互。插件錢包是與區塊鏈節點服務器通訊的窗口，一個DAPP爲了跟區塊鏈節點進行通訊，須要經過藉助插件來與後臺服務器節點進行交互。比原的插件錢包除了與後臺服務器進行交互以外，還包含一些本地業務邏輯處理的接口API，具體內容能夠參考一下DAPP開發者嚮導。因爲比原鏈是基於UTXO模型的區塊鏈系統，交易是由多輸入和多輸出構成的結構，而且交易輸入或輸出的位置也須要按照順序來排列，所以開發DAPP須要前端處理一些構建交易的邏輯。除此以外，合約中的lock-unlock語句中涉及到數量的計算須要根據抽象語法樹來進行預計算，計算的結果將用於構建交易，而verify、if-else等其餘語句類型也須要進行相關的預校驗，從而防止用戶在執行合約的時候報錯。

從功能層面來講，前端主要包含頁面的設計、插件的調用、合約交易邏輯的處理、緩衝服務器的交互等。接下來對這幾個重要的部分展開說明：

• 1）前端頁面的設計主要是網頁界面的設計，這個部分開發者能夠本身選擇頁面模式

• 2）插件錢包已經進行告終構化的封裝，而且提供了外部接口給DAPP開發者調用，開發者只須要將插件的參數按照規則進行填充，具體請參考DAPP開發者嚮導

• 3）比原鏈的合約交易是多輸入多輸出的交易結構，前端須要進行一些預判斷邏輯的處理，而後再選擇合適的合約交易模板結構。

• 4）DAPP的插件鏈接的是去中心化的bycoin服務器，該服務器從比原節點服務器上同步的全部區塊信息和交易信息，該部分主要是在插件錢包層進行了高度的封裝，用戶只需按照接口調用便可。除此以外，須要開發者搭建一個緩衝服務器，不只能夠在管理合約UTXO層面作一些性能方面的處理，並且還能夠爲DAPP作一些數據存儲。開發者能夠根據實際需求來開發一些RPC請求接口，而後在前端頁面設置相關條件來觸發這些API的調用。

前端邏輯處理流程大體以下：

• 調用插件，比原的chrome插件源碼位於Bytom-JS-SDK，開發比原DAPP時調用插件的說明能夠參考Dapp Developer Guide，其網絡配置以下：

  window.addEventListener('load', async function() {
  
    if (typeof window.bytom !== 'undefined') {
      let networks = {
          solonet: ... // solonet bycoin url 
          testnet: ... // testnet bycoin url 
          mainnet: ... // mainnet bycoin url 
      };
  
      ...
  
      startApp();
  });

• 配置合約參數，能夠採用文件配置的方式，該步驟是爲了讓前端獲得須要用到的一些已經固定化的合約參數，其前端配置文件爲configure.json.js，其示例模型以下:

  var config = {
      "solonet": {
          ...         // contract arguments
          "gas": 0.4  // btm fee
      },
      "testnet":{
          ...
      },
      "mainnet":{
          ...
      }
  }

• 前端預計算處理，若是合約中包含lock-unlock語句，而且Amount是一個數值表達式，那麼前端來提取計算表達式並進行相應的預計算。此外，前端還須要預判下全部可驗證的verify語句，從而斷定交易是否可行，由於一旦前端對這些驗證失敗，合約將必然驗證失敗。此外，若是define或assign語句涉及的變量，前端也需預計算這些變量的值。

• 構建合約交易模板，因爲解鎖合約是解鎖lock語句條件，構造交易須要根據lock語句或unlock語句來進行變換。解鎖合約交易是由inputs和outputs構成，交易的第一個input輸入通常都是是固定的，即合約UTXO的hash值，除此以外，其餘輸入輸出都須要根據DAPP中的實際合約來進行變動，其模型大體以下：

  const input = []
  input.push(spendUTXOAction(utxohash))
  ... // other input
  
  const output = []
  output.push(controlProgramAction(amount, asset, program))
  ... // other output

• 啓動前端服務

  編譯前端命令以下：

  npm run build

  啓動以前須要先啓動bufferserver緩衝服務器，而後再啓動前端服務，其前端啓動命令以下：

  npm start

DAPP緩衝服務器

緩衝服務器主要是爲了在管理合約UTXO層面作一些效率方面的處理，包括了對bycoin服務器是如何同步請求的，此外對DAPP的相關交易記錄也進行了存儲。bycoin服務器是比原鏈的去中心化錢包服務器，緩衝服務器的UTXO跟它是同步更新的，比原官方插件錢包默認鏈接的就是該服務器。儘管bycoin服務器的也對比原鏈的全部UTXO進行了管理，可是因爲UTXO數量比較大，若是直接在該層面處理會致使DAPP性能不佳，因此建議用戶本身構建本身的緩衝服務器作進一步優化處理。此外，DAPP開發者也能夠搭建了本身的去中心化錢包服務器，而且本身開發相關的插件。

緩衝服務器架構能夠參考一下bufferserver案例的源代碼，其編譯和啓動步驟以下：

• 編譯bufferserver源代碼

  按照README安裝部署服務須要的軟件包Mysql和Redis，而後下載源代碼並編譯：

  make all

  編譯完成以後，在target目錄下會生成可執行文件api和updater。

• 啓動服務

  使用root用戶建立數據庫和數據表，其命令以下：

  mysql -u root -p < database/dump.sql

  修改配置文件config_local.json，配置說明參考README的config配置參數詳解。

  啓動api和updater服務器，其中api是提供JSON RPC請求的服務進程，updater是提供同步blockcenter和區塊鏈瀏覽器數據請求的服務進程。

  ./target/api config_local.json
  
  ./target/updater config_local.json

  啓動緩衝服務器以後，即可以啓動前端服務，而後打開DAPP的網頁URL便可使用。

  附：緩衝服務器的JSON RPC接口能夠參考wiki接口說明。

Bytom DAPP實例

Bytom DAPP 實例說明，請參考儲蓄分成DAPP