EOSIO Labs™ Release: Specification Repository for Architecture and Approach Feedback

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 [email protected].

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 Note: 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.