RU2794606C2 - Method for forming a privileged transaction in blockchain and method for block validation in blockchain - Google Patents

Abstract

FIELD: blockchains.

SUBSTANCE: invention relates to a system and methods for generating a privileged blockchain transaction and validating a block in a blockchain. In the method, a privileged transaction is generated by a user by means of a first blockchain node, a cryptographic signature using the user's private key is added to the privileged transaction, thereby creating a signed privileged transaction, the signed privileged transaction is broadcasted to a plurality of other nodes in the blockchain, the other nodes checking whether the user is allowed to execute a privileged transaction, wherein the permission to perform the privileged transaction was stored on the blockchain before the privileged transaction was generated, the permission being stored as a transfer transaction on the blockchain, and the transfer transaction granting the permission comes from a trusted wallet.

EFFECT: increase in the reliability and security of transactions in the blockchain.

9 cl, 2 dwg

Description

The present invention relates to a method for generating a privileged transaction in a blockchain and a method for validating a block in a blockchain.

Blockchains are becoming more and more popular for a multitude of applications. A blockchain is a distributed database in which information is recorded inside a hardware wallet (ledger) of public transactions (that is, a blockchain).

For example, blockchains can be used to represent money, for example in the form of "digital money". One well-known example of such money is bitcoin, which is a crypto-currency based on a peer-to-peer network mode. Other digital money is Litecoin or Primecoin.

To transfer amounts (or "coins") of such money within the blockchain, transactions (or transfer transactions, as used here) are used. Transactions are usually distributed across blockchain nodes. The nodes check the transaction for correctness. Valid transactions can then be collected into blocks, in which transactions become valid only if they are included in one or more validated blocks of the blockchain.

Additionally, special or privileged transactions can be performed to slowly increase the amount of money present on the blockchain over time. These privileged transactions can, for example, generate new amounts of money (from nothing, "out of the nothing"), for example, through mining (mining) or minting (minting). Such a money generation transaction may be referred to as a "coinbase transaction" or, more generally, a "generation transaction".

However, from a security point of view, it may be preferable to ensure that only the correct elements/users/nodes of the blockchain are allowed to generate new money. In contrast, for example, in the bitcoin network, new money can be formed by each element.

Therefore, monetary blockchains are vulnerable if there are malicious nodes or even if the majority of blockchain nodes are malicious. In addition, the integrity of the blockchain may be at risk and the blockchain may be vulnerable to various attacks.

Therefore, the object of the present invention is to provide a method that enhances the security of the blockchain.

This problem is solved by methods corresponding to paragraphs. 1, 2 claims.

Claim 1 relates to a method for generating a privileged blockchain transaction, in which

- a privileged transaction is formed by the user using the first node of the blockchain,

- alternatively, using the user's private key, a cryptographic signature is added to the privileged transaction, thus creating, alternatively, a signed privileged transaction,

- The (signed) privileged transaction is broadcast to a plurality of other nodes on the blockchain, where other nodes perform validation, if the user is allowed to execute the privileged transaction, where permission to perform the privileged transaction was stored in the blockchain before the privileged transaction was generated.

Claim 2 refers to a blockchain block validation method in which

- the block is formed by the blockchain user through the first blockchain node in which the block contains one or more transactions,

- alternatively, a cryptographic signature is added to the block using the private key of the first node, creating, alternatively, a signed block,

- the (signed) block is broadcast to a plurality of other nodes on the blockchain, where other nodes preferably verify the cryptographic signature of the signed block using the user's public key, and where other nodes validate if the user is allowed to validate the block, and the permission to perform block validation has been retained on the blockchain before block validation.

In other words, the invention is based on the recognition that the security of the blockchain can be enhanced if the user (or the user's corresponding first node) requests authorization/permission to execute a privileged transaction as a permission that can be revoked for malicious nodes. Additionally, it has been confirmed to allow simple implementation of authorization in existing blockchain mechanisms if permission to execute a privileged transaction is stored in the blockchain itself. Since the blockchain itself is usually (at least partially) stored within each blockchain node, each node can be easily verified/validated if the user is allowed to perform a privileged transaction. If the user is allowed to execute a privileged transaction, then only then the privileged transaction is collected in one of the blockchain blocks. Information, if a user (or user node) is allowed to perform a privileged transaction, can be stored within the blockchain in various ways. It is only necessary that it is clear from the information stored on the blockchain that the user is allowed to perform a privileged transaction.

In particular, permission to execute a privileged transaction may be granted by a transfer transaction (ie, a transaction granting permission), as mentioned below. The transaction granting permission could, for example, transfer some amount of money either to itself, if the transaction could then contain the user's identity, or a certain amount of money could be transferred directly to the user's wallet. As long as the transferred amount of the transaction granting the permit is not spent, the permit may remain valid.

In the same way, blockchain block validation can be assigned to users who are allowed to validate the block. Thus, for example, the amount of money transferred to a user who validates a blockchain block is not transferred to a malicious user or node. Again, since the permission to perform validation is stored on the blockchain itself, only a small code change to an existing blockchain (such as the bitcoin blockchain) is needed.

In particular, permission to execute a privileged transaction and/or permission to perform block validation can be stored within the blockchain and/or centrally managed on the blockchain. Since the blockchain is usually distributed over many nodes, the invention adds a small centralized element that greatly increases the security of the blockchain.

For completeness, it should be mentioned that other nodes can verify the cryptographic signature of a signed privileged transaction using the first node's public key. Preferably, only if the user's public key and private key also match, then the transaction is collected in one of the blocks. In short, a transaction and/or block is treated as a payload that is protected by a cryptographic signature.

In general, a signed privileged transaction and/or a signed block can also be broadcast to only one other node on the blockchain, with the other node verifying the cryptographic signature of the signed privileged transaction using the public key of the first node (i.e., the user).

Further embodiments of the invention are described in more detail.

The blockchain may contain the first node and the aforementioned other nodes, where the nodes may be part of the Internet or a data network. Nodes can have a data connection to each other. In particular, all nodes may be identical to the first node.

The node may contain only software that allows the user (ie, the market participant) to manage the account. A node can be formed as an instance that contains a private key (that is, the user's private key). No software or node required, but may contain a copy of the blockchain.

The private key and public key of the first node may form a key-pair (that is, a private key and a public key corresponding to each other). The private key used to add the cryptographic signature may be, for example, the user's private node, the node's device private key, or the private key associated with a particular account.

In particular, nodes can be peer nodes. The nodes may be independent of each other and/or may be managed by independent entities and/or persons. Each node may be a separate computer having a dedicated processor, memory devices, and/or I/O devices for communicating with other nodes. The first node and/or other nodes may be a wallet device, where the wallet device may be a personal computer (PC), laptop or smart phone. A wallet device may also be called an e-wallet or a crypto-wallet.

The blockchain can store each transaction, such as the aforementioned privileged transaction and/or the transfer transactions described below, since the blockchain source, which contains a complete copy of the transaction archive, can be stored by at least one of the nodes.

In the case where (transfer) transactions are used to transfer digital money or digital currency, the transactions may contain one or more receipts (input) or "unspent" (unspent) receipts, which indicate the amount of money owned by the node (or the user operating with node) (that is, the credit balance). In other words, receipts determine how much a user can spend in a transfer transaction. Receipts can be received from any of the nodes and / or from one of the blocks of the blockchain. Additionally, a transaction may contain one or more outputs. Each issue indicates how much money should be transferred to a specific account (that is, another node).

For example, each dispensation may indicate an account number and the amount of money to be transferred to the corresponding account number. The transaction may contain a transaction reward that is awarded to the node that validates the block that contains the transaction.

A transaction may also contain a transaction signature, such as an additional cryptographic signature that is used to sign the transaction itself. The additional cryptographic signature may be based, for example, on the private key of a user who wishes to transfer digital money to another user. An additional cryptographic signature may be based on a hash value (hash-value) of the transaction, which is encrypted using a private key, such as the user. The public key may, for example, represent an e-wallet. The additional cryptographic signature may also be referred to as an "internal" cryptographic signature, since the cryptographic signature that is added after the transaction has been generated may also be based at least in part on the internal cryptographic signature. The cryptographic signature that is added to form a signed privileged transaction (as used here) may, accordingly, be referred to as an "external" cryptographic signature. Alternatively, the cryptographic signature that is added to form a signed transaction may also be an internal cryptographic signature. In short, the cryptographic signature that is added to form a signed privileged transaction (or signed block) contains a hash value of the information contained in the privileged transaction (and/or block). The hash value may be encrypted with the first node's private key (eg, the user's private key).

It should be noted that the transaction features mentioned above may refer to the privileged transaction and/or the transfer transactions mentioned below, unless otherwise stated. A transfer transaction, as used here, refers to a transaction that transfers some amount of money from one account (or wallet) to another.

Transactions can be grouped into blocks. For example, all transactions can be grouped into one-minute blocks or ten-minute blocks. This means that all transactions that were generated within the last one or ten minutes are grouped into one block. For the avoidance of doubt, it should be noted that a block may contain only transactions, only signed transactions, only privileged transactions, only signed privileged transactions, or a mixture of the above. Thus, a signed block may contain one or more signed transactions.

Preferably, the permission is stored as a transfer transaction within the blockchain. This transfer transaction may then also be referred to as a "grant permission transaction". In other words, a user (or node) who has received an amount of money using a particular transfer transaction may thus be determined to be entitled to perform a particular transaction. This has the advantage that a mechanism native to the blockchain is used to grant specific users permission to perform a privileged transaction/block validation on the blockchain. Therefore, only minimal changes are needed to implement this permission grant, i.e., changes to the source code of the existing blockchain.

Further preferably, the permission granting transfer transaction (ie, the permission granting transaction) originates from the trusted wallet. A trusted wallet may be a wallet that receives special permissions, as described in more detail below. Thus, it can be centrally determined that transfer or authorization transactions from a trusted wallet entitle the recipient of the transfer transaction to execute a privileged transaction and/or validate a blockchain block.

Therefore, a transfer transaction (ie, a transaction granting permission) from a trusted wallet preferably contains the user's identity. The identification of the user may be, for example, the user's account number, the user's public key or public hash key, etc. A permission granting transaction from a trusted wallet may, for example, transfer a very small amount of money to the user, who will be allowed to execute a special transaction and /or it will be allowed to validate a blockchain block.

If a transfer/permission-granting transaction is used from a trusted wallet, this has the advantage that the permission-granting transaction is stored on the blockchain, so that every node on the blockchain is rewarded for that permission-granting transaction. Thus, each blockchain node is given a validation/verification opportunity if a particular user is allowed to perform a privileged transaction and/or is allowed to validate a blockchain block. Again, since all the information needed to validate user permissions is stored internally on the blockchain, this mechanism can easily be implemented on an existing blockchain. In addition, falsifying the information held to grant specific permissions is nearly impossible as copies of the blockchain typically exist within multiple blockchain nodes and typically far less than 50% of the nodes are managed by the same person or entity (more than 50% should, in some cases, allow blockchain falsification).

Preferably, the authorization remains in effect as long as the amount of money transferred in the transaction granting the authorization remains unspent. As soon as the amount of money is spent (that is, transferred to another user or to another account), the permission becomes invalid.

Preferably, the transfer transaction (i.e., the authorization transaction) transfers some amount of money from a trusted wallet to itself. In other words, the trusted wallet initiates a transfer transaction that transfers some amount of money to its own trusted wallet. This transfer transaction contains, as previously mentioned, the identity of the user who is to be granted the right to execute the privileged transaction and/or to perform block validation. As an advantage, the user cannot mistakenly spend the transferred amount (thus losing permission). In addition, the trusted wallet can then remove the permission by spending the appropriate amount, thus, for example, allowing permission to be revoked from malicious users/malicious nodes.

Alternatively, as already mentioned, a transfer transaction (that is, a transaction that grants permission) can transfer some amount of money from a trusted wallet to the user. Thus, the user directly receives the amount. Preferably, permission exists as long as the amount received from the trusted wallet is unspent.

Preferably, the trusted wallet receives the amount of money from the root wallet. In other words, the root wallet transfers some amount of money to the trusted wallet (or several different trusted wallets) before the trusted wallet can transfer the amounts to users. Thus, the granting of permissions can have several stages. For example, the various stages may be similar to a chain of certificates. In particular, the root wallet can use the grant transaction to create the first trusted wallet. The first trusted wallet can then use the grant transaction to create a second trusted wallet. This process can be repeated until the nth trusted wallet is created. The nth trusted wallet can then use the grant transaction to grant permission to the real user's wallet. Providing different permission steps can have the advantage that in case of problems, for example, only the permission of the nth trusted wallet needs to be revoked, while permissions granted to trusted wallets "closer" to the root wallet can remain intact.

Further preferably, the root wallet is defined and stored in the genesis block or in the block immediately following the genesis block of the blockchain. By keeping the root wallet in the genesis block of the blockchain, it is not possible for the blockchain to branch out of the root wallet. Thus, the security of the blockchain is further increased again.

A transfer transaction that transfers some amount of money from a root wallet to a trusted wallet may contain unspent income from the root wallet. This transaction may also be referred to as a "grant permission transaction" as mentioned above. This transfer transaction may additionally contain the address or account number (eg, in the form of a public key) of the trusted wallet as issue. Thus, the trusted wallet receives the amount of money from the root wallet. Thus, the trusted wallet is assigned the role of "certificate authority". As an alternative to containing an address or account number received from a trusted wallet or from a root wallet, the availability of funds from a trusted wallet or from a root wallet may be sufficient to grant special rights (for example, the right to act as a "certificate authority").

In the same way, an additional transfer transaction (ie, an additional grant transaction) can transfer some amount of money to the user from a trusted wallet (ie, to the user's wallet or to the aforementioned first node). This authorization transaction may contain unspent receipts from the trusted wallet. This authorization transaction may contain the user's account number or address (ie, the user's identification) as the issue. Thus, the user receives some amount of money, and this amount of money/this transfer transaction may allow the user to perform a privileged transaction. Preferably, the user is allowed to execute the privileged transaction only after the transfer transaction to the user from the trusted wallet has been included in one or more validated blocks.

Preferably, the privileged transaction performs the generation of a sum of money. In other words, a privileged transaction can be a coinbase transaction or a formation transaction, or even a ("regular") transfer transaction, where the transfer transaction can also be used to generate new coins. The number of coins, that is, the amount of money that is generated, can be based on the age of the coins for the user's coins. The age of the coins can be defined as the number of coins (i.e., the amount of money) of the user multiplied by the time the user held the coins. The amount of money generated in the privileged transaction may be credited to the user.

Further preferably, the amount of money received from the trusted wallet indicates how much money can be generated in the privileged transaction. For example, if a trusted wallet transferred 10 microcoins to a user, this could indicate that the user can form an amount equal to 10% of the number of coins he owns, or, for example, an amount of 10% of the number of coins he owns, as part of a privileged transaction. multiplied by the amount of time he owns the coins.

For example, a privileged transaction may contain as receipts at least some or all of the user's unspent receipts. The privileged transaction may also contain a reference to the amount received from the trusted wallet and/or transferred to the root wallet. Additionally, a privileged transaction may contain withdrawals that amount to more money than receipts. Thus, new money is formed, which is credited to the user.

New money can thus be created by a privileged transaction, preferably on a "proof of stake" (PoS) basis. Unlike "proof of work" (PoW), which is used in the Bitcoin blockchain, for example, PoS does not require huge amounts of energy. Therefore, the blockchain can be very energy efficient.

Further preferably, the authorization is canceled by spending the amount transferred in the transfer/authorization transaction process. The amount can be spent, for example, by the user himself or his trusted wallet. Thus, for example, if a user or node is identified as malicious, a trusted wallet can spend the amount of money transferred in the transfer transaction, which indicates a malicious user, thus revoking the malicious user's permission.

The invention also relates to a blockchain system comprising

- first node

- many other nodes, where other nodes store copies of the blockchain, and the nodes are connected to each other using data connections and the first node is configured to

- formation of a privileged blockchain transaction for the user,

- preferably, using the user's private key, adding a cryptographic signature to the privileged transaction, thus creating, preferably, a (signed) privileged transaction,

- broadcasting a (signed) privileged transaction to a plurality of other nodes on the blockchain, where other nodes are executed with validation capability, if the user is allowed to perform the privileged transaction and if the permission to perform the privileged transaction was stored internally on the blockchain before the privileged transaction was generated,

and/or

wherein the first node is configured to validate a blockchain block for a user, where the first node is configured to

- formation of a blockchain block, where the block contains one or more transactions,

- preferably, adding a cryptographic signature using the private key of the first node, thus creating, preferably, a (signed) block,

- broadcasting a (signed) block to a plurality of other nodes on the blockchain, where the other nodes are configured to verify the cryptographic signature of the signed block using the user's public key, the nodes validating if the user is allowed to validate the block and the permission to validate the block has been stored within the blockchain before block validation.

The invention ultimately relates to a blockchain node device in which the node device is configured to

- formation of a privileged blockchain transaction for the user,

- preferably, using the user's private key, adding a cryptographic signature to the privileged transaction, thus preferably creating a (signed) privileged transaction,

- broadcasting a signed privileged transaction to many other blockchain nodes,

and/or

wherein the first node is configured to validate a blockchain block for a user, where the first node is configured to

- formation of a blockchain block, and the block contains one or more transactions,

- preferably, using the private key of the first node to the block, adding a cryptographic signature, thus creating a (signed) block,

- broadcast distribution of the signed block to many other nodes of the blockchain.

The disclosure related to the methods of the invention also relates to the inventive system and to the inventive assembly device. It is particularly valid in terms of the advantages and preferred embodiments mentioned here.

The various features and advantages of the present invention will become more apparent from the following description and accompanying drawings, in which:

fig. 1 - schematic representation of the blockchain;

fig. 2 is a schematic representation of the principle of operation of the blockchain, when a privileged transaction is formed and distributed.

In FIG. 1 shows a blockchain 10 containing many different blocks 12. Each of the blocks 12 links to the previous block 12. Each block 12 contains many transactions 14.

The first block 12 is called the genesis block 16. The genesis block 16 stores the address of the root wallet 18. Alternatively, the genesis block 16 may be empty except for the coinbase. The root wallet address 18 can then be stored in a subsequent block 12.

As an example, the genesis block 16 may also contain a transfer transaction 14 (i.e., a grant transaction) from the root wallet 18 to the trusted wallet 20.

The trusted wallet 20 may transfer some amount of money to the user's wallet 22, where the transfer transaction 14, which transfers a certain amount to the user's wallet 22, is stored in another block 12. transactions 14a. Alternatively, trusted wallet 20 may use transfer transaction 14 to transfer some amount to itself (ie, trusted wallet 20). This transfer transaction 14 may contain information about the user's wallet 22, thus granting the user of the wallet 22 the right to perform privileged transactions 14a.

The process of generating and processing a privileged transaction 14a is shown in FIG. 2.

In FIG. 2 shows the first node 24, the second node 26, the third node 28 and the fourth node 30. Nodes 24-30 perform the functions of the blockchain 10. Nodes 24-30 are interconnected using data connections 32 (for example, Ethernet connections). Nodes 24-30 may be identical instances of the same kind of nodes 24-30, in which in the following, the first node 24 is an example described in more detail.

Each of nodes 24-30 stores a copy of blockchain 10.

The first node 24 generates a privileged transaction 14a. The first node 24 then cryptographically signs the privileged transaction and transmits the signed privileged transaction 14 to other nodes 26-30. The other nodes 26-30 then check against their copies of the blockchain 10 if the first node 24 has received some amount of money from the trusted wallet 20 in the past and if the amount of money that was received from the trusted wallet 20 is still not spent (or if the amount which the trusted wallet 20 transferred to itself is still not spent). If such a case occurs, the other nodes 26-30 accept the privileged transaction 14a and, for example, the amount of money is credited to the user's wallet 22 for the user of the first node 24 (coinbase).

However, if the other nodes 26-30 detect that either no transaction exists from the trusted wallet 20 to the user's wallet 22, or that the amount that was transferred from the trusted wallet 20 to the user's wallet 22 has already been spent (that is, the authorization has been revoked), then privileged transaction 14a is not accepted. Thus, for example, a malicious node or user can be excluded from performing privileged transactions 14a. Thus, the security of the blockchain 10 is improved.

Note that the above is correspondingly valid for block validation 12. In this case, privileged transaction 14a in FIG. 2 should be replaced by block 12.

List of reference positions

10 - Blockchain

12 - Block

14 - Transaction

14a - Privileged transaction

16 - Genesis Block

18 - Root Wallet

20 - Trusted Wallet

22 - User wallet

24 - First node

26 - Second node

28 - Third node

30 - Fourth knot

32 - Data connection.

Claims (28)

1. A method for forming a privileged transaction (14a) in a blockchain (10), comprising the steps of: a privileged transaction (14a) is formed by the user through the first node (24) of the blockchain (10), adding a cryptographic signature using the user's private key to the privileged transaction (14a), thereby creating a signed privileged transaction (14a), broadcasting the signed privileged transaction (14a) to a plurality of other nodes (26-30) of the blockchain (10), wherein the other nodes (26-30) check whether the user is allowed to perform the privileged transaction (14a), with permission to execute the privileged transaction (14a) was stored on the blockchain (10) prior to the formation of the privileged transaction (14a), wherein the permission is stored as a transfer transaction (14) on the blockchain (10), and the transfer transaction (14) granting the permission originates from the trusted wallet (20). 2. A method for validating a block (12) of a blockchain (10), comprising the steps of: a block (12) is formed by the user of the blockchain (10) by means of the first node (24) of the blockchain (10), wherein the block (12) contains one or more transactions (14), add a cryptographic signature using the private key of the first node (24) to the block (12), thereby creating a signed block (12), broadcasting the signed block (12) to a plurality of other nodes (26-30) of the blockchain (10), wherein the other nodes (26-30) check whether the user is allowed to validate the block (12), and the permission to validate the block (12) has been retained on the blockchain (10) until the block (12) is validated, wherein the permission is stored as a transfer transaction (14) in the blockchain (10), and the transfer transaction (14) granting the permission originates from the trusted wallet (20). 3. The method according to claim 1 or 2, wherein the transfer transaction (14) contains a user indication. 4. The method according to any one of paragraphs. 1-3, in which the transfer transaction (14) transfers to itself (20) the amount of money from the trusted wallet (20). 5. The method according to any one of paragraphs. 1-3, in which the transfer transaction (14) transfers to the user (22) the amount of money from the trusted wallet (20). 6. The method according to any one of paragraphs. 1-5, in which the trusted wallet (20) receives the amount of money from the root wallet (18). 7. The method according to claim 6, wherein the root wallet (18) is determined and stored in the genesis block (16) of the blockchain (10). 8. The method according to any one of paragraphs. 1-7, in which the privileged transaction (14a) performs the formation of a sum of money. 9. The method according to any one of paragraphs. 3-8, in which the authorization is canceled by spending the amount transferred in the transfer transaction (14). 10. Blockchain system (10) containing first node (24), many other nodes (26-30), with nodes (24-30) storing copies of the blockchain (10), wherein the nodes (24-30) are connected to each other using connections (32) for data transmission, wherein the first node (24) is configured to: formation for the user of a privileged transaction (14a) of the blockchain (10), adding a cryptographic signature using the user's private key to the privileged transaction, thereby creating a signed privileged transaction (14a), broadcasting the signed privileged transaction (14a) to a plurality of other nodes (26-30) of the blockchain (10), wherein the other nodes (26-30) are configured to check whether the user is allowed to perform the privileged transaction (14a), while allowing the privileged transaction to be performed (14a) was stored on the blockchain (10) prior to the formation of the privileged transaction (14a), with the permission stored as a transfer transaction (14) on the blockchain (10) and the transfer transaction (14) granting the permission comes from a trusted wallet ( 20); and/or the first node (24) is configured to validate the block (12) of the blockchain (10) for the user, and the first node (24) is configured to: forming a block (12) of the blockchain (10), wherein the block (12) contains one or more transactions (14), adding a cryptographic signature using the private key of the first node (24) to the block (12), thereby creating a signed block (12), broadcasting the signed block (12) to a plurality of other nodes (26-30) of the blockchain (10), wherein the other nodes (26-30) check whether the user is allowed to validate the block (12), and the permission to validate the block (12) has been retained on the blockchain (10) until the block (12) is validated, whereby the permission is stored as a transfer transaction (14) in the blockchain (10) and the transfer transaction (14) granting the permission originates from the trusted wallet (20).

Images