Method and device for recording work history and proving reputation in block chain network

Abstract

A method and system for recording a work history of a specialized network node on a blockchain in a blockchain network. The method may include mining a first block that includes a registration initiation transaction that includes an identifier of a specialized network node within a registration information field; and mining two or more additional blocks in an order, each additional block containing an originating transaction, the originating transaction comprising an information field containing an identifier of a specialized network node, a reference to the originating transaction to a preceding additional block in the order, where the registered originating transaction is a first block in the order. The work history may be validated by tracking the recorded work history and validating the identifier of the specialized network node. The recorded work history may be used as a basis for a reputation score for a specialized network node that reflects contributive work proved by the work history guaranteed by the proof of work.

Description

[0001] This application is a divisional application of the PCT national stage application with the application date of May 5, 2020 and the national application number of 202080042882.1. Technical Field

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

[0003] Specialized network nodes are key elements of blockchain networks. In "proof-of-work" blockchain networks, specialized network nodes compete to complete a proof of work to "win" the race to mine a block, thereby collecting transaction fees and any newly created tokens reflected in the coinbase transaction within the new block. In this way, specialized network nodes protect the network, thus 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 specialized network node without prior approval from any other node. As the use and transaction volume of blockchains grow, it may also become increasingly important to correctly register and verify the identity of specialized network nodes (or pools of specialized network nodes).

[0004] For example, when it comes to changing the blockchain protocol, arbitrary or "top-down" code changes can undermine confidence in system stability and determinacy and may expose the blockchain network to attacks or potential fraud or theft. As a consensus-based system, any change to the underlying code of a blockchain network requires agreement among 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 verify transactions, assemble candidate blocks, and perform the computationally expensive work of mining new blocks. It may be advantageous to be able to track and verify the identity of specialized network nodes (or pools of specialized network nodes).

[0005] One mechanism for registering and verifying identities in a computer network is through the use of public key cryptography 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 registration of its public key from 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 signed by the certificate authority. Different nodes that wish to verify the identity of a node rely on their trust in the certificate authority to underpin the authentication of the node identity represented by the digital certificate.

[0006] Blockchain systems are typically permissionless, meaning that any node can join or leave the network, and other nodes have no control over whether a node joins the network. This flexibility is important for ensuring the efficient allocation of resources and allowing the addition of computing resources as needed and economically. However, in certain situations and scenarios, for the purposes of trust, reliability, and stability, it would be advantageous to be able to verify that a node (e.g., a specialized network node) is a "reputable" node in the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Exemplary embodiments of the present application will now be described by way of example with reference to the accompanying drawings, in which:

[0008] Figure 1 A simplified example method of registering the identity of a specialized network node on a blockchain is shown in the form of a flowchart;

[0009] Figure 2 An example method of setting up a quick revocation option for registering the identity of a specialized network node is shown in the form of a flowchart;

[0010] Figure 3 An example method of recording the identity of a specialized network node on a blockchain is shown in the form of a flowchart;

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

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

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

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

[0015] Figure 8 A simplified example of a computing node (e.g., a specialized network node) is shown in the form of a block diagram.

[0016] The same reference numerals are used in the drawings to denote the same elements and features.

[0017] DETAILED DESCRIPTION OF THE INVENTION

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

[0019] In some implementations, the identifier of the dedicated network node can be a public key, and the dedicated network node holds a private key for the public key.

[0020] In some implementations, the generation transaction in each additional block can include a registration reference to the generation transaction and a digital signature.

[0021] In some implementations, the reference to the generation transaction of the previous additional block in the sequence can include one of a transaction identifier, a block number, or an outpoint.

[0022] In some implementations, the method can further include: validating, by a computing node, the work history recorded on the blockchain. In some cases, validating can include: identifying the last block in the sequence; retrieving, from the blockchain in reverse order, the generation transactions from the additional blocks based on the references to the generation transactions of the previous additional blocks included in each generation transaction; retrieving the generation transaction; and verifying the registration of the identifier of the dedicated network node in the generation transaction. The generation transaction and the generation transactions provide the work history of the dedicated network node.

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

[0024]

[0025] In the above expression, Rep ID is the reputation score, i is the index of the i-th block being referenced, B is the number of blocks in the sequence, and T i is the target difficulty applied when mining block i.

[0026] In some implementations, the method may further include: recording weighted votes in a secure blockchain-based voting system by mining a voting block by a dedicated network node, where the voting block contains a genesis transaction that includes 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. In some cases, the voting block genesis transaction further includes a reputation score calculated for the dedicated network node.

[0027] In another aspect, the present application may describe a computer-implemented method for verifying the work history of a dedicated network node on a blockchain in a blockchain network. The method may include: identifying blocks mined by the dedicated network node and having a genesis transaction that includes an identifier of the dedicated 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 the last genesis transaction including a registration of the identifier of the dedicated network node is included, each earlier genesis transaction including an identifier of the dedicated network node and a reference to the corresponding preceding one of the earlier genesis transactions in reverse order; and verifying the registration of the identifier of the dedicated network node in the last genesis transaction. The genesis transaction and the plurality of earlier genesis transactions provide the work history of the dedicated network node.

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

[0029] In another aspect, a computing device for 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.

[0030] In another aspect, a computer-readable medium can be provided that stores processor-executable instructions for operating nodes in a network, the processor-executable instructions including instructions that, when executed by one or more processors, cause the processor to perform at least one method described herein.

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

[0032] In this application, the term "and / or" is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the separately listed elements, any sub-combination, or all of the elements, and does not necessarily exclude additional elements.

[0033] In this 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 separately listed elements, any sub-combination, or all of the elements, without necessarily excluding any additional elements and without necessarily requiring all of the elements.

[0034] This application will relate to hash processing or hash functions, which are intended to include any one of a plurality of cryptographic hash functions that, when applied to any set of data or "messages", deterministically produce a unique fixed-length alphanumeric string. The result of a hash function can be referred to as a hash value, fingerprint, hash result, or the like. Examples include, but are not limited to, SHA-2, SHA-3, and BLAKE2.

[0035] 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 variants. It should be noted that alternative blockchain implementations and protocols fall within the scope of the present invention.

[0036] A blockchain is a peer-to-peer electronic ledger that is implemented using a computer-based decentralized distributed system. The blockchain is composed of blocks, and the blocks are in turn composed 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 content, for example in the form of a Merkle root, and each block header contains the hash of the previous block header so that the blocks are linked together to create a permanent, immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts that are embedded in their inputs and outputs and that specify how and by whom the output of the transaction can be accessed.

[0037] A 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. The nodes verify transactions and propagate them to other nodes in the network. Specialized network nodes collect a set of unconfirmed transactions (i.e., pending transactions) into a block and attempt to "mine" the block. In these examples, mining refers to solving a proof-of-work (POW) for a corresponding block before any other specialized network node in the network successfully solves it. A nonce that is used only once is incremented repeatedly and the hashing process is repeated until the result is less than a threshold or until the specialized network node receives notice that another specialized network node has been successful. Variations of the mining process are familiar to those of ordinary skill in the art.

[0038] Among the various things checked when validating a transaction, the node determines whether the inputs of the transaction are valid. In particular, the node evaluates whether the unlocking script evaluates to true and determines whether the input references an "unspent transaction output" (UTXO) from an earlier transaction. Some nodes may maintain a running list or set of UTXOs in order to be able to quickly determine whether the referenced transaction output is in the UTXO set. A transaction can be identified by its unique transaction identifier TxID, which in some implementations is the hash of the transaction. Some transactions may have more than one output, so a unique transaction "outpoint" can be identified by the TxID and an index, where the index points to one of the outputs in the ordered set of outputs from the transaction. If a transaction output (e.g., an outpoint) exists in the UTXO set, then the output of the transaction is "unspent" and can be used as an input.

[0039] The unlocking script for a transaction outpoint defines how to prove "control" of the output in order to spend it. In many cases, the address associated with the transaction output is the hash of a public key. To prove control of the output, the unlocking script typically requires the public key and a digital signature generated using the corresponding private key. In this way, the node controlling 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, the entity associated with that particular public key effectively signs or authenticates the transaction content.

[0040] Public key cryptography has become ubiquitous in online communication. In many cases, processes 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 genuine and has not been compromised is public key infrastructure (PKI). PKI relies on trusted third parties to "authenticate" whether a public key is valid. These entities are "certificate authorities" (CAs). The CA provides the registration and issuance of digital certificates that confirm the binding between a public key and a specific party. The holder of the public key provides its public key and its digital certificate to another entity. Then, the other entity can verify the authenticity of the public key by confirming that the trusted CA has digitally signed the certificate.

[0041] As described above, specialized network nodes are key to securing a blockchain network. When specialized network nodes win the race to find a valid new block, their work is compensated. The compensation comes from transaction fees from individual transactions and "coinbase" transactions included in the new block. A coinbase transaction has no inputs, and it outputs a specified amount of tokens (e.g., currency) to the specialized network node, effectively creating new tokens. A coinbase transaction can also be referred to as a "genesis transaction", so these terms can be used interchangeably in this document. A coinbase transaction or genesis transaction has certain characteristics that distinguish it from a regular transaction. For example, each valid block contains only one genesis transaction. Each genesis transaction has no inputs and outputs a number of tokens set by the prevailing block reward setting due to the successful specialized network node according to the governing blockchain protocol. A genesis transaction is a "proof-of-work transaction" because it can only be created by a specialized network node that has successfully mined a block (i.e., completed the proof of work).

[0042] In many blockchain systems, a single entity can 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 can be pooled together, and the pool harnesses the computing power of a large number of individual processors. In many of the examples below, reference may be made to "specialized network nodes", or public-private key pairs held or controlled by specialized network nodes. From the context, it can be understood that these references can include the individual computers that implement the specialized network nodes and / or the collection or pool of computers / processors that implement the pool owned or controlled by an entity.

[0043] 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 the public keys claimed by specialized network nodes. It would be particularly advantageous to be able to perform this verification without relying on trust in a third-party certificate authority.

[0044] Establishing the Verifiable Identity of Specialized Network Nodes

[0045] According to one aspect of the present application, a dedicated network node can establish its identity by mining a block that includes a statement of the identity of the dedicated network node within the coinbase 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 its identity in the coinbase transaction as an identity statement supported by a proof of work. The identity of the dedicated network node in the following example is a public key. No third-party CA is required to verify the association between the dedicated network node and its stated public key, as this association is supported by the blockchain network and the proof of work.

[0046] To facilitate the possible revocation of the identity of the dedicated network node, for example, if the corresponding private key is compromised, the dedicated network node can first create a validity check transaction in which it states its identity and there is an output controlled by the dedicated network node for this transaction. The coinbase transaction can include a reference to this validity check transaction. Part of the authentication operation performed by another node can be used to confirm that the validity check transaction has not been "revoked" by transferring the output controlled by the dedicated network node. That is, the dedicated network node can invalidate its own identity as a dedicated network node by "spending" the output of the validity check transaction, thereby removing the validity check transaction from the unspent transaction (UXTO) set. This provides a fast revocation mechanism that does not rely on mining a new block to revoke the identity of the dedicated network node.

[0047] Reference will now be made 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 arbitrary inputs and two outputs. One output is an output controlled by the dedicated network node that assigns arbitrary tokens to an address controlled by the dedicated network node. The second output of the VCT includes an information field that contains the identity of the dedicated network node, which, in this example, is a public key PK selected by the dedicated network node ID . The dedicated network node holds the corresponding private key sk ID . The information field can be an OP_RETURN field. In this example, the identity of the dedicated network node (e.g., the dedicated network node ID) is the public key PK ID .

[0048] The VCT is propagated on the blockchain network, where it is eventually confirmed by being included in a mined block, such that the VCT is then on the chain.

[0049] Registration operation 104 involves a dedicated network node successfully mining a new block. Mining a block involves assembling a candidate block that contains a plurality of transactions selected from a memory pool of unconfirmed transactions. The dedicated network node also inserts a coinbase transaction into its candidate block. Then it attempts to mine the block by repeatedly incrementing a nonce in the block header and hashing the block header in an attempt to find a hash value less than the difficulty setting. If another dedicated network node succeeds, the dedicated network node verifies whether the new block of the other dedicated network node is valid, then creates a new candidate block and tries again.

[0050] In operation 104, the dedicated network node successfully mines a new block, and the new block contains a coinbase transaction that 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 .

[0051] Once the dedicated network node has successfully mined a block that contains a coinbase transaction that declares 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 if necessary. In addition, the identity and its association with the dedicated network node are supported by proof of work and protected by the network, thus allowing third parties to rely on the identity of the dedicated network node (e.g., its public key PK ID ) without relying on a certificate authority. The identity of the dedicated network node can then be used for various purposes, including tracking the activities of the dedicated network node, proving the authenticity or status of the dedicated network node, establishing or participating in secure encrypted communication with the dedicated network node, and ranking the dedicated network node for various purposes, etc.

[0052] Reference will now also be made to Figure 2 , which shows an example setup method 200 that can be used in method 100 for establishing the identity of a dedicated network node. The method is performed by the dedicated network node in this example.

[0053] In operations 202 and 204, the dedicated network node selects a private key sk ID and finds the corresponding public key PK ID . The public key PK ID is the identifier of the dedicated network node.

[0054] Then, in operation 206, a specialized network node creates a validity check transaction with an arbitrary input and two outputs. The input can be any UTXO for which the specialized network node holds the corresponding private key. That is, any UTXO controlled by the specialized network node. 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 token amount can be established through a policy.

[0055] One of the outputs is an output to any address controlled by the specialized network node. That is, the output is to an address for which the specialized network node holds the corresponding private key so that the specialized network node can unlock the associated locking script. In some examples, the output address can be labeled PK VCT , which is any public key selected by the specialized network node and for which it holds the corresponding private key. For example, the output can be a P2PKH (pay-to-public-key-hash) operation that specifies a transfer to a public key hash selected and controlled by the specialized network node.

[0056] The other output includes a non-operation information field in which information can be inserted. In particular, this field contains the identifier PK of the specialized network node ID . The output can use the OP_RETURN opcode to provide the information field.

[0057] There may be blockchain protocols in which a non-operation information field can be included in a transaction for the purpose of publishing information within the transaction, and this information is not necessarily implemented as an "output" of the transaction as the term can be understood. However, it should be understood that the term "output" in these examples is intended to include information fields that substitute for such possible implementations on the blockchain protocol.

[0058] Once the VCT has been created in operation 206, in operation 208, the specialized network node propagates the VCT on the blockchain network. One of ordinary skill in the art will understand that the propagation of the VCT may involve each node of the network validating the transaction and then sending it to all other nodes to which the node is connected, such that the transaction quickly propagates through the entire blockchain network. As an unconfirmed transaction, it will be inserted into the memory pool, and individual specialized network nodes will select transactions from this memory pool to include in candidate blocks. Thus, it will ultimately be "confirmed" by being included in a mined block. In operation 210, the specialized network node evaluates whether the VCT has been confirmed by being included in a mined block. Once it has been confirmed, then in operation 212, the specialized network node records the transaction identifier TxID VCTIt should be understood that in some implementations, a dedicated network node may record a transaction identifier before the VCT is mined.

[0059] For the VCT part of the blockchain, its first output to PK VCT forms part of the set of UXTOs of "unspent" outputs until a dedicated network node chooses to move / transfer the tokens associated with that output. This UXTO serves as a validity check mechanism. As long as it remains part of the UXTO set, the identifier of the dedicated network node in the VCT remains valid and unrevoked. Once it is no longer in the UXTO set, the identifier of the dedicated network node in the VCT is no longer valid.

[0060] Reference will now also be made Figure 3 to, which shows an example registration method 300 that can be used in method 100 for establishing the identity of a dedicated network node. This method is performed by the dedicated network node in this example. Method 300 assumes that a setup operation for creating a validity check transaction associated with the identifier PK ID of the dedicated network node has occurred.

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

[0062] In addition to the identifier of the dedicated network node and the 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 accomplished via the coinbase transaction. In this example, the action can be "registration" to indicate that the dedicated network node is publicly registering its identifier. It may also or alternatively include a signature. As an example, the signature can be a signature of the remainder of the information field, e.g., signature: Sig(sk ID , action || dedicated network node ID || VCT), where VCT is TxID VCT , the dedicated network node ID is PK ID .

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

[0064] If the dedicated network node successfully mines the candidate block, it records the transaction identifier TxID of the coinbase transaction REG . Note that it could alternatively note down the block number, as it will contain only one coinbase transaction that other nodes may be able to identify based on the block number.

[0065] After successfully mining a block with the registered coinbase transaction, the dedicated network node has successfully registered its identity and has published it on the blockchain. Another node that receives the identifier of the dedicated network node (e.g., the public key PK ID ) can verify whether the public key is valid and is associated with the dedicated network node without relying on trust in an independent certificate authority.

[0066] Figure 4 An example method 400 by which a node can perform to verify the identifier of a dedicated network node according to one aspect of the present application is shown in the form of a flowchart. The node is any node inside or outside the blockchain network for verifying the identifier PK of the dedicated network node ID . For example, the verification can occur as part of verifying or approving a request from the dedicated network node, establishing a communication session with the dedicated network node, or otherwise proving the validity of the public key PK ID and its association with the dedicated network node.

[0067] In operation 402, the node receives or retrieves the dedicated network node ID (PK ID ) and the registered transaction identifier (TxID REG , or in some cases, the block number in which the registered coinbase 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 signature σ m can be provided by the dedicated network node. In some cases, the message and its signature may be part of a digital certificate provided or published by the dedicated network node as proof of its identity.

[0068] In operation 404, the node is based on the registered transaction identifier TxID REGRetrieve the coinbase registration transaction from the blockchain. Then in operation 406, it verifies or confirms certain data in the coinbase registration transaction. For example, the node can parse the OP_RETURN field to extract the information in this field from the coinbase 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 a dedicated network node ID , and the "action" is "registration".

[0069] Based on the VCT transaction identifier published in the coinbase registration transaction, in operation 408, the node can retrieve the VCT. The node can confirm that the OP_RETURN field in the VCT has the same public key PK ID , as shown in operation 410. Then it can evaluate whether another output of the VCT remains "unspent", i.e., whether it is still part of the UXTO set of available output points. This may involve querying the UXTO set database directly or through an intermediate node. The query can be based on the outpoint identifier, which can include the transaction identifier TxID VCT and an index indicating which output. If the output does not appear in the UXTO set, the identifier of the dedicated network node is invalid because it has been revoked or replaced. Therefore, the verification fails.

[0070] However, if the outpoint is in the UXTO set, the node can consider PK ID as the verified public key of the dedicated network node, and then in operation 414, it can use PK ID to verify the signature of the dedicated network node to confirm the dedicated network node signature. Note that this operation 414 can include the node confirming the signature within the coinbase transaction OP_RETURN field (if any), or the node confirming the signature σ on the message m m , or the node confirming both. Obviously, if the signature check fails, then the claimed dedicated network node cannot be verified as the holder of the corresponding private key, so the verification fails. If the signature check succeeds, the dedicated network node is verified as the dedicated network node associated with the identifier (i.e., the verified registered public key PK ID ).

[0071] As described above, the registration of a dedicated network node ID can be revoked by removing the first output of the VCT from the UXTO set. This is done by "spending" the output, using it as an input to any other transaction. This may include transferring any tokens assigned to the first output to a new address in the revocation transaction. The creation and propagation of the revocation transaction is sufficient to cause any verification of the dedicated network node ID to fail, as the verification node will not be able to locate the output in the UXTO set. However, the dedicated network node can also register a revocation by including an OP_RETURN field in the coinbase transaction of its next mined block. In one example, the OP_RETURN can include the action "revoke" and the dedicated network node ID. In some implementations, it can also include the transaction identifiers and signatures of both the registration transaction and the revocation transaction.

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

[0073] To update the old dedicated network node ID PK ID-OLD , the dedicated network node first creates a new VCT for the new public key PK ID-NEW . From this process, it obtains the new VCT transaction identifier TxID VCT-NEW . The dedicated network node then mines a new block with the new coinbase transaction to register the new dedicated network node ID; however, to link the new dedicated network node ID to the old ID and any work history of the old ID, the dedicated network node can use the action "update" or "update ID" to signal that the coinbase transaction is not just the first registration of the dedicated network node ID, but rather a replacement of the previous dedicated network node ID. The content of the OP_RETURN field in the updated coinbase transaction may include:

[0074] 1. Action: Update ID

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

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

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

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

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

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

[0081] 7. New Signature: Sig(sk ID-NEW , action || new dedicated network node ID || new VCT)

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

[0083] It should also be understood that the dedicated network node can invalidate an earlier dedicated network node ID by using the output from the old VCT as an input to some other transaction. In one example, the output can be an input to the new VCT. In another example, the dedicated network node may wait until it has successfully mined a block to register the updated dedicated network node ID, and then propagate a separate revocation transaction to invalidate its old dedicated network node ID.

[0084] Using the system described above, a dedicated network node is able to establish and register its provable identifier on the blockchain. By including the identifier in the coinbase transaction of the mined block, the dedicated network node proves that it is a legitimate dedicated network node and the validity of the identifier and associated materials is supported by the proof of work. If needed, the VCT provides a fast revocation mechanism. In some example implementations, the VCT can supplement the proof of work with proof of stake by requiring that at least a predetermined token or currency value be allocated to the output. Advantageously, the system described above avoids the need to trust a certificate authority and does not involve additional work on the part of the dedicated network node and involves very little additional data in the block.

[0085] The above registration system and method enable a specialized network node to prove its identity and provide a digital certificate to a specialized network node that can be verified by another node without relying on a certificate authority. Additionally, as described below, the identifier of a specialized network node can be used to provably link together the coinbase transactions of blocks mined by that specialized network node. This provides a verifiable work history associated with the ID of the specialized network node. The 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 a certain purpose, etc. In the following description, this work history may be referred to as a "proof of reputation" system.

[0086] Proof of Reputation

[0087] 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 examples below, the work history is recorded by a chain of coinbase transactions linked in blocks mined by the specialized network node. In some implementations, the work history can be used to determine a reputation score for the specialized network node. The reputation score can be used in many applications, including, by way of example, voting operations for specialized network nodes.

[0088] In some implementations described below, each coinbase document includes the identifier of the specialized network node in an information field. In some implementations, the above methods and systems can be used to establish and verify the identifier of the specialized network node. However, in some implementations, other techniques or systems can be used to establish the identifier of the specialized network node and for verification purposes. Therefore, it should be understood that the work history and proof of reputation examples described below do not necessarily require the specialized network node identifier registration process described above in all implementations.

[0089] As described above, one mechanism for registering the identifier of a specialized network node is to place the identifier of the specialized network node into the coinbase 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., the OP_RETURN field) of the coinbase transaction. The information field can also include a signature or other data. As described above, in some implementations, the information field can include a reference to a validity check transaction, which enables the quick revocation of the identifier of the specialized network node and enables other parties to easily verify that the identifier of the specialized network node has not been revoked.

[0090] The coinbase transaction can also be utilized in combination with the registered identifier of the specialized network node to record the work history of the specialized network node. Figure 5An example method 500 for recording the work history of a dedicated network node on a blockchain is shown in the form of a flowchart. Method 500 is executed by a dedicated network node associated with the identifier of the dedicated network node. The identifier of the dedicated network node can be a public key, and the dedicated network node holds the corresponding private key for that public key, i.e., the identifier of the dedicated network node can be PK ID .

[0091] Method 500 includes registering the identifier of the dedicated network node in operation 502. As described above, the registration operation includes publishing the identifier of the dedicated network node in the coinbase transaction registered within the block mined by the dedicated network node.

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

[0093] In some implementations, the information field contains additional information. For example, in addition to the reference to the coinbase transaction of the most recently mined block from the dedicated network node, the information field can also contain references to the registration coinbase transactions in each subsequent block mined by the dedicated network node. As another example, the information field can include a digital signature generated based on the identifier of the dedicated network node (i.e., using the private key associated with the identifier of the dedicated network node). For example, the digital signature can be one of the (one or more) references included in the information field.

[0094] Once a candidate block with a coinbase transaction has been created in operation 504, in operation 506 a dedicated network node attempts to mine the block. In operation 508, it also monitors for receipt of a notification of a new block from another dedicated network node. If another node successfully finds a new block, then in operation 510, the dedicated network node verifies that the new block is valid according to the applicable blockchain protocol and then adds the new block to the blockchain. If the dedicated network node successfully mines the candidate block before receiving a 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 is from the dedicated network node or another node, once a new block is found, the dedicated network node returns to operation 504 to construct a new candidate block and tries again.

[0095] It will be understood that assuming the dedicated network node occasionally successfully mines a new block, the above loop results in a linked chain of coinbase transactions that links the blocks mined by the dedicated network node from the most recent block back to the original registered coinbase transaction. Since the OP_RETURN data is visible on the blockchain, the linked set of coinbase transactions can easily be identified as a published record of the work history of the dedicated network node, with each coinbase transaction containing an identifier of the dedicated network node.

[0096] Now refer to Figure 6 , which shows an example method 600 for 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 the blockchain network of nodes.

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

[0098] In operation 604, the computing node evaluates whether the coinbase transaction contains the identifier of a dedicated network node in the information field. In many cases, the computing node will obtain the claimed identifier of the dedicated network node, and operation 604 may involve verifying whether the same identifier appears in the coinbase transaction. If not, method 600 fails because the coinbase transaction does not verify any work history of the claimed dedicated network node's identity.

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

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

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

[0102] The mining process involves searching for a block header hash that is less than the target difficulty threshold. This search involves incrementing a nonce value that is only used once in the block header, 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 only used 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 generated approximately every 10 minutes. The adjustment is made so that the blockchain network takes into account changes in the overall hash power in the network. As the hash power increases, the difficulty changes to ensure that blocks are not generated too quickly and too easily.

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

[0104]

[0105] The value of a1 must be in the range 0 ≤ a1 ≤ 34 to ensure that the target always remains less than 2 256 , and thus can 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 and is independent of the other bits), the probability that the block header hash for a trial nNonce value is below the target is:

[0106]

[0107] In another aspect of the present application, the reputation score of a dedicated network node can be determined based on the verified work history of the dedicated network node. As described above, the work history can be represented by a linked chain of coinbase documents that prove the association between the dedicated network node, its identifier, and the set of blocks mined by the dedicated network node.

[0108] In one example implementation, the reputation score of a specialized network node is determined based on the count of mined blocks (i.e., the count of linked coinbase documents). This example gives 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.

[0109] In another example implementation, the reputation score can 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 can be based on the block height. For example, one implementation may give greater weight to older blocks. In another case, one implementation may give greater weight to more recent blocks.

[0110] In another implementation, the weight assigned to a block can be based on the block difficulty. That is, blocks with a lower difficulty threshold (i.e., blocks that on average require greater hashing power to mine) can be given greater weight when determining the reputation score. In one example of this implementation, the reputation score can be determined as a function of the target difficulty of each block that contains one of the coinbase documents in the linked coinbase document chain.

[0111] As an example, if the reputation score of a specialized network node is 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 the specialized network node can be calculated as:

[0112]

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

[0114] In some example implementations, the current reputation score can be calculated by the specialized network node and included in each coinbase transaction information field.

[0115] In some cases, the reputation score can be normalized, e.g., by dividing it by the maximum reputation score (e.g., the reputation score produced by all blocks in the blockchain or window). This ensures that all reputation scores are between 0 and 1.

[0116] Now refer to Figure 7, which shows an example method 700 for determining the reputation score of a dedicated network node. This example method 700 can be executed by a dedicated network node, by another blockchain node, or by a computing node outside the blockchain network.

[0117] In operation 702, trace the chain of coinbase transactions for a specific dedicated network node, such as as described above in connection with Figure 6 . By tracing the coinbase transactions, the work history of the dedicated network node is identified. In operation 704, determine the difficulty threshold for each block that contains one of the coinbase transactions. Then in operation 706, determine the reputation score of the dedicated network node by applying a function to the set of difficulty thresholds. As described above, this can include summing the difficulty thresholds (or their inverted values). Additional or alternative weighting can be applied through the function. The result is the reputation score of the dedicated network node, which is output in operation 708.

[0118] The reputation score is a quantifiable measure of the contribution of a dedicated network node 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 can be publicly obtained from the blockchain and verified by virtue of the immutable nature of the proof-of-work supported blockchain. To prevent malicious behavior, the reputation score of a dedicated network node can only be increased by mining blocks, i.e., by making a positive contribution to the stability of the blockchain network.

[0119] The reputation score is formed by a dedicated network node that includes its identifier and a link to the previous block in the coinbase document. The content of the coinbase file is 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 authentication to build its reputation. In addition, a dedicated network node cannot forge or tamper with its reputation.

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

[0121] An example voting scheme used in a blockchain involves an open time window during which dedicated network nodes can vote, and then the votes are tallied based on the blocks mined during that time window. This would give the dedicated network nodes with the most hash power during the time window the most votes, and would not take into account contribution history. This could lead to a "hash war" and make the system vulnerable to "rented hash", where dedicated network nodes that want to distort the voting results temporarily submit a large amount of computing power to the blockchain in order to dominate the blockchain's hash power during the window, but have no resources or interest in investing this large amount of computing power in the blockchain long term. In some cases, "rented hash" is not sustainable because it is an uneconomic allocation of resources, but is a cost incurred by the dedicated network node to force a voting result. Thus, the influence on the vote obtained by a dedicated network node is disproportionate to the dedicated network node's actual participation and investment in the blockchain.

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

[0123] To vote, the 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 coinbase transaction in the coinbase transaction. In some implementations, it can also include its computed reputation score. The dedicated network node also includes a voting signal. Depending on the vote, the signal can be a binary "yes" / "no" or "for" / "against" signal, or it can be a multi-valued signal, such as choosing between three or more options, ranking between three or more options, etc. In some examples, the coinbase transaction can also include a digital signature based on the private key corresponding to the identifier of the dedicated network node. The level of the digital signature may be higher than the other content of the information fields in the coinbase transaction.

[0124] In some implementations, a single dedicated network node may be entitled to vote multiple times during the voting window. In some other implementations, each dedicated network node (i.e., each associated dedicated network node identifier PK ID)Voting is allowed only 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. Or, the strategy might be to take the last (highest block height) vote to allow dedicated network nodes to change their votes during the window period.

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

[0126] By calculating the vote using historical block data instead of current and future block data, the vote can be conducted within a relatively short period of time while ensuring that sufficient proof-of-work data is used to calculate the vote weight to accurately reflect the chain work. This can achieve a relatively short voting period without the risk of the vote weight being distorted by a temporary hash burst.

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

[0128]

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

[0130] x t＝24 t＝48 t＝72 t＝96 0.5％ 0.514 0.764 0.885 0.944 1％ 0.765 0.945 0.987 0.997 5％ 0.999 0.999 ≈1 ≈1 25％ 0.999 ≈1 ≈1 ≈1

[0131] From the above table, it can be understood that even if PK ID has only 1% of the network hash rate, a 72-hour voting period can almost guarantee that they can mine the voting block.

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

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

[0134] Now refer to Figure 8 , which shows in block diagram form a simplified computing device 800 according to an example of the present application. 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 be a non-dedicated network node that operates to verify data in a blockchain record, 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.

[0135] 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. The memory 804 may include persistent and non-persistent memory to store values, variables, and in some cases also processor-executable program instructions.

[0136] The computing device 800 may include a processor-executable application 808 that contains processor-executable instructions that, when executed, cause the processor 802 to perform one or more of the functions or operations described herein.

[0137] The various embodiments presented above are merely examples and in no way limit the scope of the present application. Variations of the innovations described herein will be apparent to those of ordinary skill in the art, and such variations are within the scope of the present application. In particular, features from one or more of the above example embodiments may be selected to create alternative example embodiments that include sub-combinations of features that may not have been explicitly described above. Additionally, features may be selected from one or more of the above example embodiments and combined to create alternative example embodiments that include combinations of features that may not have been explicitly described above. Those skilled in the art will readily appreciate the features suitable for such combinations and sub-combinations upon reviewing the present application as a whole. The subject matter described herein and in the appended claims is intended to cover and include all suitable technical variations.

Claims

1. A computer-implemented method for verifying the work history of dedicated network nodes on a blockchain in a blockchain network, comprising: Tracking and retrieving a linked chain of genesis transactions via the blockchain network, wherein each genesis transaction includes an identifier of a dedicated network node in an output including an information field, and each genesis transaction other than the first genesis transaction includes a reference to an earlier genesis transaction among the linked genesis transactions in the chain, wherein each genesis transaction is in a corresponding block mined by the dedicated network node; and Verifying the registration of the identifier of the dedicated network node in the earliest recorded genesis transaction in the chain, whereby the linked chain of genesis transactions provides the work history of the dedicated network node.

2. The method according to claim 1, wherein, The retrieving further includes: retrieving one or more subsequent genesis transactions in the blocks mined by the dedicated network node that are after the block from the blockchain, and each subsequent genesis transaction includes an identifier of the dedicated network node and a reference to the corresponding block in front of the block in the sequence.

3. The method according to claim 1 or 2 further comprises: Calculating a work contribution by the dedicated network node based on the work history of the dedicated network node.

4. The method according to claim 3, wherein, Calculating the work contribution includes: assigning a corresponding weight to each block mined by the dedicated network node, and calculating the sum of the corresponding weights.

5. The method according to claim 4, wherein, Assigning a corresponding weight to each block mined by the dedicated network node 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.

6. A computer-implemented method for determining a reputation score of a dedicated network node in a blockchain-based blockchain network, comprising: Tracking a linked chain of genesis transactions, wherein each genesis transaction includes an identifier of a dedicated network node in an information field, and each genesis transaction other than the first genesis transaction includes a reference to an earlier genesis transaction among the linked genesis transactions in the chain, wherein each genesis transaction is in a corresponding block mined by the dedicated network node; and Determining the reputation score of the dedicated network node at least in part based on a count of the corresponding blocks associated with the genesis transactions in the chain.

7. The method according to claim 6, wherein, Determining the reputation score further includes: assigning a corresponding weight to each block mined by the dedicated network node, and calculating the sum of the corresponding weights.

8. The method according to claim 7, wherein, Assigning a corresponding weight to each block mined by the dedicated network node 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 any one of claims 6 to 8, further comprising: In a voting system based on a secure blockchain, determining a weighted vote attributable to the dedicated network node based on the reputation score.

10. The method according to claim 9, wherein, Determining weighted voting includes: retrieving data from a voting block from a secure blockchain-based voting system, the voting block mined by dedicated network nodes and containing transactions, the transactions containing identifiers of the dedicated network nodes, references to at least one genesis transaction containing the identifiers of the dedicated network nodes, and voting signals.

11. A computing device, the computing device comprising: one or more processors; a memory; and computer-executable instructions stored in the memory, the computer-executable instructions, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 10.

12. A computer-readable medium storing processor-executable instructions that, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 10.

Images