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