Wolden@vdn ...et plus

Blog Woldenien de VOL DE NUIT

0 notes

#blockchain : Cahier des charges VDNchain

L’API #VDNchain est un outil transactionnel peer-to-peer encore expérimental de type blockchain conçu pour être à la fois simple, rapide et fiable. Dès le début (été 2014) un cahier des charges a été établi pour définir à la fois sa philosophie générale et la ligne directrice de son développement. Pour en savoir plus sur les méthodes, les techniques et les objectifs reportez-vous aux articles précédents : http://woldenavro.tumblr.com/archive

L'objectif de VDNchain n’est pas de proposer une solution universelle capable de concurrencer tous les outils/APIs blockchain actuellement disponibles mais de fournir une solution adaptée à des besoins clairement identifiés dans un contexte spécifique :
- une communauté d’utilisateurs restreinte (moins de 100 000 personnes)
- des besoins de transactions et des mises à jour très rapides (quelques secondes)
- un cryptage assurant une sécurité de niveau satisfaisant (inviolabilité)
- tous les utilisateurs sont strictement égaux entre eux (pas de miners rétribués)

Cet article aborde en détail les 20 points du cahier des charges qui ont présidé à l’élaboration de VDNchain :

1. simple
Aucun outil, aucun logiciel particulier n’est à installer, tout se passe dans le navigateur web et tout passe par lui. Seule restriction : posséder des versions récentes comprenant HTML5 et les requêtes de type SSE, DSL, etc.

2. universel
Le serveur contenant les algorithmes et les scripts techniques doit être le plus universel possible. PHP est actuellement le langage serveur le plus partagé ; il est offert en service de base chez tous les hébergeurs, contrairement à d’autres technos mieux appropriées mais plus rares type node/websockets. JavaScript est requis sur chaque machine utilisateur.

3. portable
Utilisable sur tout appareil connecté : ordinateur, phone, tablette, mais aussi tout objet à venir (Internet des Objets) : montre, voiture, frigo, capteurs de toutes sortes.

4. rapide
Toute transaction (login, mise à jour de chain, échange de crypto-monnaie associée, vote en ligne, …) doit pouvoir être réalisée en moins de 10 secondes.

5. capillaire
Aucune machine ne doit détenir l’intégralité des chains qui pourraient dès lors potentiellement être hackées ; seules des extraits cryptés sont disponibles machine par machine. Certaines fonctions de l’algorithme sont chargées de reconstituer momentanément les chains pour réaliser les opérations courantes nécessaires (approbations, transferts, mises à jour, …) dont le résultat sera diffusé ensuite de machine à machine par capillarité de proche en proche.

6. sécurisé
Les fonctions de cryptage (hashage, saltage, encodage et leur mutabilité) sont opérées sur 100 caractères et signes clavier (A->Z, a->z, 0->9, {[@!-_*?$]} ) par un jeu de double clé (publique et privée) inspiré de PGP pour assurer l’inviolabilité des chains. La mutabilité changeant l’encryptage à chaque transaction, la sécurité s’accroît avec le nombre d’utilisateurs. Si il y a à terme une transaction chaque minute, un hacker ne dispose que de ce laps de temps pour prendre le contrôle de toutes les machines connectées, reconstruire les chains complètes, les décrypter, les modifier et contraindre les machines à toutes se mettre à jour avec sa version frauduleuse.

7. paramétrable
Un fichier de pilotage de l’API est éditable en mode admin pour gérer les utilisations et les types de contenus blockchainés : logins/identifications, transactions de crypto-monnaie, vote en ligne, etc. (voir usages plus bas).

8. économe
Pour économiser de la bande passante, de la ressource serveur et du temps de calcul, les temps de dialogues inter-machines (peer-to-peer) sont réduits au minimum, de l’ordre de quelques dixièmes de secondes. Tout le reste se passe en langage client sur la machine elle-même. Il s’agit souvent autant d’une “synchronisation d’ordres” (le message n’a pas toujours d’importance en soi, c’est parfois le simple fait qu’il arrive qui importe) que de dialogues réels.

9. sobre
L’algorithme est découpé en tranches fonctionnelles qui permettent de n’appeler que les fonctions utiles selon les besoins de l’instant, ce qui réduit aussi aussi d’autant les temps de calculs.

10. égalitaire
Aucun miner ne détient de clés ni d’accès privilégié à quelque fonction que ce soit ; chaque utilisateur étant acteur à 100% de la chain et strictement de même statut permet une mutualisation complète des process de décisions/approbations/validations.

11. fiable
Sans calcul de Preuve de Travail (PoW) la gestion des conflits (chains concurrentes ou contradictoires) doit être solutionné au plus vite (pas de “branche morte”) lors des process de mises à jour à la connexion de chaque machine.

12. fonctionnalisé
La production de crypto-monnaie, de résultats de votes, de validation de login ou de tout autre type de données à blockchainer est fonctionnellement découplée de la gestion interne des chains ; l’algorithme ne fait que gérer les chains indépendamment de leurs contenus et de leurs sens d’usage.

13. temporalisé
La gestion des transactions (par exemple échange de crypto-monnaie de A à B) ne dépend pas du crédit/débit de chacun dans son porte-monnaie virtuel en un instant donné, mais de sa balance globale virtuelle : si A détient 150 unités de compte, qu’il en verse 100 à B puis 100 à C, les transactions sont validées/approuvées si D a entre temps garanti d'en verser 50 à A (qui est donc virtuellement créditeur). Les jeux d’approbations horizontales permettent de prédire à tout moment dans la durée d’un temps T le solde créditeur ou débiteur de chacun.

14. indépendant
Pas d’appels ou utilisation d’API externes : “toutes les ressources du réseau VDNchain sont sur le réseau VDNchain”.

15. vérifiable
Les résultats des calculs algorithmiques doivent pouvoir être contrôlés visuellement un par un en un moment T en mode admin via une interface de data-visualisation, machine par machine ou globalement. Ce ne sont que les résultats qui sont consultables (quel calcul a été réalisé, ce qu’il a donné, quelle séquence a été produite), pas les données elles-mêmes puisque les clés de cryptages privées ne peuvent être toutes détenues simultanément par l’admin qui, en tant qu’utilisateur parmi d’autres, ne possède que la sienne.

16. optimisé
Moins de 300 Ko de ressources serveur + 100 Ko de ressources client suffisent à faire tourner VDNchain. Ceci est rendu possible par la fragmentation des chains et des ressources … à comparer avec les 4.5 Mo de datas Bitcoin et ses 10 minutes de validation/PoW.

17. protégé
Toutes les chains et tous les scripts “client” consultables en code source sont cryptés et obfusqués.

18. modulable
Adaptable rapidement à plusieurs utilisations très différentes (par exemple vote en ligne, coloured coins, titre de propriété, accès à des ressources, etc). Dire combien d’unités sont détenues dans porte-monnaie virtuel ou pour qui l’utilisateur a voté étant encodé/encrypté de la même façon, passer d’une utilisation à une autre n’est qu’une simple définition de contexte.

19. ineffaçable
Les données des chains sont écrites sur chaque machine en différents endroits et selon différentes méthodes (cookies, sessions, storage, etc.) ; en supprimer ou en modifier une, c’est la reconstituer instantanément en tâche de fond.

20. réplicable
Par un outillage spécifique (QRcode, URL persos) les chains individuelles peuvent être dupliquées à l’identique de l’ordinateur au phone ou à la tablette d’un même utilisateur reconnu et approuvé. Toutefois les mises à jour de chains, non-automatisées, se feront donc selon l’appareil utilisé à chaque connexion. Chaque appareil d’un même utilisateur (navigateurs différents) pourra donc du coup contenir des chains incohérentes entre elles mais ce n’est pas une difficulté puisque la reconnexion de l’appareil à VDNchain le remettra aussitôt à jour.

Exemples d’utilisations de VDNchain

Cette liste non-exhaustive propose quelques types d’usages possibles :

- vote distant : validation/sécurisation + changement d'avis
- économie locale : transactions + historiques
- formation : validation diplômes
- location/prêt de biens : contractualisation temporaire/smart contracts
- transports de personnes : validation de titres / confirmation VPC
- transport de biens : contractualisation
- jeux : position/gain de chaque joueur/pièce mutualisés
- invention/création : antériorité des idées/méthodes/process
- groupes : partage des missions + évaluations résultats
- réseaux : protocoles de connexion/authentification
- projets : outil de co-décision
- énergie : gestion des stocks/consommations/économies
- tâches partagées : historique + process successifs interdépendants
- décision : traçabilité des chaines de décisions + approb. horizontales
- contrats commerciaux : solvabilité/suivi exécution/bonne fin
- droits d'utilisation : contrôle + suivi
- localisation : géoloc personnes/ressources/objets/projets
- partage de tâches : séquençages actions/temps
- messagerie p2p crypto-sécurisée (non-interceptable)
- datas persos : préférences, options, choix, caractéristiques, identités
- …

Quelques exemples développés

a. “Vote distant” avec changement d'avis :
Une collectivité locale présente un projet pour lequel il faut voter. La sécurisation du vote est assurée par la chain (inviolabilité, impossiblité d'usurper une identité, cryptage, etc.). Un outil de débat/discussion/échanges est couplé à la plateforme de vote. Je vote une fois ma décision prise, mais en lisant les échanges je me rends compte que finalement mon vote ne correspond plus à ma volonté : je revote une seconde fois ou même une troisième, seul le dernier est pris en compte. Ce qui peut permettre des outils de citoyenneté plus riches en débats puisque rien n'est joué tant que l'heure de fin de vote n'a pas sonné.

b. “Localisation”+“Couplage de tâches” :
A doit réaliser l'action 1 ; dès qu'elle est réalisée, B doit réaliser l'action 2, puis immédiatement après, C réalise l'action 3. Que A, B et C soient des individus ou des machines connectées ne change rien. Dès que l'action 1 est terminée l'info est mise à jour sur toutes les machines connectées (ordis, phones, outils…). Le B le plus proche (localisé) est immédiatement prévenu qu'il doit réaliser l'action 2. Celle-ci faite, la m-à-j capillarisée demande à la machine-outil C de réaliser l'action 3. En terme de productivité on zappe l'étape centralisée (tiers de confiance) qui reçoit et redistribue les informations entre A, B et C.

c. “Energie” :
La détention sur les chains d'infos à la fois individuelles et globales (stats) permettrait à chacun de mesurer par ex son score conso comparé. On peut aussi imaginer des système de coloured coins attribués soit à des actions soit à des consommateurs d'énergie qui permettraient en dataviz de mesurer les évolutions. Ou encore concevoir un dial IoT entre compteur et phone qui capillarise en temps réel les consommations de chacun, ce qui peut permettre une gestion fine des approvisionnements. Et éventuellement le coupler à une transaction débit/crédit dans un sens ou dans un autre : par exemple ceux qui consomment le moins sont crédités au lieu d’être débités.

d. “Economie locale” :
Une balance entre acteurs-producteurs locaux permet d’équilibrer les échanges : par exemple un boulanger qui a fourni le pain et récupéré des légumes auprès du jardinier sait que faire réparer sa fuite d’eau par le plombier le laisse créditeur pour aller ce soir à l’Opéra.