Components

The Components of the Node

The REST API

TODO

The Messenger

TODO

Interceptors

• ☐ Interceptors: Interceptors listen to channels based on the topology of the Network - there is a Topic & Interceptor for each pair of sender-receiver Shards
• ☐ Interceptors: there are dedicated Interceptors on consensus-specific topics

An Interceptor is the component that reacts to the arrival of a Message on a specific Topic. The main role of Interceptors is to add incoming information from the Network into the Data Pool. Note that Interceptors do not react to all Messages: they only react to valid Messages and to Message that arrive on Topics of interest. This means that no Interceptor will react to invalid or uninteresting Messages - such Messages will be automatically dropped.

Because Messages are propagated through the Network in a peer-to-peer manner, Interceptors are invoked by the Messenger. This means that Interceptors must implement the interface p2p.MessageProcessor:

type MessageProcessor interface {
	ProcessReceivedMessage(message p2p.MessageP2P) error
}

The function Interceptor.ProcessReceivedMessage() must therefore perform all the handling required.

Where in the source code are Messages dropped due to being invalid or having uninteresting Topics?

[TODO add list of instantiated Interceptors directly from the Messenger structure at runtime]

Resolvers

• ☐ Resolvers: they send a reply back directly to the requesting Peer (the PeerID is in the Message containing the initial request)

The Data Pool

• ☐ Data Pool: clarify that there's one Data Pool, with multiple sub-pools
• ☐ Notifier (inside Data Pools): reacts to the insertion of a certain piece of information into the Data Pool
• ☐ Notifier (inside Data Pools): if the Node was awaiting a reply with a specific info, it sets a Notifier which saves the newly inserted info into a "Requested info" Data Pool

The Data Pool is a heterogeneous container, present in each Node, which stores information that has arrived through valid Messages from the Network and awaits processing (see how Nodes communicate using Messages). Note that before having their contents stored in the Data Pool, all Messages that arrive from the Network to the Node must have already been validated by Interceptors.

A Node's Data Pool contains not only the information that is vehiculated through the Network and has somehow arrived at the Node, but it also contains information that the Node has requested from its Peers (and they responded).

Here's an example of how a transaction ends up in the Data Pool of a Node, after being propagated to the network:

1. some user in the world wants to call a SmartContract
2. this generates a transaction with a sum of ERD and containing a call to a SmartContract method (see Executing SmartContracts)
3. the Transaction is propagated through the Network by broadcasting it to as many Nodes as possible - every Node, ideally (see the details of peer-to-peer Propagation of information)
4. every Node that hears about this Transaction will store it in its Data Pool, after its Interceptors validate the Message that contains it

There are two types of Data Pools, which contain different types of information, depending on what kind of Node created it. These two types of Data Pools are Sharded Data Pool and Meta Data Pool. See below.

Sharded Data Pool

It is used by Nodes that are part of normal Shards (as opposed to Metashard Nodes).

type PoolsHolder interface {
  Transactions() ShardedDataCacherNotifier
  UnsignedTransactions() ShardedDataCacherNotifier
  Headers() storage.Cacher
  HeadersNonces() Uint64SyncMapCacher
  MiniBlocks() storage.Cacher
  PeerChangesBlocks() storage.Cacher
  MetaBlocks() storage.Cacher
}

Meta Data Pool

It is used by Nodes that are part of the Metashard (as opposed to Nodes in normal Shards)

  type MetaPoolsHolder interface {
    MetaChainBlocks() storage.Cacher
    MiniBlockHashes() ShardedDataCacherNotifier
    ShardHeaders() storage.Cacher
    HeadersNonces() Uint64SyncMapCacher
  }