译文/Translated：
上个月，我们宣布推出EOSIO Labs™，这个项目标志这我们开始对建立在EOSIO上的区块链技术未来进行开放式创新。这个项目下我们首先发布探讨的是关于私钥管理的未来以及它对安全和密钥管理的影响——通用认证库（Universal Authenticator Library , UAL）。
本文会继续讨论EOSIO Labs，其中我们将主要探讨EOSIO应用程序证明、声明合约、以及它们背后蕴含的安全模型，以便用户在区块链应用上签署交易时能增加信心。
分层式的安全模型
从定义上来说，公共的、无权限的区块链可以让任何应用代表区块链上的有效用户获得区块链上的任何合约。这种开放式架构让无数服务商建立满足用户要求的应用。但是，这种开放生来具有一些问题：
- 签名过程中，应用可能对用户伪造身份（如，谎称自己是example.com的官方应用）
- 签名过程中，应用可能对用户伪造签名的内容（如，要求签署用户未授权的动作）
这里我们提供一个分层的安全模型，它会把“谁”和“什么”这两个问题抽象化，使其成为应用要考虑的问题，这就把它和实际交易签名通过可信的交易认证器（交易签名者）获取的方式分离开。
首先我们要介绍的是应用程序证明（Application Manifests ）的概念，它能验证应用程序来源、回答“你能合法地代表谁？“。第二，我们还在目标链上部署声明合约（Assert Contract ），它能根据应用程序证明上的链上内容检验交易内容，从而确保应用发起的交易是合法的。简单来说，我们引入应用程序证明和声明合约，其目的正如上所述。实际应用中，它们还要和一系列相应工具，如李嘉图合约渲染器、授权传输协议等，共同承担责任，保证区块链用户能够获得安全和可信的体验。
安全模型
应用程序证明和声明合约与相应能够现实李嘉图合约的认证器合作解决上述“谁”和“什么”的问题。我们要注意，在这个模型下，认证器不会直接代表应用和区块链通信。验证器代表用户安全地签署交易，然后把交易返回到应用，再由应用传输到相应的区块链中。比如说，图1是下面我们要详细阐述的流程图。
应用程序证明
应用程序证明公开展示去中心化应用的元素据以及该应用可以传递到一个智能合约的所有动作。这个公示会在链上以及应用网站域名中的显著地方呈现。这两个声明和声明合约一起让受信任的验证器提供以下保证：
- 请求交易签名的应用是该域名的授权应用。当应用要求交易签名时，验证器可以执行同源策略验证应用是否提供了证明以及应用程序网站域名中的证明副本是否可以进行哈希验证。这就让用户可以相信他们是在和该域名内合法的应用交互，因为只有控制该域名的合法的用户才能在该位置进行证明。此外，在必要的时候，它还能让应用程序资源，如图标等，进行哈希验证。
- 在对比证明中允许的动作之后，应用要求的动作是合法的，这样才能避免应用恶意要求代币转移，如当动作不在区块链游戏或拼车应用白名单时。
在这个模型下，我们还提供工具和渲染器来启用受信任的验证器，这就可以向终端用户展示大量的李嘉图合约内容，让他们能够验证他们在授权的交易的具体内容。证明细则提供了上面流程图的具体细节。李嘉图细则和李嘉图模板工具包向验证器提供工具渲染李嘉图合约。除了参考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社区的一员志愿对其做出贡献，但是并不能保证软件的整体性能和应用的性能。我们不代表、保证、确保或执行这里描述的任何版本、GitHub上发布的文件、EOSIO软件或者先前提到的，不管是明确说明或者暗示的，任何文件的发布，包括但不限于承诺书、商业性、为某个目的的实用性、不侵权性等。在任何情况下，我们都不对任何说法、损失或责任负责、不管是涉及合约、侵权或被侵权的情事件，不管这是因为软件或文件或使用或软件和文件中涉及的其它事宜导致，还是和这些情况相关，我们都不对此负责。测试结果或者性能数据都是有指示性的，不可能反应所有情况下的性能。任何关于第三方的引用、第三方产品、资源和服务都不是Block.one背书和支持的。第三方产品可能在任何时间被升级、改变或暂停，所以这里提供的信息可能会过时或不准确。任何使用本软件提供的关于第三放软件、产品和服务的个体应该建议这些第三方提供执照有效期、免责声明和免责条款。Block.one, EOSIO, EOSIO Labs, EOS, heptahedron和相应的图标都是Block.one的商标。这里提到的其它商标都是他们相应持有人的产权。
原文/Original：
Last month, we announced EOSIO Labs™, an initiative through which we have begun innovating in the open with regards to the future of blockchain technologies built on EOSIO. Our first release under this initiative explored the future of private key management and its implications on security and key management — the Universal Authenticator Library (UAL).
This post continues the EOSIO Labs series, expanding on the ideas of EOSIO Manifests, Assert Contracts, and the Security Model behind them to increase user confidence when signing transactions on blockchain applications.
A Layered Security Model
Public, permissionless blockchains by definition enable any application to access any contract on the blockchain on behalf of a valid user of the blockchain. This open architecture enables numerous providers to build applications that meet users’ needs. However, inherent in this openness is a set of issues:
- Applications can misrepresent who they are to the user during signing (e.g., falsely claim to be the official app for example.com)
- Applications can misrepresent what the user is signing (e.g., request signatures for actions the user did not authorize)
Here we present a layered security model that abstracts the who and whatconcerns as an application concern that is separate from the way actual transaction signatures are achieved in trusted authenticators (transaction signer).
First we introduce the concept of Application Manifests that help validate the source of the application, answering the “who do you legitimately represent?” question. Second, we introduce the Assert Contract installed on the destination chain that provides assurance that
the transactions being posted by the application are legitimate by validating transaction contents against the on-chain contents of the Application Manifest. For simplification, we present Application Manifests and the Assert Contract as having the two clearly defined purposes outlined above. In reality, they share responsibility with a series of related tools like Ricardian renderers, authorization transport protocols, and others, to help deliver a secure and trusted experience to blockchain users.
The Security Model
The Application Manifest and the Assert Contract work together with conforming authenticators that have the ability to display the Ricardian contracts to solve the who and what problems outlined above. It is important to note that under this model authenticators do not communicate directly with the blockchain on behalf of the application. Authenticators securely sign transactions on behalf of the user and return the transaction to the application, which then broadcasts it to the respective chain. For reference, Figure 1 is a summary of the flow we detail below.
Application Manifest
The Application Manifest publicly declares metadata about the decentralized application and the list of actions the application is permitted to broadcast to a particular smart contract. This declaration is made both on-chain, and at a well-known location on the application’s web domain. Taken together, these two declarations working in concert with the Assert Contract will enable the trusted authenticator to provide assurances that:
- The application requesting a transaction signature is an authorized application for that domain. When an application requests a transaction signature, the authenticator can enforce the same-origin policy and verify that the application provided manifest and the copy of manifest that lives at the web domain of the application are hash verifiable. This allows users to trust that they are dealing with a legitimate application for that domain as only legitimate users in control of their domain can host the manifest at that location. In addition, this also allows for application resources like icons to be hash verified as necessary.
- The action being requested by the application is legitimate by comparing it against the list of permitted actions in the manifest, preventing an application from maliciously requesting a transfer of tokens if that action is not listed in the whitelist for a blockchain game or ride sharing application, for example.
Under this model, we also provide tools and renderers to enable trusted authenticators, which can display rich Ricardian contract content to the end users and enable them to verify the exact contents of the transaction they are authorizing. The Manifest Specification provides additional details of the above flow. The Ricardian Spec and Ricardian Template Toolkit provide tools for authenticators to render Ricardian contracts. In addition to reviewing the repositories on GitHub, you can read more about Ricardians in our recent release post on Medium.
Assert Contract
The Assert Contract installed on the destination chain works in concert with the Application Manifest to ensure transactions being posted by the application are legitimate by validating transaction contents against the on-chain contents of the Application Manifest. Trusted authenticators under this model will add an assert::require action to all transactions forcing validation of key details of the Application Manifest on chain. This action is intended to ensure that if any of the details provided by the application don’t match the on-chain details, then the entire transaction fails, protecting the end user.
In particular, the Assert Contract:
- Allows blockchain networks to register the official chain name and chain icon.
- Allows decentralized application developers to register one or more manifests describing their application and to remove previously registered manifests.
- Allows users (via a trusted authenticator) to include an assert::requireaction in a transaction that will ensure that the entire transaction is rejected if the required pre-conditions are not valid.
Trusted authenticators can now run transaction pre-flight security assertions with the Assert Contract comparing the contents of a transaction request with the list of permitted actions the applications have declared. These assertions include comparing the hash of the Application Manifest, the hash of the app-provided chain info, the hashes of ABIs provided by the app (including the Ricardians presented to the user) against the hash of the matching ABIs on chain to validate that the contract presented to the user for the given action was not tampered with.
Keen observers of this model will note how the security model is geared to maintaining the logical separation of a trusted authenticator from decentralized applications. Authenticators that conform to this model simply add a well-known assert action to all transactions for a given chain to secure end users.
We invite the community to explore if, in the future, application contract developers can also choose to examine incoming transactions to verify that it contains the same well-known assert action before processing the transaction further. This check could provide another on-chain transaction verification mechanism. The Assert Contract provides additional technical details.
The Benefits
This layered application architecture enables trusted authenticators to be excellent custodians of users’ private keys and remain clearly delineated from application-specific actions while still enforcing a security model that provides additional assurances to the end user. This way, blockchain users do not have to review all the source code associated with every decentralized application before using them since the components of the security model in themselves provide significant assurances for the end-user to confidently interact with the blockchain.
Some of the benefits of this approach are:
- Transactions that do not conform to the Application Manifest are rejected outright by the trusted authenticator and never get broadcast to the blockchain
- Transactions that make it to the chain from trusted authenticators are still verified against the Application Manifest contents on chain
- Application search engines can listen to manifest registrations and build a comprehensive listing of known decentralized applications for end users to choose from
- The model also provides a way for application developers to defend themselves against incorrect accusations made by end-users when malicious third parties commit fraud by impersonating their application
However, this model in itself does not solve all the issues associated with imposters. If the user does not pay attention to the displayed Ricardians in a secure authenticator prior to signing the transactions proposed by applications from bloçkçhainapplication.com instead of those from blockchainapplication.com — this model fails to protect users from such imposters. We invite ideas from the community on how the framework can be extended to handle such attack vectors. We consider the model laid out here as a starting point for initiating the discussion with the community and we look forward to hearing from you.
Stay Connected
If you are interested in providing feedback and working more closely with our team to improve the EOSIO Labs repositories for developers, you can post issues and pull requests on GitHub or send our developer relations team an email at developers@block.one.
You can also stay informed of future updates by subscribing to our mailing list on the EOSIO Developer Portal. We are excited to be continually improving the usability of the software for EOSIO developers as we continue laying a foundation for the mass adoption of blockchain technology.
The Future is Open for EOSIO Labs
Through EOSIO Labs, Block.one will continue releasing our thoughts and research on projects like this for EOSIO. This is just the first of many areas of research we hope to tackle as part of the community. We welcome and encourage your feedback on areas of interest to explore and look forward to continually growing one of the most vibrant and innovative technology communities in the world.
Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. All other trademarks referenced herein are the property of their respective owners.
原文链接/Original URL:
