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

Allow alternative methods of proposer payments in validation api. #78

Closed
wants to merge 1 commit into from

Conversation

dvush
Copy link
Contributor

@dvush dvush commented Jun 20, 2023

📝 Summary

This will allow validation API to accept blocks where:

  • proposer payment is plain transfer to the fee recipient
  • proposer payment is internal payment to the fee recipient made through the smart contract
  • fee recipient is set to coinbase and accepts payment directly

The way we calculate profit is:

  • check balance difference of the fee recipient after each tx in the block
  • if its positive we count it toward total block profit
  • if its negative we ignore it, but if fee recipient is also a coinbase we add tip payed by the tx to profit
  • when profit is calculated we make sure that claimed profit is equal or bigger than calculated profit

Some features of this method:

  • withdrawals from the fee recipient don't decrease profit of the bid
  • deposits to the fee recipient address can be claimed as a profit
  • builders that ignore withdrawals/deposits of the fee recipients and just calculate balance diff of it before and after block will work.

@dvush dvush requested review from Ruteri and avalonche June 20, 2023 13:58
@Wazzymandias Wazzymandias self-requested a review June 22, 2023 17:04
Copy link
Collaborator

@metachris metachris left a comment

Choose a reason for hiding this comment

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

would love a review from @Ruteri too

@@ -114,6 +114,10 @@ $ geth --help

--builder.validation_blacklist value
Path to file containing blacklisted addresses, json-encoded list of strings

--builder.validation_force_last_tx_payment (default: false)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should the default behaviour be to enforce the direct transfer?
That would make the new change opt-in which I think is going to be nicer.

}
}
}
if feeRecipientProfit.Cmp(expectedProfit) >= 0 {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm, maybe == 0 would help us notice bugs faster

Copy link
Contributor Author

Choose a reason for hiding this comment

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

= here is so that builders can underestimate their profits. e.g. if you don't count payments to the proposals and withdrawals correctly.

@dvush
Copy link
Contributor Author

dvush commented Aug 7, 2023

closed in favor of #93

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

Successfully merging this pull request may close these issues.

4 participants