Désir d'une garantie au-delà des SLA/certifications
Pour garantir la transparence des opérations (en l'occurence : les certificats)
CONIKS applique ce modèle à la transparence des certificats
Réaction à postériori pour minimiser la latence/le blocage induit
Pour garantir l'auditabilité sans attiser la curiosité de tiers (autres clients, employés, etc.)
CONIKS par entreprise client, ou Trusternity/Hyperledger
vs
n’importe qui dans le monde peut lire et envoyer des transactions
sécurité reposant sur une cryptoéconomie incitant à participer à la vérification des transactions
si un tiers de confiance est possible : gouvernance simplifiée, granularité des droits, coûts réduits, rapidité, confidentialité.
sécurité reposant sur une approbation centralisée ou en consortium des transactions
Les deux offrent une garantie sur l’inaltérabilité du registre distribué, même lorsque certains participants sont maladroitement ou volontairement fautifs.
vs
Les deux synchronisent les données auprès de chaque participant, permettant un traitement local.
Les smart contracts sont écrits sous forme de code ajouté en tant que bloc.
Leur logique est publiquement auditable.
Quand un évènement concerné par le contrat a lieu, e.g. l'expiration d'un certificat ou l'ajout d'une nouvelle donnée au registre, son code est exécuté.
Les clients et acteurs sensibles (e.g. des régulateurs ou des responsables d'audit) ont une garantie de transparence non plus seulement des résultats d'opérations, mais de la logique qui les a créés.
Autres exemples :
Opérer sur des données privées et déléguer l'audit à un consortium/tiers (TPA) via Hyperledger Fabric
Stockage sur le registre
de la preuve (signature de
l'organisation et de F&S)
Vérification indépendante
voire du client lui-même