【一五一十】BM所提到的项目方支付CPU的功能，这里有一些细节信

2018-12-03 本文已影响40人荆凯_EOS42

BM之前提到说，未来可以允许DAPP的项目方为用户提供CPU使用，而大多数的用户不必再担心CPU不足的事情。今天文章，我们来看下关于这一特性，更多的细节。

作者: 荆凯(EOS42中国区运营，欢迎为EOS42节点投票)

BM: 未来，会实现由项目方支付CPU的方式

image.png

11月29日，BM在EOS群中回复社区关于CPU的问题是，提到:

"我们正在进行一个小的硬分叉更改(备注: hard fork，只是代码上的更改而已，不必过度解读)。它将使大多数用户永远不必再租用CPU，并允许DAPP创建者为他们的用户租用(rent)/抵押(own)CPU。"

在介绍更多细节之前，我们先补充一下关于CPU的一些基本的概括。

详见EOS42章经系列文章中第10章: [【EOS42章经】第10章: 一文看完关于CPU资源的常见问题] (https://bihu.com/article/1015058948)

1. CPU的资源消耗

CPU和网络资源，相当于是每一笔交易的燃料。CPU是以时间为单位来衡量的，而带宽资源(NET)是以字符数(bytes)来衡量的。

EOS账号中每一笔交易，都需要用到CPU，你需要为每一笔交易“买单”。

image.png

图中可见，该笔交易消耗了719 μs的CPU资源， 144 Bytes的网络资源。

2. 交易所消耗的CPU使用量，由超级节点来开出账单

超级节点在创建区块的时候，会将这笔交易进行计算，在这过程中消耗了719 μs的CPU资源， 144 Bytes的NET资源，就是为这笔交易所记下的“账单”，会记录在交易的数据结构之中。

而这一份账单，其他的节点都会认可，也留在了区块链上。

目前情况下，这份账单，是由交易的发起者来买单的。比如，A账号向B账号转账，这一笔交易的CPU消耗和NET消耗，会算作A账号的，并从A账号的CPU和NET可用余额中，扣除对应的部分。

而未来在BM所提到的新功能实现并部署到主网之后，可以由DAPP项目方为用户租赁/抵押CPU资源。这样，普通用户就再也不必担心CPU的问题了。

那么，这是怎么一种方式呢？

共识机制升级

链接参见: Issue#6332

这一Issue的标题为：升级共识机制，只向事务的第一个授权方收取CPU和网络带宽账单。
注意，由于该issue的技术性较强，涉及到较多的代码实现层的细节信息，可能不是很容易理解。我的解释和翻译难免会有错误或理解不全之处，还请反馈和指正。

白话解释

一笔事务消耗的网络和CPU资源，目前是会对授权该笔交易的所有账户中的每个账户都进行计费。
blockone的开发者创建了一个提议，标记为“hard fork”的标签，因为涉及到共识协议的升级特性，当然，不会涉及到链分叉，按照我的理解，只是表示该项功能不进行向后兼容而已，需要所有的BP统一升级EOSIO软件。
该提议实现之后，会只对事务的一个授权帐户进行计费，让CPU/网络资源的消耗更少。
应用场景: DAPP的项目方，可以选择自己来承担相应的开销来发起事务，这样，用户就不必在使用该DAPP的时候消耗CPU资源或带宽资源了。

如下为Github上相应的介绍的原文翻译。

背景

目前在EOSIO中，在一笔事务(transaction)所消耗的总CPU和网络带宽，会对该笔交易的多个授权账户的集合中的每个账户进行计费。从保护网络不被滥用的角度来看，CPU和网络带宽只需要向某个帐户计费一次。

通过引入只对事务的一个授权帐户进行计费的方式，使得对具有多个授权者的事务而言，CPU和网络带宽的消耗更少。此外，通过允许事务创建者和签名者选择对哪个授权帐户收费的方式，某个服务方可以选择按照每个事务来支付成本，以换取某种形式的补偿。

共识升级特性(Consensus upgrade feature)

此共识升级特性(Consensus upgrade feature)的目标是，事务的CPU和网络带宽成本账单，仅对事务的第一个授权帐户收取。这使得事务创建者能够处理事务(包括，如有必要，在被计费的帐户授权的事务的开头添加no-op操作)来对所需的帐户进行计费。

将添加一个新的共识升级特性(Consensus upgrade feature)，以进行此共识升级的提议中所描述的更改。为了让这一特性在区块链级别上能够理解，其实际标识符必须表示为64位整数(通常是eosio::name的形式表示)。对于本提议(proposal)，代码名ONLY_BILL_FIRST_AUTHORIZER将用于替换最终实际出现的任何特性标识符。

在transaction_context::init中，在ONLY_BILL_FIRST_AUTHORIZER激活之前，应该要维护插入到transaction_context::bill_to_accounts中的当前嵌套for循环的逻辑。但是，在ONLY_BILL_FIRST_AUTHORIZER的特性激活之后，该逻辑会替换为bill_to_accounts.insert( trx.first_authorizor() )。

注意: 在假定bill_to_accounts是授权事务的唯一帐户集的情况下，push_transaction和/或push_scheduled_transaction可能使用transaction_context::bill_to_accounts检查主观的的actor白名单/黑名单。为了避免使用上面描述的对bill_to_accunts的更改会破坏actor白名单/黑名单的检查，应该为授权事务的惟一帐户集使用单独的(适当命名的)字段, 以执行actor白名单/黑名单。

小结

在这篇文章之中，我们概括了CPU的记账方式和未来所出现的实现方式：DAPP为用户支付CPU/带宽的账单。

并且，介绍了相应的协议更新的细节，链接参见: Issue#6332 -- 升级共识机制，只向事务的第一个授权方收取CPU和网络带宽账单.

今天文章内容偏技术型一些，如果有理解不当之处，还请一起交流探讨。

感谢你的阅读，一五一十，与你一起过寒冬。

EOS42 开创去中心化的未来

EOS42的账号为: eos42freedom。
请为EOS42投票，支持我们继续不停开拓去中心化解决方案的未来。

vote for EOS42