-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add EIP: Contract Secured Revenue on an EVM based L2 #6969
Conversation
✅ All reviewers have approved. |
If @zscole doesn't have a specification ready, I recommend closing this PR and waiting to open it until it is ready. EIP number sniping and gaming is not allowed, I am manually assigning 6968, in case you want to proceed with this PR. EIP editors can overrule. Precedent for manually assigning a number for an apparent number lunge when a draft EIP/ERC isn't ready was for an ERC I authored: #4888 (review) |
EIPS/eip-6969.md
Outdated
title: Contract Secured Revenue on an EVM based L2 | ||
status: Draft | ||
type: Core | ||
discussions-to: https://t.me/+w1EKtAx824VlZDJh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please create a discussion thread on https://ethereum-magicians.org/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rename the discussion thread to the assigned EIP number EIP6968
preliminary technical specification has been added in collaboration with @lightclient. |
Update eip-6969.md
EIPS/eip-6969.md
Outdated
@@ -0,0 +1,169 @@ | |||
--- | |||
eip: 6969 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR was opened to reserve the meme number. The first commit (3a485ae) is just a preamble and the EIP template. The EIP remained mostly empty until May 6th (6c7f200).
We do our best to discourage number sniping, and @abcoathup has volunteered to reassign such numbers as they arise.
To be perfectly clear, if this proposal had content at the time it was pull requested, we wouldn't be reassigning this number.
eip: 6969 | |
eip: 6968 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change has been submitted. Can we get this merged now? Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The automatic validator is still flagging some issues that need to be fixed.
https://github.com/ethereum/EIPs/pull/6969/files
For example:
- discussions-to should point to the Ethereum magicians thread
- add your GitHub handle as an author
- There are also a number of "TODO Zak"
EIPS/eip-6969.md
Outdated
|
||
In order to fairly distribute the fee revenue, a new transaction-wide gas tracker is defined. | ||
|
||
When executing a block, maintain a mapping `gas_used_by_address` of `address` to `uint64`. This will track the amount of gas used by each address. For every EVM instruction that does not instantiate a new execution frame (e.g. `CALL`, `CALLCODE`, `DELEGATECALL`, `STATICCALL`, `CREATE`, and `CREATE2`), add the cost of the instruction to the address' current sum in the mapping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lightclient
Couple of question for this.
What does it mean "instruction that does not instantiate a new execution frame"?
I checked the https://github.com/ethereum/go-ethereum/blob/master/core/vm/instructions.go but couldn't catch that meaning.
Can you share the actual code reference about "instantiate a new execution frame"?
Thanks in advance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a standard call stack frame. When an external call is made, that pushes a new frame. A frame contains the currently executing contract's context like stack and memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So examples in the doc (CALL, CALLCODE, DELEGATECALL, STATICCALL, CREATE, and CREATE2
) are instructions that instantiate a new execution frame right?
EIPS/eip-6969.md
Outdated
|
||
Contract Secured Revenue (CSR) allows smart contract developers to claim a percentage of all transaction fees paid by users when interacting with their smart contracts. | ||
|
||
This EIP proposes the introduction of CSR on EVM-based L2s. If adopted, this would allow smart contract developers who deploy on L2s to access a potentially lucrative revenue stream and/or fund public goods. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You want to write as if the proposal has been adopted, because once it goes to final, it won't make sense to say "if adopted".
EIPS/eip-6969.md
Outdated
1. It could [become just a race to the bottom devolving into rebates for users](https://twitter.com/trent_vanepps/status/1623361559983452160) | ||
2. It has [yet to be proven that it can sustainable attract/retain/comp devs](https://twitter.com/trent_vanepps/status/1653086558633836564) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll have to remove external links, except for the exceptions defined in EIP-1.
EIPS/eip-6969.md
Outdated
Constructing the revenue recipient mapping ephemerally during each transaction appears inefficient on the surface. This value is expected to be relatively static and even if it did need to change, the change could be facilitated by the recipient contract. | ||
|
||
Unfortunately such a change is much more invasive for the EVM. The recipient value would need to be stored somewhere. This would require a modification to the account structure in the state trie. Also, the recipient value would need to be set at some point. This would necessitate either a modification to the `CREATE*` opcodes or a new opcode, similar to `SETREVENUERECIPIENT`, that would be called by initcode to "initialize" the recipient value. | ||
## Rationale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have two rationale sections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These change requests have been addressed. Thank you.
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
fixes typo
Update eip-6968.md
The commit 31ccb07 (as a parent of 368b00e) contains errors. |
fixed linting errors in md
status: Draft | ||
type: Standards Track | ||
category: Core | ||
created: 2023-05-01 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created: 2023-05-01 | |
created: 2023-05-01 | |
requires: 150 |
|
||
Additionally: | ||
|
||
- If the address does not exist in the mapping, it's total gas used is `0`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If the address does not exist in the mapping, it's total gas used is `0`. | |
- If the address does not exist in the mapping, its total gas used is `0`. |
All the outstanding issues have been addressed. Can we get this merged? @SamWilsn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are still two outstanding comments, but they're minor enough to fix later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Reviewers Have Approved; Performing Automatic Merge...
Contract Secured Revenue (CSR) allows smart contract developers to claim a percentage of all transaction fees paid by users when interacting with their smart contracts.
This EIP proposes the introduction of CSR on EVM-based L2s. If adopted, this would allow smart contract developers who deploy on L2s to access a potentially lucrative revenue stream and/or fund public goods.
This is a draft PR with a draft specification. Please see the submitted .md file and also checkout the discussion at https://ethereum-magicians.org/t/eip-6969-generalized-csr-protocol/14178