Blockchain-based tender information processing method and device

Abstract

The application discloses a blockchain-based bidding information processing method and device, computer equipment and a storage medium, and belongs to the network technology and blockchain technology fields. The technical scheme provided by the application embodiment enables the bidding content information published on the platform to be real and reliable by recording the bidding content information of the bidding institutions that have passed authentication on the platform in the blockchain system, so that the subsequent bidding process can be simple, efficient, and the data can be open and transparent.

Description

Technical Field

[0001] This application relates to the fields of network technology and blockchain technology, and in particular to a blockchain-based bidding information processing method, apparatus, computer equipment and storage medium. Background Technology

[0002] In recent years, with the rapid development of my country's economy and society, the scale of commercial projects has continued to expand, and the number has increased year by year.

[0003] In a market economy, high transparency in the bidding process for commercial projects and simplicity and efficiency in the performance of commercial contracts have always been two major demands of business entities. For bidders, the more public the bidding information, the wider its reach and the easier it is to find suitable bidders; for bidders, the more transparent the bidding process, the fairer they can compete with other competitors. Therefore, there is an urgent need for a bidding information processing method that can ensure simplicity, efficiency, and transparency in the bidding process. Summary of the Invention

[0004] This application provides a blockchain-based method, apparatus, computer equipment, and storage medium for processing bidding information, which enables a simplified and efficient bidding process, as well as data openness and transparency. The technical solution is as follows:

[0005] On the one hand, a blockchain-based bidding information processing method is provided, applied to node devices in a blockchain system, including:

[0006] In response to the first user's operation of publishing bidding content information, the bidding information of the first user is obtained. The bidding information carries bidding content information, the user identifier of the first user, and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process.

[0007] The target smart contract identifier carried in the bidding information is queried in the blockchain system.

[0008] If it is determined through querying that the target smart contract has been deployed in the blockchain system, the bidding information is verified, and after the verification is passed, the publication operation of the bidding content information is triggered;

[0009] Write the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract;

[0010] After the blockchain system reaches a consensus on the transaction execution results based on the bidding information and the bidding information, the block containing the transaction execution results based on the bidding information and the bidding information is stored on the blockchain of the blockchain system.

[0011] In one possible implementation, before querying the blockchain system based on the target smart contract identifier, the method further includes:

[0012] The bidding information also carries the first user's public key and digital signature. The legality of the digital signature is verified based on the public key. If the verification passes, the step of querying in the blockchain system is executed.

[0013] In one possible implementation, writing the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract includes:

[0014] The target smart contract is written with the content feature value of the bidding content information as the key, and the bidding content information, the user identifier of the second user, and the feature value of the bidding information as the value.

[0015] Using the content feature value of the bidding content information as the key, the bidding content data is written into the corresponding bidding list in the target smart contract.

[0016] In one possible implementation, the method further includes:

[0017] When it is detected that any clause in the cooperation framework agreement is satisfied, at least one processing flow corresponding to the satisfied clause is triggered.

[0018] In one possible implementation, the method further includes:

[0019] The execution result of the processing flow corresponding to the satisfied terms is written into the target smart contract.

[0020] In one possible implementation, the method further includes:

[0021] In response to obtaining the authentication certificate of any user, obtain the certificate feature value of the authentication certificate of the user;

[0022] If the certificate feature value of the authentication certificate is not found to be stored on the blockchain, then the certificate feature value of the authentication certificate and the authentication certificate are written into the target smart contract.

[0023] After the blockchain system reaches a consensus on the authentication certificate, a block containing the authentication certificate and its feature value will be stored on the blockchain.

[0024] Output a successful on-chain message, which carries the on-chain result and the certificate feature value of the authentication certificate.

[0025] On the one hand, a blockchain-based bidding information processing device is provided, which is applied to node devices in a blockchain system, including:

[0026] The acquisition module is used to acquire the bidding information of the first user in response to the release operation of the bidding content information of the first user. The bidding information carries the bidding content information, the user identifier of the first user and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process.

[0027] The query module is used to query the blockchain system based on the target smart contract identifier carried in the bidding information;

[0028] The verification module is used to verify the bidding information if it is determined through querying that the target smart contract has been deployed in the blockchain system.

[0029] The publishing module is used to trigger the publishing operation of the bidding content information after the verification is passed;

[0030] The contract writing module is used to write the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract.

[0031] The block storage module is used to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the consensus on the bidding information and the bidding information is passed by the blockchain system.

[0032] In one possible implementation, the verification module is configured to perform any one or a combination of the following verification procedures:

[0033] Based on the content feature value of the bidding content information, query the blockchain to see if there is already bidding content information with the same content feature value as the bidding content information. If there is, the verification fails. If not, and all other verification processes have been completed, the verification passes.

[0034] The bidding information also carries the certificate feature value of the first user's first authentication certificate. Based on the certificate feature value, the blockchain is queried to see if an authentication certificate with the certificate feature value is already included. If not, the verification fails. If so, and all other verification processes have been completed, the verification passes.

[0035] The bidding information also carries the public key of the first user. If the first authentication certificate is found, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, the verification fails. If they match and all other verification processes have been completed, the verification passes.

[0036] In one possible implementation, the contract writing module is used to write the target smart contract with the content feature value of the bidding content information as the key and the bidding content information and the user identifier of the first user as the value.

[0037] The content feature value of the bidding information is used as the key, and the feature value of the bidding information is used as the value, to write the target smart contract.

[0038] In one possible implementation, the bidding information also carries the first user's public key and digital signature. The verification module is also used to verify the legality of the digital signature based on the public key. If the verification passes, the step of querying in the blockchain system is executed.

[0039] In one possible implementation, the device further includes an output module for outputting a successful on-chain message, the successful on-chain message carrying the transaction execution result based on the bidding information, the content feature value of the bidding content information, and the feature value of the bidding information.

[0040] In one possible implementation, the device further includes:

[0041] The bidding information acquisition module is used to respond to the bidding operation of the second user on the bidding content information published by the first user, and to acquire the bidding information of the second user. The bidding information carries the bidding content information, the content feature value of the target bidding content information, the user identifier of the second user, and the identifier of the target smart contract.

[0042] The query module is also used to perform a query in the blockchain system based on the target smart contract identifier in the bidding information;

[0043] The verification module is further configured to verify the bidding information if it is determined through querying that the target smart contract has been deployed in the blockchain system.

[0044] The bidding module is used to trigger a bidding operation based on the bidding content information after the verification is passed;

[0045] The contract writing module is also used to write the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract;

[0046] The block storage module is also used to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the blockchain system has reached a consensus on the transaction execution results based on the bidding information and the bidding information.

[0047] In one possible implementation, the contract writing module is further configured to write the target smart contract with the content feature value of the bidding content information as the key, and the bidding content information, the user identifier of the second user, and the feature value of the bidding information as the value;

[0048] Using the content feature value of the bidding content information as the key, the bidding content data is written into the corresponding bidding list in the target smart contract.

[0049] In one possible implementation, the device further includes:

[0050] The protocol acquisition module is used to respond to the protocol publishing operation of the first user and acquire the protocol framework information of the first user. The protocol framework information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user.

[0051] The contract writing module is also used to set the signing status of the cooperation framework agreement to "first user has signed" after the verification of the agreement framework information is passed, and to write the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the signing status into the target smart contract.

[0052] The block storage module is also used to write a block containing the first write result into the blockchain after the blockchain system has reached a consensus on the first write result. The first write result is used to indicate whether the write based on the signing status was successful.

[0053] The information output module is used to output the first writing result and the protocol framework information of the first user to the target second user.

[0054] In one possible implementation, the device further includes:

[0055] The signing information acquisition module is used to respond to the agreement signing operation of the target second user and acquire the agreement signing information of the target second user. The agreement signing information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user.

[0056] The contract writing module is also used to update the signing status of the cooperation framework agreement to effective after the verification of the agreement signing information is passed, and to write the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the updated signing status into the target smart contract.

[0057] The block storage module is also used to write a block containing the second write result into the blockchain after the blockchain system has reached a consensus on the second write result. The second write result is used to indicate whether the write based on the updated signature status was successful.

[0058] The information output module is also used to output the second writing result to the first user.

[0059] In one possible implementation, the device further includes:

[0060] The triggering module is used to trigger at least one processing flow corresponding to the satisfied clause when it is detected that any clause in the content of the cooperation framework agreement is satisfied.

[0061] In one possible implementation, the contract writing module is further configured to write the execution result of the processing flow corresponding to the satisfied terms into the target smart contract.

[0062] In one possible implementation, the apparatus further includes: a certificate processing module configured to, in response to obtaining the authentication certificate of any user, obtain the certificate feature value of the user's authentication certificate;

[0063] If the certificate feature value of the authentication certificate is not found to be stored on the blockchain, then the certificate feature value of the authentication certificate and the authentication certificate are written into the target smart contract.

[0064] After the blockchain system reaches a consensus on the authentication certificate, a block containing the authentication certificate and its feature value will be stored on the blockchain.

[0065] Output a successful on-chain message, which carries the on-chain result and the certificate feature value of the authentication certificate.

[0066] The method provided in this application embodiment records the bidding content information of certified bidding agencies on the blockchain system, thereby making the bidding content information published on the platform authentic and reliable, and enabling the subsequent bidding process to be simple and efficient, as well as the data to be open and transparent. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0068] Figure 1 This is a schematic diagram of the implementation environment of a bidding information processing method provided in an embodiment of this application;

[0069] Figure 2 This is a schematic diagram of an authentication certificate acquisition process provided in an embodiment of this application;

[0070] Figure 3 This is a schematic diagram of a smart contract deployment process provided in an embodiment of this application;

[0071] Figure 4 This is a schematic diagram of a bidding information processing flow provided in an embodiment of this application;

[0072] Figure 5 This is a schematic diagram of a bidding information processing flow based on bidding information provided in an embodiment of this application;

[0073] Figure 6 This is a schematic diagram of a contract signing process provided in an embodiment of this application;

[0074] Figure 7 This is a schematic diagram of a blockchain structure provided in an embodiment of this application;

[0075] Figure 8 This is a schematic diagram of the structure of a bidding information processing device provided in an embodiment of this application;

[0076] Figure 9 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0078] To facilitate understanding of the technical processes involved in the embodiments of this application, some terms used in the embodiments of this application are explained below:

[0079] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each block contains information about a network transaction, used to verify the validity of the information (anti-counterfeiting) and generate the next block. Each block contains a timestamp and a link to the previous block. In a narrow sense, blockchain is a chain-like data structure that combines data blocks sequentially according to time, and is a distributed ledger that is cryptographically guaranteed to be immutable and unforgeable; that is, data in the blockchain is irreversible once recorded. Blockchain uses a one-way hash algorithm, and each newly generated block strictly follows a chronological order. The irreversibility and irreversibility of time make any attempt to tamper with the data in the blockchain easily traceable, leading to rejection by other nodes and extremely high costs for forgery, thus limiting related illegal activities.

[0080] A consensus mechanism is a mathematical algorithm used in a blockchain system to establish trust and assign rights among different nodes. In a blockchain system, transactions can be verified and confirmed in a very short time through voting by specific nodes. If several nodes with unrelated interests can reach a consensus on a transaction, it can be assumed that all nodes in the system can also reach a consensus on it.

[0081] A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. In a blockchain system, each node automatically executes a contract program based on specific conditions. This program can manipulate data stored on the chain and serves as a crucial means for users to interact with the blockchain and leverage it to implement business logic. The purpose of smart contracts is to provide a more secure method than traditional contracts and reduce other transaction costs associated with contracts. They allow for trusted transactions without a third party, and these transactions are traceable and irreversible.

[0082] Public key and private key: These are key pairs (a public key and a private key) obtained through an algorithm. The public key is the publicly known part of the key pair, while the private key is the private key. Public keys are commonly used for encrypting data, verifying digital signatures, etc. This algorithm ensures that the resulting key pair is unique. When using this key pair, if data is encrypted with one key, it must be decrypted with the other key. For example, data encrypted with the public key must be decrypted with the private key, and vice versa; otherwise, decryption will fail.

[0083] Figure 1 This is a schematic diagram illustrating the implementation environment of a blockchain-based bidding information processing method provided in this application embodiment. See also... Figure 1 The implementation environment includes a first server 110, a second server 120, and a blockchain system 130.

[0084] Among them, the first server 110 may refer to the server of the investment cooperation framework platform, which can provide bidding services to enterprises, institutions and government agencies through web pages or application clients.

[0085] The second server 120 can refer to the server of a CA (Certificate Authority), which can provide authentication services online or offline. For example, when providing authentication services offline, the party needing the service can provide supporting documents to the CA for authentication. If the CA approves the authentication, it can issue an electronic certificate. Similarly, when providing authentication services online, the second server 120 can provide authentication services to enterprises, institutions, and government agencies through web pages or application clients. The party needing the service can provide electronic materials online to the CA for authentication. If the CA approves the authentication, it can issue an electronic certificate.

[0086] The aforementioned first server 110 and second server 120, along with other servers, can be cloud computing platforms, virtualization centers, etc. When providing services, they can be provided in the form of access servers, business servers, and databases. Access servers provide access services to terminals. Business servers provide backend services related to business processing. The database can include server-related databases, such as databases of supporting documents, bidding information, and user information. Different services provided by the server can correspond to different databases. There can be one or more business servers. When there are multiple business servers, at least two business servers provide different services, and / or at least two business servers provide the same service, such as providing the same service through load balancing. This application embodiment does not limit this.

[0087] Furthermore, the aforementioned first server 110 may be a server connected to the blockchain system 130, which may include multiple node devices. Each node device can execute the relevant steps of the blockchain-based bidding information processing method provided in this application embodiment. In this application embodiment, the multiple node devices can share data based on the blockchain. In one possible implementation, the blockchain system can be any of a private chain, a public chain, or a consortium chain, and the data sharing of the blockchain system can be directed to multiple node devices within the system. Of course, the server 140 may also be a node device in the blockchain system, and this application embodiment does not limit this.

[0088] In a blockchain system, a node device is a data processing node that receives and processes data transmitted from outside. After processing the target data transmitted from outside and obtaining the data to be stored, the node device can broadcast the data to be stored within the blockchain system. Upon receiving the data, the consensus node device in the blockchain system performs consensus calculations. After consensus is achieved, the target data can be used to generate data blocks according to the corresponding chained hash table.

[0089] Consensus nodes are the devices that participate in the consensus process within a blockchain system. Their primary purpose is to verify the authenticity of the content being shared. The number of consensus nodes participating in the consensus process can be greater than six. Common consensus algorithms used by these nodes to execute consensus operations include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT), among others.

[0090] Of course, the above implementation environment may also include terminal 140. Enterprise users, public institution users and other institutional users can use terminal 140 to use the services provided by at least one of the first server 110, the second server 120 and the blockchain system 130. Terminal 140 can refer to one of multiple terminals. This embodiment only uses terminal 140 as an example.

[0091] Those skilled in the art will understand that the number of terminals described above can be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more, in which case other terminals may also be included in the above implementation environment. This application does not limit the number of terminals or the type of device in its embodiments.

[0092] All parties involved in the aforementioned investment cooperation framework platform, bidding agencies (such as government agencies, enterprises, public institutions, or non-profit entities), and bidding organizations are required to obtain certification from a CA (Certificate Authority). Furthermore, to facilitate data storage and sharing through the blockchain system, the certification certificates must be stored on the blockchain to ensure the smooth operation of the bidding project. See also... Figure 2 The following explanation will use the authentication process jointly completed by a CA (Certificate Authority) and a blockchain system as examples.

[0093] 201. The first server sends an authentication request to the second server, which carries the first user's authentication data.

[0094] The qualification data can be data issued by an authoritative institution to prove qualifications, and may include enterprise certification data, financial certification data, etc. For example, enterprise certification data may be electronic copies of business licenses, financial certification data may be audit results data, credit rating certification data, institutional rating data, etc. This application embodiment does not limit this.

[0095] The aforementioned "first user" can refer to the platform's affiliated organization. The first user's qualification data can carry signature data based on the private key of a pair of asymmetric keys generated locally on the first server, thus ensuring the security of the qualification data. When sending a qualification authentication request, the digital signature and the public key from the asymmetric key can be included in the authentication request. Accordingly, step 201 can be replaced by the following step: The first server digitally signs the qualification data based on the public key from the locally generated asymmetric key, and sends the qualification data, the public key from the asymmetric key, and the signature data obtained from the signature in the qualification authentication request to the second server.

[0096] 202. After receiving the qualification authentication request, the second server verifies the qualification data carried in the qualification authentication request.

[0097] In this embodiment of the application, after receiving the qualification certification request, the second server can extract the qualification data carried, query the corresponding authoritative institution based on the type of qualification data, and verify the qualification data based on the query results. For example, for enterprise certification data, it can query through the website of the Administration for Industry and Commerce to determine whether the enterprise is legal and exists.

[0098] It should be noted that the above query process can be a manual query, or it can be based on the type of qualification data to determine the query entry point of the authoritative institution's server, thereby automatically triggering a query request based on the query entry point of the authoritative institution's server, carrying the qualification data to be queried in the query request, and after receiving the query results based on the query request, determining whether the qualification data is true and reliable based on the query results, thereby realizing the verification of qualification data.

[0099] If the authentication request carries signed authentication data, the signed data can be verified based on the public key carried in the authentication request. If the verification passes, it is confirmed that the data was indeed sent by the first user, and the above verification process can be performed based on the authentication data.

[0100] 203. If the second server verifies the qualification data carried in the qualification authentication request and issues an authentication certificate to the first server, the authentication certificate will be sent to the blockchain system.

[0101] After successful verification, the second server can issue an authentication certificate to the first server. This certificate is in electronic data form, which can be transmitted over a network and stored on a storage medium. After issuing the certificate, the second server can generate transaction data that conforms to the blockchain system's data format and send the transaction data to the blockchain system, thus achieving the goal of putting the authentication certificate on the blockchain.

[0102] The second server can sign the authentication certificate so that the blockchain system can verify its legitimacy. The key used for signing the certificate can be the key of the second server.

[0103] 204. After receiving the authentication certificate issued by the second server to the first user, the blockchain system obtains the certificate feature value of the authentication certificate according to the first smart contract, which is used to instruct the processing logic of the authentication certificate.

[0104] The first smart contract can be a pre-deployed smart contract in the blockchain system, used to implement the processing logic for the authentication certificate provided by the user. This first smart contract can be considered a storage space for storing authentication-related data, and the processing logic it indicates can include querying the authentication certificate, storing the authentication certificate, etc., which are not limited in this embodiment.

[0105] After receiving the authentication certificate, the node device of the blockchain system can perform a legality verification to ensure the legality of the data. After the legality verification is passed, the storage process of the authentication certificate is executed based on the first smart contract.

[0106] In one possible implementation, the node devices of the blockchain system can perform feature value acquisition and subsequent steps through virtual machines. As a mechanism that can run independently of other virtual machines, virtual machines can provide relatively exclusive hardware resources for the process, so that the storage process can be unaffected by other devices.

[0107] The process of obtaining the certificate feature value of the authentication certificate, taking the feature value as a hash value as an example, can include: the node device in the blockchain system performs a hash algorithm on the authentication certificate to obtain the digest hash of the authentication certificate.

[0108] 205. The blockchain system queries whether the first smart contract stores an authentication certificate with the certificate feature value based on the certificate feature value of the authentication certificate. If it does, proceed to step 206; otherwise, proceed to step 207.

[0109] The first smart contract can be used to store authenticated certificates. This storage can be done using the certificate's signature value as the key and the certificate itself as the value. Upon receiving an authentication certificate from any user, the contract can query whether the same certificate is already stored based on its signature value. Specifically, the query can be based on the signature value. If the first smart contract already has a key equal to the signature value, it means the certificate is already stored, and the storage step is skipped; instead, step 206 is executed, returning a failure result. If no key equals the signature value, it means the certificate is not stored, and step 207 (certificate storage) is executed.

[0110] 206. If the blockchain system finds that the first smart contract does not store an authentication certificate with the certificate feature value based on the certificate feature value of the authentication certificate, then the execution failure result is output.

[0111] 207. If the blockchain system finds an authentication certificate with the certificate feature value stored on the blockchain based on the certificate feature value of the authentication certificate, the blockchain system writes the certificate feature value of the authentication certificate and the authentication certificate into the first smart contract.

[0112] In step 207, writing the certificate feature value of the authentication certificate and the authentication certificate into the first smart contract can be done using the key-value method described above. That is, the certificate feature value of the authentication certificate is used as the key, and the authentication certificate is used as the value.

[0113] 208. After the blockchain system reaches a consensus on the write result, the blockchain system stores the write result on the blockchain. The write result is used to indicate the certificate feature value of the authentication certificate and whether the authentication certificate has been successfully written.

[0114] After the first smart contract is written, the blockchain system can also reach a consensus on the writing result. Once the consensus is reached, the blockchain system can store the writing result on the blockchain in the form of blocks.

[0115] 209. The blockchain system sends a successful on-chain message to the second server. The successful on-chain message carries the on-chain result and the certificate feature value of the authentication certificate.

[0116] 210. After receiving the successful on-chain message, the second server sends a qualification authentication pass message to the first server. The qualification authentication pass message carries the authentication certificate and the certificate feature value of the authentication certificate.

[0117] 211. After receiving the qualification authentication pass message, the first server stores the authentication certificate and the certificate feature value of the authentication certificate.

[0118] After the above process is completed, the blockchain system can feed back the on-chain result and the certificate feature value of the certification certificate to the CA institution. This allows the CA institution to determine whether the blockchain system has stored the certification certificate or not. Based on whether it has been stored, the CA institution can determine whether the qualification certification process is complete. After receiving the on-chain success message, the CA institution can send the certification certificate and the certificate feature value of the certification certificate to the first server to notify the platform that the qualification certification has been completed. This allows the platform to subsequently provide bidding services based on the certification certificate and certificate feature value of the first server.

[0119] For bidding and tendering agencies, the qualification authentication process can be conducted through the first server, following a similar procedure to the aforementioned qualification authentication process. Bidding agencies can register on the first server for real-name authentication, which then generates an asymmetric key for them. This key interacts with the second server to complete the authentication process. After the second server returns the bidding agency's authentication certificate and certificate signature to the first server, the first server can output these documents to the bidding agency for safekeeping by its staff. Alternatively, the output can be made on the client side, storing the authentication certificate and certificate signature in the bidding agency's client for use in subsequent bidding processes. Similarly, bidding agencies can obtain their own authentication certificate and certificate signature through the same process and store them in their client for use in subsequent bidding processes.

[0120] For the first server, namely the investment cooperation framework platform, it is also necessary to deploy the target smart contract in the blockchain system to execute the bidding logic for the bidding service. The specific deployment process can be shown in the following process.

[0121] 301. In response to the smart contract deployment operation, the first server sends first transaction data to the blockchain system, the first transaction data including the target smart contract, the certificate feature value of the first server's authentication certificate, and the public key.

[0122] Before providing services, the first server can trigger the contract deployment process through smart contract deployment operations performed on the first server. The first server can send the target smart contract to the blockchain system in the form of a transaction. When sending the transaction, the first server can carry the certificate feature value of the authentication certificate obtained by the first server through authentication in the transaction data to prove that the first server has been certified by a CA and that its authentication certificate has been stored in the blockchain system. The first server can also carry its public key for verification such as legitimacy.

[0123] The target smart contract can be data that has been signed with a private key by a first server, so that the blockchain system can verify it based on the public key after receiving the first transaction data.

[0124] 302. After receiving the first transaction data, the blockchain system obtains the contract characteristic value of the target smart contract.

[0125] After receiving the first transaction data, any node device in the blockchain system can perform a legality verification to ensure the legality of the data. After the legality verification is passed, the storage process of the target smart contract is then executed.

[0126] In one possible implementation, the node devices of the blockchain system can perform feature value acquisition and subsequent steps through virtual machines. As a mechanism that can run independently of other virtual machines, virtual machines can provide relatively exclusive hardware resources for the process, so that the storage process can be unaffected by other devices.

[0127] The process of obtaining the contract feature value of the target smart contract described above, taking the feature value as a hash value as an example, can include: the node device in the blockchain system performing a hash algorithm on the target smart contract to obtain the digest hash of the target smart contract.

[0128] Of course, if the blockchain system passes the above-mentioned legality verification, it can execute step 303 below. If the legality verification fails, it can return a verification failure result and end the process.

[0129] 303. The blockchain system uses the contract's characteristic value as the contract identifier for querying.

[0130] In a blockchain system, pre-configured smart contracts can be stored based on contract identifiers. These identifiers can be contract feature values. Specifically, they can be stored using the smart contract's feature value as the key and the target smart contract as the value. Upon receiving a smart contract from any user, the system can query whether the same smart contract already exists in the blockchain based on its feature value. If a key equal to the feature value already exists in the blockchain, it means the target smart contract is already stored, and the storage step is skipped; instead, step 304 is executed, returning a failure result. If no key equals the feature value, it means the target smart contract is not stored, and step 305 is executed.

[0131] 304. If a smart contract with the contract identifier is found to have been deployed, output an execution failure result and proceed to step 308.

[0132] The execution failure result may include the first transaction data and an execution failure label to indicate that the first transaction data failed to execute. Additionally, the execution failure result may also include a reason for the execution failure, such as information about duplicate contract deployment, to indicate the cause of the failure.

[0133] 305. If no smart contract with the contract identifier is found to be deployed in the blockchain system, the authentication certificate is queried through the certificate feature value of the first server's authentication certificate. If the query fails, the execution failure result is output.

[0134] The execution failure result may include the first transaction data and an execution failure label to indicate that the first transaction data failed to execute. Additionally, the execution failure result may include a reason for the failure, such as information that the authentication certificate failed verification, to indicate the cause of the execution failure.

[0135] In one possible implementation, the execution failure result can also carry verification process information to indicate at which verification process the execution failure occurred. For example, if the verification based on the contract feature value passes, but the verification based on the certificate feature value fails, the execution failure result can carry the information "contract not deployed repeatedly, authentication certificate failed verification" to indicate the verification results of each stage of the above verification process. This greatly improves the first server's perception capability, enabling the first server to know where the problem is, and thus update the first transaction data accordingly before triggering the deployment of the smart contract.

[0136] 306. If the authentication certificate of the first server is found in the blockchain system, compare whether the public key in the first transaction data is consistent with the public key of the stored authentication certificate. If they are inconsistent, output the execution failure result.

[0137] This public key-based verification is performed on the premise that the blockchain system has stored the authentication certificate. For each stored authentication certificate, there is a corresponding public key of the authentication authority. Therefore, the consistency can be compared based on the stored public key, thereby improving data security through multiple verification methods.

[0138] 307. If and only if all the above verifications are successful, the target smart contract shall be stored in the blockchain system with the contract feature value of the target smart contract as the key and the target smart contract as the value.

[0139] In this embodiment of the application, the target smart contract can be written into the cache of the node device of the blockchain system, so as to process the received transaction data based on the processing logic in the target smart contract.

[0140] 308. If the blockchain system reaches a consensus on the transaction execution result based on the first transaction data, the first transaction data will be stored on the blockchain.

[0141] It should be noted that the execution of the first transaction data may result in two outcomes: either the transaction fails or it succeeds. In either case, to ensure the authenticity of the data, it is stored on the blockchain based on consensus. This also ensures that the behavior of the first server can be traced, further improving data security.

[0142] 309. The blockchain system sends a successful on-chain message to the first server. The successful on-chain message includes the first transaction data, the transaction execution result of the first transaction data, and the contract identifier of the target smart contract.

[0143] It should be noted that after a node device in a blockchain system outputs an execution failure result, the node device returns the execution failure result to the first server. The first server can then learn of the failure based on this execution failure result, thereby triggering the process of redeploying the smart contract.

[0144] 310. After receiving the successful on-chain message, the first server stores the first transaction data, the transaction execution result of the first transaction data, and the contract identifier of the target smart contract.

[0145] After receiving the successful on-chain message, the first server can store its content to know whether the target smart contract has been deployed in the blockchain system. If the deployment is successful, the contract identifier of the target smart contract obtained from the deployment can be applied to the subsequent bidding service process.

[0146] The first server can deploy the target smart contract through steps 301 to 310 described above. This deployment allows the first server to implement the processing logic provided by the target smart contract through the blockchain system, thereby providing a bidding information processing process for institutional users who need to conduct bidding. When any institutional user triggers the bidding service on the first server, the first server can obtain the contract identifier of the stored target smart contract. In the process of interacting with the blockchain system, the first server can notify the blockchain system to process transaction data based on the target smart contract, such as processing the information provided by the bidding party, processing the information provided by the bidder, and processing information during the contract signing process.

[0147] The above deployment process can be carried out when the first server starts providing bidding services, so that subsequent institutional users who log in to the platform can conduct bidding and tendering based on the target smart contract. The following describes the bidding information processing process based on the deployed target smart contract. The bidding information processing process specifically includes the release of bidding information, the acquisition of tender information, and the signing process. The first step is to introduce the process of releasing bidding information, that is, the process by which bidding institutional users release bidding information to the outside world through the platform and put the bidding information on the blockchain.

[0148] 401. The blockchain system receives bidding information from a first user sent through a first server. The bidding information carries bidding content information, the user identifier of the first user, and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process.

[0149] The "first user" refers to the institutional user who publishes the bidding information. This institution can be a government agency, enterprise, non-profit organization, etc. After logging into the first server, the first user can publish the bidding information, triggering a response from the first server. In response, the first server sends the first user's identifier, the target smart contract's identifier, and the bidding information provided by the first user to the blockchain system in the form of transaction data, enabling the blockchain system to receive the bidding information. The first user's bidding information can be digitally signed using their private key, allowing the blockchain system to verify it using their public key upon receipt.

[0150] Of course, since the above embodiments also describe the content about the first user obtaining an authentication certificate, in order to enable the first user to use the bidding service, the bidding information of the first user may also include the certificate feature value of the first user's authentication certificate.

[0151] 402. The blockchain system performs a query within the blockchain system based on the target smart contract identifier.

[0152] By querying based on the target smart contract identifier, it can be determined whether the target smart contract has been deployed in the blockchain system, thereby determining whether to provide the corresponding service to the first user. In one example, the node device of the blockchain system can use the target smart contract identifier as a query index to query whether the blockchain system stores a smart contract that uses the target smart contract identifier as a key. If it does, step 403 is executed; otherwise, an execution failure result can be returned.

[0153] In one possible implementation, the node device of the blockchain system can also perform a legality verification after receiving the bidding information. That is, before querying the blockchain system based on the target smart contract identifier, the method further includes: the bidding information also carries the public key and digital signature of the first user, and the legality of the digital signature is verified based on the public key. If the verification passes, the step of querying the blockchain system based on the target smart contract identifier is executed; if the verification fails, a verification failure result is returned, thereby ensuring the legality of the bidding service.

[0154] In one possible implementation, the node devices of the blockchain system can execute the query step through a virtual machine. As a mechanism that can run independently of other virtual machines, the virtual machine can provide relatively exclusive hardware resources for the process, so that subsequent processes can be unaffected by other devices.

[0155] 403. If it is determined through querying that the target smart contract has been deployed in the blockchain system, the blockchain system verifies the bidding information. After the verification is successful, it triggers the publication operation of the bidding content information.

[0156] In this embodiment of the application, the verification of bidding information may include a combination of multiple verification processes to ensure the authenticity of the bidding information and the reliability of the data. After the verification is passed, the first server can be triggered to publish the bidding content information. The triggering process may include the blockchain system sending a publishing instruction to the first server, and the first server responding to the publishing instruction by publishing the bidding content information on the webpage maintained by the first server.

[0157] The verification of the bidding information includes any one or a combination of the following verification processes:

[0158] Based on the content feature value of the bidding content information, query the blockchain to see if there is already bidding content information with the same content feature value as the bidding content information. If there is, the verification fails. If not, and all other verification processes have been completed, the verification passes.

[0159] The bidding information also carries the certificate feature value of the first user's first authentication certificate. Based on the certificate feature value, the blockchain is queried to see if an authentication certificate with the certificate feature value is already included. If not, the verification fails. If it is, and all other verification processes have been completed, the verification passes.

[0160] The bidding information also carries the public key of the first user. If the first authentication certificate is found, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, the verification fails. If they match and all other verification processes have been completed, the verification passes.

[0161] The above verification process can be combined and configured based on data requirements. This application does not limit the specific combination of these processes. For example, taking one verification process as an example, one combination of the above verification process is illustrated: The node device of the blockchain system determines whether the target smart contract has been deployed in the blockchain system through the target smart contract identifier. If not, an execution failure result is returned. If deployed, the blockchain is queried based on the content feature value of the bidding content information to see if bidding content information with the same content feature value is included. If so, an execution failure result is returned. If not, the blockchain is queried based on the certificate feature value of the first user's first authentication certificate to see if an authentication certificate with that certificate feature value is included. If not, an execution failure result is returned. If so, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, an execution failure result is returned; if they match, the verification passes. This verification process can determine whether the above-mentioned bidding service is provided and can also ensure data security.

[0162] 404. The blockchain system writes the content feature value of the bidding information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract.

[0163] In one possible implementation, the node devices of the blockchain system can write to the target smart contract using the content feature value of the bidding information as the key, and the bidding information and the user identifier of the first user as the value; and write to the target smart contract again using the content feature value of the bidding information as the key and the feature value of the bidding information as the value. This storage method allows for querying the corresponding bidding information and bidding publisher information based on the content feature value of the bidding information, and also allows for querying whether the corresponding bidding information has been published based on its content feature value.

[0164] 405. After the blockchain system reaches a consensus on the transaction execution result based on the bidding information and the bidding information, the block containing the transaction execution result based on the bidding information and the bidding information will be stored on the blockchain of the blockchain system.

[0165] It should be noted that the transaction execution results based on the bidding information can include two types: transaction execution failure and transaction execution success. For either result, in order to ensure the authenticity of the data, it is stored on the blockchain based on consensus, which also ensures that the behavior of the first server can be traced, further improving the security of the data.

[0166] 406. The blockchain system sends a successful on-chain message to the first server. The successful on-chain message carries the transaction execution result based on the bidding information, the content feature value of the bidding content information, and the feature value of the bidding information.

[0167] It should be noted that after a node device in a blockchain system outputs an execution failure result, the node device returns the execution failure result to the first server. The first server can then know about the failure based on the execution failure result, thereby triggering the re-release process.

[0168] It should be noted that after receiving the successful on-chain message, the first server can store its content to know whether the bidding information has been stored in the blockchain system, and inform the first user that the bidding information it published has been successfully on-chain and published, so that the first user can know its progress.

[0169] The first server can realize the platform publication and blockchain storage of bidding information through the above steps 401 to 406, thereby ensuring the authenticity and traceability of the bidding information.

[0170] The above describes the process of publishing bidding information. The following section introduces the process of obtaining bidding information, that is, the process by which bidding agencies can submit bids based on the bidding information published on the platform and upload the bidding information to the blockchain through the platform. Specifically, this may include the following steps.

[0171] 501. The blockchain system receives the bidding information of the second user. The bidding information carries the content feature value of the bidding content information, the user identifier of the second user, and the identifier of the target smart contract.

[0172] The second user refers to the institutional user who publishes the bidding information. This institution can be an enterprise, non-profit organization, etc. After logging into the first server, the second user can perform a bidding operation on the bidding information published by the first user. The server can then bid on the bidding information based on the bidding information published by the first user. The specific process may include: the second user initiates a bidding operation; the first server responds by obtaining the bidding information from the first user; and the first server, in response to the bidding operation, sends the bidding information, the content feature value of the target bidding information, the user identifier of the second user, and the identifier of the target smart contract to the blockchain system in the form of transaction data, enabling the blockchain system to receive the bidding information. The second user's bidding information can be digitally signed based on the second user's private key, allowing the blockchain system to verify the bidding information based on the public key carried in the bidding information upon receipt.

[0173] Of course, since the above embodiments also describe the content about the second user obtaining an authentication certificate, in order to enable the second user to use the bidding service, the second user's bidding information may also include the certificate feature value of the second user's second authentication certificate.

[0174] 502. The blockchain system performs a query within the blockchain system based on the target smart contract identifier.

[0175] Step 502 is the same as step 402, and will not be described in detail here.

[0176] 503. If it is determined through querying that the target smart contract has been deployed in the blockchain system, the blockchain system verifies the bidding information. After the verification is successful, a bidding operation based on the bidding content information is triggered.

[0177] The verification step in step 503 can be the same as the verification step in step 403. After the verification is successful, the blockchain system can return a trigger message to the first server to trigger the first server to perform the bidding operation for the second user.

[0178] 504. The blockchain system writes the content feature value of the bid information, the user identifier of the second user, and the feature value of the bid information into the target smart contract.

[0179] In one possible implementation, step 504 can be implemented using the following process: writing the bid content information to the target smart contract using its content feature value as the key, and the bid content information, the second user's user identifier, and the bid information's feature value as the value; then writing the bid content data to the corresponding bid list in the target smart contract using the bid feature value of the tender content information as the key. This bid list records the bid content data of each second user who has bid on the first user's tender content information, thereby enabling the identification of users who have submitted bids and the various data items they have submitted.

[0180] 505. After the blockchain system reaches a consensus on the transaction execution result and the bid information, the blockchain system will store the block containing the transaction execution result and the bid information on the blockchain system's blockchain.

[0181] 506. The blockchain system sends a successful on-chain message to the first server. The successful on-chain message carries the transaction execution result based on the bidding information and the feature value of the bidding information.

[0182] It should be noted that after a node device in a blockchain system outputs an execution failure result, the node device returns the execution failure result to the first server. The first server can then know about the failure based on the execution failure result, thereby triggering the re-release process.

[0183] It should be noted that after receiving the successful on-chain message, the first server can store its content to know whether the bidding information has been stored in the blockchain system, and inform the first user and the second user that the bidding information has been successfully on-chained and published, so that both the first user and the second user can know its progress.

[0184] The first server can realize the platform publication and blockchain storage of bidding information through the above steps 501 to 506, thereby ensuring the authenticity and traceability of the bidding information.

[0185] Based on the release of bidding and tendering information, the first user can determine the winning bidder from among multiple second users who have submitted bids. Alternatively, this process can be handled by the first server, which runs a target algorithm model based on the conditions for the winning bidder outlined in the first user's tender information to output a suggested winning bidder or directly output the winning bidder. After determining the winning bidder using either implementation method, the first user can initiate a contract signing process based on the first server. The following describes the processing steps of this contract signing process.

[0186] 600. In response to the protocol publishing operation of the first user, the first server sends the protocol framework information of the first user to the blockchain system. The protocol framework information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user.

[0187] The bidding agency user, also known as the first user, can log in to the first server to initiate the signing process, provide the first server with the content of the cooperation framework agreement, and perform the signing operation based on the content of the cooperation framework agreement. This allows the first server to generate the first user's agreement framework information based on the content of the cooperation framework agreement, the user identifier of the first user, and the user identifier of the target second user identified by the first user as the winning user.

[0188] Of course, the protocol framework information can also be digitally signed based on the first user's private key, so that the blockchain system can verify it based on the public key carried in the first user's protocol framework information after receiving it.

[0189] 601. The blockchain system receives the protocol framework information of the first user.

[0190] In one possible implementation, after receiving the protocol framework information, the blockchain system can query based on the target smart contract identifier carried in the protocol framework information to determine whether the target smart contract has been deployed in the blockchain system, thereby determining whether to provide a signing service to the first user. In one example, the node device of the blockchain system can use the target smart contract identifier as a query index to query whether the blockchain system stores a smart contract that uses the target smart contract identifier as a key. If so, the verification process in step 602 is executed; if not, an execution failure result can be returned.

[0191] In one possible implementation, the node device of the blockchain system can also perform a legality verification after receiving the protocol framework information of the first user. That is, the method also includes: the protocol framework information of the first user also carries the first user's public key and digital signature, and the legality of the digital signature is verified according to the public key. If the verification passes, the subsequent steps are executed to ensure the legality of the bidding service; if the verification fails, a verification failure result is returned.

[0192] In one possible implementation, the node devices of the blockchain system can execute the query step through a virtual machine. As a mechanism that can run independently of other virtual machines, the virtual machine can provide relatively exclusive hardware resources for the process, so that subsequent processes can be unaffected by other devices.

[0193] 602. After the verification of the agreement framework information is passed, the blockchain system sets the signing status of the cooperation framework agreement to "first user has signed", and writes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the signing status into the target smart contract.

[0194] The verification may include verification based on the identifier of the target smart contract and other verification processes as shown in the above embodiments, which are not limited in this application embodiment. If any verification process fails, an execution failure result can be returned to indicate that the protocol framework information verification has failed. For example, a verification process is described as follows: The node device of the blockchain system can query whether the smart contract has been deployed by the identifier of the target smart contract. If not, an execution failure result is returned. If it has been deployed, the node device can query whether the corresponding authentication certificate is stored by the certificate feature value of the first user's first authentication certificate. If the query fails, an execution failure result is returned. The node device further compares whether the public key in the authentication certificate is consistent with the public key in the protocol framework information. If they are inconsistent, an execution failure result is returned. The node device can query whether the bidding content information is stored by the content feature value of the bidding content information. If the query fails, an execution failure result is returned. The node device verifies whether the user identifier of the first user carried in the protocol framework information is consistent with the user identifier in the investment information. If they are inconsistent, an execution failure result is returned. The node device can query whether the bidding content information is stored by the content feature value of the bidding content information. If the query fails, an execution failure result is returned. The signing and writing process in step 602 is executed only if all the above verifications are successful. The verification objects and the execution order of the verification process are only one example. In some possible implementations, the number of verification objects can be reduced or increased, and the specific execution order of verification can be changed. This application does not specifically limit this.

[0195] It should be noted that the signing status of the above-mentioned contract framework agreement may include the agreement signing user and its corresponding signing status. The specific signing process can be based on the processing logic recorded by the target smart contract, and this application embodiment does not limit this.

[0196] 603. After the consensus on the first write result is passed in the blockchain system, the block containing the first write result is written into the blockchain.

[0197] The first write result is used to indicate whether the write based on the signature status in step 602 above was successful.

[0198] 604. The blockchain system feeds back the first write result and the protocol framework information of the first user to the first server.

[0199] After the node device of the blockchain system confirms that the on-chain data has been successfully uploaded, it can feed back the first write result and the protocol framework information of the first user to the first server to notify the first user that the contract has been completed. This will then trigger the first server to notify the target second user to sign the contract. By uploading the contract completion and the protocol framework information to the blockchain, the bidding results are made real, reliable, fair and transparent.

[0200] 605. The first server sends the first write result and the protocol framework information of the first user to the target second user.

[0201] The second target user can choose whether to sign a contract based on their own needs. If they decide to sign, they can execute the agreement signing operation to trigger step 606 and subsequent processes.

[0202] 606. In response to the agreement signing operation of the target second user, the first server sends the agreement signing information of the target second user to the blockchain system. The agreement signing information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bid content information of the target second user.

[0203] The winning bidder, also known as the target second user, can log in to the first server to sign the agreement. Before signing the agreement, the target second user can trigger a query process based on the identifier of the cooperation framework agreement to query the content of the cooperation framework agreement stored in the blockchain system. The query results are then compared with the content of the cooperation framework agreement displayed by the first server. If they match, the agreement signing operation can be executed to initiate the signing process. This allows the first server to generate the agreement signing information of the target second user based on the content of the cooperation framework agreement, the user identifier of the first user, the user identifier of the target second user identified by the first user as the winning bidder, and the agreement signing operation.

[0204] Of course, the protocol framework information can also be digitally signed based on the private key of the target second user, so that the blockchain system can verify it based on the public key carried in the protocol signing information of the target second user after receiving the protocol signing information.

[0205] 607. The blockchain system receives the agreement signing information from the target second user.

[0206] In one possible implementation, after receiving the agreement signing information from the target second user, the blockchain system can query based on the target smart contract identifier carried in the agreement signing information to determine whether the target smart contract has been deployed in the blockchain system, thereby determining whether to provide signing services to the second user. In one example, the node device of the blockchain system can use the target smart contract identifier as a query index to query whether a smart contract using the target smart contract identifier as a key is stored in the blockchain system. If so, the verification process in step 608 is executed; otherwise, an execution failure result can be returned.

[0207] In one possible implementation, the node device of the blockchain system can also perform a legality verification after receiving the protocol signing information of the target second user. That is, the method also includes: the protocol signing information of the target second user also carries the public key and digital signature of the second user, and the legality of the digital signature is verified according to the public key. If the verification passes, the subsequent steps are executed to ensure the legality of the bidding service; if the verification fails, a verification failure result is returned.

[0208] In one possible implementation, the node devices of the blockchain system can execute the query step through a virtual machine. As a mechanism that can run independently of other virtual machines, the virtual machine can provide relatively exclusive hardware resources for the process, so that subsequent processes can be unaffected by other devices.

[0209] 608. After the verification of the signing information of the agreement is passed, the blockchain system updates the signing status of the cooperation framework agreement to be effective, and writes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the updated signing status into the target smart contract.

[0210] The verification may include verification based on the identifier of the target smart contract and other verification processes as shown in the above embodiments, which are not limited in this application. If any verification process fails, an execution failure result can be returned to indicate that the verification has failed. For example, a verification process is described as follows: The node device of the blockchain system can query whether the smart contract has been deployed by the identifier of the target smart contract. If not, an execution failure result is returned. If it has been deployed, the node device can query whether the corresponding authentication certificate is stored by the certificate feature value of the first authentication certificate of the first user (or the second authentication certificate of the second user, or both). If the query fails, an execution failure result is returned. The node device can further compare whether the public key in the stored authentication certificate is consistent with the public key in the protocol signing information. If they are inconsistent, an execution failure result is returned. The node device can also query whether the cooperation framework protocol exists by the identifier of the cooperation framework protocol. If the query fails, an execution failure result is returned. The node device can query whether the content feature value of the cooperation framework protocol content stored on the chain is consistent with the content feature value of the cooperation framework protocol content carried in the protocol signing information. If they are inconsistent, an execution failure result is returned. The process involves several steps: First, verifying whether the signing status indicates the first user has signed. If not, returning an execution failure result. Second, verifying whether the stored user identifier of the first user (or the target second user's user identifier, or both) matches the user identifier of the first user (or the target second user's user identifier, or both) carried in the agreement signing information. If not, returning an execution failure result. Third, verifying whether the stored and carried cooperation framework agreement content matches. If not, returning an execution failure result. Fourth, verifying whether the content feature values ​​of the stored first user's bidding content information and the target second user's bid content information match the corresponding content feature values ​​of the carried first user's bidding content information and the target second user's bid content information. If not, returning an execution failure result. Only if all the above verifications are successful will step 608 (updating the signing status and writing process) be executed. The verification objects and execution order of this process are only one example. In some possible implementations, the verification objects can be reduced or increased, and the specific verification execution order can be changed. This application embodiment does not specifically limit this.

[0211] It should be noted that the signing status of the above-mentioned contract framework agreement may include the agreement signing user and its corresponding signing status. The specific signing process can be based on the processing logic recorded by the target smart contract, and this application embodiment does not limit this.

[0212] 609. After the blockchain system reaches a consensus on the second write result, the blockchain system will write the block containing the second write result into the blockchain.

[0213] The second write result is used to indicate whether the write process based on the updated signature status in step 608 was successful.

[0214] 610. The blockchain system sends the second write result back to the first server.

[0215] 611. In response to the received second write result, the first server sends a successful subscription message to the first user and the second user respectively.

[0216] After confirming successful on-chain processing, the node device of the blockchain system can send the second write result back to the first server to notify the target second user that the contract has been completed. This triggers the first server to notify the first user and the target second user to execute the agreement. By storing the signed status on the chain, the bidding results are made real, reliable, fair and transparent.

[0217] A blockchain system can automate the execution of a signed cooperation framework agreement based on a target smart contract. Specifically, when the blockchain system detects that any clause in the cooperation framework agreement is satisfied, it triggers at least one processing step corresponding to that satisfied clause. The blockchain system also writes the execution result of the processing step corresponding to the satisfied clause into the target smart contract, so that the execution of the agreement can be recorded through a smart contract. The following is a specific example illustrating this automated execution process.

[0218] Taking land approval as an example, the blockchain system, based on the terms of the cooperation framework agreement, detects that the current time meets the trigger time of the land approval process, and then generates corresponding operation task requests. For example, it can generate an approval request to inform the relevant government agencies to quickly approve the land and issue the land approval document. It can also generate a business registration request to notify the Administration for Industry and Commerce of the above-mentioned enterprise information and the cooperation framework agreement for business registration. Furthermore, it can generate a fund transfer request to inform the bank to transfer funds from the enterprise after the relevant documents and land approval are obtained.

[0219] To execute the above process, automated execution logic can be generated based on the content of the cooperation framework agreement. This automated execution logic can be configured as an oracle smart contract. That is, when the blockchain system triggers any task in the cooperation framework agreement, a corresponding operation task can be created through the oracle smart contract based on the task. The triggering conditions and completion conditions of each stage of the task can be configured in the operation task. For example, sending a processing request to the target server, the content carried by the processing request, etc. After receiving the processing result returned by the server, it is determined whether to trigger the next stage based on the processing result. If the completion conditions of the task are met, the task execution result is written to the target smart contract or the status of the corresponding task in the cooperation framework agreement is updated.

[0220] For example, when a blockchain system triggers an approval process, a corresponding operation task can be created through an oracle smart contract. This task is then communicated to oracle task nodes deployed outside the blockchain system. Upon receiving the land approval task, the task nodes quickly approve the land through the government agency's interface and send the approval results and documents back to the oracle smart contract deployed within the blockchain system. The oracle smart contract stores the received approval data and then informs the target smart contract, which updates the relevant status according to the cooperation framework agreement. Similarly, the target smart contract can use an oracle smart contract to ensure the smooth registration process with the Administration for Industry and Commerce and update the relevant status according to the cooperation framework agreement. After obtaining the relevant documents and data as agreed upon in the cooperation framework agreement, the target smart contract can use an oracle smart contract to instruct the bank to transfer funds from the company's account and write the bank transfer data into the target smart contract via the oracle smart contract.

[0221] The status of each stage of each agreement's performance can be updated through the corresponding processing procedures described above. The first and second users can then query the status of the agreement's performance through a blockchain explorer, truly achieving a simple and efficient process as well as open and transparent data.

[0222] The method provided in this application, by recording the bidding information of certified bidding agencies on the blockchain system, ensures the authenticity and reliability of the bidding information published on the platform. This enables a simplified and efficient bidding process, as well as greater data openness and transparency. Furthermore, both bidding and tendering agencies are certified by the platform and issued public and private keys, with their authentication certificates recorded on the blockchain for subsequent contract signing, guaranteeing the reliability of the bidding participants. Moreover, in addition to recording bidding information on the blockchain, bidding information is also processed on the blockchain, and the signing process of the cooperation framework agreement based on the bidding and tender information is also conducted on the blockchain, thus achieving a closed-loop contract signing process and on-chain record-keeping, significantly improving data openness and transparency. Furthermore, blockchain systems can also automatically execute tasks according to the terms of the agreement based on oracle smart contracts to achieve automatic performance, such as notifying government agencies to approve projects, land approvals and other public services, banks to transfer corporate funds to purchase land, corporate registration, and recording progress data on the blockchain based on the progress of the above tasks. This solves many problems in traditional government investment promotion and cooperation, reduces costs, improves efficiency, and enhances government credibility.

[0223] The following describes the block generation and storage process involved in the above embodiments. Specifically, each node device in the blockchain system can receive the transaction execution result. Taking any node device as an example, the node device can generate the first block based on the information received within a certain period of time and broadcast the first block. Other node devices can receive the first block generated by the node device and can reach a consensus based on the received block. When the consensus is reached, each node device in the blockchain system will execute the step of storing the first block on the blockchain of the blockchain system, realizing the recording and sharing of the transaction execution result of the system as a whole.

[0224] To facilitate understanding, the above storage process is illustrated below with an example. Each node device in the blockchain system has a corresponding node identifier, and each node device can also store the node identifiers of other node devices in the blockchain system. This allows the generated block to be broadcast to other node devices in the blockchain system based on their node identifiers, enabling consensus among the other node devices. Each node device can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 uses IP addresses as an example only.

[0225] Table 1

[0226] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0227] Each node in a blockchain system can store an identical copy of the blockchain. A blockchain consists of multiple blocks. Figure 7 This is a schematic diagram of a blockchain structure provided in an embodiment of this application. See also... Figure 7 The blockchain consists of multiple blocks. The genesis block 701 includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, while the block body stores the input information. The next block 702 is the parent block of the genesis block 701. The next block 702 also includes a block header and a block body. The block header stores the input information feature value of the current block 703, the block header feature value of the parent block, the version number, the timestamp, and the difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0228] When generating blocks in the blockchain, the node device where the blockchain resides verifies the input information upon receiving it. In this embodiment, the input information may be at least one transaction execution result. After verifying the transaction execution result, the node device stores the result in a memory pool and updates the hash number used to record it. Then, it updates the timestamp to the time the transaction execution result was received and attempts to calculate the feature value multiple times using different random numbers, ensuring that the calculated feature value satisfies the following formula:

[0229] SHA256(SHA256(version+prev_merkle_rool+ntime+nbits+x)) <TARGET

[0230] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0231] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and block body to obtain the current block. Subsequently, the node in the blockchain sends the newly generated current block to other nodes in its blockchain system based on the node identifiers of other nodes in the blockchain system. The other nodes then reach a consensus on the newly generated current block. Once the current block passes the consensus, it can be added to the blockchain. Each node device in the blockchain system can execute the above block generation process. Of course, only some node devices can execute the above block generation process. When any block passes the consensus of the blockchain system, the above on-chain operation can be performed. If the current block fails to pass the consensus, the block on-chain operation can be skipped.

[0232] It should be noted that the above description of storing the transaction execution result to the blockchain is only an exemplary description of a storage method, and the embodiments of this application do not limit which storage method is specifically adopted.

[0233] Figure 8 This is a schematic diagram of the structure of a blockchain-based bidding information processing device provided in an embodiment of this application. See also... Figure 8 The device includes:

[0234] The acquisition module 801 is used to acquire the bidding information of the first user in response to the release operation of the bidding content information of the first user. The bidding information carries the bidding content information, the user identifier of the first user and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process.

[0235] The query module 802 is used to query the blockchain system based on the target smart contract identifier carried in the bidding information;

[0236] The verification module 803 is used to verify the bidding information if it is determined by querying that the target smart contract has been deployed in the blockchain system.

[0237] The publishing module 804 is used to trigger the publishing operation of the bidding content information after the verification is passed;

[0238] The contract writing module 805 is used to write the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract.

[0239] The block storage module 806 is used to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the consensus on the transaction execution results based on the bidding information and the bidding information is passed by the blockchain system.

[0240] In one possible implementation, the verification module is configured to perform any one or a combination of the following verification procedures:

[0241] Based on the content feature value of the bidding content information, query the blockchain to see if there is already bidding content information with the same content feature value as the bidding content information. If there is, the verification fails. If not, and all other verification processes have been completed, the verification passes.

[0242] The bidding information also carries the certificate feature value of the first user's first authentication certificate. Based on the certificate feature value, the blockchain is queried to see if an authentication certificate with the certificate feature value is already included. If not, the verification fails. If so, and all other verification processes have been completed, the verification passes.

[0243] The bidding information also carries the public key of the first user. If the first authentication certificate is found, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, the verification fails. If they match and all other verification processes have been completed, the verification passes.

[0244] In one possible implementation, the contract writing module is used to write the target smart contract with the content feature value of the bidding content information as the key and the bidding content information and the user identifier of the first user as the value.

[0245] The content feature value of the bidding information is used as the key, and the feature value of the bidding information is used as the value, to write the target smart contract.

[0246] In one possible implementation, the bidding information also carries the first user's public key and digital signature. The verification module is also used to verify the legality of the digital signature based on the public key. If the verification passes, the step of querying in the blockchain system is executed.

[0247] In one possible implementation, the device further includes an output module for outputting a successful on-chain message, the successful on-chain message carrying the transaction execution result based on the bidding information, the content feature value of the bidding content information, and the feature value of the bidding information.

[0248] In one possible implementation, the device further includes:

[0249] The bidding information acquisition module is used to respond to the bidding operation of the second user on the bidding content information published by the first user, and to acquire the bidding information of the second user. The bidding information carries the bidding content information, the content feature value of the target bidding content information, the user identifier of the second user, and the identifier of the target smart contract.

[0250] The query module is also used to perform a query in the blockchain system based on the target smart contract identifier in the bidding information;

[0251] The verification module is further configured to verify the bidding information if it is determined through querying that the target smart contract has been deployed in the blockchain system.

[0252] The bidding module is used to trigger a bidding operation based on the bidding content information after the verification is passed;

[0253] The contract writing module is also used to write the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract;

[0254] The block storage module is also used to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the blockchain system has reached a consensus on the transaction execution results based on the bidding information and the bidding information.

[0255] In one possible implementation, the contract writing module is further configured to write the target smart contract with the content feature value of the bidding content information as the key, and the bidding content information, the user identifier of the second user, and the feature value of the bidding information as the value;

[0256] Using the content feature value of the bidding content information as the key, the bidding content data is written into the corresponding bidding list in the target smart contract.

[0257] In one possible implementation, the device further includes:

[0258] The protocol acquisition module is used to respond to the protocol publishing operation of the first user and acquire the protocol framework information of the first user. The protocol framework information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user.

[0259] The contract writing module is also used to set the signing status of the cooperation framework agreement to "first user has signed" after the verification of the agreement framework information is passed, and to write the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the signing status into the target smart contract.

[0260] The block storage module is also used to write a block containing the first write result into the blockchain after the blockchain system has reached a consensus on the first write result. The first write result is used to indicate whether the write based on the signing status was successful.

[0261] The information output module is used to output the first writing result and the protocol framework information of the first user to the target second user.

[0262] In one possible implementation, the device further includes:

[0263] The signing information acquisition module is used to respond to the agreement signing operation of the target second user and acquire the agreement signing information of the target second user. The agreement signing information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user.

[0264] The contract writing module is also used to update the signing status of the cooperation framework agreement to effective after the verification of the agreement signing information is passed, and to write the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the updated signing status into the target smart contract.

[0265] The block storage module is also used to write a block containing the second write result into the blockchain after the blockchain system has reached a consensus on the second write result. The second write result is used to indicate whether the write based on the updated signature status was successful.

[0266] The information output module is also used to output the second writing result to the first user.

[0267] In one possible implementation, the device further includes:

[0268] The triggering module is used to trigger at least one processing flow corresponding to the satisfied clause when it is detected that any clause in the content of the cooperation framework agreement is satisfied.

[0269] In one possible implementation, the contract writing module is further configured to write the execution result of the processing flow corresponding to the satisfied terms into the target smart contract.

[0270] In one possible implementation, the apparatus further includes: a certificate processing module configured to, in response to obtaining the authentication certificate of any user, obtain the certificate feature value of the user's authentication certificate;

[0271] If the certificate feature value of the authentication certificate is not found to be stored on the blockchain, then the certificate feature value of the authentication certificate and the authentication certificate are written into the target smart contract.

[0272] After the blockchain system reaches a consensus on the authentication certificate, a block containing the authentication certificate and its feature value will be stored on the blockchain.

[0273] Output a successful on-chain message, which carries the on-chain result and the certificate feature value of the authentication certificate.

[0274] It should be noted that the bidding information processing device provided in the above embodiments is only illustrated by the division of the above functional modules when processing bidding information. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the bidding information processing device and the bidding information processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0275] The computer device provided in this application embodiment can be implemented as a server, which can be used to execute the steps executed by the first server in the above embodiments, or the steps executed by any node device. Figure 9 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 900 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 901 and one or more memories 902. The one or more memories 902 store at least one instruction, which is loaded and executed by the one or more processors 901 to implement the methods provided in the various method embodiments described above. Of course, the server 900 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server 900 may also include other components for implementing device functions, which will not be elaborated upon here.

[0276] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including instructions that can be executed by a processor to complete the bidding information processing method in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0277] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0278] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A blockchain-based method for processing bidding information, characterized in that, include: In response to the first user's operation of publishing bidding content information, the bidding information of the first user is obtained. The bidding information carries bidding content information, the user identifier of the first user, and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process. The target smart contract is deployed in the blockchain system by the first server corresponding to the investment cooperation framework platform for the bidding service provided by the platform. The target smart contract is data signed by the first server with a private key. The investment cooperation framework platform supports bidding and tendering based on the target smart contract after logging in. The target smart contract identifier carried in the bidding information is used to perform a query in the blockchain system; If it is determined through querying that the target smart contract has been deployed in the blockchain system, the bidding information is verified, and after the verification is passed, the publication operation of the bidding content information is triggered; Write the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract; After the blockchain system reaches a consensus on the transaction execution results based on the bidding information and the bidding information, the block containing the transaction execution results based on the bidding information and the bidding information is stored on the blockchain of the blockchain system. The method further includes: In response to the protocol publishing operation of the first user, the protocol framework information of the first user is obtained. The protocol framework information includes the following information: the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user; the target second user is the winning user determined from multiple second users who bid. After the protocol framework information is verified, the signing status of the cooperation framework agreement is set to "first user has signed", and the information content and the signing status are written into the target smart contract. After the blockchain system reaches a consensus on the first write result, which indicates whether the write based on the signature state was successful, a block containing the first write result is written into the blockchain. The first writing result and the protocol framework information of the first user are fed back to the first server to notify the first user that the contract has been completed, and the first server is triggered to output the first writing result and the protocol framework information of the first user to the target second user. The first server is used to: initiate a signing process in response to the agreement signing operation triggered when the target second user logs into the first server and queries and confirms that the content of the cooperation framework agreement stored in the blockchain system is consistent with the content of the cooperation framework agreement displayed by the first server.

2. The method according to claim 1, characterized in that, The verification of the bidding information includes any one or a combination of the following verification processes: Based on the content feature value of the bidding content information, query the blockchain to see if there is already bidding content information with the same content feature value as the bidding content information. If there is, the verification fails. If not, and all other verification processes have been completed, the verification passes. The bidding information also carries the certificate feature value of the first user's first authentication certificate. Based on the certificate feature value, the blockchain is queried to see if an authentication certificate with the certificate feature value is already included. If not, the verification fails. If so, and all other verification processes have been completed, the verification passes. The bidding information also carries the public key of the first user. If the first authentication certificate is found, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, the verification fails. If they match and all other verification processes have been completed, the verification passes.

3. The method according to claim 1, characterized in that, The step of writing the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract includes: The content feature value of the bidding content information is used as the key, and the bidding content information and the user identifier of the first user are used as the values ​​to write the target smart contract; The content feature value of the bidding information is used as the key, and the feature value of the bidding information is used as the value, to write the target smart contract.

4. The method according to claim 1, characterized in that, After storing the block containing the transaction execution result based on the bidding information and the bidding information on the blockchain of the blockchain system, the method further includes: Output a successful on-chain message, which carries the transaction execution result based on the bidding information, the content feature value of the bidding content information, and the feature value of the bidding information.

5. The method according to claim 1, characterized in that, The method further includes: In response to the second user's bidding operation on the bidding content information published by the first user, the bidding information of the second user is obtained. The bidding information carries the bidding content information, the content feature value of the bidding content information, the user identifier of the second user, and the identifier of the target smart contract. Based on the identifier of the target smart contract in the bidding information, a query is performed in the blockchain system; If it is determined through querying that the target smart contract has been deployed in the blockchain system, the bidding information is verified, and after the verification is passed, a bidding operation based on the bidding content information is triggered; Write the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract; After the blockchain system reaches a consensus on the transaction execution results based on the bidding information and the bidding information, the block containing the transaction execution results based on the bidding information and the bidding information will be stored on the blockchain of the blockchain system.

6. The method according to claim 1, characterized in that, After outputting the first write result and the protocol framework information of the first user to the target second user, the method further includes: In response to the agreement signing operation of the target second user, the agreement signing information of the target second user is obtained. The agreement signing information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user. After the signing information of the agreement is verified, the signing status of the cooperation framework agreement is updated to effective, and the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the updated signing status are written into the target smart contract. After the blockchain system reaches a consensus on the second write result, a block containing the second write result is written into the blockchain. The second write result is used to indicate whether the write based on the updated signature status was successful. Output the second write result to the first user.

7. The method according to claim 1, characterized in that, Before querying the blockchain system based on the identifier of the target smart contract carried in the bidding information, the method further includes: The bidding information also carries the first user's public key and digital signature. The legality of the digital signature is verified based on the public key. If the verification passes, the step of querying in the blockchain system is executed.

8. The method according to claim 5, characterized in that, The step of writing the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract includes: The target smart contract is written with the content feature value of the bidding content information as the key, and the bidding content information, the user identifier of the second user, and the feature value of the bidding information as the value. Using the content feature value of the bidding content information as the key, the bidding content data is written into the corresponding bidding list in the target smart contract.

9. The method according to claim 1, characterized in that, The method further includes: When it is detected that any clause in the cooperation framework agreement is satisfied, at least one processing flow corresponding to the satisfied clause is triggered.

10. The method according to claim 9, characterized in that, The method further includes: The execution result of the processing flow corresponding to the satisfied terms is written into the target smart contract.

11. The method according to claim 1, characterized in that, The method further includes: In response to obtaining the authentication certificate of any user, obtain the certificate feature value of the authentication certificate of the user; If, based on the certificate feature value of the authentication certificate, it is found that no authentication certificate with the certificate feature value is stored on the blockchain, then the certificate feature value of the authentication certificate and the authentication certificate are written into the target smart contract; After the blockchain system reaches a consensus on the authentication certificate, a block containing the authentication certificate and its feature value will be stored on the blockchain. Output a successful on-chain message, which carries the on-chain result and the certificate feature value of the authentication certificate.

12. A blockchain-based bidding information processing device, characterized in that, include: The acquisition module is used to respond to the first user's bidding content information release operation and acquire the first user's bidding information. The bidding information carries bidding content information, the first user's user identifier, and the identifier of the target smart contract. The target smart contract is used to indicate the processing logic of the bidding process. The target smart contract is deployed in the blockchain system by the first server corresponding to the investment cooperation framework platform for the bidding service provided by the platform. The target smart contract is data signed by the first server using a private key. The investment cooperation framework platform supports bidding and tendering based on the target smart contract after login. The query module is used to query the blockchain system based on the identifier of the target smart contract carried in the bidding information; The verification module is used to verify the bidding information if it is determined through querying that the target smart contract has been deployed in the blockchain system. The publishing module is used to trigger the publishing operation of the bidding content information after the verification is passed; The contract writing module is used to write the content feature value of the bidding content information, the user identifier of the first user, and the feature value of the bidding information into the target smart contract. The block storage module is used to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the consensus on the transaction execution results based on the bidding information and the bidding information is passed by the blockchain system. The device further includes: The protocol acquisition module is used to respond to the protocol publishing operation of the first user and acquire the protocol framework information of the first user. The protocol framework information includes the following information: the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user; the target second user is the winning user determined from multiple second users who bid. The contract writing module is also used to set the signing status of the cooperation framework agreement to "first user has signed" after the verification of the protocol framework information is passed, and to write the information content and the signing status into the target smart contract. The block storage module is further configured to write a block containing the first write result into the blockchain after the blockchain system has reached a consensus on the first write result indicating whether the write based on the signature status was successful. The information output module is used to feed back the first writing result and the protocol framework information of the first user to the first server, so as to notify the first user that the contract has been completed and trigger the first server to output the first writing result and the protocol framework information of the first user to the target second user. The first server is used to: initiate a signing process in response to the agreement signing operation triggered when the target second user logs into the first server and queries and confirms that the content of the cooperation framework agreement stored in the blockchain system is consistent with the content of the cooperation framework agreement displayed by the first server.

13. The apparatus according to claim 12, characterized in that, The verification module is configured to perform any one or a combination of the following verification processes: Based on the content feature value of the bidding content information, query the blockchain to see if there is already bidding content information with the same content feature value as the bidding content information. If there is, the verification fails. If not, and all other verification processes have been completed, the verification passes. The bidding information also carries the certificate feature value of the first user's first authentication certificate. Based on the certificate feature value, the blockchain is queried to see if an authentication certificate with the certificate feature value is already included. If not, the verification fails. If so, and all other verification processes have been completed, the verification passes. The bidding information also carries the public key of the first user. If the first authentication certificate is found, the public key in the first authentication certificate is compared with the public key carried in the bidding information. If they do not match, the verification fails. If they match and all other verification processes have been completed, the verification passes.

14. The apparatus according to claim 12, characterized in that, The contract writing module is used for: The content feature value of the bidding content information is used as the key, and the bidding content information and the user identifier of the first user are used as the values ​​to write the target smart contract; The content feature value of the bidding information is used as the key, and the feature value of the bidding information is used as the value, to write the target smart contract.

15. The apparatus according to claim 12, characterized in that, The device further includes: The output module is used to output a successful on-chain message, which carries the transaction execution result based on the bidding information, the content feature value of the bidding content information, and the feature value of the bidding information.

16. The apparatus according to claim 12, characterized in that, The device further includes: The bidding information acquisition module is used to respond to the bidding operation of the second user on the bidding content information published by the first user, and to acquire the bidding information of the second user. The bidding information carries the bidding content information, the content feature value of the bidding content information, the user identifier of the second user, and the identifier of the target smart contract. The query module is also used to perform a query in the blockchain system based on the identifier of the target smart contract in the bidding information; The verification module is further configured to verify the bidding information if it is determined through querying that the target smart contract has been deployed in the blockchain system. The bidding module is used to trigger a bidding operation based on the bidding content information after the verification is passed; The contract writing module is also used to write the content feature value of the bidding content information, the user identifier of the second user, and the feature value of the bidding information into the target smart contract; The block storage module is further configured to store a block containing the transaction execution results based on the bidding information and the bidding information on the blockchain of the blockchain system after the blockchain system has reached a consensus on the transaction execution results based on the bidding information and the bidding information.

17. The apparatus according to claim 12, characterized in that, The device further includes: The signing information acquisition module is used to respond to the agreement signing operation of the target second user and acquire the agreement signing information of the target second user. The agreement signing information includes the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, and the content feature value of the bidding content information of the target second user. The contract writing module is further configured to update the signing status of the cooperation framework agreement to effective after the agreement signing information is verified, and to write the user identifier of the first user, the user identifier of the target second user, the identifier of the target smart contract, the content of the cooperation framework agreement, the identifier of the cooperation framework agreement, the content feature value of the bidding content information, the content feature value of the bidding content information of the target second user, and the updated signing status into the target smart contract. The block storage module is further configured to write a block containing the second write result into the blockchain after the blockchain system has reached a consensus on the second write result, wherein the second write result is used to indicate whether the write based on the updated signature status was successful; The information output module is also used to output the second writing result to the first user.

18. The apparatus according to claim 12, characterized in that, The device further includes: The bidding information also carries the first user's public key and digital signature. The verification module is also used to verify the legality of the digital signature based on the public key. If the verification passes, the step of querying in the blockchain system is executed.

19. The apparatus according to claim 16, characterized in that, The contract writing module is also used for: The target smart contract is written with the content feature value of the bidding content information as the key, and the bidding content information, the user identifier of the second user, and the feature value of the bidding information as the value. Using the content feature value of the bidding content information as the key, the bidding content data is written into the corresponding bidding list in the target smart contract.

20. The apparatus according to claim 12, characterized in that, The device further includes a trigger module for: When it is detected that any clause in the cooperation framework agreement is satisfied, at least one processing flow corresponding to the satisfied clause is triggered.

21. The apparatus according to claim 20, characterized in that, The contract writing module is also used to write the execution result of the processing flow corresponding to the satisfied terms into the target smart contract.

22. The apparatus according to claim 12, characterized in that, The device further includes a certificate processing module for: In response to obtaining the authentication certificate of any user, obtain the certificate feature value of the authentication certificate of the user; If, based on the certificate feature value of the authentication certificate, it is found that no authentication certificate with the certificate feature value is stored on the blockchain, then the certificate feature value of the authentication certificate and the authentication certificate are written into the target smart contract; After the blockchain system reaches a consensus on the authentication certificate, a block containing the authentication certificate and its feature value will be stored on the blockchain. Output a successful on-chain message, which carries the on-chain result and the certificate feature value of the authentication certificate.

23. A computer device, characterized in that, The computer device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, the program code being loaded and executed by the one or more processors to perform the operations performed by the blockchain-based bidding information processing method as described in any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to perform the operations of the blockchain-based bidding information processing method as described in any one of claims 1 to 11.

Images