A method for running a program, a computer program product, a computer device, and a system

Abstract

A method includes retrieving a header file from a first transaction recorded on a blockchain maintained by multiple nodes in a blockchain network. The header file includes program header information and reference information, the reference information including one or more corresponding transaction IDs of one or more corresponding second transactions stored on the blockchain. Each second transaction includes a corresponding portion of the body of the program file, at least one of said portions including executable program code. The method includes retrieving the corresponding portion of the program file from at least one of the second transactions via the blockchain based on the reference information; and running the program including the program header information and the at least one retrieved portion.

Description

Technical Field

[0001] This disclosure relates to a file format for storing and initiating operable programs in blockchain transactions. Background Technology

[0002] A blockchain is a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain consists of a series of data blocks, where each block contains one or more transactions. Each transaction can refer back to previous transactions in the sequence, and can extend one or more blocks. Transactions can be included in new blocks by being submitted to the network. The process of creating new blocks is called "mining."

[0003] Each node in the network can have any one, two, or all of the following three roles: forwarding, mining, and storing. Forwarding nodes propagate transactions throughout the network. Mining nodes mine transactions into blocks. Storing nodes each store their own copy of the mined blocks in the blockchain. To record a transaction in the blockchain, one party sends the transaction to one of the nodes in the network for propagation. Mining nodes receiving the transaction can compete to mine it into a new block. Each node is configured to adhere to the same node protocol, which will include one or more conditions for confirming the validity of a transaction. Invalid transactions will not be propagated or mined into blocks. Assuming a transaction has been verified as valid and thus accepted on the blockchain, the transaction (including any user data) will therefore continue to be stored as an immutable public record at various nodes in the P2P network.

[0004] In an "output-based" model (sometimes called a 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 specifying the amount of digital assets, sometimes referred to as a UTXO ("unspent transaction output"). This output may also include a locking script specifying the conditions used to redeem the output. Each input includes a pointer to such an output in a previous transaction and may also include an unlocking script used to unlock the locking script pointing to the output. Thus, consider a pair of transactions, referred to as the first transaction and the second transaction (or the "target" transaction). The first transaction includes at least one output specifying the amount of digital assets and includes a locking script defining one or more conditions for unlocking that output. The second transaction (the 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; this unlocking script is used to unlock the output of the first transaction.

[0005] In this type of model, when a second transaction (the target transaction) is sent to the P2P network for propagation and recording in the blockchain, one of the validity criteria applied at each node will be: the unlocking script satisfies all of the conditions defined in one or more conditions in the locking script of the first transaction. Another condition will be: the output of the first transaction has not yet been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid based on any of these conditions will not propagate the transaction, nor will it include it in the block to be recorded in the blockchain.

[0006] Another transaction model is the account-based model. In this case, the amount of each transaction is not defined by referring to the UTXO of previous transactions in the past transaction sequence, but by referring to the absolute account balance. The current state of all accounts is stored individually in the blockchain by the mining nodes and is continuously updated.

[0007] Transactions in blockchains are typically used to transfer digital assets, i.e., data as a store of value. However, blockchains can also be used to implement layered additional functionalities. For example, blockchain protocols can allow the storage of additional payload data (i.e., user data or application content, rather than basic data relating to how the transaction functions as a transaction on the blockchain network) within a transaction. Such payload data could include, for example, non-spendable outputs of a transaction in an output-based model, such as via the OP_RETURN opcode included in a locking script, which terminates the locking script when a node in the blockchain network is running, and thus renders the output ineffective when transacted with the input of another transaction. Modern blockchains are constantly increasing the maximum data capacity that can be stored in a single transaction, enabling the incorporation of more complex data. For example, this can be used to store electronic documents, or even audio or video data, on the blockchain.

[0008] As is well known, a transaction's payload includes a small piece of executable code. That is, in an output-based model, this includes code other than the lock and unlock scripts, or in an account-based model, code other than the active portion of the smart contract. Instead, the executable code provides additional auxiliary or "layer 2" (i.e., application layer) functionality. In other words, from the perspective of the transaction protocol adopted on the blockchain network, the executable code is identical to any other payload data. Clients can download the code by examining a portion of the blockchain stored on a storage node within the blockchain network and accessing the code from the payload of the relevant transaction. The code can then be run on the local client computer. Summary of the Invention

[0009] However, although it is known that a small piece of executable code is included in the payload of a transaction, to the inventors’ knowledge, no self-contained program has ever been included on a blockchain.

[0010] Blockchain offers a decentralized and tamper-proof alternative to traditional database servers, potentially revolutionizing the storage, access, and distribution of data. However, due to its immaturity, it lacks standardized architectures and network protocols for easily building applications and software, and its underlying technology remains largely unknown. For blockchain to become a fundamental infrastructure like the internet, an easy-to-use protocol must be developed for users and software to access data stored on the blockchain.

[0011] The following discloses a file format suitable for standardizing a range of blockchain-enabled applications. This disclosure establishes a method for storing executable software (i.e., runnable code) on a blockchain, which can be refactored locally to run on a single computer with permitted access. This introduces a novel blockchain-based file format for files stored on a blockchain that can run locally or on a virtual machine.

[0012] According to one aspect disclosed herein, a method for running a program is provided. The method includes the following steps performed on a consumer's computer device. First, the method includes retrieving a header file from a first transaction recorded on a blockchain maintained by multiple nodes in a blockchain network. The header file includes: program header information and reference information, which includes one or more corresponding transaction IDs of one or more corresponding second transactions stored on the blockchain. Each second transaction includes a corresponding portion of the body of the program file, at least one portion of which includes executable program code. Then, the method includes retrieving the corresponding portion of the program file from at least one of the one or more second transactions via the blockchain, based on the reference information; and running the program including the program header information and at least one retrieved portion.

[0013] In one embodiment, permissions can be encoded in the transaction storing the file or in the file itself to allow control over who can execute the file.

[0014] Implementations may also integrate blockchain access into high-level programming languages ​​to facilitate interaction between native software and the blockchain. A request-response protocol may be provided for accessing data referenced by transaction hyperlinks in a blockchain hypertext file. For example, the request-response protocol could be implemented using a hypertext-enabled wallet to make requests via the OP_RETURN flag.

[0015] This disclosure also discusses exemplary system and computer architectures, as well as how components of computer hardware and software can interact in implementing the disclosed techniques. Attached Figure Description

[0016] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments can be implemented, descriptions will now be provided by way of example only, with reference to the accompanying drawings, in which:

[0017] Figure 1 This is a schematic block diagram of a system for implementing blockchain.

[0018] Figure 2 The illustration shows some examples of transactions that can be recorded in the blockchain;

[0019] Figure 3 This is a schematic block diagram of a set of transaction examples used in a stored procedure.

[0020] Figure 4 This is a schematic block diagram of a client application.

[0021] Figure 5 The blockchain-based file format according to embodiments herein is illustrated schematically.

[0022] Figure 6 This is a schematic block diagram of an exemplary computer architecture for implementing the technology disclosed herein.

[0023] Figures 7A to 7B An exemplary process for accessing and reconstructing an operable program file is shown according to embodiments disclosed herein. Detailed Implementation

[0024] Exemplary System Overview

[0025] Figure 1 An exemplary system 100 for implementing blockchain 150 is shown. System 100 includes a packet-switched network 101, typically a wide area network such as the Internet. The packet-switched network 101 includes a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, and different nodes 104 belong to different peers. Each node 104 includes a processing device containing one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of 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 memory (EEPROMs), and / or optical media such as optical disc drives.

[0026] Blockchain 150 comprises a series of data blocks 151, with a corresponding copy of blockchain 150 maintained at each of the multiple nodes in the P2P network 160. Each block 151 in the blockchain includes one or more transactions 152, where 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 typically uses a specific 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 representing the value of digital assets belonging to user 103 whose output is cryptographically locked (requiring the user's signature to unlock, thereby enabling redemption or spending). Each input points to the output of a previous transaction 152, thus linking these transactions.

[0027] At least some of the nodes in node 104 act as forwarding nodes 104F, forwarding and thus propagating transaction 152. At least some of the nodes in node 104 act as mining nodes 104M, mining block 151. At least some of the nodes in node 104 act as storage nodes 104S (sometimes also called "full copy" nodes), each storage node storing a corresponding copy of the same blockchain 150 in its respective storage. Each mining node 104M also maintains a pool 154 of transactions 152 waiting to be mined into block 151. A given node 104 can be any combination of forwarding node 104, mining node 104M, storage node 104S, or two or all of these nodes.

[0028] In a given current transaction 152j, the inputs (or each input) include a pointer that references the output of a previous transaction 152i in the transaction sequence, specifying that the output will be redeemed or "spent" in the current transaction 152j. Typically, the current transaction can be any transaction in pool 154 or any block 151. While the existence and verification of the previous transaction 152i are required to ensure the validity of the current transaction, the previous transaction 152i does not necessarily exist when the current transaction 152j is created or even sent to network 106. Therefore, in this context, "previous" refers to the predecessor in the logical sequence linked by the pointer, not necessarily the creation or sending time in the time series, thus not necessarily excluding the possibility of out-of-order creation or sending of transactions 152i or 152j (see the discussion of orphaned transactions below). The previous transaction 152i can also be referred to as the preceding transaction or predecessor transaction.

[0029] The input to the current transaction 152j also includes the signature of user 103a to whom the output of the previous transaction 152i is locked. In turn, the output of the current transaction 152j can be cryptographically locked to a new user 103b. Therefore, the current transaction 152j can transfer the amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to split the input amount among multiple users (one of which can be the original user 103a for modification). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and redistribute them to one or more outputs of the current transaction.

[0030] The above can be referred to as an "output-based" transaction protocol, sometimes also called a protocol for unspent transaction outputs (UTXOs) (where the output is called a UTXO). A user's total balance is not defined by any single number stored in the blockchain; instead, the user needs a special "wallet" application 105 to organize all of the user's UTXO values, which are scattered across many different transactions 152 in the blockchain 151.

[0031] As part of the account-based transaction model, another type of transaction protocol can be called an "account-based" protocol. In the account-based case, each transaction's amount is not defined by referencing the UTXO of previous transactions in a past transaction sequence, but rather by referencing the absolute account balance. The current state of all accounts is stored individually in the blockchain by the mining nodes and is continuously updated. In such systems, transactions are ordered using the account's running transaction history (also known as "positions"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. Furthermore, optional data fields can also be used to sign transactions. For example, if a data field contains the ID of a previous transaction, that data field can point to that previous transaction.

[0032] Regardless of the type of transaction protocol used, when user 103 wishes to execute a new transaction 152j, they wish to send the new transaction from their computer terminal 102 to one of the nodes 104 of the P2P network 106 (currently typically a server or data center, but in principle it could be another user terminal). This node 104 checks the validity of the transaction according to the node protocol applied at each node in the node 104. The details of the node protocol will correspond to the type of transaction protocol used in the relevant blockchain 150, together forming the entire transaction model. The node protocol typically requires node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, depending on the previous transaction 152i in the ordered sequence of transactions 152. In the case of output-based transactions, this may include checking whether the user's cryptographic signature contained in the input of the new transaction 152j matches a condition defined in the output of the previous transaction 152i that the new transaction spends, where the condition typically includes at least checking whether the cryptographic signature in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction points. In some transaction protocols, conditions may be defined, at least in part, by custom scripts included in the inputs and / or outputs. Alternatively, this may be determined solely by the node protocol, or through a combination thereof. Regardless of the approach, if the new transaction 152j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocol, thereby forwarding the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction propagates throughout the network of nodes 104.

[0033] In the output-based model, whether a given output (e.g., a UTXO) is spent is defined as whether it has been validly redeemed by the input of another subsequent transaction 152j, according to the node protocol. Another condition for a transaction to be valid is that the output of the previous transaction 152i that it attempted to spend or redeem has not yet been spent / redeemed by another valid transaction. Similarly, if invalid, transaction 152j will not be propagated or recorded in the blockchain. This prevents double-spending, i.e., a spender spending the output of the same transaction more than once. On the other hand, the account-based model prevents double-spending by maintaining an account balance. Because a defined transaction order also exists, the account balance has a single defined state at any given time.

[0034] Besides verification, at least some nodes in node 104M compete to create transaction blocks in a process called mining. At mining node 104M, new transactions are added to a pool of valid transactions that have not yet appeared in the block. The mining nodes then compete to assemble a new valid block 151 of transactions 152 from transaction pool 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "random number" value so that when the random number is concatenated with transaction pool 154 and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition could be that the output of the hash value has a certain predefined number of leading zeros. A characteristic of hash functions is that they have unpredictable outputs relative to their inputs.

[0035] The first mining node 104M to solve the puzzle announces the solution on network 106, providing the solution as proof. Other nodes 104 in the network can then easily check the solution (once a solution with a hash value is provided, it can be directly checked whether the solution makes the output of the hash value satisfy the condition). Based on the winner's announced solution being checked at each of these nodes, the winner's pool of transactions 154 that solved the puzzle is subsequently recorded in blockchain 150 as a new block 151 by at least some of the nodes 104 acting as storage nodes 104S. A block pointer 155 is also assigned to a new block 151n pointing to the previously created block 151n-1 in the blockchain. Once created, block 151 is immutable because it is identified and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointer 155 also imposes order on block 151. Since transaction 152 is recorded in ordered blocks at each storage node 104S in the P2P network 106, an immutable public ledger of transactions is provided.

[0036] It should be noted that different mining nodes 104M vying to solve the puzzle at any given time may perform this operation based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they begin searching for a solution. The person solving the corresponding puzzle first defines the transactions 152 contained in the new block 151n and updates the current unmined transaction pool 154. Then, mining nodes 104M continue to compete to create blocks from the newly defined unmined pool 154, and so on. Furthermore, there are protocols for resolving any potential "forks," where two mining nodes 104M solve the puzzle for each other in a very short time, thus propagating a conflicted view of the blockchain. In short, the fork with the longest possible direction becomes the final blockchain 150.

[0037] In most blockchains, the winning mining node 104M automatically receives a special type of new transaction as a reward. This special type of transaction is sometimes called a "generating" transaction, and it automatically forms part of a new block 151n.

[0038] Due to the computational resources involved in mining, each mining node in at least the mining nodes 104M typically takes the form of a server, which includes one or more physical server units, or even an entire data center. Each forwarding node 104M and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 may take the form of a single user terminal or a group of user terminals networked together.

[0039] Each node 104's memory stores software configured to run on the node 104's processing device to perform its corresponding role and process transactions 152 according to the node protocol. It should be understood that any action attributed to 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 in lower layers such as the operating system layer or protocol layer, or in any combination of these layers. Furthermore, the term "blockchain" as used herein refers to a general term for a general type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0040] Each of the multiple parties 103 acting as consumer users has its computer device 102 connected to network 101. They act as payers and payees in transactions but do not necessarily participate in mining or disseminating transactions on behalf of other parties. They do not necessarily run mining protocols. 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, but for convenience, they are not shown. Each party 103 may be an individual or organization. For illustrative purposes only, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob herein may be replaced by "first party" and "second party," respectively.

[0041] Each party 103's computer device 102 includes a corresponding processing means, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, application-specific processors, and / or FPGAs. Each party 103's computer device 102 also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may include one or more memory cells in the form of one or more memory media, such as magnetic media like hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory on each party 103's computer device 102 stores software including corresponding instances of at least one client application 105 configured to run on the processing means. It should be understood that any action attributed herein to a given party 103 can be performed by software running on the processing means of the respective computer device 102. Each party 103's computer device 102 includes at least one user terminal, such as a desktop or laptop computer, tablet computer, smartphone, or wearable device such as a smartwatch. The computer device 102 of the given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0043] The client application 105 includes at least a "wallet" function. This has two main functions. One function is to enable the corresponding user 103 to create, sign, and send transactions 152 intended to be propagated throughout the network of nodes 104 and thus included in the blockchain 150. The other function is to report the amount of digital assets currently held by the corresponding party. In an output-based system, this second function includes organizing the amounts defined in the outputs of the various transactions 152 belonging to the relevant party scattered across the blockchain 150.

[0044] Note: While various client functionalities can be described as being integrated into a given client application 105, this is not necessarily limiting. Rather, any client functionality described herein can be implemented in a suite of two or more different applications, such as through an API or as a plugin for one application. More colloquially, client functionalities can be implemented at the application layer or at a lower layer such as the operating system, or any combination of these layers. The following description is based on client application 105, but it should be understood that this is not limiting.

[0045] An instance of client application or software 105 on each computer device 102 is operatively coupled to at least one forwarding node among the forwarding nodes 104F of the P2P network 106. This enables the wallet functionality of client 105 to send transaction 152 to network 106. Client 105 can also contact one, some, or all of the storage nodes 104 to query in blockchain 150 any transaction for which the corresponding party 103 is the recipient (or actually check transactions of other parties in blockchain 150, since in this embodiment, blockchain 150 is a public facility that provides trust in transactions to some extent through its public visibility). The wallet functionality on each computer device 102 is configured to formulate and send transaction 152 according to a transaction protocol. Each node 104 runs software configured to verify the validity of transaction 152 according to a node protocol and, in the case of forwarding node 104F, forward transaction 152 to propagate such transactions throughout network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. All transactions 152 in blockchain 150 use the same transaction protocol (although the transaction protocol may allow different transaction subtypes to exist within it). All nodes 104 in network 106 use the same node protocol (although they may distinguish and process different transaction subtypes according to the rules defined for that subtype, and different nodes may also play different roles, thus realizing different corresponding aspects of the protocol).

[0046] As described above, blockchain 150 includes a series of blocks 151, each block 151 comprising a set of one or more transactions 152. Each block 151 also includes a block pointer 155, which points to previously created blocks 151 in the blockchain to define the order of blocks 151. Blockchain 150 also includes a pool of valid transactions 154, awaiting inclusion in new blocks. Each transaction 152 (except for a generating transaction) includes pointers to previous transactions to define the order of the transaction sequence (note: the sequence of transactions 152 can branch). The blockchain of blocks 151 traces back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more early original transactions 152 in blockchain 150 point to the genesis block 153, not to previous transactions.

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

[0048] If the newly received transaction 152j passes the validity test (i.e., under the condition of being "valid"), any storage node 104S that receives transaction 152j will add the new valid transaction 152 to pool 154 in the replica of blockchain 150 maintained at that node 104S. Further, any forwarding node 104F that receives transaction 152j will then propagate the valid transaction 152 to one or more other nodes 104 in the P2P network 106. Since each forwarding node 104F applies the same protocol, it is assumed that transaction 152j is valid, meaning that the transaction will quickly propagate throughout the P2P network 106.

[0049] Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also recorded immutably.

[0050] Different nodes 104 can initially receive different instances of a given transaction, and thus have conflicting views about which instance is "valid" before an instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then finds that a second instance has been recorded in blockchain 150, then that node 104 must accept this and discard (i.e., consider) its initially accepted unmined instance invalid.

[0051] UTXO-based model

[0052] Figure 2 An exemplary transaction protocol is illustrated. This is an example of a UTXO-based protocol. Transaction 152 (referred to as "Tx") is the basic data structure of blockchain 150 (each block 151 includes one or more transactions 152). The following description will refer to protocols based on outputs or UTXOs. However, this is not limited to all possible embodiments.

[0053] In the UTXO-based model, each transaction (“Tx”) 152 includes a data structure comprising 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 yet been redeemed). The UTXO specifies the amount of digital asset (a store of value). It may also contain the transaction ID of its source transaction and other information. The transaction data structure may also include a header 201, which may include size indicators for the input fields 202 and the output fields 203. The header 201 may also include the transaction ID. In this embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the original transaction 152 submitted to the mining node 104M.

[0054] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of related digital assets to Bob 103b. Figure 2 In the middle, Alice's new transaction 152j is marked as " Tx 1 The new transaction acquires the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence, and transfers at least a portion of such an amount to Bob. Figure 2 In the middle, the previous transaction 152i is marked as " Tx 0 ". Tx 0 and Tx 1 It is just an arbitrary marker, and it does not necessarily mean Tx 0The first transaction in Blockchain 151 and Tx 1 The next transaction in pool 154. Tx 1 It can point to any previous (i.e. preceding) transaction that still has an unspent output 203 locked to Alice.

[0055] When Alice creates her new deal Tx 1 At that time, or at least when she sent the new transaction to network 106, the previous transaction Tx 0 It may already be valid and included in blockchain 150. The transaction may now be included in a block in block 151, or it may still be waiting in pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx 0 and Tx 1 They can be created and sent together to network 102; or, if the node protocol allows buffering "orphaned" transactions, Tx 0 Even in Tx 1 Then it is sent. In the context of transaction sequences in this article, the terms "previous" and "subsequent" 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 can also be replaced with "predecessor" and "successor," "first" and "second," or "parent" and "child," etc. This does not necessarily refer to the order in which they are created, sent to network 106, or arrive at any given node 104. However, a subsequent transaction (subsequent transaction or "child transaction") that points to a previous transaction (first transaction or "parent transaction") will not be valid unless the parent transaction is valid. Child transactions that arrive at node 104 before the parent transaction are considered orphaned transactions. Depending on the node protocol and / or mining node behavior, they may be discarded or buffered for a period of time to wait for the parent transaction.

[0056] Previous transactions Tx 0 One or more outputs 203 include a specific UTXO, tagged as UTXO 0 Each UTXO includes a value representing the amount of digital assets and a locking script. This locking script defines the conditions that the unlocking script in input 202 of a subsequent transaction must meet to make the subsequent transaction 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: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to whom the previous transaction was locked.

[0057] A 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" (S capitalized). The locking script specifies the information required for the spend transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the transaction output. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to satisfy the locking script guidelines. For example, it might contain Bob's signature. The unlocking script appears in the transaction input 202.

[0058] Therefore, in the example shown, Tx 0 Output 203 UTXO 0 Including the locking script [Checksig] P A This locking script requires Alice's signature (Sig). P A to redeem UTXO 0 (Strictly speaking, it is for the purpose of enabling those who attempt to redeem) UTXO 0 Subsequent transactions are valid. [Checksig] P A Contains the public key from Alice's public-private key pair. P A . Tx 1 Input 202 includes back pointers Tx 1 pointers (e.g., via their transaction IDs) TxID 0 In the embodiment, this refers to the entire transaction. Tx 0 (hash value). Tx 1 Input 202 includes Tx 0 Chinese logo UTXO 0 The index, in order to Tx 0 It is identified in any other possible output. Tx 1 Input 202 further includes an unlock script. <Sig P AThe unlocking script includes Alice's cryptographic signature, which she creates by applying the private key from her key pair to a predetermined portion of data (sometimes referred to in cryptography as a "message"). The data (or "message") that Alice needs to sign to provide a valid signature can be defined via a locking script, a node protocol, or a combination thereof.

[0059] When new transactions Tx 1 Upon arrival at node 104, the node applies the node protocol. This involves running a locking script and an unlocking script together to check if the unlocking script meets the conditions defined in the locking script (wherein the conditions may include one or more criteria). In this embodiment, this involves juxtaposing two scripts:

[0060] <Sig P A > < P A > || [Checksig P A ]

[0061] Here, "||" indicates concatenation, "<...>" indicates placing data on a stack, and "[...]" indicates a function consisting of the unlock script (in this example, a stack-based language). Similarly, scripts can be run one after another using a shared stack, instead of concatenating them. Regardless of the method used, when run together, the scripts use Alice's public key. P A (including) Tx 0 (in the output of the locking script) to authenticate. Tx 1 The input of the locking script must include the signature of the expected portion of the data when Alice signs it. The expected portion of the data itself (the "message") also needs to be included. Tx 0 In order to perform this authentication. In an embodiment, the signature data includes the entire Tx 0 (Therefore, there is no need to include a separate element to specify the part of the signature data in plaintext, because it already exists on its own.)

[0062] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Essentially, if Alice has encrypted and signed a message using her private key, then given Alice's public key and the message in plaintext (the unencrypted message), other entities such as Node 104 must have already signed the encrypted version of the message to authenticate it. Signing typically involves hashing the message, signing the hash value, and attaching this to the plaintext version of 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 specific data segment or transaction portion, etc., can mean signing the hash value of that data segment or transaction portion.

[0063] if Tx 1 The unlock script in the middle satisfies Tx 0 One or more conditions specified in the locking script (therefore, in the example shown, if in Tx 1 If Alice's signature is provided and authenticated, then node 104 considers... Tx 1 Valid. If it's mining node 104M, this means it will be added to transaction pool 154. If it's forwarding node 104F, it will transact... Tx 1 Forwarded to one or more other nodes 104 in network 106, thus propagating throughout the network. Once Tx 1 Valid and included in Blockchain 150, this will put Tx 0 In UTXO 0 Defined as already spent. Please note, Tx 1 This only applies when spending an unspent output of transaction 203. If you attempt to spend an output that has already been spent in another transaction 152, it will not work even if all other conditions are met. Tx 1 This will also be invalid. Therefore, node 104 also needs to check previous transactions. Tx 0 Whether the UTXO referenced in the code has been spent (has become a valid input to another valid transaction) is important. This is one of the reasons why the order in which blockchain 150 imposes the definition on transaction 152 is important. In practice, a given node 104 could maintain a separate database marking the UTXOs 203 that have been spent in transaction 152, but the final definition of whether a UTXO has been spent depends on whether it has become a valid input to another valid transaction in blockchain 150.

[0064] This is another failure criterion in most transaction models 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. Therefore, such a transaction will not be propagated or mined into block 151.

[0065] Please note that in a UTXO-based transaction model, a given UTXO must be used as a whole. You cannot "leave" a portion of the amount defined as spent in the UTXO while simultaneously spending another portion. However, the amount of a UTXO can be divided among multiple outputs of the next transaction. For example, Tx 0 of UTXO 0 The amount defined in can be Tx 1 This involves splitting the data between multiple UTXOs. Therefore, if Alice doesn't want to... UTXO 0 All the amounts defined in the document are given to Bob, and she can use the remainder in... Tx 1 In the second output, you either make change yourself or pay the other party.

[0066] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere in blockchain 150. Therefore, typically, the assets of the given party 103 are scattered across the various UTXOs of transactions 152 throughout blockchain 150. No single number defining the total balance of the given party 103 is stored anywhere in blockchain 150. The wallet function of the client application 105 serves to consolidate the various UTXO values ​​locked to the respective party and not yet spent in other subsequent transactions. This is achieved by querying a copy of blockchain 150 stored at any storage node 104S (e.g., the storage node 104S most recently or best connected to the respective party's computer device 102).

[0067] Please note that script code is typically represented using diagrams (i.e., non-precise language). For example, it might be written as [Checksig] P A ] indicates [Checksig P A ] = OP_DUP OP_HASH160 <H( P AOP_EQUALVERIFY OP_CHECKSIG. "OP_..." refers to a specific opcode in the scripting language. OP_CHECKSIG (also known as "Checksig") is a scripting opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrences of the signature ('sig') in the script are removed, but additional requirements, such as hash puzzles, are retained in transactions verified by 'sig' inputs. Similarly, OP_RETURN is a scripting language opcode used to create a non-spendable output for a transaction, which can store metadata in the transaction, thus immutably recording the metadata in the blockchain. For example, the metadata may include files that need to be stored in the blockchain.

[0068] sign P A This is a digital signature. In this embodiment, it is based on ECDSA using elliptic curve secp256k1. The digital signature signs a specific segment of data. In this embodiment, for a given transaction, the signature will sign part of the transaction input and all or part of the transaction output. Signing a specific portion of the output depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature, used to select the output to be signed (and therefore fixed at the time of signing).

[0069] A locking script, sometimes called a "scriptPubKey," refers to the fact that it includes the public key of the party to whom the corresponding transaction is locked. An unlocking script, sometimes called a "scriptSig," refers to the fact that it provides the corresponding signature. However, more generally speaking, in all applications of Blockchain150, the conditions for UTXO redemption do not necessarily include signature authentication. Furthermore, scripting languages ​​can be used to define one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" are preferable.

[0070] Client software

[0071] Figure 4An exemplary implementation of a client application 105 for implementing embodiments of the present disclosure is shown. The client application 105 includes a transaction engine 404 and a user interface (UI) layer 401. According to the scheme discussed above, the transaction engine 404 is configured to implement basic transaction-related functions of the client 105, such as formulating a transaction 152, receiving and / or sending transactions and / or other data via a side channel 301, and / or sending transactions for propagation via a P2P network 106. Further, according to the embodiments disclosed herein, the transaction engine 401 of at least Bob's client 105b (and possibly other clients) further includes a data transfer engine 403, a program launcher 405, and an optional hyperfile engine 402. The hyperfile engine 402, data transfer engine 403, and transaction engine 404 together constitute a "smart wallet" function 406 (although the hyperfile engine 402 is an optional part of this function). The functionality of these different modules will be discussed in more detail later. The smart wallet function 406 is also simply referred to herein as a "smart wallet".

[0072] UI layer 401 is configured to present a user interface via user input / output (I / O) methods of the corresponding user's computer device 102, including outputting information to the corresponding user 103 via user output methods of device 102, and receiving input from the corresponding user 103 via user input methods of device 102. For example, user output methods may include one or more screens (touch or non-touchscreen) providing visual output, one or more speakers providing audio output, and / or one or more haptic output devices providing haptic output, etc. User input methods may include, for example, an input sensor matrix of one or more touchscreens (which may be the same as or different from the display used for output methods); one or more cursor-based devices, such as a mouse, trackpad, or trackball; one or more microphones and voice or sound recognition algorithms for receiving voice or sound input; one or more gesture-based input devices for receiving input in the form of manual or body gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0073] The transaction engine 403 of the smart wallet 406 can access the code stored in the payload of transaction 152 on blockchain 150 (e.g., in the unspendable output of an output-based transaction model) and transmit the code from there to the program initiator 405. The code initiator 405 runs this code and presents any user-visible program effects to the user 103b through the UI layer 401. Specifically, according to the embodiments disclosed herein, the code initiator 405 is configured to reconstruct program files from multiple transactions 152 on blockchain 150 and run the reconstructed program files. This aspect will be discussed in more detail later.

[0074] Note: While the various functionalities described herein may be described as being integrated into the same client application 105, this does not necessarily constitute a limitation. Instead, they can be implemented in a suite of programs consisting of two or more different applications, such as one application acting as a plug-in to another or interfaced via an API (Application Programming Interface). For example, the functionality of any of modules 401, 402, 403, 404, and 405 can be implemented in any combination of two or more independent applications. Furthermore, it is not excluded that some or all of the described functionalities may be implemented, for example, at the operating system layer. Wherever reference is made to a single or given application 105 or the like anywhere in this document, it should be understood that this is merely illustrative, and more generally, the described functionalities can be implemented in any form of software.

[0075] Blockchain-based program file format

[0076] To support the integration of blockchain technology as a fundamental technological infrastructure, a simple process should be preferred for building and accessing higher-level applications. To achieve this, developers need to be provided with standard data formats that can be included not only within transactions but also in software built to execute code stored in blockchain transactions. This may involve dedicated smart wallets that can interact with the blockchain at any time for data requests and facilitate software connectivity on local computers, central processing units (CPUs), and computer memory. By integrating blockchain data into traditional programming languages, a wider range of applications can be developed on the blockchain to support more secure and tamper-proof desktop and mobile applications.

[0077] The system disclosed in this paper facilitates direct interaction between software and blockchain by providing a file format that supports transactions (containing programming languages ​​other than scripting languages ​​used for locking and unlocking scripts, etc.). In modern programming languages ​​such as C, C++, and Java, there exists a system called... pointer An object that acts as a reference to a specific memory address. This disclosure provides a method that can be called... Blockchain pointer A similar object, whose pointer can be integrated into a programming language to act as a reference to some transaction data or metadata.

[0078] Some embodiments may also employ a system for requesting and responding to data requests via linked hypertext files referenced by their TxIDs.

[0079] Figure 5 A blockchain-based program file format according to an embodiment disclosed herein is shown for storing program files across multiple transactions 152 on blockchain 150. Figure 5The left panel a) shows a program file in fragmented form, stored across multiple transactions 152 on blockchain 150. The fragmented program file includes a header file 501 and one or more body sections 502i…502n, the header file being stored in a first transaction 152Y on blockchain 150, and each body section being stored in a corresponding second transaction 152Z on the blockchain (see also...). Figure 6 (This will be discussed in more detail later). In the output-based model, each header file 501 and body portion 502 can be stored in the non-expendable output (e.g., UTXO) of its corresponding first or second transaction 152Y, 152Z.

[0080] Figure 3 An example of this aspect is illustrated schematically. In the following exemplary scenario, Alice 103a is the provider. Alice formulates first and second transactions 152Y, 152Z and broadcasts these transactions to blockchain network 106 (directly or via a third party) to record these transactions on blockchain 150. Bob 103b is the consumer. Bob reads header file 501 and section 502 from the corresponding first and second transactions 152Y, 152Z to reconstruct program file 507.

[0081] like Figure 3As shown, in the output-based model, the first transaction 152Y includes at least one input 202Y that points to the outputs of some other preceding transactions 152 on blockchain 150. The outputs of the preceding transactions may be locked to Alice's output, meaning Alice pays an amount of her own digital assets to record the first transaction 152Y on blockchain 150. Typically, the first transaction 152Y will also need to include at least one spendable output 203Y0. This will include a locking script that locks output 203Y0 to the recipient. The locking script is written in a relevant scripting language recognized by the transaction protocol adopted by blockchain network 106, such as Script. The amount specified in the spendable output 203Y0 can be a small (i.e., negligible) amount and / or the recipient can be Alice herself, meaning Alice pays herself to record the first transaction 152Y on blockchain 150. Alternatively, it is not excluded that a transaction model or protocol may be adopted that does not necessarily require the inclusion of a spendable output in every transaction. Regardless of the approach used, the first transaction 152Y also includes an unspendable output 203Y1. In an embodiment, this is achieved by including a special opcode in a scripting language within the locking script of the unspendable output 203Y1. This opcode, when executed on a node 104 of the blockchain network 106, terminates the execution of the locking script containing that opcode. This allows any other arbitrary payload not written in a scripting language to be included in the unspendable output 203Y1 without otherwise affecting the functionality of transaction 152Y as a transaction on the blockchain network 106.

[0082] According to the embodiments disclosed herein, the mechanism is used to include header file 501 in the unspendable output 203Y1 of the first transaction 152Y, and thus store header file 501 in the first transaction 152Y on blockchain 150. Header file 501 is compiled in a format or language other than a scripting language (e.g., Script) used in the locking script, according to the transaction protocol adopted by blockchain network 106.

[0083] A similar mechanism can be used to include each body portion 502 in the unspendable output 203Z1 of the corresponding second transaction 152Z on blockchain 150. Each body portion 502 includes program code written in a language other than a scripting language (e.g., Script) used in the locking script.

[0084] In alternative implementations, it is not excluded that header file 501 and body portion 502 may be included as transaction payloads, depending on different mechanisms in other transaction protocols or models. For example, in an alternative implementation, blockchain network 106 may employ an account-based model, and each header file 501 and body portion 502 may be included in the data fields or smart contract of the corresponding transaction 152Y, 152Z. In this case, each header file 501 and body portion 502 will be compiled in a language other than the language used to execute smart contracts recognized by node 104.

[0085] Return to Figure 5 The header file 501 includes at least a portion of the program header information 503, and a list of one or more transaction IDs 504. The program header information 503 includes basic header information for the program file, which will form at least a portion of the header of the program file 507 once refactored. This may include, for example, any, more, or all of the following: the program version number, the version number of the target computer system, the size of the program or the refactored program file, a description, reserved variables, a date / timestamp, and / or a checksum used to check that the refactored program is error-free.

[0086] The transaction IDs contained in list 504 serve as pointers to the corresponding body portion 502 of the program file, which is stored in the corresponding other second transaction 152Z on blockchain 150. For example... Figure 5 As shown in the right panel (b), the consumer Bob 103b reconstructs an instance of the program file 507 in a non-fragmented form by combining the header information header 503 with each of one or more body parts 502i…502n pointed to by the corresponding transaction ID 504 contained in the header file 501.

[0087] In an embodiment, header file 501 may also include instructions for one or more conditions 505, and code stubs 506 for evaluating one or more conditions. The functionality of these parts will be discussed in more detail later.

[0088] Figure 6 An exemplary computer architecture for a consumer-side computer device 102b, also referred to herein as a client device, is shown. This architecture can be implemented on a single, local user device or distributed across multiple devices, which may include user devices, server resources, or a combination thereof.

[0089] Client device 102b includes hardware 608, input / output (I / O) devices 607, and software. Hardware 608 includes at least one processor 609, such as a CPU. Hardware 608 also includes random access memory (RAM) and hard disk storage 611 (i.e., non-volatile memory, such as a hard disk or solid-state drive (SSD)). The central processing unit (CPU) 609 includes electronic circuitry that executes machine-level instructions by performing arithmetic logic and input / output operations. RAM 610 utilizes the CPU 609 to provide temporary data storage and machine-level instructions, acting as an intermediary between the software and the hard disk 611.

[0090] User 103b can interact with input / output device 607, and commands are translated into instructions / data that are relayed to software in operating system 602. Several schemes for I / O device 607 have been referenced previously. Figure 4 Let's have a discussion.

[0091] The software includes an operating system 602, a program launcher 405 running on the operating system 602, and a smart wallet function 406. The operating system 602 includes system software that manages computer hardware and software resources.

[0092] The following definitions may also be used in this article.

[0093] Virtual machine: A simulated computer system.

[0094] System virtual machine: A virtual machine that provides the functionality to execute an entire operating system. The virtual machine monitor uses native execution (machine code, executed directly by the computer's CPU) to share and manage hardware, allowing multiple isolated environments to exist on a single physical machine.

[0095] Virtual machine monitor: Computer software, firmware, or hardware that creates and runs virtual machines.

[0096] Dynamic linker: Part of the operating system, it loads and links the shared libraries required by the executable file during execution ("runtime") by copying the contents of libraries from persistent storage to RAM and populating jump tables and relocating pointers. The specific operating system and executable format determine how the dynamic linker works and how it is implemented.

[0097] Library: A collection of resources used by a computer program (configuration data, documentation, pre-written code and subroutines, categories, values ​​or type specifications).

[0098] Shared libraries: Files shared by the executable file and further shared object files. At runtime, the modules used load these shared objects into memory as individual files, rather than having them copied by the linker when creating a single, monolithic executable for the program.

[0099] Assembler: A computer program that creates object code by converting combinations of mnemonics and syntax used for operation and addressing modes into their numerical equivalents (machine code).

[0100] Compiler: A computer program that translates computer code written in one programming language into another language (usually from a high-level language to a low-level language) to create an executable program.

[0101] Executable file or executable program: A file that enables a computer to perform a specified task according to coded instructions. It should also be noted that, most generally, the terms "execution" or "executable" in this document can refer to any method of running software, and are not necessarily limited to executing, for example, low-level machine code instructions. For instance, "execution" in this document can also refer to compiling and running a high-level language, assembling and running an assembly-level language, or interpreting an interpreted language.

[0102] Figure 6 The transaction 152 stored on blockchain 150 on blockchain network 106 is also shown, including first transaction 152Y and second transaction 152Z.

[0103] In operation, consumer Bob 103b uses at least one I / O device 607 to select access to header file 501 from a first transaction 152Y stored on blockchain 150 (it should be understood that "first" and "second" as used in this context are simply arbitrary tags). In some embodiments, this can be achieved by selecting a hyperlink in the hypertext file 601. For example, this can be compiled with HTML, but enhanced with additional types of tags that allow links to the transaction ID of transaction 152 on blockchain 150, rather than a URL in a traditional hyperlink. In such embodiments, the hypertext engine 402 of smart wallet 406 presents the hypertext file 601 to Bob through UI layer 401 and detects the selection of a hyperlink. In response, it triggers the data transfer engine 403 of wallet 406 to retrieve header file 501 from the linked transaction (first transaction 152Y) on blockchain 150 via blockchain network 106 (by querying storage node 104S).

[0104] The hypertext file 601 can be accessed via local storage on the Bob computer device 102b or via a network. Alternatively, the hypertext file 601 itself can be stored as payload data in source transaction 152X on blockchain 150, for example, in the unspendable output of an output-based model. In this case, during the preparation step, the data transfer engine 403 accesses the hypertext file 601 from source transaction 152X on the blockchain via blockchain network 106 and transmits it to the hypertext engine 402 for presentation to user 103b.

[0105] In an alternative embodiment, there is no need to link the hypertext file 601 to the header file 501. Instead, the data transfer engine 403 can retrieve the header file 501 by querying the blockchain 150 in a known manner. For example, the spendable output 203Y0 (potentially a small amount) of the first transaction 152Y can be sent to Bob 103b, allowing him to find it on the blockchain 150 using conventional wallet functionality. And / or Alice 103a or a third party can inform Bob of the address of the first transaction 152Y via an off-chain side channel (not shown). In these embodiments, the hypertext engine 402 is not required as part of the wallet functionality 406.

[0106] Regardless of the access method, header file 501 is retrieved via data transfer engine 403 of wallet 406 and transmitted to program initiator 405. Program initiator 405 is configured to read one or more transactions 504 from the retrieved header file 501 and use these transactions as pointers to cause data transfer engine 403 of wallet 406 to retrieve the corresponding body portion 502 from the corresponding second transaction 502 on the blockchain (also by querying storage node 104S). Program initiator 405 then merges program header information 503 with one or more retrieved body portions 502 to reconstruct program file 507. Program initiator 405 can run the reconstructed program file. Alternatively, the reconstructed program file 507 can be stored in storage 611 or stored back in another transaction 152 on blockchain 150, and / or the reconstructed file 507 can be transmitted to a third party for execution or storage.

[0107] At least a portion of at least one body portion 502 includes program code for the desired application. In embodiments, one or more body portions 502 may also include data manipulated by the program code (i.e., target data or operand data), and / or one or more libraries for compiling and / or linking the program code.

[0108] The program code in the main body 502 of program file 507 can be written in any suitable language, such as C, C++, JavaScript, Python, Basic, etc. This code is written in a language other than a scripting language used for locking scripts (such as Script). Therefore, this code can be referred to as non-Script code in embodiments. The program can have any application functionality required by the developers, such as a game, office tool, communication client, or diagnostic tool. Consumer 103b can be an end user or operator of node 104, such as a mining node. Consumer device (client device) 102b can include user equipment, server resources, or a combination thereof. In some cases, consumer device 102b may also act as a node 104 of blockchain network 106, rather than simply a consumer.

[0109] In an embodiment, the program launcher 405 may take the form of a virtual machine. It may include a compiler 603, an assembler 604, and / or a linker 605. It may include one or more pre-repositories 606. Running the program file 507 may include compiling high-level code, assembling assembly-level code, and / or linking. During linking, this may include linking between parts 502 from different transactions, partial linking within a given part 502, and / or linking to a library in one of the pre-repositories 606. In a further alternative embodiment, running the program file 507 may include interpreting high-level code in an interpreted language. In yet another alternative embodiment, the program may already contain low-level machine code, in which case running includes executing the machine code.

[0110] Note: It is also possible that the header file 501 itself may contain a body section (not shown), which includes part of the program code, and may be included as a part of one or more body sections 502 pointed to by the transaction ID 504 in the final reconstructed program file 507.

[0111] In an embodiment, header file 501 may optionally include section 505, which specifies one or more conditions for running one, multiple, or all body sections 502. These conditions can control under what circumstances body sections 502 are run. For example, these conditions may include one or more access conditions determining who can access one, multiple, or all body sections to reconstruct or run the file. More generally, condition 505 may include any conditions associated with one, multiple, or all body sections 502; for example, compatibility conditions, such as what operating system the client device 102b uses (e.g., checking that Bob is not trying to run a Windows program on a Mac), or whether the client device 102b has sufficient memory. Preferably, header file 501 also includes a code stub 506 for evaluating condition 505. This is not part of body sections 502 and does not need to be included in the finally reconstructed program file 507. Instead, code stub 506 is run automatically by the code initiator when header file 501 is retrieved from blockchain 150. However, like the main body, the code stub 506 can be written in a language other than the scripting language used to lock the script (e.g., a non-Scripting language).

[0112] When run, code stub 506 implements the relevant functionality for evaluating condition 505. Alternatively, evaluation by pre-stored code on Bob device 102b, or even by Alice or a third party, is not excluded. It should also be noted that although in Figure 5While schematically shown as a separate element, in some embodiments employing code stub 506, condition 505 may be integrated into stub 506 as part of its code. Alternatively, however, condition 505 may indeed be specified in a different section of header file 501 and referenced by code stub 506.

[0113] Condition 505 may, for example, include one or more access conditions, whereby access to one or more body parts 502 depends on the identity of the consumer 103b attempting to reconstruct program file 107. In this case, the evaluation includes checking whether the identity of consumer 103b is the same as the identity specified in access condition 505. It may also include authenticating the identity of consumer 103b. Those skilled in the art will be familiar with suitable authentication and identity verification techniques themselves.

[0114] As another alternative or additional example, condition 505 may include one or more compatibility conditions relating to the compatibility of the client computer device 102b, which is attempting to refactor program file 107, with one or more main body parts 502. In this case, the evaluation includes checking whether the computer device 102b meets one or more technical specifications specified in compatibility condition 505. Those skilled in the art will be familiar with suitable compatibility checking techniques themselves.

[0115] If the condition 505 specified in header 501 is not met, the code initiator 405 will i) be unable to access one, more, or all of the subject parts 502 via blockchain 150 at all; or ii) at least not include the condition in the final refactored program file 507. This could mean that no program file 507 is refactored, or that a version of program file 507 with only simplified functionality is created (lacking any subject parts 502 of consumer 103 and / or its computer device 102b that do not meet the associated condition 505).

[0116] In an embodiment, list 504 in header file 501 points to multiple transaction IDs for multiple body sections of stored procedure file 507. In some such embodiments, different corresponding conditions 505 may exist associated with different parts of the body section. This can be used to create different access levels. An exemplary application of this is a program for reading and writing text files. The "read" function and the "write" function can be two separate parts of the code, each with its own access control.

[0117] In some embodiments, header file 501 may be stored in encrypted form on chain 150, based on a shared key shared by Alice and Bob. This allows only Bob (and anyone else who knows the shared key, but not the public) to access header file 501 and thus reconstruct program file 507. The shared key can be obtained through a key negotiation process between Alice and Bob via an off-chain side channel (not shown) or an on-chain process. Alternatively, in other embodiments, header file 501 may not be encrypted but may be freely available to the public via blockchain 150.

[0118] Data stored in transactions can be retained in a UTXO collection. In an embodiment, to update information, an output containing the data can be spent. Previous data is recorded on the blockchain, but the UTXO collection only contains the latest information. Therefore, the blockchain pointer can always reference the data stored in the UTXO collection as the most up-to-date data.

[0119] The latest UTXO record is stored in the UTXO set of each storage and / or mining node 104S, 104M. This reflects the latest state of blockchain 150 and is typically maintained by all mining nodes and some nodes storing a complete copy of blockchain 150. Once recorded on the blockchain, existing transactions cannot be altered. Instead, in this embodiment, updates are achieved by adding a new transaction to the chain later, where the new transaction spends the spendable output of an existing transaction that stores the data being updated. Thus, the existing transaction (the transaction being updated) will at least contain spendable outputs (and possibly unspendable outputs if the data is contained in OP_RETURN, etc.). Once verified, the spendable outputs are included in the UTXO set. The UTXO set is maintained in part or all of the storage and / or mining nodes 104S, 104M. To perform an update, the spendable UTXOs of the existing transaction need to be spent, and the updated data is included in the new transaction (e.g., again, using the OP_RETURN opcode, etc., to include it in the new unspendable output of the new transaction). Once verified, this new transaction is included in the UTXO set. Therefore, the latest information will always be available in the UTXO set maintained by each storage and / or mining node 104S / M.

[0120] We will now discuss some exemplary implementation details of the above concepts in more detail.

[0121] An executable file consists of assembly-level code and any data, libraries, or scripts required by the code at runtime. Typically, this is organized in a standardized format depending on the operating system. Examples include the Portable Executable (PE) format in Windows and the Executable and Linkable Format (ELF) in Linux. Although the structure varies by format, it generally consists of the following components:

[0122] The program header specifies information such as machine and version information, file size, and pointers to file data.

[0123] Section header table, which references data contained in the file;

[0124] The data section includes code and other execution requirements.

[0125] The file specifies references to memory addresses for storing the required data. This file and each of its dependencies are stored on disk and reconstructed in memory at runtime based on the instructions specified in the file.

[0126] This paper discloses a similar executable file format that is stored in a decentralized manner on a blockchain, rather than storing the file and its dependencies on a local disk. This file format may be referred to as the Blockchain Executable Format (BEF) in this paper.

[0127] Assembly-level code, required libraries, or even imported data are all stored, compressed, and referenced on blockchain 150. Each component is stored in a separate transaction 152, and header file 501 only needs to retain TxID 504 and any header information 503, conditions 505, and / or stubs 506. As shown in the diagram below, the building, linking, and execution processes can all be performed by the integrated smart wallet / virtual machine.

[0128] Header file 501 has header 503, which contains some or all of the information listed above (version, checksum, etc.). When the BEF file 507 is fragmented, the executable stub 506, header 503, and TxID 504 required for reassembly and any access checks 505 are all stored in a single transaction 152Y. This transaction 152Y can also be referred to as a compressed version of file 507. Stub 506 is the executable code that checks the access conditions of the entire file 507.

[0129] The execution process of BEF is shown below. Figures 7A to 7B The method is also shown in the document.

[0130] exist Figure 7A In this step, an initial file request is initiated via a previously embedded HTML document on the blockchain, user input, or locally executed code, and sent to the blockchain network 106. In response, the smart wallet 406 returns and interprets header file 501.

[0131] In step S0, user 103b selects the TxID of the transaction containing header 501. This can be achieved through an existing hyperlink in a hypertext file, a locally stored address, or a blockchain pointer in locally executed code.

[0132] In step S1, smart wallet 406 requests the BEF file via a TxID request, which involves transaction 152Y containing header 501.

[0133] In step S2, network 106 responds with transaction information, which is then interpreted by smart wallet 406.

[0134] Figure 7B The steps illustrate how a smart wallet checks the compatibility and verification conditions listed in header 501 505. This can be achieved, for example, by running a stub 506. If all requirements are met, wallet 406 requests a portion of the body 502 addressed in the TxID list 503 of header 501, and a natively assembled executable file 507. The executable file, along with any necessary native libraries, is sent to linker 605, which then creates the file in memory 610 or 611 and executes it on CPU 609. The result can be presented to the user via UI device 607, written to blockchain 150, or used in additional scripts.

[0135] In step S3, when the file format structure flag is seen in the retrieved transaction, wallet 406 interprets the BEF file 507 and requests any further transactions (if any) referenced in the BEF file (and checks any access / key conditions where applicable).

[0136] In step S4, the assembly file 507 and any native libraries are transferred to the linker 605 in the virtual machine 405.

[0137] In step S5, machine code and any data are extracted from disk 611 at runtime, assembled in memory 610, and executed on CPU 609.

[0138] In step S6, the output is interpreted according to the program code. The program code may include (but is not limited to): i) displaying the output to user 103b, ii) pushing it onto the stack for in-script computation, iii) feeding it as input to another code running in virtual machine 405, and / or iv) writing another transaction created via smart wallet 406 to blockchain 150 as new data or to update existing data.

[0139] Figure 5 The structure of the BEF file is shown here. The intended format of the BEF file, to be interpreted by the smart wallet 406, is presented here. The assembly structure 507 is similar to a traditional Windows PE file, but for compression, the file is decomposed into several different transactions, allowing for independent data management and restricted access when needed. The header file 501 contains all the TXID pointers 504 required for reconstruction. Figure 5The left panel a) shows the fragmented executable file, which is distributed across several transactions 152Y and 152Z. The header file 501 includes the STUB program 506, header details 503, and references 504 to the transactions holding the section header table and the data required for execution. The right-hand structure shows the structure of the native assembly.

[0140] Stub 506 can be used to control where or under what conditions file 507 can be executed. The remainder of header file 501 may also contain code that determines the flow and format of the generated program. This could be a simple loader or it could use multiple UTXOs and transactions. The interpreted code can be fragmented into different forms of software, depending on user interaction or predefined automaton use cases. Header file 501 may have the following forms. This shows sections 503, 504, and 505. Stub 506 may be appended to this format.

[0141]

[0142] The UTXO relocation table is a list of pointers (504) pointing to one or more portions of one or more other transactions (152Z). In this implementation, what is actually identified is the specific UTXO within the referenced TxID, not just the TxID. Therefore, for example, referencing... Unexpendable .

[0143] The header ends with sorting information for the different parts 502. When assembling multiple parts 502, the same execution order as standard compilation / execution should be maintained. This is achieved by including the assembly sequence in the header file 501 (e.g., in header information 501).

[0144] Alternatively, header file 501 may contain only pointers to a single other TxID. In this case, if multiple sections 501 are to be assembled, each section, except for the last section 502, will itself contain a small header portion that includes at least a pointer to the next TxID in the ordered chain. The program initiator 405 then follows each pointer in the chain to collect all sections 502 for reconstructing the entire file 507. In embodiments, the header portion of each section 502 may include part or all of the same format as header file 501, such as the format shown in the table above. Furthermore, a combination of methods can be used. For example, header file 501 may thus contain a list 504 of some sections 502 of the entire file 507, and at least one of these sections may itself contain a header portion that points to one or more other sections. Again, the program initiator 405 follows each pointer to collect the required sections 502 for reconstructing the entire file 507.

[0145] For example, the sorting information at the end of the header format described above could include a reference to the next part of a file, which could be stored in a separate transaction, and wallet 406 could retrieve the next part of the file once certain verification conditions are met. This could go wrong if used improperly and could be flagged as requiring a signature, an incorrect UTXO type, or requiring permissions such as a key or fulfillment of payment conditions.

[0146] This can be implemented using key verification or selective decryption functions, such as XOR-based decryption. When reconstructing code from one or more data sources from one or more UTXOs on the blockchain, the method jumps to the OEP (Original Execution Point) after the assembly code. The executable is then passed to linker 605 and executed on the local computer. The data is loaded as an initial disk image file (such as an ISO) and reconstructed in a virtual machine or possibly in a browser.

[0147] Header 501 is constructed independently within a single initiating transaction that can be read publicly or using a selected key (such as an XOR-encrypted software link, or encoded as disclosed in PCT / IB2017 / 050856). The information received and interpreted by the smart wallet 406 allows the virtual machine 405 to determine the software version and ensure compatibility. An example explanation of this is provided in the next paragraph.

[0148] Execution of the stub procedure: As described above, the smart wallet 406, merged into the device, virtual machine, or browser, obtains information and identifies it as an executable image file via a reference flag in the transaction. The first part of the BEF file to be executed is a STUB, similar to the PE format. In the PE format, the DOS STUB verifies that the file is not executed in DOS; if so, it prints "This program cannot run in DOS mode" and stops execution. In the context of the BEF file, the STUB can be used to specify the operating environment (Windows, Linux, or a specified virtual machine) and can even be used to initiate access authentication. Client credentials can be interpreted, and if the presented information is insufficient to access the secure area of ​​the virtual machine, the STUB procedure can be used to prompt the user for authentication, such as username and password. Protocols can also be specified when access credentials cannot be proven, such as: I) printing a message to the user and terminating execution; II) restricting functionality by assembling only a specified portion of the execution data; III) restricting access to input data; and / or IV) blacklisting IP addresses attempting to access the executable file.

[0149] in conclusion

[0150] It should be understood that the above embodiments are described by way of example only.

[0151] More simply, according to one aspect disclosed herein, a method for running a program is provided, the method comprising: retrieving a header file from a first transaction recorded on a blockchain maintained by multiple nodes of a blockchain network by a computer device of a consumer. The header file includes program header information and reference information, the reference information including one or more corresponding transaction IDs of one or more corresponding second transactions stored on the blockchain, wherein each second transaction includes a corresponding portion of the body of the program file, at least one portion including executable program code. The method further comprises: retrieving a corresponding portion of the program file from at least one of the one or more second transactions via the blockchain based on the reference information; and running the program including the program header information and at least one retrieved portion.

[0152] In an embodiment, the running program may include: reconstructing a program file from header information and at least one retrieval portion, the program file including the program, storing the reconstructed program file in the memory of the consumer's computer device, and running the reconstructed program file on the consumer's computer device.

[0153] Alternatively, the consumer can execute each part separately and then move on to the next part, instead of assembling all the content into a single executable.

[0154] In one embodiment, the code may include assembly-level code, and execution may include assembling the assembly-level code and executing the assembled code. Alternatively, in another embodiment, the code may include a high-level language, and execution may include compiling the high-level code of the program file and executing the compiled program, such as using Just-In-Time (JIT) compilation. As another alternative embodiment, the program file may include raw machine code, and execution may include executing the machine code. In yet another alternative embodiment, the code may include a high-level language, and execution may include interpreting the high-level code.

[0155] In an embodiment, the operation may further include links, such as links between different parts of different transactions, or links between different sub-parts within a given part of a given transaction.

[0156] In an embodiment, the reference information may include multiple transaction IDs of multiple second transactions, each of which stores a corresponding body portion of a program file.

[0157] Different parts may include program code, one or more libraries, and / or data manipulated by the program.

[0158] In an embodiment, the retrieval may include retrieving a corresponding portion from two or more of a plurality of second transactions via a blockchain; the running program may include program header information and the retrieval portion from two or more second transactions.

[0159] Alternatively, the reference information in the header file may include only a single transaction ID that references only a single entity portion of a single second transaction.

[0160] In an embodiment, at least one body portion of at least one second transaction may itself include a header segment that includes at least a reference to a third transaction, which contains another body portion. In this case, the running program may include a program header and body portions from the second and third transactions.

[0161] In an embodiment, the header file may further include one or more conditions; and the method may include evaluating the conditions, wherein the retrieval or execution of at least one part of the program is conditional upon the result of the evaluation.

[0162] In one embodiment, the evaluation may be performed by the consumer's computer device.

[0163] In one embodiment, the header file may include a code stub for evaluating one or more conditions. In this case, the method may include running the code stub on the consumer's computer device to perform the evaluation.

[0164] In an embodiment, the conditions may include at least one access condition relating to the consumer's identity. In this case, the evaluation includes verifying that the consumer's identity matches the identity specified by at least one access condition, wherein at least one part of retrieving or running the procedure depends on a positive result of the verification.

[0165] In an embodiment, the conditions may include at least one compatibility condition relating to the consumer's computer device. In this case, the evaluation includes checking whether the consumer's computer device meets one or more technical criteria specified by the compatibility conditions, wherein at least one part of retrieving or running a program depends on a positive result of the check.

[0166] The compatibility technical guidelines may include one or more standards regarding the hardware of the consumer's computer device. Additionally / or, the compatibility technical guidelines may include one or more guidelines regarding the software installed on the consumer's computer device, such as one or more guidelines for the operating system, and / or one or more guidelines for one or more sister applications to be installed.

[0167] In an embodiment, the condition may include a corresponding condition associated with each of a plurality of parts, at least some of which are different from each other. The method may include evaluating the condition associated with each of at least some of the plurality of parts, wherein retrieving or running each of these parts depends on the result of the evaluation.

[0168] This advantageously provides different levels of access and operation, whereby some parts are available while others are not based on modularity and depend on specific conditions (e.g., depending on the identity of the consumer).

[0169] In an embodiment, the condition may include corresponding access conditions regarding the consumer's identity for each of some or all of the portions, and the evaluation includes verifying that the consumer's identity matches the corresponding identity specified by the corresponding condition of each corresponding portion, wherein retrieving or running the corresponding portion depends on the positive result of the corresponding verification.

[0170] In an embodiment, the condition may include corresponding compatibility conditions for each of some or all of the portions regarding the consumer's computer equipment being compatible with the corresponding portion, and the assessment includes verifying that the consumer's computer equipment meets one or more corresponding technical criteria specified by the corresponding conditions for each corresponding portion, wherein retrieving or running the corresponding portion depends on the positive results of the corresponding check.

[0171] In further alternative or additional embodiments, because non-script code is more general than the locking / locking scripts typically used in blockchain transactions, the one or more access conditions may include any user-defined conditions that the developer desires.

[0172] In an embodiment, the program header information may include one or more of the following: the version number of the program file, the version number of the system on which the program file runs, the size of the program file, a description, a list of reserved variables, a date and / or a timestamp, a checksum, and / or sorting information for the body section.

[0173] For example, in one embodiment, the program header information includes at least version and size information.

[0174] In an embodiment, the blockchain and blockchain network may be configured to operate according to an output-based model, wherein each transaction includes at least one output and at least one input, each output includes a locking script, and each input includes a pointer and an unlocking script, the pointer pointing to the output of another transaction, the unlocking script being used to unlock the locking script of the pointed-to output, wherein the scripts are written in a scripting language. In this case, the header file and the program code may be written in a language other than a scripting language.

[0175] In an embodiment, each of the header file and one or more parts is stored in at least one unspendable output of the corresponding first or second transaction on the blockchain.

[0176] For example, each unspendable output can be made unspendable by including an opcode in a scripting language that terminates the script when run by nodes in the blockchain network. For instance, the opcode could be OP_RETURN (the scripting language is Script).

[0177] In an embodiment, the reference information in the header file may include an identifier for a single corresponding output within each second transaction, and retrieval may include retrieving each retrieval portion from the identified output.

[0178] In one embodiment, the header file stored in the first transaction may be stored in encrypted form, encrypted using a shared key between the consumer and the provider of the service. In this case, retrieving the header file involves decrypting the header file using the shared key.

[0179] Alternatively, the header file can be unencrypted and therefore made freely available to the public on-chain.

[0180] According to another aspect disclosed herein, a computer program contained on a computer-readable storage medium is provided, which is configured to perform any of the method steps disclosed herein when run on a consumer's computer device.

[0181] According to another aspect, a consumer-side device is provided, comprising: a memory including one or more memory units, and a processing means including one or more processing units; wherein the memory stores code configured to run on the processing means, the code being configured to execute a consumer-side method according to any embodiment disclosed herein at runtime.

[0182] According to another aspect disclosed herein, a group of transactions is provided for recording in a blockchain, the group being on a computer-readable data medium or media, the group comprising: a first transaction including a header file, and one or more second transactions, each second transaction including a corresponding portion of the body of a program file, at least one portion of which contains executable program code; wherein the header file includes: program header information, and a set of one or more corresponding transaction IDs of the one or more second transactions stored on the blockchain, enabling the program file to be constructed using the program header information and at least one portion of the portion.

[0183] According to another aspect disclosed herein, a method may be provided that includes actions of a first party, a second party, any third parties that may be involved, and / or a network of nodes.

[0184] According to another aspect disclosed herein, a system may be provided that includes a first-party computer device, a second-party computer device, any third-party computer device, and / or a network of nodes.

[0185] Once the disclosure herein is given, other variations or use cases of the disclosed technology may become apparent to those skilled in the art. The scope of this disclosure is not limited to the described embodiments, but only to the appended claims.

Claims

1. A method of running a program, the method comprising being performed by a consumer's computer device: Retrieve a header file from the first transaction recorded on a blockchain maintained by multiple nodes in the blockchain network, the header file including: The program header information and reference information, wherein the reference information includes one or more corresponding transaction IDs of one or more corresponding second transactions stored on the blockchain, wherein each second transaction includes a corresponding part of the body of the program file, and at least one of the parts includes executable program code; The corresponding portion of the program file is retrieved from at least one of the one or more second transactions via the blockchain, based on the reference information. Run the program, which includes program header information and the at least one retrieved portion.

2. The method according to claim 1, wherein the running program comprises: From the header information and the at least one retrieved partial reconstructed program file, the program file including the program; The reconstructed program file is stored in the memory of the consumer's computer device; and the reconstructed program file is run on the consumer's computer device.

3. The method according to claim 1 or 2, wherein the reference information includes multiple transaction IDs of multiple second transactions, each second transaction storing a corresponding body portion of the program file.

4. The method according to claim 3, wherein: The retrieval includes retrieving a corresponding portion from two or more of the plurality of second transactions via the blockchain; The running program includes program header information and the retrieved portions from the two or more second transactions.

5. The method according to claim 1, wherein: At least one body portion of at least one of the second transactions includes a header segment, which includes at least a reference to a third transaction that contains another body portion; The running program includes a program header and the body portion from the second and third transactions.

6. The method of claim 1, wherein the header file further includes one or more conditions; and the method includes evaluating the conditions, wherein the retrieval or execution of at least one portion of the program depends on the result of the evaluation.

7. The method of claim 6, wherein the evaluation is performed by the computer device of the consumer.

8. The method of claim 7, wherein the header file includes a runnable code stub for evaluating the one or more conditions, the method comprising running the code stub on the consumer's computer device to perform the evaluation.

9. The method according to any one of claims 6 to 8, wherein the condition includes at least one access condition that is a condition relating to the consumer's identity; the evaluation includes verifying that the consumer's identity matches the identity specified by the at least one access condition, wherein the retrieval or execution of at least one part of the procedure depends on a positive result of the verification.

10. The method of claim 6, wherein the condition includes at least one compatibility condition relating to the compatibility of the consumer's computer device; the assessment includes checking that the consumer's computer device meets one or more technical criteria specified by the compatibility condition, wherein the retrieval or operation of at least one part of the program depends on a positive result of the check.

11. The method according to claim 6, wherein: The reference information includes multiple transaction IDs for multiple second transactions, and each second transaction stores the corresponding main body portion of the program file; The conditions include corresponding conditions associated with each of the plurality of said portions, at least some of which are different from each other; The method includes evaluating the conditions associated with at least some of the plurality of said portions, wherein the retrieval or operation of each said portion depends on the result of the evaluation.

12. The method of claim 11, wherein the conditions include corresponding access conditions regarding the identity of the consumer for each of some or all of the portions, the evaluation including verifying that the identity of the consumer matches a corresponding identity specified by the corresponding condition of each corresponding portion, wherein the retrieval or operation of the corresponding portion depends on a positive result of the corresponding verification.

13. The method of claim 6, wherein the conditions include corresponding compatibility conditions for each of some or all of the portions regarding the compatibility of the consumer's computer equipment with the corresponding portion, the assessment including verifying that the consumer's computer equipment meets one or more corresponding technical criteria specified by the corresponding conditions for each corresponding portion, wherein the retrieval or operation of the corresponding portion depends on a positive result of the corresponding check.

14. The method of claim 1, wherein the program header information includes one or more of the following: the version number of the program file, the version number of the system on which the program file runs, the size of the program file, a description, a list of reserved variables, a date and / or a timestamp, a checksum, and / or sorting information of the corresponding portion of the body of each of the second transactions.

15. The method of claim 1, wherein the blockchain and blockchain network are configured to operate according to an output-based model, wherein each transaction includes at least one output and at least one input, each output includes a locking script, and each input includes a pointer and an unlocking script, the pointer pointing to an output of another transaction, the unlocking script being used to unlock the locking script of the pointed-to output; The script is written in a scripting language, and the header file and program code are written in a language other than the scripting language.

16. The method of claim 15, wherein each of the header file and the one or more portions is stored in at least one unspendable output of the corresponding first or second transaction on the blockchain.

17. The method of claim 16, wherein each unspendable output becomes unspendable by including an opcode of the scripting language, the opcode terminating the script when run by a node of the blockchain network.

18. The method of claim 17, wherein the opcode is OP_RETURN.

19. The method of any one of claims 15 to 18, wherein the reference information in the header file includes an identifier of a single corresponding output within each second transaction, and the retrieval includes retrieving each portion of the retrieved portion from the identified output.

20. The method of claim 1, wherein the header file stored in the first transaction is stored in encrypted form and encrypted based on a shared key shared between the consumer and the provider of the program; and wherein retrieving the header file includes decrypting the header file based on the shared key.

21. A computer program product contained on a computer-readable storage medium, configured to perform the method according to any one of claims 1 to 20 when run on a consumer's computer device.

22. A consumer-side computer device, comprising: The memory, comprising one or more memory cells, A processing apparatus, the processing apparatus comprising one or more processing units; The memory stores code configured to run on the processing device, the code being configured to execute the method according to any one of claims 1 to 20 when executed.

23. A system for recording transactions in a blockchain, the system being on a computer-readable data medium or media, the system comprising: The first transaction, which includes a header file, and One or more second transactions, each second transaction comprising a corresponding portion of the body of a program file, at least one portion of which includes executable program code; The header file includes program header information and a set of one or more corresponding transaction IDs of one or more of the second transactions stored on the blockchain, enabling the program file to be constructed using the program header information and at least one of the portions.

Images