译文/Translated：
在#B1June活动中，我们宣布了EOSIO战略愿景，它规划了Block.one希望推进EOSIO™软件的四大根本支柱：规模化、开发者、用户、和企业。由于EOSIO的持续发展主要依靠和开发者社区的关联，我们正在发布一个新的储存库，从而支持整个生态系统中每个用户，实现更大的增益。
今天发布的版本是EOSIO规范存储库，EOSIO Lab™的这个项目旨在为战略愿景中很多想法提供技术设计细节。它在GitHub上创建了一个专门的存储库，我们可以通过这个存储库更紧密地和开发者社区合作。
促进开源协作
EOSIO的设计是促成一个开源环境，促成更包容的开发方法。EOSIO规范存储库让每个人都有机会对我们已经打下基础的想法进行审阅、评价和项目构建。
存储库包含了目前我们关于技术设计选择的想法和用户可以选择用来实现战略愿景提到的特性和功能的方法。此外，规范是在MIT许可下发行的，目的是鼓励开放协作。
具体来说，我们发布这些规范有如下目的：
- 寻求反馈、并且和社区中使用我们方法的其他人进行直接对话
- 鼓励社区中其他人建立和参与实施这些想法，进一步加速EOSIO生态系统创新的步伐。
本次初始发布包含以下规范，我们的目的是寻求反馈和EOSIO开发者社区的协作
- 合约之间转发授权—合约可以向其它合约证明用户身份验证。这就可以启用合约定义的“子账户”来使用其它合约。
- 合约定义的交易认证—合约定义的子账户可以认证子账户之间的交易。这就让小账户更有用、实现更灵活的账户结构，帮助其它链上的账户和基于EOSIO区块链的账户合作。
- 合约支付交易费用—合约可以支付交易费用（NET和CPU）。没有太多资源或者没有资源的用户可以在不要求应用共同签署原始交易的情况下使用应用。
- 弃用延迟交易—我们在探索如何弃用节点中的延迟交易，其中有几大原因，包括简化交易过程、减少错误可能、调整因为历史和安全因素导致的复杂性问题。本建议解释了其中的一些理由，并提供了一些现有用例可能的替代方案。
- 增强代币—新代币标准的这个潜在定义包含了几个增强。代币增强，其功能性也就增强，它们就能支持子允许跨链交互的子账户。新的备注字段允许用户向合约发送结构化的ABI定义的二进制数据。改进后的通知系统和区块浏览器相辅相成，我们也逐渐终止了对表结构的依赖，这就给自定义代币合约带来了更多开发上的灵活性。
- 灵活的通知—这个通知协议设计得更加灵活。它支持合约对合约信号和合约到外部事件。
- 获取现在的超级节点—让智能合约能够识别现在的超级节点。比如，这就让合约能够识别仅和某些超级节点相关的差异。
- 键值储存—对于作为键值储存实现的节点可能会有数据库的加强，这将会提供更多的灵活性、更好的性能、最终让开发者可以针对不断变化的架构编写高效的代码。
- 查询资源消耗—能够支付交易费用的智能合约需要获得某些数据的权限。让智能合约能够接入交易NET、 CPU费用、和他们自己的RAM消耗，他们就能利用这些指标准确地向用户收费。
- 合约可访问主观数据—与获取信息的方法相同，该意见提供了一些参数以便智能合约能够获得一些主观数据，如CPU费用、挂钟时间和随机数生成器。
- 命名区域—交易吞吐量面临着和智能合约序列执行模型相关的最终限制因素。这里我们讨论是否有方法可以通过名为“命名区域”的并行执行实现规模化。命名区域可以使用普通的区块日记，这样他们就可以保持同步，并提高吞吐量。
- ABI 1.2:ABI中指定数据大小—该规划给ABI提供了一个方法来描述固定储量的内容，同时还能指定任意固定大小。
- 同步调用—合约依靠表格彼此通讯，这就意味着当表格格式更改时会和其它合约产生冲突。本提议提供了方法使合约能够通过只读查询同步相互调用。
- 标记数据—合约可以用自定义类型标记序列化数据，以便进行识别和解码。
加入我们
您可以在GitHub的EOSIO规范存储库提交问题并直接参与讨论。投稿的其它建议及存储库组织的方式参见投稿指南。我们会积极地解决问题并不断参与讨论。
重要注意事项
我们最好把大多数规范称为用户如何实现特性/功能需求的前瞻性项目，我们不能保证最终如何按设计实现该功能，也不能保证更新规范以便匹配最终版本。但是，我们鼓励社区感兴趣的成员和我们的工程团队合作，通过填写GitHub针对单个规范的issue来参与我们概述的设计选择。请注意我们可能不能对反馈的每个部分都做出回应，我们也可能把所有的反馈整合成一个共识方法。
保持联系
我们希望能听到您的意见，所以如果您想给我们提供反馈，或者和我们团队更好地合作，为开发者改进EOSIO，您可以给我们的开发者关系小组发邮件：developers@block.one。
注意，您还可以登录EOSIO新站订阅我们，获取我们未来宣布的最新信息。我们很高兴能够不断为EOSIO开发者改进该软件的可用性，同时，我们也在不断为区块链技术的不断奠定基础。
. . .
重要事项：我们提供的所有信息都受限于本重要通知，您必须熟悉其中的条款。该通知包含了关于我们的软件、发布、商标、第三方资源和前瞻性声明的重要信息、条件和限制。您获取任何材料的时候就意味着您接受并同意该通知的条款。
原文/Original：
At the #B1June event, we announced the EOSIO Strategic Vision which outlines four foundational pillars where Block.one hopes to advance the EOSIO™ software: Scalability, Developers, Users, and Enterprise. As the ongoing evolution of EOSIO fundamentally relies on engagement with the developer community, we’re releasing a new repository to support greater synergy between every stakeholder in the ecosystem.
Today’s release, the EOSIO Specification Repository, an EOSIO Labs™ initiative, provides technical design details for many of the ideas discussed in the Strategic Vision. It creates a dedicated repository in GitHub through which we can more closely collaborate with the developer community.
Fostering Open Source Collaboration
EOSIO is designed to foster an open source environment that will enable a more inclusive approach to the development process. The release of the EOSIO Specification Repository is an opportunity for everyone to review, comment, and build upon the ideas for which we’ve laid the foundation.
The repository contains details regarding our current thinking on technical design choices and high level approaches one could take to realize the features and functionality outlined in the Strategic Vision. Further, the specifications are being released under the MIT License to encourage open collaboration.
Specifically, we are sharing these specifications to:
- Seek feedback and have an open dialogue with others in the community on our approach.
- Encourage others in the community to build on and participate in the implementation of the ideas to further accelerate the pace of innovation in the EOSIO ecosystem.
The following specifications are included in this initial release, intended for feedback and collaboration with the EOSIO Developer community:
- Forwarding Authorizations Between Contracts – Contracts can attest user authentication to other contracts. This enables contract-defined “subaccounts” that can use other contracts.
- Contract-Defined Transaction Authentication – Contract defined subaccounts can authenticate transactions between subaccounts. This makes lightweight accounts more useful, enables more-flexible account structures, and helps accounts from other chains interact with EOSIO-based chains.
- Contracts Paying Transaction Costs – Contracts can pay transaction costs (NET and CPU). Users with little or no resources would be able to use applications without requiring those applications to cosign the original transaction.
- Deprecate Deferred Transactions – We are exploring deprecating deferred transactions in nodeos for a number of reasons, including to simplify transaction processing and make it less error prone, fix complications with history and security issues. This recommendation explains some of the motivation behind this, and presents some potential replacements for existing use cases.
- Enhanced Token – This potential definition of a new token standard includes several enhancements. The increased functionality of enhanced tokens will allow them to support subaccounts allowing for cross-chain interactions. A new memo field allows users to send structured ABI defined binary data to contracts. A revamped notification system plays nice with Block Explorers, and we’ve phased out reliance on table structures resulting in more developmental flexibility for custom token contracts.
- Flexible Notifications – This notification protocol is being designed to be more flexible than previous implementations. It supports both contract-to-contract signals and contract-to-outside events.
- Get Current Producer – Provides the ability for smart contracts to identify the current block producer. This allows contracts the ability to identify discrepancies that are seen only with certain block producers, for instance.
- Key-Value Store – Potential database enhancements in nodeos implemented as a key value store that would provide increased flexibility, performance, and ultimately allow developers to write code that is robust against changing schemas.
- Query Resource Consumption – Smart contracts that are capable of paying transaction costs need access to certain data. By allowing smart contracts to access transaction NET, CPU costs, and their own RAM consumption it’s possible for them to use those metrics to accurately bill users.
- Contract Access to Subjective Data – In the same vein of accessing information, this proposal offers parameters through which subjective data including CPU costs, wall clock time, and a random number generator can be provided to smart contracts.
- Named Regions – Transaction throughput faces an eventual limiting factor relative to the smart contract serial execution model. Here we discuss an approach to scaling via parallel execution called “named regions”. Named regions could share a common block log which enables them to stay synchronized and help increase throughput.
- ABI 1.2: Sized Data in ABIs – This proposal gives ABIs a way to describe the content of sized storage, and to specify arbitrary fixed sizes.
- Synchronous Calls – Contracts rely on tables to communicate with one another, which means that when a table format changes it can create a conflict with other contracts. This proposal provides a method through which contracts can use read-only queries to synchronously call into each other.
- Tagged Data – Contracts may tag serialized data with custom types to identify it for decoding.
Get Involved
Get involved by submitting issues and join the discussion directly in the EOSIO Specification Repository on GitHub. Additional recommendations for contributing and how this repository will be organized are included in the Contribution Guide. We will be actively working to address issues there and stay involved in the discussion.
Important Considerations
Since many of the specifications can be best described as forward looking projections about how one might implement the feature/functionality needs, we are unable to make any guarantees about eventually implementing the functionality as designed or being able to keep the specifications updated to match the eventual implementation. However, we encourage interested members of the community to engage with our engineering team and discuss the design choices we have outlined by filing GitHub issues against individual specifications. Please do note that we may not be able to respond to every element of feedback, or synthesize all the feedback into a consensus approach.
Stay Connected
We want to hear from you, so if you are interested in providing feedback and working more closely with our team to improve EOSIO for developers, you can send our developer relations team an email at developers@block.one.
Remember, you can also keep up to date with future announcements by subscribing to our mailing list on the new EOSIO website. We are excited to be regularly improving the usability of the software for EOSIO developers as we continue to lay a foundation for the mass adoption of blockchain technology.
. . .
Important: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations, and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.
原文链接/Original URL:
