Blockchain / Distributed Ledger System and Method for Manag ing Data of a Smart Contract

The invention relates to a blockchain / distributed ledger system and a method for managing data of a smart contract in a blockchain / distributed ledger system.

The technology of blockchain or "distributed ledger" is cur rently an intensively discussed technology, which can be re alized, in particular, as a distributed database system.

The blockchain is a growing list of records, called blocks or data blocks, which are linked using cryptography. Each data block contains, for instance, a cryptographic hash of the previous data block in the blockchain, a timestamp, and transaction data. By the design of the blockchain, a block- chain is resistant to modification of the transaction data. The blockchain is an open, distributed ledger that can record transactions between, for instance, two parties efficiently and in a verifiable and permanent way. Transactions data once recorded in any given data block cannot be deleted or altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Because of this, subsequent transactions are built on previous transac tions and confirm these as correct by proving knowledge of the previous transactions. This makes it impossible to manip ulate or erase the existence or content of previous transac tions without destroying all subsequent transactions at the same time. Although blockchain records are not unalterable, but blockchains are considered secure by design.

In addition to applications of blockchains for decentralized payment systems (e.g. Bitcoin) , new applications are being developed in the financial industry. In particular, transac tions between companies can be realized without an intermedi ary or clearing house, protected against manipulation. This enables new business models without a trustworthy arbiter, reduces transaction costs, and new digital services can be offered flexibly without having to set up a special infra structure and trusted relationships. A transaction record or transaction protected by a blockchain includes program code, for instance, which can also be referred to as a "smart con tract" .

Every smart contract in a blockchain system, for example based on Ethereum blockchain, maintains certain data regard ing e.g. users/partners who are involved in business process es managed by the smart contract, permissions and/or roles of different parties involved into the business and state infor mation of various workflows managed by the smart contract.

A smart contract mainly for industrial use may need to be up dated because the business logics and rules defined in the smart contract need to be improved or extended, and/or spe cific cases to the workflows have to be added.

When deploying a new version of said smart contract, there is a problem that all the data managed by the existing version of the smart contract will be lost due to the nature of blockchain technologies. In other words, after the updated smart contract is deployed, it will have no information re garding the state of business managed by the previous version of the smart contract.

In order to solve this problem, the following two solutions have been suggested:

A smart contract is deployed and executed in its original version which will never be upgraded or re-deployed. The in volved Parties use always the original version of the smart contract. This solution works normally only for limited num ber of use-cases. Alternatively, in addition to a new version of the smart con tract, a set of scripts has to be developed for storing all the data, such as the state information of existing smart contract, in memory or in an intermediate or a transitional contract. Afterwards, these data will be restored into the upgraded smart contract.

The second solution is more flexible, covers most of the cas es and suits the industrial requirements where iterations of improvements of smart contracts based on collected feedback from customers have to be done.

However, the set of scripts for the data migration in the second solution may be considerably complex, in particular, when the complexity of the corresponding smart contract is relatively high. This leads to an input of significant re sources and time during the development and release manage ment of each new version of the smart contract and during the operation of the blockchain system for covering additional complexity on the system. Correspondingly, project costs are relatively high.

Accordingly, it is an object of the present invention to overcome the drawbacks of the above-mentioned two solutions in order to provide an improved way for the data management in a blockchain / distributed ledger system, in particular during the update of smart contracts.

This object is inventively achieved by the independent claims 1, 6, 11 and 12. Advantageous further developments may be taken from the subclaims.

The invention provides, according to a first aspect, a block- chain / distributed ledger system comprising a plurality of interlinked blocks, at least a first smart contract unit con figured to store a first smart contract and a second smart contract unit configured to store a second smart contract.

The first and second smart contract units are stored in the blocks. The first smart contract unit is further configured to execute the first smart contract to read/store first data from/to the second smart contract unit. The second smart con tract unit is further configured to, upon the execution of the first smart contract, execute the second smart contract to read/store the first data from/to the blocks.

It is particularly advantageous that the inventive blockchain / distributed ledger system strips the data management func tion from the first smart contract working as the main smart contract holding business logics and rules.

A second smart contract which may be quite small and simple provides e.g. data retrieval/storage or read/write function to the first/main smart contract. The second smart contract holds neither any business logic nor any rule, but functions only as "outsourcer" of the first smart contract regarding data management tasks.

Accordingly, the first/main smart contract does not maintain any state information by itself, but, when being executed, calls the "store" or "read" function of the second smart con tract for setting or getting required data object.

Thereby, the re-deployment and the upgrade of smart contracts which contain business logics and rules are considerably sim plified and can be performed in an agile way.

Inventively, time-consuming redesigns and redevelopments of complicated set of scripts for data migration between two versions of smart contracts are avoided. Since the function ality of the second smart contract of the present invention is limited to store data to the blocks or to read data from them, the second smart contract does not need to be changed or upgraded. In addition, the development/implementation of the second smart contract requires much less time and fewer resources due to the simplicity of the functions of the sec ond smart contract. As a result of removing the need of placing plenty of efforts on data migration during smart contract upgrades, the mainte nance costs of a blockchain / distributed ledger system and/or blockchain-based applications are significantly re duced .

Furthermore, the initial development/implementation of smart contracts which hold business logics and rules is less com plex than the state of the art because inventively there is no more need to initially implement complex scripts in the system for data migration in the future.

In a preferable embodiment, the system comprises further a third smart contract unit which is stored in the blocks and configured to store a third smart contract and execute the third smart contract to read/store second data from/to the second smart contract unit, and wherein the second smart con tract unit is further configured to, upon the execution of the third smart contract, execute the second smart contract to read/store the second data from/to the blocks.

Particularly, the third smart contract is an updated version of the first smart contract. Once this updated version is de ployed and implemented in the system or a blockchain-based application, it can easily retrieve data which were managed by the previous version of the smart contract, i.e. by the first smart contract, from blocks via the second smart con tract providing data retrieval function to the updated/third smart contract.

Alternatively, the third smart contract may be another smart contract holding business logics and rules which are totally independent from the first smart contract. In this case, the second smart contract provides data read/storage functions to both of the first and third smart contracts. It is thus advantageous that a plurality of smart contracts holding business logics and rules may "outsource" the data management tasks to the same additional smart contract, i.e. the inventive second smart contract which has a simple func tionality and may contain only a generic piece of code allow ing setting or getting arbitrary piece of data from the blocks .

In this regard, all of the complex scripts for data migration during upgrades of these smart contracts are avoided and re placed by the small second smart contract. Thereby, the maintenance costs of a blockchain / distributed ledger system and/or a blockchain-based application are further reduced.

In a further preferable embodiment, the first smart contract unit is further configured not to execute the first smart contract any more upon the execution of the third smart con tract .

In this embodiment, the first smart contract is updated as the third smart contract with e.g. certain business rules im proved. Since the previous version of the smart contract, i.e. the first smart contract should not be implement

ed/executed anymore, codes are contained in the first smart contract to detect the implementation of the third smart con tract and then prevent the first smart contract from being executed by e.g. calling a "suicide" or "selfdestruct" func tion .

In a further preferable embodiment, the first data are iden tical with the second data.

The first smart contract stores the first data to the blocks via the second smart contract, while after the deployment of the updated/third smart contract, the second data which are actually the stored first data are retrieved by the third smart contract from the blocks via the second smart contract. Thereby, a simple data migration during contract upgrade is achieved .

In a further preferable embodiment, the first smart contract unit is further configured to execute the first smart con tract to generate/edit the first data, and wherein the third smart contract unit is further configured to execute the third smart contract to generate/edit the second data.

The edit of data does not mean amending or deleting data which are already stored in the blocks, but editing the data retrieved from the blocks and then store them as new data in to the blocks. The first and third smart contracts may gener ate or edit data when being implemented, i.e. when the con tained business logics and rules are executed. The generated or edited new data are then stored to a new block by calling the "store" function of the second smart contract. Since the second smart contract does not contain any business log ic/rule, it does not generate or edit any data, but "trans ports" exiting data between the blocks and the first/third smart contracts.

The invention further provides, according to a second aspect, a method for managing data of a smart contract in a block- chain / distributed ledger system comprising a plurality of interlinked blocks, comprising the steps of storing a first and a second smart contract in the blocks; executing the first smart contract to read/store first data from/to the second smart contract; and executing, upon the execution of the first smart contract, the second smart contract to read/store the first data from/to the blocks.

A preferable embodiment of the method comprises further the steps of storing a third smart contract in the blocks; exe cuting the third smart contract to read/store second data from/to the second smart contract; and executing, upon the execution of the third smart contract, the second smart con tract to read/store the second data from/to the blocks. A further preferable embodiment of the method comprises fur ther the step of stopping executing the first smart contract upon the execution of the third smart contract.

A further preferable embodiment of the method comprises fur ther the step of executing the first smart contract to gener ate/edit the first data, or executing the third smart con tract to generate/edit the second data.

The invention further provides, according to a third aspect, a computer program comprising instructions which, when the program is executed by a computer, cause the computer to car ry out the method according to the second aspect.

The invention further provides, according to a fourth aspect, a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to the second aspect.

Further advantageous details and features may be taken from the following description of several exemplary embodiments of the invention in conjunction with the drawings, in which:

Fig. 1 shows a schematic representation of a part of an embodiment of the inventive blockchain / distribut ed ledger system;

Fig. 2 shows a schematic representation of another embodi ment of the inventive blockchain / distributed ledger system;

Fig. 3 shows a block diagram of an embodiment of the in ventive method for managing data of a smart con tract in a blockchain / distributed ledger system;

Fig. 4 shows a block diagram of an embodiment of the in ventive computer program; and Fig. 5 shows a block diagram of an embodiment of the in ventive computer-readable medium.

A part of an embodiment of the inventive blockchain / dis tributed ledger system shown in Fig. 1 comprises a first smart contract unit 2a configured to store a first smart con tract 2 and a second smart contract unit 4a configured to store a second smart contract 4. The first and second smart contract units 2a, 4a are stored in the blocks of a block- chain in the inventive blockchain / distributed ledger system (not shown in Fig. 1) .

The first smart contract 2 works as a main smart contract holding business logics and rules 24, 26, 28, 30. In the shown embodiment, the business logic 24 is a function of add ing new partners to be involved in the first smart contract 2. The business logic 26 is a function of initiating workflow of the first smart contract 2. The business rule 28 is a function of paying fees to a certain party involved in the first smart contract 2. The business logic 30 is a function of monitoring processes when the first smart contract 2 is executed .

It is particularly advantageous that the first smart contract 2 has only content regarding business logics and rules, but no function for maintaining state information generated when executing the first smart contract 2.

Inventively, the task of data maintenance/management is out sourced to the second smart contract 4 which only comprises two functions 20, 22 regarding storing data to and reading data from the blocks.

If the first smart contract 2 is updated due to business re quirement, the new version thereof can easily retrieve data regarding state information generated by the previous version of the first smart contract 2 by calling the "read" function of the second smart contract 4 which then retrieves said data from the corresponding addresses in the blocks.

Thereby, a simple data migration during the upgrade of the first smart contract 2 is realized, without having to develop and implement complex set of scripts for each upgrade. In ad dition, since the second smart contract 4 relates only to the simple data read/write functions, it does not need to be up graded, which considerably saves the costs on the maintenance of a blockchain system or a blockchain-based application.

The embodiment of the inventive blockchain / distributed ledger system 100 shown in Fig. 2 comprises a blockchain 50, a plurality of mining nodes 32 and a blockchain network 11 for e.g. connecting the mining nodes 32 to the blockchain 50 as well as connecting parties (not shown in Fig. 2) in order to involve them in smart contracts stored in the blockchain 50.

The Mining nodes 32 are participators of the blockchain 50 who execute smart contracts stored there and try to store the result of the execution as a new block in the blockchain in a manner known per se in the field of blockchain technologies, in order to get paid for performing the smart contracts.

The blockchain 50 consists of a plurality of interlinked blocks. The length of the blockchain 50 may continually grow due to the generation of new blocks. There are only five in terlinked blocks n-2, n-1, n, n+1, n+2 schematically shown in Fig. 2. However, it should be understood that the number of the blocks in the blockchain 50 is not limited to five.

Reference signs 10, 12, 14, 16, 18 denote points in time along the growth of the blockchain 50 which are only approxi mately depicted in Fig. 2, but do not represent precise time.

At the time 10, the inventive first smart contract 2 holding only business logics and rules and the inventive second smart contract 4 for data management are deployed into the block- chain system 100. They are then stored in the next block n-2 of the blockchain 50.

At the time 12, the first smart contract 2 is executed, and data regarding state information are generated. The first smart contract 2 calls then the "store" function of the sec ond smart contract 4 in order to store the data in a new block n-1 which stores also the existing first and second smart contracts 2, 4.

At the time 14, a third smart contract 6 which is an updated version of the first smart contract 2 is deployed in the blockchain system 100. The updated/third smart contract 6 is then stored in a new block n together with the previous ver sion 2, the second smart contract 4 and data regarding state information generated by the previous version 2.

At the time 16, the third smart contract 6 may retrieve said data regarding state information from a certain address of the block n by calling the "read" function of the second smart contract 4. The first smart contract 2 comprises codes which are able to detect the deployment of the updated ver sion and codes such as function "suicide" or "selfdestruct" to have the first smart contract 2 killed, and thus prevent ing the first smart contract 2 from being performed anymore. In this way, the second and third smart contracts 4, 6 as well as the "inherited" data regarding state information gen erated by the first smart contract 2 are stored in the new block n+1.

At the time 18, the third smart contract 6 is performed. New data are generated accordingly and then stored in the new block n+2.

In another embodiment not shown in Fig. 2, the first smart contract 2 comprises codes which are able to detect not the deployment, but the execution of the updated version 6. In this case, the first smart contract 2 does not call its func tion "suicide" or "selfdestruct" until the time 18 at which the third smart contract 6 is performed.

The embodiment of the inventive method for managing data of a smart contract in a blockchain / distributed ledger system comprising a plurality of interlinked blocks shown in Fig. 3 comprises three steps S10, S20, S30.

In the step S10, a first and a second smart contract are stored in the blocks. In the step S20, the first smart con tract is executed to read/store first data from/to the second smart contract. In the step S30, the second smart contract is executed, upon the execution of the first smart contract, to read/store the first data from/to the blocks.

The embodiment of the inventive computer program 200 shown in Fig. 4 comprises instructions 250 which, when the program 200 is executed by a computer, cause the computer to carry out the embodiment of the inventive method shown in Fig. 3.

The embodiment of the inventive computer-readable medium 300 shown in Fig. 5 comprises instructions 350 which, when exe cuted by a computer, cause the computer to carry out the em bodiment of the inventive method shown in Fig. 3.

The invention is described and illustrated in detail by the preferable embodiments mentioned above. However, the inven tion is not limited by the disclosed examples, and other var iations can be derived therefrom while still being inside the protection scope of the invention.