So far, you’ve learned that every SSZ View in Lodestar is backed by a Merkle tree — a structure that allows you to represent and verify data efficiently.

But what if you only need to prove or verify part of an SSZ object — like a specific field inside a large Ethereum state object?

That’s where proofs come in.

1. What Is a Merkle Proof?

A Merkle proof is a compact, cryptographic way to prove that a specific piece of data exists inside a larger dataset — without revealing the entire dataset.

It’s built using a Merkle tree, where:

• Every leaf node represents a piece of data (e.g. a field value)

• Every parent node represents the hash of its two children

• The top node (root) represents the entire dataset

To verify a proof, you only need:

• The root hash of the full dataset, and

• The proof (a minimal set of sibling hashes + the leaf value)

If the proof recomputes the same root, the data is valid

2. Proofs in SSZ and Lodestar

In Lodestar SSZ, proofs let you:

• Generate a Merkle proof for selected fields

• Send or store only those parts (great for light clients)

• Verify or reconstruct the partial object later

Every View in Lodestar comes with methods for working with proofs.

3. Creating a Proof

Let’s create a proof for an SSZ type — the Attestation object.

import { ssz } from "@lodestar/types";

// Create a tree-backed view
const attestation = ssz.phase0.Attestation.defaultView();

// Update a field
attestation.data.source.epoch = 100;
attestation.data.target.epoch = 120;

// Create a proof for only specific subfields
const proof = attestation.createProof([
  ['data', 'source', 'epoch'],
  ['data', 'target', 'epoch'],
]);

console.log(proof);

What this does:

• The proof includes only the paths to those two fields (source.epoch, target.epoch)

• Lodestar automatically collects the necessary sibling hashes

• You can now send this proof object to someone else who just needs to verify those fields

4. Reconstructing from a Proof

Later, someone else can use that proof to reconstruct a partial view of the object:

const partialAttestation = ssz.phase0.Attestation.createFromProof(proof);

// Access included fields
console.log(partialAttestation.data.source.epoch); //  Works

// Access excluded fields
try {
  console.log(partialAttestation.aggregationBits);
} catch (e) {
  console.error(" Field not included in proof");
}

The partial view only contains the fields included in the proof — accessing anything else throws an error.

5. Anatomy of a Proof

A Lodestar SSZ proof is an object that contains:

• type – the SSZ type definition

• gindices – generalized indices for each field (tree positions)

• leaves – serialized field values

• witnesses – sibling hashes needed to recompute the root

You rarely need to inspect these manually, but here’s a conceptual breakdown:

Proof {
  type: Attestation,
  leaves: [
    { path: ['data', 'source', 'epoch'], value: 100 },
    { path: ['data', 'target', 'epoch'], value: 120 }
  ],
  witnesses: [ <hash1>, <hash2>, ... ]
}

6. Verifying a Proof

To verify a proof, Lodestar recomputes the Merkle root from the provided values and sibling hashes, then compares it to the expected root.

const root = attestation.hashTreeRoot();
const proofRoot = partialAttestation.hashTreeRoot();

console.log(root.equals(proofRoot)); // ✅ true if proof is valid

This is the same logic that Ethereum’s light clients and consensus layer use to verify data efficiently without downloading the whole chain.

7. Common Proof Use Cases

8. Proofs + Views: Working Together

Since each Subview in Lodestar represents a subtree, you can create proofs for any nested field simply by specifying the path.

Example:

const proof = attestation.createProof([
  ['data', 'source'],
  ['data', 'target', 'root'],
]);

• ['data', 'source'] → proves the whole source container

• ['data', 'target', 'root'] → proves only one field from target

Subviews make it intuitive to target exactly what you need to prove — no manual Merkle math required.

9. Tips & Gotchas

Summary

Key Takeaway

SSZ proofs let you prove data, not trust it.

With just a few lines of Lodestar code, you can generate and verify Merkle proofs for any part of an Ethereum consensus object — from validator sets to attestations — without handling the full state.

Let’s break it down step-by-step, starting from the basics.

Step 1: What is SSZ?

SSZ (Simple Serialize) is Ethereum’s serialization format.
It defines how Ethereum’s consensus data (like blocks, states, attestations) are stored, hashed, and transmitted.

In Lodestar (a TypeScript implementation of Ethereum’s consensus layer), SSZ data isn’t stored as plain JavaScript objects.
Instead, Lodestar uses Views — special objects that represent SSZ data along with its Merkle tree.

This helps:

• Make updates efficient (only re-hash the changed part of the tree)

• Support proofs (Merkle branches)

• Keep large data structures consistent

Step 2: What is a View?

A View is Lodestar’s in-memory representation of an SSZ value.

• It behaves like a normal JavaScript object (you can get/set properties).

• But under the hood, it’s backed by a Merkle tree (a hash-based data structure).

  (If you are not sure what merkle trees are or merkleization , I will post a beginner friendly article explaining those concepts in details.)

There are two main kinds:

You create views like this:

import { ssz } from "@lodestar/types";

const attestation = ssz.phase0.Attestation.defaultView();

Now attestation is a View of type Attestation.

Step 3: What is a Subview?

A Subview is a nested view — a field inside another view that’s itself a complex SSZ object.
Think of it as a branch inside a bigger Merkle tree.

Example:

const attestation = ssz.phase0.Attestation.defaultView(); //the main view

attestation.data      // ← This is a subview
attestation.data.source  // ← Another subview
attestation.signature // ← Not a subview (it's a byte vector)

Visually, you can think of it like this:

Attestation (root view)
├── aggregationBits (basic type)
├── data (Subview)
│   ├── source (Subview)
│   │   ├── epoch (basic type)
│   │   └── root (basic type)
│   └── target (Subview)
└── signature (basic type)

In Lodestar, each nested SSZ type (like a container, list, or vector) automatically becomes a subview.

Step 4: Why Do We Need Subviews?

Subviews make it possible to work with parts of large SSZ structures efficiently — without touching or re-hashing the entire thing.

Let’s see what this means in practice.

1⃣ Work with Nested Data Efficiently

Instead of treating an entire object as a single blob, you can zoom into just one part.

// Create an attestation view
const att = ssz.phase0.Attestation.defaultView();

// Change a nested field deep inside
att.data.source.epoch = 10;

Under the hood, Lodestar:

• Updates only the source branch of the tree

• Re-hashes just the affected nodes

• Updates the root automatically

No need to rebuild the whole object.

2⃣ Replace or Reuse Subtrees

Subviews let you copy or replace entire parts of a structure easily.

Example:

const att1 = ssz.phase0.Attestation.defaultView();
const att2 = ssz.phase0.Attestation.defaultView();

// Copy `data` from att1 to att2
att2.data = att1.data;

Here you replaced the entire data subtree — including source, target, and everything under it — in one line.
This is much faster than serializing/deserializing plain JS objects.

3 Support for Merkle Proofs

Subviews are essential for Merkle proofs, since they represent subtrees.

For example:

const proof = attestation.createProof([
  ['data', 'source', 'epoch']
]);

Here, Lodestar knows exactly how to navigate the tree to isolate data → source → epoch — because each is a subview pointing to a subtree.

Step 5: Subview Independence — View vs ViewDU

There’s a subtle but important behavior difference between TreeView and TreeViewDU when it comes to subviews.

TreeView (Immediate Update)

Each subview is independent.
If you assign one subview to another, Lodestar copies the data, but they don’t stay linked.

const c1 = C.toView({ a: [0, 0] });
const c2 = C.toView({ a: [1, 1] });

// Copies data — not linked
c1.a = c2.a;

// Changing c1 doesn’t affect c2
c1.a.set(0, 5);
console.log(c2.a.get(0)); // still 1

TreeViewDU (Linked Cache)

In TreeViewDU, subviews share mutable caches for performance.
So assigning one subview to another links them until you commit.

const c1 = C.toViewDU({ a: [0, 0] });
const c2 = C.toViewDU({ a: [1, 1] });

// Now both reference the same cache
c1.a = c2.a;

// Mutations affect both
c1.a.set(0, 5);
console.log(c2.a.get(0)); // 5

That’s because DU views prioritize speed and batching over isolation.
Changes stay in cache until you finalize them with .commit().

Step 6: When to Use Subviews

Example Recap

Here’s a quick end-to-end example showing subviews in action:

import { ssz } from "@lodestar/types";

// Create a tree-backed view
const att = ssz.phase0.Attestation.defaultView();

// Work with nested data (subviews)
att.data.source.epoch = 5;
att.data.target.epoch = 8;

// Replace a subtree
const newData = ssz.phase0.AttestationData.defaultView();
newData.source.epoch = 10;
att.data = newData;

// Create a proof using subviews
const proof = att.createProof([
  ['data', 'source', 'epoch'],
]);

console.log(att.hashTreeRoot().toString());

In Summary

Key Takeaway

A Subview is just a “view within a view” — a nested SSZ structure you can access and manipulate independently.
It’s the bridge between Lodestar’s Merkle trees and the object-oriented way TypeScript developers write code.

Thank you for taking your time to read through this article and if you have any question feel free to reach out. More resources on SSZ here.

An old video but still important/relevant.

I used to wonder, why does the structure of some functions appear to take parameters twice or include parameters in different position. I did a lil digging and here's what I found.

Solidity, the programming language for writing smart contracts on Ethereum and other blockchain platforms, has a unique syntax that can be confusing for beginners. One area is the structure of functions, especially when parameters seem to appear twice or are placed in different positions. This article will break down the structure of Solidity functions and explain why this happens in simple terms.

function functionName(parameterType parameterName) visibility modifier returns (returnType) {

    // Function body

}

• functionName: The name of the function.

• Parameters: Declared in parenthesis (parameterType parameterName) immediately after the function keyword.

• Visibility: Defines who can call the function (e.g., public, private, internal, external).

• Modifiers: Keywords that alter the behavior of the function (e.g., payable, view, pure, or custom modifiers).

• Returns: Specifies the type of value(s) the function will return.

When this happens it's usually due to the following reasons:

Modifiers in Solidity are reusable pieces of code that can add functionality to functions. Modifiers can also take arguments, which are separate from the function’s parameters.

modifier onlyOwner(address _owner) {
      require(msg.sender == _owner, "Not the owner");
  _;
}
function updateOwner(address _newOwner) public onlyOwner(msg.sender) {
//function body
} 

• • The onlyOwner modifier takes _owner as a parameter.

  • The updateOwner function has its own _newowner parameter.

The parameters of the modifier and the function are independent but may seem repetitive because they serve different purposes.

When Contracts are inheriting other contracts, they can sometimes override functions from the parent contract. When this happens the overriding function should match the parents functions signature including the parameters.

Example

contract Parent {
     function something(uint x) public virtual return (uint)
            return Y +1;
    }
}
contract Child is Parent {
     function something(uint x) public overide returns (uint) {
           return Y + 2;
}

something function in Child matches the parameter (uint x) of the parent function in Parent. this makes sure that the child contract will follow the parent's interface.

In Solidity, the placement of parameters, visibility, and modifiers is part of the language’s syntax. Here’s the order:

• Function Parameters: Always declared first, directly after the function keyword.

• Visibility and Modifiers: Come after the parameters to define who can call the function and its behavior.

• Return Parameters: Declared after the returns keyword, specifying the type of value(s) the function will return

I am yet to fully understand this but this is what I gathered.

Sometimes you will find low-level functions like call or delegate call. They are basically functions that interact with other contracts and they use encoded parameters that will look different from regular parameters.

Example.

(bool success, bytes memory data) = address(otherContract).call(
    abi.encodeWithSignature("doSomething(uint256)", 123)
);

Parameters for the Something function {i wrote on the previous example} are passed via abi.encodeWithSignature.

The call function itself has its own parameters and return values.

• Start Simple: Focus on understanding basic function structures before diving into modifiers and low-level calls.

• Read the Documentation: Solidity’s official documentation is a great resource for learning the syntax and features. READ DOCUMENTATION!!

• Practice: Build small contracts to experiment with different function structures and see how they behave.

• Ask Questions: Don’t hesitate to seek help from the Solidity community or forums when you encounter something confusing.

The structure of Solidity functions is designed to be logical and flexible, even if it seems complex at first. By understanding how parameters, visibility, modifiers, and return types fit together, We can write clear and effective smart contracts. We should keep practicing, and soon this will become second nature!

KEEP BUILDING.

The ETH Safari Hackathon was my first real deep dive into Web3 development. I attended numerous workshops, eager to soak up knowledge. One of these workshops was led by the Base team, featuring Elisha, Dami, and another expert whose name escapes me (apologies!).

I had set my sights on the zkSync and Graph bounties, so I was laser-focused on learning those tools. However, the Base workshop stood out. The way the mentors taught was nothing short of amazing—clear, engaging, and beginner-friendly. As someone new to Web3, I was astonished at how much I could grasp and implement after just afew session. Their teaching style was a breath of fresh air compared to a previous hackathon workshop I had attended, which was… let’s just say less than stellar. So that is how I met Base. After the worksho that was it. I went ahead and continued working with the zksync plugin.

A special shoutout to the zkSync/web3.js mentor - Santiago Trujillo, who was incredibly supportive and willing to help. Anyone who worked with him would agree! H e laid the foundation for my web3 Knowledge.

The contrast between these experiences was striking, and it made me appreciate the Eth Safari team’s efforts even more.(Technical mentors)

Fast forward to the Base Buildathon—an event I was not going to miss{ A chance to build on base and learn more about web3, bet) . Determined to learn more about Web3 and Base, I attended every workshop. And when I say attended, I mean I traveled two hours to the venue and was among the first to arrive every single day. Yes, I’m that proud of myself! 🙂

This time, I invited my partner from ETH Safari to join me. We decided to build our solution on Base, and I worked on not one but two applications:

1. Afida: A crowdfunding platform.

2. Miniminds: A decentralized application aimed at kids aged 4 to 17. It incorporates crowdfunding to provide quality education to children in developing countries. (there is more to it)

Before I dive deeper, let’s talk about Base itself. It’s an Ethereum Layer 2 solution designed to make transactions faster and cheaper while maintaining the security of the Ethereum mainnet. Built using Optimistic Rollups, Base offers EVM compatibility, making it easy for developers to port their existing projects. What really sets Base apart, though, is its developer-first approach and community support—qualities I experienced firsthand during the Buildathon.

Unlike hackathons, buildathons emphasize continuity. After the event, my partner and I continued working on Miniminds. This application holds a special place in my heart because of its potential to make a real difference. By providing quality education to underprivileged kids, Miniminds aims to create opportunities and foster innovation in developing countries.

We’re still refining the application, but the dream is to push it to production eventualyy. I’m excited for the day you’ll see Miniminds on your screen, helping kids across the globe access the education they deserve and at the same time earn as they learn. We are also giving teachers a chance to showcase their work , control their work and earn as they teach.

The base meetup.

After the buildathon the base meetup happened and I got a chance to meet the base team including the founder . At the same time I met may like minded developers. Seeing an interactive community ready to help it inspired me to continue building on base. Even though we did not win the buildathon, I believe in the future miniminds will make a great difference, changing the life of students, teachers and how we view education in general.

Looking back, my journey with Base has been trans-formative. From the ETH Safari Hackathon to the Buildathon, I’ve grown not just as a developer but as a problem-solver and visionary. Base has been more than a platform for me; it’s been a catalyst for creativity and collaboration.

As we continue to build Miniminds, I invite you to follow along. The journey is far from over, and the best is yet to come. Stay tuned, because the future of Web3 is bright—and we’re building it together.