美日韩午夜精品,亚洲日韩美一区,91无码高清加勒比

寫在前面

轉載請注明出處，引用也請標注來源，謝謝

STO是一個新興的事物，研究此領域純屬機緣。

探究事物本源，并思考在現(xiàn)實世界的真實價值，是本人的樂趣所在。

市面上寫STO的文章、整合相關材料的剪貼報已經(jīng)非常多，在此向這些同學們致敬，因為，有了他們，才有了更多的人對STO的了解。

初始布道這些內容的，大都是準備從事這個行業(yè)的BD項目方的組織。因為只有讓項目方了解了，自己才能有生意做??！

所以也請大家擦亮眼睛，因為并不是所有作者的立場都客觀中立。

STO本質分為兩塊：金融+ 技術

金融部分需要非常深入研究，在全盤了解現(xiàn)實以及歷史金融世界規(guī)則變遷的基礎上。技術部分，感謝區(qū)塊鏈開源的精神，白皮書和github社區(qū)能讓大家公開的來分辨真?zhèn)巍?/p>

有一點點寫代碼的底子，研讀了各家主流STO發(fā)幣技術平臺的白皮書和協(xié)議。從初步技術實現(xiàn)、實現(xiàn)框架、推測的實現(xiàn)程度、愿景生態(tài)來分析一下各家的情況。

BTW：我不是翻譯白皮書的，所以只寫看完白皮書和代碼之后自己理解的重點。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

免責聲明：

對各類協(xié)議的解讀，還是需要懂區(qū)塊鏈開發(fā)的技術人員來參與，才能更為專業(yè)。作為業(yè)余人士，表示只看了各家github上接口定義，和contract的部分代碼，認識理解可能還存在不完整的地方。還請各位看官見諒。

背景常識

先來一點通用背景常識。主流協(xié)議大部分是基于ERC-20的，ERC-20的接口只有如下function和event。

contract ERC20 {

??function totalSupply() public view returns (uint256);

??function balanceOf(address who) public view returns (uint256);

??function transfer(address to, uint256 value) public returns (bool);

??function allowance(address owner, address spender) public view returns (uint256);

??function transferFrom(address from, address to, uint256 value) public returns (bool);

??function approve(address spender, uint256 value) public returns (bool);

??event Approval(address indexed owner, address indexed spender, uint256 value);

??event Transfer(address indexed from, address indexed to, uint256 value);

}

因為STO的業(yè)務都還在探索，僅僅只有投資人資格限制的規(guī)則在法律上比較明確（主流參考美國各類Reg，都是限制合格投資人和鎖倉一年），對于投后的權益和監(jiān)管規(guī)則設計涉及都很少。

因此tranfer（）和transferFrom（）就成了各家協(xié)議的改造重災區(qū)。

當然也有很多人在ERC 1404出來的時候說，僅僅增加了兩個function啊。是的，接口看就兩個function，但是里面的實現(xiàn)是要寫很多代碼的！

最怕老板說，不就是在交易的時候加一個check嗎？嗯，不知道該如何回答了。

協(xié)議分析?

Securitize

沒有找到他家Github的代碼，以下信息完全從白皮書中獲得。

Securitize的目標是打造一個生態(tài)環(huán)境，因此不僅僅提供了on-chain的DS協(xié)議系統(tǒng)，還提供了off-chain的RFE-API接口和外部交易所等合作機構對接。——這點是優(yōu)于其他平臺的，因為一級市場的鎖倉并不意味著在鎖倉期完全不能交易，在合格投資人之間，是可以的。鎖倉僅針對不能交易給非合格投資人。

DS Token是基于ERC-20的令牌。對ERC-20協(xié)議的變動如下：

重寫transfer（）和 transferFrom（）兩個接口，在Token轉移的過程中，提供符合監(jiān)管規(guī)則的校驗。（包括雙方身份的校驗、Token本身的可售屬性等）重寫這兩個接口也是大部分主流協(xié)議采用的方案。

增加block wallets和freeze token的功能（為了了符合監(jiān)管要求），具體如何實現(xiàn)未知

Iterate，返回所有Token持有人名單（為了進行分紅等功能）。不僅僅為了分紅，很多權益和監(jiān)管要求，也是需要隨時能夠知道所有Token的持有人。

DS生態(tài)系統(tǒng)中提供了內置的智能合約，進行一些基礎核心服務，比較重要的兩個Service是：

Registry Service——完成投資人的信息認證以及上鏈（每個白名單用戶的KYC狀態(tài)、合格投資人認證狀態(tài)都會上鏈保存），這個是其他家不具備或者在白皮書中沒有提到的，個人理解大部分都是脫鏈管理，對于白名單僅僅是地址信息的上鏈

Compliance Service——根據(jù)不同發(fā)行策略，內置的監(jiān)管合規(guī)的校驗規(guī)則（例如文書簽名、不同類型投資人人數(shù)、一段時間內的交易頻次、丟失代幣的找回等等）感覺這塊尚未很好的實現(xiàn)，還等著合作伙伴來開發(fā)

TrustService主要用來認證管理合作伙伴，個人理解類似傳統(tǒng)系統(tǒng)對接中的API密鑰分發(fā)。

CommsService是一個用來給Token持有人發(fā)通知的服務。

同時在整個生態(tài)圈中，平臺鼓勵開發(fā)者和平臺實現(xiàn)各類DS Apps來完善和豐富DS Token所能具備的功能，比如，回購、派息、投票、特別監(jiān)管規(guī)則，等等。在白皮書中，這些僅按照Case的方式做了講解，并未真實實現(xiàn)。反正架構設計上，分分鐘可以加上去?！幸粋€好的架構設計是多么重要！

為了完成這個Token的生命周期管理（一級分發(fā)，到二級流通），DS生態(tài)提供了對接交易所的RFE-API，交易所通過該接口完成投資人白名單加入，在Token交易的時候調用DS的校驗規(guī)則。

Securitize對于交易所分類四類，相當詳細的講解了不同類型的交易所，和DS Token對接的難度。和交易所對接的本質是如何增加白名單用戶，因為在區(qū)塊鏈世界，地址代表身份。所以對于類似中心化錢包交易所（用戶的錢包地址并不是用戶自己的），支持上會比較困難。

小結：

推測，Securitize僅實現(xiàn)了DS Token的定義，以及Registry Service的合約開發(fā)。其他規(guī)則依賴于更多的DS Apps的開發(fā)者。

已經(jīng)對接了Openfinance、AirSwap、BnkToTheFuture、Blocktrade.com、SharePost、HYPERION、ERCdex這些交易所。布局還是比較完善的，新興ST交易所，傳統(tǒng)股權交易所都有涉及。

所有白皮書里面，Securitize是寫的相對完整的，并且從生態(tài)的角度來考慮問題。Securitize本身是從金融基金下分離出來的，金融背景比較強，對STO來說，設計協(xié)議架構和系統(tǒng)架構不能僅僅停留在技術層面，而是要從金融產(chǎn)品業(yè)務的角度出發(fā)。

脫離了業(yè)務單純玩技術，類似閉門造車，是行不通的。

Securitize的商業(yè)模式類似做Saas服務，toB端收費，鑒于一年能發(fā)行的STO數(shù)量有限，這筆生意是不是做的下去，拭目以待。

Harbor

以下基于Github代碼和白皮書。

R-token是基于ERC-20協(xié)議的，對ERC-20協(xié)議的變動如下：

重寫transfer（）和 transferFrom（）兩個接口，在Token轉移的過程中，進行check（）。

增加check（）方法，在Token轉移的過程中驗證交易規(guī)則，該方法的實際邏輯寫在Regulator Service中，方便不斷升級規(guī)則。

兩個Service：

RegulatorService——通過和off-chain的TraderController交互，來決定一筆交易是否可以被允許，里面只有一個接口check（）

ServiceRegistry——主要用來綁定R-Token使用的RegulatorService版本關系。這個注冊器基本主流協(xié)議都有，原因是，方便升級各類目前尚未厘清的規(guī)則。

R-Token提供兩類校驗：

參與者

????send的權限

????receive的權限

Token

????鎖定/非鎖定（用來控制交易鎖倉時間）

????允許拆分售賣/不允許拆分售賣（用來控制總投資人數(shù)）

核心交易規(guī)則的交易在off-chain的Trade Controller，校驗的結果同步給Regulator Service。這部分的實現(xiàn)，相對的沒有其他家協(xié)議透明?？窗灼?，Trade Controller的實現(xiàn)目前是控制在Harbor自身，沒有對外開放。

小結：

相比較Securitize的生態(tài)系統(tǒng)，R-Token略顯稚嫩，特別是投資人認證的信息以及交易監(jiān)管邏輯其實是在off-chain實現(xiàn)的。對于二級市場的接口對接推測應該在off-chain完成。

亮點是對于交易校驗的分層設計，很明確的提出了兩層校驗。

不足：Harbor的系統(tǒng)相對封閉，未有提到引入三方開發(fā)的意思。不像Securitize和Polymath，一上來，就招呼大家一起來玩耍。

Harbor的合作方也在逐步建立中，合作的交易所偏去中心化的比較多，主要是0x protocol，SWAP協(xié)議的。

鑒于Habor最近發(fā)售了第一個項目，關注度又上升了不少?？凑麄€的邏輯就是自己做發(fā)幣技術平臺、Token銷售平臺，做一個閉環(huán)，而不是像Securitize和Polymath僅僅做發(fā)幣技術平臺。也許是因為這點，所以Habor的技術一開始就沒有設計要引入三方開發(fā)。

Harbor的一條龍商業(yè)模式，類似toB toC兩手抓，成功的概率可能更大。

Polymath

以下基于Github代碼，Polymath的白皮書主要focus在他家自己的POLY平臺幣的生態(tài)，而不是在具體STO協(xié)議的實現(xiàn)技術。

Polymath的github代碼量非常多，不停在更新，看起來著實費勁，因此本人僅從他家的readme.md獲取相關信息來管中窺豹。所以對于Polymath代碼層面的解讀，可能存在不全面的地方。

ST-20是基于ERC-20協(xié)議的：

重寫transfer（）和 transferFrom（）兩個接口，在Token轉移的過程中，進行verifyTransfer（），主要進行白名單校驗。

增加了mint（）、verifyTransfer（）接口

提供凍結交易的接口

提供獲取投資人名單的接口，方便派息

增加了N多模塊注冊的接口

增加強制轉移接口

通過增加模塊到SecurityToken上，來達到豐富STO各類控制的功能。比較核心的幾個模塊：

TransferManager模塊：主要控制白名單以及鎖定期

Security Token Offering模塊：主要定義Token的分發(fā)規(guī)則，類似傳統(tǒng)ICO的Crowdsale合同

Permission模塊：控制不同角色的參與者，對合約功能的權限

以及各類增加Module豐富Token控制功能的模塊，這塊設計賦予了無限可能

Polymath的投資人白名單是off-chain管理的。和二級市場的接口對接，也未有詳細提到。推測和Harbor類似。

從Polymath的白皮書中，可以看到Polymath不僅僅立志做一套STO發(fā)幣和管理協(xié)議，而是放了比較多精力在相關過程的document上鏈溯源，以及，生態(tài)內各個三方供應商（律所、開發(fā)者）的眾包服務平臺。

基本就是，我提供了一個毛胚房，同學們來裝修入駐吧。不好意思，進門請給POLY。平臺立志從POLY上掙錢。感覺還是ICO浪潮下技術公司的思路。

小結：

Polymath的代碼更新的最勤快，對于交易控制以及STO代幣權益（股息派發(fā)）的設計都已考慮。對于Security Token中定義了非常多的自有接口。但是對于二級市場用戶的白名單管理接口，提及不多。

Polymath對于document的上鏈溯源的考慮，是一個亮點。也許別家也有，沒提。

另外，Polymath的生態(tài)中，規(guī)劃是依賴于外部的智能合約的developer來提供豐富的符合發(fā)行監(jiān)管要求的Token合約代碼，因此，Polymath自己僅僅提供核心基礎代碼以及擴展增加各類合約的接口而已。每個項目發(fā)幣，都要找平臺上的外包開發(fā)定制合約。

也許未來，Polymath會退化成一個基礎協(xié)議+眾包平臺。

從平臺本身的發(fā)展方向看，STO發(fā)行的核心就是律所合規(guī)和金融產(chǎn)品設計了，這些都要無數(shù)輪線下溝通，包括最終合約開發(fā)，隨便找個眾包，可控性太差。眾包平臺的這個設想，個人認為并不是很適合這個行業(yè)。

Polymath的缺點，11/17，發(fā)布了2.0.0版本，然后悲催的和1.3.0不兼容。某種程度上，這個技術架構設計是不是不如Habor or Securitze？

StartEngine

這家公司的協(xié)議提到的人比較少，這是一個傳統(tǒng)的股權眾籌網(wǎng)站。其實STO玩家有兩種，一種純區(qū)塊鏈技術公司，一種就是傳統(tǒng)股權眾籌公司轉型，各有各的優(yōu)勢。有時間可以再寫寫這類公司的研究。

StartEngine提出了ERC 1450協(xié)議，以下基于github和白皮書。

ERC-1450是基于ERC-20協(xié)議的：

對于合約中方法和事件的觸發(fā)權限，做了嚴格的角色分類，引入了RTA（Register Transfer Agent）這種新的角色

對于交易的驗證控制以及交易操作（transferFrom, mint, and burnFrom），都由RTA角色執(zhí)行

禁用了transfer, allowance, and approve

投資人的信息和認證信息都是off-chain的。

整個架構設計上，一級市場發(fā)幣以及二級市場交易的管理，都是通過把權限控制在RTA這樣的角色來完成。合格投資人認證、鎖倉時間等信息，都是由RTA在off-chain控制。

二級市場設計上，RTA需要和ATS對接，RTA執(zhí)行token的transfer。

1450提出了符合監(jiān)管的找回投資人丟失證券的設計方案（在區(qū)塊鏈，你忘記錢包地址了，丟幣了就是丟幣了，但是這是Security Token，丟了，還得負責給你找回來重發(fā)）。此為亮點。

小結：

StartEngine是股權眾籌網(wǎng)站，因此所設計的協(xié)議和架構，傳統(tǒng)金融痕跡濃厚。對于區(qū)塊鏈技術本身的應用僅局限于給了RTA一個控制權限，交易操作都必須是RTA來執(zhí)行。

對ERC-20接口改的太多。技術參考價值不大，但是在業(yè)務模型設計上，可以借鑒。

總結

各家都屬于尚在不斷完善和開發(fā)自己的協(xié)議中，通過架構的可擴展設計，達到——先發(fā)幣、后逐漸完善交易規(guī)則、權益規(guī)則合約的目的。通俗的講，就是系統(tǒng)先跑起來，后面慢慢再迭代。（先圈錢！）

同時各家基本都屬于需要引入三方developer一起幫忙完善開發(fā)更多合約的開發(fā)。

現(xiàn)有的主流協(xié)議的功能成熟度總結：

交易控制：大家都是干這個的

派息分紅：Securitize、Polymath

取消/凍結交易：Securitize、Polymath、StartEngine

重發(fā)Token：StartEngine

強制轉移：Polymath

不同功能的權限控制：基本每家都有考慮