Pollen Testnet v0.3.0 Release Notes

Tech Updates Oct 12, 2020

We are releasing a new version of our Pollen testnet: v0.3.0. As anticipated in our last Research Status Update, this release includes the full integration of the Decentralized Random Number Generator (dRNG) module! The full list of changes include:  

  • Add multiple dRNG committees support: Pollen, X-Team and Custom.
  • Add clock synchronization plugin via NTP.
  • Add basic codeQL analysis pipeline for common vulnerability scanning.
  • Add basic HTTP authentication.
  • Change payload layout to be more similar to the one specified for Chrysalis phase 2.
  • Improverand-seed to write its output to a file.
  • Improve the Docker network by making MongoDB, Grafana and Prometheus optional so that startup/shutdown times are low when not needed.
  • Upgrade to the latest hive.go.
  • Upgrade NodeJS dependencies of the dashboard.
  • Fix several security issues.
  • Refactor the entire codebase to make its package structure flat and more consistent with Hornet.
  • Move data structures to hive.go
  • Remove JWT authentication due to security issues of the package dgrijalva/jwt-go

As for the previous release, this version bump resets the network as well as the Tangle, and all the balances and tokenized assets.

Here, you can find instructions on how to set up or update your node.

A dRNG can be implemented in many different ways, including:

  • Verifiable secret sharing and threshold signatures
  • Cryptographic sortition
  • Verifiable delay functions

After reviewing some existing solutions, we decided to use a variant of the drand protocol, originally developed by the DEDIS research group and currently under the drand organization. This protocol has been already used by other projects such as The League of Entropy. In a nutshell, drand works in two phases: setup and generation.  

In the setup phase, a set of nodes, called a committee, run a distributed key generation (DKG) protocol to create a collective private and public key pair shared among the members of the committee. Each member gets a copy of the public key as well as a share of the collective private key, such that no individual member knows the entire collective private key. These shares will then be used by the committee members to sign their contributions during the next phase.  

The generation phase works in discrete rounds. In every round, the committee produces a new random value by leveraging on a deterministic threshold signature scheme such as BLS. Each member of the committee creates in roundr the partial BLS signature σ_r on the message m=H(r || ς_r-1) where ς_r-1 denotes the full BLS threshold signature from the previous round r−1 and H is a cryptographic hash function. Once at least t members have broadcasted their partial signatures σ_r, anyone can recover the full BLS threshold signature ς_r (via Lagrange interpolation) which corresponds to the new random value. This result, called dRNG beacon, is published in the Tangle by each committee member so that all of the IOTA nodes can verify the validity of the new randomness against the collective public key. Then, the committee moves to the next round and reiterates the above process.  

If you are interested in knowing more about drand, we recommend you to check out their Github repository as well as our IOTA cafe post.  

Part of the Coordicide project is to define how to integrate the drand protocol into IOTA. The main challenge here is to find consensus on which nodes act as committee members. One approach could be to select the nodes with the highest mana and refresh the committee selection every now and then. Since there is no perfect consensus on mana and different nodes can have different mana values, we require all nodes interested in the committee participation to prepare a special ‘’application’’ message which determines the value of mana of a given node. Then the committee is formed from the top n highest mana holders candidates. Such a committee would be updated periodically, to account for nodes going offline and changes in mana. Alternatively, a prefixed committee can be selected, for instance, the community could vote on which node should be part of the committee. Ideally, IOTA will have different committees, each of one with a recommended priority, so that the network can freely decide which one to follow.

With this release, the Pollen testnet provides support for 3 committees:

  1. Pollen: managed by the GoShimmer team
  2. X-Team: managed by the community member of the GoShimmer X-Team
  3. Custom: any set of users can create their own committee

If you would like to know more about setting-up your own custom committee, you can check out our dRNG repository, hosting the required software as well as a wiki describing all the steps to set up a committee and configure GoShimmer. We also updated the GoShimmer wiki page with a new section describing the new dRNG API.  

We would like to thank, once again, our GoShimmer X-Team community members for their help and support throughout the testing phase of the dRNG module.

As always, we welcome your comments and questions either here on Medium or in the #tanglemath channel on our Discord. You can also join in the #goshimmer-discussion on Discord.  


IOTA Foundation

Official posts from the IOTA Foundation, and migrated posts from old platforms.