This is a proposal for introducing a new type of node that provides the same interface as a normal node, but does not perform consensus. It acts as a "relay station" for clients to communicate with.

Motivation

The motivation for creating mirror nodes is that it will quickly allow users to run their own nodes since it would not require swapping. It is also a step in the direction of providing more decentralisation to the system, since these nodes would provide resieliency for the data stored in the DART. Secondly, mirror nodes is the first step in creating further distribution and decentralization of the system since DART synchronization catch-up would need to work and be exercised on a greater scale.

Requirements

The requirements for a mirror nodes is to provide the same external protocols as a full node see Protocols: public hirpcmethods for more information. Therefore the node will also be required to have enough space to store the DART locally.

Documentation for starting a mirror node have to be very well documented such that it is easier to boot.

Proposed solution

The tagionshell can stay the complete same, as it acts as a caching / interface layer. Neuewelle would provide a new switch that can start a mirror node. It might be better to create a new program for mirror nodes but this is something that will have to be discussed. The mirror node works by subscribing to other nodes recorders and constantly updating its own DART and TRT. The nodes that are communicated with would for a start be the ones located in the dart. If the mirror node is behind communication it will start by syncing up before accepting outside requests. This is done via DART synchronization. It will also verify that information is correct while doing so. A new service will have to be responsible for this called DARTSynchronzation.

The switch would also prevent the Transcript from being spawned, since the node does not perform consensus. It will start all other services as these are still important for verifying incoming transactions.
Once a transaction has gone through the TVM and reaches the EpochCreator the transaction will be gossiped to other nodes via their public methods.

Future updates

In the future once the database grows bigger, nodes could also run but only keeping sections of the database backed up. If they get a transaction that requires information from other sectors, they will ask nodes they know have this information.