You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 implementingStark
. The issue is thatStark
is not object-safe, meaning that we can't do something likeVec<Box<dyn Stark>>
.Some possible solutions have been mentioned (@atanmarko, @dlubarov, @BGluth, @0xaatif):
Stark
object-safe.Stark
types as argument.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.
The text was updated successfully, but these errors were encountered: