上个月，我们宣布推出EOSIO Labs™，这个项目标志这我们开始对建立在EOSIO上的区块链技术未来进行开放式创新。这个项目下我们首先发布探讨的是关于私钥管理的未来以及它对安全和密钥管理的影响——通用认证库（Universal Authenticator Library , UAL）。
本文会继续讨论EOSIO Labs，其中我们将主要探讨EOSIO应用程序证明、声明合约、以及它们背后蕴含的安全模型，以便用户在区块链应用上签署交易时能增加信心。
分层式的安全模型
从定义上来说，公共的、无权限的区块链可以让任何应用代表区块链上的有效用户获得区块链上的任何合约。这种开放式架构让无数服务商建立满足用户要求的应用。但是，这种开放生来具有一些问题：
这里我们提供一个分层的安全模型，它会把“谁”和“什么”这两个问题抽象化，使其成为应用要考虑的问题，这就把它和实际交易签名通过可信的交易认证器（交易签名者）获取的方式分离开。
首先我们要介绍的是应用程序证明（Application Manifests ）的概念，它能验证应用程序来源、回答“你能合法地代表谁？“。第二，我们还在目标链上部署声明合约（Assert Contract ），它能根据应用程序证明上的链上内容检验交易内容，从而确保应用发起的交易是合法的。简单来说，我们引入应用程序证明和声明合约，其目的正如上所述。实际应用中，它们还要和一系列相应工具，如李嘉图合约渲染器、授权传输协议等，共同承担责任，保证区块链用户能够获得安全和可信的体验。
安全模型
应用程序证明和声明合约与相应能够现实李嘉图合约的认证器合作解决上述“谁”和“什么”的问题。我们要注意，在这个模型下，认证器不会直接代表应用和区块链通信。验证器代表用户安全地签署交易，然后把交易返回到应用，再由应用传输到相应的区块链中。比如说，图1是下面我们要详细阐述的流程图。
应用程序证明
应用程序证明公开展示去中心化应用的元素据以及该应用可以传递到一个智能合约的所有动作。这个公示会在链上以及应用网站域名中的显著地方呈现。这两个声明和声明合约一起让受信任的验证器提供以下保证：
-
请求交易签名的应用是该域名的授权应用。当应用要求交易签名时，验证器可以执行同源策略验证应用是否提供了证明以及应用程序网站域名中的证明副本是否可以进行哈希验证。这就让用户可以相信他们是在和该域名内合法的应用交互，因为只有控制该域名的合法的用户才能在该位置进行证明。此外，在必要的时候，它还能让应用程序资源，如图标等，进行哈希验证。
-
在对比证明中允许的动作之后，应用要求的动作是合法的，这样才能避免应用恶意要求代币转移，如当动作不在区块链游戏或拼车应用白名单时。
在这个模型下，我们还提供工具和渲染器来启用受信任的验证器，这就可以向终端用户展示大量的李嘉图合约内容，让他们能够验证他们在授权的交易的具体内容。证明细则提供了上面流程图的具体细节。李嘉图细则和李嘉图模板工具包向验证器提供工具渲染李嘉图合约。除了参考GitHub存储库，你还可以参考我们在Medium发布的最新帖子了解李嘉图合约。
声明合约
安装在目标链上的声明合约和应用程序证明协作验证交易内容是否符合应用程序证明的链上内容，从而保证应用提出的交易是合法的。这个模型下，受信任的验证器会对所有交易增加assert::require动作，强制验证链上应用程序证明的关键细节。这个动作的目的是保证如果应用提供的任何细节不符合链上细节，那么整个交易都会被取消，从而保护终端用户。
特别是，声明合约：
1. 允许区块链网络注册官方链名称和链图标。
2. 允许去中心化应用开发者注册一个或多个应用程序证明描述其应用和注销之前注册的应用程序证明。
3. 允许用户（通过受信任的验证器）在交易中加入assert::requireaction，从而确保如果所需前提无效整个交易都会被取消。
受信任的验证器现在可以运行交易处理前安全声明，对比交易请求的内容和应用公布的允许的动作。这些声明包括对比应用程序证明的哈斯值，应用提供的链信息哈希值、应用提供的ABI哈希值（包括呈现给用户的李嘉图协议）和链上匹配的ABI哈希值比值从而验证提供给用户的特定动作合约未被篡改。
