Goal(s)

For the next version of the playground, we'd like to improve the UI/UX and add some new functionality, such as the ability to prove a program as well as run it.

Concrete goals still need to be more clearly defined, but will be based on addressing feedback from Polygon dev rel team and the points raised here: https://github.com/0xPolygonMiden/miden-vm/discussions/601

Details

Regarding UI/UX improvements:
There are a number of outstanding issues for improvement which came up during v0.1 development that should be addressed, such as repo organization and UI framework choices. We'd like to get some help from the internal Polygon design team, and these changes could be made as part of a redesign.

Regarding UX:
It would be great to have an easy-to-reference page with the Miden Assembly instructions within the playground, such as the way evm.codes is done

It would also be great to add the ability to prove and verify.

Working group:

@Dominik1999 @grjte @Overcastan

Coordinator: @Dominik1999

We want to provide Assembler instructions with the Playground. Users should be able to have a nice list handy when they code with the Playground.

A good example is https://www.evm.codes

Implementation - done is better than perfect

We will start with a second tab that lists all Assembler instructions. We can improve that in the future. The Assembler Tab will have a searchable list (https://www.npmjs.com/package/react-table) and will cover the same information as our docs. We can think of better ways to show the cycle count in the next iteration.

ToDo Lists

• Create a new tab for the Miden Assembler Instructions
• Bring all Assembler instructions from our docs into necessary format
• Show Assembler instructions in react table
• Create an issue to improve the Instructions table in the future with automated cycle count

We want to sponsor zkHack end of March. The Playground will be the entry point for Hackers to start working with the Miden VM.

The Playground is still missing some functionality. In addition, we should iterate over the design and visibility of explanations and links to relevant docs (Miden VM and the CLI).

Working group:

@Dominik1999

Coordinator: @Dominik1999

• Spacing consistency
• Size consistency
• Margin
• Only have our two colours (White and Polygon blue)
• Font in the instruction table can also be black (from Andrey)
• Clicking links should open a new window
• Header section takes too much real estate
• Shorten the name of the playground
• The ActionButtons Run, Debug, Prove, Verify can be made "sticky"
• Add a button to always come back to top of the page
• Use Tailwind UI Component and simply copy our stuff in there (e.g. here)

When executing the nprime example in the playground, I get

panicked at 'called `Result::unwrap()` on an `Err` value: "Failed to generate exection trace = DivideByZero(173), and advice_tape = []"', src/lib.rs:60:17

When the user closes the window, her code is gone. We need persistency. Her code should reappear when she reopens the window.

There are a couple of improvements that we can do to the Instruction Set.

• We could remove cycle and cycles in the Cycles column and only have a number
• We should be able that the instructions set pops out and overlays the CodingEnvironment. That way users could looks at the instructions and still code
• We should add a search functionality to the table
• We should update the table, some instructions are not correct, e.g. rphash
• We should have the font in the table black

At the moment, the playground is tested poorly. We need to test the Typescript Frontend and the WASM backend.

The correctness of the examples will be tested in a separate issue. #56

• Test the frontend using https://reactjs.org/docs/testing.html
• Test the WASM part using unit tests and one integration test

Goal is to provide a Merkle inclusion proof of length n

That means we want to prove that node is a node of a Merkle tree. To prove that, we need to know the path on the Merkle tree to the element. The path consists of hashes and either a 0 or another element e_2, at the end.

Implementation

The benchmark is to create a Merkle path of depth 32, and then n would be the number of Merkle paths we verify.

So, for n=10, we verify 10 Merkle paths of depth 32; for n=100, we verify 100 Merkle paths of depth 32 etc.

(Example for job sizes from other benchmarks)
https://github.com/delendum-xyz/zk-benchmarking/blob/c12e0ddeb076b0011aa91bf4f24cf86095de4244/miden/src/benches/iter_sha2.rs#L15-L17

Example

To discuss a super simple example, for n=1 and depth=2, we create a SparseMerkleTree.

        let merkle_leafs_keys: Vec<u64> = (0..4).collect();
        let mut merkle_leafs: Vec<Word> = Vec::new();

        for i in 0..merkle_leafs_keys.len() {
            merkle_leafs.push([Felt::new(merkle_leafs_keys[i]), Felt::ZERO, Felt::ZERO, Felt::ZERO]);
        }

        // Now we create a Sparse Merkle Tree with the leafs we just created
        let smt = AdviceSet::new_sparse_merkle_tree(merkle_leafs_keys, merkle_leafs, 2).unwrap();

Then the scenario is about verifying that node_0 (the node with index 0) is indeed part of the tree.

In Miden assembly, we can create a simple program to verify the inclusion of a node into a Merkle Tree.

  begin
  # verify a merkle path
      mtree_get
  end

So we need to create ProgramInputs for that program, hence for stack_init = [depth, index, root of the tree] and the tree must be present in the advice provider, so we can push the tree smt as advice_sets.

At the end we need to check the stack if the output is correct.

After #33 is merged, we will have a CLI to run examples.

It would be nice also to have the benchmark verify the correctness of the result. The simplest way to do it would be to include the expected result for a given example in the example directory. This would, however, mean that adjusting example parameters would be difficult. We could also include a small Rust file with each example which could output the expected result for a given set of parameters - but this might be something we do later.

This originates from #9

We want to change to Tailwind CSS instead of MUI

At the moment in the App.tsx we use Material UI. A better choice would be Tailwind CSS. Tailwind is much easier and more flexible just to use core html + styling (which tailwind makes easy).

Another note: We depend on the entire MUI icons package for one icon. Instead, I would prefer to directly add a new svg component with the Send icon from HeroIcons. We can do this when we switch to Tailwind (the same team makes them, and the icons are styled using tailwind)

Having a strong presence on the zkHack in March 23

(there is no official confirmation of the date, https://zkhack.dev/)
We assume there will be a zkHack (hackathon) on March 23.

We want hackers to have a good experience building on the Miden VM. We want them to be able to use a stable, easy-to-use Miden VM - and have fun doing so. It should also differentiate itself from other proving systems. Our goal is to show that with the Miden VM, developers can build novel applications (that are difficult or impossible to build otherwise).

We thought of several tech- and non-tech-related requirements that must be met to be ready for the zkHack in March.

Tech-related requirements

We must develop some features and tools to provide the experience described above. We should reflect the following in our planning and prioritization.

Recursive proofs

Recursive proofs can be our main differentiator. Developers can hack novel applications using the Miden VM that leverage recursive proofs.

[to be ensured: 1) No other proving system allows that for its developers, 2) there are hacks possible and realistic with recursive proofs that are not possible without it (@bobbinth @grjte do you have a different understanding of this point?)]

One higher-level language compiler (prototype)

To ensure a relatively good developer experience, we should have an alternative to Miden assembly. Realistically, we might get a compiler prototype from either Sway, Rust or Yul until March.

Debugging

Besides the compiler, hackers might also use Miden assembly. At the moment, debugging programs using the Miden VM is quite hard. We need debugging tools for Miden assembly and the Miden VM. For reference, see #580

Non-tech-related requirements

There are several non-tech-related requirements we see for a good developer experience.

Tutorials and Interface-descriptions to the documentation

Even though our documentation already follows high standards, we can improve the documentation for the hackathon. We should add some tutorials for simple programs and interactions. And we should add documentation for the Miden interfaces (which Miden datatypes are exposed in which crate and how to use them).

Improve the Miden Playground

The Miden Playground can be improved to serve as an easy-to-use Miden showcase. Hackers can go there as a start and try instructions or snippets. Therefore, we need to add

• a tab to see all instructions
• a simple step through the execution mechanism (one execution per click and see the stack)
• a possibility of seeing the proof
• a possibility to tamper and proof and see it failing

Add scaffolded repos to fork

We should provide some repos to fork that already entail the basic building blocks to create a program.

The repo currently has 8 branches and it seems like at least 3 of them are obsolete. Ideally, we should be deleting branches as soon as the related PR is merged.

We don't show op: Option<Operation> or asmop: Option<AsmOpInfo> in the output. We cannot simply return Operation or AsmOpInfo, but we might be able to deserialize it.

This is not super complicated but we need to decide how we want to show it.

We can add a toast.success also after executing and proving. The toast can show the time it took.

We should add a dropdown to set the font size. See here https://godbolt.org/ the dropdown with the A symbol.

We have a lot of examples now. Most of them need to be adequately tested.

We should have Rust implementations of all examples as well and test the output that the Miden VM produces against the Rust implementation.

We need to add a function to Debug to the playground. The Button is already there.

We can use the simple assembler debugger here 0xPolygonMiden/miden-vm#693.

However, we need to wrap it into a function to call something like

     pub fn debug_program(masm_code: &str, inputs_frontend: &str, command: &str) -> Vec<u64> {
     ...
    }

Where command is !next, !play, !prev, !print.

We will not be able to support all commands at the beginning.

We can simply call execute_iter() in here
https://github.com/0xPolygonMiden/miden-vm/blob/360b5b080b79b9d66e912e2eb286a5237a261eb2/processor/src/lib.rs#L118-L138

Then we have a VmStateIterator object on which we can call various debugging commands, see https://github.com/0xPolygonMiden/miden-vm/blob/360b5b080b79b9d66e912e2eb286a5237a261eb2/processor/src/debug.rs#L128

The challenging question will be how the VmStateIterator can be stored in the state of the browser.

Goal

Currently, in the playground (after we merge #50) we can prove a program. We only return a simple Vec<u64> in which we encode the stack_output and the overflow_addresses to the front end to show it to the user.

But we also want to return

• the proof
• the program hash
• metrics (cycles and time used to prove)

Problem wasm-bindgen doesn't allow to return tuples

We can't simply create a tuple that includes all those values (including the proof in bytes). Wasm-bindgen (which compiles Rust to WASM) doesn't allow tuples as returns, see here

Possible solution

There is a way to return a struct. So we might even be able to return ProgramOutputs (for Miden VM v0.3.) as a struct. Here are the docs (https://rustwasm.github.io/wasm-bindgen/contributing/design/exporting-rust-struct.html). I only spent 1h, but I couldn't figure out how to implement this yet.

Further considerations

We also need to find a way to show the proof to the user. Together with some links or explainers of what a proof is. Ideally, if a user would change the proof somehow, he could test to verify the changed proof and see that it would get rejected.

At the moment, we only execute the Miden assembly program. We should add the ability to prove and also to verify a program.

Proving a Miden program in lib.rs

We can add the feature as another function, pub fn prove_program and also have the program, the inputs and the output_count as function inputs.

The problem so far is, that we can't return a tuple or a complex struct from Rust to the frontend using wasm-bindgen, see https://stackoverflow.com/questions/75064800/how-to-return-a-tuple-to-frontend-from-wasm

There are solutions, but I was not able to implement them in #50

Another problem is that there is no info about the trace or the time exposed in Miden v0.3. So we don't know how many cycles or how long it took, see #29. The problem with the duration of the proving step could be solved by adding a timestamp to the frontend.

Proving a Miden program in the App.tsx

We add another function like for run_program. The return values so far are the stack_output and the overflow_addresses.
However, we do not get the proof or any other info yet to print, see above.

In an ideal world, we would get some info while the proving step is executed, like the info that is logged when you prove via the CLI.

Open questions to clarify in the working group

Maybe the ability to prove is enough for this iteration, but if not we need to answer

• What do we want to output while proving?
• What do we want to output during proving?
• How do we want to show the proof?

Any opinions / ideas on the above @grjte or @Overcastan ?

At the moment, the example program that is shown when the playground starts cannot be chosen by the user using the dropdown. We can add this example to the dropdown.

It would be good to improve the output section of the web interface to make it more distinguishable and easy to read. The easiest, but not the best way is to simply add something like "stack output" before the output itself. And, maybe, add some separator between output elements: If there are a lot of numbers, and they are large, then it is not always convenient to quickly determine where one number ends and the next number begins. But these are all topics for discussion.

The CodeMirror Component should always have a certain number of lines by default, regardless of how big the code is. Then after a certain max_height, it should be scrollable.

In this example the Inputs CodeMirror box has 4 lines and the Outputs box only 1.

    nit: we should add our logo to the icons here

Originally posted by @grjte in #6 (comment)

Currently, we can hash using Sha256; see here. This hash has 64-bytes as input and 32-bytes as output.

However, when we want to compute multiple hashes in a row, e.g. hash(hash(a,b), b)) or hash(hash(a,b)), we need the ability to hash using a 32-byte input as well.

Memory is being transformed from a Vec<(u64, Word)> into a Vec<u64>. So we need to cut it in slices of 5 in the frontend again.

Unsure how to use / display memory, let's discuss.

One other comment: I wonder whether rather than putting the playground into the root of the repo it should go into something like /wasm-playground (or just /playground) directory. This would enable us to add other things in the future (e.g., CLI mentioned in #9). Maybe the structure of the repo could be something like:

├─ bench-cli
├─ examples
└─ playground

What do you guys think?

Originally posted by @bobbinth in #6 (comment)

Currently, we get errors when the input is not correctly formatted, or stack_init is missing. We need to catch any input before deserialising it in the Rust backend. We can have a pop-up window warning the user that a certain input cannot be accepted. We can use https://react-hot-toast.com/ to prompt a pop-up.

Input data

Currently, we support stack_init and advice_tape as inputs.

The playground should accept any input that:

• is empty
• only consists of stack_init and is a valid JSON, and stack_init consists of at least one integer and only consists of integers
• only consists of advice_tape and is a valid JSON, and advice_tape consists of at least one integer and only consists of integers
• consists of stack_init and advice_tape and is a valid JSON, and stack_init and advice_tape consists of at least one integer and only consist of integers

Input code

Currently, we support any code input. There is no restriction on valid Assembly code. But we should check that the code does not go over a certain length.

Introduction/Background: As our little project here grows in complexity, the need for a robust and automated testing and deployment process becomes crucial. Implementing Continuous Integration (CI) for our examples repository will help us ensure code quality and reduce the risk of bugs in production.

Goals/Objectives:

• Automate testing to run on every commit and pull request.
• Ensure code style consistency using automated linting.
• Enable automated deployment to our staging environment.

Requirements and Specifications:

• Use GitHub Actions as the CI tool.
• Automate unit and integration testing.
• Set up linting with ESLint for code consistency.

Provide a good, easy experience for Hackers in Lisbon

We want to prepare for our involvement in the zkHack in Lisbon End of March - see here.

We want to polish our docs, incl. tutorials, hold a 30-min workshop, and create scaffolded repos containing the major components needed to hack on the Miden VM.

Tutorials and Interface-descriptions to the documentation

Even though our documentation already follows high standards, we can improve the documentation for the hackathon. We should add some tutorials for simple programs and interactions. And we should add documentation for the Miden interfaces (which Miden datatypes are exposed in which crate and how to use them).

Workshop 30-min

We will have a 30-min workshop in Lisbon to introduce the Miden VM, Miden Assembly and our tools. We need to prepare that.

Scaffolded repos

We want to create some repos containing the major components needed to hack on the Miden VM.

For the Delendum Benchmarking project our first benchmarking scenario will be to iterate a hash function - which we call a hash chain. We will iterate our default hash function BLAKE3.

The scenario is defined as

Compute h(h(h(...h(x)))), where h() is a cryptographic hash function for some input [0u8; 32] (32-bytes).

We will benchmark three different chain lengths, 1, 10, 100, and 1000 hashes.

The benchmarking repo can be found here. https://github.com/delendum-xyz/zk-benchmarking

Steps:

• create 1-to-1 BLAKE3
• create scenario for hash chains
• measure time to prove
• measure time to proof size
• measure time to verify
• check result according to hash function

When the playground is processing after a button has been pressed, we should indicate somehow that things are processing, either with a spinner on the pressed button or a spinner in front of the whole page. All buttons should also be disabled until the playground is done processing.

This list is WIP. The goal is to improve the debugging feature of the playground.

• When the users clicks Debug the program should start and display clk=0
• We need to be able to jump more than one clk (maybe one button for 10 and one for 100)?
• op and asmop are quite confusing for users. It is hard to map them to Assembler Instructions (is that true?)
• fmp is not super helpful to show
• memory is not shown correctly

For the Delendum Benchmarking project our first benchmarking scenario will be to iterate a hash function - which we call a hash chain. We will iterate our default hash function SHA256.

The scenario is defined as

Compute h(h(h(...h(x)))), where h() is a cryptographic hash function for some input [0u8; 32] (32-bytes).

We will benchmark three different chain lengths, 1, 10, 100, and 1000 hashes.

The benchmarking repo can be found here. https://github.com/delendum-xyz/zk-benchmarking

Steps:

• create 1-to-1 SHA256
• create scenario for hash chains
• measure time to prove
• measure time to proof size
• measure time to verify
• check result according to hash function

Currently, we can hash using BLAKE3; see here. This hash has 64-bytes as input and 32-bytes as output.

However, when we want to compute multiple hashes in a row, e.g. hash(hash(a,b), b)) or hash(hash(a,b)), we need the ability to hash using a 32-byte input as well.

The original issue is 0xPolygonMiden/miden-vm#204. The basic idea is that it would be nice to add some program metadata about executing a given program. Things which could be useful:

1. Number of cycles.
2. Length of execution trace (basically, number of cycles rounded to the next power of two).
3. Execution time, and maybe proving time once we have proving integrated.

There are probably many other interesting things, but this could be a good starting set.

Would be great to support the ability to run benchmarks in concurrent mode via the CLI. The ideal way would be to specify number of threads via a CLI parameter - but I'm not sure if that's possible.

We need a working search for the assembler table. Users should be able to search for any word either in the name or description of the playground.

closed as this is reflected in #86

A few small things that would be great to improve in benchmarking CLI:

1. We should use structop instead of clap as thats what we use for all other CLIs (e.g., here).
2. We should keep CLI parameters as consistent as possible across different CLIs (e.g., for how we specify security, number of outputs etc.). See example here.
3. Let's change the executable file name to something like miden-bench (miden-benchmarking-cli is way too long).
4. miden::prove() also includes execution time, I believe. So, to make things more clear, we should probably label it as "Execution + proving time" or something like that.
5. Would also be great to print out proof size.

We can add syntax highlighting to the code editor for MASM.

Here is a Miden Assembly extension for VScode. I think, we can reuse them for the CodeMirror. But I am not 100% sure. Here is some info https://codemirror.net/docs/ref/#language.syntaxHighlighting

Once we have settled on what we want to show in the Debugging Output, we should format the output to a JSON in Rust. That way, in the front end we can show what we want.

At the moment, we return a structure Outputs from Rust land when the user executes Run or Prove.

It would be good to be consistent with the Debugging feature and return a similar data structure for all features. We can then format the Outputs in JS land how we want.

When I run the Game of Life example in the playground, I would expect using the initial universe

"stack_init": ["0", "0", "0", "0", "0", "0", "0", "0", "0", "0", "1", "1", "0", "0", "1", "0"]

the following output

["0", "0", "0", "0", "0", "0", "0", "0", "0", "0", "1", "1", "0", "0", "1", "1"]

But somehow I get only 0's.

Currently, playground is located in the root directory of the repo. Instead it should be in its own directory at the same level as benchmarking CLI and examples.

    For the future: It would be good to pull this out into its own component and add it at both the top and the bottom of the screen. I think that would provide better UX (people wouldn't need to scroll back up after writing their code). Do you agree? If so, can you create an issue?

Originally posted by @grjte in #6 (comment)

We should add a small CLI which could be used to benchmark any of the examples. This would also be helpful for the Delendum benchmarking project.

The CLI should take a path to the example directory as input, execute/prove the example, and output the following metrics:

1. Cold compilation time (i.e., when the example is compiled with a new assembler).
2. Hot compilation time (i.e., when the example is complied with an assembler which was already used to compile the same code).
3. Execution time.
4. Proving time.
5. Verification time.

It would also be nice to enable benchmarking at 96-bit and 128-bit security levels. So, maybe this could be another input parameter for the CLI.

Lastly, it would be really nice to also have the benchmark verify the correctness of the result. The simplest way to do it would be include the expected result for a given example into the example directory. This would, however, mean that adjusting example parameters would be difficult. We could also include a small Rust file with each example which could output the expected result for a given set of parameters - but this might be something we do later on.

Goal(s)

• Benchmark Miden VM against the defined scenarios in https://github.com/delendum-xyz/zk-benchmarking
• Add necessary features and change code to be able to benchmark

Details

For this target, we want to benchmark the Miden VM against other proving systems, e.g. Risk0. Therefore, we have predefined scenarios. Our goal is to create a neutral and objective playground to benchmark several proving systems also to invite other systems like Cairo VM in the future.

Working group:

@Dominik1999 @itzmeanjan

Coordinator: @Dominik1999

It would be super cool, if there is a good explainer per example, when people hover over a symbol, like a question mark.

For example, it is not clear to most users why our Fibonacci example starts with [1, 1] or why the game of life inputs and outputs are as they are.

So it can be a simple site or pop-up that explains one example step by step with graphics.

Because we don't show the proof to the user, atm the difference between executing and probing is quite subtle (or not visible in the example of Fibonacci).

We can have a small icon that indicates that there is a proof. We can show the proof size and the security level of the proof.

In the future, we can provide the ability to download and even upload a proof.

The user should be able to see the proof in Hex.

We want to be able to verify programs in the Miden Playground. And we want that users are able to tamper with the Output that gets verified to see that not every program can be verified.

Therefore, we need to

• recollect the values from the Output stack_output and overflow_addr from the frontend
• recollect the program inputs from the frontend
• pass the proof back to the backend, (need to do #52 first)
• pass the program back to the backend to get the program.hash

It should fail if a user changes the input or output in the CodeMirror components.

For the Delendum Benchmarking project our first benchmarking scenario will be to iterate a hash function - which we call a hash chain. We will iterate our default hash function Rescue Prime.

The scenario is defined as

Compute h(h(h(...h(x)))), where h() is a cryptographic hash function for some input [0u8; 32] (32-bytes).

We will benchmark three different chain lengths, 1, 10 and 100 hashes.

The benchmarking repo can be found here. https://github.com/delendum-xyz/zk-benchmarking

Steps:

• create 1-to-1 Rescue Prime
• create scenario for hash chains
• measure time to prove
• measure time to proof size
• measure time to verify
• check result according to hash function

PR is here delendum-xyz/zk-benchmarking#5