ITBear科技资讯

想开发区块链应用,你被solidity拖后腿了吗?

 

作为一个前端开发,我接触智能合约开发已经快一年了,期间也开发了几个智能合约应用,看过了一些以太坊合约代码。

在使用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++作为更成熟的语言,大部分的开发者会有一定的开发基础。

编写的便利性得到提升,安全性也有一定的保障。

还有一个比较好的地方体现在,随着越来越多的人加入,工具库和合约被开发和复用,合约的开发也将会更加便捷高效。

也欢迎使用迅雷链开发的人多跟我沟通和交流。

读者交流

扫二维码加ITBear科技数码群,大咖随时在线与你聊科技!
不方便扫码可加微信号:17091359999,也可以长按上图保存图片->微信扫一扫->点击右上角相册->选择刚保存的二维码。(如果在微信中打开此页面可以长按二维码识别)


本栏最新
全站最新