背景
之前在一家FinTech的公司和银行合作，做基于区块链的资金存管系统，从头开始基于Solidity设计项目的智能合约架构。转眼几年时间过去了，2B的热潮退去，但是DeFi的热潮上来了。所以总结一下过去的方案，顺便思考下新形势下的问题。
典型交易分析（以投标交易为例）：
说明：这个交易阶段就是用户已经完成注册了，用户信息在链上了，也经过了验证了；而且账户里面有钱了
业务思考问题：
-
用户的定义以及其在链上的数据结构是啥？
-
标的数据结构如何解耦，比如开发人员A和B分别写了一个，如何用creator直接new 创建出来，做到代码层面的抽象
-
一个标的在一个智能合约中，还是所有标的在一个智能合约中
技术思考问题
- solc编译器版本选择问题
1.智能合约账户地址的生成算法
- 删除合约有无gas奖励
设计#### 原则：
-
数据存储尽量分散，不要几千万数据全在一个智能合约中，目前业界热门的ico是eos的，大约几十万个地址购买过，还没到这个量
-
链上只存核心数据，比如投标时，减少用户账户，增加标的账户，至于这个动作的utxo是在交易调用的区块中，作为event回复出来，由外部数据库记录，不必写入statedb
-
用户和合约都有余额概念，后续可以考虑抽取成一个简单的接口（相当于库函数）但是这个余额不同于ether或者token，只有记账功能，也不预设总量，只是在每次转账后有个校验，提现怎么办？提现是减去他的余额，链外给人民币，是有业务系统应用影子数据库内容进行校验的。不涉及transfer和send其msg.value
-
也没有for循环
-
编码规则按
1）类、事件、结构体命名首字母大写；
2）函数变量名、本地、函数修饰符、状态变量按驼峰式；
3）常量用下划线分割并全部大写。
-
数据分为加密区和hash区（关键数据用原文+交易hash再次hash得出，单向保密，可以用于数据验证）
-
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动作）