The purpose of this documentation is to provide an overview of the LACCHAIN Besu Network's topology, architecture, communication protocols and security.
The nodes of LACChain public-permissioned 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.
Core nodes play an essential role in the correct functioning of the network. The network can't work without them. Core nodes are classified into validator and boot nodes.
-
Validator nodes
Validator nodes are those that participate of the consensus protocol. They are responsible for the generation of on new blocks. Validator nodes are only connected to each other and to boot nodes for security and efficiency purposes.
-
Boot nodes
Boot nodes are those that act as a liaison between validator and satellite nodes, which implies that (i) they listen to the writer nodes and pass along to the validator nodes the information about the transactions generated by writers, and (ii) they update the satellite nodes about the new blocks generated by the validator nodes. They are also responsible for setting up new nodes by providing them with a list of active nodes in the network, the latest version of the blockchain, and other relevant information such as whitelists and blacklists. Boot nodes are connected to all the types of nodes in the network.
Satellite nodes do not play an essential role in the correct functioning of the network. The network works without them. Satellite nodes are classified into writer and observer nodes.
-
Writer nodes
Writer nodes are those that can broadcast transations to the network. They communicate the transactions to the boot nodes, that pass them along to the validator nodes. They can also create private channels between themselves for private communication using the Orion private transaction manager. Writer nodes are connected to boot nodes and to other writer nodes.
-
Observer nodes
Observer nodes are those that can only read the blockchain. Observer nodes are only connected to boot nodes.
Note: Observer nodes haven’t been enabled in the LACChain Blockchain Network yet.
LACChain Networks are distributed ledgers aimed to serve as trusted and immutable public-permissioned blockchains to be used by any entity in Latin America and the Caribbean to deploy applications with social impact. Therefore, LACChain Networks are peer-to-peer networks.
For the purpose of the LACChain Global Alliance, peer-to-peer(P2P) architectures present many advantages against client-server architectures:
| Client Server | Peer-to-Peer |
|---|---|
| 1. Server is the central entity and only provider of service and content 2. Network managed by the server 3. Server as the higher performance system 4. Clients as the lower performance system Example: WWW |
1. Resources are shared between the peers 2. Resources can be accessed directly from other peers 3. Peer is provider and requestor 4. Any peer can be removed without loss of overall functionality 5. No central entities Example: Ethereum, LACChain |
In peer-to-peer systems each peer behaves both as a server and as a client. Each peer or client can send and receive data directly from any other peer or client. In blockchain jargon peers are generally called nodes. Each node can request data from it’s own databases, and it can also read from another node’s database.
LACChain Blockchain Network is based on Hyperledger Besu, which is a Ethereum enterprise client. In LACChain Blockchain Network all nodes can request information from other node about the network’s current state (smart contracts, account balance, latest blocks, etc.). Additionally, each node maintains both a synchronized copy of the full ledger and a repository of the smart contracts that have been deployed in the network.
Nodes rely on validator nodes to validate transactions and generate now blocks through the application of the consensus protocol. LACChain Blockchain Network operates with IBFT2.0 consensus protocol.
As LACChain Blockchain Network is based on Ethereum infrastructure, the architecture of the network has two stacks. A Discovery Stack to discover existing nodes in the network and Connection Stack to send messages or communicate with other nodes in the network.
For a P2P network work properly, there must be a good implementation of node discovery that allows a node to discover other nodes that are part of the network. In LACChain Networks, as detailed previously in Section Topology, nodes can have the category of validator, boot, writer or observer.
The discover protocol implemented in LACChain Blockchain Network to build the peer to peer network is based on Kademlia.
Kademlia is a well-defined distributed hash table recognized as a robust standard and protocol. LACChain Blockchain Network inherits from Ethereum the use of the discovery part of the Kademlia protocol.
To begin the discovery process, a node needs an identity. Currently, the identity of the node is achieved through an enodeID, which is then hashed with keccak into a 256-bit value. For more details, you can go to node identity. In the future, LACChain nodes will be using Decentralized Identifiers (DIDs) and Verifiable Credentials (VC) for identification and authentication. In order for a node to get an identity in LACChain Blockchain Network, you can follow the instructions in the README.
Once you have deployed your node, got your identity and followed the administrative steps to be permissioned in LACChain Blockchain Network, you node will start the discovery process.
LACChain uses UDP protocol to exchange information across the P2P network. The steps to achieve the discovery of nodes in the network are the following:
- LIST: When a new node aims to join a network, it needs to be provided with a list of nodes that are already part of that network so it can try to communicate with them. In LACChain Blockchain Network, the addresses of the boot nodes are hard-coded and the list is located at /root/lacchain/orion.conf.
-
PING: The new node sends PING messages to all the boot nodes in the list and expects a PONG message in return. This pair of messages is used to determine whether a neighboring node is responsive.
-
FIND_NEIGHBOURS: As soon as the new node gets PONG messages from responsive boot nodes, it sends a findnode message asking them for a list of 16 nodes of those they are connected to.
-
CONNECT: At present, there is no limit for the number of nodes a new node can be connected to. Eventually, the number will be set to 25. In order to isolate validator nodes from writer and observer nodes for security and efficiency purposes, we are doing research on smart contracts for permissioning managed at a local level for each validator node, so they only whitelist boot nodes and other validator nodes for their communications.
To summarize, the discovery process to join a node to the lacchain network is as follows:
- Get a enode ID.
- Get the list of boot nodes.
- Bond to boot nodes:
- Send Ping
- On Pong do a findNeighbours
- Connect to active nodes
- Table of new node is persisted to minimize bootstrap requirements
Once discovery is successful, nodes can have peer-to-peer communications over the LACChain Besu Network. Communication consist of sending and receiving messages between nodes.
For data transfer, LACChain Besu Network uses the RLPx Protocol. RLPx enables nodes to transfer encrypted and serialized data through encrypted multiplexed messaging.
This protocol leverages Elliptic Curve Integrated Encryption Scheme (ECIES) to establish secure communications between nodes using public key infrastructure and elliptic curve cryptography.
After the handshake, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth”, the Ethereum’s Whisper protocol is “shh”, and the Light Ethereum Node Subprotocol is “les”. The subsequent messages are dependent on the protocol chosen.
Through this protocol:
- Writer nodes broadcast transactions to boot nodes.
- Boot nodes update writer and observer nodes on the new blocks generated by the validator nodes.
- Validator nodes agree on the generation of new blocks among themselves and broadcast to boot nodes the new blocks generated.
Transactions are the way the off-chain world interacts with the LACChain network. Transactions are used to amend or update the state stored in the LACChain network.
The transaction cycle is:
-
An account address sends a signed transaction to a writer node.
-
The writer node verifies the transaction is signed by an authorized account address (every writer node is responsible for whitelisting and blacklisting account addresses, as they are fully responsible for the transactions they broadcast to the network).
-
The writer node broadcasts the transaction to the boot nodes it is connected to. Once the transaction is broadcast, the writer node also outputs the transaction id which can be used to track the status of the transaction.
-
The boot noodes broadcast the transaction to the validator nodes.
-
Validator nodes receive the transaction and add it to the transaction pool.
-
Validator nodes apply the IBFT2.0 consensus protocol to validate the transaction and incorporate it into a new block. The number of transactions that can fit into a block depends on LACChain Besu Network block size.
-
Validator nodes update their ledger by appending the new block and send the information to the boot nodes.
-
Boot nodes pass the information along to writer and observer nodes. Upon receiving the new block, writer and observer nodes execute all the transacciones in the block.
#TO DO#