Plateforme blockchain R-chain: architecture générale et évolution

Bonjour à tous ceux qui suivent le développement de l'utilisation des plateformes décentralisées dans les processus corporate et inter-entreprises. Nos publications sur ce sujet ont été interrompues début 2018. Non, la Raiffeisenbank n'a pas cessé d'œuvrer dans ce sens: le moment est venu de passer des calculs méthodologiques et de la familiarisation avec les capacités des différentes technologies à la mise en œuvre de business cases spécifiques dans un environnement industriel ou au plus près de celui-ci. Cet article est assez volumineux et en même temps informatif. Par conséquent, nous espérons votre implication et vous avertissons du format du tutoriel.











En 2016-2017, nous avons réalisé un certain nombre de projets de recherche pour construire une plateforme décentralisée de financement du commerce. Test utilisé Ethereum (Rinkeby) comme plate-forme de registre distribué sous-jacente et Ethereum Swarm comme outil de partage de fichiers décentralisé. En plus des problématiques générales de construction d'une plateforme décentralisée, nous avons testé les possibilités des contrats intelligents, l'utilisation d'oracles et des contrats intelligents d'arbitrage. Certains de ces résultats sont





Sur la base de ces projets de recherche,





Le résultat de ce travail assez long a été, comme le disent les militaires, «l'acceptation pour la fourniture» de l'informatique de la Raiffeisenbank de la plate-forme décentralisée régulière R-Chain. Il est désormais proposé comme élément de service à la clientèle pour des groupes d'entreprises de différentes tailles.



Nous partageons les principales caractéristiques de la construction de cette plate-forme, et parlons également de l'évolution de l'utilisation de divers composants «techniques» - plates-formes blockchain et systèmes de fichiers distribués.

Contenu

• Caractéristiques des systèmes d'entreprise et inter-entreprises
• Architecture générale de la plateforme
  
  
  • Architecture des composants logiciels
  • Processus métier unique
  • Avantages de l'utilisation d'un processus métier à guichet unique
  • Inconvénients de l'utilisation d'un processus métier générique
  • Surveillance du réseau hôte
• Évolution de l'utilisation de divers composants techniques
• Expérience dans la recherche et l'exploitation de plates-formes d'entreprise et leur développement ultérieur

Caractéristiques des systèmes d'entreprise et inter-entreprises

Afin que la mise en œuvre de la plateforme en exploitation industrielle se déroule sans heurts et sans excès inattendus pour les développeurs, il faut comprendre que la plateforme proposée au futur participant doit répondre aux exigences suivantes:

• La plate-forme doit avoir un opérateur - une entité juridique qui est responsable envers les participants de son fonctionnement. L'option - chacun pour soi, tout sera décidé par le consensus des participants, et ainsi de suite, typique des plateformes publiques de blockchain, ne fonctionnera pas ici.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

Beaucoup dans cette liste seront surpris de constater que les mots «transactions par seconde» et autres évaluations de performance sont absents. Notre expérience montre que la productivité n'est pas la condition la plus importante pour une mise en œuvre réussie de la plateforme. Les performances doivent simplement être «suffisantes», et il existe de nombreuses architectures de flux de données qui peuvent considérablement augmenter le débit de la plate-forme sous-jacente - des registres de données aux flux turbo latéraux. La probabilité que votre projet meure en raison d'une inattention aux points ci-dessus est hyperboliquement plus élevée.

Architecture générale de la plateforme

Architecture des composants logiciels

Les applications que nous avons utilisées dans nos projets de recherche en 2016-2017 ont été écrites sur la base d'une intégration directe d'interfaces de dialogue avec les composants «techniques» de la plateforme distribuée - geth et swarm. Mais, après avoir analysé les possibilités et les conséquences de cette approche, nous sommes arrivés à la conclusion qu'il est nécessaire d'introduire une autre couche entre le backend métier et les composants «techniques» - un adaptateur d'objets métier unifiés. Cette technique appartient à des schémas assez classiques de construction d'architecture logicielle, ce qui, néanmoins, ne réduit pas son efficacité. En conséquence, l'architecture logicielle du nœud de notre plate-forme a commencé à ressembler à ceci:







Dans cette architecture, l' application métierne fonctionne pas directement avec des abstractions de composants DLT, mais avec un certain "processus métier universel" conditionnel (ci-après dénommé le processus) - il crée un processus, change l'état du processus. La réduction de la structure de données du processus universel et des opérations sur celui-ci aux données et opérations utilisées dans le client DLT est réalisée par un ensemble de composants désignés comme "Miroir des processus métier". Le "miroir" effectue également la transformation inverse des informations reçues du client DLT, et filtre également les informations par des processus qui ne sont pas liés au participant - le propriétaire du nœud. Ainsi, sur chaque nœud, une base de données de processus métier à laquelle ce nœud participe est maintenue dans un état synchrone, et dans le format le plus pratique pour une application métier . Application métierinteragit avec cette base de données - une base de données de processus métier, recevant des informations sur l'état des processus et transférant des opérations pour modifier ces états.

Processus métier unique

Naturellement, la question s'est posée de savoir quelles propriétés devraient être dotées d'un processus métier universel afin de fournir, d'une part, une utilisation maximale des avantages des plates-formes blockchain, et d'autre part, une flexibilité et des fonctionnalités maximales pour une utilisation dans une application métier. Une condition supplémentaire était la possibilité d'implémenter les propriétés sélectionnées sur la plupart des plates-formes DLT courantes, dont les fonctionnalités sont très différentes à certains égards (Ethereum / Quorum / Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Sur la base de l'expérience de nos propres projets et de ceux des autres, nous sommes arrivés aux conclusions suivantes.



Un processus métier universel doit avoir les attributs suivants:

• Paramètres de processus (type de processus, statut, attributs de contexte du processus)
• Liste des rôles des participants au processus
• Liste des documents électroniques relatifs aux processus
• Carte de transition de processus

Dans le même temps, la plateforme doit, au niveau du composant blockchain, fournir les conditions suivantes pour la propagation du processus dans le réseau:

• Exhaustivité et intégrité des informations
• Confidentialité des documents électroniques en dehors du cercle des participants au processus
• Contrôle du suivi de la carte de transition de processus
• Stockage de l'historique des modifications des états de processus

Pour mettre en œuvre ces capacités, des contrats intelligents «cadre» ont été développés avec les ensembles correspondants de propriétés et de méthodes.



Attardons-nous sur certains des attributs et conditions énumérés - quoi, comment et pourquoi.



Paramètres de processus- sont conditionnellement ouverts, car ils sont transmis directement via un contrat intelligent. Pour certaines plateformes blockchain, elles sont fondamentalement publiques (Ethereum / Masterchain), pour d'autres, elles peuvent être fermées par des moyens standards garantissant la confidentialité des données (Quorum - contrats intelligents privés, Hyperledger Fabric - canaux et données privées). Le «type de processus» est probablement le plus important des paramètres du «cœur» du processus dans notre implémentation, car il porte non seulement une charge sémantique, mais aussi fonctionnelle - en fonction du «type de processus», l'adaptateur DLT choisit un modèle de contrat intelligent que ce processus sera Présentez-vous. Pourquoi est-ce nécessaire? De toute évidence, il existe d'innombrables types de transactions et les mêmes divers processus métier qui assurent leur mise en œuvre.Dans un assez grand nombre de cas, les processus métier ne diffèrent essentiellement que par la carte de transition (du point de vue de la plate-forme) et peuvent être mis en œuvre avec un seul contrat intelligent prenant en charge une carte de transition arbitraire (plus d'informations ci-dessous). Mais des moments assez uniques peuvent être associés à un processus métier spécifique:

• (, )
• (, )
• (, )

Essayer de formaliser, de «formater» et d'entasser toute cette diversité potentielle dans un seul modèle de contrats intelligents est absolument utopique. Le développement d'un modèle unique pour un type spécifique de processus métier est un moyen beaucoup plus efficace, offrant à la fois une grande flexibilité et la possibilité de flasher "en dur" les éléments de processus nécessaires et les contrôles critiques directement dans le "cœur" du composant blockchain. Cela exclura toute possibilité de manipulation par des participants individuels. En outre, la plate-forme dans son ensemble combinera l'unification des interfaces pour l'interaction des applications métier avec les processus et une grande modularité de la mise en œuvre de leurs fonctionnalités spécifiques.



Les «attributs du noyau» de notre processus incluent également «status» et «note»: le premier est une brève description de l'état du processus («New», «Canceled», «Closed», «OnApproval»), le second est une chaîne «longue» avec une description plus détaillée du "statut". Nous limitons la longueur d'une note à environ 1000 caractères (par exemple, «Fonds insuffisants dans le compte»), car les documents électroniques joints au processus sont destinés au transfert de quantités importantes d'informations (en particulier confidentielles).



Carte de transition de processus- décrit si un participant ayant un rôle spécifique peut changer l'état du processus et vers lequel. Le contrôle de l'admissibilité des transitions est assuré par le «cœur» du composant blockchain et ne peut être simulé par un participant «impuissant». En outre, la carte de navigation peut, par exemple, être utilisée par une application métier pour déterminer les actions possibles du propriétaire du nœud dans l'état actuel du processus pour la gestion appropriée des composants de dialogue.



Transfert de données confidentielles.Pour transférer des informations confidentielles, des documents électroniques sont utilisés qui sont joints au processus. L'application métier télécharge les documents nécessaires vers le stockage de fichiers local "Miroirs" et les indique dans l'opération de modification de l'état du processus. Avant le transfert du stockage local vers DFS, le document est chiffré avec les clés publiques des nœuds destinataires - participants au processus. Une fois que le conteneur cryptographique ainsi formé est transféré vers DFS, le lien vers celui-ci et le hachage du document original sont transférés vers le contrat intelligent du processus. À la réception des informations sur un changement d'état du processus, les détails du fichier sont extraits dans la base de données des processus métier, puis le crypto-conteneur est extrait du DFS à l'aide du lien et décrypté avec la clé du nœud de réception. Un contrôle est effectué pour s'assurer que la somme de hachage du document spécifié dans le contrat intelligent du processus correspond,le document est placé dans le stockage de fichiers local et devient disponible pour l'application métier. Ainsi, l'application métier ne fonctionne qu'avec la version "ouverte" du document - tous les soucis concernant son transfert sécurisé sont pris en charge par le "Miroir".



L'historique du changement d'état du processus est une séquence de "trames", dont chacune correspond à une opération du changement d'état du processus. Dans notre implémentation, nous stockons les données suivantes pour chaque "frame" de l'historique:

• statut
• Remarque
• l'identifiant de l'initiateur de la transaction de changement d'état

L'historique des modifications est enregistré au niveau du contrat intelligent et permet non seulement de suivre la séquence des transitions à des fins d'audit, mais permet également à l'application métier de traiter correctement la chaîne d'événements, même en cas de leur arrivée ponctuelle (par exemple, gel, interruption de fonctionnement, etc.).



Assurer la signification juridique- un problème très important, que nous avons noté dans la section «Caractéristiques des systèmes d'entreprise et inter-entreprises». Nous sommes partis au départ du concept selon lequel l'importance juridique ne devrait pas être fournie au moyen d'une plate-forme blockchain, mais à travers l'utilisation d'une PKI externe bénéficiant d'un soutien réglementaire ou d'un niveau de confiance approprié entre les participants de la plate-forme. En gros, un document électronique qui fournit une base légale à vos actions (document de paiement, contrat, demande, etc.) et joint au processus doit être signé sur la base d'une PKI «casher» (en Russie - GOST, quelque part à l'étranger, par exemple, SSL ou PGP / GPG). L'application métier vérifiera la signature «externe» et prendra les mesures appropriées. Ou pas, selon le résultat. Quelqu'un diraque ce n'est pas «évangélique» et «nous devons convaincre les avocats de la signification juridique des transactions blockchain». Nous avons traversé de nombreuses étapes de ce voyage et le résultat était toujours le même. Cependant, dans le cas de la RussieLa certification Masterchain ouvre certaines opportunités à cet égard - comme le dit le dicton "Bonne chasse!"

Avantages de l'utilisation d'un processus métier à guichet unique

Qu'est-ce que cette approche nous a apporté au final?

• Élargir le cercle des développeurs potentiels d'applications métier décentralisées. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

Ici, probablement, comme il est chanté dans une chanson célèbre - "Derrière eux, vous pouvez entendre un murmure ..." - par exemple, que le code de chaîne Hyperledger Fabric ou Corda, contrairement au Solidity un peu trop élégant, vous permet de mettre en œuvre une logique presque infiniment complexe de processus métier, et cette approche profane leur fonctionnalité. Eh bien, oui, ils auront absolument raison. Aux murmures, je vous rappellerai plusieurs messages bien connus du domaine du génie logiciel:

• Où mettre la logique métier - dans les procédures stockées de la base de données ou dans le code des applications métier?
• Quel est le meilleur - un ordinateur central ou un ordinateur spécial?
• Êtes-vous sûr que la référence que vous choisissez maintiendra la compatibilité avec les futures mises à jour de la vie? Et en général, survivra-t-il les 2 prochaines années?

La réponse est assez simple si:

• Vous avez beaucoup d'argent, de temps et de spécialistes de la blockchain gratuits
• Vous êtes sûr que la base de la blockchain que vous avez choisie n'aura pas à être modifiée par rapport au mot "jamais"
• Vous devez vraiment «réduire» les capacités de la plate-forme de 101%

Eh bien, alors - une calculatrice spéciale ... dans le sens de Hyperledger Fabric ou Corda avec des coutures sur le cheyncode et d'autres "ciselures dans la pierre". Sinon, pensez par vous-même ...

Surveillance du réseau hôte

Ce sera peut-être pour certains une révélation, mais une surveillance bien organisée est la base du bon fonctionnement des systèmes logiciels dans une entreprise. Et ce concept inclut non seulement (et même pas tant) la surveillance de l'infrastructure standard des serveurs, mais aussi la surveillance fonctionnelle des composants logiciels. Votre plate-forme distribuée doit non seulement fonctionner correctement, mais également faire correctement des erreurs, en fournissant au service d'assistance une quantité suffisante d'informations saines qui vous permettront d'identifier, d'identifier et de réparer rapidement une panne. C'est encore mieux si le système de surveillance a des capacités proactives - il vous permet d'identifier les «mauvaises choses» potentielles et bloque leurs conséquences possibles avant « qu'elles ne se produisent».



Si à chaque instant vous ne comprenez pas dans quel état se trouvent les nœuds de votre réseau et ce qui se passe sur eux, mais que vous allez travailler "selon les signaux des utilisateurs" - il vaut mieux libérer immédiatement de l'espace dans la file d'attente et ne pas prendre le temps de chers clients.



Sur la base de ce qui précède, dès le début du développement de notre plateforme, un système de surveillance proactif y a été intégré. Décrivons le principe de son fonctionnement:

• Dans la base de la blockchain de la plate-forme, un contrat intelligent spécial est établi qui est responsable de la collecte et de la distribution des données de surveillance (par souci de concision, nous appellerons ce contrat intelligent SCM)
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > piste d'audit des applications métiers

À une certaine valeur ou combinaison de valeurs pour le suivi des indicateurs, Mirror met automatiquement en pause le traitement de ses files d'attente d'opérations, bloque l'apparition de conséquences indésirables potentielles, par exemple:

• En cas de retard critique dans l'étiquette de contrôle du canal blockchain, qui est interprété comme un noeud abandonnant le réseau blockchain ou une perturbation complète de son fonctionnement
• En cas de retard critique dans l'étiquette de contrôle du canal DFS, qui est interprété comme la perte d'un nœud du réseau DFS ou une perturbation complète de son fonctionnement
• En cas d'erreurs dans la file d'attente des opérations, toutes les opérations ultérieures associées à cet objet métier (processus métier universel) sont bloquées

Une attention particulière a été portée au traitement des erreurs de base de données utilisées par le "Mirror". Cette base de données est utilisée non seulement comme interface avec les applications métier, mais également comme pile d'état pour la machine d'état des files d'attente d'opérations "Miroir". L'expérience a montré qu'en présence d'erreurs spécifiques lors de la modification des données dans les tables de la base de données, des opérations de bouclage peuvent se produire avec un ré-envoi massif de transactions et d'autres plaisirs. Une fois, en raison d'une erreur similaire, en deux jours, nous avons «réalisé» un volume semestriel de la chaîne sur Quorum. Par conséquent, si une erreur de ce type est détectée, le "Miroir" est complètement désactivé et attend une réponse manuelle du service d'assistance.



Les nœuds de surveillance centraux récupèrent les informations de tous les nœuds du réseau (y compris eux-mêmes, d'ailleurs) du SCM et les analysent, ce qui permet de détecter en temps opportun des conditions dangereuses ou potentiellement dangereuses comme, par exemple:

• - DFS-
• - DFS-
• -
• «»
• «»

L'image ci-dessous montre un exemple du moniteur le plus simple pour l'un de nos réseaux de test:







des schémas de surveillance proactive plus "de haut niveau" ont été développés et mis en œuvre, y compris des applications commerciales, mais nous arrivons ici à la frontière fragile de la propriété intellectuelle de clients spécifiques.



Ne cachons pas le fait que dans certains de nos réseaux blockchain, la surveillance du trafic constitue l'écrasante majorité du trafic total. À cet égard, il a même été envisagé d'utiliser un horaire flottant pour la fréquence des «sondages de colis» - plus souvent pendant les heures de travail, moins souvent en dehors des heures de travail. Mais ça vaut le coup. Vraiment.



En général, surveillez tout ce que vous pouvez imaginer tant que la bande passante de votre réseau décentralisé le permet. Vous ferez l'éloge des dieux de la programmation plus d'une ou deux fois, eh bien, et les auteurs de cet article, bien sûr :)



Car comme le dit l'une des interprétations de la loi de Murphy: "L'erreur réside généralement dans une position dont personne ne doute."

Évolution de l'utilisation de divers composants techniques

Après avoir examiné les conditions générales de déploiement et d'exploitation des réseaux décentralisés d'entreprise, ainsi que les principes architecturaux que nous avons utilisés pour construire la plate-forme R-Chain, nous passons maintenant à l'histoire de comment et pourquoi ses composants techniques individuels ont évolué dans le processus de mise en œuvre de projets spécifiques.



Le premier était le projet d'émettre une garantie internationale , dans lequel nos partenaires étaient des collègues de Biélorussie - mars-décembre 2018.



Nous avons commencé avec la configuration Ethereum - Ethereum Swarm - Crypto-Pro (DLT-DFS-cryptographie), qui a fait ses preuves dans des projets de recherche. Au lieu du réseau PoA de test public Ethereum Rinkeby utilisé, le réseau privé Ethereum PoA et le réseau privé Ethereum Swarm ont été soulevés. Au départ, aucun problème technique n'est apparu, mais nous avons rencontré un problème «cryptographique» - l'un des participants biélorusses a catégoriquement refusé d'utiliser les outils de cryptographie que nous proposons, se référant à la loi locale sur la gestion électronique des documents. À l'époque, il n'était pas possible de trouver une solution de haute qualité «pour le moment», mais on comprenait constamment le rôle difficile et important de la cryptographie dans le succès des projets internationaux.



Déjà dans le processus d'exécution des transactions de contrôle sur l'infrastructure réelle du réseau (chaque participant a déployé un nœud sur ses ressources), des échecs dans le travail d'Ethereum Swarm ont été identifiés - les pertes de fichiers étaient au niveau de 20%. Il a été suggéré que la perte est due à des problèmes dans le client Swarm lors de l'envoi de plusieurs fichiers en parallèle. En général, cette hypothèse a été confirmée: expérimentalement, nous avons réussi à trouver une pause entre l'envoi de fichiers individuels à Swarm en 5 secondes. Lors de la transition vers une configuration de réseau complètement combattante, qui, en raison des particularités de la segmentation du réseau appliquée dans l'infrastructure de Raiffeisenbank, nécessitait la création d'un nœud Swarm de transit, un problème critique est apparu - Ethereum Swarm a permis jusqu'à 30% des fichiers à perdre lors du travail via un nœud de transit.L'architecture «en couches» et un bon système de surveillance ont permis de mener à bien l'émission proprement dite de la garantie en mode «pompage manuel d'essence», mais le sort d'Ethereum Swarm était scellé. Il faut dire que la capacité déclarée d'Ethereum Swarm à fonctionner dans des topologies sans connexion directe émetteur-récepteur a été l'une des principales raisons pour lesquelles elle a été choisie comme base technologique pour DFS, et son incapacité à travailler de manière fiable dans ce mode a créé beaucoup de problèmes.et son incapacité à travailler de manière fiable dans ce mode a créé de nombreux problèmes.et son incapacité à travailler de manière fiable dans ce mode a créé de nombreux problèmes.



Il convient de noter que le réseau privé basé sur Ethereum dans ce projet satisfait de sa récupérabilité. Le calendrier du projet supposait que la clôture de la garantie émise se ferait 3 mois après son émission, et pendant cette pause, certains des participants ont arrêté leurs nœuds. Néanmoins, lors du redémarrage du réseau sans aucune danse avec des tambourins en 1 jour, il a restauré son intégrité, et l'opération de fermeture de la garantie s'est déroulée sans aucune plainte.



Le projet suivant était la création d'un réseau intra-groupe pour le groupe d'entreprises Ascona - septembre 2018 - heure actuelle.



Sur la base de l'expérience du projet de garantie internationale, IPFS (InterPlanetary File System) a été choisi comme base technologique de DFS. Cela fonctionnait bien pour envoyer des fichiers en parallèle et ne nécessitait pas d'ajustements de mode spéciaux. Peut-être que le seul point faible d'IPFS est l'impossibilité (spécifiée!) De travailler dans des topologies de «transit». Lors de la construction de réseaux avec un grand nombre de participants, la mise en place par chacun d'eux d'une «étoile pleine» d'accès de chacun à chacun est, pour le moins, un problème d'organisation. En revanche, tous les participants implémentent un accès entre eux et les nœuds «support» de l'opérateur. Par conséquent, pour organiser la distribution fluide des fichiers, le mécanisme suivant a été implémenté:

• Lorsqu'un fichier est joint à un contrat intelligent d'un certain processus métier, l'événement DeliveryFile est généré contenant un lien vers le fichier
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

Ainsi, le projet Ascona a démarré dans la configuration Ethereum - IPFS - Crypto-Pro.



L'utilisation de Crypto-Pro pour crypter des fichiers et des signatures «externes» de documents légalement significatifs a assuré la simplicité de la liaison juridique, ainsi que l'absence de réclamations des services de sécurité de l'information, ce qui a eu un effet extrêmement positif sur le moment d'obtention des approbations nécessaires de la banque et parties aux sociétés du groupe de sociétés Ascona. En général, le projet s'est développé en ordre de marche et, après avoir passé l'étape pilote, c'était à l'arrivée pour passer à la production et ici ...



... et ici dans deux projets à la fois - conditionnellement «extraterrestres», mais auxquels nous avons participé en tant qu'experts, sur des configurations similaires nous avons attrapé des méga-fourches de milliers de blocs, avec la perte de transactions d'une partie du réseau. Une analyse des journaux et des interprétations de la communauté blockchain a conduit à une conclusion décevante - l'utilisation d'Ethereum PoA (et dans certains cas même PoW) dans des réseaux compacts avec un petit nombre de nœuds (et les réseaux d'entreprise appartiennent exactement ici) présente un risque élevé de tels monstres. De plus, un bug mystérieux a commencé à apparaître périodiquement dans notre réseau de test, lorsqu'un nœud s'est déconnecté du réseau et ne voulait plus se synchroniser avec lui. Même après avoir réinstallé Ethereum et complètement décapé. En bref, il est devenu clair que le réseau prod avait besoin d'une alternative à la base de la blockchain. Et vite. Très vite.



La solution s'est avérée être Quorum - pratiquement, le frère d'Ethereum. Le nombre d'améliorations dans le "Mirror" était minime, l'application métier, bien entendu, ne nécessitait aucune amélioration.



Pour le moment, la transition vers Quorum n'a apporté que des avantages:

• Le consensus de radeau utilisé élimine les fourches
• L'absence de blocs vides réduit la taille de la chaîne

L'absence de fourchettes nous permet de se passer de pause en attendant la finalisation conditionnelle des transactions, qui était auparavant nécessaire pour ne pas gérer un éventuel rollback de transactions, et nous avons eu jusqu'à 6 cycles de génération de blocs. Cela, d'une part, augmente naturellement les performances de la plate-forme, et d'autre part, cela supprime les problèmes très difficiles qui se posent si le fork a dépassé la pause calculée et que l'état des objets métier "en miroir" qu'il touche cesse d'être cohérent avec leur état de blockchain.



La seule fonctionnalité peut-être désagréable de Quorum est la possibilité de générer un méga-bloc de plusieurs mégaoctets lors du redémarrage après une longue pause, ce qui bloque simplement l'adaptateur DLT lors d'une tentative de déchargement de son contenu. Mais, à proprement parler, le service desk ne devrait pas dormir aussi longtemps.



À la suite de toute cette évolution dramatique, nous sommes arrivés à la configuration Quorum - IPFS - Crypto-PRO , que nous utilisons maintenant sur le marché intérieur russe.



Peut-être que quelqu'un posera une question logique: "Eh bien, vous n'avez jamais entendu parler de Quorum auparavant, ou quoi?"... Nous avons entendu parler de Quorum, Hyperledger Fabric et EOS. L'auteur de cet article a même assisté au premier atelier Corda en russe à l'automne 2017. Probablement, spécifiquement pour une réponse intelligente à de telles questions, Hegel a inventé sa dialectique. La petite équipe qui a commencé la recherche en 2016 avait une bonne expérience dans le développement d'applications interactives pour Windows, et Ethereum public (le premier test est compréhensible) avait le seuil d'entrée le plus bas des plates-formes blockchain. Et comme nous étions intéressés à mener des recherches spécifiquement sur le sujet de la blockchain, et non à bricoler différents dockers, sans lesquels il serait tout simplement irréaliste de lancer Quorum ou Hyperledger Fabric "adulte" (et pas sur toutes les plates-formes Windows virtuelles), alors le choix était évident. Alors que les résultats de la recherche ont commencé à attirer l'attention des business units de la banque et de ses partenaires,il est devenu possible d'agrandir l'équipe, de confier des bottes aux cordonniers, des tartes aux gâteaux, de mettre la main sur des serveurs Linux, etc. Et, naturellement, personne n'a jeté les solutions développées tant qu'elles ont conservé leur potentiel de développement. Dialectique et évolution.

Expérience dans la recherche et l'exploitation de plates-formes d'entreprise et leur développement ultérieur

L'auteur de cet article a participé à un assez grand nombre de projets blockchain menés à la Raiffeisenbank, à la FinTech Association et dans d'autres lieux - à la fois en tant que développeur et en tant qu'expert des plateformes décentralisées. Certains d'entre eux étaient purement des projets de recherche, certains ont abouti à des projets pilotes, d'autres sont devenus des réseaux industriels assez vastes de plusieurs dizaines de nœuds.



Quelles sont les principales conclusions que l'on peut tirer de toute cette expérience?



1. Il existe une certaine variété de plates-formes blockchain, qui sont très différentes dans leurs qualités "consommateurs":

• "Seuil d'entrée" et facilité de déploiement du réseau
• bande passante
• fonctionnalité des contrats intelligents
• options de fermeture des informations
• temps de développement et coût

Par conséquent, je pense qu'il est impossible de dire que l'une des plates-formes se révélera absolument dominante. Chacun a son propre cercle d'utilisateurs potentiels et de tâches, où son utilisation est la plus rationnelle et la plus rentable. Cela s'applique à Ethereum, Quorum, Hyperledger Fabric et Corda. Ici, comme pour les langages de programmation - seuls Vasya et Petya, qui connaissent chacun une langue, discuteront au point de savoir lequel est le meilleur - "plus" ou "crapaud". Et Semyon Petrovich et Albert Ivanovich, qui en connaissent une douzaine, parleront pacifiquement - quand les "plus" sont meilleurs, et quand - "crapaud".



2. Malgré le fait que certaines des plates-formes DLT (par exemple, Hyperledger Fabric et Corda) offrent la possibilité de transférer des éléments de données volumineux - en fait, les fichiers, très probablement, la base de la blockchain avec des mécanismes de contrat intelligents et la fonctionnalité de transfert de fichiers resteront séparées. Cela est dû aux points suivants:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3. Actuellement, il y a une pénurie chronique de spécialistes pour les services d'appui technique des plates-formes décentralisées. Plus précisément, ils n'existent tout simplement pas. Absolument. Dans la plupart des projets que je connais, la part du lion du travail de support technique est effectuée par les développeurs ou les ingénieurs de recherche qui ont créé ces plates-formes, ce qui, bien sûr, n'est pas bon. Je pense que cela est dû à la jeunesse de la direction et progressivement le développement d'instructions techniques, de modèles de réponse, de schémas de suivi et d'autres matériels méthodologiques nécessaires à l'organisation du travail efficace du service de soutien est en cours. L'un des problèmes ici est le manque de bons cours de synthèse en russe sur des plates-formes blockchain spécifiques. Tout doit être passé de main en main. Mais un spécialiste du support en entreprise n'est pas un développeur, et il se concentre sur d'autres problématiques: le monitoring,diagnostic des erreurs, assurant la disponibilité et la récupération des systèmes après des accidents (pensez-vous que vous n'aurez aucun accident? Oui, bien sûr). Et, franchement, la probabilité qu'un projet d'entreprise meure en raison d'un soutien insuffisant est nettement plus élevée qu'en raison de la mauvaise qualité du développement. Par conséquent, attirer des spécialistes de haute qualité ayant une expérience dans le support et l'exploitation de systèmes d'entreprise est un facteur important, sinon le plus important, dans le fait que le projet vivra et se développera pendant longtemps, et ne se fanera pas dès que quelques pères fondateurs le quitteront.Par conséquent, attirer des spécialistes de bonne qualité ayant une expérience dans le support et l'exploitation de systèmes d'entreprise est un facteur important, sinon le plus important, dans le fait que le projet vivra et se développera pendant longtemps et ne se fanera pas dès que deux pères fondateurs le quitteront.Par conséquent, attirer des spécialistes de haute qualité ayant une expérience dans le support et l'exploitation de systèmes d'entreprise est un facteur important, sinon le plus important, dans le fait que le projet vivra et se développera pendant longtemps, et ne se fanera pas dès que deux pères fondateurs le quitteront.



4. L'un des domaines juridiques les plus obscurs est la formalisation des relations entre l'opérateur et les participants au réseau, qui est aggravée par le fait que l'opérateur, d'une part, n'est pas propriétaire du réseau et de ses ressources, et d'autre part, est obligé d'en assurer le fonctionnement, même si le cette mesure est en conflit avec les intérêts des participants individuels. L'équilibre entre les droits et obligations de l'opérateur, ses «moyens d'influence» sur les participants au réseau, la responsabilité financière de l'opérateur - tout cela fait désormais l'objet de litiges très difficiles. La question la plus simple:Comment assurer le remplacement synchrone des logiciels critiques par tous les participants du réseau, malgré sa simplicité apparente, entraîne des discussions très animées? L'émergence d'exemples de formalisation juridique de la position de l'opérateur et des participants au réseau sur la base de l'expérience des plateformes déjà entrées en prod va considérablement accélérer l'introduction des réseaux décentralisés en tant qu'élément significatif des relations corporate et interentreprises.



Si vous avez atteint la fin, il y a aussi un bonus: certaines des questions sur l'état actuel et les voies de développement des plateformes d'entreprise décentralisées se reflètent dans le matériel préparé par l'auteur de cet article pour l'une des ressources de la blockchain (le matériel est conçu pour un large éventail de lecteurs ).