Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus upgrade to only bill CPU and network bandwidth to first authorizer of a transaction #6332

Closed
arhag opened this issue Nov 16, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@arhag
Copy link
Contributor

commented Nov 16, 2018

Background

Currently, the set of all unique authorizing accounts of a transaction are each billed for the total CPU and network bandwidth consumed by the transaction. From the perspective of protecting the network from abuse, the CPU and network bandwidth only needs to be billed once to some account.

By only billing one of the authorizing accounts of the transaction, less CPU and network bandwidth is expended for transactions with multiple authorizers. Furthermore, by allowing the transaction creator and signers choice over which of the authorizing accounts are billed, it becomes possible for a service to elect to pay for the costs of a transaction on a per-transaction basis in exchange for some form of compensation.

Consensus upgrade feature

The goal of this consensus upgrade feature is to only bill the first authorizing account of a transaction for the CPU and network bandwidth costs of the transaction. This enables transaction creators to craft the transaction (including, if necessary, adding a no-op action to the beginning of the transaction authorized by the account to be billed) to bill the desired account.

A new consensus protocol upgrade feature will be added to trigger the changes described in this consensus upgrade proposal. The actual digest for the feature understood at the blockchain level is to be determined. For the purposes of this proposal the codename ONLY_BILL_FIRST_AUTHORIZER will be use to stand-in for whatever the feature identifier will actually end up being.

In transaction_context::init, prior to ONLY_BILL_FIRST_AUTHORIZER activation, the current nested for loop logic that inserts into transaction_context::bill_to_accounts should be maintained. However, after ONLY_BILL_FIRST_AUTHORIZER activation, that logic should instead be replaced simply with bill_to_accounts.insert( trx.first_authorizor() ).

Note: push_transaction and/or push_scheduled_transaction may be using transaction_context::bill_to_accounts for the purposes of checking the subjective actor whitelist/blacklist under the assumption that bill_to_accounts is the set of unique accounts authorizing the transaction. To avoid breaking the actor whitelist/blacklist checks with the changes to bill_to_accounts described above, a separate (properly named) field for the set of unique accounts authorizing the transaction should be used for actor whitelist/blacklist enforcement.

@arhag arhag added the HARDFORK label Nov 16, 2018

@conr2d

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2018

I think this feature is very useful, when DApp provider allows users to make some transactions (related to DApp directly) using provider's CPU and NET bandwidth.

@shuke0327

This comment has been minimized.

Copy link

commented Dec 3, 2018

an awesome feature. waiting for your implementations. and I am wondering when will this feature will be implemented?

@arhag

This comment has been minimized.

Copy link
Contributor Author

commented Dec 7, 2018

This issue depends on #6429. It will also be setup by default to be a protocol feature requiring pre-activation, thus it also depends on #6431.

@arhag

This comment has been minimized.

Copy link
Contributor Author

commented Apr 10, 2019

Resolved by #7089.

@arhag arhag closed this Apr 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.