Supports blockchain collections in databases

Abstract

This document describes a high-throughput technique for incorporating cryptographic blockchains into relational data. In one embodiment, a computer indicates in a database dictionary within a database that a relational table is used for blockchain storage. The relational table includes one or more application columns. In response to the indication, the relational table is associated with one or more system columns that are not modifiable by administrators or clients of the database. The one or more system columns include a cryptographic hash column. A request is received from a client to store a specific value in a specific application column. In response to receiving the request, a cryptographic hash value is calculated for a new row in the relational table. In the relational table, the computer stores the new row, which includes: the specific value in the specific application column and the cryptographic hash value in the cryptographic hash column.

Description

Technical Field

[0001] The present invention relates to database data integrity and is a high-throughput technique for incorporating cryptographic blockchains into relational data. Background Art

[0002] Blockchain uses cryptography to guarantee the integrity of persistent transactions. Transaction integrity requires features such as non-repudiation and tamper-evidence.

[0003] In one approach, decentralized blockchains like Hyperledger Fabric use cryptographic hashing to link blocks together to form a tamper-proof chain when there are multiple untrusted writers and no single point of trust. Due to the distributed nature of decentralized solutions, transaction throughput and transaction latency are affected.

[0004] Another approach involves database systems that provide a cryptographically verifiable transaction log owned by a central trusted authority. This approach has several drawbacks. The transaction log is automatically maintained as a side effect of database changes and is not a first-class object that can be used as a ledger by applications. Furthermore, the transaction log has only a single chain that can be disputed, which can limit throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the attached figure:

[0006] Figure 1 is a block diagram depicting an example database management system (DBMS) that renders relational tables tamper resistant and tamper evident based on blockchain(s);

[0007] Figure 2 is a flow chart depicting an example of appending a new cryptographic block to a blockchain;

[0008] Figure 3 is a block diagram depicting an example DBMS that flexibly integrates blockchain across multiple tables and / or multiple database instances;

[0009] Figure 4 is a block diagram illustrating a computer system upon which embodiments of the present invention may be implemented;

[0010] Figure 5 is a block diagram illustrating a basic software system that may be used to control the operation of a computing system. DETAILED DESCRIPTION

[0011] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the present invention can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessary obfuscation of the present invention.

[0012] General Overview

[0013] Using cryptographic hashing to link rows in append-only tables with optional digital signatures brings some of the advantages of blockchain to centralized databases at a modest cost. This approach works with a variety of data models, including relational, columnar, key-value, and document.

[0014] If the database provider is at least partially trustworthy, blockchain technology can be used to instill a higher level of trust and support multiple writers who do not trust each other. This paper presents a variation of the approach we call Database Blockchain Aggregate. Database Blockchain Aggregate introduces the following features:

[0015] 1. Use blockchain technology in the database for first-level collections declared as append-only.

[0016] Depending on the data model, a collection can be a relational table, a key-value collection, a document collection, etc.

[0017] 2. Support multiple chains within such collections to achieve scalability within and across database instances.

[0018] 3. Declaratively support row retention in such collections.

[0019] 4. Support collection lifecycle in a declarative way.

[0020] 5. Support verification of chains in such collections.

[0021] In an embodiment, a computer indicates in a database dictionary within a database that a relational table is used for blockchain storage. The relational table includes one or more application columns. In response to the indication, the relational table is associated with one or more system columns that are unmodifiable by administrators and clients of the database. The one or more system columns include a cryptographic hash column. A request is received from a client to store a specific value in a specific application column. In response to the request, a cryptographic hash value is calculated for a new row in the relational table. In the relational table, the computer stores the new row, which includes: the specific value in the specific application column and the cryptographic hash value in the cryptographic hash column.

[0022] 1.0 Sample Database Management System

[0023] Figure 11 is a block diagram illustrating an example database management system (DBMS) 100 in an embodiment. DBMS 100 makes relational tables 120 tamper-resistant and tamper-proof based on (one or more) blockchains. DBMS 100 includes and is hosted by at least one computer, which may be a rack server (such as a blade), a personal computer, a mainframe, a virtual computer, or other computing device.

[0024] The DBMS 100, such as a relational DBMS (RDBMS), includes at least one database, such as 110. In an embodiment and according to a schema and / or database dictionary, the database 110 includes at least one relational table, such as 120, which may contain zero or more rows and at least one application column, such as 131-132. The database 110 and the relational table 120 are exemplary. Other embodiments may have a data repository different from the database 110, such as a graph database, a NoSQL database, a tuple repository such as a Resource Description Framework (RDF) triple store, a key-value store, or a document data repository such as for documents containing JavaScript Object Notation (JSON) or Extensible Markup Language (XML). For example, a columnar database may have column families instead of the relational table 120.

[0025] In an embodiment not shown, such as a key-value store, DBMS 100 may store application data separately as named (i.e., keyed) values, such as 151-153. In the illustrated embodiment, values ​​151-153 may be organized as data fields within a logical unit of data aggregation, such as a record. In the illustrated example, identical fields in multiple records may be logically organized into application columns, such as 131-132, such that all values ​​151-153 in the same column have the same data type, i.e., the data type of the column. For example, values ​​151-153 may be numbers.

[0026] In the illustrated embodiment, the various semantic objects are stored in the relational table 120 as one or more table rows as follows: In the illustrated embodiment, the relational table 120 operates more or less as a versioned table with a self-contained auditable history as follows.

[0027] The relationship table 120 stores logical records. For each record, the relationship table 120 stores the current and past versions as table rows. In the illustrated embodiment, the relationship table 120 links all versions of the same record into corresponding blockchains of linked cryptographic blocks. In the illustrated embodiment, each version of the same record has a separate block in the blockchain.

[0028] In the illustrated embodiment, there is a one-to-one correspondence between blockchains and logical records. In the illustrated embodiment, there is a one-to-one correspondence between blocks and record versions. In the illustrated embodiment, there is a one-to-one correspondence between record versions and rows of the relationship table 120.

[0029] As discussed later in this article, this one-to-one correspondence of such logical objects may not exist in other embodiments. For example, a block may correspond to a transaction, client, or session of a database as discussed later in this article.

[0030] In this example, blockchains and logical records may be more or less synonymous and may share identifiers, such as identifiers 171-172 in record identifier column 142. Likewise, blocks, record versions, and table rows may be more or less synonymous and may share identifiers, such as an identifier (such as AB) in version column 143.

[0031] In this example, columns 142-143 may operate together as a candidate key to uniquely identify a row of relational table 120. Each logical record has its own version sequence, so that multiple rows shown as version A may be the first version of unrelated corresponding logical records 171-172.

[0032] In an embodiment, DBMS 100 can cooperate with (one or more) client applications that use application columns 131-132 to store and retrieve fields of application records. In various embodiments, DBMS 100 can provide additional features such as atomic, consistent, isolated, and durable (ACID) transactions, data persistence, data manipulation languages ​​(DML) such as for queries, data definition languages ​​(DDL) such as for schema evolution, and / or data control languages ​​(DCL) for access authorization. For example, DML can provide create, read, update, and delete (CRUD) operations for ad hoc access and / or batch processing.

[0033] In operation, a client may send a write request 180 to DBMS 100. For example, write request 180 may be an update statement in the form of a DML statement, such as an SQL update statement. Relational table 120 has a special behavior that occurs when an attempt is made to modify an existing row (such as row A shown), such as through write request 180. When an attempt is made to modify an existing row A of record 171, the existing row A is retained without modification, and a new row B is appended to relational table 120 of record 171. For example, write request 180 specifies a value of 153, and new row B contains this specified value in application column 131. However, the old row A of record 171 still retains the value 151 in application column 131.

[0034] Clients cannot modify system columns 141-143, which contain row metadata. For example, row identifier column 143 identifies row AB as a separate physical row. However, record identifier column 142 indicates that row AB is a different version of the same logical record 171. Therefore, relational table 120 can store the versioning history of record 171 and similarly structured records. Therefore, relational table 120 is a versioned table, and record 171 is a versioned record.

[0035] Cryptographic hash column 141 stores, in each row, a value calculated by applying a cryptographic hash function to the row. The cryptographic hash value may be based on some or all fields of the row. Therefore, the cryptographic hash value depends on the content of the row. If the content is later modified, such as accidentally or intentionally, applying the same cryptographic hash function to the modified row will calculate a different hash value. A row can be audited by detecting a mismatch between the currently recalculated hash value and the hash value stored in the row, in which case the row is incomplete. Thus, relational table 120 can be somewhat tamper-proof.

[0036] For multiple rows AB that are versions of the same record 171, multiple corresponding values ​​in cryptographic hash column 141 of rows AB of record 171 may be mathematically related. For example, the cryptographic hash function may be sensitive not only to the current row, but also to one or more older rows of the same record. For example, the cryptographic hash function may also be based on cryptographic hash values ​​of previous versions of the record. For example, cryptographic hash value 163 may be based on cryptographic hash value 161.

[0037] Thus, many versioned rows of the same record may be mathematically daisy-chained into a tamper-proof blockchain. For example, versioned rows of the same record may be sorted by age and / or version column 143, and each hash value may be verified based on the hash value(s) of the previous row(s). Thus, multiple rows of the same record may form a blockchain.

[0038] The value in the cryptographic hash column is protected from being updated, and DBMS 100 should prohibit such updates. If the security mechanism of DBMS 100 is bypassed and the hash value in cryptographic hash column 141 is replaced, such that a row of hidden record 171 has been tampered with, then cryptographic hash value 161 will be displayed as invalid and / or cryptographic hash value 163 of the logical next row of the record will be displayed as invalid. Therefore, the blockchain of table rows of database records is tamper-proof.

[0039] In embodiments, the physical ordering of rows on disk for the same record need not reflect the logical ordering of those rows as versions of the record. For example, compaction of the relational table 120 may require physical reordering of rows, which does not disrupt the blockchain(s) for those rows. For example, a physical row identifier (such as a DBMS native ROWID) not stored in the version column 143 may change for the same row, such as when the row is relocated.

[0040] In an embodiment, older rows of the same logical record may be read, such as when a query specifies a row identifier (such as AB). In an embodiment, and by default, when no historical rows are explicitly requested, the scope of the query is implicitly limited to rows that are the latest version of the record. In an embodiment, the visibility of older rows of a record depends on the database access permissions granted to the user. For example, only the latest version of a record may be exposed to some users.

[0041] 2.0 Example Transaction

[0042] Figure 2 is a flow chart depicting an example of appending a new cryptographic block to a blockchain in an embodiment. Figure 1 discuss Figure 2 .

[0043] Steps 201-202 are preliminary steps for configuring DBMS 100 for blockchain. In the database dictionary within the database, step 201 indicates that relational table 120 is used for blockchain storage. For example, DBMS 100 may receive a data definition language (DDL) statement that: a) creates a new relational table 120 for blockchain storage, or b) modifies an existing relational table 120 for blockchain storage.

[0044] When the relationship table 120 is new, steps 201-202 are combined. Otherwise, in response to step 201, step 202 occurs. Step 202 associates the relationship table 120 with at least one system column that is not modifiable by either the administrator or the client. For example, Figure 1 The system columns shown in are added to the definition of the relational table 120 in the database dictionary.

[0045] When the relational table 120 is not new and already contains rows, various embodiments may: a) automatically calculate and store values ​​in new system columns (including cryptographic hash column 141); for example, version column 143 may mark all rows as the first version A of a different new corresponding blockchain (such as 171-172), or b) leave the new system columns uninitialized, such as storing nulls. In an embodiment, the database dictionary itself is implemented by the relational table(s) storing the blockchain, so that the database dictionary itself is versioned and / or tamper-resistant.

[0046] Steps 203-205 occur sequentially during real-time operations such as for a transaction. From the client, step 203 receives a request to store the value 153 in the application column 131. For example, the request may arrive as a SQL DML or other CRUD write request.

[0047] When the request arrives, version A is the only version of the blockchain and logical record, with identifier 171. Processing the request will leave the row of the relationship table 120 intact. Step 204 calculates the cryptographic hash value 163 for the new row of the relationship table 120, which is shown as version B, but the new row has not yet been appended to the relationship table 120.

[0048] Step 204 calls the cryptographic hash function and provides arguments such as: a) the new row that has not yet been appended, b) some or all application column values ​​of the new row, and / or c) some or all system column values ​​of the new row and / or the previous row with version A for the same logical record. At a minimum, the cryptographic hash function should be provided with all the inputs necessary to compute the cryptographic hash value 163 as a cryptographic link between the encrypted blocks AB in the blockchain 171.

[0049] In relational table 120, step 205 stores the new row as shown. The new row becomes the latest version of the logical record that clients can observe. With each subsequent change, blockchain 171 can grow with additional cryptographic blocks, and relational table 120 can grow with additional rows.

[0050] 3.0 Example Table Lifecycle

[0051] Table 1 below lists example lifecycle scenarios 601, 604, 608, and 612 in an example lifecycle of a tamper-proof relationship table. Embodiments of DBMS 100 may implement some or all of these lifecycle scenarios. Each lifecycle scenario includes at least one processing step, as shown in Table 1. The steps in the same lifecycle scenario may occur in the order listed. For example, step 602 may occur before step 603. Figure 1 Discussion Table 1.

[0052]

[0053] In the life cycle scenario 601, the latest version of the logical record is used as follows. From the client, step 602 receives a request to retrieve the content of the record 171 that already has version AB, such as Figure 1 For example, a query might ask what value is stored in the application column 131 of record 171.

[0054] In step 603, the value 153 is returned to answer the query because only the latest version B of record 171 is used as the data source. Older versions A are not considered unless older data is explicitly requested. In an embodiment, the cryptographic hash value 163 is verified whenever version B is accessed, which may or may not require verification of the cryptographic hash value 161 of the previous version A. In an embodiment, the blockchain 171 is verified whenever any version in the blockchain 171 is accessed, which requires verification of all cryptographic hash values ​​in the blockchain 171.

[0055] Lifecycle scenario 604 requires deleting a logical record as follows. From the client, step 605 receives a request to delete a record 171, such as using a SQL DML statement or other CRUD request. Based on the cryptographic hash value of the current version of the record, step 606 calculates a new cryptographic hash value for marking the record as deleted.

[0056] Lifecycle scenario 604 does not delete any rows of records. In the record's relationship table, step 607 appends a new row containing: an indication that the record was deleted, and a new cryptographic hash value in the cryptographic hash column of the relationship table. Embodiments may or may not allow some or all users to detect and / or review old rows of deleted records.

[0057] Lifecycle scenario 608 maintains a separate blockchain table. As discussed earlier in this document, a relational table can store a blockchain when the relational table contains relevant system columns. In some cases, adding these system columns to the (e.g., traditional) table may not be feasible or desirable.

[0058] Lifecycle scenario 608 provides an alternative that instead requires the creation of a separate blockchain table that provides blockchain storage for the regular table(s) during step 609. Instead of adding system columns to the regular table(s), system columns are created using the blockchain table or added to the blockchain table. In other words, blockchain support can be retrofitted onto traditional tables without changing their schema or content. Reads and writes occur as described previously herein, with the difference that access to application and system columns requires separate tables. For example, a cryptographic hash function may require values ​​from both the regular table and the blockchain table. In embodiments, two regular tables can share a blockchain table.

[0059] In an embodiment, step 610 deletes a blockchain table when it has not been accessed for a threshold duration. For example, when only the current or most recent year or years of regulatory compliance need to be audited, but data mining requires many years, then the blockchain table dedicated to the older years may eventually be discarded. For example, each year can have its own separate blockchain table, whether common records have a single multi-year table or a separate common table for each year.

[0060] Depending on the embodiment, lifecycle scenario 612 expires old table rows that may or may not include the latest version of the record. Step 611 deletes one or more rows of a horizontal data partition of a relational table when the duration since the relevant event exceeds a threshold. The relevant event can be row or partition dependent and can be the creation or access of a row or partition.

[0061] As explained, scenarios 608 and 612 require fine-grained deletion of data, such that some or all version rows of a logical record and some or all version blocks of the blockchain may be deleted. In other words, the relationship table may contain a truncated blockchain, or when the relationship table is associated with a discarded blockchain table, the record may have no blockchain at all.

[0062] In this case, blockchain verification only requires the preserved blocks of the truncated blockchain. Similarly, the oldest preserved blocks in the truncated blockchain may be exempt from verification. In an embodiment, the cryptographic hash value of the most recent deleted block of the truncated blockchain is retained, even though the deleted block may no longer exist, as discussed later in this document. Thus, even the oldest preserved blocks in the truncated blockchain are verifiable.

[0063] 4.0 Example Patterns and Topologies

[0064] Figure 3 1 is a block diagram illustrating an example database management system (DBMS) 300 in an embodiment. DBMS 300 flexibly integrates blockchains across multiple tables and / or multiple database instances. DBMS 300 may be an implementation of DBMS 100.

[0065] Only the system columns are shown, but not all are. For example, the password hash column is not shown. Record identifier columns 343A-B and 346 store identifiers for logical records. For example, according to columns 342A and 343A, record X has two versions 0-1.

[0066] As explained previously, blockchains can contain different versions of the same record in the same relational table. In this case, each row is more or less a self-contained link or block in the blockchain. For example, and based on chain identifier column 341A, blockchain C contains two versions 0-1 of the same record X.

[0067] As also explained earlier in this document, a relational table may contain multiple blockchains with disjoint record sets and disjoint row sets. For example, in relational table 331A, only record Y is in blockchain D, and none of the rows for record X are in blockchain D because they are in blockchain C.

[0068] In embodiments, multiple records may appear in the same version of a block on the same blockchain. For example, each blockchain may represent a purchase order that may have multiple line item records. In embodiments, each blockchain is versioned, and the blockchain and its multiple records share the same version.

[0069] For example, in relational table 331A, blockchain C has two versions 0-1. Version 0 of blockchain C contains two records W and X. Version 1 of blockchain C contains only record X. For example, a data manipulation language (DML) transaction, such as one used in structured query language (SQL), can delete record W and / or modify record X from blockchain C.

[0070] Relationship tables 331A and 332 can be schematically related in various ways. In the master-detail model example, relationship tables 331A and 332 are the master table and detail table, respectively. In the multidimensional database example, relationship tables 331A and 332 are the fact table and dimension table, respectively. In the online analytical processing (OLAP) example, relationship tables 331A and 332 are part of a star or snowflake pattern.

[0071] Blocks of a blockchain can span multiple relational tables. For example, version 0 of blockchain D contains records T and Y in corresponding relational tables 331A and 332, which can be the master and detail tables, respectively. Each of relational tables 331A and 332 can contain a full complement of system columns, including a cryptographic hash column.

[0072] In embodiments, some relational tables can indirectly participate in the blockchain and lack these system columns. For example, a table with such system columns and another table without such system columns can be linked via a foreign key in either table. As long as a cryptographic hash function is applied to the contents of corresponding rows in both tables, both rows can be protected as tamper-proof blocks of the blockchain. For example, a fact table can have such system columns, but a dimension table whose rows can be shared by separate fact rows in separate blockchains, whether for the same or different fact tables, would not have such system columns.

[0073] In one embodiment, relational tables 331A and 332 may be horizontal partitions of the same logical table, such as time or alphabetical partitions. For example, relational table 331A may be used for transactions in January, and relational table 332 may be used for transactions in February. For example, record X and blockchain C have version 2 in February, as shown. Thus, different blocks of the same blockchain and / or different versions of the same record and the same blockchain may reside in different relational tables.

[0074] The DBMS 300 is hosted by computers 311-312 interconnected by a communication network. Each of the computers 311-312 hosts a corresponding database instance, such as 321-322, which may have the same or different relational schemas. For example, the relational tables 331A-B may have the same or different definitions. For example, the relational tables 331A-B may be shards of the same logical table, such as: a) time sharding, b) content-based sharding, such as alphabetical sharding, c) hash-based sharding that operates as a hash bin, and / or d) load-balanced sharding that inserts rows with stickiness by row or by logical record (such as round-robin, least busy, or least idle storage).

[0075] Depending on the embodiment, stickiness can mean that data is always stored in the same relational table and / or the same database instance when used for: a) a specific row, b) any version of the same logical record, or c) any record in the same block of the same blockchain. Depending on the embodiment, some related data can also be distributed. For example, version 0 of blockchain E contains records S and Z, which are stored in separate relational tables in separate database instances.

[0076] Time or other sharding sets can store different versions of the same record in different database instances. For example, record V and version 0-1 of blockchain F are stored in separate database instances.

[0077] 5.0 Example Transaction Processing

[0078] Table 2 below lists example transaction concerns 621 and 624 in an example transaction. Embodiments of DBMS 300 may implement some or all of these transaction scenarios. Each transaction scenario includes multiple processing activities, as shown in Table 2. Activities 625-627 in transaction scenario 624 may occur in the order listed. For example, activity 625 may occur before activity 626. Activities 622-623 in transaction scenario 621 may occur in any order or concurrently. Figure 3 Discussion Table 2.

[0079] Transactional concerns meaning Activity 621 Block distribution 622-623 624 Transaction integrity 625-627

[0080] To increase data locality, reduce peer database server network traffic, increase throughput, and reduce latency, the entire blockchain with all its blocks can be pinned to a single table, data partition, and / or database instance. This is shown as activity 623. Activities 622-623 are alternative activities to transaction concern 621 for block distribution, which can impact performance. Without stickiness, different blocks of the same blockchain can be distributed across multiple tables, data partitions, and / or database instances using activity 622.

[0081] Transactional integrity is a transactional concern 624. Simultaneous data mutations by multiple clients could accidentally corrupt any of the following: fields in a table row and / or block passwords. In some cases, row locks may be sufficient, such as for consistent reads. DBMS 300 can support ACID transactions, as explained earlier in this document. Depending on the embodiment, the following transactional aspects may or may not be based on the ACID mechanisms of DBMS 300.

[0082] When modifying an application column value requires appending a new table row, such modification can be treated as a concurrent and / or locked table row insert. In embodiments, row inserts do not require locking because DBMS 300 implicitly serializes concurrent inserts. In embodiments, locking may not be required even when a new block of the blockchain has multiple records in the same or different tables.

[0083] In embodiments, a mutex, semaphore, or critical section is required for additional serialization, particularly for cryptography. For example, two concurrent writers of the same logical record should not link using the same encryption block as their respective previous blocks.

[0084] Multiple blockchains may be semantically related, such as when multiple logical records of the same or different relational tables are semantically related. For example, a money transfer may mean that two bank accounts are operationally related, even if they are not schematically related. Money credited to one account should be debited from another account in an atomic, all-or-nothing manner, such that each can succeed only if both the credit and debit are successful.

[0085] For example, when each bank account has its own unique blockchain, a money transfer should automatically update both blockchains, which may or may not be technically challenging when the bank database has only one writer. However, while a bank account is participating in that money transfer, concurrent writers might attempt to write to the account's blockchain for other financial transactions at the same time. Concurrent writers could unexpectedly interfere with each other, especially if one writer performs a transaction rollback.

[0086] For example, a writer should not use an encrypted block as a previous block for chaining when another writer undoes the insertion of (one or more) table rows of that block during a rollback. Therefore, a transaction may need to lock multiple participating blockchains, which is an example of locking multiple resources, which is prone to deadlock.

[0087] For example, two writers I-II might compete for two blockchains III-IV. If writer I locks blockchain III, and writer II simultaneously locks blockchain IV, a deadlock occurs because neither writer can proceed without acquiring the lock held by the other. The solution is for both writers to lock the blockchains with the same ordering, such as blockchain III before IV. This ordering is canonical because even if writers independently compute the ordering, the simultaneous writers always agree on it.

[0088] In an embodiment, the writer optimistically prepares the mutated data during the database transaction, but provides a pre-commit callback subroutine that, when called in step 625: a) cryptographically hashes the new block for the mutated data, b) computes the canonical ordering of the participating blockchains, such as explained below for step 626, c) locks the participating blockchains in the canonical ordering in step 627, d) persists the blockchain, and e) unlocks the blockchain.

[0089] In some embodiments, lock ordering is based on a static convention, such as blockchain age or an identifier. In some embodiments, lock ordering is dynamic. For example, in step 626, lock ordering is based on statistical information such as: a) the frequency of reads, writes, or both in the same period, or b) the recency of the last read, write, or both.

[0090] 6.0 Exemplary Embodiments

[0091] The following are exemplary embodiments that utilize various features of the examples presented earlier in this document. The requirements of these exemplary embodiments are not necessarily the same as those of the examples presented earlier in this document. In these exemplary embodiments, a relational table is configured for blockchain storage and the following operations.

[0092] Relational tables prohibit row updates and prohibit ad hoc row deletions. Aging may automatically delete rows, such as described earlier in this article.

[0093] System columns such as password columns can be hidden or invisible. The maximum number of blocks in a relational table can be configured by the database system or database administrator (DBA).

[0094] In embodiments, all rows inserted into the same or different relational tables by the same database transaction or the same database session can be automatically linked together into the same blockchain. In embodiments, each such row has its own corresponding blockchain block. In embodiments, some or all of these rows are part of the same block of the blockchain.

[0095] In an embodiment, a block of a blockchain and / or a row of a relationship table includes a cryptographic digital signature of a client. In an embodiment, the client digital signature is based on the contents of (one or more) application columns rather than system columns.

[0096] In an embodiment, blocks of a blockchain and / or rows of a relational table include a cryptographic digital signature of a DBMS. In an embodiment, the DBMS digital signature is based on the contents of application column(s) and system column(s). In an embodiment, storing the cryptographic signature of a set of newly added blocks and / or newly added rows of a relational table for a blockchain may be delayed for a limited duration, such as until a threshold number of rows or blocks are added or until a periodic interval timer expires.

[0097] In embodiments, verification of cryptographic hash values ​​in one or more blocks of a blockchain can be accomplished by calling a database application programming interface (API). In embodiments, such verification can be performed entirely by the database client after retrieving the hash value and without calling the DBMS. In embodiments, such client-side verification requires the public keys of multiple corresponding digital signers. In embodiments, multiple hash values ​​of the same blockchain can be verified in parallel.

[0098] In an embodiment, cryptographic hash values ​​of (one or more) blocks (particularly deleted blocks) of a blockchain and / or (one or more) rows of a relational table (particularly deleted rows), as well as information such as identifying the blockchain and / or block (such as the location of the block within the blockchain), and / or digital signatures within the blockchain, block, or table row, can be periodically copied to an external database. This information can be stored in another database, a file system, a website, a decentralized blockchain, etc. This copied information can be used to: a) detect the removal of records from the blockchain or modifications to the blockchain, and / or b) more or less verify a truncated blockchain, such as due to aging of (one or more) older blocks.

[0099] In an embodiment, the CREATE TABLE DDL SQL statement is extended to support blockchain-specific information. The following is an example syntax for creating a blockchain-ready table called "bank_ledger" in a relational database:

[0100] CREATE BLOCKCHAIN ​​TABLE bank_ledger(bank VARCHAR2(128),EOD_depositNUMBER)

[0101] NO DROP UNTIL 31 DAYS IDLE

[0102] NO DELETE UNTIL 365 DAYS AFTER INSERT

[0103] HASHING USING"sha2_512"AND DATAFORMAT"v1"

[0104] The BLOCKCHAIN ​​keyword specifies that the table being created should include blockchain support. The NO DROP clause controls when a table can be dropped. The NO DELETE clause controls when each row can be deleted individually, based on the time period that may affect future and / or existing table rows. The HASHING clause specifies the cryptographic hash function to use. The DATA FORMAT clause specifies the data layout for input to the hash function.

[0105] Extensions to the ALTER TABLE DDL SQL statement can modify blockchain-specific information. Locking a table for blockchain support uses the LOCKED keyword in CREATE BLOCKCHAIN ​​TABLE or ALTER TABLE, which prevents subsequent ALTER TABLE statements from removing blockchain support.

[0106] In an embodiment, the prepare-commit phase of a database transaction includes adding a transaction control (TC) block to a blockchain or log record containing the blockchain. In an embodiment, participating DBMSs should not enter the prepare state of a distributed transaction, such as a transaction-aware (XA) transaction or other two-phase commit transaction, or confirm it before adding the TC block.

[0107] 7.0 Database Overview

[0108] Embodiments of the present invention are used in the context of a database management system (DBMS).Therefore, a description of an example DBMS is provided.

[0109] Generally speaking, a server, such as a database server, is a combination of integrated software components and an allocation of computing resources, such as memory, nodes, and processes on the nodes used to execute the integrated software components, where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of the server's clients. A database server controls and facilitates access to a specific database, processing client requests to access the database.

[0110] A user interacts with the database server of a DBMS by submitting commands to the database server that cause the database server to perform operations on the data stored in the database. A user can be one or more applications running on a client computer that interacts with the database server. Multiple users may also be collectively referred to as users in this article.

[0111] A database consists of data and a database dictionary, which is stored on a persistent storage mechanism such as a set of hard disks. A database is defined by its own separate database dictionary. The database dictionary includes metadata that defines the database objects contained within the database. In practice, the database dictionary defines the majority of the database. Database objects include tables, table columns, and tablespaces. A tablespace is a collection of one or more files used to store data for various types of database objects, such as tables. If the data for a database object is stored in a tablespace, the database dictionary maps the database object to the tablespace or tables that hold the data for the database object.

[0112] The database dictionary can include multiple data structures that store database metadata. For example, the database dictionary can include multiple files and tables. Portions of the data structures can be cached in the main memory of the database server.

[0113] When a database object is said to be defined by a database dictionary, the database dictionary contains metadata that defines the properties of the database object. For example, the metadata in the database dictionary that defines a database table might specify the column names and data types, as well as one or more files or portions thereof that store the data for the table. The metadata in the database dictionary that defines a procedure might specify the name of the procedure, its arguments, and the return and argument data types, and might include the source code and its compiled version.

[0114] The DBMS refers to the database dictionary to determine how to execute database commands submitted to the DBMS. Database commands can access database objects defined by the dictionary.

[0115] Database commands can be in the form of database statements. In order for a database server to process a database statement, the database statement must conform to a database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including proprietary forms of SQL supported by database servers such as Oracle (such as Oracle Database 11g). SQL data definition language ("DDL") instructions are issued to a database server to create or configure database objects, such as tables, views, or complex types. Data manipulation language ("DML") instructions are issued to a DBMS to manage data stored in a database structure. For example, SELECT, INSERT, UPDATE, and DELETE are examples of DML instructions common in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in an object-relational database.

[0116] A multi-node database management system consists of interconnected nodes that share access to the same database. Typically, the nodes are interconnected via a network and, to varying degrees, share access to shared storage, such as a set of disk drives and the data blocks stored thereon. The nodes in a multi-node database system can be in the form of a group of computers (such as workstations and / or personal computers) interconnected via a network. Alternatively, the nodes can be nodes of a grid consisting of nodes in the form of server blades interconnected with other server blades on a rack.

[0117] Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computing resources (such as memory, nodes, and processes on the nodes that execute the integrated software components on processors) that are dedicated to performing specific functions on behalf of one or more clients.

[0118] Resources from multiple nodes in a multi-node database system can be allocated to run the software for a particular database server. Each combination of software and allocation of resources among nodes is referred to herein as a "server instance" or "instance" of a server. A database server can include multiple database instances, some or all of which run on separate computers (including separate server blades).

[0119] 7.1 Query Processing

[0120] A query is an expression, command, or set of commands that, when executed, causes a server to perform one or more operations on a data set. A query may specify source data object(s), such as table(s), column(s), view(s), or snapshot(s), from which result set(s) are to be determined. For example, source data object(s) may appear in the FROM clause of a Structured Query Language ("SQL") query. SQL is a well-known example language for querying database objects. As used herein, the term "query" is used to refer to any form of representation of a query, including queries in the form of database statements and any data structure used for internal query representation. The term "table" refers to any source object that is referenced or defined by a query and that represents a collection of rows, such as a database table, view, or inline query block (such as an inline view or subquery).

[0121] Queries can perform operations on data from source data objects row by row as the object(s) are loaded, or on the entire source data object(s) after the object(s) have been loaded. The result sets generated by some operations can make other operations(s) available, and in this way, the result sets can be filtered out or narrowed based on certain criteria, and / or joined or combined with other result sets(s) and / or other source data objects(s).

[0122] A subquery is a portion or component of a query that is distinct from the other portion(s) or component(s) of the query and can be evaluated separately from the other portion(s) or component(s) of the query (i.e., as a separate query). The other portion(s) or component(s) of the query can form an outer query, which may or may not include other subqueries. A subquery nested within an outer query can be evaluated separately one or more times, while simultaneously computing a result for the outer query.

[0123] Generally speaking, a query parser receives a query statement and generates an internal query representation of the query statement. Typically, the internal query representation is a collection of interlinked data structures that represent various components and structures of the query statement.

[0124] The internal query representation can be in the form of a node graph, with each interconnected data structure corresponding to a node and a component of the represented query statement. The internal representation is typically generated in memory for evaluation, manipulation, and transformation.

[0125] 7.2 Database Transactions

[0126] Changes to a database in a DBMS are made using transactions. A database transaction is a set of operations that change database data. In a DBMS, a database transaction is initiated in response to one or more database statements that request one or more changes, such as DML statements that request to update, insert, or delete one or more table rows. Committing a transaction makes the transaction's changes permanent.

[0127] All data changes made by a transaction are made atomically. When a transaction is committed, either all changes are committed or the transaction is rolled back.

[0128] In a distributed transaction, multiple DBMSs use a two-phase commit method to commit the distributed transaction. Each DBMS executes a branch of the distributed transaction locally. One DBMS (the coordinating DBMS) can be responsible for coordinating the submission of the transaction on one or more other DBMSs. The other DBMSs are referred to as participating DBMSs in this article.

[0129] Two-phase commit involves two phases: prepare-commit and commit. During the prepare-commit phase, the corresponding branch transaction is prepared in each participating DBMS. While the branch transaction is preparing on the DBMS, the database is in a "prepared state," ensuring that modifications to database data performed as part of the branch transaction can be committed. This guarantee may require persistent storage of a record of the branch transaction's changes. The participating DBMSs confirm when they have completed the prepare-commit phase and entered the prepared state of their corresponding branch transaction.

[0130] Hardware Overview

[0131] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. Special-purpose computing devices can be hard-wired to perform these technologies, or can include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these technologies), or can include one or more general-purpose hardware processors that are programmed to perform these technologies according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, or FPGAs with custom programming to implement these technologies. Special-purpose computing devices can be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices that combine hard-wiring and / or program logic to implement these technologies.

[0132] For example, Figure 4 4 is a block diagram illustrating a computer system 400 on which embodiments of the present invention may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a hardware processor 404 coupled with bus 402 for processing information. Hardware processor 404 may be, for example, a general-purpose microprocessor.

[0133] Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 may also be used to store temporary variables or other intermediate information during the execution of instructions by processor 404. These instructions, when stored in a non-transitory storage medium accessible to processor 404, make computer system 400 a special-purpose machine customized to perform the operations specified in the instructions.

[0134] Computer system 400 also includes a read-only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk, optical disk, or solid-state drive, is provided and coupled to bus 402 for storing information and instructions.

[0135] The computer system 400 may be coupled to a display 412, such as a cathode ray tube (CRT), via bus 402 for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is a cursor control 416, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0136] Computer system 400 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic (which, in combination with a computer system, enables or programs computer system 400 to function as a special-purpose machine). According to one embodiment, computer system 400 performs the techniques described herein in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. These instructions may be read into main memory 406 from another storage medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0137] As used herein, the term "storage medium" refers to any non-transient medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 410. Volatile media include dynamic memory, such as main memory 406. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip, or a cassette tape.

[0138] Storage media are distinct from, but can be used in conjunction with, transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0139] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal, and appropriate circuitry may place the data on bus 402. Bus 402 transfers the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 before or after execution by processor 404.

[0140] Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides two-way data communication coupled to network link 420, wherein network link 420 is connected to local network 422. For example, communication interface 418 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, communication interface 418 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface 418 all sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0141] The network link 420 typically provides data communication to other data devices through one or more networks. For example, the network link 420 can provide a connection through a local network 422 to a host computer 424 or to data equipment operated by an Internet service provider (ISP) 426. The ISP 426, in turn, provides data communication services through a global packet data communication network, now commonly referred to as the "Internet" 428. Both the local network 422 and the Internet 428 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals passing through the various networks and the signals on the network link 420 and through the communication interface 418 (which carry the digital data to and from the computer system 400) are example forms of transmission media.

[0142] Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420, and communication interface 418. In the Internet example, server 430 can send the requested code for an application program through Internet 428, ISP 426, local network 422, and communication interface 418.

[0143] The received code may be executed by processor 404 as it is received, and / or stored in storage device 410 or other non-volatile storage for later execution.

[0144] Software Overview

[0145] Figure 5 is a block diagram of a basic software system 500 that can be used to control the operation of computing system 400. Software system 500 and its components (including their connections, relationships, and functionality) are merely exemplary and are not meant to limit implementation of the example embodiment(s). Other software systems suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functionality.

[0146] Software system 500 is provided for directing the operation of computer system 400. Software system 500, which may be stored on system memory (RAM) 406 and fixed storage (eg, hard disk or flash memory) 410, includes a kernel or operating system (OS) 510.

[0147] The OS 510 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more applications, represented as 502A, 502B, 502C ... 502N, can be "loaded" (e.g., transferred from fixed storage 410 into memory 706) for execution by the system 500. Applications or other software intended for use on the computer system 400 can also be stored as a downloadable set of computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., a web server, app store, or other online service).

[0148] Software system 500 includes a graphical user interface (GUI) 515 for receiving user commands and data in a graphical manner (e.g., "point and click" or "touch gesture"). These inputs can, in turn, be acted upon by system 500 based on instructions from operating system 510 and / or application(s) 502. GUI 515 is also used to display the results of operations from OS 510 and application(s) 502, allowing the user to provide additional input or terminate the session (e.g., log out).

[0149] OS 510 may execute directly on the bare hardware 520 (e.g., processor(s) 404) of computer system 400. Alternatively, a hypervisor or virtual machine monitor (VMM) 530 may be interposed between the bare hardware 520 and OS 510. In this configuration, VMM 530 acts as a software "buffer" or virtualization layer between OS 510 and the bare hardware 520 of computer system 400.

[0150] VMM 530 instantiates and runs one or more virtual machine instances ("guests"). Each guest includes a "guest" operating system (such as OS 510) and one or more applications (such as application(s) 502) designed to execute on the guest operating system. VMM 530 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0151] In some cases, VMM 530 can allow a guest operating system to run as if it were running directly on bare hardware 520 of computer system 500. In these instances, the same version of the guest operating system that is configured to execute directly on bare hardware 520 can also execute on VMM 530 without modification or reconfiguration. In other words, VMM 530 can, in some cases, provide full hardware and CPU virtualization to the guest operating system.

[0152] In other cases, the guest operating system may be specifically designed or configured to execute on the VMM 530 to improve efficiency. In these instances, the guest operating system is "aware" that it is executing on a virtual machine monitor. In other words, the VMM 530 may provide paravirtualization to the guest operating system in certain circumstances.

[0153] A computer system process includes an allocation of hardware processor time, and an allocation of memory (physical and / or virtual), an allocation of memory for storing instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing hardware processor state (e.g., the contents of registers) between allocations of hardware processor time when the computer system process is not running. A computer system process runs under the control of an operating system and may run under the control of other programs executing on the computer system.

[0154] cloud computing

[0155] The term "cloud computing" is used generally herein to describe a computing model that enables on-demand access to a shared pool of computing resources (such as computer networks, servers, software applications, and services) and that allows resources to be quickly provisioned and released with minimal management effort or service provider interaction.

[0156] Cloud computing environments (sometimes referred to as cloud environments or just clouds) can be implemented in a variety of different ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the public. In contrast, a private cloud environment is generally intended for use by or within a single organization. A community cloud is intended to be shared by several organizations within a community, while a hybrid cloud comprises two or more types of clouds (e.g., private, community, or public) bound together by data and application portability.

[0157] Generally speaking, the cloud computing model enables some of those responsibilities that might previously have been provided by an organization's own information technology department to instead be delivered as a service layer within the cloud environment for consumption by consumers (either internally or externally, depending on the public / private nature of the cloud). The precise definition of the components or features provided by or within each cloud service layer can vary depending on the specific implementation, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on the cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages ​​and development tools supported by the PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything below the runtime execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications and / or provision processes, storage, networks, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), in which the consumer uses a database server or database management system running on cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure and applications.

[0158] The above basic computer hardware and software and cloud computing environment are presented to illustrate the basic underlying computer components that can be used to implement the example embodiment(s). However, the example embodiment(s) are not necessarily limited to any particular computing environment or computing device configuration. Instead, according to the present disclosure, the example embodiment(s) can be implemented in any type of system architecture or processing environment that a person skilled in the art will understand as being capable of supporting the features and functions of the example embodiment(s) presented herein.

[0159] In the foregoing description, embodiments of the present invention have been described with reference to numerous specific details that may vary from embodiment to embodiment. The description and drawings should therefore be viewed in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what applicants intend as the scope of the invention, is the literal and equivalent scope of the claims issued from this application in their specific form, including any subsequent amendments.

Claims

1. A method comprising: Indicating in a database that a relational table is used for blockchain storage, wherein the relational table includes at least one application column; In response to the indication that the relational table is used for blockchain storage, adding at least one hidden column to the same relational table, wherein the at least one hidden column comprises a cryptographic hash column; receiving a first request to store a first value in an application column of the at least one application column; calculating a first cryptographic hash value based on the at least one application column of the first new row of the relationship table; Storing a first new row in the relational table, the first new row comprising: a first value in the application column, and a first cryptographic hash value in the cryptographic hash column; receiving a second request to store a second value in the application column of the at least one application column; calculating a second cryptographic hash value based on the at least one applied column of the second new row of the relationship table and a column of the at least one hidden column of the first new row; A second new row is stored in the relationship table, the second new row including: a second value in the application column and a second cryptographic hash value in the cryptographic hash column.

2. The method of claim 1, wherein: The first new line indicates a record; The first newline is older than the second newline; The second request to store a second value specifies updating the record; The second new line represents said record; The storing the second new row in the relationship table causes the relationship table to contain the second new row and the first new row as separate rows.

3. The method of claim 2, further comprising: receiving a request for content of the record from a client; In response to receiving the request for the content, the second new line of content is sent to the client without sending the first new line of content.

4. The method of claim 1, wherein: The first new line indicates a record; The second request is a request to amend the record.

5. The method of claim 4, further comprising: receiving a request to delete the record; A third new row is stored, the third new row containing an indication to delete the record. The method of claim 4 , wherein the calculating the second cryptographic hash value is based on the first cryptographic hash value.

7. The method of claim 1 , wherein the at least one hidden column contains blockchain data for a plurality of blockchains.

8. The method of claim 7, further comprising: distributing the blockchain data for multiple blockchains across one or more database instances; Storing the blockchain data for a blockchain in the plurality of blockchains: When the one or more database instances include multiple database instances, storing the data only in a first database instance among the one or more database instances. partially stored in a first database instance of the one or more database instances and partially stored in a second database instance of the one or more database instances, or Part is stored in the relational table and part is stored in a second relational table, the relational table and the second relational table being in the same database instance among the one or more database instances.

9. The method of claim 7 , further comprising obtaining corresponding locked database transactions for each of two blockchains in the plurality of blockchains in canonical ordering.

10. The method of claim 9, wherein acquiring the respective locks of the two blockchains occurs during a pre-commit callback of the database transaction.

11. The method of claim 9, wherein the canonical ordering depends on the respective access frequencies of the two blockchains.

12. The method of claim 1 , further comprising: A row of a relational table is deleted when a duration since an event for the row exceeds a threshold, wherein the event is: creation of the row, or last access of the row. 13 . The method of claim 12 , wherein deleting the row of the relational table comprises deleting a time partition or a time subpartition of the relational table containing the row.

14. The method of claim 1, wherein the second request to store the second value is received from a client and includes a digital signature of the client.

15. The method of claim 14, wherein the digital signature of the client is based on at least one of: the second value, and a value already stored in the at least one hidden column.

16. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the method of any one of claims 1-15 to be performed.

17. A system comprising: processor; as well as A memory coupled to the processor and having executable instructions stored thereon, the executable instructions, when executed by the processor, causing the processor to perform the method of any one of claims 1-15.

18. A computer program product comprising instructions which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1 to 15.

Images