A blockchain protocol outlines a secure way to validate data being transferred, however it does not specify how data is transferred. Data, in the form of transactions, could technically be transferred by USB or be sent to one-other as email attachments. However, for the sake of usability, a more advanced form of transferring transactions is required.
This article will be outlining the design for the Seed launcher's networking segment. The networking segment handles the act of transferring transactions between clients, acting as the glue which connects users using Seed.
One of the primary goals of the Seed network is to be a distributed blockchain system, giving no user more power than other users. This holds true at the Seed protocol level, however the same cannot necessarily be true for creating the networking level. A distributed network would be a full mesh topology, where every client is connected to every other client. Mesh topologies scale incredibly poorly with size, since each additional client increases every other clients required connections.
The decentralized approach blockchains traditionally take is to have a unique role known as a miner or a consensus node. These are special nodes which are part of the blockchain protocol itself. However, in Seed, no such role exists.
In order to minimize the amount of connections between clients, the simplest solution is to allow nodes to selectively act as a hub. A hub would be a special node which listens for other clients to connect. If a topology only has one hub, it is generally not secure as it has a single point of failure. However, if any client could choose to be a hub, there would be multiple points, keeping the network up as long as one hub stays online.
The chosen design is to use these hub nodes and have them relay transactions between each other. These nodes will be referred to as Relay Nodes.
Clients must be able to connect to the network via any connected relay node. Once connected, a Client can request blockchain and entanglement header data to determine what data it needs to request. If its a clients first time running, they would request all block and transaction data. However, if the client has offline data already stored, they would request only block and transaction hashes that belong to transactions they do not already own.
Clients must be able to propagate transactions to the network. A client would send their transactions directly to any relay nodes they choose. Relay nodes will then propagate the transactions to other users.
Relay nodes will also relay transactions between each other, routing transactions efficiently around the network.
Relay nodes must be able to connect to the network in the same way as clients. The simplest solution is to have relay nodes create clients which communicate with other relay nodes. A connecting relay node can then request through their client all the information needed to be caught up to date.
Clients connect to listening relay nodes using web sockets. The client.js file will export the creation of a Client instance. The Client instance will take the IP of the chosen relay node as the parameter into the constructor.
The Client class will implement the following functions:
| Function | Description |
|---|---|
| requestBlockchainHeaders() | Requests block header data from the connected relay node. |
| requestEntanglementHeaders() | Requests entanglement header data from the connected relay node. |
| requestBlocks(blockInfos) | Requests specified blocks data from the connected relay node. |
| requestTransactions(transactionInfos) | Requests the spcified transactions data from the connected relay node. |
| sendTransaction(transaction) | Propagates a transaction to the connected Relay node. |
Relay nodes listen for clients to connect, and relay messages between clients. The relayNode.js file will export the creation of a RelayNode instance. The RelayNode instance will take an array of IP addresses for other relay nodes they wish to communicate with as the parameter in the constructor.
The RelayNode class will implement the follow functions:
| Function | Description |
|---|---|
| listen() | Begin listening for clients to connect. |
| loadState() | Creates a Client instance which communicates with another relay node, asking for all existing transactions and blocks to date. |
Despite RelayNodes having minimal functions, they still have a large amount of logic behind them. The listen() function will contain all the response callbacks for responding to client events, such as returning requested header information, data, or relaying transactions to other clients & relay nodes.
The described architecture will allow any user to act as a client or a relay node. When a user is a client, they act as an end point in the network, communicating with other end points through the relay nodes. When a user is a relay node, they are choosing to act as a hub clients can connect to, propagating and relaying transactions between other users.
