Moonia's Builder Journey

[moonia]

Hello, I'm Mounia 👋

I'm a French developer and a third-year student at Epitech Paris. I enjoy programming in C, TypeScript, Rust and Golang (for a little while now).

Thanks to my freelance work and personal projects, I’ve built a strong background in web development and DevOps. I'm also interested in blockchain! I’m still new to the field and don’t know much yet, but I’m really motivated to learn more and deepen my understanding.

I'm currently part of the Epitech student program, where my friends and I are contributing to Gno.

In this issue, you’ll be able to follow my journey over the next 4 months — until July 31st. ✨

[moonia]

Activities from Last Week

• Explored Gno.land: Reviewed its documentation, workshops and examples.​

• Reviewed documentation and watched videos to understand GRC-20 tokens and DAOs.

• My Home Realm here : Implemented a mini cookie fortune feature with a custom random function and a basic voting system.​

• Also, started a Custom voting DAO here or Draft pr here : Began creating a simple DAO with fundamental methods.​

Plans for This Week

• Complete DAO Methods: Aim to finalize the implementation of all methods in my DAO.​

• Implement Custom GRC-20 Token: Management of token flows (minting, transferring, burning) and governance.

• Develop Contributor Compensation Project : Consider creating a system where contributors are compensated within the DAO (e.g., 1 hour = 1 token over a chosen period) to reduce salary waiting times and enable progressive receipt.

[moonia]

Activities from Last Week

This week, I completed the full implementation of my DAO and added all the remaining methods.
It’s now possible to :

• create multiple DAOs
• view a dashboard listing all existing DAOs
• track statistics for each one
• close votes based on a chosen time period
• manage admin rights — for example, by accepting or rejecting new members.

I also addressed the improvements suggested by Léon in the PR comments and updated my code accordingly.

Reminder: Draft pr here

Finally, I also implemented my own GRC-20 (a minimal version), using this p and this video as a reference. I'm currently finalizing the unit tests for my GRC.

[moonia]

This week, I started working on the Gno EVM implementation alongside @paulogarithm and @Tchips46. For the moment, I’ve already started implementing some EVM opcodes like PUSH and SWAP.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

We also started working on the flamegraph issue implementation on Gnodev with @paulogarithm. It's currently on pause while we focus on the EVM issue, but here's the repo.

[moonia]

This week, @paulogarithm, @Tchips46 and I got real bytecode execution working — real opcodes, real output. Our EVM is now Turing complete and supports nearly all opcodes.

Next, I’ll focus on EVM-dependent opcodes and mocking them to minimize behavior differences with real contracts. I also plan to add more opcodes and release an r/ version so Gno users can run bytecode freely.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

[moonia]

This week, I worked with @paulogarithm and @Tchips46 on the Gno EVM. Our implementation now runs Ethereum contracts, supports all storage types, and is integrated into /r/demo/evm for transaction visualization.

We're now focusing on the most complex opcodes and refactoring the account logic to properly handle smart contracts as accounts.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

[moonia]

This week, I continued working on GnoEVM by adding many tests. I also kept thinking about the flamegraph issue and continued implementing it in gnodev as a flag. I also improved its execution speed performance.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

[moonia]

Activities from Last Week

I fully integrated the flamegraph feature into gnodev as a subcommand. It now accepts parameters like --bin, --duration, and --output, and generates much more readable flamegraphs using flamegraph.pl.

I also fixed several logic issues around sleep timing, resulting in significantly improved speed and overall reliability.

The command supports profiling compiled Go binaries and automatically produces a cpu.pprof file that is turned into a flamegraph SVG. This makes it much easier to run and visualize performance diagnostics locally.

Example:

PR:

• feat(#4130): Profiling Support for GnoVM (pprof + Flamegraph) gno#4330

Next steps?

With @paulogarithm, we're now considering the next steps based on discussions in the related issue:

• Should we move the profiler into a separate tool, like in a "contribs/profiler" for example?

• Or should we only focus on providing a make profile makefile command?

--

A possible next step could also be to profile the gnovm binary while it executes a .gno file.

Would that be a valid approach to start testing the performance of actual Gno programs?

[moonia]

Activities from Last Week

🚀 Gno EVM

This week, I continued working on GnoEVM by adding some new opcodes such as BASEFEE, BLOBHASH, BLOBBASEFEE, COINBASE. Along with this, I wrote some tests and updated the documentation accordingly.

I’m currently finalizing the implementation of the BLOCKHASH opcode that retrieves the hash of a given block among the last 256 blocks. If the block number is invalid, it returns 0.

The EVM implementation is almost complete. Once finished, @paulogarithm and I will fully focus on the flamegraph issue. We are now working on finalizing the remaining opcodes.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

Internship report

Last Friday, I had a working session with @Tchips46 and @paulogarithm, mainly dedicated to advancing our internship report.

It's structured into two parts, and the first part is particularly important because its goal is to create a document that provides clear onboarding for future contributors.

This detailed guide (aiming for at least 3000 words) should make it much easier for new contributors to understand how to get started and actively participate in the Gno ecosystem.

[moonia]

🚀 Flamegraph

Last week, with @paulogarithm, we started experimenting with some instrumentation inside the GnoVM to better understand how opcodes are executed.
For each opcode, we're tracking:

• how many times it's executed
• how much total time it takes (in nanoseconds)
• and where in the original .gno source code it was triggered

We're modifying the GnoVM directly and getting more familiar with the codebase as we go. (Still very much in testing mode)

BTW, we're aligning our approach with Marc's recommendations on the profiling issue for gno files:

PR:

• feat(#4130): Profiling Support for GnoVM (pprof + Flamegraph) gno#4330

🚀 Gno EVM

I also added some remaining missing opcodes such as BlockHash, ExtCodeHash, Balance, Address,Origin and we’ve made some changes based on Marc’s feedback on the PR.

PR:

• feat: add p/demo/evm (ethereum vm) gno#4187

[moonia]

Hello!

This week, I’ve been working with @paulogarithm on the flamegraphs implementation for the GnoVM.

We’re currently in a research phase focused on deepening our understanding of how the GnoVM works internally, as well as the fundamentals of profiling. We had a very helpful call with Mark, which really helped us clarify our approach and align on the next steps.

As a first milestone, we started by inspecting the VM’s behavior through direct modifications to the Gno source code. This allowed us to begin instrumenting the runtime to identify each opcode during execution and collect key metrics such as cumulative execution time, memory allocations, frequency, etc.

PR:

• feat(#4130): Profiling Support for GnoVM (pprof + Flamegraph) gno#4330

We’re now moving on to the next step:

• Resolve the CI errors
• Mapping each executed opcode to a precise location in the code (both at the bytecode and source code level)
• Convert the profiling data from Gno files into a .pprof

[moonia]

Hi,
This week, for the Flamegraph project, I focused on mapping opcodes to the source code. We spent quite a bit of time figuring out the best way to perform this mapping in a clear and effective way.

We're currently using the following structure:

type OpTrace struct {
    Op        Op       // The opcode that was executed
    SourcePos Position // Position in the source code (line/column/file)
    IndexOp   int      // Index in the Ops slice (program opcode array)
    FuncName  string   // Name of the current function being executed
}

At the same time, I started refactoring a large portion of the code and removed all the previous versions of the project to clean things up.

Lastly, the internship report is now done! I maybe need to send it to someone now for review so we can wrap that up as well.

[moonia]

Hi!

Last week, I attended ETHCC in Cannes and it was absolutely amazing! 🇫🇷

I learned so much more about blockchain technology and it made me even more excited to dive deeper. I also went to the event organized by the Samuraï Crew, which I really appreciated because I discovered how to blend the blockchain world and DAOs with art.

--

I also have been working on the flamegraphs again and made some good progress.

I was able to fix the opcode allocations (for now) using estimations. The reason I'm using estimations is that implementing precise memory tracking would be quite complex and would require significant architectural changes to the VM. It would involve instrumenting every allocation point in the runtime, tracking object lifetimes, and correlating them with specific opcodes.

I also successfully mapped the opcodes to the source code as shown below.

I can now generate output like:

... 

Hello 4
[TRACE] Opcode=OpReturn           | Index=100 | Func=println              | tests.gno:101 | CPU=  38 | Alloc=16 | Count=5
[TRACE] Opcode=OpPopResults       | Index=101 | Func=<unknown>            | tests.gno:102 | CPU=   1 | Alloc=8 | Count=5
[TRACE] Opcode=OpAdd              | Index=106 | Func=<unknown>            | tests.gno:107 | CPU=  18 | Alloc=0 | Count=5
[TRACE] Opcode=OpAssign           | Index=107 | Func=<unknown>            | tests.gno:108 | CPU=  79 | Alloc=16 | Count=5
[TRACE] Opcode=OpBody             | Index=113 | Func=main                 | tests.gno:114 | CPU=  43 | Alloc=32 | Count=2
[TRACE] Opcode=OpExec             | Index=114 | Func=main                 | tests.gno:115 | CPU=  25 | Alloc=48 | Count=2
[TRACE] Opcode=OpReturnFromBlock  | Index=115 | Func=main                 | tests.gno:116 | CPU=  36 | Alloc=16 | Count=1

Opcode               | Count      | Cumulative CPU  | Alloc (KB)
----------------------------------------------------------------------
OpDefine             | 1          | 111             | 0.03      
OpForLoop            | 11         | 297             | 0.26      
OpReturn             | 5          | 190             | 0.08      
OpAdd                | 5          | 90              | 0.00      
OpAssign             | 5          | 395             | 0.08      
OpEval               | 179        | 5191            | 5.59      
OpFieldType          | 28         | 1652            | 0.66      
OpStaticTypeOf       | 12         | 1200            | 0.28      
OpMapType            | 2          | 118             | 0.09      
OpPopResults         | 5          | 5               | 0.04      
OpPopBlock           | 64         | 192             | 0.50      
OpSliceType          | 10         | 550             | 0.31      
OpBody               | 2          | 86              | 0.06      
OpReturnFromBlock    | 1          | 36              | 0.02      
OpPrecall            | 6          | 1242            | 0.23      
OpCall               | 6          | 1536            | 0.47      
OpExec               | 2          | 50              | 0.09      
OpLss                | 6          | 78              | 0.00      
OpCallNativeBody     | 5          | 2120            | 0.47      
OpInterfaceType      | 55         | 4125            | 2.15      
OpFuncType           | 19         | 1539            | 0.89      
----------------------------------------------------------------------
TOTAL                | 429        | 20803           | 12.30     

The code is still quite messy at the moment, but I'll work with Paul to clean it up and properly fix the allocations before moving on to generating the pprof file.

[moonia]

This week, I moved on to generating a profile in pprof format. I successfully produced a functional dump that includes metrics like cpu/cycles, alloc/bytes, and count/calls, all correlated with source code lines using the traces implemented earlier.

✅ What’s working well:

• Initial pprof export is complete, with a valid header (PeriodType, Time, Samples, Locations, Mappings, etc.).

• Samples are aggregated by PC, and correctly mapped to .gno source files and line numbers.

• Stack traces for functions appear properly in the profile.

⚠️ What still needs work:

• Several entries are still marked as Func=<unknown> in both the TRACE output and Locations, even though the line of code is correctly identified.

Hypothesis: There might be an issue with PC to function mapping (because of a bad offset ?).

Here, an example of a pprof profile (txt format):

// header

PeriodType: cpu ns
Period: 1
Time: 2025-07-10 21:53:20.032642 +0200 CEST

//  Samples section with cpu, alloc, count

Samples:
cpu/cycles  alloc/bytes  count/calls
       5191       5728        179: 1000 
       4125       2200         55: 1001 
        192        512         64: 1002 
       5191       5728        179: 1002 
       1539        912         19: 1003 
       1652        672         28: 1004 
       5191       5728        179: 1005 
       5191       5728        179: 1006 
       4125       2200         55: 1007 
       1652        672         28: 1008 
       1539        912         19: 1009 
        192        512         64: 1010 
       5191       5728        179: 1000 
       1539        912         19: 1001 
        192        512         64: 1002 

 ...

// Link samples to specific functions and source lines

Locations
  1113: 0x0 M=1 main tests.gno:114:0 s=1()
  1040: 0x0 M=1 println tests.gno:41:0 s=1()
  1079: 0x0 M=1 println tests.gno:80:0 s=1()
  1060: 0x0 M=1 println tests.gno:61:0 s=1()
  1082: 0x0 M=1 <unknown> tests.gno:83:0 s=1() // here is an example of my unknown problem

...

// Tell where code is loaded in memory -> profilers can match addresses to files

Mappings
1: 0x1000000/0x2000000/0x0 gno-vm gno-profiler [FN][FL][LN][IN]