CN115996226B - Shared incentive method, device and equipment for multiple intelligent contracts based on block chain - Google Patents
Shared incentive method, device and equipment for multiple intelligent contracts based on block chain Download PDFInfo
- Publication number
- CN115996226B CN115996226B CN202310295550.XA CN202310295550A CN115996226B CN 115996226 B CN115996226 B CN 115996226B CN 202310295550 A CN202310295550 A CN 202310295550A CN 115996226 B CN115996226 B CN 115996226B
- Authority
- CN
- China
- Prior art keywords
- data
- verification
- requester
- resource
- data set
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The application provides a shared incentive method, a device and equipment for multiple intelligent contracts based on a blockchain, wherein the method comprises the following steps: acquiring an access request sent by a data requester for a target data set in an intelligent contract; verifying the data requester based on verification parameters corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified; if the verification is successful, generating a target token for the data requester, and sending the target token to the data requester so that the data requester accesses the target data set based on the target token; the access request comprises a resource verification parameter, the resource verification parameter comprises a first settlement resource and a second settlement resource, and if the first settlement resource is not smaller than the data price of the target data set and the second settlement resource is not smaller than the first guarantee price of the data requester, the resource verification parameter meets the verification passing condition. Through the technical scheme, the data security can be ensured.
Description
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, and a device for sharing and stimulating multiple intelligent contracts based on blockchains.
Background
For a large amount of data on a network, in order to effectively use the data, data sharing is involved, in which users using different computers and different software in different places can read data of other users, and perform various operations, calculation and analysis on the data of other users. After the data sharing is realized, more users can more fully use the existing data resources, and repeated labor such as data collection, data acquisition and the like is reduced. With the continuous development of the information age, the information exchange among different departments and different areas is gradually increased, and the rapid development of computer network technology provides information transmission guarantee for data sharing.
However, because data sharing needs to transmit data between different users, potential safety hazards exist in the data, the data cannot be ensured, the data is used as digital assets of the users, and the users are reluctant to share the data.
Disclosure of Invention
In view of the above, the present application provides a method, an apparatus and a device for sharing and stimulating multiple intelligent contracts based on blockchain, which can reduce data of a transmission terminal device, thereby ensuring data security.
The application provides a shared incentive method of multiple intelligent contracts based on a blockchain, which comprises the following steps:
acquiring an access request sent by a data requester for a target data set in an intelligent contract;
verifying the data requester based on verification parameters corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified, and if any verification parameter does not meet the verification passing condition, the data requester is failed to verify;
if the verification is successful, generating a target token for the data requester, and sending the target token to the data requester so that the data requester accesses the target data set based on the target token;
the access request comprises a resource verification parameter, the resource verification parameter comprises a first settlement resource and a second settlement resource, if the first settlement resource is not smaller than the data price of the target data set and the second settlement resource is not smaller than a first guarantee price of the data requester, the resource verification parameter meets a verification passing condition, and the first guarantee price is determined based on the credibility of the data requester and the data price.
The application provides a shared incentive apparatus for multiple intelligent contracts based on blockchain, the apparatus comprising:
the acquisition module is used for acquiring an access request aiming at a target data set and sent by a data requester;
the verification module is used for verifying the data requester based on verification parameters corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified, and if any verification parameter does not meet the verification passing condition, the data requester is failed to verify; the access request comprises a resource verification parameter, the resource verification parameter comprises a first settlement resource and a second settlement resource, if the first settlement resource is not smaller than the data price of the target data set, the second settlement resource is not smaller than a first guarantee price of the data requester, the resource verification parameter meets a verification passing condition, and the first guarantee price is determined based on the credibility of the data requester and the data price;
and the processing module is used for generating a target token for the data requester and sending the target token to the data requester so that the data requester accesses the target data set in the intelligent contract based on the target token if the data requester is successfully authenticated.
The application provides an electronic device, comprising: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute the machine executable instructions to implement the above-described blockchain-based shared incentive method of multiple intelligent contracts.
In another aspect, the present application provides a machine-readable storage medium storing machine-executable instructions executable by a processor; the processor is configured to execute the machine-executable instructions to implement the above-described blockchain-based shared incentive method of multiple intelligent contracts.
In another aspect, the present application provides a computer program stored on a machine-readable storage medium, which when executed by a processor causes the processor to implement the above-described shared incentive method of blockchain-based multiple intelligent contracts.
As can be seen from the above technical solutions, in the embodiments of the present application, a data provider issues a target data set (i.e., shared data) to an intelligent contract of a blockchain, so that a data requester accesses the target data set in the intelligent contract of the blockchain to obtain data in the target data set. By introducing the blockchain into the data sharing, the data is added to the blockchain, and as the blockchain has non-repudiation and tamper resistance, the possibility of tampering of the data is reduced, and the data accuracy is ensured. The automatic verification of each user access condition is established through the intelligent contract, an incentive mechanism for establishing user sharing data through rewards is supported, the intelligent contract realizes double guarantee price, the guarantee price is inversely proportional to credibility, so that the integrity of all users is ensured, and the users are motivated to share the data.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following description will briefly describe the drawings that are required to be used in the embodiments of the present application or the description in the prior art, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings may also be obtained according to these drawings of the embodiments of the present application for a person having ordinary skill in the art.
FIG. 1 is a flow diagram of a shared incentive method for blockchain-based multiple intelligent contracts;
FIG. 2 is a schematic diagram of a shared incentive for multiple intelligent contracts based on blockchain;
FIG. 3 is a flow diagram of a dataset publishing process in one embodiment of the present application;
FIG. 4 is a flow diagram of a dataset access process in one embodiment of the present application;
FIG. 5 is a schematic diagram of a shared incentive apparatus for blockchain-based multiple smart contracts;
fig. 6 is a hardware configuration diagram of an electronic device in an embodiment of the present application.
Detailed Description
The terminology used in the embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the 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 any or all possible combinations including one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in embodiments of the present application to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, a first message may also be referred to as a second message, and similarly, a second message may also be referred to as a first message, without departing from the scope of the present application. Depending on the context, furthermore, the word "if" used may be interpreted as "at … …" or "at … …" or "in response to a determination".
In the embodiment of the present application, a method for sharing and activating multiple intelligent contracts based on a blockchain is provided, and the method may be applied to a blockchain system, and is shown in fig. 1, and is a schematic flow chart of the method, and the method may include:
For example, the access request may include a resource verification parameter including a first settlement resource and a second settlement resource, the resource verification parameter satisfying a verification pass condition if the first settlement resource is not less than a data price of the target data set and the second settlement resource is not less than a first guarantee price of the data requester, the first guarantee price being determined based on a reputation and the data price of the data requester.
For example, before acquiring the access request for the target data set in the intelligent contract sent by the data requester, an issue request for the target data set sent by the data provider may also be acquired, and the data provider may be authenticated based on an authentication parameter corresponding to the issue request. If each verification parameter corresponding to the release request meets the verification passing condition, the data provider is verified successfully, and if any verification parameter does not meet the verification passing condition, the data provider is verified failed. The issuing request may include a resource verification parameter, where the resource verification parameter may include a third settlement resource, and if the third settlement resource is not less than a second guaranteed price of the data provider, the resource verification parameter satisfies a verification passing condition, and the second guaranteed price is determined based on the credibility and the data price of the data provider. After authenticating the data provider, if the authentication of the data provider is successful, the target data set may be published in the smart contract.
Illustratively, determining the first protection price based on the reputation of the data requestor and the data price may include, but is not limited to: determining a first scale of the data requester based on the reputation of the data requester and determining a first price for the guarantee based on the first scale and the data price for the target data set; wherein the first ratio is proportional to the reputation of the data requestor and the first guaranteed price is inversely proportional to the first ratio. Determining a first ratio of the data requestor based on the reputation of the data requestor may include, but is not limited to: determining a first proportion of data requesters based on the reputation of the data requesters and the liveness of the data requesters; wherein, the credibility represents the evaluation average value of the first data set by the user accessing the first data set, the first data set is the data set issued by the data requester in the intelligent contract, and the liveness represents the successful transaction times of the data requester.
For example, a first proportion of data requesters may be determined based on the following formula:
in the above-mentioned formula(s),
representing a first proportion of data requesters, +.>
Weight coefficient corresponding to the credibility parameter, < ->
Representing the reputation of the data requester, s representing any one node in the blockchain, ++ >
Representing the reputation of node s in the blockchain, +.>
Weight coefficient corresponding to the activity parameter, < +.>
Representing the liveness of the data requester, +.>
Representing the liveness of node s in the blockchain.
Illustratively, determining the second guaranteed price based on the reputation of the data provider and the data price may include, but is not limited to: determining a second proportion of the data provider based on the reputation of the data provider, and determining a second guaranteed price based on the second proportion and the data price of the target data set; wherein the second ratio is proportional to the reputation of the data provider and the second guaranteed price is inversely proportional to the second ratio. Determining a second scale for the data provider based on the reputation of the data provider may include, but is not limited to: determining a second proportion of the data provider based on the reputation of the data provider and the liveness of the data provider; wherein the reputation represents an average of the user's evaluations of the second data set by the user accessing the second data set, the second data set being a data set issued by the data provider in the smart contract, and the liveness representing the number of successful transactions by the data provider.
For example, the second ratio of data providers may be determined based on the following formula:
In the above-mentioned formula(s),
representing a second proportion of the data provider, +.>
Weight coefficient corresponding to the credibility parameter, < ->
Representing the reputation of the data provider, s representing any one node in the blockchain, ++>
Representing the reputation of node s in the blockchain, +.>
Indicating living thingsWeight coefficient corresponding to the jump parameter, +.>
Representing the liveness of the data provider, +.>
Representing the liveness of node s in the blockchain.
Illustratively, the access request may also correspond to at least one of the following authentication parameters: registration verification parameters, release verification parameters, token verification parameters. For example, if the access request corresponds to a registration verification parameter, and the registration verification parameter is used to indicate that the data requester has successfully registered, the registration verification parameter satisfies a verification passing condition. And/or if the access request corresponds to a release verification parameter, and the release verification parameter is used for indicating that the data requester has released the data set in the intelligent contract, the release verification parameter meets the verification passing condition. And/or if the access request corresponds to a token verification parameter, and the token verification parameter is used for indicating that the data requester does not have a token for accessing the target data set, the token verification parameter meets the verification passing condition.
Illustratively, after the data requester accesses the target data set based on the target token, if the data validity information (for indicating that the data in the target data set is valid) sent by the data requester for the target data set is obtained, returning the third settlement resource to the data provider, settling the first settlement resource to the data provider, and returning the second settlement resource to the data requester; alternatively, after expiration of the access time of the target token corresponding to the data requester, the third settlement resource may be returned to the data provider, the first settlement resource may be settled to the data provider, and the second settlement resource may be returned to the data requester.
As can be seen from the above technical solutions, in the embodiments of the present application, a data provider issues a target data set (i.e., shared data) to an intelligent contract of a blockchain, so that a data requester accesses the target data set in the intelligent contract of the blockchain to obtain data in the target data set. By introducing the blockchain into the data sharing, the data is added to the blockchain, and as the blockchain has non-repudiation and tamper resistance, the possibility of tampering of the data is reduced, and the data accuracy is ensured. The automatic verification of each user access condition is established through the intelligent contract, an incentive mechanism for establishing user sharing data through rewards is supported, the intelligent contract realizes double guarantee price, the guarantee price is inversely proportional to credibility, so that the integrity of all users is ensured, and the users are motivated to share the data.
The following describes the technical solution of the embodiment of the present application in conjunction with a specific application scenario.
The embodiment of the application provides a sharing incentive method of multiple intelligent contracts based on a block chain, which can realize data sharing by combining the block chain. The block chain is a chain type data structure formed by combining data blocks in a sequential connection mode according to a time sequence, and a non-falsifiable and non-falsifiable distributed account book ensured in a cryptographic mode is an intelligent contract formed by verifying and storing data by utilizing the block chain type data structure, generating and updating the data by utilizing a distributed node consensus algorithm, ensuring the safety of data transmission and access by utilizing a cryptographic mode and utilizing an automatic script code. Blockchain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm and the like, blockchain is a shared distributed ledger, and transactions of the blockchain are permanently recorded through additional blocks. A smart contract is a computer protocol that aims to propagate, verify or execute contracts in an informative way, allowing trusted transactions to be made without third parties, which transactions are traceable and irreversible, the smart contract encoding business rules in a programmable language onto blocks and being implemented by network participants.
In the embodiment of the application, multiple intelligent contracts are provided for establishing automatic verification of access conditions of each user, supporting establishment of an incentive mechanism of user sharing data through rewards (such as micropayment and the like), and realizing double-guarantee-gold guarantee by the intelligent contracts, wherein the proportion of the guarantee gold is inversely proportional to the reputation value corresponding to a data provider so as to ensure that all participants perform honest, and the user sharing data is motivated, namely the user sharing data is motivated through rewards.
Referring to FIG. 2, which is a schematic diagram of a shared incentive for multiple intelligent contracts based on blockchain, a blockchain system may include, but is not limited to: a registration smart contract module, a dataset smart contract module, a smart contract ownership module, an access smart contract module, a token management smart contract module. Obviously, multiple intelligent contracts are realized through the 5 intelligent contract modules, and different intelligent contracts realize different functions.
And the registration intelligent contract module is used for providing authorization for the data requester and the data provider and providing access monopolization for the data requester and the data provider. For example, a data requester may send a registration request to a blockchain system that registers the data requester through a registration smart contract module, without limitation to the registration process, and after registration of the data requester, may provide authorization to the data requester so that the data requester can access a data set in a smart contract. The data provider may send a registration request to the blockchain system, which registers the data provider through the registration smart contract module, without limitation to the registration process, and may provide authorization to the data provider after registration of the data provider, such that the data provider is able to publish a data set in a smart contract (e.g., a data set smart contract).
The data requesters and the data providers are opposite, and each user is used as a data requester when the user needs to access the data set in the intelligent contract, and is used as a data provider when the user needs to issue the data set in the intelligent contract, so that the user can be used as a data requester or a data provider of the blockchain system as long as the user is registered in the intelligent contract registering module to finish registration.
And the data set intelligent contract module is used for processing data release, data update and user incentive. For example, the data set smart contract module may include, but is not limited to, a data publishing sub-module, a data updating sub-module, and a user incentive sub-module. The data issuing sub-module is used for processing data issuing, the data updating sub-module is used for processing data updating, and the user exciting sub-module is used for processing user excitation.
For example, the data publishing sub-module is configured to interact with a data provider, obtain a data set from the data provider, and publish the data set in a smart contract (e.g., a data set smart contract). The data update sub-module is configured to interact with a data provider, obtain an updated data set from the data provider, and update the data set in a smart contract (e.g., a data set smart contract). The user motivating sub-module interacts with the data provider and the data requester, is capable of obtaining settlement resources from the data requester and providing the settlement resources of the data requester to the data provider, thereby providing a method for the data provider to obtain the settlement resources from the shared data.
An intelligent contract ownership module for defining the connected contracts as owned by the data provider deploying the master contract and connecting to an additional module that allows the data provider to delete its intelligent contracts.
And the access intelligent contract module is connected with the token management intelligent contract module, obtains a token from the token management intelligent contract module and prompts a data requester to access the data set in the intelligent contract based on the token.
For example, the access smart contract module is configured to process an access request of a data requester, and after the data requester is authenticated, send a token to the data requester to enable the data requester to access a data set in the smart contract based on the token. The access intelligent contract module is used for processing access update requests of the data requesters.
The token management smart contract module is configured to process tokens associated with accessing data, for example, a token may be generated for a data requester and sent to the access smart contract module.
The following describes each intelligent contract module of the blockchain system in connection with a specific application scenario.
And the registration intelligent contract module is used for providing authorization for the data requester and the data provider. The data requester sends a registration request to the blockchain system, the blockchain system registers the data requester through the registration smart contract module, and after the data requester registers, authorization can be provided for the data requester so that the data requester can access a data set in a smart contract (such as a data set smart contract). In addition, the data provider sends a registration request to the blockchain system, which registers the data provider through the registration smart contract module, and after registration of the data provider, the data provider may be provided with authorization so that the data provider can publish a data set in a smart contract (e.g., a data set smart contract).
A data publishing sub-module in the data set smart contract module for interacting with the data provider, obtaining the data set from the data provider, and publishing the data set in a smart contract (e.g., a data set smart contract). Wherein the data publishing sub-module ensures that each data set is published on a separate data set smart contract, thereby enabling the data set smart contract to provide a fully recorded structure and change metadata through updates.
In one possible implementation, referring to fig. 3, the data set publishing process may include:
For example, when a data provider needs to publish a data set (for convenience of distinction, the data set is denoted as a target data set), the data publication submodule may obtain a publication request for the target data set.
For example, the issuing request may correspond to at least one verification parameter, if each verification parameter corresponding to the issuing request meets a verification passing condition, the data issuing sub-module determines that the verification of the data provider is successful, and if any verification parameter corresponding to the issuing request does not meet the verification passing condition, the data issuing sub-module determines that the verification of the data provider fails. If the data provider verification is successful, step 303 is performed, and if the data provider verification fails, the data publishing sub-module prohibits the data provider from publishing the target data set in the smart contract.
Illustratively, the verification parameters corresponding to the issue request may include, but are not limited to, at least one of: registering the verification parameters and the resource verification parameters. For example, only the registration verification parameter may be corresponding, or only the resource verification parameter may be corresponding, or both the registration verification parameter and the resource verification parameter may be corresponding.
For example, if the publishing request corresponds to a registration verification parameter, the data publishing sub-module may obtain the registration verification parameter corresponding to the publishing request, where the registration verification parameter is used to indicate that the data provider has successfully registered, or that the data provider has not successfully registered. For example, the data issuing sub-module obtains the registration verification parameter corresponding to the issuing request from the registration intelligent contract module, and obviously, if the data provider is successfully registered, the registration intelligent contract module records the user information, so the data issuing sub-module can obtain the registration verification parameter corresponding to the issuing request, and the registration verification parameter indicates that the data provider is successfully registered. If the data provider does not register successfully, the registration intelligent contract module does not record the user information, so that the data release sub-module can obtain the registration verification parameter corresponding to the release request, and the registration verification parameter indicates that the data provider does not register successfully.
If the registration verification parameter is used to indicate that the data provider has successfully registered, the data publishing sub-module determines that the registration verification parameter meets a verification pass condition. If the registration verification parameter is used to indicate that the data provider has not successfully registered, the data publishing sub-module determines that the registration verification parameter does not satisfy the verification passing condition.
For example, if the issuing request corresponds to a resource verification parameter, for example, the issuing request may include the resource verification parameter, the data issuing sub-module may parse the resource verification parameter from the issuing request, where the resource verification parameter may include a settlement resource (for convenience of distinction, the settlement resource is denoted as a third settlement resource), and the third settlement resource is used as a guarantee of the data provider. For example, when a data provider needs to publish a target data set in a smart contract, a third settlement resource needs to be provided to the smart contract as a guarantee.
If the third settlement resource is not less than the second guaranteed price of the data provider, the data release sub-module determines that the resource verification parameter meets the verification passing condition. If the third settlement resource is smaller than the second guaranteed price of the data provider, the data release sub-module determines that the resource verification parameter does not meet the verification passing condition.
Illustratively, the second guaranteed price is a guaranteed price corresponding to the data provider, which may be an empirically configured guaranteed price, or may be determined based on the reputation (reputation value) of the data provider and the data price of the target data set (the data price of the target data set may be configured by the data provider).
For example, a second scale of the data provider may be determined based on the reputation of the data provider and a second guaranteed price may be determined based on the second scale and the data price of the target data set. Wherein the second ratio is proportional to the reputation of the data provider, i.e., the greater the reputation of the data provider, the greater the second ratio, the less the reputation of the data provider, and the less the second ratio. The second guaranteed price is inversely proportional to the second ratio, i.e. the larger the second ratio, the smaller the second guaranteed price, and the smaller the second ratio, the larger the second guaranteed price. In summary, the second guaranteed price is inversely proportional to the reputation of the data provider, i.e. the greater the reputation of the data provider, the smaller the second guaranteed price, and the greater the reputation of the data provider.
For example, in determining the second proportion of the data provider based on the reputation of the data provider, the second proportion of the data provider may be determined based on the reputation of the data provider and the liveness of the data provider.
For example, the second proportion of the data provider may be determined based on the following formula (1), of course, the formula (1) is only one example, and the determination is not limited as long as the second proportion of the data provider is proportional to the reputation of the data provider and the second proportion is proportional to the liveness of the data provider.
In the case of the formula (1),
representing a second proportion of the data provider, +.>
The weight coefficient corresponding to the credibility parameter can be a value which is configured according to experience, namely ++>
0 or more and 1 or less, < >>
Weight coefficient corresponding to the activity parameter, < +.>
0 or more and 1 or less.
s represents any one node in the blockchain,
representing the reputation of a node s in a blockchain, for example, a blockchain may include a plurality of nodes (including the data provider described above, i.e., representing the data provider described above when s is j) as data requesters and data providers, and for each node, taking node s as an example, the reputation of node s may be obtained>
The acquisition mode is referred to as creditworthiness of the data provider +.>
In addition to the way in which->
A sum value representing the reputation of all nodes of the blockchain.
s represents any one node in the blockchain,
representing the liveness of a node s in a blockchain, for example, the blockchain may include a plurality of nodes, and for each node, taking the node s as an example, the liveness of the node s may be obtained>
The acquisition mode is referred to as liveness +.>
The acquisition mode of (2) is not described in detail herein.
As can be seen from equation (1), the second ratio can be determined based on the reputation of the data provider, the liveness of the data provider, the reputation of all nodes in the blockchain, and the liveness of all nodes in the blockchain, and the second ratio is proportional to the reputation of the data provider, i.e., the greater the reputation the second ratio is, and the second ratio is proportional to the liveness of the data provider, i.e., the greater the liveness the second ratio is.
Illustratively, a second proportion of the data provider may also be determined based on the following equation (2):
In the formula (2) of the present invention,
representing the data provider (i.e. data provider corresponding node +.>
) At->
A second proportion of time of day->
Weight coefficient corresponding to the credibility parameter, < ->
And the weight coefficient corresponding to the liveness parameter is represented. />
Representing that the data provider is->
Reputation of time of day>
Representing that the data provider is->
Time liveness>
The time may be the current time or a time before the current time, which is not limited.
For example, after obtaining the second proportion of the data provider, a second guaranteed price may be determined based on the second proportion and the data price of the target data set, and the second guaranteed price is inversely proportional to the second proportion, i.e., the larger the second proportion, the smaller the second guaranteed price, and the smaller the second proportion, the larger the second guaranteed price.
For example, assume that the data price (configurable by the data provider) of the target data set is
The second guaranteed price may be +.>
*/>
And->
，/>
Representing a second proportion of the data provider, and +.>
Can be greater than or equal to 0 and less than or equal to 1, obviously, the second guaranteed price is compared with the second proportion +.>
Inversely proportional.
In summary, it can be seen that a second proportion corresponding to the data provider can be determined based on the reputation of the data provider, and a second guaranteed price can be determined based on the second proportion and the data price of the target data set.
Based on the second guaranteed price corresponding to the data provider, after the data issuing sub-module parses the third settlement resource (the third settlement resource is used as the guaranteed price of the data provider) from the issuing request, if the third settlement resource is not smaller than the second guaranteed price corresponding to the data provider, the data issuing sub-module determines that the resource verification parameter meets the verification passing condition. If the third settlement resource is smaller than the second guaranteed price corresponding to the data provider, the data release sub-module determines that the resource verification parameter does not meet the verification passing condition.
In summary, the data publishing sub-module in the data set smart contract module may obtain the target data set from the data provider and publish the target data set in a smart contract (e.g., a data set smart contract).
An access smart contract module for processing access requests of the data requesters, after the data requesters are authenticated successfully, a token can be sent to the data requesters to enable the data requesters to access the target data sets in the smart contracts based on the token, and for processing access update requests of the data requesters.
In one possible implementation, referring to fig. 4, the dataset access procedure may include:
For example, when the data requester needs to access the target data set, the access intelligent contract module may issue an access request, and the access intelligent contract module may obtain the access request for the target data set sent by the data requester.
The access request corresponds to at least one verification parameter, if each verification parameter corresponding to the access request meets the verification passing condition, the access intelligent contract module determines that the data requester is verified successfully, and if any verification parameter corresponding to the access request does not meet the verification passing condition, the access intelligent contract module determines that the data requester is verified failed. If the data requester verification is successful, step 403 is performed, and if the data requester verification fails, the access smart contract module prohibits the data requester from accessing the target data set in the smart contract.
Illustratively, the authentication parameters corresponding to the access request may include, but are not limited to, at least one of: registration verification parameters, release verification parameters, token verification parameters, and resource verification parameters. For example, only the registration verification parameter may be corresponding to the resource verification parameter, or both the registration verification parameter and the resource verification parameter may be corresponding to the registration verification parameter, the release verification parameter, the token verification parameter, and the resource verification parameter, which are, of course, only a few examples and are not limited thereto.
For example, if the access request corresponds to a registration verification parameter, the access intelligent contract module obtains the registration verification parameter corresponding to the access request, where the registration verification parameter is used to indicate that the data requester has successfully registered or that the data requester has not successfully registered. For example, the registration verification parameters corresponding to the access request are obtained from the registration intelligent contract module, if the data requester is successfully registered, the registration intelligent contract module records the user information, so as to obtain the registration verification parameters corresponding to the access request, wherein the registration verification parameters indicate that the data requester is successfully registered. If the data requester is not successfully registered, the registration intelligent contract module does not record the user information, so that the registration verification parameters corresponding to the access request are obtained, and the registration verification parameters indicate that the data requester is not successfully registered.
If the registration verification parameter is used for indicating that the data requester has successfully registered, the access intelligent contract module determines that the registration verification parameter meets a verification passing condition. If the registration verification parameter is used for indicating that the data requester is not successfully registered, the access intelligent contract module determines that the registration verification parameter does not meet the verification passing condition.
In summary, when the data requester has successfully registered and the data requester has the same license required to access the target data, it may be determined that the registration verification parameter satisfies the verification passing condition.
For example, if the access request corresponds to a release verification parameter, the access intelligent contract module obtains the release verification parameter corresponding to the access request, where the release verification parameter is used to indicate that the data requester has released the data set in the intelligent contract or has not released the data set in the intelligent contract. For example, the access smart contract module may obtain the release verification parameter corresponding to the access request from the data set smart contract module, determine that the release verification parameter is a data set of the data requester that has been released in the smart contract if the data set smart contract module already has the data set of the data requester, and determine that the release verification parameter is a data set of the data requester that has not been released in the smart contract if the data set smart contract module does not have the data set of the data requester.
If the release verification parameter is used for indicating that the data requester has released the data set in the intelligent contract, determining that the release verification parameter meets the verification passing condition. If the release verification parameter is used for indicating that the data requester does not release the data set in the intelligent contract, determining that the release verification parameter does not meet the verification passing condition.
In summary, when the data requester issues the data set, it is determined that the issue verification parameter satisfies the verification passing condition, that is, only the user who issues the data set may access the target data set in the smart contract, so that a large number of users issue the data set in the smart contract.
For example, if the access request corresponds to the token verification parameter, the access intelligent contract module obtains the token verification parameter corresponding to the access request, where the token verification parameter is used to indicate that the data requester does not have a token for accessing the target data set, or that the data requester already has a token for accessing the target data set. For example, if the access request carries token information of the target data set, determining that the token verification parameter is used for indicating that the data requester already has a token for accessing the target data set, and if the access request does not carry token information of the target data set, determining that the token verification parameter is used for indicating that the data requester does not have a token for accessing the target data set.
If the token verification parameter is used to indicate that the data requester does not have a token accessing the target data set, then it is determined that the token verification parameter satisfies a verification pass condition. If the token verification parameter is used to indicate that the data requester already has a token accessing the target data set, it is determined that the token verification parameter does not satisfy the verification pass condition.
In summary, when the data requester does not have an access token for the target data set, the data requester is allocated a token, that is, the token verification parameter satisfies the verification passing condition, and if the data requester has an access token for the target data set, the data requester does not need to be allocated a token.
For example, if the access request corresponds to a resource verification parameter, such as the access request may include the resource verification parameter, the access smart contract module may parse the resource verification parameter from the access request, where the resource verification parameter may include a first settlement resource and a second settlement resource, and the first settlement resource is used as a payment resource of the target data set, and the second settlement resource is used as a guarantee of the data requester. For example, when a data requester needs to access a target data set in an intelligent contract, a first settlement resource needs to be provided to the intelligent contract as a payment resource for the target data set, and a second settlement resource needs to be provided to the intelligent contract as a deposit.
If the first settlement resource is not less than the data price of the target data set (the data price of the target data set can be configured by the data provider) and the second settlement resource is not less than the first guaranteed price of the data requester, the access intelligent contract module determines that the resource verification parameter meets the verification passing condition. If the first settlement resource is less than the data price of the target data set and/or the second settlement resource is less than the first guaranteed price of the data requester, the intelligent contract module is accessed to determine that the resource verification parameter does not meet the verification passing condition.
Illustratively, the first guaranteed price is a guaranteed price corresponding to the data requester, which may be a guaranteed price configured empirically, or may be determined based on the reputation (reputation value) of the data requester and the data price of the target data set. For example, a first scale of the data requestor may be determined based on the reputation of the data requestor, and a first guarantee price may be determined based on the first scale and the data price of the target data set. The first proportion is proportional to the reputation of the data requester, namely the larger the reputation of the data requester is, the smaller the reputation of the data requester is, and the smaller the first proportion is. The first guaranteed price is inversely proportional to the first ratio, i.e. the larger the first ratio, the smaller the first guaranteed price, the smaller the first ratio, and the larger the first guaranteed price. In summary, the first guaranteed price is inversely proportional to the reputation of the data requester, i.e. the larger the reputation of the data requester, the smaller the first guaranteed price, the smaller the reputation of the data requester, and the larger the first guaranteed price.
For example, in determining the first proportion of the data requester based on the reputation of the data requester, the first proportion of the data requester may be determined based on the reputation of the data requester and the liveness of the data requester.
For example, the first proportion of the data requester may be determined by using the above formula (1), and the determination method is not limited as long as the first proportion of the data requester is proportional to the reputation of the data requester and the first proportion is proportional to the liveness of the data requester, except that the parameter definition in the formula (1) is changed.
In the case of the formula (1),
representing a first proportion of data requesters, +.>
Weight coefficient corresponding to the credibility parameter, < ->
And the weight coefficient corresponding to the liveness parameter is represented. />
Representing the reputation of the data requester, the reputation representing an average of the user's evaluations of the first data set by the user who accessed the first data set, the first data set being the data set issued by the data requester in the smart contract. Assuming that the data requester issues the data set E (may be multiple data sets) in the smart contract, that is, the data set E is used as the first data set, each user accesses the data set E and can evaluate the data set E, so that an average value of the evaluation of the data set E by all the users can be obtained, and the average value of the evaluation is used as the credibility of the data requester. It should be noted that, each time a user accesses the data set E, if the user evaluates the data set E, the average value of the evaluation of the data set E needs to be updated, that is, the reputation of the data requester is updated, that is, the reputation is the reputation of the current moment.
s represents any one node in the blockchain,
representing the reputation of node s in the blockchain, +.>
The sum value representing the reputation of all nodes of the blockchain is not repeated here.
s represents any one node in the blockchain,
representing the liveness of node s in the blockchain, liveness +. >
The acquisition of (a) is referred to as liveness +.>
The acquisition mode of (2) is not described in detail herein.
For example, the first proportion of the data requesters may be determined based on formula (2), which is not described herein.
As can be seen from formulas (1) and (2), the first ratio is determined based on the reputation of the data requester, the liveness of the data requester, the reputation of all nodes in the blockchain, and the liveness of all nodes in the blockchain, and the first ratio is proportional to the reputation of the data requester, i.e., the greater the reputation the greater the first ratio, and the first ratio is proportional to the liveness of the data requester, i.e., the greater the liveness the greater the first ratio.
For example, after the first proportion of the data requester is obtained, the first guarantee price may be determined based on the first proportion and the data price of the target data set, and the first guarantee price is inversely proportional to the first proportion, that is, the larger the first proportion is, the smaller the first guarantee price is, and the smaller the first proportion is, the larger the first guarantee price is.
For example, assume that the data price (configurable by the data requester) of the target data set is
The first guaranteed price may be +.>
*/>
And- >
，/>
A first ratio representing the data requester, and +.>
Can be 0 or more and 1 or less, obviously, the first guaranteed price is equal to or less than the first ratio +.>
Inversely proportional.
In summary, it can be seen that a first ratio corresponding to a data requestor can be determined based on the reputation of the data requestor, and a first guarantee price can be determined based on the first ratio and the data price of the target data set.
Based on the first guaranteed price corresponding to the data requester, the access intelligent contract module analyzes the first settlement resource (serving as the payment resource of the target data set) and the second settlement resource (serving as the guarantee of the data requester) from the access request, and if the first settlement resource is not smaller than the data price of the target data set and the second settlement resource is not smaller than the first guaranteed price of the data requester, the resource verification parameter is determined to meet the verification passing condition. If the first settlement resource is smaller than the data price of the target data set and/or the second settlement resource is smaller than the first guarantee price of the data requester, determining that the resource verification parameter does not meet the verification passing condition.
For example, after verification of the data requester is successful, the access smart contract module is coupled to the token management smart contract module, obtains a target token for the target data set from the token management smart contract module, and sends the target token to the data requester, which accesses the target data set based on the target token.
In one possible implementation, after the data requester accesses the target data set based on the target token, if the data validity information (for indicating that the data in the target data set is valid) sent by the data requester for the target data set is obtained, that is, the data requester confirms that the target data set is valid, the third settlement resource is returned to the data provider (that is, the deposit of the data provider is returned to the data provider), the first settlement resource is settled to the data provider (that is, the payment resource of the data requester for the target data set is settled to the data provider), and the second settlement resource is returned to the data requester (that is, the deposit of the data requester is returned to the data requester), so on, and the resource settlement process is completed.
In another possible embodiment, after the access time of the target token corresponding to the data requester expires, i.e. the data requester has finished the access process of the target data set, a resource settlement process may be performed, and then a third settlement resource may be returned to the data provider, the first settlement resource may be settled to the data provider, and the second settlement resource may be returned to the data requester to complete the resource settlement process.
In one possible implementation, the access intelligence contract module may implement processes such as data access, access update, and relinquishing access, for example, the data requester issues an access request. The access smart contract module establishes a connection with the registration smart contract module to confirm the permissions of the data requester. If the data requester meets all access requirements (i.e., the authentication of the data requester is successful), the access smart contract module will generate a unique token (i.e., a target token) through the token management smart contract module, the target token acting as an access password for the data requester to the target data set. The data requester is granted limited access time. After expiration of the access time, the data requestor may update the access time; alternatively, after the access time expires, the data requestor may relinquish access, actively delete the data copy and access to the data by the data requestor.
A data update sub-module in the data set smart contract module for interacting with the data provider, obtaining an updated data set from the data provider, and updating the data set in a smart contract (e.g., a data set smart contract). For example, when the data set is updated each time, metadata of the data set will be changed, a data requester needs to confirm whether the update of the data set is compliant, if the update of the data set is compliant, the data update sub-module allows the data set to be updated, otherwise, the data update sub-module does not allow the data set to be updated.
Illustratively, the data provider may also change the license needed to access the data set at each update of the data set, and the data update sub-module may delete all license-type erroneous tokens and notify the data requester. All affected data requesters can confirm that they are in compliance with the change and delete their data set copies, revisit the updated data set, and the data provider can determine the data price.
A user incentive sub-module in the data set intelligent contract module is used for interacting with the data provider and the data requester, obtaining settlement resources from the data requester and providing the settlement resources of the data requester to the data provider, for example, the user incentive sub-module is used for completing the following settlement functions: the user incentive sub-module returns the third settlement resource to the data provider, the user incentive sub-module settles the first settlement resource to the data provider, and the user incentive sub-module returns the second settlement resource to the data requester.
In summary, the user incentive sub-module proposes a method for the data provider to obtain settlement resources from the shared data, for example, the user incentive sub-module may implement the function by adopting the following steps:
Step S11, only the rights of the data provider and the data requester registered in the blockchain system are granted.
Step S12, modifying the intelligent contract state of the target data set into a creation state.
Step S13, the data provider determines the data price of the target data set
。
Step S14, the data provider has a guarantee of at least
，/>
And->
Representing that the data provider corresponds to node +.>
A second proportion of time and ∈>
And may be 0 or more and 1 or less. Obviously, guarantee gold->
Second ratio->
The inverse ratio, i.e. the larger the second ratio, the smaller the gold is guaranteed. It should be noted that the second ratio is proportional to the reputation of the data provider, both for the relationship described in the above embodiments.
Step S15, the intelligent contract balance of the target data set is
。
Step S16, the data requester pays at least for the target data set
，/>
Data price for target dataset, +.>
*/>
Representing the assurance of the data requester, +.>
=/>
And->
Representing that the corresponding node of the data requester is +.>
A first proportion of time and ∈>
And may be 0 or more and 1 or less. Obviously, guarantee gold->
*/>
With a first ratio of
Inversely proportional, i.e. the larger the first ratio, the smaller the gold is guaranteed. It should be noted that the first ratio is proportional to the reputation of the data requester, both for the relationship described in the above embodiments.
Step S17, the intelligent contract balance of the target data set is
+/>
+/>
*/>
。
And S18, modifying the intelligent contract state of the target data set into a locking state.
Step S19, the data requester accesses the target data set in the intelligent contract.
Step S20, the data requester confirms that the data in the target data set is valid.
And S21, modifying the intelligent contract state of the target data set into a closed state.
Step S22, deposit the data requester' S deposit
*/>
From the smart contract, back to the data requester.
Step S23, intelligent contract remainder of target data setThe amount is
+/>
。/>
Step S24, intelligent contract balance of target data set
+/>
Forwarded to the data provider.
As can be seen from the above technical solutions, in the embodiments of the present application, a data provider issues a target data set (i.e., shared data) to an intelligent contract of a blockchain, so that a data requester accesses the target data set in the intelligent contract of the blockchain to obtain data in the target data set. By introducing the blockchain into the data sharing, the data is added to the blockchain, and as the blockchain has non-repudiation and tamper resistance, the possibility of tampering of the data is reduced, and the data accuracy is ensured. The automatic verification of each user access condition is established through the intelligent contract, an incentive mechanism for establishing user sharing data through rewards is supported, the intelligent contract realizes double guarantee price, the guarantee price is inversely proportional to credibility, so that the integrity of all users is ensured, and the users are motivated to share the data.
Based on the same application concept as the method, in an embodiment of the present application, a shared incentive apparatus of multiple intelligent contracts based on blockchain is provided, and referring to fig. 5, a schematic structural diagram of the apparatus is shown, where the apparatus includes:
an obtaining module 51, configured to obtain an access request for a target data set sent by a data requester;
a verification module 52, configured to verify the data requester based on a verification parameter corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified, and if any verification parameter does not meet the verification passing condition, the data requester is failed to verify; the access request comprises a resource verification parameter, the resource verification parameter comprises a first settlement resource and a second settlement resource, if the first settlement resource is not smaller than the data price of the target data set, the second settlement resource is not smaller than a first guarantee price of the data requester, the resource verification parameter meets a verification passing condition, and the first guarantee price is determined based on the credibility of the data requester and the data price;
and the processing module 53 is configured to generate a target token for the data requester if the data requester is successfully authenticated, and send the target token to the data requester, so that the data requester accesses the target data set in the smart contract based on the target token.
Illustratively, the obtaining module 51 is further configured to obtain a release request for the target data set sent by the data provider; the verification module 52 is further configured to verify the data provider based on a verification parameter corresponding to the release request; if each verification parameter corresponding to the release request meets the verification passing condition, the data provider is successfully verified, and if any verification parameter does not meet the verification passing condition, the data provider is failed to verify; the issuing request comprises a resource verification parameter, wherein the resource verification parameter comprises a third settlement resource, and if the third settlement resource is not smaller than a second guaranteed price of the data provider, the resource verification parameter meets a verification passing condition, and the second guaranteed price is determined based on the credibility of the data provider and the data price; the processing module 53 is further configured to issue the target data set in an intelligent contract if the data provider authentication is successful.
Illustratively, the verification module 52 is specifically configured to determine a first guaranteed price based on the reputation of the data requestor and the data price: determining a first proportion of the data requesters based on the reputation of the data requesters, determining a first guarantee price based on the first proportion and the data price of the target data set; wherein the first ratio is proportional to the reputation of the data requestor and the first guaranteed price is inversely proportional to the first ratio; the verification module 52 is specifically configured to, when determining the second guaranteed price based on the reputation of the data provider and the data price: determining a second proportion of the data provider based on the reputation of the data provider, and determining a second guaranteed price based on the second proportion and a data price of the target data set; wherein the second ratio is proportional to the reputation of the data provider and the second guaranteed price is inversely proportional to the second ratio.
Illustratively, the verification module 52 is specifically configured to, when determining the first proportion of the data requestor based on the reputation of the data requestor: determining a first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters; the credibility represents an evaluation average value of a user accessing a first data set on the first data set, wherein the first data set is a data set issued by the data requester in the intelligent contract, and the liveness represents the successful transaction times of the data requester; the verification module 52 is specifically configured to, when determining the second proportion of the data provider based on the reputation of the data provider: determining a second proportion of the data provider based on the reputation of the data provider and the liveness of the data provider; the credibility represents an average value of evaluation of a second data set by a user accessing the second data set, the second data set is a data set published by the data provider in the intelligent contract, and the liveness represents the successful transaction times of the data provider.
Illustratively, the verification module 52 is specifically configured to determine a first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters: determining a first ratio of the data requesters based on the following formula: 
The method comprises the steps of carrying out a first treatment on the surface of the Wherein said->
Representing a first proportion of the data requesters, the
Weight coefficient corresponding to the representing credibility parameter, said +.>
Representing the reputation of the data requester, s representing any one node in the blockchain, said +.>
Representing the reputation of a node s in the blockchain, said +.>
Weight coefficient corresponding to the activity parameter, said +.>
Representing the liveness of said data requester, said +.>
Representing the liveness of node s in the blockchain.
Illustratively, the access request corresponds to at least one of the following authentication parameters: registering verification parameters, issuing verification parameters and token verification parameters; if the access request corresponds to a registration verification parameter, and the registration verification parameter indicates that the data requester has successfully registered, the registration verification parameter meets a verification passing condition; if the access request corresponds to a release verification parameter, and the release verification parameter indicates that the data requester has released a data set in an intelligent contract, the release verification parameter meets a verification passing condition; and if the access request corresponds to a token verification parameter and the token verification parameter indicates that the data requester does not have a token for accessing the target data set, the token verification parameter meets a verification passing condition.
Illustratively, the processing module 53 is further configured to, if data valid information for the target data set sent by the data requester is acquired, return the third settlement resource to the data provider, settle the first settlement resource to the data provider, and return the second settlement resource to the data requester; or after the access time of the target token corresponding to the data requester expires, returning the third settlement resource to the data provider, settling the first settlement resource to the data provider, and returning the second settlement resource to the data requester.
Based on the same application concept as the above method, an electronic device is proposed in an embodiment of the present application, and is shown in fig. 6, and includes a processor 61 and a machine-readable storage medium 62, where the machine-readable storage medium 62 stores machine-executable instructions that can be executed by the processor 61; processor 61 is configured to execute machine-executable instructions to implement the blockchain-based multi-intelligence contract sharing incentive method described herein.
Based on the same application concept as the above method, the embodiment of the application further provides a machine-readable storage medium, where a plurality of computer instructions are stored, and when the computer instructions are executed by a processor, the method for sharing and activating multiple intelligent contracts based on blockchain disclosed in the above example can be implemented.
Wherein the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, or the like. For example, a machine-readable storage medium may be: RAM (Radom Access Memory, random access memory), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., hard drive), a solid state drive, any type of storage disk (e.g., optical disk, dvd, etc.), or a similar storage medium, or a combination thereof.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer entity or by an article of manufacture having some functionality. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present application.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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.
Moreover, 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.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.
Claims (9)
1. A method of shared incentive for multiple intelligent contracts based on blockchain, the method comprising:
acquiring an access request sent by a data requester for a target data set in an intelligent contract;
verifying the data requester based on verification parameters corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified, and if any verification parameter does not meet the verification passing condition, the data requester is failed to verify;
if the verification is successful, generating a target token for the data requester, and sending the target token to the data requester so that the data requester accesses the target data set based on the target token;
the access request comprises a resource verification parameter, wherein the resource verification parameter comprises a first settlement resource and a second settlement resource, and if the first settlement resource is not smaller than the data price of the target data set and the second settlement resource is not smaller than a first guarantee price of the data requester, the resource verification parameter meets a verification passing condition, and the first guarantee price is determined based on the credibility of the data requester and the data price;
The determining a first protection price based on the reputation of the data requestor and the data price includes: determining a first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters, and determining a first guarantee price based on the first proportion and the data price; wherein the reputation represents an average of the evaluations of a first data set by a user who accesses the first data set, the first data set being a data set published by the data requester in the smart contract; the liveness represents a number of successful transactions by the data requester, the number of successful transactions being a sum of a number of times the data requester accesses a data set and a number of times the first data set is accessed;
wherein the determining the first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters comprises:
determining a first ratio of the data requesters based on the following formula:
wherein, the liquid crystal display device comprises a liquid crystal display device,
representing a first proportion of said data requesters, < >>
Weight coefficient corresponding to the credibility parameter, < ->
Representing the data requestCreditworthiness of the seeker, s represents any node in the blockchain, ++ >
Representing the reputation of node s in the blockchain, +.>
Weight coefficient corresponding to the activity parameter, < +.>
Representing the liveness of said data requester, < >>
Representing liveness of a node s in the blockchain;
wherein the access request also corresponds to the following authentication parameters: issuing verification parameters;
if the release verification parameter indicates that the data requester has released a data set in an intelligent contract, the release verification parameter meets a verification passing condition; and if the release verification parameter is used for indicating that the data requester does not release the data set in the intelligent contract, the release verification parameter does not meet the verification passing condition.
2. The method of claim 1, wherein prior to the obtaining the access request sent by the data requester for the target data set in the smart contract, the method further comprises:
acquiring a release request for a target data set sent by a data provider;
verifying the data provider based on verification parameters corresponding to the release request; if each verification parameter corresponding to the release request meets the verification passing condition, the data provider is successfully verified, and if any verification parameter does not meet the verification passing condition, the data provider is failed to verify; the release request comprises a resource verification parameter, the resource verification parameter comprises a third settlement resource, if the third settlement resource is not smaller than a second guaranteed price of the data provider, the resource verification parameter meets a verification passing condition, and the second guaranteed price is determined based on the credibility of the data provider and the data price;
And if the verification is successful, the target data set is issued in the intelligent contract.
3. The method of claim 2, wherein the step of determining the position of the substrate comprises,
the determining a second guaranteed price based on the reputation of the data provider and the data price comprises: determining a second proportion of the data provider based on the reputation of the data provider, and determining a second guaranteed price based on the second proportion and the data price; wherein the second ratio is proportional to the reputation of the data provider and the second guaranteed price is inversely proportional to the second ratio.
4. The method of claim 3, wherein the step of,
the determining a second ratio of the data provider based on the reputation of the data provider comprises: determining a second proportion of the data provider based on the reputation of the data provider and the liveness of the data provider; wherein the reputation represents an average of the evaluations of a second data set by users who have accessed the second data set, and the second data set is a data set issued by the data provider in the intelligent contract, and the liveness represents the number of successful transactions of the data provider.
5. The method according to any of claims 1-4, wherein the access request corresponds to at least one of the following authentication parameters: registering verification parameters and token verification parameters;
if the access request corresponds to a registration verification parameter, and the registration verification parameter indicates that the data requester has successfully registered, the registration verification parameter meets a verification passing condition;
and if the access request corresponds to a token verification parameter and the token verification parameter indicates that the data requester does not have a token for accessing the target data set, the token verification parameter meets a verification passing condition.
6. The method of any of claims 2-4, wherein after the data requestor accesses the target data set based on the target token, the method further comprises:
if the data effective information sent by the data requester for the target data set is obtained, returning the third settlement resource to the data provider, settling the first settlement resource to the data provider, and returning the second settlement resource to the data requester; or alternatively, the process may be performed,
and after the access time of the target token corresponding to the data requester expires, returning the third settlement resource to the data provider, settling the first settlement resource to the data provider, and returning the second settlement resource to the data requester.
7. A shared incentive apparatus for multiple intelligent contracts based on blockchain, the apparatus comprising:
the acquisition module is used for acquiring an access request aiming at a target data set and sent by a data requester;
the verification module is used for verifying the data requester based on verification parameters corresponding to the access request; if each verification parameter corresponding to the access request meets the verification passing condition, the data requester is successfully verified, and if any verification parameter does not meet the verification passing condition, the data requester is failed to verify; the access request comprises a resource verification parameter, the resource verification parameter comprises a first settlement resource and a second settlement resource, if the first settlement resource is not smaller than the data price of the target data set, the second settlement resource is not smaller than a first guarantee price of the data requester, the resource verification parameter meets a verification passing condition, and the first guarantee price is determined based on the credibility of the data requester and the data price;
the processing module is used for generating a target token for the data requester and sending the target token to the data requester if the data requester is successfully verified, so that the data requester accesses the target data set in the intelligent contract based on the target token;
The verification module is specifically configured to, when determining a first guaranteed price based on the reputation of the data requester and the data price: determining a first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters, and determining a first guarantee price based on the first proportion and the data price; wherein the reputation represents an average of the evaluations of a first data set by a user who accesses the first data set, the first data set being a data set published by the data requester in the smart contract; the liveness represents a number of successful transactions by the data requester, the number of successful transactions being a sum of a number of times the data requester accesses a data set and a number of times the first data set is accessed;
wherein the verification module is specifically configured to, when determining the first proportion of the data requesters based on the reputation of the data requesters and the liveness of the data requesters: determining a first ratio of the data requesters based on the following formula:
the method comprises the steps of carrying out a first treatment on the surface of the Wherein said->
Representing a first proportion of said data requesters, said +.>
Weight coefficient corresponding to the representing credibility parameter, said +. >
Information representative of the data requesterReputation, s denotes any node in the blockchain, said +.>
Representing the reputation of a node s in the blockchain, said +.>
Weight coefficient corresponding to the activity parameter, said +.>
Representing the liveness of said data requester, said +.>
Representing liveness of a node s in the blockchain;
wherein the access request also corresponds to the following authentication parameters: issuing verification parameters;
if the release verification parameter indicates that the data requester has released a data set in an intelligent contract, the release verification parameter meets a verification passing condition; and if the release verification parameter is used for indicating that the data requester does not release the data set in the intelligent contract, the release verification parameter does not meet the verification passing condition.
8. The apparatus of claim 7, wherein the device comprises a plurality of sensors,
the acquisition module is further used for acquiring a release request aiming at a target data set, wherein the release request is sent by a data provider; the verification module is further used for verifying the data provider based on verification parameters corresponding to the release request; if each verification parameter corresponding to the release request meets the verification passing condition, the data provider is successfully verified, and if any verification parameter does not meet the verification passing condition, the data provider is failed to verify; the issuing request comprises a resource verification parameter, wherein the resource verification parameter comprises a third settlement resource, and if the third settlement resource is not smaller than a second guaranteed price of the data provider, the resource verification parameter meets a verification passing condition, and the second guaranteed price is determined based on the credibility of the data provider and the data price; the processing module is further configured to issue the target data set in an intelligent contract if the data provider verifies successfully;
Wherein the verification module is specifically configured to, when determining a second guaranteed price based on the reputation of the data provider and the data price: determining a second proportion of the data provider based on the reputation of the data provider, and determining a second guaranteed price based on the second proportion and a data price of the target data set; wherein the second ratio is proportional to the reputation of the data provider, and the second guaranteed price is inversely proportional to the second ratio;
wherein the verification module is specifically configured to, when determining the second proportion of the data provider based on the reputation of the data provider: determining a second proportion of the data provider based on the reputation of the data provider and the liveness of the data provider; wherein the reputation represents an average of the evaluations of a second data set by a user who accesses the second data set, and the second data set is a data set issued by the data provider in the intelligent contract, and the liveness represents the successful transaction times of the data provider;
wherein the access request corresponds to at least one of the following authentication parameters: registering verification parameters and token verification parameters; if the access request corresponds to a registration verification parameter, and the registration verification parameter indicates that the data requester has successfully registered, the registration verification parameter meets a verification passing condition; if the access request corresponds to a token verification parameter and the token verification parameter indicates that the data requester does not have a token for accessing the target data set, the token verification parameter meets a verification passing condition;
The processing module is further configured to, if data valid information for the target data set sent by the data requester is acquired, return the third settlement resource to the data provider, settle the first settlement resource to the data provider, and return the second settlement resource to the data requester; or after the access time of the target token corresponding to the data requester expires, returning the third settlement resource to the data provider, settling the first settlement resource to the data provider, and returning the second settlement resource to the data requester.
9. An electronic device, comprising: a processor and a machine-readable storage medium storing machine-executable instructions executable by the processor; the processor is configured to execute machine executable instructions to implement the method of any of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310295550.XA CN115996226B (en) | 2023-03-17 | 2023-03-17 | Shared incentive method, device and equipment for multiple intelligent contracts based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310295550.XA CN115996226B (en) | 2023-03-17 | 2023-03-17 | Shared incentive method, device and equipment for multiple intelligent contracts based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115996226A CN115996226A (en) | 2023-04-21 |
| CN115996226B true CN115996226B (en) | 2023-06-27 |
Family
ID=85995466
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310295550.XA Active CN115996226B (en) | 2023-03-17 | 2023-03-17 | Shared incentive method, device and equipment for multiple intelligent contracts based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115996226B (en) |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190333054A1 (en) * | 2018-04-20 | 2019-10-31 | Infonetworks Llc | System for verification of pseudonymous credentials for digital identities with managed access to personal data on trust networks |
| US11296895B2 (en) * | 2018-09-12 | 2022-04-05 | Bitclave Pte. Ltd. | Systems and methods for preserving privacy and incentivizing third-party data sharing |
| CN109685501B (en) * | 2018-12-04 | 2023-04-07 | 暨南大学 | Auditable privacy protection deep learning platform construction method based on block chain excitation mechanism |
| CN110473058A (en) * | 2019-07-25 | 2019-11-19 | 广东工业大学 | A kind of shared platform method of commerce based on block chain credit value |
| CN113792301A (en) * | 2021-03-08 | 2021-12-14 | 北京沃东天骏信息技术有限公司 | Block chain-based Internet of things data access method and device |
| CN113268543A (en) * | 2021-05-19 | 2021-08-17 | 重庆邮电大学 | Block chain-based security content sharing management method in Internet of vehicles |
| CN113987080A (en) * | 2021-12-28 | 2022-01-28 | 国网区块链科技(北京)有限公司 | Block chain excitation method and device based on reputation consensus and related products |
| CN114546970B (en) * | 2022-02-25 | 2024-04-05 | 山东大学 | Data sharing method and system based on participant alliance chain excitation |
| CN114612248A (en) * | 2022-03-11 | 2022-06-10 | 蚂蚁区块链科技(上海)有限公司 | Service processing method, device, equipment and system based on block chain |
-
2023
- 2023-03-17 CN CN202310295550.XA patent/CN115996226B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN115996226A (en) | 2023-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11907947B2 (en) | Resource transfer system | |
| US20210250353A1 (en) | Decentralized identities for access to multiple computing resource systems | |
| US20210166203A1 (en) | System and process for tokenization of digital media | |
| US11652605B2 (en) | Advanced non-fungible token blockchain architecture | |
| US20220172201A1 (en) | Controlling asset access based on payments via a distributed ledger | |
| JP2021184274A (en) | Method for secure peer-to-peer communication on blockchain | |
| JP2023184749A (en) | Method of distributing block chain-registered digital asset, and autonomous computation agent | |
| US11699202B2 (en) | Method and system to facilitate gamified arbitration of smart contracts | |
| KR20200091882A (en) | Incremental digital asset collateral wallet | |
| TW201937436A (en) | Blockchain based transaction execution method and device and electronic equipment | |
| KR20190133573A (en) | Block Chain Trading System with Smart Contract And That way | |
| JP2019511766A (en) | Method and system for efficient transfer of entities in a blockchain | |
| US20210192541A1 (en) | Account owner funding of know your customer and accredited investor verification renewal and monitoring charges through coin payment | |
| US11652604B2 (en) | Blockchain data compression and storage | |
| Reddy et al. | Blockchain as a disruptive technology in healthcare and financial services-A review based analysis on current implementations | |
| US20200118093A1 (en) | System and method for arbitrating a blockchain transaction | |
| US20230108610A1 (en) | Systems for secure data replication and original destruction using a blockchain distributed ledger | |
| US20230298001A1 (en) | Non-fungible token (nft) purchase and transfer system | |
| CN115996226B (en) | Shared incentive method, device and equipment for multiple intelligent contracts based on block chain | |
| US20210295283A1 (en) | Methods and systems for blockchain digital currency stake delegation | |
| JP7308977B2 (en) | Method, transaction management device and computer readable medium for facilitating concurrent trading | |
| JP7490916B1 (en) | Information processing device | |
| WO2022118565A1 (en) | Control method, control device, and program | |
| US20240007479A1 (en) | Method and apparatus for decentralized management of trusted data on trustless networks | |
| KR20230162348A (en) | Operation method of NFT terminal device based on sharing mobility activity information using block chain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |