CN111667255B

CN111667255B - Digital asset transfer system and method based on alliance chain

Info

Publication number: CN111667255B
Application number: CN202010479050.8A
Authority: CN
Inventors: 林国斌; 刘刚; 张占礼; 刘彦平
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2020-05-29
Filing date: 2020-05-29
Publication date: 2023-04-07
Anticipated expiration: 2040-05-29
Also published as: CN111667255A

Abstract

The embodiment of the application provides a digital asset circulation system and a method based on a alliance chain, wherein the system comprises the following steps: a plurality of DApp nodes corresponding to the alliance chain are sent to the alliance chain for evidence storage; each DApp node is provided with a unique identity, and the two DApp nodes in an off-line state are used for performing double off-line transaction between each other, wherein the double off-line transaction comprises digital asset transaction and digital asset transfer; after any one of the two DApp nodes performing the double offline transaction is in an online state, the DApp node is used for asynchronously sending transaction information corresponding to the double offline transaction to the alliance chain for evidence storage, and three-party consensus is achieved between the two DApp nodes and the alliance chain. The method and the device can establish a value transfer mechanism of the digital assets for the alliance connection, can effectively establish trusted equipment resources for the transfer of the digital assets based on the alliance chain, and further can improve the decentralized degree on the basis of effectively improving the transaction data processing efficiency.

Description

Digital asset transfer system and method based on alliance chain

Technical Field

The application relates to the technical field of block chains, in particular to a digital asset circulation system and a digital asset circulation method based on a alliance chain.

Background

With the development of blockchain technology, real-world assets are rapidly digitized. If the distribution, circulation, validation, etc. of digital assets are performed efficiently, it is desirable to provide reliable techniques to do so.

But currently, the industry uses a public-link-based Token mechanism to establish a decentralized application DApp as a value transfer mechanism based on a blockchain technology. But the public chain has the problems of low efficiency and the like and cannot be used for large-scale commercial use. And a value transfer mechanism which is built in is not arranged under the alliance chain, the application is developed and applied based on the alliance chain, the client side which is accessed to an application layer of the alliance chain is corresponding to the public chain DApp, essentially, the whole alliance chain is regarded as a central facility, and the dependence of the client side on the alliance chain is in a centralized form. A federation chain has no nodes that can be equated to a public chain DApp. Federation chains are far less centralized than public chains, but more efficient than public chains. In the federation chain application architecture, the consensus nodes in the federation chain, as a whole, are in a centralized location. This problem will be more intuitively seen in fig. 1-4.

Referring to fig. 1 and fig. 2, all DApp nodes in a public chain are deployed in a peer-to-peer network (P2P), and interact with each other pairwise, each node uses a block storage technology to store a whole network account book, and a whole network consensus is achieved among all the DApp nodes. Referring to fig. 3 and 4, a blockchain network is formed by several consensus nodes in a federation chain by using a blockchain technology, and the network becomes a server node of a blockchain application of the federation chain, while different clients in the application system of the federation chain can perform business processing by connecting any consensus node in the federation chain. The consensus process applied by the federation chain occurs only in block chain consensus nodes, which use block storage techniques to store a common ledger in each consensus node within the chain. The client nodes of the federation chain application do not participate in the consensus process and save the consensus ledger. The application structure of the public link DApp belongs to a peer-to-peer application mode (P2P mode), while the federation link application mode is a server-client mode (CS mode).

Therefore, how to establish a value circulation mechanism of digital assets for a federation connection is a problem to be solved urgently at present.

Disclosure of Invention

Aiming at the problems in the prior art, the application provides a digital asset circulation system and method based on a alliance chain, which can establish a value circulation mechanism of digital assets for alliance connection, can effectively establish trusted equipment resources for digital asset circulation based on the alliance chain, and further can improve the decentralized degree on the basis of effectively improving the transaction data processing efficiency.

In order to solve the technical problem, the application provides the following technical scheme:

in a first aspect, the present application provides a federation chain-based digital asset transition system, comprising: a plurality of DApp nodes for receipt, storage, and transfer of digital assets corresponding to a federation chain that is an issuer of the digital assets;

each DApp node is respectively provided with a corresponding unique identity, and the running state of the DApp node comprises an offline state in which the network connection with the node in the alliance chain is not established and an online state in which the network connection with the node in the alliance chain is established;

the two DApp nodes in the offline state are used for performing double offline transactions between each other, and the double offline transactions comprise digital asset transactions and digital asset transfer;

after the operation state of any one of the two DApp nodes for performing the double offline transaction is changed into the online state, the DApp node in the online state is used for asynchronously sending transaction information corresponding to the double offline transaction to the alliance chain for evidence storage, and three-party consensus is achieved between the two DApp nodes for performing the double offline transaction and the alliance chain.

In a second aspect, the present application provides a federation chain-based digital asset transfer method, where the federation chain-based digital asset transfer method is implemented by using the federation chain-based digital asset transfer system;

the digital asset circulation method based on the alliance chain comprises the following steps:

after the issuing node in the alliance chain issues the digital assets, transferring the digital assets required by the DApp node to the DApp node;

the two DApp nodes in the offline state perform the double offline transaction between each other;

after the running state of any one of the two DApp nodes for performing the double offline transaction is changed into the online state, the DApp node in the online state asynchronously sends transaction information corresponding to the double offline transaction to the evidence storing node in the evidence storing process of the federation chain, and the two DApp nodes for performing the double offline transaction and the federation chain achieve three-party consensus.

According to the technical scheme, the system and the method for digital asset circulation based on the alliance chain comprise the following steps: a plurality of DApp nodes for receipt, storage, and transfer of digital assets corresponding to a federation chain that is an issuer of the digital assets; each DApp node is provided with a corresponding unique identity, and the running state of the DApp node comprises an offline state in which the network connection with the node in the alliance chain is not established and an online state in which the network connection with the node in the alliance chain is established; the two DApp nodes in the offline state are used for performing double offline transactions among each other, and the double offline transactions comprise digital asset transactions and digital asset transfer; after the operation state of any one of the two DApp nodes performing the double offline transaction is changed into the online state, the DApp node in the online state is used for asynchronously sending transaction information corresponding to the double offline transaction to the alliance chain for evidence storage, and three-party consensus is achieved between the two DApp nodes performing the double offline transaction and the alliance chain, so that trusted device resources can be established, a cooperation mechanism between the resource-based devices can be established, and a digital resource issuing and transferring mechanism can be provided, for example, offline payment of an electronic wallet (such as an electronic RMB issuing and transferring mechanism) or a resource issuing and transferring mechanism after securities are digitalized, so that the decentralization degree can be improved on the basis of effectively improving the transaction data processing efficiency, and a possibility is provided for establishing a new accounting system.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following descriptions are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a schematic diagram of a public-link DApp node deployment model.

FIG. 2 is a schematic diagram of a point-to-point model of the public chain DApp.

FIG. 3 is a schematic diagram of a federation chain application node deployment model.

FIG. 4 is a schematic diagram of a server-client model of a federation chain application.

Fig. 5 is a schematic diagram illustrating a logical relationship between a DApp node and a federation chain node in the digital asset transition system based on federation chain according to an embodiment of the present application.

FIG. 6 is a diagram of federation chain value transfer provided by an application example of the present application.

Fig. 7 is a diagram of a reference unit structure of a digital resource provided in an application example of the present application.

Fig. 8 is a schematic diagram of resource block distribution provided in the application example of the present application.

Fig. 9 is a digital resource flow diagram provided in an application example of the present application.

Fig. 10 is a schematic diagram of an a-node split resource block provided in an application example of the present application.

Fig. 11 is a schematic diagram of a transfer of a data block provided in an application example of the present application.

Fig. 12 is a schematic diagram of merging of data blocks provided in an application example of the present application.

Fig. 13 is a schematic diagram of a data storage manner of the DApp node according to an application example of the present application.

Fig. 14 is a schematic diagram of table storage before and after a node a splits before transaction according to an application example of the present application.

Fig. 15 is a schematic diagram of table storage of easy before and after a nodes provided in the application example of the present application.

Fig. 16 is a schematic diagram of table storage of node B before and after transaction provided by an application example of the present application.

Fig. 17 is a schematic diagram of data storage after synchronization between the node a and the federation chain, according to an application example of the present application.

Fig. 18 is a schematic diagram of data storage after nodes are synchronized by a federation chain according to an application example of the present application.

Fig. 19 is a schematic diagram of defragmentation of resources on the federation chain as provided in the application example of the present application.

Fig. 20 is a schematic diagram of a DApp node and a federation chain synchronization process provided in an application example of the present application.

Fig. 21 is a schematic diagram of a data snapshot structure provided in an application example of the present application.

Fig. 22 is a schematic diagram of a federation chain certification result data packet provided in the application example of the present application.

Fig. 23 is a schematic diagram of data snapshot merging federation link message data provided in an application example of the present application.

Fig. 24 is a schematic diagram of point borrowing and credit verification provided in an application example of the present application.

Fig. 25 is a schematic diagram of a service model of a DApp service network according to an example of the application of the present application.

Fig. 26 is a schematic diagram of a basic structure of a DApp node according to an application example of the present application.

Fig. 27 is a schematic diagram of a deployment form of the DApp node according to an application example of the present application.

Fig. 28 is a schematic diagram of a topological relationship between a DApp node and a federation chain according to an application example of the present application.

Fig. 29 is a schematic diagram of the evolution of DApp compared with App provided in the application example of the present application.

Fig. 30 is a schematic diagram of a DApp node and a federation chain synchronization process provided in the application example of the present application.

Fig. 31 is a diagram illustrating a data snapshot structure of a DApp node according to an exemplary application of the present application.

Fig. 32 is a schematic diagram of a three-point consensus structure provided in an application example of the present application.

Fig. 33 is a schematic diagram of a mechanism for consensus between DApp nodes according to an example of the application.

Fig. 34 is a schematic diagram of a three-point consensus method provided in an application example of the present application.

Fig. 35 is a schematic diagram of a DApp service architecture provided in an application example of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.

The block chain is a distributed account book technology and has the characteristics of decentralization, no tampering, traceability and the like. The application provides a system and a method for constructing a decentralized application (DApp) based on alliance connection, which are used for realizing the distribution and circulation of digital assets.

The core purpose of this application is to establish a value circulation mechanism for federation.

Specifically, a trusted node is established on the basis of alliance connection, and the issuing, circulation and right confirmation of assets are realized. So-called node trustworthiness, i.e., the DApp running on a device, acts as a node whose generated data can unambiguously and unambiguously identify that the device was generated and issued. It can be determined from the stored form of the data that a certain data originates from a specific device or DApp node without error. On any DApp node, the system capability and the method for digital asset transaction and digital asset reliable transfer are provided pairwise, and on the basis, DApp node application with thousands of actual functions can be constructed. To achieve the above purpose, the following points must be firstly achieved:

1. each DApp node is provided with a unique identity.

The DApp node has the basic capability of receiving, storing and transferring the digital assets.

If the resource used by the DApp service system is electronic money, the issue of issuing, transferring and managing audit of the electronic money needs to be considered. In terms of technical problems, the following needs are considered:

4. double off-line transaction: namely, the two clients are in an offline state, but can realize the circulation of digital assets, and after any party of the DApp node is online, the transaction information can be stored and certified to a federation chain.

5. The digital assets are not allowed to be copied and forged in the distribution and circulation processes.

6. The trading of any two DApp nodes is not constrained by the establishment of the federation chain system bearer.

The two parties of the DApp node transaction and the party of the alliance chain reach a three-party consensus.

8. And (4) auditing management of the program can be implemented in the process of issuing and circulating the digital assets of the DApp node.

Based on this, in order to establish a value transfer mechanism of digital assets for a federation connection, and effectively implement establishing trusted device resources for digital asset transfer based on a federation chain, and further improve the decentralized degree on the basis of effectively improving transaction data processing efficiency, an embodiment of a digital asset transfer system based on a federation chain is provided in the embodiments of the present application, and with reference to fig. 5, the digital asset transfer system based on a federation chain specifically includes the following contents:

a plurality of DApp nodes for receiving, storing, and transferring digital assets corresponding to a federation chain as an issuer of the digital assets, each DApp node being connected to at least one DApp; each DApp node is provided with a corresponding unique identity, and the running state of the DApp node comprises an offline state in which the network connection with the node in the alliance chain is not established and an online state in which the network connection with the node in the alliance chain is established; the two DApp nodes in the offline state are used for performing double offline transactions among each other, and the double offline transactions comprise digital asset transactions and digital asset transfer; after the operation state of any one of the two DApp nodes for performing the double offline transaction is changed into the online state, the DApp node in the online state is used for asynchronously storing the transaction information corresponding to the double offline transaction to the federation chain, and three-party consensus is achieved between the two DApp nodes for performing the double offline transaction and the federation chain.

In one embodiment of the federation chain-based digital asset transition system of the present application, the DApp node is configured to implement an underlying base service and an application layer service on top of the underlying base service; the underlying base service includes: network communication, identity authentication, and a transaction service connected with the alliance chain to call intelligent contracts of the alliance chain and digital resources; the application layer services include: and invoking the service of the bottom foundation.

Specifically, a DApp node contains two layers of functionality, one being the underlying basic service functionality. The method provides network communication, identity authentication, connection with a alliance chain, and calling an intelligent contract of the alliance chain to realize the transaction basic function of the digital resource. The application layer is above the basic service function of the DApp bottom layer, and calls the bottom layer function service to realize various specific application logics facing to DApp users. The DApp node mentioned in the text emphasizes how the underlying basic service functions of the DApp are implemented. In the DApp service network, the federation chain realizes each function assumed by the DApp node by providing related intelligent contracts for the DApp node to call. Communication between the DApp node and the federation chain is asynchronous. The result of the federation chain's processing of the DApp transaction data is asynchronously returned to the DApp node via a messaging mechanism. The DApp node does not participate in the consensus process of the consensus nodes in the federation chain. The consensus achieved by the DApp node in the transaction process and the consensus between the consensus nodes in the alliance chain are completely two independent processes and have no synchronous relation with each other. The implementation of functions in the DApp application services network may be viewed as a specific blockchain application implemented on the existing architecture of the federation chain to avoid affecting the operation of the federation chain itself.

In one embodiment of the federation chain-based digital asset transfer system of the present application, the federation chain is further configured to perform DApp node registration, register DApp node identity information, certify DApp node transaction data, and store defragmentation digital resource fragments. That is, in the DApp application service network, the federation chain takes on the functions of digital resource issuance, DApp node registration, DApp node identity information registration, DApp node transaction data storage and digital resource fragmentation sorting. The alliance chain is used as a social service party, stores data of the DApp nodes, and stores and proves transaction data among the DApp nodes, so that the transaction data among the DApp nodes cannot be tampered. All the registration information of the DApp nodes and transaction data generated among the DApp nodes are finally stored in the federation chain, and the federation chain knows the specific affiliation of each data and the relationship among the data.

In one embodiment of the federation chain-based digital asset circulation system of the present application, the digital asset comprises a plurality of resource block reference units and the basic information of each of the resource block reference units comprises a unique number, a publisher and a corresponding digital asset class. Specifically, the transferable digital resource is regarded as a plurality of isolated resource block reference units with continuous numbers, so as to be managed, and each resource block reference unit is provided with some basic information, such as: unique number, issuing authority, resource category. A resource block is made up of several consecutive resource block reference units. The resource block reference unit is a minimum unit of allocation of resource blocks. Such as: for electronic renminbi, a reference unit of 1 yuan per resource block may be set.

In one embodiment of the alliance-chain-based digital asset transition system of the present application, a plurality of resource block reference units, which are consecutively numbered, constitute a resource block, and attributes of each of the resource blocks include: head number, tail number, volume, issuing authority, and digital asset class of issue. Specifically, each resource block reference unit has a unique number. The set of consecutive resource block reference units is called a resource block, and the attributes of each resource block include: head number, tail number, volume, issuing authority, issuing category. The issuing mechanism and the resource category of each resource block are completely consistent with those of the reference unit contained in the resource block, so that the reliability of digital asset circulation is ensured.

In one embodiment of the alliance chain-based digital asset circulation system of the present application, a chain composed of a plurality of sequentially linked resource blocks is a resource chain; and the resource chain is stored in the DApp node in a data table form, wherein the data table comprises a current resource block number, a resource block head address, a resource block length, a resource block tail address and a next resource block address. In particular, a chain consisting of a plurality of resource blocks linked back and forth is referred to as a resource chain. In particular, in the DApp business hierarchy, the public key of the resource issuer must be available. To verify the source of legitimacy of the resource block. A plurality of continuous resource blocks form resource packets, and each resource packet has a start-stop number of the resource block, so that the safety and the legality of digital asset circulation of the alliance chain are effectively improved.

In the DApp provided by the application, the resource block is issued by a federation chain, the DApp is only used and circulated with the resource block, and the federation chain and the DApp jointly form a service chain for completing issuing, circulating, splitting, merging and storing of the resource.

In an embodiment of the system for digital asset circulation based on a federation chain of the present application, the DApp node is a software system running on an intelligent terminal, and the federation chain runs on a cloud software platform.

In particular, smart front-end refers to various smart end machines and edge computing devices, such as: cell-phone, camera, automatic driving vehicle, robot, unmanned aerial vehicle, network equipment, unmanned vending machine, intelligent production line equipment, sharing hardware equipment etc.. The intelligent front end has the technical characteristics that: the system has the basic characteristics of autonomous operation, programmability, remote control, limited computing power, limited memory, one or more networking capabilities, intermittent and indefinite network environment and the like. Also known as an intelligent front end as an autonomous object, the present application uses intelligent front ends in unison. The DApp under the federation chain discussed in this application is a software system running on a smart item, a functional node running on computing, logic processing and storage is applied to various end machines and edge computing devices, namely the last two of cloud, edge and end, and federation chain services on which the DApp depends run at the cloud.

As can be seen from the above description, the federation chain-based digital asset transfer system provided in the embodiment of the present application can establish trusted device resources, establish a cooperation mechanism between the resource-based devices, and provide a digital resource issuing and transferring mechanism, for example, implement offline payment of an electronic wallet (e.g., an electronic renminbi issuing and transferring mechanism), or a resource issuing and transferring mechanism after securities are digitized, so as to improve the decentralized degree on the basis of effectively improving the transaction data processing efficiency, and provide a possibility for establishing a new accounting system.

In order to establish a value transfer mechanism of digital assets for a federation connection, effectively establish trusted device resources for the transfer of digital assets based on a federation chain, and further improve decentralized degree on the basis of effectively improving transaction data processing efficiency, the present application further provides an embodiment of a digital asset transfer method based on a federation chain, which is implemented by applying the digital asset transfer system based on a federation chain, and the digital asset transfer method based on a federation chain specifically includes the following contents:

s100: and after the issuing node in the alliance chain issues the digital assets, transferring the digital assets required by the DApp node to the DApp node.

S200: the two DApp nodes in the offline state conduct the double offline transaction between each other.

S300: after the operation state of any one of the two DApp nodes for performing the double offline transaction is changed into the online state, the DApp node in the online state asynchronously stores the transaction information corresponding to the double offline transaction to a storage node in the federation chain, and three-party consensus is achieved between the two DApp nodes for performing the double offline transaction and the federation chain.

In a specific implementation manner of step 300 provided in this application, in order to effectively improve reliability of transaction information evidence preservation, a process of the online DApp node asynchronously preserving transaction information corresponding to the dual offline transactions to the evidence preservation node in the federation chain specifically includes the following steps:

s310: aiming at two DApp nodes corresponding to the same double offline transaction, the alliance link receives transaction information corresponding to the double offline transaction sent by one DApp node and registers the transaction information.

S320: and receiving transaction information corresponding to the double offline transactions sent by the other DApp node corresponding to the same double offline transactions, confirming the transaction information, and returning a corresponding confirmation result to the other DApp node.

In a specific embodiment of the alliance-chain-based digital asset transfer method provided by the present application, in order to effectively improve the reliability of transaction information storage, the alliance-chain-based digital asset transfer method further includes the following steps:

s400: and after each transaction or after receiving the confirmation result sent by the alliance chain, the DApp node stores the current condition of the existing data chain and the transaction data corresponding to the current transaction or the current confirmation result sent by the alliance chain as a data packet.

As can be seen from the above description, the federation chain-based digital asset transfer method provided in the embodiment of the present application can establish trusted device resources, establish a cooperation mechanism between the resource-based devices, and provide a digital resource transfer and transfer mechanism, for example, implement offline payment of an electronic wallet (e.g., an electronic renminbi issue and transfer mechanism), or a resource transfer and transfer mechanism after securities are digitized, so as to improve the decentralized degree on the basis of effectively improving the transaction data processing efficiency, and provide a possibility for establishing a new accounting system.

To further explain the solution, the present application further provides an application example of a digital asset transfer system and method based on a federation chain, which specifically includes the following contents:

1) Under-alliance DApp node value transfer model

Referring to fig. 6, the present application designs the above model as a business model for a DApp application under a federation chain. Under the model, the alliance chain serves as a digital asset issuer issuing value, and the DApp node serves as a value transfer node and transfers the value. Namely: the digital assets are issued on the alliance chain and then transferred to the DApp node, and the DApp node uses the digital assets issued by the alliance chain as a transaction medium in the transaction process and finally uploads transaction information to the alliance chain for evidence storage processing. The transaction data generated by the DApp node is credible, traceable and difficult to tamper by the transaction parties and the three-point service of the alliance chain.

The DApp node constructed by the application aims to construct a value transfer mechanism on the basis of the existing federation chain, so that a DApp service system constructed on the basis of the federation chain has an internal digital asset issuing and circulation mechanism, the mechanism is constructed into the internal basic capability of the DApp, and any functional node with computing, logic processing and storage is applied to various end computers and edge computing equipment, namely the last two of cloud, edge and end, so that the capability of storing and transferring the value among the nodes is provided.

With the support of the DApp architecture, the DApp node has trusted node capabilities. Any operation, storage and operation process can irrefutably determine which DApp node is, and the user of the DApp node bears the irrevocable responsibility. After the DApp technology architecture provides basic capability for storage and transfer of digital assets for each DApp node, any business logic can be implemented based on specific applications among all the DApp architectures.

2) Functional division of labor between DApp nodes and federation chains

A DApp node contains two layers of functionality, one being the underlying basic service functionality. The method provides network communication, identity authentication, connection with a alliance chain, and calling an intelligent contract of the alliance chain to realize the transaction basic function of the digital resource. The application layer is above the basic service function of the DApp bottom layer, and calls the bottom layer function service to realize various specific application logics facing to DApp users. The DApp node mentioned in the text emphasizes how the underlying basic service functions of the DApp are implemented.

In the DApp service network, the federation chain realizes each function assumed by the DApp node by providing related intelligent contracts for the DApp node to call. Communication between the DApp node and the federation chain is asynchronous. The result of the processing of the DApp transaction data by the federation chain is asynchronously returned to the DApp node via a messaging mechanism. The DApp node does not participate in the consensus process of the consensus nodes in the federation chain. The consensus achieved by the DApp node in the transaction process and the consensus between the consensus nodes in the alliance chain are completely two independent processes and have no synchronous relation with each other. The implementation of functions in the DApp application services network may be viewed as a specific blockchain application implemented on the existing architecture of the federation chain.

3) Data processing relationship between DApp nodes and federation chains

In the DApp application service network, the alliance chain plays a role in digital resource publishing, registration by the DApp node, registration of DApp node identity information, evidence storage of DApp node transaction data and storage and sorting of digital resource fragments. The alliance chain is used as a social service party, stores data of the DApp nodes, and stores and proves transaction data among the DApp nodes, so that the transaction data among the DApp nodes cannot be tampered. All the registration information of the DApp nodes and transaction data generated among the DApp nodes are finally stored in the federation chain, and the federation chain knows the specific affiliation of each data and the relationship among the data.

4) DApp node design goal

1. Efficiency is prioritized: the financial services support capabilities of the DApp node do not place a great deal of stress on existing systems. The efficiency of the transaction between DApp nodes depends only on the parties to the transaction.

2. Avoiding environmental dependence: the DApp nodes should not be overly network dependent, ensuring that they can trade each other when the network is disconnected.

3. Irrecoverable liability: any DApp node has a unique identity mechanism, and any operation occurring in the DApp service system, such as operation, storage, data communication and the like, necessarily has a DApp node responsible for the corresponding operation.

4. Tamper-proof: the transaction data that has occurred is stored on the DApp nodes of both parties to the transaction, on the one hand, and on the other hand, the certificate is stored on the federation chain. The two transaction parties and the alliance chain form a three-party consensus. Each DApp node superposes and stores all past transaction data of the node in a block storage mode.

5. Copy-not-compatible: the digital asset transaction capability provided by the DApp service system must ensure that once each unit (each share) of digital assets is issued, the digital assets must be attributed to a specific node at any time in the subsequent circulation process, and cannot be attributed to more than one DApp node at the same time. If not, necessarily in the management of the federation chain.

5) Service characteristics of DApp node

5-1) logical relationship formed by DApp nodes under federation chain

Referring to fig. 5, the dots in the figure indicate DApp nodes. The rectangle represents a federation chain node. The rectangular bar represents a federation chain. The lower case nodes in the DApp nodes represent the offline DApp nodes. After the DApp nodes go offline, the nodes need to realize that each other can do double offline transactions. The transaction data is stored in blocks, and signature verification is carried out in a public-private key mode, so that the data resource is confirmed to be transmitted from one node to another node. After the DApp nodes are connected, data are written into the alliance chain and are agreed with all the nodes of the alliance chain.

5-2) counterparty data between DApp nodes

In the deployment relationship depicted in fig. 5, the implication of transactions between DApp nodes is that under certain business logic, a transfer of digital resource points occurs between two different DApp nodes. When a transaction occurs between the DApp nodes, counterparty data is generated. The counterparty data refers to transaction information which is generated by two transaction parties and has consistent and logical meanings but slightly different expressions. For example, if node A transfers 200 resource points to node B, then for DApp node A, the information expressed is: a-100 >. For the node B, the information expressed is: b +100 were constructed as a, and this information was designated as B. A and b are information of mutual transaction opponents. After the transaction between the DApp nodes is finished, the DApp nodes of both transaction parties respectively upload the transaction data to the federation chain evidence storage processing. As shown in the above example, DApp node A uploads A-100> -B and DApp node B uploads B +100<A.

5-3) communication mechanism between DApp nodes

The method for uploading the transaction information to the federation chain by the DApp node is an asynchronous mode, namely: during the transaction process between the DApp nodes, interaction with the alliance chain is not needed, but after the transaction is finished, if the DApp nodes can establish network connection with the alliance chain at the moment, the DApp nodes can upload the transaction data to the alliance chain nodes quickly.

The DApp nodes are deployed in the intelligent physical equipment, and each DApp node can be interconnected with the alliance chain in a network communication mode. Any DApp nodes can be connected and interacted, and can be connected in any mode. Such as: the method comprises the following steps that Bluetooth, two-dimension code mutual scanning, NFC near field communication, high-frequency sound waves, character codes and other means are used for interconnection transaction, if one physical device comprises a plurality of DApp nodes, transaction can be conducted among the nodes in an inter-process communication mode. The post-trade DApp node generates opponent data. And the transaction data generated by the DApp nodes are uploaded to a federation chain respectively, and all nodes in the federation chain complete the consensus storage of the transaction data of the DApp nodes.

5-4) DApp node financial service mechanism

The trusted use of the public private key and the digital signature technology to realize the DApp can treat the items which can be exchanged with each other in the transaction process as a transferable digital asset. DApp may implement a wide variety of specific business transactions based on the transferable digital assets.

In order to realize the transaction characteristics of the digital assets, a plurality of items such as issuing, circulation, storage, merging and the like of the digital assets need to be considered, namely, the circulation requirement in the transaction is met, and the supervision requirement needs to be considered synchronously. For this purpose, the present application considers the converted matter (equivalent exchange) in the transaction process as the resource, and realizes the basis of the trading property of the DApp by realizing the issuing, the transferring, the storing and the merging of the resource. The essence of a DApp transaction is the tagging of a digital asset, the transaction process of a digital asset, and in fact the process by which a data asset is relinquished from one subject to another. By technical means, it is ensured that only one subject owns a particular digital resource at any one time. The issuing, circulation filing and recovery management of digital resources by the alliance chain represent the acceptance of the data resource circulation process by the public. The circulation of data resources among the DApp nodes represents the joint approval of the two trading parties to the attribution allowance of the digital resources.

5-5) related concepts of resource blocks

The digital resource which can be circulated is regarded as a plurality of resource block reference units which are composed of a plurality of isolated continuous numbers, and each resource block reference unit is provided with some basic information, such as: unique number, issuing authority, resource category. A resource block is made up of several consecutive resource block reference units.

They are the smallest unit of allocation of resource blocks. Such as: for electronic renminbi, each resource block reference cell may be set to 1-element renminbi. Each resource block reference unit has a unique number.

6) Digital resource block concept

Referring to fig. 7, a set composed of a plurality of consecutive reference units of a resource block is called a resource block, and the attribute of each resource block includes: head number, tail number, volume, issuing authority, issuing category. The issuing organization and resource category of each resource block completely coincide with the issuing organization and resource category of the reference unit included in the resource block.

7) Digital resource chain concept

A chain consisting of a plurality of resource blocks linked back and forth is called a resource chain.

In the DApp business hierarchy, the public key of the resource issuer must be available. To verify the source of validity of the resource block. A plurality of consecutive resource blocks form resource packets, each resource packet having a start-stop number of a resource block.

8) Digital resource issuing method

Referring to fig. 8, the distribution of digital assets is over a federation chain. The term distribution is intended to mean that some of the assets that are present are represented in a digitized form, and the digital assets that these digitized assets form are referred to as digital resources in this application. These digital resources may consist of reference units. The circulation process of the digital assets is realized through management processes of splitting, transferring, recording, merging and the like of the digital resources. This flow process, in turn, may be referred to as the equivalent of a general transaction.

After the digital assets are released, the corresponding digital resource reserves on the alliance chain can be provided to the DApp node at any time. If the number of the issued data resources is excessive and is transferred to the number of DApp nodes, the number required by DApp can be split from the data chain blocks of the existing reserves of the issuer and transferred to the DApp nodes.

One specific distribution process is shown in FIG. 8. The figure illustrates the distribution flow process for a 500 point physical asset to a 500 point digital asset. When the 500-point physical resource is converted into the 500-element digital resource, a 500-point digital resource block is formed, the number of the head of the resource block is 1000, the number of the tail of the resource block is 1499, the length of the digital resource block is 500, and the resource block is a continuous resource block. The resource block belongs to a specific issuing node (in practice: bank accounting) in the alliance chain. When a certain number of data resources need to be transferred to a certain DApp node, the digital resource block is split into different resource blocks, and the digital resource block equivalent to the digital resource block required by the DApp node is transferred to the DApp node by a union link.

As shown in fig. 8, when a DApp node needs to be assigned 100 points from the federation chain, only one principal has a particular digital resource from and at any one time.

9) Digital resource flow mechanism

The process of digital resource block flow exists between the federation chain distribution node and the DApp node, or between the DApp nodes. The mechanism of flow between any two DApp nodes is the same. In any DApp node, a data resource chain stores the data resource blocks currently owned by the node. The relationship of the data of the flow between the DApp nodes is illustrated in fig. 9. In this example, see if 30 points of resource block transfer occur and are implemented.

In FIG. 9, there is one DApp node A, referred to as the A node. Three resource blocks are provided, the length of each resource block is 10, 8 and 28, the total amount of digital resources used by the DApp node is 46, and each resource block is linked back and forth to form a data chain. The data chains are stored in the DApp node in the form of data tables. Also shown in fig. 9 is a DApp node B, referred to as node B. The node B contains 2 data blocks of

length

100 and 25, respectively, also stored in the DApp node as a data table.

Referring to fig. 10, when the a node needs to transfer 30 points to the B node, the a node needs to split through data blocks to form a sub-chain with a length of 30 points. The data block of length 8 in the a node is split into 2 data blocks, and the length of the data blocks is 6 and 2 respectively. After splitting, the total amount of the resource chain of the node A is unchanged, but the number of data blocks in the chain is changed from 3 to 4, and the data amount of one sub-chain is just 30.

Referring to fig. 11, when node a transfers 30 points to node B, the node a splits up a total number of child chains equal to 30, and transfers the created communication link between node a and node B from node a to node B. After the transfer, the total chain length of the node A is reduced by 30 points, and the total chain length of the node B is increased by 30 points.

Referring to fig. 12, after the sub-chain of the node a is transferred to the node B, that is, after the transaction, the formed new data chain and the transaction data sub-chain are uploaded to the federation chain when being in the networking state at the node, respectively, and after the federation chain performs transaction record and data chain integration processing, new data blocks are formed, respectively, and are issued and transmitted back to the node a and the node B.

10 ) storage of resources

The linked list of data resource blocks is stored in the DApp node in the form of a data table. As shown in fig. 13. The method comprises the following steps: resource block number, resource block head address, resource block length, resource block tail address, next resource block address. For convenience of calculation, the resource blocks are generally sorted according to their sizes.

Referring to fig. 14, when 30-point data resources need to be paid out externally, the a-node data chain is split, as shown in fig. 14. The original node with the length of 8 is split into a node with the length of 2 and a node with the length of 6.

As can be seen from fig. 15, after the node a pays 30 points outwards, the data chain of the node a only has 2 data resource blocks left.

As can be seen from fig. 16, after the node B receives 30 external transmissions, the data link of the node B is increased by 2 data resource blocks.

The process of data storage after the node A is synchronized with the federation chain is shown in FIG. 17, and the process of data storage after the node A is synchronized with the federation chain is shown in FIG. 18.

11 ) a merging algorithm of resources

As shown in fig. 19, when the federation chain is used as an issuer and continuously forwards some data blocks to the DApp node by means of splitting, more and more data blocks are inevitably generated on its own data chain, and the data blocks may have smaller and smaller values, i.e. a large amount of data fragments are formed.

As shown in fig. 20, each DApp node uploads its own data chain to the federation chain after a transaction. For the same transaction data, the federation chain will accept the same transaction data at least twice. The first time is to receive new transaction data and the second time is to receive counterparty data. When the alliance chain receives the transaction data, the alliance chain registers the transaction data and does not carry out data sorting operation. And when the alliance chain receives the data of the transaction opponent, the alliance chain confirms the transaction data and returns a confirmation result to the DApp node in an asynchronous mode.

After receiving the data chain of the DApp node, the federation chain is responsible for merging and sorting the data and issuing a new data block to the DApp node so as to ensure the simplicity and convenience of calculation.

When data merging is implemented, under the condition of keeping the whole amount of the resource block unchanged, the distributed address is distributed from the unallocated address block, and the distributed address is recycled. The process of migration and allocation is recorded in the federation chain.

A data block A is provided, the starting address of the data block A is x1, the ending address of the data block A is y1, and the length L1 of the data block A is y1-x1+1.

There is another data block B with a start address of x2 and an end address of y2, and the length L2 is y2-x2+1.

If the fragmented data blocks A and B are to be eliminated, a data block C with the length of L1+ L2 is allocated to the lower DApp node from the currently unallocated blocks with the starting address of p. While labels a and B are blocks to be allocated. And sequencing all the data blocks to be distributed according to the starting addresses, and combining the front data block and the rear data block into a new data block if the starting addresses and the stopping addresses are connected. If the two data block addresses A and B are connected, then it is necessary: x2= y1+1, a and B may be combined to form a new data block D, where D has a start address of x1, an end address of y2, and a length of y2-x1+1. The label D is an unallocated data block.

12 DApp node data snapshot

Referring to fig. 21, for a DApp node, a data snapshot is generated after each transaction or after the federation chain marshals the resource block data. The snapshot is similar to a log, and saves the current existing data chain condition (hereinafter referred to as a storage chain) and the transaction data occurring in the transaction as a data packet. After processing the data snapshot of the DApp node, the federation chain generates a delivered result data packet, wherein the data packet includes an integration result of the resource blocks in the snapshot and a confirmation result of the transaction data.

When the federation chain verifies the transaction data of the DApp node, the data packet structure of the DApp node is as shown in FIG. 22, the DApp replaces the data chain in the node according to the resource block result, and after networking, returns the processing state to the federation confirmation to confirm the verification result, and the DApp node has received the verification result.

After receiving the certificate storage data packet issued by the alliance chain, the DApp node carries out snapshot superposition processing on the data packet before the moment, and a new data snapshot is formed after each processing. As shown in fig. 23, after 2 transactions, data snapshot 1 and data snapshot 2 are formed, and when a certificate storage confirmation result issued by the federation is received, data snapshot 3 and data snapshot 4 are generated, and the next transaction is continued on the basis of data snapshot 4, and after the third transaction is finished, data snapshot 5 is generated. After the transaction, the network is successfully connected, the certification storage results 11 and 12 of the alliance chain are received, a data snapshot result 6 is generated, and the next transaction is carried out on the basis.

13 Transaction data debit point upload mechanism

After the DApp node is traded, the trading data needs to be submitted to a federation chain, and the federation chain carries out trading data storage and digital resource defragmentation. And the federation chain can only arrange the data after receiving the data sent by the DApp node for double transaction.

In order to ensure that the transaction data of the DApp node is uploaded as soon as possible, after the DApp node is transacted, the transaction data which is not stored by the other party needs to be mutually transmitted. When the DApp node finds that the DApp node is currently in the networking process, an asynchronous thread is used for uploading all node data snapshots which are not stored in the DApp node to the federation chain storage processing. Referring to fig. 24, a, B and C are DApp nodes, respectively, and after B and C transact, B and C mutually store the transaction data of the non-linked chain certificate of the other party. When A and B trade, A and B also mutually store the non-stored data of the other side, wherein the non-stored data of C stored by B comprises the non-stored data of C, if A is connected into the alliance chain before B and C, snapshot data which is not stored by A and non-stored snapshot data of other nodes stored by A are uploaded to the alliance chain. Thus, although B and C are not connected to the network, the transaction snapshot data of B and C are uploaded to the alliance chain through A. After B, C joins the network again, can receive the result of depositing the evidence of their own non-deposited snapshot directly from the alliance chain.

When the alliance chain receives transaction snapshot data of the DApp node, on one hand, existing chain combination is carried out, on the other hand, whether the transaction data in the snapshot are subjected to evidence storing processing or not is checked, and if not, the evidence storing processing is carried out. If the transaction data in the current snapshot is found to be inconsistent with the previous one, the alarm is raised.

Thus, during the transaction, any node may exist, although it is always not networked, but its transaction partner data has been certified in the federation chain.

14 To cope with loss of data resources

If a certain DApp node has a data snapshot without evidence after a plurality of transactions, if the DApp node is damaged and the data in the DApp node is completely lost, two conditions exist:

although there is a data snapshot which is not uploaded by the node in the DApp node, the DApp node is replaced by another node to upload the certificate, and after the DApp node is reassembled, the data snapshot which is finally stored with the certificate and all previous transaction records are recovered from the alliance chain.

The transaction data snapshots which are not stored exist in the DAPP node, and the data snapshots which are not stored cannot be uploaded by other borrowing DAPP nodes, the transaction data snapshots are issued to the DAPP nodes at the moment, and the data resources reserved in the DAPP nodes are lost. The records displayed in the federation chain are then: these data resources are left in the original DApp node forever. For the DApp service network, these data resources are lost and the value of continuing the transaction is lost. Of course, this is extremely rare, and typically occurs when two transaction nodes are destroyed at the same time.

15 Under-federation chain DApp service model

The business model of the DApp service network is shown in fig. 25.

16 Deployment location of DApp nodes

Intelligent front-end refers to various intelligent end-machines and edge computing devices, such as: cell-phone, camera, automatic driving vehicle, robot, unmanned aerial vehicle, network equipment, unmanned vending machine, intelligent production line equipment, sharing hardware equipment etc.. The intelligent front end has the technical characteristics that: the system has the basic characteristics of autonomous operation, programmability, remote control, limited computing power, limited memory, one or more networking capabilities, intermittent and indefinite network environment and the like. Also known as an autonomous object, the application uses intelligent front-ends in unison.

The DApp under the federation chain discussed in this application is a software system running on a smart item, a functional node running on computing, logic processing and storage is applied to various end machines and edge computing devices, namely the last two of cloud, edge and end, and federation chain services on which the DApp depends run at the cloud.

17DApp node basic structure

Referring to fig. 26, the federation chain DApp nodes are organized into 5 levels.

1. Operating system layer: and providing basic services for the application system.

2. Network communication layer: TCP/IP network communication and related communication encryption services.

3. Block chain protocol layer: the P2P network service, the public ledger storage service and the related consensus algorithm are provided, and the consensus is achieved among related party nodes.

4. Block chain application layer: and providing an intelligent contract running environment and decentralized application core basic functions.

5. User interface layer: and providing a UI interface for interaction between the DApp and the user, wherein the UI interface can be a native application App, or an interactive page constructed based on a WEB page, or even a non-interface interaction mode which is formed by a CLI command line interface and interacts with the outside.

18 Design of transaction interface for DApp node

DApp provides the implementation of the application specific logic on which the infrastructure is used. In particular, the DApp realizes necessary interfaces by a specific mechanism and provides the interfaces to the DApp application layer, so that the DApp application layer can construct DApp application nodes with thousands of actual functions on the basis of the interfaces.

19 DApp deployment modality

As DApp software running on the intelligent front end, different issuing forms can be provided according to the forms of the equipment, including:

and (3) application market release: for mobile phone devices, it can be released in the application market as standalone DApp software. And providing a corresponding auditing mechanism, an authentication mechanism and a downloading mechanism by the application market. The application market may be a public application market such as: apple AppStore, google's PlayStore, or application markets within the row, such as: and managing the application market of the block chain under the BaaS.

And (3) issuing in an applet form: on a client with an applet mechanism, a DApp support architecture is implemented that allows the DApp to run in the form of an applet on the client with the applet mechanism.

The embedded downloading of the intelligent equipment: the money in the download address of the DApp program is on the intelligent device, the intelligent device can access a specific website through the BIOS built-in setting, and the intelligent device is put into use after downloading the DApp application.

The deployment form of the DApp node is shown in fig. 27.

20 DApp node's requirements for the Intelligent device

The optional characteristics are as follows: the system has the advantages of operational capability (CPU + memory + IO), time-base mechanism, wireless or wired networking capability and GPS positioning.

Optional features: code scanning identification, audio playback, and others, require that the DApp base service be able to identify the capabilities that the device has and provide to the application layer for invocation.

21 Unique identity authentication mechanism

The DApp must have a unique identity authentication mechanism to uniquely identify the associated data processing, transmission, and storage as being handled by a particular DApp node. By using a public-private key mechanism, the DApp signs and encrypts all the operations of the DApp, and the DApp running on the device can definitely and clearly identify the data generated and sent by the device. Regardless of the generation, computation, transmission, storage of data, it may be clear that certain data originates from a particular device or DApp node.

22 Under a federation chain DApp node network topology

FIG. 28 depicts the topological relationship between the DApp node and the federation chain node. It can be seen that the DApp node, together with the federation chain, forms a DApp application service network. Any DApp nodes can be connected and interacted, and the whole alliance chain serves other DApp nodes in the network as a special node.

23 Functional division of labor between DApp nodes and federation chains

A DApp node contains two layers of functionality, one of which is the underlying basic service function. The method provides network communication, identity authentication, connection with a alliance chain, and calling an intelligent contract of the alliance chain to realize the transaction basic function of the digital resource. The application layer is above the basic service function of the DApp bottom layer, and calls the bottom layer function service to realize various specific application logics facing to DApp users. The DApp node mentioned in the text emphasizes how the underlying basic service functions of the DApp are implemented.

In the DApp service network, the federation chain realizes the functions assumed by the DApp node by providing related intelligent contracts for the DApp node to call. Communication between the DApp node and the federation chain is asynchronous. The result of the federation chain's processing of the DApp transaction data is asynchronously returned to the DApp node via a messaging mechanism. The DApp node does not participate in the consensus process of the consensus nodes in the federation chain. The consensus achieved by the DApp node in the transaction process and the consensus between the consensus nodes in the alliance chain are completely two independent processes and have no synchronous relation with each other. The implementation of functions in the DApp application services network may be viewed as a specific blockchain application implemented on the existing architecture of the federation chain.

24 Data processing division between DApp nodes and federation chains

25 inter-DApp node communication mechanism

The DApp nodes may communicate with each other in a variety of ways. The DApp node and the alliance chain background should establish an encryption channel communication mechanism.

The method for uploading the transaction information to the federation chain by the DApp node is an asynchronous mode, namely: during the transaction process between the DApp nodes, interaction with the federation chain is not needed, but after the transaction is finished, if the DApp nodes can establish network connection with the federation chain at the moment, the DApp nodes can quickly upload the transaction data to the federation chain nodes.

The DApp nodes are deployed in the intelligent physical equipment, and each DApp node can be interconnected with the alliance chain in a network communication mode. Any DApp nodes can be connected and interacted, and can be connected in any mode. Such as: the method comprises the following steps that Bluetooth, two-dimension code mutual scanning, NFC near field communication, high-frequency sound waves, character codes and other means are used for interconnection transaction, if one physical device comprises a plurality of DApp nodes, transaction can be conducted among the nodes in an inter-process communication mode. The post-trade DApp node generates opponent data. Transaction data generated by the DApp nodes are uploaded to a federation chain respectively, and all nodes in the federation chain finish the consensus storage of the transaction data of the DApp nodes.

26 DApp Access model to the background

Referring to fig. 29, evolving from App architecture access to DApp architecture, the DApp node may directly connect to a federation chain node, and use the federation chain as a whole as a storage consensus background service.

27 Design for data synchronization between DApp and Federation chain

Referring to fig. 30, each DApp node, after trading, uploads its own data chain to the federation chain. For the same transaction data, the federation chain will accept the same transaction data at least twice. The first time is to receive new transaction data and the second time is to receive counterparty data. When the alliance chain receives the transaction data, the alliance chain registers the transaction data and does not perform data sorting operation. And when the alliance chain receives the data of the transaction opponent, the alliance chain confirms the transaction data and returns a confirmation result to the DApp node in an asynchronous mode.

After receiving the data chain of the DApp node, the alliance chain is responsible for merging and sorting the data and sending a new data block to the data

DApp node to ensure ease of computation.

When data merging is implemented, under the condition of keeping the whole amount of the resource block unchanged, the distributed address is distributed from the unallocated address block, and the distributed address is recycled. The process of transfer and allocation is recorded in the federation chain.

28 DApp node data snapshot implementation

Referring to fig. 31, for the DApp node, a data snapshot is generated after each transaction or after the federation chain marshals the resource block data. The snapshot is similar to a log, and saves the current existing data chain condition (hereinafter referred to as a chain) and transaction data of the transaction as a data packet. After processing the data snapshot of the DApp node, the alliance chain generates a delivered result data packet, wherein the data packet comprises an integration result of the resource blocks in the snapshot and a confirmation result of the transaction data.

When the alliance link verifies the transaction data of the DApp node, the data packet is sent to the DApp node, the DApp replaces the data link inside the node according to the resource block result, after networking, the processing state is returned to the alliance to confirm, the verification result is confirmed, and the DApp node receives the verification result.

Referring to fig. 23, after receiving a certification data packet issued by the federation chain, the dapp node performs snapshot overlay processing on the data packet before the moment, and each time of processing forms a new data snapshot. After 2 times of transaction processes, data snapshots 1 and 2 are formed, after a certificate storage confirmation result issued under the alliance is received, a data snapshot 3 and a data snapshot 4 are generated, next transaction is continued on the basis of the data snapshot 4, and a data snapshot 5 is generated after the third transaction is finished. After the transaction, the network is successfully connected, the certificate storage result 11 and the certificate storage result 12 of the alliance chain are received, a data snapshot result 6 is generated, and the next transaction is carried out on the basis.

29 DApp node data recovery mechanism

If a data snapshot which is not stored exists in a certain DApp node after a plurality of transactions, if the DApp node is damaged and the data in the DApp node is completely lost, two situations exist:

30 Three-party consensus mechanism

In the present application, as shown in fig. 32, the consensus of the transaction between DApp nodes is achieved by three parties. DApp trading nodes and DApp nodes and federation chain nodes. The DApp nodes achieve mutual recognition in the transaction process. And then, after the two nodes are networked, the two nodes upload own transaction data respectively. The transaction data is registered and validated by the federation chain and a new data block is formed to the DApp node. The federation chain represents an issuer of the data resource and a public validation party. Thus, the consensus between the two parties of the transaction and the whole society, namely three-point consensus, is formed.

In the process of forming the three-point consensus system, client downloading of DApp nodes, anonymous registration of the DApp nodes, offline transaction of the DApp nodes, transaction communication independent of a alliance chain among the DApp nodes, and online service of the DApp nodes are needed to realize the transaction data synchronization and data block arrangement work between the DApp nodes and the alliance chain. Through the steps, synchronous consensus is realized as a direct participant of the transaction of the DApp node, and an asynchronous consensus mechanism is realized between the DApp node and the alliance chain, so that multi-party consensus and data synchronization are finally realized. The mechanism of consensus between DApp nodes is shown in fig. 33, and the three-point consensus method is shown in fig. 34.

31 DApp service architecture module composition

As shown in fig. 35, the functional modules that the DApp node needs to implement and the matching functional modules that the federation chain needs to implement are reflected. The core idea is as follows: the data marking and issuing technology and the functions of issuing, transferring, splitting, merging, storing (referred to as 'mark-transfer-split coexistence') and the like of the marked data are adopted, the marked data are ensured to exist in a specific node all the time through the public and private key technology, and a federation chain at the moment is regarded as a node for realizing consensus storage in the whole relative to a DApp node.

From the above description, it can be seen that the system and method for digital asset circulation based on federation chain provided in the application example of the present application specifically include the following effects:

1) Technical effect of DApp implementation under federation chain

1. Any two DApp nodes can be disconnected from the network for interaction and transaction.

2. Digital assets can be transferred between any two DApp nodes.

Dapp node data may be restored to the data that was synchronized at the end of the federation chain.

4. Because the data synchronization process between the DApp node and the federation chain is implemented through an asynchronous process, the DApp node does not cause load pressure on the federation chain.

The dapp node becomes the business logic antenna for federation out-chaining.

6. Provides a technical foundation for constructing a novel accounting system.

2) Application value and effect of DApp

1. The method for applying the block chain to the terminal machine is provided, trusted equipment resources are established, and a cooperation mechanism between the equipment based on the resources is established.

2. A digital resource issuing and circulation mechanism is provided, for example, an off-line payment for an electronic wallet (e.g., an electronic RMB issuing and circulation mechanism) or a resource issuing and circulation mechanism after securities are digitized.

3. And the establishment of a new accounting system is possible.

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

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

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

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The principle and the implementation mode of the invention are explained by applying specific embodiments in the invention, and the description of the embodiments is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

Claims

1. A federation chain-based digital asset transition system, comprising: a plurality of DApp nodes for receipt, storage, and transfer of digital assets corresponding to a federation chain that is an issuer of the digital assets;

each DApp node is provided with a corresponding unique identity, and the running state of the DApp node comprises an offline state in which the network connection with the node in the alliance chain is not established and an online state in which the network connection with the node in the alliance chain is established;

the two DApp nodes in the offline state are used for performing double offline transactions among each other, and the double offline transactions comprise digital asset transactions and digital asset transfer;

2. The federation chain-based digital asset transition system of claim 1, wherein the DApp node is configured to implement an underlying base service and an application layer service on top of the underlying base service;

the underlying base service includes: network communication, identity authentication, intelligent contract connected with the alliance chain to call the alliance chain and transaction service of the digital assets;

the application layer services include: and calling the bottom-layer basic service.

3. The system of claim 1, wherein the federation chain is further configured to perform DApp node registration, register DApp node identity information, certify DApp node transaction data, and store defragmented digital resources.

4. A federation chain-based digital asset transition system as recited in claim 1 wherein said digital asset comprises a plurality of resource block reference units and the basic information for each said resource block reference unit comprises a unique number, issuing authority and corresponding digital asset class.

5. A federation chain-based digital asset transfer system as claimed in claim 4, wherein a plurality of consecutively numbered resource block reference units constitute a resource block and the attribute of each said resource block comprises: head number, tail number, capacity, issuing authority, and digital asset class of issue.

6. A federation chain-based digital asset transfer system as claimed in claim 5 wherein the chain made up of a plurality of sequentially linked resource blocks is a resource chain;

and the resource chain is stored in the DApp node in a form of a data table, wherein the data table comprises a current resource block number, a resource block head address, a resource block length, a resource block tail address and a next resource block address.

7. The system of claim 1, wherein the DApp node is a software system running on a smart terminal, and the federation chain runs on a cloud software platform.

8. A alliance chain based digital asset transfer method, wherein the alliance chain based digital asset transfer method is implemented by applying the alliance chain based digital asset transfer system of any one of claims 1 to 7;

after the operation state of any one of the two DApp nodes for performing the double offline transaction is changed into the online state, the DApp node in the online state asynchronously sends transaction information corresponding to the double offline transaction to the evidence storage node in the evidence storage of the federation chain, and three-party consensus is achieved between the two DApp nodes for performing the double offline transaction and the federation chain.

9. The method of claim 8, wherein the online DApp node asynchronously sends transaction information corresponding to the dual offline transactions to a credentialing node in credentialing of the federation chain, and the method includes:

aiming at two DApp nodes corresponding to the same double offline transaction, the alliance link receives transaction information corresponding to the double offline transaction sent by one DApp node and registers the transaction information;

and receiving the transaction information corresponding to the double offline transactions sent by the other DApp node corresponding to the same double offline transactions, confirming the transaction information, and returning the corresponding confirmation result to the other DApp node.

10. A federation chain-based digital asset transition method as recited in claim 9, further comprising:

and after each transaction or after receiving the confirmation result sent by the alliance chain, the DApp node stores the current condition of the existing data chain and the transaction data corresponding to the current transaction or the current confirmation result sent by the alliance chain into a data packet.