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

Update EIP-2537: double each discount table value in the MSM gas cost model #8910

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jwasinger
Copy link
Contributor

@jwasinger jwasinger commented Sep 26, 2024

Based on discussion during ACDE, we are repricing the bls MSM precompiles to be twice as expensive.

@github-actions github-actions bot added c-update Modifies an existing proposal s-review This EIP is in Review t-core labels Sep 26, 2024
@eth-bot
Copy link
Collaborator

eth-bot commented Sep 26, 2024

File EIPS/eip-2537.md

Requires 1 more reviewers from @asanso, @ineffectualproperty, @ralexstokes, @shamatar

@eth-bot eth-bot added the a-review Waiting on author to review label Sep 26, 2024
@eth-bot eth-bot changed the title eip2537: double each discount table value in the MSM gas cost model Update EIP-2537: double each discount table value in the MSM gas cost model Sep 26, 2024
@chfast
Copy link
Member

chfast commented Sep 26, 2024

Based on discussion during ACDE, we are repricing the bls MSM precompiles to be twice as expensive.

Maybe you did discusse it but it didn't make any sense now: up to 7 inputs the cost is higher than computing the multiplication one by one.

@jwasinger
Copy link
Contributor Author

Maybe you did discusse it but it didn't make any sense now: up to 7 inputs the cost is higher than computing the multiplication one by one.

The rationale from my side is: doubling the entries in the discount table is the simplest repricing we can do such that the pricing of g1 msm is at least that of the ecrecover precompile in the worst case (on Geth, concurrency disabled for MSM, benchmarked across several machines - x86/arm).

I need to do some further research to come up with a justification for the reason that MSM is higher cost than naive method (muls) up to a threshold. From what I know right now, there is some setup overhead with MSM that makes it perform worse than muls for small input sizes.

For example, here is the ratio of the runtime for the naive method vs the runtime of gnark's g1 msm on my M2 Macbook Pro:

1 pairs - 2.451
2 pairs - 1.535
3 pairs - 1.239
4 pairs - 1.07
5 pairs - 0.996
6 pairs - 0.942
7 pairs - 0.878

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-review Waiting on author to review c-update Modifies an existing proposal s-review This EIP is in Review t-core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants