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

many testdata was missing in executor\src\tests.rs

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:

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.

Hello,

I would like to request the creation of a Turkish version of the current English README. Providing a Turkish translation will help to make the project more accessible to Turkish-speaking users and contributors.

Proposed Solution:

Translate the entire README from English to Turkish.
Ensure that all technical terms are accurately translated or appropriately kept in English if they do not have a direct Turkish equivalent.
Add a link to the Turkish version at the top of the existing README for easy access.

Context:

I am a Turkish speaker and would be happy to assist with or fully handle the translation process. Please let me know if this is something the project maintainers are open to, and if there are any specific guidelines or formats that I should follow.

Thank you for considering this request!

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

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?

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

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.

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.

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.

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

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.

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

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.