Lodestar Zig Roadmapping Discussion #4

[philknows]

Meeting Info

September 18, 2025, 15:00-16:00 UTC
Google Meet: https://meet.google.com/pvh-xobi-nev

Agenda

• Open Discussion
  • State-transition-Z
  • Spec test development
  • TreeView
  • TBD

Instructions

Please post here any topics to be added for Standup discussions. Examples of agenda items are issues, discussions, proposals which require feedback, consensus from the team and/or community members.

[philknows]

@spiral-ladder will be walking through some of the new Zig code and giving thoughts on things like structure, code organization, style, correctness as it pertains to our current Lodestar implementation. The idea is to set and give everyone a baseline of expectations when reviewing our naive rewrite for the Zig work we continue doing.

We will then see how we can break up the PR for review between reviewers.

In addition, if we have time, there are some premature conversations we can get into about problems we may expect in the future and how to potentially prepare for them:

• Code debugging methods/tools post-nodeJS
• Prometheus metrics implementation in Lodestar Bun

These are just conversations that have come up recently with some of you guys.

[spiral-ladder]

To add more details on the above + some points touched upon in my private conversations with @wemeetagain and @twoeths:

I will most likely aim to spend 15-20minutes maximum going through the PR, with focus on:

1. Code organization and structure,
2. Correctness versus the current production Lodestar.

I think these are what matter the most at the moment - for more opinionated matters like code style/style guide, we can adjust along the way. The goal for this first review is to ensure the correctness of the naive state transition implementation.

Some open questions:

1. Memory allocation - Could we adopt a policy of minimal dynamic memory allocation? To be specific, we might statically allocate as much as possible on startup (which is a method that Tigerbeetle uses). A purely static allocation on startup is probably impossible due to the persistent long-running nature of the client with validators dropping in/out, but we could perhaps have a policy where we statically allocate whatever is possible to be statically allocated, and design our data structures around that approach.

2. Refactoring opportunities - @philknows mentioned some long standing refactor work that was dragged on for a while in production Lodestar - if there are any such similar cases, I think this could be a good chance to fix those issues on a rewrite, and is in line with our idea that we shouldn't be afraid of making big changes even on a first rewrite.

[philknows]

Notes captured in: https://github.com/ChainSafe/lodestar/wiki/Lodestar-Zig-Roadmap-Discussions#lodestar-zig-roadmap-discussions-4--setepmber-18-2025
Closing for #8438