Block generation

Abstract

This method is executed by nodes within a blockchain network and comprises the steps of determining whether the number of transactions in a set of verified transactions exceeds a first threshold, and, if the number of transactions in a set of verified transactions exceeds the first threshold, performing a calculation to include the set of verified transactions in the blockchain.

Description

Technical Field

[0001] The present disclosure relates to block generation in a blockchain network.

Background Art

[0002] Proof-of-Work (PoW)-based blockchain technology has been misunderstood as having poor energy efficiency. In fact, as the scale expands, the energy efficiency becomes increasingly improved. Since the energy used for block generation does not depend on the number of transactions included in the block, the energy required for a block containing one transaction is the same as that for a block containing one billion transactions. That is, the more transactions there are in a block, the higher the energy efficiency. According to some studies, the energy used in traditional banking systems involving ATMs, branches deployed worldwide, and the printing, minting, and transportation of physical banknotes is greater than the energy consumed by Bitcoin. In the future, if Bitcoin comes to function as a scalable infrastructure that supports any type of value exchange, including the exchange of information or data, on a global scale, the energy consumption will be easily justified.

Summary of the Invention

[0003] According to one aspect disclosed herein, a method executed by a node in a blockchain network is provided, the method including determining whether the number of transactions in a set of verified transactions exceeds a first threshold, and, if the number of transactions in the set of verified transactions exceeds the first threshold, hashing the set of verified transactions.

[0004] To assist in understanding the embodiments of the present invention and to show how such embodiments are implemented, reference is made, by way of example, to the accompanying drawings.

Brief Description of the Drawings

[0005] [Figure 1] It is a schematic block diagram of a system for implementing a blockchain. [Figure 2] It is a diagram schematically showing some examples of transactions that can be recorded on a blockchain. [Figure 3] It is a schematic block diagram of node software for processing transactions. [Figure 4] It is a diagram showing a graph of an example of a hashing strategy. [Figure 5] It is a diagram showing a further graph of an example of the hashing strategy of FIG. 4.

Embodiments for Carrying Out the Invention

[0006] 1. Mining Strategy [[ID=2故に、本発明の目的は、上記の問題点を解消し、ブロックチェーンにおけるエネルギー消費を低減することができるマイニング戦略を提供することにある。

[0007] The sawtooth mining strategy and the start-stop mining strategy can extend battery usage and the life of hash hardware in addition to improving energy efficiency. These strategies also save the energy used for cooling the hardware during the hash process.

[0008] It should be noted that there seems to be an error in the original text at line 25 where the content is incomplete. I have translated it as best as possible based on the available information.Many mining companies employ a mining pool model for processing Bitcoin transactions and issuing blocks. A mining pool typically consists of a pool master and numerous hash units, which may be distributed globally or across large hash farms. The pool master's primary role is to construct block candidates and pass portions of the block header to the hash units to find the appropriate nonce. A reasonably large mining pool could exhaust all its nonce within a minute. Once a new block template is constructed, the pool master naturally includes all recently verified transactions in addition to those from previous block candidates. Consequently, the longer it takes to find a block, the more transactions it contains, and the higher the transaction fees that nodes can receive. According to some examples, mining only begins when the number of transactions or transaction fees reach a level sufficient to justify the energy expenditure. According to some examples, energy efficiency is measured by the energy consumption per transaction.

[0009] The strategies described herein may be executed by nodes within a blockchain network. These nodes may include hash nodes. In some examples, when the number of transactions in a set of verified transactions exceeds a first threshold, a computation is performed to add to the set of verified transactions. This computation may include hashing data or other appropriate calculations corresponding to the set of verified transactions. In some examples, the data may include block headers.

[0010] 1A. Start-Stop Strategy (Step Function) The following parameters are assumed. ·N hash Let this be the expected number of hashes required to find a block at a given difficulty. This is from the perspective of the entire network. ·rtx , r fee Let them be the increase rate of the number of transactions in the memory pool and the increase rate of the transaction fees by those transactions, respectively. ·H i be the hash rate of node M i which is normalized as a percentage of the network hash rate and is estimated to be N hash / 600. (In this example, the expected block interval is 600 seconds and the difficulty is assumed to reflect this. In other examples, the expected block interval is different). That is,

Number

[0011] Let t be the time (in seconds from T = 0) when N hash hashes are executed by the network. When it is determined that the number of transactions in the set of verified transactions exceeds the threshold, the set of verified transactions (transactions in the memory pool) can be hashed.

[0012] If all nodes start mining at T = 0, the expected total energy consumption is simply N hash units of energy, and the block is expected to contain 600r tx transactions and 600r fee transaction fees.

[0013] If node M i starts mining at T = t for each i and stops at time T = t when the network has executed a total of N i hashes, the following equation is obtained. hash

Number

Number

number

number

[0014] Note that if ti ≠ 0 for i, then t > 600. More precisely, Σ i t i H i It is an additional element that increases efficiency using the same amount of energy.

[0015] If it takes more than 10 minutes to mine a block, the difficulty will be slightly reduced in the next difficulty adjustment. As a result, the network's hash rate will be higher than what the new difficulty would suggest. The sawtooth mining strategy (t) described below i (≠Starting from 0) or start-stop strategy (t i By adopting a starting point (≠0), the estimated time to find a block reaches equilibrium at approximately 10 minutes. In other words, the efficiency improvements from the sawtooth mining strategy are not ignored by the difficulty adjustment algorithm.

[0016] 1B. Serrated Strategy The above strategy can be improved by allocating computing power (e.g., hash power) proportional to the number of transactions or the amount of transaction fees in the mempool (i.e., the set of verified transactions).

[0017] Node M i The hash rate that it possesses is H i Therefore, node M i As the number of transactions in the mempool increases, H i The minimum percentage h min The hash rate can be increased from a percentage. The increase may be exponential, linear, or logarithmic, based on the number of transactions in the mempool or the transaction fees in the mempool.

[0018] For example, the following formula uses H based on the number of transactions in the mempool (indicated by x). i This gives a percentage (h) of the linear utilization coefficient α and the minimum number of transactions (threshold n) required to start mining. tx-min (as shown by), and the minimum percentage of hashrate available at startup (h min It is parameterized by (as shown by ).

number

[0019] To understand the energy efficiency achieved by the sawtooth mining strategy, we can consider the number of transactions per unit of energy.

[0020] t is N hash Let T be the time (in seconds from T=0) that a hash is performed by the network. Assume that a new block candidate is created every second. That is, based on the number of transactions in the block candidate, the pool master calculates the corresponding percentage of hash units that send a partial block header. In effect, the hash rate is updated every second. ij Using M i The percentage of hash rate used in the j-th second

number

[0021] Therefore, the following equation holds true.

number

[0022] According to some examples, the number of transactions included in the set of verified transactions is the first threshold n. tx-min If the number of transactions exceeds a certain threshold, the set of verified transactions is hashed. In some examples, the hash rate increases linearly, exponentially, or logarithmically. According to some examples, if the set of transactions contains the maximum threshold number of transactions, the hash node hashes at the maximum hash rate.

[0023] In some examples, the hash rate can be zero up to a first threshold. Between the first and second thresholds, the hash rate can be a first value. Between the second and third thresholds, the hash rate can be a second value, higher than the first value. Therefore, the hash rate may depend on a step function based on the number of transactions in the mempool. This step function may have multiple steps between a hash rate of 0 and the maximum hash rate.

[0024] 1C. Serrated and Start-Stop Mining Strategies and Renewable Energy The aforementioned sawtooth mining and start-stop mining strategies allow nodes to pause hashing or periodically reduce energy consumption. This enables more efficient use of green energy. For example, pausing hashing allows time for batteries to recharge. Batteries may not be fully charged before being used again for hashing. However, when renewable energy sources such as seasonal water flows have limited availability, the sawtooth mining strategy allows nodes to maximize their use of the supply. For example, it can extend the time a node can utilize energy from a seasonal river. Furthermore, battery-based energy supply means that hash farms can be built in remote areas where national or general power grids are unavailable. This includes remote desert areas where solar power is abundant during the day but unavailable at night. The sawtooth mining strategy enables energy-efficient hashing in remote areas, for example, allowing batteries to power through the night.

[0025] 1D. Serrated and Start-Stop Mining Strategies and ASICs Application-specific integrated circuits (ASICs) are high-performance chips, but they can generate heat quickly. Fans and other cooling mechanisms can consume a lot of power in an attempt to cool the chip enough for hashing to be performed. The sawtooth mining strategy and start-stop mining strategy described above are helpful in two ways. 1. When all ASICs are turned on simultaneously, power surges become extremely high, potentially causing circuit breaks. A sawtooth mining strategy allows nodes to turn on ASICs at different time intervals. This not only improves energy efficiency but also provides a safer way to operate the ASICs. 2. ASICs have cooling issues. In a sawtooth mining strategy, nodes can briefly turn off the ASICs at each block interval. While the downtime may be short, with the help of a cooling system, the chips can be quickly cooled and restarted. This not only saves energy consumption in the cooling system but also extends the lifespan of the ASICs.

[0026] 1E. Sawtooth Mining Strategy with Fixed Parameters Node M i The hash rate of H i Therefore, as the number of transactions in the mempool increases, H i The minimum percentage h min The hash rate can be increased by %. For example, the following formula uses the number of transactions (x) in the mempool to determine the hash rate used. i This gives the percentage (h) of the utilization factor α and the minimum number of transactions (n) required to start mining. tx-min It is parameterized by the hash rate (denoted by ) and the minimum percentage of the hash rate available at startup (denoted by h).

number

[0027] The raw, illustrative data for the parameters specified in the above example is shown in Table 1. [Table 1-1] [Table 1-2] [Table 1-3]

[0028] 2. Example of a system overview A blockchain is a form of decentralized data structure in which duplicate copies of the blockchain are maintained on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network") and are widely publicized. A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which can span one or more blocks and trace back to one or more coinbase transactions. Coinbase transactions will be discussed further below. Transactions submitted to the blockchain network are included in a new block. New blocks are created through a process often called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered, validated, and unprocessed set of transactions waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and block publication may be achieved through the publication of only the block header.

[0029] Transactions in a blockchain can be used for one or more purposes, such as moving digital assets (i.e., a certain number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or ordering index pointers in time. Blockchains can also be leveraged to overlay additional functionality on top of them. For example, blockchain protocols can enable the storage of additional user data or indexing of data within transactions. Since there is no predetermined limit on the maximum amount of data that can be stored within a single transaction, increasingly complex data can be incorporated. For example, this can be used to store electronic documents or audio or video data on a blockchain.

[0030] In the "output-based" model (sometimes called the UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of digital asset that can be derived from the preceding sequence of the transaction. Consumable outputs are sometimes called UTXOs ("unconsumed transaction outputs"). Outputs may further comprise a locking script that specifies the conditions for the future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit digital tokens or assets. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlocking script to unlock the locking script of the pointed-to output. Thus, we consider pairs of transactions, which we call the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output specifying the amount of digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction has at least one input, which is a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0031] In such a model, when a second target transaction is sent to the blockchain network to be propagated and recorded on the blockchain, one of the legitimacy criteria applied at each node is that the unlock script satisfies all one or more conditions defined in the lock script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another earlier, legitimate transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not propagate the target transaction (not as a legitimate transaction, but possibly to register a fraudulent transaction), nor will it include the target transaction in a new block to be recorded on the blockchain.

[0032] An alternative type of transaction model is the account-based model. In this case, each transaction is defined not by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but by referring to the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by multiple nodes and is constantly updated.

[0033] Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may comprise a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 comprises a plurality of blockchain nodes 104, which may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph, so that each blockchain node 104 is highly connected to other blockchain nodes 104.

[0034] Each blockchain node 104 is equipped with the computer equipment of its peers, and different nodes of node 104 belong to different peers. Each blockchain node 104 is equipped with one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or processing units comprising field-programmable gate arrays (FPGAs), as well as other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of non-temporary computer-readable media. The memory may comprise one or more memory units utilizing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROMs, and / or optical media such as optical disc drives.

[0035] Blockchain 150 comprises a chain of data blocks 151, and each copy of blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the decentralized network or blockchain network 106. As mentioned above, maintaining a copy of blockchain 150 does not necessarily mean storing blockchain 150 completely. Instead, blockchain 150 can be pruned in terms of data, as long as each blockchain node 150 stores the block header (discussed below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction refers to some kind of data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout.

[0036] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby allowing transaction 152 to spread throughout the network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (or “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as the “mempool”. In this specification, this term is not limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as legitimate, and for which node 104 is not obligated to accept other transactions that seek to consume the same output.

[0037] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or "consumed" in the current transaction 152j. Consuming or redeeming is certainly one common use, but it does not necessarily mean the transfer of a financial asset. More generally, consumption can be described as consuming an output or assigning it to one or more outputs in another subsequent transaction. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. The preceding transaction 152i does not necessarily exist when the current transaction 152j is created or even when it is sent to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Therefore, in this specification, "preceding" refers to something that precedes a logical sequence linked by pointers, and does not necessarily refer to the time of creation or transmission in chronological order, and does not necessarily exclude the possibility that transactions 152i and 152j may be created or transmitted in a different order (see the following discussion on orphan transactions). The preceding transaction 152i may be equivalently called an ancestor transaction or predecessor transaction.

[0038] Due to the resources involved in verifying and publishing the validity of transactions, each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a user terminal, or a group of user terminals connected together to the network.

[0039] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform its respective role and handle transaction 152 in accordance with the blockchain node protocol. It will be understood herein that any action attributed to blockchain node 104 may be performed by software running on the processing unit of the respective computer equipment. Node software may 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 thereof.

[0040] Any given blockchain node can be configured to perform one or more of the following actions: transaction verification, transaction storage, transaction propagation to other peers, and consensus (e.g., proof-of-work) / mining actions. In some examples, each type of action is performed by a different node 104; that is, a node can specialize in a particular action. For example, node 104 can specialize in transaction verification and propagation, or in block mining. In some examples, blockchain node 104 can perform multiple processes of these actions in parallel. A reference to blockchain node 104 may refer to an entity configured to perform at least one of these actions.

[0041] Each computer device 102 of the multiple parties 103, who act as consuming users, is also connected to the network 101. These users can interact with the blockchain network 106, but do not participate in validating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store a copy of the blockchain 150 (for example, by obtaining a copy of the blockchain from a blockchain node 104).

[0042] Some or all of the parties 103 may be connected as part of a different network, such as a blockchain network 106 superimposed on it. Users of the blockchain network (often called “clients”) are sometimes said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may utilize the blockchain 150 by interacting with the blockchain network 106 and thereby connecting to (i.e., communicating with) the blockchain network 106. Two parties 103 and their respective devices 102, namely the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are shown for illustrative purposes. It will be understood that more such parties 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each party 103 may be an individual or an organization. For illustrative purposes only, the first party 103a is referred to herein as Alice and the second party 103b as Bob, but this is not limiting, and it will be understood that any reference herein to Alice or Bob may be replaced by “the first party” and “the second party,” respectively.

[0043] Each computer device 102 of Party 103 comprises a processing unit comprising one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of a non-temporary computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, for example, magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disc drives. The memory of each computer device 102 of Party 103 stores software comprising each entity of at least one client application 105 configured to run on the processing unit. It will be understood that any action attributed herein to a given Party 103 can be performed using the software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other network-connected resources, such as cloud computing resources accessed via a user terminal.

[0044] The client application 105 is initially provided to the computer equipment 102 of any given party 103 on a suitable computer-readable storage medium, which may be downloaded from a server and provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0045] The client application 105 has at least a “wallet” function. This has two main functions. One is to enable each party 103 to create, authorize (e.g., sign) a transaction 152 and send it to one or more Bitcoin nodes 104 so that the transaction 152 is disseminated throughout the network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report to each party the amount of digital assets that each party currently owns. In an output-based system, the second function is to match the amounts defined in the outputs of various transactions 152 scattered throughout blockchain 150 that belong to the party in question.

[0046] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limited, and any client function described herein may instead be implemented in a suite of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functions may be implemented in the application layer, lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not limited.

[0047] Each computer device 102, an entity of a client application or software 105, is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to inquire about any transaction to which each party 103 is the recipient (or, in an embodiment, to actually investigate the transactions of other parties on blockchain 150, since blockchain 150 is a public institution that brings credibility to transactions by being publicly visible in part). The wallet function of each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As stated above, each blockchain node 104 runs software configured to validate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate transaction 152 throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol is associated with a given node protocol, and together they implement a given transaction model. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0048] An alternative type of transaction protocol operated by some blockchain networks may be called an “account-based” protocol as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but by referencing the absolute balance of the account. The current state of all accounts is stored separately on the blockchain by the nodes of that network and is constantly updated. In such a system, transactions are ordered using the account’s transaction execution record (also called a “position”). This value is signed by the sender as part of the sender’s cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0049] Some account-based transaction models share some similarities with the output-based transaction models described here. For example, as mentioned earlier, the data fields in an account-based transaction may reference previous transactions. This is equivalent to the input in an output-based transaction referencing the output point of a previous transaction. Thus, both models enable links between transactions. As another example, an account-based transaction may include a "Recipient" field (specifying the account's receiving address) and a "Value" field (where the amount of the digital asset can be specified). The recipient and value fields, combined, are equivalent to the output in an output-based transaction and can be used to assign the amount of the digital asset to a blockchain address. Similarly, an account-based transaction may have a "Signature" field containing the transaction's signature. This signature is generated using the sender's private key and confirms that the sender has approved this transaction. This is typically equivalent to the input / unlock script in an output-based transaction that includes the transaction's signature. Once both types of transactions are sent to their respective blockchain networks, the signatures are checked to determine whether the transaction is valid and recordable on the blockchain. In account-based blockchains, a “smart contact” refers to a transaction that contains a script configured to perform one or more actions (for example, sending or “releasing” a digital asset to a recipient’s address) in response to one or more inputs (provided by the transaction) that satisfy one or more conditions defined in the smart contact’s script. Smart contracts exist as transactions on the blockchain and are invoked (or triggered) by subsequent transactions.Therefore, in some examples, a smart contract can be considered equivalent to a locking script for an output-based transaction, which is triggered by a subsequent transaction and checks whether the input of the subsequent transaction satisfies one or more conditions defined in the locking script.

[0050] 3. UTXO base model Figure 2 shows an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following description will refer to the output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it can be equally implemented on other exemplary blockchain networks.

[0051] In the UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unconsumed transaction output (UTXO), which can be used as a source for the inputs 202 of another new transaction (if the UTXO has not yet been redeemed). The UTXO contains a value specifying the amount of the digital asset, which represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originates. The transaction data structure may also have a header 201, which may indicate the sizes of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an 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 raw transaction 152 submitted to node 104.

[0052] Suppose Alice 103a wants to create transaction 152j to transfer the amount of the target digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It has the amount of the digital asset locked in Alice in output 203 of the preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, nor that Tx1 is the next transaction in pool 154. Tx1 could point to any preceding (i.e., ancestor) transaction that still has the unspent output 203 locked in Alice.

[0053] In the context of transaction sequences, the terms “preceding” and “successor” as used herein refer to the order of transactions in a sequence as defined by the transaction pointers specified in the transaction (e.g., which transaction points to which other transaction). They can be equally replaced with “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. It does not necessarily imply the order in which they are created, the order in which they are sent to network 106, or the order in which they reach any given blockchain node 104. Nevertheless, a successor transaction (descendant transaction or “child”) pointing to a preceding transaction (ancestor transaction or “parent”) will not be validated until the parent transaction has been validated, and unless it has been validated. A child that reaches blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for its parent.

[0054] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a specific UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO, and a lock script defining conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus for the redemption of the UTXO to be successful.

[0055] A lock script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S), used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it might include Bob's signature. The unlock script appears in transaction input 202.

[0056] Therefore, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A This includes Alice's signature Sig P, which is necessary for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be legitimate). A [Checksig P A ] is the public key P from Alice's public key-private key pair. AThe input 202 of Tx1 includes a representation (i.e., a hash). The input 202 of Tx1 includes a pointer that points to Tx1 (for example, by transaction ID TxID0, where in an embodiment TxID0 is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0 in order to identify the UTXO0 from all other possible outputs of Tx0. The input 202 of Tx1 further includes a lock release script <Sig P A > comprises Alice's cryptographic signature, which is created by Alice applying her private key from a key pair to a predetermined portion of the data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, by a node protocol, or a combination thereof.

[0057] When a new transaction Tx1 reaches blockchain node 104, that node applies the node protocol. This involves executing both the lock script and the unlock script to check whether the unlock script satisfies the conditions defined in the lock script (which may consist of one or more criteria).

[0058] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of the transaction that can store data within the transaction, thereby immutably recording the data on blockchain 150. For example, the data may consist of documents that are desired to be stored on the blockchain.

[0059] Typically, the input to a transaction is the public key P. A This includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific part of the output that the digital signature signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects (and is therefore fixed at the time of signing) which outputs to sign.

[0060] A lock script is sometimes called a "scriptPubKey," which relates to the fact that the lock script typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a "scriptSig," which relates to the fact that the unlock script typically supplies the corresponding signature. However, more generally, it is not required in all application examples of blockchain150 that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0061] 4. Node Software Figure 4 shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO-based or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes one or more of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The consensus module 455C may include a verification module (not shown) configured to verify transactions according to the blockchain protocol. The verification module may be configured separately from the consensus module 455C. One or more modules may operate in parallel. Node 104 may include additional modules. The protocol engine 401 is typically configured to recognize different fields of transaction 152 and process them according to the node protocol. m-1 Transaction 152j(Tx) has inputs that point to the output (e.g., UTXO) of ). j When it receives ), protocol engine 451 sends Tx j Identify the unlock script within and pass it to script engine 452. Protocol engine 451 also handles Tx j Tx based on the pointer in the input i Identify and retrieve Tx i It may be publicly available on blockchain 150, in which case the protocol engine will take the transaction from a copy of block 151 of blockchain 150 stored on node 104. iYou can obtain it. Alternatively, Tx i It is possible that the transaction has not yet been published to blockchain 150. In that case, the protocol engine 451 will take the transaction from the ordered set of unpublished transactions 154 managed by node 104. i It is possible to obtain the Tx. In either case, the protocol engine 451 will obtain the referenced Tx i Identify the lock script from the output and pass it to script engine 452.

[0062] In this way, script engine 452, Tx i The lock script and the corresponding Tx j The unlock script is obtained from the input. For example, Figure 2 shows transactions labeled Tx0 and Tx1, but the same applies to any pair of transactions. The script engine 452 executes the two scripts together as described above, which involves placing data on the stack 453 and retrieving data from the stack 453, according to the stack-based scripting language being used (e.g., Script).

[0063] The script engine 452 executes these scripts simultaneously to determine whether the unlock script meets one or more criteria defined in the lock script; that is, whether to "unlock" the output containing the lock script. The script engine 452 returns this determination result to the protocol engine 451. If the script engine 452 determines that the unlock script meets one or more criteria specified in the corresponding lock script, it returns a result of "true". Otherwise, it returns a result of "false".

[0064] In an output-based model, the output "true" from script engine 452 is one of the conditions for transaction validity. Typically, one or more protocol-level conditions, evaluated by protocol engine 451, must also be met. For example, Tx j The total value of the digital assets specified in the output does not exceed the total value indicated by its input, and Tx i This includes ensuring that the output has not already been consumed by another valid transaction. The protocol engine 451 evaluates the output from the script engine 452 and one or more protocol-level conditions, and only if they are all true does transaction Tx proceed. j The protocol engine 451 outputs an instruction to the application-level decision engine 454 indicating whether the transaction is valid. j Only if it is actually verified, the decision engine 454 controls both the consensus module 455C and the propagation module 455P, and Tx j Each blockchain-related function can be executed in relation to this. This means that the consensus module 455C can perform Tx j Adding the ordered transaction set 154 of each node and incorporating it into block 151, and the propagation module 455P Tx j This includes transferring the transaction to another blockchain node 104 within the network 106. Optionally, in the embodiment, an application-level decision engine 454 may apply one or more additional conditions before triggering any or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees remain.

[0065] Furthermore, the terms "true" and "false" here are not necessarily limited to returning a result represented by a single binary number (bit), but are merely one implementation example. More generally, "true" refers to any state indicating success or a positive outcome, and "false" refers to any state indicating failure or a negative outcome. For example, in an account-based model, a "true" result could be indicated by a combination of implicit protocol-level verification of the signature and a positive output from the smart contract (the overall result is considered true if both individual results are true).

[0066] 5. Appendix Other variations or use cases of the techniques disclosed may become apparent to those skilled in the art if the disclosures herein are given. The scope of this disclosure is limited only by the appended claims and not by the embodiments described herein.

[0067] For example, some of the embodiments described above relate to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it will be understood that the Bitcoin blockchain is one specific example of blockchain 150, and the above description may apply in general to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any reference above to Bitcoin network 106, Bitcoin blockchain 150, and Bitcoin node 104 may be replaced by a reference to blockchain network 106, blockchain 150, and blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of Bitcoin blockchain 150, Bitcoin network 106, and Bitcoin node 104, as described above.

[0068] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, publishing, distributing, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the function of distributing and / or storing blocks without creating and publishing them (as stated above, these entities would not be considered nodes of the preferred Bitcoin network 106).

[0069] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, rather than all, of creating, publishing, distributing, and storing blocks 151 of blockchain 150. For example, on those other blockchain networks, “node” may be used to refer to a network entity configured to create and publish blocks 151 but not to store and / or distribute those blocks 151 to other nodes.

[0070] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, publishing, distributing, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in the same way as described above with reference to blockchain nodes 104.

[0071] Several embodiments describe blockchain networks that implement a proof-of-work consensus mechanism to secure the underlying blockchain. However, proof-of-work is only one type of consensus mechanism, and in general embodiments, any type of appropriate consensus mechanism can be used, such as proof-of-stake, delegated proof-of-stake, proof-of-capacity, or proof-of-elapsed time. As a special case, proof-of-stake uses a randomized process to determine which blockchain node 104 will be given the opportunity to generate the next block 151. The selected node is often called a validator. Blockchain nodes can lock tokens for a certain period of time to have a chance of becoming a validator. Generally, the node that locks the largest stake for the longest period of time is most likely to become the next validator.

[0072] It will be understood that the embodiments described above are for illustrative purposes only. More generally, methods, apparatus, or programs are provided according to one or more of the following descriptions.

[0073] Statement 1: A method performed by a node in a blockchain network, comprising the steps of: determining whether the number of transactions in a set of verified transactions exceeds a first threshold; and, if the number of transactions in a set of verified transactions exceeds the first threshold, performing a calculation to include the set of verified transactions in the blockchain.

[0074] Statement 2: The method according to Statement 1, wherein the step of performing a calculation to include a set of verified transactions in a blockchain includes the step of hashing the set of verified transactions by a hash rate, the hash rate being based on the number of transactions in the set of verified transactions.

[0075] Statement 3: The method according to Statement 2, wherein the hash rate increases linearly based on the number of transactions in the set of verified transactions.

[0076] Statement 4: The method according to Statement 2, wherein the hash rate increases non-linearly based on the number of transactions in the set of verified transactions.

[0077] Statement 5: The method according to Statement 2, wherein the hash rate has a first value between the first threshold and the second threshold, and the hash rate has a second value between the second threshold and the third threshold, where the second value is greater than the first value.

[0078] Statement 6: The method according to Statement 5, wherein the hash rate has a third value between the third threshold and the fourth threshold, and the third value is greater than the second value.

[0079] Statement 7: The method of any of statements 2 to 6, wherein the hash rate has a maximum value that exceeds the fifth threshold.

[0080] Statement 8: The method described in any of statements 2 through 7, wherein the first threshold is a non-zero value.

[0081] Statement 9: The method of any of Statements 1 to 8, wherein the step of determining whether the number of transactions in a set of verified transactions exceeds a first threshold includes the step of determining whether the amount of transaction fees exceeds a transaction fee threshold.

[0082] Statement 10: The method according to any of statements 1 through 9, wherein the node is powered by a rechargeable battery and the rechargeable battery is charged when the number of transactions in a set of validated transactions falls below a first threshold.

[0083] Statement 11: The method of any of statements 2 through 10, wherein a node has multiple application-specific integrated circuits, and the multiple application-specific integrated circuits are turned on at different times to hash a set of hash-validated transactions.

[0084] Statement 12: The method described in any of statements 1 through 11, such that when the number of transactions in a set of validated transactions falls below a first threshold, the node is turned off for cooldown.

[0085] Statement 13: A method of any of statements 1 through 12, wherein the computation involves hashing data that depends on a set of verified transactions.

[0086] Statement 14: The method described in Statement 13, wherein the data includes a block header.

[0087] Statement 15: A device comprising at least one processor and at least one memory, wherein the memory stores an instruction, and when the instruction is executed by at least one processor, the device causes at least to determine whether the number of transactions in a set of verified transactions exceeds a first threshold, and if the number of transactions in a set of verified transactions exceeds the first threshold, to hash the set of verified transactions.

[0088] Statement 16: Memory including one or more memory units, Computer equipment comprising a processing unit including one or more processing units, wherein memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method described in any of statements 1 to 14.

[0089] Statement 17: A computer program embodied on computer-readable storage, configured to perform any method described in statements 1 through 14 when executed on one or more processors. [Explanation of symbols]

[0090] 101 Internet, packet-switched network 102 Computer terminals and equipment 103 users 104 Blockchain Nodes 105 Client Applications 106 P2P Network 107 Side Channel 150 Blockchains 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block pointers 201 Header 202 inputs 203 Output

Claims

1. A method performed by nodes within a blockchain network, A step to determine whether the number of transactions in the set of verified transactions exceeds a first threshold, When the number of transactions in the set of verified transactions exceeds the first threshold, the steps include performing a calculation to include the set of verified transactions in the blockchain. A method that includes [a certain feature].

2. The method according to claim 1, wherein the step of performing a calculation to include the set of verified transactions in a blockchain includes the step of hashing the set of verified transactions by a hash rate, the hash rate being based on the number of transactions in the set of verified transactions.

3. The method according to claim 2, wherein the hash rate increases linearly based on the number of transactions in the set of verified transactions.

4. The method according to claim 2, wherein the hash rate increases non-linearly based on the number of transactions in the set of verified transactions.

5. The method according to claim 2, wherein the hash rate has a first value between the first threshold and the second threshold, and the hash rate has a second value between the second threshold and the third threshold, wherein the second value is greater than the first value.

6. The method according to claim 5, wherein the hash rate has a third value between the third threshold and the fourth threshold, and the third value is greater than the second value.

7. The method according to any one of claims 2 to 6, wherein the hash rate has a maximum value that exceeds a fifth threshold.

8. The method according to any one of claims 1 to 7, wherein the first threshold value is a non-zero value.

9. The method according to any one of claims 1 to 8, wherein the step of determining whether the number of transactions in a set of verified transactions exceeds a first threshold includes the step of determining whether the amount of transaction fees exceeds a transaction fee threshold.

10. The method according to any one of claims 1 to 9, wherein the node is powered by a rechargeable battery, and the rechargeable battery is charged when the number of transactions in the set of verified transactions falls below a first threshold.

11. The method according to any one of claims 2 to 10, wherein the node has a plurality of application-specific integrated circuits, and the plurality of application-specific integrated circuits are turned on at different times to hash a set of hash-validated transactions.

12. The method according to any one of claims 1 to 11, wherein the node is turned off for cooldown when the number of transactions in the set of verified transactions falls below the first threshold.

13. The method according to any one of claims 1 to 12, wherein the calculation includes hashing data that depends on the set of verified transactions.

14. The method according to claim 13, wherein the data includes a block header.

15. A device comprising at least one processor and at least one memory, When the memory stores an instruction and the instruction is executed by the at least one processor, the device has at least: Determine whether the number of transactions in the set of validated transactions exceeds the first threshold, When the number of transactions in the set of verified transactions exceeds the first threshold, a calculation is performed to include the set of verified transactions in the blockchain. A device that performs an action.

16. Memory including one or more memory units, Computer equipment comprising a processing unit including one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code, when executed on the processing unit, is configured to perform the method according to any one of claims 1 to 14.

17. A computer program, embodied on computer-readable storage, configured to perform the method described in any one of claims 1 to 14 when executed on one or more processors.

Images