DE102021205107A1 - Computer-implemented method and test system for computer-aided testing of a smart contract - Google Patents

Abstract

The invention relates to a test system and computer-implemented method for computer-aided testing of a smart contract, computer-implemented method for computer-aided testing of a new smart contract (RC) which is intended to expand a predetermined series of original smart contracts (R_1,...,R_N) designed as basic rules where the original smart contracts (R_1,...,R_N) form an original smart contract chain (TE1) and the original smart contracts (R_1,...,R_N) with the new smart contract (RC) form a form a new smart contract chain (TE2), and wherein each of the smart contracts (R_1,...,R_N) is configured to be deployed in a distributed peer-to-peer system, wherein the individual smart contracts (R_1 ,...,R_N) have the same parameters and deliver result values according to the basic rules stored in the respective Smart Contract (R_1,...,R_N), whereby a number of test parameters (T_1,...,T_M) are generated and wherein the new smart contract (RC) to be tested, by which the original smart contract chain (TE1) is to be extended, is only provided as an executable program and a test environment is simulated, which is configured, at least the new one Execute smart contract chain (TE1) with provided respective test parameters (T_1,...,T_M).

Description

The invention relates to a computer-implemented method and test system for computer-aided testing of a smart contract.

Peer-to-peer systems without a central authority that manage the data flow represent a special type of distributed systems. For example, they consist of individual computers, also called nodes. A well-known example of such a peer-to-peer system is a blockchain. A blockchain comprises a continuously expandable list of data blocks that are linked together using cryptographic processes. A block can be a list of transactions/data that is recorded in a ledger (account book) over a certain period of time. The chain includes a hash key that links the blocks together.

A private blockchain is a form of blockchain where only selected participants have access rights. The private blockchain is not publicly visible, but can only be viewed and checked by authorized persons. It is considered to be more secure due to the heavily regulated access and is therefore preferably used in companies to manage internal transactions.

Transactions are validated and packed into blocks, and the blocks are appended to the blockchain after going through a consensus algorithm. Thus, a chain of data records becomes unchangeable and tamper-proof.

A special blockchain is Hyperleger Fabric and another is Ethereum, which is based on a public blockchain. Ethereum and Hyperleger enable so-called “smart contracts (intelligent contract)”. This allows contracts to be programmed that are executed and checked electronically.

However, smart contracts only execute a code snippet instruction. A frequently used use case of 'smart contract' is based on "if this then that" rules. To do this, programs are created and executed on a virtual machine (VM). Compared to normal contracts, smart contracts offer greater transparency, efficiency and the possibility of automating contract sequences. They also achieve a high level of reliability, since parameters and conditions are clearly defined and follow fixed rules. Thanks to cryptographic encryption methods (hash functions) and the nature of the peer-to-peer system, manipulation of the contract terms is almost impossible and can be ensured using standardized means even if the contract value is low.

However, special care must be taken when programming smart contracts. Programmed security gaps can have fatal consequences. This was the case, for example, with “The DAO Hack” that led to the Ethereum hard fork “Ethereum Classic”.

The Blockchain Hyperledger Fabric is purpose-built to address enterprise use cases. In particular, Hyperledger Fabric is used to implement smart contracts, which reflect business logic. Every member of the Hyperledger Fabric must be able to close deals and contracts using smart contracts.

• Generieren einer vorgegebenen Transaktion und/oder eines vorgegebenen Smart-Contracts , wobei der vorgegebenen Transaktion und/oder dem vorgegebenen Smart-Contract jeweils ein Vorgabewert zugeordnet ist;
• Einfügen der vorgegebenen Transaktion und/oder des vorgegebenen Smart-Contracts in die Blockkette;
• Ausführen der vorgegebenen Transaktion und/oder des vorgegebenen Smart-Contracts, wobei ein Messwert des Ausführens der vorgegebenen Transaktion und/oder des vorgegebenen Smart-Contracts erfasst wird, wobei das Ausführen der vorgegebenen Transaktion und/oder des vorgegebenen Smart-Contracts das Bearbeiten der vorgegebenen Transaktion und/oder des vorgegebenen Smart-Contracts durch die Blockkette bewirkt;
• Testen des Messwertes anhand des Vorgabewertes, wobei bei einer Abweichung von dem Vorgabewert ein Steuersignal bereitgestellt wird.

the WO 2018 188 967 A1 discloses a method for computer-aided testing of a block chain with the following method steps:

• generating a specified transaction and/or a specified smart contract, wherein a default value is assigned to the specified transaction and/or the specified smart contract;
• inserting the predetermined transaction and/or the predetermined smart contract into the blockchain;
• Executing the predetermined transaction and/or the predetermined smart contract, capturing a metric of executing the predetermined transaction and/or the predetermined smart contract, wherein executing the predetermined transaction and/or the predetermined smart contract involves processing the predetermined transaction and/or the predetermined smart contract effected by the blockchain;
• Testing the measured value using the default value, with a control signal being provided if there is a deviation from the default value.

It is an object of the invention to specify a means which enables members of a peer-to-peer system to use smart contracts securely.

The object is achieved by a computer-implemented method for computer-aided testing of a new smart contract according to the features of claim 1 and a test system for computer-aided testing of a new smart contract according to the features of claim 8.

Further advantageous measures which can be combined with one another in order to achieve further advantages are listed in the dependent claims.

According to the invention, the object is achieved by a computer-implemented method for computer-aided testing of a new smart contract, which is intended to expand a predetermined series of original smart contracts designed as basic rules, the original smart contracts forming an original smart contract chain and the original smart Contracts form a new smart contract chain with the new smart contract, and each of the smart contracts is configured to be deployed in a distributed peer-to-peer system, each smart contract having the same parameters and result values according to deliver the basic rules stored in the respective smart contract,
wherein a number of test parameters are generated and wherein the new smart contract to be tested, with which the original smart contract chain is to be extended, is provided only as an executable program and wherein a test environment is simulated which is configured, at least the new smart Execute the contract chain with the respective test parameters provided.

In this context, computer-aided means that the method is executed on a processor, for example. A processor is an electronic circuit, for example. A processor can in particular be a microprocessor or a microcontroller, for example an integrated circuit IS or an embedded system, which usually act in combination with a memory unit/memory for storing program instructions, etc. It can also be a graphics processor GPU (Graphic Processing Unit).

Preferably, each of the smart contracts is written in a predetermined programming language.

For example, memory can be volatile storage in the form of random-access memory (RAM) or permanent storage such as a hard drive or disk.

A smart contract chain is a series of smart contracts, each of which has non-conflicting ground rules. A basic rule, for example, can be that the odometer must not decrease as a vehicle is continuously operated. However, when taking out vehicle insurance, the basic rule can also be that this can only be done from the age of 21. A newly added smart contract allowing them to be 18+ in relation to the same deal would violate such a basic rule.

The basic rules are stored user- and application-specifically in the individual Smart Contracts.

Each of the smart contracts is configured to be deployed in a distributed peer-to-peer system. This also applies to the smart contract chain, which can be run on the distributed peer-to-peer system with the appropriate parameters. The new smart contract to be added can be added as a new contract to the e.g. private blockchain (peer-to-peer system).

Smart contracts, which are provided without knowledge of the exact software code / content, are considered to be only executable programs.

In business relationships, the contracting parties must comply with the basic rules that have been set out in advance. These can be stored in a smart contract to which the contractual partners have joined forces or are members of this network. It has been recognized that any member or approved new member must have the ability to add a new smart contract to existing smart contracts without violating the applicable rules. The violation can, for example, be intentional (basic rule changed). However, it can also be an unintentional violation, for example if the smart contract has errors in the program code that lead to a fundamental rule violation (for example, a driver forgot to set the minimum age). The new smart contract is provided as at least an executable program. It is not necessary to provide the software code.

According to the invention, a number of test parameters are first created/generated. Test parameters can also be understood as test parameter-value pairs (or payloads).

According to the invention, a test environment is then simulated in which the new smart contract chain expanded by the new smart contract is tested. The invention makes it possible to safely expand existing Smart Contract contracts without violating existing basic rules.

By testing in a simulated test environment with sufficient test parameters, an extension to a smart contract chain, for example, can be achieved without destroying the entire smart contract chain with an invalid smart contract. If, for example, the program code of the new smart contract is faulty or violates the rules, this can no longer be reversed after it has been installed on the peer-to-peer system like a private blockchain. Since information (smart contracts) on a peer-to-peer system such as blockchain is immutable, such errors cannot be changed afterwards, otherwise the basic rules that apply to all users could be changed. The invention can create a private blockchain or distributed peer-to-peer network system with users, in which there are some non-negotiable ground rules. Nevertheless, existing contracts can be supplemented or restricted by certain basic rules without knowledge of the software code/exact content of the new smart contract to be added being necessary.

The simulated test environment allows faulty smart contracts to be checked before they are permanently added to a blockchain, for example. According to the invention, a smart contract that has been checked in this way and is to be added can be used to expand an existing set of basic rules, with the existing basic rules already being validated and provided on the private blockchain, for example.

The method according to the invention ensures that, for example, if the non-decreasing property of the odometer value is used as a basic rule, no member can violate this through a tailor-made smart contract. This means that a bespoke or flawed smart contract cannot break the ground rules already in place and validated. The method according to the invention enables members of the peer-to-peer system to use jointly agreed business logic as intelligent contracts, which only apply to the members involved in the agreement, without violating the basic rules.

The original smart contract chain and the new smart contract chain with the newly added smart contract are preferably tested in the simulated test environment. To do this, the original smart contract chain and the new smart contract chain with the extended smart contract are executed in the simulated test environment.

Preferably, the original smart contract chain returns an original result value and the new smart contract chain returns a new result value for each test parameter in the simulated test environment.

In a further preferred embodiment, the result values are marked as passed and failed, depending on whether executing a respective test parameter from the basic rules stored in the smart contracts does not indicate an error or whether executing the respective test parameter from the basic rules stored in the smart contracts is incorrect. Failed means, for example, that the smart contract chain tested with a test parameter returns an error when run.

• - der ursprüngliche und der neue Ergebniswert sind als fehlgeschlagen gekennzeichnet,
• - der ursprüngliche Ergebniswert ist als bestanden gekennzeichnet und der neue Ergebniswert ist als fehlgeschlagen gekennzeichnet,
• - der ursprüngliche Ergebniswert ist als bestanden gekennzeichnet und der neue Ergebniswert ist als bestanden gekennzeichnet.

Preferably, adding the new smart contract to the original smart contract chain is granted if for all test parameters related to the original and new smart contract chain:

• - the original and the new result value are marked as failed,
• - the original result value is marked as passed and the new result value is marked as failed,
• - the original score is marked as passed and the new score is marked as passed.

This can, for example, prevent some non-negotiable ground rules from being adhered to, such as that the odometer value of a vehicle must never decrease. This means that the range of values in which the result value must lie can be limited, but it cannot increase. Thus, for example, the non-decreasing property of the odometer value is employed as a basic rule, and no member can violate this through a custom-made or mis-programmed smart contract.

• - der ursprüngliche Ergebniswert ist als fehlgeschlagen gekennzeichnet und der neue Ergebniswert ist als bestanden gekennzeichnet.

Preferably, adding the new smart contract to the original smart contract chain is rejected if for at least one test parameter related to the original and new smart contract chain:

• - the original score is marked as failed and the new score is marked as passed.

This makes it easier to identify smart contracts that violate the basic rules set out in the other smart contracts. Adding such a smart contract will thus denied and the functionality of the entire smart contract chain on the peer-to-peer system can thus be maintained.

The new smart contract is preferably designed as a blind executable program. This means that further information such as the software code or the rules it contains is not known, but only the parameters to be entered are known.

The task is also solved by a test system for computer-aided testing of a new smart contract which is intended to extend a predetermined series of original smart contracts designed as basic rules, with the original smart contracts forming an original smart contract chain and the original smart contracts with form a new smart contract chain from the new smart contract, and wherein each of the smart contracts is configured to be set up in a distributed peer-to-peer system, wherein the individual smart contracts have the same parameters and result values according to the in provide the basic rules stored in the respective smart contract, with a test environment being simulated which is configured to run at least the new smart contract chain with the respective test parameters provided and with the new smart contract being extended by the original smart contract chain should be al s executable program is provided.

The test system can, for example, include a processor and a memory as well as a transmission unit, which transmits the new smart contract to a private blockchain, for example, as required.

• 1: zeigt ein erfindungsgemäßes Verfahren schematisch als Blockschaubild. Obwohl die Erfindung im Detail durch die bevorzugten Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt. Variationen hiervon können vom Fachmann abgeleitet werden, ohne den Schutzumfang der Erfindung, wie er durch die nachfolgenden Patentansprüche definiert wird, zu verlassen.

The advantages of the method can also be transferred to the test system. Other features, properties and advantages of the present invention result from the following description with reference to the attached figure. It shows schematically:

• 1 : shows a method according to the invention schematically as a block diagram. Although the invention has been illustrated and described in detail by the preferred embodiments, the invention is not limited by the disclosed examples. Variations may be devised by those skilled in the art without departing from the scope of the invention as defined by the following claims.

1 shows the method according to the invention schematically. First of all, certain basic rules R_1,...,R_N have been mutually agreed upon by users. These are designed as a smart contract and stored as a smart contract chain TE1 on a peer-to-peer system, here a private blockchain, to prevent unwanted changes.

Such a basic rule can be, for example, that the odometer value of a vehicle must never be reduced.

If the members include, for example, a car maintenance company and an insurance company, a basic rule can be, for example, that the insurance company must be informed of a necessary maintenance appointment for a vehicle that the owner has not kept.

Storing such basic rules in the form of smart contracts on a private blockchain guarantees users that the basic rules cannot be changed unilaterally. On the one hand, a private blockchain offers data protection through encryption, while at the same time being tamper-proof. By avoiding central structures, security is also increased and costs saved. Changes or updates are only possible if everyone agrees. This means that data stored in a private blockchain is accurate, transparent and consistent. They have been verified and approved by all members of the group.

A current or new member wants to add a new smart contract RC to the smart contract chain TE1 already on the private blockchain and validated and recognized by the members. In particular, this is to be added to the smart contract chain TE1 as a blind smart contract RC, i.e. only as an executable program. However, even if the software code is included, it is difficult to verify programming errors and thus unintentional changes to the basic rules. Such a new smart contract RC can thus represent unwanted changes to the valid basic rules, for example due to programming errors, which are difficult to correct after being installed on the private blockchain.

According to the invention, it was recognized that testing of the new smart contract RC is necessary in advance.

For this purpose, a test environment in a test system 1 is simulated. A large number of test parameters T_1,...,T_M are then generated, where M is a very large integer. Test parameters can also be understood as test parameter-value pairs (or payloads).

The already validated smart contract chain TE1 is first tested with these test parameters T_1,...,T_M, so that an original result value is returned for each test parameter T_1,...,T_M (or each test parameter set) in the simulated test environment .

Furthermore, the new smart contract chain TE2, which consists of the original smart contract chain TE1 and the added new smart contract RC, is tested with the test parameters T_1,...,T_M, so that for each test parameter T_1,... .,T_M (or each test parameter set) returns a new result value in the simulated test environment. This sets the highest priority for the Smart Contract RC. This means that if RC violates e.g. R1, the result will be taken from RC and not from R1.

These result values are marked as passed and failed, depending on whether executing a respective test parameter T_1,..T_M from the smart contract chain TE1 or TE2 does not return an error or whether executing a respective test parameter T_1 ,..T_M from smart contract chain TE1 or TE2 is faulty.

• - der ursprüngliche Ergebniswert der ursprünglichen Smart-Contract-Kette TE1 und der neue Ergebniswert der neuen Smart-Contract-Kette TE2 ist als fehlgeschlagen (Failed) gekennzeichnet. Dies ist in 1 mit F1 beschrieben.
• - der ursprüngliche Ergebniswert der ursprünglichen Smart-Contract-Kette TE1 ist als bestanden gekennzeichnet (Passed) und der neue Ergebniswert der neuen Smart-Contract-Kette TE2 ist als fehlgeschlagen (Failed) gekennzeichnet. Dies ist in 1 mit F2 beschrieben.
• - der ursprüngliche Ergebniswert der ursprünglichen Smart-Contract-Kette TE1 ist als bestanden gekennzeichnet (Passed) und der neue Ergebniswert der neuen Smart-Contract-Kette TE2 ist als bestanden (Passed) gekennzeichnet. Dies ist in 1 mit F3 beschrieben.

Thereby, an addition of the new smart contract RC to the original smart contract chain TE2 is granted if for all tested test parameters T_1,..T_M applies with respect to the original smart contract chain TE1 and new smart contract chain TE2 :

• - the original result value of the original smart contract chain TE1 and the new result value of the new smart contract chain TE2 are marked as failed. this is in 1 described with F1.
• - the original result value of the original smart contract chain TE1 is marked as Passed and the new result value of the new smart contract chain TE2 is marked as failed (Failed). this is in 1 described with F2.
• - the original result value of the original smart contract chain TE1 is marked as passed (Passed) and the new result value of the new smart contract chain TE2 is marked as passed (Passed). this is in 1 described with F3.

This makes it possible to expand the existing original smart contract chain TE1 with the new smart contract RC without knowing the content of the new smart contract RC exactly and/or avoiding unwanted programming errors that can entail a change in the basic rules.
This can also be used to extend an existing set of ground rules in the form of smart contracts R_1,..,R_N.

• - der ursprüngliche Ergebniswert der ursprünglichen Smart-Contract-Kette TE1 ist als fehlgeschlagen gekennzeichnet (Failed) und der neue Ergebniswert der neuen Smart-Contract-Kette TE2 ist als bestanden (Passed) gekennzeichnet. Dies ist in 1 mit F4 beschrieben.

Furthermore, adding the new smart contract RC to the original smart contract chain TE2 is rejected if all tested test parameters T_1,..T_M apply with respect to the original smart contract chain TE1 and new smart contract chain TE2 :

• - the original result value of the original smart contract chain TE1 is marked as failed (Failed) and the new result value of the new smart contract chain TE2 is marked as passed (Passed). this is in 1 described with F4.

The method according to the invention and the test system 1 according to the invention ensure that no member can violate one of the basic rules through a tailor-made smart contract. The basic rules already validated, which must be respected by all members, can now be followed without precise knowledge of the new Smart Contract RC. Any member of the blockchain is thus able to add custom smart contracts without violating the already validated and recognized ground rules.

reference list

T_1,...,T_M

test parameters

TE1

original smart contract chain

TE2

new smart contract chain

R_1,...,R_N

original smart contracts

RC

new smart contract

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• WO 2018188967 A1 [0009]

Claims (14)

Computer-implemented method for computer-aided testing of a new smart contract (RC) which is intended to extend a predetermined set of basic smart contracts (R_1,...,R_N) designed as ground rules, the original smart contracts (R_1,...,R_N ) form an original smart contract chain (TE1) and the original smart contracts (R_1,...,R_N) form a new smart contract chain (TE2) with the new smart (RC) contract, and each of the Smart Contracts (R_1,...,R_N) is configured to be set in a distributed peer-to-peer system, where each Smart Contract (R_1,...,R_N) has the same parameters and result values according to the deliver the basic rules stored in the respective smart contract (R_1,...,R_N), with a number of test parameters (T_1,...,T_M) being generated and the new smart contract (RC) to be tested, by which the original smart contract chain (TE1) who expanded is intended to be provided only as an executable program and a test environment is simulated which is configured to run at least the new smart contract chain (TE2) with the respective test parameters (T_1,...,T_M) provided. Computer-implemented method claim 1 , characterized in that the original smart contract chain (TE1) and the new smart contract chain (TE2) with the test parameters (T_1,...,T_M) are first tested in the simulated test environment. Computer-implemented method claim 2 , characterized in that the original smart contract chain (TE1) returns an original result value and the new smart contract chain (TE2) a new result value for each test parameter (T_1 ,...,T_M) in the simulated test environment. Computer-implemented method claim 3 , characterized in that the result values are marked as passed and failed, depending on whether executing a respective test parameter (T_1,...,T_M) from the basic rules stored in the Smart Contracts (R_1,...,R_N) does not produce an error or whether the execution of the respective test parameter (T_1,...,T_M) is incorrect based on the basic rules stored in the Smart Contracts (R_1,...,R_N). Computer-implemented method claim 4 , characterized in that adding the new smart contract (RC) to the original smart contract chain (TE1) is granted if for all test parameters (T_1,...,T_M) related to the original smart contract Chain (TE1) and new smart contract chain (TE2) applies: - the original and the new result value is marked as failed, - the original result value is marked as passed and the new result value is marked as failed, - the original result value is marked as passed and the new result value is marked as passed. Computer-implemented method according to any of the preceding Claims 4 or 5 , characterized in that adding the new smart contract (RC) to the original smart contract chain (TE1) is rejected if for at least one test parameter (T_1,...,T_M) related to the original smart contract chain (TE1) and new smart contract chain (TE2): - the original result value is marked as failed and the new result value is marked as passed. Computer-implemented method according to one of the preceding claims, characterized in that the new smart contract (RC) is designed as a blind executable program. Test system (1) for computer-aided testing of a new Smart Contract (RC) which is intended to extend a predetermined series of original Smart Contracts (R_1,...,R_N) designed as ground rules, the original Smart Contracts (R_1,... ,R_N) form an original smart contract chain (TE1) and the original smart contracts (R_1,...,R_N) form a new smart contract chain (TE2) with the new smart contract (RC), and where each of the smart contracts (R_1,...,R_N) is configured to be deployed in a distributed peer-to-peer system, with each smart contract (R_1,...,R_N) having the same parameters and result values according to the basic rules stored in the respective smart contract (R_1,...,R_N), a test environment being simulated which is configured to run at least the new smart contract chain (TE2) with the respective test parameters (T_1,. ..,T_M) and where the new Smart contract (RC) by which the original smart contract chain (TE1) is to be extended is provided as an executable program. Test system (1) according to claim 8 , characterized in that the new smart contract (RC) is designed as a blind executable program. Test system (1) according to claim 8 or 9 , characterized in that the test system (1) is simulated in the test environment first the original smart contract chain (TE1) and the new smart contract chain (TE2) with the test parameters (T_1, ..., T_M ) to test. Test system (1) according to claim 10 , characterized in that the original smart contract chain (TE1) is configured to generate an original result value and the new smart contract chain (TE2) is configured to generate a new result value for each test parameter (T_1,..., T_M) to return. Test system (1) according to claim 11 , characterized in that the test system (1) is simulated to mark the result values as passed and failed, depending on whether a respective test parameter (T_1,...,T_M) is executed by the smart contracts (R_1,. ..,R_N) stored basic rules does not reflect an error or whether the execution of the respective test parameter (T_1,...,T_M) of the basic rules stored in the Smart Contracts (R_1,...,R_N) is incorrect. Test system (1) according to claim 12 , characterized in that the test system (1) is simulated to grant an addition of the new smart contract (RC) to the original smart contract chain (TE1) if for all test parameters (T_1,...,T_M) in Regarding the original smart contract chain (TE1) and new smart contract chain (TE2): - the original and the new result value is marked as failed, - the original result value is marked as passed and the new result value is marked as marked as failed, - the original score is marked as passed and the new score is marked as passed. Test system (1) according to claim 12 or 13 , characterized in that the test system (1) is simulated to reject adding the new smart contract (RC) to the original smart contract chain (TE1) if for at least one test parameter (T_1,...,T_M) in relation to the original smart contract chain (TE1) and new smart contract chain (TE2): - the original result value is marked as failed and the new result value is marked as passed.

Images