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