Dev Update Week 6: Taming the Go Runtime for Bare-Metal RISC-V

# Dev Update Week 6: Taming the Go Runtime for Bare-Metal RISC-V **Developer:** Developeruche **Week Ending:** July 25, 2025 ### Summary Following last week's analysis which highlighted the complexity of the Go runtime as a major hurdle for zkVMs, this week was dedicated to a two-pronged attack to simplify its behavior. First, I successfully compiled the Geth `t8n` tool for a **bare-metal RISC-V target** using the Tamago toolchain, proving it's possible to decouple Go from a full Linux OS. Second, I developed a strategy to constrain the standard Go runtime by disabling garbage collection and forcing single-threaded execution, then captured a new, simplified syscall profile. This work demonstrates a viable path to running complex Go applications like Geth in a resource-constrained, verifiable environment. ### Accomplishments This Week * **Bare-Metal Go Compilation:** I successfully used the Tamago Go compiler extension to compile the Geth `t8n` tool into a bare-metal RISC-V binary. This is a significant breakthrough, as it removes the dependency on a host Linux OS and its complex ABI, a major step towards zkVM compatibility. * **Go Runtime Constraining:** I devised and executed a method to dramatically simplify the Go runtime's behavior. By using the `GOMAXPROCS=1`, `GOGC=off`, and `GODEBUG=asyncpreemptoff=1` environment variables, I forced the application into a single-threaded, non-preemptive execution model without garbage collection. * **Simplified Syscall Analysis:** I ran the constrained Geth binary with `strace` to capture a new syscall log. This experiment is designed to provide a direct comparison against last week's profile, with the goal of quantifying the reduction in complex syscalls (like `clone`, `futex`, and `rt_sigaction`). * **Documented a Repeatable Workflow:** I documented the full toolchain setup, including the specific Tamago build commands and the QEMU environment configuration. This creates a reproducible process for compiling and testing bare-metal or constrained Go applications for RISC-V. ### Next Steps & Goals for Next Week With a new, simplified syscall profile in hand, the next steps are to analyze the results and push the bare-metal exploration further. 1. **Analyze the Constrained Syscall Log:** I will perform a detailed analysis of the new `geth_strace.log`. The primary goal is to quantify the reduction in syscall complexity and confirm the elimination of threading and signal-related calls, providing a much smaller target for our zkVM's `ECALL` dispatcher. 2. **Execute the Bare-Metal Binary:** The next critical step is to attempt to run the Tamago-compiled bare-metal binary in a minimal QEMU environment. This will reveal the binary's true, minimal dependencies and determine what, if any, host services are required for it to function. 3. **Update the zkVM Syscall Design:** Based on the findings from the constrained log, I will update the design for the zkVM's syscall handler. This will likely lead to a more refined and achievable "Advanced Tier" of support, specifically tailored for constrained Go applications. ### Challenges & Learnings * **Challenge: Specialized Toolchains:** Setting up a cross-compilation environment with Tamago for a bare-metal RISC-V target was a complex but rewarding challenge. It required a deep understanding of compiler toolchains and build flags. * **Learning: The Go Runtime is Not a Monolith:** This week's key insight is that the Go runtime is highly configurable. We are not forced to support its full, complex feature set. By strategically disabling features like the GC and scheduler, we can dramatically reduce its footprint and make it a viable target for a zkVM. * **Learning: A Clear Path to Eliminating the OS:** Successfully compiling a bare-metal Geth binary proves that we can break the hard dependency on a full Linux kernel. This simplifies the zkVM's task from "emulate Linux" to "provide a handful of essential services," which is a far more achievable goal. * **Learning: Configuration Over Emulation:** This work reinforces a powerful design principle for our zkVM: it is far easier to constrain the guest application's behavior through configuration than it is to build a complex, all-encompassing emulation layer. https://github.com/eth-act/riscv-compilation/tree/main