译文/Translated：

　　上个月，我们宣布推出EOSIO Labs™，这个项目标志这我们开始对建立在EOSIO上的区块链技术未来进行开放式创新。这个项目下我们首先发布探讨的是关于私钥管理的未来以及它对安全和密钥管理的影响——通用认证库(Universal Authenticator Library , UAL)。

　　本文会继续讨论EOSIO Labs，其中我们将主要探讨EOSIO应用程序证明、声明合约、以及它们背后蕴含的安全模型，以便用户在区块链应用上签署交易时能增加信心。

　　分层式的安全模型

　　从定义上来说，公共的、无权限的区块链可以让任何应用代表区块链上的有效用户获得区块链上的任何合约。这种开放式架构让无数服务商建立满足用户要求的应用。但是，这种开放生来具有一些问题：

　　签名过程中，应用可能对用户伪造身份(如，谎称自己是example.com的官方应用)

　　签名过程中，应用可能对用户伪造签名的内容(如，要求签署用户未授权的动作)

　　这里我们提供一个分层的安全模型，它会把“谁”和“什么”这两个问题抽象化，使其成为应用要考虑的问题，这就把它和实际交易签名通过可信的交易认证器(交易签名者)获取的方式分离开。

　　首先我们要介绍的是应用程序证明(Application Manifests)的概念，它能验证应用程序来源、回答“你能合法地代表谁?“。第二，我们还在目标链上部署声明合约(Assert Contract)，它能根据应用程序证明上的链上内容检验交易内容，从而确保应用发起的交易是合法的。简单来说，我们引入应用程序证明和声明合约，其目的正如上所述。实际应用中，它们还要和一系列相应工具，如李嘉图合约渲染器、授权传输协议等，共同承担责任，保证区块链用户能够获得安全和可信的体验。

　　安全模型

　　应用程序证明和声明合约与相应能够现实李嘉图合约的认证器合作解决上述“谁”和“什么”的问题。我们要注意，在这个模型下，认证器不会直接代表应用和区块链通信。验证器代表用户安全地签署交易，然后把交易返回到应用，再由应用传输到相应的区块链中。比如说，图1是下面我们要详细阐述的流程图。

　　图1：声明、认证细则和李嘉图合约支持的安全模型原理图

　　应用程序证明

　　应用程序证明公开展示去中心化应用的元素据以及该应用可以传递到一个智能合约的所有动作。这个公示会在链上以及应用网站域名中的显著地方呈现。这两个声明和声明合约一起让受信任的验证器提供以下保证：

　　请求交易签名的应用是该域名的授权应用。当应用要求交易签名时，验证器可以执行同源策略验证应用是否提供了证明以及应用程序网站域名中的证明副本是否可以进行哈希验证。这就让用户可以相信他们是在和该域名内合法的应用交互，因为只有控制该域名的合法的用户才能在该位置进行证明。此外，在必要的时候，它还能让应用程序资源，如图标等，进行哈希验证。

　　在对比证明中允许的动作之后，应用要求的动作是合法的，这样才能避免应用恶意要求Token转移，如当动作不在区块链游戏或拼车应用白名单时。

　　在这个模型下，我们还提供工具和渲染器来启用受信任的验证器，这就可以向终端用户展示大量的李嘉图合约内容，让他们能够验证他们在授权的交易的具体内容。证明细则提供了上面流程图的具体细节。李嘉图细则和李嘉图模板工具包向验证器提供工具渲染李嘉图合约。除了参考GitHub存储库，你还可以参考我们在Medium发布的最新帖子了解李嘉图合约。

　　声明合约

　　安装在目标链上的声明合约和应用程序证明协作验证交易内容是否符合应用程序证明的链上内容，从而保证应用提出的交易是合法的。这个模型下，受信任的验证器会对所有交易增加assert::require动作，强制验证链上应用程序证明的关键细节。这个动作的目的是保证如果应用提供的任何细节不符合链上细节，那么整个交易都会被取消，从而保护终端用户。

　　特别是，声明合约：

　　1. 允许区块链网络注册官方链名称和链图标。

　　2. 允许去中心化应用开发者注册一个或多个应用程序证明描述其应用和注销之前注册的应用程序证明。

　　3. 允许用户(通过受信任的验证器)在交易中加入assert::requireaction，从而确保如果所需前提无效整个交易都会被取消。

　　受信任的验证器现在可以运行交易处理前安全声明，对比交易请求的内容和应用公布的允许的动作。这些声明包括对比应用程序证明的哈斯值，应用提供的链信息哈希值、应用提供的ABI哈希值(包括呈现给用户的李嘉图协议)和链上匹配的ABI哈希值比值从而验证提供给用户的特定动作合约未被篡改。

　　敏锐的读者可能已经意识到这个安全模型是如何维持一个受信任的验证器和去中心化应用的逻辑分离。在给定的链中，符合该模型的验证器只要在所有的交易中加入常见的验证动作就可以保证终端用户安全。

　　我们希望社区能够共同探索，思考未来应用合约开发者是否可以选择检验输入交易验证是否其中包含了相同的常见的验证动作以决定是否进行下一步交易。这个检查可以提供另一个链上交易验证机制。技术详情可以参考声明合约。

　　优点

　　分层的应用架构让受信任的验证器成为用户私钥绝佳的保管人。此外，它能在执行安全模型、向终端用户提供额外保障的同时还能清楚地描述特定应用的动作。通过这个方法，区块链用户不需要在使用前检验每个去中心化应用的所有源代码，因为安全模型的每个部分本身都为终端用户提供了重要的保证，让他们能自信地和区块链互动。

　　该方法至少包含以下好处：

　　不符合应用程序证明的交易会直接被受信任的验证器拒绝、并永远不会进入区块链中

　　通过受信任的验证器检验进入区块链的交易依然要受到链上应用程序证明内容验证

　　应用搜索引擎可以收听证明注册并建立已知的去中心化应用的完整目录供终端用户选择

　　该模型还给应用开发者提供了方法保护自己，以免在第三方恶意冒用他们应用进行欺诈之后受到终端用户指责

　　但是，这个模型本身不能解决所有冒名顶替的问题。如果用户在签署的交易来自bloçkçhainapplication.com的应用，而不是blockchainapplication.com 的应用，如果此时他们没有仔细阅读安全验证器的李嘉图合约，那么这个模型是不能保护用户免受侵害的。我们希望社区能够集思广益思考这个框架可以如何扩展，从而解决这些攻击媒介。我们希望这里呈现的模型能够抛砖引玉，我们也希望能听到您的声音。

　　联系我们

　　如果您愿意给我们反馈并想和我们团队并肩完善EOSIO Labs储存库，你可以把问题和需求发在GitHub页面上，您也可以给我们的开发者关系小组发邮件：developers@block.one.

　　您还可以通过在EOSIO开发者入口订阅我们的更新。我们希望能够不断为EOSIO开发者提供更好用的软件，同时，我们也不断为区块链技术的大规模应用奠定基础。

　　未来对EOSIO Labs敞开了大门

　　通过EOSIO Labs，Block.one持续为EOSIO发布如本文所提的想法和研究。这只是我们作为社区的一员我们希望能深入和很多研究中的一小步。我们欢迎并鼓励您在感兴趣的领域对我们提出反馈，也期待着世界上最蓬勃发展、最有创意的科技社区能够不断发展。

　　免责声明：Block.one是作为EOSIO社区的一员志愿对其做出贡献，但是并不能保证软件的整体性能和应用的性能。

　　原文链接/Original URL:

　　https://medium.com/eosio/eosio-labs-release-the-assert-manifest-security-model-cdd296a58710

本文链接：https://www.hellobtc.com/kp/bi/05/1760.html

来源：EOS WIKI