Reading:
Development status updates, external audit results and CoinNet test version opening plan
Image

Development status updates, external audit results and CoinNet test version opening plan

2022-04-18

This monthly report, albeit tardy, comes packed with a lot of exciting updates. During the period from Friday, the 1st of October 2021 to Friday, the 21st of January 2022, the team has created 291 pull requests, 271 of which have been merged. This amount for 484 commits, and over 34,000 lines changes over 177 files. And that’s just for Agora! Our development team also works on multiple related project, including many libraries used by Agora (example here), as well as Agora’s API server, the wallet, the block explorer, and more.

The team uses Github releases to track stable releases, and deploy to our private TestNet. During that period of time, 10 releases were put out, the latest being v0.32.0. As usual, anyone can download a release from the Docker registry, however the team also provides native builds for Ubuntu 20.04 and MacOS 11 as of the latest release.

Below is a more detailed explanation of the items that our team worked on during those months. For an even more in-depth view, refer to releases between v0.23.1 (released October 1st) and v0.32.0 (released January 19th).

Highlights

External Audit Report

A main focus of ours was to address points raised during the security audit. They have now all been addressed, and during our last round of audit, SlowMist reported no vulnerability.

Some of the items reported but are now fixed, were related to (by order of importance) :

  • Cross-chain replay attack (e.g. propagating transactions from TestNet to CoinNet);
  • DoS (denial-of-service) vectors, such as how the transaction pool handles large amount of transactions;
  • Some code style recommendation;

Name registry in the BOSAGORA network

The “name registry” or “DNS server” is a term that has been present in a few dev reports already. It might not be clear what role it takes in the network, so before we go over recent improvements, we think best to give you a refresher.

The name registry is a component of every Agora node: It allows to associate a public key with one or more IP addresses. This is needed because, when a node requests to become a validator, they don’t provide their public IP — as it can change at any time. Hence, other members of the network need a way to contact said validator. That’s what the registry does.

Under the hood, the registry implements a full DNS server, from scratch. This has multiple advantages:

  • It uses a well-established protocol that is the backbone of today’s internet;
  • You can type a node address in your browser, or use it anywhere you would use google.com, and will be able to access the node;
  • It greatly simplifies interoperability with other services;
  • As mentioned, each Agora node has a registry. Nodes can be configured to make this registry public, providing a DNS server for other nodes to find validators they want to contact.

Following is a more detailed list of improvements to the registry:

Persistence & Integration into Agora

Before October, the name registry was a separate entity, configured independently, without persistence. Early in October, it has been integrated in Agora, allowing greater flexibility, enhanced peer verification, and enabling persistence.

Authenticated peers, validators, and the rest of the world

The registry used to work in a black-and-white fashion: Either a peer was a validator, and could register, or wasn’t an validator, and couldn’t register. However, as enrollments expire with time, this led to some undesirable jitter, both on the registry and Agora’s side. Hence, the registry was changed to first accept registrations if there was a pending enrollment (an enrollment in the pool), then simply to accept registration if the public key owned an UTXO which could be used as a stake in an enrollment. Agora hasn’t been fully updated to follow the same logic yet, but it should soon be done.

Multiple improvements to comply with the RFC, including EDNS(0)

The initial implementation of the name registry was simply an HTTP server. Later on, for Votera, the need to use a DNS server arose. The first foray into DNS land implemented the most basic features of a DNS server, leaving some missing. This included name compression, handling a few edge cases, and support for DNS extensions. Those have all been implemented and tested with various clients, to ensure that we follow the specification to the letter.

Support for AXFR

A great advantage that DNS provides over a bare HTTP server is built-in replication. One can set up the primary server to be Agora, and any secondary / caching server to be one of the commonly-available softwares, such as BIND9. In order to support this, our team implemented AXFR, allowing servers to share their zones with one another. The support, initially implemented in November, has recently (January) been extended to be limited to a set of whitelisted peers, as is the custom with DNS servers.

Realm, validators, flash zones

Each node, in its configuration, now contains a realm. This realm is the domain name under which the network will live. For example, for TestNet, the realm will be testnet.bosagora.io. Under this realm, the registry currently maintains 2 zones: validators, and flash. As the name suggests, the former is for validators to register, while the second will keep track of flash nodes. This also makes possible seeding in a fashion similar to Bitcoin (meaning a node only needs to know its realm to start its IBD — Initial Block Download). Those zones can live in the same registry, or be split among multiple ones.

Other Agora improvements

Besides the registry improvements, the team is constantly tweaking the code to make sure it works under any situation. Improvements are mostly of two natures: consensus improvements, where the consensus protocol is adjusted, and general improvements, where the consensus is the same but the nodes behave differently. One example of a consensus improvements is the addition of a chain ID, where the way that hashes are generated and changed to prevent transactions generated for TestNet to be propagated in CoinNet. On the other hand, a more generic improvement would be the use of exponential backoff in connections, as opposed to fixed-interval retries: exponential backoff will handle long downtimes / error better and provide a more “logical” behavior to a human observer than fixed-interval retries would.

The following list only includes consensus improvements, as they are the main improvements, and the general improvements are both too numerous and technical. If you are interested in more details, the list of releases contain both.

Introduce Chain ID

As mentioned earlier, one of the benefits of the audit was to introduce a chain ID. While no one should use the same key pair in TestNet and CoinNet, the new chain ID mechanism ensures that, even if one does, their messages cannot be copied from one network to the other.

Commons payout interval now working on TestNet

Our TestNet has a shorter block interval, and shorted validator cycle: blocks are produced ten times faster than in CoinNet, and nodes need to re-enroll a hundred times more often. In that context, all consensus constants are parameterized, allowing our team to quickly test a variety of scenarios. The initial implementation of commons payout had a bug that showed up in TestNet, in which the interval was not properly handling different block intervals, which is now fixed.

Changes in Block signature scheme

The block signature scheme has been designed to be additive: Using the pre-image scheme, nodes can do a Schnorr signature without much of the setup normally required by this technique. However, a critical vulnerability was discovered, which would have allowed an attacker to steal private keys of validators. The scheme was then changed to patch this vulnerability, while keeping the additive property. However, the scheme also provided the ability to reveal a misbehaving validator’s key should they sign more than one block for the same height. This is currently not possible anymore, but the team is looking for alternatives.

Block header has been changed to include pre-images

The block header was previously including two components, missing_validators and random_seed. The former was expected to be almost always empty (as it was the list of validators being slashed this block), while the latter was a hash that was a combination of pre-images. However, as the block itself depends on pre-images for its signature scheme, this created some issues with validators needing to request both pieces of data separately.

The block header has been changed to include pre-images, and derive missing validators and the random seed from it. The pre-images can still be compressed internally by validators, as one needs only to keep the last pre-images of an enrollment (sometimes less) to be able to re-build the entire list.

Time offset has been eliminated

At the time in which a block is externalized and fixed in the consensus parameter, the nodes derive at which height they need to be, based on their local time (within a margin of error). The genesis timestamp is another part of the consensus parameter. Thanks to multiple improvements in the externalization process, the time_offset that was previously in the block header to work around delay in externalizations have been removed.

Improved block conflict resolution

When presented with competing blocks and/or nominations, nodes (and validators) should prefer those with more enrollments, as a larger network leads to more safety. This notion has been introduced in the consensus protocol.

Freezing transaction have been restructured to include an explicit fee

Previously, freezing transactions that were slashed were done so implicitly, leading to implementation issues in the wallet. A new implementation makes slashing more explicit, and more visible to clients.

Nomination sizes are now limited

Nomination sizes now have an upper limit, meaning that the block size is now implicitly limited as well.

Enrollments now need to be signed using the target block height

When a node decides to enroll, they were gossiping a structure containing a few key infos. However, this enrollment could be delayed and not included at the right height, leading to reconciliation issues on the node side. Worse, in some cases, hostile peers could re-use enrollments under some rare circumstances to try to enroll a node without their knowledge. This most likely would lead to the node being slashed if it wasn’t online to notice. Enrollments are now signed based on the block height, meaning those enrollments are only valid for a certain target height.

CoinNet test version opening plan

We plan to open CoinNet test version to external contributors on February 16th prior to the official launch of CoinNet. When test version is made public, anyone can participate as a validator and see how the network works. The wallet and Block Explorer developed by BOSAGORA are also integrated to CoinNet test version and can be tested together.

We also plan to hold an event with the opening of CoinNet test version. Contributors who participate as validators or find and report bugs in the test version will be rewarded. Detailed information related to the CoinNet test version open event will be announced in a separate announcement shortly, so please stay tuned!


0 Comments

Leave a Reply

Related Stories

Arrow-up