Development

Github metrics:

Polkadot-JS:

Polkadot Implementations

There are Polkadot implementations developed in Rust, C++, Go, and JavaScript.

Parity Polkadot — The Rust client is developed by Parity Technologies in concert with their work on Substrate.

Kagome — C++ implementation of the Polkadot Runtime Environment being built by Soramitsu, a Japanese digital identity company that previously developed Hyperledger Iroha. They were awarded a grant from the Web3 Foundation. As part of the process they are developing a libp2p networking layer in C++.

Gossamer — A Go implementation being built by ChainSafe Systems, a 23-person development team in Toronto that is also building an Eth2.0 Serenity client. Grant announcement.

Polkadot-JS — A JavaScript client and tool set developed by Polkadot JS.

Polkadot’s Messaging Scheme

The Web3 Foundation Research team has been working on a text outlining the functionality of Cross-Chain Message Passing (XCMP). It’s a key component in Polkadot, the Web3 Foundation’s flagship protocol.

Cross-Chain Message Passing (XCMP) scheme is a subset of the Polkadot protocol. It defines how messages can be passed among parachains with no additional trust assumptions beyond the economic security of the relay chain. This write-up addresses the messaging protocol of parachains and relies heavily on Polkadot’s unique relay chain architecture and design.

The protocol covers:

In terms of consensus: mechanisms for queuing and ordering of messages.

In conjunction with the rest of the relay chain and in particular GRANDPA finalization : data availability.

data availability. In conjunction with the parachain validation function: message input and output.

In addition, this write-up also reviews delivery, how consistent history is achieved and ideas for preventing DoS attacks. Finally, they review XCMP in conjunction with SPREE and conclude by summarizing the properties that are achieved by XCMP.

In this report we’ll focus chiefly on the review of Cross-Chain Message Passing (XCMP) in conjunction with SPREE and the properties that are achieved by XCMP.

XCMP and SPREE

Shared Protected Runtime Execution Enclaves (SPREE) are fragments of logic similar to runtime modules but that live on the relay chain and can have their functionality opted into by parachains.

These fragments of logic are blobs of WebAssembly code uploaded onto Polkadot either through a governance mechanism or by parachains. Once the blob is uploaded to Polkadot, all other parachains can decide to opt in to the logic. The SPREE module would retain its own storage independent of the parachain but would be able to be called through an interface with the parachain. Parachains will send messages to the SPREE module synchronously. For more information about SPREE see its wiki article.

It will be possible to address an XCMP message to a SPREE module and guarantee that when that message is acted on, it will use the same code from that SPREE module as any other parachain. SPREE modules are important to the overall XCMP architecture because they provide a guarantee that a certain interpretation of the code will be executed on the destination parachains. While XCMP guarantees the delivery of a message, it does not guarantee what code will be executed, i.e. how the receiving parachain will interpret the message. Updates to the code of a SPREE module will be simultaneous across parachains. In addition to the security benefits, this means that changing message formats is possible without coordinating updates across many parachains.

While XCMP accomplishes trustless message passing, SPREE is the trustless interpretation of the message and a key part to the usefulness of XCMP. XCMP messages that are addressed to SPREE modules give the developers and users of the dispatch messages clarity to how the message will be processed.

The XCMP scheme achieves the following properties:

Trustlessness. Since the same set of validators secure one parachain as another while they also guarantee correct message passing, XCMP requires no more trust than a single blockchain would.

Consistency. The team provide absolute guarantee that the messages received were exactly those sent, even despite any chain reorgs.

Availability. Polkadot guarantees that the messages will not be lost and are kept available. This is achieved by distributing erasure-coded pieces that can be used to reconstruct messages.

Maintaining the right ordering for messages output by parachain blocks is guaranteed by Input/Output validation.

Efficiency. The protocol avoids too much bandwidth overhead and allows messages to arrive as quickly as possible.

Study the whole write-up to learn more about the key features of XCMP scheme.

Kusama Upgrade Bulletin (1032–1037)

Kusama is about to get a new logic core; here’s the details of this and a few earlier ones.

Details

Runtime version: 1037

Supported natively by Polkadot v0.7.17

Polkadot Git commit hash: f570356

Substrate Git commit hash: 860b79b

Council motion: #85

Key changes

Multisig accounts and pseudonymous sub-accounts (#4462): Support for stateful threshold multisig transactions/accounts/wallets and pseudonymous “sub” accounts (accounts controlled by other accounts).

Indirectly slashed nominators stay nominating (#4553): If a validator is slashed (e.g. for being offline), their nominators were all forced to chill, depriving other, unrelated, validators of nominations. This logic is removed.

Rebonding (#4374): Unbond operations can now be cancelled before completed and the funds returned to staking operations.

Structured Tipping (#4480): The treasury now has a threshold-median-timeout tipping scheme allowing a much more agile means of doling out funds. Public “scouts” can find things worth tipping and claim a finders fee (if a majority of the council tips).

Additional changes

Fix fees in Substrate (#4421): There have been issues regarding transaction fee calculation and in particular how the fee multiplier changed according to transaction volume. This is now fixed.

Additional events (#4468, #4459): Several additional events for tracking certain changes have been added.

Twitter field in identity info (#4476): The identity system now includes the Twitter account identity field.

Multisigner uses compressed ECDSA public key (#4502): Multisigner is corrected to use a hash of the compressed public key. This enables ECDSA (SECP256k1) controlled accounts in Kusama.

Facilitate cancelation of slashes (#744): To cancel a slash, only one-half of council approvals are required rather than three-quarters.

Fix transaction fees (#736): Transaction fees were accidentally 1/100th of their correct cost. This fixes it.

Timeline (1037)

Submitted as a council proposal at: ~#562,400

Accepted as a council proposal at: n/a

Preimage noted at: ~#567,500

Referendum end block: #569,326

Activation block: #569,326

For developers coding in JavaScript or typescript, the 𝚙𝚘𝚕𝚔𝚊𝚍𝚘𝚝/𝚊𝚙𝚒 version 1.0 is here!

PANIC for Polkadot: A Monitoring and Alerting Solution for Nodes

In the case of Polkadot, validators need to be online to author new blocks for the relay chain, otherwise, they might risk getting their funds slashed. One can easily see the importance of having a monitoring and alerting tool that gives useful alerts, helping the node operator prevent dangerous scenarios such as the disabling of his validator. This is where PANIC comes into the picture.

What is PANIC?

PANIC is a lightweight yet powerful open-source monitoring and alerting solution developed and open-sourced by Simply VC. PANIC was first developed and open-sourced for the Cosmos ecosystem. Given the great feedback they received and the fact that it is believed to be a valuable tool, they decided to develop PANIC for Polkadot. The project also received support from the Web3 Foundation Grants Program.

The goal of PANIC is to help validator node operators monitor the behavior and state of their validators easily by sending useful alerts. But this is not all, PANIC can also be used to monitor non-validator full nodes, the blockchain(s) the nodes are connected to, and GitHub repositories.

Although PANIC is an alerting tool at its core, it also delivers a great user experience, which includes the capability to interact with it using Telegram commands. Telegram commands are used for two things, to have some sense of control over the behavior of PANIC, and to query data. This will become more clear as we go along in this article.

PANIC High-Level Design

The above image gives a high-level description of PANIC and how it interacts with external components. In what follows we will dissect this design such that by the end of this section you will have a basic understanding of how PANIC operates internally, and how it interacts with the external components. Let us start by focusing on the monitors.

Channels and Alert Severity

Not every change in state is critical in nature. As a result, not every alert sent by PANIC is critical. For example, a new GitHub repository release is not as critical in nature as the downtime of a validator. Due to this, PANIC uses four different types of severities for alerts:

INFO : Alerts of this type have zero to little severity but consist of information that may still be important to acknowledge. Example : increase in bonded balance.

: Alerts of this type have zero to little severity but consist of information that may still be important to acknowledge. : increase in bonded balance. WARNING : Alerts of this type require attention as they may be a warning of an incoming critical alert. Example : validator is not elected to validate for the next session.

: Alerts of this type require attention as they may be a warning of an incoming critical alert. : validator is not elected to validate for the next session. CRITICAL : Alerts of this type are severe in nature. Example : validator has been slashed.

: Alerts of this type are severe in nature. : validator has been slashed. ERROR: Alerts of this type are triggered by abnormal events and range from zero to high severity based on the error raised.

PANIC supports the following five alerting channels:

Twilio : Alerts are raised in the form of a phone call.

Alerts are raised in the form of a phone call. Telegram : Alerts are sent via a Telegram bot to a Telegram chat.

: Alerts are sent via a to a Telegram chat. E-mail : Alerts are sent as emails using an SMTP server, with option for authentication.

: Alerts are sent as emails using an SMTP server, with option for authentication. Console : Alerts printed to standard output.

: Alerts printed to standard output. Log: Alerts logged to an alerts log.

Alerts of all severities may be sent through the Telegram, e-mail, console and log channels. On the other hand Twilio is only used when alerts are critical in nature.

By default, the console and log channels are always enabled as these require no configuration and are important for when the operator wants to check what is happening during monitoring and alerting. That being said, it is up to the user to decide whether to enable the Twilio, Telegram and the e-mail channels.

Although the team considers that PANIC will be an indispensable tool for validator operators within the Polkadot ecosystem, they will continue upgrading it. The next step is to give a better user experience when using PANIC. This will be achieved by developing a web user interface which can easily show the status of the nodes and the alerter. The user interface will also provide the operator with capabilities to switch on/off specific alerts, thus providing a more customizable user experience. In addition to this, the user interface will have the capabilities to more easily set up and (re-)configure PANIC.

Read the full article about PANIC for Polkadot to find out more about its core features.

Polkascan Development Update #5