Author: @Daniel Sanchez Quiros

Introduction

The Nomos Explorer is an external component separated from the main node to access the Nomos network information without the need to run a full node. This decision focused on making the node as lightweight as possible. Hence the Nomos explorer is the counterpart of the Nomos node. Its main purpose is to keep track of what is going on in the network and pile up services exposing that information in a modular fashion.

How does it work

The Nomos explorer will read data from the different Nomos networks

• Reads blocks from the Nomos validator public network
• Reads Txs from the Nomos validator public network

flowchart RL
    B[Validator Network] --> |Blocks| A[Explorer]
    B[Validator Network] --> |Txs| A[Explorer]

The nomos explorer will serve an API on top of a locally constructed (and validated) database. Additionally, it may host a frontend for interacting with that API in different ways:

• Web frontend explorer with data visualization
• Slots/Epochs real-time visualization
• Search engine for querying the local DB

  • Transactions:

    • We access the chain information of accepted txs and the mempool information of pending ones.

  • Blocks

    • We read live blocks from the public network. Blocks are verified in the same fashion a validator would do (we can probably skip sampling?, because that information is not really valuable here, and the explorer opinion on sampling doesn’t modify anything). Only validated blocks are added to the local storage.

  • Forks

    • We build a local global view of the whole network by reading the blocks broadcasted into the public network. We can show the DAG of all forks happening and use the same fork_choice rule the validators use to build a live representation of the probability for each of the forks to be accepted. We can use the same measurements to show the the pruning probabilities of the branches themselves. This information may not be completely accurate as we do not really know what the majority of validators will follow. But it would converge with time (at least for the current rule of the longest chain).

    graph LR
        A((Genesis)) --> B1((1))
        B1 --> B2((2))
        B2 --> B3((3))
        B3 --> C1((C1))
        B3 --> D1((D1))
        B3 --> E1((E1))
        
        C1 --> C2((C2))
        
        D1 --> D2((D2))
        D2 --> D3((D3))
        D3 --> D4((D4))
        D4 --> D5((D5))
        D5 --> D6((D6))
        D6 --> D7((D7))
        D7 --> D8((D8))
        
        E1 --> E2((E2))
        E2 --> E3((E3))
        E3 --> E4((E4))
        E4 --> E5((E5))
        
        C2 -.- |43%| C2
        D8 -.- |96%| D8
        E5 -.- |68%| E5
    

Explorer flow overview

sequenceDiagram
    loop Read Blocks
        Network->>Explorer: Blocks
        Explorer->>Explorer: Validate Block and store
    end
    loop Read Txs
        Network->>Explorer: Tx
        Explorer->>Explorer: Keep track of pending and approved txs
    end
    loop Serve data
        User->>+Explorer: Request information
        Explorer->>-User: Serves information
    end

Internal architecture

We can consider the Nomos explorer a kind of light node that validates what is happening in the Nomos networks and adds the information into the locally constructed databases.

flowchart LR
    E[Explorer] -->|Blocks| D1[(SQL)]
    E[Explorer] -->|Txs| D1[(SQL)]
    E[Explorer] -->|Forks| D2[(Neo4j)]
    F(Frontend) -.-> E[Explorer]

It uses: