Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

Latest commit

 

History

History
61 lines (35 loc) · 4.7 KB

LACChain_topology.md

File metadata and controls

61 lines (35 loc) · 4.7 KB

LACCHAIN TOPOLOGY

The purpose of this documentation is to provide an overview of the LACChain Networks's topology.

Topology

The nodes of LACChain networks can be classified into two groups, according to their participation in the maintenance of the network. In each of these two groups there are also two different types of nodes, according to the specific role of the node in the network.

In the following image we can see the topology and connections between the different types of nodes.

LACChain Topology

Core nodes

Core nodes play an essential role in guaranteeing correct functioning of the network. The network cannot work without them. Core nodes are classified into validator and boot nodes

  • Validator nodes

Participate in the consensus protocol and are responsible for the generation of new blocks. Validator nodes must only connect to each other and to the boot nodes. Validator nodes are not allowed to reject or ignore any transaction without notifying the LACChain Permissioning Team. If a transaction is not valid according to the network rules, they must reject it. If a block proposed by another node contains invalid transactions, they must report it.

  • Boot nodes

Act as a liaison between validator and satellite nodes, which implies that:

  • They onboard new nodes by sharing the history and state of the blockchain with them in the first place. The state of the blockchain includes information about the other nodes in the network, routing rules, and whitelists and blacklists.
  • They must listen to the writer nodes and pass along the transactions broadcasted by the writers to the validator nodes.
  • They update the satellite nodes about new blocks generated by the validator nodes.

Boot nodes must be connected to all validator nodes and to the writer nodes they are assigned to.

Satellite nodes

Satellite nodes do not play an essential role in guaranteeing the network. The well-functioning of the network does not depend on satellite nodes, so they can join and leave the network with no consequences. Satellite nodes are classified into writer and observer nodes:

  • Writer nodes

Allowed to broadcast transactions to the network. These nodes generate traffic in the network, usually coming from apps, DApps, end users and other types of services:

  • They communicate transactions to the boot nodes, who then pass the transactions along to the validator nodes.
  • They can establish private channels and side-chains between one another for private communication, for which they can leverage native tools in the network.
  • They can share public documents and information using native decentralized storage in the network.

Writer nodes can only be connected to boot nodes and to other writer nodes.

  • Observer nodes

Can only read the blockchain. They can join the network by connecting to boot nodes that are open for the purpose of reading the blockchain and are maintained by the LACChain Technical Team. No permissioning requirements should be imposed on entities or individuals running observer nodes, as the network is public. Additionally, these nodes cannot broadcast transactions nor generate blocks, so they cannot cause any harm.

Motivation

This topology is motivated by two fundamental reasons, a technological one and a legal one.

The technological basis for this specific topology is that separating the nodes that generate blocks (validators) from the nodes that broadcast transactions (writers) allows validator nodes to be more isolated because they do not need to be directly exposed to apps, DApps, end users, or other services, and their peer connections are limited to other validators and boot nodes.

The legal basis for this specific topology is that, from a regulatory perspective, having a network of servers connected through TCP/UDP connections, which are well-known transport protocols, cannot possibly violate any law. Instead, transactions that contain data and information and are registered immutably in all these interconnected servers need to be looked at from a regulatory perspective. In a blockchain network, the data and information shared, which come from the applications on top of it, and not the ledger itself, need to be regulated and/or compliant with regulations.

The rationale discussed in the two paragraphs above leads to the following breakdown of regulatory compliance: a number of validator and boot nodes across the world that are only connected with each other though Internet but that do not hold any data make up a regional blockchain which is perfectly compliant with regulation. Complementarily, each writer node that broadcasts data should be entirely accountable for those broadcasts and should acquire liability associated with it.