Nara Network Release Plan

[bedeho]

Name

Nara

An ancient Japanese city known for its rich history and cultural heritage.
Associated item: Todai-ji Temple, which houses the world's largest bronze statue of the Buddha.

Brand

TBD

Goals

1. Upgrade Substrate to polkadot-v0.9.39.

2. Restrict content curator powers.

3. Use JIP process.

Scope

Upgrade Substrate to v0.9.39.

Motivation

When the gap in versions becomes to great, there is an increased risk of upgrade debt becoming more complex to resolve later, as changes accumulate and interact, and the system also is left open for greater risks as time passes, in particular as Joystream gains a wider audience, for example if the token becomes tradeable. It has also been observed that serious problems in the Substrate framework may be fixed and even deployed quickly on Polkadot/Kusama, while it is nearly undetectable what has happened by reading the release notes. In fact, there currently is no established notice process for Substrate teams to learn about vulnerabilities detected and remedied, which is quite astounding, and the discussion seems to be centred on parachain teams, not all users.

Status

The work is here largely concluded, so far the conclusion is that the work required no changes to logic, types or storage representations in pallets, simply augmenting type names. Benchmarking of extrinsics is just about done. All integration tests pass, including for the upgrade itself. This implies the CLI, QN, Argus, Colossus and other infra is working well out of the box, the only known issues currently are

• RPC nodes need to upgrade, however not validators
• QN nodes need to restart from docker images

Restrict content curator powers.

Motivation

The full motivation is described here: #4589, but the short of it is that there are two needlessly powerful deletin privilidges that curators hold which should be removed to increase security that channel owners have in their property rights, because removing them does not meaningfully reduce capacity of DAO to enforce any policy it wants. Specifically remove

• delete_video_as_moderator: requires that video has no NFT
• delete_channel_as_moderator: requires that channel has no videos, and also in the future no creator token.

Status

The work has not started here, and while removal of extrinsics is trivial, the complexity may occur w.r.t. changing certain permission types that currently live in storage, which thus implies a migration step. This will significant work to review, implement and test rigorously. Regardless of the migration issue, there will also be some impacts on dependencies:

• CLI: remove curator commands
• QN: remove event processing for extrinsics
• Orion: remove events processing for extrinsics

Not started, big issue here is migration: is it needed or not?

Use JIP process.

Motivation

The Joystream Improvement Proposal (JIP) process, is the equivalent of the BIP and EIP processes for the Bitcoin and Ethereum communities, respectively. It exists to facilitate and organise the process of introduction and management of standards, such as runtime upgrades, or social procedures, like how to change key operational parameters, like max validator count.

Status

The first full proposal for the process itself was codified in a JIP 1 proposal document, available here: https://github.com/bedeho/jip/blob/main/jip-1/jip.md

It was intended to be used with the Ephesus network, however due to time constraints and the complexity of introducing everyone, it was abandoned for a future release. Initial work has also been done on the JIP portal, here, but it has not been reviewed. At this time, the current steps seem to be involved in getting JIP used for Nara.

• JIP 1 finalized.
• Draft JIP 2 for runtime upgrades.
• JIP 2 finalized.
• Draft JIP 3 for Nara upgrade specifically, following JIP 2.
• Complete reference implementation and full testing of JIP 3.
• JIP 3 finalized.

It's nothing that currently, runtime upgrades have constitutionality 2, not 4, as in prior upgrades.

Release Process

Versioning

Software	Maintainer	Current Version	Expected Nara Version
Runtime Spec Version	Ignazio	1001	?
Node	Mokhtar	?	?
Atlas	Artem	1.2.2	?
Gleev	Artem	1.0.0	?
Pioneer	Theo	TBD.	?
QN	Zeeshan	0.1.0	?
Argus	Leszek/Zeeshan	0.2.0	?
Colossus	Mokhtar	3.0.0	?
Hydra	Zeeshan	4.0.0-alpha.9	?
CLI	Zeeshan	0.10.0	?
YoutubeSync	Zeeshan	-	?
Orion	Leszek	1.0.0	?

ETA

Milestone for when upgrade can be proposed for council is: TBD

Blockchain Deployment

This will be a runtime upgrade, without any migration.

Asana Timeline

• public link
• jsgenesis link

Monorepo

We are working on branch nara-network, which is based on TBD branch.

https://github.com/Joystream/joystream/tree/ephesus

Release Manager

Bedeho

Regular Meetings

We start regular weekly release calls on Mondays 11am CET.

Before each meeting make sure that

• all work you are doing is reflected in issues or PRs with the nara-network label
• if you have completed work, then make sure issue for that work is closed.

Meeting minutes are logged in this issue: #4736