The central element of every cryptocurrency is a public ledger called the blockchain, which links blocks together.
Since the blocks in the chain are ordered, the complete transaction history is held on the blockchain.
Subsequent blocks have increasing heights that differ by one.
Each block can contain up to 6,000 transactions (public network), being this value configurable per network.
Symbol blocks complete every 30 seconds, making transactions confirm quickly enough for everyday use.
Nodes stores blocks in a serialized form as follows:
Version: 0x01
EntityType: 0x8143
Inlines:
Property |
Type |
Description |
|---|---|---|
height |
Height of the blockchain. Each block has a unique height. Subsequent blocks differ in height by 1. |
|
timestamp |
Number of milliseconds elapsed since the creation of the nemesis block. |
|
difficulty |
Determines how difficult is to find a new block, based on previous blocks. |
|
generationHashProof |
Generation hash proof. |
|
previousBlockHash |
Hash of the previous block. |
|
transactionsHash |
Hash of the transactions in this block. |
|
receiptsHash |
Hash of the receipts generated by this block. |
|
stateHash |
Hash of the global chain state at this block. |
|
beneficiaryAddress |
Address of the optional beneficiary designated by harvester. |
|
feeMultiplier |
Fee multiplier applied to block transactions. |
|
blockHeader_Reserved1 |
uint32 |
Reserved padding to align end of BlockHeader on 8-byte boundary. |
Symbol calls the first block in the chain the nemesis block. The first block is defined before launching a new network and sets the distribution of the network currency mosaics.
The process of creating the subsequent new blocks is called harvesting.
Blocks are created by accounts, which are chosen by the consensus algorithm based on their importance score. The consensus algorithm determines a new account to harvest the subsequent block after each block creation.
The harvesting account receives the fees for the transactions added in the block and the mosaics created by inflation. This gives the harvester an incentive to add as many transactions to the block as possible.
To ensure fast response times, the Symbol blockchain is designed in a way that, in the presence of a network failure or partition, requests are still answered, and transactions added to the blockchain.
This naturally leads to forks, this is, different chains are created in the disconnected parts of the network. Once connectivity is restored fork resolution takes place to merge the divergent chains into a single one.
This process might require that some blocks are rolled back: they are removed from the blockchain so all their transactions move to the unconfirmed state and have to be validated again. At this point there’s a chance that their deadlines expire without ever being confirmed again.
For this reason, confirmed transactions (which have already been added to the blockchain) cannot be relied upon until their block is finalized, as shown below.
This is the process of making changes on a blockchain ledger permanent. Before blocks reach finality, they still might need to be rolled back in the presence of a network failure or partition. However, once blocks are finalized, they become immutable.
Finalization occurs in rounds. In each round, a sorting algorithm selects the accounts responsible for validating all blocks pending finalization. If a proposed block matches an account’s node’s records, the account emits a positive vote.
Once more than 67% of the stakes selected for voting have emitted positive votes, the block becomes finalized. At that point the transactions linked to the block are permanently recorded on the blockchain.
Note
In order to be eligible as a voter, an account must:
Be the owner of a node.
Have at least minVoterBalance network currency units.
Be registered as a voter by announcing a VotingKeyLinkTransaction to the network.
When there is low connectivity, or many bad actors, finalization can take longer than usual and create large Rollbacks. However, no finalized block will ever be rolled back.
Thus, clients that rely on the immutability of the blockchain history should only trust transactions from finalized blocks.
Finalization rounds are actually called Epochs and happen every 1440 blocks or about 12h (see votingSetGrouping in the network properties). Each Epoch is divided in multiple Finalization Points (See the Technical Reference section 15.2 for more details).
