Blockchain-based message logging

Abstract

A computer-implemented method for logging messages sent to and / or from a first party, where the method comprises: determining a first message to be logged, where the first message is sent to or from the first party; generating a first log recording message, wherein the first log recording message comprises a copy of the first message; storing the first log recording message and / or an encrypted version of the first log recording message at a storage location; and sending a first block chain transaction to the block chain network to record on the block chain, wherein the first block chain transaction comprises a first hash generated by performing hash processing on at least the first log record message.

Description

Technical Field

[0001] The present disclosure relates to a method of journaling (i.e., archiving) messages using a blockchain. Background Art

[0002] Blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and is widely disclosed. The blockchain includes a series of data blocks, each of which includes one or more transactions. Except for the so-called "coinbase transaction", each transaction points to a previous transaction in a sequence, which can span one or more blocks back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of a plurality of nodes competing to perform "proof of work", i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of blocks can be achieved by publishing only the block header.

[0003] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in a blockchain.

[0004] The nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert them into block templates, which attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes of the network, so that each node can record the new block on the blockchain. In order to record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The nodes receiving the transaction can compete to find a proof-of-work solution that incorporates the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on each node in the blockchain network.

[0005] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

[0006] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset, which can be derived from the ongoing sequence of transactions. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies future redemption conditions for the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset, and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0007] In such a model, when the second (target) transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new block to be recorded in the blockchain.

[0008] Another transaction model is the account-based model. In this case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored individually by the node in the blockchain and is constantly updated. Summary of the invention

[0009] There are laws and regulations that require businesses to log (i.e., archive) messages as they are transmitted, including emails and other electronic messages. For example, banks and financial institutions need to log various messages for audit, review, litigation, and compliance purposes. Similarly, in the retail industry, emails or messages between employees and customers regarding the sale of goods need to be logged.

[0010] Existing solutions usually rely on cloud storage servers to achieve the scalability and integrity required for journaled messages. However, enterprises that utilize logging services need to trust the cloud-based servers responsible for the integrity of the journaled messages. Subsequently, the integrity features of cloud-based logging systems face trust challenges. The problem is that it is difficult to prove that the journaled messages have not been tampered with by, for example, administrators, cloud service providers, or others.

[0011] Therefore, there is a need to be able to prove the integrity of logging messages.

[0012] According to one aspect disclosed herein, a computer-implemented method is provided for logging messages sent to and / or from a first party, wherein the method comprises: determining a first message to be logged, wherein the first message is sent to or from the first party; generating a first logging message, wherein the first logging message comprises a copy of the first message; storing the first logging message and / or an encrypted version of the first logging message at a storage location; causing a first blockchain transaction to be sent to a blockchain network for recording on a blockchain, wherein the first blockchain transaction comprises a first hash generated by hashing at least the first logging message.

[0013] The present disclosure describes a blockchain-based logging solution that utilizes the tamper-proof nature of blockchain to maintain the integrity of journaled (i.e., archived) messages. The solution can be seamlessly integrated with existing logging systems without changing their basic architecture.

[0014] The logging service is configured to detect when a message sent to or from a party (e.g., a user's email account) is logged (i.e., archived) for subsequent access. The logging service generates a copy of the message. In addition to the message, the logging message may also include other data, such as the sender and / or recipient of the message, the time the message was sent and / or received, and the like. The logging message is stored in a database. In some examples, the logging message is stored in its original form. In other examples, the logging message is stored in an encrypted form. In some examples, both the original version and the encrypted version may be stored. In addition, a hash of the logging message is stored on the blockchain. Storing the hash of the logging message on the blockchain can provide proof that the message has been accurately stored and has not been tampered with. This is because a third party can later verify whether the logging message (which includes a copy of the message) is hashed to the same hash as that stored on the blockchain. This mechanism does not require trusting a third party. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To facilitate an understanding of the embodiments of the present disclosure and to show how such embodiments may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0016] Figure 1 is a schematic block diagram of a system for implementing a blockchain;

[0017] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown;

[0018] Figure 3 is a schematic block diagram of an exemplary system for logging messages;

[0019] Figure 4 is a schematic block diagram of another exemplary system for logging messages;

[0020] Figure 5 schematically illustrates an exemplary hierarchical structure of encryption keys for logging messages;

[0021] Figure 6 An exemplary hierarchical structure of encryption keys and payment keys for logging messages is schematically shown. DETAILED DESCRIPTION

[0022] 1. Exemplary System Overview

[0023] Figure 1 An exemplary system 100 for implementing a blockchain 150 is shown. The system 100 may include a packet-switched network 101, typically a wide area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0024] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0025] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can be pruned as long as each blockchain node 150 stores a block header (discussed below) for each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output that is cryptographically locked to a user 103 (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0026] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0027] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 are propagated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to spend the same output.

[0028] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. Spending or redeeming does not necessarily mean transferring a financial asset, although this is certainly a common application. More generally, spending can be described as consuming an output, or allocating it to one or more outputs in another subsequent transaction. In general, a previous transaction can be any transaction in an ordered set 154 or any block 151. Although a previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, it is not necessary for a previous transaction 152i to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in a logical sequence linked by a pointer, and not necessarily the creation time or sending time in a time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of isolated transactions below). A previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0029] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0030] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i that the new transaction spends (or "allocates"), where the condition typically includes at least checking whether the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. In either case, if the new transaction 152j is valid, the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0031] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (or "spent") is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents double spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents double spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at all times.

[0032] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0033] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered set of transactions 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it spends or allocates the same output as a previously verified valid transaction, otherwise it is called a double spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0034] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0035] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

[0036] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal or a group of user terminals networked together.

[0037] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0038] Computer devices 102 of each of the parties 103 acting as consuming users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0039] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0040] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as SSDs, flash memory or EEPROMs, and / or optical media such as optical disk drives. The memory on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

[0041] The client application 105 may initially be provided to the computer device 102 of any given party 103 via a suitable computer-readable storage medium downloaded from a server, for example, or via a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable disk drive, floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive, etc.

[0042] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0043] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0044] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This can enable a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which the corresponding party 103 is a recipient (or indeed to check other parties' transactions in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0045] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that Alice's computer 102 is best connected to. When any given blockchain node 104 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of script and node protocol.

[0046] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0047] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0048] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0049] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0050] 2. UTXO-based model

[0051] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

[0052] In the UTXO-based model, each transaction ("Tx") 152 includes a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not been redeemed). The UTXO includes a value that specifies the amount of a digital asset. This represents a set of tokens on a distributed ledger. The UTXO may also include a transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include an indicator of the size of the input field 202 and the output field 203. The header 201 may also include an ID for the transaction. In an embodiment, the transaction ID is a hash value of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the node 104.

[0053] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In the , Alice's new transaction 152j is marked as "Tx 1 ”. This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2 In the previous transaction 152i, it is marked as "Tx 0 "Tx 0 and Tx 1 Just an arbitrary mark, it does not necessarily mean Tx 0 Refers to the first transaction in blockchain 151 and Tx 1 Refers to subsequent transactions in pool 154. Tx 1 Any previous (ie, predecessor) transaction that still has unspent output 203 locked to Alice may be pointed to.

[0054] When Alice creates her new transaction Tx 1 , or at least when she sends this new transaction to the network 106, the previous transaction Tx 0 may already be valid and included in block 151 of blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or may still be waiting in ordered set 154, in which case the transaction will be included in a new block 151 soon. Alternatively, Tx 0 and Tx 1 can be created and sent together to the network 106; or, if the node protocol allows buffering of "orphan" transactions, Tx 0 Even in Tx 1 Sent afterwards. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transaction (which transaction points to which other transaction, etc.). They may equally be replaced with "predecessor" and "successor", "predecessor" and "descendant" or "parent" and "child", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") that point to previous transactions (predecessor transactions or "parent transactions") will not be valid unless the parent transaction is valid. A child transaction that arrives at a blockchain node 104 before a parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0055] Previous transaction Tx 0 One of the one or more outputs 203 includes a particular UTXO, denoted as UTXO 0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that must be satisfied by the unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking conditions, which typically include the following conditions: The unlocking script in the input of a subsequent transaction includes a cryptographic signature of the party to whom the previous transaction was locked.

[0056] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to spend the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0057] Thus in the example shown, Tx 0 Output 203 of the UTXO 0 Includes locking script [Checksig P A ], the locking script requires Alice’s signature Sig P A , to redeem UTXO 0 (Strictly speaking, this is to make it possible for attempts to redeem UTXO 0 Subsequent transactions are valid). A ] contains Alice's public key P from her public-private key pair A Representation (i.e. hash). Tx 1 The input 202 includes a pointer to Tx 1 A pointer to a transaction (e.g., by its transaction ID (TxID 0 ), which in the embodiment is the entire transaction Tx 0 Tx 1 The input 202 includes the Tx 0 Identify UTXO 0 The index of the 0 It is identified among any other possible outputs of Tx 1 The input 202 further includes an unlocking script <Sig P A>, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0058] When a new transaction Tx 1 Upon reaching the blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing the two scripts:

[0059] <Sig PA> <pa>||[Checksig PA]

[0060] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (Included in Tx 0 ) to authenticate Tx 1 The unlocking script in the input contains the signature of Alice when she signed the expected part of the data. The expected part of the data itself (the "message") also needs to be included in order to perform this authentication. In an embodiment, the signed data includes the entire Tx 1 (Therefore there is no need to include a separate element to specify in plain text the portion of the data being signed, since that already exists).

[0061] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0062] If Tx 1 The unlocking script in satisfies Tx 0 One or more conditions specified in the locking script of tx (so, in the example shown, if 1 Alice's signature is provided and authenticated), then blockchain node 104 considers Tx 1 This means that blockchain node 104 will send Tx 1 Add to the pending transaction ordered pool 154. Blockchain node 104 also sends transaction Tx 1 Forwarded to one or more other blockchain nodes 104 in the network 106 so that it will be propagated throughout the network 106. 1 Valid and included in blockchain 150, which will make UTXO 0 From Tx 0 It should be noted that Tx 1 It is only valid if it spends an unspent transaction output 203. If it attempts to spend an output that has already been spent by another transaction 152, then even if all other conditions are met, Tx 1 Therefore, blockchain node 104 also needs to check the previous transaction Tx 0 152 has been spent (i.e., has it formed a valid input to another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a spent transaction 152, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0063] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0064] Note that in a UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave" a portion of a UTXO defined as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, Tx 0 UTXO 0 The amount defined in Tx 1 Therefore, if Alice does not want to split UTXO 0 All the amount defined in Tx 1 You can use the second output of the coin to make change for yourself, or pay it to another party.

[0065] In practice, Alice will also typically need to include a fee for Bitcoin node 104 that successfully includes Alice’s transaction 104 in block 151. If Alice does not include such a fee, then Tx 0 May be rejected by blockchain nodes 104, and therefore, although technically valid, may not be propagated and included in blockchain 150 (if blockchain node 104 does not wish to accept transaction 152, the node protocol does not force blockchain node 104 to accept). In some protocols, transaction fees do not require their own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 issuing the transaction. For example, assuming that the amount pointed to UTXO 0 The pointer is Tx 1 The only input, and Tx 1 Has only one output UTXO 1 If in UTXO 0 The amount of digital assets specified in the UTXO 1 The amount specified in the , can be created by winning the proof-of-work competition to create a UTXO containing 1 The node 104 of the block of allocates (or spends) the difference. Alternatively or additionally, this does not necessarily exclude that the transaction fee can be explicitly specified in one of the UTXO 203 of its own transaction 152.

[0066] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

[0067] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a particular function. "OP_..." refers to a particular opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates an unspendable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

[0068] Typically, the inputs to a transaction contain a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0069] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0070] 3. Side Channels

[0071] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). The side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0072] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0073] 4. Message Logging

[0074] Message logging generally refers to the process of creating copies of incoming and / or outgoing messages as they are being transmitted. Logged messages contain copies of the actual message content, and any content typically includes associated metadata such as the time, date, and addresses of senders / receivers involved in the communication.

[0075] Typical functions of a message logging system are as follows:

[0076] ● Real-time: Messages are captured continuously, and logging messages are created and sent to the storage system at the same time as the actual messages are transmitted.

[0077] ● Rule-based selection: The administrator sets a set of log rules that determine what to log, what to log, and where to store the log messages. The log messages are sent to a predetermined mailbox.

[0078] ● With index: An identifier indicating that the email sending the logging message to a predetermined mailbox is part of the logging protocol and not normal email communication.

[0079] ●Searchable: Log records can be searched by index.

[0080] Logging systems are usually based on the following principles:

[0081] ●Data integrity: Data must be retained in its original state and must not be tampered with or deleted.

[0082] ●Data security: Protect retained information from threats such as unauthorized access, spyware and virus attacks.

[0083] ●Data Auditability: Information can be audited, easily accessed and verified by authorized personnel.

[0084] Commercially available message logging systems provide cloud-based storage and typically log messages in real time. Organizations are able to define logging rules, rule scopes, logging recipients, and logging mailboxes to ensure they meet regulatory and compliance requirements. The logging service generates logging reports and automatically sends them to the logging mailbox in real time as messages are sent and received through user mailboxes. The journal report is a specific message that saves the original journal message as an attachment. If the journal mailbox is not available to receive journal reports, an alternate journal mailbox is used to receive undelivered reports. Typically, the alternate journal mailbox is not provided by the primary journal system, but rather by a local or third-party archiving system.

[0085] Although existing logging methods claim that they are immutable and can maintain the integrity of logged data, this claim can be challenged due to their off-chain nature. Currently, it is impossible to verify whether a logging message has been modified or deleted, so users must trust the message logging system.

[0086] 5. Blockchain-based message logging

[0087] Embodiments of the present disclosure relate to a blockchain-based messaging logging system and protocol. Figure 3 An exemplary system 300 for implementing such an embodiment is shown. System 300 includes a logging service 302 and two or more parties. Logging service 302 is connected to blockchain network 106 and is configured to communicate with the blockchain network. Logging service 302 includes and operates a computer device, which includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). The computer device of logging service 302 also includes a memory, i.e., a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0088] exist Figure 3 In the example of , the parties are shown as users Alice 103a and Bob 103b. However, in general, the parties may take any form, such as individual users, user groups, companies, organizations, universities, government agencies, etc. In addition, although the parties will be described in terms of Alice 103a and Bob 103b, the parties themselves (or more precisely, their corresponding computer devices) do not need to have any blockchain-related capabilities. In this regard, it should be understood that any actions described as being performed by Alice 103a or Bob 103b are actually performed by their corresponding computer devices.

[0089] System 300 also includes storage location 304. Storage location 304 is located at Figure 3 304, where the logging service 302 is connected to the storage location 304 (e.g., via a wired or wireless connection). For example, the logging service 302 can be connected to the storage location 304 via the Internet. In other examples, the logging service includes the storage location 304. The storage location 304 can be a dedicated storage operated by the logging service 302. In other examples, the storage location 304 can be cloud-based and consist of one or more servers. It should be noted that the storage location 304 is not the blockchain 150.

[0090] System 300 also includes requestor 306. In general, requestor 306 can take any form (e.g., user, organization, company, etc.). In some examples, requestor 306 is an auditor. Figure 3 Not shown, but the requester 306 can be connected and configured to communicate with the blockchain network 106.

[0091] The logging service 302 is configured to log messages sent to and / or from Alice 103 and / or Bob 103b. For simplicity, the embodiments will be described primarily by logging messages sent to and / or from Alice 103a. Here, "logging messages" is considered to mean data that includes at least a copy of the message. Thus, "logging a message" is considered to mean saving a copy of the message, and optionally saving metadata associated with the copied message.

[0092] The logging service 302 first determines that messages that Alice 103a has sent or received will be logged. In some examples, all messages sent or received by Alice 103a will be logged. In other examples, only certain types of messages will be logged, such as messages sent to and / or from specific parties (e.g., all messages sent to and / or from Bob 103b), messages sent and / or received during a specific time window that contain specific content (e.g., keywords), etc. The logging service 302 can determine whether the message meets one or more conditions before logging the message.

[0093] After determining the message to be logged ("first message"), the logging service 302 generates a logging message ("first logging message"). Here, "first" is only used as a distinguishing label and does not necessarily mean order. That is, the first message is not necessarily the first message to be logged. The first logging message includes a copy of the first message. In some examples, the first logging message consists of the first message. In other examples, the first logging message includes additional metadata. For example, the first logging message may include the sender of the first message (e.g., Alice 103a) and / or the recipient of the first message (e.g., Bob 103b). Other metadata (e.g., timestamp, message type, priority, etc.) may be included as part of the first logging message.

[0094] The logging service 302 stores the first logging message at the storage location 304. As described below, the first logging message can be encrypted, where the encrypted version is stored in addition to or instead of the plaintext version of the first logging message. Depending on the type of storage, storing the first logging message can include the logging service 302 storing the first logging message in an internal storage or sending the first logging message to a remote storage, such as a cloud storage.

[0095] In some examples, the logging message is encrypted and then stored at the storage location 304. For example, the first logging message can be encrypted and then stored. That is, the logging service 302 can encrypt the first logging message to generate a first encrypted logging message, and store the first encrypted logging message at the storage location 304 (rather than the plaintext first logging message). Any suitable encryption scheme can be used, including symmetric and asymmetric encryption.

[0096] In addition, the logging service 302 generates a hash of the first logging message ("first hash"). The first hash is generated by hashing at least the first logging message using a hash function (e.g., a cryptographic hash function such as a SHA-based hash function (e.g., SHA256)). Other types of hash functions can be used. The logging service 302 submits a transaction ("first transaction") to the blockchain network 106, where the first transaction includes the first hash. The first transaction can be signed by the logging service 302.

[0097] The first transaction has a transaction identifier ("first transaction identifier" or first TxID). The logging service 302 may store the logging message at a storage location 304 mapped to the first TxID. That is, a data pair including the first logging message and the first TxID may be stored at the storage location 304. The first logging message and the TxID may be stored in a database at the storage location. When the first transaction is accepted on the blockchain, the block number of the block in which the first transaction is recorded may be obtained and mapped to the first transaction stored at the storage location 304. The first logging message may be mapped to the first TxID or both the first TxID and the block number.

[0098] In some examples, the first message can have a message index ("first message index"). The first message index can be generated by logging service 302. Typically, logging service 302 can log multiple messages, and the message index indicates the position of a particular logging message in the sequence of logging messages. For example, in addition to the first TxID and / or the block number, logging service 302 can also store the first logging message at a storage location mapped to the first message index.

[0099] It should be noted that the hashed logging message (eg, the first hash of the first logging message) is a hash of the plaintext logging message, not a hash of the encrypted logging message.

[0100] In some examples, logging service 302 can generate and maintain a hierarchical key structure (e.g., a hierarchical deterministic (HD) wallet of keys) where each key is linked to a master key. Figure 5 An exemplary structure is shown. The key structure may include a first key branch, wherein at least some of the keys in the first branch are used to encrypt the logging messages. Each key in the branch (the "encryption branch") is linked to a master encryption key (e.g., Figure 5 The key k in E ). It should be noted that although it is called an encryption branch, not all keys in the branch need to be used to encrypt messages. For example, some keys may only be used to derive subkeys within the key structure. The encryption branch includes keys in several layers of the structure. Each key has a corresponding index. The encryption branch includes a message key (or message index key) layer. The encryption branch may include other layers, such as a function layer, a participant layer, and a mailbox layer. Each message key is associated with a corresponding logging message. For example, Figure 5 The message key k in ES1 The logging service may encrypt the first logging message using a key derived from a message key associated with the first logging message (the "encryption key"). For example, Figure 5 The encryption key k in ES11 can be used to encrypt the first logging message for the first time, and Figure 5 The encryption key k in ES12 Can be used to encrypt the first logging message a second time (re-encryption will be discussed below).

[0101] Now return to storing the hashed logging message on-chain. The first hash of the first logging message can be stored in a spendable or non-spendable output of the first transaction. In any case, the first transaction contains at least one spendable output (which may or may not contain the first hash). The spendable output is locked to a payment public key generated by the logging service 302. In some examples, the hierarchical key structure can include a second key branch ("payment branch"). The public key used to lock the spendable output can occupy a position in the payment branch that corresponds to the encryption key used to encrypt the first logging message. Figure 6 An example of a key structure including an encryption branch and a payment branch is shown. Figure 6 The payment key k in PS11 The spending public key that can be used to derive the spendable outputs of the first transaction are locked to. More details on the key structure are provided in Section 6 below.

[0102] As described above, the logging service 302 can log many messages. The logging service 302 uses a similar process described for each logging message. That is, for each respective message to be logged, the logging service 302 generates a respective logging message that includes a copy of the respective message, and stores the respective logging message (or an encrypted version thereof) at the storage location 304. The logging service 302 also generates a respective hash of the logging message, and stores the respective hash in the respective transaction on the blockchain 150. When encrypting the respective messages, the logging service 302 can use respective encryption keys from the same hierarchical key structure. Each encryption key is derived from a message key associated with the respective logging message (i.e., the message key has an index that corresponds to the index of the respective logging message). For example, if Figure 5 The message key k in ES1 is associated with the first logging message, then the second logging message may be associated with the message key k ES2 The third logging message may be associated with the message key k ES3 , and so on. Similarly, the spendable outputs of each corresponding transaction can be locked to a corresponding spend key from the same hierarchical key structure. Each spend key is derived from the message key associated with the corresponding logging message (i.e., the message key has an index corresponding to the index of the corresponding logging message). For example, if Figure 6 The message key k in PS1 is associated with the first logging message, then the second logging message may be associated with the message key k PS2 The third logging message may be associated with the message key k ES3 Related, and so on.

[0103] Turning now to the process by which the requester 306 verifies the integrity of the logging message. The requester 306 may request access to a logging message, such as a first logging message. In response, the logging service 302 retrieves the encrypted logging message from the storage location 304, decrypts the encrypted logging message, and sends the decrypted logging message (i.e., the first logging message) to the requester 306. In an example where the logging message is not stored in an encrypted form, the logging service 302 retrieves the first logging message from the storage location 304 and proves the first logging message to the requester 306. The requester 306 may then verify that the first logging message hash is the same first hash stored in the first transaction on the blockchain 150. In some examples, the logging service 302 provides the first TxID to the requester 306. In addition, the block number and / or message index mapped to the first logging message may also be provided to the requester 306.

[0104] In some examples, once the requesting party 402 has accessed the logging message (i.e., provided to the requesting party), the logging service 302 submits a transaction (a "second transaction") to the blockchain network 106 that includes at least a double hash of the logging message. If the logging message is accessed again, a third transaction including a triple hash of the logging message may be sent to the blockchain network 106, and so on. The preimage may contain other data, such as the name of the requesting party 402, an access timestamp of the logging message, etc. Each time a new transaction is generated to store a new hash value (e.g., a double hash of the logging message), the TxID mapped by the new transaction is appended to the previous TxID mapped to the logging message at the storage location 402. This creates a chain or history of transactions associated with a particular logging message.

[0105] It should be noted that in the example where the next transaction in the chain spends the spendable output of the previous transaction, the link between the transactions is obvious on the chain. In this case, the transaction chain history does not necessarily have to be explicitly recorded in storage location 402.

[0106] In examples where there is no cost link between the first transaction, the second transaction, etc. transactions (ie, there is a separate transaction to notarize each access), the transaction chain may be written to storage location 402 .

[0107] In an example where the logging message is stored in encrypted form at storage location 402 and needs to be decrypted in order to access the logging message, logging service 302 can re-encrypt the logging message using a new encryption key each time the logging message is accessed and store the re-encrypted logging message at storage location 304. The encryption key used to encrypt the logging message a second time can be a second key derived from the same message key. For example, encryption key k ES12 can be used to encrypt the first log message a second time. If the first log message is accessed for the third time, a third encryption key (e.g., k ES13 ) re-encrypts the first logging message.

[0108] Similarly, each new transaction used to store an updated hash of a logging message may have a spendable output locked to a new pay public key. The pay public key may be derived from a pay key in the pay branch of the key structure, where the location of the pay key corresponds to the location of the encryption key used to re-encrypt the first logging message. For example, a second transaction storing a double hash of the first logging message may have a spendable output locked to the pay key k. PS12 Output.

[0109] Figure 4 1 shows a more detailed version of the message logging system 300 described above, and shows the logging of a message sent from Alice 103a to Bob 103b. Example process of logging and access. In step 1, Alice 103a sends a message to Bob 103b In step 2, the logging service 302 captures the message to generate logging messages

[0110] The logging process will now be described. See the solid arrows. In step 3a, the logging message Encryption to generate encrypted logging messages In step 3b, a logging message is generated The hash of , and in steps 4 and 5, create a transaction identifier TxID S1 transactions and stores them on the blockchain 150. Encrypted logging messages With transaction identifier TxID S1 A Stored together in the logging database.

[0111] The access process will now be described. Refer to the dashed arrow. In this example, the requester 306 is an auditor. In step 1, the auditor 306 sends an access request to the logging service 302. In step 2a, the logging service 302 performs an encrypted logging message. Decrypt to get the logging message And in step 2b, the logging message Send to auditor 306. In step 3a, log the message In step 3b, a double hash of the logging message is generated. And in step 4b and step 5b, will have transaction identifier The transaction is stored on blockchain 150. Here, n refers to the nth access to the log record message. From the auditor's perspective, in step 3c, auditor 306 accesses the log record message The hash is processed and in step 4b, the auditor obtains the transaction identifier TxID S1 A The auditor 306 checks the transaction and verifies whether the hash contained in the transaction matches the hash of the log record message. If these hashes match, the auditor 306 can ensure that the log record message has not been tampered with or otherwise changed.

[0112] It should be noted that Figure 4 The labels / numbers of the steps in the example are for illustration purposes only. In some examples, some steps may occur in a different order. Similarly, some steps may occur in parallel.

[0113] 6. Exemplary Implementation

[0114] This section describes the specific implementation of the above blockchain-based message logging protocol, including the logging process and the access chain protocol. The access chain allows the order and timestamp of each access on the blockchain to be recorded. The protocol achieves at least the following two goals:

[0115] ● Maintain the integrity of logging messages

[0116] ● Manage access control to logging messages

[0117] 6.1 Definition and Characteristics

[0118] A logging message can be defined as, for example, a copy of the original message, including the message itself, the sender's name and address, the recipient's name and address, and a corresponding timestamp. Additional metadata can also be included in the logging message, for example based on organizational preferences. Once the original message matches a logging rule, the message text and associated metadata will be automatically captured during transmission and sent to the logging destination.

[0119] The logging destination can be a mailbox or other storage server. In this exemplary logging protocol, the logging destination is a local storage server managed by an organization administrator. The logging message is encrypted and stored on this local server. This allows the organization to flexibly choose encryption schemes to meet organizational requirements and further manage access controls that require decryption keys. However, it should be noted that the local server can choose to be mirrored in real time on a cloud server, backed up to a cloud server regularly, or even replaced by a cloud server. Although cloud services typically encrypt stored data (and automatically decrypt the data when a user accesses it), this is independent of the encryption implemented by the logging system, and there are no compatibility restrictions associated with different encryption formats.

[0120] The logging protocol logs messages in real time, i.e., a logging message is created when a message is sent or received through a user's mailbox. At the same time, a hash of the logging message (including the original message text and metadata) is published to the blockchain. This provides a time-stamped, immutable record of the logging message that can be used at any time to verify the integrity of the copy on the server.

[0121] The parties involved in the message logging protocol include the message sender, message receiver, administrator, and auditor. Among them, the sender and receiver of the logging message are called the logging party.

[0122] Some features of this exemplary message logging protocol include:

[0123] ● Encrypted—All logging messages are encrypted and the encrypted copy is accessible only by administrators and / or auditors. The logging party cannot access the encrypted copy.

[0124] ● Verifiable — The integrity of a logged message can be verified based on a timestamped, immutable hash of the message stored on the blockchain. This maintains data privacy while allowing for proof of integrity.

[0125] ● Searchable—Logged messages are searchable by transaction ID.

[0126] ● Accountability — Logging parties know they are being logged and can verify the hash of the logging message they published on the blockchain using their original message.

[0127] 6.2 Encryption

[0128] The encryption is implemented by the administrator, and there is no interaction between the logging party and the administrator during the encryption process. Therefore, a symmetric encryption scheme is sufficient to encrypt the logging messages.

[0129] The encryption keys of different logging parties are managed in a hierarchical structure (see Figure 5 As an example). This hierarchical structure allows administrators to track and manage all encryption keys. is the administrator's master secret key ( Figure 5 Level 0 in ). According to BIP 43 and 44, for cryptographic purposes, Derive the secret key k E (Level 1). For simplicity, assume that there are two logging parties Alice and Bob in the logging protocol. Level 2 has a sub-secret key and The two sub-secret keys are used for logging messages for Alice and Bob respectively. Level 3 creates and It is from the corresponding mailboxes of Alice's sent mailbox and received mailbox From each key at this level, a series of subkeys (level 4) are derived to represent each message in the mailbox: Export For Alice's first sent message, export for her second sent message, and so on. It should be noted that the keys in levels 0-4 are only used to create the tree structure. Level 5 contains the keys used for encryption. As the lowest level of the key hierarchy, these keys cannot be used to derive the values ​​of other keys in the structure, so even if a single key is compromised, an attack will be limited to a single record. Each time a message is accessed, it is re-encrypted - this allows for strict access control and monitoring of each access. The first time a message is logged, it is encrypted using the first subkey, e.g., initially it would be encrypted using the key Encrypt Alice's first sent message. If the message is accessed, the key The message is re-encrypted.

[0130] It should be noted that in some examples, all secret keys are managed by an administrator, but these keys can be generated and exported by software. This enables the process of key generation and management, encryption, decryption, and signing and transaction generation to be automated behind the scenes.

[0131] 6.3 Process

[0132] For simplicity, assume the following:

[0133] ●JM is the logging message, i.e. a copy of the original message and its metadata.

[0134] H is the hash of JM and will be published on the blockchain via a blockchain transaction.

[0135] ●eM is an encrypted JM and is saved in the logging destination. This location can be a local server set by the administrator.

[0136] Once a message satisfies the logging rules, it is logged, encrypted, and stored in a data structure at the logging destination (called the logging database). For example, the hash of the logging message will be published to the blockchain using the OP_RETURN in the output of the transaction. It should be noted that the logging party should be aware of the logging rules, including what information will be captured during the logging process.

[0137] 6.4 Logging Protocol

[0138] Assume that Alice 103a is an internal user and all messages she sends need to be logged. She sends a message to Bob 103b, who can be either an internal user or an external user. If Bob is an internal user and is designated as the logging party, the logging process applies to messages received by Bob, as described in the next section. If Bob is an external user, the logging process only applies to messages sent by Alice.

[0139] We will first describe the message logging process from the sender's (Alice) perspective.

[0140] 1. Copy Alice's message when it is sent, thus creating a

[0141] 2. Use a secret key right Encryption, such as Figure 5 shown.

[0142] 3. Encrypted is represented as And saved in the logging database.

[0143] 4. Use transactions published to the blockchain The output of the script OP_RETURN is calculated and stored Hash value Transactions Stored in the logging database and used as a pointer to The links are shown in Table 1 below.

[0144] The hash value stored on-chain is the hash of the (original) logged message, not the hash of the encrypted message. This allows the logging party to verify the integrity of the on-chain hash using its original message without access to the encryption key, and maintains user privacy since the original message data is not stored on-chain.

[0145] Now, assume that Bob is an internal user and the messages he receives from Alice above are logged. The logging process is similar to above and is as follows:

[0146] 1. Copy the message from Alice as it is received through Bob’s mailbox server, thereby creating a

[0147] 2. Use a secret key right Encryption is performed.

[0148] 3. Encrypted is represented as And saved in the logging database.

[0149] 4. Calculation Hash value and stores it in the Bitcoin transaction published to the blockchain OP_RETURN output of the transaction. Saved in the logging database and linked to As shown in Table 1.

[0150] It is worth noting that the message sent from Alice to Bob is represented on Alice's side as and on Bob's side it is represented as Although the original message has the same content, the logged versions will have different timestamps and possibly different logging metadata (e.g. Alice and Bob are internal users of different companies with different logging rules), so their hashes and will have different values. It should be noted that the two versions of the logging message are notarized in separate transactions on the blockchain.

[0151] 6.5 Logging Database

[0152] The logging messages are stored on the server in a data structure called the logging database. The format of this structure is not formally defined in this article, but it can store encrypted message data and link each encrypted message to its message index and the transaction ID and block number of the hash commitment on the chain. Other optional fields (e.g., logging party, mailbox, and timestamp) can be included to assist in search functions, and the details of the access request history (access index, requester, time, date, etc.) can also be recorded as needed.

[0153] The logging database is directly accessible by administrators, but not by logging parties or auditors. Administrators can set up a lookup table for each logging party that enables them to view only the records in the logging database that correspond to their messages. Similarly, auditors can view a subset of records that meet their audit criteria. It should be noted that the content of messages is always encrypted in the database, with decryption key access controlled by the administrator and implemented by the logging system.

[0154] Table 1. Example of a logging database linking logging message indexes, encrypted message ciphertexts, and corresponding TxIDs. The following example entries are provided for illustration.

[0155]

[0156] 6.6 Blockchain Transaction Format and Payment Keys

[0157] When a transaction is created on the blockchain, the output (where the logging message hash can be stored) is locked to a public key. Each time a logging message hash is stored on-chain, a new public / private key pair is generated. This can be done automatically by the logging system. In a branch running in parallel with the encryption key, a private key based on the master secret key is used A payment key derivation system for derived secret keys. This allows the key index within the payment branch to match the index in the encryption branch.

[0158] First, from the master secret key Derive the secret key k for payment P ,like Figure 6 Each time an encryption secret key is generated for Alice's logging message, a parallel payment secret key is also created. For example, For use in Encryption and also generate payment private key For like Figure 6 shown.

[0159] Table 2 shows an example blockchain transaction created when a message is first logged. For simplicity, the inputs and outputs required to pay transaction fees and changes are omitted. The remaining lock script is a standard P2PKH script based on the public key associated with the newly generated spend key, i.e. Where "*" represents elliptic curve scalar multiplication, and G is the elliptic curve generator point.

[0160] Table 2. Example blockchain transaction for initial logging of a message. Input UTXO is any UTXO controlled by an administrator or logging system. Outputs are locked to a spend key The logging message hash is embedded into the output via the OP_RETURN code.

[0161]

[0162] 6.7 Verification

[0163] The message logging system provides verifiable integrity of logged messages. This is achieved by comparing the log record or original message to a timestamped, immutable hash published on the blockchain.

[0164] The auditor requests access to the administrator's logging messages and receives access to the decrypted logging messages. The process is described below. The corresponding transaction ID of one or more blockchain transactions containing the corresponding hash of the logging message can be linked to each logging message in the logging database, allowing the auditor to locate the corresponding hash of the logging message on the blockchain. They can then hash the decrypted logging message and compare the two hash values ​​to determine whether the integrity of the logging message is intact.

[0165] An auditor may want to prove that when a message was first logged (and timestamped on the chain), it was the same version they now have access to. In this case, the auditor needs access to the TxID of the first transaction in the chain. As another example, an auditor may want to audit the access chain (e.g., to check that only authorized personnel have accessed the data), in which case they need to see the access chain record and all corresponding transactions.

[0166] The logging party may also want to check that the logged message copy is identical to its original message. They can use a lookup table to find the associated transaction ID and locate the on-chain hash. Since they have access to the original message, they do not need to decrypt the logged copy. Instead, the logged message can be reconstructed according to the logging format rules and hashed. If the hashes match, the user knows that their message has been logged accurately.

[0167] 6.8 Access Chain

[0168] The hash value of the logging message is recorded on the blockchain to maintain the integrity of the logging message. Each time a party (e.g., an auditor) requests the decryption key for a logging message, the access request can be recorded on the blockchain by creating a new transaction that spends the UTXO of the current transaction associated with the logging message. Therefore, all transactions corresponding to the access of a single logging message will be linked on the blockchain through the spending of UTXO, which is called an access chain. The access request is also reflected in the logging database by updating the access chain of the transaction and re-encrypting the logging message. This allows administrators and logging parties to track and verify the access history of the corresponding transaction to the logging message.

[0169] 6.9 Key Management

[0170] When a new decryption request is initiated (by an auditor or administrator), two new keys are generated within the key structure: one in the encryption branch (e.g. ), one in the payment branch (e.g. ). The key generation follows the above structure. It should be noted that the second numerical index used in this white paper (i.e., The index j) is incremented with each access. Figure 5 and Figure 6 This is shown in level 5 of . Accessing the index ( Figure 5 ) can be derived from the number of the TxID listed for each logged message, or explicitly included in the logging database.

[0171] The spend key is used as a private key to generate a public key for new transactions Encryption Key Used for This ensures that every time a logging message is decrypted, a new decryption key request must be initiated, providing a comprehensive access history reflected on the blockchain and in the logging database. This also supports security against theft or disclosure of encryption keys.

[0172] As described in the section on initial encryption, key generation and derivation during access can be implemented by software within the logging system. Similarly, the software can use the key to decrypt and re-encrypt the data and automatically perform the steps in the protocol described below to run the access log.

[0173] 6.10 Blockchain Transaction Format

[0174] When targeting a logging message (for example, ) When a decryption request is initiated, the associated transaction is spent UTXO in. New transaction (Table 3) References As input, a private key is required The generated signature. The output is locked to the new public key The UTXO is sent and also includes a double hash of the logging message in the OP_RETURN locking script.

[0175] Table 3. Example blockchain transaction for recording the first access to a logging message. Inputs reference the most initial transaction associated with JM, outputs are locked to the public key hash of the new spend key generated upon access. A double hash of the logging message is embedded into the output via the OP_RETURN code.

[0176]

[0177] It should be noted that this transaction includes a double hash of the logging message, rather than the single hash used in previous transactions. This helps protect the privacy of the logging party because it makes it more difficult to identify links between the data payloads of transactions. In this case, each access to the same logging message updates the hash on the blockchain by hashing the previous hash.

[0178] The access chain formed by the access transaction provides an immutable record that includes the number of accesses and the time of access. Additional metadata (e.g., who viewed the record) can be recorded in the logging database and notarized on the chain. For example, an auditor may be required to provide a digital signature that is used to sign each request to review a record. This digital signature can be included in the access transaction on the chain, along with a certificate that associates the auditor's public key with their identity, current affiliation, and professional certifications. This can be achieved in a variety of ways. For example, the hash of the access metadata can be concatenated with the previous hash of the JM before applying the second hash (e.g., Where data is metadata associated with the access). In this case, for the logging party to verify the access chain, they need to be able to access the raw metadata associated with each access. An alternative is to represent the metadata associated with the access chain in a separate hash: either after the JM hash in the OP_RETURN, or in a separate output.

[0179] 6.11 Access Agreement

[0180] Each time an auditor needs to access records, they must submit an access request. Access requests can be processed manually by an administrator or automatically by the software after asking the auditor to provide credentials.

[0181] We now use the example of access to a single logging message to describe the full protocol that occurs when an access request is granted, but in reality, many requests may occur simultaneously during an audit. If the auditor accesses Alice's logging messages, such as The logging system will then perform the following steps:

[0182] 1. Use right Decrypt and allow auditors to view the decrypted and corresponding records, such as the logging party "Alice" and the mailbox "Sent" in the logging database. It should be noted that the auditor uses corresponding records to identify They are The hash is taken and compared to the hash on the chain to verify its integrity.

[0183] 2. From Exporting a new encrypted secret And from Export parallel payment private key

[0184] 3. Calculate the associated payment public key

[0185] 4. Create a new transaction The new thing costs UTXO and pay to (Optional) Add metadata about the access request to the transaction.

[0186] 5. Put the new Added to the entry of the logging message in the logging database, as shown in Table 4.

[0187] 6. Use right Re-encrypt and store it in the logging database (it should be noted that this should overwrite the previously encrypted message ciphertext to ensure that the old decryption key cannot be reused).

[0188] 7. (Optional) Update the logging database with additional information about the access request (e.g., access index, requester, access date and time, etc.).

[0189] Table 4. Examples of update indication access logging messages to the logging database.

[0190]

[0191] 6.12 Overview and Features

[0192] Figure 4 An exemplary message is shown in An initial message is logged and an overview of the processes that occur during the access.

[0193] The characteristics of the access chain are summarized as follows:

[0194] ● High level of user data privacy - Personal data is not stored directly on-chain, but is notarized via a hash commitment that can be used to verify the integrity of the data stored in the logging database. In addition, while there is a chain of transactions indicating the access history of each logging message, the hash value stored in each subsequent transaction will be different. This is because after each access, an additional round of hashing function is applied to the data in the OP_RETURN (e.g., double hashing → triple hashing). This helps to obfuscate any links between transactions and provides a certain privacy for access history, which could otherwise be inferred by searching for transactions containing specific hash values.

[0195] One-time access - The encryption secret key can only be used to access the encrypted logging messages from the logging database once. After decryption, the encryption of the logging messages is updated with the new encryption secret. If the auditor wants to access the logging messages again, they need to obtain a new decryption key from the administrator. This helps the administrator manage access after the decryption key has been handed over to the auditor.

[0196] ●On-chain access records - Each access from the logging database will be recorded on the blockchain through a transaction. In this case, the timestamp and order of each access cannot be tampered with.

[0197] ● Traceable Access - New transaction IDs will be updated in the logging database. This makes it easy to search and track each access through these transaction IDs.

[0198] 7. Further comments

[0199] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

[0200] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes can share some or all of the characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 described above.

[0201] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the functions described in creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions but not all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and publishing blocks (remember that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0202] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that the node can perform at least one or part of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150, but not all of the functions. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

[0203] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," where such entity / element is configured to perform some or all of the roles in creating, publishing, propagating, and storing blocks. The functionality of such a network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

[0204] Some embodiments have been described in terms of a blockchain network that implements a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments any type of suitable consensus mechanism may be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed-time. As a specific example, proof-of-stake uses a randomization process to determine which blockchain node 104 has a chance to produce the next block 151. The selected node is often referred to as a verifier. A blockchain node may lock its token for a period of time in order to have a chance to become a verifier. Typically, the node that has locked the largest stake for the longest time is most likely to become the next verifier.

[0205] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0206] Statement 1. A computer-implemented method for logging messages sent to and / or from a first party, the method comprising:

[0207] determining a first message to be logged, wherein the first message is sent to or from the first party;

[0208] generating a first logging message, wherein the first logging message comprises a copy of the first message;

[0209] storing the first logging message and / or an encrypted version of the first logging message at a storage location;

[0210] Causing a first blockchain transaction to be sent to a blockchain network for recording on a blockchain, wherein the first blockchain transaction includes a first hash generated by hashing at least the first logging message.

[0211] Statement 2. The method of statement 1, wherein the first blockchain transaction has a first transaction identifier, and wherein the first logging message and / or the encrypted version thereof is mapped to the first transaction identifier at the storage location.

[0212] Statement 3. A method according to statement 2, wherein the first blockchain transaction is recorded in a first block of the blockchain, wherein the first block has a first block number, and wherein the first logging message and / or the encrypted version thereof is mapped to the first block number at the storage location.

[0213] Statement 4. A method according to any of the preceding statements, wherein the first message has a first message index, and wherein the first logging message and / or the encrypted version thereof is mapped to the first message index at the storage location.

[0214] Statement 5. A method as described in any of the preceding statements, wherein the first logging message includes first metadata associated with the first message.

[0215] Statement 6. The method according to statement 5, wherein the first metadata includes one or more of the following: a sender of the first message, a receiver of the first message, a timestamp, and a message type.

[0216] Statement 7. A method according to any of the preceding statements, the method comprising:

[0217] encrypting the first logging message to generate the encrypted version of the first logging message; and,

[0218] The encrypted version of the first logging message is stored at the storage location.

[0219] Statement 8. A method as described in any of the preceding statements, wherein the encrypted version of the first logging message is generated using a symmetric encryption scheme.

[0220] 9. The method of clause 7 or 8, wherein the first logging message has a first logging message index, and wherein the method comprises:

[0221] Generating a hierarchical key structure, the hierarchical key structure comprising one or more key layers (one or more layers of keys, each layer comprising one or more corresponding keys with corresponding key indexes), wherein the hierarchical key structure comprises a first key branch, and wherein encrypting the first logging message comprises: using a first encryption key derived from a first message key, the first message key being in the first key branch and having a first key index corresponding to the first logging message index.

[0222] Statement 10. The method of statement 9, wherein the first blockchain transaction includes a first spendable output, the first spendable output is locked to a first payment public key, wherein the hierarchical key structure includes a second key branch, wherein the first payment public key is derived from a first payment key, and wherein the first payment key is derived from a first message key, the first message key is located in the second key branch and has a first key index corresponding to the first logging message index.

[0223] Statement 11. The method of statement 10, wherein the first hash value is stored in the first spendable output.

[0224] Statement 12. The method of statement 10, wherein the first hash value is stored in an output other than the first spendable output.

[0225] Statement 13. A method as described in any of the preceding statements, wherein the determination includes: determining whether the first message satisfies one or more conditions for logging a message.

[0226] Statement 14. A method according to any of the preceding statements, the method comprising:

[0227] Determining a plurality of corresponding messages to be logged;

[0228] generating a plurality of corresponding logging messages, wherein each corresponding logging message comprises a copy of the corresponding message;

[0229] storing the plurality of respective logging messages and / or respective encrypted versions of the respective logging messages at the storage location;

[0230] For each respective logging message of the plurality of respective logging messages, causing a respective blockchain transaction to be sent to the blockchain network to be recorded on the blockchain, wherein the respective blockchain transaction comprises a respective hash generated by hashing at least the respective logging message.

[0231] Statement 15. The method of statement 14, comprising:

[0232] encrypting each respective logging message to generate the respective encrypted version of the respective logging message; and,

[0233] Each respective encrypted version of the respective logging message is stored at the storage location.

[0234] Statement 16. A method according to statements 9 and 15, wherein encrypting each corresponding logging message includes: using a corresponding encryption key, wherein the corresponding encryption key is derived from a corresponding message key, wherein the corresponding message key is located in the first key branch and has a corresponding key index corresponding to the corresponding logging message index.

[0235] Statement 17. A method according to statements 10 and 16, wherein the corresponding blockchain transaction includes a corresponding spendable output, the corresponding spendable output is locked to a corresponding payment public key, wherein the corresponding payment public key is derived from a corresponding payment secret key, and wherein the corresponding payment key is derived from a corresponding message key, the corresponding message key is located in the second key branch and has a corresponding key index corresponding to the corresponding logging message index.

[0236] Statement 18. A method according to any preceding statement, comprising:

[0237] receiving a request from a requester to access the first logging message;

[0238] The first logging message is sent to the requestor.

[0239] Statement 19. The method of statements 7 and 18, comprising:

[0240] In response to receiving the request, the encrypted version of the first logging message is decrypted.

[0241] Statement 20. The method of statement 18 or 19, comprising:

[0242] The first transaction identifier is provided to the requestor.

[0243] Statement 21. The method of any one of statements 18 to 20, comprising:

[0244] Causing a second blockchain transaction to be sent to the blockchain network for recording on the blockchain, wherein the second blockchain transaction includes a second hash generated by double hashing at least the first logging message.

[0245] Statement 22. The method of any one of statements 18 to 21 dependent upon statement 9, comprising:

[0246] re-encrypting the first logging message to generate a re-encrypted version of the first logging message; and,

[0247] The re-encrypted version of the first logging message is stored at the storage location, wherein re-encrypting the first logging message includes: using a second encryption key derived from the first message key, the first message key is located in the first key branch and has the first key index corresponding to the first logging message index.

[0248] Statement 23. The method of statement 21 or 22 as dependent on statement 10, wherein the second blockchain transaction includes an input that references the first spendable output of the first blockchain transaction, and wherein the second blockchain transaction includes a second spendable output locked to a second payment public key, wherein the second payment public key is derived from a second payment secret key, and wherein the second payment key is derived from the first message key, the first message key being located in the second key branch and having the first key index corresponding to the first logging message index.

[0249] Statement 24. The method of any one of statements 21 to 23 as dependent upon statement 2, wherein the second blockchain transaction has a second transaction identifier, and wherein the method comprises:

[0250] The first transaction identifier mapped to the first logging message and / or the encrypted version thereof is appended with the second transaction identifier.

[0251] Statement 25. A computer device, the computer device comprising:

[0252] a memory, the memory comprising one or more memory cells; and,

[0253] A processing device comprising one or more processing units, wherein the memory stores code configured to be executed on the processing device, the code being configured to execute a method according to any one of statements 1 to 24 when executed on the processing device.

[0254] Statement 26. A computer program embodied on a computer readable memory and configured to, when executed on one or more processors, perform the method of any one of statements 1 to 24.< / pa>

Claims

1. A computer-implemented method for logging messages sent to and / or from a first party, the method comprising: determining a first message to be logged, wherein the first message is sent to or from the first party; generating a first logging message, wherein the first logging message comprises a copy of the first message; storing the first logging message and / or an encrypted version of the first logging message at a storage location; causing a first blockchain transaction to be sent to a blockchain network for recording on a blockchain, wherein the first blockchain transaction includes a first hash generated by hashing at least the first logging message.

2. The method of claim 1 , wherein the first blockchain transaction has a first transaction identifier, and wherein the first logging message and / or the encrypted version thereof is mapped to the first transaction identifier at the storage location.

3. The method of claim 2, wherein the first blockchain transaction is recorded in a first block of the blockchain, wherein the first block has a first block number, and wherein the first logging message and / or the encrypted version thereof is mapped to the first block number at the storage location.

4. A method according to any preceding claim, wherein the first message has a first message index, and wherein the first logging message and / or the encrypted version thereof is mapped to the first message index at the storage location.

5. The method of any preceding claim, wherein the first logging message comprises first metadata associated with the first message. 6 . The method according to claim 5 , wherein the first metadata comprises one or more of the following: a sender of the first message, a receiver of the first message, a timestamp, and a message type.

7. A method according to any preceding claim, comprising: encrypting the first logging message to generate the encrypted version of the first logging message; as well as The encrypted version of the first logging message is stored at the storage location.

8. A method according to any preceding claim, wherein the encrypted version of the first logging message is generated using a symmetric encryption scheme.

9. The method of claim 7 or 8, wherein the first logging message has a first logging message index, and wherein the method comprises: Generate a hierarchical key structure, the hierarchical key structure comprising one or more key layers, each layer comprising one or more corresponding keys with corresponding key indexes, wherein the hierarchical key structure comprises a first key branch, and wherein encrypting the first logging message comprises: using a first encryption key derived from a first message key, the first message key is located in the first key branch and has a first key index corresponding to the first logging message index.

10. The method of claim 9, wherein the first blockchain transaction comprises a first spendable output locked to a first payment public key, wherein the hierarchical key structure comprises a second key branch, wherein the first payment public key is derived from a first payment key, and wherein the first payment key is derived from a first message key, the first message key being located in the second key branch and having a first key index corresponding to the first logging message index.

11. The method of claim 10, wherein the first hash value is stored in the first spendable output.

12. The method of claim 10, wherein the first hash value is stored in an output other than the first spendable output.

13. A method according to any preceding claim, wherein the determining comprises: A determination is made as to whether the first message satisfies one or more conditions for logging a message.

14. A method according to any preceding claim, comprising: Determining a plurality of corresponding messages to be logged; generating a plurality of corresponding logging messages, wherein each corresponding logging message comprises a copy of the corresponding message; storing the plurality of respective logging messages and / or respective encrypted versions of the respective logging messages at the storage location; For each respective logging message of the plurality of respective logging messages, causing a respective blockchain transaction to be sent to the blockchain network for recording on the blockchain, wherein the respective blockchain transaction comprises a respective hash generated by hashing at least the respective logging message.

15. The method according to claim 14, comprising: encrypting each respective logging message to generate the respective encrypted version of the respective logging message; as well as A respective encrypted version of each of the respective logging messages is stored at the storage location.

16. The method of claims 9 and 15, wherein encrypting each respective logging message comprises: Using a corresponding encryption key, the corresponding encryption key is derived from a corresponding message key, the corresponding message key is located in the first key branch and has a corresponding key index corresponding to the corresponding logging message index.

17. The method of claims 10 and 16, wherein the respective blockchain transaction comprises a respective spendable output locked to a respective payment public key, wherein the respective payment public key is derived from a respective payment secret key, and wherein the respective payment key is derived from a respective message key, the respective message key being located in the second key branch and having a respective key index corresponding to the respective logging message index.

18. A method according to any preceding claim, comprising: receiving a request from a requestor to access the first logging message; The first logging message is sent to the requestor.

19. The method according to claims 7 and 18, comprising: In response to receiving the request, the encrypted version of the first logging message is decrypted.

20. The method according to claim 18 or 19, comprising: The first transaction identifier is provided to the requestor.

21. A method according to any one of claims 18 to 20, comprising: causing a second blockchain transaction to be sent to the blockchain network for recording on the blockchain, wherein the second blockchain transaction includes a second hash generated by double hashing at least the first logging message.

22. A method according to any one of claims 18 to 21 as appended to claim 9, comprising: re-encrypting the first logging message to generate a re-encrypted version of the first logging message; as well as The re-encrypted version of the first logging message is stored at the storage location, wherein re-encrypting the first logging message includes: using a second encryption key derived from the first message key, the first message key is located in the first key branch and has the first key index corresponding to the first logging message index.

23. A method according to claim 21 or 22 as dependent on claim 10, wherein the second blockchain transaction includes an input referencing the first spendable output of the first blockchain transaction, and wherein the second blockchain transaction includes a second spendable output locked to a second payment public key, wherein the second payment public key is derived from a second payment secret key, and wherein the second payment key is derived from the first message key, the first message key being located in the second key branch with the first key index corresponding to the first logging message index.

24. A method according to any one of claims 21 to 23 as appended to claim 2, wherein the second blockchain transaction has a second transaction identifier, and wherein the method comprises: The first transaction identifier mapped to the first logging message and / or the encrypted version thereof is appended with the second transaction identifier.

25. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device comprising one or more processing units, wherein the memory stores a code arranged to be executed on the processing device, the code being configured to execute the method according to any one of claims 1 to 24 when executed on the processing device.

26. A computer program embodied on a computer readable memory and configured to, when run on one or more processors, perform the method according to any one of claims 1 to 24.

Images