Symbol blockchain platform is built from a network of nodes. These nodes provide a powerful, stable, and secure platform where Smart Assets transactions are conducted, searched, and immutably logged on the blockchain ledger.
The four-layered architecture allows developers to update any of these tiers without disrupting the others, which improves security.
Repository: Catapult Client
The peer nodes form the backbone of the blockchain, making the network robust since it cannot be shut down by eliminating a single entity. The role of the node is to verify transactions and blocks, run the consensus algorithm, create new blocks, and propagate the changes through the network.
The API nodes push new transactions to the P2P network, where they are included in a block or discarded. After the block is processed, the node saves:
The binary of each block as a flat-file on disk.
The updated chain state in memory or RocksDB (configurable).
Peer nodes store the chain state in RocksDB. The data structures cached are serialized and stored as values to corresponding keys. For example, a column in this database maps the public keys to addresses. Another one, the account state entries as the values to corresponding address keys.
Storing the state in memory is faster than using RocksDB. However, storing state information in RocksDB demands less memory of the network nodes.
Persisting the state in RocksDB is convenient in networks with a large number of accounts.
Public networks enable anyone to run a node. Some of these nodes could share invalid information or try to disturb the network.
To reduce miscommunication attempts, the nodes keep track of the results of preceding communications. Every node with P2P capabilities keeps a success and a failure counter for every other peer node that it has interacted with.
Nodes update the counters accordingly after processing the data requested. If a node successfully connects to a remote peer, it first increments the success counter towards the remote peer. If the communication attempt fails, the node increments the remote peer’s failure counter. Likewise, the node updates the peer counters accordingly after processing data shared.
Extrapolating from these scores, the node assigns a weight between 500 and 10000 to every peer reached.
The probability of selecting a remote node to read data from depends linearly on its weight. Every four rounds of node selections, the criteria changes to prevent Sybil attacks.
Repository: Catapult Client
The primary responsibility of an API node is to store the data in a readable form in MongoDB. The catapult-client software allows configuring standalone API nodes or with Peer capabilities (Dual).
Instead of writing the data directly into MongoDB, the nodes write it into a file-based queue called
A broker service consumes the data from the spool and updates MongoDB accordingly.
Once a block is processed, the broker service notifies the changes to catapult-rest instances using ZMQ.
API nodes are also responsible for collecting the cosignatures of aggregated bonded transactions, which are only processed once they are complete.
MongoDB stores blocks, transactions, and chain states for high query performance.
The broker service updates the linked MongoDB instance when:
A new block / a bunch of blocks finish processing.
New unconfirmed transactions complete processing.
MongoDB should not be accessed externally.
ZeroMQ is an asynchronous messaging library, which enables real-time subscriptions. It transports notifications from the API node to the ZMQ endpoint, where Catapult REST listens. It is an alternative to REST WebSockets, aimed to be used when performance is critical.
Repository: Catapult REST
The REST gateways handle JSON API client requests. The gateway reads from MongoDB, formats the response, and returns it to the client. This component is also responsible for returning events to the client using WebSockets.
Each REST gateway connects to one API instance to send new transactions requests triggered from the client-side and receive updates in real-time using sockets.
This guide will walk you through the process of setting up your own private network using Symbol.
This guide walks you through the process of setting up a node to join Symbol’s public network.
There is a large number of network-related settings that can be customized in Symbol.
There is a large number of node-related settings that can be customized in Symbol.
Learn how to access your API node’s MongoDB instance.
On Linux systems using
This guide walks you through the process of setting up a node to join Symbol’s network without using Symbol Bootstrap.
The running-a-symbol-node guide explains how to easily create a node using Symbol Bootstrap. In that guide, the setup process is conducted on the same machine that will host the node, meaning that private keys are generated on a machine connected to the Internet. If you need a hardened level of security you can follow this guide instead, at the cost of a more involved setup process.
How to relinquish control of a node’s main account to an external account, so that the external account’s private key is never required in the node setup process.
Once you have created a Symbol node, be it manually or using Symbol bootstrap, the node is mostly autonomous. But there is still a little bit of maintenance required, explained in this guide.
Last updated by Xavi Artigas on 2021-07-26.Did you find what you were looking for? Give us your feedback.