-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: BeginTx and EndTx support taiko's 1559 #18
feat: BeginTx and EndTx support taiko's 1559 #18
Conversation
johntaiko
commented
Jul 31, 2023
•
edited
Loading
edited
- bus_mapping && TxTable support eip-1559
- BeginTx support taiko's eip-1559
- Add test cases
- EndTx suppports taiko's eip-1559
- Add test cases
75dc724
to
07b6c22
Compare
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.
Quickly looked at it, overall looks good.
Because some balance updates are now done conditionally, you will probably have some issues with the rw counter. So correctly updating the rw counter will be necessary in the state transition, or alternatively you could keep all the balance update but just use 0
as the delta, but I remember the code being smart enough to then skip the update so the rw counter may still not need incrementing.
If you have problems, let me know because for the invalid transactions similar code for this was necessary: taikoxyz#115
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.
Looks good! Added some questions/minor suggestions.
I do have some questions about taiko_test_util
and taiko_mock
. I remember on the call you said there were troubles otherwise, but is full duplication of this code required to fix the problem or will it be possible with some extra effort to just modify the code instead? I haven't looked into that code in detail so I'm not sure what the problem is. Could you explain a bit more?
I also haven't run the test yet because make test-all
does not run without changes, I think just some small issues that I haven't tried fixing myself yet: taiko_mock
is marked as optional (not sure why) and there's still an error in the taiko super circuit benchmark.
|
||
// panic!( | ||
// "RWTable Account field {:?} lookup to non-existing account rwc: {}, op: {:?}", | ||
// rw, self.block_ctx.rwc.0, op | ||
// ); |
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.
Just marking it so it's not forgotten to be uncommented
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.
Now, we add zero value to an empty coinbase with anchor transaction. So maybe I need to add a flag to distinguish between anchor and others
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.
I believe this is still something that need to be fixed in general, also on the main PSE branch, so okay for now.
pub const N_BYTE_LOOKUPS: usize = 24; | ||
pub const N_BYTE_LOOKUPS: usize = 28; |
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.
Instead maybe MAX_STEP_HEIGHT
can be increased so other opcodes don't get more expensive, but not important for now.
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.
Where this 4 more lookups come from?
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.
More words are allocated in the end_tx step, so more data needs to be stored in these steps. So either the circuit can be made wider with more capacity for byte values (what this change does) or we just allow the step to use more rows (currently limited by MAX_STEP_HEIGHT
) to store all the necessary data.
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, as we prefer height over width, giving more space to MAX_STEP_HEIGHT makes more sense, is it?
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.
Generally yes. And in this specific case especially true because increasing the max height just allows the end_tx to use more rows, which doesn't impact the cost of the other opcodes. Making the circuit wider or increasing the number of lookups also impacts the cost of the other opcodes because that cost is for each row, regardless of what opcode is being processed.
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.
Where this 4 more lookups come from?
I test the number one by one, because I need more cells in like: Word<F>(RandomLinearCombination)
- tx_gas_tip_cap, tx_gas_fee_cap, base_fee_plus_tip = 3* 32 cells
- mul_base_fee_by_gas_used = 32 + 8 cells
- treasury updatebalance = 32 * 2 cells
- and two AddWords = 2 cells
total ≈ 200+
our MAX_STEP_HEIGHT equals to 21, so we need more 10 columns, but N_BYTE_LOOKUPS has some remaining
so I test to increase columns one by one
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.
Yeah, I think it makes sense to increase the MAX_STEP_HEIGHT
let mul_base_fee_by_gas_used = | ||
MulWordByU64Gadget::construct(cb, base_fee.clone(), gas_used.clone()); | ||
|
||
// check gas_price == min(base_fee + gas_tip_cap, gas_fee_cap) |
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.
Okay I think this is correct but it took me a while to figure that out! Because on https://eips.ethereum.org/EIPS/eip-1559: we have the following:
# priority fee is capped because the base fee is filled first
priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)
# signer pays both the priority fee and the base fee
effective_gas_price = priority_fee_per_gas + block.base_fee_per_gas
So this is a bit different than what is written here, but if the base_fee
is subtracted from the formula than we do get to the same formula as in the EIP:
tx_gas_price = effective_tip + base_fee ->
effective_tip = tx_gas_price - base_fee
tx_gas_price == min(tx.gas_tip_cap + base_fee, tx.gas_fee_cap) -> (subtract base_fee everywhere)
tx_gas_price - base_fee == min(tx.gas_tip_cap, tx.gas_fee_cap - base_fee) ->
effective_tip = min(tx.gas_tip_cap, tx.gas_fee_cap - base_fee)
So checks out! But I'm wondering why you didn't simply use the equation from the EIP here? tx_gas_price
and effective_tip
are already linked in sub_gas_price_by_base_fee
so the original equation should also be okay I think.
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.
Yeah, I found both of these two approaches are used in taiko-geth:
- https://github.com/taikoxyz/taiko-geth/blob/73c5b3e7d77a02a1d0e4afb2b29210bbcc9ffb4f/accounts/abi/bind/backends/simulated.go#L636
- https://github.com/taikoxyz/taiko-geth/blob/73c5b3e7d77a02a1d0e4afb2b29210bbcc9ffb4f/core/state_transition.go#L396
So, maybe it's good to align with eip
pub const N_BYTE_LOOKUPS: usize = 24; | ||
pub const N_BYTE_LOOKUPS: usize = 28; |
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.
Where this 4 more lookups come from?
Co-authored-by: Brecht Devos <[email protected]>
LGTM! I think the shanghai upgrade alignment can be a new PR for new gas config and PUSH0, which could be after test with real testnet data. |
Co-authored-by: Brecht Devos <[email protected]>
Co-authored-by: Brecht Devos <[email protected]>
Add TODOs |
) -> Result<(), Error> { | ||
let (found, sender_account) = self.sdb.get_account(&sender); | ||
if !found { | ||
return Err(Error::AccountNotFound(sender)); | ||
} | ||
let mut sender_balance_prev = sender_account.balance; | ||
if !is_anchor_tx { |
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.
We use zero value fee instead of a flag
Changes look good!
Would still like to know some more about the points above I also don't really know how to run the tests now because it seems |
Yeah, lots of test cases broke after added anchor transaction. And I think it's low priority to fix these tests. I also commit a new PR in our Taiko's repository, because the rlp-circuit will not be added in next testnet. Please see taikoxyz#136 |