Decentralized security measures against fraud

Abstract

A method includes obtaining, at a node server, blockchain data for a blockchain address on a blockchain network. The blockchain data includes a plurality of transactions for the blockchain address. The method includes generating a local node trust score for a blockchain address based on blockchain data. The local node trust score indicates the likelihood that the blockchain address involves fraudulent activity. The method includes receiving a plurality of other local trust scores for the blockchain address from a plurality of remote servers. The method includes determining a consensus trust score based on the local node trust score and a plurality of other local trust scores. In addition, the method includes receiving a trust request for the blockchain address from the requesting device, and sending a consensus trust score specifying the blockchain address to the requesting device.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 16 / 429,562, filed on June 3, 2019, which claims the benefit of U.S. Provisional Application No. 62 / 680,017, filed on June 4, 2018. The disclosures of each of the above applications are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates to providing security measures to prevent fraud in blockchain transactions. Background Art

[0004] Cryptocurrencies may provide a medium of exchange for pseudonymous / anonymous cryptocurrency traders. Cryptocurrencies may operate on a decentralized network of computing devices that each operate according to a blockchain protocol. The decentralized network may control a blockchain transaction ledger that includes a list of transactions between different blockchain addresses. Transactions on the decentralized network may be verified by cryptography. In some cases, traders may interact with the decentralized network using a wallet application, and traders may interact with the decentralized network via a digital currency exchange. Summary of the invention

[0005] In one example, a method includes obtaining blockchain data for a blockchain address on a blockchain network at a node server. The blockchain data includes multiple transactions for the blockchain address. The method also includes generating a local node trust score for the blockchain address based on the blockchain data of the blockchain address. The local node trust score indicates the likelihood that the blockchain address is involved in fraudulent activity. The method also includes receiving multiple additional local trust scores for the blockchain address from multiple remote servers. In addition, the method includes determining a consensus trust score based on the local node trust score and the multiple additional local trust scores. The consensus trust score indicates a consensus value of the local node trust score between the node server and the multiple remote servers. The method also includes receiving a trust request for the blockchain address from a requesting device, and sending the consensus trust score for the specified blockchain address to the requesting device.

[0006] In one example, a system includes one or more memory components and one or more processing units. The memory components are configured to store blockchain data for a blockchain address on a blockchain network. The blockchain data includes multiple transactions for the blockchain address. The one or more processing units are configured to execute computer-readable instructions that cause the one or more processing units to generate a local node trust score for the blockchain address based on the blockchain data of the blockchain address. The local node trust score indicates the likelihood that the blockchain address is involved in fraudulent activity. The one or more processing units are configured to receive multiple additional local trust scores for the blockchain address from multiple remote servers. The one or more processing units are configured to determine a consensus trust score based on the local node trust score and the multiple additional local trust scores. The consensus trust score indicates a consensus value of the local node trust score. The one or more processing units are configured to receive a trust request for a blockchain address from a requesting device and send the consensus trust score of the specified blockchain address to the requesting device. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present disclosure will be more fully understood from the detailed description and accompanying drawings.

[0008] Figures 1A-1E An example trust network in communication with a cryptocurrency trader computing device, an intermediary trading system, and an automated trading system is shown.

[0009] Figure 2 is a method that describes the operation of an example trust network.

[0010] Figure 3 is a functional block diagram of an example node that calculates local trust scores and consensus trust scores.

[0011] Figure 4A is a functional block diagram of an example node that calculates the consensus trust score.

[0012] Figure 4B is a flow chart illustrating an example method of calculating a consensus trust score.

[0013] Figure 5 is a functional block diagram of an example node for calculating reputation value.

[0014] Figure 6 is a functional block diagram of an example node that implements a token economy for a trust network.

[0015] Figure 7 An example method describing the operation of a reward protocol is shown.

[0016] Figures 8A-8B A graphical user interface (GUI) for requesting and reviewing a trust report is shown.

[0017] Fig. 9 is a functional block diagram of a trust network used in a payment insurance implementation.

[0018] Fig. 10A An example relationship of staked tokens and consensus trust score cost is shown.

[0019] Fig. 10B Example services associated with different levels of nodes are shown.

[0020] Fig. 10C An example relationship between the number of nodes, the number of cliques, address overlap, and the probability that a node will obtain a single address in its control is shown.

[0021] Fig. 10D Sample token stake amounts and node counts are shown.

[0022] Fig.11 is a functional block diagram of an example trust score determination module and local trust data store.

[0023] Fig.12 is a method describing the operation of an example trust score determination module.

[0024] Fig.13 It is the functional block diagram of the data acquisition and processing module.

[0025] Fig.14 It is a functional block diagram of the blockchain data acquisition and processing module.

[0026] Figures 15A-15B The generation and processing of blockchain graph data structures is shown.

[0027] Fig.16 It is a functional block diagram of the scoring feature generation module and the scoring model generation module.

[0028] Fig.17 is a functional block diagram illustrating the operation of the score generation module.

[0029] In the drawings, reference numerals may be repeated to identify similar and / or identical elements. DETAILED DESCRIPTION

[0030] Although cryptocurrencies have experienced growth, their mainstream utility as a medium of exchange may be more limited due to a lack of protection for payers. For example, cryptocurrency funds sent to a fraudulent party may not be easily recovered. The disclosed trust network 100 generates a consensus trust score for cryptocurrency traders. The consensus trust score can provide cryptocurrency traders with a safeguard against fraud while protecting user anonymity and autonomy. The consensus trust score can provide a base trust level on which other security layers can be built, including cryptocurrency payment insurance, protection, and reimbursement.

[0031] The trust network 100 generates a consensus trust score for cryptocurrency traders. For example, for cryptocurrencies based on blockchain technology, the trust network 100 may generate a consensus trust score for different blockchain addresses interacting on the blockchain. The trust network 100 may determine the consensus trust score based on data retrieved from various data sources (e.g., fraud / custodial data) and the blockchain data on which the cryptocurrency is based. The trust score (e.g., the consensus trust score) may be a number (e.g., a decimal or integer) indicating the likelihood that a blockchain address is involved in fraudulent activity. In other words, the trust score may represent the propensity of a blockchain address to be involved in fraudulent activity.

[0032] A cryptocurrency trader may request a consensus trust score from the trust network 100 before engaging in a cryptocurrency blockchain transaction, in which funds (e.g., cryptocurrency blockchain tokens) are traded on the blockchain. In general, a cryptocurrency trader may use a consensus trust score to determine whether a blockchain address with which they are transacting is trustworthy. For example, a trader who intends to send funds to a recipient may request the recipient's consensus trust score. In this example, the trader may use the consensus trust score of the intended recipient in order to assess the likelihood that the intended recipient is a fraudulent party.

[0033] Traders can use consensus trust scores to take various actions. For example, a trader can use consensus trust scores to determine whether to proceed or cancel a blockchain transaction. As another example, a trader (e.g., a digital exchange) can use consensus trust scores to determine whether to insure a transaction. As another example, an organization can use consensus trust scores to decide whether to accept funds from a blockchain address. Similarly, the consensus trust scores described herein can help protect traders from fraud or from receiving fraudulent funds. Note that the consensus trust score informs traders of the degree to which any cryptocurrency address can be trusted without requiring the trader to know the identity of the party behind the address. In this way, the consensus trust score can keep traders anonymous.

[0034] Figure 1AAn example trust network 100 is shown that communicates with cryptocurrency trader computing devices 102, 104, 106 (hereinafter referred to as "trader computing devices") via a communication network 108. The network 108 may include various types of computer networks, such as a local area network (LAN), a wide area network (WAN), and / or the Internet. The trust network 100 may include a plurality of trust nodes 100-1, 100-2..., 100-N (referred to herein as "nodes"). Each of the nodes 100 may include one or more node computing devices (e.g., one or more server computing devices) that implement the various protocols described herein.

[0035] Node 100 may obtain data associated with a cryptocurrency blockchain address and determine various trust scores based on the obtained data. A trust score determined locally at a node based on the obtained data may be referred to as a "local node trust score" or "local trust score". Nodes 100 may be configured to communicate their local trust scores between each other so that each node may know the local trust scores associated with other nodes. After a node obtains multiple local trust scores, the node may determine a candidate consensus trust score (hereinafter referred to as a "candidate trust score") based on the multiple local trust scores. One or more nodes may determine a consensus trust score based on the multiple candidate trust scores. The consensus trust score may indicate a consensus value of a local trust score between multiple nodes. The consensus trust score for a cryptocurrency address may be written to a distributed consensus ledger and subsequently retrieved from the trust network 100 (e.g., in response to a trust request).

[0036] The trust scores described herein (e.g., local, candidate, or consensus) may be calculated / provided in various formats. In some implementations, the trust score may be an integer value with a minimum and maximum value. For example, the trust score may be in the range of 1-7, where a trust score of '1' in this example indicates that the blockchain address may be fraudulent, and a trust score of '7' may indicate that the blockchain address is unlikely to be fraudulent (i.e., very trustworthy). In some implementations, the trust score may be a decimal value. For example, the trust score may be a decimal value indicating the likelihood of fraud (e.g., a percentage value from 0 to 100%). In some implementations, the trust score may be in the range of from a maximum negative value to a maximum positive value (e.g., from -1.00 to 1.00), where a larger negative value indicates that the address is more likely to be fraudulent. In this example, a larger positive value may indicate that the address is more likely to be trustworthy. Customers may select the trust score format they prefer.

[0037] The distributed trust network 100 described herein distributes the trust score calculation workload across multiple nodes to produce a resilient network that is resistant to failures / outages and attacks. In some implementations, the trust network 100 may include built-in transaction autonomy mediated by tokens (e.g., UTOKEN) that allow the trust network 100 to distribute the computational workload. In addition, distributing trust computations throughout the network can provide resistance to fraud / conspiracies intended to undermine the network.

[0038] The trader computing devices 102, 104, 106 comprise computing devices that can interact with the trust network 100. Example trader computing devices may include a user trader device 102, such as a smartphone, tablet, laptop, desktop computer, or other computing device. The user trader device 102 may include an operating system 110 and a plurality of applications, such as a web browser application 112 and additional applications 114.

[0039] The user trader device 102 may include a transaction application 116 that may transact with a cryptocurrency blockchain network 118 (hereinafter referred to as "cryptocurrency network 118") to perform blockchain transactions. The transaction application 116 may also request a consensus trust score from the trust network 100. Some example transaction applications may be referred to as "wallet applications". In some cases, if the decentralized wallet application does not interact with a centralized server-side component, the transaction application may be referred to as a "decentralized wallet application".

[0040] Additional example trader devices may be included in the intermediary trading system 104. The intermediary trading system 104 (e.g., one or more server computing devices) may communicate with the cryptocurrency network 118, the user trader device 102, and the trust network 100. The intermediary trading system 104 may perform cryptocurrency transactions on behalf of the user trader device 102. The intermediary trading system 104 may also obtain a consensus trust score from the trust network 100 on behalf of the user trader device 102. In some implementations, the intermediary trading system 104 may provide a user interface for the user trader device 102 (e.g., via a web-based interface and / or an installed trading application 116). The example intermediary trading system 104 may include a digital currency exchange (e.g., Coinbase, Inc., San Francisco, California). In some implementations, the exchange may be decentralized.

[0041] Additional example trader devices may be included in the automated trading system 106. The automated trading system 106 (e.g., one or more server computing devices) may communicate with the trust network 100 and the cryptocurrency network 118. The example automated trading system 106 may include a payment system, such as a payment system or gateway that makes recurring payments (e.g., Stripe, Inc. of San Francisco, California, or Plaid, Inc. of San Francisco, California).

[0042] The transactor devices 102, 104, 106 may participate in transactions on a cryptocurrency network 118. The cryptocurrency network 118 may be formed by a network of computing devices that each operate according to a cryptocurrency blockchain protocol 120. The cryptocurrency network 118 may control a cryptocurrency blockchain transaction ledger 122 (hereinafter referred to as "cryptocurrency ledger 122"). The cryptocurrency ledger 122 includes a list of transactions between different cryptocurrency blockchain addresses. The cryptocurrency ledger 122 may also include additional data, such as transaction metadata. Example cryptocurrency networks 118 may include, but are not limited to, Ethereum and Litecoin. Although in Figure 1A Although a single cryptocurrency network is shown in FIG, the trust network 100 may use the techniques described herein to provide consensus trust scores for addresses on multiple different cryptocurrency blockchain networks.

[0043] The cryptocurrency ledger 122 may include cryptocurrency blockchain addresses that identify transactors on the cryptocurrency network 118. A transactor may refer to a party that controls transactions for a cryptocurrency blockchain address. For example, a transactor may include an individual or an organization such as a business, a non-governmental organization, or a decentralized autonomous organization. A transactor may control one or more cryptocurrency blockchain addresses on a single cryptocurrency network. A transactor may also have one or more cryptocurrency blockchain addresses on different cryptocurrency networks.

[0044] A trader may initiate a blockchain transaction in which the trader's blockchain address sends / receives funds to / from another blockchain address. A blockchain address that sends funds to another blockchain address may be referred to herein as a "blockchain sender address" or "sender address." A blockchain address that receives funds may be referred to herein as a "blockchain receiver address" or "receiver address."

[0045] The trader devices 102, 104, 108 may send a trust request to the trust network 100 and receive a trust response from the trust network 100 (see, e.g., Figure 1B-1D ). A trust request may indicate one or more cryptocurrency blockchain addresses that a trader wants to trust a report (e.g., one or more consensus trust scores). In some implementations, a trust request may include a request for payment, such as blockchain tokens and / or fiat currency (e.g., U.S. dollars). The request for payment may be distributed to nodes in the trust network 100 as payment for providing a consensus trust score.

[0046] In one example, a trader device may send a trust request to the trust network 100 and receive a trust response (e.g., a trust report) from the trust network. The trader device and the trust network 100 may communicate via an application programming interface (API). The trust request may include the cryptocurrency blockchain address of the trader on the other side of the transaction. For example, a trust request from a sender may request a trust report for the blockchain address of a recipient. The sender may make a decision based on the received trust report, such as whether to participate in a cryptocurrency blockchain transaction with the recipient.

[0047] Figure 1B-1D The interactions between the different transactor devices / systems 102, 104, 108, the cryptocurrency network 118, and the trust network 100 are shown. Figure 1B In the embodiment of the present invention, a user trader device 102 includes a transaction application 116 (e.g., a wallet application) that conducts transactions with a cryptocurrency network 118. The transaction application 116 includes a trust request module 128 that interfaces with the trust network 100. For example, the trust request module 126 can generate a trust request 130 (e.g., a network request). The trust request module 126 can also receive a trust response 132 from the trust network 100. In some implementations, the trust request module 126 can generate a graphical user interface (GUI) with which a user can interact in order to send a trust request 130 and view a trust report 132.

[0048] exist Figure 1C In the example, the trader device 102 can trade on the cryptocurrency network 118 via the intermediate trading system 104. For example, in Figure 1C In the example, the trader device 102 may include a web browser application 112 that interacts with the intermediary transaction system 104. The intermediary transaction system 104 (e.g., a web server) may provide an interface to the web browser 112 for transactions on the cryptocurrency network 118. The intermediary transaction system 104 may also provide an interface (e.g., a web-based interface) for the user to select whether the user wants to trust the report before participating in the blockchain transaction.

[0049] exist Figure 1D In the embodiment of the present invention, the automated trading system 106 controls transactions on the cryptocurrency network 118. The automated trading system 106 may also request a trust report from the trust network 100. In some implementations, the transactions in which the automated trading system 106 participates may depend on the consensus trust score reported by the trust network 100. For example, if the trust score indicates that the address is unlikely to be involved in fraudulent activity, the automated trading system 106 may participate in the transaction.

[0050] While the devices / systems described herein may make a trust request 130 in order to receive a consensus trust score before conducting a cryptocurrency blockchain transaction, in some implementations, other devices / systems may request a consensus trust score in other circumstances. For example, a compliance officer at a switch may request a consensus trust score for compliance reasons.

[0051] See also Figure 1E In some implementations, the trust network 100 may implement a fraud alert protocol that can automatically notify network participants (e.g., fraud alert requesting devices) of potentially fraudulent cryptocurrency blockchain addresses. For example, a node may include a fraud alert module 134 that is configured to provide a fraud alert 136 under a set of fraud alert criteria that can be configured by a user. In one example, the fraud alert module 134 may monitor one or more cryptocurrency addresses and provide a fraud alert 136 if the consensus trust score of any address drops below a threshold level of trustworthiness (e.g., set by a user). In another example, a fraud alert 136 may be sent if the monitored trust score changes by more than a threshold percentage. In some implementations, a fraud alert protocol may be implemented using a smart contract that monitors the consensus trust score and provides alerts based on a set of business rules that may be defined by a user in some implementations, and a node may be required to stake an amount of UTOKEN to be eligible to receive fraud alerts.

[0052] In some implementations, nodes may be connected via a network of state channels. When a cryptocurrency trader issues a trust request and payment (e.g., UTOKEN), the request may be idled until it reaches a node with the requested consensus trust score. The node may return the consensus trust score to the cryptocurrency trader. The payment may then be authorized according to the reward protocol.

[0053] Example traders may include, but are not limited to, custodial exchanges, non-custodial exchanges, custodial wallets, non-custodial wallets, new token developers and sellers, decentralized applications, blockchain-enabled merchants, node operators, algorithm vendors, and proof-of-work security providers.

[0054] A custodial exchange may refer to an entity (e.g., a company) that enables the exchange of crypto assets while holding assets on behalf of its customers. A custodial exchange may use a consensus trust score to assess whether depositing crypto assets is fraudulent. Additionally, custodial exchanges may receive alerts to monitor blockchain addresses they hold in custody. A non-custodial exchange may refer to an entity (e.g., a company) that enables the exchange of crypto assets without holding crypto assets on behalf of token buyers or sellers. A non-custodial exchange may use a consensus trust score to assess the trustworthiness of a contracting party.

[0055] A custodial wallet may refer to an entity (e.g., a company) that holds private keys on behalf of a customer and enables them to send and receive crypto assets. Custodial wallets may use consensus trust scores to assess whether the crypto assets being deposited are fraudulent and receive fraud alerts. They may also use consensus trust scores to protect their users from sending crypto assets to fraudulent addresses. A non-custodial wallet may refer to an entity (e.g., a company) that makes software that allows individuals to hold and trade crypto assets locally on their personal devices. A non-custodial wallet may use consensus trust scores to protect its users from sending crypto assets to fraudulent addresses and from receiving fraudulent funds.

[0056] New token developers and sellers can refer to an entity (e.g., a company or individual) that creates software that, when run by a peer-to-peer network, creates a new decentralized token. The company can also sell some initial distribution of tokens to interested buyers. These traders can perform an initial coin offering (ICO). New token developers and sellers can use the consensus trust score to ensure that the funds used to purchase their tokens are not fraudulent, thereby ensuring that they are selling tokens in a compliant manner.

[0057] Decentralized applications can refer to applications that run on a decentralized network. These applications can include applications that manage money, applications that involve money but require another money, and other applications that include voting and governance systems. In addition to protecting participants from fraud, decentralized applications can also use consensus trust scores for any activity that involves an assessment of trust in a contracting party.

[0058] A blockchain-enabled merchant may refer to an entity (e.g., a company) that accepts payments in the form of crypto assets (e.g., security tokens). Blockchain-enabled merchants can use consensus trust scores to ensure that funds being used as payments are not fraudulent. They can also receive alerts about addresses they interact with.

[0059] Return to reference Figure 1A , the environment includes a data source 124 that the trust network 100 can use to determine whether a blockchain address is fraudulent. Example data sources 124 described herein include fraud data sources and custodial data sources. The trust network 100 can determine a local trust score based on data included in the data source 124 and data included in the cryptocurrency ledger 122.

[0060] Figure 2 Shows the description Figures 1A-1D Example methods of operation of the environment shown. For example, Figure 2 The method shows the determination of a local trust score, a candidate trust score, and a consensus trust score for a single cryptocurrency blockchain address. Figure 2A method is proposed to determine local trust scores, candidate trust scores, and consensus trust scores for multiple cryptocurrency blockchain addresses.

[0061] In block 200, the node 100 obtains and processes the fraud and custody data 124 associated with the cryptocurrency address. In block 202, the node 100 obtains and processes the cryptocurrency blockchain data associated with the cryptocurrency address. In block 204, the nodes 100 each determine a local trust score for the cryptocurrency address based on the data obtained in blocks 200-202.

[0062] In block 206, the nodes 100 communicate local trust scores of the cryptocurrency addresses to each other. After communicating the local trust scores, each node may include multiple local trust scores calculated by other nodes. In block 208, the node 100 determines a candidate trust score for the cryptocurrency address based on the local trust score. In block 210, the node 100 determines a consensus trust score for the cryptocurrency address based on the candidate trust score for the cryptocurrency address. In block 212, the node 100 may update the distributed consensus trust score ledger to include the calculated consensus trust score. In blocks 214-216, the trust network 100 receives a trust request 130 for the cryptocurrency address from a requesting device and sends a trust response 132 including the consensus trust score to the requesting device.

[0063] Figure 3 The generation of a local trust score is shown. FIG. 4A to FIG. 4B 1 shows the generation of a consensus trust score. In addition to generating trust scores, the trust network 100 can also implement Figure 5-7 In some implementations, the trust network 100 may implement a reputation protocol that calculates and stores a reputation value that indicates various parameters associated with a node, such as the amount of work performed by the node (see, e.g., Figure 5 ).

[0064] In some implementations, the trust network 100 may implement a token economy that operates as a medium of exchange in the trust network 100. The token economy described herein uses a token called "UTGKEN". Each of the nodes may implement a wallet module (e.g., see Figure 6 ), the wallet module can send, receive, pledge and burn UTGKEN according to the protocol implemented in the trust network.

[0065] In some implementations, the trust network 100 may implement a reward protocol that tracks various parameters of nodes (e.g., workload) and rewards nodes using UTOKEN (e.g., see Figure 6-7 ). The trust network 100 may also implement a pledge protocol that determines the functionality of a node and penalizes certain node behaviors (e.g., the generation of fraudulent data).

[0066] Different nodes in the trust network 100 may be configured to implement different features of the trust network 100. For example, different nodes may be configured to implement different protocols or portions of protocols described herein. In some implementations, the pledge protocol may determine which features a node may implement. The modules and data stores included in the node may represent the protocols implemented by the node and the data stored by the node. Each node may include one or more computing devices. In some implementations, multiple nodes may run on a single computing device.

[0067] Figure 3 An example node 100-1 is shown that includes a trust score determination module 300 and a local trust data store 302. The trust score determination module 300 obtains and processes various data described herein, such as fraud and custody data 124 and blockchain data. The local trust data store 302 can store data for multiple cryptocurrency addresses.

[0068] The data associated with a single cryptocurrency address is shown here as a blockchain address record 304. The local trust data store 302 may include multiple such blockchain address records, each for a different cryptocurrency address. Each blockchain address record 304 may include a blockchain address 306 that uniquely identifies the record 304. Each blockchain address record 304 may also include a local trust score 308 associated with the blockchain address 306. The blockchain address record 304 may include a history of local trust scores calculated over time for blockchain addresses.

[0069] The blockchain address record 304 described herein represents data stored in the local trust data store 302. Node 100-1 may include a variety of different data structures for implementing data. Therefore, the blockchain address record 304 may be implemented using one or more data structures different from those explicitly described herein.

[0070] exist Figure 3 In the example embodiment of the present invention, the trust score determination module 300 obtains and processes various types of data, such as custody data and fraud data 124. Example fraud and custody data may include data that provides evidence of fraud about a cryptocurrency address and / or indicates a party that owns / controls the cryptocurrency address. The trust score determination module 300 may store the custody and fraud data associated with the cryptocurrency address in a blockchain address record 304. The trust score determination module 300 may also generate a fraud tag based on the obtained fraud data, the fraud tag indicating whether the cryptocurrency address is likely to be fraudulent.

[0071] The trust score determination module 300 obtains and processes blockchain data (e.g., the cryptocurrency ledger 122). The trust score determination module 300 can store raw and processed blockchain data associated with a cryptocurrency address in a blockchain address record 304. Example cryptocurrency blockchain data can include data for a plurality of blockchain transactions between a plurality of different cryptocurrency addresses.

[0072] The trust score determination module 300 determines a local trust score for a cryptocurrency address based on the acquired blockchain data and fraud / custody data. In some implementations, the trust score determination module 300 may determine a local trust score for a cryptocurrency address based on the blockchain data (e.g., see Fig. 15B ) to generate a blockchain graph data structure. The trust score determination module 300 may also process the graph to determine one or more graph-based values ​​(e.g., importance values) that may be used to generate a local trust score.

[0073] In some implementations (e.g., see Fig.16 ), the trust score determination module 300 can generate a scoring feature for the cryptocurrency address and generate one or more scoring models based on the scoring feature and other data (e.g., flagged fraud data). In these implementations, the trust score determination module 300 can use the one or more scoring models and the scoring features associated with the blockchain address to generate one or more local trust scores for the blockchain address. Figure 11-17 A more detailed implementation of the trust score determination module 300 and the local trust data store 302 is shown.

[0074] Multiple nodes may communicate with each other in order to reach a consensus trust score for a cryptocurrency address. Each node may be identified (e.g., uniquely identified) by a node identifier (ID). In some implementations, a public / private key pair is generated when the node is started. In these implementations, the node's public key may be used as the node ID, although other identifiers may be used.

[0075] In the case where different nodes access the same / similar cryptocurrency blockchain data and fraud / custody data, different nodes can calculate the same / similar local trust score. In some cases, the local trust scores between nodes can be different. For example, when a node has access to different fraud and custody data, the local trust score can be different. In a specific example, nodes located in different jurisdictions (e.g., countries) can access data sources that are blocked in other jurisdictions. In another specific example, some nodes can access information at different rates.

[0076] The nodes 100 implement a trust consensus protocol that determines a consensus trust score for a cryptocurrency address. The consensus trust score may be stored in a consensus trust score ledger 400 distributed to nodes across the trust network 100. Figure 4AAn example node 100-1 is shown that includes a consensus determination module 310 and a trust consensus data store 312 (hereinafter referred to as "consensus data store 312"). The trust network 100 may include multiple nodes, which include Figures 4A-4B The consensus determination module 310 can communicate with other consensus determination modules of other nodes (e.g., via the communication module 310-1) to determine the consensus trust score. The consensus data store 312 includes the consensus trust score and other data in the consensus trust score ledger 400.

[0077] The consensus determination module 310 may communicate with other nodes (e.g., consensus modules of other nodes). For example, each node may communicate its local trust score to other nodes via outgoing trust consensus message 402. In addition, each node may receive local trust scores from other nodes via incoming trust consensus message 404. An example trust consensus message may include a node ID, a node IP address, an encrypted blockchain address, and an associated local trust score. In some cases, instead of indicating an associated local trust score, the trust consensus message may indicate that the local trust score has not yet been calculated or is in the process of being calculated.

[0078] The consensus determination module 310 may generate a local trust score list 406 ("trust score list 406") based on local trust scores received from other nodes (e.g., using the list construction module 310-2). The trust score list 406 may include a list of node IDs and corresponding local trust scores for cryptocurrency addresses. The consensus determination module 310 may generate a local trust score list 406 for each cryptocurrency address. Each node may communicate its trust score list to other nodes. For example, a node may send / receive a trust score message including a trust score list. A node may update a local trust score list based on other received trust score lists.

[0079] Each node in the trust network 100 may be configured to communicate with a different group of nodes. In other words, the nodes in the trust network 100 may be configured to communicate with non-overlapping groups of nodes. Since different nodes may communicate with different groups of other nodes, ultimately, each node that communicates local trust scores with each other may know the local trust score calculations of other nodes. In this case, different nodes may include similar trust score lists. In some examples, the trust scores in the trust score lists may converge within a fraction of a second or a few seconds.

[0080] The trust score list 406 for cryptocurrency addresses may include a frequency (count) distribution of local trust scores. In some cases, the trust score list 406 may include a large number of local trust scores within a tight grouping. In some cases, the trust score list 406 may include outlier trust scores with values ​​outside the main grouping. For example, an outlier may be due to a change in the information used to generate the local trust score. As another example, one or more outliers may be caused by a node that generates / distributes fraudulent trust scores. As described herein, a node that generates / distributes fraudulent trust scores may be responsible (e.g., by burning staked funds).

[0081] The consensus determination module 310 determines a candidate trust score based on the local trust scores included in the trust score list 406 (e.g., using the candidate determination module 310-3). In some implementations, the consensus determination module 310 may include a "candidate determination criterion" that triggers the determination of the candidate trust score. Example candidate determination criteria may include the presence of a threshold number of nodes and / or a threshold score of nodes' local trust scores. For example, the consensus determination module 310 may determine the candidate trust score in response to the presence of a threshold number / score of local trust scores included in the trust score list.

[0082] In some implementations, the consensus determination module 310 may determine candidate trust scores in response to a distribution pattern of trust scores in the trust score list. For example, if the trust score distribution includes outliers, when the trust score is centered on the distribution (e.g., closely centered on a single distribution), the consensus determination module 310 may be triggered to determine candidate trust scores, and the consensus determination module 310 may continue to communicate local trust scores with other nodes. In a specific example, when the variance of the distribution is less than a threshold variance, the consensus determination module 310 may be triggered to determine candidate trust scores. In the case of a distribution with multiple patterns, the consensus determination module 310 may determine whether the pattern is valid or whether the pattern is attributed to a fraudulent trust score. Similarly, if the variance of the distribution is too large (e.g., greater than a threshold), the consensus determination module 310 may determine whether the variance is due to changes in calculations and / or fraudulent behavior. The consensus determination module 310 may filter out (i.e., remove) trust scores that can be attributed to fraudulent behavior before determining candidate trust scores.

[0083] The consensus determination module 310 may use various techniques to determine the candidate trust scores. In some implementations, the consensus determination module 310 may remove outlier local trust scores from the trust score list before determining the candidate trust scores. The consensus determination module 310 may determine the candidate trust scores based on an average (e.g., a blended average) of the remaining local trust scores in the trust score list 406. For example, the consensus determination module 310 may determine the candidate trust scores by using a statistically weighted average of the local trust scores based on the node counts.

[0084] The nodes may communicate candidate trust scores between each other. The nodes may also store candidate trust scores 408. A set of consensus determination modules may determine a consensus trust score for a cryptocurrency address based on multiple candidate trust scores 408. In some implementations, the consensus determination module may monitor the candidate trust scores to determine whether the candidate trust scores converge to similar trust scores. The consensus determination module may be configured to determine the consensus trust score in response to one or more consensus triggers associated with the candidate trust scores. For example, if the candidate trust scores greater than a threshold number / score are consistent (e.g., within a threshold variance), the consensus determination module may be configured to determine a consensus trust score.

[0085] In some implementations, the consensus determination module may perform validation operations associated with the candidate trust score (e.g., using validation module 310-4). For example, the consensus determination module may perform error checking on the candidate trust score. The error checking operation may include verifying whether communication of the local trust score actually occurred for the candidate score or whether a conspiracy occurred that resulted in the candidate score. In some implementations, the consensus determination module may query multiple nodes participating in the communication of the local trust score and the determination of the candidate score to determine what the multiple nodes communicated with each other. In some implementations, the nodes may select a leader node to perform error checking operations and determine whether the nodes are consistent.

[0086] After validating the candidate trust scores, the consensus determination module 310 may calculate the consensus trust score. In some implementations, the consensus determination module may determine the consensus trust score based on an average (e.g., a mixed average) of the candidate trust scores. For example, the consensus determination module may determine the consensus trust score by using a statistical weighted average of the candidate trust scores based on counts. The consensus determination module 310 may then update the consensus ledger 400 with the consensus trust score. The consensus determination module 310 may then distribute the updated ledger to other nodes (e.g., using the ledger update module 310-5). In some implementations, although nodes that did not participate in generating the consensus ledger 400 may receive an updated version of the consensus ledger 400, only a subset of the nodes may write the trust score and other data to the consensus ledger 400.

[0087] The consensus ledger 400 includes consensus trust scores for different cryptocurrency addresses over time. The consensus trust scores included in the consensus ledger 400 can be provided to trust score requesters. The consensus ledger 400 can also include timing data indicating when the consensus trust score is written to the ledger 400. For the determined consensus trust score, the consensus ledger can include verification information associated with the consensus trust score, such as a candidate trust score for the consensus trust score and a verified node. Storing the verification information for the consensus trust score can allow a node to check how the consensus trust score is verified.

[0088] Node 100 may be configured to generate a new trust score for a new cryptocurrency address and update the trust score over time. For example, the trust score determination module may be configured to generate / update a local trust score for a cryptocurrency address. As another example, the consensus determination module may be configured to generate / update a candidate trust score and a consensus trust score over time. The update frequency may be set by a consensus protocol. In some cases, the data associated with a cryptocurrency address may change over time. In some cases, the data included in the hidden blockchain may change over time. These trust score determination modules and consensus determination modules may be configured to generate a new trust score in response to such changes in the data.

[0089] In some implementations, the consensus determination module may communicate the new local trust score and / or updated local trust score to other nodes. For example, if the update in the local trust score results in a change greater than a threshold amount, the consensus determination module may communicate the update in the local trust score to other nodes. The update to the local trust score may in turn cause a change to the candidate trust score, which may cause a change to the consensus trust score and the consensus ledger. In this way, the consensus ledger 400 may reflect the history of changes in the consensus trust scores of multiple cryptocurrency addresses over time.

[0090] Regarding the calculation of trust scores, different nodes may have different levels of functionality. Different functions may be based on the amount of value (e.g., UTOKEN) pledged by the node, where a larger pledge amount may authorize more functions. In some implementations, all nodes may be authorized to purchase trust scores and include a copy of the consensus ledger. In these implementations, a subgroup of nodes may be configured to calculate a local trust score, a candidate trust score, and a consensus trust score. In addition, a subgroup of nodes or another subgroup may be configured to write a consensus trust score to the consensus ledger.

[0091] Figure 4B An example method is shown that describes the calculation of a consensus trust score from the perspective of an example node 100 - 1 . Figure 4BThe method may be performed multiple times to determine local trust scores, candidate trust scores, and consensus trust scores for multiple cryptocurrency blockchain addresses.

[0092] In blocks 410-412, the trust score determination module 310 obtains and processes the fraud and custody data 124 and the cryptocurrency blockchain data. In block 414, the trust score determination module 310 determines a local trust score for the cryptocurrency address. In block 416, the consensus determination module 310 receives the local trust score from other nodes. In block 418, the consensus determination module 310 sends the local trust score to the other nodes.

[0093] In block 420, the consensus determination module 310 determines whether to calculate a candidate trust score (e.g., based on the candidate determination criteria). If the candidate determination criteria are not met, the consensus determination module 310 may continue to communicate the local trust score with other nodes in blocks 416-418. If the consensus determination module 310 determines that the candidate determination criteria are met, in block 422, the consensus determination module 310 may determine the candidate trust score based on the local trust scores in the trust score list 406. In block 424, the consensus determination module 310 may determine a consensus trust score based on the plurality of candidate trust scores. In block 426, the consensus determination module 310 may update the consensus trust ledger 400 to include the consensus trust score.

[0094] See also Figure 5 , the trust network 100 may implement a reputation protocol in which multiple nodes may each calculate one or more reputation values. The reputation value of a node may indicate various parameters associated with the node, such as the amount of work performed by the node during the trust score calculation and distribution, the quality of the work performed (e.g., accuracy), and the consistency of the node operation (e.g., node uptime). The reputation value may be used by other protocols in the trust network 100. For example, a node may determine a candidate and / or consensus trust score based on a reputation value associated with one or more nodes. As another example, a node may be rewarded and / or punished based on its reputation value.

[0095] Node 100-1 includes a reputation determination module 500 that determines a reputation value of a node. In some implementations, node 100 may send reputation messages 504-1, 504-2 to other nodes. Reputation message 504 may include reputation data, such as a reputation value associated with one or more nodes. In this way, each node may receive the reputation values ​​of multiple other nodes. In a specific example, each node may be configured to communicate reputation data with a group of other nodes. In this specific example, each node may directly request reputation data from any node in the group of nodes. In addition, each node may also request reputation data of multiple other nodes from any node in the group of nodes.

[0096] The node includes a reputation data store 502 that stores reputation data for a plurality of nodes (e.g., a subgroup of nodes on a trust network). The reputation data may be stored in a reputation ledger 508 that includes a plurality of node IDs and associated reputation values. The reputation data store 502 may also store additional information 508, such as data used to generate a reputation value and data associated with generating a consensus trust score.

[0097] The reputation determination module 500 may determine a plurality of different reputation values ​​for each node. In some implementations, the reputation determination module 500 may determine one or more work reputation values ​​for the amount of work performed by the node with respect to computing the trust score. For example, the reputation determination module 500 may determine one or more reputation values ​​based on the number of local trust scores calculated, the number of candidate trust scores calculated, and the amount of work associated with computing the consensus trust score. The one or more work reputation values ​​may also be based on the amount of communication (e.g., trust consensus messages) performed by the node.

[0098] The reputation determination module 500 may also determine a plurality of quality reputation values ​​for a node based on the quality of the computations performed by the node. For example, the quality reputation value may be based on a plurality of trust score cluster values ​​generated by the node and how quickly the trust score is generated. The reputation determination module 500 may also determine a plurality of distribution reputation values ​​for a node based on the distribution of consensus trust scores to requesters and the distribution of trust scores as fraud alerts.

[0099] The reputation determination module 500 may also determine a plurality of node performance reputation values ​​based on various node parameters such as node bandwidth, node processing power, node throughput, and node availability. Example reputation values ​​associated with node availability may be based on an uptime value, a mean time between failures (MTBF) value, and / or a mean time to repair (MTTR) value.

[0100] The reputation determination module 500 may determine one or more data storage reputation values ​​based on the amount of data (e.g., historical data) stored at the node and the amount of time the data is stored. The reputation determination module 500 may also determine one or more reputation values ​​indicating the amount of time the node has been included (e.g., online) in the trust network 100. The reputation determination module 500 may determine one or more pledge reputation values ​​based on the amount pledged by the node. In addition, the reputation determination module 500 may determine one or more outlier reputation values ​​indicating the number of outliers associated with the node and whether the outliers are considered fraudulent or supported by evidence.

[0101] In some implementations, reputation determination module 500 may calculate one or more composite reputation values, each of which may be a function of any individual reputation value described herein. For example, a composite reputation value may be a weighted calculation of one or more composite reputation values.

[0102] The reputation data store 502 may store information other than the reputation ledger. For example, the reputation data store 502 may store historical trust score data or other data used to determine a reputation value. In one example, the reputation data store 502 may store the history of each trust score and the contribution to the trust score from each node. In a more specific example, the historical data may include the number of nodes that participated in the consensus calculation, the range of scores used in the calculation, and other factors on which the consensus score is based.

[0103] In some implementations, the consensus determination module 310 can determine a candidate trust score and / or a consensus trust score based on one or more reputation values. For example, the consensus determination module 310 can determine whether a trust score is an outlier based on the reputation associated with the node. In some implementations, the consensus determination module 310 can consider the reputation value during the validation operation.

[0104] Reference Figure 6 In some implementations, the trust network 100 may implement a token economy that operates as a medium of exchange in the trust network 100. For example, a trust network node may include a utility token module 600 that implements a utility token protocol 602. The utility token protocol 602 may be powered by a token (e.g., a native utility token). The utility token may be assigned a name (e.g., a coined name). For example, the utility token may be referred to herein as a "UTOKEN," although other names may be used.

[0105] The trust network 100 includes a utility token blockchain ledger 606 that can be stored in the utility token data store 604 across nodes. The utility token ledger 606 can be a version of a public transaction ledger integrated into the trust network 100. The utility token ledger 606 can include a list of UTOKEN transactions between different utility token blockchain addresses. For example, the utility token ledger 606 can indicate various transactions associated with the node 100, such as the purchase of UTOKEN, the purchase of trust points, payments into the reward protocol, rewards paid by the reward protocol, and the amount of funds pledged by the node. The utility token ledger 606 may also include additional data, such as transaction metadata.

[0106] UTOKEN can be used in various ways on the trust network 100. In some implementations, UTOKEN can be used as payment for access to trust scores and fraud alerts. In some implementations, UTOKEN can be used to reward nodes that perform work. In some implementations, nodes can pledge UTOKEN to enable additional functions within the trust network 100. Although UTOKEN is described as a medium of exchange in the trust network 100 here, other payment types can also be used as a medium of exchange in the trust network 100. For example, other types of payments / tokens can be used to obtain trust scores, obtain fraud reports, pay rewards, and pledge. In some implementations, the utility token module 600 can implement a smart contract for the trust network 100. The communication between nodes during the implementation of the utility token protocol is shown at 601.

[0107] Initially, the trust network 100 may include a set number of UTOKEN. For example, there may be 1,000,000,000 UTOKEN initially. UTOKEN may be initially authorized and / or sold to nodes. In some implementations, the supply of UTOKEN may be expanded in a deflationary manner, which may track economic indicators including the total number of nodes, transaction volume, staked amount, and breakdown of UTOKEN tokens.

[0108] Each node may include a wallet module 614, which can be used to perform transactions on the utility token blockchain 606. The wallet module 614 can implement various functions. In some implementations, the wallet module 614 can be used to purchase trust scores. As described herein, payments for trust scores can be placed in a reward protocol. In some implementations, the wallet module 614 can be used to send / receive UTOKEN (e.g., with other nodes). In some implementations, the wallet module 614 can be used to pledge UTOKEN. In some implementations, the wallet module 614 can lock the UTOKEN, thereby indicating to the trust network 100 that the locked UTOKEN is not available for sending before unlocking. In some implementations, the wallet module 614 can be used to burn UTOKEN. Burning UTOKEN prevents the burned UTOKEN from being used for any function in the future.

[0109] The trust network 100 may implement a reward protocol for receiving payments for various activities (e.g., purchasing trust scores and purchasing fraud alerts). The trust network 100 may pay UTOKEN to a node (e.g., a node wallet) based on a variety of factors. The node includes a reward module 608 and a reward data storage 610 that implements a reward protocol. For example, the reward module 608 may receive a UTOKEN payment and pay the UTOKEN as a reward payment to the node (e.g., according to the work performed). The reward data storage 610 may store a reward ledger 616, which indicates the node receiving the reward payment and the corresponding factors associated with the reward payment (e.g., the work performed). For example, the reward ledger 616 may provide the amount of UTOKEN received by the reward protocol, the calculation of the reward, and the accounting of the amount of UTOKEN paid to different nodes in response to the calculation. The UTOKEN payment associated with the reward protocol may be stored according to one or more reward addresses on the utility token ledger 606.

[0110] The reward protocol may receive a UTOKEN from a variety of sources. For example, the reward protocol may receive a UTOKEN for purchasing a trust score report. As another example, the reward protocol may receive a UTOKEN for purchasing a fraud alert.

[0111] The reward protocol may pay out rewards to a node based on a variety of factors associated with the node. In some implementations, the reward protocol may pay out rewards to a node based on a reputation value associated with the node. The reward protocol may check one or more reputation ledgers 506 to determine a reputation value associated with a node. The reward payout calculation may be a multi-factor calculation including one or more reputation values. In some cases, reward calculations and payments may be performed periodically.

[0112] In some implementations, the reward protocol may pay rewards based on one or more work reputation values ​​indicating the amount of work performed by the node with respect to computing / communicating trust scores. The reward protocol may pay a larger portion of the reward to nodes that perform more work in computing and communicating trust scores. In some implementations, the reward protocol may pay rewards based on one or more quality / distribution reputation values ​​of the node based on the quality of the computations performed by the node. The reward protocol may pay a smaller portion of the reward to nodes that generate outlier trust scores.

[0113] In some implementations, the reward protocol may pay rewards based on one or more distributed reputation values ​​of nodes based on the distribution of consensus trust scores for requesters and the distribution of trust scores as fraud alerts. The reward protocol may pay a larger portion of the reward to nodes that distribute a larger amount of trust scores. In some implementations, the reward protocol may pay rewards based on one or more performance reputation values. For example, the reward protocol may pay a larger reward to nodes with greater bandwidth, processing power, throughput, and availability.

[0114] In some implementations, the reward protocol may pay rewards based on one or more data storage reputation values. For example, the reward protocol may pay larger rewards to nodes that store more data. In some implementations, the reward protocol may pay rewards based on one or more reputation values ​​indicating the amount of time a node has been included (e.g., online) in the trust network 100. For example, the reward protocol may pay larger rewards to nodes that have been online in the trust network 100 for a longer period of time. In some implementations, the reward protocol may pay rewards based on one or more pledge reputation values. For example, the reward protocol may pay larger rewards to nodes that have more UTQKEN pledged.

[0115] In some implementations, algorithm providers can be rewarded in UTOKEN for providing nodes that contribute algorithms to the ecosystem. In some implementations, proof of work consensus algorithms can be used to verify the UTOKEN ledger. Proof of work providers can receive UTOKEN as block rewards to incentivize their participation in the ecosystem. Communication between nodes during the implementation of the reward protocol is shown at 603.

[0116] Figure 7 An example method describing the operation of a reward protocol is shown. In block 700, the reward protocol receives payment for trust scores and fraud alerts. In block 702, the reward protocol retrieves reputation values ​​for a plurality of nodes. In block 704, the reward protocol determines a reward payout to a plurality of nodes based on the reputation values ​​associated with the nodes. In block 706, the reward protocol pays the nodes according to the determined payout. In block 708, the reward protocol updates the reward ledger 616 to reflect the payment calculation (e.g., based on the reputation value) and the payment amount. The reward protocol may be repeated periodically. Figure 7 The method allows nodes to be periodically rewarded for their relative contributions to the trust network 100.

[0117] The trust network 100 may implement a pledge protocol in which each node may pledge a certain amount of UTGKEN (e.g., using a pledge module 612). The amount of pledged UTOKEN may determine the level of functionality provided to the node. The pledged UTOKEN may be reflected in the utility token ledger 606.

[0118] The pledged UTOKEN may be under the temporary control of the trust network 100. For example, in some implementations, the reward protocol may punish the node by removing the pledged UTOKEN. In some implementations, the pledge function may be implemented as a smart contract, wherein violation of the contract results in the surrender (e.g., burning) of some pledged UTOKEN. In these implementations, the performance of the smart contract results in the UTOKEN being returned to the pledger. In some implementations, if the outlier score is determined to be fraudulent, the reward protocol may punish the node used to generate the outlier trust score.

[0119] In some implementations, when a network participant pledges a certain amount of UTOKEN (e.g., a required amount), a node can be formed. The amount of UTOKEN pledged by the node can determine the amount of functions that the node can implement. For example, pledging more UTOKEN allows the node to implement a larger amount of network functions. In these cases, nodes can be assigned different functional levels. Lower-level nodes may have functions limited to requesting trust scores. Higher-level nodes may participate in calculating local trust scores, candidate trust scores, and consensus trust scores. There may be any number of node levels that can perform any number of services on the trust network 100. If the trust network punishes a node and burns the node's pledge, the node may drop in level and lose the corresponding function. Communication between nodes during the implementation of the pledge agreement is shown at 605.

[0120] In some implementations, the cost required by a node to pay for a trust score may decrease as the amount of UTOKEN staked by the node increases. In these cases, the more UTOKEN a node stakes, the fewer UTOKENs are required to obtain a trust score (e.g., via real-time reporting). An example relationship between staked UTOKEN and consensus trust score cost is shown in Fig. 10A In one specific example, in order to be eligible for a discount, it may be necessary to stake the UTOKEN for a period of time (e.g., at least 90 days).

[0121] Figures 8A-8B An example GUI is shown that may be generated by a trading application 116 or an intermediary trading system 104 on a user trader device 102. The GUI shown may be used by a sender in a cryptocurrency transaction. It may be assumed that Figures 8A-8B The cryptocurrency network in which blockchain transactions occur uses "coin" units for transactions. The top of the GUI includes fields indicating information of the sender, such as the sender's blockchain address and their balance (e.g., 10 coins). The top of the GUI also includes fields in which the sender can specify the recipient address and indicate the transaction amount of the potential transaction (e.g., 5 coins). The GUI includes a "Send Coins" GUI element that can initiate a specified transaction between the sender and the receiver.

[0122] Figures 8A-8B The lower portion of the GUI provides the sender with the option to obtain a trust report from the trust network 100 before conducting a transaction. Fig. 8A , the user may select (e.g., touch / click) a “Request Trust Report” GUI element to send a trust request to the trust network 100. The trust request may include the address of the recipient, as specified in the “To:” box above. Figure 8B An example trust report received in response to a trust request is shown.

[0123] exist Figure 8B , the received trust report indicates that the recipient has a trust score of -.90. In this case, it can be assumed that a negative trust score close to -1.0 indicates that the recipient address is likely to be fraudulent. Similarly, a positive trust score close to 1.0 can indicate that the recipient address is unlikely to be fraudulent in addition to the numerical score of -0.90, and the trust report also summarizes the meaning of the trust score numerical value. Specifically, the trust report indicates that "the trust score indicates that the recipient may be involved in fraudulent activity." The GUI also provides a "Cancel Transaction" GUI element that the sender can select (e.g., touch / click) to cancel the specified transaction.

[0124] In some implementations, the sender may be charged the amount for requesting the consensus trust score. In implementations where the sender transacts via an exchange, the exchange may spend UTOKEN in a reward protocol to retrieve the consensus trust score. In implementations where the sender does not interact via an intermediary transaction system 104, the sender may purchase UTOKEN from the trust network 100 for obtaining the consensus trust score.

[0125] Fig. 9 An example of querying the trust network 100 as part of a payment insurance process is shown. Fig. 9 In the example, the user trader device 102 conducts transactions on the cryptocurrency blockchain network 118 via the intermediary transaction system 900. The intermediary transaction system 900 includes a trust request module 126 that can retrieve trust reports from the trust network 100. The intermediary transaction system 900 can also provide payment insurance to traders.

[0126] Fig. 9 The intermediary transaction system 900 includes a payment insurance module 902 that can determine whether a transaction will be insured. The owner / operator of the intermediary transaction system 900 and the owner / operator of the payment insurance system 904 (e.g., an insurer system) can agree to the terms under which the transaction is insurable. In some implementations, payment insurance can be provided for transactions in which the transaction blockchain address has a trust score indicating a low likelihood of fraud. The payment insurance system 904 can obtain data related to the transaction (e.g., trust score, timing, etc.) for audit purposes.

[0127] exist Fig. 9 In the example embodiment, initially, the trader device 102 may initiate a transaction with the intermediary transaction system 900. In response to the initiated transaction, the intermediary transaction system 900 (e.g., the trust request module 126) may retrieve a trust report of the recipient and / or sender. The intermediary transaction system 900 may then determine whether the transaction is insurable. For example, the payment insurance module 902 may determine whether the transaction blockchain address has a trust score indicating a low likelihood of fraud. In some implementations, the payment insurance module 902 may compare the consensus trust score with a trust score threshold indicating a maximum tolerable likelihood of fraud. In these implementations, if the consensus trust score is less than the trust score threshold, the payment insurance module 902 may indicate that the transaction is insurable. If the consensus trust score is greater than the tolerable level of fraud, payment insurance may be denied.

[0128] In some implementations, the payment insurance module 902 may query the payment insurance system 904 to determine whether the transaction is insurable. The query may indicate the consensus trust scores of the transaction parties. In these implementations, the payment insurance system 904 may determine whether to insure the transaction. The payment insurance system 904 may then notify the intermediary transaction system 900 whether the transaction is insurable.

[0129] In addition to the trust network 100 playing a role in the payment insurance process, the trust network 100 can also play a role in other financial processes. For example, the trust score / report generated by the trust network 100 can be used to freeze transactions and / or recover funds.

[0130] Trust network 100 may include any number of nodes. As described herein, nodes 100 may have different levels of functionality (e.g., based on pledge). The level of a node may be variable, and different node levels may be eligible to participate in different services. Fig. 10B Example services associated with three different levels of nodes are shown.

[0131] In some implementations, a level 1 node may pledge a minimum amount of UTOKEN,X for a period of time (e.g., at least 90 days). In some implementations, a level 1 node may perform all node activities. In addition to performing updates to trust scores and participating in real-time reporting, level 1 nodes may also participate in trust score processing and trust arbitration, collect and verify evidence of fraud and custody, and send trader fraud alerts. In some implementations, level 1 nodes may be the most important nodes. In some cases, in order to maintain the security of the trust network, there should be a minimum number of level 1 nodes (e.g., 100 level 1 nodes). A decentralized autonomous organization (DAO) may include a command to run additional level 1 nodes if the minimum value is not met.

[0132] In some implementations, a Level 2 node may stake a minimum amount of UTOKEN (e.g., proportional to X / 2) for a period of time (e.g., at least 90 days) to perform trust score updates and participate in trust arbitration. Level 2 nodes may additionally update the UTOKEN ledger, add custody evidence to the blockchain, and deliver fraud alerts. Level 3 nodes may stake a minimum amount of UTOKEN (e.g., proportional to X / 5) for a period of time (e.g., at least 90 days) to verify fraud and custody evidence.

[0133] Trust report requests may be stored in a node's transaction storage pool for processing and prioritization. Each node level may have a separate transaction storage pool. For example, in some implementations, level 3 nodes may not store report requests. However, level 1 may store report requests (e.g., state channel updates). In some implementations, nodes involved in fraud and custody verification may use separate storage pools for these purposes.

[0134] Nodes can receive rewards for performing services. For example, a node can receive rewards proportional to its level. When cryptocurrency traders access trust scores, UTOKEN can be split between rewarded nodes. Additionally, when protecting blocks in the utility token blockchain, nodes can receive a percentage of mining rewards (e.g., 45%).

[0135] The node level can have a corresponding reward queue. The amount of mining rewards received by each node (e.g., 45% of the mining rewards) can be proportional to the amount they staked (e.g., node level). When a node joins the trust network 100, it can be placed at the bottom of the queue, and as long as it actively provides services (e.g., service proof) on the trust network 100, it can queue up. When it reaches the top of the queue (e.g., the top 10%), it is eligible for reward selection. In a specific example, the probability of random selection can be 1 / n, where n is the number of nodes in the top 10% of the queue.

[0136] In a specific implementation, the target par value of the cost of node service may be 1UTOKEN, while the par value of node income may be 1.2UTOKEN. In this specific implementation, the consensus trust score price is set higher than the cost of helping to ensure rewards to the node.

[0137] A node contribution program may enable nodes to jointly develop algorithms for consensus trust scores. The program may be a contribution path that allows nodes to better assign the accuracy of algorithms (e.g., prediction algorithms) for trust scores. The program may allow the network to evolve to best suit new use cases and development on the blockchain. Rewards for contributors may be controlled by the DAO through a bounty program.

[0138] The utility token protocol can be governed by a DAO. The DAO allows the protocol to keep up with new developments. Participants can vote in the DAO using UTOKEN. The DAO can be funded with an endowment (e.g., 5%) of the initial token supply, and if the number of level 1 nodes falls below a set number (e.g., 100), the DAO can use DAO funds to run the minimum required nodes, and the DAO can receive a percentage of mining rewards (e.g., 10% of each mining reward).

[0139] The DAO can determine protocol updates, including adjusting supply coefficients, setting boundaries for updating protocols, improving or adjusting existing integrations with partners, and accepting work when completed. The DAO can allocate and reward this bounty program. If a malicious actor attempts to exploit the trust network 100, a bug bounty for the algorithm can be opened to address that specific pattern, thereby strengthening the entire ecosystem. The DAO can additionally approve changes to open source bot software.

[0140] The DAO can control key system variables, including the number of UTOKEN staked at each node level, the staking period, and the cryptocurrency trader discount for each staked amount.

[0141] The correct proportion of node staking allows for a healthy token economy. The DAO can modify the protocol to ensure there are enough UTOKEN in circulation to facilitate transactions and enough staking to promote a healthy and balanced token velocity. Fig. 10D Sample UTOKEN stake amounts and number of level 1 nodes are shown. For example, a graph may depict sample node counts when between 35% and 50% of UTOKENs are in circulation.

[0142] Nodes can divide the work of updating trust scores into groups based on the organic underlying graph topology of the blockchain. Groups can then be assigned to nodes to update and report. Dividing the graph into groups prevents individual nodes from having full access to all trust data. This protects the integrity of the token economy while maintaining a complete graph. There may be overlap of addresses within a group. As the number of nodes increases, group overlap may increase.

[0143] Fig. 10C The table of shows an example relationship between the number of nodes, the number of cliques, address overlap, and the probability that a node will obtain a single address in its control. Here, the overlap can be proportional to the number of nodes. The security of the trust network 100 can be proportional to the number of nodes on the trust network 100. The maximum probability of a node obtaining a specific address is 5%, with a minimum of 5 overlapping addresses per clique.

[0144] The probability of a node obtaining a single address can be determined by the following formula: P(address A)=(number of clusters with address A) / (total number of clusters).

[0145] However, the probability of gaining control of a specific address can be different from the probability of gaining control of any address. If a participant has only one node, then the participant cannot gain control of a single address because other nodes also contain that address in their clique.

[0146] The high cost of becoming a node may be one way the network protects against Sybil attacks. Because clique placement may be pseudo-random, in some cases a malicious actor would have to control an average of 51% of the nodes to have 51% control over a single address.

[0147] The hypergeometric distribution described below can be used to calculate the probability of a node randomly obtaining 51% control of a single address or any address.

[0148] N = number of nodes

[0149] B = Wrong node (the node that wants to control the address)

[0150] O = Overlap

[0151] C=51% of the number of control nodes=(O / 2)+1

[0152]

[0153] The more nodes there are, the higher the cost of UTOKEN and the harder it is to attack. For the base case of 100 nodes with 5 overlaps, the probability of obtaining 51% control of an address can be:

[0154]

[0155] The probability becomes 1.7e-10 when the number of cliques increases to 1,000 and the overlap increases to 50. The probability of a 51% attack to control the trust score of any single address approaches 0 as the number of nodes and cliques increases.

[0156] Fig.11 is an example detailed functional block diagram of a trust score determination module 300 (hereinafter referred to as “trust module 300 ”) and a local trust data store 302 . Fig.12 is a method describing the operation of the trust module 300. Fig.11, the trust module 300 obtains and processes various data described herein. The processed data may be included in the local trust data store 302. The data associated with a single cryptocurrency blockchain address is shown herein as a blockchain address record 304. The record data store 1110 may include a plurality of such blockchain address records 304, each corresponding to a different blockchain address. Each blockchain address record 304 may include a blockchain address 306 that uniquely identifies the record. The blockchain address records 304 described herein represent data stored in the local trust data store 302. The local trust data store 302 may include a variety of different data structures for implementing the data. Therefore, the blockchain address record 304 may be implemented using one or more data structures different from those explicitly described herein.

[0157] Fig.12 Is a description Fig.11 The method of operation of the trust module 300 is shown. In block 1200, the data acquisition and processing module 1100 acquires and processes various types of data 124, such as custody data and fraud data (see, for example, Fig.13 ). The data acquisition and processing module 1100 may store custody and fraud data 1118 associated with the blockchain address in the blockchain address record 304. The data acquisition and processing module 1100 may also generate a fraud tag 1120 based on the acquired fraud data, the fraud tag 1120 indicating whether the blockchain address is likely to be fraudulent.

[0158] In block 1202, the blockchain acquisition and processing module 1102 acquires and processes blockchain data (e.g., blockchain ledger 122) (e.g., see Fig.14 ). The blockchain acquisition and processing module 1102 may store the raw and processed blockchain data 1122 associated with the blockchain address in the blockchain address record 304. In block 1204, the graph generation and processing module 1104 generates a blockchain graph data structure based on the blockchain data (e.g., see Figures 15A-15B ). The blockchain graph data structure may be stored in the graph data store 1112. The graph generation and processing module 1104 may also process the graph to determine one or more graph-based values ​​1124 (e.g., importance values) that may be used to generate a local trust score.

[0159] In block 1206, the feature generation module 1106 generates a feature for a blockchain address (e.g., see Fig.16) generates scoring features 1126. In block 1208, the scoring model generation module 1108 generates one or more scoring models based on the scoring features and other data (e.g., the labeled fraud data). The one or more scoring models may be stored in the scoring model data store 1114. In block 1210, the score generation module 1116 generates a scoring model using the one or more scoring models and the scoring features associated with the blockchain address (e.g., see Fig.17 ) to generate one or more local trust scores 308 for the blockchain address. Data related to the request and response of the consensus trust score can be stored as the request data 1128 of the blockchain address record 304.

[0160] Reference now Figure 13-15A and Figure 16-17 A detailed example of a trust module 300 and a local trust data store 302 is described. For illustrative purposes, various modules and data stores are omitted in the figure. For example, various modules and data stores have been omitted to focus on the functions associated with the modules and data stores shown.

[0161] Fig.13 Data acquisition and processing for fraud and custodial data sources are shown. Fig.14 The acquisition and processing of blockchain data is shown. Figures 15A-15B Illustrate the generation and processing of blockchain graph data structures. Fig.16 Scoring feature generation and scoring model generation are shown. Fig.17 Generating a local trust score for a blockchain address using a scoring model and scoring features for the blockchain address is shown.

[0162] See also Fig.13 , the data acquisition and processing module 1100 includes a data acquisition module 1100-1 that acquires data from the fraud and custody data source 124. The data acquisition and processing module 1100 also includes a data processing module 1100-2 that processes the acquired data. The raw and processed data 1118 can be stored in the record data storage 1110. The data acquisition module 1100-1 can acquire data in a variety of ways. In some implementations, the data acquisition module 1100-1 can acquire planning data, such as planning / purchasing data provided by partners / customers. In some cases, the data can be structured data that is checked by users peers.

[0163] In some implementations, the data acquisition module 1100-1 can be configured to automatically acquire data (e.g., crawl / scrape a website). For example, the data acquisition module 1100-1 can be configured to perform targeted data acquisition, such as acquiring data for a specific social media account. As another example, the data acquisition module 1100-1 can perform more general data acquisition, such as more general site crawling / scraping.

[0164] The data acquisition module 1100-1 can obtain custody data from the custody data source 124-1. The custody data can indicate a party that owns / controls a blockchain address (e.g., a key). Example parties that can custody a blockchain address can include, but are not limited to, exchanges, wallets, and banks. In some implementations, the custody source 124-1 can provide the custody data.

[0165] In some implementations, the trust module 300 may implement custodian-specific trust score generation. For example, the trust module 300 may select a particular scoring model based on the custodian associated with the blockchain address. In some implementations, the trust module 300 may implement client / custodian specific reporting for blockchain addresses (e.g., based on the custodian associated with the blockchain address). For example, a trust report may be formatted in a particular manner for a particular custodian.

[0166] The data acquisition module 1100-1 acquires data that can provide evidence of fraud from various fraud data sources 124-2. The trust module 300 can determine the fraud probability of the blockchain address based on the fraud data. For example, the trust module 300 can mark the blockchain address as fraudulent based on the fraud data. Subsequently, the trust module 300 can generate a scoring feature and a scoring model based on the marked blockchain address.

[0167] In some implementations, the trust module 300 may be configured to obtain databases and lists indicating fraudulent activity associated with a blockchain address. In one example, the fraud data source 124-2 may include a database of fraud information, such as a third-party database of fraud information and / or a database of fraud information provided by a customer. The database may be provided by a public entity (e.g., a government watch list) and / or a private entity (e.g., a company-generated watch list).

[0168] In some examples, a database of fraud information may be provided in the form of a blacklist that includes a list of blockchain addresses that have been identified as being involved in fraud. In this example, the data acquisition module 1100 may acquire a public blacklist, purchase a blacklist, and / or receive a blacklist from a client. In some cases, the blacklist may have been peer-checked by a group of trusted parties (e.g., experts). In some implementations, if an address is included on a blacklist, the data processing module 1100-2 may mark the address as fraudulent. In other implementations, the presence of a blockchain address on a blacklist may be used as a scoring feature for determining whether a blacklisted blockchain address may be fraudulent.

[0169] In some implementations, the data acquisition module 1100-1 can be configured to obtain fraud data from a target location, such as a location on the Internet specified by a network uniform resource locator (URL) and / or a username (e.g., a specific social media account). In some implementations, a location (e.g., a network URL) can be provided where the data acquisition module 1100-1 can monitor fraudulent activities. For example, a client can provide a network address to a social media page associated with a specific blockchain address. In this example, if a blockchain address other than the specified blockchain address appears at the network address in the network content, the data processing module 1100-2 can identify fraudulent behavior. In another example, if there is a known contribution address for an initial coin offering (ICO), accounts and blockchain addresses that fraudulently attempt to obtain funds (e.g., phishing) can be detected. The trust network 100 can notify the user of the fraudulent address and use evidence of the fraudulent activity described herein.

[0170] While the data acquisition module 1100-1 can be configured to acquire fraud data from a target location, in some implementations, the data acquisition module 1100-1 can generally crawl and scrape other data sources (e.g., social media sites) for fraud data and other data. In these examples, the data processing module 1100-2 can identify fraudulent blockchain addresses based on behavior across social media platforms, such as scams that request funds from multiple social media users, new accounts that directly solicit funds from other users, and scams that offer fake initial coin offerings.

[0171] In some implementations, the trust module 300 (e.g., the data processing module 1100-2) may mark the blockchain address as fraudulent (e.g., at 1120). For example, the data processing module 1100-2 may mark the blockchain address as fraudulent based on the fraud data. In a specific example, if the blockchain address is included in one or more blacklists, the data processing module 1100-2 may mark the blockchain address as fraudulent. If the blockchain address is not marked as fraudulent, the fraud status of the blockchain address may be unknown. In other words, an unmarked blockchain address does not necessarily indicate that the blockchain address is not fraudulent. In some cases, a blockchain address may be marked as a known good address that is not fraudulent. For example, an exchange wallet or a verified smart contract may be an example of a known good address.

[0172] For blockchain addresses that are assigned one or more trust scores and are marked as fraudulent, the fraud label of the blockchain address can play a decisive role in the issue of fraud of the blockchain address. Likewise, in these implementations, the trust module 300 can ignore the trust score of the blockchain address and / or set the trust score of the blockchain address to 100% fraud certainty. In other implementations, the trust module 300 can continue to calculate the trust score of the blockchain address marked as fraudulent.

[0173] The fraud tag 1120 may also include fraud tag metadata. The fraud tag metadata may indicate the source of the information used to mark the blockchain address as fraudulent (e.g., a specific blacklist). The fraud tag metadata may also indicate the type of fraud (e.g., a phishing scam). The fraud tag metadata may also include the content of the fraudulent behavior, such as text associated with the scam (e.g., text posted online or in an email). The trust module 300 may return the fraud tag metadata to the requesting device to clearly explain why the trust module 300 marked the blockchain address as fraudulent.

[0174] See also Fig.14 , a blockchain data acquisition module 1102-1 (hereinafter referred to as “blockchain acquisition module 1102-1”) may acquire blockchain data from the blockchain network 118. For example, the blockchain acquisition module 1102-1 may acquire a blockchain transaction ledger 122. The blockchain acquisition module 1102-1 may store raw blockchain data 1122 in the record data storage 1110. The blockchain processing module 1102-2 may process the blockchain transaction ledger 122 and store processed blockchain values ​​1122 (e.g., transaction amount, dormancy, etc.) in the record data storage 1110 (e.g., in the blockchain address record 304).

[0175] The blockchain transaction ledger 122 includes data for multiple blockchain transactions. Each transaction may include: 1) a sender address, 2) a recipient address, and 3) a value amount (e.g., a coin amount). The transaction may also include transaction identification data that uniquely identifies the transaction on the blockchain. The transaction identification data may be referred to herein as a transaction identifier (ID). In some implementations, a transaction hash may be used as a unique identifier for a transaction. The transaction hash may be a pseudo-random string that uniquely identifies a transaction. Some blockchains may also include additional data that may be stored and processed. Exemplary additional data may include internal transaction data, such as a program executed in an Ethereum smart contract.

[0176] A blockchain transaction ledger may include multiple blocks. Each block may include a collection of transactions. A block may include a collection of transactions that occurred on the blockchain within a specific time period. A block may include a block number (e.g., a sequentially assigned number) that may serve as an identifier for the block. In the case of cryptocurrency, a transaction may include a sender address, a receiver address, an amount sent, and various parameters describing the speed. Ethereum may include similar transaction data, as well as raw data surrounding the execution of a function on a smart contract in the case of an execution function.

[0177] Different blockchain networks may include different types of blockchain ledgers. For example, different blockchain ledgers may include blockchain transaction data in different formats. As another example, different blockchain ledgers may include additional or alternative data associated with a transaction. The blockchain acquisition module 1102-1 may be configured to acquire blockchain transaction data for different blockchains. For example, the blockchain acquisition module 1102-1 may include different modules, each of which may be configured to acquire blockchain transaction data for different blockchain networks.

[0178] In some cases, the blockchain network may include timing data indicating the time (e.g., relative / absolute time) of blockchain transactions. In these implementations, the blockchain acquisition module 1102-1 may use the provided timing data to indicate when a transaction occurred. In other cases, the blockchain network may not include timing data. In these implementations, the blockchain acquisition module 1102-1 may generate a timestamp for the transaction. In some cases, the timing data may be generated from the block assigned to the transaction. Blocks may be assigned as part of a mining process whereby actors on the blockchain compete to verify the validity of a set of transactions. Once a block is mined and a transaction is verified, the timing data may be assumed from the consensus of other miners.

[0179] The blockchain processing module 1102-2 may determine various values ​​based on the acquired blockchain data. The trust module 300 (e.g., the score generation module 1116) may use the determined values ​​as scoring features for determining a trust score. The trust module 300 (e.g., the model generation module 1108) may also generate a scoring model based on the determined values. The blockchain value for the blockchain address may be stored in a blockchain address record (e.g., at 1122).

[0180] The blockchain processing module 1102-2 may include functionality for determining the various blockchain values ​​described herein. For example, Fig.14 The blockchain processing module 1102-2 includes a dormancy determination module 1400 that can determine a dormancy value of a blockchain address. The blockchain processing module 1102-2 also includes a behavior identification module 1402 that can determine whether the blockchain address matches one or more behavior templates (e.g., patterns or fingerprints). Fig.14 The modules 1400 and 1402 in the blockchain processing module 1102-2 are only example modules. Similarly, the blockchain processing module 1102-2 may include Fig.14 Additional / alternative modules to those shown in . In addition, included in Fig.14 The blockchain values ​​in the blockchain data 1122 of are only example values. Similarly, the blockchain data of the blockchain address may include additional / alternative values

[0181] In some implementations, the blockchain processing module 1102-2 may determine a value associated with the amount of funds transacted by the blockchain address. For example, the blockchain processing module 1102-2 may determine: 1) the total amount of funds received by the blockchain address, 2) the total amount of funds sent by the blockchain address, 3) the total amount of funds transacted to and from the blockchain address, and 4) the average transaction amount of the blockchain address.

[0182] In some implementations, the blockchain processing module 1102-2 may determine a value associated with the timing of transactions associated with the blockchain address. For example, the blockchain processing module 1102-2 may determine the activity level of the blockchain address, such as how frequently the address participates in transactions (e.g., the average time and variance between transactions). As another example, the blockchain processing module 1102-2 may determine the age of transactions associated with the address. Another example scoring feature related to timing may include the time between funds entering and exiting funds from the blockchain address (e.g., the timing of a single transaction or the average of multiple transactions). In some cases, fraudulent activity may not exit the address immediately.

[0183] As another example, the dormancy determination module 1400 can determine a dormancy probability for a blockchain address. An example dormancy probability can indicate an amount of time that a blockchain address is not associated with a transaction. For example, the dormancy probability can indicate an amount of time that a blockchain address is not associated with a transaction relative to an expected time between transactions for the address. Put another way, an example dormancy time can indicate a probability that a blockchain address is dormant. With respect to dormancy probability, in some cases a fraudulent address may not remain active for a long time.

[0184] In some implementations, the blockchain processing module 1102-2 can determine values ​​associated with the timing and transaction amount of transactions. For example, the blockchain processing module 1102-2 can determine: 1) the total amount of funds received in a period of time, 2) the total amount of funds transferred in a period of time, and 3) the total amount of funds traded in a period of time.

[0185] In some implementations, the blockchain processing module 1102-2 may determine a value associated with how the blockchain address interacts with other blockchain addresses. For example, the blockchain processing module 1102-2 may determine a list of addresses that have interacted with the blockchain address and / or a total number of addresses that have interacted with the blockchain address (e.g., as a sender and / or a receiver). The value may be calculated iteratively to determine how important the address is to its local neighborhood and to the blockchain as a whole.

[0186] The blockchain processing module 1102-2 includes a behavior identification module 1402 that can determine whether the blockchain address matches a specific behavior template that can indicate fraud. If the behavior identification module 1402 identifies a match between the behavior of the blockchain address and the behavior template, the match can be stored in the blockchain address record 304. In some implementations, the local trust data store 302 can store a set of behavior templates. In these implementations, the behavior identification module 1402 can determine whether the behavior of the blockchain address matches one or more of the set of behavior templates.

[0187] A behavior template may include a set of conditions that, if met, cause the behavior template to match a blockchain address. A behavior template may include conditions based on any blockchain value described herein. For example, a behavior template may include conditions based on at least one of: 1) the amount of funds transferred, 2) the number of transactions, 3) the timing of transactions (e.g., transaction rate), 4) how the blockchain address interacts with other addresses (e.g., the number of different senders / receivers and patterns of transactions), and 5) the likelihood of an address being dormant.

[0188] In one specific example, a behavior template may define a threshold number of transactions (e.g., 5 transactions in and out) at a threshold rate. In this example, if a blockchain address participates in a small number of transactions (e.g., less than or equal to the threshold number) in rapid succession (e.g., a short, fast burst), the behavior template may be matched. Another example condition for a behavior template may be a high probability of dormancy, as any transaction may be limited to a burst. In another specific example, a behavior template may define a high threshold number of transactions (e.g., a non-regular high for a blockchain). In this example, if a blockchain address participates in transactions greater than a threshold number, the behavior template may be matched. In this example, the behavior template may also require a high importance value, requiring the blockchain address to have a minimum importance value to match the template. Additionally, the behavior template may require a low probability of dormancy, as fraudulent behavior may follow the pattern of regular transactions.

[0189] If the blockchain address matches the behavior template, the match may be stored as a blockchain value in the blockchain address record 304. For example, the blockchain address record may store a binary value (e.g., 0 / 1) for each behavior template that indicates whether the behavior template matches. In implementations where the behavior identification module 1402 determines a value (e.g., a decimal or integer value) indicating how well the blockchain address matches the behavior template, the value may be stored in the blockchain address record 304.

[0190] See also Figures 15A-15B , the graph generation module 1104-1 generates a blockchain graph data structure based on blockchain transactions of multiple different blockchain addresses. The graph data structure includes blockchain addresses and transactions between blockchain addresses. For example, for each blockchain address, the graph data structure may describe each transaction associated with the blockchain address and the direction of the transaction, such as whether the blockchain address is a sender or a receiver. The graph data structure may also include the transaction amount of each transaction. In some implementations, the graph data structure may include fraud data (e.g., a fraud tag). The fraud tag may indicate that the address has been involved in a fraudulent activity (e.g., is a known fraudulent address).

[0191] Fig. 15B An example representation of a graph data structure is shown. Fig. 15B In the graph data structure, nodes and edges are represented. The graph data structure includes blockchain addresses as nodes of the graph. Transactions between blockchain addresses are edges between nodes, where arrows indicate the direction of the transaction (e.g., the recipient is at the arrow). The amount of each transaction is marked next to the arrow. A fraud label for each blockchain address is included above the node. Fig. 15B There are 4 traders with blockchain addresses A, X, Y, and Z. Blockchain address Y has been marked as a fraudulent address. The other blockchain addresses have unknown fraud status. The figure shows 3 blockchain transactions. The first transaction is from blockchain address X to blockchain address A for a first amount (i.e., amount 1). The second transaction is from blockchain address Y to blockchain address A for a second amount (i.e., amount 2). The third transaction is from blockchain address A to blockchain address Z for a third amount (i.e., amount 3).

[0192] The graph data structure is stored in the graph data store 1112. The graph generation module 1104-1 can update the graph data structure over time so that the graph data structure includes the latest representation of the transactions included on the blockchain network 118.

[0193] The graph processing module 1104-2 may use the graph data structure to generate a graph-based value 1124. The graph-based value 1124 may be stored in the blockchain address record 304. The graph processing module 1104-2 may update the graph-based value 1124 over time.

[0194] In some implementations, the graph processing module 1104-2 may determine one or more importance values ​​for each blockchain address. The importance value may indicate the importance of the blockchain address relative to other blockchain addresses (e.g., relative to all blockchain addresses). In some implementations, the graph processing module 1104-2 may determine the importance value of the blockchain address based on neighboring blockchain addresses. In some implementations, the graph processing module 1104-2 may weight the contribution of neighboring blockchain addresses by the importance of the blockchain address.

[0195] In some implementations, the graph processing module 1104-2 may determine the importance value by counting the number of transactions entering the blockchain address. In this particular example, more transactions may indicate that the blockchain address is more important than other blockchain addresses with fewer incoming transactions. In some implementations, the graph processing module 1104-2 may determine the importance value by determining the number of different blockchain addresses that the blockchain interacts with. In some implementations, the graph processing module 1104-2 may determine an importance value indicating the total amount of funds entering the blockchain address relative to the amount of funds leaving the address (e.g., the amount leaving divided by the amount entering). In another example, the graph processing module 1104-2 may determine an importance value indicating the number of transactions entering the blockchain address relative to the number of transactions leaving the blockchain address (e.g., the total number of transactions entering divided by the total number of transactions leaving). In another example, the graph processing module 1104-2 may determine the importance value based on the number of transactions entering the blockchain address, the number of transactions leaving the blockchain address, the amount of funds entering, and the amount of funds leaving. In some implementations, the graph processing module 1104 - 2 may implement other processing techniques, such as PageRank (PR) and / or personalized hit time (PHT).

[0196] In some implementations, the graph processing module 1104-2 may determine a fraud distance score feature that indicates the distance of the blockchain address from fraud in the graph. For example, the fraud distance score feature may include a minimum distance from fraud, an average distance from fraud, and / or a number of fraudulent blockchain addresses with which the blockchain address has interacted.

[0197] refer to Fig.16 , the feature generation module 1106 can generate a scoring feature for each blockchain address. The trust module 300 (e.g., the score generation module 1116) can generate one or more local trust scores for the blockchain address based on the scoring features associated with the blockchain address. The scoring features can be numerical values ​​(e.g., integers or decimal values), Boolean values ​​(e.g., 0 / 1), enumerated values, or other values.

[0198] The feature generation module 1106 can generate scoring features based on any blockchain value described herein. For example, a scoring feature for a blockchain address can be based on 1) a volume associated with a transaction, 2) timing data associated with a transaction (e.g., dormancy), 3) a graph-based value associated with the blockchain address (e.g., one or more importance values), and / or 4) behavior-based data associated with the blockchain address.

[0199] For behavior-based data, the feature generation module 1106 may generate a Boolean scoring feature indicating whether the blockchain address matches any of the behavior templates. In another example, the feature generation module 1106 may generate a Boolean scoring feature for each behavior template, such that the scoring feature identifies which behavior templates are matched. In another example, the feature generation module 1106 may generate a scoring feature indicating how many behavior templates are matched (e.g., a total available percentage). In another example, instead of generating a Boolean feature, the feature generation module 1106 may generate a numerical value indicating how well the blockchain address matches the behavior template, such as a decimal value (e.g., 0.00-1.00) indicating how well the behavior template matches.

[0200] Trust module 300 includes scoring model generation module 1108 (referred to herein as “model generation module 1108”), which can generate scoring model 1800 for generating a local trust score for a blockchain address. For example (see, e.g., Fig.17 ), the scoring model may receive the scoring features of the blockchain address and output a local trust score for the blockchain address. The model generation module 1108 may generate a scoring model based on the training data. The training data may include scoring features and associated fraud labels. The set of scoring features used as input by the model may be referred to as a "feature vector" in this article. In some implementations, the trust module 300 may use a deep neural network for scoring, where the classification is determined by known good / bad addresses. The neural network can be trained on the feature vector. In some implementations, the trust module 300 may utilize models based on random forests, decision trees, and logistic regression, and combine them in the form of "expert consensus".

[0201] The model generation module 1108 can generate a scoring model (e.g., a machine learning model) based on the training data, which includes a set of feature vectors and their corresponding fraud labels (e.g., fraud: 0 / 1). In this example, the generated scoring model can output a local trust score (e.g., a decimal value) indicating the likelihood that the blockchain address is fraudulent. In some implementations, the training data can also include a label that positively indicates that the blockchain address is a known good address (e.g., non-fraudulent).

[0202] Although the trust module 300 can generate a scoring model for generating a local trust score, the trust module 300 can generate the local trust score in other ways. For example, the trust module 300 can generate the local trust score using a scoring function (e.g., a weighted scoring function) and / or a heuristic model that generates a local trust score according to a rule.

[0203] Fig.17 An example score generation module 1118 is shown that generates a local trust score for a blockchain address. The score generation module 1116 can generate a local trust score for a blockchain address by using a feature vector of the blockchain address and a scoring model. For example, the score generation module 1116 can input the feature vector of the blockchain address into a scoring model that outputs a local trust score.

[0204] The local trust score 308 for the blockchain address can be stored in the blockchain address record 304. The score generation module 1116 can generate a local trust score for each blockchain address. The score generation module 1116 can also update the local trust score over time, such as when additional data is acquired. The blockchain address record 304 may include the most recently calculated local trust score as well as the historically calculated local trust score. In some implementations, the trust module 300 can use changes in the local trust score (and historical scores) to provide a real-time alert system so that if the trust score of an address drops (e.g., in the case where an organization receives fraudulent funds through an address it controls), a party can be notified. The trust module 300 can provide an API that can be hooked into its service, which can freeze transactions and alert relevant personnel at the organization (e.g., by phone, email, etc.).

[0205] The score generation module 1116 can be configured to provide a local trust score in various formats. In some implementations, the local trust score can be an integer value with a minimum and maximum value. For example, the local trust score can be in the range of 1-7, where a trust score of '1' indicates that the blockchain address is likely to be fraudulent. In this example, a trust score of '7' can indicate that the blockchain address is unlikely to be fraudulent (i.e., very trustworthy). In some implementations, the local trust score can be a decimal value. For example, the local trust score can be a decimal value indicating the likelihood of fraud (e.g., a percentage value from 0-100%). In some implementations, the local trust score can range from a maximum negative value to a maximum positive value (e.g., from -1.00 to 1.00), where a larger negative value indicates that the address is more likely to be fraudulent. In this example, a larger positive value can indicate that the address is more likely to be trustworthy. Customers can select the trust score format they prefer.

[0206] In some implementations, the blockchain address record 304 may store request data 1128 for each trust request. The request data 1128 may include any data associated with the received trust request and / or the provided trust response. The request data 1128 may be stored in the associated blockchain address record 304. In some implementations, the blockchain address record may store request data 1128 each time a trust request is made for a blockchain address. In these implementations, the request data 1128 may indicate the number of times a trust request has been made for the blockchain address. The request data 1128 may also indicate the blockchain address from which the trust request was made, the consensus trust score reported to the requester, and the time of the request. Thus, the request data 1128 may show trends over time for parties requesting the trust score of the blockchain address. In some implementations, the scoring feature of the blockchain address may include a scoring feature based on the request data 1128. One example scoring feature may be the total number of times a trust request has been made for the blockchain address. Another example scoring feature may be a number of different blockchain addresses from which a trust request has been made for the blockchain address. Other example features may include the frequency with which trust requests have been made for the blockchain address (e.g., multiple requests over a period of time).

[0207] Although the trust module 300 may calculate a single local trust score for each blockchain address, regardless of whether the blockchain address is a sender or a receiver, in some implementations, the trust module 300 may calculate a receiver trust score and a sender trust score for each address. In one example, a blockchain address that regularly falls for scams may have a sender trust score that is set to be less trustworthy than a blockchain address that does not typically fall for scams. In another example, a blockchain address that regularly falls for phishing scams may not have a modified receiver trust score when there is no indication of malicious activity associated with receiving funds at the blockchain address.

[0208] The modules and data stores included in the trust network 100 represent features that may be included in the trust network 100 of the present disclosure. The modules and data stores described herein may be implemented by electronic hardware, software, firmware, or any combination thereof. Describing different features as separate modules and data stores does not necessarily mean that these modules and data stores are implemented by common or separate electronic hardware or software components. In some implementations, features associated with one or more modules and data stores described herein may be implemented by common electronic hardware and software components. In some implementations, features associated with one or more modules and data stores described herein may be implemented by separate electronic hardware and software components.

[0209] These modules and data storage can be implemented by electronic hardware and software components, including but not limited to one or more processing units, one or more memory components, one or more input / output (I / O) components and interconnect components. The interconnect components can be configured to provide communication between one or more processing units, one or more memory components, and one or more I / O components. For example, the interconnect components may include one or more buses configured to transmit data between electronic components. These interconnect components may also include control circuits (e.g., memory controllers and / or I / O controllers) that are configured to control communication between electronic components.

[0210] The one or more processing units may include one or more central processing units (CPUs), graphic processing units (GPUs), digital signal processing units (DSPs), or other processing units. The one or more processing units may be configured to communicate with memory components and I / O components. For example, one or more processing units may be configured to communicate with memory components and I / O components via interconnect components.

[0211] The memory components (e.g., main memory and / or storage devices) may include any volatile or non-volatile media. For example, the memory may include, but is not limited to, electronic, magnetic, and / or optical media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), electrically erasable programmable ROM (EEPRGM), flash memory, hard disk drive (HDD), tape drive, optical storage technology (e.g., compact disk, digital versatile disk, and / or Blu-ray disk), or any other memory component.

[0212] The memory component may include (e.g., store) data described herein. For example, the memory component may include data included in the data store. The memory component may also include instructions that can be executed by one or more processing units. For example, the memory may include computer-readable instructions that, when executed by one or more processing units, cause the one or more processing units to perform various functions attributed to the modules and data stores described herein.

[0213] I / O components may refer to electronic hardware and software that provide communication with various different devices. For example, I / O components may provide communication between other devices and one or more processing units and memory components. In some examples, I / O components may be configured to communicate with a computer network. For example, I / O components may be configured to exchange data on a computer network using various physical connections, wireless connections, and protocols. I / O components may include, but are not limited to, network interface components (e.g., network interface controllers), repeaters, bridges, network switches, routers, and firewalls. In some examples, I / O components may include hardware and software configured to communicate with various human-machine interface devices, including but not limited to display screens, keyboards, pointing devices (e.g., mice), touch screens, speakers, and microphones. In some examples, I / O components may include hardware and software configured to communicate with additional devices, such as external memory (e.g., external HDD).

[0214] In some implementations, the trust network 100 may include one or more computing devices (e.g., node computing / server devices) configured to implement the techniques described herein. In other words, the features attributed to the modules and data storage described herein may be implemented by one or more computing devices. Each of the one or more computing devices may include any combination of the above-mentioned electronic hardware, software, and / or firmware. For example, each of the one or more computing devices may include any combination of the above-mentioned processing units, memory components, I / O components, and interconnect components. The one or more computing devices of the trust network 100 may also include various human-machine interface devices, including but not limited to display screens, keyboards, pointing devices (e.g., mice), touch screens, speakers, and microphones. These computing devices may also be configured to communicate with other devices, such as external memory (e.g., external HDD).

[0215] In some examples, one or more computing devices may reside in a single machine at a single geographic location. In other examples, one or more computing devices may reside in multiple machines at a single geographic location. In yet another example, one or more computing devices of the trust network 100 may be distributed across multiple geographic locations.

Claims

1. A system for decentralized security measures to prevent fraud, comprising: one or more memory components configured to store blockchain data for a blockchain address on a blockchain network, wherein the blockchain data includes a plurality of transactions for the blockchain address; and One or more processing units configured to execute computer-readable instructions that cause the one or more processing units to: generating a local node trust score for the blockchain address based on the blockchain data of the blockchain address, wherein the local node trust score indicates a likelihood that the blockchain address is involved in fraudulent activity; receiving a plurality of additional local trust scores for the blockchain address from a plurality of remote servers; determining a consensus trust score based on the local node trust score and the plurality of additional local trust scores, wherein the consensus trust score indicates a consensus value of the local node trust score among the plurality of remote servers; receiving a trust request for a blockchain address from a requesting device; Sending the consensus trust score of the specified blockchain address to the requesting device; determining a local candidate consensus trust score based on the local node trust score and the plurality of additional local trust scores, wherein the local candidate consensus trust score is a candidate value of the local consensus trust score; determining the consensus trust score based on the candidate consensus trust scores; and performing a validation operation associated with the candidate trust score, the validation operation including an error checking operation of the candidate trust score, Wherein, the error checking operation selects a leader node to perform the error checking operation and determine whether the nodes are consistent.

2. The system according to claim 1, wherein: The one or more processing units are further configured to: generating a trust score list including a frequency distribution including the local node trust score and the plurality of additional local trust scores; identifying an outlier trust score included in the list of trust scores; removing the identified outlier trust scores; as well as The consensus trust score is determined based on the trust scores included in the trust score list after removing the identified outlier trust scores.

3. The system according to claim 1, wherein: The one or more processing units are further configured to: generating a trust score list including a frequency distribution including the local node trust score and the plurality of additional local trust scores; as well as The consensus trust score is determined based on a weighted average of the local node trust score and the plurality of additional local trust scores in the trust score list.

4. The system according to claim 1, wherein: The one or more processing units are further configured to: generating a trust score list including a frequency distribution including the local node trust score and the plurality of additional local trust scores; determining whether the trust score list includes a trust score greater than a threshold number; as well as When the trust score list includes trust scores greater than the threshold number, the consensus trust score is determined based on the trust scores included in the trust score list.

5. The system according to claim 1, wherein: The one or more processing units are further configured to: generating a trust score list including a frequency distribution including the local node trust score and the plurality of additional local trust scores; determining whether a variance of the trust scores in the trust score list is less than a threshold variance value; as well as The consensus trust score is determined based on the trust scores included in the trust score list when the variance of the trust scores in the trust score list is less than the threshold variance value.

6. The system according to claim 1, wherein: The one or more processing units are further configured to: generating a trust score list including a frequency distribution including the local node trust score and the plurality of additional local trust scores; identifying an outlier trust score included in the list of trust scores; responsive to identifying the outlier trust score, requesting new local trust scores from the plurality of remote servers; receiving the new local trust score; as well as The consensus trust score is determined based on the new local trust score.

7. The system according to claim 1, wherein: The one or more processing units are further configured to: receiving a plurality of additional candidate consensus trust scores for the blockchain address from the plurality of remote servers; as well as The consensus trust score is determined based on the local candidate consensus trust score and the plurality of additional candidate consensus trust scores.

8. The system according to claim 7, wherein: The one or more processing units are further configured to determine the consensus trust score based on a weighted average of the local candidate consensus trust score and the plurality of additional candidate consensus trust scores.

9. The system according to claim 7, wherein: The one or more processing units are further configured to: determining an amount of variance between the local candidate consensus confidence score and the plurality of additional candidate consensus confidence scores; determining whether the amount of variance is less than a threshold variance value; as well as When the amount of variance is less than the threshold variance value, the consensus trust score is determined based on the local candidate consensus trust score and the plurality of additional candidate consensus trust scores.

10. The system according to claim 1, wherein: The one or more processing units are further configured to receive a reward payment based on the calculation of at least one of the local node trust score and the consensus trust score.

11. The system according to claim 1, wherein: The one or more processing units are further configured to receive a reward payment based on the amount of communication with the plurality of remote servers.

12. The system of claim 1, wherein: The one or more processing units are further configured to: determining that the consensus trust score indicates that the blockchain address may be involved in fraudulent activity; and In response to determining that the consensus trust score indicates that the blockchain address may be involved in fraudulent activity, sending a fraud alert to a fraud alert requesting device.

13. The system of claim 1, wherein: The one or more processing units are further configured to: Obtaining new blockchain data for the blockchain address; generating a new local node trust score for the blockchain address based on the new blockchain data; as well as A new consensus trust score is determined based on the new local node trust score.

14. The system of claim 1, wherein: The one or more processing units are further configured to: receiving a plurality of new additional local trust scores for the blockchain address from the plurality of remote servers; as well as A consensus trust score is determined based on the local node trust score and the plurality of new additional local trust scores.

15. The system of claim 1, wherein: The one or more processing units are further configured to: A validation operation associated with the candidate trust score is performed, the validation operation including an error checking operation of the candidate trust score, wherein the error checking operation includes verifying whether communication of a local trust score actually occurred for the candidate score or whether a conspiracy occurred that resulted in the candidate score.

Images