Applications décentralisées : questions clés d'un directeur de l'innovation bancaire

Alex Batlin est responsable principal de l'innovation au FinTech Innovation Lab d'UBS et responsable de la recherche Crypto 2.0 Pathfinder de la société financière suisse sur la Technologies blockchain.

Dans cet article Analyses , Batlin donne un point de vue personnel sur la façon dont les applications décentralisées courent un plus grand risque de centralisation que les protocoles câblés comme Bitcoin.

Au cours des derniers mois, j'ai été aux prises avec un sentiment instinctif selon lequel le modèle d'application distribuée (dapp) basé sur des contrats intelligents d'Ethereum a une dynamique différente de celle des protocoles câblés comme Bitcoin ou Ripple.

Cette semaine, ce sentiment s’est cristallisé en une pensée semi-cohérente.

Les protocoles câblés n'établissent pas de distinction entre le protocole et la logique métier. Les mêmes concepteurs de protocoles, développeurs de logiciels et mineurs contrôlent la manière dont l'organisation autonome distribuée émergente (DAO) fonctions.

C'est différent pourapplications décentralisées– il existe une séparation claire des préoccupations entre le protocole et la logique métier encapsulée dans le contrat intelligent.

La dynamique d'évolution d'un protocole basé sur une dApp peut être similaire à celle de Bitcoin, mais très différente pour les dApp elles-mêmes. Elles peuvent avoir un propriétaire clairement identifié, comme la personne ou l'organisation qui a rédigé le contrat intelligent, celui qui l'a téléchargé ou celui qui facture son utilisation.

Risque de centralisation

Cela présente un risque inattendu, du moins à mon avis, de centralisation.

Bien sûr, le protocole peut être distribué et donc le fonctionnement du dapp est également distribué, mais si de nombreuses autres dapps utilisent un contrat intelligent partagé contrôlé unilatéralement, alors au moins au niveau logique, vous revenez à un modèle centralisé, que dans certains cas vous souhaiterez peut-être éviter.

Ce n’est pas forcément un problème si c’est bien géré.

Les contrats intelligents hautement partagés pourraient être reconnus comme des composants d'infrastructure clés et être officiellement détenus et gérés par une forme de fondation pour logiciels ouverts (OSF), que ce soitFondation Ethereumou un autre organisme. L'essentiel est qu'il n'y ait aucune confusion quant à la propriété du contrat intelligent et à ses obligations.

Vous pouvez également écrire des contrats intelligents « en miroir » pour atténuer le risque de centralisation. Par exemple, si deux parties doivent suivre des obligations bilatérales, chacune déploiera sa propre instance du contrat intelligent, et chaque instance suivra les vues nostro et vostro des obligations.

Techniquement, cela est moins efficace car vous effectuez un double suivi des données, mais cela offre un modèle de propriété plus simple.

Cela dit, rien n'empêche les contacts intelligents d'être privés, même s'ils sont largement partagés, à condition qu'ils offrent une valeur unique et que les utilisateurs comprennent parfaitement les risques associés. En supposant que le propriétaire du contrat fixe les frais dans le code, le risque de hausse des prix est atténué dans le monde on-chain par rapport aux activités d'intermédiation traditionnelles.

Bienvenue dans le « Dapp Store »

Dès que vous commencez à facturer des frais pour l'utilisation de vos dApps, vous devez définir clairement ce que vous facturez. Facturez-vous la licence pour déployer votre propre instance d'un contrat intelligent et utiliser le portefeuille d'applications décentralisées (un BIT comme pour acheter une application sur l'App Store) ? Ou facturez-vous un service fourni par un contrat intelligent déjà déployé ?

On peut dire que, puisque ce sont en réalité les mineurs qui fournissent le service d’exécution et de validation des transactions, il est difficile de justifier la facturation de frais de service pour les contrats intelligents, à moins qu’il n’existe de nombreux services hors chaîne à valeur ajoutée regroupés avec la dapp.

Sur la base de cette évaluation, nous pourrions nous retrouver avec un modèle de « Dapp Store », dans lequel les utilisateurs achètent une licence pour déployer une instance d'une dapp bien écrite, conforme aux normes, testée et éprouvée sur une blockchain.

Cela implique cependant que le créateur de l'application décentralisée ne fournit pas de garanties opérationnelles, alors qui le fait ?

Il existe des parallèles aujourd'hui, par exemple, les développeurs iOS comptent sur Apple pour fournir l'appareil, le système d'exploitation et l'App Store, et tous deux comptent sur les fournisseurs de services Internet haut débit et mobiles (FAI) pour fournir la connectivité. Cependant, aucun d'entre eux ne garantit un service complet de bout en bout à l'utilisateur de l'application.

Nouvelle entité requise

La conclusion est donc qu'un nouveau type d'entité est nécessaire : un fournisseur de services blockchain (BSP). Il ne s'agit pas d'un mineur ou d'un validateur Bitcoin ou Ethereum , mais ONEun fournisseur offrant des garanties et gérant des nœuds complets utilisables par des portefeuilles légers pour utilisateurs finaux.

Le BSP fonctionnera probablement sur une plateforme de calcul cloud Blockchain-as-a-Service (BaaS), telle que la plateforme Azure de Microsoft.déjà en chargeplusieurs blockchains.

Une telle structure doit définir clairement la responsabilité juridique de l'ensemble de la chaîne d'approvisionnement. L'utilisateur final doit accepter formellement les conditions générales du portefeuille d'application décentralisée, du contrat intelligent d'application décentralisée et du BSP.

Plusieurs BSP interconnectés devront fournir un niveau de confiance adéquat, qui sera supérieur à ONE fourni par un service centralisé, car aucun participant n’est en mesure de modifier unilatéralement une partie du système.

En d'autres termes, une entreprise blockchain est une entreprise de confiance. Vous devrez ensuite déterminer si cette confiance renforcée est nécessaire ou non pour votre cas d'utilisation spécifique.

Cet article a été initialement publié sur le site d'Alex Batlin.Page LinkedIn Pulseet a été republié ici avec permission.

Image du hubvia Shutterstock