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

feat: BeginTx and EndTx support taiko's 1559 #18

Closed

Conversation

johntaiko
Copy link
Collaborator

@johntaiko johntaiko commented Jul 31, 2023

  • bus_mapping && TxTable support eip-1559
  • BeginTx support taiko's eip-1559
    • Add test cases
  • EndTx suppports taiko's eip-1559
    • Add test cases

@johntaiko johntaiko force-pushed the feat/evm_circuit_1559 branch from 75dc724 to 07b6c22 Compare July 31, 2023 15:01
Copy link

@Brechtpd Brechtpd left a 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

bus-mapping/src/evm/opcodes/begin_end_tx.rs Outdated Show resolved Hide resolved
Copy link

@Brechtpd Brechtpd left a 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.

zkevm-circuits/src/evm_circuit/execution/begin_tx.rs Outdated Show resolved Hide resolved
zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
Comment on lines +312 to +316

// panic!(
// "RWTable Account field {:?} lookup to non-existing account rwc: {}, op: {:?}",
// rw, self.block_ctx.rwc.0, op
// );
Copy link

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

Copy link
Collaborator Author

@johntaiko johntaiko Aug 10, 2023

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

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;
Copy link

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.

Copy link
Owner

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?

Copy link

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.

Copy link
Owner

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?

Copy link

@Brechtpd Brechtpd Aug 9, 2023

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.

Copy link
Collaborator Author

@johntaiko johntaiko Aug 10, 2023

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)

  1. tx_gas_tip_cap, tx_gas_fee_cap, base_fee_plus_tip = 3* 32 cells
  2. mul_base_fee_by_gas_used = 32 + 8 cells
  3. treasury updatebalance = 32 * 2 cells
  4. 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

Copy link
Collaborator Author

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

zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
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)
Copy link

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
external-tracer/src/lib.rs Show resolved Hide resolved
taiko-mock/src/anchor.rs Outdated Show resolved Hide resolved
zkevm-circuits/src/evm_circuit/execution/end_tx.rs Outdated Show resolved Hide resolved
pub const N_BYTE_LOOKUPS: usize = 24;
pub const N_BYTE_LOOKUPS: usize = 28;
Copy link
Owner

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?

@smtmfft
Copy link
Owner

smtmfft commented Aug 10, 2023

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.

@johntaiko
Copy link
Collaborator Author

@smtmfft @Brechtpd All comments are fixed, please review again

@johntaiko
Copy link
Collaborator Author

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.

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 {
Copy link
Collaborator Author

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

@Brechtpd
Copy link

Changes look good!

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.

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 taiko_mock is required to do that, but I only see it used in begin_tx and most of the tests fail there for me as well so I think I'm doing something wrong.

@johntaiko
Copy link
Collaborator Author

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 taiko_mock is required to do that, but I only see it used in begin_tx and most of the tests fail there for me as well so I think I'm doing something wrong.

Yeah, lots of test cases broke after added anchor transaction. And I think it's low priority to fix these tests.
I will commit another PR for this case after the aggregation integrating

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

@johntaiko johntaiko closed this Aug 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

zkevm circuit 1559 support
3 participants