J’aimerais profiter des RML16 pour créer la toile de confiance initiale de la ĞDev et lancer la blockchain ĞDev par la même occasion 
Cela implique d’avoir choisi entre-temps les valeurs des paramètres, on en discute
ici:
Disclaimer
Je rappelle qu’il s’agit d’un logiciel libre que je développe sur mon temps libre les soir et week-end, je ne suis lié par aucun contrat et je n’apporte donc aucune garantie quant au bon fonctionnement de cette 1ʳᵉ monnaie de test. Il est tout à fait possible qu’il y ait de gros problèmes et que l’on soit obligé d’arrêter la blockchain ĞDev prématurément (ou qu’elle soit carrément bloquée). Si cela arrive ce n’est pas grave, je relancerai la blockchain ĞDev à partir d’un nouveau genesis dans les jours/semaines qui suivront (avec la même wot initiale où très proche).
Security
Certaines fonctionnalités indispensables à la bonne sécurité d’un mainnet sont manquantes, mais ce n’est pas gênant, car la ĞDev comportera un admin central (moi), qui pourra tout faire, y compris supprimer un membre ou une autorité.
Bien entendu, il n’y aura jamais d’admin central dans la Ğ1, cette fonctionnalité est réservée aux réseaux de test, elle permet de lancer un réseau sans attendre d’avoir toutes les fonctionnalités pour assurer le niveau de sécurité que requiert un système décentralisé.
Features
La ĞDev contiendra déjà la plupart des fonctionnalités de la Ğ1 dès son lancement, et même de nombreuses fonctionnalités en plus (la plupart apportées par substrate donc n’ayant pas demandé de développement spécifique de ma part, seulement de la configuration/intégration).
La seule grosse fonctionnalité en plus que j’ai développée moi-même, c’est la sous-toile forgeron.
Liste non-hexhaustive des fonctionnalités:
- La monnaie crée par Dividende Universel avec transfers en quantitatif et en relatif DU
- Les actions utilisateur planifiables, ce qui permet par exemple les virements automatiques (pallet scheduler).
- Les comptes multisig: compte partagé nécessitant la signature de plusieurs clés privées.
- Atomic swap (pallet atomic-swap)
- La toile de confiance (tout sauf la distance)
- La sous-toile forgeron
- Un collectif des membres forgerons: gouvernance on-chain permettant de réaliser n’importe-quel “call” au nom d’une proportion des members forgerons.
- Une trésorerie commune: compte spécial sans clé privée, qui ne peut être dépensé que par la blockchain. La trésorerie commune est alimentée par don libre et par la monnaie prélevée pour frais ou/et sanctions. N’importe-qui peut proposer d’utiliser les sous de la trésorerie pour financer un projet, la proposition doit être approuvée par 50% des membres forgerons pour être exécutée.
- La possibilité de déléguer des droits sur son compte à un autre compte (pallet proxy)
- Et d’autres fonctionnalités encore
Missing Features
Certaines fonctionnalités sont manquantes, et seront ajoutées par runtime upgrade, où par purge du réseau si nécessaire pour ne pas trop ralentir les développements.
Il manque notamment:
- L’étalonnage des weighs: indispensable pour estimer correctement le coût d’exécution de chaque transaction. Pour le moment les weighs sont inscrits manuellement à des valeurs surévaluées par sécurité.
- La gestion des “offences”: c’est à dire comment sanctionner les autorités qui agissent mal. Le consensus BABE/GRANDPA gère le système de rapport automatique d’“offences” et de vérification de leur validité, ce qui permet de prouver qu’une autorité a mal agi, mais ça ne gère pas les sanctions, donc pour le moment dans la ĞDev une autorité qui agit mal ne sera pas sanctionnée (ce qui n’est pas gênant, car il y a un admin central).
- L’évaluation de la règle de distance: de par la manière dont est conçu substrate, et les contraintes du consensus BABE/GRANDPA, on ne peut par calculer directement la distance on-chain. Il va donc falloir développer un système d’oracle, ça sera probablement la plus longue feature manquante à développer.
- La création manuelle du DU
- L’auto-renouvellement du membership
- Peut-être d’autres fonctionnalités que j’oublie
Autorités au genesis
Par mesure de sécurité et de simplicité, il y aura une seule autorité au genesis (mon compte), et dans un premier temps je serai le seul à pouvoir ajouter des autorités, j’en ajouterai au compte-goutte en fonction des volontaires et si tout ce passe bien.
J’ouvrirai le droit de rejoindre les autorités lorsque je serais suffisamment confiant sur la stabilité du réseau, probablement quelques jours/semaines après le lancement.
Déroulement du lancement
Le lancement va se dérouler en plusieurs étapes, certaines seront peut-être diffusées en live où en différé selon les conditions de connexion sur le lieu des RML16.
Avant les RML16:
Choix des paramètres du genesis
Vérification minutieuse des paramètres du runtime, si possible contre-vérifiée par au moins 2 autres personnes. je ferai sans doute une visio dédiée pour ça, il faudra juste qu’on soit 2 ou 3 (max 4), ça ne sert à rien d’être trop nombreux).
Tag et build du runtime définitif qui sera inscrit dans le genesis.
Faux lancement de test pour vérifier que le runtime est fonctionnel
Pendant les RML16, le jeudi (26 mai 2022):
Inscription de ceux qui le souhaitent dans la wot initiale. Vérification des clés en présentiel.
Génération des chain spec
Faux lancement de test pour vérifier le fonctionnement des chain spec
Pendant les RML16, le vendredi (27 mai 2022):
Réel lancement du genesis et déploiement de nœuds RPC publics
Test des différentes fonctionnalités avec les présents aux RML16, c’est aussi une bonne opportunité de découvrir son fonctionnement en interagissant avec.
Si l’on trouve des bugs corrigeables rapidement, j’en profiterai pour faire un atelier pour montrer comment corriger un bug dans le cœur.
