EOS账户系统(7)权限评估

EOS账户系统(7)权限评估

1. 场景

  • 授权涉及个人或群体,并且往往是分类的。
  • 身份验证和权限管理必须标准化,并与应用程序的业务逻辑分开。

2. 定义

确认某项操作是否被正确授权。

最简单的权限管理是检查交易是否具有所需的签名,这也意味着所需的签名是已知的。

EOS 提供了一个声明式权限管理系统,可以对账户进行细粒度、高级别的控制,以确定谁在何时可以做什么。

2.1. 评估过程

以通用的方式管理权限:从小到大进行逐级匹配。

@alice 以 “Action” 类型发送一条消息给 @bob

step1. 检查@alice 是否为 @bob.groupa.subgroup.Action 定义过权限映射。
step2. 如果没有找到,紧接着检查@bob.groupa.subgroup 映射,然后是 @bob.groupa,最后 @bob 将被检查。如果都没有找到,那么假定映射为命名的权限群组@alice.active

  • 一旦一个映射被识别,则使用相关联的签名验证权限。
  • 如果失败了,则跃迁至父权限,直至拥有者权限@alice.owner。

2.2. 特点

权限管理和程序逻辑是相互独立的,自然权限评估和程序逻辑也是可以分开执行的,这让验证权限成为一个只读过程且可以并发执行、跳过多余的权限评估过程,从整体上提高性能,显著提高TPS性能。

权限评估过程是“只读”的,并且对事务所做的权限更改直到块结束才会生效。

=>

  • 所有事务的密钥和权限评估可以并发执行;
  • 可以快速验证权限,而不需要重新启动昂贵的应用程序逻辑;

2.3. 交易权限

验证权限占验证交易所需计算资源的很大一部分。

  • 交易权限可以在接收到待处理的交易时进行评估,而在应用它们时无须重新评估。
  • 当我们重放区块链的历史,试图从操作日志重新生成确定性状态时,不需要再次评估权限。交易包含在一个已知的不可逆区块中这一客观事实,足以让其跳过权限评估的步骤。这极大地减少了重放不断增长的区块链时消耗的计算资源。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值