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

Posted 2021-09-02 郑泽洲

背景

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

典型交易分析（以投标交易为例）：

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

业务思考问题：

0. 用户的定义以及其在链上的数据结构是啥？

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

2. 一个标的在一个智能合约中，还是所有标的在一个智能合约中

技术思考问题

0. solc编译器版本选择问题

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

2. 删除合约有无gas奖励

---

设计#### 原则：

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

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

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

4. 也没有for循环

5. 编码规则按

1）类、事件、结构体命名首字母大写；

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

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

5. 数据分为加密区和hash区（关键数据用原文+交易hash再次hash得出，单向保密，可以用于数据验证）

6. 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动作）