Web3 interface calling method, system, device and storage medium based on blockchain

Abstract

The present application discloses a Web3 interface calling method, system, device and storage medium based on blockchain, which is used for the security of application migration and data storage. The present application method includes: receiving a call request for a target interface; obtaining corresponding input parameters according to the call request, and encapsulating the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed; parsing the interface parameters from the target interface; verifying the interface parameters; if the verification is successful, performing corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameters.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain-based Web3 interface calling method, system, device and storage medium. Background Art

[0002] Internet applications are applications based on the Internet, and are generally divided into servers and clients, and into C / S and B / S modes. The C / S mode is the Client / Server mode, and the B / S mode is the Browser / Server mode. Internet applications generally start Hypertext Transfer Protocol (HTTP) service or Web Socket service on the server side, that is, a long connection service based on TCP (Transmission Control Protocol), and the client application or browser application communicates with the server side to achieve the service mode.

[0003] Internet applications have gone through three eras: Web1.0, Web2.0, and Web3.0. Among them:

[0004] Web1.0 mainly relies on central servers to generate data content for users to access and use, and there is no problem of user asset confirmation;

[0005] Web2.0 mainly generates data through users and stores it on the server side. The data generated by users does not become the data assets of users.

[0006] Web3.0 also generates data through users, who sign the data with the private key of a decentralized identity (full name: Decentralized Identity, abbreviated as DID), thereby binding the data to the user's identity, realizing the asset rights of user-generated content, and usually storing data in a blockchain manner.

[0007] The Internet is now in an era where Web2.0 applications are the mainstream. Users can generate massive amounts of user behavior data, virtual asset data, transaction data, item data, etc. in Web2.0 Internet application systems such as games, social networking, e-commerce, and education. These data are stored on central servers, and the data generated by users do not become their data assets. The server side of Web3.0 is usually decentralized, mostly in the form of blockchain native applications or smart contract applications. User assets can be confirmed through DID identities, thereby restoring the value of data assets to users.

[0008] Upgrading the current mainstream Internet Web2.0 applications to Web3.0 applications will be a complex system engineering project. For example, the current blockchain is an era of coexistence of multiple chains, including Ethereum, which is well-known for its innovative introduction of smart contracts and blockchain 2.0, Polygon, which is characterized by fast speed and low gas fees, and Solana, which is known for its fast speed and innovative Proof of History (PoH) technology. Traditional Web2.0 Internet applications need to connect to these blockchains and develop smart contracts, which will face the technical problem of choosing which chain and transforming the server-side program into a secure decentralized smart contract program, and will require a lot of R&D costs and time costs for design, development, testing, deployment and online launch. Summary of the invention

[0009] In order to solve the above technical problems, the present application provides a blockchain-based Web3 interface calling method, system, device and storage medium.

[0010] The first aspect of the present application provides a Web3 interface calling method based on blockchain, the method comprising:

[0011] Receive a call request to the target interface;

[0012] And according to the call request, corresponding input parameters are obtained, and the input parameters are encapsulated into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed;

[0013] Parsing the interface parameters from the target interface;

[0014] Verifying the interface parameters;

[0015] If the verification is successful, corresponding data access is performed on the data stored in the corresponding blockchain according to the identification field contained in the interface parameters.

[0016] Optionally, the verifying the interface parameters includes:

[0017] A timestamp verification is performed on the interface parameters.

[0018] Optionally, the timestamp verification of the interface parameters includes:

[0019] Timestamp verification is performed using the following formula:

[0020] T1 <Tv-Tu<T2;

[0021] If the above formula is satisfied, the verification is confirmed to be successful;

[0022] Among them, Tv is the current time, Tu is the sending time of the call request, and T1 and T2 are the upper and lower thresholds of the preset time window.

[0023] Optionally, after generating the interface parameters, the method further includes:

[0024] The interface parameters are signed with a private key.

[0025] Optionally, the verifying the interface parameters includes:

[0026] Perform signature verification on the interface parameters.

[0027] Optionally, the private key signing the interface parameters includes:

[0028] Concatenate key parameters in the interface parameters, and perform hash calculation on the concatenated parameters to obtain a first hash value;

[0029] Performing a private key signature on the first hash value according to the user's private key;

[0030] The performing signature verification on the interface parameters comprises:

[0031] Recover the user's username based on the signature result obtained by signing with the private key and the first hash value to obtain a recovered username;

[0032] comparing the recovered username with the claimed username;

[0033] If they are consistent, the verification is confirmed to be successful.

[0034] Optionally, before executing corresponding data access according to the calling request, the method further includes:

[0035] The call request is verified using an authorization token.

[0036] Optionally, the performing authorization token verification on the call request includes:

[0037] Reading a corresponding key parameter from the interface parameter, wherein the interface parameter includes a second hash value;

[0038] Concatenate the key parameters, and perform hash calculation on the concatenated parameters using an agreed hash function to obtain a third hash value;

[0039] Comparing the second Hash value with the third Hash value;

[0040] If they are consistent, the verification passes.

[0041] Optionally, performing corresponding data access on the data stored in the blockchain includes:

[0042] Corresponding data access is performed on the data stored in the blockchain through the smart contract middleware.

[0043] Optionally, before receiving the call request for the target interface, the method further includes:

[0044] The identity of the user is confirmed through the user's decentralized identity DID.

[0045] The second aspect of the present application provides a blockchain-based Web3 interface calling system, including:

[0046] An interface unit, used for receiving a call request to a target interface;

[0047] The interface unit is further used to obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed;

[0048] A data parsing service unit, used for parsing the interface parameters from the target interface;

[0049] A verification unit, used to verify the interface parameters;

[0050] The smart contract unit is used to perform corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameter after the verification unit determines that the verification is passed.

[0051] Optionally, the smart contract unit is provided with a smart contract middleware, and the smart contract unit accesses data with the blockchain through the smart contract middleware.

[0052] Optionally, the interface unit includes:

[0053] User permission interface module, used to perform user login operations, management and sharing of permission tokens;

[0054] The asset attribute change module is used to create data assets, destroy data assets, and transfer data assets.

[0055] Optionally, the verification unit includes:

[0056] A timestamp verification module, used for performing timestamp verification on the interface parameters;

[0057] A signature verification module, used to perform signature verification on the interface parameters;

[0058] The permission token verification module is used to verify the user's permission token.

[0059] The third aspect of the present application provides a Web3 interface calling device based on blockchain, the device comprising:

[0060] Processor, memory, input-output unit, and bus;

[0061] The processor is connected to the memory, the input and output unit, and the bus;

[0062] The memory stores a program, and the processor calls the program to execute the first aspect and any optional method in the first aspect.

[0063] A fourth aspect of the present application provides a computer-readable storage medium, on which a program is stored. When the program is executed on a computer, the program executes the first aspect and any optional method in the first aspect.

[0064] It can be seen from the above technical solutions that this application has the following advantages:

[0065] In the method provided by the present application, during the process of calling the target interface, the input parameters specified by the user are encapsulated into the target interface, and then the interface parameters are parsed from the target interface. After the interface parameters are verified, the corresponding access operation is performed on the data stored in the blockchain according to the calling request, thereby ensuring the secure migration of the application and the secure storage of the data.

[0066] When Internet applications access data, the interface parameters of this method include an identification field for specifying the blockchain to be accessed, which supports applications to specify one or more chains to be accessed, so as to select one or more chains from multiple blockchains to write application data according to actual needs, thereby giving applications multiple choices to ensure the best adaptation of storage security, TPS, and fuel fee requirements required by application data. (For example, the Ethereum chain has the highest security, TPS less than 100, and high fuel fees; while the Solana chain has medium security, TPS up to 50,000+, and extremely low fuel fees). BRIEF DESCRIPTION OF THE DRAWINGS

[0067] In order to more clearly illustrate the technical solution in the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0068] Figure 1 This is a schematic diagram of the structure of an embodiment of a blockchain-based Web3 interface calling system provided in this application;

[0069] Figure 2 This is a flowchart of an embodiment of a blockchain-based Web3 interface calling method provided in this application;

[0070] Figure 3 This is a flowchart of another embodiment of the blockchain-based Web3 interface calling method provided in this application;

[0071] Figure 4 This is a flowchart of another embodiment of the blockchain-based Web3 interface calling method provided in this application;

[0072] Figure 5 This is a schematic diagram of the structure of an embodiment of a blockchain-based Web3 interface calling device provided in this application.

[0073] Figure 6 A schematic diagram of the deployment of an embodiment of the blockchain-based Web3 interface calling system provided in this application. DETAILED DESCRIPTION

[0074] The present invention constructs a smart contract middleware that connects to multiple blockchains, and provides a unified data security rights confirmation interface for Internet applications, supporting the rapid, smooth and secure migration of data of various types of Web2.0 Internet applications such as games, social networking, e-commerce, and education to blockchain storage, solving the technical problem of rapid migration of various types of Web2.0 Internet applications to Web3.0 applications across multiple chains. Among them, cross-multi-chain means that Internet applications can specify which chain to migrate to, thereby giving applications multiple choices, ensuring the storage security required by application data, TPS (Chinese full name: transaction processing per second, English full name: TransactionPerSecond, English abbreviation: TPS), and the best adaptation of fuel cost requirements; the present invention can significantly reduce the R&D cost investment in application migration, improve development efficiency, and improve security.

[0075] The method provided in this application is applied to the Web3 interface calling system based on blockchain, please refer to Figure 1 as well as Figure 6 , Figure 1 This is a schematic diagram of the structure of an embodiment of the blockchain-based Web3 interface calling system provided in this application. Figure 1 and Figure 6 In the figure, the solid-line frame represents the part belonging to this system, and the dotted-line frame represents the part not belonging to this system. The system includes:

[0076] Interface unit 101, data analysis service unit 102, verification unit 103, smart contract unit 104, smart contract middleware 1041 is set in the smart contract unit 104, interface unit 101 is a web3.0 interface, interface unit 101 is connected with multiple types of upper-layer Internet applications through open HTTP, JSON RPC, Web Socket and other interface forms, and smoothly and quickly migrates Web2.0 applications and data such as games, social networking, e-commerce, and education to the Web3.0 space, and quickly upgrades them to Web3.0 applications; the interface unit 101 writes the application data into the underlying multiple blockchain chain storage via the smart contract unit 104 connected to multiple chains. Blockchains may include Ethereum, Polygon, Solana, etc.

[0077] See also Figure 1 as well as Figure 6 The system provided in this application provides a unified data security confirmation interface for Internet applications by connecting to the smart contract middleware of multiple blockchains, and supports the rapid, smooth and secure migration of data from various Web2.0 Internet applications such as games, social networking, e-commerce, and education to Web3.0 applications.

[0078] The system can adopt a decoupled design, each module can be deployed independently, and can be deployed in a distributed multi-node manner, making the system high-performance, highly reliable, and easy to expand.

[0079] The system consists of: interface unit, data analysis server, verification server and smart contract unit; the external part includes Internet applications and blockchain storage; the interface unit connects with multiple types of upper-level Internet applications through open HTTP, JSON RPC, Web Socket and other interface forms; the interface unit writes application data into the underlying multiple blockchain storage through the smart contract unit that connects to multiple chains. Each blockchain storage is carried on the decentralized cluster of each blockchain.

[0080] The interface unit consists of a user authority interface server, an asset attribute change interface server, a token-based read interface server, and an open read interface server; among which:

[0081] The user authority interface server deploys user login, token management, token sharing and other modules of the user authority interface unit, and provides user login, token management and token sharing services in an interface manner.

[0082] The asset attribute change interface server deploys modules such as creating data assets, destroying data assets, transferring data assets, minting NFTs, destroying NFTs, and transferring NFTs to provide corresponding services in an interface manner.

[0083] Based on the token reading interface unit deployed on the token reading interface server, modules such as user-owned data asset query, user-owned NFT query, shared asset query, shared NFT query, etc. are provided in the form of interfaces.

[0084] The open reading interface server deploys modules such as the owner query of data assets of the open reading interface unit, the owner query of NFT, and the transaction data query, and provides corresponding services in the form of interfaces.

[0085] The data analysis service module is deployed on the data analysis server, which is responsible for receiving the data transmitted by the interface unit, analyzing the data, and forming structured data.

[0086] The timestamp verification, user signature verification, and user token verification modules are deployed on the verification server to provide timestamp verification, user signature verification, and user token verification services respectively.

[0087] Multiple smart contract middlewares of smart contract units are deployed on multiple types of smart contract virtual machines, which are responsible for reading and writing data stored in the blockchain through interface calls, making it convenient for application developers to program in an interface-oriented manner. That is, they only need to care about the business logic of the application itself and do not need to care about the underlying blockchain technology details.

[0088] Based on this, see Figure 2 , the present application provides a Web3 interface calling method based on blockchain, the method comprising:

[0089] 201. Receive a call request for a target interface;

[0090] The system receives the user's call request through the interface module. For example, the user needs to call the permission token management or sharing interface, call the asset attribute change interface, call the permission token-based reading interface, call the open reading interface, etc. In practice, the user can log in to the system through DID (Chinese full name: Decentralized Identity, English full name: Decentralized Identity, English abbreviation DID). When logging in, the user's private key signature can be used to obtain the corresponding account information. For example, the user can apply for a DID account through a third-party wallet plug-in, and then use the account to log in to the system. According to the user's token management or token sharing operations, the Web3 application developed by the application developer will call the generate / modify / delete token or token sharing interface accordingly; for example, when the user generates a token on the interface of the Web3 application, a call to the token generation interface in the token management will be initiated.

[0091] 202. Obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, where the interface parameters include an identification field for specifying the blockchain to be accessed;

[0092] Get the corresponding operation information according to the call request. When the user generates a permission token, the corresponding permission information of the permission token needs to be specified.

[0093] In an optional embodiment, the interface parameters can be in JSON format, which can also include identification fields for specifying a single or multiple blockchains to be accessed. For example, it is necessary to specify the data assets (DataAssetHash) that the token is to access, access rights (Auth), token expiration time (Expiration) and other information, and the Web3 application generates the JSON interface parameters: {"UserName":"user1","TokenId":"123","Token":"tokenxxx","DataAssetHash":"12fa...12aa","Auth":"rw","Expiration":1668848511","DestID":3,"TimeStamp":1637671437,"sig":"de241...22"}, indicating that user user1 will generate a token with TokenId 123 and token name tokenxxx. The data asset with a hash value of "12fa...12aa" can be accessed, the permissions are read and write, the token expiration time is 1668848511 (expressed in Unix timestamp, the total number of seconds from 00:00:00 Greenwich time on January 1, 1970 (08:00:00 Beijing time on January 1, 1970) to the present, 1668848511 means 17:01:51 on November 19, 2022), the user-specified on-chain destination is represented by the identification field DestID, DestID is 3, indicating that the token information is on-chain to Ethereum, the current timestamp TimeStamp = 1637671437 means 20:43:57 Beijing time on November 23, 2021, and the signature sig = "de241...22" is the signature of the hash value concatenated from all the previous fields.

[0094] This optional embodiment supports reading and writing application data across multiple chains, adapting to the security / TPS / fuel cost requirements of applications. When Internet applications access data, the interface provided by this system supports applications to specify the DestID parameter, so as to select one or more chains on multiple blockchains to write application data according to actual needs, thereby giving applications multiple choices to ensure the best adaptation of storage security, TPS, and fuel cost requirements required by application data. (For example, the Ethereum chain has the highest security, TPS below 100, and high fuel costs; while the Solana chain has medium security, TPS up to 50,000+, and extremely low fuel costs).

[0095] 203. Parse interface parameters from the target interface;

[0096] 204. Verify the interface parameters. If the verification passes, execute step 205. If the verification fails, execute step 206.

[0097] The data parsing service unit 102 parses the interface parameters from the target interface, and then the interface parameters are verified by the verification unit 103. There are many ways to verify the interface parameters, such as timestamp verification and signature verification. Figure 3 The corresponding embodiments will be described in detail. By verifying the interface parameters, the safe migration of applications and the safe storage of data can be ensured.

[0098] 205. Perform corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameter.

[0099] If the interface parameters are verified, the user is allowed to call the interface and perform corresponding access to the called interface according to the actual call request. For example, if the token management or token sharing interface is called, the user's token information is written into the blockchain, specifically, the token information is written into the blockchain storage through the smart contract middleware. If the asset attribute change interface is called, the asset attribute information is written into the blockchain storage through the smart contract middleware. If the token-based reading interface is called, the corresponding information is read from the blockchain storage through the smart contract middleware.

[0100] 206. End the process.

[0101] If the interface parameters fail to be verified, the process ends and the corresponding error message may be returned to the user.

[0102] In actual applications, there are many ways to verify interface parameters. For example, multiple security mechanisms can be used to ensure the secure migration of applications and secure data storage. When accessing data assets through interfaces, timestamp verification can be used to resist replay attacks, and user private key signature verification can be used to confirm the ownership of user data assets (i.e., determine the user ownership of data assets). This will be explained in detail through the following embodiments.

[0103] See also Figure 3 , the embodiment comprises:

[0104] 301. Receive a call request to a target interface;

[0105] 302. Obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed;

[0106] 303. Sign the interface parameters with a private key;

[0107] When it comes to interface calls such as user authority and asset attribute change, the interface parameters can be privately signed, for example, the key parameters in the interface parameters are concatenated, and the concatenated key parameters are hashed to obtain the first hash value. The hash algorithm can use the keccak-256 algorithm, and then the first hash value is privately signed. The private key signature can use an asymmetric encryption algorithm, such as the standard algorithm secp256k1 of the Elliptic Curve Digital Signature Algorithm (ECDSA), or the RSA algorithm to ensure interface security. For example:

[0108] When creating a data asset, the input parameters include (UserName, Data, MetaData, DestID, TimeStamp, MsgKeccak256, Sig), where UserName is the user name, Data is the data sent by the user, MetaData is the metadata of the data, DestID is the on-chain destination ID specified by the user (for example: 3 for Ethereum, 4 for Polygon), TimeStamp is the timestamp when the interface is called, and MsgKeccak256 is the result of the above input parameters calculated by Keccak-256, that is:

[0109] MsgKeccak256=Keccak-256(UserName||Data||MetaData||DestID||TimeStamp);

[0110] Among them, sig is the private key signature result of MsgKeccak256, which is based on the user's private key and uses an asymmetric encryption algorithm:

[0111] sig=secp256k1(privateKey of UserName,MsgKeccak256).

[0112] Therefore, when the interface is called, timestamp verification and signature verification can be performed. The verification process is detailed in steps 305 and 306.

[0113] 304. Parse interface parameters from the target interface;

[0114] 305. Perform timestamp verification on the interface parameters. If the verification passes, execute step 306. If the verification fails, execute step 308.

[0115] The interface parameters are verified through the timestamp verification module. Specifically, an appropriate time window can be set to verify the timestamp of the interface call to prevent the interface from being replayed. An appropriate time window can be set according to the network delay and tolerance from the interface call initiator to the interface service provider. For example, the time window is set to (T1, T2) and the timestamp verification is performed using the following formula:

[0116] T1 <Tv-Tu<T2;

[0117] Where Tv is the current time, Tu is the sending time of the call request, and T1 and T2 are the upper and lower thresholds of the preset time window. If the above formula is satisfied, it means that the sending of the call request is within the time window and the verification is passed. If the above formula is not satisfied, the verification fails. For example:

[0118] The time window is set to (0s, 10s), that is, the time difference from the caller of the interface initiating the call request to the time when the timestamp verification module receives the call request must be less than 10 seconds. Any call request outside the time window will be rejected to ensure that it is not attacked by malicious users with repeated request replays.

[0119] 306. Perform signature verification on the interface parameters. If the verification passes, execute step 307. If the verification fails, execute step 308.

[0120] When the user permission interface or asset attribute change interface needs to be called, the interface parameters can be signed and verified. Taking the input parameters and signature method in step 303 as an example, the process of verifying the interface parameters can be: recovering the user's username based on the signature result obtained by the private key signature and the first hash value to obtain the restored username; comparing the restored username with the declared username; if they are consistent, it is determined that the verification is passed. For example:

[0121] When performing signature verification, you can calculate the recovered user's public key from MsgKeccak256 and sig, deduce the username from the public key, and compare whether the declared username UserName and the recovered username recoveredUserName are equal to determine whether the declared user is equal to the signing user, thereby verifying whether the signature is correct. If they are equal, the signature verification passes, otherwise it fails.

[0122] For example:

[0123] First, the public key used by the user when signing is derived through the formula: recoveredPub,=SigToPub(MsgKeccak256,sig);

[0124] Then, the user name corresponding to the public key is recovered through the formula: recoveredUserName=PubkeyToAddress(recoveredPub), that is, the recovered user name is obtained.

[0125] 307. If the verification is successful, the corresponding data access is performed on the data stored in the corresponding blockchain according to the identification field contained in the interface parameters.

[0126] 308. Return the corresponding access result.

[0127] If the verification passes, the corresponding access result is returned. If the verification fails, the corresponding error message is returned.

[0128] In this embodiment, multiple security mechanisms ensure the secure migration of applications and the secure storage of data: when performing interface access to data assets, timestamp verification is used to resist replay attacks; user data asset ownership is confirmed through user private key signature verification, and access to data assets is controlled through user tokens; and to ensure high data availability, the system supports users to store data assets across multiple chains, and supports the minting of NFTs on multiple chains, that is, specifying one or more chains to be accessed through the identification field DestID; supports users to compress data, and encrypt based on the user's public key, and agrees on the algorithm parameters used for compression or encryption in the metadata field of the interface parameters (such as the MetaData field) for decompression or decryption.

[0129] Furthermore, the data assets can be securely accessed and controlled through the authorization tokens held by the users, thereby ensuring the high availability and secure storage of data. For example, when calling the token-based reading interface, authorization token verification can be performed. The specific method will be described in the following embodiments.

[0130] See also Figure 4 , the embodiment comprises:

[0131] 401. Receive a call request to a target interface;

[0132] 402. Obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed;

[0133] 403. Parse interface parameters from the target interface;

[0134] 404. Verify the interface parameters. If the verification passes, execute step 405; if the verification fails, execute step 407;

[0135] 405. Verify the authorization token of the call request; if the verification is successful, execute step 406; if the verification is unsuccessful, execute step 407;

[0136] When it comes to calling the interface based on token reading, the permission token verification can be performed. There are many ways to verify the permission token. When the user makes an interface call, the permission token it holds is superimposed with the key parameters in the interface parameters, and a hash calculation is performed to obtain a second hash value, which is sent to the system together with the interface parameters for verification by the system. After receiving the interface parameters, the system reads the corresponding key parameters from the interface parameters, which contain the second hash value; concatenates the key parameters, and performs a hash calculation on the concatenated parameters through the agreed hash function to obtain a third hash value; compares the second hash value with the third hash value; if they are consistent, the verification is passed. This verification method ensures that the interface parameters are not tampered with by the middleman.

[0137] The following is an example:

[0138] For example, the input interface parameters include (Username, UserToken, TimeStamp, MsgKeccak256), where UserName is the user name and UserToken is the user's permission token;

[0139] MsgKeccak256-2=Keccak-256(UserName||UserToken||TimeStamp);

[0140] The system reads the key parameters Username, UserToken, and TimeStamp and concatenates them, and then uses the agreed Keccak-256 function to perform hash calculation on the concatenated key parameters to obtain the third hash value MsgKeccak256-3=Keccak-256(UserName||UserToken||TimeStamp).

[0141] Then compare the second hash value MsgKeccak256-2 and the third hash value MsgKeccak256-3. If they are consistent, it means that the interface parameters are consistent with those sent. If they are inconsistent, it means that the interface parameters may have been tampered with during the sending process.

[0142] 406. Perform corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameter.

[0143] 407. Return the corresponding access result.

[0144] If the verification passes, the corresponding access result is returned. If the verification fails, the corresponding error message is returned.

[0145] The above embodiments have described the method provided in the present application in detail. The system, device and storage medium provided in the present application will be described below.

[0146] See also Figure 1 , the system provided by this embodiment includes:

[0147] The interface unit 101 is used to receive a call request to a target interface;

[0148] The interface unit 101 is also used to obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed;

[0149] The data analysis service unit 102 is used to parse interface parameters from the target interface;

[0150] Verification unit 103, used to verify interface parameters;

[0151] The smart contract unit 104 is used to perform corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameters after the verification unit determines that the verification is successful.

[0152] Optionally, the smart contract unit is provided with a smart contract middleware 1041, and the smart contract unit accesses data with the blockchain through the smart contract middleware 1041;

[0153] Optionally, the interface unit 101 includes:

[0154] User authority interface module 1011, used to perform user login operations, management and sharing of authority tokens;

[0155] Asset attribute change module 1012, used for the creation, destruction and transfer of data assets and NFTs;

[0156] Based on the token reading interface module 1013, it is used to query the data assets / NFTs owned by the user and the data assets / NFTs shared by other users.

[0157] The open reading interface unit 1014 is used to query the owners of data assets, query the owners of NFTs, query transaction data, etc.

[0158] Optionally, the verification unit 103 includes:

[0159] A timestamp verification module 1031 is used to perform timestamp verification on interface parameters;

[0160] The signature verification module 1032 is used to perform signature verification on the interface parameters;

[0161] The authority token verification module 1033 is used to verify the user's authority token.

[0162] Optionally, the timestamp verification module 1031 is specifically used for:

[0163] Timestamp verification is performed using the following formula:

[0164] T1 <Tv-Tu<T2;

[0165] If the above formula is satisfied, the verification is confirmed to be successful;

[0166] Wherein, Tv is the current time, Tu is the sending time of the call request, and T1 and T2 are the upper and lower thresholds of the preset time window.

[0167] Optionally, after the interface parameters are generated, the user side may sign the interface parameters. The specific signing process may be: concatenating the key parameters in the interface parameters, and performing hash calculation on the concatenated parameters to obtain a first hash value; and performing a private key signature on the first hash value according to the user's private key;

[0168] Further, on the service side, the signature verification module 1032 performs signature verification on the interface parameters. The process of performing signature verification on the interface parameters may be:

[0169] Recover the user's username based on the signature result obtained by the private key signature and the first hash value to obtain a recovery username;

[0170] Compare the recovered username with the claimed username;

[0171] If they are consistent, the verification is confirmed to be successful.

[0172] Optionally, the authority token verification module 1033 is specifically used for:

[0173] Reading a corresponding key parameter from an interface parameter, wherein the interface parameter includes a second hash value;

[0174] Concatenate the key parameters, and perform hash calculation on the concatenated parameters using an agreed hash function to obtain a third hash value;

[0175] The second hash value is compared with the third hash value; if they are consistent, the verification is successful.

[0176] See also Figure 5 , this application also provides a Web3 interface calling device based on blockchain, including:

[0177] Processor 501, memory 502, input and output unit 503, bus 504;

[0178] The processor 501 is connected to the memory 502, the input and output unit 503 and the bus 504;

[0179] The memory 502 stores a program, and the processor 501 calls the program to execute any of the above blockchain-based Web3 interface calling methods.

[0180] The present application also relates to a computer-readable storage medium on which a program is stored, wherein when the program is run on a computer, the computer executes any of the above-mentioned blockchain-based Web3 interface calling methods.

[0181] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0182] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0183] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0184] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0185] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Claims

1. A Web3 interface calling method based on blockchain, characterized in that: The method comprises: Receive a call request to the target interface; Obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed; Parsing the interface parameters from the target interface; Verifying the interface parameters; If the verification is successful, corresponding data access is performed on the data stored in the corresponding blockchain according to the identification field contained in the interface parameter; After generating the interface parameters, the method further includes: Signing the interface parameters with a private key; The verifying of the interface parameters comprises: Performing signature verification on the interface parameters; The private key signing of the interface parameters comprises: Concatenate key parameters in the interface parameters, and perform hash calculation on the concatenated parameters to obtain a first hash value; Performing a private key signature on the first hash value according to the user's private key; The performing signature verification on the interface parameters comprises: Recover the user's username based on the signature result obtained by signing with the private key and the first hash value to obtain a recovered username; comparing the recovered username with the claimed username; If they are consistent, the verification is confirmed to be successful; The verifying of the interface parameters comprises: Performing timestamp verification on the interface parameters; The timestamp verification of the interface parameters comprises: Timestamp verification is performed using the following formula: T1 <Tv-Tu<T2; If the above formula is satisfied, the verification is confirmed to be successful; Wherein, Tv is the current time, Tu is the sending time of the call request, T1 and T2 are the upper and lower thresholds of the preset time window; The interface parameters are in JSON format and include an identification field for specifying a single or multiple blockchains to be accessed. The target interface supports the application to specify a DestID parameter, thereby selecting one or more chains on multiple blockchains to write application data.

2. According to the blockchain-based Web3 interface calling method described in claim 1, it is characterized in that: Before executing the corresponding data access according to the calling request, the method further includes: The call request is verified using an authorization token.

3. According to the blockchain-based Web3 interface calling method described in claim 2, it is characterized in that: The performing authorization token verification on the call request includes: Reading a corresponding key parameter from the interface parameter, wherein the interface parameter includes a second hash value; Concatenate the key parameters, and perform hash calculation on the concatenated parameters using an agreed hash function to obtain a third hash value; Comparing the second Hash value with the third Hash value; If they are consistent, the verification passes.

4. The Web3 interface calling method based on blockchain according to any one of claims 1 to 3, characterized in that: The performing corresponding data access on the data stored in the blockchain includes: Corresponding data access is performed on the data stored in the blockchain through the smart contract middleware.

5. The blockchain-based Web3 interface calling method according to any one of claims 1 to 3, characterized in that: Before receiving the call request to the target interface, the method further includes: The identity of the user is confirmed through the user's decentralized identity DID.

6. The blockchain-based Web3 interface calling method according to any one of claims 1 to 3, characterized in that: The interface parameters are in JSON format, and include an identification field for specifying the blockchain to be accessed.

7. A Web3 interface calling system based on blockchain, characterized in that: include: An interface unit, used for receiving a call request to a target interface; The interface unit is further used to obtain corresponding input parameters according to the call request, and encapsulate the input parameters into the target interface to generate interface parameters, wherein the interface parameters include an identification field for specifying the blockchain to be accessed; A data parsing service unit, used for parsing the interface parameters from the target interface; A verification unit, used to verify the interface parameters; A smart contract unit, configured to perform corresponding data access on the data stored in the corresponding blockchain according to the identification field included in the interface parameter after the verification unit determines that the verification is passed; After the interface parameters are generated, the user side signs the interface parameters, and the signing process includes: concatenating the key parameters in the interface parameters, and performing hash calculation on the concatenated parameters to obtain a first hash value; and performing a private key signature on the first hash value according to the user's private key; The service side performs signature verification on the interface parameters through the signature verification module. The process of signature verification on the interface parameters includes: Recover the user's username based on the signature result obtained by the private key signature and the first hash value to obtain a recovery username; Compare the recovered username with the claimed username; If they are consistent, the verification is confirmed to be successful; The permission token verification module is specifically used for: Reading a corresponding key parameter from an interface parameter, wherein the interface parameter includes a second hash value; Concatenate the key parameters, and perform hash calculation on the concatenated parameters using an agreed hash function to obtain a third hash value; Compare the second hash value with the third hash value; if they are consistent, the verification is successful; The verification unit includes: Timestamp verification module, used to perform timestamp verification on interface parameters; Signature verification module, used to perform signature verification on interface parameters; The permission token verification module is used to verify the user's permission token; The timestamp verification module is specifically used for: Timestamp verification is performed using the following formula: T1 <Tv-Tu<T2; If the above formula is satisfied, the verification is confirmed to be successful; Wherein, Tv is the current time, Tu is the sending time of the call request, T1 and T2 are the upper and lower thresholds of the preset time window; The interface parameters are in JSON format and include an identification field for specifying a single or multiple blockchains to be accessed. The target interface supports the application to specify a DestID parameter, thereby selecting one or more chains on multiple blockchains to write application data.

8. According to the blockchain-based Web3 interface calling system described in claim 7, it is characterized in that: The smart contract unit is provided with a smart contract middleware, and the smart contract unit performs data access with the blockchain through the smart contract middleware.

9. According to the blockchain-based Web3 interface calling system described in claim 7, it is characterized in that: The interface unit comprises: User permission interface module, used to perform user login operations, management and sharing of permission tokens; The asset attribute change module is used to create data assets, destroy data assets, and transfer data assets.

10. A Web3 interface calling device based on blockchain, characterized in that: The device comprises: Processor, memory, input-output unit, and bus; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method according to any one of claims 1 to 6.

11. A computer-readable storage medium having a program stored thereon, wherein the program, when executed on a computer, performs the method according to any one of claims 1 to 6.

Images