sin7y / olavm Goto Github PK

For now, there are 2 builtins use transpose, bitwise and range_check.

When we get memory trace from vm, we call this raw memory trace raw_mem_trace, we need sort it by address, clk, pc. We call sorted memory trace sorted_mem_trace,

we then can do memory constraint:

• First time operation of specified address should be write.
• Address should be increased(since we sorted them).
• When operation is read, the value must be same as last operation.
• more...

Constraint sorted memory is not enough, we need permutation argument to make sure raw_mem_trace and sorted_mem_trace are permuted.

For now, there are several broken color tags in readme, e.g the status (done, doing, to do). Fix these with emoji.

What?

There are three pr merge strategies: (normal) merge, squash, rebase.
More info about them on https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github .

Why?

1. Clean git logs. As we all know, when someone new a pr, usually, there are more than one commit. Using this strategy can squash many into one.
2. The commit msg will be Pr title + pr num. We can easy track the pr context of a commit.

• A demo as below:

How?

• Go to repo->settings->General
• Confg the Pull Requests like below:

Hey guys,
I'm new at this field and I just read your documentation and I'm a little confused.
I don't know the step-by-step process for writing a guest program on the circuit and validating it.
I would appreciate it if you guys help me through this.
Thanks.

Should we use u64 as our main type for operands? In contrast, currently we use GoldilocksField, which is a 63 bit field(more precisely, P = 2^64 - 2^33 + 1). So the question is: what are the pros vs cons?

We need more utils gates, like range check, comparison. So we can use these gates whenever we need. And we can also use these gates internally in builtins.

For example, something like PSE's lt gadget.

We use plonky2, which requires a recent nightly toolchain, we better override toolchain to nightly.

I found that the verification command only needs to input a proof file, so how to ensure that the proof received by the verifier is the proof of the given program. Some stark proofs I have learned will include the hash of the program in order to bind the program and the proof.

At present, there is no constraint on the reading and writing of register, but after preprocessing, the data of register is taken out and constructed into AIR trace. We should consider make these constraints.

The execute function in executor::Process is way too large, consider refactor it to multiple smaller functions based on each instruction.

I followed the tutorial to run the asm file and wanted to generate a code file, but this step reported an error:

$ ola asm --input fib.asm --output fib.code
Input assemble file path: fib.asm
thread 'main' panicked at assembler/src/encode.rs:263:18:
not match opcode:{
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Right now, we use serde to serialize StarkProof, which wastes quite a bit of space. We should make custom serializer, like plonky2 proof do. We better 'inherit' Buffer, add StarkOpeningSet read/write function.