基于Solidity的XX项目智能合约架构设计

Posted 郑泽洲

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于Solidity的XX项目智能合约架构设计相关的知识,希望对你有一定的参考价值。

背景

之前在一家FinTech的公司和银行合作,做基于区块链的资金存管系统,从头开始基于Solidity设计项目的智能合约架构。转眼几年时间过去了,2B的热潮退去,但是DeFi的热潮上来了。所以总结一下过去的方案,顺便思考下新形势下的问题。

典型交易分析(以投标交易为例):

说明:这个交易阶段就是用户已经完成注册了,用户信息在链上了,也经过了验证了;而且账户里面有钱了

业务思考问题:
  1. 用户的定义以及其在链上的数据结构是啥?

  2. 标的数据结构如何解耦,比如开发人员A和B分别写了一个,如何用creator直接new 创建出来,做到代码层面的抽象

  3. 一个标的在一个智能合约中,还是所有标的在一个智能合约中

技术思考问题
  1. solc编译器版本选择问题

1.智能合约账户地址的生成算法

  1. 删除合约有无gas奖励


设计#### 原则:

  1. 数据存储尽量分散,不要几千万数据全在一个智能合约中,目前业界热门的ico是eos的,大约几十万个地址购买过,还没到这个量

  2. 链上只存核心数据,比如投标时,减少用户账户,增加标的账户,至于这个动作的utxo是在交易调用的区块中,作为event回复出来,由外部数据库记录,不必写入statedb

  3. 用户和合约都有余额概念,后续可以考虑抽取成一个简单的接口(相当于库函数)但是这个余额不同于ether或者token,只有记账功能,也不预设总量,只是在每次转账后有个校验,提现怎么办?提现是减去他的余额,链外给人民币,是有业务系统应用影子数据库内容进行校验的。不涉及transfer和send其msg.value

  4. 也没有for循环

  5. 编码规则按

1)类、事件、结构体命名首字母大写;

2)函数变量名、本地、函数修饰符、状态变量按驼峰式;

3)常量用下划线分割并全部大写。

  1. 数据分为加密区和hash区(关键数据用原文+交易hash再次hash得出,单向保密,可以用于数据验证)

  2. pragma用ethereumj1.5.0发布(2017年6月7日)之前的版本,之后最新的编译器,怕有些指令有变化,跑有问题,而以太坊向后兼容的特性所以用0.4.11 (比1.5.0发布早了一个月)

最关键的分歧,用户信息和标的信息要不要一个合约一个数据,还是所有数据都在一个合约?无非就增加了代码的冗余量,减少了合约下的statedb。用户规模上,目前以太坊公链已有3000多万个账户,每天新增5万个账户。访问有skiplist技术,应该还是比较快的

单个用户(包含投资人、借款人)单独是个合约,还有个好处是为推广到C端做好充足的准备,可以由系统管理员账户set一个owner地址,于是我们可以灰度推广,就是大部分客户信息还是北京银行托管,但是有些资深用户具备了管理密钥能力的,可以进行C端自己开外部账户,绑卡,并直接setOwner后操作自己的合约账户

记录债权关系在链外,所有的动作依据都是链上交易(可以log传出,可以对账,但是不建议做到链内部去)


C端推广:

  • C端还是要认证过,我们的账户,所有刚开始都是没有gas的,要经过银行充值,也就是允许C端,这些客户熟悉区块链

  • Proxy,就不必限定onlySystem了,但是要传入msg.sender

  • Service(只能Proxy访问),取data的Owner,进行逻辑比较后才能访问data

  • data这层有个setOwner,也是银行System账户设置;data访问只能由Service访问

(所以这个Proxy可以分为用户发起和网贷公司发起两种,但是data层和Service不变,data增加的owner通用,如果托管就是网贷公司,否则自己;Service都有比较owner动作)

以上是关于基于Solidity的XX项目智能合约架构设计的主要内容,如果未能解决你的问题,请参考以下文章

基于以太坊的智能合约开发教程Solidity 合约的销毁

智能合约开发 基于Hardhat(实操)

基于以太坊的智能合约solidity学习日记

基于以太坊的智能合约开发教程 Solidity 全局变量

基于以太坊的智能合约开发教程Solidity 继承与权限

基于以太坊的智能合约开发教程Solidity mapping在结构体当中的使用