Autonomous protocol implementation method for solving front-end application calling back-end blockchain

Abstract

The application provides a self-protocol implementation method for solving the calling of a front-end application to a back-end blockchain, comprising a digital collectible module, the digital collectible module comprising a digital collectible operation protocol and a digital collectible scheduling engine, the digital collectible operation protocol defining processing protocols for various operations of digital collectibles, the processing protocols including user registration, collectible issuance, digital certificate transfer, digital certificate destruction, and various query operations, the digital collectible operation protocol being capable of summarizing and encapsulating various operations of digital collectibles to form operation instructions, which are scheduled and executed by the digital collectible scheduling engine. The application can asynchronously interface with a blockchain interface through a task scheduling engine, thereby solving the contradiction between the front-end high-concurrency application and the back-end blockchain performance bottleneck, and realizing the online of the blockchain digital collectible product in the front-end APP.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, in particular to a self-protocol implementation method for solving the calling of a front-end application to a back-end blockchain. BACKGROUND

[0002] Compared with traditional centralized systems, the advantage of blockchain is decentralization, without any central agency and central server, realizing point-to-point direct interaction, which not only saves resources, makes transactions autonomous and simple, but also eliminates the risk of being controlled by centralized agents. At the same time, it has higher reliability and availability.

[0003] However, the blockchain has a significant disadvantage: performance bottleneck.

[0004] According to available information, the transaction throughput of the financial system is at least the order of magnitude of ten thousand times per second. This requires very high confirmation time and transaction processing capacity per second (TPS) of the blockchain system. The common blockchain system currently processes no more than 1.8 million transactions per day, and the highest tps is only about 20. If the TPS is too low, it is easy to cause serious network congestion, so that the blockchain cannot be landed in the field of high-value high-concurrency business.

[0005] Mobile phone APP and other Internet applications want to develop digital collectibles and other products, which face the contradiction between front-end super large user volume and high concurrency and back-end blockchain performance bottleneck, and need to design a scheme or mechanism to link the front and back ends to solve the problem of performance asynchronization. SUMMARY

[0006] In order to overcome the defects of the prior art, the present application provides a self-protocol implementation method for solving the calling of a front-end application to a back-end blockchain, to solve the problem of performance asynchronization in the development of digital collectibles and other products by mobile phone APP and other Internet applications, which face the contradiction between front-end super large user volume and high concurrency and back-end blockchain performance bottleneck.

[0007] The application discloses a self-protocol implementation method for solving front-end application calling a back-end blockchain, and comprises a digital collectible module, the digital collectible module comprises a digital collectible operation protocol and a digital collectible scheduling engine, the digital collectible operation protocol defines processing protocols for various operations of digital collectibles, the processing protocols are user registration, collectible issuance, digital certificate transfer, digital certificate destruction and various query operations, the digital collectible operation protocol can be used for summarizing and encapsulating various operations of digital collectibles to form operation instructions, the operation instructions are scheduled and executed through the digital collectible scheduling engine, after receiving an operation request from an application, the digital collectible scheduling engine encapsulates operation instructions according to the DCOP protocol and puts the operation instructions into a task queue, the digital collectible scheduling engine executes instructions in the queue according to a scheduling strategy, analyzes and calls a blockchain interface to execute operations, obtains a result of the blockchain, processes the result, updates a task state, and then notifies a source application, the digital collectible module is further connected with a front-end application, and the front-end application encapsulates digital collectible operation instructions into operation work orders according to the digital collectible operation protocol, and sends the work orders to the digital collectible scheduling engine through an interface.

[0008] Preferably, the digital collectible scheduling engine runs as follows: after receiving the work order, the digital collectible scheduling engine adds the work order into the task queue and returns a receipt to the front-end application synchronously.

[0009] The scheduling engine of the digital collectible scheduling engine monitors the task queue, takes out operation work orders from the queue, analyzes operation instructions, and calls corresponding interfaces of the blockchain for processing according to the instruction type.

[0010] For instructions that return results of the blockchain in real time, the task state is updated immediately after synchronous results are obtained, and the results are encapsulated according to the DCOP and then fed back to the front-end application through an asynchronous notification interface of the application end.

[0011] For instructions that return results of the blockchain asynchronously, the task state is updated after synchronous results are obtained, and the processing results are fed back to the application end through the asynchronous notification interface of the application end.

[0012] Preferably, for instructions that return results of the blockchain asynchronously, sub-tasks are automatically generated while synchronous results are obtained, asynchronous execution results of the blockchain are queried, and the final results are notified to the application end again after the asynchronous execution results are obtained.

[0013] Preferably, an operation layer composed of the digital collectible operation protocol and the digital collectible scheduling engine is located between the front-end application and the blockchain and is used for linking between the front-end application and the blockchain, the operation layer supports multiple front-end applications, and the operation layer is connected with multiple blockchain systems.

[0014] The blockchain end itself has an asynchronous operation, and the blockchain end returns the instruction number of the operation in an asynchronous manner, and then queries the progress of the operation and returns the result according to the instruction number.

[0015] Preferably, the asynchronous operation generates a query task by automatically creating a subtask to obtain the result of the asynchronous operation.

[0016] Preferably, the blockchain operation scenario includes query type and execution type, the query type includes user collection query, digital certificate query, and certificate detail query.

[0017] The execution type includes user registration, collection issuance, transfer certificate, and certificate destruction.

[0018] Preferably, for the execution type operation, the blockchain itself can adopt an asynchronous manner, and does not directly return the result after the operation, but returns the number of asynchronous requests, and queries the execution result of the blockchain operation through the number.

[0019] Preferably, the digital collection scheduling engine adopts a memory queue, and in implementation, a database is used to store tasks according to the requirements of performance, compatibility, and development difficulty.

[0020] Preferably, the blockchain is connected through interface and logical adaptation operation to connect various different blockchain platforms.

[0021] The beneficial effects of the present application are:

[0022] 1. The method designs a set of instruction protocols, encapsulates digital collection related operations, agrees on corresponding parameter, format and other data transmission specifications, and asynchronously connects the blockchain interface through the task scheduling engine, so as to solve the contradiction between the high concurrency application of the front end and the performance bottleneck of the back end blockchain, and realize the online of the blockchain digital collection product in the front end APP.

[0023] 2. The method designs a self-defined protocol, digital collection operation protocol DCOP, so that both parties or multiple parties of upstream and downstream cooperation can directly develop based on the protocol specification, and after development, the debugging test can be carried out, avoiding the constant communication and discussion of both parties, and the inconsistent phenomenon when multiple parties are connected, and improving the development efficiency. DETAILED DESCRIPTION

[0024] Figure 1 The structure diagram of the digital collection operation protocol and the digital collection scheduling engine.

[0025] Figure 2 The main flowchart of the digital collection scheduling engine running.

[0026] Figure 3 The business time sequence diagram of the digital collection running mechanism. Detailed Implementation

[0027] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention.

[0028] Reference Figures 1-3 This paper addresses the implementation method of autonomous protocols for front-end applications to call back-end blockchains, including a digital collection module. The digital collection module consists of two parts: a digital collection operation protocol and a digital collection scheduling engine. The digital collection operation protocol (DCOP) defines the processing protocol for various operations of digital collections, such as user registration, collection issuance, digital certificate transfer, digital certificate destruction, and various query operations. Based on this definition, various operations of digital collections can be summarized and encapsulated to form operation instructions, which are then scheduled and executed by the digital collection scheduling engine (DCSE).

[0029] The Digital Collections Scheduling Engine (DCSE) is a task-based scheduling mechanism. Upon receiving an operation request from an application, it encapsulates the operation instructions according to the DCOP protocol and places them in a task queue. The engine executes the instructions in the queue according to the scheduling strategy, parses them, and calls the blockchain interface to perform the operation. After obtaining the synchronous response result or asynchronous notification result from the blockchain, it processes the result, updates the task status, and notifies the source application. The Digital Collections module also has a network connection to a front-end application. The front-end application encapsulates the digital collections operation instructions into operation work orders according to the digital collections operation protocol and sends the work orders to the Digital Collections Scheduling Engine through the interface.

[0030] As a preferred implementation, the front-end application (APP) encapsulates the data collection operation instructions into operation orders (ORDER) according to the Digital Collection Operation Protocol (DCOP) and sends the order to the Digital Collection Scheduling Engine (DCSE) through the interface.

[0031] After receiving a work order, DCSE adds it to the task queue and then synchronously returns a receipt to the front-end application.

[0032] DCSE's scheduling engine monitors the task queue, retrieves operation orders from the queue, parses the operation instructions, and then calls the corresponding blockchain interface for processing based on the instruction type.

[0033] Upon receiving the synchronized result from the blockchain's real-time return instruction, the task status is immediately updated. Simultaneously, the result is encapsulated using DCOP and fed back to the front-end application via the application's asynchronous notification interface.

[0034] The instruction of returning the result of the blockchain asynchronously updates the task state after obtaining the synchronous result, and feeds back the processing result to the application end through the asynchronous notification interface of the application end. At the same time, a subtask (the subtask records the preceding task number) is automatically generated, the asynchronous execution result is queried, and the final result is notified to the application end again after obtaining the asynchronous execution result.

[0035] As a preferred embodiment, the method is an operation layer between the front-end application layer and the blockchain layer, which links between the two, supports multiple front-end applications upward, and can be connected to multiple blockchain systems downward.

[0036] For the blockchain end, there may be asynchronous operations, such as some time-consuming processing, the blockchain end will also use the asynchronous mode, first returns the operation instruction number, and then queries the operation progress and returns the result according to the instruction number.

[0037] The method supports synchronous return of the blockchain and can also support asynchronous operation in the blockchain. For asynchronous operation, a query task is generated by automatically creating a subtask to obtain the result of the asynchronous operation.

[0038] As a preferred embodiment, the scenarios of the blockchain operation include two types of query and execution, the query type such as user collection query, digital certificate query, and certificate detail query, and the execution type such as user registration, collection issuance, transfer of certificates, and destruction of certificates.

[0039] For the execution type operation, the blockchain itself may also use the asynchronous mode, and does not directly return the result after operation, but returns the number of asynchronous requests, which can be used to query the execution result of the blockchain operation. The method supports slow operation of the synchronous blockchain and also supports operation of the asynchronous blockchain. For asynchronous blockchain operation, a subtask is generated to obtain the asynchronous return result, and steps 12, 13, 14, and 15 in the timing.

[0040] Operation order:

[0041] The digital collection scheduling engine (DCSE) runs in the order (ORDER) mode, receives the order from the front-end application (APP), and the order encapsulates the order number, operation number, request parameter, application number, and preceding order number, etc., as follows:

[0042] Work order number orderid Operation number actionid Request parameter requests Application number appid Preceding work order number Preorderid Execution result Result

[0043] Among them: the order number orderid is the unique identifier of the order, which is used to identify and locate the order.

[0044] The operation number actionid is a specific digital collection operation, including user registration, collection issuance, and other related operation instructions.

[0045] The request parameter requests encapsulates the parameter set required by the request instruction, such as the operator, collection number, digital certificate number, transferor, and recipient.

[0046] The application number appid is the identification of the front-end application, used to identify the source application.

[0047] The pre-order number preorderid is the order number of the front-end task. Some asynchronous operations exist on the blockchain side, and the results cannot be returned immediately, such as user registration and collection issuance. After the completion of the previous task and the receipt of the synchronous reply, the system will automatically generate a sub-task to receive and process the asynchronous result notification from the blockchain side. The previous task is the front-end task of the sub-task.

[0048] The execution result Result stores the execution result returned by the instruction.

[0049] Instruction set:

[0050] The operation instructions of digital collection include user registration, collection issuance, etc.

[0051] User registration userRegister Collection issuance mintShard Query user collection queryShardByAccount Query collection digital voucher queryShardByAsset Query digital voucher details getShardDetail Transfer digital voucher tranferShard Destroy digital voucher burnShard Query asynchronous request result getOperateResult …… ……

[0052] Different operation instructions require different request parameters, which are encapsulated in requests and parsed according to DCOP.

[0053] Input parameters:

[0054] The main input parameters agreed upon by the protocol are shown in the following table, where R is mandatory and O is optional.

[0055] With the development of business, more parameters can be extended according to the protocol agreement:

[0056]

[0057]

[0058] The format of instruction input parameters supports json and xml. According to actual business needs, other methods can also be used, as long as both upstream and downstream partners use the same format for encapsulation and parsing.

[0059] The following explains the encapsulation method of input parameters in Json format.

[0060] A. Example of main input parameters for user registration instruction:

[0061]

[0062]

[0063] B. Query user collection instruction main input parameter example:

[0064]

[0065] Output parameters:

[0066] The key features of the main output parameters agreed by the protocol are shown in the following table, where R is mandatory and O is optional.

[0067] More parameters can be extended according to the protocol as the business develops.

[0068]

[0069]

[0070] Among them:

[0071] Code is the response code, indicating whether the operation is successful or if an error is encountered.

[0072] Message is the response information, which returns detailed error information when the operation encounters an error.

[0073] Result is the return result, mainly used for query instructions, which returns the query result data. For execution instructions, this parameter is empty. Note: According to the different instructions, the return format of this parameter is different, and it needs to be parsed according to the protocol agreement.

[0074] Requestid is the request ID, used for asynchronous execution instructions (such as registration, issuance, etc.). The blockchain system does not return the operation result in real time, and the operation execution progress can be queried again according to this request ID.

[0075] The output format of the instruction operation result supports json and xml. According to actual business needs, other formats can also be used as long as both upstream and downstream partners use the same format for packaging and parsing.

[0076] The following explains the packaging method of the output result in Json format.

[0077] A. Main parameter example of user registration instruction output result:

[0078]

[0079] B. Main parameter example of user collection instruction output result:

[0080]

[0081]

[0082] Compatibility:

[0083] Task queue: The digital collectible scheduling engine (DCSE) recommends using a memory queue. In terms of implementation, according to the requirements of performance, compatibility, development difficulty, etc., a database can also be used to store tasks.

[0084] Work order type: The operation work order recommends using http+json. In terms of specific implementation, according to the requirements of compatibility, etc., http+xml, etc. can also be used.

[0085] Application docking: Through the adaptation of interfaces and logic operations, it can be suitable for various front-end APP calls.

[0086] Blockchain docking: Through the adaptation of interfaces and logic operations, it can be connected to a variety of different blockchain platforms.

[0087] Working principle: The method is an intermediate operation layer for bridging the front-end application layer and the blockchain layer, which is not the technology of the front-end application and the blockchain itself. The method is used to solve the problem of different performance of the front-end and the back-end, and can also be used for other businesses with large differences between the front-end and the back-end. The method is designed as a general solution, which can be connected to different applications and different blockchains, and can be scheduled in a task mode. It supports synchronous operations on the blockchain side and also supports asynchronous operations on the blockchain side (obtains the result of asynchronous operation through sub-tasks, asynchronous asynchronous). The method realizes the common operation on the process in the form of passing work orders, that is, abstracts the operation into the processing of work orders and the return of processing results. By converting the business operations into custom instruction parameters and business numbers, encapsulating them into work orders on the sending side and parsing work orders on the receiving side, different business request operations can be adapted.

[0088] The above embodiments of the application are described in detail in conjunction with the drawings. Those skilled in the art can make various changes to the application according to the above description. Therefore, some details in the embodiments should not be construed as limiting the application, and the scope of protection of the application will be defined by the appended claims.

Claims

1. A method for implementing an autonomous protocol for solving the calling of a back-end blockchain by a front-end application, characterized in that it comprises the steps of: The digital collectible module comprises a digital collectible operation protocol and a digital collectible scheduling engine; ​ The digital collectible operation protocol defines a processing protocol for various operations of the digital collectible, including user registration, collectible issuance, digital certificate transfer, digital certificate destruction, and various query operations, and encapsulates the various operations of the digital collectible to form operation instructions, which are scheduled and executed by the digital collectible scheduling engine; After receiving an operation request from the application, the digital collectible scheduling engine encapsulates the operation instructions as work orders according to the DCOP protocol and puts them into the task queue, and returns a receipt to the front-end application in synchronization; The DCOP protocol defines a processing protocol for various operations of the digital collectible, including user registration, collectible issuance, digital certificate transfer, digital certificate destruction, and various query operations, and encapsulates the various operations of the digital collectible to form operation instructions, which are scheduled and executed by the digital collectible scheduling engine; The digital collectible scheduling engine executes the instructions in the queue according to the scheduling strategy, parses the operation request and calls the block link interface to execute the operation, obtains the result of the block chain, processes and updates the task state, and then notifies the source application; The digital collectible module is also connected to a front-end application, which encapsulates data collectible operation instructions as operation work orders according to the digital collectible operation protocol, and sends the work orders to the digital collectible scheduling engine through an interface.

2. The method of claim 1, wherein the method further comprises: The operation mechanism of the digital collectible scheduling engine is as follows: After receiving the work order, the digital collectible scheduling engine adds the work order to the task queue and returns a receipt to the front-end application in synchronization; The scheduling engine of the digital collectible scheduling engine monitors the task queue and takes out the operation work order from the queue, parses the operation instruction, and calls the corresponding interface of the block chain for processing according to the instruction type; For instructions that return results from the block chain in real time, update the task state immediately after obtaining the synchronous result, and then feed back the result to the front-end application through the asynchronous notification interface of the application end after encapsulating the result according to the DCOP; For instructions that return results from the block chain asynchronously, update the task state after obtaining the synchronous result, and feed back the processing result to the application end through the asynchronous notification interface of the application end.

3. The method of claim 2, wherein the method further comprises: For instructions that return results from the block chain asynchronously, generate a subtask automatically when obtaining the synchronous result, query the asynchronous execution result of the block chain, and then notify the final result to the application end again after obtaining the asynchronous execution result.

4. The method of claim 3, wherein the method further comprises: The operation layer composed of the digital collectible operation protocol and the digital collectible scheduling engine is located between the front-end application and the block chain, and is used for linking between the front-end application and the block chain, the operation layer supports multiple front-end applications, and the operation layer interfaces with multiple block chain systems; The block chain end itself has asynchronous operations, and the block chain end uses an asynchronous mode to return an operation instruction number first, and then queries the progress and returns the result of the operation according to the instruction number.

5. The method of claim 4, wherein: The asynchronous operation generates a query task in the form of an automatically created subtask to obtain the result of the asynchronous operation.

6. The method of claim 4, wherein: The scenarios of the blockchain operation include two kinds of query type and execution type, the query type includes user collection query, digital certificate query and certificate detail query; The execution type includes user registration, collection issuance, transfer certificate and certificate destruction.

7. The method of claim 6, wherein the method further comprises: For the execution type operation, the blockchain itself can adopt an asynchronous mode, and after the operation, the result is not directly returned, but the number of asynchronous request is returned, and the execution result of the blockchain operation is queried through the number.

8. The method of claim 7, wherein the method further comprises: The blockchain is connected through the interface and the logical adaptation operation, and is connected with various different blockchain platforms.

Images