status-im
/
c-kzg-4844
mirror of https://github.com/status-im/c-kzg-4844.git
2
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Minimal 4844 version of c-kzg
740 Commits 4 Branches 0 Tags 9.4 MiB
Nim 42.9%
C 26.4%
Rust 7.2%
Java 6.1%
C# 3.8%
Other 13.6%
Go to file
George Kadianakis f19cee9c3f
Sanity check that trusted setup was loaded in Lagrange form (#309) 
* Sanity check that trusted setup was loaded in Lagrange form

* fixup! Sanity check that trusted setup was loaded in Lagrange form

* Fix some nits

* Fix another nit

---------

Co-authored-by: Justin Traglia <jtraglia@pm.me>
 		2023-06-01 14:58:46 +03:00
.github/workflows [Go] Make UnmarshalText funcs safer (#306) 2023-05-25 14:40:21 +03:00
bindings Make from_hex() safer in rust bindings (#307) 2023-05-28 18:47:59 +03:00
blst@e9dfc5ee72 Update blst and remove hacks (#281) 2023-04-07 07:58:17 -05:00
fuzz Add coverage-guided C fuzzers (#203) 2023-03-13 12:45:02 +02:00
inc Small cleanups (#202) 2023-03-10 11:32:13 -06:00
lib Insert lib/ directory and update Readme 2021-02-02 11:36:36 +00:00
src Sanity check that trusted setup was loaded in Lagrange form (#309) 2023-06-01 14:58:46 +03:00
tests Switch to big-endian (#305) 2023-05-24 08:44:05 -05:00
.gitignore Small cleanups (#202) 2023-03-10 11:32:13 -06:00
.gitmodules Upgrade blst & remove sha256 patch (#85) 2023-01-25 20:07:15 +00:00
LICENSE Initial commit 2021-02-01 20:15:45 +00:00
README.md Add more information to the readme (#264) 2023-04-04 09:37:42 -05:00
go.mod Update blst and remove hacks (#281) 2023-04-07 07:58:17 -05:00
go.sum Update blst and remove hacks (#281) 2023-04-07 07:58:17 -05:00
kzg4844.nimble Add support for nimble package (#232) 2023-03-24 08:02:38 -05:00

README.md

C-KZG-4844

A minimal implemention of the Polynomial Commitments API for EIP-4844, written in C.

Bindings

While the core implementation is in C, bindings are available for various high-level languages, providing convenient wrappers around C functions. These bindings are intended to be used by Ethereum clients, to avoid re-implemention of crucial cryptographic functions.

Language Link
C# README
Go README
Java README
Nim README
Node.js README
Python README
Rust README

Interface functions

The C-KZG-4844 library provides implementations of the public KZG functions that are defined in the Polynomial Commitments specification. The aim is to align these functions as closely as possible with the specification.

  • blob_to_kzg_commitment
  • compute_kzg_proof
  • compute_blob_kzg_proof
  • verify_kzg_proof
  • verify_blob_kzg_proof
  • verify_blob_kzg_proof_batch

This library also provides functions for loading and freeing the trusted setup, which are not defined in the specification. These functions are intended to be executed once during the initialization process. As the name suggests, the trusted setup file is considered to be trustworthy.

  • load_trusted_setup
  • load_trusted_setup_file
  • free_trusted_setup

Remarks

Tests

All the bindings are tested against the KZG reference tests, which are defined in the consensus-spec-tests. Additionally, a suite of unit tests for internal C functions is located here.

Parallelization

The interface functions in C-KZG-4844 are single-threaded for simplicity, as implementing multi-threading across multiple platforms can be complex. While performance is important, these functions are already quite fast and efficient. For instance, verify_blob_kzg_proof is expected to finish in under 3ms on most systems.

Batched verification

When processing multiple blobs, verify_blob_kzg_proof_batch is more efficient than calling verify_blob_kzg_proof individually. In CI tests, verifying 64 blobs in batch is 53% faster per blob than verifying them individually. For a single blob, verify_blob_kzg_proof_batch calls verify_blob_kzg_proof, and the overhead is negligible.

Benchmarks

C-KZG-4844 does not include C benchmarks; however, some bindings (Go, Java, and Rust) have their own benchmarks. Including benchmarks in the bindings offers a more realistic performance estimate, as C-KZG-4844 is not expected to be used outside of the bindings.

Why C?

The primary reason for choosing C is because blst, the BLS12-381 signature library we wanted to use, is mostly written in C. Rust was a viable alternative, but it has some disadvantages. The C toolchain is ubiquitous, and it would be somewhat awkward for all the bindings to depend on another toolchain, such as Rust. Compared to Rust, C offers a lighter memory and binary footprint. Furthermore, C serves as the de facto language for FFI, so we could not have completely avoided using C anyway.