La valeur des registres répliqués et partagés selon First Principles

Les « monnaies numériques » ne sont T nécessaires pour expliquer l'importance des registres distribués. Dans cet article, Richard Gendal Brown d'IBM développe un argument en faveur des registres partagés répliqués à partir des principes fondamentaux.

Il s'agit d'un « document éducatif » destiné à ceux, en particulier dans le secteur Finance , qui préfèrent que les explications des nouvelles technologies soient ancrées dans une description d'un problème commercial réel plutôt que de commencer par une description d'une prétendue solution.

Ainsi, dans cet article, vous ne trouverez aucune mention des monnaies numériques, car il s'avère que vous n'en avez T besoin pour déduire un argument en faveur des technologies de registre distribué.

Nous commencerons par les systèmes bancaires

Commencez par réfléchir àd'aujourd'huisystèmes bancaires. Dans ce qui suit, j'utilise un exemple de dépôt et de paiement bancaire. Mais la même logique s'applique partout, comme je le démontrerai plus tard.

Imaginons un monde avec trois banques :Banque A,Banque B et Banque Cet deux clients,Client A et Client BChaque banque possède ses propres systèmes informatiques pour KEEP ses soldes. Le monde actuel est très similaire.

Donc Banque ALes systèmes de enregistrent les soldes desBanque Ales clients de ,Banque BLes systèmes de enregistrent les soldes desBanque Bles clients de et ainsi de suite.

Peut-être que l'image LOOKS à ceci :

Deux observations immédiates sautent aux yeux :

• Tout d'abord, regardezBanques A et B.Banque ALes systèmes de ’s enregistrent qu’il lui est dû 1 million de livres sterling parBanque B. Et Banque Bsystèmes deaussi enregistrer ce fait : ils enregistrent queBanque B doit1 million de livres sterling àBanque A. Ainsi, les mêmes informations sont enregistrées deux fois, par deux systèmes développés, maintenus et exploités indépendamment. Dans d'autres domaines, cette duplication est beaucoup plus importante et coûteuse, comme nous le verrons plus loin.
• Deuxièmement, regardezClient A. On leur doit de l'argentBanques A et Cet sont à découvert àBanque B. Autrement dit,Banques A et Cdevoir de l'argent àClient AQui enregistre ce fait ?Banques A et C! Nous tenons cette situation pour acquise, mais il semble très étrange queClient Adoit faire confianceles deuxque la banque sera bonne pour l'argentet que les registres bancaires seront exacts. Cela ressemble à un conflit d'intérêts, s'il en est…

Nous avons donc deux phénomènes intéressants : les déposants doivent faire confiance à leurs banques pour être en mesure de gérer leur argent.etpour rendre compte correctement. Et les banques elles-mêmes doivent consacrer beaucoup de temps et d'argent au développement de systèmes qui font tous à peu près la même chose, et consacrer encore plus de temps et d'argent à vérifierl'un l'autrepour s’assurer que leurs systèmes concordent sur des faits communs.

Même dans notre exemple simple, il y a potentiellement sept entrées correspondantes distinctes à vérifier.

Les « faits » bancaires sont généralement enregistrés par au moins deux entités différentes et un processus coûteux de rapprochement est nécessaire pour garantir que la vision du monde de chaque partie est la même.

Il ne s'agit pas seulement des dépôts bancaires. Les Marchés des valeurs mobilières et des produits dérivés suivent la même tendance.

Cette histoire concerne les dépôts bancaires. Maisexactement la même choseOn pourrait raconter une histoire sur les systèmes de valeurs mobilières et les systèmes de produits dérivés.

En effet, dans ce dernier cas, le problème pourrait être encore pire : non seulement nous devons nous assurer que tout le monde est d’accord sur qui a conclu quelles transactions avec qui, mais nous devons également nous assurer que leurs systèmes s’accordent sur les obligations qui en découlent – ils doivent également s’accorder sur leslogique métier.

Pensez au nombre de systèmes quasi identiques qui existent dans le paysage financier, ONE fonctionnant légèrement différemment et produisant des résultats très légèrement différents qui doivent être étudiés et résolus. C'est extrêmement coûteux.

Retour à l'histoire bancaire

Mais concentrons-nous pour l’instant sur l’exemple du secteur bancaire.

Vous pouvez réaliser quelque chose de vraiment intéressant avec les cinq registres que nous avons utilisés. Vous pouvez les écrire différemment, en conservant les mêmes informations dans uncélibatairetable, plutôt que répartie sur cinq tables différentes :

Les cinq registres distincts de gauche peuvent être écrits, de manière parfaitement équivalente, comme le tableau unique de droite, et inversement. On peut déduire ONEun de l'autre. La seule différence est que le tableau de droite comporte une colonne supplémentaire permettant d'enregistrer à la fois l'émetteur et le titulaire d'une créance.

En d’autres termes, plutôt que d’avoir une vue partielle du monde détenue par chaque banque, nous pourrions avoir un tableau unique qui enregistretout et obtenir le même résultat.

Alors pourquoi ne pas avoir un registre bancaire unique pour le monde ?

Cela soulève une question intéressante. S'il est si coûteux et compliqué pour chaque banque de gérer son propre système, qui reflète sa vision étroite du monde, et de devoir ensuite vérifier sa compatibilité avec les autres systèmes où les faits se recoupent, pourquoi ne pas simplement payer quelqu'un pour gérer uncélibataireun registre dont tout le monde s'accorde à dire qu'il fera autorité ?

Après tout, comme nous l’avons montré plus haut, toute banque qui le souhaitait pourrait facilement tirer sa propre vision du monde de ce méga-tableau, de manière tout à fait triviale.

Bien sûr, nous devrions réfléchir à la manière de gérer l’accès au registre – qui est autorisé à observer ou à mettre à jour quels enregistrements – mais nous savons comment faire… et ce n’est pas un problème impossible.

Es-tu fou?

Il est tentant de dire qu’une telle chose serait insensée : imaginez à quel point l’entreprise quicouruUn tel système. Imaginez les conséquences catastrophiques pour le monde en cas de panne du système !

Peut-être que le système coûteux, sujet aux erreurs, mais fondamentalement décentralisé et robuste (anti-fragile ?) dont nous disposons aujourd’hui est un prix qui vaut la peine d’être payé.

Mais une question intéressante se pose : et s’il existait un moyen de bénéficier des avantages d’un système partagé à l’échelle mondiale, sans avoir à se confronter à la difficile question politique de savoir comment contrôler un opérateur tout-puissant ou comment gérer le risque d’une panne d’une infrastructure aussi importante et centrale ?

Peut-être que nous pouvons y parvenir…

Le registre répliqué et partagé

Rappelez-vous ce que nous avons réalisé dans le diagramme ci-dessus : nous avons créé un tableau unique qui pourrait décrire toussoldes bancaires et qui était intrinsèquement partagé : différents acteurs disposaient de différentes autorisations pour mettre à jour différentes parties de celui-ci.

Mais la crainte évoquée dans la section précédente était qu'un registre mondial partagé soit contrôlé par une seule entité puissante et que ce système centralisé puisse représenter un risque systémique. Pouvons-nous alors apporter deux modifications au modèle ?

• D'abord, pourquoi ne pas reproduire le grand livremassivement. Donc, plutôt qu'un ONE exemplaire, il faudrait en avoir plusieurs. Peut-être un exemplaire dans chaque banque. Ainsi, il T de point de défaillance unique. Nous aurions à nous soucier de comment Ces copies sont bien sûr synchronisées, ce qui n'est T une WIN absolue, mais le fait d'avoir des copies dans chaque banque pourrait également faciliter l'intégration avec l'infrastructure existante. Cela faciliterait peut-être également l'adoption.
• Deuxièmement, pourquoi ne pas faire en sorte que ceux qui participent au système – peut-être seulement les banques ou peut-être aussi leurs clients – soient également conjointement responsables de son maintien et de sa sécurité. Après tout, nous savons qui sont les autres dans ce monde, donc nous savons qui punir en cas de tricherie. Nous remplaçons donc une entité unique et puissante par un modèle oùtout le mondecontribue à la sécurité du système.

Si c'est le cas, l'image ressemblerait peut-être à ceci :

Si une seule copie du registre global partagé est indésirable ou risquée, alorsle reproduireTous les participants pourraient bénéficier du meilleur des deux mondes. Le problème est désormais de synchroniser automatiquement les systèmes plutôt que de les réconcilier et de gérer les interruptions manuellement.

L'image ci-dessus LOOKS superficiellement à ONE que j'ai dessinée au début de l'article. Mais il y a une différence cruciale. ceDans ce modèle, tous les participants disposent d'une copie du registre, mais ne peuvent modifier que les écritures qui les concernent. Il s'agit donc à la foisrépliqué et commun.

Et c'est pourquoi j'appelle ce concept le «registre répliqué et partagéJe pense que cette formulation est plus efficace pour évoquer le bon modèle mental que « grand livre distribué », par exemple.

Et selon que vous souhaitez modéliser des soldes, d’autres actifs ou mêmeaccordsEntre les parties, des startups travaillent sur un projet. J'ai écrit un article l'année dernière qui disaita tenté de donner un sens aux différents acteurs présents– et bien d’autres ont émergé depuis.

« Contrats intelligents »

Il vaut la peine d’accorder une attention particulière à l’idée d’ajouterlogique métier à ce concept : de sorte que les « faits » enregistrés ne concernent T seulement qui possède quoi, mais des accords réels entre les parties.

Cela ouvre la possibilité intrigante de « contrats intelligents » : un monde où les contreparties des produits dérivés conviennent qu'une partie partagée decodereprésente l'accord qu'ils ont conclu entre eux et ils l'exécutent sur le registre partagé et répliqué - éliminant peut-être complètement le besoin de construire, de maintenir, d'exploiter et de rapprocher leurs propres plateformes de produits dérivés propriétaires ?

Peut-être même permettre au code de prendre en charge les actifs du grand livre, de gérer automatiquement les flux de trésorerie et la marge ?

Questions en suspens

Je tiens à souligner que cette approche soulève de nombreuses questions techniques : ce n’est pas une bonne idée à coup sûr.

Par exemple, savons-nous que la Technologies de réplication sous-jacente fonctionne comme décrit ? Dans tous les scénarios de menace plausibles ? Comment pouvons-nous être sûrs qu'une ONE (ou un client) ne puisse T consulter (ou modifier) ​​les informations d'une autre banque ? Quelle quantité de données un tel système pourrait-il contenir ? Serait-il évolutif ? Est-ce le cas ?vraimentune bonne idée de modéliser les accords juridiques en code plutôt qu'en anglais ?

Conclusion

Il semble y avoir de nombreux exemples de systèmes dupliqués à grands frais dans plusieurs domaines du système bancaire.

L'idée d'uncommunLe grand livre est prometteur, avecréplicationLes participants constituent un mécanisme permettant de réduire les risques et de mutualiser leur fonctionnement. Il reste cependant à vérifier si cet argument est valable en pratique. Je m'attends donc à voir de plus en plus d'expérimentations de la part des banques et d'autres acteurs dans les mois et les années à venir.

Note de l'auteur : Pour éviter tout doute, dans l'article ci-dessus, j'étaispas en parlant de Bitcoin – cet article concerne le domaine que j'appelle parfois le monde non « semblable à Bitcoin », comme défini dans cet article.

Cet article a été initialement publié surLe blog de Richard. Il a été republié ici avec permission.

Image du grand livrevia Shutterstock