Catapult Series – Dragon Update
The NEM Core Developers recently released the latest Catapult Update code named Dragon, information on the features of this update is below.
Link to the document: here
Enter the Dragon:
Examining the Features in the Latest Catapult Developer Milestone
Catapult Update: Features of the Dragon
Catapult is the next full-featured core NEM engine scheduled to be released in Q4 of 2019. Following the network release of the Cow update, the core developers are now releasing the fourth milestone for the Catapult server, Dragon.
The Dragon update includes several key feature implementations and improvements to serve enterprise functionality.
Harvesting is the process by which NEM’s nodes generate blocks and earn rewards. With Dragon, each node will have the ability to set a beneficiary public key to share a percentage of the harvesting rewards.
The sharing ratio will be set by the node owner and will be configurable per network. When the node does not define a beneficiary, all the rewards will go to the block signer.
For instance, let us imagine that a node owner Amir, established Jake as a beneficiary of his harvesting. The network is configured with a defined beneficiary percentage of 10 percent, setting up Jake to receive a tenth of the total harvesting rewards.
Thus, if Amir’s node were chosen by the consensus protocol to create a block, in which the fees of the transactions amount to 100 XEM, Amir would receive 90 XEM and Jake would receive 10 XEM, given that the block is successfully created.
Through this feature, deployed networks will be capable of creating an incentive structure for supporters of the network to run full nodes. The potential for compensation will establish larger and more stable networks.
Previously, the network native currency mosaic could only be created with a set final supply. However, with the introduction of the Dragon update, Catapult engine will support the possibility of increasing the native currency supply over time.
Through inflation configuration, the supply of network native currency mosaic can be increased per block. As the total supply increases, the incrementing ratio can vary depending on the block height, as defined in the network configuration.
For example, a private network could enable inflation, increasing their currency mosaic, nugget, in such a manner:
starting-at-height-1 = 500
starting-at-height-1000 = 250
starting-at-height-2000 = 0
According to the configuration, there will be 500 nuggets created per block from the block 1 to 999, then 250 nuggets per block until the block height reaches 1999.
At the 2000th block, no more will be added to the supply, effectively ending the inflation of the mosaic. If the initial supply at its genesis block (block height = 0) was 1,000,000, this means that the final supply of nuggets will be 1,750,000.
With the addition of inflation, the block rewards for harvesters will include the mosaics created due to inflation, similarly to mining in other cryptocurrencies. The harvester will collect the newly created mosaics, sharing them with the beneficiaries, if the beneficiary key has been configured.
The introduction of controlled inflation will give NEM the flexibility to support new token economic models. Especially in combination with harvesting beneficiary capabilities, the creation of inflationary mosaics will empower consortiums and private networks to apply new token economic models that suit their individual needs.
Read more: Inflation
Updated Modify Multisig Transaction
Modify Multisig Transactions (MMT) are used for two reasons:
- Transform an account into a multisig account.
- Change the configurable properties of an existing multsig account.
Following the Dragon update, MMT must be wrapped in an Aggregate Transaction. As such, the proposed multisignature cosignatories will have to opt-in by cosigning the Aggregate Transaction for its completion. Unless the required participants have signed, the Aggregate Transaction will not be included in a block, hence the multisig account in question will fail to add new cosignatories.
Prior to this alteration, there were a couple of factors that produced crucial complications with MMT:
- There was a maximum number of accounts for which an account could be a cosignatory.
- An account could not get rid of a multisig cosignatory until there was a quorum between multisig cosignatories.
Therefore, it was possible to add unsuspecting accounts to dummy multisigs, preventing users from utilizing the multisig feature. However, by giving potential cosigners the opportunity to approve or deny cosigner authority, the threat of cosignatory spamming is nullified.
For instance, if Jim and Pam wanted to setup a multisignature account on Catapult for their daughter’s college fund, they would have to initiate an Aggregate Transaction with their personal accounts as the cosigners. In this case, their daughter’s college fund account will be converted into a Multi-signature account if, and only if, Jim and Pam both opt-in by providing their signatures.
Cross-Network Replay Protection
Dragon also bolstered Catapult’s security by adding cross-network replay protection.
The NEM network identifier is only a byte (256 different values), so there are overlaps when there are more than 256 networks. Previously, if two accounts are both part of two networks sharing a common network identifier, a transaction between the accounts in one network could be “replayed” in the other network.
Suppose two accounts, Amy and Kevin (both with 100 XEM), are part of two networks (NET1 and NET2) with an identical network identifier. Amy wants to send 50 XEM to Kevin, so she creates a transaction and sends it to the NET1 network. After confirmation, Amy has a balance of 50 XEM and Kevin has a balance of 150 XEM, as intended.
However, Kevin is greedy and wants to take more funds from Amy on NET2. So he copies the original NET1 transaction and sends it to NET2. The transaction is accepted because it is valid and signed. As a result, Amy is erroneously debited an additional 50 XEM on NET2 and credited to Kevin. Amy is left with 0 XEM, while Kevin now holds 200 XEM.
In order to solve this problem, transactions from networks with the same identifiers needed to be distinguishable so that they cannot be applied to both networks. Thus, Dragon added a security layer by prepending a network generation hash (unique to each network) to the transaction data payload prior to its verification.
Signature = account.sign(generationHash + SpecificTxPayload)
If Kevin was to attempt to replay the transaction in NET2 in Catapult after the Dragon update, the replay transaction would be rejected by the network due to the incorrect network generation hash and the subsequent signed transaction payload.
Read more: Transaction
Notable Minor Updates
Hash Lock Transaction – Hash Lock Transactions will now accept locking aliased mosaics. When creating HashLock transactions, it will be possible to specify an alias (namespace Id) instead of the mosaic Id of funds to be locked, allowing for a more convenient and user-friendly experience.
Secret Lock Transactions – Secret Lock Transactions will allow the reuse of a secret as long as the recipients set are different.
Catapult Broker Process – New catapult broker process will automatically push changes into MongoDB and ZMQ.
Catapult Recovery Process – If the Catapult server terminates due to uncontrolled errors, this process will restore the local state.