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