Waves — the fastest ever blockchain
The Waves network has implemented a ground-breaking new protocol that will allow its blockchain to process thousands of transactions per minute.
Reasoning
Maximum rate of transactions in blockchain systems is limited by the choice of two parameters: block size and block interval.
The block interval defines the average amount of time that passes between the creation of two blocks. If we reduce this time, forks will appear more frequently, which will lead to either non-resolved forks or to decreased throughput since considerable amount of time would be spent on resolving these forks.
Larger blocks lead to huge network usage spikes during block propogation, which in turn will lead to throughput problems and huge forks.
Waves-NG Solution
Waves addresses this issue by allowing miner to continuously farm a block during time of mining. This continuously increasing block is called liquid block, which becomes immutable when next block refecrencing it is built and appended. Liquid block consists of keyblock and chain of microblocks. The proccess of creating liquid block goes as follows:
When miner node observes it has the right to create a block, it creates and sends keyBlock, which is regularly just an empty block.
After that, it creates and sends microblocks every 3 seconds. Microblock is very similar to regular block: it's a non-empty pack of transactions, which references its parent: previous microblock or keyblock.
Microblocks are continously mined and propogated to network until a new keyblock, referencing current liquidBlock appears.
Microblock Structure
generator: PublicKeyAccount
transactionData: Seq[Transaction]
prevResBlockSig: BlockId
totalResBlockSig: BlockId
signature: ByteStr
totalResBlockSig is the new total signature of a block with all transcations from blockId=prevResBlockSig and own transactionData. This means that having a liquid block consisting of 1 keyblock and 3 microblocks:
KEYBLOCK() <- MICRO1(tx1,tx2) <- MICRO2(tx3,tx4) <- MICRO3(tx5,tx6)
We have 4 versions of last block:
ID Transactions
KEYBLOCK.uniqueId -
MICRO1.totalResBlockSig tx1,tx2
MICRO2.totalResBlockSig tx1,tx2,tx3,tx4
MICRO3.totalResBlockSig tx1,tx2,tx3,tx4,tx5,tx6
Next miner can reference ANY of these ids in its keyBlock.
Economy
For a miner, it might seem a good idea to reference KEYBLOCK from previous example and pack all txs from microblocks to its own (micro)block(s). In order to make 'stealing' transactions less profitable than referencing the best known version of liquid block(= the last known microblock), we change the mechanics of fees: After activating NG, miner will recieve 40% of fees from the block it creates and 60% of fees from the block he references.
Related Protocol Changes
New block version(=3) which can contain up tp 65535 transactions and doesn't require transaction sorting.
By default miners will first create an empty keyblock. It's a regular block, propogated by BlockForged message, but it now gets broadcasted if it's empty.
Microblocks are propogated by broadcasting its header for every node which applied it(MicroBlockInv) MicroBlockInv contains verifiable signature to prevent node from being flooded. Microblock will be requested afterwards via MicroBlockRequest and recieved back within MicroBlockResponse. Microblocks will be re-requested from other node which has it if a node doesn't respond.
Configuration
The following miner parameters can be tuned(though it's best not to change them in order to maximize final version of your liquid block in the resulting blockchain):
KeyBlock size(maxTransactionsInKeyBlock, default = 0). If changed, it won't be rebroadcasted and the usual extension-requesting mechanics will be used.
Microblock mining interval(microBlockInterval, default = 3s).
Max amount of transactions per microblock(maxTransactionsInMicroBlock, default = 200).
Miner will try to reference the best known microblock with at least minMicroBlockAge age(default = 3s). This is required in order for miner to reference already-propogated block so its keyblock doesn't get orphaned.
Microblock synchronization mechanism can be tuned with waitResponseTimeout(default = 2s) ,processedMicroBlocksCacheTimeout(default = 10s), invCacheTimeout(default = 10s) whcich are basically time of awaiting a microblock and times to cache a processed microblock ids and a list of nodes which have a microblock(by id).
API changes
Upon applying every microblock, last block gets changed, which means /blocks/last and /blocks/at/... will reflect that.
/peers/blacklisted now expose ban reason, one can clear a node's blacklist via /peers/clearblacklist
/debug/ and /consensus/ section are expanded, stateHash doesn't take liquid block into consideration.
Traditional blockchain model
In a traditional blockchain model, blocks are discovered at roughly similar intervals and the most recent transactions are processed once a miner has earned the right to submit them to the network. This places fundamental limits on the capacity of the blockchain. Bitcoin, for example, has a theoretical maximum of roughly 3 tps.
NG model
In the NG model, the next miner is selected in advance. The miner creates a ‘key block’, which is then immediately filled with microblocks containing transactions, which requires no further proof-of-work. Whilst maintaining the open structure of the protocol, this allows transactions to be confirmed as fast as the network will allow. Waves’ proof-of-stake approach further improves speed, increasing capacity by a factor of a hundred or more.