作为一个前端开发，我接触智能合约开发已经快一年了，期间也开发了几个智能合约应用，看过了一些以太坊合约代码。
在使用Solidity开发基于EVM的智能合约的过程中曾不可避免的踩过许多坑，因此当我得知迅雷链最近推出了支持C/C++开发基于WASM合约的时候，迫不及待的来上手尝试了一番，期望能够获的比使用Solidity开发合约时更好的体验。
以下是我基于Catalyst的TRC3模板合约体验及一些简单的合约移植后代码修改的流程，主要介绍一下曾经在使用Solidity时出现的问题，以及后来使用C/C++在WASM实现中的对比
Dapp合约开发经历
我曾经使用Solidity写过一个溯源存证类的合约，主要就是把用户通过表单提交的一些信息，存入到区块链上。最初按照传统的方案实现，直接将数据库表字段映射到合约里的结构体，然后调用合约方法存储到Map里。
如果大家有过相似的开发经历的话，大都会遇到一个很直接的问题：stack too deep, try using fewer variables。如下面这段代码：
pragma solidity ^0.4.20;
contract Test {
struct Tstr {
string a1;
string a2;
string a3;
string a4;
string a5;
string a6;
string a7;
string a8;
}
mapping(uint => Tstr) public tmap;
function test(string _a1, string _a2, string _a3, string _a4, string _a5, string _a6, string _a7, string _a8) public {
Tstr memory tstr = Tstr(_a1, _a2, _a3, _a4, _a5, _a6, _a7, _a8);
tmap[0] = tstr;
}
}
这个错误是由于EVM限制了栈最多能取到stack[15]就是从栈顶向下第16个栈元素的内容，这就导致了如果一个函数方法的入参、返回值、函数内参数的个数如果大于一定量的时候很可能会触发这个错误，实际情况要根据opcode来分析。
理论上来说如果合约业务逻辑复杂，总会有不可避免的情况会遇到上述问题。
比如，理论上我们可以通过拆分合约逻辑，优化代码结构来修复。但这就是一个典型的EVM限制开发的问题。 另外还有像EVM限制合约Bytecode大小不超过24K，Solidity无法在合约外返回变长数组、没有迭代器来遍历map，不支持原生string的操作等等这些问题。
抱着这些使用Solidity过程中产生的疑惑和对WASM的期待，我们来看一下使用C/C++开发合约的过程。
使用Catalyst
首先我从迅雷链的Catalyst工具开始，因为目前为止想通过迅雷链部署WASM类型的合约，还只能通过官方提供的Catalyst做编译测试。
对Catalyst的使用这里不做过多介绍，因为其实整体和remix的使用体验很贴近，只是编译、部署和执行都是通过迅雷链测试环境实现的。
而Catalyst里提供了一份WASM类型的模板合约，实现的是TRC3标准的token，也就是ERC20的token合约。接触过区块链的应该都知道这是以太坊的token通证发行标准，并且已经有很多基于Solidity的成熟的实现。
我们以这里的C++实现的token合约模板来解析。
结构
可以看到模板里TRC3 token合约分为三个文件来实现，其中ITRC3.hpp定义了TRC3的必须要实现的方法，以及两个事件;TRC3.hpp则继承自ITRC3，并定义了一般token所需要的私有属性，私有方法(transfer,approve)，并实现了接口类的方法; TRC3.cpp则是通过thunderchain_main初始化了TRC3的合约实例，定义了一系列ACTION提供对外调用的逻辑入口，并调用TRC3对应方法实现最终函数。
使用TC宏
每个文件里都引用了 tcapi.h 头文件，这应该是迅雷链为WASM合约开发提供的一个工具函数库，比如合约里使用到的address 类型定义、TCStorage的操作，TCnotify事件操作等，这些api都是可以通过迅雷链的文档查到的，链接https://open.onethingcloud.com/site/wasm.htm
这一段自定义了范型参数的类TCMap，实现私有属性 _balances 和 _allowed
// Mapping from address to balance
TCMap
// Mapping from spender to approvals
TCMap_allowed{"allowed_"};
另外合约事件的宏定义及参数的传递如下
#define EMIT(eventID, arg1, arg2, arg3) {
void *jsroot = TC_JsonNewObject();
TC_JsonPutString(jsroot, #arg1, arg1);
TC_JsonPutString(jsroot, #arg2, arg2);
TC_JsonPutString(jsroot, #arg3, arg3);
TC_Notify(_transferEventID, TC_JsonToString(jsroot));
}
使用TC_Json相关Api可以轻松实现json数据，然后通过事件将json string触发。
其他transfer的常规实现利用C++以及迅雷链提供的一些Api，可以说基本照搬Solidity中对ERC20合约的实现即可。
ACTION
从TRC3.cpp合约的实现来看，所有的合约需要有一个名为thunderchainmain的主函数入口，并且通过ACTION case来路由对应的方法调用。thunderchainmain的参数只有两个，就是要执行的方法action名称，以及执行方法的参数json。 因为这里将所有的参数都转为json形式传入，并且WASM对栈的使用无限制，所以不会出现像EVM一样的stack too deep的问题。
但是这种方法路由的实现方式也是有一些弊端：比如合约调用方必须准确匹配要调用的合约名称，以及参数的名称(json参数取值根据参数名获取)，否则就会执行到默认action。
基于上述方式的合约方法调用以及查询，是将交易data按照|的形式，action与args以"|"分割，这种实现相比于Solidity基于ABI编码参数和解码返回值，更加直接。
对比
通过对比使用C/C++开发合约的过程，现在对这种实现有了一些简单的认识。
从开发的角度来看，WASM虚拟机更多的意义在于带来了一种常见语言(以后也许能支持更多语言)支持合约的开发，使开发者有了一定的可选择性。
而C/C++作为更成熟的语言，大部分的开发者会有一定的开发基础。
编写的便利性得到提升，安全性也有一定的保障。
还有一个比较好的地方体现在，随着越来越多的人加入，工具库和合约被开发和复用，合约的开发也将会更加便捷高效。
也欢迎使用迅雷链开发的人多跟我沟通和交流。
