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

Handle arbitrary, different Stark types as argument #1610

Open
hratoanina opened this issue Jul 29, 2024 · 0 comments
Open

Handle arbitrary, different Stark types as argument #1610

hratoanina opened this issue Jul 29, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@hratoanina
Copy link
Contributor

A long-standing problem has been to handle a collection of different STARKs in Plonky2. The problem is that Stark is a trait, and that its instantiations are created externally to the crate, in the project using starky. This prevents us from writing any kind of generic code for multi-STARK systems in plonky2, even though this is what we would want to following #1600.

Batched STARKs require to work with (e.g.) a Vec of different, arbitrary defined types implementing Stark. The issue is that Stark is not object-safe, meaning that we can't do something like Vec<Box<dyn Stark>>.
Some possible solutions have been mentioned (@atanmarko, @dlubarov, @BGluth, @0xaatif):

  • Making Stark object-safe.
  • Use a sort of linked list of Stark types as argument.
  • Using macros.
  • Using unsafe C++-style casting.
  • Implementing a custom vtable ourselves.

Having a good solution would be extremely nice, but if needed we can just keep things as is and leave any multi-STARK code to the calling project.

@hratoanina hratoanina added the enhancement New feature or request label Jul 29, 2024
@github-project-automation github-project-automation bot moved this to Backlog in Zero EVM Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Backlog
Development

No branches or pull requests

1 participant