Yaron Goland, architecte principal chez Microsoft, a publié un article décrivant comment un client de la blockchain peut être implémenté AP ou CP en fonction de sa mise en œuvre. Cela permet de configurer le nombre de blocs après une transaction jusqu'à ce qu'elle soit acceptée. Plus il y a eu de blocs après la transaction, plus il est probable qu'il y ait un large consensus dans l'ensemble du système, ce qui le rend cohérent.
La blockchain est une base de données distribuée, pair à pair, sans source centrale de vérité. Goland explique comment cela pourrait être particulièrement problématique pour les devises numériques comme le bitcoin. Un utilisateur peut croire avoir reçu des bitcoins, échanger de l'argent réel avec, puis vérifier leur portefeuille à un moment ultérieur seulement pour découvrir que les bitcoins ont disparu.
Alors que la blockchain est une série de blocs immuables, il est toujours possible pour chaque pair de construire un ensemble différent d'historique de transactions. Cette divergence est connue sous le nom de forking et qui est la cause du problème de cohérence dans l'exemple de Goland. Il explique que la façon dont la chaîne de blocs résout ceci est avec un algorithme de consensus, où éventuellement, il existe un accord majoritaire sur lequel les forks devraient être abandonnées :
Il s'agit d'un exemple assez classique d'une éventuelle cohérence. Deux valeurs contradictoires ont été écrites, le système les a détectées et éventuellement un protocole de résolution de conflit a été utilisé pour choisir un gagnant.
Goland explique que c'est le choix d'attendre ou non que la blockchain devienne finalement compatible qui fait qu'un client est AP ou CP. Pour être AP, un client doit accepter une transaction dès qu'elle est ajoutée à la chaîne de blocs. De cette manière, il n'y a pas de dépendance à l'égard du reste des pairs, ce qui le rend disponible, mais il y a un risque que les pairs restants rejettent la transaction et sacrifient la cohérence. Pour être CP, le client devrait accepter la transaction une fois que la chaîne de blocs est parvenue à un consensus. Cela a l'effet inverse, où les données sont cohérentes, mais risquent de devenir indisponibles s'il existe une partition réseau empêchant un consensus.
En termes d'attente d'un consensus sur le système d'une transaction, Goland a publié une explication détaillée qu'il résume comme suit : "Ne pas traiter tout ce qui existe jusqu'à ce qu'il soit au moins X blocs". Cela signifie qu'un client attendra que X blocs en plus se produisent après une transaction jusqu'à ce qu'elle soit acceptée.
Yaron souligne également que la possibilité de configurer un client de cette manière ne viole pas le théorème CAP. C'est parce que ce type de configuration est un compromis entre disponibilité et cohérence - les deux ne peuvent pas être tenus simultanément :
Donc, ce que nous avons fait ci-dessus ne montre pas que Bitcoin peut être à la fois AP et CP. Ce que nous avons fait ci-dessus montre comment on peut construire deux systèmes complètement différents avec des compromis CAP complètement différents en gardant toutes les parties de Bitcoin identiques sauf les clients".
En résumé, Goland a démontré que, bien que la chaîne de bloc soit un modèle pair à pair, de fortes exigences de cohérence peuvent être satisfaites. Ceci est particulièrement important pour les devises numériques telles que le bitcoin, car ce type de compromis signifie que les utilisateurs peuvent faire confiance aux transactions.