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

Support Dynamic number of inputs and Required/Optional inputs #48

Open
austbot opened this issue Oct 16, 2024 · 0 comments
Open

Support Dynamic number of inputs and Required/Optional inputs #48

austbot opened this issue Oct 16, 2024 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@austbot
Copy link
Contributor

austbot commented Oct 16, 2024

Currently bonsol execution request inputs and program inputs must match exactly.
This doest not allow for optional inputs or dynamic numbers of inputs.

We should support an additional metadata on the program input and deployment struct that allows and input to be marked required, then other inputs can be dynamic. The easiest way to make this work is that required inputs must be first followed by any optional ones. This is similar to many programming languages.

One complication is that in the GUEST and HOST we add the inputs to the env in order. Having some sort of guest side manifest of which inputs are present will be important. This will naturally look like a helper struct over the GUEST env::read_slice functionality. The main goal of this helper is to help the zkprogram developer know if there are any remaining inputs.

Since there is not a way to know this we must rely on the fact that env::read_slice will error with eof.

Inputs in the guest should be thought of a s a big slab of bytes

pub fn write_slice<T: Pod>(&mut self, slice: &[T]) -> &mut Self {
        self.inner
            .input
            .extend_from_slice(bytemuck::cast_slice(slice));
        self
    }

Bonsol treats each input as a separate call to write_slice but in reality the guest just sees a big slab of bytes. Its up to the developer to select the right range of inputs for their program, for example if there are 100 bytes in the slab that the guest sees, but the host put those as one 49 byte input and one 51 byte input, if the first call to read_slice reads to a 51 byte buffer then you will be missing some bytes for when you try to read the next input.
All this is to say that helping the developer with input order and proper sizing will be important. We want to provide this helper without getting in the way of any deserialization they may need to perform to do their logic.

@austbot austbot added enhancement New feature or request question Further information is requested labels Oct 16, 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 question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant