译文/Translated：
作为发展和加强EOSIO软件的贡献者，我们高兴地宣布我们已经完成了EOSIO的升级候选发布版本。您可以在GitHub存储库找到更多关于EOSIO v1.8.0-rc1的细节。详细文档将在稳定版发布的时候在EOSIO Developer Portal上更新，如果您在EOSIO区块链网络上运营节点，您可以在上GitHub找到我们的建议。
这次候选发布版本标志着EOSIO软件平台的一个重大升级：共识协议的升级，这次版本将对协议规则进行调整，要成功部署，它首先的需要区块生产节点的合作。请注意，这只是一个候选发布版本，主要用以收集反馈，社区内审核和测试升级版本几周之后，官方才会发布正式版本。目前最新的正式版是v1.7.3。
当本版本升级成正式版后，我们将会介绍一些根本机制来激活共识协议升级。在EOSIO软件的GitHub存储库#6429, #6431, 和 #6437 三个部分中，您可以看到这些机制的细节。本次共识协议升级旨在修改协议规则，而这些机制允许EOSIO区块链上2/3活跃的区块生产者去激活共识协议升级的独立功能。所有的节点需要进行本地设置才能接受这些升级，而升级的过程非常简单，和安装新的节点软件版本没有太大的差异。基本上每个功能都可以按需激活，即，每个功能可以独立于其它功能被激活，但是，正如以下每个部分会提到的，某些功能可能需要依靠其它功能存在。
EOSIO平台用户的影响：
EOSIO v1.8.0-rc1候选发布版本协议升级特性：
（#6431）启用协议功能预激活
Codename: PREACTIVATE_FEATURE
该功能实际上是激活共识协议升级的基本机制的一部分，所以，它应该是最先被激活的功能。为了在区块链上实现预激活，有些功能应该首先被设定好。这就让我们能够通过智能协议提出客观的链上政策来决定什么时候激活某个特定功能，而不是依赖于区块生产者们主观的想法。一般来说，这种客观的链上政策的形式是要求至少2/3活跃的区块生产者同意一个链上多重签名认证交易提议，而该提议能执行一个特殊的系统合约动作来预激活该特定功能。在带有该特定动作的系统合约版本被部署之前，PREACTIVATE_FEATURE功能必须已经被激活了，因为采用该行动需要在PREACTIVATE_FEATURE被激活之后才能使用的特权内在函数的支持。
（#6333）不允许连接到不存在的权限
Codename: ONLY_LINK_TO_EXISTING_PERMISSION
不允许把一个动作（通过eosio::linkauth native action）连接到一个不存在的权限中。未做该检查不会产生任何安全问题，只是为了避免不方便用户。
(#6672)修复对eosio::linkauth的过多限制
Codename: FIX_LINKAUTH_RESTRICTION
修复了无意中限定动作必须连接到最低权限要求的限制。主观减少不能修复该漏洞。但是，该漏洞不是安全问题。这是说，在该功能激活前，合约开发者不能把动作命名为updateauth, deleteauth, linkauth, unlinkauth, 和 canceldelay，以免用户对合约动作设定客户最低权限要求时遇到任何问题。
(#6458)不允许提出空生产者调度
Codename: DISALLOW_EMPTY_PRODUCER_SCHEDULE
不允许合约提出空生产者调度。本漏洞不需要主观减少，因为：提出空生产者调度不会产生问题；且只有特权合约，如系统合约，才能提出生产者调度变化。
(#6705)向自己发送动作时限制权限检查
Codename: RESTRICT_ACTION_TO_SELF
当合约向自己发送内联网动作或只发送只包含对自己动作的延期交易时，应用的授权检查绕过被移除。限制授权绕过的主观减少已经被释放了。但本功能在限制上更进一步，将其设定成客观要求，这样不管是在输入交易的原始动作、合约产生交易中的动作或者合约发出的内联网动作，所有的动作都需要进行授权检查行为。区块生产者应该要意识到，激活该功能会解除依靠其余激活授权绕过的合约，因为本功能会移除这些授权绕过。
(#6103)修复了和取代延期交易相关的问题
Codename: REPLACE_DEFERRED
现在的机制在使用send_deferred内部函数取代已有的延期交易存在一个问题。首先，用来储存初始延期交易的RAM不会回到初始支付方。其次，初始延期交易的交易ID一直存在，这就意味着新的延期交易会使用错误的交易ID退回区块中。修复这些问题需要共识协议升级，这就是本功能要做的事情。本功能还会修改任何已经受到该漏洞影响的账户的RAM使用。目前，EOSIO软件已经不允许利用send_deferred内部函数取代现存延期交易来主动减少问题。但当本功能激活时，我们就会移除该机制。
(#6115)避免延期交易的交易ID冲突
Codename: NO_DUPLICATE_DEFERRED_ID
过去取代延期交易额能会导致延期交易停止时的交易ID重复之前已停止的交易，但在使用现在EOSIO协议规则的时候还会出现其它情况导致延期交易和链上其它交易的ID相同。如果我们能保证区块链上任何两个不同的交易都几乎不会拥有相同的交易ID，那么大量的持币者，尤其是区块探索者，都能从中获益。本功能主要依靠REPLACE_DEFERRED功能，它会做出必要的调整保证我们实现上述目标。区块生产者应该注意，激活本功能会适当调整提供给合约的错误句柄的延期交易结构。对于本次调整的细节和它可能对现存合约产生的影响，详见评论。
(#6105)修改对RAM计费的限制
Codename: RAM_RESTRICTIONS
先前发布的主观减轻的措施不允许动作通知背景下执行的非特权合约对除自己以外的其它账户RAM计费。本功能不单让该限制变成客观执行方法，同时它还采取了更加灵活的方式实现不让通知背景下执行的非特权合约在动作最后增加任何其他账户的RAM使用。但是，它还允许非特权合约执行动作（不管是不是在通知背景下）实现对另一个账户RAM计费的数据库操作，只要在动作最后该账户的RAM使用不增加即可。
(#6332)只向交易的第一授权方收取CUP和网络带宽费用
Codename: ONLY_BILL_FIRST_AUTHORIZER
本功能改变了EOSIO区块链的CUP和Net使用收费行为，只收取交易第一授权方的费用。该变化让企业应用开发者能够建立其它模型，用以支付交易占用区块链网络产生的CPU和Net资源费用。比如说，他们可以设定应用支付其用户的CPU和Net费用，但只限于用户只使用该应用服务的交易。
(#6988)把setcode动作转发到在eosio账户上部署的WebAssembly代码
Codename: FORWARD_SETCODE
本功能改变了eosio::setcode动作的分派方式，激活本功能后，WebAssembly系统合约代码哪怕没在合约设定在某些账户中都有机会执行。允许WebAssembly代码运行有利于加强执行关于合约部署的链上政策。
(#7028)允许合约判定某内联网动作的发出者账号
Codename: GET_SENDER
本功能增加了一个新的内部函数，其名称是get_sender，它能允许合约判定哪个账户是某内联网动作的发出者。这给合约提供了更灵活的方式，通过发送内联网动作而不是使用require_receipient通知另一个合约事件的发生，同时，因为这个新的内部函数，合约还可避免遭遇欺骗攻击。
请注意详细查阅EOSIO v1.8.0-rc1储存库，获得本次发布所有功能的完整解释。
推荐所有基于EOSIO的区块链网络的升级过程
在GitHub,我们向每一个运营EOSIO区块链网络节点的人提供了推荐详情，让大家可以合理地测试和升级系统，获得各个待安装功能。所有的节点运营商（包括非区块生产的节点）应该尽快阅读建议的指导方案，因为升级到EOSIO v1.8.0需要从头反复测试，这也需要一定的时间。这些步骤将在另一个节点上获得，您可以将来在一段时间内脱机使用这些步骤。
在向任何非测试网络部署升级之前，协议升级应该在测试网络部署和测试。现在的EOSIO测试网络可以使用今天发布的EOSIO v1.8.0-rc1使用和测试升级过程。
本次测试升级过程能够让相应EOSIO区块链网络的区块生产者练习采取必要的步骤，以成功地完成第一个功能的激活，该功能将剔除激活时还未升级到新版本节点的所有节点。这个过程我们也会通知区块生产者我们要求把节点从V1.7.x及之前的版本升级到v1.8.x，从而帮生产者决定什么时候最终通知持币人第一个功能激活的时间。
联系我们
如果您愿意给我们反馈并想和我们团队并肩让EOSIO软件更进一步，您给可以给我们的开发者关系小组发邮件：developers@block.one.
您还可以通过在EOSIO开发者入口订阅我们的更新。我们希望能够不断为EOSIO开发者提供更好用的软件，同时，我们也不断为区块链技术的大规模应用奠定基础。
免责声明：Block.one是作为EOSIO社区的一员志愿对其做出贡献，但是并不能保证软件的整体性能和应用的性能。我们不代表、保证、确保或执行这里描述的任何版本、GitHub上发布的文件、EOSIO软件或者先前提到的，不管是明确说明或者暗示的，任何文件的发布，包括但不限于承诺书、商业性、为某个目的的实用性、不侵权性等。在任何情况下，我们都不对任何说法、损失或责任负责、不管是涉及合约、侵权或被侵权的情事件，不管这是因为软件或文件或使用或软件和文件中涉及的其它事宜导致，还是和这些情况相关，我们都不对此负责。测试结果或者性能数据都是有指示性的，不可能反应所有情况下的性能。任何关于第三方的引用、第三方产品、资源和服务都不是Block.one背书和支持的。第三方产品可能在任何时间被升级、改变或暂停，所以这里提供的信息可能会过时或不准确。任何使用本软件提供的关于第三放软件、产品和服务的个体应该建议这些第三方提供执照有效期、免责声明和免责条款。Block.one, EOSIO, EOSIO Labs, EOS, heptahedron和相应的图标都是Block.one的商标。这里提到的其它商标都是他们相应持有人的产权。标
原文/Original：
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
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. All other trademarks referenced herein are the property of their respective owners.
原文链接/Original URL:
