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

WASM execution without prior deployment #9379

Open
Tracked by #9377
jakmeier opened this issue Aug 2, 2023 · 4 comments
Open
Tracked by #9377

WASM execution without prior deployment #9379

jakmeier opened this issue Aug 2, 2023 · 4 comments
Labels
A-contract-runtime Area: contract compilation and execution, virtual machines, etc T-contract-runtime Team: issues relevant to the contract runtime team

Comments

@jakmeier
Copy link
Contributor

jakmeier commented Aug 2, 2023

A truly stateless validator would not have access to pre-deployed contract code.
If we can't rely on that optimization, how much slower would WASM execution be and what can we do about it?

Luckily, we have already spent a lot of time optimizing compilation and are proud of our linear in time and space complexity WASM validation & compilation passes. So maybe it's actually okay to add this extra latency?

According to our gas costs today, compilation takes ~0.3ms + ~6.4ms per 100kB on a chunk producer.

  • For SWEAT (204kB) it would be ~13.356ms
  • For SocialDB (392kB) it would be ~25.388ms
  • For Aurora (1MB) it would be ~64.3ms

Adding this extra delay for every function call on the stateless validator is unfortunate. But something we can potentially overcome.

Also note that due to everything being in-memory on the stateless validator, all storage related costs should be much faster. So for storage access heavy receipts, chunks would be produced much slower than stateless validators can validate them if they are running on comparable CPUs.

Other possible solutions to get around the compilation include:

  • Store x86 on-chain instead of WASM and include this in the witness. (downside: increases witness size)
  • Interpret WASM instead of compiling it.
@jakmeier jakmeier added A-contract-runtime Area: contract compilation and execution, virtual machines, etc T-contract-runtime Team: issues relevant to the contract runtime team labels Aug 2, 2023
@robin-near
Copy link
Contributor

Validators can locally cache compiled contracts. Hopefully this will resolve most cases?

@jakmeier
Copy link
Contributor Author

jakmeier commented Aug 3, 2023

Yeah that's right, for the foreseeable future even a stateless validator should have enough disk space to cache the executables. There will be an ugly drop in performance anytime we have a protocol upgrade that invalidates old compilation results.
But I would expect it to be fine anyway. Or at least I think we have bigger problems to worry about first. :P

@jakmeier
Copy link
Contributor Author

jakmeier commented Aug 3, 2023

near/NEPs#481 (comment) contains some info about interpreter speed if we ever want to go down that route anyway

@nagisa
Copy link
Collaborator

nagisa commented Sep 1, 2023

Just to add an alternative which is not written down: ZK validation does not care as much about execution time as there's only a single (or a couple) machines actually doing the actual execution and giving a significant time for the validators to compile and execute the contracts only serves to increase latency of individual transactions, rather than throughput of the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-contract-runtime Area: contract compilation and execution, virtual machines, etc T-contract-runtime Team: issues relevant to the contract runtime team
Projects
None yet
Development

No branches or pull requests

3 participants