EOS源码分析(5)账号

# EOS 账号

EOS 的账号系统可以说在当前的公链系统中是非常完善的，在进一步理解EOS的账号系统以前，让我们先看一下区块链中其他公链的账户系统是怎样设计的。

大家都知道，区块链上的第一个应用就是比特币，它创建了一种点对点的电子货币系统。由于是一套货币系统，因此它主要针对的是货币的产生，点对点货币支付等场景，在这套系统中，设计的视角是从货币出发的，系统中仅有交易地址的概念，并没有账号的概念。

相比于交易地址，账号一般都会有余额的概念，系统为每个账户存放了余额信息，任何时候你都可以查询到此余额，而比特币交易地址并没有这些余额信息，比特币所保存的信息主要就是交易信息本身，余额信息是通过交易推算出来的，交易的过程类似于我们在生活中使用法币的场景。试想一下你兜里目前有3张一元和一张五元的纸币，当你要购买一个价格为2.5 角的冰激凌的时候，你可以考虑拿三张一元的纸币，也可以考虑直接使用一张五元的纸币，对方会根据你的纸币金额再找零给你。在任何一个时间点，其实没有一个固定的余额数字告诉你兜里还有多少钱，但你的余额可以根据你所有的交易数据推算出来，每个账户的余额就是你交易地址所涉及的所有未花费交易输出（UTXO: unspent transaction outputs)。比特币的这种账号系统的优势就在于他完全是无状态的，从技术的角度来说，无状态的系统更容易扩展，更容易并行处理。

与比特币的UTXO模型不同，以太坊是有账户体系的，它的账户包含四个部分：

1. 随机数，用于确定每笔交易只能被处理一次的计算器

2. 账户目前的以太币余额

3. 账户的合约代码，如果有的话

4. 账户的存储（默认为空）

以太坊有两种类型的账户：外部账户和智能合约账号，其中外部账号是没有代码的。人们可以通过创建和签名一笔交易从外部账号发送消息，每当智能合约账户收到消息后，其内部代码会被激活，允许代码对账户内部存储进行读取和写入。可以看到，账户系统对于智能合约功能的支持来说是必须的，有了账户的概念，智能合约中才能更方便的访问账户中的信息。

以太坊账户系统已经提供了一些通用的信息和功能，但这个账户系统在实际应用使用中，还是不够完善，主要集中在三个方面：

1. 账户的地址是一个20字节的地址，不方便记忆

2. 账户不支持权限管理，不能应用在需要复杂权限管理的场景

3. 密钥一旦丢失，再也无法使用此账号

正是看到了以上这些问题，EOS系统在设计的时候，力求打造一套具备完善功能的账号体系，这样能够更好的支持各类应用场景需要，具体特性包括：

1. 采用了方便人类阅读的字符串（2-32字符）来创建账号

2. 支持域的概念，例如@domain 账号的拥有者是唯一能够创建@user.domain 账号的人

3. 支持完善的权限管理体系

4. 账户间消息发送和处理

5. 恢复被盗窃的密钥

# 权限管理

## 基于角色的权限管理

所谓权限管理，简单的来说就是判定某条消息是否被正确的授权，此处的消息泛指EOS中一切调用，包括交易和对智能合约的调用。在区块链中，比较常见的一种权限管理方式是判定一笔交易是否包含有效的签名，比特币中每笔交易都会做类似的判定，这种权限管理方式属于很简单的一种类型，它的审查范围是针对每笔交易，没有细化到账号级别，并且在这类判定中，操作所需权限（签名）都是已知的，而在实际情况中，权限一般都会绑定到账号或者多人账号级别，并且账号所拥有的权限和操作所需要的权限是分别控制的，EOS 提供的这种声明式的权限系统可以在账户级别提供细粒度和高纬度的控制，它可以有效的管理什么账号可以在什么时间做什么事情。

认证和权限管理必须标准化，并且与应用程序的业务逻辑分开，这样可以通过开发工具以通用的方式来管理权限，并且为性能优化提供可能。

每个账号都能被其他多个账号和私钥按照权重组合进行控制，这就创造了一种分层级的权限结构，它真实反映了现实中的权限分配方式，并且让多用户共同管理资产变得从未如此简单。这种多账户控制机制，能对账户的安全性提供保障，减少被黑客攻击而造成的资金损失风险。EOS甚至还允许定义某种多账户和私钥的组合可以发送特定的消息类型给另外一个账号。举个例子，可以指定一个密钥给一个用户的社交媒体账号，同时另一个密钥访问交易所。甚至可以授权其他账号来代表本账号而无需把自己的密钥分配给他们。

## 命名的权限级别

EOS 中每个账号都会有两个固有的命名权限，如下：

- `owner`

`owner` 表示账户的所有权（是账户最高权限），此权限能够对账号做所有的操作，甚至可以重新恢复那些已经被泄漏的权限，一般只有很少的操作需要此权限。通常情况下，建议你把此权限对应的私钥进行冷存储，不要把它与任何人分享。

- `active`

`active`权限可以用来进行转币，投票和其他的一些高级别的操作。

除了系统固有的这两种命名权限外，账号还可以添加定制的命名权限来扩充账号管理功能，并且这种权限可以从更高级别的命名权限继承。每一个命名权限都支持多重签名阀值校验，其中的多重签名可以包含密钥和/或其他账户的命名权限级别。

针对上面所说的权限级别，这里举一个例子。在Steem区块链应用中，包含了三个硬编码的命名权限级别，分别是`owner`, `active`和`posting`, `posting` 权限只能进行如投票和发帖的社交活动，`active`权限可以做除了变更拥有之外的所有操作。`owner`权限则可以做包括冷存储在内的所有的事情。

## 命名的消息处理群组

EOS允许账号可以根据命名的嵌套群组来定义其消息处理函数。这个命名的消息处理群组可以在其他账号配置他们权限级别时被引用。

最高级别的消息处理群组是账户名称，最低级别的是一个账户所接收到的单独的消息类型，这个群组可以被这样引用：

`@accountname.groupa.subgroupb.MessageType`

在这样的模型下，交易所合约可以通过将挂单的创建和取消分组，从而与充值提现分离开。交易所合约的这种分组对用户而言带来了方便。

## 签名

### 单签（默认账户配置）

账号在创建的时候，默认会有两个权限，分别是`owner` 和`active`，每个权限对应一套密钥（一个公钥，一个私钥），每套密钥对应的权重都是1，权限的验证阀值也是1，因此消息的授权只需要某一个权限的单独签名即可，如下：

|:--|:--|:--|:--|

| owner | | | 1 |

| | EOS5EzTZZQQxdrDaJAPD9pDzGJZ5bj34HaAb8yuvjFHGWzqV25Dch | 1 | |

| active | | | 1 |

| | EOS61chK8GbH4ukWcbom8HgK95AeUfP8MBPn7XRq8FeMBYYTgwmcX | 1 | |

在以上@bob账号中，bob的`owner`的权限权重是1，交易签名所需要的授权阀值也是1，因此当bob需要发送交易消息的时候，只需要使用owner的key对交易消息进行签名即可通过验证。

### 多签与定制权限

以下我们虚构一个需要多签名的账户@multisig. 在这个场景中，@multisig 账号的`owner`和`active`权限分别有需要两个账户的授权，`publish`权限则需要三个签名，包括两个账户和一个`key`，并且这三个签名的权重是不一样的，具体如下：

|:--|:--|:--|:--|

| owner | | | 2 |

| | @bob | 1 | |

| | @stacy | 1 | |

| active | | | 1 |

| | @bob | 1 | |

| | @stacy | 1 | |

| publish | | | 2 |

| | @bob | 2 | |

| | @stacy | 2 | |

| | EOS7Hnv4iBWo1pcEpP8JyFYCJLRUzYcXSqtQBcEnysYDFTEbUpi6y | 1 | |

在以上场景中，由于`owner`的权限阀值是2，而`owner`权限下的两个账号的权重都是1，因此，当需要对交易消息进行签名的时候，需要这两个账号同时授权才可以。

如果所发送的交易消息需要`active`权限，由于此权限的阀值是1，这就意味着只需要`active`权限下任何一个账号授权就可以了。

这里还有一个自定义的命名权限叫做`publish`, 此权限的阀值是2，而其下的账号@bob和@stacy的权重都是2，另外一个key的权重是1，这就意味着@bob和@stacy都可以独立的进行签名，而key则需要另外一个签名一起才可以进行授权。

在以上案例中，权限的设置同时使用了**账号**和**key** 的形式，这种形式初看起来觉得意义不大，但其实引入了一种非常灵活的维度。

## 权限映射

命名权限级别和消息处理群组这两个概念之间可以做映射，也就是说，可以将某个消息处理群组分配到某个权限级别上。举个例子：一个账户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射，有了这个映射，任何朋友都可以以这一账户的身份在社交媒体上发帖，但尽管他们能够以账户所有者的身份发帖，他们仍然使用自己的密钥来签名消息，这意味着总可以辨别出是哪一个朋友在以何种方式使用账户。

## 评估权限

当@alice发送一条类型为“Action”的消息给@bob 时，EOS首先会检查是否存在一条@alice权限和@bob.groupa.subgroup.Action操作之间的映射，如果没有找到，会继续检查@bob.groupa.subgroup与@alice权限之间是否存在映射，然后是@bob.groupa,最后@bob将被检查，如果都没有找到，那么就假定映射为命名权限@alice.active。

一旦某个映射被识别，则通过阀值多签名流程验证权限是否有效，如果失败了，则会找寻其父权限，直至拥有者权限@alice.owner.

![evaluating permission](images/3.1.eval-perm.png?raw=true)

请看以上事例，图中@USER是一个账户，@EXCHANGE.CONTRACT是个交易所智能合约。@USER账号对应着一组权限，分别是`OWNER`, `ACTIVE`, `FAMILY`, `FRIENDS`,`LAWYER`，其中`OWNER`,`ACTIVE`为EOS提供的账号固有权限，其他则为自定义的权限。他们之间有继承关系，`FRIENDS`权限是继承自`FAMILY`的。

@EXCHANGE.CONTRACT 智能合约中定义了一些消息类型，其中`WITHDRAW MESSAGE`和`TRADE GROUP`是平行的消息类型，`BUY`,`SELL`,`CANCEL`消息都是挂在`TRADE GRAOUP`下的。

图中@User 把交易所智能合约的消息类型和账户的权限做了映射，`CONTRACT`及其下的`TRADE` 类型的消息映射到`FAMILY`权限下，此处相当于在`FAMILY`权限下有两个映射。`WITHDRAW`类型的消息映射到`LAWYER`权限下面，这样的映射形成了如下规则：

1. `FRIENDS`权限下能够做的做的事情，`FAMILY`权限都可以做，因为它是`FRIENDS`的父权限

2. `FAMILY`权限可以发送除`WITHDRAW`消息外其他任何消息，这是因为`WITHDRAW`消息在其他权限下做了特殊的映射，`FAMILY`权限无法覆盖此消息

3. `LAWYER`权限可以发送`WITHDRAW`消息，但无法发送其他消息

当用户向智能合约发送`BUY`消息的时候，系统会按照如下规则判断权限是否符合：

1. 判断是否有 @exchange.contract.buy 和账号权限映射，如果有，直接返回对应的权限，如果没有，则继续

2. 判断是否有 @exchange.contract 和账号权限映射，如果有，直接返回对应的权限，如果没有，则直接返回 @active 权限

3. 判断消息所附带的授权是否能够满足消息所需要的权限

## 并行权限评估

由于权限评估的过程是只读的，并且交易执行对权限的变更在一个区块结束之前是不会起作用的，这就意味着：

1. 所有的权限评估都是可以并行执行的

2. 无需再启动一个可能会引起回滚的高成本的应用逻辑去实现快速的权限验证，并行权限验证已经是一种快速解决方案了

3. 当收到需要等待的交易（pending transactions)时，系统可以直接对其进行权限评估，而无需等到此交易在执行时再被评估，这样可以节约交易执行时间

并且，由于权限验证的操作占据了验证类交易计算量的很大比例，因此，权限评估过程的只读和并发执行的特性将会使整体性能有一个质的飞跃。

# 消息和处理程序

在EOS中，每个账号都可以向其他账户发送结构化的消息，并且可以定义脚本来处理他们接收到的消息。同时，EOS 还给每个账户提供了只有自己的消息处理脚本才能访问的私有数据库。消息处理脚本同样能够给其他账户发送消息，消息和自动化消息处理的结合构成了EOS的智能合约。

## 带强制性延迟的消息

时间是安全中的一个关键组成部分。在大多数情况下，一个私钥在没有被使用前都无从知晓它是否被盗窃。当一个需要密钥的应用在你的某台每天联网的电脑上运行时，基于时间的安全会更加重要。EOS 允许应用开发者指定某条消息在加入到区块之后需要等待多久才能被执行，在这段等待时间，可以随时取消这条消息。

用户会在消息广播出去后通过邮件或者文字的形式收到通知，如果他们没有授权相关操作，则可以使用账户恢复流程来恢复账号，并收回消息。

这个延迟的长短取决于操作的敏感性。如果是为一杯咖啡付款，可以无需设置任何延迟，几秒内交易就不可逆了。而购买一套房子也许需要72小时的结算期。转移整个账号的控制则可能需要长达30 天。具体的延迟时间由开发者和用户来做选择。

# 恢复被盗窃的密钥

EOS系统提供给用户一种找回失窃密钥控制权的方式。账户的恢复需要有以下两个要素：

1. 过去30 天活跃的任意的`owner key`

2. 指定的账户恢复合作伙伴所给出的批准

以上两个条件缺一不可。

那对于已经获取了账号控制权的黑客来说，他会尝试去执行这个账户恢复流程吗？正常来说应该不会，因为他已经取得了账号控制权，再走这个流程对他没有太大的意义。当然，也许这位黑客想完全控制此账户，他希望通过重置`owner key`而完全拥有它，但当他走这个账户恢复过程的时候，账户恢复合作伙伴将会通过多种方式进行身份验证（例如电话，邮箱等）。这将是的黑客做出让步或者无功而返。

账号恢复流程看上去也需要多个账户的合作，有点类似多签名交易的过程，但其实它们是完全不同的两个流程。在多签名流程中，其他参与账号需要针对每笔执行的交易都要进行签名。但在账号恢复流程中，账号恢复合作者只能参与到账号恢复的流程，而无权参与到日常的交易消息签名。这大大降低了账号恢复合作者的成本和法律责任。

网址：http://www.qukuailianxueyuan.io/

欲领取造币技术与全套虚拟机资料

区块链技术交流QQ群：756146052 备注：CSDN

尹成学院微信：备注：CSDN

网址：http://www.qukuailianxueyuan.io/

欲领取造币技术与全套虚拟机资料

区块链技术交流QQ群：756146052 备注：CSDN

尹成学院微信：备注：CSDN

EOS源码分析(5)账号相关推荐

eos源码分析和应用(一)调试环境搭建
转载自 http://www.limerence2017.com/2018/09/02/eos1/#more eos基于区块链技术实现的开源引擎,开发人员可以基于该引擎开发DAPP(分布式应用).下面 ...
[EOS源码分析]1.EOS源码编译运行
本文所有实践都是基于EOS dawn-v4.1.0,请切到该分支然后实践切换命令:git checkout dawn-v4.1.0 目前网络上都是针对老版EOS2.0源码编译的文章,我在mac上参考 ...
[EOS源码分析]4.EOS源码调试
在[EOS源码编译运行]一文已经详细描述了EOS源码编译.但是阅读代码,光跑代码是不够的,必须要可以调试.一搜发现网上没有相关的文章,只好自己探索折腾.不过很快发现其实EOS已经为我们做好了的,只需带 ...
[EOS源码分析]10.EOS区块同步及生产
本文所有实践都是基于EOS v1.0.1,请切到该分支然后对比源码切换命令:git checkout v1.0.1 提到区块生产和同步,我们肯定有几个疑问? 节点同步 1)节点从哪里同步数据 ...
EOS源码分析：transaction的一生
最近在处理智能合约的事务上链问题,发现其中仍旧有知识盲点.原有的认识是一个事务请求会从客户端设备打包签名,然后通过RPC传到非出块节点,广播给超级节点,校验打包到可逆区块,共识确认最后变为不可逆区块. ...
[EOS源码分析]7.EOS智能合约开发实践之合约调用合约(inline action)
首先,目前dawn-4.1, dawn-4.2使用inline action是会报如下错误 transaction declares authority '{"actor":&qu ...
[EOS源码分析]6.EOS特殊智能合约eosio
这里说的eosio智能合约不是泛指eos的智能合约,它是一个特殊的具体的合约.它本事可大了,我们一起来看看它有哪些功能负责智能合约部署大家有注意到如下红色字体的log吗 $ cleos set c ...
[EOS源码分析]5.EOS编写HelloWorld智能合约及各种坑
本文所有实践都是基于EOS dawn-v4.1.0,请切到该分支然后实践切换命令:git checkout dawn-v4.1.0 HelloWorld源码 #include <eosioli ...
[EOS源码分析]2.EOS账号钱包密钥等基本概念及操作实践
本文所有实践都是基于EOS dawn-v4.1.0,请切到该分支然后实践切换命令:git checkout dawn-v4.1.0 cleos cleos应用程序是用户端命令行交互模块,用于解析用户 ...

EOS源码分析(5)账号

EOS源码分析(5)账号相关推荐

最新文章

热门文章