EOSIO™ Version 1.8.0-rc1: EOSIO Consensus Protocol Upgrade Release Candidate for Enhanced Security and Usability Features
As a contributor to the development and enhancement of the EOSIO software, we are pleased to announce a release candidate is available for EOSIO. You can find more details about EOSIO v1.8.0-rc1 in the GitHub repository. Documentation on the EOSIO Developer Portal will be updated by the stable release and recommendations for anyone operating a node for an EOSIO blockchain network are available in GitHub.
This release candidate marks a major update for the EOSIO software platform: a consensus protocol upgrade, which implements a change to the protocol rules and requires alignment by block producing nodes for the upgrade to be successfully deployed. Please note, this is a Release Candidate for feedback, the official release will be marked stable in the coming weeks once we have finished vetting and testing the update with the community. The latest STABLE release is v1.7.3.
When this release is promoted to stable, foundational mechanisms will be introduced to facilitate the activation of the consensus protocol upgrade. More specific details on these mechanisms are available in issues #6429, #6431, and #6437 in the GitHub repository for the EOSIO software. These mechanisms will allow a two-thirds majority of active block producers of EOSIO blockchains to activate individual features of the consensus protocol upgrade to modify the protocol rules. All nodes will need to be locally configured to accept these upgrades, which can be as simple as installing a new version of the nodeos software. Each feature is for the most part designed to be à la carte, i.e. each feature can be activated independently of one another, however, some features may have dependencies on other features as noted in each issue.
Continue reading below for an overview of the initial protocol upgrade features in this release and their implications to developers and users of EOSIO platforms:
Protocol upgrade features in EOSIO v1.8.0-rc1 Release Candidate:
(#6431) Enable protocol feature pre-activation
Codename: PREACTIVATE_FEATURE
This feature is actually part of the foundational mechanisms to facilitate activation of consensus protocol upgrades and will, therefore, need to be the first feature that is activated. Some features will be configured to require pre-activation on the blockchain. This enables replacing the subjective block producer policy of when to activate a particular feature with an objective on-chain policy carried out via smart contracts. Typically this objective on-chain policy will be in the form of requiring more than two-thirds of active block producers to approve an on-chain multisig transaction proposal which would execute a special system contract action to pre-activate the particular feature. The PREACTIVATE_FEATURE feature must be activated before the new version of the system contract with that special action can be deployed since the action implementation will require a privileged intrinsic function only made available after PREACTIVATE_FEATURE is activated.
(#6333) Disallow linking to non-existing permission
Codename: ONLY_LINK_TO_EXISTING_PERMISSION
This disallows linking an action (via the eosio::linkauth native action) to a non-existing permission. Missing this check should not create any security issues; it is only to avoid an inconvenience for the user.
(#6672) Fix excessive restrictions of eosio::linkauth
Codename: FIX_LINKAUTH_RESTRICTION
This relaxes the unintentionally restrictive limitations on which actions can be linked to a minimum required permission. Subjective mitigation cannot fix this bug. However, the bug is not a security issue. It simply means that until this feature is activated, contract developers should not name their actions updateauth, deleteauth, linkauth, unlinkauth, or canceldelay so that their users do not run into any trouble with setting custom minimum permissions for the contract’s actions.
(#6458) Disallow proposing an empty producer schedule
Codename: DISALLOW_EMPTY_PRODUCER_SCHEDULE
This disallows a contract from proposing an empty producer schedule. No subjective mitigation is needed for this bug because: proposing an empty producer schedule does no harm; and, only privileged contracts, such as the system contract, are allowed to propose producer schedules changes anyway.
(#6705) Restrict authorization checking when sending actions to self
Codename: RESTRICT_ACTION_TO_SELF
This would remove the authorization checking bypass that applied when a contract sent an inline action to itself or when it sent a deferred transaction consisting of only actions to itself. Subjective mitigation to restrict the authorization bypass was already released. This feature goes further in the restriction and makes it objective so that the authorization checking behavior for all actions becomes consistent regardless of whether the actions are the original actions in an input transaction, actions included in a contract-generated transaction, or inline actions sent by a contract. Block producers should be aware that activating this feature could break existing contracts that rely on the remaining activate authorization bypass that this feature would remove.
(#6103) Fix problems associated with replacing deferred transaction
Codename: REPLACE_DEFERRED
An issue exists with the current mechanism to replace an existing deferred transaction using the send_deferred intrinsic function. First, the RAM used to store the original deferred transaction is not returned back to the original payer. Second, the transaction ID of the original deferred transaction persists, which means the new deferred transaction could retire in a block with the incorrect transaction ID. Fixing these issues requires a consensus protocol upgrade, which is what this feature does. This feature will also correct the RAM usage of any accounts that have already been affected by this bug. Currently, EOSIO software has a subjective mitigation to disallow replacing existing deferred transactions using the send_deferred intrinsic function. That subjective mitigation will be removed when this feature is activated.
(#6115) Avoid transaction ID collision of deferred transactions
Codename: NO_DUPLICATE_DEFERRED_ID
The prior issue with replacing deferred transactions could lead to a deferred transaction retiring with a transaction ID that is a repeat of a prior retired transaction. But this is not the only way a deferred transaction could end up with the same ID as another transaction in the blockchain with the current protocol rules of EOSIO. Various stakeholders, particularly block explorers, would benefit from a guarantee of it being virtually impossible for any two distinct transactions within a blockchain to have the same transaction ID. This feature, which depends on REPLACE_DEFERRED feature, makes the changes necessary to enable that guarantee. Block producers should be aware that activating this feature will slightly change the structure of the deferred transactions provided to the onerror handlers of contracts; for details of this change and the impact it may possibly have on existing contracts, see this comment.
(#6105) Modify restrictions on RAM billing
Codename: RAM_RESTRICTIONS
A prior released subjective mitigation disallowed unprivileged contracts executing under the context of an action notification from billing any RAM to accounts other than self. Rather than simply making this restriction objective, this feature takes a more flexible approach which still achieves the same goal of disallowing an unprivileged contract executing under a notification context from increasing the RAM usage of any other account by the end of the action. However, it also allows unprivileged contracts executing an action (whether under a notification context or not) to carry out database operations which bill RAM to another account, despite no authorization on the action from that account, as long as by the end of the action the RAM usage of the account has not increased.
(#6332) Only bill CPU and network bandwidth to the first authorizer of a transaction
Codename: ONLY_BILL_FIRST_AUTHORIZER
This feature changes the CPU and Network usage billing behavior of EOSIO blockchains to only charge the first authorizer of the transaction. This one change enables entrepreneuring application developers to build alternative models for paying the CPU and Network resource costs that a transaction imposes on the blockchain network. For example, an application can be designed to pay the CPU and Network costs of their users but only for transactions by the user that solely interact with the application’s services.
(#6988) Forward setcode action to WebAssembly code deployed on eosio account
Codename: FORWARD_SETCODE
This feature changes how the eosio::setcode action is dispatched so that, when activated, the WebAssembly system contract code has a chance to execute when a contract is set on some account. By allowing the WebAssembly code to run, it opens up different possibilities of enforcing on-chain policies regarding the deployment of contracts.
(#7028) Allow contracts to determine which account is the sender of an inline action
Codename: GET_SENDER
This feature adds a new intrinsic function called get_sender which allows contracts to determine which account is the sender of an inline action. This can enable a more flexible method for a contract to notify another contract of an event by sending an inline action rather than using require_receipient while still remaining resistant to spoofing attempts thanks to the new intrinsic function.
Be sure to review the EOSIO v1.8.0-rc1 repository in detail for a full explanation of all the features in this release.
Recommended upgrade process for all EOSIO based blockchain networks:
In GitHub, we have detailed recommendations for anyone operating a node for an EOSIO blockchain network to adequately test and update their systems for each feature to be implemented. All node operators (including non block-producing nodes) should review the suggested instructions as soon as possible because updating to EOSIO v1.8.0 will require a replay from genesis which can take some time. These steps should be followed on an additional node that you can afford to take offline for an extended period of time.
Before deploying the upgrade to any non-test networks, protocol upgrades should be deployed and verified on test networks. Existing EOSIO test networks can use EOSIO v1.8.0-rc1 released today to carry out and test the upgrade process.
This test upgrade process can give Block Producers of their respective EOSIO blockchain networks practice with carrying out the steps necessary to successfully coordinate the activation of the first feature, which will fork out any nodes that have not yet updated to the new version of nodeos by the time of activation. The process will also inform Block Producers of the requirements for nodes to upgrade nodeos to v1.8.x from v1.7.x and earlier, and it can help them decide on an appropriate deadline to be given as notice to stakeholders of the network for when the first feature will be activated.
Stay Connected
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.
You can also keep up to date with 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.
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. Other trademarks referenced herein are the property of their respective owners. Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything, and all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding EOSIO’s development, expected performance, and future features, or our business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.
