Bitshares 基础介绍
bitshares 简介
bitshares是基于石墨烯2.0基础上的区块链交易所
在这里我会介绍如何快速搭建自有链以及区块链相关配置及其含义
bitshares的源码点击这里即可看到
在这个仓库中的readMe会有英文介绍，但是不论是它的wiki,可以说对于想要参与这个开源仓库的贡献者来说，均是非常不友好。
在bitshares根目录下，我会介绍这么几个有用的文件及模块
- -libraries 这个文件夹中包含的是bitshares各个模块的c++代码，如果需要二次开发的话，动刀的代码就是在这里
- -programs 这个文件夹中包含的是bitshares各个执行文件的代码，如果按照官方教程，最终其编译出来的可执行文件代码均会在这个目录下
- CMakeLists.txt 这个文件就标志着，bitshares是可以跨平台编译的，如果我们需要编译更多的版本，比如说对应需要支持iOS,Android的情况下，我们就需要修改这个文件了
- genesis.json 这个文件可以相当重要的，它在bitshares中可以被称为创世文件，在这里bitshares由于是从1.0迁移到目前的2.0版，因其历史数据遗留，因此这个文件内容十分庞大
我们拿到了源代码，接下来需要做什么呢?
答案自然就是将源代码编译成对应平台的可执行文件了
这里我会介绍在各个平台中分别如何编译
Bitshares编译
Linux - Ubuntu 16.04
安装环境
#升级apt—get
sudo apt-get update
#安装bitshares需要的相关环境
sudo apt-get install cmake make libbz2-dev libdb++-dev libdb-dev libssl-dev openssl libreadline-dev autoconf libtool git ntp libcurl4-openssl-dev g++ libcurl4-openssl-dev
#由于16.04中已经有boost1.58的库了，因此无需将boost从源代码编译了
sudo apt-get install libboost-all-dev
编译bitshares
#下载git代码
git clone https://github.com/bitshares/bitshares-core.git
#进入下载好的bitshares代码根目录中
cd bitshares-core
#因为bitshares采用的是git中的子仓库，因此我们需要将子仓库中的对应代码也下载下来
git submodule update --init --recursive
#调用cmake命令生成项目make文件
cmake -DBOOST_ROOT="$BOOST_ROOT" -DCMAKE_BUILD_TYPE=Release .
#最后开始编译
make
Ubuntu下编译bitshares是最简单的，本人在编译的时候几乎没有出现什么问题，但是也还是发现了几个问题，如果读者发现新的问题，可以在评论中将问题发给我，看见后会回复问题的处理
- Ubuntu下编译这个项目需要最少内存是4个G，所以如果是需要编译的虚拟机，请将内存设置为4个G及以上
Mac-os
因为我平时工作时候用的机器是Mac，因此对mac的相关操作说明也会更多
一台全新的mac，需要安装一个Xcode 和 Homebrew
Xcode可以直接在苹果商店搜索下载，在这里就不过多叙述了，但是需要提前说明，如果电脑上没有安装Xcode,请先安装Homebrew
Homebrew的安装方法网上也有很多 点击这里可以看到如何安装及相关说明
#
brew doctor
#给homebrew升级
brew update
#用homebrew安装相关依赖
brew install boost cmake git openssl autoconf automake
#搜索boost库
brew search boost
#安装boost 1.60
brew install boost@1.60
#升级openssl
brew upgrade openssl
#更换openssl的库
brew link --force openssl
按照官网的教程到这一步,依赖就已经装完了，但是这也是bitshares比较坑的地方,因为你如果继续一步一步按照这个走的话，接下来肯定会报缺少libtool这个库的错误
#用homebrew安装libtool
brew install libtool
然后我们可以继续向下一步走了
git clone https://github.com/bitshares/bitshares-core.git
cd bitshares-core
git submodule update --init --recursive
#这一步和Linux上的可以不同了
#cmake 命令是可以直接生成项目工程的，相信基本上做mac 相关开发的肯定都用过Xcode
接下来就是按照官网的教程走，标准编译
#这一步是按照官网的教程走
cmake -DBOOST_ROOT=/usr/local/opt/boost@1.60 -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl .
#直接编译
make
但是作为开发过iOS的工程师来说，直接这么编译，如果希望做定制开发肯定是希望使用Xcode进行打包和编译的，所以接下来我将展示如何把这个工程编译成Xcode项目
在这里我需要稍微普及一下cmake的一些参数
上一段shell脚本中cmake最后的那个.是代表着当前目录,也就是意味着cmake将在调用这段命令时的所在目录去寻找对应的Cmakelist.txt
如果这里我们希望将项目的编译相关文件与源码文件分离开，则我们可以在bitshares-core同级目录建立一个文件夹命名为Xcode
#退回到上一级目录
cd ..
#创建Xcode文件夹
mkdir Xcode
接下来我们希望编译出Xcode的工程，而cmake中正好提供了这一属性-GXcode
#进入到刚刚创建的Xcode文件夹中
cd Xcode
#编译出Xcode项目工程
cmake -DBOOST_ROOT=/usr/local/opt/boost@1.60 -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl -GXcode ../bitshares-core
接下来,我们只需要打开Xcode所在文件夹就可以看到对应的项目工程了,接下来就都是Xcode相关操作了
Windows
Windows 因为目前正在研究,所以先不会更新Windows的编译
可执行文件介绍
witness-node
对应的可执行文件在make时所在目录的programs/witness_node下
它在bitshares区块链中非常重要,顾名思义,它的中文名可以被翻译成见证节点。在bitshares区块链中，一个个分布着见证人的见证节点相互连接共同组成了区块链网络。
启动它的命令也很简单
#进入到witness-node 所在目录
./witness-node
这种情况下我们就可以直接连接bitshares的官方节点了，它将节点列表直接写入到其c++源码中
但是，很多时候我们并不想用他们的区块链数据，我们需要的是自建链，我们需要部署一个属于自己的链。
bitshares提供教程
这里我就按照它提供的教程展示一遍，但是shell命令会与它提供的稍有不同
- 创建一个新的创世文件
创世文件中包含这条链的所有初始信息，比如初始账户，初始见证人，各个操作的手续费，块的生成时间等等
目前看来比较详尽的一个介绍创世文件genesis.json文档的就是这篇，如果有更好的介绍可以给我推荐，我以后也会更新相应文章分析这个文件
#首先进入到witness-node所在目录中
#然后执行创建创世文件命令
./witness_node --create-genesis-json genesis.json
然后我们就可以在对应文件目录下看到genesis.json这个文件了
- 根据创世文件启动节点(首次启动节点)
创世文件存在后，我们需要再次调用见证人节点命令
#这次后缀是指定某个文件为创世文件
#如果以一个创世文件启动区块链后，请保存好该文件，以后的启动将都需要这个文件
./witness_node --genesis-json=genesis.json
节点启动完成后，我们可以直接按Ctrl+C结束这个进程
然后此时我们在当前目录下可以看见witness_node_data_dir这个文件夹
- 真正启动前的配置
刚才的命令其实是用我们给定的创世文件连接上了bitshares的自有链节点，它将自有链节点写入了源码之中
接下来我们在刚才进入刚才发现的文件夹中，其中包含的文件结构如下
- blockchain
- p2p
- log
- config.ini
blockchain中存储的是区块链的所有数据，也就是区块链的数据库;
p2p为区块链节点之间的连接信息，如果节点为独立节点(只运行在一台服务器上，不在多台服务器间同步数据)则不会有这个文件夹;
log为节点运行的日志信息;
config.ini为区块链节点的配置文件(这个文件很重要,接下来我会着重介绍这个文件);
# Endpoint for P2P node to listen on
# p2p-endpoint 为当前节点对外广播的端口号 如果将这行注释的话 witness_node 将随机创建一个端口使用 这里我们将端口设置为对全网公开的8091
#若用127.0.0.1:8091则代表只只允许本地访问
p2p-endpoint = 0.0.0.0:8091
# P2P nodes to connect to on startup (may specify multiple times)
# seed-node 代表着启动的时候连接的节点（若没有启动时希望连接节点，请不要将注释放开）
# seed-node =
# JSON array of P2P nodes to connect to on startup
#启动后连接的节点数组，如果不希望连接任何节点，请按下面的方法进行；否则请按照注释方法进行
seed-nodes = []
# seed-nodes = ["47.104.82.72:8092"]
# Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
#这个命令对启动暂时是无用(用途为记录点，但具体细节还需要研究，暂时保持)
# checkpoint =
# Endpoint for websocket RPC to listen on
# 这个命令很重要，最终由这个端口决定着区块链网页的等等客户端的连接 这里我们开放全网8090端口 客户端通过ws://服务器ip:8090 连接 非ssl
rpc-endpoint = 0.0.0.0:8090
# Endpoint for TLS websocket RPC to listen on
# 这个跟上面一样区别是这个是采用ssl证书的
# rpc-tls-endpoint =
# The TLS certificate file for this server
# ssl证书地址
# server-pem =
# Password for this certificate
# ssl证书密码
# server-pem-password =
# File to read Genesis State from
# 标志着见证节点从哪里获取创世文件 同命令行参数效果
# genesis-json =
# Block signing key to use for init witnesses,
overrides genesis file
# 可以重写创世文件中的见证人签名，具体用途暂时还没有尝试
# dbg-init-key =
# JSON file specifying API permissions
# 允许客户端访问的api（一般是全部开放）
# api-access =
# Space-separated list of plugins to activate
# 挂载的接口
# plugins =
# Enable block production, even if the chain is stale.
# 这个比较重要，是否允许区块链节点产块，即使这个链被冻结（产生第1块或者长时间未使用），一般填true
enable-stale-production = true
# Percent of witnesses (0-99) that must be participating in order to produce blocks
# 这个用途暂时未知
required-participation = false
# ID of witness controlled by this node (e.g. "1.6.5", quotes are required, may specify multiple times)
# 当前节点控制的见证人id 格式 witness-id = "1.6.5" 可以添加多个
# witness-id =
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
# 对应区块签名的公私钥对
private-key = ["BTS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
# 下面的东西用途暂时不多所以先不继续介绍了
# Tuple of [PublicKey, WIF private key] (may specify multiple times)
debug-private-key = ["BTS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]
# Account ID to track history for (may specify multiple times)
# track-account =
# Keep only those operations in memory that are related to account history tracking
partial-operations = 1
# Maximum number of operations per account will be kept in memory
max-ops-per-account = 1000
# Elastic Search database node url
# elasticsearch-node-url =
# Number of bulk documents to index on replay(5000)
# elasticsearch-bulk-replay =
# Number of bulk documents to index on a syncronied chain(10)
# elasticsearch-bulk-sync =
# Log bulk events to database
# elasticsearch-logs =
# Use visitor to index additional data(slows down the replay)
# elasticsearch-visitor =
# Track market history by grouping orders into buckets of equal size measured in seconds specified as a JSON array of numbers
bucket-size = [60,300,900,1800,3600,14400,86400]
# How far back in time to track history for each bucket size, measured in the number of buckets (default: 1000)
history-per-size = 1000
# Will only store this amount of matched orders for each market in order history for querying, or those meet the other option, which has more data (default: 1000)
max-order-his-records-per-market = 1000
# Will only store matched orders in last X seconds for each market in order history for querying, or those meet the other option, which has more data (default: 259200 (3 days))
max-order-his-seconds-per-market = 259200
# RPC endpoint of a trusted validating node (required)
# trusted-node =
# Block number after which to do a snapshot
# snapshot-at-block =
# Block time (ISO format) after which to do a snapshot
# snapshot-at-time =
# Pathname of JSON file where to store the snapshot
# snapshot-to =
# declare an appender named "stderr" that writes messages to the console
[log.console_appender.stderr]
stream=std_error
# declare an appender named "p2p" that writes messages to p2p.log
[log.file_appender.p2p]
filename=logs/p2p/p2p.log
# filename can be absolute or relative to this config file
# route any messages logged to the default logger to the "stderr" logger we
# declared above, if they are info level are higher
[logger.default]
level=info
appenders=stderr
# route messages sent to the "p2p" logger to the p2p appender declared above
[logger.p2p]
level=info
appenders=p2p
一般如果更改创世文件中的见证人的见证公钥时，肯定是有对应的一个公私钥对的，所以我们需要把见证人的公私钥写入这个文件中，同时把见证人的id填入（见证人id，如果没有在区块链中后续添加，则为创世文件中对应顺序依次递增，前缀都是"1.6."）
这里我们只是需要对应的这个config.ini文件，所以当前目录下的其他文件夹可以全部删除了
- 启动程序
准备工作都已经做完，我们可以继续重新启动程序了
./witness-node
如果上一步的config没有问题的话，到这里我们已经能看到链全部信息了
cli_wallet
cli 的意思是 command-line interface,也就是命令行界面,这个文件也就是命令行钱包,它是和bitshares web版钱包具有相同功能(甚至更高一级功能)的客户端。
与其他币种客户端不一样的是,cli不需要获取全部区块即可进行交易,它需要连接一个指定的witness_node才能成为一个可以正常工作的钱包
钱包有几个比较重要的参数,这里我会介绍一下
# 所有参数前面一定都要是用两个'-'
# --server-rpc-endpoint 为cli钱包连接的节点所在地址
# (如果是有ssl证书的就用wss,标准节点用ws) 中间可以用'=‘ 或者' ' 分割
--server-rpc-endpoint=ws://127.0.0.1:8090 #连接本地8090端口的节点
#连接的链的id,一般如果是同一个创世文件编译出来的witness_node和cli_wallet的话，他们的链id是一样的，如果不一样的话我们也可以指定专门的链id，使cli_wallet不用重新被编译就可以直接运行，如果链id不对，cli_wallet会将远端服务的链id提示出来，下一次直接复制过来就可以了
--chain-id=11111111 #链id是很长的一串编码在这里只是一个演示
全命令
# 首先先进入cli_wallet 所在文件夹
./cli_wallet --server-rpc-endpoint=ws://127.0.0.1:8090 --chain-id=11111111
首先先给出一个chain-id错误时候的提示
如果刚才参照着教程启动的见证人节点,现在启动钱包应该就会变成如下图所示了
小记
这篇文章就写这么多了，接下来我将会分几篇文章介绍一下cli_wallet的具体使用(毕竟它才是bitshares区块链的具体操作载体)，与如何增加新的自定义方法(如转账自定义手续费支出)
最后,我还是希望能推广一波自己的github上的代码仓库:
https://github.com/chouheiwa/bitshares_wallet
这个仓库是用java实现的cli_wallet,采用的是同步机制,非常适合服务器端的bitshares自动操作程序架设，目前因为时间不是很富裕，上面的readMe写的不是很多，后续会将详细补齐。
如果你觉得这篇文章还算的上不错，给作者一个赞或者给仓库一个star，万分感激
