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

wasi: expose setters for timeNow and randSource #491

Closed
sam-at-luther opened this issue Apr 21, 2022 · 7 comments · Fixed by #513
Closed

wasi: expose setters for timeNow and randSource #491

sam-at-luther opened this issue Apr 21, 2022 · 7 comments · Fixed by #513

Comments

@sam-at-luther
Copy link

I have a somewhat niche use-case that requires strict non-determinism, and from what I can tell the wasi implementation mostly supports this except for 1) time and 2) randomness. I see the implementation has already provided hooks to override these in tests, but it would be very helpful for me to set these outside of the package.

Totally understand if this is deemed outside the scope of normal usage and not a priority.

		timeNowUnixNano: func() uint64 {
		randSource: func(p []byte) error {
@codefromthecrypt
Copy link
Collaborator

thanks for the priority flexibility, probably we can expose this in a way it doesn't complicate other things, just minds are loaded at the moment. nag if no progress next week!

@codefromthecrypt
Copy link
Collaborator

codefromthecrypt commented Apr 27, 2022

@sam-at-luther question. Are you needing this determinism only in tests? It might not change the outcome, but it helps to know the reason for the determinism if you can share. We don't know all the use cases, that requires users to tell us 😎

I'm currently thinking a context key named "experimental" for this config vs add it to the public API, that would allow you to work while popularity builds, also we can figure out if we need this independent of WASI or not.

@sam-at-luther
Copy link
Author

The experimental key sounds fine.

I need non-determinism for smart contracts, or in other words multiple executions of the same code across separate independent processes with exactly the same input. I realize wasm has certain edge cases that already make this problematic, but I can work around those. I don't think this is an explicit goal of WASI, but a cursory look at this implementation leads me to believe it's very close if I can control time and the random number generator, since the other problematic functions are stubbed out or have hooks.

@codefromthecrypt
Copy link
Collaborator

thanks for the context, it helps teach us more. Let's go forward with experimental for now and we can revise the design for a more stable API once we figure out the impact of the next wasi #263 and if there are wasi alternatives besides assemblyscript's special imports.

@codefromthecrypt
Copy link
Collaborator

ptal! #513

@codefromthecrypt
Copy link
Collaborator

@sam-at-luther sorry to spam you, but I read this today and thought of you. https://www.slideshare.net/FluenceLabs/fast-deterministic-and-verifiable-computations-with-webassembly

@codefromthecrypt
Copy link
Collaborator

we probably need to categorize in general all sources of determinism we can control. Ex we have this (albeit experimental) as well the recently added CompileConfig.WithMemorySizer which allows pre-allocating (via capacity). @sam-at-luther if you notice something else, please file an issue as we're not always aware of what opportunities there are.

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 a pull request may close this issue.

2 participants