AlexiaChen
commented
4 years ago 高级模板实现机制调研报告
前言
主要调研BTC的脚本机制实现，ETH的solidity智能合约方案，以及substrate的基于WebAssembly的合约方案，以这三个开源社区的资料调研。暂时不对具体实现代码做分析，也暂时不对编译器，解释器的相关工具技术进行调研，还不到代码实现的阶段。因为这个调研报告与检查点(Check Points)的调研报告不一样，检查点方案很成熟，复杂度不高，目的需求也很明确，直接参考BTC的检查点源码就行了。
BTC的脚本机制
这里的脚本是基于栈的计算语言（也就是stack-based virtual machine/language），语言并不图灵完备(没有循环语句)，脚本从左到右解析并计算，BTC把一些基础行为抽象成了几百个脚本指令操作原语(OP CODE)，这样是为了安全，设计上也简约，可控性更强。可编程的入口不能提供太多接口功能给用户。这样的方式思想很像大学的时候实现的基于栈的支持四则运算的计算器，但又比这个复杂得多。
下面通过一个例子来学习BTC的脚本，主要是为了直观感受下脚本机制，首先下载编译一个BTC脚本调试器来运行并调试BTC脚本语言，这样可以更好的熟悉BTC的脚本机制，然后我们本地实验下。
- 加载一个自定义的脚本， 脚本实现一个加法运算：
btcdeb ['OP_2 OP_1 OP_ADD']运行后是以下显示:
btcdeb 0.2.19 -- type `btcdeb -h` for start up options
miniscript failed to parse script; miniscript support disabled
valid script
3 op script loaded. type `help` for usage information
script | stack
--------+--------
2 |
1 |
OP_ADD |
#0000 2看到以上结果，很显然，调试器加载了3个OP CODE，从左往右加载，分别是2，1，OP_ADD。第三个显然是加法指令了，第一，二个显然是数值常数指令。此时类似于x86汇编指令的eip指令寄存器指向2，说明一旦运行，第一次就是执行2这个OP CODE。
这些都是BTC预先定义好的指令，不能乱写，比如你写个OP_20, 这个指令就不存在，最后会执行错误。也就是，BTC的OP CODE根本没有定义20这个数值指令，限制很严格。
好的，接下来再用调试器的step命令来单步跟踪下这三个OP CODE的执行过程和栈上的数据变化。
- 第一次step
btcdeb> step
<> PUSH stack 02
script | stack
--------+--------
1 | 02
OP_ADD |
#0001 1好了，这次单步运行，执行了OP_2，把2这个数值，压入栈中，然后指令指针指向OP_1，说明下一步就执行OP_1了。
- 第二次step
btcdeb> step
<> PUSH stack 01
script | stack
--------+--------
OP_ADD | 01
| 02
#0002 OP_ADD执行了OP_1，把1这个数值又压入栈中，然后指令指针指向OP_ADD，说明下一步该执行加法运算了。
- 第三次step
btcdeb> step
<> POP stack
<> POP stack
<> PUSH stack 03
script | stack
--------+--------
| 03OP_ADD做了三件事，首先把栈中的1， 2依次弹出来，做加法运算，结果为3，最后把数值3又压入栈中存储。
记住OP_ADD是个二元运算指令，不支持 btcdeb ['OP_3 OP_2 OP_1 OP_ADD'] 这样的脚本，但是这个脚本是正常的，只是结果不符合直觉，实际上最终的结果是:
btcdeb 0.2.19 -- type `btcdeb -h` for start up options
miniscript failed to parse script; miniscript support disabled
valid script
4 op script loaded. type `help` for usage information
script | stack
--------+--------
3 |
2 |
1 |
OP_ADD |
#0000 3
btcdeb> step
<> PUSH stack 03
script | stack
--------+--------
2 | 03
1 |
OP_ADD |
#0001 2
btcdeb> step
<> PUSH stack 02
script | stack
--------+--------
1 | 02
OP_ADD | 03
#0002 1
btcdeb> step
<> PUSH stack 01
script | stack
--------+--------
OP_ADD | 01
| 02
| 03
#0003 OP_ADD
btcdeb> step
<> POP stack
<> POP stack
<> PUSH stack 03
script | stack
--------+--------
| 03
| 03根据上面的单步运行，其实OP_ADD只支持离栈顶最近的两个数值做运算。多余的数值它不管。所以结果是栈中最后有两个数值3。
BTC还有很多OP CODE，每个OP CODE都对应有自己的二进制编码，需要可以查阅: https://en.bitcoin.it/wiki/Script
最后提一下，这个btcdeb工具还附带了一个btcc的命令行工具，可以把可读的BTC脚本代码翻译成对应的二进制编码（十六进制字符串表示），这些二进制才是可执行的指令编码:
$ btcc OP_DUP OP_HASH160 897c81ac37ae36f7bc5b91356cfb0138bfacb3c1 OP_EQUALVERIFY OP_CHECKSIG
76a914897c81ac37ae36f7bc5b91356cfb0138bfacb3c188ac以上的脚本逻辑就是一段锁定脚本(scriptPubkey)，要与解锁脚本(scriptSig)结合起来才能运行成功。下面我们来结合这个脚本来简单复述下BTC transaction的转账过程。
以Alice给Bob转账为例:
比如Alice的地址上有一个UTXO，如果转账给Bob就需要引用这个UTXO，作为新创建交易的input，这个新交易只有验证了才有可能在BTC的P2P网络中被广播，验证的时候就需要解锁脚本(scriptSig)，也就是解锁脚本和交易的input关联，锁定脚本和这个UTXO关联。只有提供正确的解锁脚本，才能正常花费这个UTXO，当然，解锁脚本肯定包含Alice的私钥的签名。换句话说，这个UTXO的钥匙就是解锁脚本。下面开始具体化分析这次正常转账场景的脚本机制：
锁定脚本(scriptPubKey): OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
解锁脚本(scriptSig): <signature> <pubkey>注意，上面解释了，锁定脚本与UTXO关联，解锁脚本与新交易的input关联，所以没有相应的解锁脚本的辅助，光运行锁定脚本就是错误的。好了，解锁脚本到手了，可以组合成一个完整的验证Tx是否合法脚本程序了，最终脚本是这样:
<signature> <pubkey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG- 首先，指令指针从左往右运行，先后把\<signature> \<pubkey> 压入栈中:
stack:
<pubkey> <- stack top pointer
<signature>- 执行OP_DUP，由于该指令的语义是复制一份栈顶元素到栈顶上，所以栈变成了这样:
stack:
<pubkey> <- stack top pointer
<pubkey>
<signature>- 执行OP_HASH160，该指令的语义是两个Hash的复合: ripemd160(sha256(
)),把栈顶元素pop出来，作为该指令的输入，该指令的运算后的输出结果又压入栈中:
stack:
<pubKeyHashA> <- stack top pointer
<pubkey>
<signature>从上面的ripemd160(sha256(\<pubkey>))来看，其实结果就是pubkey所对应的公钥地址，也就是BTC的地址了。
- 执行\<pubKeyHash>:
stack:
<pubKeyHash> <- stack top pointer
<pubKeyHashA>
<pubkey>
<signature>- 执行OP_EQUALVERIFY,语义是，判断栈顶两个元素是否相等，相等就弹出堆栈，继续执行，不相等就停止运行，报错。也就是判断 pubKeyHash == pubKeyHashA 是否成立。如果成立，把比较的两个元素pop出栈，继续运行。
stack:
<pubkey> <- stack top pointer
<signature>- 执行OP_CHECKSIG， 语义就是通过pubkey来验证签名是否合法，返回true或false，最终脚本执行完成，停机。正常结束还是报错结束，得看签名校验是否合法。把true或false最终结果压入栈中：
stack:
true or false <- stack top pointer
把上面得脚本逻辑代入Alice转账Bob的过程，Alice转账给Bob，那么Bob地址上的UTXO关联的锁定脚本是这样的:
OP_DUP OP_HASH160 <Bob's pubkey Address> OP_EQUALVERIFY OP_CHECKSIG如果Bob要花费自己地址上的UTXO，也就是给别人转账，那么它必须提供一个解锁脚本，用自己的私钥签名，并提供自己的公钥(pubkey),所以，解锁脚本是Bob提供的，长这样:
<Bob's signatre> <Bob's pubkey>最终，组合成一个合法的脚本:
<Bob's signature> <Bob's pubkey> OP_DUP OP_HASH160 <Bob's pubkey Address> OP_EQUALVERIFY OP_CHECKSIG最终查看UTXO是否是转到Bob自己的地址上，并通过这个Bob这个地址所对应的公钥来验证Bob的签名。看Bob是否有花费该地址上的UTXO的权限。这个脚本例子的官方叫法是：pay-to-pubkey-hash。
当然BTC还有很多脚本例子，可以实现一些高级功能。不一一讲解。
总结：对应到我们bigbang中，这段脚本就是实现了VerifyTransaction中destIn.VerifyTxSignature的功能。只是BTC是脚本化了，当然，可以看到，脚本机制与BTC的代码还是有一定耦合的，也不是一整套的隔离沙箱解释器的运行机制，是bigbang模板硬编码的可编程化的自然延申。bigbang要支持高级模板，又要提供一定的解耦的沙箱运行机制有一定挑战，不然UTXO和CTxIn等数据结构就会改变，这个想法还很初步的估计，最终细化可能还是得深入研究下BTC脚本的源码，并且小组讨论以后，才能下结论。不过了解过BTC脚本以后，我发现脚本是最贴合我们的bigbang的，因为bigbang的整体架构就是模仿的BTC的架构，从类，函数的命名都遵循一致的标准，既简单，又可控，防止用户随意编程。
以太坊的合约机制
用solidity语言编写合约，合约最终在ETH上的EVM虚拟机环境执行，猜测应该解耦的比较充分，但是编程自由度太高，为此ETH的智能合约在历史上发生过不少安全事件，可控性比较差，但是灵活很多。而且solidity语言是图灵完备的，也就是支持循环语句（BTC脚本不支持循环语句），常见的控制流语句都支持，也就是理论上它什么都可以写。因为太自由了，为了防止一些无限循环，一些故意耗费EVM计算资源的现象，ETH又在智能合约上加了gas燃油这样的概念，每运行一个solidity语句就会消耗燃油，消耗完毕就停机。让作恶者的作恶成本升高，入不敷出。
也许是因为智能合约太自由，可编程性太高，所以又催生出一个审核（审计）合约代码的一个行业来让专业团队评估一份合约的安全性或正确性, 或者让第三方的合约代码静态分析软件（比如，slither）来自动化分析合约代码的安全。
围绕着solidity语言这套体系生态过于复杂，入门也没BTC的脚本简单，实现上已经实现了一个完整的虚拟机，一套完整的编译，审核流程。
所以，如果要建立完备，开放最大限度的自由的智能合约机制，就需要周边建立完善的生态，不然实际意义不大，用户门槛过高。连BTC那么简单的脚本，都需要有类似第三方btcdeb这样的脚本调试器。
下面来大致看下ETH的合约工作原理，以及部署，调用机制。
-
首先，写一份solidity合约源码。
-
编译源码 solc
--abi --bin -o ./
编译后，生成了两个文件，bin文件二进制文件，包含EVM虚拟机指令，abi文件，一个描述合约接口的文件，用json描述，调用合约接口会用到abi文件, 这个abi文件就像C++的头文件一样。
- 部署合约
合约的部署跟发送一笔交易是一样的操作，调用transaction函数，from为发布者的地址，to为0，data为合约的evm操作码。在矿工打包的时候会生成智能合约地址。智能合约地址的生成是由创建者的账号和发送的交易数作为随机数输入，通过Kecca-256加密算法重新创建一个地址作为账号。也就是说最后合约地址对应合约的代码会保存在区块链数据库。调用者只需要有合约地址和abi文件就可以调用合约的代码。
- 合约调用
要调用合约需要合约的地址和合约的方法，智能合约是部署在区块链的代码，区块链本身不能执行代码，代码的执行是在本地的EVM中，实际上，部署在区块链上代码是能够在本地产生原智能合约代码的代码，可以理解区块链为一个数据库，而客户端从数据库中读取了存储的运行代码，并在本地运行后，将结果写入到了区块链这个数据库中,写回到区块链了，所以P2P网络只要同步到保存该结果的块，那么就可以看见，智能合约的最新结果状态了。
> abi=[{"constant":false,"inputs":[],"name":"kill","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"internalType":"string","name":"_newgreeting","type":"string"}],"name":"setGreeting","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"greet","outputs":[{"internalType":"string","name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"inputs":[],"payable":false,"stateMutability":"nonpayable","type":"constructor"}]
> MyContract = eth.contract(abi) #这时候就体现了abi的重要性，相当于接口的描述文档
> contractAddress = "0xbc7384998a5453a41bc51c1aa0f252034b57b986" #这个地址就是合约地址
> myContract = MyContract.at(contractAddress)
> myContract.greet.call()
"hello world"总结: 从用户角度看，ETH的智能合约使用就复杂，更别说链上核心实现，以及周边生态工具。个人调研结果，几乎彻底放弃对ETH智能合约的参考。
EOS，Substrate等基于WebAssembly的合约机制
现在主流的合约实现已经开始与以太坊不一样了，以太坊EVM有自己的虚拟机字节码指令，都是自己设计。现在主流智能合约编译出来的中间指令字节码都是WebAssembly这样的标准化字节码了，浏览器可直接运行，复用标准，比如知名的EOS也是基于WASM，以太坊一位核心灵魂开发者Gavin Wood（波卡创始人）自己开创了一个Rust语言写的区块链框架Substrate的合约机制都基于WebAssembly来做了。包括一些区块链创业小公司的合约机制也是基于WASM，甚至直接用Substrate框架来开发自己的公链, 据说该框架是模块化的，很多模块替换很方便，十分钟定制一个自己的极简公链不是问题，开箱即用。
想了解Substrate请看这里 https://zhuanlan.zhihu.com/p/47805322
EOS合约
下面开始讲解下EOS的合约，EOS的合约代码是C++写的，其项目本身也是C++，作为合约开发者来说，C++的门槛还是比ETH的solidity高一些，把C++的合约代码编译成WASM，通过EOS-VM这个专为EOS定制化的WASM解释器来运行合约代码，EOS-VM还附带单步调试C++合约代码的功能。
解释合约WASM的说了，那么开发合约的工具呢？EOS提供了一个EOSIO.CDT的工具包和环境来开发GNU & C++11风格的合约代码。下面说下教程步骤。
- 安装EOS
wget https://github.com/EOSIO/eos/releases/download/v2.0.0/eosio_2.0.0-1-ubuntu-18.04_amd64.deb
sudo apt install ./eosio_2.0.0-1-ubuntu-18.04_amd64.deb- 自己创建一个合约开发的目录
mkdir contracts && cd contracts && pwd- 安装合约开发工具包
wget https://github.com/EOSIO/eosio.cdt/releases/download/v1.6.3/eosio.cdt_1.6.3-1-ubuntu-18.04_amd64.deb
sudo apt install ./eosio.cdt_1.6.3-1-ubuntu-18.04_amd64.deb- 创建开发钱包
与BigBang类似，EOS也提供类似cli的命令工具去创建钱包，导入密钥对等功能。
# 会返回钱包密码，要记住
cleos wallet create --to-console- 有关于钱包的操作
cleos wallet open # 打开钱包
cleos wallet list # 列出钱包
cleos wallet unlock # 解锁钱包- 创建密钥对并导入钱包
cleos wallet create_key # 类似于bigbang的getnewkey- 导入开发密钥
每个新的EOS链都有一个默认的系统账户叫"eosio", 这个账户是通过加载链上治理以及共识的系统内建的合约用来初始化设置这条链，每个新的EOS链都有一个开发密钥，这个密钥大家都是相同的，加载此密钥就是为了代表eosio这个系统账户来签名交易。（千万不要用这个开发密钥来对生产环境上的账户做任何事，因为这个开发密钥是众所周知的，这样就等于生产账户大家都可以访问了。）
- 启动节点和钱包
后台启动keosd，相当于我们的bigbang -wallet这个钱包，单独的钱包管理程序
keosd &然后启动节点:
nodeos -e -p eosio \
--plugin eosio::producer_plugin \
--plugin eosio::producer_api_plugin \
--plugin eosio::chain_api_plugin \
--plugin eosio::http_plugin \
--plugin eosio::history_plugin \
--plugin eosio::history_api_plugin \
--filter-on="*" \
--access-control-allow-origin='*' \
--contracts-console \
--http-validate-host=false \
--verbose-http-errors >> nodeos.log 2>&1 &以上的命令就是加载各个基本插件，打开CORS跨域功能，智能合约调试和输出日志。这样就启动起来了，可以查看日志 nodeos.log看启动状况
查看钱包，可以查看多个钱包:
cleos wallet list通过http RESTful API查看节点状况,这个功能是chain_api_plugin 这个插件提供的。
curl http://localhost:8888/v1/chain/get_info- 创建测试账号
一个账号有属于自己的一堆权限。用来识别标记发送者和接收者。账号有灵活的权限系统，可以通过配置相关的授权被个人或组织拥有。账号就是发送和接受交易的地址了。
这里会用到两个用户账号alice和bob，还有个默认的eosio账号作为配置。这几个账号到后面的智能合约会用到。
之前创建过一个public key，在创建开发钱包那一节，把那个public key拿过来通过eosio账号创建两个账号:
cleos create account eosio bob YOUR_PUBLIC_KEY
cleos create account eosio alice YOUR_PUBLIC_KEY创建的账号会形成两个交易，以交易的形式被广播，最终被P2P网络确认。
executed transaction: 40c605006de... 200 bytes 153 us
# eosio <= eosio::newaccount {"creator":"eosio","name":"alice","owner":{"threshold":1,"keys":[{"key":"EOS5rti4LTL53xptjgQBXv9HxyU...
warning: transaction executed locally, but may not be confirmed by the network yet ]公钥和账号的关系是什么，公钥和账号都是独立的，公钥只是一组权限的ID，把权限ID与公钥关联上，即使把公钥换了，也不会改变账号的权限。
alice账号的公钥获取：
cleos get account alice会输出该账号的相关信息,可以看到，会以网络带宽，CPU带宽来限制某个账号
permissions:
owner 1: 1 EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
active 1: 1 EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
memory:
quota: unlimited used: 3.758 KiB
net bandwidth:
used: unlimited
available: unlimited
limit: unlimited
cpu bandwidth:
used: unlimited
available: unlimited
limit: unlimited从以上信息看，alice其实同时拥有owner和active公钥，EOS有一个独特的授权结构来保证你账号的安全性，在使用active相关联的密钥时，可以将owner密钥保持为冷状态，从而最大限度地减少帐户的曝光。这样，如果您的active密钥被泄露，您就可以用您的owner密钥重新控制您的帐户。
在授权方面，如果您拥有owner权限，则可以更改active私钥的权限，反之不行。
- Hello World的合约实例
在之前的CONTRACTS_DIR中新建一个hello的目录, 里面新建一个hello.cpp:
cd CONTRACTS_DIR
mkdir hello
cd hello
touch hello.cpp在hello.cpp里面写下:
#include <eosio/eosio.hpp>
using namespace eosio;
class [[eosio::contract]] hello : public contract {
public:
using contract::contract;
[[eosio::action]]
void hi( name user ) {
print( "Hello, ", user);
}
};hi函数就是该合约的一个Action，Action的意思就是，通过交易传递一个参数给EOS网络来执行一个智能合约所暴露的功能接口。
然后把合约C++代码编译成WebAssembly,准备部署合约:
eosio-cpp hello.cpp -o hello.wasm当一个合约部署后，也就相当于它部署到一个账号上了，账号变成了该合约的接口，为合约创建一个账户hello_account，然后把它部署到链上
cleos create account eosio hello_account YOUR_PUBLIC_KEY -p eosio@active
cleos set contract hello_account CONTRACTS_DIR/hello -p hello@active通过账户来调用合约action:
cleos push action hello hi '["bob"]' -p bob@activeexecuted transaction: 4c10c1426c16b1656e802f3302677594731b380b18a44851d38e8b5275072857 244 bytes 1000 cycles
# hello.code <= hello.code::hi {"user":"bob"}
>> Hello, bob- 合约，发行以及转账
官方维护了一些合约代码，可以clone下来
git clone https://github.com/EOSIO/eosio.contracts --branch v1.7.0 --single-branch下面我们围绕着一个非常重要的合约来分析理解
cd eosio.contracts/contracts/eosio.token接下来就是创建账号，部署合约了
cleos create account eosio eosio.token EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
eosio-cpp -I include -o eosio.token.wasm src/eosio.token.cpp --abigen
cleos set contract eosio.token CONTRACTS_DIR/eosio.contracts/contracts/eosio.token --abi eosio.token.abi -p eosio.token@active完成后，控制台会看到类似的消息
Reading WASM from ...eosio.contracts/contracts/eosio.token/eosio.token.wasm...
Publishing contract...
executed transaction: a68299112725b9f2233d56e58b5392f3b37d2a4564bdf99172152c21c7dc323f 6984 bytes 6978 us
# eosio <= eosio::setcode {"account":"eosio.token","vmtype":0,"vmversion":0,"code":"0061736d0100000001a0011b60000060017e006002...
# eosio <= eosio::setabi {"account":"eosio.token","abi":"0e656f73696f3a3a6162692f312e310008076163636f756e7400010762616c616e63...
warning: transaction executed locally, but may not be confirmed by the network yet ]再接下来是创建token:
cleos push action eosio.token create '[ "alice", "1000000000.0000 SYS"]' -p eosio.token@active用了eosio.token账号的create接口创建的token。该接口接收一个参数，该参数由两部分构成，一个是发行人（EOS的一个账号），该发起人将有权调用发行或执行其他操作，如关闭帐户或注销token。一个是一种资产类型，由两个数据组成，一个浮点数设置最大供应量，一个符号用大写字母来表示资产。例如，“1.0000 SYS”。
运行完成后控制台会看到类似消息:
executed transaction: 10cfe1f7e522ed743dec39d83285963333f19d15c5d7f0c120b7db652689a997 120 bytes 1864 us
# eosio.token <= eosio.token::create {"issuer":"alice","maximum_supply":"1000000000.0000 SYS"}
warning: transaction executed locally, but may not be confirmed by the network yet ]创建完Token后就是发行token了，也就是发币。
cleos push action eosio.token issue '[ "alice", "100.0000 SYS", "memo" ]' -p alice@activeexecuted transaction: d1466bb28eb63a9328d92ddddc660461a16c405dffc500ce4a75a10aa173347a 128 bytes 205 us
# eosio.token <= eosio.token::issue {"to":"alice","quantity":"100.0000 SYS","memo":"memo"}
warning: transaction executed locally, but may not be confirmed by the network yet ]这次输出包含几个操作：一个发行操作和三个转账操作。虽然签名的唯一操作是发行，但是发行操作执行了内部的转账，并且内联转账通知了发送方和接收方帐户。输出指示调用的所有操作处理程序、调用它们的顺序以及是否由该操作生成任何输出。
从技术上讲EOS代币合约本可以跳过内部转账，直接选择修改余额。然而，在这种情况下EOS代币合约遵循一种象征性的约定，即要求所有账户余额都可以通过引用它们的转账操作的总和来派生。它还要求通知资金的发送者和接收者，以便他们能够自动处理存款和取款。
转账Token，这个是最后一步了
cleos push action eosio.token transfer '[ "alice", "bob", "25.0000 SYS", "m" ]' -p alice@activeexecuted transaction: 800835f28659d405748f4ac0ec9e327335eae579a0d8e8ef6330e78c9ee1b67c 128 bytes 1073 us
# eosio.token <= eosio.token::transfer {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"m"}
# alice <= eosio.token::transfer {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"m"}
# bob <= eosio.token::transfer {"from":"alice","to":"bob","quantity":"25.0000 SYS","memo":"m"}
warning: transaction executed locally, but may not be confirmed by the network yet ]Alice转给了Bob 25 SYS。
Bob可以查到这笔收款:
cleos get currency balance eosio.token bob SYSAlice也可以查到自己的余额，总共发行了100，扣除25，还剩75：
cleos get currency balance eosio.token alice SYS总结： EOS的合约跟账户，授权各种权限系统关联耦合，合约系统并不独立，虽然是C++实现，但是实现也非常复杂，在实现上做减法也是件很困难的事情。
Substrate合约
Substrate是Rust语言编写的模块化区块链开发框架。很多模块是可以替换的，并且有内建的可选模块，比如共识有GrandPa和Aura，合约有 FRAME Contracts pallet 和 FRAME EVM pallet 模块，可以添加到Runtime里获得模块提供的功能支持，后者的EVM模块是为了兼容以太坊合约字节码，前者是Substrate自己的合约模块。FRAME Contracts pallet的合约语言是ink!, 基于Rust语言的合约代码，其实也就是写Rust语言了，开发区块链和开发合约都相当于写Rust代码了。
总结： Substrate现在发展不错，很多小微创业型的区块链企业是用这个框架快速开发定制自己的链，但是周边生态还不是很繁荣，Rust语言受众就比较小，更别说其中的一个区块链开发框架了，也就是遇到问题，也不好定位和解决。团队适合小而精的Rust团队。我们的高级模板也不好参考这个框架。门槛，社区，语言都完全不合适。
基于Lua语言从零开始实现合约系统
这个要说起段BigBang的发展历史，在BBC还在酝酿阶段，LomoCoin发展的早期，其主要架构师就开了一个分支想基于Lua实现一份LMC的智能合约系统，后来据说是写了一半，就没有后续消息了，BigBang的自主化设计的架构思想主要是类似BTC，LomoCoin改自的PPCoin也来自BTC。所以两个的架构一些原理非常相似，原架构师的对智能合约是有一定前瞻性的思考的，从这里出发来看，大体是基于BTC架构的前提下，又要提供比BTC脚本机制更加灵活完备的合约机制，可能基于Lua是不错的选择，开发上的减法不用做太多，比改以太坊，EOS的代码复杂度已经大量减少，很可能大部分是在Lua解释器上做修改，对接BBC链本身的API，然后再考虑与现有模板机制结合。
另外，调研中，也发现已经有一个叫Aergo的项目用Lua语言+SQL语言来写合约了，口号是：It's not a blockchain. It's the Blockchain for Business.
感觉是为了对接企业级业务而存在的合约平台,当然，它底层也是一个公链，只是是高TPS的企业级公链，采用BFT+DPoS混合共识，可以多查看下它们的应用场景以及客户类型。这里是它们的主网区块链浏览器，出块速度非常快。在韩国，其风头很大，跟三星等有战略合作，以下是Aergo的相关新闻:
- 商业白皮书：https://paper.aergo.io/AERGO_Whitepaper_v5.2.pdf
- 技术白皮书： https://www.aergo.io/downloads/AERGO_Chain_Technical_Whitepaper_V1.0.pdf
这些新闻标题，以及官网介绍，大体上是符合现阶段高级模板与企业对接落地的原始需求的。
下面来关注其技术部分，技术与业务是怎么结合的，以及一些场景
How does it work?
Aergo uses a hybrid architecture so you can balance the need to maximize performance and control of your most important data while leveraging a highly secure and trusted distributed public blockchain network.
It also offers an easy-to-deploy architecture that can run on a serverless cloud, so you can focus on building your business applications, services, and ecosystems. No need to build complex IT infrastructure any longer.
Easy-to-use development and deployment frameworks allow developers of all levels to program and build solutions with minimal effort and complexity.
Aergo的五大落地方案:
-
身份验证：韩国最大的信用卡公司之一在与可信的第三方安全公司合作时，使用了Aergo的核心技术来简化用户的支付流程并控制他们的数据。他们减少了90%的安全开支，支付速度加快了80%。https://www.taiwannews.com.tw/en/news/3073071
-
付款结算： 韩国的一家证券交易所利用Aergo背后的技术，将在其OTC创业市场上结算交易所需的时间从最多5天大幅缩短到仅1至3天。宋春阳大学权贤俊教授的数据分析显示，2017年，他们节省了7800万美元。https://www.coindesk.com/korea-exchange-launches-blockchain-powered-private-market-service
-
安全电子投票： 韩国人口最多的省份之一京畿道省通过一个基于Aergo核心技术的投票应用程序，完成了500多个社区项目的评选。 https://ca.sports.yahoo.com/news/south-korean-local-government-uses-184956923.html
-
文档管理： 韩国一家政府机构利用Aergo背后的技术，以自动化和可信的方式管理房地产文件，以透明的方式合作进行文件核查，防止欺诈者伪造文件，并每年获利超过数亿美元。https://m.news.naver.com/read.nhn?mode=LSD&mid=sec&sid1=105&oid=092&aid=0002149937
-
IoT物联网： 一家网络巨头利用Aergo的核心技术，让他们安全地将资源转向特定的物联网设备和物联芯片卡，这样加快了他们进入边缘计算领域的进程。https://bitcoinmagazine.com/articles/expect-a-surge-of-blockchain-adoption-across-south-korean-business-and-industry-sectors-1479400720/
Aergo技术概览：
- 混合区块链
结合了公链和私链的特点，企业业务服务可以托管在私有的链上，然后私链可以通过主网的主链来进行安全的结算。这样的机制与BBC的树状无限可分叉的链很像，子链一般对应一个企业的业务，跨链的交易结算需要通过安全主链来保证。虽然实现细节不一样，但是主要的思想趋同。
Aergo链也是高性能，高可扩展的，BBC的理念也是如此。Aergo的主网主链的共识是BFT+DPoS共识，23个DPoS节点，安全主链作为独立私链和应用程序开发的中心枢纽，它提供了在自己的侧链上集成不同应用程序和服务的功能，使开发人员能够利用现实世界中复杂的网络拓扑来实现复杂的业务模型。私链也可以有自己的共识机制。
无论从哪个角度看，Aergo的诞生设计之初与BBC的诞生设计理念都高度吻合，无非就是实现细节完全不同。
- 智能合约
Aergo Lua，基于Lua的合约开发环境，并支持SQL。可以编写业务逻辑，构建Dapp。当然Aergo一门ASCL的全新的合约语言，完全类似PLSQL的语法，从这里可以看出，Lua + SQL的模式只是发展初期的一种简化方案。BBC高级模板初期也应该这样，尽量基于Lua等简单的语言构建合约环境。
- 平台生态
主要就是Aergo核心技术与云计算，云存储相关结合的上层生态服务，类似于BaaS（Blockchain as a service）整个生态。其中用到了弹性伸缩，k8s，容器，负载均衡等等。从这里可以看出，BBC的上层产品的路线，也应该类似这样。
总结：从三大方向的技术概览来看，BBC是可以参考Aergo的，特别是合约相关，因为这里着重合约调研，但是合约又应该本身结合BBC的特性，来发展。也就是对比ETH，BTC，EOS，Substrate下来，从大方向上看，BBC与Aergo是非常契合的，但是Aergo主体是Go语言写的，可能各种细节的复杂度，要移植到C++开发的BBC上，工程量还是复杂的。
结论（这里待团队讨论分析）
所以合约系统经过个人分析，高级模板的实现优先偏好考虑如下顺序：
- 基于Lua从零自研 = 复用Aergo的一些合约设施（这个不清楚能不能，核心代码是Go语言，但貌似不是合约部分，代码细节没看，也没尝试使用，没法预估工作量）
- 修改EOS合约代码（工作量无法估计）
- BTC脚本机制（看当前的需求反馈，这样的脚本暂时不满足需求，可以不可以在其基础上完善，这又是另一个问题）
- 以太坊合约代码 或者Substrate合约机制（全是Go或Rust，与BBC完全不契合，几乎不考虑）
参考资料：
- https://en.bitcoin.it/wiki/Script
- https://bitcoindev.network/
- https://github.com/jxu86/technique-architect/tree/master/blockchain/ethereum
- https://learnblockchain.cn/2018/01/04/understanding-smart-contracts/
- https://github.com/EOSIO/eosio.contracts
- https://eosio/build-on-eosio/
- https://eos.readthedocs.io/zh_CN/latest/
- https://substrate.dev/docs/en/knowledgebase/smart-contracts/overview
- https://blog.csdn.net/shangsongwww/article/details/89784722
- https://www.parity.io/what-is-substrate/
- https://www.8btc.com/article/296948
- https://developers.eos.io/welcome/latest/tutorials/index
- https://www.aergo.io/
- https://github.com/aergoio
- https://github.com/aergoio/aergo-contract-ex
- https://blog.codingnow.com/eo/luaoeeeaeau/
- https://blog.csdn.net/u012278016/article/details/79471738
shangqd
需要一定的可编程化。先探探路。主要先查阅BTC，以太坊，substrate等智能合约或脚本机制的方案和资料，有一定理解以后再考虑与现有模板机制结合。