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

Suggestions for the new no-relay template #76

Merged
merged 11 commits into from
Feb 5, 2024

Conversation

nategraf
Copy link
Contributor

@nategraf nategraf commented Feb 3, 2024

I went about taking the new template for a test drive, and ran into a few issues.
This PR contains a number of suggestions I had from the process of trying to use and understand the template better.

/// Generates a snark proof for the given elf and input.
/// When `RISC0_DEV_MODE` is set, executes the elf locally,
/// as opposed to sending the proof request to the Bonsai service.
pub fn generate_proof(elf: &[u8], input: Vec<u8>) -> Result<Proof> {
pub(crate) fn generate_proof(elf: &[u8], input: impl serde::Serialize) -> Result<Proof> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think this function should be exposed by the ethereum-sdk; people might need it outside of the starter-template

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the utilities provided are ready for wider use as a public API, and so I am hesitant to encourage folks to use this as a library. I'd like to keep types like Proof internal for now if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take on the current maturity of this code is that users should use it as an example, and copy it if it solves their problem. And we'll aim to move the into risc0 or the new risc0-ethereum repo soon.

@@ -87,7 +87,7 @@ impl TryFrom<bonsai_sdk::responses::Groth16Seal> for Seal {

/// Snark proof as generated by Bonsai.
#[derive(Clone, Debug)]
pub struct Proof {
pub(crate) struct Proof {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same suggestion as for generate_proof. Wouldn't this be useful in the context of the ethereum-sdk?

}

function set(uint256 number) internal {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why removing this? I think the way it was before looked cleaner

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With test code, my style preference if general in favor of a bit more duplication if it means each test is more self contained. This also makes it more clear where the failure case is actually failing, instead of including additional lines of code that should never be reached.

sdk/src/prover.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@capossele capossele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall awesome improvement, thanks!
I left a few comments and suggestions, lemme know what you think

nategraf and others added 2 commits February 5, 2024 10:52
Co-authored-by: Angelo Capossele <angelocapossele@gmail.com>
Copy link
Contributor

@capossele capossele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful!

@nategraf nategraf merged commit abc27a1 into capossele/no-relay Feb 5, 2024
3 checks passed
@nategraf nategraf deleted the victor/capossele/no-relay branch February 5, 2024 23:09
@nategraf
Copy link
Contributor Author

nategraf commented Feb 5, 2024

I've merged this into capossele/no-relay to consolidate any further effort there. Still open to make changes on any of the open comments above.

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