LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资产 > 加密金融之路殊途同归 数字证券协议标准大融合时代来临

加密金融之路殊途同归 数字证券协议标准大融合时代来临

2019-12-22 咪咪源 来源:区块链网络

在过去一年中,以太坊出现了许多协议来处理区块链上自动化合规方面的问题。对于加密金融而言,合规是必要的,因为目前存储在区块链上的证券和其他价值表现形式,都要受到合规监管的约束。作为一项具有真实资产支撑的加密资产,数字证券也必须遵守现有的证券法。虽然数字资产的合规之路是艰难的,但自动化合规依然具备十分强大的吸引力。

合规是要确保组织遵循另一个实体制定的一组精确的规则、标准和流程,这些规则保护国家安全、打击非法洗钱,并阻止金融体系内的犯罪活动。比如在美国,判定金融活动合规性的机构就包括金融业监管局(FINRA)、商品期货交易委员会(CFTC)、证券交易委员会(SEC)和金融犯罪执法网络(FinCEN)。

自动化合规有很多好处,发行者需要考虑如何确保数字资产在一级和二级市场上的合规性,自动化合规的可编程能力则可以减少对人的依赖,控制人为因素导致的风险。另一种方法是在遵循“信任且验证”结构的情况下进行合规性检查。通常,经纪自营商会设立合规部门,通过每天进行检查以确定是否存在“违规”或“异常”。现在,他们可以通过实时运行自动化合规程序,从而确保数字资产无法在违规的情况下进行交易或转移。

随着技术进步,自动化合规将成为未来IT和金融服务的标准。如果我们想使用区块链这样的技术来提高金融效率并进行无国界交易,就可以利用智能合约来进行这些实时检查。下面,我们重点分析S3、R-Token、ST-20、DS Protocol和ERC-1400协议,这些协议在自动化合规方面类似但机制略有不同。

Smart Securities Standard(S3) — Open Finance Network

OpenFinance Network是专注于数字证券交易的平台,它有一个可以通过智能合约自动执行合规程序的框架,该框架作为灵活的Smart Securities Standard(S3)发布。他们的Github存储库既包含智能合约库,也包含用于与智能合约交互的库,这个库能够包含所有“注册和受限证券”,包括法规D、Reg S、Reg A+和Reg CF。

简化的S3体系结构提供了一个不需要进行链上规则检查的被许可通证。与ERC-20兼容的标准包含两个主要组件,其中一个包含通证的股权结构表,另一个包含通证的核心逻辑。核心逻辑组件称为Delegate ERC-20,它充当由另一个智能合约处理所有通证逻辑的代理。这个合约被称为TokenFront,它只允许被另一个合约调用。这使得当有新规则需要被遵循的时候,通证的商业逻辑可以被修改,同时允许其保留一个永久地址,并且有一个单一合约可执行类似Transfer这样的事件,该事件可被相关方和数据追踪方接收。

这个框架在处理余额和转账方面有两个独特之处。与其他标准相比,该框架的所有S3标准证券的股权结构表都存储在一个单一合约中,该合约与其传输限制规则相分离。本合约需要执行两个阶段的清算结算协议,用户通过在关联的通证前端调用Transfer和TransferFrom函数来创建通证传输请求。之后,第三方通过提供一个错误代码来解析每个传输请求。该协议可以让通证在二级市场进行上市和共享,而不存在传输不兼容的风险。此外,错误代码可以作为一个信号,确保用户理解如何进行合规性的处理。

Regulated Token(R-Token) — Harbor

Harbor创建了一种去中心化的合规协议,称为R-Token,它确保数字资产能够被合规地交易。该协议由三个部分组成,分为三个不同的智能合约。实际的数字资产(协议的通证部分)构建在ERC-20标准之上,该标准允许与现有的去中心化应用程序系统集成。在其他两个智能合约的帮助下,通证将监管检查嵌入其中。

当通证的智能合约被创建时,服务注册表(Service Registry)将被附加到通证上。服务注册表映射到一个注册服务之中,该服务包含对特定通证的传输检查。在进行传输之前,通证将与被映射到监管者服务之中的服务注册表进行检查。监管者服务嵌入了准确的合规检查,确保双方都有资格根据各自的钱包地址和转账金额完成转账。一旦检查失败,将输出一个公共事件,可以让正在接受此合约的各方确定传输失败的原因。

与S3机制类似,该协议有一个固定的合约地址,该合约具有稳定的地址和可以调用的特定函数。服务注册表充当可以被修改的监管者服务代理,只有指定的服务注册表所有者才能更新监管服务。该协议需要一个所有者或中心主体,它作为管理员的角色可以对监管服务和通证本身进行检查。受监管的通证(R-Token)之所以被许可,是因为有一个检查交易的监管者服务,它们承担了自动化合规的角色。

ST-20(Security Token Standard)(ERC-1400/ERC-1410) — Polymath

ERC标准引入的另一个协议是ERC-1400/ERC-1410,该协议得到了Polymath的支持和实现。ST-20是ERC-1400/EC-1410的同义词,在ERC-1400/EC-1410中,ST-20致力成为发布数字证券、管理其所有权和传输限制的标准接口。ST-20实现有一个verify Transfer函数,该函数根据特定的数据参数检查传输是否成功,如果传输失败,则输出失败的原因。在本规范中还提供了通过放置法律文档的散列来支持链上文档。

数字证券标准的构建是灵活的,可以管理不同类型可替换通证(Fungible Tokens)所代表的资产所有权。ST-20本身在ERC-20之上有几个额外的检查,分别是verify Transfer、mint和burn。此外,ST-20协议要求通证能够具有强制转移能力,以防法律诉讼并用于资金追回操作。这一能力是ST-20独有的特性,其他框架还没有明确讨论是否支持强制转移。

数字证券标准包含关于部分可替换通证的内容,这意味着可以将通证的所有者划分为不同的部分。这些不同的部分可以用于不同的归属或锁定逻辑。虽然这增加了复杂性,但这种结构可以更好地应用于Polymath所研究的某些用例。

Polymath为整个通证生命周期构建了一个生态系统。通过几个嵌入式模块,数字证券可以符合监管法规。它允许发行方创建可升级的合规通证,这些通证可以兼容任何复杂的规则集。比如,有一个模块可以限制投资者的总量或限制每个投资者持有的通证数量。此外,还有一些模块可以处理股息支付,并在链上和链下信息处理之间架起桥梁。

Digital Securities(DS)Protocol — Securitize

Securitize创建的DS Protocol是所有已发行证券的完整通证生命周期和架构。该协议适用于发行者、投资者和交易所。DS通证兼容ERC-20。在通证初始化时,它们具有调用DS Protocol的嵌入式函数。

DS Protocol具有多个确保合规性的模块和服务,包括信任服务、注册服务、合规服务。与其他标准类似,Transfer和TransferFrom函数包含前面提到的检查服务。此外,它还提供了将去中心化的应用程序集成到DS Protocol中的能力,这些应用程序可以触发通证的功能。这个额外功能由信任服务处理,因此DApps可以为投资者进行KYC和验证。

DS Protocol通过注册服务查看更小粒度的投资者信息,包含投资者国籍、KYC到期日、经过哈希处理的KYC信息等,而不仅仅查验投资者是否有资格进行交易。对信息进行散列意味着这是单向查找,因此可以进行验证,但是不能从散列中收集信息。在链上存储过多信息的一个后果是,它让发行者之外的不可信方承担合规责任。

最后一个服务,合规服务是在Transfer和TransferFrom过程中调用的服务,此服务可以对注册服务进行检查,并包含此通证约束的逻辑。

本质上,这些协议的技术要点是一些被许可的智能合约,其遵循发行人或持有人在通证转移过程中的限制以及其他规则和条例,其中一些协议使用标准的错误代码来提供更多关于限制的信息。对于数字证券而言,这些规则需要在整个通证生命周期(即一级发行和二级交易)期间得到执行。一些基本特征将二级市场的交易限制在特定的交易方,这可能只是一个以太坊钱包地址列表。虽然看上去很简单,但考虑到KYC和AML法规,因此在区块链上拥有数字身份是十分必要的。同样重要的是,能够锁定一个账户的通证,并限制其因为法律纠纷而转移。这些通证的另一个常见特性是,不同的通证可能具有不同的锁定期,这取决于资产或管辖权。此外,管理员需要能够铸造或销毁通证。

所有这些项目都试图解决类似的问题,但都是针对其自身的用例。不过这些项目已经意识到,基本的ERC-20通证因缺乏足够的检查而无法做到合规。由于现实世界具有很强的操作合规性,因此仅使用ERC-20的项目必须重新发行通证才能实现合规,但今天许多通证并未限制二级市场的交易。同时,交易行为不再集中于中心化平台之上,点对点交易成为加密金融领域的重要交易方式,因此就需要在通证中内置监管检查合约。这些解决方案包含了中心化的某些方面,比如管理员角色的设置或维护合规标准的特定小组。

如今,数字证券领域的标准正在向一个全新的标准迈进,如果说标准化带来了互操作性,并能够让更多的流程和系统在范例中得以构建和应用,那么未来即使是非常小众的标准,也会被融合进统一的标准之中。

—-

编译者/作者:咪咪源

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...