La plateforme Arc

Original article in English here.

Au moment où nous avons fondé DAOstack au début de 2017, nous avions deux idées principales sur les DAO. La première était que les organisations autonomes décentralisées (DAO) constituaient le principal cas d’utilisation de la blockchain après la monnaie, et la seconde était qu’il était impossible de prédire à quoi ressemblerait ces DAO et qu’elles évolueraient rapidement. En conséquence, nous avons décidé de créer Arc, une plate-forme générique pour les DAO sur le réseau Ethereum.

La notion d’Arc doit être une plate-forme modulaire, facilement évolutive, permettant une sélection naturelle rapide des systèmes de gouvernance. Nous créons une bibliothèque ouverte de composants interopérables qui permettra de créer rapidement et facilement de nouvelles organisations. Cela ressemble un peu au modèle WordPress pour les sites Web. Nous avons choisi de l’appeler Arc d’après le mot grec arche.

Architecture

L’architecture est probablement le plus gros défi lors de la construction d’infrastructures. Nous devions créer une plateforme suffisamment souple et adaptée à tous les types d’organisations et d’idées en matière de gouvernance. Le mot clé est, encore une fois, la modularité. Après un processus long et itératif, la version actuelle du système prend cette forme :

Notez d’abord que chaque case de la figure est un contrat. (Pour être plus précis, il pourrait également s’agir de contrats de proxy + logique.) Les trois contrats de gauche sont le token, la réputation et l’avatar, que nous appelons les acteurs (ou organes). Token ne nécessite probablement pas d’explication, car il s’agit du cas d’utilisation le plus répandu du réseau Ethereum, contrairement à la réputation et à l’avatar.

Un avatar est le visage d’une organisation figurant sur la blockchain, par exemple. si l’organisation doit être propriétaire de quelque chose, comme la propriété d’un contrat ou d’un actif, l’adresse sera celle de l’avatar.

La réputation nécessite encore plus d’explications, car différentes personnes utilisent le mot «réputation» en pensant à des choses très différentes. Dans Arc, la réputation représente votre pouvoir de décision dans un DAO donné. C’est unidimensionnel, ce qui signifie qu’il existe une simple carte entre les adresses et les nombres. Il ressemble beaucoup à un token, avec deux différences principales : premièrement, il est incessible, et deuxièmement, il peut être accordé ou retiré par le DAO.

Sur le côté droit de la figure, nous avons les schémas. Les schémas sont de simples éléments de logique qui comprennent les différentes actions pouvant être exécutées dans un DAO. Un exemple de schéma est un schéma ICO, dans lequel un agent qui envoie ETH à un DAO reçoit des tokens de l’organisation en retour. Un autre exemple est un système de propositions de financement, dans lequel tout le monde peut suggérer et voter sur des propositions. Si une proposition est approuvée, elle est automatiquement financée.

Au fond se trouvent les contraintes globales. Le concept de contraintes globales est presque obligatoire lorsque l’on considère la logique modulaire, car on souhaite généralement empêcher les modules de violer certaines règles globales. Un exemple est un plafonnement de la réputation possible totale d’une organisation ou un taux de consommation maximal des fonds d’une organisation.

Nous avons ensuite le contrôleur, qui est un module de contrôle d’accès. Il conserve une trace de tous les modèles enregistrés dans un DAO ainsi que des autorisations pour chaque modèle. En outre, il enregistre toutes les contraintes globales et les applique en annulant les transactions qui ne respectent aucune de ces contraintes.

Les derniers types de composants sont les machines à voter, également appelées modules de gouvernance. Ces composants permettent la modularisation du processus de prise de décision, permettant des itérations rapides et le développement de tels modules. Le type principal de machine à voter mis en place aujourd’hui repose sur le protocole holographique Consensus, le modèle de base de DAOstack pour la gouvernance décentralisée.

Code de recyclage et efficacité du gas

L’une des premières questions à prendre en compte lors de la création d’une plateforme de contrats intelligents concerne le recyclage du code. La création de composants partagés comporte de nombreux avantages, mais elle soulève également des problèmes de complexité, de sécurité, d’efficacité et de facilité d’utilisation. Deux approches principales peuvent être envisagées.

L’une est l’approche du contrat en tant que service (CaaS). Dans ce concept, un contrat unique est utilisé pour servir de nombreuses organisations / agents. Comme exemple de CaaS, pensez à un contrat multi-signature qui maintient des soldes pour tout groupe qui souhaite l’utiliser, au lieu que chaque groupe déploie son propre contrat. Cela économise beaucoup de carburant lors du déploiement, car le contrat n’est déployé qu’une seule fois pour que tout le monde puisse l’utiliser. Il faut simplement ajouter à chaque transaction un paramètre indiquant le portefeuille auquel il est fait référence, ce qui peut être fait à très bas coût en gaz. Le principal inconvénient de l’approche CaaS est que le contrat est un peu plus complexe, ce qui peut entraîner des coûts de sécurité. De plus, cela peut créer des difficultés lors de la construction de l’interopérabilité entre les contrats, car la norme de blockchain est qu’une adresse représente une « identité », et nous avons ici une adresse unique représentant plusieurs identités.

La seconde approche du recyclage de code est l’approche par procuration. Dans cette approche, on déploie un contrat logique avec des contrats proxy qui ne font que des delegate calls au contrat logique. Cette approche coûte moins de gas en déploiement que de conserver un contrat séparé contenant toute la logique, mais elle coûte un peu plus cher pour chaque transaction, en raison de l’ajout de delegateCall. Le coût du gas de delegateCall est particulièrement problématique pour les appels de «transfert», limités à 2300 gas (problème pour lequel nous avons récemment proposé un correctif pour Github). Un autre inconvénient de l’approche proxy est la complexité supplémentaire du codage, et en particulier de l’initialisation du contrat. La version actuelle d’Arc utilise l’approche CaaS. Nous sommes en train de faire des recherches approfondies sur l’approche par procuration, à la fois pour les raisons évoquées ci-dessus et parce que cette option augmenterait également la possibilité de mise à niveau (qui présente par ailleurs ses propres pièges et complications).

Sécurité

L’avantage principal d’un système modulaire est qu’il est beaucoup plus facile d’effectuer un audit et de le sécuriser, car des éléments simples peuvent être examinés et testés de manière approfondie. Ce n’est bien sûr pas une garantie, mais c’est une approche pour s’attaquer au problème. Cette approche a été mise à l’essai lors d’un audit approfondi mené par les experts de ChainSecurity, qui a été adopté par Arc.

Quoi qu’il en soit, notre approche principale en matière de sécurité dans DAOstack consiste à tester sur le feu, ce qui signifie que le code doit être utilisé dans le monde réel, avec de l’argent réel, dans l’intention que les gens essaient de le résoudre et de nous aider ainsi à détecter les bogues. Nous avons l’intention d’augmenter progressivement le montant des fonds de notre contrat, à mesure que nous aurons l’assurance de leur sécurité.

Roadmap

Arc est toujours une version alpha, nommée Genomics. La prochaine grande version, sous le nom de code Genuine, contient principalement des améliorations en matière de modularité et d’évolutivité. Il est prévu pour le deuxième trimestre 2019, bien qu’au rythme actuel, il sera probablement publié plus tôt.

Remerciements à Oren Sokolowsky et Josh Zemel.