币圈乱象终结者! 以太坊新STO方案详解

“现在两根金条放这儿，你告诉我哪一根是高尚的，哪一根是龌龊的”

——《潜伏》谢若林

STO：币圈乱象终结者

随着数字货币和ICO市场的逐渐冷却，以监管合规为特点的证券型通证发行（Security Token Offering，证券型通证发行，简称STO）开始获得广泛关注。

STO是将证券的发行、交易以及其他生命周期中的事件放到区块链账本上管理的方式。既然是证券，就必须符合证券法的监管。证券型通证在现实中必须有某种金融资产和权益作为内在价值支撑，例如公司股权、债权、黄金、房地产投资信托、可转债的转换权等。

技术方面，9月14日，开发者Stephane Gosselin在以太坊改进方案（EIP）中提出了一种以太坊上实现STO的技术方案ERC1410，称为“部分可替代通证标准（Partially Fungible Token Standard）”，是一种兼容ERC20和ERC777标准的证券型通证发行标准。

笔者将从代码层面，为您剖析ERC1410提案的实现细节，帮助开发者深入理解以太坊ERC1410实现可监管证券型通证的细节。

从Fungible定义说起

要搞清什么是“部分可替代通证标准（Partially Fungible Token Standard)”，就需要从Fungile的定义讲起。

Fungible一般被翻译为“可替代的”或“可互换的”，根据Wikipedia上的定义:

在经济学中，Fungibility指的是物品可以根据特定单位进行互换的属性。 比方说，黄金可以根据重量单位进行互换，纯度100%的1公斤黄金可以和任意同纯度的1公斤黄金互换，而不管它是硬币、铸锭还是其他的状态。其他可互换的物品包括轻质原油、公司股票、债券、贵金属以及货币等等。 可替代性仅指每单位物品与另一同类物品每单位之间的等价性，而不是指一种物品与另一种物品的交换，比如以物换物。

在以太坊上，所有的ERC20 Token都是“可替代通证”（Fungible Token，简称FT），同一通证内两个相等单位的Token并无差别。Bitcoin与Ether也是可替代的，我的一个Ether跟你的一个Ether并无差别。

与可替代通证相反的叫做“不可替代通证”（Non-Fungible Token，简称NFT）。不可替代通证中的每一个Token都是独一无二的。比如一部2002年的诺基亚无法与一部2018年的智能手机相互替换，因为它们在各自的功能、型号、外观等属性上千差万别，无法通过一种可互换的基础单位进行替代。在以太坊上，ERC721标准即为不可替代通证的标准，ERC721标准中主要刻画了不同属物品的所有权转移。在2017年底流行的CryptoKitties（加密猫游戏）就是基于ERC721实现的。

Partially Fungible Token是什么

如果把可替代通证与不可替代通证看做两端，部分可替代通证（Partially Fungible Token，简称PFT）就是兼具了可替代性和不可替代性2种属性的通证形态。

部分可替代通证是如何做到兼具可替代性和不可替代性的呢?

ERC1410引入一个新的名词叫作“Tranche”，在证券行业中通常翻译为“分级”（例如AAA级、AA级、次级），目的是将通证持有者的账户内Token分成不同的tranches份额，比如用户Alice拥有100个Token，其中tranche1是20个，tranche2是30个，tranche3是50个。不同的tranche具有不同的属性(元数据,metadata)，基于这些元数据，对tranche进行不同的控制。比如tranche1只能用作投票，tranche2只能用于股权确认，tranche3只能用于流通交易。从而在更小的业务粒度上管理账户的数字资产。

不支持tranche的通证账户：

支持tranche的通证账户：

ERC1410技术细节剖析

ERC1410提案的核心部分是tranche，所有提供的操作接口都围绕tranche展开。每个tranche用一个key（类型为bytes32）表示，每个账户地址下可以有多个tranches。

与tranche有关的查询接口

查询某个账户下指定 tranche 的余额：

function balanceOfByTranche(bytes32 _tranche，address _tokenHolder) external view returns (uint256);

查询某个账户下所有的tranches：

function tranchesOf(address _tokenHolder) external view returns (bytes32[]);

与tranche有关的转账接口

举个例子，Alice想要用自己的账户给Bob的账户转账，那么她需要考虑如下问题:

1. 要选取的是账户中哪个tranche?
2. 要转到Bob账户的哪个tranche?
3. 转账的数量是多少?

针对问题1，可以指定一个tranche，或默认的1个或多个tranches（默认tranches将在后文讲述）；针对问题2，由业务逻辑决定；针对问题3，需要由接口指定。

sendByTranche：

function sendByTranche(bytes32 _tranche，address _to，uint256_amount，bytes _data) external returns (bytes32);

上述接口表示从调用者的指定tranche转指定金额到目的账户。

• 如果转账交易不能完成，函数必须revert；
• 如果转账成功，必须emit SentByTranche event；
• 如果转账成功但接收者的tranche与发送者的tranche不同，则必须emit ChangedTranche event；
• 返回值为目的账户接受此次转账的tranche；
• 最后一个参数_data，可以将目标tranche直接用此参数指定，或存放任何与该交易相关的数据，比如授权信息。

sendByTranches：

function sendByTranches(bytes32[] _tranches，address[] _tos，uint256[] _amounts，bytes _data) external returns (bytes32);

上述接口是sendByTranche接口的升级版本，从指定的多个tranches中，往多个目标地址进行转账。

• 如果转账交易不能完成，函数必须revert；
• 如果转账成功，必须emit SentByTranche event；
• 如果转账成功但接收者的tranche与发送者的tranche不同，则必须emit ChangedTranche event

sendByTranche、sendByTranches接口均为交易发起者(msg.sender)对自有账户的操作。

ERC1410基于 ERC777继承了交易员(operator)的相关概念，允许某个交易员代表某个账户持有者基于tranche进行转账。operatorSendByTranche和operatorSendByTranches就是该类型接口。

operatorSendByTranche：

function operatorSendByTranche(bytes32 _tranche，address _from，address _to，uint256 _amount，bytes _data，bytes _operatorData) external returns (bytes32);

• 如果一个未被授权(isOperatorForTranche)的地址调用，函数必须revert；
• 如果转账成功，则必须emit SentByTranche event；
• 如果转账成功且接收者的tranche与发送者的tranche不同，则必须emit ChangedTranche event。

operatorSendByTranches：

function operatorSendByTranches(bytes32[] _tranches，address _from，address _to，uint256[] _amounts，bytes _data，bytes _operatorData) external returns (bytes32[]);

• 如果一个未被授权（isOperatorForTranche）的地址调用，函数必须revert；
• 如果转账成功，则必须emit SentByTranche event；
• 如果转账成功且接收者的tranche与发送者的tranche不同，则必须emit ChangedTranche event。

默认tranche管理

setDefaultTranches：

为了保证与ERC777、ERC20的兼容性，当调用send时，需要决定从哪个或哪几个tranches中转出。为解决这个问题，可以指定某一个或某几个tranches为默认。

function setDefaultTranche(bytes32[] _tranches) external;

设置默认tranches，这样在调用send时，将从default tranches中转账。

getDefaultTranches：

function getDefaultTranches(address _tokenHolder) external view returns (bytes32[]);

获得某个账户的默认tranches。如果返回值为空，则调用send会抛出异常。如果返回多个，则可以按照某种策略进行转出。

交易员（Operator）相关接口

交易员可以被授权操作:

• 所有账户的所有tranches
• 所有账户的某个特定的tranche
• 某个特定账户的所有tranches（包括现在与未来的）
• 某个特定账户的特定tranche

defaultOperatorsByTranche：

function defaultOperatorsByTranche(bytes32 _tranche) external view returns (address[]);

返回具有所有账户的某个特定tranche的默认操作员列表。

authorizeOperatorByTranche：

function authorizeOperatorByTranche(bytes32 _tranche，address _operator) external;

消息发送者授权给某个交易员某个特定tranche的操作权。每次被调用，必须emit AuthorizedOperatorByTranche event。

revokeOperatorByTranche：

function revokeOperatorByTranche(bytes32 _tranche，address _operator) external;

消息发送者撤销某个交易员对某个特定tranche的操作权。每次被调用，必须emit RevokedOperatorByTranche event。

（注: 此Operator仍有可能通过defaultOperatorsByTranche或defaultOperators拥有对此tranche的操作权。）

isOperatorForTranche：

function isOperatorForTranche(bytes32 _tranche，address _operator，address _tokenHolder) external view returns (bool);

查询_operator是否是某个账户特定tranche的操作员。

兼容性

为了使新标准与ERC20/ERC777(另一个NFT标准)兼容，需要定义在transfer/send操作时，哪些tranches会被用到。ERC1410中扩展的getDefaultTranches/setDefaultTranche规则将会被用到。

function getDefaultTranches(address _tokenHolder) external view returns (bytes32[]);

function setDefaultTranche(bytes32[] _tranches) external;

token的创建者必须为所有的通证持有人定义默认的tranche(s)(使用tranchesOf)，以供ERC20/ERC777相关函数使用。而每个单独的账户所有者也可以针对性的修改其默认tranche(s)。

以下行为是在实施ERC777函数中的注意点:

• send()必须调用getDefaultTranche获得默认tranche
• operatorSend()必须调用getDefaultTranche获得默认tranche
• burn()必须调用getDefaultTranche获得默认tranche
• operatorBurn()必须调用getDefaultTranche获得默认tranche
• balanceOf()必须遍历token持有者的所有tranche得到总值
• totalSupply()必须计算合约中的所有token
• defaultOperators()必须返回能操作所有账户与tranche的操作员列表
• authorizeOperator()必须针对msg.sender的所有tranche进行授权
• revokenOperator()必须撤销操作员对msg.sender所有tranche的授权
• isOperatorFor()必须查询_operator是否对_tokenHolder的所有tranches具有授权
• 无论何种原因，如果token总量增加，必须emit两个event : Minted()，MintedByTranche()
• 无论何种原因，如果token总量减少，必须emit两个event : Burned()，BurnedByTranche()
• authorizeOperator()必须emit AuthorizedOperator()
• revokeOperator()必须emit RevokedOperator()

应用场景

ERC1410带来的部分可替换通证能力，为证券通证化带来了可能。通过关联元数据，还能带来丰富的功能逻辑和更灵活的权限控制。

证券型通证发行

• 对证券型通证增加元数据来实现细粒度功能控制。比如股权和投票权分离机制下，一些tranche对应股权信息，一些tranche对应投票权。
• 通证锁定机制。部分通证具有锁定期，比如25%锁定一年，75%锁定两年。则可以划分成三个tranches：不受限部分，受限1年部分，受限2年部分。没到达锁定期前，不能将受限Token转出到不受限制的tranche中；但是可以对相同tranche的Token进行互转。
• 关联公共数据到证券(比如发行者信息，KYC/AML，相关法律文件)，加强通证的信息披露和合规能力。

游戏点卡控制

游戏内的道具需要用点卡购买，为吸引玩家，玩家存入10个点数(Token)赠送2个点数(此刻玩家一共获得12个点数)。但从细粒度来看，这12个点数分为两个 tranches：10个是玩家自有的，可提现但需要优先消费；2个是系统赠送的，不可提现可后消费。在智能合约内就可以实现对不同tranches的不同控制逻辑。

总结

STO的兴起，意味着区块链通证主动进入证券法的监管范围。ERC1410结合可替代通证和证券业务的特点，在技术层面将通证分割成不同的tranches（份额），不同tranches拥有不同的业务逻辑，从而赋予智能合约对通证的细粒度控制能力。

虽然ERC1410目前还处于草案阶段，需要在社区进行广泛听证、讨论后才能正式实施，但从可监管的角度来看，ERC1410依旧是证券通证化的一个良好开端，笔者团队也将持续跟进，为读者解读标准的后续进展。

参考链接

ERC 1400: Security Token Standard #1411

https://github.com/ethereum/EIPs/issues/1411

ERC 1410: Partially Fungible Token Standard #1410

https://github.com/ethereum/EIPs/issues/1410

Security Token Standard

https://github.com/SecurityTokenStandard/EIP-Spec

作者简介：Codefine好码安全团队专注于智能合约安全审计和全生命周期管理, 已为全球多家交易所、钱包、公链做过智能合约安全审计和开发管理。团队通过独有的多维审计引擎，持续为合作伙伴提供正确、安全、可用的智能合约基础设施。