Adopt Encointer Runtime

[brenzi]

Encointer is a system chain on Kusama since Jan 2022 and has been developed and maintained by the Encointer association. This RFC proposes to treat Encointer like any other system chain and include it in the fellowship repo with this PR

[ggwpez]

Thanks for the MR!

I left some formal comments, only one thing about explaining your maintenance plan a bit would be good.

[brenzi]

what's the process here? how and when will this matter be decided?

[ggwpez]

what's the process here? how and when will this matter be decided?

I will advertise it in the channel to get some more reviews.

Would say in two weeks the latest the on-chain voting should be started.

[gilescope]

I'm happy to sponsor this RFC and maintain it until such time as encointer devs join the fellowship.

[bkchr]

Generally I'm okay with this. I don't think that Encointer will make the job more complicated for the fellowship. The fellowship runtimes repo only uses crates from crates.io. This means that actually every runtime can update in its own speed and doesn't block the others.

[bkchr]

This would need to change. We only want to have crates on crates.io if possible.

[brenzi]

OK. we can do that. we didn't succeed in upstreaming all our no_std patches to our dependencies, but then we just need to publish all our forks to crates.io

[bkchr]

I think the fellowship can not commit on doing these dependency bumps etc. With the switch to using crates.io releases, this should also not really be required. Encointer could continue to use older releases of the crates until someone updates it. This doesn't mean that someone updating the other system chains, not also updates Encointer, but there should not be any real requirement in doing this.

[brenzi]

I'll rephrase

[brenzi]

assuming the comments have been adressed, can we move forward with this? I'll test the bot and my new assumed privilege right away

[brenzi]

/rfc propose

[github-actions]

Hey @brenzi, here is a link you can use to create the referendum aiming to approve this RFC number 0022.

Instructions

1. Open the link.

2. Switch to the Submission tab.

3. Adjust the transaction if needed (for example, the proposal Origin).

4. Submit the Transaction

---

It is based on commit hash 464ea2201af4d12af7d90cc7a53eb57ed33829c2.

The proposed remark text is: RFC_APPROVE(0022,09eba4f2bb409b2033c9513b9dc1e9861b2ed6a3ac4d2477faaaf52473fcee5b).

[olanod]

I can not vote but anyway I would aye it if it's what you guys really want(are all RFCs gonna be voted by ranks 3+ only?), Encointer has been a role model for us to follow that showed us it's possible(with a lot of pain) to to build a common good with resources from the ecosystem.

My comment during last fellows meetup was just an observation, you guys asked to be a common good when it was not yet well defined what it meant to be one, now we shifted towards the concept of system chains instead of common good ones and Encointer got dragged into this new definition during the transition, but I think Encointer is not a system chain, it's a common good that deserves to be funded by the treasury but it's not an extension of the core protocol that would fit with other fellowship maintained runtimes.

I'm curious if you guys have considered giving up your system chain status and "be free", as a very experimental project you might want to iterate often, change and break things, I feel that being dependent on Kusama's governance to do runtime upgrades it's a huge drag that damages the project's ability to adapt to the needs of your users.
While developing Virto(Kreivo now on Kusama) I always had the goal to do as Encointer, don't have a token(make it hard for the L1 to fall into the control of the same few) and aim to do something nice, something for the common good(but remain sustainable). However if we want to stay kreiv-ative giving up the control of our runtime was a no-go, so I just waited patiently(some years now?) for parathreads to be a thing while doing other work on the client side. Now the wait is over, on-demand blockspace is not there yet but Kusama slots being "free" meant our time has come, we still build a common good chain(whether it's an official definition or not), we can iterate quickly and if the ecosystem feels it's worth supporting the ideas and innovations that can come out this project then we can keep the chain alive. Wouldn't this kind of model fit your project better?

[brenzi]

@olanod Thank you for your thoughtful comment.

I have previously commented on my take. Like you, I don't think the "system chain" label is a good fit for Encointer. But then, it's mostly a marketing label and I have no strong feelings here.

Concerning our freedom to iterate often and change/break things, I don't believe that joining this repo changes much. Lacking our own root origin, we have to wait for OpenGov approval anyway and it's the Fellowship which can accelerate by whitelisting, so we need to wait anyway.

From a purely technical point of view, we would have been much better off as a solochain the last two years: Less downtime, faster bugfix deployment, faster blocktime. But at our current state, "solo" would have meant de facto "centralized" and that's not what we're in for. Decentralization is an integral part of our field-experiment.

Grabbing a cheap parachain slot on Kusama could be a viable alternative if we establish personhood-based democratic governance for our chain. However, in that case we might chose to go one step further and elect our own validators just as well and go straight to a very interesting experiment of delegated personhood consensus. This, however, would require quite substantial groundwork in advance.

So, back to where we are now: We submitted this RFC to get a clear statement from Fellowship on the currently perceived status of Encointer by the technocratic arm of OpenGov: Does the Fellowship think that Encointer should be more tightly integrated or not? We can accept both outcomes, but we request clarity on the matter.

[brenzi]

/rfc help

[github-actions]

The RFC action aims to help with the creation of on-chain RFC referenda and with handling the RFC PRs.

The main commands are /rfc propose and /rfc process.

See usage instructions.

[brenzi]

/rfc process 0x3c07696acaba98022d0960a0c14da01d96bd747eead9380b3aac5c1f5c38b046

[github-actions]

The on-chain referendum has approved the RFC.