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

dev: make Serde usable from hints executed on Rust VM #883

Closed
enitrat opened this issue Feb 27, 2025 · 0 comments · Fixed by #887
Closed

dev: make Serde usable from hints executed on Rust VM #883

enitrat opened this issue Feb 27, 2025 · 0 comments · Fixed by #887
Assignees

Comments

@enitrat
Copy link
Collaborator

enitrat commented Feb 27, 2025

In order to properly use EVM traces we would want to make the Serde class usable from hints on the Rust VM.

Using our dynamic hint system, we have:

  • a py wrapper for our rust memory segments
  • a py wrapper for our rust dict manager

what's missing:

  • the program identifiers, required to resolve types in the serde logic

What we could do:

  • pass the program json to the rust runner
  • pass the program json during execution of a hint that needs serde
  • deserialize the json, getting the identifiers field
  • instantiate Serde using these identifiers, and the segments / dict_manager that we put in local variables prior to hint execution

This will unlock logging and tracing from rust / py vms, super easily!

@github-project-automation github-project-automation bot moved this to Backlog in Keth Feb 27, 2025
@ClementWalter ClementWalter moved this from Backlog to In progress in Keth Feb 27, 2025
ClementWalter added a commit that referenced this issue Feb 28, 2025
Exposes a `serialize` function, available in the scope of all hints,
that enables the serialization using `serde` of cairo types, and returns
their python representation.

This can be used for the logging / tracing system.

I am welcoming any alternative idea on the currently proposed design -
as working with python `globals()` has been quite a hassle.

Also, i'm not sure yet how we can make this entirely transparent with
the pythonVM runs. If we realize there's a need for that, we can do it
later.

This does introduce a small performance overhead of about ~5% from what
i've observed empirically. So in production we'll need to make sure
we're not compiling with this flag.
Closes #883

---------

Co-authored-by: Clément Walter <[email protected]>
@github-project-automation github-project-automation bot moved this from In progress to Done in Keth Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant