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

Add ContextStore as a way to simplify context recovery #103

Merged
merged 2 commits into from
Jun 20, 2022

Conversation

xosmig
Copy link
Contributor

@xosmig xosmig commented Jun 17, 2022

Currently, working with signatures and hashes in mir is associated with a lot of boilerplate due to the need to create new protobuf types and wrap / unwrap them. The idea of ContextStore is to create a more general way to recover the context after the control flow returns to the module.

I want ContextStore to be used by default in dsl modules (see #102), with some nice wrappers so that the user doesn't have to think about it.

Open questions:

  • How to implement a concurrent ContextStore?
    • If I understand the Mir architecture correctly, the assigned ids should be deterministic.
    • One potential option would be to use sha256 hash as the item id, but this is rather problematic and slow.
  • How to create a wrapper for dsl modules without causing a callback hell?
    • Can we do something similar to futures?

protos/eventpb/eventpb.proto Show resolved Hide resolved
The goal of contextstore is to simplify context recovery when
working with modules like Crypto and Hasher. Currently, using
these modules requires creating a new protobuf type each time the
user wants to verify a signature or compute a hash. This is
associated with a lot of boilerplate code. ContextStore allows
saving the context locally in the module and only sending an
automatically generated id in a standard ContextStoreOrigin
protobuf.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants