发起交易各种方法比较结论
在Fiscobcos链上发起交易有多种方法,看文档都看花了眼,晕头转向的,到底那一种是最好用的呢?今天我们做一个总结,给出推荐方案。
1 各种方法简单介绍
- 智能合约Java类调用: 智能合约solidity编译成java类文件,通过常见合约类对象直接调用函数就发起了交易。
- 节点RPC接口调用: 针对链节点的rpc监听端口 20200~20203发起调用,自己填写curl命令的数据内容。
- 节点管理服务接口调用: 针对节点管理服务接口5001发起调用,自己填写命令的参数内容和鉴权token。
- 前置节点管理服务调用:针对前置节点管理服务接口5002发起调用,填写的命令参数内容与节点管理服务接口命令相同,无需鉴权
- JavaSDK API调用: 主要是通过创建和使用AssembleTransactionProcessor对象来完成合约相关的部署、调用和查询等操作, 并获得TransactionResponse的结果
- 交易服务器调用: 针对交易服务接口5003发起调用,自己填写命令参数内容。 这种方法暂时没有研究。
2 对比表格
1智能合约Java类调用 | 2节点RPC接口调用 | 3节点管理服务接口调用 | 4前置节点管理服务调用 | 5JavaSDK API调用 | |
---|---|---|---|---|---|
连接对象 | 节点 | 节点 | node-manager服务 | front服务 | 节点 |
连接方式 | https | http | http | ||
身份证书 | Yes | No | No | No | Yes |
鉴权 | No | No | Yes | No | No |
合约部署交易查询 | Yes | 无部署 | Yes | Yes | Yes |
异步调用 | Yes | Yes | No | No | No |
本地签名 | Yes | 不支持签名,只能发送签名后的交易 | Yes | Yes | Yes |
私钥托管 | No | No | Yes | Yes | No |
需要合约java类 | Yes | No | No | No | No |
需要abi、bin文件 | No | No | Yes | Yes | No |
需要contractId | No | No | Yes | Yes | No |
易用性 | AAAAA | A | AAA | AA | AAA |
通用性 | AA | A | AAAAA | AAAAA | AA |
耦合性 | 极高 | 低 | 中 | 中 | 中 |
合约升级 | 必须重新编译应用项目 | 只更改abi、bin,不用重新编译项目 | 只更改abi、bin,不用重新编译项目 | 只更改abi、bin,不用重新编译项目 | 只更改abi、bin,不用重新编译项目 |
3 结论
第一种方法( 智能合约Java类调用)调用时参数填写、返回值解析清晰简单,调用代码最少,任意指定私钥账户进行签名。
代码调用最方便。
缺点是合约升级时需要更改java类文件,就需要更新应用程序。
第三种方法(节点管理服务接口调用)调用时要填写鉴权token,命令json格式数据参数组装繁琐,可以使用单独的签名服务进行签名,签名时简单。
优点是只需要合约地址、abi、bin文件就能发起调用。合约升级时只需要更改合约数据库记录,不用更新应用程序代码。
缺点是需要自己包装一套接口,能方便调用接口, 这个工作费时费力。
4 推荐方案
(1)简易方案
采用第一种方法( 智能合约Java类调用),
应用程序管理用户私钥文件,私钥文件内容存入用户私钥数据表。本地加载用户私钥文件进行签名。
适合合约变动次数少,升级不频繁的场景。
缺点是有泄漏用户私钥危险。
(2)标准方案
采用第三种方法(节点管理服务接口调用)
通过Webase-web管理用户私钥,指定用户signedId通过签名服务进行签名。
适合 大量交易、大量用户,不受合约升级影响。
(3)高性能方案
采用第6种方法(交易服务器调用)
交易发给交易服务器,适合巨量交易场景。