基于角色的权限
这是我从Hyperledger Composer中学到的一个概念，它是一个在Hyperledger结构之上工作的框架。NodeJS SDK提供了通过访问不同应用程序的指令来开发不同“角色”的环境。
在EOS中，基于角色的权限管理涉及确定操作是否被授权。每个帐户（哈希）由其他帐户和私钥的组合控制。根据我的经验，这个概念虽然非常简单，但在Hyperledger Composer中并不直观，因为抽象会淡化去中心化的基本原则。也许Hyperledger 结构更深，但学习曲线更慢。Hyperledger Composer在基于角色的管理中缺乏更多自定义。
最终，EOS定义了密钥或帐户的哪些组合可以发送特定的操作（Action）。由于权限是只读的，因此可以在不使用昂贵的应用程序逻辑的情况下验证权限。当其他帐户在攻击中需要识别时，安全性会增加。
模块
在EOS中，如果应用程序从不依赖于另一个合约的状态，则定义给其他应用程序的操作将被安全地忽略。我使用Hyperledger Composer中的业务网络定义(.BNA文件)体验过此功能。.BNA文件使用应用程序的标识符启动，该标识符用于与具有正确权限的其他应用程序通信。例如，某些事务可能对某些应用程序是可读和可编辑的，但对于其他应用程序则不是。根据我的经验，Hyperledger Composer为开发人员提供了一种连接不同应用程序的简单方法，因为它可以作为应用程序的URL。EOS可能有类似的功能，但我在这方面没有更广泛的经验。
计算资源的计量
此功能是一道安全墙。如果区块检测到帐户或事务正在使用异常数量的资源，区块生产者可以拒绝该事务。这与以太坊中用于防止DDoS攻击的Gas限制阈值非常类似。计算资源的计量是由区块生产者主观地完成的。因此，不一定要用确定性的方法来衡量，然后用一些优化方法进行改进。
应用程序消耗了三种主要资源类，这些资源创建了通证化的环境。
1、带宽和日志存储（磁盘）
2、计算和待办计算积压（CPU）
3、状态存储（RAM）（可从应用程序逻辑访问的信息）
翻译自：my-thoughts-in-eos-blockchain-vs-ethereum-and-hyperledger
