-
Notifications
You must be signed in to change notification settings - Fork 856
Conversation
77305d1
to
d3784a2
Compare
354503c
to
3e53d37
Compare
3e53d37
to
c545e14
Compare
7dae6a7
to
bbb3067
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.
LGTM. Nice refactor! Only have two minor suggestions
@@ -320,7 +329,12 @@ impl<C: CircuitsParams> CircuitInputBuilder<C> { | |||
// accumulates gas across all txs in the block | |||
for (tx_index, tx) in eth_block.transactions.iter().enumerate() { | |||
let geth_trace = &geth_traces[tx_index]; | |||
self.handle_tx(tx, geth_trace, tx_index + 1 == eth_block.transactions.len())?; | |||
self.handle_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.
How do you think we have a var, let next_tx_index = tx_index + 1
and replace the next two tx_index + 1
?
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 added a new variable and a comment.
As I understand it, tx_index + 1
is not the "next" tx id. The tx_index + 1
is there because the tx id starts from 1.
let gas_fee = tx.gas_price * tx.gas; | ||
let tx_id = tx.id; | ||
let tx = &tx.tx; | ||
let gas_fee = tx.gas_price * tx.gas_limit.as_u64(); |
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.
suggest to use tx.gas()
as you did in end_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.
Fixed in d33f401
I add a convenient method for gas that returns simple u64
.
The reason not to change the gas_limit field from U64
to u64
is that the gas_limit
field must use U64
to be appropriately serialized for JSON RPC to consume.
self.tx_callee_address | ||
.assign_h160(region, offset, tx.callee_address)?; | ||
self.call_callee_address.assign_h160( | ||
region, | ||
offset, | ||
if tx.is_create { | ||
get_contract_address(tx.caller_address, tx.nonce) | ||
} else { | ||
tx.callee_address | ||
}, | ||
)?; | ||
.assign_h160(region, offset, tx.to_or_contract_addr())?; | ||
self.call_callee_address | ||
.assign_h160(region, offset, tx.to_or_contract_addr())?; |
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.
Wait, I realized I confused tx_callee_address and call_callee_address.
I need to figure out what's the difference here.
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 checked the deleted zkevm-circuits/src/witness/tx.rs
and confirmed that tx_callee_address
and call_callee_address
are currently assigned with the same value.
So changes are not required here. We can optimize the constraints in future PR.
let gas_fee = tx.gas_price * tx.gas; | ||
let tx_id = tx.id; | ||
let tx = &tx.tx; | ||
let gas_fee = tx.gas_price * tx.gas_limit.as_u64(); |
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.
Fixed in d33f401
I add a convenient method for gas that returns simple u64
.
The reason not to change the gas_limit field from U64
to u64
is that the gas_limit
field must use U64
to be appropriately serialized for JSON RPC to consume.
@@ -320,7 +329,12 @@ impl<C: CircuitsParams> CircuitInputBuilder<C> { | |||
// accumulates gas across all txs in the block | |||
for (tx_index, tx) in eth_block.transactions.iter().enumerate() { | |||
let geth_trace = &geth_traces[tx_index]; | |||
self.handle_tx(tx, geth_trace, tx_index + 1 == eth_block.transactions.len())?; | |||
self.handle_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.
I added a new variable and a comment.
As I understand it, tx_index + 1
is not the "next" tx id. The tx_index + 1
is there because the tx id starts from 1.
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.
Nice job! Fantastic to remove one more technical burden <3
I would like to propose a minor change to make coding style looks more comfortable.
impl std::ops::Deref for Transaction {
type Target = geth_types::Transaction;
fn deref(&self) -> &Self::Target {
&self.tx
}
}
By dereference, It will make all access to inner tx like itself, so we save save one nested access!
So
tx.tx.xxxx
becometx.xxx
tx.tx.clone()
become*tx.clone()
@hero78119 |
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.
LGTM! 🎆 :) thanks for the quick fix
pub fn is_create(&self) -> bool { | ||
self.calls[0].is_create() | ||
} |
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 method is causing the test to fail.
For padding tx in tx circuit, the calls
vector is empty. So that querying is_create would panic.
We use the is_create
property in witness::Transaction before this PR, which relies on the is_create
method of geth_types::Transaction shown below. The below method is more robust because it doesn't panic.
We now remove the circuit_input_builder::Transaction's is_create
. Any tx.is_create()
call will propagate to geth_types::Transaction's is_create
, due to the deref effect. It would be the same method at work before this PR.
pub fn is_create(&self) -> bool {
self.to.is_none()
}
Description
We remove the witness tx struct.
We can wait for the lo-hi refactor ready then for this PR.
Issue Link
Part of #1391
Type of change
New feature (non-breaking change which adds functionality)
Contents