当本版本升级成正式版后，我们将会介绍一些根本机制来激活共识协议升级。在EOSIO软件的GitHub存储库#6429, #6431, 和 #6437 三个部分中，您可以看到这些机制的细节。本次共识协议升级旨在修改协议规则，而这些机制允许EOSIO区块链上2/3活跃的区块生产者去激活共识协议升级的独立功能。所有的节点需要进行本地设置才能接受这些升级，而升级的过程非常简单，和安装新的节点软件版本没有太大的差异。基本上每个功能都可以按需激活，即，每个功能可以独立于其它功能被激活，但是，正如以下每个部分会提到的，某些功能可能需要依靠其它功能存在。
不允许把一个动作（通过eosio::linkauth native action）连接到一个不存在的权限中。未做该检查不会产生任何安全问题，只是为了避免不方便用户。
修复了无意中限定动作必须连接到最低权限要求的限制。主观减少不能修复该漏洞。但是，该漏洞不是安全问题。这是说，在该功能激活前，合约开发者不能把动作命名为updateauth, deleteauth, linkauth, unlinkauth, 和 canceldelay，以免用户对合约动作设定客户最低权限要求时遇到任何问题。
免责声明：Block.one是作为EOSIO社区的一员志愿对其做出贡献，但是并不能保证软件的整体性能和应用的性能。我们不代表、保证、确保或执行这里描述的任何版本、GitHub上发布的文件、EOSIO软件或者先前提到的，不管是明确说明或者暗示的，任何文件的发布，包括但不限于承诺书、商业性、为某个目的的实用性、不侵权性等。在任何情况下，我们都不对任何说法、损失或责任负责、不管是涉及合约、侵权或被侵权的情事件，不管这是因为软件或文件或使用或软件和文件中涉及的其它事宜导致，还是和这些情况相关，我们都不对此负责。测试结果或者性能数据都是有指示性的，不可能反应所有情况下的性能。任何关于第三方的引用、第三方产品、资源和服务都不是Block.one背书和支持的。第三方产品可能在任何时间被升级、改变或暂停，所以这里提供的信息可能会过时或不准确。任何使用本软件提供的关于第三放软件、产品和服务的个体应该建议这些第三方提供执照有效期、免责声明和免责条款。Block.one, EOSIO, EOSIO Labs, EOS, heptahedron和相应的图标都是Block.one的商标。这里提到的其它商标都是他们相应持有人的产权。标
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 isv1.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
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
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
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
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
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
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
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
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
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
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
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.
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 firstname.lastname@example.org.
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. All other trademarks referenced herein are the property of their respective owners.