SKALE NETWORK CONSENSUS
Hello Readers!!!
Let’s discuss the SKALE Network Consensus
SKALE Network implementation was initially created to offer Elastic Sidechains of virtualized subnodes that work together in block creation and are committed through a leaderless, provably, and asynchronous secure protocol. The protocol was designed to keep the network strong in any case that the virtualized subnodes may have downtime which will be regarded as a low link.
Messaging
Network Security Assumption
Pending Transaction Queue
Network Security Assumption
This network security is assumed to be asynchronous as messages are guaranteed to eventually deliver, this simply means all virtualized subnodes available in the Elastic Sidechain are assumed to have a connection through a reliable communications link, this link can be slow during the process but will eventually deliver messages.
Messages are transferred from one subnode to another, from the sending to the receiving virtualized subnode, there’d be multiple attempts until the transfer is finally successful.
Pending Transactions Queue
A lot of virtualized subnodes in the network, each of them is able to maintain a pending transactions queue, and the first subnode to receive the transaction into the queue will make an attempt to spread it to its peer via dedicated outgoing messages queues for each subnode. Messages being sent to the peer are serviced by a separate thread that delivers messages to subnodes in parallel so that any message failure from one of the peers(in accepting messages) will not prevent other peers from receiving the same message.
Consensus
Block Proposal
Data Availability
Pluggable Binary Byzantine Agreement
Finalizing Winning Block Proposal
Block Proposal
The previous consensus round which is messaging must have been completed and immediately each virtualized subnode’s TIP_ID will increase by 1 then, a block proposal will be created.
Before a block proposal can be created, a virtualized subnode will do the below-listed
- Examine all pending transaction queues it has
All transactions from the queue will be taken by the virtualized subnode to fill in a block proposal if the transaction in the queue is less than or equal to MAX_BLOCK_SIZE. - The oldest to the newest received order will be used by the virtualized subnode to fill a block proposal if the total transaction in the queue exceeds the MAX_BLOCK_SIZE.
- Block Proposal with transactions ordered by the SHA-256 root from the oldest to the newest received will be assembled by the virtualized subnode.
- If there’s no pending queue at all, the virtualized subnode has to wait for BEACON_TIME, but if the queue is empty still, an empty block proposal will be made with no transaction in it.
Data Availability
There’s a protocol called Data availability protocol which ensures that messages are passed to the supermajority of virtualized subnodes. Once a block proposal is created, the data available protocol works by communicating it to other subnodes.
Here are the steps of the Data Availability Protocol;
One virtualized subnode will serve as the sending one (Assumed to be A)and it will be sending 2 things which are, the block proposal and the transaction hashes composing the proposal (Assumed to be P) to all its peers.
Peers must have transactions in their pending queue and upon receipt of the block proposal from virtualized subnode(A), each peer constructs the proposal(P) by matching hashes with transactions showing in their pending queue. If any peer can’t find transactions in the pending queue, the peer will send a request to the sender which is virtualized subnode A, and then A will forward back to the peer virtualized subnode it receives from, the bodies of these transactions, upon receipt again, the peer will reconstruct the block proposal and have it added to its proposal storage database.
After the block proposal has been reconstructed and stored by the peers, they send a receipt back to the sender virtualized subnode containing a threshold signature share of the proposal(P).
Virtualized subnode A will wait to gather signature shares from the majority of the peers that are supermajority(>2/3) which also includes itself. After gathering the signature shares from the peers, A will create a supermajority signature (Assumed to be S). Then S will be the evidence that the supermajority of virtualized subnodes have received and signed the proposal(P).
After all, this has been done, the virtualized subnode A will broadcast the supermajority signature it has created to the other virtualized subnode in the network.
Pluggable Binary Byzantine Agreement
This is another consensus and this particular one uses Asynchronous Binary Byzantine Agreement(ABBA), currently SKALE Network uses ABBA from Mostefaoui et al, this doesn’t mean that any other ABBA protocol cannot be used, but it can only be used if it satisfies the properties stated below:
- Network Model — The proposal assumes an asynchronous messaging system described above in the Messaging
- Byzantine nodes — The proposal assumes less than one-third party of the nodes(Byzantine).
- Initial Vote — The proposal assumes to receive an initial yes/no vote from each node.
- Consensus Vote — The proposal terminates with a consensus vote of either a yes or a no, if the consensus vote is yes, there’s a guarantee that at least one of the nodes will give a yes and that node will be known as the honest one.
Finalizing Winning Block Proposal
Immediately consensus with winning block proposal(P) on any Virtualized subnode A, before the proposal can be finalized and committed to the chain, the virtualized will execute some algorithm, see below;
- Virtualized subnode A will look for the receipt of the winning proposal(P)
- If A can’t find a receipt of P, A will request it from the virtualized subnode which is also a peer.
- Virtualized subnode A will wait to get signature shares from a supermajority of other peers including itself.
- The received signature shares will be combined by A into a threshold signature.
- Lastly, A will be able to commit the proposal(P) to the blockchain alongside that threshold signature gotten from the combination of signature shares of peers.
About SKALE
SKALE is the world’s fastest blockchain, designed for fast, secure, user-centric Ethereum scaling. SKALE chains offer zero gas fees to end-users and have advanced features such as on-chain file storage, interchain messaging, zero-cost minting, ML/AI smart contracts, and enhanced security features.
The SKALE network enables developers to deploy their own EVM blockchain in minutes without sacrificing speed, security, or decentralization. Welcome to the SKALEverse.
