Digi Műhely | Robosztus alkalmazás-ökoszisztémák blokklánc alapú digitális jegybankpénz rendszerekben
Robosztus digitális jegybankpénz alkalmazások tanulmány
A tanulmány angol nyelven íródott, magyar nyelvű változata nem elérhető, eredeti címe: Robust CBDC applications
Készítette: László Gönczy, Pál Varga, Imre Kocsis
The term robustness means the tolerance against perturbations that may affect the systems’s functions. The robustness of a system can be challenged by faults in the surrounding environment or threats of unintentional misuse or deliberate attacks.
We introduce the general concept of (technical) robustness and dependability, focusing on the execution of smart contracts over blockchain. While smart contract code is considered as the business logic of applications, ledger content, supporting blockchain mechanisms such as consensus and ordering, and even client workload influences the observable robustness of a blockchain application.
We first present the general concept of dependability, then introduce its special applications and considerations in an enterprise blockchain. Information sources and tools supporting vulnerability assessment and a method for systematic evaluation by fault injection is also presented. When it comes to actual execution of smart contract, we approach the demonstration from industrial usage point of view, where workflows are executed both at the enterprise level and at the production level. Although such workflows can be described through various ways from Business Process Modelling Notation (BPMN) to Coloured Petri Nets (CPN), these can also be mapped to smart contracts. Being able to describing the workflows themselves error-free is an initial step towards having robust smart contracts based on those workflow descriptions. Describing the necessary precautions on smart-contract-based workflow execution is also part of the aims here.
To summarize, we conclude with an overview of the potential impact of enabling the regulatory control by distributed ledger technologies, with an emphasis on fault tolerance.
Fault removal and mitigation: Continuous audit In the case of traditional audit processes, faults can be detected only long time after their occurrence, therefore minimizing their impact can be done only by cumbersome compensation actions. Although such actions can also be expressed as special workflows (as supported by e.g., the BPEL and BPMN standards), these are rarely used since the difficulty of designing a correct and effective compensation flow. Therefore, the promise of executing a ”continous audit process” can be a strong argument for the application of distributed ledgers.
Fault prevention: Checking / enabling Transactions before they get active or live. Fault prevention can be implemented by including the regulatory body or further participants of the financial infrastructure in the execution of transactions. As there is a possibility to share transactions without revealing the origin/target of the transaction (e.g., based on digital identities and external oracles), suspicious transactions and transaction patterns can be analyzed quasi realtime, which can drastically decease the chance of executing a fraudulent transaction.
Fault prevention: Whitelisting and Blacklisting functionalities can be directly integrated to the business logic. As execution of smart contract steps can be bound to specific roles, the supervisor can act as a distinguished actor to ”enable or disable” certain transactions. Smart contract: how to include?
Whether and how different participants of the financial infrastructure should be part of the business logic or used as information source, and exactly what kind of data should be stored on the ledger and managed by smart contracts (including the possibility to offer query to third parties) is an important further research question.
Value-added services on top of CBDC smart contracts. If the smart contract handle different aspects of transactions (and also different ”colors” of tokens), a number of value added services can be created as a layer on top of the ”flow of money”. In the case of industrial IoT, for example, applying certain methods in manufacturing (like a low-emission machinery step) can result ”bonuses” (e.g., reduction of environmental tax). The conditions for such services can be regularly updated and the effect of this ”upper layer” of smart contracts can be evaluated and compared with the original goal of the policy maker.
Platform: whether and how to include the regulator and/or central bank The level and method of including the regulatory in the blockchain network is an important design decision. A possible design pattern can be to share only aggregated information, when even without the detailed view, the regulatory can follow and monitor the transaction flow. On the other hand, performance itself should not be an obstacle; depending on the resolution of information and the definition of ”transaction” in the smart contracts (chaincode), current technologies promise a potential throughput which even supports the central bank in participating in a number of blockchain networks.
Kulcsszavak: robustness; DLT platforms; smart contracts; workflow; fault model