Supply chain “blockchain vs crypto-monnaie” = “Audit vs traçabilité” ?
Une “blockchain” si on admet qu’il y a une définition technique unique, permet de historiser des empreintes numériques unique d’évènements signés, liés aux précédents et de répliquer cet historique sur plusieurs serveurs. Ca ne permet pas d’arbitrer sur les différentes versions en concurrence sur le réseau, et ça ne protège pas de la corruption, censure, altération, des versions forcées, ni de la centralisation des données, ou d’une dépendance à des autorisations tierces par des mainteneurs de l’infrastructure qui ont leurs interfaces elles-mêmes dépendantes de systèmes/acteurs tiers. Pour cela il faut briser le lien économique entre les utilisateurs de la blockchain et ses mainteneurs; c’est un des rôles des crypto-monnaies. Avec des mainteneurs inconnus des utilisateurs, sans moyen de distinguer un évènement d’un autre, dont le comportement est dirigé par des enjeux économiques ad’hoc (récompense pour la sécurisation mathématique de la version de référence). Donc la preuve sera d’autant plus forte sur une crypto-monnaie dont le “créateur” technique de la preuve est réellement indépendant.
Mais surtout, si quelqu’un veut “certifier” de la viande cheval alors que c’est du boeuf, à l’origine de l’étiquetage il mettra que c’est de la viande de cheval, signera, ce sera horodaté, et pour toute la succession d’acteurs il y aura sur la blockchain une “preuve” que l’auteur à dit à tel moment que c’est du cheval. On peut donc auditer qui a signé quoi et quand mais ça n’apporte pas de “vérité”. Mais il n’y a pas de trace entre la représentation numérique et sa réalité physique.
Pour avoir un début de vérité il faut que l’on puisse vérifier à tout moment la correspondance entre l’empreinte physique de ce qui est représenté et sa représentation sur la blockchain.
Parfois l’IoT permet d’aller plus loin, mais c’est facilement falsifiable en fournissant à l’IoT de fausses informations qu’il capturera sans distinguer d’erreur ou avec un IoT corrompu ou en simulant un IoT.
Les processus de représentation des unités de la supply chain se créent souvent avec une description vérifiable des caractéristiques représentées par un Merkle Tree (off-line) dont la racine est à signer et à historiser sur une blockchain. C’est à dire signer l’empreinte finale totale de l’ensemble des empreintes de chaque caractéristiques dans un ordre précis. C’est cette représentation finale et la description associée qui doit être auditable et tracé dans la mesure ou les signataires ont les moyens de reproduire sur l’objet réel, la capture des preuves des caractéristiques pour retrouver la même empreinte totale finale que celle historisée sur la blockchain. Dans ce cas, les vérificateurs ont un rôle clé qu’il faut sécuriser pour garantir une traçabilité.
Cette description est aussi valable pour les état opérationnels de la supply chain, permettant (en toute confidentialité) de partager les états opérationnels en transverse des acteurs de la supply chain, sans dépendre d’une infrascture centrale (ce qui fournirai un avantage à celui qui l’exploite).
Les multi-signatures complexes comme on peut en produire avec min.sc sont souvent plus efficaces pour créer une traçabilité. Il faut une diversité d’intérêts de acteurs concernés, avec si possible une concurrence sur la “vérité” des représentations signées (donc un modèle économique), et une entropie sur la sélection des participants aux signatures qui peut être relativement simple en favorisant de manière décroissante les premiers acteurs de type :
- i(n=1) = ( ( #bloc mod ∑ Participants ) / 2 ) + 1
- i(n>1) = ( i(n-1) / 2 ) + 1
Index (i) du premier participant (n=1) dans la liste des participants à la multi-signature dans leur ordre de “révélation” (la liste des participants est elle même une preuve distribuée).
Techniquement, la multi-signature à d’autres avantages pour la robustesse de la preuve lorsqu’il est produit sur des registre par entrées/sorties (type Bitcoin) à l’instar des registres par adresses de comptes et de smarts contracts (type Ethereum). Dans le cas des entrées sorties, les scripts exécutant les multi-signatures sont natifs au protocole est fonctionne manière strict et vérifiée, la description des conditions de multi-signature est fournie par les utilisateurs qui peuvent créer leurs adresses, leurs transactions (confidentielles pour éviter tout risque concurrentiel), les signer et les envoyer aux autres acteurs pour multi-signature en toute autonomie, sans les serveurs de la blockchain. L’utilisateur est totalement autonome avec ses preuves dont il un totalement libre accès sans dépendance au système pour se défendre le cas échéant. Ainsi la production de la preuve et les signatures appliquées sont directement liées aux acteurs, sans intervention d’un smart contract tiers qui aurait été alors écrit par des développeurs rémunérés par l’un des acteurs et avec des failles potentielles (Ethereum rends possible de nombreuses failles car il est Turing complet). Cette multi-signature peut être appliquée par de l’IoT (équipement identifié et sécurisé au passage) comme par des personnes ou des personnes représentant des organisations, avec divers niveaux de confidentialité et d’accès possibles. Les multi-signatures peuvent paraître à priori coûteuses sur les transactions, mais dans le cas de la supply chain on certifie un réseau de niveau 2 performante (très rapide, transactions gratuites tel Elements) sur une blockchain de niveau 1 résiliente (PoW tel Bitcoin), donc il n’y a pas coût à l’historisation sur le niveau 2, le coût n’est donc pas une limite à la traçabilité.
Ainsi le processus de multi-signatures sur une crypto-monnaie est adapté pour créer une traçabilité à l’instar de smart contracts ou de la simple utilisation d’une blockchain.
