DoraID：通用去中心化身份和Staking机制

目标

DoraID旨在提供一套能够在区块链上自治的去中心化身份认证体系，为链上大量的需要身份认证、抗女巫攻击的去中心化应用提供基础服务支持。

一方面，传统链上的KYC认证均无法绕过一定程度的中心化节点对于账户的链外身份信息进行查验、记录的步骤。因此这类服务往往对于用户的操作复杂度、使用成本都较高。而且基于验证的方式、审核的合规程度不同，这类中心化节点参与的认证服务也会存在通用性较差，中心化节点自身的安全风险等问题。

另一方面，在实际运作中有很多项目和机构使用Token Staking（锁仓或持有量证明）来作为一个特定账户地址在其去中心化应用中的身份判别条件。这一方法能够有效筛选出“有身份”的账户地址，但是大多数场景下用户只是为了特定的一个合约服务来进行锁/持仓操作，而身份认证服务本身没有任何泛用性。同时对于一些体量较小，或者功能较为简单的去中心化轻服务（比如仅仅参与一个投票）来说，让用户为了一次简单的操作而提供一个“昂贵”的持有量证明，将会极大的拉高这类应用的用户门槛，阻碍应用的发展。

基于目前链上身份认证服务的基础，本着在去中心化网络中“资产即身份”的理念，DoraID仍然以锁仓Token数量，锁仓时间作为身份认证的核心要素。在此基础上，允许用户以更灵活的方式调整自己的锁仓情况，同时将账户身份判断的决策权转交到上层的应用合约或者链外的服务中。因此用户可以根据实际的需要来动态调整锁仓情况，以便使用最优的锁仓数量和时间来享受“认证后”的权利。也可以通过配置一个“充分”的锁仓方案，来实现一次锁仓，享受多个不同合约/服务中的身份认证权益。

核心功能

在DoraID的去身份验证合约中实现了如下基本功能：

•   在合约内可以且仅可以设置一种ERC20 Token，作为该合约进行身份认证时所依赖的代币。

•   合约内设置了若干初始认证账户地址，即初代认证账户。

•   用户可以将任意数量的对应Token以任意时间锁仓在合约内。其中，在设定的锁仓时间结束之前，用户不能取出他所有锁定在合约内的Token，但是可以任意的增加锁仓的数量或者延长锁仓的时间。

•   已认证用户的在合约的内锁仓会生成他们的持有量证明。

•   任何一个在当前时刻锁仓数量和剩余锁仓时间均超过“认证阈值”的未认证账户，可以被一个已认证账户通过消耗一定的持有量证明，调用合约接口来进行激活，成为一个已认证用户。

•   合约对外暴露查询账户状态的接口，供其他合约或者链外的个人或组织对特定地址的身份认证状态进行评估。

合约中不包含管理员账户，不可升级，没有任何项目方收取手续费的设计，是一个纯粹的身份验证合约。

另外地，DoraID 同时会提供一套便于用户进行交互/查看/查询的前端界面，辅助用户直观的和链上的核心身份验证合约交互。同时用户也可以直接和链上合约交互以实现更灵活的对于锁仓情况的控制。

身份证明

在合约部分，任意一个账户地址都可以查询到以下公开信息：

•   是否是已认证状态

•   当前锁仓Token数量

•   当前锁仓的最早可释放时间

•   激活该账户的认证用户地址（如果当前账户已认证）

•   通过该账户激活的账户数目（如果当前账户已认证）

•   POS持有量证明

•   账户所有者自己上传的一段String备注信息

DoraID本身并不规定如何根据这些公开信息来判断某一特定账户是否在当前的上下文中具有“被认证”的权益，而是需要使用 DoraID 的合约/链外服务（下文统称应用）根据这些公开信息，结合自身的场景和用户的请求来判断。但是一般的，我们认为这些应用应该基于以下有序逻辑来对账户地址的身份进行判断：

判断账户是否已认证

除非当前应用认为当前操作不需要用户有认证状态（比如当前用户是正在参与一个非常公开的活动），否则应当始终忽略未认证的账户地址，即使他们提供了一些锁仓作为身份证明。

判断锁仓数量是否大于特定阈值

逻辑上我们认为锁仓数量与账户地址的“身份高低”应当存在正比例关系，即锁仓数量越大，应当享受的权益也越大。应用可以根据用户当前使用的功能，判断当前的锁仓数量是否可以享受认证后的权益，甚至可以量化的计算出用户能享受的权益程度。

需要注意的是由于锁仓的代币价值可能会有所波动，应用层应当结合实际情况调整阈值的高低，并且可以保留调整阈值的方法。

判断剩余锁仓时间是否大于特定阈值

应用必须判断当前账户地址的锁仓时间是否大于该地址当前可能申请到的权益的生效时间。否则，该账户的所有者完全可以在锁仓时间结束，而权益未结束的时候取出所有锁定的Token，并用这些Token锁仓、激活另一个新的地址，从而使得同一份Token在应用层面换取到两份重叠的收益。

特别地，如果当前地址可能申请到的这份权益的有效时间也是动态的，那么应用可以不需要判断锁仓时间阈值，而是给这个地址一份同样有效持续时间的权益。

例如：用户尝试参与一个持续一星期，需要身份认证的IDO。这等同于用户尝试申请一个最少持续一星期的不可代替的此次 IDO 的认购权。因此公募合约必须检查用户剩余的锁仓时间至少有一星期以上。

【可选】判断该账户的上下游认证连锁路径

虽然合约中完整记录了地址的认证链路，但是由于链上递归操作可能造成Gas使用过高的风险，因此不建议在没有辅助用以判断认证关系的中间件层时，检测地址的完整认证路径。另一方面，“谁认证了该地址”与“该地址认证了谁”这两个信息的实际含义一般对于该地址的权益判断没有强关系。基于以上原因，应用可以根据实际场景来设计是否需要使用这一数据。

【可选】公示账户的备注信息

合约一般不会处理String类型的自定义信息，但是对于链外应用，或者通过 DoraID 来查看特定地址身份的开发者，可以公示、阅读该账户在合约中储存的备注信息。

我们并没有硬性规定这部分备注应该以什么格式提交，也不强制所有用户上传这一备注信息，更不保证任何备注信息的真实性。但是我们建议用户上传一个URL，并且在URL指向的资源中提供一些可公开的强身份性的信息，并且最好能循环公示/证明其账户地址。（例如：在备注里备注一个Github的链接地址，在这个链接中可以看到某一Repo中readme.md中也注明了这一链上账户地址信息，那么显然这个账户地址和这个Github账号之间有很强的身份关联）

另外，应用不应该参考账户的POS持有量证明，尽管这一数据也是公开的。因为账户的持有量证明会在身份认证合约中被用于激活其他账户而消耗，而除此之外这又是一个持续自增的变化参数，我们不认为这一数据具有强的身份判别关系。

身份认证背后的共识

除了提供合约及配套的前端界面的服务外，DoraID 还希望能建立一套针对该服务下所产生的认证身份含义的共识——这也是基础服务能够给上层应用赋能的重要条件。

首先需要指出的是，DoraID 并不保证任何一个在合约内经过“认证”的账户地址都是对应一个独立的自然人或者真实的组织、团队、公司。因为这是一个去中心化的解决方案，在没有链外信息的干预时，我们基于“资产即身份”的基础价值观念，仅在逻辑层面全力保证同一份资产（Token）不会在同一个时间段用以代表多个身份，从而极大的增加女巫攻击上层应用的门槛。

在锁仓-确权的理念之外，DoraID 中还设计了若干初始认证账户，及“新认证账户必须已认证账户激活”的机制。基于这一机制，在合约的数据层面将会形成一个网状辐射的认证关系网络，所有认证关系也都是可以遍历的。虽然合约中并没有额外收取任何手续费用，但是老认证用户需要为这种激活操作支付区块链网络上基础的矿工费用，即花费一定的成本，因此没有理性的认证用户会无条件的帮助所有符合锁仓阈值的非认证用户进行激活。我们认为基于这种设计，两个账户地址的持有者（当他们不是同一个人的时候）在链外至少有一定的沟通。继而我们也可以认为在这个过程中，激活者对于被激活者的真实身份有一个弱的担保关系。具体来讲，即使被认证节点地址使用认证的身份在某些场合做出一定的恶意行为，认证者也不应当被认为需要对这一恶意行为承担任何责任。但是对于一个频繁地去无差别激活其他地址，甚至包括多个恶意账户地址的激活者，其自身及其激活的其他账户地址的可靠性评价会被认为是更低的。

由于遍历认证关系这种行为在链上非常“笨拙”，因此这种关系一般情况下不会对使用身份认证服务的上层的合约所感知（它们只关心认证状态、锁仓数量、锁仓时间）。但是在链外一些更“主观”的场合，通过分析这个认证网络以及网络中各节点地址的特征，我们可能会对同样是认证过的地址有不同程度的可信度的评价。这种共识的评价会在一些有社区生态的应用中，给社区成员提供一些对他人身份认证情况的参考。

拓展功能及机制

有报酬的认证请求

在合约层面，希望得到认证的未认证用户可以在锁仓的同时指定一个报酬金额和一个委托账户地址。一旦报酬金额被设置，那么成功认证该账户地址的已认证账户将会获得这部分报酬（合约所支持的ERC20 Token）。同时，如果委托账户地址被指定，那么在未对委托账户进行修改前，仅有指定的已认证账户可以激活该待认证账户。

对于激活者和被激活者在链外已经一定程度上确认过身份并且沟通完毕的情况下，这种机制可以确保被激活者承诺的认证报酬可以在认证达成时奖励给激活他的已认证账户，保障双方的利益。同时特定的委托账户地址保证没有其他已认证用户通过更高的Gas费进行攻击，抢先激活并获得其收益。

锁仓强制取回

在合约中，用户的锁仓数量和时间都是自定义的。一般情况下，在锁仓时间到期前锁仓数量只能增加不能取回，而锁仓结束时间只允许设置一个更靠后的时间点来覆盖。因此用户如果由于失误设置了不合理的数量或时间，可能导致用户在非常长的时间里都失去他的代币的使用权。而在没有设置超级管理员的去中心化合约中，这种失误造成的损失是无法找回的。

尽管这种失误的发生完全是又用户自己造成的，并非服务本身有问题，但是我们还是可以在合约中设置一个强制取回的逻辑：用户可以锁仓一笔相当大数量的Token，来无视任何条件将他锁仓的时间重置为一个相对较小值。

这种机制的存在会对整个身份认证系统的可靠性存在一定的影响，因为持有巨量Token的用户有滥用这种功能创造多个虚假身份的风险。但是由于在这一过程中存在重置锁仓时间后的最短时间限制，巨额的Token并不能在短时间能重复使用创建多个有身份账户。而一味的增加操作中使用的Token数量也会带来较大的无常损失风险。仅有当应用层面身份验证后的收益极大时，利用锁仓强制取回机制才有可能给攻击者带来利益，而在这种情况下，我们建议应用不要使用DoraID，而使用整体成本都更高的其他KYC服务。