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

feat: Save sierra program in the runtime #1381

Closed
LucasLvy opened this issue Jan 18, 2024 · 4 comments
Closed

feat: Save sierra program in the runtime #1381

LucasLvy opened this issue Jan 18, 2024 · 4 comments
Assignees
Labels
backlog Ready to be picked enhancement New feature or request

Comments

@LucasLvy
Copy link
Contributor

To run the os we need the sierra contract class, it's currently not saved anywhere, save it somewhere that is accessible for the commitment state diff service.

@LucasLvy LucasLvy added the enhancement New feature or request label Jan 18, 2024
@tdelabro
Copy link
Collaborator

I think it should be in the client, not the runtime.
The runtime is supposed to receive the sierra contract and the sierra hash. Check the hash matches the sierra contract, compile the sierra to casm, check the casm hash. But it does not need to be stored for anything else in the runtime.
So, the client can store the contract. It should probably hash it in order to make sure the sierra_hash contained in the tx is the good one.

@tdelabro
Copy link
Collaborator

In client, add_declare_transaction, for BroadcastedDeclareTransactionV2 only

  • hash the contract_class, make sure it it's hash matches the content of the class_hash field in the tx
  • store a mapping from class_hash to contract_class into the madara backend db, in a new db created in crates/client/db
  • proceed to publish the tx as usual

Problem with this approach:

  • if the tx then fail in the runtime (no accepted in the mempool, execution fails coz no funds), the node would have stored an unusable class. Someone could spam this in order to fill the node disk with garbage class
  • it only works for a single node, the others ones won't receive the RPC so they won't be able to replicate this

So I think we should go for something else

@tdelabro
Copy link
Collaborator

Another approach:

  • Don't change the RPC at all
  • when a node receives a block that went through consensus, parse the list of txs, and find the ones that are DeclareTransactionV2 and upper. Do the storing here. No need to check hashes, it should be correct if part of a block. Same DB mapping in the client.

@tdelabro
Copy link
Collaborator

closed by #1409

@github-actions github-actions bot locked and limited conversation to collaborators Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backlog Ready to be picked enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

2 participants