feat: blst bindings by spiral-ladder · Pull Request #192 · ChainSafe/lodestar-z

spiral-ladder · 2026-01-26T15:06:32Z

No description provided.

gemini-code-assist · 2026-01-26T15:06:51Z

Summary of Changes

Hello @spiral-ladder, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request integrates the blst cryptographic library into the N-API environment, providing robust and efficient BLS signature capabilities. It allows for the creation, serialization, and verification of public keys and signatures, including support for aggregate verification. The changes are accompanied by comprehensive type definitions for TypeScript and thorough unit tests to ensure reliability and ease of use.

Highlights

BLST Bindings Implementation: Introduced new Zig bindings for the blst cryptographic library, enabling PublicKey and Signature object handling and verification functions within the N-API environment.
PublicKey and Signature Management: Implemented constructors, fromBytes (supporting compressed and serialized forms), toBytes, and toBytesCompress methods for both PublicKey and Signature objects.
Signature Verification Functions: Added blst_verify for individual BLS signature verification and blst_fastAggregateVerify for efficient aggregate signature verification, crucial for applications like blockchain consensus.
TypeScript Type Definitions: Updated bindings/src/index.ts with declare class definitions for PublicKey and Signature, and an interface Blst to provide strong type checking for the new N-API bindings.
Comprehensive Testing: Included a new test file bindings/test/blst.test.ts with extensive tests covering PublicKey and Signature serialization/deserialization, argument validation, and both individual and aggregate signature verification.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

The pull request introduces BLST bindings for NAPI, enabling public key and signature operations, along with verification functions. New TypeScript interfaces and test cases have been added to support this functionality. The overall structure for exposing BLST to NAPI is clear. However, there are critical concerns regarding memory management in the bindings/napi/blst.zig file, as it directly violates the repository's strict policy against dynamic memory allocation after initialization. This needs immediate attention to align with the project's design goals for safety and performance.

gemini-code-assist · 2026-01-26T15:08:16Z

+var gpa: std.heap.DebugAllocator(.{}) = .init;
+const allocator = if (builtin.mode == .Debug)
+    gpa.allocator()
+else
+    std.heap.c_allocator;


The repository style guide (line 93) explicitly states, "All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization." Using std.heap.c_allocator in release mode implies dynamic memory allocation, which directly contradicts this critical memory management policy. This needs to be re-evaluated to ensure all memory is managed statically or through pre-allocated pools.

References

All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization.

gemini-code-assist · 2026-01-26T15:08:16Z

+    const pk = try allocator.create(PublicKey);
+    errdefer allocator.destroy(pk);


The use of allocator.create(PublicKey) constitutes dynamic memory allocation, which is strictly forbidden by the repository's memory management policy (line 93). This is a critical violation that needs to be addressed. Consider using pre-allocated memory or a different approach that aligns with the static allocation requirement.

References

All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization.

gemini-code-assist · 2026-01-26T15:08:16Z

+    const pks = try allocator.alloc(PublicKey, pks_len);
+    defer allocator.free(pks);


The allocator.alloc(PublicKey, pks_len) call represents dynamic memory allocation, which is explicitly prohibited by the repository's memory management policy (line 93). This is a critical issue that requires a solution using static memory or pre-allocated buffers.

References

All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization.

gemini-code-assist · 2026-01-26T15:08:16Z

+import { createRequire } from "node:module";
+import { join } from "node:path";


The removal of the TODO comment is fine, but the change in import formatting from import {createRequire} from "node:module"; to import { createRequire } } from "node:module"; is a stylistic change. While not explicitly covered for TypeScript, consistency in formatting is generally good. Consider running a linter/formatter if available for TypeScript files to maintain a consistent style.

gemini-code-assist · 2026-01-26T15:08:16Z

+    });
+
+    it("should throw on invalid length", () => {
+      expect(() => bindings.blst.Signature.fromBytes(new Uint8Array(95))).toThrow();


This test uses toThrow() without specifying the expected error message or type. For better test clarity and robustness, it's recommended to assert the specific error that is expected, similar to other tests in this file (e.g., toThrow("InvalidSignatureLength")). This helps ensure that the correct error condition is being met.

Suggested change

expect(() => bindings.blst.Signature.fromBytes(new Uint8Array(95))).toThrow();

expect(() => bindings.blst.Signature.fromBytes(new Uint8Array(95))).toThrow("InvalidSignatureLength");

gemini-code-assist · 2026-01-26T15:08:16Z

+    it("should throw on wrong message length", () => {
+      const pk = bindings.blst.PublicKey.fromBytes(TEST_VECTORS.publicKey.compressed);
+      const sig = bindings.blst.Signature.fromBytes(TEST_VECTORS.signature.compressed);
+      expect(() => bindings.blst.fastAggregateVerify(new Uint8Array(31), [pk], sig)).toThrow();


Similar to the previous comment, this test uses toThrow() without specifying the expected error. It would be more robust to assert the specific error message, such as toThrow("InvalidMessageLength"), to ensure the correct error path is being tested.

Suggested change

expect(() => bindings.blst.fastAggregateVerify(new Uint8Array(31), [pk], sig)).toThrow();

expect(() => bindings.blst.fastAggregateVerify(new Uint8Array(31), [pk], sig)).toThrow("InvalidMessageLength");

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7d54cfcddf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-01-29T16:32:16Z

+pub fn PublicKey_ctor(env: napi.Env, cb: napi.CallbackInfo(0)) !napi.Value {
+    const pk = try allocator.create(PublicKey);
+    errdefer allocator.destroy(pk);
+    _ = try env.wrap(cb.this(), PublicKey, pk, PublicKey_finalize, null);


Initialize PublicKey in constructor or make it unusable

The constructor allocates a PublicKey but leaves it uninitialized, and the class is publicly exposed in JS/TS. Calling new blst.PublicKey() (or any code path that creates an instance without fromBytes) yields garbage memory; subsequent toBytes() or verify() calls will operate on undefined data and can return nondeterministic results. This is easy to trigger because the TypeScript declaration does not hide the constructor. Consider initializing to a known value or throwing in the constructor so only fromBytes can create valid instances.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-01-29T16:32:16Z

+pub fn Signature_ctor(env: napi.Env, cb: napi.CallbackInfo(0)) !napi.Value {
+    const sig = try allocator.create(Signature);
+    errdefer allocator.destroy(sig);
+    _ = try env.wrap(cb.this(), Signature, sig, Signature_finalize, null);


Initialize Signature in constructor or make it unusable

Like PublicKey_ctor, Signature_ctor allocates a Signature without initialization while exposing a public JS constructor. new blst.Signature() therefore produces an object backed by uninitialized memory; calling toBytes*() or passing it into verify() will read garbage bytes and can lead to incorrect verification results. Consider zero‑initializing or throwing in the constructor so instances must be created via fromBytes.

Useful? React with 👍 / 👎.

Co-authored-by: Cayman <caymannava@gmail.com>

spiral-ladder self-assigned this Jan 26, 2026

gemini-code-assist Bot reviewed Jan 26, 2026

View reviewed changes

spiral-ladder force-pushed the bing/blst-napi branch from 5f91d82 to b9cd9b8 Compare January 26, 2026 15:14

feat: blst bindings

4bb7e47

spiral-ladder force-pushed the bing/blst-napi branch from b9cd9b8 to 4bb7e47 Compare January 26, 2026 15:15

Merge branch 'napi' into bing/blst-napi

7d54cfc

wemeetagain marked this pull request as ready for review January 29, 2026 16:27

wemeetagain requested a review from a team as a code owner January 29, 2026 16:27

wemeetagain merged commit 21a95cf into napi Jan 29, 2026
1 check passed

chatgpt-codex-connector Bot reviewed Jan 29, 2026

View reviewed changes

spiral-ladder added a commit that referenced this pull request Feb 24, 2026

feat: blst bindings (#192)

f477e52

Co-authored-by: Cayman <caymannava@gmail.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: blst bindings#192

feat: blst bindings#192
wemeetagain merged 2 commits intonapifrom
bing/blst-napi

spiral-ladder commented Jan 26, 2026

Uh oh!

gemini-code-assist Bot commented Jan 26, 2026

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot Jan 29, 2026

Uh oh!

chatgpt-codex-connector Bot Jan 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		const pk = try allocator.create(PublicKey);
		errdefer allocator.destroy(pk);

		const pks = try allocator.alloc(PublicKey, pks_len);
		defer allocator.free(pks);

		import { createRequire } from "node:module";
		import { join } from "node:path";

	expect(() => bindings.blst.Signature.fromBytes(new Uint8Array(95))).toThrow();
	expect(() => bindings.blst.Signature.fromBytes(new Uint8Array(95))).toThrow("InvalidSignatureLength");

	expect(() => bindings.blst.fastAggregateVerify(new Uint8Array(31), [pk], sig)).toThrow();
	expect(() => bindings.blst.fastAggregateVerify(new Uint8Array(31), [pk], sig)).toThrow("InvalidMessageLength");

Conversation

spiral-ladder commented Jan 26, 2026

Uh oh!

gemini-code-assist Bot commented Jan 26, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants