System and method for sharing distributed revocation list on blockchain

Abstract

A system for sharing a distributed revocation list on a blockchain includes circuitry that identifies access attempts of a wallet on a first blockchain network and adds the wallet to a blacklist. And the blacklist identifies the wallet as a suspicious wallet. The circuit system generates a soul binding token, and the soul binding token is air-dropped into the wallet. And the soul binding token identifies that the wallet belongs to the distributed revocation list and identifies that the wallet is a suspicious wallet to a block chain network.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Application No. 18 / 072,130, filed on November 30, 2022, the entire content of which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] The present disclosure relates to systems and associated methods for sharing a distributed revocation list (or decentralized blacklist) of suspicious wallets on a blockchain using soul - bound non - transferable tokens (NFTs). Background Art

[0004] Smart contracts are transaction protocols hosted on a blockchain that allow for digital verification, control, and execution of contracts. When the parties fulfill their terms, the smart contract automatically executes. Today, when a smart contract wants to block malicious users (represented by personal wallets connected to the blockchain) from accessing its application, it must interface with various blacklists of suspicious wallets maintained by multiple different parties. Since there is no way to immediately synchronize all these different blacklists, hackers can easily withdraw stolen funds from the blockchain ecosystem after a successful exploit attack. Thus, these blockchain ecosystems are vulnerable to money laundering attacks.

[0005] Accordingly, there is a need for a system to share blacklists of suspicious wallets across blockchain ecosystems with low latency to address these and other deficiencies of current systems. Summary of the Invention

[0006] The present disclosure describes a distributed revocation list sharing system and method that addresses cybersecurity issues in conventional blockchain ecosystems. Specifically, the present disclosure describes a distributed revocation list sharing system and method having the following features.

[0007] In an exemplary aspect of the present disclosure, a system for sharing a distributed revocation list on a blockchain includes circuitry. The circuitry identifies an access attempt of a wallet on a first blockchain network, adds the wallet to a blacklist that identifies it as a suspicious wallet, generates a soul - bound token, and air - drops the soul - bound token into the wallet. The soul - bound token identifies that the wallet belongs to the distributed revocation list and identifies the wallet as a suspicious wallet of the blockchain network.

[0008] In an exemplary aspect of the present disclosure, after receiving a transaction request from a wallet, a second blockchain network determines whether the wallet includes a soul - bound token. If the wallet includes a soul - bound token, then the second blockchain network rejects the transaction request.

[0009] In an exemplary aspect of the present disclosure, the circuit system also detects an attempt by the wallet to transfer funds to another wallet. After detecting the attempt, the circuit system adds the other wallet to a blacklist. Additionally, the circuit system generates another soul-bound token and airdrops the soul-bound token into the other wallet.

[0010] In an exemplary aspect of the present disclosure, after receiving a transaction request from the other wallet, the second blockchain network determines whether the other wallet includes another soul-bound token, and if the other wallet includes another soul-bound token, then rejects the transaction request.

[0011] In an exemplary aspect of the present disclosure, the circuit system also monitors transactions made by the wallet on the first blockchain network to identify access attempts.

[0012] In an exemplary aspect of the present disclosure, the circuit system also determines whether the access attempt is false. When it is determined that the access attempt is false, the circuit system revokes the soul-bound token in the wallet and removes the wallet from the blacklist.

[0013] In an exemplary aspect of the present disclosure, the circuit system also performs revocation of the soul-bound token by modifying the metadata of the soul-bound token.

[0014] In an exemplary aspect of the present disclosure, the circuit system also determines whether the access attempt is false based on context information related to the transaction.

[0015] In an exemplary aspect of the present disclosure, the circuit system also detects an attempt by the wallet to transfer a soul-bound token. After detecting the attempt, the circuit system blocks the transfer of the soul-bound token.

[0016] In an exemplary aspect of the present disclosure, after receiving a transaction request from the wallet, the first blockchain network determines whether the wallet is on the blacklist. If the wallet is on the blacklist, then the first blockchain network rejects the transaction request.

[0017] In an exemplary aspect of the present disclosure, the circuit system also pauses the first blockchain network after identifying an access attempt.

[0018] In an exemplary aspect of the present disclosure, after receiving a transaction request from the wallet, the second blockchain network reads the local whitelist and determines whether the wallet includes a soul-bound token airdropped from a source in the local whitelist. When the determined result is affirmative, the second blockchain network rejects the request. When the determined result is negative, the second blockchain network processes the request based on the policy of the second blockchain network.

[0019] In an exemplary aspect of the present disclosure, the circuit system also generates a global whitelist. The second blockchain network obtains the global whitelist and updates the local whitelist based on the obtained global whitelist.

[0020] In an exemplary aspect of the present disclosure, the circuitry also air-drops a soul-bound token with the highest priority.

[0021] In an exemplary aspect of the present disclosure, the circuit also air-drops another soul-bound token with the highest priority.

[0022] In an exemplary aspect of the present disclosure, the circuitry also identifies access attempts, including at least one of exploitation, hijacking, money laundering, theft, phishing attacks, unauthorized intrusion, and unauthorized access attempts.

[0023] In an exemplary aspect of the present disclosure, each of the first and second blockchain networks includes a smart contract.

[0024] In an exemplary aspect of the present disclosure, a method for sharing a distributed revocation list on a blockchain includes using circuitry to identify an access attempt of a wallet on a first blockchain network. The method further includes using circuitry to add the wallet to a blacklist that identifies it as a suspicious wallet. The method further includes using circuitry to generate a soul-bound token and air-drop it into the wallet. The soul-bound token identifies that the wallet belongs to the distributed revocation list and identifies the wallet as a suspicious wallet of the blockchain network.

[0025] In an exemplary aspect of the present disclosure, a non-transitory computer-readable medium includes computer-readable instructions. When the computer-readable instructions are executed by at least one processor, the at least one processor is caused to execute a method. The method includes identifying an access attempt of a wallet on a first blockchain network. The method further includes adding the wallet to a blacklist that identifies it as a suspicious wallet. The method further includes generating a soul-bound token and air-dropping the soul-bound token into the wallet. The soul-bound token identifies that the wallet belongs to the distributed revocation list and identifies the wallet as a suspicious wallet of the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Since the present invention can be better understood by considering the following detailed description in conjunction with the accompanying drawings, a more complete understanding of the invention and many of its attendant advantages will be readily obtained, in which:

[0027] Figure 1A is an exemplary block diagram of the deployment of a blockchain ecosystem;

[0028] Figure 1B is an exemplary scenario in which a hacker manages to perform money laundering in a blockchain ecosystem after an exploitation attack;

[0029] Figure 2A is an exemplary block diagram of the deployment of a blockchain ecosystem according to an exemplary aspect of the present disclosure;

[0030] Figure 2B is an exemplary scenario in which hackers are prevented from escaping with stolen funds according to an exemplary aspect of the present disclosure;

[0031] Figure 3 is a functional block diagram of a monitoring tool according to an exemplary aspect of the present disclosure;

[0032] Figure 4 is an algorithmic flowchart of a process executed by a monitoring tool according to an exemplary aspect of the present disclosure;

[0033] Figure 5 is a functional block diagram of a minting contract according to an exemplary aspect of the present disclosure;

[0034] Figure 6 is an algorithmic flowchart of a process executed by a minting contract according to an exemplary aspect of the present disclosure;

[0035] Figure 7 is a functional block diagram of a smart contract according to an exemplary aspect of the present disclosure;

[0036] Figure 8 is an algorithmic flowchart of a process executed by a smart contract according to an exemplary aspect of the present disclosure;

[0037] Figure 9 is one that can form Figure 2A an exemplary block diagram of a system of one or more of the blocks shown in; and

[0038] Figure 10 is a hardware diagram of a computing device according to an exemplary aspect of the present disclosure. DETAILED DESCRIPTION

[0039] Reference is now made to the accompanying drawings, in which like reference numerals refer to identical or corresponding parts throughout several views. Figure 1A Illustrated is a block diagram of an exemplary blockchain ecosystem, in which wallets 151, 152, and 153 can transact with smart contracts 101, 102, and 103. As Figure 1AAs shown, smart contracts 101, 102, and 103, as well as wallets 151, 152, and 153, are all connected to network 140. Monitoring tools 111, 112, and 113 are respectively responsible for monitoring transactions conducted on smart contracts 101, 102, and 103. Monitoring tools 111, 112, and 113 generate and maintain blacklists 121, 122, and 123 for the corresponding smart contracts 101, 102, and 103 based on the monitored transactions. For example, after detecting a hacking attempt, these blacklists 121, 122, and 123 can be dynamically updated by the corresponding monitoring tools 111, 112, and 113 and directly implemented into the corresponding smart contracts 101, 102, and 103. Alternatively, the administrator of the smart contract can manually create and update the blacklist for the smart contract (not shown).

[0040] In addition to blacklists 111, 112, and 113, various centralized authorization agencies and entities in the blockchain ecosystem can also generate and maintain blacklists of suspicious wallets. As Figure 1A shown, centralized authorization agencies 131, 132, and 133 respectively create blacklists 124, 125, and 126. These blacklists 124, 125, and 126 can be provided on-chain or off-chain as an oracle. An example is the oracle of Chainalysis for sanctions screening based on Office of Foreign Assets Control (OFAC) data. Alternatively, blacklists 124, 125, and 126 can be provided off-chain by the community or a centralized entity as address tags on a blockchain browser. For example, address tags such as "exploit", "hijack", "phishing / hacking" can be provided on the Ethereum (ETH) blockchain browser.

[0041] Therefore, in order to prevent hackers from laundering stolen funds, each smart contract needs to refer to multiple blacklists of suspicious wallets. There is currently no general way to immediately share or synchronize all these blacklists to reduce the impact of blockchain protocol exploitation.

[0042] To enhance privacy, virtual currency mixers (or "cryptocurrency anonymizers") facilitate anonymous transactions indiscriminately by obfuscating the source, destination, and counterparty of transactions and do not attempt to determine the source of the transactions. Typically, virtual currency mixers receive various transactions and mix them together before transmitting them to their respective recipients. Therefore, virtual currency mixers can be used by criminals to launder stolen funds. However, when it comes to virtual currency mixers, Figure 1A the exemplary blockchain ecosystem shown in

[0043] Figure 1B illustrates an exemplary scenario where a hacker manages to execute money laundering in the blockchain ecosystem after an exploit. InFigure 1B Among them, the monitoring tools X 114, Y 115, and Z 116 maintain blacklists A 127, B 128, and C 129 for the smart contracts A 104, B 105, and C 106. The smart contract B 105 can be a virtual currency mixer, and the smart contracts A 104 and C 106 can be any smart contracts. After successfully detecting the exploitation of the smart contract A 104 by the wallet A 154, the monitoring tool X 114 adds the wallet A 154 to the blacklist A 127 associated with the smart contract A 104. However, since the wallet A 154 is not in the blacklist B 128 associated with the smart contract B 105, the wallet A 154 can launder funds using the smart contract B 105, and another wallet B 155 can withdraw funds from the smart contract B 105. Moreover, since both the wallet A 154 and the wallet B 155 are not in the blacklist C 129 associated with the smart contract C 106, they can both use the smart contract C 106. Because the updates in the blacklists are not reflected quickly enough in other blacklists, adding the wallet A 154 to the blacklist A 127 does not prevent the wallet A 154 from laundering the stolen funds via other smart contracts.

[0044] Figure 2A is an exemplary block diagram of a blockchain ecosystem according to an exemplary aspect of the present disclosure. As Figure 2A shown, the smart contracts 201, 202, and 203 and the wallets 251, 252, and 253 are connected to the network 220. The monitoring tools 211, 212, and 213 respectively monitor the transactions conducted on the smart contracts 201, 202, and 203 and maintain blacklists ( Figure 2A not shown in the figure) for the corresponding smart contracts 201, 202, and 203. Also connected to the network 220 is a minting contract 230 that mints soul-bound NFTs and revokes the minted soul-bound NFTs in response to calls from the monitoring tools 211, 212, and 213. Additionally, the blockchain ecosystem includes a global whitelist 240 that includes a list of sources of trusted or approved NFTs. For example, the sources of trusted or approved NFTs can include a list of minting contracts and / or a list of monitoring tools. For example, the global whitelist 240 can be created by a community or a centralized authorization agency (not shown) and published on a website.

[0045] Figure 2B is an exemplary scenario for preventing hackers from escaping with stolen funds according to an exemplary aspect of the present invention. In Figure 2BIn this case, monitoring tool X 214 monitors transactions on smart contract A 204 and updates blacklist 260 when a hacking attempt is identified from the transactions. For example, hacking attempts can be exploits, hijacking, money laundering, theft, phishing attacks, unauthorized intrusion, and unauthorized access attempts. For clarity, the monitoring tool or blacklist with respect to smart contract B 205 or C 206 is not shown.

[0046] After detecting an exploit of smart contract A 204 by wallet A 254, monitoring tool X 214 adds wallet A 254 to blacklist 260 to prevent further exploitation from the same wallet. For example, when smart contract A 204 receives a transaction request from a wallet, it reads blacklist 260 to determine whether the wallet that issued the request is in blacklist 260. If the wallet that issued the request is in blacklist 260, then smart contract A 204 rejects the transaction request. If the wallet that issued the request is not in blacklist 260, then smart contract A 204 continues to process the transaction request according to its policy.

[0047] Those skilled in the art can recognize that further remedial measures are possible. For example, as an event response to the detected vulnerability, monitoring tool X 214 can pause smart contract A 204 until security is restored.

[0048] Moreover, after wallet A 254 detects an exploit, monitoring tool X 214 sends a tainted call to custom NFT minting contract 235 such that a dedicated soul-bound NFT is air-dropped into wallet A 254. The tainted call is sent to the blockchain with the highest priority to prevent wallet A 254 from managing to use other smart contracts (e.g., smart contract B 205 or C 206) between detecting the exploit event and the airdrop of the soul-bound NFT.

[0049] Minting contract 235 monitors the blockchain to detect attempts to transfer the NFTs it has air-dropped. In this way, when wallet A 254 attempts to transfer an NFT to another wallet, minting contract 235 blocks this transfer. For example, minting contract 235 can be programmed to systematically reject the transfer of the NFT after it is first air-dropped. Without departing from the scope of the present disclosure, this functionality can be implemented for non-EVM chains by similar techniques.

[0050] To detect the transfer of stolen funds from wallet A 254 to other wallets (such as wallet B 255), the monitoring tool X214 monitors transfer transactions from wallet A 254 in the blockchain. When such a transfer attempt is identified, the monitoring tool X 214 reacts by sending another contaminating call to the minting contract 235, causing another NFT to be minted and airdropped into wallet B255. Again, this contaminating call is sent to the blockchain with the highest priority. In addition, the monitoring tool X 214 adds wallet B255 to the blacklist 260.

[0051] When a contaminated wallet A 254 or a contaminated wallet B 255 requests to use any other smart contract (e.g., smart contract B 205 or C 206), the smart contract determines whether the wallet making the request has a soul-bound NFT from a trusted source (e.g., the minting contract 235 and / or the monitoring tool X 214). If the wallet has such a soul-bound NFT, then the transaction request is rejected.

[0052] The process of generating a contaminated NFT and airdropping it into a suspicious wallet can be very fast. Typically, it can be completed when the next block is added to the blockchain. There is no need to transmit or synchronize many lengthy blacklists across the blockchain. In this way, a decentralized distributed blacklist can be shared in real time across the entire blockchain ecosystem. Accordingly, even if virtual currency mixers are involved (if compatible), money laundering can be effectively combated.

[0053] Figure 2A-2B The illustrations are not restrictive, and other variations are possible without departing from the scope of the present disclosure. For example, Figure 2A illustrates three monitoring tools 211-213, three smart contracts 201-203, and three wallets 251-253. However, this is only for clarity, as in practice, there can be many more such components in the blockchain ecosystem. In addition, Figure 2B illustrates that the blacklist 260 is part of the monitoring tool X 214. However, this is only for clarity, as they can be separate components, or the blacklist 260 can be part of the smart contract A 204. Additionally, Figure 2A-2B The different boxes shown in can be separate, independent entities, or can form part of a single entity, but are not limited to this.

[0054] Figure 3 is a functional block diagram of a monitoring tool according to an exemplary aspect of the present disclosure. Figure 3The monitoring tool 300 therein includes a transaction monitoring unit 305, a hacking attempt identification unit 310, a tainted call generation unit 315, a blacklist update unit 320, and a blacklist 325. The transaction monitoring unit 305 monitors transactions made using smart contracts. The hacking attempt identification unit 310 detects hacking attempts on smart contracts by wallets from the monitored transactions. After detecting a hacking attempt, the blacklist update unit 320 adds the wallet to the blacklist 325. Meanwhile, the tainted call generation unit 315 generates a tainted call for the wallet and sends it to the minting contract. Although the blacklist 325 is shown as being included in the monitoring tool 300, the blacklist 325 may be separate from the monitoring tool 300, for example, stored in a smart contract.

[0055] In addition, the monitoring tool 300 may further include a hacking attempt investigation unit 330 and a decontamination call generation unit 335. The hacking attempt investigation unit 330 conducts an investigation on the identified hacking attempt to determine whether it is a false alarm. The investigation may be performed based on the context information of the transactions between the wallet and the smart contract. If the identified hacking attempt is determined to be a false alarm, then the hacking attempt investigation unit 330 signals the blacklist update unit 320 to remove the wallet from the blacklist 325. Additionally, the decontamination call generation unit 335 sends a decontamination call for the wallet to the minting contract.

[0056] In an alternative example, the investigation of the hacking attempt may be performed by an entity independent of the monitoring tool 300. In this case, the monitoring tool 300 receives the investigation results from that entity and decides whether to initiate decontamination accordingly.

[0057] In addition, the monitoring unit 300 includes a suspicious wallet monitoring unit 340, a transfer attempt detection unit 345, and a transfer attempt prevention unit 350. The suspicious wallet monitoring unit 340 monitors the blockchain to see if a blacklisted wallet attempts to transfer funds to another wallet. If so, then the transfer attempt detection unit 345 signals the blacklist update unit 320 to add the transferee wallet to the blacklist 325. Meanwhile, the tainted call generation unit 315 sends a tainted call for the transferee wallet to the minting contract.

[0058] Figure 4 is an algorithmic flowchart of a process performed by a monitoring tool according to an exemplary aspect of the present disclosure. Figure 4On the left side is the hacking attempt identification sub - process 410 implemented by the monitoring tool. At step 412, the monitoring utilizes the smart contract for transactions. If a hacking attempt on a wallet is identified from the transaction ("Yes" at step 414), then at step 416, a pollution call is sent to the minting contract to mark the wallet as suspicious. At step 418, the wallet is added to the blacklist associated with the smart contract. If no hacking attempt is identified ("No" at step 414), then the sub - process 410 returns to step 412 to continue monitoring the transaction.

[0059] Figure 4 On the right side is the fund transfer prevention sub - process 470. At step 472, the activities of suspicious wallets are monitored. If it is detected that a wallet attempts to transfer funds to another wallet ("Yes" at step 474), then a pollution call is sent to the minting contract, such that the minting contract marks the transferee wallet as suspicious. Additionally, at step 478, the transferee wallet is added to the blacklist. If no attempt to transfer funds is identified ("No" at step 474), then the sub - process 470 returns to step 472 to continue monitoring the activities.

[0060] Figure 4 In the middle is the hacking attempt investigation sub - process 440 executed by the monitoring tool. At step 442, the hacking attempt is investigated to determine whether it is a false alarm. If it is determined that the hacking attempt is a false alarm ("Yes" at step 444), then a decontamination call is sent to the minting contract. Additionally, at step 448, the suspicious wallet is removed from the blacklist (and optionally, the transferee wallet is also removed from the blacklist), which ends the investigation sub - process 440. If the investigation result is that the hacking attempt is not a false alarm ("No" at step 444), then the investigation sub - process 440 jumps to the end.

[0061] Figure 5 is a functional block diagram of a minting contract according to an exemplary aspect of the present disclosure. The minting contract 500 includes a call receiving unit 510, an NFT minting unit 520, and an NFT revocation unit 530. The call receiving unit 510 receives calls sent by the monitoring tool. If the received call is a pollution call for a certain wallet, then the NFT minting unit 520 mints a soul - bound NFT and airdrops it into the wallet to identify the wallet as a suspicious wallet. In a non - limiting example, the metadata of the soul - bound NFT can indicate various information, such as the identity of the minting contract 500, the time of airdropping the NFT, the status of the NFT (e.g., valid and invalid), information about the transaction or event that is the basis for the pollution call, etc.

[0062] If the received call is a decontamination call for a suspicious wallet, then the NFT revocation unit 530 revokes the soul-bound NFTs present in the wallet. Optionally, the soul-bound tokens in the assignee's wallet can also be revoked. The revocation of the soul-bound NFTs can be achieved by any feasible means. In a non-limiting example, the revocation can be achieved by changing the status of the NFT from valid to invalid.

[0063] Note that although in the example shown in Figure 3-6 , the revocation of the soul-bound NFTs is performed by the minting contract 500 in response to a decontamination call from the monitoring tool 300, in another example, the decontamination process can be done by the monitoring tool 300 itself without the participation of the original minting contract 500. For example, if the metadata is stored in an AWS S3 bucket, then the monitoring tool 300 can change the status of the NFT from valid to invalid by simply modifying the corresponding file. Alternatively, in yet another example, the decontamination process can be done by adding the suspicious wallet to a whitelist.

[0064] As Figure 5 shown, the minting contract 500 also includes an NFT transfer monitoring unit 540 and an NFT transfer blocking unit 550. The NFT transfer monitoring unit 540 monitors the blockchain to detect if a suspicious wallet is attempting to transfer an NFT airdropped by the minting contract 500. When such an attempt is detected, the NFT transfer blocking unit 550 blocks the transfer.

[0065] Figure 6 is an algorithmic flowchart of the process executed by the minting contract according to an exemplary aspect of the present disclosure. The contamination / decontamination sub-process 610 is shown on the left. At step 615, a call is received from the monitoring tool. If the received call is a contamination call for a certain wallet (left branch of step 620), then at step 625, a soul-bound NFT is minted and airdropped into that wallet to identify the wallet as a suspicious wallet. If the received call is a decontamination call for a suspicious wallet (right branch of step 620), then at step 630, the NFTs in the wallet airdropped by the minting contract are revoked.

[0066] Figure 6 The right side of

[0067] Figure 7It is a functional block diagram of a smart contract according to an exemplary aspect of the present disclosure. The smart contract 700 includes a global whitelist acquisition unit 710, a local whitelist update unit 720, and a local whitelist 730. The global whitelist acquisition unit 710 acquires the global whitelist from a trusted source on-chain or off-chain. The local whitelist update unit 720 updates the local whitelist 730 based on the acquired global whitelist. For example, the global whitelist can be maintained by a community or some authorized institution and published on a website regularly (e.g., weekly, monthly, etc.). The global whitelist can include a list of sources of trusted or approved soul-bound NFTs (e.g., the minting contract of the airdropped NFT and / or the monitoring tool that sends polluted calls). In this way, new minting contracts and new monitoring tools can be registered through the global whitelist and thus be accepted by existing smart contracts. Note that when the update frequency of the global whitelist is not too high (e.g., less than once a month), it is feasible to manually update the local whitelist 730 at the smart contract 700.

[0068] The smart contract 700 further includes a transaction request receiving unit 740, a requesting wallet checking unit 750, and a transaction request processing unit 760. The transaction request receiving unit 740 receives a transaction request from a wallet. The requesting wallet checking unit 750 checks the wallet that issues the request to determine whether the wallet that issues the request has NFTs from a whitelisted source (e.g., a trusted minting contract and / or a trusted monitoring tool). Then, if the wallet that issues the request has such NFTs, the requesting wallet checking unit 750 rejects the transaction request. If the wallet that issues the request does not have any valid NFTs from a whitelisted source, the transaction request processing unit 760 processes the transaction request based on the strategy of the smart contract.

[0069] Figure 8 It is an algorithmic flowchart of a process executed by a smart contract according to an exemplary aspect of the present disclosure. Figure 8 On the left side of is the transaction request processing sub-process 810. At step 815, a request to transact with the smart contract is received from a wallet. At step 820, the local whitelist is read. At step 825, it is determined whether the wallet that issues the request has NFTs from a whitelisted source. If the wallet has such NFTs ("Yes" at step 825), then the transaction request is rejected at step 835. If the wallet does not have such NFTs ("No" at step 825), then at step 830, the smart contract processes the transaction request based on an internal strategy.

[0070] Figure 8The right side of [Figure] shows the whitelist update sub - process 850. At step 855, the global whitelist is obtained by the smart contract. At step 860, it is determined whether there is a difference between the global whitelist and the local whitelist. If the determination result is affirmative ("Yes" at step 860), then the local whitelist is updated based on the global whitelist. If the determination result is negative ("No" at step 860), then the sub - process returns until a new global whitelist is obtained.

[0071] For clarity, the functional module for processing transaction requests based on whether the wallet that issues the request is in the blacklist maintained by the corresponding monitoring tool is omitted from Figure 7 Similarly, the corresponding steps are also omitted from the processing shown in Figure 8

[0072] Figure 9 is an exemplary block diagram of a system that can form one or more of the blocks shown in Figure 2A For example, the system shown in Figure 9 can correspond to any one of the smart contracts 201 - 203, any one of the monitoring tools 211 - 213, the minting contract 230, the entity (not shown) that generates the global whitelist 240, or any one of the wallets 251 - 253. In the case where any one of the blocks in Figure 2A is covered in a single system, the single system can be illustrated by the system shown in Figure 9 For example, the smart contract 201 and the monitoring tool 211 can be part of a single system (such as the system of Figure 9 ) As can be recognized, Figure 2A other combinations of different blocks into a single system (such as the system of Figure 9 ) are also possible.

[0073] Figure 9 The exemplary system shown in

[0074] ​Computing devices 905, 910, 915 can include desktop computers, laptop computers, tablet computers, mobile phones, thin clients, and any other known computing devices. Computing devices 905, 910, 915 can also have a permanent, semi-permanent, or temporary connection to network 900. These connections can also be wired, such as an Ethernet connection; or can be wireless, such as WiFi, Bluetooth, or cellular connections (i.e., 3G, 4G, LTE, etc.). Although only three computing devices 905, 910, 915 are illustrated in the figure, Figure 9 the system can include any number of computing devices, without limitation.

[0075] Server devices 920, 925, and 930 are connected to network 900 via a permanent connection and can store data and provide services to computing devices 905, 910, 915, such as email, database services, etc. In Figure 9 the system, there can be more than three servers or fewer than three servers, without limitation.

[0076] Next, a description of the hardware of computing devices 905, 910, 915 and server devices 920, 925, 930 is provided. In Figure 10 the case where the boxes shown in Figure 2A correspond to the respective devices, the hardware of those devices can also be as shown in Figure 10 . Figure 10 The device of

[0077]

[0078] Figure 10 The communication interface 1010 is circuitry that connects the Figure 10 device to one or more communication networks (such as an Ethernet network, a cellular network, a WiFi network, a Bluetooth network, etc.). For example, the communication interface 1010 can be a network interface card (NIC).

[0079] The processor 1005 can be based on a reduced instruction set (RISC) architecture, a von Neumann architecture, a Harvard architecture, or any other known processing architecture. The processor 1005 can also be implemented as a system on a chip, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or discrete logic circuit components. The processor 1005 can also be implemented in software executed on a processing circuit system having any of the above architectures.The main memory 1025 and the ROM 1020 are used to store instructions and other data required by the processor 1005 to perform various tasks that are consistent with the exemplary aspects of the present disclosure. Specifically, the ROM 1030, being a read-only memory circuit, may include permanent instructions that do not require change, such as low-level routines. The main memory 1025 may include a combination of random access memory and erasable programmable read-only memory (EPROM) to store programming instructions that can be periodically updated and data that can be changed periodically or frequently during the execution of instructions by the processor 1005.

[0080] The display controller 1030 is an interface circuit that allows a display 1045, such as a liquid crystal display, to be connected to Figure 10 the device in order to provide visual information to its user. The disk controller 1015 is an interface circuit that allows a device such as a hard disk 1040 that provides mass storage to be connected to the bus 1000 and thus to the processor 1005. The disk controller 1015 also allows the connection of other removable media 1035, such as a compact disc reader, a Secure Digital (SD) card, a memory stick, etc. The keyboard 1050 and a pointing device 1055, such as a mouse, may also be connected to Figure 10 the device shown to provide a means for a user of the device to enter data. For the sake of brevity, further description of these components is omitted.

[0081] Obviously, various modifications and variations of the present invention are possible in light of the above teachings. Accordingly, it should be understood that within the scope of the appended claims, the invention may be practiced in a manner different from that specifically described herein.

Claims

1. A system for sharing a distributed revocation list on a blockchain, comprising: Circuitry configured to receive information indicating that a first digital wallet on a first blockchain network is marked, add the first digital wallet to a distributed revocation list, the distributed revocation list including a list of digital wallets indicated as being marked, Generate a first soulbound token, and Send the first soulbound token to the first digital wallet, where The first soulbound token indicates that the first digital wallet belongs to the distributed revocation list and indicates that the first digital wallet is a marked digital wallet of the blockchain network, and The marked status follows the first digital wallet to any additional digital wallets associated with the first digital wallet.

2. The system according to claim 1, wherein the circuitry is further configured to After detecting a transaction request from the first digital wallet to the second digital wallet, determine whether the first digital wallet includes the first soulbound token, and After determining that the first digital wallet includes the first soulbound token, reject the transaction request.

3. The system according to claim 1, wherein the circuitry is further configured to After detecting a transaction request from the first digital wallet to the second digital wallet, Add the second digital wallet to the distributed revocation list, Generate a second soulbound token, and Before the second digital wallet initiates a second transaction request, send the second soulbound token to the second digital wallet.

4. The system according to claim 3, wherein the circuitry is further configured to After detecting a transaction request from the second digital wallet, determine whether the second digital wallet includes the second soulbound token, and After determining that the second digital wallet includes the second soulbound token, reject the transaction request.

5. The system according to claim 1, wherein the circuitry is further configured to Monitor transactions conducted by the first digital wallet on the first blockchain network to identify that the transaction is a marked event.

6. The system according to claim 1, wherein the circuitry is further configured to Determine whether the first digital wallet is falsely marked, and After determining that the first digital wallet is falsely marked, Revoke the first soulbound token in the first digital wallet, and Remove the first digital wallet from the distributed revocation list.

7. The system according to claim 6, wherein the circuitry is further configured to Perform the revocation of the first soulbound token by modifying the metadata of the first soulbound token.

8. The system according to claim 5, wherein the circuitry is further configured to determine whether the marked event is false based on context information related to the transaction.

9. The system according to claim 1, wherein the circuitry is further configured to Prevent the transfer of the first soulbound token after detecting that the first digital wallet attempts to transfer the first soulbound token.

10. The system according to claim 1, wherein the circuitry is further configured to When detecting a transaction request from the first digital wallet, determine whether the first digital wallet is in the distributed revocation list, and After determining that the first digital wallet is in the distributed revocation list, reject the transaction request.

11. The system according to claim 1, wherein the circuitry is further configured to After receiving information indicating that a first digital wallet on a first blockchain network is marked, suspend transactions on the first blockchain network.

12. The system according to claim 2, wherein after detecting a transaction request from the first digital wallet to a second digital wallet, the circuitry is further configured to After determining that the first soul-bound token is sent from a source in the locally authorized source list, reject the transaction request, and After determining that the first soul-bound token is not sent from a source in the locally authorized source list, process the transaction request based on the policy of the second blockchain network corresponding to the second digital wallet in the blockchain network.

13. The system according to claim 12, wherein the circuitry is further configured to generate a globally authorized source list, and the second blockchain network obtains the globally authorized source list and updates the locally authorized source list based on the obtained globally authorized source list.

14. The system according to claim 1, wherein the circuitry is further configured to send the first soul-bound token with the highest priority.

15. The system according to claim 3, wherein the circuitry is further configured to send the second soul-bound token with the highest priority.

16. The system according to claim 1, wherein the first digital wallet is marked based on a transaction made by the first digital wallet being a marked event, the marked event including at least one of exploitation, hijacking, money laundering, theft, phishing attack, unauthorized intrusion, and unauthorized access attempt.

17. The system according to claim 1, wherein the first blockchain network includes a first smart contract and the circuitry is further configured to generate a first soul-bound token and send the first soul-bound token to the first digital wallet by Generating a first soul-bound token request, and Transmitting the first soul-bound token request to the first smart contract, the first soul-bound token request being configured to instruct the first smart contract to generate a first soul-bound token and transmit the first soul-bound token to the first digital wallet.

18. A method for sharing a distributed revocation list on a blockchain, comprising: Receiving, by a circuitry, information indicating that a first digital wallet on a first blockchain network is marked; Adding, by the circuitry, the first digital wallet to a distributed revocation list, the distributed revocation list including a list of digital wallets indicated as being marked; Generating, by the circuitry, a first soul-bound token; And Sending, by the circuitry, the first soul-bound token to the first digital wallet, wherein The first soul-bound token indicates that the first digital wallet belongs to the distributed revocation list and indicates that the first digital wallet is a marked digital wallet of the blockchain network, and The marked status follows the first digital wallet to any additional digital wallets associated with the first digital wallet.

19. A non-transitory computer-readable medium comprising computer-readable instructions that, when executed by at least one processor, cause the at least one processor to execute a method for sharing a distributed revocation list on a blockchain, the method comprising: Receiving information indicating that a first digital wallet on a first blockchain network is marked; Adding the first digital wallet to a distributed revocation list, the distributed revocation list comprising a list of digital wallets indicated as being marked; Generating a first soul-bound token; and Sending the first soul-bound token to the first digital wallet, wherein The first soul-bound token indicates that the first digital wallet belongs to the distributed revocation list and indicates that the first digital wallet is a marked digital wallet of the blockchain network, and The marked status follows the first digital wallet to any additional digital wallets associated with the first digital wallet.

Images