Bonjour tout le monde ! @dan Larimer, l'ingénieur qui a inventé l'algorithme DPoS qui est le moteur des blockchains comme Bitshares, EOS et même Steem, a écrit un article sur Medium nommé "L'intention du code est loi". C'est un article particulièrement important, car il propose à l'intérieur de celui-ci une réforme de la constitution d'EOS que Block.One propose en tant que EOS constituion 2.0. En voici la traduction en français.

Avant d'entammer la lecture de cet article, je vous conseil de jeter un coup d'oeil à ma traduction de la constitution actuelle d'EOS

---

L'intention du code est loi

La communauté EOS s'est lancée dans une grande expérience pour voir si elle peut combiner les meilleurs aspects des crypto-contrats, des contrats humains et de la résolution de conflits humains. Cela fait d'EOS la première chaîne de contrat Ricardienne intelligente.

La naissance décentralisée d'une nouvelle chaîne de blocs et d'un nouveau système de gouvernance peut être désordonnée parce que tout le monde essaie de comprendre les règles. Certaines personnes veulent reproduire les structures juridiques existantes, d'autres veulent réglementer toutes sortes de comportements et d'autres veulent conserver le Code-est-Loi.

En regardant la communauté lancer une chaîne de blocs basée sur EOS.IO, j'ai déjà beaucoup appris. J'ai vu que si vous donnez aux gens le pouvoir arbitraire de résoudre des différends arbitraires, alors tout devient un différend et les décisions prises sont arbitraires. Plus l'arbitre a de pouvoir, plus les différends deviennent vicieux et mesquins et moins le résultat est prévisible.

La promesse d'un code est un texte de loi

La caractéristique la plus convaincante du Code-est-Loi est l'élimination de toute possibilité de différend. Toutes les conditions contractuelles sont définies par le code, qui sera exécuté fidèlement en supposant qu'il n'y a pas de censure. Cela donne à toutes les parties de solides garanties et de prévisibilité, sauf lorsqu'il y a des bogues (différences entre les attentes des parties utilisant le code et ce qui fonctionne réellement).

EOS a reconnu que des bogues se produisent et que la communauté a besoin d'un processus pour établir rapidement l'intention des contrats intelligents et résoudre les choses en conséquence. Ce n'est rien de plus que la formalisation et l'accélération du même type de processus qu'Ethereum utilisé pour résoudre le hack des DAO ou que Bitcoin a utilisé pour résoudre la fourchette (fork) 0.7/0.8.

Le chaos des contrats sous forme libre

Les contrats libres, c'est-à-dire ce que nous utilisons depuis des milliers d'années, sont soumis à toutes sortes de contrôles subjectifs et imprévisibles. Tout, de l'établissement de la validité des signatures aux définitions des mots, en passant par la validité même des termes, fait l'objet de débats. Cela rend leur application très coûteuse et donne au système de gouvernance un pouvoir illimité.

Contrats Ricardiens

Un contrat Ricardien spécifie à la fois des termes de forme libre et des termes de code. La communauté EOS discute actuellement de la question de savoir si et comment faire respecter les termes libres. Ces termes comprennent des choses comme la divulgation obligatoire de la propriété des producteurs de bloc et la certification des faits sous peine de parjure. D'autres veulent de nouveaux termes pour réglementer tout comme le font les régisseurs du gouvernement.

Nécessité d'établir des limites objectives

Les utilisateurs de la chaîne de blocs EOS ont besoin de certaines garanties de la part de la communauté afin de se sentir en sécurité. Si tout ce qui se trouve sur la chaîne de blocs est soumis à la règle de la mafia, personne n'est en sécurité. Si la communauté n'a pas de principes d'organisation forts et objectifs, alors tout est sujet à interprétation et devient imprévisible et arbitraire. Les débats et les conflits qui s'ensuivent peuvent déchirer une communauté.

Block One demande qu'il soit mis fin à toutes les ordonnances d'arbitrage autres que de rendre des opinions non exécutoires sur l'intention du code. Je crois que les producteurs de blocs élus devraient être le jury, qui doit rendre une décision 2/3+1 de geler un contrat rompu et/ou de remplacer un contrat rompu par un contrat qui fonctionne selon l'intention originale (tel que déterminé par arbitrage).

Cela signifie que les producteurs de blocs élus ont le même pouvoir que celui démontré par Ethereum dans le bug du contrat DAO, il est juste formalisé et dans les mains des électeurs symboliques au lieu d'être informel et dans les mains des électeurs du hash power.

Exécution des termes ricardiens (subjectifs)

Le but des contrats Ricardiens est de documenter l'intention des parties et de fournir des preuves d'intention en cas de bug. Si un contrat ricardien comprend des clauses qui ne peuvent pas être évaluées et appliquées par le code, il n'est pas du ressort des producteurs de blocs et de l'arbitrage communautaire pour évaluer et appliquer le code.

Un contrat ricardien correctement écrit est entièrement appliqué par le code ; par conséquent, tous les litiges doivent être résolus en fixant le code. Si un contrat ricardien veut appliquer d'autres lois (p. ex. parjure), il doit le faire en définissant le processus dans le code de présentation des griefs, en nommant les juges, en percevant les paiements de cautionnement, en rendant des décisions et en les exécutant. Tout cela doit se produire au niveau de la couche application, et non au niveau de la couche protocole de base. L'ensemble du processus d'application devrait être objectif, tous les acteurs exerçant une autonomie complète dans les limites de l'intention du code.

Clés perdues et volées

Le but des clés privées est de générer une preuve objective de propriété. Si nous ne pouvons pas nous fier uniquement aux signatures, nous devons nous fier à l'identité et aux interprétations subjectives des intentions. Cela ouvrira la voie à un niveau insoutenable de différends et de nouveaux types de fraude et/ou d'injustice.

La solution à ce problème devrait être de nature technique : mettre en œuvre le multisig avec protection biométrique des portefeuilles matériels avec des délais. Chaque membre de la communauté est responsable de sa propre sécurité et de la configuration des permissions. Permettre un recours à l'arbitrage pour contester la validité d'une signature après qu'elle a été irréversiblement acceptée par la chaîne de blocage ouvre plus de problèmes qu'elle n'en résout. EOSIO a été conçu pour prendre en charge l'Apple Secure Enclave, Touch ID, Face ID, et les temps de délais. Une fois déployé dans les portefeuilles, le vol de clés privées devrait être pratiquement inexistant et les temps de délais devraient s'occuper du reste.

EOSIO a été rédigé à partir de zéro afin de fournir l'infrastructure nécessaire pour vraiment protéger et récupérer les comptes sur la base d’options d’adhésion [opt-in] Ces caractéristiques comprennent la prise en charge de la courbe elliptique R1 telle qu'utilisée par Apple, Android et de nombreux périphériques de cartes à puce. Avec le temps, les utilisateurs peuvent profiter de la facilité d'utilisation de la signature avec un seul appareil tout en disposant d'une sauvegarde sécurisée des signatures de plusieurs appareils. La capacité de lire objectivement le temps d'inactivité des comptes dans les contrats intelligents donne aux développeurs la possibilité de définir leurs propres processus de récupération sans donner à une tierce partie un contrôle potentiel au jour le jour.

Clés perdues et volées

Le but des clés privées est de générer une preuve objective de propriété. Si nous ne pouvons pas nous fier uniquement aux signatures, nous devons nous fier à l'identité et aux interprétations subjectives de l'intention. Cela ouvrira la voie à un niveau non durable de différends et à de nouveaux types de fraude et/ou d'injustice.

La solution à ce problème devrait être de nature technique : mettre en œuvre le multisig avec protection biométrique des portefeuilles matériels avec des délais. Chaque membre de la communauté est responsable de sa propre sécurité et de la configuration des permissions. Permettre un recours à l'arbitrage pour contester la validité d'une signature après qu'elle a été irréversiblement acceptée par la chaîne de blocage ouvre plus de problèmes qu'elle n'en résout. EOSIO a été conçu pour prendre en charge l'Apple Secure Enclave, Touch ID, Face ID, et les temps de délai. Une fois déployé dans les portefeuilles, le vol de clés privées devrait être pratiquement inconnu et les délais devraient s'occuper du reste.

EOSIO a été rédigé à partir de zéro afin de fournir l'infrastructure nécessaire pour vraiment protéger et récupérer les comptes sur la base de l'opt-in. Ces caractéristiques comprennent la prise en charge de la courbe elliptique R1 telle qu'utilisée par Apple, Android et de nombreux périphériques de cartes à puce. Avec le temps, les utilisateurs peuvent profiter de la facilité d'utilisation de la signature avec un seul appareil tout en disposant d'une sauvegarde sécurisée des signatures de plusieurs appareils. La capacité de lire objectivement le temps d'inactivité des comptes dans les contrats intelligents donne aux développeurs la possibilité de définir leurs propres processus de récupération sans donner à une tierce partie un contrôle potentiel au jour le jour.

Avis ECAF [EOSIO Core Arbitration Forum]

Les tout premiers litiges portés devant l'ECAF concernent un site Web d'enregistrement d'escroquerie qui fournit aux utilisateurs de fausses paires de clés publiques/privées. En raison de limitations techniques, même les utilisateurs qui utilisaient des portefeuilles hardware sur Ethereum sont devenus la proie de l'arnaque. Bien que la communauté ait une preuve objective des propriétaires originaux des adresses d'Ethereum, ces personnes sont devenues la proie du site d'escroquerie parce qu'elles n'ont pas utilisé le site Web officiel d'eos.io et n'ont pas suivi les instructions officielles.

Autant j'aimerais que les détenteurs de clés précédents reçoivent leurs jetons en retour, autant je pense que le précédent établi par une telle intervention causerait plus de dommages à l'écosystème EOS que l'argent qu'ils reçoivent. À ce stade, je recommanderais que les producteurs de blocs EOS fassent campagne pour faire un don de charité à la cause pour aider ces gens. Il serait beaucoup moins coûteux pour la communauté EOS de résoudre ces problèmes par le biais de dons de la communauté que par la mise en place d'une intervention des producteurs.

Comment faire respecter les ordonnances d'arbitrage en cas de vol de clés

Dans un monde où la résolution des conflits au niveau du protocole se limite à corriger les bogues dans le code, comment se protège-t-on contre la fraude et le vol de clés ? La réponse réside en une option d'adhésion à un contrat bancaire ricardien qui contrôle les jetons au nom de leurs propriétaires. Les transferts dans le cadre du contrat intelligent font l'objet d'un règlement des différends lorsque les arbitres nommés dans le contrat ont le pouvoir de renverser les transactions et de geler les jetons. Les retraits du contrat bancaire smart sont soumis à un délai de 3 jours après lequel ils ne peuvent plus être annulés.

Ceux qui veulent que les producteurs de blocs élus et/ou ECAF protègent leurs intérêts peuvent opter pour un nouveau contrat intelligent où ECAF/producteurs sont le système d'arbitrage. Les échangeurs qui souhaitent interagir avec ces clients dans un délai plus rapide que 3 jours peuvent également ouvrir un compte de dépôt dans le cadre du contrat bancaire intelligent. La portée du pouvoir de l'arbitre serait limitée à ce seul contrat.

Certaines personnes craignent que tout leur compte soit volé, et pas seulement leurs jetons. Cette situation peut être résolue en plaçant l'ensemble du compte sous la propriété d'un contrat intelligent. En tant qu'utilisateur du compte, vous contrôlerez les clés actives, mais vous ne contrôlerez pas directement l'autorisation du propriétaire.

EOSIO est conçu avec tous les outils et capacités pour construire une gouvernance de haut niveau robuste pour ceux qui préféreraient faire confiance à une organisation comme ECAF pour arbitrer les litiges relatifs aux clés volées. Il peut y avoir des centaines d'organisations de ce type dont chacune fonctionne selon des principes différents et qui peuvent toutes s'appuyer sur la même chaîne de blocs basée sur EOSIO.

Projet de référendum sur la Constitution de l'EOS

1. L'intention du code est la loi où l'intention qui est documentée par le code, le contrat Ricardian, les interfaces utilisateur et l'utilisation réelle.
2. S'il y a un différend sur l'intention du code, l'intention sera déterminée par un vote à la super majorité des producteurs élus ou par un arbitre convenu d'un commun accord par les parties au différend et adopté par les producteurs. Une super majorité peut, à sa discrétion, geler un contrat pendant un différend actif jusqu'à ce que le code pour fixer le contrat soit disponible. Les parties au différend doivent produire le code de remplacement proposé. Les producteurs peuvent imposer des frais ou d'autres exigences aux parties au différend. Une super majorité est définie comme 2/3+1. Les clauses contractuelles ricardiennes qui ne peuvent pas être appliquées par un code qui fonctionne correctement dépassent le pouvoir d'évaluation et d'application du producteur.
3. En aucun moment, les producteurs de blocs élus ne peuvent geler ou modifier les contrats qui fonctionnent comme prévu.
4. Les développeurs contractuels ne sont pas responsables des dommages causés par des bogues dans le code. Toutes les parties sont responsables de la vérification du code et du contrat Ricardien avant l'utilisation.
5. Tous les fournisseurs de services qui produisent des outils pour faciliter la construction et la signature de transactions pour le compte de tiers doivent présenter les termes complets du Contrat Ricardien de la présente Constitution et des autres contrats référencés.
6. Aucune Partie n'a la responsabilité fiduciaire de soutenir la valeur du jeton EOS. Les parties n'autorisent personne à détenir des actifs, emprunter, parler ou contracter au nom des détenteurs de jetons EOS ou de la chaîne de bloc collectivement. Cette chaîne de blocs n'aura pas de propriétaires, de gestionnaires ou de fiduciaires.
7. Un contrat Ricardien est considéré comme accepté lorsqu'une transaction est incorporée dans la chaîne de blocs.
8. Les parties consentent volontairement à ce que toutes les autres parties conservent de façon permanente et irrévocable une copie, analysent et distribuent toutes les transactions de radiodiffusion et les renseignements dérivés.
9. La présente Constitution peut être signée en un nombre quelconque d'exemplaires, dont chacun, une fois signé et remis, constitue un duplicata original, mais tous les exemplaires constituent ensemble un seul accord. L'utilisation de la chaîne de bloc constitue un consentement.
10. Cette Constitution peut être amendée par un vote des détenteurs de jetons EOS qui attire pas moins de 15% de participation au vote par accumulation de jetons et pas moins de 10% de plus de votes Oui que de votes Non, soutenus pendant 30 jours consécutifs dans une période de 120 jours.