In the first productive decentralized applications of blockchain technology, special challenges arise for user, role and rights management. Solutions to these are costly and complex, but entirely possible.
Challenges in the use of blockchain technology
Now that companies have put the first decentralized applications into production as distributed ledger technology (DLT) or blockchain applications and have been able to gain experience with this type of application in productive operation, problems are emerging for which there are long established solutions in the context of centralized applications, as examples show.
Many of these problems are well known, but generic solutions are complex and technically costly to implement in the decentralized context, so that case-specific solutions or “best practices” can be useful alternatives.
Secure and fast and decentralized? The blockchain trilemma
The challenges are often inherent characteristics of decentralized applications as a new type of application: for example, scalability and security are always at odds with each other, i.e., any improvement in scalability results in a decrease in security. A prominent example is the purchase of a good with a decentralized cryptocurrency. Using maximum security, the purchase transaction must be confirmed by all network nodes (“the whole world needs to know Bob just bought a beer”) for decentralized consensus to work in public blockchains.
Of course, a secure and scalable variant of the purchase transaction would be possible: if the transaction were entered into a centrally managed database. Obviously, this would only be achieved at the cost of less decentralization. This regularity is known as the blockchain trilemma, and there are similar phenomena in other research areas, the CAP theorem in databases, the trilemma of the exchange rate regime in economies, etc.
Blockchain trilemma: security, decentralization, and scalability
Diverse implementation options in the blockchain space. By now, the range of implementation options in the blockchain space is sufficiently wide. In the early days of blockchain implementations, a solution based on the Bitcoin blockchain, which for a long time represented the only reality-tested blockchain implementation, could only be maximally secure, but very inperformant. Today, there are numerous gradations; for example, a private-permissioned Blockchain in an operator consortium of cooperative companies can deliver very high security with acceptable performance and decentralization.
The technologies used have evolved since the Bitcoin Blockchain, e.g., Ethereum Turing-complete implementations are available or Corda industry-specific implementations optimized for specific use cases. In general, the application-specific selection and customization of blockchain or distributed ledger technology implementations is the decisive factor for the success of decentralized applications.
In addition to general non-functional trade-offs such as security vs. performance, there are still enterprise-specific requirements, e.g., on user, role and rights management and user authenticity, that must be considered for applications.
User, role and rights management in blockchain.
A very concrete problem when using decentralized technologies in a consortium of companies is, for example, the loss of a security token, e.g., a private key, and the related question of how this can be countered in a decentralized context. How can stakeholders trust a single participant in the consortium not to grant false credentials, and who exactly do stakeholders trust here?
Password loss in centralized structures
Anna has accidentally shared her password for her company’s intranet. The authenticity of her company-specific actions is thus compromised. She must report this incident and submit a change request, which is logged according to internal security policies and processes, and her identities and authorizations are checked in the identity and access management system. An administrator with appropriate permissions (and assignments according to MA risk, etc.) will assign a new password via the identity and access management system using the 4-eyes principle, and Anna will have to assign her own new password when she logs in for the first time. The very high complexity of the correct administration of the identities and their properties, as well as the role and rights assignments, is thus countered with specialized tools and specified processes.
Identity, roles and rights management in companies
Establishing identity, roles and rights management in companies
These processes typically vary only marginally across companies, and oversight and responsibility for these processes lie with the company in question. The company in turn may be subject to external constraints due to process certifications, regulatory requirements, etc., but is in principle responsible for potential misconduct and risks incurred.
In contrast to decentralized applications, there is always an intermediary between the individual user and a central logic. The middleman, in the corporate context e.g. a department with administrators, can always assign, change or withdraw the rights and identities of the individual user.
Password loss in decentralized structures
In a decentralized context, trust is transferred entirely to the individual employee, since conceptually there is no middleman. Ethereum smart contracts, for example, always verify the sender’s signature, which is derived from the company employee’s private key. An intermediary would either have complete control by possessing the private key or no control at all.
This problem is known in the field of crypto exchanges, for example, as “wallet/key custody”: who takes custody of the private keys and thus complete control over the signatures?
Numerous exchanges for decentralized cryptocurrencies use a custodial wallet and thus have complete control over their customers’ transactions – this is a blatant contradiction to self-managed private keys on the part of the end user, which was the original goal of blockchains. Users of a decentralized application should have exclusive control over their assets without having to trust third parties, such as banks.
Authenticity problems in the decentralized scenario
Thus, transferring this authenticity problem to a decentralized scenario is much more complicated than in a single firm: e.g., firms A, B, C, and D are cooperative with each other, i.e., they are competitors, but they want to cooperate permanently for a certain type of transaction, for a certain period of time, or even in general in a certain area. However, the “cooperative” A, B, C, D can change permanently, e.g. E and F can be added while A and B are dropped at the same time. Accordingly, the trust of the participants also changes, so the joint solution will probably start with a “familiar” group of participants at the beginning, but due to the given openness of the solution, new participants can also join or existing participants can leave. The technical and organizational measures and processes for smooth operation must then compensate for the lack of trust in these new participants.
Problematic in such a setup is the different distributed trust, which has to be identified and evaluated. In the second part of the article, corresponding solution approaches are presented.