CN113496392A

CN113496392A - Block chain-based restricted fund supervision method and system

Info

Publication number: CN113496392A
Application number: CN202111040271.6A
Authority: CN
Inventors: 赵汉生; 彭利; 赵达悦; 金戈; 蔡嘉娴
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-09-06
Filing date: 2021-09-06
Publication date: 2021-10-12

Abstract

Embodiments disclosed herein provide a block chain based restricted fund policing method and system. The fund using mechanism submits the using condition of the limited fund to the block chain system for evidence storage, so that supervision can be conveniently carried out according to the difficult-to-tamper limited fund using condition of the evidence stored on the chain.

Description

Block chain-based restricted fund supervision method and system

Technical Field

Embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and a system for supervising limited funds based on blockchains.

Background

The limited funds refer to funds whose manner of use is limited. For example, the restricted funds may be funds that are collected by the business from the market that are dedicated to business operations. As another example, the restricted funds may be government allocated funds specific to the utility.

Typically, the usage of the restricted funds needs to be regulated, however, it is difficult to ensure that the usage of the restricted funds is authentic.

Disclosure of Invention

Various embodiments of the present description provide a block chain based restricted funds policing method and system.

The technical scheme provided by the embodiments of the specification is as follows:

according to a first aspect of various embodiments herein, there is provided a block chain-based restricted fund policing method, including:

the fund use institution client submits the qualification registration information specified by the fund use institution to the blockchain system; the qualification registration information is used for characterizing the use of the limited funds and the internal approval process of the fund use institution for the limited fund use event;

the fund use institution client submits the internal approval record generated by the fund demand institution aiming at each limited fund use event to a block chain system;

the fund depositor client determines a bill record generated by the limited account for each limited fund use event and submits the determined bill record to the blockchain system; the restricted account is used for depositing the restricted funds;

the method is used for monitoring whether the internal approval record corresponding to each limited fund use event accords with the internal approval process or not and monitoring whether the bill record corresponding to each limited fund use event accords with the use of the limited fund or not.

According to a second aspect of various embodiments herein, there is provided a block chain based restricted funds administration system, comprising: the system comprises a block chain system, a fund using mechanism client and a fund custody client;

the fund use institution client submits the qualification registration information specified by the fund use institution to the blockchain system; the qualification registration information is used for characterizing the use of the limited funds and the internal approval process of the fund use institution for the limited fund use event; submitting internal approval records generated by the fund demand organization aiming at each limited fund use event to a blockchain system;

Through the technical scheme, the using condition of the limited fund is submitted to the block chain system by the fund using mechanism for evidence storage, and the monitoring is conveniently carried out according to the difficult-to-tamper limited fund using condition of the evidence stored on the chain. In particular, the use of the restricted funds may include internal approval records generated by the funds-use institution for the restricted funds-use event, and billing records generated by the restricted account managed by the funds administrator for the restricted funds-use event.

In addition, for the supervision requirement, the internal approval record of the fund use institution needs to conform to the internal approval process of the fund use institution, and the bill record of the limited account needs to conform to the use of the limited fund, so that the internal approval process and the use of the limited fund can also be stored in a chain, and the use condition of the limited fund can be supervised based on the credible internal approval process and the use of the limited fund.

Drawings

FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

Fig. 4 is a flowchart of a block chain-based restricted fund supervision method provided in this specification.

Fig. 5 is a schematic structural diagram of a block chain-based restricted fund supervision system provided in the present specification.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

A challenge faced in regulating the use of restricted funds is that it is difficult to ensure that the use of restricted funds revealed by the funds-using authority is authentic. The funds-using institution may reveal false limited funds use.

The use of the restricted funds may include internal approval records generated by the funds-use institution for the restricted funds-use event, and billing records generated by the restricted account managed by the funds repository for the restricted funds-use event.

To facilitate the regulation of the use of restricted funds, it is often desirable to deposit the restricted funds in a restricted account opened by the funds repository. The fund keeping party is a party independent from the fund using mechanism and has the ability of keeping the fund. A common depositor of funds may be a bank.

A limited funds use event refers to an event in which a funds use facility requests use of all or a portion of the limited funds. There are often several levels within the funds-using institution that often require approval of the funds-using event in accordance with a standardized internal approval process. For example, the internal approval process may be performed by the department manager for the use of more than 1 ten thousand funds, and then by the board of directors, or by the department manager for the use of less than 1 ten thousand funds. The funds-using party will generate a corresponding internal approval record for each limited funds-use event.

However, the personnel within the funds-using institution may not necessarily follow the internal approval process of the specification for use of funds, and for such non-specification situations, the funds-using institution may choose not to disclose the funds.

If the approval is passed within the funds-using institution, the funds-using institution may request that the funds-depositor transfer at least a portion of the amount in the restricted account to another account (e.g., a general account of the funds-using institution, or an account of another institution that the funds-using institution needs to pay for the funds). The fund depositor will generate a bill record of the limited account and record the relevant information of the limited fund usage event, which may include the usage time, the usage amount, the specific usage, the identity of the account receiver, etc.

However, it is possible for the funds-using institution to communicate with the funds-depositor and tamper with the billing records that do not comply with the restricted funds use.

In one or more embodiments provided by the present disclosure, the use condition of the limited fund by the fund use authority is submitted to the blockchain system for evidence storage, so as to facilitate supervision according to the difficult-to-tamper limited fund use condition stored on the chain. In addition, for the supervision requirement, the internal approval record of the fund use institution needs to conform to the internal approval process of the fund use institution, and the bill record of the limited account needs to conform to the use of the limited fund, so that the internal approval process and the use of the limited fund can also be stored in a chain, and the use condition of the limited fund can be supervised based on the credible internal approval process and the use of the limited fund.

The block chain technique is described first below.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the system and perform related operations. Private chain the other way around, the write rights of the system are controlled by an organization or organization, and the data read rights are specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants maintain blockchain operation together by authorizing to join the system and forming a stakeholder union.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. Intelligent contracts on blockchains are contracts that can be triggered to execute by transactions (typically client-initiated) on the blockchain system. An intelligent contract may be defined in the form of code.

It should be noted that in the blockchain field, the request for invoking the intelligent contract submitted to the blockchain system has a data structure specified by the blockchain protocol, which is generally referred to as a transaction. A blockchain transaction is a data structure, and the "transaction" in the blockchain-based transaction methods described in the embodiments herein refers to a transaction activity, and those skilled in the art can distinguish these two transaction expressions in meaning.

Taking the etherhouse as an example, the support user creates and invokes some complex logic in the etherhouse system, which is the biggest challenge of the etherhouse to distinguish from the bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet system, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code.

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house system, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account of the initiator of the transaction (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract being invoked, and the value field is the value in EtherFang that is kept in the data field of the transaction as the method and parameters for invoking the smart contract. After invoking the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance through a blockchain node (e.g., node 6 in fig. 2). The intelligent contract is independently executed at each node in the blockchain system in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. To create an intelligent contract in an ethernet workshop, the intelligent contract needs to be compiled, compiled into byte codes, deployed to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, and the intelligent contract codes are distributed and run in the virtual machine of each node in the Ethernet workshop system.

It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain systems may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to the EVM in the ethernet bay, various virtual machines may be used in different blockchain systems, which is not limited herein.

After executing a transaction that invokes an intelligent contract, a node in the blockchain system generates a corresponding receipt (receipt) for recording information related to executing the intelligent contract. In this way, information about the contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can realize message passing through an event in a receipt so as to trigger the blockchain node or a node device deploying the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The blockchain node or the node device deploying the blockchain node may perform the preset processing by monitoring the topic of the event, in case that the predefined topic is monitored, or read the related content from the data field of the corresponding event, and may perform the preset processing based on the read content.

In the event mechanism, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain systems, in order to keep accounts consistent among nodes recording accounts, a consensus algorithm is generally adopted to ensure that the above-mentioned consensus mechanism is adopted. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

Fig. 4 is a flowchart of a block chain-based restricted fund supervision method provided in this specification, which may include the following steps:

s400: and submitting qualification registration information specified by the fund use institution to the blockchain system by the fund use institution client.

The blockchain system described herein may include a blockchain network, and may also include a blockchain network and a network management platform (BaaS platform).

The blockchain network in the blockchain system may be a public chain network, a federation chain network, or a private chain network. In some embodiments, the blockchain network in the blockchain system may be a federation chain network, and one or more of a funds-using institution, a funds-keeper, a funds-supervisor, and an auxiliary-validator may be members of a federation.

The client described herein refers to a blockchain client for interacting with a blockchain system. The client can submit data to the blockchain system, and can also call an intelligent contract deployed in the blockchain system while submitting the data, so as to perform certain processing on the submitted data.

The funds-using institution-specified qualifying registration information may be used to characterize the use of the restricted funds, as well as the internal approval process of the funds-using institution for the restricted funds-using event. The submission of the qualification registration information to the blockchain system is useful to enable the funds-using institution to commit to the use of the restricted funds and the internal approval process by taking advantage of the non-tamper-ability of the data in the blockchain system.

It should be noted that the limited funds may be used by the fund use institution first by using the funds in the ordinary account for payment and then by using the limited funds for reimbursement, or by directly using the limited funds for payment.

S402: and the fund use mechanism client submits the internal approval record generated by the fund demand mechanism for each limited fund use event to the blockchain system.

And each time the fund use mechanism triggers a fund use event, the fund use mechanism can submit the internal approval record corresponding to the fund use event to the blockchain system, and after the internal approval is passed, the fund depositor can be requested to draw at least part of the amount in the limited account for use.

S404: the fund keeper client determines a bill record generated by the restricted account for each restricted fund usage event and submits the determined bill record to the blockchain system.

The fund depositor may generate a billing record for each restricted fund use event based on the restricted account balance change caused by the event and submit the billing record to the blockchain system.

Therefore, by utilizing the data stored in the blockchain system, whether the internal approval record corresponding to each limited fund use event accords with the internal approval process or not can be monitored, and whether the bill record corresponding to each limited fund use event accords with the use of the limited fund or not can also be monitored. Since the data stored in the blockchain system is difficult to be tampered, the evidence on which the supervision is based is credible, and the supervision conclusion is convincing.

In some embodiments, the eligibility registration information is also used to characterize the amount of the restricted funds. In this way, whether the sum of the balance of the limited account and the bill amount of the bill record corresponding to each limited fund usage event conforms to the amount of the limited fund can be further monitored. Of course, in other embodiments, the eligibility registration information may not contain the amount of the restricted funds, but the funds supervisor may pre-record the amount of the restricted funds itself. This mode of supervision can be considered as a tie-out, ensuring that the destination of each part of the restricted funds is supervised and documented.

In some embodiments, the use of the restricted funds may include at least two specific uses. For example, the use of the restricted funds may be a poverty relief, the funds-using institution may be a village council in a certain village, and the specific use may include connecting tap water, repairing roads, purchasing student textbooks, and the like. By way of further example, the restricted funds may be funds that the business has collected from the market (e.g., funds collected by issuing securities on the market), the use may be a gaming service, and the specific use may include employee payroll, copyright purchases, promotional offers, and the like.

In some embodiments, the eligibility registration information is also used to characterize the proportion of funds for different specific uses. Wherein, whether the accumulated amount of the bill record corresponding to the fund usage event of the specific purpose conforms to the fund proportion corresponding to the specific purpose can be monitored for each specific purpose. In addition, the qualification registration information can include fund proportion information corresponding to different specific purposes, and also can include fund amount information corresponding to different specific purposes.

That is, the limited fund can be divided into several parts for each specific use, and each specific use occupies a certain proportion, which is also a part of the limitation of the user of the limited fund and also needs to be supervised.

In some embodiments, the funds-using entity may be qualified for use of restricted funds and require approval by the funds administrator, particularly with respect to the qualification registration information specified by the funds-using entity. After approval, the restricted funds may be deposited into the restricted account for use by the fund consumer.

That is, the funder client may submit approval results for the qualification registration information to the blockchain system. Wherein the restricted funds are deposited to the restricted account if the approval result representation passes.

For example, a government regulatory agency (e.g., a certificate Authority) approves a business for marketing eligibility, and the business receives the marketing eligibility and then collects funds for use by issuing securities.

It should be noted that the qualification registration information specified by the fund consumer may contain more contents related to qualification registration, which is not specifically limited herein. For example, if a business desires to collect funds from the market, the specified qualifications registration information may include an account, various certificates, share constituents, and so forth for the business.

In some embodiments, the fund manager may supervise with the assistance of one or more secondary reviewers. For example, if an enterprise wants to collect funds from the market, a sponsoring agency (e.g., a dealer) needs to perform a sponsoring, which involves the sponsoring agency verifying qualification registration information specified by the use of the funds; the qualification registration information needs to be checked (mainly related to account auditing) by an accounting service (such as an accounting firm); qualification registration information needs to be verified (mainly relating to compliance review) by legal services, such as law firms.

One or more secondary validator clients may submit validation results for the qualification registration information to the blockchain system. The fund manager can determine the approval result according to the verification result of each auxiliary verification party.

In addition, there may be an information disclosure platform dedicated to information disclosure that may obtain and disclose information related to restricted funds from the blockchain system. The fund manager can acquire the information which needs to be known from the blockchain system and also can acquire the information which needs to be known from the information disclosure platform.

In addition, some supervision-related operations occurring under the chain can be transferred to the chain for execution by using intelligent contracts deployed in the blockchain system. It should be understood that one skilled in the art can flexibly choose to implement any below-chain regulatory-related operations with on-chain intelligence contracts. Some embodiments are given below by way of example, but this should not be construed as limiting the scope of the description.

In some embodiments, after the funds consumer submits the eligibility registration information to the blockchain system, the intelligent contracts in the blockchain system may notify the funds administrator client, or may also notify one or more secondary validator clients, by means of an off-chain notification. The supervisor can directly approve the qualification registration information displayed by the fund supervisor client without viewing the qualification registration information from the blockchain system. The fund manager client can also display the qualification registration information travel report in a visual interface mode. Similarly, the auxiliary verifying party client can also display the qualification registration information to the corresponding auxiliary verifying party for verification.

In some embodiments, if a funds-using institution desires to update the eligibility registration information, for example, to update usage, to update the amount of restricted funds (such as supplemental funding), to update an internal approval process, the funds-using institution client may submit updated eligibility registration information specified by the funds-using institution to the blockchain system. The intelligent contracts in the blockchain system may notify the funder client of the updated qualification registration information. The funder client may submit approval results for the updated eligibility registration information to the blockchain system. Under the condition that the examination and approval result representation aiming at the updated qualification registration information is determined to pass, the updated qualification registration information can be validated, and the qualification registration information before updating is invalidated.

In some embodiments, the intelligent contract may also notify one or more secondary validator clients of the updated eligibility registration information. One or more auxiliary verifier clients deliberately submit verification results for the updated qualification registration information to the blockchain system. The intelligent contract may notify the fund manager client of the verification result for the updated qualification registration information, so that the fund manager determines the approval result for the updated qualification registration information with reference to the verification result for the updated qualification registration information.

The intelligent contract in the block chain system can verify whether the bill record corresponding to each limited fund use event meets a preset rule or not for each limited fund use event, and if not, trigger a warning message to the outside of the chain and/or refuse to chain the bill record. Wherein the preset rules include at least one of:

the account from which the billing record was generated is the restricted account; the bill amount is less than the designated amount; the bill validation time is within a specified period.

In some embodiments, smart contracts in a blockchain system may be based on internal approval records submitted by the funds usage authority and billing records submitted by the funds custodian client, generating a regulatory report and notifying the funds custodian client. The intelligent contracts in the blockchain system may also verify whether the internal approval records corresponding to each restricted fund usage event conform to the internal approval process.

In some embodiments, intelligent contracts in the blockchain system may also verify that the billing record corresponding to each restricted funds usage event is consistent with the use of the restricted funds.

In some embodiments, the funds-use institution client may submit introductory information for each restricted funds-use event to the blockchain system. The introductory information for each limited funds use event includes at least the specific use for the limited funds use event.

It should be noted that the introductory information may include other information, such as the time, location, etc. of the limited funds use event, in addition to the information of the specific use of the limited funds use event.

In addition, the intelligent contracts in the blockchain system can determine the specific use of each limited fund use event according to the introductory information of the limited fund use event and accumulate the bill amount of the bill record corresponding to the limited fund use event into the accumulated amount corresponding to the specific use of the limited fund use event.

In this manner, intelligent contracts in a blockchain system may trigger warning messages out of the chain if it is determined that the cumulative amount corresponding to any particular use exceeds the product of the limited funds and the proportion of funds corresponding to that particular use.

The supervisor client may listen to warning messages triggered by smart contracts in the blockchain system to facilitate the supervisor in alerting, penalizing, etc. the fund consumer.

In addition, the present specification provides a schematic structural diagram of a block chain-based restricted funds supervision system, as shown in fig. 5, including: the system comprises a block chain system, a fund using mechanism client and a fund custody client;

Further comprising: a fund manager client;

the fund supervision client submits an approval result aiming at the qualification registration information to a blockchain system; wherein the restricted funds are deposited to the restricted account if the approval result representation passes.

Further comprising: one or more secondary validator clients;

the one or more auxiliary checking party clients submit checking results aiming at the qualification registration information to the blockchain system; and the fund manager determines the approval result according to the verification result of each auxiliary verification party.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing describes several embodiments of the present specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the various embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments herein. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in various embodiments of the present description to describe various information, the information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the various embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the method embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to the partial description of the method embodiment for relevant points. The above-described method embodiments are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the embodiments of the present specification. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A blockchain-based restricted funds oversight method, comprising:

2. The method of claim 1, wherein said qualification registration information is further for characterizing an amount of said restricted funds;

wherein the method is further configured to determine whether the sum of the balance of the restricted account and the billing amount of the billing record corresponding to each restricted funds usage event corresponds to the amount of the restricted funds.

3. The method of claim 1, wherein the use of the restricted funds comprises at least two specific uses.

4. The method of claim 3, wherein the qualification registration information is further configured to characterize a proportion of funds corresponding to different specific uses;

wherein the method is further used for supervising whether the accumulated amount of the bill record corresponding to the fund usage event of the specific purpose is in accordance with the fund proportion corresponding to the specific purpose or not for each specific purpose.

5. The method of claim 1, further comprising:

the fund supervisor client submits the approval result aiming at the qualification registration information to the blockchain system; wherein the restricted funds are deposited to the restricted account if the approval result representation passes.

6. The method of claim 5, further comprising:

one or more auxiliary checking party clients, which submit checking results aiming at the qualification registration information to the blockchain system;

and the fund manager determines the approval result according to the verification result of each auxiliary verification party.

7. The method of claim 6, wherein the restricted funds are funds that have been recruited from the market by the funds-using entity;

the fund manager comprises: a government regulatory agency;

the one or more secondary verification parties include at least one of:

a sponsoring agency, an accounting service agency, and a legal service agency.

8. The method of claim 7, wherein an information disclosure platform obtains and discloses information related to restricted funds from the blockchain system.

9. The method of claim 5, further comprising:

the fund use institution client submits the updated qualification registration information specified by the fund use institution to the blockchain system;

the intelligent contract in the blockchain system informs the updated qualification registration information to the fund manager client;

the fund manager client submits the approval result aiming at the updated qualification registration information to a block chain system;

and the intelligent contract takes the updated qualification registration information into effect and invalidates the qualification registration information before updating under the condition that the examination and approval result representation aiming at the updated qualification registration information passes.

10. The method as recited in claim 9, further comprising:

the intelligent contract informs one or more auxiliary verifier clients of the updated qualification registration information;

the one or more auxiliary checking party clients submit checking results aiming at the updated qualification registration information to the blockchain system;

and the intelligent contract informs the fund manager client of the verification result aiming at the updated qualification registration information so that the fund manager can refer to the verification result aiming at the updated qualification registration information and determine the approval result aiming at the updated qualification registration information.

11. The method of claim 1, further comprising:

the intelligent contract in the block chain system verifies whether the bill record corresponding to each limited fund use event meets a preset rule or not aiming at each limited fund use event, if not, a warning message is triggered to the outside of the chain, and/or the bill record is refused to be linked;

the preset rule includes at least one of:

the account from which the billing record was generated is the restricted account;

the bill amount is less than the designated amount;

the bill validation time is within a specified period.

12. The method of claim 1, further comprising:

and the intelligent contract in the block chain system generates a supervision report and informs the fund supervisor client based on the internal approval record submitted by the fund using mechanism and the bill record submitted by the fund keeper client.

13. The method of claim 1, further comprising:

the intelligent contracts in the block chain system verify whether the internal approval records corresponding to each limited fund use event conform to the internal approval process;

and/or

And the intelligent contract in the blockchain system verifies whether the bill record corresponding to each limited fund use event conforms to the use of the limited fund.

14. The method of claim 4, further comprising:

the fund usage institution client submits introductory information of each limited fund usage event to the blockchain system; the introductory information for each limited funds use event includes at least the specific use for the limited funds use event.

15. The method of claim 14, further comprising:

and the intelligent contract in the blockchain system determines the specific use of each limited fund use event according to the introductory information of the limited fund use event and accumulates the bill amount of the bill record corresponding to the limited fund use event to the accumulated amount corresponding to the specific use of the limited fund use event.

16. The method as recited in claim 15, further comprising:

and the intelligent contracts in the blockchain system trigger warning messages out of the chain if the accumulated amount corresponding to any specific purpose exceeds the product of the limited funds and the fund proportion corresponding to the specific purpose.

17. A blockchain-based restricted funds oversight system, comprising: the system comprises a block chain system, a fund using mechanism client and a fund custody client;

the system is used for monitoring whether the internal approval record corresponding to each limited fund use event accords with the internal approval process or not and monitoring whether the bill record corresponding to each limited fund use event accords with the use of the limited fund or not.

18. The system of claim 17, further comprising: a fund manager client;

19. The system of claim 18, further comprising: one or more secondary validator clients;