Amazon QLDB (Quantum Ledger DataBase) est une base de données as a service qui fournit un journal de mutations transparent, immuable et vérifiable par cryptographie, appartenant à une autorité de confiance centrale. Amazon QLDB suit chaque modification des données d'application et conserve un historique complet et vérifiable des modifications dans le temps.

Nous allons voir dans cet article quels sont les domaines d’application de cette technologie et comment créer et requêter une base.

AWS QLDB en détails

Les origines

AWS QLBD repose sur une technologie qu’Amazon utilise déjà depuis plusieurs années en interne. Il leur était nécessaire de stocker de la donnée de manière immuable et traçable pour leur systèmes les plus critiques. D'après Rahul Pathak “nos clients nous ont demandé de leur fournir ces fonctionnalités de registre et un moyen de vérifier l'intégrité de leurs données [...] alors, on a fait Amazon QLDB.”

La démocratisation de la blockchain comme un registre partagé et immuable a popularisé cette notion de tracer l’ensemble des mutations effectués sur la donnée (appelés transactions en blockchain) au point d’en devenir un nouveau standard.

De nombreux acteurs se sont alors tournées vers la création ou l’utilisation d’une blockchain. Hors, utiliser une blockchain publique coûte cher en prix de transactions, et construire sa propre blockchain privé est un casse-tête sans nom. Entre autres, l'hébergement et le maintien d’un noeud blockchain chez chaque acteur d’un consortium est très long et difficile.

Chez OCTO Technology, nous avons déployé de nombreux projects blockchains chez nos clients. La plupart du temps, le besoin principal était “seulement” de connaître l’historique complet des mutations des données et vérifier cryptographiquement l’auteur des mutations. Une blockchain fait parfaitement ce job, mais une blockchain fait bien plus que ça, c’est surtout un réseau autonome capable d’arriver à un consensus sans tier de confiance. Cette fonctionnalité rajoute énormément de complexité à l'écosystème, alors qu’elle n'est pas nécessaire pour les cas simple de stockage de données. Avec QLDB, Amazon se place en tier de confiance en garantissant l’immuabilité du journal de transactions (aka historique des mutations) et est capable de fournir la preuve cryptographique de cette immuabilité. Cela répond donc parfaitement aux projets où la décentralisation n’est pas nécessaire, et vu la facilité avec laquelle on peut déployer une base QLDB (vs la complexité d’une blockchain), il est évident que QLDB répond déjà à un besoin du marché.

Immuable et transparent

QLDB ressemble comme deux gouttes d’eau à une base de donnée SQL sur laquelle on peut ajouter, modifier et supprimer de la donnée. Cependant, l’ensemble de ces opérations est automatiquement tracé et séquencé dans un historique immuable. Cette historique est “append-only”’, ce qui signifie qu’une fois une ligne ajoutée à l’historique, elle ne peut être ni modifiée ni supprimée. Même si vous supprimez une donnée de la base SQL, vous pouvez toujours accéder à l’historique des modifications de cette donnée et lire ses valeurs précédant sa suppression.

On pourrait imaginer un registre des propriétaires de véhicules dans QLDB. Quand une voiture change de propriétaire, on met à jour sa valeur dans la base de donnée. Cette mutation est tracé dans l’historique. QLDB permettrait alors de pouvoir consulter l’ensemble des propriétaires précédents du véhicule. L’historique traque également la date et l’heure des mutations, vous pouvez donc savoir quand la voiture a été vendue.

Vérifiable cryptographiquement

QLDB utilise la fonction de hachage SHA-256 (utilisée par de nombreuses blockchains tel que le Bitcoin) pour fournir une signature cryptographique de l’historique à un instant donné. Cette signature ou “digest” permet alors de vérifier l’intégrité de l’historique et de savoir si il a été modifié ou non (e.g. si une transaction s’est produite ou non). Ce digest est une preuve cryptographique relative à l’ensemble des transactions. Dans le cas d’un registre de véhicules, le digest permettrait de prouver le changement de propriétaire à une date donnée.

Serverless

QLDB est une base de données serverless, autrement dit elle ne nécessite pas de gérer de serveurs. Vous ne payez pas pour un nombre de serveurs choisi à la main, mais pour le nombre de requêtes que vous faites. Vous ne payez donc que pour ce que vous consommez. A noter également que la base passe à l'échelle de manière automatique et transparente afin de faire face à la charge.

Enfin, étant donné que QLDB n’est pas une blockchain décentralisée mais une BDD centralisée chez AWS, ses performances en écriture et en lecture sont bien plus rapides qu’une blockchain et comparable à une base de données SQL classique.

Facilité d’utilisation

Les développeurs familiers avec les bases de données SQL sont déjà en mesure d’utiliser QLDB tel quel. QLDB utilise PartiQL, un nouveau langage libre de requête. PartiQL supporte les requêtes SQL orientés documents incluant des données semi-structurées et imbriquées. QLDB respecte les principes ACID d’atomicité, de consistance, d’isolation, et de durabilité. Dans notre exemple de registre de véhicules, lorsqu’on transfère un véhicule d’un propriétaire A a un proprietaire B, l'opération est exécutée de manière complète et cohérente, ou elle ne s'exécute pas du tout. Les mutations sont en séries. La transaction ne sera jamais exécutée de manière partielle et incohérente, e.g. lorsque le véhicule est transféré au propriétaire B mais non supprimé du propriétaire A ou vice-versa.

Nous allons voir dans le chapitre suivant comment créer et requêter une base QLDB.

Créer et requêter une base

Creation de la base

Pour créer une nouvelle base, il suffit simplement d’aller sur https://console.aws.amazon.com/qldb et d’entrer un nom de base, par exemple ‘vehicules’. Une fois créé, AWS propose un outil de requêtes en ligne. Créons un table:

Insérons-y une nouvelle ligne :

Vérifions:

Allons maintenant dans les paramètres de la base et demandons le calcul du digest de la base :

QLDB nous renvoie le digest ou SHA-256 de la base au 10/2/2019 a 9:34:52 AM, soit 18kdrhSoMVgtQlBC5BDSH1ZkVbjJXwv43zhedUnZ/Do=. On obtient également le Digest Tip qui représente la localisation du dernier bloc couvert par le digest. En effet, bien qu’il se s'agit pas d’une blockchain, QLDB utilise quand même une structure en blocs. Chaque mutation de données génère un ou plusieurs nouveau blocs. Le standId représente l’identifiant de notre chaîne. Pour le moment, une base QLDB ne peut avoir qu’une seule chaîne. Le strandId est donc l’identifiant de notre base de données et ne changera pas. Le sequenceNo représente la longueur de notre chaîne, soit le nombre de blocs qu’elle contient. Ici, notre chaîne a une longueur de 11 blocs.

Mutations

Maintenant, modifions le propriétaire du véhicule:

Vérifions:

Re-demandons le calcul du digest de la base :

Le digest est différent, ce qui prouve que la base a été modifiée. On voit également que notre chaîne fait désormais 27 blocs. Allons donc voir l’historique des modifications:

On y voit deux lignes: la création initiale du véhicule, puis la modification du propriétaire. Chaque ligne montre plusieurs propriétés:

• Le blocAddress qui représente dans quel bloc cette mutation a été enregistrée
• Le hash ou SHA-256 de la data
• La data, i.e. les valeurs du document après cette mutation en particulier (on voit donc ici toutes les valeurs précédentes du document)
• La metadata qui montre:
  • l’id de la data modifiée dans la base de données
  • la version de la data. Cette valeur est auto-incrémentée par QLDB à chaque mutation. La création du véhicule est la v0 et le changement de propriétaire représente la v1
  • le txTime ou la date de la mutation
  • le txId, un id auto-généré pour chaque mutation

Verification

Enfin, QLDB propose un outil de vérification cryptographique de la donnée. Supposons que j’enregistre le digest sur mon ordinateur au bloc 45. Ce digest couvre donc l’ensemble des mutations jusqu’au bloc 45. Puis, plus tard, au bloc 87, supposons que je souhaite vérifier la création de mon véhicule au bloc 4. En utilisant l’ID du document, je peux demander a QLDB de recalculer le digest de la base jusqu’au bloc 45 et de le matcher au digest que j’ai enregistré précédemment. Si les digests sont égaux, cela prouve que l’historique et plus particulièrement cette mutation n’ont pas été altérés entre le moment où j’ai enregistré le digest au bloc 45 et maintenant au bloc 87.

Conclusion

AWS QLDB est un veritable game changer. Aussi simple à utiliser qu’une base de données SQL, QLDB permet également d’obtenir l’historique de toutes les mutations et de prouver cryptographiquement que cet historique n’a pas été altéré. De nombreux cas d’usage de blockchain privé peuvent alors être remplacé par QLDB. On pourrait également imaginer une surcouche API de signature par clé privée/clé publique afin de vérifier cryptographiquement l’auteur des mutations, on aurait alors le parfait système de traçage des données. Cette utilisation serait particulièrement intéressante pour les entreprises nécessitant d’avoir une donnée auditable, telle que les banques.

A noter cependant que QLDB a quelques limites en terme de taille et appels concurrentiels. Enfin, QLDB est centralisé chez AWS mais est-ce vraiment un problème quand on peut chiffrer la donnée et prouver qu’elle n’a pas été altérée par Amazon ? La décentralisation est importante pour de nombreux cas d’usages en blockchain publique, mais dans les autres cas, il y a désormais QLDB.