WO2023116028A1 - Cross-domain access method on blockchain and server - Google Patents

Abstract

The present application discloses a cross-domain access method on a blockchain and a server. The method is applied to a global server on the blockchain and comprises: receiving a resource access request sent by a first server in a first domain on the blockchain, the resource access request representing that a first node requests to access a first resource in a second node, the first node being in the first domain and the second node being not in the first domain; in a record list of the global server, obtaining record information corresponding to the resource access request; transmitting, according to the record information, the resource access request to a second server in a second domain where the second node is located; receiving authorization information corresponding to the resource access request transmitted by the second server; and transmitting the authorization information to the first node, the authorization information being used for indicating the first node to access the first resource.

Description

Cross-domain access method and server on block chain

This application claims the priority of the Chinese patent application with the application number CN202111575402.0 and the title of the invention "Cross-domain access method and server on the block chain" submitted to the China Patent Office on December 21, 2021, the entire content of which is passed References are incorporated in this application.

technical field

The present application relates to the technical field of block chain, and in particular to a cross-domain access method and server on the block chain.

Background technique

The blockchain can be divided into a public chain and a permissioned chain, and the permissioned chain can be divided into a consortium chain and a private chain according to whether the data maintainer is a single entity. .

On the permissioned chain, resource access between nodes can be realized in the same consortium chain, but nodes in different consortium chains do not trust each other, resulting in inability to access resources.

Contents of the invention

In view of this, this application provides a cross-domain access method and server on the blockchain, as follows:

A cross-domain access method on the blockchain, applied to a global server on the blockchain, the method comprising:

Receiving a resource access request sent by a first server in the first domain on the blockchain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain, the second node is not in the first domain;

In the record list of the global server, obtain record information corresponding to the resource access request;

transmitting the resource access request to a second server in the second domain where the second node is located according to the record information;

receiving authorization information corresponding to the resource access request transmitted by the second server;

transmitting the authorization information to the first node, where the authorization information is used to instruct the first node to access the first resource.

In the above method, preferably, the record information corresponding to the resource access request is recorded in the record list in the following manner:

receiving a resource authorization request sent by the second node through the second server, the resource authorization request indicating that the second node authorizes the first node to access the first resource with authorization information;

Add record information corresponding to the resource authorization request to the record list, where the record information corresponding to the resource authorization request at least indicates that the first node is authorized to access the first resource in the second node.

In the above method, preferably, the record information corresponding to the resource access request further represents the target access type of the first node accessing the first resource;

Wherein, the target access type is recorded in the record list in the following manner:

receiving an authorization setting request sent by the second node through the second server, the authorization setting request indicating that the second node authorizes the first node to access the first resource with a target access type;

The record information corresponding to the authorization setting request is added to the record list, and the record information corresponding to the authorization setting request not only indicates that the first node is authorized to access the first resource in the second node, but also indicates that the The first node is authorized to access the first resource with the target access type.

The above method, preferably, also includes:

receiving an authorization revocation request sent by the second node through the second server, the authorization revocation request indicating that the second node does not allow the first node to access the first resource;

Add record information corresponding to the authorization revocation request to the record list, where the record information corresponding to the authorization revocation request indicates that the first node is prohibited from accessing the first resource in the second node.

In the above method, preferably, obtaining the record information corresponding to the resource access request in the record list of the global server includes:

Comparing the global node identifier of the first node, the global node identifier of the second node, and the resource identifier in the resource access request with the record information in the record list to obtain information related to the resource access request Matching record information.

In the above method, preferably, the global server registers the global node identifier for the first node in the following manner:

receiving the node registration request sent by the first node through the coordinating server in the block chain; the node registration request at least includes the local node identifier of the first node in the first domain;

generating a global node identifier for the first node according to the local node identifier of the first node in the node registration request;

Returning the global node identifier of the first node to the first node through the coordinating server.

In the above method, preferably, transmitting the authorization information to the first node includes:

When the link layer between the global server and the first node is connected, send the authorization information to the first node through the link layer;

When the link layer between the global server and the first node is not connected, the authorization information is at least sent to the first node through the first server.

A cross-domain access method on a block chain, applied to a first server in a first domain on the block chain, the method comprising:

receiving a resource access request sent by a coordinating server in the blockchain, the resource access request representing that the first node requests to access the first resource in the second node, and the first node is in the first domain;

determining that the second node is in a second domain;

sending the resource access request to the global server on the block chain;

receiving authorization information sent by the global server;

sending the authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource.

A cross-domain access device on the block chain, applied to the global server on the block chain, the device includes:

A request receiving unit, configured to receive a resource access request sent by a first server in the first domain on the blockchain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first the node is in the first domain and the second node is not in the first domain;

a record obtaining unit, configured to obtain record information corresponding to the resource access request in the record list of the global server;

a request transmission unit, configured to transmit the resource access request to a second server in the second domain where the second node is located according to the record information;

an authorization receiving unit, configured to receive authorization information corresponding to the resource access request transmitted by the second server;

An authorization transmission unit, configured to transmit the authorization information to the first node, where the authorization information is used to instruct the first node to access the first resource.

A cross-domain access device on the block chain, applied to the first server in the first domain on the block chain, the device includes:

A request receiving unit, configured to receive a resource access request sent by a coordinating server in the block chain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain;

a node determining unit, configured to determine that the second node is in the second domain;

a request sending unit, configured to send the resource access request to the global server on the block chain;

an authorization receiving unit, configured to receive authorization information sent by the global server;

An authorization sending unit, configured to send the authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource.

A server, as a global server on the blockchain, including:

memory for storing computer programs and data generated by running the computer programs;

A processor, configured to execute the computer program, so as to: receive a resource access request sent by a first server in the first domain on the block chain, the resource access request indicates that the first node requests to access the resource in the second node For the first resource, the first node is in the first domain, and the second node is not in the first domain; in the record list of the global server, record information corresponding to the resource access request is obtained; According to the record information, transmit the resource access request to a second server in the second domain where the second node is located; receive authorization information corresponding to the resource access request transmitted by the second server; transmit the resource access request; Authorization information is transmitted to the first node, where the authorization information is used to instruct the first node to access the first resource.

A server, as the first server in the first domain on the blockchain, comprising:

memory for storing computer programs and data generated by running the computer programs;

a processor, configured to execute the computer program, so as to: receive a resource access request sent by a coordinating server in the blockchain, where the resource access request indicates that the first node requests to access the first resource in the second node, The first node is in the first domain; determine that the second node is in the second domain; send the resource access request to the global server on the block chain; receive authorization information sent by the global server ; Send the authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource.

It can be seen from the above technical solution that in the cross-domain access method and server on the blockchain disclosed in this application, nodes in each domain on the blockchain generate authorization information for nodes in other domains, and The corresponding authorized access relationship is recorded on the global server set on the blockchain, and then when the blockchain node in the current domain needs to access the resources in the blockchain node in the other domain, the global server can search for the corresponding record information. To instruct the server in the opposite domain to return the authorization information, and then return the authorization information to the blockchain node in the current domain, the blockchain node in the current domain can access the resources in the blockchain node in the opposite domain, thus realizing Access across domains.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. Those of ordinary skill in the art can also obtain other drawings based on these drawings without making creative efforts.

FIG. 1 is a flow chart of a cross-domain access method on a blockchain provided in Embodiment 1 of the present application;

Figure 2 is an example diagram of realizing cross-domain access on the blockchain;

Figures 3-7 are partial flowcharts of a cross-domain access method on a blockchain provided in Embodiment 1 of the present application;

FIG. 8 is a flow chart of a cross-domain access method on a blockchain provided in Embodiment 2 of the present application;

FIG. 9 is a schematic structural diagram of a server provided in Embodiment 3 of the present application;

FIG. 10 is a schematic structural diagram of a server provided in Embodiment 4 of the present application;

FIG. 11 is a schematic diagram of deployment in a domain that implements cross-domain access in this application;

FIG. 12 is an overall architecture diagram for realizing cross-domain access in this application;

FIG. 13 is a schematic diagram of the interaction of registering a global domain identifier for a domain in this application;

FIG. 14 is an interactive schematic diagram of registering a global node identifier for a node user in this application;

Fig. 15 is a flow chart of issuing delegation policies between node users in this application;

Fig. 16 and Fig. 17 are respectively schematic diagrams of cross-domain access between blockchain nodes in this application.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the application with reference to the drawings in the embodiments of the application. Apparently, the described embodiments are only some of the embodiments of the application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

Referring to Figure 1, it is a flow chart of the implementation of a cross-domain access method on the blockchain provided by Embodiment 1 of the present application. This method can be applied to the global server on the blockchain, and the nodes on the blockchain are Divided into multiple domains, each domain can be regarded as a consortium chain. Nodes in the same domain trust each other based on the same root of trust, and nodes in different domains do not trust each other. Based on this, this application is based on blockchain Set up a global server, such as the global smart contract server shown in Figure 2. Therefore, in the technical solution of this application, the global server establishes a trust relationship between nodes in different domains to achieve cross-domain access.

Specifically, the method in this embodiment may include the following steps:

Step 101: Receive a resource access request sent by a first server in a first domain on the blockchain.

Wherein, the resource access request indicates that the first node requests to access the first resource in the second node, the first node is in the first domain, and the second node is not in the first domain, that is, the second node is in a different domain from the first node , the domain where the second node is located is recorded as the second domain, that is, the resource access request is a global access request, that is, entities in different domains request to access resources.

Specifically, the resource access request includes at least the resource identifier of the first resource and the global node identifier of the second node where the first resource is located, and of course, may also include the global node identifier of the first node. The resource identifier of the first resource may be an address identifier or a name identifier of the first resource. The global node identifier of the second node indicates that the second node is in the second domain and uniquely indicates the second node in the second domain. The global node identifier of the first node indicates that the first node is in the first domain and uniquely indicates the first node in the first domain.

It should be noted that the first server in the first domain can be a local smart contract server in the first domain, that is, the first consortium chain, and the first server receives the resource access request sent by the first node through the cross-domain coordination server. Specifically, after the first node generates a resource access request, it sends it to the cross-domain coordination server on the blockchain through addressing, and the cross-domain coordination server generates a corresponding cross-domain transaction for the resource access request, and the cross-domain transaction form The resource access request is sent to the first server in the first domain, and the first server sends the resource access request to the global server on the blockchain.

Step 102: Obtain the record information corresponding to the resource access request in the record list of the global server.

Specifically, the global server may search for record information matching the resource access request in the record list, for example: combine the global node ID of the first node, the global node ID of the second node, and the resource ID in the resource access request with the record The record information in the list is compared to obtain the record information matching the resource access request, and the record information indicates that the second node authorizes the first node to access the first resource in the second node.

It should be noted that the local authorization list in each domain contains authorization information generated by nodes in this domain for nodes in this domain and other domains, such as the resource identifier of the resource authorized to access, and the public key information required for authorized access As well as information such as the type of access authorized to access, the authorization information generated by a node for nodes in its own domain can be called a local delegation policy, and the authorization information generated by a node for nodes in other domains can be called a global delegation policy. In the record list of the global server, the authorized access relationship in which nodes in each domain generate authorization information for nodes in other domains is recorded, which can be called a global delegation policy. In order to ensure security, only the authorization status is recorded in the record list, but the authorization information is not recorded. For example, the authorization status of the second node authorizing the first node to access the first resource is recorded but the public key information generated by the second node for the first node is not recorded. .

Among them, the local authorization list in each domain is stored on the blockchain, and the record list of the global server is stored on the blockchain.

Step 103: According to the record information, transmit the resource access request to the second server in the second domain where the second node is located.

In one implementation, in this embodiment, resource access requests can be broadcast to servers in domains other than the first domain on the blockchain according to the found record information, and servers in each domain can receive resource access requests. Access request, only the second server in the second domain where the second node is located finds that the global node ID of the node in the current domain matches the global node ID contained in the resource access request. At this time, the second server in the second domain can Find the corresponding authorization information in the local authorization list according to the resource access request. The local authorization list here contains the authorization information for each node in the second domain to provide resource access for other nodes (including nodes in the current domain and nodes in other domains). , based on this, the second server in the second domain returns the found authorization information to the global server after searching the local authorization list for authorization information that matches the content in the resource access request.

In another implementation manner, in this embodiment, according to the global node identifier of the second node in the found record information, the record information may be unicast to the second server in the second domain where the second node is located, for example, The addressing method can be used to transmit the record information to the second server in the second domain where the second node is located according to the path between domains, so that the second server in the second domain finds the resource in the local authorization list. The content in the access request matches the authorization information, and then returns the found authorization information to the global server.

Wherein, the second server may be a local smart contract server in the second domain, such as a local smart contract server in domain 2 as shown in FIG. 2 .

Step 104: Receive authorization information corresponding to the resource access request transmitted by the second server.

Wherein, if the second server does not find the authorization information corresponding to the resource access request in the local authorization list, then the global server may receive the access prohibition message returned by the second server, and at this time, the global server returns the access prohibition message to to the first node.

Step 105: Transmit the authorization information to the first node.

Wherein, the authorization information is used to instruct the first node to access the first resource. For example, the authorization information is the public key information generated by the second node for the first node to access the first resource. Therefore, after receiving the authorization information, the first node can use the authorization information to access the first resource, such as using The public key information decrypts data encrypted by the second node using the corresponding private key.

In an implementation manner, the global server may directly send the authorization information to the first node through the connected link layer when the link layer between the global server and the first node is connected;

In another implementation, the global server may at least send the authorization information to the first node through the first server when the link layer between the global server and the first node is not connected, for example, first send the authorization The information is sent to the first server in the first domain, and then the first server in the first domain sends the authorization information to the cross-domain coordination server, so that the cross-domain coordination server sends the authorization information to the first node.

It should be noted that before the global server directly sends the authorization information to the first node or before the global server sends the authorization information to the first server, it first sends a wake-up command to the first node to wake up the first node, and then Authorization information is transmitted to the first node.

It can be seen from the above technical solution that in the cross-domain access method on the blockchain provided by Embodiment 1 of the present application, nodes in each domain on the blockchain generate authorization information for nodes in other domains, and in The corresponding authorized access relationship is recorded on the global server set on the blockchain, and then when the blockchain node in the current domain needs to access the resources in the blockchain node in the other domain, the global server can search for the corresponding record information , to instruct the server in the opposite domain to return the authorization information, and then return the authorization information to the blockchain node in the current domain, the blockchain node in the current domain can access the resources in the blockchain node in the opposite domain, thus Realize cross-domain access.

In one implementation, taking the record information corresponding to the resource access request as an example, the following is the implementation process of recording the record information corresponding to the resource access request in the record list corresponding to the global server, as shown in FIG. 3 :

Step 301: Receive a resource authorization request sent by the second node through the second server.

Wherein, the resource authorization request indicates that the second node authorizes the first node to access the first resource with authorization information.

Specifically, the resource authorization request may include the global node identifier of the second node, the global node identifier of the first node, the resource identifier of the first resource, and authorization information. The authorization information may be that the second node can access Public key information generated by the first resource.

It should be noted that after the second node generates the resource authorization request, it can first send it to the cross-domain coordination server on the blockchain. The cross-domain coordination server generates a corresponding cross-domain transaction for the resource authorization request, and the cross-domain transaction form The resource authorization request is sent to the second server in the second domain where the second node is located. When the second server determines that the first node and the second node are in different domains, the second server records the authorization information in the resource authorization request At the same time as the local authorization list, resource authorization requests are sent to the global server.

Wherein, if the second server determines that the first node and the second node are in the same domain, then the second server only needs to record the authorization information in the resource authorization request in the local authorization list.

Specifically, the second server may compare the global node ID of the first node with all node IDs in the second domain, and if the node ID of a node in the second domain matches the global node ID of the first node, then the Determine that the first node is in the second domain; if there is no node ID in the second domain that matches the global node ID of the first node, it can be determined that the first node is not in the same domain as the second node, that is, the first node is in first domain.

Step 302: Add record information corresponding to the resource authorization request in the record list.

Wherein, the record information corresponding to the resource authorization request at least indicates that the first node is authorized to access the first resource in the second node.

Specifically, the record information corresponding to the resource authorization request includes the global node identifier of the second node, the global node identifier of the first node, and the resource identifier of the first resource, so as to indicate that the first node is authorized to access the resource identifier of the second node. a resource. Based on this, the global server can find corresponding record information in the record list according to the global node identifier and resource identifier contained in the resource access request.

Further, the record information corresponding to the resource access request also represents the target access type of the first node's access to the first resource. Based on this, taking the record information corresponding to the resource access request as an example, as shown in FIG. 4, after step 302, the following implementation steps of recording the target access type in the record list corresponding to the global server may be included:

Step 303: Receive an authorization setting request sent by the second node through the second server.

Wherein, the authorization setting request indicates that the second node authorizes the first node to access the first resource with the target access type. The target access type here may be read-only, write-only, or both readable and writable.

Specifically, the authorization setting request may include the global node identifier of the second node, the global node identifier of the first node, the resource identifier of the first resource, and the target access type.

It should be noted that after the second node generates the authorization setting request, it can first send it to the cross-domain coordination server on the blockchain. The cross-domain coordination server generates a corresponding cross-domain transaction for the authorization setting request, and the The authorization setting request is sent to the second server in the second domain where the second node is located. When the second server judges that the first node and the second node are in different domains, the second server sends the target access type in the authorization setting request to While recording in the local authorization list, an authorization setting request is sent to the global server.

Step 304: Add record information corresponding to the authorization setting request in the record list.

Wherein, the record information corresponding to the authorization setting request not only indicates that the first node is authorized to access the first resource in the second node, but also indicates that the first node is authorized to access the first resource in the target access type.

Specifically, the record information corresponding to the authorization setting request includes the global node ID of the second node, the global node ID of the first node, the resource ID of the first resource, and the target access type, so as to indicate that the first node is authorized to access type accesses the first resource in the second node. Based on this, the global server can find the corresponding record information in the record list according to the global node identifier and resource identifier contained in the resource access request, so as to determine that the first node is authorized by the second node to access the first resource and the Target access type.

Based on the above implementation, the global server can not only record the authorization access relationship of nodes in each domain to generate authorization information for nodes in other domains in the record list, but also record the authorization of nodes in each domain to revoke authorization information for nodes in other domains Access relationship, specifically, after step 302 or after step 304, the following implementation steps may also be included on the global server, as shown in Figure 5:

Step 305: Receive an authorization revocation request sent by the second node through the second server.

Wherein, the authorization revocation request indicates that the second node does not allow the first node to access the first resource.

Specifically, the authorization revocation request may include the global node identifier of the second node, the global node identifier of the first node, the resource identifier of the first resource, and prohibition information, and the prohibition information may be represented by specific symbols.

It should be noted that after the second node generates the authorization revocation request, it can first send it to the cross-domain coordination server on the blockchain. The cross-domain coordination server generates a corresponding cross-domain transaction for the authorization revocation request, and the The authorization revocation request is sent to the second server in the second domain where the second node is located. When the second server determines that the first node and the second node are in different domains, the second server records the record information corresponding to the authorization revocation request. At the same time as the local authorization list, resource authorization requests are sent to the global server. Based on this, the second server can find the corresponding record information in the local authorization list according to the global node ID and resource ID contained in the resource access request, which can include authorization information, target access type and prohibition information, so as to determine the first The second node authorizes the first node to access the first resource with the target access type by using the authorization information, and then revokes the authorization to the first node again, that is, the second node prohibits the first node from accessing the first resource.

Step 306: Add record information corresponding to the authorization revocation request in the record list.

Wherein, the record information corresponding to the authorization revocation request indicates that the first node is prohibited from accessing the first resource in the second node.

Specifically, the record information corresponding to the authorization revocation request includes the global node identifier of the second node, the global node identifier of the first node, the resource identifier of the first resource, and prohibition information, so as to indicate that the second node revokes access to the first node. Authorization of the first resource. Based on this, the global server can find the corresponding record information in the record list according to the global node identifier and resource identifier contained in the resource access request, so as to determine that the first node is authorized by the second node to access the first resource and the After the target access type, the first node is revoked by the second node to access the first resource.

In one implementation, the global node ID of each node in each domain can be registered and recorded on the global server, taking the global node ID of the first node as an example, registering the global node ID for the first node on the global server The implementation steps are shown in Figure 6:

Step 601: Receive a node registration request sent by the first node through the cross-domain coordination server in the blockchain.

Wherein, the node registration request includes at least the local node identifier of the first node in the first domain, the local node identifier of the first node is used to uniquely represent the first node in the first domain, and the local node identifier of the first node is used as the second The identity of a node is recognized by other nodes in the first domain in the first domain, but in other domains, nodes in other domains cannot recognize the local node ID of the first node.

It should be noted that after the first node generates a node registration request, it can first send it to the cross-domain coordination server on the blockchain. The cross-domain coordination server generates a corresponding cross-domain transaction for the node registration request, and the cross-domain transaction form The node registration request is sent to the first server in the first domain where the first node is located, and the first server sends the node registration request to the global server.

Step 602: Generate a global node identifier for the first node according to the local node identifier of the first node in the node registration request.

Wherein, based on the local node identification of the first node, the global server generates for the first node a global node identification that can uniquely represent the first node among nodes in all domains on the blockchain, and the global node identification of the first node is in the block The global node identifiers of each node in each domain on the chain are unique.

Step 603: Return the global node identifier of the first node to the first node through the cross-domain coordination server.

Specifically, the global server may first send the global node ID of the first node to the first server in the first domain, and then the first server sends the global node ID of the first node to the cross-domain coordination server, and the cross-domain coordination server passes After the wake-up instruction wakes up the first node, the global node identifier of the first node is sent to the first node.

Similarly, both the global node ID of the second node and the global node ID of any node in any other domain can be registered on the global server through the above method.

The above is how the global server registers the global node ID for the nodes in each domain. The implementation of registering the global domain ID for each domain is similar. Take the global server as an example to register the global domain ID for the first domain. The specific implementation steps are shown in the figure Shown in 7:

Step 701: Receive a domain registration request sent by the management server in the first domain through the cross-domain coordination server in the blockchain.

Wherein, the domain registration request includes at least the local domain identifier of the first domain, and the local domain identifier of the first domain is used to represent the first domain, but in other domains, the local domain identifier of the first domain cannot be identified.

It should be noted that after the management server in the first domain generates a domain registration request, it can first send it to the cross-domain coordination server on the blockchain, and the cross-domain coordination server generates a corresponding cross-domain transaction for the domain registration request, and the cross-domain The domain registration request in the form of a domain transaction is sent to the first server in the first domain, and the first server sends the domain registration request to the global server.

Step 702: Generate a global domain identifier for the first domain according to the local domain identifier of the first domain in the domain registration request.

Wherein, the global server generates a global domain identifier for the first domain that can uniquely represent the first domain among all domains on the blockchain based on the local domain identifier of the first domain, and the global domain identifier of the first domain is stored on the blockchain Unique within the global domain ID of each domain.

Step 703: Return the global domain identifier of the first domain to the management server in the first domain through the cross-domain coordination server.

Specifically, the global server may first send the global domain identifier of the first domain to the first server in the first domain, and then the first server sends the global domain identifier of the first domain to the cross-domain coordination server, and the cross-domain coordination server passes After the wake-up instruction wakes up the management server in the first domain, the global domain identifier of the first domain is sent to the management server of the first domain.

Similarly, both the global domain ID of the second domain and the global domain ID of any other domain can be registered on the global server through the above methods.

Referring to FIG. 8 , it is a flowchart of an implementation of a cross-domain access method on a blockchain provided by Embodiment 2 of the present application. This method can be applied to the first server in the first domain on the blockchain, as shown in FIG. 2 The local smart contract server in Domain 1 is shown. In the technical solution of the present application, a global server is used to establish a trust relationship between nodes in different domains, so as to realize cross-domain access.

Specifically, the method in this embodiment may include the following steps:

Step 801: Receive the resource access request sent by the coordinating server in the blockchain.

Wherein, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain.

Specifically, the resource access request includes at least the resource identifier of the first resource and the global node identifier of the second node where the first resource is located, and of course, may also include the global node identifier of the first node.

It should be noted that after the first node generates a resource access request, it sends it to the cross-domain coordination server on the blockchain by addressing, and the cross-domain coordination server generates a corresponding cross-domain transaction for the resource access request, and the cross-domain A resource access request in the form of a transaction is sent to the first server in the first domain.

Step 802: Determine that the second node is in the second domain.

Specifically, the first server may compare the global node ID of the second node in the resource access request with the node IDs of all nodes in the first domain, and if there is a node ID in the first domain that matches the global node ID of the second node If the node ID matches, it can be determined that the second node is in the first domain; if there is no node ID in the first domain that matches the global node ID of the second node, then it can be determined that the second node is not in the same domain as the first node. domain, that is, the second node is in the second domain.

Wherein, if the second node is in the first domain, as shown in Figure 9, the first server can query the corresponding authorization information in the local authorization list according to the content in the resource access request, and pass the found authorization information through the cross-domain The coordinating server sends it to the first node, so that the first node uses the authorization information to access the first resource in the second node.

However, if the second node is in the second domain, the following process is performed.

Step 803: Send the resource access request to the global server on the blockchain.

Wherein, the global server can obtain the record information corresponding to the resource access request in its record list, for example, in the resource access request, the global node ID of the first node, the global node ID of the second node, and the resource ID in the record list The record information is compared to obtain the record information that matches the resource access request, and the record information indicates that the second node authorizes the first node to access the first resource in the second node. If the global server finds the record information corresponding to the resource access request in the record list and there is no prohibition information set by the second node in the record information, it can be determined that the second node authorizes the first node to access the first resource. If the record information corresponding to the resource access request is not found in the record list or the record information corresponding to the resource access request contains prohibition information set by the second node, it can be determined that the second node does not authorize the first node to access the first resource.

Based on this, if it is determined that the second node authorizes the first node to access the first resource, then the global server can send the resource access request to the second server in the second domain where the second node is located, and the second server in the second domain will locally Find the authorization information that matches the content in the resource access request in the authorization list, and then return the found authorization information to the global server, and the global server will return the authorization information to the first server, or the global server will directly send the authorization information to Return to the first node.

Certainly, if it is determined that the second node does not authorize the first node to access the first resource, then the global server may return an access prohibition message to the first server, and the first server transmits the access prohibition message to the first node through the cross-domain coordination server , or, the global server can directly return an access prohibition message to the first node when the link layer between the global server and the first node is connected; if the second server does not find the resource access request in the local authorization list If the contents of the authorization information all match, the second server returns a message of prohibiting access to the global server, and the global server returns a message of prohibiting access to the first server, and the first server transmits the message of prohibiting access to the first node through the cross-domain coordination server. Alternatively, the global server may directly return an access prohibition message to the first node when the link layer between the global server and the first node is connected.

It should be noted that, before the global server sends the authorization information or the access prohibition message, it first transmits a wake-up instruction to the first node, so as to wake up the first node.

Step 804: Receive authorization information sent by the global server.

Step 805: Send the authorization information to the first node through the coordinating server.

Wherein, the authorization information is used to instruct the first node to access the first resource.

It can be seen from the above technical solution that in the cross-domain access method on the blockchain provided by Embodiment 2 of the present application, nodes in each domain on the blockchain generate authorization information for nodes in other domains, and in The corresponding authorized access relationship is recorded on the global server set on the blockchain, and then when the blockchain node in the current domain needs to access the resources in the blockchain node in the other domain, the resources can be uploaded to the server in the current domain. The access request is forwarded to the global server, and then the global server searches for the corresponding record information to instruct the server in the other domain to return the authorization information, and then returns the authorization information to the blockchain node of the current domain, the blockchain in the current domain Nodes can access resources in blockchain nodes in the other party's domain, thereby achieving cross-domain access.

It should be noted that for other implementations of the first server in the first domain, reference may be made to the implementation of the functions of the second server in the second domain above, which will not be described in detail here.

Referring to FIG. 9 , it is a schematic structural diagram of a server provided in Embodiment 3 of the present application, and the server serves as a global server on the blockchain. For example, a global smart contract server as shown in Figure 2. In the technical solution of the present application, a global server is used to establish a trust relationship between nodes in different domains, so as to realize cross-domain access.

Specifically, the global server in this embodiment may include the following structure:

The memory 901 is used to store computer programs and data generated by running the computer programs;

The processor 902 is configured to execute a computer program to realize: receiving a resource access request sent by a first server in the first domain on the blockchain, where the resource access request represents that the first node requests to access the first resource in the second node, and the second One node is in the first domain, and the second node is not in the first domain; in the record list of the global server, the record information corresponding to the resource access request is obtained; according to the record information, the resource access request is transmitted to the second node where the second node is located. The second server in the domain; receiving authorization information corresponding to the resource access request transmitted by the second server; transmitting the authorization information to the first node, where the authorization information is used to instruct the first node to access the first resource.

In addition, the global server in this embodiment may also include structures such as a communication module to realize interaction with the first server and the second server. For example, the processor 902 receives the resource access request sent by the first server in the first domain on the blockchain by triggering the communication module, transmits the resource access request to the second server in the second domain where the second node is located, and receives the resource access request from the second server. Transmitting authorization information corresponding to the resource access request, transmitting the authorization information to the first node, and so on.

It can be seen from the above technical solution that in the server provided by Embodiment 3 of the present application, the nodes in each domain on the blockchain generate authorization information for nodes in other domains, and the global server set on the blockchain Record the corresponding authorized access relationship on the network, and then when the blockchain node in the current domain needs to access the resources in the blockchain node in the other domain, the global server can look up the corresponding record information to instruct the server in the other domain to return After the authorization information is returned to the blockchain node in the current domain, the blockchain node in the current domain can access the resources in the blockchain node in the other domain, thus realizing cross-domain access.

In an implementation manner, the record information corresponding to the resource access request is recorded in the record list by the processor 902 . The processor 902 is specifically configured to: receive a resource authorization request sent by the second node through the second server, the resource authorization request indicates that the second node authorizes the first node to access the first resource with authorization information; add the resource authorization request corresponding to the resource authorization request in the record list Record information, the record information corresponding to the resource authorization request at least indicates that the first node is authorized to access the first resource in the second node.

In an implementation manner, the record information corresponding to the resource access request further represents a target access type of the first node's access to the first resource; wherein, the target access type is recorded in the record list by the processor 902 . The processor 902 is specifically configured to: receive an authorization setting request sent by the second node through the second server, the authorization setting request indicates that the second node authorizes the first node to access the first resource with the target access type; add the authorization setting request corresponding to the record list The record information corresponding to the authorization setting request not only indicates that the first node is authorized to access the first resource in the second node, but also indicates that the first node is authorized to access the first resource in the target access type.

In one implementation, the processor 902 is further configured to: receive an authorization revocation request sent by the second node through the second server, where the authorization revocation request indicates that the second node does not allow the first node to access the first resource; add Record information corresponding to the authorization revocation request, wherein the record information corresponding to the authorization revocation request indicates that the first node is prohibited from accessing the first resource in the second node.

In an implementation manner, when the processor 902 obtains the record information corresponding to the resource access request in the record list of the global server, it is specifically configured to: use the global node identifier of the first node in the resource access request, the The global node ID and the resource ID are compared with the record information in the record list to obtain the record information matching the resource access request.

In one implementation, the processor 902 registers the global node identifier for the first node in the following manner: receiving the node registration request sent by the first node through the coordinating server in the blockchain; the node registration request includes at least local node ID in the first domain; generate a global node ID for the first node according to the local node ID of the first node in the node registration request; return the global node ID of the first node to the first node through the coordinating server.

In an implementation manner, when the processor 902 transmits the authorization information to the first node, it is specifically configured to: when the link layer between the global server and the first node is connected, transmit the authorization information through the link The authorization information is sent to the first node at least through the first server when the link layer between the global server and the first node is not connected.

It should be noted that, for the specific implementation of the processor in this embodiment, reference may be made to the corresponding contents above, and details are not described here again.

Correspondingly, the embodiment of the present application also provides a cross-domain access device on the blockchain, which is applied to the global server on the blockchain, and the device includes:

The request receiving unit is configured to receive the resource access request sent by the first server in the first domain on the block chain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain, the second node is not in the first domain;

a record obtaining unit, configured to obtain record information corresponding to the resource access request in the record list of the global server;

a request transmission unit, configured to transmit the resource access request to a second server in the second domain where the second node is located according to the record information;

An authorization receiving unit, configured to receive authorization information corresponding to the resource access request transmitted by the second server;

An authorization transmission unit, configured to transmit authorization information to the first node, where the authorization information is used to instruct the first node to access the first resource.

Referring to FIG. 10 , it is a schematic structural diagram of a server provided in Embodiment 4 of the present application. The server serves as the first server in the first domain on the blockchain. For example, a local smart contract server in Domain 1 as shown in Figure 2. In the technical solution of the present application, a global server is used to establish a trust relationship between nodes in different domains, so as to realize cross-domain access.

Specifically, the first server in this embodiment may include the following structure:

Memory 1001, used to store computer programs and data generated by running computer programs;

The processor 1002 is configured to execute a computer program to realize: receiving a resource access request sent by a coordinating server in the block chain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first node One domain; determine that the second node is in the second domain; send the resource access request to the global server on the block chain; receive the authorization information sent by the global server; send the authorization information to the first node through the coordination server, and the authorization information is used for The first node is instructed to access the first resource.

In addition, the global server in this embodiment may also include structures such as a communication module to realize interaction with the first server and the second server. For example, the processor 1002 receives the resource access request sent by the coordination server in the blockchain by triggering the communication module, sends the resource access request to the global server on the blockchain, receives the authorization information sent by the global server, and sends the authorization information through the coordination server. The server sends to the first node, and so on.

It can be seen from the above technical solution that in the server provided in Embodiment 4 of the present application, the nodes in each domain on the blockchain generate authorization information for nodes in other domains, and the global server set on the blockchain Record the corresponding authorized access relationship on the network, and then when the blockchain node in the current domain needs to access the resources in the blockchain node in the other domain, the resource access request can be forwarded to the global server on the server in the current domain, Then, the global server searches for the corresponding record information to instruct the server in the other domain to return the authorization information, and then returns the authorization information to the blockchain node in the current domain, and the blockchain node in the current domain can access the zone in the other domain. Resources in the block chain nodes, thus achieving cross-domain access.

Correspondingly, the embodiment of the present application also provides a cross-domain access device on the blockchain, which is applied to the first server in the first domain on the blockchain, and the device includes:

The request receiving unit is configured to receive a resource access request sent by the coordinating server in the blockchain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain;

a node determining unit, configured to determine that the second node is in the second domain;

The request sending unit is used to send the resource access request to the global server on the block chain;

An authorization receiving unit, configured to receive authorization information sent by the global server;

An authorization sending unit, configured to send authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource.

Take the cross-domain access between the first domain and the second domain, such as the blockchain nodes of domain 1 and domain 2, as an example. As shown in Figure 11, each domain contains the basic modules that run the fabric, which can be Realize complete smart contract calls, including at least electronic certification service CA (Certificate Authority), sorting server ordering service, peer node peer node, membership server (Membership service), etc. On this basis, the global smart contract server Global smart contract (referred to as the global smart contract), the local smart contract server Local smart contract (referred to as the local smart contract) and the cross-domain coordination server Cross Domain Coordinator (also known as the cross domain coordinator) are added to the blockchain. domain coordinator) to complete cross-domain access.

The overall architecture is shown in Figure 12. The underlying network Underlay and the overlay network Overlay are constructed on the blockchain. In the Overlay network, all blockchain nodes on the blockchain form the Global Blockchain, which is the Overlay The peer-to-peer network on the Internet is the Global hyperledger fabric network, while in the Underlay network, each consortium chain forms a local chain Local Blockchain, namely Domain1, Domain2, Domain..., which is the peer-to-peer network on the Underlay, That is, Local hyperledger fabric network. Node users operate on the blockchain nodes to implement operations such as node registration, domain registration, entrusted release, revoked entrustment, and access.

First, the cross-domain coordination server allows users to access within a single domain and across domains. When the cross-domain coordination server receives a request from a user on a node, it generates a cross-domain CD (CrossDomain) transaction. Then, the cross-domain coordination server forwards the cross-domain transaction to the local smart contract of the node's domain.

Here's what the cross-domain coordination server does:

1. After receiving the registration request (node registration request, domain registration request), the cross-domain coordination server generates a cross-domain transaction to register the global identifier "CD.register" to register the global identifier of the node or domain on the blockchain.

2. The owner is allowed to publish and revoke the delegation policy of its resources using the cross-domain transaction of the publishing delegation policy "CD.delegate" and the cross-domain transaction of the revoking delegation policy "CD.revoke", respectively.

3. Generate a cross-domain transaction that sets the access type "CD.access" to set access/operate on-chain information in the same domain or in other domains.

Second, smart contracts on the blockchain define all operations of the access control system. Two types of smart contracts are proposed in this application, namely local smart contracts and global smart contracts. These local smart contracts and global smart contracts are deployed in the underlay and overlay networks respectively. These smart contracts define authentication and authorization operations for internal and external users, respectively. The smart contract performs corresponding processing operations when receiving cross-domain transactions from the cross-domain coordination server. The local smart contract stores the local delegation policy and the global delegation policy in two different data structures, that is, the authorization information authorized to nodes in the domain to access resources and the authorization information authorized to nodes in other domains to access resources in the local authorization list above. Similarly, the global smart contract stores the global delegation strategy in its data structure, which is the record information in the record list mentioned above.

Finally, based on the above cross-domain coordination server, global smart contracts and local smart contracts within each domain, at least the following operations can be performed:

1. Register the global node ID and the global domain ID in the global smart contract to realize domain registration.

2. Register the local node ID in the local smart contract to realize the registration of user nodes.

3. Publish the delegation policy, revoke the delegation policy and set the delegation action (that is, set the target access type in the previous article).

4. Cross-domain resource access.

The following take the registration of the global node ID, the registration of the global domain ID, publishing delegation policy and resource access as examples to illustrate:

Referring to Figure 13, in order to register the global domain identity in the Hyperledger Fabric alliance, the Domain owner, such as the management server in Domain 1, sends a domain registration request to the CrossDomain coordinator. Domain registration requests contain information such as domain names, IP addresses, and other metadata. The CrossDomain coordinator generates a cross-domain transaction of "CD.register", and then sends the cross-domain transaction to the global smart contract through the local smart contract Local smart contract of domain 1. After the Global smart contract registers the global domain identifier for the Domain owner , when the CrossDomain coordinator wakes up the Domain owner, the global domain identifier is returned to the Domain owner through the Local smart contract and the CrossDomain coordinator.

Referring to Figure 14, the node user user in the Domain sends a node registration request to the CrossDomain coordinator, and the node registration request includes information such as the local node ID, IP address and other metadata. The CrossDomain coordinator generates a "CD.register" cross-domain transaction, and then sends the cross-domain transaction to the global smart contract through the local smart contract Local smart contract of the current domain, and the Global smart contract is registering the node user user in the Domain After the global node identification, when the CrossDomain coordinator wakes up the Domain user, the Global smart contract returns the global node identification to the node user user in the Domain through the Local smart contract and the CrossDomain coordinator.

Referring to Figure 15, it is a flow chart of node user o _j issuing delegation policies to node user s _j , specifically as follows:

1. The node user o in the Domain sends a resource authorization request to the CrossDomain coordinator. The resource authorization request includes at least the global node ID of the node user o _j , the authorized node user s _j , the authorized public key p _k and the resources authorized to be accessed logo.

2. The CrossDomain coordinator generates a "CD.delegate" cross-domain transaction for the resource authorization request, and then sends the cross-domain transaction to the Local smart contract of the current domain;

3. The Local smart contract judges whether the node user o _j and the node user s _j are in the same domain, that is, whether the node user s _j is a node user on the global blockchain or a node user on the local blockchain;

4a. If the node user s _j is in the same domain as the node user o _j , the Local smart contract stores the authorization delegation policy in the local authorization list as the local delegation policy;

5a. If the node user s _j is in the same domain as the node user o _j , the Local smart contract returns to the CrossDomain coordinator a message indicating that the local authorization policy is successfully saved;

4b. If the node user s _j is not in the same domain as the node user o _j , the Local smart contract sends the authorization delegation policy to the Global smart contract, and stores the authorization delegation policy in the local authorization list as the global delegation policy;

5b. The Global smart contract stores the authorization delegation strategy in the record list as the global delegation strategy.

Referring to Figure 16 and Figure 17, it is a schematic diagram of cross-domain access between blockchain nodes in domain 1 and domain 2. The node user user in Domain1 sends a resource access request to the CrossDomain coordinator. There are two situations as follows:

As shown in Figure 16, if the resource access request is a resource access request for a node in the domain, after the CrossDomain coordinator sends the resource access request in the form of a cross-domain transaction to the Local smart contract of domain 1, the Local smart contract judges the After the global node identifier is determined as a resource access request to a node in the domain, the Local smart contract searches the local authorization list for the local authorization policy corresponding to the resource access request, and then obtains the corresponding authorization information. If no corresponding local authorization policy is found , then generate an access-forbidden message, and then the Local smart contract returns the authorization information or the access-forbidden message to the node user user in Domain1 through the CrossDomain coordinator, so that the node user user in Domain1 can use the authorization information to access the nodes in the domain The data;

As shown in Figure 17, if the resource access request is a resource access request to a node in another domain, after the CrossDomain coordinator sends the resource access request in the form of a cross-domain transaction to the Local smart contract of domain 1, the Local smart contract judges the resource access request based on the request After the global node identifier of the node is determined as a resource access request for nodes in other domains, the Local smart contract sends the resource access request to the Global smart contract, and the Global smart contract broadcasts the resource access request to nodes in other domains, such as node users in Domain2 And the node users in Domain3, etc., thus, the Local smart contract in each domain can obtain the corresponding authorization information after finding the local authorization policy corresponding to the resource access request. If the corresponding local authorization policy is not found, Then, a message of prohibiting access is generated. After that, the Local smart contract in each domain returns the authorization information or the message of prohibiting access to the Global smart contract. After the Global smart contract wakes up the node user user in Domain1, it will authorize through the CrossDomain coordinator Information or a message of prohibiting access is returned to the node user user in Domain1, so that the node user user in Domain1 can use the authorization information to access the data on the node in the corresponding domain.

Each embodiment in this specification is described in a progressive manner, each embodiment focuses on the difference from other embodiments, and the same and similar parts of each embodiment can be referred to each other. As for the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and for relevant details, please refer to the description of the method part.

Professionals can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software or a combination of the two. In order to clearly illustrate the possible For interchangeability, in the above description, the composition and steps of each example have been generally described according to their functions. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be directly implemented by hardware, software modules executed by a processor, or a combination of both. Software modules can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other Any other known storage medium.

The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the application. Therefore, the present application will not be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

A cross-domain access method on the blockchain, applied to a global server on the blockchain, the method comprising: Receiving a resource access request sent by a first server in the first domain on the blockchain, the resource access request indicates that the first node requests to access the first resource in the second node, and the first node is in the first domain, the second node is not in the first domain; In the record list of the global server, obtain record information corresponding to the resource access request; transmitting the resource access request to a second server in the second domain where the second node is located according to the record information; receiving authorization information corresponding to the resource access request transmitted by the second server; transmitting the authorization information to the first node, where the authorization information is used to instruct the first node to access the first resource. The method according to claim 1, wherein the record information corresponding to the resource access request is recorded in the record list in the following manner: receiving a resource authorization request sent by the second node through the second server, the resource authorization request indicating that the second node authorizes the first node to access the first resource with authorization information; Add record information corresponding to the resource authorization request to the record list, where the record information corresponding to the resource authorization request at least indicates that the first node is authorized to access the first resource in the second node. According to the method according to claim 2, the record information corresponding to the resource access request further represents the target access type of the first node to access the first resource; Wherein, the target access type is recorded in the record list in the following manner: receiving an authorization setting request sent by the second node through the second server, the authorization setting request indicating that the second node authorizes the first node to access the first resource with a target access type; The record information corresponding to the authorization setting request is added to the record list, and the record information corresponding to the authorization setting request not only indicates that the first node is authorized to access the first resource in the second node, but also indicates that the The first node is authorized to access the first resource with the target access type. The method according to claim 1 or 2, further comprising: receiving an authorization revocation request sent by the second node through the second server, the authorization revocation request indicating that the second node does not allow the first node to access the first resource; Add record information corresponding to the authorization revocation request to the record list, where the record information corresponding to the authorization revocation request indicates that the first node is prohibited from accessing the first resource in the second node. According to the method according to claim 1 or 2, obtaining record information corresponding to the resource access request in the record list of the global server includes: Comparing the global node identifier of the first node, the global node identifier of the second node, and the resource identifier in the resource access request with the record information in the record list to obtain information related to the resource access request Matching record information. The method according to claim 5, wherein the global node identifier is registered for the first node on the global server in the following manner: receiving the node registration request sent by the first node through the cross-domain coordination server in the blockchain; the node registration request at least includes the local node identifier of the first node in the first domain; generating a global node identifier for the first node according to the local node identifier of the first node in the node registration request; Returning the global node identifier of the first node to the first node through the cross-domain coordination server. According to the method according to claim 1 or 2, transmitting the authorization information to the first node comprises: When the link layer between the global server and the first node is connected, send the authorization information to the first node through the link layer; When the link layer between the global server and the first node is not connected, the authorization information is at least sent to the first node through the first server. A cross-domain access method on a block chain, applied to a first server in a first domain on the block chain, the method comprising: receiving a resource access request sent by a coordinating server in the blockchain, the resource access request representing that the first node requests to access the first resource in the second node, and the first node is in the first domain; determining that the second node is in a second domain; sending the resource access request to the global server on the block chain; receiving authorization information sent by the global server; sending the authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource. A server, as a global server on the blockchain, including: memory for storing computer programs and data generated by running the computer programs; A processor, configured to execute the computer program, so as to: receive a resource access request sent by a first server in the first domain on the block chain, the resource access request indicates that the first node requests to access the resource in the second node For the first resource, the first node is in the first domain, and the second node is not in the first domain; in the record list of the global server, record information corresponding to the resource access request is obtained; According to the record information, transmit the resource access request to a second server in the second domain where the second node is located; receive authorization information corresponding to the resource access request transmitted by the second server; transmit the resource access request; Authorization information is transmitted to the first node, where the authorization information is used to instruct the first node to access the first resource. A server, as the first server in the first domain on the blockchain, comprising: memory for storing computer programs and data generated by running the computer programs; a processor, configured to execute the computer program to realize: receiving a resource access request sent by a coordinating server in the blockchain, the resource access request representing that the first node requests to access the first resource in the second node, The first node is in the first domain; determine that the second node is in the second domain; send the resource access request to the global server on the block chain; receive authorization information sent by the global server ; Send the authorization information to the first node through the coordinating server, where the authorization information is used to instruct the first node to access the first resource.

Images