Duniter v2 alpha 🌀

It has been a while since we announced Duniter version 2 in this blog post. From that time, a lot of work was achieved, not only on Duniter v2 itself, but on the whole v2 ecosystem including the Duniter Squid indexer, and the version 2 clients like Cesium v2 and Ğecko. It is now time to announce the Duniter v2 alpha, ready for testing with the gdev network.

Still a solo chain 💫

Duniter v1 is a solo chain run by members of the Ğ1 web of trust. While using the Polkadot Sdk (Substrate), we do not want to be a parachain of Polkadot or Kusama for technical and political reasons. On the technical side, the web of trust requires to store a lot of onchain data and we do not want the proof_size limitation of parachains which limits the size of data coming from the merkle tree used during the blocks execution. On the political side, we want the tools to be in the hands of their users forever and can not delegate the consensus to a relay chain that costs "non-libre money", even if fees are offered within the common good parachain program. That's why we invite Ğ1 members who care about independence to join the gdev test network.

Join the test network ☄

We have run multiple test networks by the past to get familiar with the technology. Now that the software is stabilizing, we are ready to welcome more people on our gdev test network. You can join as a mirror node if you simply want to discover, and announce a public RPC endpoint if you want to increase decentralization. If you feel confident and want to take part to the consensus, you can even run a smith node. The documentation is available in the wiki section.

The test network is a way to get familiar with Duniter identity system. Since it's a test network you can get certified without IRL meetings simply by giving a public key in the forum Ğdev section. The clients in beta version are configured to connect to this test network by default.

Blockchain as a common good 🌲

We already mentioned the "software as a common good" approach of Duniter project in the previous post:

Common good: "a resource that community manage for individual and collective benefit"

We worked further on this topic with the Ğ1 community, in particular to address the fees problem, but also on governance aspects. Details below.

A solution to the fee problem 💸

Blockchain is a truly shared and open resource, not as a multiuser system that limits ssh connections to a set of known pre-configured keys, but as a virtal machine that runs the same code in a distributed manner. It has a permission system and must take execution cost seriously if it does not want to be attacked by denial of service. Since it is a distributed system, there is no way to simply rely on per-ip limitations and other measures have to be put in place.

Users are identified by a cryptographic public key with "infinite" number of possibilities in the sense that it's extremly improbable that the same key is picked twice with proper random generation (IPv4 is 32 bits, IPv6 is 128 bits, we use ed25519 public keys with 256 bits). This is necessary for key security but prevents from applying a per-key quota. Because we have a web of trust, we could limit the use of the blockchain to a restricted set of keys, but that would prevent anonymous accounts (not linked to any part of the wot) to use the blockchain. All public blockchains we heard of came up with the same solution: fees. Any operation on the blockchain costs money to the author which limits the amount of resource he can afford. In addition, validators can prioritize transactions based self-interest with tipping mechanism.

This solution has multiple issues incompatible with our vision of software as a common good and equalitarian currency:

• the use of the common resource is not really free, it comes with a cost
• those wo own more have more right to use the blockchain (they pay less fees in proportion of their total wealth)
• those wo own more are privileged over the other (they can pay a higher tip to the validator to get prioritized)

In some situations like Ethereum, the cost ("gas") became so prohibitive that users left the platform. In some situations like Solana, the base cost is so low that DDos are not expensive enough and occur often, triggering priorization fees.

In our research of finding the best of the two worlds, we came up with a solution that should allow a totally free blockchain use most of the time and a free blockchain use within a quota for humans (identified by the web of trust) during the attacks. This solution is based on substrate's good benchmarking framework. Since we know quite precisely the worst case scenario of each action in terms of storage size and execution time, as well as the maximum capacity of the reference machine, we can set a threshold of activity below which every action is free of charge. When this threshold is exceeded — most likely due to an attack — the fees stop being null and make the attack stop by lack of "fuel". During these attacks, the non-anonymous accounts (= linked to the web of trust) are protected from the attack within a certain quota.

We think that this solution will encourage people tired of bank fees to try our blockchain and give room for unexpected application that would be financially irrelevant with per-transaction fees like transparent account-based cost accounting for organization.

Blockchain governance for runtime upgrades 🆙

Advanced onchain governance for runtime upgrades like the one leveraged by Kusama are interesting, but:

• it hides the fact that software development is strongly financially driven
• is not well suited to the rather small-sized, strongly linked, non-technical Ğ1 community

For the moment, we simply want to make more transparent the way things worked in v1. First developers come with an idea, they voluntarily come with an implementation, talk with the other devs, and submit it to the smith. Smiths are not necessarily tech people, but they trust the developers and install the update. In v2 we needed to secure the smith group by a smith web of trust (more on that later) and to get more reactivity for the runtime upgrade, hence a more well-informed technical committee. We first thought it would be a centralisation issue for the community but we found that 1️⃣ this is a particularity of forkless consensus systems that a more sophisticated voting system can help scale but not fix (🞰), 2️⃣ this is not what the community expects when it comes to software development, hence the next section (🞰).

Software ecosystem built with the community (🞰) 🤝

What the community really expects is not theoretical perfection of the way decision are taken but the evolution of the final app they will have between their hands. In other words, the way UI are crafted is more important to common user that the core system they rely on. It's more important that their feature requests are implemented in a reasonable amount of time than the process of this implementation. So we will focus first our efforts on establishing and maintaining a high-quality link between the community will and the implementation and only then implement self-governance mechanisms rather "bottom-up" than "top-down". This means we will likely first experiment with offchain information and voting system before implementing them onchain.

Stay tuned if you are interested in our developments and do not hesitate fund the project to help it grow!