Maru
  • Introduction
  • Volume use cases
  • Architecture overview
  • Maru Roadmap
  • ZK IMPLEMENTATION
    • Schema
      • Sum proof
      • Search proof
      • Data proof
      • Keccak proof
      • KeccakSponge proof
      • Logic proof
      • Arithmetic proof
    • Plonky2 verifier in Circom
  • user guide
    • Maru Demo FAQ
      • Why event proofs?
      • Why starky?
    • Deployed contracts
  • Maru ZKVM
    • Computer architecture
    • Memory model
    • Instruction set architecture
      • Instructions Execution
      • Instruction set
      • Instruction encoding
    • High-level frontend
    • Domain Specific Language
      • Unary map
      • Zip and binary map
      • Filter for all ETH-USDC swap prices on Uniswap
      • Calculate a 24-hour block-by-block moving average of the ETH-USDC pair on Uniswap
      • Compiler optimizations
Powered by GitBook
On this page
  1. Maru ZKVM
  2. Domain Specific Language

Compiler optimizations

The compiler can be smart enough to optimize semantically related operators into significantly more efficient specific implementations, considering the information it has about them. For example, in the aforementioned implementation for moving_avg, instead of writing:

.fold((moving_avg,
 (moving_avg, block_average_priсe)) => 
moving_avg + block_average_priсe / block_window_len)

The compiler allows us to write more concisely and expressively:

.map(block_average_priсe => 
block_average_priсe / block_window_len)
.sum()

Although the user logically expressed multiple operators, the compiler can make assumptions based on properties such as commutativity. For example, if the compiler determines that addition is commutative, it can generate a differential operator that takes advantage of this fact, avoiding the need for iteration. On the other hand, the compiler cannot make the same assumption about the commutativity of the fold function.

PreviousCalculate a 24-hour block-by-block moving average of the ETH-USDC pair on Uniswap

Last updated 1 year ago