
Release of v0.14.0.1
The first major release of the Absolute Core including Long Living Masternode Quorums (LLMQ) Deterministic Masternodes.
Introduction of IPv6 Support
Support is now available for Masternodes to be run on the IPv6 framework. Our VPS install script will allow you to automatically assign a Masternode service to an available IP address, this can be either be a IPv4 or IPv6 address. It is now also possible to run more than one masternode on a VPS, which is determined by hardware specification and maxium IP allocation. If you are considering IPv6 setups, please be aware that most home ISP services will not relay IPv6 addresses if you wish to connect to your VPS via SSH IPv6 alone. We would recommend connecting via IPv4 and then configuring any additional IPv6 connections via our install script.
Introduction to LLMQ’s
LLMQ’s live a long time (as the name says…) and may grow to be quite enormous, boosting the safety of those around them.
At the same time, instead of increasing the strain on the entire network, they just increase the needed resources (CPU, RAM, and network) on the members of such quorums.
Instead of selecting a new quorum on demand, we build them ahead of time and then reuse them
Instead of selecting a new quorum on demand, we build them ahead of time and then reuse them for a set length of time. The reason for this is that when a decision needs to be taken, an LLMQ executes M-of-N threshold signing sessions to reach a majority consensus.
The prior system required that each quorum member’s vote be propagated individually. The votes are propagated to all nodes in the network, who must then validate and store them. This does not scale well and may result in a variety of consensus issues.
LLMQs, on the other hand, just require the quorum members to propagate and validate individual votes (signature shares). When any quorum member collects enough votes, the final result (recovered signature) is established and broadcast to the rest of the network.
The ultimate result is a single BLS signature because it is the result of a BLS-based M-of-N threshold signing session. It takes far less CPU, RAM, and network bandwidth to propagate only this single signature over the network.
Because only members of the LLMQs do the heavy lifting and numerous LLMQs are operational at the same time, the overall network load is evenly divided.
LLMQ Use Case
InstantSend is the first and most evident use case for LLMQs. It is simple to implement by having LLMQ members threshold sign observed transaction inputs. If any LLMQ member gathers enough threshold shares, the final result is created and propagated to the entire network. The network will only have to propagate one message per transaction input as a result of this.
Later we should be able to scale this into the configurator platforms to allow consensus of any consignment or contact data needed to be logged on the chain.
Introduction to Chainlocks (51% Attack Prevention via Masternode LLMQ’s)
ChainLocks’ goal is to do a network-wide, verifiable measurement/vote of the “first-seen” rule. An LLMQ of a few hundred masternodes is chosen for each block, and each participating member signs the first block that extends the active chain at the current height.
If enough members (e.g. >= 60%) observe the same block as the initial block, a P2P message (CLSIG) can be created and propagated to all nodes in the network.
There are also additional details to this process, particularly when multiple miners discover a block at the same moment. DIP8 goes over these specifics.
Only if a sufficient number of quorum members agree can the CLSIG message be produced. This is because LLMQs use BLS M-of-N Threshold Signatures, and a valid threshold signature must be supplied in the CLSIG message. Internally, this threshold signature is identical to a standard BLS signature, and all nodes can verify it without knowing who signed it.
The LLMQ’s quorum public key, which can be acquired via on-chain data, is all that is required for this verification. There can only be one legitimate CLSIG message or none, due to the nature of how LLMQ Signing Requests/Sessions function, therefore there is no confusion due to conflicts.
The presence of a valid CLSIG message indicates that the specified block has been seen as the first block by the majority of LLMQ members (e.g. 60%).
Because LLMQs are built at random from Absolute Masternodes, the distribution of nodes who have seen this block first over the entire network is statistically identical to the distribution within the LLMQ. This means that if 60% of LLMQ members saw the block first, roughly 60% of the entire network should have seen it first as well.
If a node receives a valid CLSIG message, it should reject all blocks (and their grandchildren) at the same height that do not match the CLSIG message’s block.
This makes the active chain decision rapid, simple, and unambiguous. Reorganizations below this block are also impossible.
Implementation Plan
1. Wallets, Masternodes and Miners upgrade their nodes to the latest release
2. Using BIP9 miners will start voting on the deployment for DIP8, but only after they have seen enough MNs have upgraded (this is automated)
3. BIP9 requires a certain number of blocks have been mined, DIP8 will activate to start the LLMQ process. 2016 blocks where 1108 are signed using v0.14.0.1 with then lock in DIP8.
4. DIP 8 will fully activate after a further lock-in period has completed, which is a further 2016 blocks.
5. Once DIP8 is active: Spork 17 (QUORUM_DKG), Spork 19 (CHAINLOCKS) and Spork 20 (INSTANTSEND_LLMQ) will activate on the 25th of July 2021
7. After all Spork activations have occurred, all v13.0.1 Masternodes will be placed in a Pose Ban state on the network. Standard coin functionality will still work for v13.0.1 but Masternodes will not receive rewards until they upgrade.
Implementation Guides
We have two guides available to make the upgrade or install process as easy as possible for this version.
Install Script Guide for New Single Masternode Implementations
Please refer to the guide on the support page here: https://absify.me/docs/absolute-abs-masternode-install-script/
Install Script Guide for New Multiple Masternode Implementations
Please refer to the guide on the support page here: https://absify.me/docs/absolute-abs-multi-masternode-install-script/
Upgrade Process guide for Existing Masternode Owners
Please refer to the guide on the support page here: https://absify.me/docs/upgrade-your-masternode-to-v0-14-0-1/