背景
之前在一家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動作）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/292553.html
標籤：區塊鏈