-
Notifications
You must be signed in to change notification settings - Fork 77
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
support eth transfer to proposers with code #251
support eth transfer to proposers with code #251
Conversation
possibly, up to some gas limit, as otherwise a proposer could try to grief this builder implementation and if we do have some fixed gas limit, it starts to look suspiciously like option 2, so not sure the extra complexity is worth 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.
this is amazing, great work!
left some suggestions
mev-build-rs/src/payload/builder.rs
Outdated
|
||
let proposer_fee_recipient_account = db.load_cache_account(config.proposer_fee_recipient)?; | ||
let is_empty_code_hash = | ||
proposer_fee_recipient_account.account_info().unwrap_or_default().is_empty_code_hash(); |
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 is very minor, but I would guess it is cheaper to unwrap at the end
as written, it would construct a full AccountInfo::default()
instance, and then call is_empty_code_hash
if we do this, it would skip the instantiation if the account is missing
proposer_fee_recipient_account.account_info().unwrap_or_default().is_empty_code_hash(); | |
proposer_fee_recipient_account.account_info().map(|account| account.is_empty_code_hash()).unwrap_or_default(); |
mev-build-rs/src/payload/builder.rs
Outdated
|
||
// If the proposer (fee recipient) has associated code, we hardcode 250_000 for gas payment. | ||
// If it is a regular EOA, we send the base gas 21_000. | ||
let gas_limit = if is_empty_code_hash { BASE_TX_GAS_LIMIT } else { 250_000 }; |
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.
would suggest putting another constant next to BASE_TX_GAS_LIMIT
above
let gas_limit = if is_empty_code_hash { BASE_TX_GAS_LIMIT } else { 250_000 }; | |
const PAYMENT_TO_CONTRACT_GAS_LIMIT: u64 = 250_000; | |
// ... | |
let gas_limit = if is_empty_code_hash { BASE_TX_GAS_LIMIT } else { PAYMENT_TO_CONTRACT_GAS_LIMIT }; |
mev-build-rs/src/payload/builder.rs
Outdated
// If the proposer (fee recipient) has associated code, we hardcode 250_000 for gas payment. | ||
// If it is a regular EOA, we send the base gas 21_000. |
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.
and to reduce future churn, we can be more abstract in the comment, something like:
// If the proposer (fee recipient) has associated code, we hardcode 250_000 for gas payment. | |
// If it is a regular EOA, we send the base gas 21_000. | |
// Use a fixed gas limit for the payment transaction reflecting the recipient's status as smart contract or EOA. |
here's a lido payment: https://etherscan.io/tx/0x252940cec2d0f1d0340a5438f7abcf77f926c26931e5a53e03c10ca3aecd7981 only 22,111 gas stakefish: rocket pool smoothing pool: so maybe 250k is much too high.... perhaps we just go with 100k 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.
amazing thank you!
implements 248
For the near future would it be better to go with option 3? (simulate the call and based on that use the appropriate gas)