Method and apparatus for recording work history and proving reputation in a blockchain network

Abstract

Methods and systems for recording a work history of a dedicated network node on a blockchain in a blockchain network. The method may include mining a first block containing a registration genesis transaction, the registration genesis transaction including an identifier of the dedicated network node within a registration information field; and mining two or more additional blocks in sequence, each additional block containing a genesis transaction, the genesis transaction including an information field, the information field including the identifier of the dedicated network node, a reference to the genesis transaction of the preceding additional block in the sequence, wherein the registration genesis transaction is the first block in the sequence. The work history may be verified by tracking the recorded work history and verifying the identifier of the dedicated network node. The recorded work history may be used as the basis for a reputation score of the dedicated network node, the reputation score reflecting the contributed work demonstrated by the work history secured by proof of work.

Description

Technical Field

[0001] The present disclosure relates to blockchain networks, and more particularly to recording work history and proving reputation in a blockchain network. Background Art

[0002] Dedicated network nodes are a key element of blockchain networks. In a "proof of work" blockchain network, dedicated network nodes compete to complete proof of work in order to "win" the race to mine blocks, thereby collecting transaction fees and any newly created tokens reflected in the coinbase transaction within the new block. In this way, dedicated network nodes secure the network, ensuring that transactions are valid and that all participating nodes comply with the prevailing blockchain protocol. However, since most blockchains operate as permissionless protocols, any node can join or leave the network, and any node is able to participate as a dedicated network node without the prior approval of any other node. As blockchain usage and transaction volume grows, it may also become increasingly important to properly register and verify the identity of dedicated network nodes (or pools of dedicated network nodes).

[0003] For example, when it comes to changing blockchain protocols, arbitrary or "top-down" code changes can undermine confidence in the stability and determinism of the system and can expose the blockchain network to attack or possible fraud or theft. As a consensus-based system, any changes to the underlying code of a blockchain network require agreement by the entities that make up the system. In practice, this means that specialized network nodes must agree to the change, as they are the entities that validate transactions, assemble candidate blocks, and perform the expensive work of mining new blocks. It can be advantageous to be able to track and verify the identity of a specialized network node (or pool of specialized network nodes).

[0004] One mechanism for registering and verifying identities in a computer network is through the use of a public key cryptographic infrastructure. The public key in a key pair can represent a node identifier. In such a system, a node obtains a public-private key pair and then requests to register its public key with a third-party certificate authority. The certificate authority performs some level of online or offline authentication of the node and issues a digital certificate for the public key, verifying that the public key is associated with the node. The digital certificate can be issued by a certificate authority. Different nodes that wish to verify the identity of the node rely on their trust in the certificate authority to support the authentication of the node identity represented by the digital certificate.

[0005] Blockchain systems are typically permissionless, meaning that any node can join or leave the network, and other nodes cannot control whether a node joins the network. This flexibility is important to ensure that resources are allocated efficiently and allow computing resources to be added as needed and economically justified. However, in some cases and scenarios, it would be advantageous to be able to verify that a node (e.g., a dedicated network node) is a "reputable" node in the blockchain network for the purposes of trust, reliability, and stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, in which:

[0007] Figure 1 A simplified example method of registering the identity of a dedicated network node on a blockchain is shown in the form of a flow chart;

[0008] Figure 2 An example method of setting a fast revocation option for registering an identity of a dedicated network node is shown in flowchart form;

[0009] Figure 3 An example method of recording the identity of a dedicated network node on a blockchain is shown in the form of a flow chart;

[0010] Figure 4 An example method of verifying an identifier of a specialized network node is shown in flowchart form;

[0011] Figure 5 An example method of recording work history on a blockchain is shown;

[0012] Figure 6 An example method of using blockchain to verify work history is shown;

[0013] Figure 7 An example method of determining a reputation score for a dedicated network node based on a recorded work history is shown; and

[0014] Figure 8 A simplified example of a computing node (eg, a specialized network node) is shown in block diagram form.

[0015] The same reference numbers are used throughout the drawings to represent the same elements and features.

[0016] Specific implementation method

[0017] In one aspect, a computer-implemented method of recording a work history of a dedicated network node on a blockchain in a blockchain network may be provided. The method may include mining, by the dedicated network node, a first block containing a registration generation transaction, the registration generation transaction including an identifier of the dedicated network node within a registration information field; and mining, by the dedicated network node, two or more additional blocks in sequence, each additional block containing a generation transaction, the generation transaction including an information field including the identifier of the dedicated network node and a reference to a generation transaction of a preceding additional block in the sequence, wherein the registration generation transaction is the first block in the sequence.

[0018] In some implementations, the identifier of the dedicated network node may be a public key for which the dedicated network node holds a private key.

[0019] In some implementations, the genesis transaction in each append block can include a registration reference and a digital signature pointing to the registration genesis transaction.

[0020] In some implementations, the reference to the genesis transaction of a preceding additional block in the sequence may include one of a transaction identifier, a block number, or an outpoint.

[0021] In some implementations, the method may further include: verifying, by the computing node, the work history recorded on the blockchain. In some cases, the verification may include: identifying the last block in the sequence; retrieving genesis transactions from the additional block in reverse order from the blockchain based on a reference to a genesis transaction of a preceding additional block contained in each genesis transaction; retrieving a registration genesis transaction; and verifying registration of the identifier of the specialized network node in the registration genesis transaction. The registration genesis transaction and the genesis transaction provide a work history for the specialized network node.

[0022] In some implementations, the method may further include determining a reputation score for the specialized network node based on a recorded work history of the specialized network node. In some cases, the determination includes calculating the reputation score based on a count of the number of blocks in the sequence. In some cases, the determination includes calculating the reputation score based on assigning a corresponding weight to each block in the sequence and calculating a sum of the corresponding weights. In some such examples, assigning a corresponding weight to each block includes, for each block, determining a difficulty score for the block based on a difficulty threshold applied when mining the block, and setting a corresponding weight based on the difficulty score. In some examples, the reputation score may be calculated as:

[0023]

[0024] In the above expression, Rep ID is the reputation score, i is the index of the ith block, B is the number of blocks in the sequence, and T i is the target difficulty to apply when mining block i.

[0025] In some implementations, the method may further include recording the weighted vote in a secure blockchain-based voting system by mining a voting block by a dedicated network node, wherein the voting block includes a genesis transaction, the genesis transaction including an identifier of the dedicated network node of the voting block, a reference to a most recent genesis transaction of the voting block, and a voting signal. In some cases, the voting block genesis transaction also includes a reputation score calculated for the dedicated network node.

[0026] In another aspect, the present application may describe a computer-implemented method of verifying a work history of a specialized network node on a blockchain in a blockchain network. The method may include: identifying a block mined by the specialized network node and having a genesis transaction, the genesis transaction including an identifier of the specialized network node and a reference to an earlier genesis transaction in an information field; retrieving a plurality of earlier genesis transactions from the blockchain in reverse order until a final genesis transaction including a registration of an identifier of the specialized network node, each earlier genesis transaction including an identifier of the specialized network node and a reference to a corresponding preceding one of the earlier genesis transactions in reverse order; and verifying the registration of the identifier of the specialized network node in the final genesis transaction. The genesis transaction and the plurality of earlier genesis transactions provide a work history of the specialized network node.

[0027] In another aspect, the present application may provide a computer-implemented method for determining a reputation score of a dedicated network node in a blockchain-based blockchain network. The method may include: tracing a chain of linked genesis transactions, wherein the genesis transactions each include an identifier of the dedicated network node in an information field, and each genesis transaction except the first genesis transaction includes a reference to an earlier genesis transaction in the linked genesis transactions in the chain in an information field, wherein each genesis transaction is in a corresponding block mined by the dedicated network node; for each genesis transaction, determining a difficulty score of its corresponding block; and determining a reputation score of the dedicated network node based on the difficulty score of the corresponding block associated with the genesis transaction in the chain.

[0028] In another aspect, a computing device implementing a node in a network may be provided. The computing device may include a memory, one or more processors, and computer executable instructions that, when executed, cause the processor to perform one or more of the methods described herein.

[0029] In yet another aspect, a computer-readable medium storing processor-executable instructions for operating a node in a network may be provided, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to perform at least one of the methods described herein.

[0030] Other example embodiments of the present disclosure will become apparent to those of ordinary skill in the art by reviewing the following detailed description in conjunction with the accompanying drawings.

[0031] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including any one, any subcombination or all of the elements listed individually, and does not necessarily exclude additional elements.

[0032] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any subcombination or all elements, without necessarily excluding any additional elements and without necessarily requiring all elements.

[0033] This application will refer to hashing or hash functions, which are intended to include any of a number of cryptographic hash functions that, when applied to an arbitrary set of data or "messages", deterministically produce a unique fixed-length alphanumeric string. The result of a hash function may be referred to as a hash value, fingerprint, hash result, or equivalent. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0034] In this document, the term "blockchain" is understood to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations.

[0035] A blockchain is a peer-to-peer electronic ledger implemented using a decentralized, distributed computer system. The blockchain consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes, among other possible information, the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block header contains a summary of the block's contents, for example in the form of a Merkle root, and each block header contains a hash of the previous block header so that blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed.

[0036] Blockchain is implemented on a network of nodes. Each node is a computing device with network connectivity and execution software that executes the applicable blockchain protocol. Nodes verify transactions and propagate them to other nodes in the network. Specialized network nodes collect a collection of unconfirmed transactions (i.e., pending transactions) into a block and attempt to "mine" the block. In these examples, mining refers to solving the proof of work before any other specialized network node in the network successfully solves the proof of work (POW) for its corresponding block. The random number that is used only once is repeatedly incremented and the hashing process is repeated until the result is less than a threshold or until the specialized network node receives notification that another specialized network node has succeeded. Variations in the mining process are familiar to those of ordinary skill in the art.

[0037] The unlocking script of the transaction output defines how to prove "control" of the output in order to be used. In many cases, the address associated with the transaction output is a hash of the public key. In order to prove control of the output, the unlocking script usually requires the public key and a digital signature generated using the corresponding private key. In this way, the node that controls the private key can control when and how the transaction output is used in any subsequent input. As will be discussed further below, this has the following corollary: when a transaction input corresponding to a particular public key includes a digital signature, then the entity associated with that particular public key effectively signs or authenticates the transaction content.

[0038] Public key cryptography has become ubiquitous in online communications. In many cases, procedures and policies are needed to provide certainty that a public key is owned by an entity associated with a specific entity. The most common way to ensure that a public key is authentic and has not been compromised is a public key infrastructure (PKI). PKI relies on a trusted third party to "authenticate" whether a public key is valid. These entities are "certificate authorities" (CAs). CAs provide registration and issuance of digital certificates that confirm the binding between a public key and a specific owner. The holder of a public key provides its public key and its digital certificate to another entity. The other entity can then verify the authenticity of the public key by confirming that a trusted CA has digitally signed the certificate.

[0039] As mentioned above, specialized network nodes are key to securing a blockchain network. Dedicated network nodes are compensated for their work when they win the race to find a valid new block. The compensation comes in the form of transaction fees from individual transactions and "coinbase" transactions included in new blocks. A coinbase transaction has no inputs, and it outputs a specified number of tokens (e.g., currency) to a dedicated network node, effectively creating a new token. A coinbase transaction may also be referred to as a "genesis transaction," so these terms may be used interchangeably herein. Coinbase transactions or genesis transactions have certain features that distinguish them from regular transactions. For example, each valid block contains only one genesis transaction. Each genesis transaction has no inputs and generates a number of token outputs set by the then-current block reward due to successful dedicated network nodes in accordance with the governing blockchain protocol. A genesis transaction is a "proof-of-work transaction" because it can only be created by a dedicated network node that has successfully mined a block (i.e., completed proof of work).

[0040] In many blockchain systems, a single entity may own, control, or direct a large number of individual computers that act as specialized network nodes. In some cases, the resources of multiple specialized network nodes may be pooled together in a mining pool that utilizes the computing power of a large number of individual processors. In many of the examples below, references may be made to a "specialized network node" or a public-private key pair held or controlled by a specialized network node. As will be understood from the context, these references may include individual computers that implement specialized network nodes and / or collections or pools of computers / processors that implement a mining pool owned or controlled by a mining entity.

[0041] Given the importance of specialized network nodes, it would be advantageous to be able to verify the authenticity and identity of specialized network nodes and / or public keys claimed by specialized network nodes. It would be particularly advantageous to be able to do this verification without relying on trust in a third-party certificate authority.

[0042] Establish verifiable identities of dedicated network nodes

[0043] According to one aspect of the present application, a dedicated network node can establish the identity of a dedicated network node by mining a block that includes a statement of the identity of the dedicated network node within a coin creation transaction. The validity of the newly mined block and the validity of all transactions therein are confirmed by the blockchain network. The dedicated network node includes an identity statement in the coin creation transaction that its identity is supported by proof of work. The identity of the dedicated network node in the following example is a public key. There is no need for a third-party CA to verify the association between the dedicated network node and its declared public key because the association is supported by the blockchain network and proof of work.

[0044] To facilitate the possible revocation of the identity of a dedicated network node, for example, if the corresponding private key is compromised, the dedicated network node may first create a validity check transaction in which the identity of the dedicated network node is asserted and there are outputs for that transaction that are controlled by the dedicated network node. The creation transaction may include a reference to the validity check transaction. Part of the authentication operation performed by another node may be used to confirm that the validity check transaction has not been "revoked" by transferring the outputs controlled by the dedicated network node. This provides a fast revocation mechanism that does not rely on mining new blocks to revoke the identity of the dedicated network node.

[0045] Now refer to Figure 1 , which shows in the form of a flowchart an example method 100 for establishing the identity of a dedicated network node in a blockchain network. The method 100 includes a setup operation 102 and a registration operation 104. The setup operation 102 includes creating and propagating a validity check transaction (VCT). The VCT includes any input and two outputs. One output is an output controlled by the dedicated network node, which assigns any token to an address controlled by the dedicated network node. The second output of the VCT includes an information field, which contains the identity of the dedicated network node, in this example, the identity of the dedicated network node is a public key PK selected by the dedicated network node. ID . A dedicated network node holds the corresponding private key sk ID In this example, the identity of a dedicated network node (eg, a dedicated network node ID) is the public key PK ID .

[0046] VCT is propagated across the blockchain network where it is ultimately confirmed by inclusion in a mined block, making the VCT on-chain.

[0047] The registration operation 104 involves the specialized network node successfully mining a new block. Mining a block involves assembling a candidate block that contains multiple transactions selected from a memory pool of unconfirmed transactions. The specialized network node also inserts a coin creation transaction into its candidate block. It then attempts to mine a block by repeatedly incrementing a random number in a block header that is only used once and hashing the block header to try to find a hash value that is less than the difficulty setting. If another specialized network node succeeds, the specialized network node verifies whether the new block of the other specialized network node is valid, then creates a new candidate block and tries again.

[0048] In operation 104, the dedicated network node successfully mines a new block, and the new block contains a coin creation transaction, which itself contains the identity of the dedicated network node (e.g., PK ID) and contains a reference to the VCT. For example, the reference can be the transaction identifier TxID of the VCT VCT .

[0049] Once a dedicated network node has successfully mined a block containing a coin creation transaction that asserts the identity of the dedicated network node, it has successfully established its identity. The identity is verifiable and can be revoked or updated by the dedicated network node in a provable and traceable manner when necessary. Furthermore, the identity and its association with the dedicated network node is supported by proof of work and secured by the network, thereby allowing third parties to rely on the identity of the dedicated network node (e.g., its public key PK ID ) without requiring trust in a certificate authority. The identity of a dedicated network node can then be used for a variety of purposes, including tracking the activities of a dedicated network node, proving the authenticity or status of a dedicated network node, establishing or participating in secure encrypted communications with a dedicated network node, and ranking dedicated network nodes for various purposes.

[0050] Now we will also refer to Figure 2 , which shows an example setting method 200 that can be used in the method 100 of establishing the identity of a dedicated network node. The method is performed by the dedicated network node in this example.

[0051] In operations 202 and 204, the dedicated network node selects a private key sk ID And find the corresponding public key PK ID . Public key PK ID Is an identifier for a dedicated network node.

[0052] Then, in operation 206, the specialized network node creates a validity check transaction with any input and two outputs. In many implementations, the input can be an amount of currency or tokens sufficient to offset any transaction costs associated with the VCT to ensure that the VCT is included in the block. In some implementations, a minimum amount of tokens can be established by policy.

[0053] One of the outputs is an output to any address controlled by the dedicated network node. That is, the output is to an address for which the dedicated network node holds a corresponding private key to enable the dedicated network node to unlock the associated locking script. In some examples, the output address may be labeled PK VCT , which is any public key chosen by a dedicated network node and holds the corresponding private key for it. For example, an output can be a P2PKH (payment to public key hash) operation, which specifies a transfer to a public key hash chosen and controlled by a dedicated network node.

[0054] Another output includes a non-operational information field into which information can be inserted. In particular, this field contains the identifier PK of the dedicated network node ID .

[0055] There may be blockchain protocols in which non-operational information fields may be included in transactions, for the purpose of publishing information within a transaction without that information being necessarily implemented as an "output" of the transaction, as that term may be understood. However, it should be understood that the term "output" in these examples refers to information fields that are intended to include such possible implementations on alternative blockchain protocols.

[0056] Once the VCT has been created in operation 206, in operation 208, the specialized network node propagates the VCT on the blockchain network. Those of ordinary skill in the art will appreciate that the propagation of the VCT may involve each node of the network verifying the transaction and then sending it to all other nodes to which the node is connected, so that the transaction is quickly propagated through the entire blockchain network. As an unconfirmed transaction, it will be inserted into the memory pool, from which each specialized network node will select transactions to include in the candidate blocks. Therefore, it will eventually be "confirmed" by being included in the mined block. In operation 210, the specialized network node evaluates whether the VCT has been confirmed by being included in the mined block. Once it has been confirmed, in operation 212, the specialized network node records the transaction identifier TxID VCT It should be appreciated that in some implementations, dedicated network nodes may record transaction identifiers before VCT is mined.

[0057] Now we will also refer to Figure 3 , which shows an example registration method 300 that can be used in the method 100 of establishing the identity of a dedicated network node. The method is performed by the dedicated network node in this example. The method 300 assumes that an identifier PK of the dedicated network node is created. ID The associated validity check transaction's setup operation has already occurred.

[0058] In operation 302, the dedicated network node creates a candidate block. The candidate block contains a plurality of transactions selected from a memory pool of unconfirmed transactions. The dedicated network node then inserts a coin creation transaction in the candidate block, as reflected in operation 304. In addition to creating a specified number of new tokens or currencies for the dedicated network node, the coin creation transaction also includes an information field that contains an identifier PK of the dedicated network node. ID and a reference to the VCT. The reference can be a transaction identifier TxID VCT For example, an OP_RETURN code or equivalent may be used to provide the information field.

[0059] In addition to the identifier of the dedicated network node and a reference to the VCT, the information field may also contain additional information. For example, it may contain an action identifier or code indicating what action is being achieved through the coin creation transaction. In this example, the action may be "register" to indicate that the dedicated network node is publicly registering its identifier. It may also or instead include a signature. As an example, the signature may be a signature of the rest of the information field, for example, the signature: Sig(sk ID , action||dedicated network node ID||VCT), where VCT is TxID VCT , the dedicated network node ID is PK ID .

[0060] Once a candidate block with the coinbase transaction has been generated, the specialized network node attempts to mine the block, as shown in operation 306. It also evaluates whether a competing specialized network node has successfully mined another block, as shown in operation 308. If the competing specialized network node wins the race to mine the block, the specialized network node verifies the other block, adds it to the blockchain, and returns to operation 302 to build a new candidate block and try again.

[0061] If a dedicated network node successfully mines a candidate block, it will record the transaction identifier TxID of the coin creation transaction. REG Note that it could have written down the block number instead, as it would then only contain one coinbase transaction that other nodes might be able to identify based on the block number.

[0062] After successfully mining a block using the registration coin creation transaction, the dedicated network node has successfully registered its identity and published it on the blockchain. ID ) can verify that the public key is valid and associated with a dedicated network node, without relying on trust in an independent certificate authority.

[0063] Figure 4 An example method 400 that a node may perform to verify an identifier of a dedicated network node according to an aspect of the present application is shown in the form of a flowchart. A node is any node inside or outside the blockchain network that verifies the identifier PK of a dedicated network node. ID For example, authentication may be performed as verifying or approving a request from a dedicated network node, establishing a communication session with a dedicated network node, or otherwise proving a public key PK. ID The effectiveness of and its association with a dedicated network node occurs as part of the.

[0064] In operation 402, the node receives or retrieves a unique network node ID (PK ID) and register a transaction identifier (TxID REG , or in some cases, the block number in which the registration coin creation transaction appears). Operation 402 may also include retrieving or receiving a message that the dedicated network node claims to have signed. The message m and the signature σ m It may be provided by a dedicated network node. In some cases, the message and its signature may be part of a digital certificate provided or issued by a dedicated network node as proof of its identity.

[0065] In operation 404, the node registers a transaction identifier TxID based on REG The register coin creation transaction is retrieved from the blockchain. Then in operation 406, it verifies or confirms certain data in the register coin creation transaction. For example, the node can parse the OP_RETURN field to extract the information in that field from the coin creation transaction. From the parsed information, it obtains the VCT transaction identifier TxID VCT It can confirm that the OP_RETURN field includes the same public key PK provided by the dedicated network node ID , and the Action is Register.

[0066] Based on the VCT transaction identifier issued in the registration coin creation transaction, the node can retrieve the VCT in operation 408. The node can confirm that the OP_RETURN field in the VCT has the same public key PK ID , as shown in operation 410. It may then evaluate whether another output of the VCT remains "unspent".

[0067] Note that operation 414 may include the node confirming the signature within the OP_RETURN field of the coin creation transaction (if any), or the node confirming the signature σ on the message m m , or the node confirms both. Obviously, if the signature check fails, then the claimed dedicated network node cannot be verified as the holder of the corresponding private key, and thus the verification fails. If the signature check succeeds, the dedicated network node is verified as the holder of the corresponding private key (i.e., the verified registered public key PK ID )A dedicated network node associated with the

[0068] However, a dedicated network node may also register a revocation by including an OP_RETURN field in the coin creation transaction of its next mined block. In one example, the OP_RETURN may include the action "revoke" and the dedicated network node ID. In some implementations, it may also include transaction identifiers and signatures for both the registration transaction and the revocation transaction.

[0069] In many cases, a dedicated network node may wish to "renew" or replace its ID rather than simply revoke it because its private key has been compromised. This may be due to the disclosure or theft of a private key, or may be done periodically as part of risk management to ensure that key material is regularly updated.

[0070] To update the old dedicated network node ID PK ID-OLD , the dedicated network node first generates a new public key PK ID-NEW Create a new VCT. From this process, it obtains a new VCT transaction identifier TxID VCT-NEW The dedicated network node then mines a new block with the new coin creation transaction to register the new dedicated network node ID; however, in order to link the new dedicated network node ID to the old ID and any work history of the old ID, the dedicated network node may use the action "update" or "update-id" to signal that the coin creation transaction is not just registering the dedicated network node ID for the first time, but is replacing the previous dedicated network node ID. The contents of the OP_RETURN field in the updated coin creation transaction may include:

[0071] 1. Action: Update ID

[0072] 2. Old dedicated network node ID: PK ID-OLD

[0073] 3. New dedicated network node ID: PK ID-NEW

[0074] 4. Old dedicated network node ID signature:

[0075] Sig(SK ID-OLD PK ID-OLD ||PK ID-NEW )

[0076] 5. Old VCT signature: Sig(SK VCT , PK ID-OLD ||PK ID-NEW )

[0077] 6. New VCT: TxID VCT-NEW

[0078] 7. New signature:

[0079] Sig(sk ID-NEW , action||new dedicated network node ID||new VCT)

[0080] In this example, it should be understood that the update operation involves the dedicated network node providing up to three signatures: one associated with the old dedicated network node ID, one associated with the old VCT, and one associated with the new dedicated network node ID. In some cases, the old VCT signature may not be included.

[0081] It should also be understood that a specialized network node may invalidate an earlier specialized network node ID by using an output from an old VCT as an input to some other transaction. In one example, the output may be an input to a new VCT. In another example, a specialized network node may wait until it successfully mines a block to register the updated specialized network node ID before propagating a separate revocation transaction to invalidate its old specialized network node ID.

[0082] Using the above system, a dedicated network node is able to establish and register its provable identifier on the blockchain. By including the identifier in the coin creation transaction of the mined block, the dedicated network node proves that it is a genuine dedicated network node, and the validity of the identifier and associated materials is supported by proof of work. VCT provides a rapid revocation mechanism if necessary. In some example implementations, VCT can supplement proof of work with proof of stake by requiring at least a predetermined token or monetary value to be assigned to the output through a policy. Advantageously, the above system avoids the need for trust in a certificate authority and involves no additional work by the dedicated network node and very little additional data in the block.

[0083] The above-described registration system and method enables a specialized network node to prove identity and provide the specialized network node with a digital certificate that another node can verify without relying on a certificate authority. In addition, as described below, the identifier of the specialized network node can be used to provably link coin creation transactions from blocks mined by the specialized network node. This provides the specialized network node with a verifiable work history associated with its ID. This work history can be used to establish many things, including the status of the specialized network node, the right to access certain resources, ranking the hierarchy of specialized network nodes for some purpose, etc. In the following description, this work history may be referred to as a "reputation proof" system.

[0084] Proof of Reputation

[0085] In one aspect, the present application provides methods and systems for recording the work history of a specialized network node on a blockchain and for verifying the work history of a specialized network node. As will be described, in the following example, the work history is recorded by a chain of coin creation transactions linked in a block mined by a specialized network node. In some implementations, the work history can be used to determine a reputation score for a specialized network node. Reputation scores can be used in many applications, including voting operations of specialized network nodes as an example.

[0086] In some implementations described below, the coin creation documents each include an identifier of a dedicated network node in an information field. In some implementations, the above-described methods and systems may be used to establish and verify the identifier of a dedicated network node. However, in some implementations, other techniques or systems may be used to establish the identifier of a dedicated network node and for verification purposes. Therefore, it should be understood that the work history and reputation proof examples described below do not necessarily require the use of the dedicated network node identifier registration process described above in all implementations.

[0087] As described above, one mechanism for registering an identifier of a specialized network node is to place the identifier of the specialized network node in a coin creation transaction of a block mined by the associated specialized network node. The identifier of the specialized network node may appear in an information field (e.g., an OP_RETURN field) in a coin creation transaction. The information field may also include a signature or other data. As described above, in some implementations, the information field may include a reference to a validity check transaction, which enables the specialized network node's identifier to be quickly revoked and enables other parties to easily verify that the specialized network node's identifier has not been revoked.

[0088] The coin creation transaction may also be utilized in conjunction with the registered dedicated network node identifier to record the dedicated network node's operating history. Figure 5 An example method 500 for recording the work history of a dedicated network node on a blockchain is shown in the form of a flow chart. The method 500 is performed by a dedicated network node associated with an identifier of the dedicated network node. The identifier of the dedicated network node may be a public key, and the dedicated network node holds a corresponding private key for the public key, i.e., the identifier of the dedicated network node may be a PK ID .

[0089] The method 500 includes registering an identifier of a dedicated network node in operation 502. As described above, the registration operation includes publishing the identifier of the dedicated network node in a registration coin creation transaction within a block mined by the dedicated network node.

[0090] In operation 504, the specialized network node continues to attempt to mine a new block. In particular, the specialized network node constructs a new candidate block and inserts a coin creation transaction, which includes an information field that contains an identifier of the specialized network node. The coin creation transaction information field also contains a reference to a previous coin creation transaction in a block mined by the same specialized network node. The previous coin creation transaction is a recently mined block in which the coin creation transaction contains the identifier of the specialized network node. In the case of the second mined block, the reference is to a registered coin creation transaction. Subsequent mined blocks from the specialized network node will contain coin creation transactions that are linked by references to the coin creation transactions of the most recently mined block in the order in which the blocks were mined. For example, the reference can be a transaction identifier (e.g., TxID) of the coin creation transaction. In some cases, based on the fact that the node can identify the coin creation transaction within the block, the reference can be the block number containing the coin creation transaction. In some cases, the reference may be an "outpoint", which includes the TxID and a reference to one of the outputs of the coinbase transaction (specifically an OP_RETURN output).

[0091] In some implementations, the information field includes additional information. For example, in addition to a reference to the coin creation transaction of the most recently mined block from the dedicated network node, the information field may also include a reference to the registered coin creation transaction in each subsequent block mined by the dedicated network node. As another example, the information field may include a digital signature generated based on an identifier of the dedicated network node (i.e., using a private key associated with the identifier of the dedicated network node). For example, the digital signature may be the reference(s) included in the information field.

[0092] Once a candidate block with a coin creation transaction has been created in operation 504, the specialized network node attempts to mine the block in operation 506. It also monitors for receipt of notification of a new block from another specialized network node in operation 508. If the other node successfully finds a new block, the specialized network node verifies that the new block is valid according to the applicable blockchain protocol in operation 510, and then adds the new block to the blockchain. If the specialized network node successfully mines the candidate block before receiving notification of a new block from another node, it quickly propagates the successful mining of the candidate block on the blockchain network and adds the new block to the blockchain in operation 512. Regardless of whether the new block on the blockchain comes from the specialized network node or another node, once the new block is found, the specialized network node returns to operation 504 to build a new candidate block and try again.

[0093] It will be appreciated that, assuming that a dedicated network node occasionally successfully mines a new block, the above cycle results in a chain of linked coin creation transactions linking the block mined by the dedicated network node from the most recent blockchain back to the original registered coin creation transaction. Since the OP_RETURN data is visible on the blockchain, the linked set of coin creation transactions is easily identified as a published record of the work history of the dedicated network node, each of which contains an identifier for the dedicated network node.

[0094] Reference now Figure 6 , which shows an example method 600 of verifying the work history of a dedicated network node from a blockchain. The method 600 can be performed by any computing node, whether or not the computing node is part of a blockchain network of nodes.

[0095] The computing node identifies the coin creation transaction in operation 602. This identification can occur in a number of possible ways. For example, the specialized network node may provide the computing node with its purported identity and a transaction identifier of the coin creation transaction. The transaction identifier may point to a recently mined coin creation transaction generated by the specialized network node. In some cases, the specialized network node may provide this information to the computing node in conjunction with a request to join, vote, participate, communicate, or otherwise as part of an assertion that the specialized network node has a particular identity and an associated reputation or work history. This assertion may be published in some manner by the specialized network node, and the computing node may access and retrieve information from the publication. Regardless of the context or mechanism, the computing node obtains information that identifies a particular coin creation transaction as part of the purported work history of the particular specialized network node.

[0096] In operation 604, the computing node evaluates whether the coin creation transaction contains an identifier of the dedicated network node in the information field. In many cases, the computing node will obtain a purported identifier of the dedicated network node, and operation 604 may involve confirming whether the same identifier appears in the coin creation transaction. If not, then method 600 fails because the coin creation transaction does not verify any working history of the identity of the purported dedicated network node.

[0097] In operation 606, the computing node also determines whether the coin creation transaction information field contains a reference to an earlier coin creation transaction. For example, the reference can be a TxID number. In some cases, the reference may be a block number or height identifying the block in which the coin creation transaction is to be found, or may be an exit point of an earlier coin creation transaction. If the reference exists and is for an earlier (lower block height) mined coin creation transaction, then in operation 608, the computing node retrieves a copy of the coin creation transaction from the blockchain and returns to operation 604 to confirm that it also contains an identifier for a dedicated network node and points to the earlier coin creation transaction. In this way, the computing device traces back through the linked set of coin creation transactions using the reference in the coin creation transaction information field, which links back to the previous transaction in the order in which the transaction was mined.

[0098] If, in operation 606, one of the coin creation transactions does not contain a reference to an earlier coin creation transaction, the computing node evaluates whether it is a registration coin creation transaction, i.e., the first in the chain. This is verifiable based on an information field, which may contain an indication that the coin creation transaction is a registration coin creation transaction, for example it may contain "Action: Registration" or an equivalent code or indicator. In some cases, alternatively or additionally, the coin creation transaction may be verified based on the identification of all other coin creation transactions in the chain as a registration coin creation transaction. If the coin creation transaction is not a registration coin creation transaction, the chain is broken and the method 600 cannot verify the working history. If so, the working history has been identified and the computing node may proceed to verify the identifier of the dedicated network node in operation 612. As described above, in some embodiments, this may include utilizing a validity check transaction and an associated verification process.

[0099] As an example, the above process allows a third-party computing node to verify that a particular specialized network node has a particular work history. That is, the computing node can easily track the work history of the specialized network node, which provides a verifiable reputation proof for the specialized network node. A specialized network node with a long history of producing valid blocks may be considered more reliable, more important, more trustworthy, more loyal, or more worthy of investment than a specialized network node with little or no work history. Based on this, "proof of work" is not only used to determine which block is valid and which specialized network node receives the current reward for its investment in computing power, but also to support the reputation of building a specialized network node for investing computing power and for committing to building a specific blockchain.

[0100] The mining process involves searching for a block header hash that is less than a target difficulty threshold. This search involves incrementing a nonce value in the block header that is used only once, hashing the block header, evaluating whether a certain number of hash results are below the difficulty threshold, and if not, incrementing the nonce value that is used only once and trying again. The difficulty threshold is set by the protocol and is adjusted periodically based on the blockchain protocol so that a block is produced approximately every 10 minutes. Adjustments are made so that the blockchain network takes into account changes in the overall hash power in the network. As hash power increases, the difficulty changes to ensure that blocks are not produced too quickly and too easily.

[0101] The block header includes a field, the nBits field, which specifies the current difficulty threshold for the block. The difficulty threshold is expressed in base 256 scientific notation. Therefore, if A=a1a2a3a4 is 4 bytes, the target T is defined as:

[0102]

[0103] The value of a1 must be in the range 0 ≤ a1 ≤ 34 to ensure that the target always remains less than 2 256 , and can therefore be represented as a 32-byte string. Given that the SHA256 function behaves like a random oracle (i.e., the output of SHA256 is a random 256-bit string where each bit is equally likely to be 1 or 0, independent of the other bits), the probability that the block header hash is below the target for the trial nNonce value is:

[0104]

[0105] In another aspect of the present application, a reputation score of a specialized network node may be determined based on the specialized network node's verified work history. As described above, the work history may be represented by a chain of linked coin genesis documents that attest to the association between the specialized network node, its specialized network node identifier, and the set of blocks mined by the specialized network node.

[0106] In one example implementation, the reputation score of a dedicated network node is determined based on the count of mined blocks (i.e., the count of linked coinbase documents). This example provides equal weight to any block at any point in the blockchain history, provided that the block forms part of a chain of mined blocks via linked coinbase transactions.

[0107] In another example implementation, the reputation score may be based on a weighted count of mined blocks. That is, each block may have a weight associated with it. In one example implementation, the weight may be based on block height. For example, an implementation may give a greater weight to older blocks. In another case, an implementation may give a greater weight to more recent blocks.

[0108] In another implementation, the weight assigned to a block may be based on block difficulty. That is, blocks with a lower difficulty threshold (i.e., blocks that require more hashing power on average to mine) may be given greater weight in determining the reputation score. In one example of such an implementation, the reputation score may be determined as a function of the target difficulty for each block that contains one of the genesis documents in the chain of linked genesis documents.

[0109] As an example, if a dedicated network node has a reputation score of Rep ID , the target difficulty of block i is T i , and the number of blocks in the work history is B, then the reputation score of a dedicated network node can be calculated as:

[0110]

[0111] In some examples, the reputation score may be based on the entire work history or may be based on a window of up to a maximum number of recent blocks, i.e., a "rolling" reputation score. In some cases, the window may be based on blockchain height, e.g., any block from the work history falls within X blocks of the current blockchain height.

[0112] In some example implementations, the current reputation score may be calculated by a dedicated network node and included in each coin generation transaction information field.

[0113] In some cases, reputation scores can be normalized, such as by dividing them by the maximum reputation score (e.g., the reputation scores generated by all blocks in the blockchain or window). This will ensure that all reputation scores are between 0 and 1.

[0114] Reference now Figure 7 , which illustrates an example method 700 for determining a reputation score for a dedicated network node. The example method 700 can be performed by a dedicated network node, by another blockchain node, or by a computing node external to the blockchain network.

[0115] In operation 702, a chain of coin creation transactions for a particular dedicated network node is traced, such as described above in conjunction with Figure 6As described. By tracking the coin creation transactions, the work history of the specialized network node is identified. In operation 704, a difficulty threshold is determined for each block containing one of the coin creation transactions. Then in operation 706, a reputation score for the specialized network node is determined by applying a function to the set of difficulty thresholds. As described above, this may include summing the difficulty thresholds (or their inverted values). Additional or alternative weightings may be applied by the function. The result is a reputation score for the specialized network node, which is output in operation 708.

[0116] The reputation score is a quantifiable measure of a dedicated network node's contribution to the blockchain and can be used in a variety of scenarios. Advantageously, all data used to determine and verify the identity of a dedicated network node and its associated reputation score is publicly available from the blockchain and verifiable by virtue of the immutable nature of the blockchain supported by proof of work. To prevent malicious behavior, the reputation score of a dedicated network node can only be improved by mining blocks, i.e., by actively contributing to the stability of the blockchain network.

[0117] The reputation score is formed by a dedicated network node including its identifier and a link to the previous block in the genesis file. The contents of the genesis file are under the control of the dedicated network node, which means that the dedicated network node does not need to rely on any third-party verification or certification to build a reputation. In addition, the dedicated network node cannot forge or tamper with the reputation.

[0118] The ability to verifiably determine the reputation score of a specialized network node with the identity of an associated specialized network node can be used in many applications. For example, the right to participate in a particular protocol or activity can be predicted based on specialized network nodes having a minimum threshold reputation score so that only specialized network nodes with a certain pedigree are allowed to participate. Another potential application is voting. In particular when it comes to proposed changes to the underlying blockchain protocol, specialized network nodes can be responsible for submitting votes, and that vote can be weighted in some way. One option is to weight the votes based on the reputation score, thereby giving specialized network nodes with higher reputation scores greater weight based on the fact that they have done more work to build the existing blockchain.

[0119] One example voting scheme used in a blockchain involves opening a time window during which a specialized network node can vote, and then tallying the votes based on the blocks mined during the time window. This will provide the most votes to the specialized network node with the most hashing power during the time window, and regardless of contribution history. This can lead to "hash wars" and make the system vulnerable to "hashing for rent," where a specialized network node that intends to skew the outcome of a vote temporarily commits large amounts of computing power to the blockchain in order to dominate the blockchain's hashing power during the window, but does not have the resources or interest to commit these large amounts of computing power to the blockchain in the long term. In some cases, "hashing for rent" is unsustainable because it is a non-economic allocation of resources, but a cost incurred by the specialized network node to force the outcome of the vote. As a result, the influence on the vote gained by the specialized network node is disproportionate to the specialized network node's actual involvement and investment in the blockchain.

[0120] In one example, the voting process of a dedicated network node may allow the dedicated network node to participate, provided that the dedicated network node has a registered dedicated network node identifier (e.g., PK ID ) and the associated reputation score Rep ID Voting occurs during an agreed-upon time window, from a start time to an end time (or, from a start block height to an end block height). The mechanism for reaching consensus on the window and timing of any vote may be on-chain or off-chain.

[0121] In order to vote, a dedicated network node must mine a voting block during the voting window. In the voting block, the dedicated network node inserts its identifier and a reference to its most recent coin creation transaction in the coin creation transaction. In some implementations, it may also include its calculated reputation score. The dedicated network node also includes a voting signal. Depending on the vote, the signal may be a binary "yes" / "no" or "for" / "against" signal, or it may be a multi-valued signal, such as a choice between three or more options, a ranking between three or more options, etc. In some examples, the coin creation transaction may also include a digital signature based on a private key corresponding to the identifier of the dedicated network node. The digital signature may be at a higher level than the other contents of the information field in the coin creation transaction.

[0122] In some implementations, a single dedicated network node may be entitled to vote multiple times during a voting window. In some other implementations, each dedicated network node (i.e., the identifier PK of each associated dedicated network node) may be assigned a unique identifier. ID) is only allowed to vote once. In the latter case, if a dedicated network node mines more than one block claiming to vote, a strategy can be applied to determine which one to count. For example, the strategy might be to take the earliest (lowest block height) vote. Alternatively, the strategy might be to take the last (highest block height) vote to allow dedicated network nodes to change their vote during the window.

[0123] Any vote monitor can verify that the vote is valid by verifying the dedicated network node's identifier (described above) and verifying the reputation score associated with the dedicated network node's identifier (described above). If a signature is required as part of the voting token transaction, it prevents another dedicated network node from maliciously mining a block and claiming to have obtained the vote by using their PK ID After the voting window closes, any observing party can determine the result by summing the votes weighted by the reputation score of each option, as all information is recorded on the blockchain and can be verified.

[0124] By calculating votes using historical block data instead of current and future block data, voting can be done in a relatively short period of time while ensuring that voting weight is calculated using enough proof-of-work data to accurately reflect chain work. This allows for relatively short voting periods without the risk of voting weight being distorted by temporary hash bursts.

[0125] However, since voting requires each PK ID To mine a new block, sufficient time must be given to allow dedicated network nodes to vote. Assuming the block time is 10 minutes, if you have PK ID If a dedicated network node has x% of the network hash rate, then the probability of mining at least one block in t hours is:

[0126]

[0127] Table 1 below gives the P for various x and t

[0128] x t＝ t＝ t＝ t＝ 0.5％ 1％ 5％ ≈ ≈ 25％ ≈ ≈ ≈

[0129] It can be understood from the above table that even if PK ID With only 1% of the network hashrate, a 72-hour voting period almost guarantees that they will be able to mine the voting block.

[0130] In at least one example modeling of a possible hash war scenario, the above reputation system can provably reduce the effectiveness of rented hashes such that even if an attacker dominates 75% of the network within 14 days, the attacker will only manage to accumulate 23% of the voting power.

[0131] It should be understood that some or all of the above-described operations of the various above-described example methods may be performed in an order different than that shown and / or may be performed simultaneously without changing the overall operation of those methods.

[0132] Reference now Figure 8 , which shows a simplified computing device 800 according to an example of the present application in block diagram form. The computing device 800 may perform one or more of the above functions. For example, the computing device 800 may be a dedicated network node. In some implementations, the computing device 800 may not be a dedicated network node, which operates to verify data recorded by the blockchain, such as, for example, an identifier of a dedicated network node, a work history of a dedicated network node, a reputation score of a dedicated network node, or a voting block of a dedicated network node.

[0133] The computing device 800 includes a processor 802, which may include one or more microprocessors, application specific integrated circuits (ASICs), microcontrollers, or similar computer processing devices. The computing device 800 may also include a memory 804 and a network interface 806, and the memory 804 may include persistent and non-persistent memory to store values, variables, and in some cases processor executable program instructions.

[0134] Computing device 800 may include processor-executable applications 808 containing processor-executable instructions that, when executed, cause processor 802 to perform one or more functions or operations described herein.

[0135] The various embodiments presented above are merely examples and are by no means meant to limit the scope of the present application. The changes in the innovations described herein will be apparent to those of ordinary skill in the art, and such changes are within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments, which include sub-combinations of features that may not be explicitly described above. In addition, features may be selected from one or more of the above-described example embodiments and combined to create alternative example embodiments, which include combinations of features that may not be explicitly described above. Those skilled in the art will readily appreciate the features that are suitable for such combinations and sub-combinations when reviewing the present application as a whole. The subject matter described herein and in the claims cited is intended to encompass and include all suitable technical changes.

Claims

1. A computer-implemented method for recording a work history of a dedicated network node on a blockchain in a blockchain network, comprising: mining, by the dedicated network node, a first block including a registration genesis transaction having an output including an identifier of the dedicated network node within a registration information field; as well as Two or more additional blocks are mined in sequence by the dedicated network node, each additional block containing a corresponding genesis transaction, each said genesis transaction comprising an output, the output having an information field, the information field containing an identifier of the dedicated network node, a reference to a genesis transaction of a preceding additional block in the sequence, wherein the registered genesis transaction is the first block in the sequence.

2. The method according to claim 1, wherein: The identifier of the dedicated network node is a public key, and the dedicated network node holds a private key for the public key.

3. The method according to claim 1 or claim 2, wherein: The genesis transaction in each append block includes a registration reference pointing to the registration genesis transaction and a digital signature.

4. The method according to any one of claims 1 to 3, wherein: The reference to a genesis transaction of a preceding additional block in the sequence comprises one of a transaction identifier, a block number, or an exit point.

5. The method according to any one of claims 1 to 4, further comprising: The work history recorded on the blockchain is verified by a computing node, wherein the verification includes: identifying the last block in the sequence; retrieving genesis transactions from the additional blocks from the blockchain in reverse order based on a reference contained in each genesis transaction to a genesis transaction of a preceding additional block; retrieving the registration origination transaction; and verifying registration of the identifier of the dedicated network node in the registration genesis transaction, Thus, the registration genesis transaction and the genesis transaction provide a working history of the dedicated network node.

6. The method according to any one of claims 1 to 5, further comprising: A reputation score for the specialized network node is determined based on a recorded working history of the specialized network node, wherein the determining includes calculating the reputation score based on a count of a number of blocks in the sequence.

7. The method according to any one of claims 1 to 5, further comprising: Determining a reputation score for the specialized network node based on a recorded operating history of the specialized network node, wherein the determining comprises calculating the reputation score based on: assigning a corresponding weight to each block in the sequence; and The sum of the corresponding weights is calculated.

8. The method according to claim 7, wherein: Assigning the corresponding weight to each block includes: for each block, determining a difficulty score for the block based on a difficulty threshold applied when mining the block, and setting the corresponding weight based on the difficulty score.

9. The method according to claim 7 or claim 8, wherein: The reputation score is calculated as: Among them, Rep. ID is the reputation score, i is the index of the referenced i-th block, B is the number of blocks in the sequence, and T i is the target difficulty to apply when mining block i.

10. The method according to any one of claims 6 to 9, further comprising: Weighted votes are recorded in a secure blockchain-based voting system by mining voting blocks by the dedicated network nodes, wherein the voting blocks contain a genesis transaction, the genesis transaction containing an identifier of the dedicated network node of the voting block, a reference to the most recent genesis transaction of the voting block, and a voting signal.

11. The method according to claim 10, wherein: The voting block genesis transaction also includes a reputation score calculated for the dedicated network node.

12. A computer-implemented method for verifying a work history of a specialized network node on a blockchain in a blockchain network, comprising: identifying a block mined by the dedicated network node and having a genesis transaction, the genesis transaction having an output including, in an information field, an identifier of the dedicated network node and a reference to an earlier genesis transaction; retrieving from the blockchain in reverse order a plurality of earlier genesis transactions until an earliest genesis transaction that includes a registration for an identifier of the specialized network node, each earlier genesis transaction including in an output to each respective genesis transaction the identifier of the specialized network node and a reference to a respective preceding one of the earlier genesis transactions in reverse order; as well as verifying the registration of the identifier of said dedicated network node in said earliest genesis transaction, Thus, the genesis transaction and the plurality of earlier genesis transactions provide a working history of the dedicated network node.

13. A computer-implemented method for determining a reputation score of a dedicated network node in a blockchain-based blockchain network, comprising: tracking a chain of linked genesis transactions, wherein the genesis transactions each include an identifier of the dedicated network node in an output containing an information field, and each of the genesis transactions except the first genesis transaction includes in the information field a reference to an earlier genesis transaction in the linked genesis transactions in the chain, wherein each genesis transaction is in a respective block mined by the dedicated network node; For each genesis transaction, determine the difficulty score of its corresponding block; and A reputation score for the dedicated network node is determined based on a difficulty score of a corresponding block associated with a genesis transaction in the chain.

14. A computing device for managing a public key infrastructure using a blockchain network, the computing device comprising: one or more processors; Memory; as well as Computer executable instructions stored in the memory, when executed by the one or more processors, cause the processor to perform the method according to any one of claims 1 to 13.

15. A computer-readable medium storing processor-executable instructions for managing a public key infrastructure using a blockchain network, the processor-executable instructions comprising instructions that, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 13.

Images