Skip to content

Releases: ingonyama-zk/blaze

Supporting a new module for NTT calculation

17 Aug 12:02
98226ea
Compare
Choose a tag to compare

What’s included in the new release:

  • Supporting the new module for NTT calculation

  • FPGA driver loading function corrected

  • Fixed configurations: now there is no problem when using Blaze as configuration libraries are not loaded

🔥 In the new release, we are also attaching a driver binary that you can try out. In this release we support the U250 binary for NTT.

How to use the new module?

As a reference, you can find two tests for NTT in blaze/tests/integration_ntt.rs

The first one is called ntt_test_correctness. Its main function is to check the correctness of one iteration of a calculation. That’s why they use the buffer number for the host and FPGA (kernel).

How to run tesst:

BIN=<path_to_bin> INFNAME=<path_to_binary_input_vector> OUTFNAME=<path_to_binary_output_vector> RUST_LOG=info cargo test -- integration_ntt -- ntt_test_correctness

Note that the input data does not necessarily have to be in the file equivalent. All that is required is a byte vector for the input data - it is used at the set_data function. And also a byte vector with the result at the correctness check stage.

The second test ntt_parallel_test_correctness already fully reveals all the advantages of NTT - we write new vectors in parallel while the computation is going on.

For this test, we need several input/reference values, so to run the test we need to specify the directory:

BIN=<path_to_bin> INDIR=<path_to_dir_with_input_vectors> REFDIR=<path_to_dir_with_ref_vectors> RUST_LOG=info cargo test — integration_ntt — ntt_parallel_test_correctness

New design and HW support

05 May 09:56
886f1b2
Compare
Choose a tag to compare

Main changes of the new design

  • Added support for working with different HW configurations (soon we will resume work on AWS-F1 based on this architecture)
  • The new architecture divides the basic interaction with the card independent of the binary loaded there and into separate modules for each primitive.
  • Common interface for modules allows you to easily add new primitives, while preserving the flexibility of implementation within the module itself
  • The following modules are currently available
    • MSM
      • BLS12_377
      • BN254
      • BLS12_381
    • Poseidon hash
  • Added option to work with HBM memory.
  • Configuration of the card and each module is done via json
  • Added user-friendly debug of card status - offsets in logs are shown by name instead of value

F1 support for MSM on Bls12-377

05 May 06:26
6cbbdef
Compare
Choose a tag to compare
v0.1

Create .gitignore