Triton VM

Futhark Port and Introduction

2024-08-10

Hello,

My name is Hunter. I am an undergrad from Seattle. I’ve been in communication with Thorkil about porting the stark prover from rust to futhark so it can run on the GPU.

Of which I have been developing in this fork: https://github.com/Holindauer/ruthark

Currently, I’m starting by porting over the building blocks needed for this task. At the moment, I have ported the Tip5 hash_pair() and hash_10() functions from twenty-first. With my next immediate moves being to tackle BFieldCodec.rs and merkle_tree.rs.

Additionally, I was wondering where I would find the polynomial and low degree extension logic within the codebase. And if there is any general advice regarding what order to port different components over in.

Good to meet you all, -Hunter

Scripting language

2024-08-14

Hi, my name is Chance and I work on the privacy and scaling explorations team at the EF. I’ve been looking for a solid STARK proving system for a while and I think TritonVM is probably the most advanced/well built STARK based zkvm out right now.

To use this vm I have been designing a simple scripting language to express mathematical relationships. I’m trying to take learnings from pain points in circom, the simplicity of javascript, and the safety/usability of rust. I’ve held off on sharing this for a while because I wasn’t sure if the language could be better than writing raw assembly, but I’m now confident that it can be.

One important feature of this language (ashlang) is that each file is a distinct function. The function name is the file stem. This made it easy to assemble files that are written in different languages. In an ashlang project functions can be written either in ashlang, or tasm. Ashlang functions can call tasm functions, and tasm functions can call ashlang functions, provided they manually manipulate the stack in the correct way.

I had significant doubts about my ability to write an assembler that can produce tasm that is as efficient as handwrittem tasm, but it turns out these doubts are almost irrelevant. Ashlang can be used to manage the control flow and write the high level structure, then specific functions can be implemented efficiently using tasm.

To achieve this tasm source files specify a function signature as the first non-whitespace line. This allows the assembler to statically analyze the program and confirm that the tasm function calls are being passed the correct arguments. You can see an example of this in the shift left circular implementation. This function accepts two scalars and returns a single scalar.

The language still has some oddities with argument handling and return types. Specifically the arguments are reversed on the stack during calls (so to execute lt a swap 1 is necessary), and an extra argument is always passed to account for the case of a function returning a memory based variable. Both of these are simple changes that can be addressed immediately.

You can see the larger standard library here there are some example programs in the test-vectors directory in that repo as well. My immediate next steps are refactoring out some debt and fixing the issues i described above. After that I’m planning to make a STARK proof where a user decrypts data, operates on the data, and re-encrypts it (using chacha).

I’d love to get feedback from the team. I imagine learnings from the tasm-lib would be almost directly applicable. I’d also like to make the language useful to the team if possible.

Thanks

announcing Triton VM v0.40.0

2024-04-16

Triton VM v0.40.0 is now live. The main highlights are:

Performance

This release fixes a previously unknown performance bottleneck when proving programs that perform a lot of RAM I/O. One such program is Triton VM’s very own recursive verifier, making this performance boost mission critical.

As another perfomance highlight, Triton VM now consumes considerably less RAM when proving the correct execution of a program.

Profiling

The profiler for Triton assembly programs now reports not only the clock cycle contribution of any encountered subroutine, but the contribution to any of parts critical for prover performance. On any Triton VM program, you can execute .profile() to get the new report. The Display implementation of that report gives you a markdown table listing all the new goodies.

Full Changelog

✨ Features

(!) Generate profiles despite unfinished tasks (f7ebd2cb)
(!) Streamline accessing AET’s heights (3f3a9fd1)
(!) Track all relevant tables in VM profiler (fa38fa8b)

🐛 Bug Fixes

(!) Don’t treat randomizer polynomial special (9bbe963b)

⚡️ Performance

Minimize squeezes for combination weights (50b803c7)
Re-organize prover steps (86a7799f)
(test) Use minimal size for quotient domain (727ff8ec)
Use faster polynomial coset evaluation (29849abe)
Compute Bézout coefficients faster (652b7e9c)

📚 Documentation

Add rationale for performed DEEP updates (74814884)
Update documentation of MasterTable (d5c2049c)
Describe computation of Bézout coefficients (06123843)

⚙️ Miscellaneous

Use fewer glob uses (9ca39513)
(!) (circuit) Use challenge’s index (e05e3ff3)
(!) (circuit) No Challenges in evaluate (15a8cd7f)
Use constant “lookup table height” more (22834b03)
Benchmark Bézout coefficient computation (ab135be4)

♻️ Refactor

Deprecate method num_quotients() (363ae773)
(!) Use BFieldElements everywhere (05bd271a)
(!) Make ProofStream non-generic (bde928d4)
(!) Remove deprecated type aliases (14d08ef8)
(!) Rename TableId variants (c265cf4d)
Bypass quotient table (ff305459)

✅ Testing

Benchmark program with lots of memory I/O (c7613878)

🎨 Styling

Improve readability of .verify() slightly (e0ac1096)

announcing Triton VM v0.33.0

2023-08-10

Triton VM v0.33.0 is now live. The main highlights are:

Non-deterministic Initialization of RAM

In all prior versions, the only way for programs to receive input was through public or secret input, i.e. using instructions read_io, divine, or divine_sibling. As of this version, RAM can be initialized before Triton VM starts execution. This means that elements that might need to be processed don’t waste precious clock cycles if they don’t end up being processed, as they can happily live in RAM without ever being read.

In future versions of Triton VM, non-deterministic RAM initialization might also be useful to place objects in RAM that depend on the current state of the VM. The zero-knowledge proof system already supports this behavior.

Improved Speed

Through changes to the proof system, better use of parallelization, and more efficient initialization of certain memory objects, the speed of the VM has increased noticeably. Depending on the hardware, the speedup factor should lie somewhere between 3 and 4 compared to the previous version, and almost 10 compared to the version that shipped with the initial release of Neptune’s alphanet.