Method for improving memory allocation of LLL generated code

Abstract

A method for improving the memory allocation of code generated by means of a language model comprises the steps of:-providing program code, which is generated by means of a language model; when the new version of the program code is available, generating an executable file by means of compilation and detection, in which the memory cleaning program inserts instructions into the program code and / or into the executable file; -performing a fuzz test by an obfuscator, where the obfuscator injects an input into the executable file; -monitoring memory performance, and optionally runtime information, behavior and / or output of the executable file; storing metadata generated from the allocated and released memory in a memory metadata database, where the metadata is based on the instructions and is stored during generation of the executable file and / or during execution of a fuzz test; and outputting the program code if no reduction in memory performance or other errors are found.

Description

Technical Field

[0001] The present invention relates to a method for improving memory allocation of LLL generated code. Background Art

[0002] Language models such as Large Language Models (LLM) are increasingly used to generate program code. This can be done, for example, within the framework of language translation or automated program code translation or code refactoring.

[0003] The use of methods for automated code generation, e.g. from LLMs, always presents challenges, so code correctness cannot be guaranteed and performance improvements cannot be guaranteed. For example, improvements for small code snippets can be generated, but the method is not practical for larger code bases.

[0004] Working with a larger code base reduces the usefulness of certain static methods (e.g., abstract interpretation) because correctness guarantees cannot be computed in a reasonable time, or require approximations that then lead to over-approximation errors. Furthermore, static methods are hardly suitable for measuring software performance, such as memory consumption.

[0005] The sanitizer can identify all types of runtime errors. Here, the focus is particularly on memory errors and memory inefficiencies that occur during runtime. The danger lies in particular with partially initialized variables. The value of variables can sometimes only be determined when these variables are initialized, for example by a write operation. In some cases, the C++14 standard allows indefinite propagation of values, so that sanitizers often report a large number of false positive results. Partially initialized variables can become vulnerable if the uninitialized value exceeds the trust range.

[0006] The problem of uninitialized memory can usually be solved by using a memory cleaner. However, LLM-based code generators can generate suboptimal, but still functionally correct code (e.g., increased heap memory allocations). Tests, such as unit tests used to check LLM-based code optimizations, have little or no chance of revealing such inefficiencies. Summary of the invention

[0007] A first general aspect of the present disclosure relates to a method for improving memory allocation of code generated with the aid of a language model.

[0008] The method includes:

[0009] - providing a program code, the program code being generated with the aid of a language model;

[0010] When a new version of the program code becomes available,

[0011] - generating an executable file by means of compilation and detection, wherein the memory cleaning program inserts instructions into the program code and / or the executable file;

[0012] - performing fuzz testing via a fuzzer, wherein the fuzzer injects input into the executable file;

[0013] - monitoring memory performance, and optionally monitoring runtime information, behavior and / or output of the executable;

[0014] - storing metadata generated from allocated and freed memory in a memory metadata database, wherein the metadata is based on the instructions and is stored during generation of the executable file and / or during performance of fuzz testing;

[0015] - If no memory degradation or other errors are found, the program code is output.

[0016] A second general aspect of the present disclosure relates to a method for training a language model set up to automatically generate program code.

[0017] The method includes:

[0018] - Input source code into the language model and generate program code;

[0019] - improving the program code using the method according to the first general aspect;

[0020] - generating a reward for the language model, wherein the reward is based on monitoring memory performance and optionally monitoring runtime information, behavior and / or output of the executable and / or such metadata;

[0021] -Use the value of the reward to update the weight of the language model.

[0022] A third general aspect of the present disclosure relates to a computer system, which is designed to execute the method according to the first and / or second general aspect (or its implementations).

[0023] A fourth general aspect of the present disclosure relates to a computer program, which is designed to perform the method according to the first general aspect (or its embodiments).

[0024] A fifth general aspect of the present disclosure relates to a computer-readable medium or signal storing and / or containing a computer program according to the fourth general aspect (or an embodiment thereof).

[0025] In some cases, the techniques of the first, second, third, fourth, and fifth general aspects may have one or more of the following advantages.

[0026] The present disclosure uses a dynamic software testing method, fuzz testing, and in particular fuzz testing extended with a cleaner. A memory cleaner is used to make memory behavior (such as allocation, release, and size) visible. Fuzz testing is used to cover as many different paths as possible in the software to be tested. Based on the observed memory behavior, it can be determined whether the code generated using LLM becomes more powerful, which can achieve a feedback loop for better command prompts (prompts) for new, LLM-generated code.

[0027] The present disclosure enables software testing without existing tests, especially unit tests for checking whether the generated code patches are functionally correct. These tests typically do not measure memory consumption, nor do they measure improvements in memory performance. Existing tests fail only when too much memory is used. Using LLM for code generation always carries the risk that the generated code contains meaningless or poorly functional code. The present disclosure enables iterative learning to improve the LLM generated code over multiple generations.

[0028] Another problem with LLM is refactoring and optimizing code for different goals. Here, a typical allocation of heap memory is to release the heap memory after all operations on the data are completed. On devices with limited memory space, such as IoT devices, refactoring may be useful to reuse heap memory between various data operations so that each variable does not need to be kept in memory. The present disclosure enables monitoring and improving memory allocation to support such refactoring. In other words, the present disclosure enables effective testing of the memory consumption of LLM-generated code so that a language model (such as LLM) can generate better, especially memory-optimized code.

[0029] The present disclosure enables coverage to be implemented as a quality metric for generated code, which in turn enables the selection of better generated code. This higher quality code is then easier to test.

[0030] The present disclosure relates to any product based on automated testing, especially dynamic testing methods, and any product with legacy code or performance issues.

[0031] In this disclosure, some terms are used in the following manner.

[0032] The “language model” may be, in particular, a large language model (LLM), a neural network, a recurrent neural network (RNN), a transformer model, or a code model as a language model specifically for code, or a very general language model, which also includes code. It also includes computer languages, such as program codes of computing devices (such as computers). The language of the model may include not only natural languages, but also artificial languages ​​such as programming languages.

[0033] In software development, code "refactoring" means making structural improvements to the code while maintaining observable program behavior, i.e., functionality. This is done, for example, to improve readability, understandability, maintainability, and / or extensibility, with the goal of reducing the corresponding workload for error analysis and / or functional expansion. Typical refactorings are, for example, renaming variables to self-explanatory names and / or extracting code parts into their own methods. Through refactoring, the quality of the code is improved, and thus the quality of the software is improved.

[0034] "Testing", "checking" or "comparison" of source program code and target program code may include: for example, formal checking of identical behavior of source program code and target program code by means of bounded model checking, testing in the source language, contract testing and / or syntax and style testing in the source language, fuzz testing, mutation of inputs to the test harness, derivation from contracts of the source language and / or target language and / or derivation from language models.

[0035] A "Test-Harness" or test framework includes a collection of software and test data that is used to systematically and automatically test a program under various environmental conditions. A test harness typically includes: a test execution engine that is responsible for processing the test logic; and a test data repository or database that contains test scripts, test programs, and other test resources. Here, the test harness is automatically generated, for example, by adding differentiated tests to the database. The start of the test can be initiated with a given or pre-made test from the test database. The system can also automatically generate tests.

[0036] Here, the data can be software code, including test cases and wiring harnesses plus additional (natural language) descriptions of functional principles or effective ranges. In the case of language translation, C is described here as the source language and Rust is described as the target language, but other combinations are also possible. Translating C into Rust is of interest because Rust provides features in the field of safety-critical systems, but there is a large amount of legacy code in other languages, especially C. In the case of refactoring, the source language and target language are the same.

[0037] A "Memory Sanitizer" is a tool that identifies uses of uninitialized memory. A memory sanitizer may insert additional instructions, and / or store metadata on which the memory sanitizer works. A memory sanitizer may identify uses of uninitialized memory, memory leaks, out of memory space, hanging or infinite loops, and infinite recursion (StackOverflows). For example, other sanitizers also identify use-after-free, buffer overflows, data races, deadlocks, int / float overflows, or bitwise shifts of invalid amounts.

[0038] An "intermediate representation" (IR) - also broadly called an intermediate language - is a data structure or code that is generated during the translation process through a compiler or virtual machine at an abstract level between a high-level source language and a target language that is usually machine-dependent. This intermediate representation can be used internally by a compiler or virtual machine to represent source code.

[0039] "Contracts" are an integral part of contract-based programming or "design by contract." This is a software development concept that aims to optimize the interaction of individual program modules by defining formal contracts for use beyond their statically defined interfaces.

[0040] The term "codebase" refers to the entirety of the source text files and possibly related configuration files belonging to a project. The codebase may also include various other files required for the compilation process, such as the so-called Makefile.

[0041] "Fuzzing" or "Fuzz-Testing" is the automated process of sending randomly generated inputs from a fuzzer to a target or target program and observing the target's response.

[0042] A "Fuzzer" or "Fuzzing-Engine" is a program that automatically generates inputs. Therefore, they are not necessarily associated with the software under test and do not perform any instrumentation. However, they are capable of instrumenting code, generating test cases and executing the program under test. Known examples are afl and libfuzzer.

[0043] A "Fuzz-Target" is a software program or function to be tested by fuzz testing. The main characteristics of a fuzz target are that it is a binary file, library, application programming interface (API) or something else that can process bytes as input.

[0044] A "Glue-Code", "Wrapper", "Harness" or "Fuzz Driver" connects the fuzzer with the fuzz target.

[0045] A "fuzz test" is a combined version of a fuzzer and a fuzz target. The fuzz target can then be instrumented code to which the fuzzer is connected as input. Fuzz tests can be executed. A fuzzer can also start, observe, and stop multiple ongoing fuzz tests (typically hundreds or thousands per second), each with slightly different inputs generated by the fuzzer.

[0046] A "test case" is a specific input and a specific test run (TestDurchlauf) from a test harness or fuzz test. To ensure reproducibility, the runs of interest (finding new code paths or crashes) are stored.

[0047] "Instrumentation" is used to make coverage metrics observable, for example during compilation. Instrumentation is the insertion of commands into a program in order to obtain feedback about the execution. It is usually implemented by the compiler and can, for example, describe the code blocks reached during execution.

[0048] Coverage-guided fuzzing uses code coverage information as feedback during fuzz testing in order to identify whether an input causes the execution of new code paths / blocks.

[0049] In "mutation-based fuzzing", new inputs are created by taking a set of known inputs (the corpus) and applying mutations to them randomly.

[0050] In "generation-based fuzzing", new inputs are recreated from scratch, for example by using an input model or input grammar.

[0051] A "Mutator" is a function that takes a byte as input and outputs a small random mutation of that input.

[0052] A "corpus" (Korpus, plural: Korpora) is a set of inputs. The initial input is the seed. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 is a flow chart illustrating the disclosed technique for improving memory allocation.

[0054] Figure 2 A system is schematically shown in which the disclosed techniques for improving memory allocation may be used.

[0055] Figure 3 A memory cleaning program is schematically shown, in which the technology for improving memory allocation of the present disclosure can be used.

[0056] Figure 4 A system is schematically shown in which the disclosed techniques for improving memory allocation may be used.

[0057] Figure 5 is a flow chart illustrating the disclosed technique for training a language model. DETAILED DESCRIPTION

[0058] Figure 1 1 is a flow chart showing a method 10 for verifying static warnings of code generated with the aid of a language model. Figure 1 , the generated code is generated by automated program code translation from a source language to a target language. Alternatively, the program code may be generated by code refactoring.

[0059] The method 10 proposed in the present disclosure is designed to improve the memory allocation of software code generated by means of a language model. The software can be designed to control, regulate and / or monitor at least one computing unit of a technical system, in particular a cyber-physical system, in particular a vehicle. The software can be in particular embedded software, which is designed to be executed on an embedded (i.e., for example, task-specific) system.

[0060] In a first step, program code is provided 11, which is generated by means of a language model. The provision includes not only inputting the program code into the method or the system, but also including the generation or the language model in the method or the system.

[0061] When a new version of the program code is available, an executable file is generated 12 by means of compilation and detection, for example by a memory cleaner, wherein the memory cleaner inserts instructions into the program code, for example, during the generation or inserts instructions into the executable file during the execution. The cleaner inserts its commands optimally into the intermediate representation to support a variety of different languages. In the memory cleaner, "shadow memory" is used to initialize and fill "normal" instructions with variables and information that it is shadow memory. Then, there are further instructions for implementing the method. It is also possible to track which variables are allocated and released at what memory size. With this, the development of memory utilization can be understood. However, the pure number of allocations can also be of interest.

[0062] Optionally, a corpus with input for the fuzzer is provided, the corpus containing initial test cases from a code repository of program code and / or from provided tests and test harnesses. The corpus is initially populated and can be further populated during the method.

[0063] Next, fuzz testing is performed 13 by the fuzzer, wherein the fuzzer injects input into the executable file. The goal is to achieve the best possible coverage of the file or code by the injected input of the fuzzer.

[0064] Next, memory performance (such as memory usage or memory footprint) is monitored 14, and optionally runtime information (e.g., actual runtime of each test case), behavior of the executable, and / or output. In this monitoring, the executables subjected to fuzz testing and the memory metadata database may be monitored. Provision may be made for returning memory performance, runtime information, behavior of the executable, and / or output of the executable to the fuzzer.

[0065] Next, metadata generated from the allocated and released memory is stored 15 in a memory metadata database, wherein the metadata is based on the instructions and is stored during the generation of the executable file and / or during the execution of the fuzz test. In this way, metadata can be generated from the allocated and released memory of all different versions of the program code and stored in the memory metadata database. This enables the investigation and comparison of memory behavior across different versions of the program code.

[0066] Next, if no memory performance degradation or other errors are found, the program code is output 16. Provision may be made that an abnormal termination of the method is triggered during or after the execution of the fuzz test if the memory performance is worse than an older entry from the memory metadata database.

[0067] Optionally, static testing can be performed in parallel with fuzz testing or execution in a memory cleaner. Static testing or checking can include, for example:

[0068] -Contracts are either specified or extracted from the system environment.

[0069] - In the case of Rust, static checking can also be provided by the compiler, and in other languages ​​it can also be provided by linters, etc.

[0070] - Bounded model checking and / or abstract interpretation, implemented in commercial tools such as Astrée or open source tools such as CBMC.

[0071] - Automatically build a bounded model checking setup that statically compares the target program code with a given contract.

[0072] - Automatically build an Abstract Interpretation Setup that statically compares the target program code with a given contract.

[0073] - Automatically build a bounded model checking setup that checks the functional equivalence of source and target program codes.

[0074] According to one embodiment, the method further comprises: the program code or a portion of the program code is updated using memory performance, runtime information, behavior of the program code and / or output of the program code, and wherein the updated program code is optionally returned as input to a language model.

[0075] As an alternative to the described translation, a reconstruction of the program code can be provided. The reconstruction of the program code can include: changing the program code. The reconstructed program code can also be the code of the software, in particular the source code of the software.

[0076] Figure 2 A computer system 20 is schematically shown in which the disclosed technique for improving memory allocation of code generated by means of a language model can be used. The computer system 20 is designed to: execute Figure 1 Method 10 and follow Figure 5 The computer system 20 may be implemented in hardware and / or software. Figure 2 The system shown in can be viewed as a computer program designed to: execute the Figure 1 Method 10 and follow Figure 5Method 50.

[0077] Source program code 21 in a source language such as C is provided to a language model 22 such as a large oracle model (LLM) for translation into a target language such as Rust. The language model 22 generates (target) program code 23 as a translation of the source program code 21. This area of ​​the computer system 20 may be referred to as a generation area.

[0078] The language model is, for example, a large language model (LLM) into which data (such as program code here) and questions (such as translation or reconstruction requests here) are input via an input (prompt).

[0079] Another input 24 to the system 20 is a test, and optionally a test harness in the source language. Alternatively or optionally, the test and / or test harness may exist in the target language. These inputs are fed to the test harness 25. The test harness 25 records the function or test in the target language.

[0080] Optionally, static tests, quality assessments and / or contracts 26 can be fed to a static testing unit 27 , where they are managed for a later check of program code 23 .

[0081] The input end of the memory cleaning program 28 with fuzzer is connected to the language model 22 for inputting the program code 23, and is connected to the test harness 25 for inputting the test routine. In the memory cleaning program 28, the program code 23 is tested based on the test harness 25 having the source program code 21. Figure 3 , describes the memory cleaner 28 and its functions in more detail.

[0082] The generation of program code 23 by language model 22 can be repeated under changed conditions, such as changes in one or more hyperparameters (such as a temperature parameter of the language model), transformations in the source program code, and / or changes in the input to the language model, such as changes in tasks or prompts. Variables in the code can also be renamed.

[0083] By these measures, a difference is produced. This difference allows verification of the generated translation and an improved quality assessment, and also allows training of the language model with the aid of feedback. Within the framework of the improved quality assessment, it can be ascertained which of the generated program codes 23 is more or less suitable. The fuzzifier 28 then works with these variants of the program code 23.

[0084] The input of the checking unit 29 is connected to the language model 22 for inputting the program code 23 and to the static testing unit 27 for inputting the static tests, quality assessments and / or contracts 26. In the checking unit 29, the program code 21 is checked by means of the static tests, quality assessments and / or contracts 26.

[0085] If the check in the memory cleaning program 28 and in the check unit 29 is completed successfully, a status message 30 is output: the program code 23 is normal. This area of ​​the computer system 20 can be referred to as a check area.

[0086] The quality of the target program code 31 may be evaluated based on metrics 32. These metrics 32 may include code quality metrics, test quality metrics, and / or test quantity. When the evaluation is successful, the program code and its quality or quality are output as output 33. This area of ​​the computer system 20 may be referred to as a quality evaluation area.

[0087] Based on the evaluation, the quality can be calculated. If multiple target program codes have been generated, the solutions can be provided to the user in order of quality.

[0088] The program code may be evaluated, for example, based on code quality metrics such as source code length, loop count and / or branch depth, test quality metrics such as coverage (branch coverage) and / or the number of available or executed tests.

[0089] Figure 3 The memory cleaning program 28 is shown in detail, as well as the test harness 25 and program code 23 as inputs to the memory cleaning program 28 .

[0090] In order to check and monitor memory performance, the memory cleaner 28 comprises the following parts. The (optional) corpus 40 is filled with initial test cases from the code repository (which is translated or refactored) and / or from the provided tests and test harnesses. To this end, the corpus 40 is connected to the test harness 25.

[0091] A compiling and testing unit 41 is provided in order to generate an executable file 43 from the program code 23. To this end, the unit 41 receives the program code 23 as input and is connected to the test harness 25 for compiling and testing.

[0092] A fuzzer 42 is provided to generate inputs and inject these inputs into the executable 43. For these inputs, the fuzzer 42 is connected with the corpus 40 and / or the test harness 25.

[0093] A memory metadata database 44 is provided to store metadata. The memory metadata database 44 is generated or initially populated using information from the compilation and detection unit 41. During runtime, the memory metadata database 44 is populated with runtime information from the allocated and released memory of the executable file 43. To this end, the memory metadata database 44 is connected to the compilation and detection unit 41 and the executable file 43. In the memory metadata database 44, metadata from the allocated and released memory of all different versions of the executable file 43 can be stored so that memory behavior across different versions can be considered.

[0094] The monitoring unit 45 measures or monitors memory performance, and optionally measures or monitors runtime information, the behavior and / or output of executable files. Here, the coverage of the code can be monitored during runtime, usually in a grey box setting. This can then be stored in the monitoring unit 45. All of this is handed back to the fuzzer 42 to generate better test cases. Additionally, the monitoring unit 45 is connected to a memory metadata database 44 to obtain information about memory metadata and include this information in the monitoring. This can, for example, include comparisons of memory data such as memory performance, memory usage, etc.

[0095] Figure 4 A computer system 20 is schematically shown in which the disclosed technique for improving memory allocation may be used. The computer system 20 may correspond to Figure 2 The computer system 20 in the embodiment of the present invention is designed to: execute the Figure 1 Method 10 and follow Figure 5 Method 50, in particular, from Figure 3 The computer system 20 is designed to: execute Figure 5 The computer system 20 may be implemented in hardware and / or software. Figure 3 The system shown in can be viewed as a computer program designed to: execute the Figure 1 Method 10 and follow Figure 5 Method 50.

[0096] exist Figure 4 2 shows the error handling mechanism of the computer system 20. If the program code 31 cannot be generated without errors, this will lead to an error in the memory cleaning program 28. Correspondingly, a message 34 is output for reducing the confidence in the translation. In addition, the error and the associated program code 31 are registered in the error module 35.

[0097] From the error module 35, the best program code to date, which still contains errors, is returned as information 36 to the language model 22 in order to generate a better target program code which is ideally error-free. This reduces reliability and is taken into account in the quality determination.

[0098] Optionally, this may not only concern errors in the inspection region, but similarly may also concern errors in the quality assessment region.

[0099] Figure 5 is a flow chart illustrating a method 50 for training a language model. The language model is set up for automatic generation of program code.

[0100] In summary, the code generated by the language model is fed back to the language model as feedback to generate a new generation of source code. The idea is that the already good (or better) code can then be fine-tuned with respect to monitoring and behavioral output using the updated command prompt containing the new code. For example, if the already good code only has runtime problems in certain places, these places can be fed back into the language model.

[0101] In the first step of the method, source program code or source code is input 51 into a language model and program code is generated. The language model may have been pre-trained and, if necessary, fine-tuned. Alternatively, it is also possible to start with a new, untrained language model. Here, the training is based on reinforcement learning. The training is performed in a training environment, for example, using PPO (Proximal Policy Optimization).

[0102] In addition, by virtue of the Figure 1 The described method 10 improves 52 the program code predicting the target program code.

[0103] Next, a reward is generated 53 for the language model, wherein the reward is based on monitoring 14 memory performance and optionally monitoring runtime information, behavior and / or output of the executable 43 and / or these metadata. Thus, a low score may be made when memory performance is low and / or when a large amount of memory is occupied or a small amount of memory is freed. A high score may be made when memory performance is high and / or when a small amount of memory is occupied or a large amount of memory is freed.

[0104] Finally, using the value of the reward, the weights of the language model are updated 54. The result of this method is a language model that is better trained on new unlabeled data (here, for example, C code from an engine control), ie, provides more reliable translations.

[0105] According to one embodiment, the method further comprises: approximating the reward by performing only a subset of the tests checked automatically. This allows for a speed-up of the training.

Claims

1. A method (10) for improving memory allocation of code generated with the aid of a language model (22), the method comprising the following steps: - providing (11) a program code (23), said program code being generated with the aid of a language model (22); When a new version of the program code (23) becomes available, - generating (12) an executable file (43) by means of compilation and detection through a memory cleaning program (28), wherein: The memory cleaning program (28) inserts instructions into the executable file (43) during the generation (12); - performing (13) fuzz testing via a fuzzer (42), wherein the fuzzer (42) injects input into the executable file (43); - monitoring (14) memory performance, and optionally runtime information, behavior and / or output of said executable file (43); - storing (15) metadata generated from the allocated and freed memory in a memory metadata database (44), wherein the metadata is based on the instructions and is stored during generation (12) of the executable file (43) and / or during execution (13) of fuzz testing; - If the fuzz testing has not found the memory performance degradation or other errors, output (16) the program code (23).

2. The method (10) according to claim 1, wherein: The instructions are inserted into an intermediate representation of the executable file (43).

3. The method (10) according to claim 1 or 2, wherein: A corpus (40) is provided with input to the fuzzer (42), the corpus containing initial test cases from a code repository of the program code (23) and / or from provided tests and test harnesses.

4. The method (10) according to any one of claims 1 to 3, wherein: If the memory performance is worse than an older entry from the memory metadata database (44), an abnormal termination of the method is triggered during or after performing (13) the fuzz test.

5. The method (10) according to any one of claims 1 to 4, wherein: For the monitoring (14), the executable file (43) subjected to the fuzz testing and the memory metadata database (44) are monitored.

6. The method (10) according to any one of claims 1 to 5, wherein: Memory performance, runtime information, behavior of the executable file (43) and / or output of the executable file (43) are returned to the fuzzer (42).

7. The method (10) according to any one of claims 1 to 6, wherein: The program code (23) or a portion of the program code (23) is updated using memory performance, runtime information, behavior of the program code (23) and / or output of the program code (23), and wherein the updated program code is optionally returned as input to the language model (22).

8. A method (50) for training a language model (22) set up for automatically generating program code (23, 31), the method comprising the following steps: - Inputting source code (51) into a language model (22) and generating program code (23); - improving (52) the program code (23) by means of a method (10) according to any one of claims 1 to 7; - generating (53) a reward for the language model (22), wherein The reward is based on monitoring (14) memory performance and optionally monitoring runtime information, behavior and / or output of the executable file (43) and / or the metadata; - Using the value of the reward, updating (54) the weights of the language model.

9. The method (50) according to claim 8, wherein: The reward is approximated by performing only verification.

10. A computer system (20) designed to execute the method (10; 50) according to any one of claims 1 to 9.

11. A computer program configured to carry out the method (10; 50) according to any one of claims 1 to 9.

12. A computer readable medium or signal storing and / or containing a computer program according to claim 11.

Images