Added new gas mechanics design. #1411
Conversation
|
|
||
| 1. Ethereum must be used for gas operations and bridged from the layer 1 protocol. | ||
| 2. Bridged gas should automatically deposit into the respective addresses. | ||
| 3. Gas-consuming transactions should include a layer 1 cost component for calldata publishing and a layer 2 component that covers execution costs and prevents endless transaction execution. |
There was a problem hiding this comment.
shouldn't the l2 gas component implemnet the eip 1559 as well? To regulate the congestion on the L2?
If batches are 50% full, the l2 base fee increases, etc
There was a problem hiding this comment.
As per the discord conversation, we need to address what it means to have batches full which is currently not a concept. I'll update the design with this.
|
|
||
| ## Gas Cost Display | ||
|
|
||
| Metamask can disassemble the cost components for layer 1 and layer 2 for specific transactions on Optimism, such as token balance approvals. However, it remains unclear how they achieve this as it's neither fully documented nor supports all transactions. |
There was a problem hiding this comment.
how can we find out? Is it based on the chainId?
Maybe we can ask them?
There was a problem hiding this comment.
Bhav will get in touch to get the requirements from their dev team
design/gas/Design_gas.md
Outdated
|
|
||
| ```EthereumDeposited(address receiver, uint256 amount)``` | ||
|
|
||
| The enclave will automatically pick up this message, along with other cross-chain messages, but it will be treated specially. Upon detection, the enclave will increase the balance of the receiver account by the amount specified in the message. |
There was a problem hiding this comment.
No relayer required?
There was a problem hiding this comment.
No. If we require a relayer here, we end up with a chicken and an egg problem where during the initial bootstrap of the network no one has ETH to their address and thus no one can relay the message. This is the only special handling required of us in order to ensure the network can always receive ETH and work with it. Note that those messages will not end up in calling the address and potentially a fallback function if someone is depositing to a smart contract; It's just a stateDB balance increase.
|
|
||
| Before executing a transaction at Obscuro, we must automatically deduct the layer 1 costs for the transaction from the sender's balance. This can be done directly through the stateDB before processing. Ideally, the remaining balance will be refunded, simulating a scenario where the gas limit has been spent. However, potential overruns of execution costs could result in transactions exceeding their set gas limit. | ||
|
|
||
| The best approach would be to both decrease the balance and reduce the transaction's gas limit, assuming that layer 1 prices will be factored into this gas limit, given that the limit is set based on the eth_estimateGas call. |
There was a problem hiding this comment.
this is the key element of the design.
Needs to be elaborated on a bit more
There was a problem hiding this comment.
To be able to reason about this, here a structure I'd suggest.
(You already have this more or less, but it's not very explicit)
I. Briefly cover how gas works in Ethereum, and what problems it solves.
- Requirements
- Briefly summarise the solution, including the UX . (enough to mention the latest eip)
II. The differences for an L2 network.
- The requirements. (revenue for sequencer, congestion, dos, etc)
- The solution adopted by existing L2s. (Briefly)
III. Implementation in Obscuro
- Extra requirements from the other L2s or any other particularities to keep in mind. Do we use the same high level approach as them? Do we make any simplifications in phase 1?
- How does Eth get to the L2?
- How do we prevent dos, and how would we handle congestion?
- How much we charge? Includes the L1 estimation logic
IV. List of decisions we have to make
|
|
||
| The enclave will automatically pick up this message, along with other cross-chain messages, but it will be treated specially. Upon detection, the enclave will increase the balance of the receiver account by the amount specified in the message. This automatic relaying is needed in order to avoid the chicken and egg problem one would have initially where no relayer has any gas to relay the gas deposit messages. It would also ensure relayers who run out of gas can easily recharge without relying on other relayers if we were to use a different bootstrap mechanism. Note that those deposits will not call the fallback function of the address if it is a smart contract and any deposits to such contracts would later on need a message relayed to verify the message as they would normally. | ||
|
|
||
| ## Gas Estimation |
There was a problem hiding this comment.
This isn't 100% correct, and makes things confusing.
Gas estimation is how much processing power it takes to execute the transaction.
Which is used for network congestion throttling.
Since :
- The rollup is not executed
- We're not accounting for rollup compression costs
- Once a tx is minted into a batch it's "soft-final"
- We don't have a finality mechanism that allows users to bump their txs to be rolled up faster
I don't believe there is a point in changing how the gas estimation for a given transaction is done. The binary search tree done in geth should be enough, and I don't see the need to add the L1 calldata cost.
My suggestion would be to leave the gas estimation as geth and move additional payout to the gas price.
There was a problem hiding this comment.
Gas estimation needs to reflect what the user will actually pay.
|
|
||
| ## Gas Expenditure | ||
|
|
||
| Before executing a transaction at Obscuro, we must automatically deduct the layer 1 costs for the transaction from the sender's balance. This can be done directly through the stateDB before processing. Ideally, the remaining balance will be refunded, simulating a scenario where the gas limit has been spent. However, potential overruns of execution costs could result in transactions exceeding their set gas limit. |
There was a problem hiding this comment.
Why deduct the layer 1 costs for the transaction from the sender's balance ?
What if the gas price was bumped for a given transaction? Such that :
gas_price = l2_current_gasPrice + projected_number_txs_in_a_rollup / l1_projected_gasPrice
There was a problem hiding this comment.
This calculation makes it so transactions that spend more gas on the L2 to pay for more L1 fees, while value transfers will pay little in L1 fees. It's not really a competitive solution with other rollups. We'd have some users subsidizing others.
There was a problem hiding this comment.
I might be missing somthing, can you explain a bit more about how is one user subsidizing others?
The lowest possible transaction is a value transfer, which has a fixed L2 gas cos, which will potentially be a fixed L1 Rollup cost, so it should pay a smaller L1 fee than a contract creation or other transactions right ?
There was a problem hiding this comment.
Value transfer should pay less for L1 cost than transactions with encoded calldata, correct. But it should still pay its full L1 gas price. If I do a transaction to say a smart contract that has a fallback (so no calldata) and in this contract you have a for loop er whatever, the calldata is pretty much the same as it would be for a value transfer, yet because L1 fees are factored in the gas price each iteration of the loop would be subsidizing L1 costs that are completely irrelevant to the computation.
There was a problem hiding this comment.
No, because the gas limit of that said transaction is higher than the value transfer.
So let's say there's a Quirky Tx that does a call on a contract which does a for loop (spins a while).
gasPrice: ( L2Gasprice + L1Gasprice)
Tx A: Value transfer - tx rollup size 10 - gas limit 21 000 - Final gas cost 21 000 * gasPrice
Tx B: Deploy Contract - tx rollup size 3000 - gas limit 120 000 - Final gas cost 120 000 * gasPrice
Tx C: Quirky Tx - tx rollup size 40 - gas limit 500 000 - Final gas cost 500 000 * gasPrice
The rollup size does not matter for the gas price nor for the final gas paid by the user.
Saying that tx A and C are subsidizing Tx B doesn't make a lot of sense because they are paying network congestion on the L2.
That being said, if you want to figure out a way that you can adjust the L1GasPrice component based on the potential tx rollup size, I think that's a good idea, but perhaps not needed for a first iteration imo.
| The revenue generation mechanism for Obscuro hinges on the collection of gas fees. Notably, as Obscuro operates as a layer 2 protocol, the cost of operations surpasses that of layer 1, since it has to cover layer 1 gas costs in addition to its operational expenses. Unlike layer 1 miners, who only shoulder operational costs, there's no expenditure prerequisite for block publication on Obscuro except for the static cost of stake. | ||
|
|
||
| The gas mechanics of a protocol normally have the following functions: | ||
| 1) Revenue for node operators. |
There was a problem hiding this comment.
- Revenue for node operators.
Has not been discussed (just in case it was missed :) )
Co-authored-by: Pedro Gomes <[email protected]>
|
|
||
| ## Gas Expenditure | ||
|
|
||
| Before executing a transaction at Obscuro, we must automatically deduct the layer 1 costs for the transaction from the sender's balance. This can be done directly through the stateDB before processing. Ideally, the remaining balance will be refunded, simulating a scenario where the gas limit has been spent. However, potential overruns of execution costs could result in transactions exceeding their set gas limit. |
There was a problem hiding this comment.
Let's say we have a mechanism to estimate the L1 eth gas cost.
The following happens:
- Obscuro user submits TX1 (size=1kb) and the L2 execution cost is 1Million gas.
- Tx1 enters the enclave which will do the following:
a. Check that the user has enough balance to pay for size(Tx1) * estimated_publishing cost. If yes, deduct that amount. Also, record this amount, in case it needs to be payed back if the tx is not included.
b. Check the user has the minium gas required for Obscuro. Deduct that
c. Start executing, until the tx finishes, or the user runs out of gas.
There was a problem hiding this comment.
This is the initial approach I was thinking about as it is most intuitive to implement, but the problem with it is that transactions will result in spending more ETH than authorised when signed. When a user signs there is an agreement over the total gas cost that can be deducted from the balance + the total value being sent in the transaction; Deducting externally of the gas will result in higher than authorized "total" gas spend.
There was a problem hiding this comment.
but why do you have to deduct more than authorised?
Obscuro user submits TX1 (size=1kb) and the L2 execution cost is 1Million gas.
Tx1 enters the enclave which will do the following:
a. Check that the user has enough balance to pay for size(Tx1) * estimated_publishing cost. Also if the tx is authorised to spend that. If yes, deduct that amount. Also, record this amount, in case it needs to be payed back if the tx is not included.
b. Check the user has the minium gas required for Obscuro. Deduct that
c. Start executing, until the tx finishes, or the user runs out of gas.
|
@StefanIliev545 , should we merge this now? |
|
@StefanIliev545 , ping |
I'll upgrade it with the outcome of the dev |
Why this change is needed
We need a gas mechanic in order to compensate the sequencer for publishing L1 rollups and generate revenue.
What changes were made as part of this PR
Introduced initial version of the gas design document.
PR checks pre-merging
Please indicate below by ticking the checkbox that you have read and performed the required
PR checks