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

Ask a question about the size limit of contract #20803

Closed
james-ray opened this issue Mar 24, 2020 · 2 comments
Closed

Ask a question about the size limit of contract #20803

james-ray opened this issue Mar 24, 2020 · 2 comments

Comments

@james-ray
Copy link

james-ray commented Mar 24, 2020

In EIP170, the max size of contract has been set to 24768 bytes. Recently I am doing work about Zksnarks, and using zokrates to generate the verifier contract, though a very simple hash verifier contract does not exceed the limit, I am having trouble understanding the thoughts in this discussion:
(deleted)

From my understanding, every OpCode in the EVM has its gas cost, and user has to pay more if the call consumes more. Why we need to constrain the limit of the contract?

when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity

Why constant amount of gas? Why O(n) cost reading the code from disk? And what causes adding O(n) data to the merkle proof? Is it logging or storing something? but logging and storing are expensive.

@james-ray
Copy link
Author

james-ray commented Mar 24, 2020

Though this(deleted)
makes it clearer, I still don't understand what the "adding O(n) data to the merkle proof" is from?
n here means the code size, right? Why the added data in merkle proof has something to do with the code size?

@james-ray
Copy link
Author

james-ray commented Mar 24, 2020

Oh, I see, is this means: the more codes, the more complexity, thus more variables need to be stored, thus it is proportional with the code size

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

No branches or pull requests

1 participant