NEM Catapult: A New Server Release (Cow)
The server release milestone codenamed “Cow” was made public. This update brings new features and some breaking changes to NEM2.
For Japanese click here.
In the coming weeks, we will be introducing a series of blog posts, which will go through the features included in Cow and how to use them for your use-case. You can find the technical change-log here.
Updated codebase
The P2P server and the REST API gateway have been updated. The bootstrap service (docker) will follow soon, while changes to the docker files have already been made.
These are breaking changes, therefore, it is essential to have the newest NEM2 SDKs. Please note: the rollout initially only happens to TypeScript/JavaScript. Please watch the repository for updates here. The TS/JS SDK does not support Bison/Cow as of 11th of February. Other SDK languages will follow at a later stage.
Communication
To attract and manage contributions to the NEM ecosystem, a Project Management Committee (PMC) has been put into place.
To align the new PMC with the Slack communication channel, some of the nem2.slack.com channels have been renamed or removed. This prevents information from being scattered over different channels.
New proposed features are added as an issue to their corresponding milestone in the server repository. NEM improvements proposals can be added and discussed on GitHub in the NIP repository.
Server Milestones and features
Bison Changes
While the following feature has been included in the Bison server release, it is mentioned here, because the SDK implementation work happens closely with Cow related changes.
Account filters
Account filters permit account owners to block certain transactions. For example: crypto exchanges can set a filter so they only allow transactions with mosaics they support. Another application can be described for the supply chain industry, where an account can be used to represent an asset. The company decides only to allow incoming mosaics known to a predefined list. When an incoming transaction contains a mosaic different from that list, the transaction simply fails. Read more
Blocking spam transactions
Available filters:
- Mosaic filter: Can be set to whitelist/blacklist certain mosaics
- Address filter: Can be set to whitelist/blacklist transactions from a certain address
- Transaction type filter: Can be set to whitelist/blacklist certain outgoing transaction types
Account properties parameters
Cow Changes
Aliases
With aliases, it is possible to attach (sub-)namespaces to accounts or mosaics. This allows for more human-readable distinguishment of the objects. It is possible to send a transaction to an account and use the alias of that account as an address. The same applies for mosaics also: you can send a transaction with a mosaic using the alias of that mosaic. Aliases can be set and removed. Documentation preview can be found here.
Implementation
- Address Alias: Can set/remove a (sub-)namespace as alias to an account
- Mosaic Alias: Can set/remove a (sub-)namespace as alias to a mosaic.
Receipts
Complex transactions are enabled by conditional changes in the background. For example, a Lockfund Transaction (deposit) is returned as soon as the aggregate bonded transaction is confirmed. However, there is no additional transaction recorded when the lockfund is automatically returned to the account. This might appear as a “hidden change” that increases the account balance. That’s why so-called receipts come to the rescue! Receipts provide proof for every hidden change. Documentation preview can be found here.
Updated Features
Cross-chain swaps
New hashing algorithms have been added to increase compatibility with other chains.
Default:
- SHA3–256
New:
- Keccak-256 (ETH compatibility)
- Op_Hash_160: first with SHA-256 and then with RIPEMD-160 (BTC compatibility)
- Op_Hash_256: input is hashed twice with SHA-256 (BTC compatibility)
Fee improvements
Changes have been made at the protocol level in preparation of the fee system. A preview can be found here. This topic deserves its own article, so a comprehensive explanation will follow as soon as it materializes.
Harvesting
This change allows the setting of a different mosaic than the primary chain currency for harvesting. This allows greater customisation of private networks and for new crypto-economic models. Read more
Serialisation
Transactions that are sent to the NEM2 REST gateway are serialized in the SDK for more performant handling in the NEM2 protocol implementation. Until now, the serialization was done by the flatbuffer library (Google). This library will be replaced by a custom library called catbuffer. Less overhead and less trust in low-level builders from third parties. This requires an update to how SDKs serialize transactions. Such an update also demands an implementation of the code generator in the respective programming language. Read more
Separating Mosaics from Namespaces
Until now mosaics had to be configured to expire after x amount of blocks. With the new implementation, it is possible to configure the mosaic not to expire, which ensures the usage of mosaics — even if the creator is out of business.
Mosaics do not sit under a specific (sub-) namespace anymore but can exist on its own. They can be named using aliases, and mosaics can also be renamed by using the alias system. Read more
First appeared on medium
Node reputation (replacing Eigentrust++)
Nodes basically keep track of successful communication in the past and use that list to reconnect. This plays a role to subvert Sybil attacks, where identities of nodes are forged to disturb the P2P system. Read more
