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