Transaction management system and transaction management method

Abstract

To provide a transaction management system capable of maintaining satisfactory reliability of a BC service while managing a resource-sharing status as appropriate among participating organizations in the BC services.SOLUTION: A transaction management system 45000 is a distributed ledger system in which a business network is constituted of multiple nodes 20000. The node 20000 is configured to calculate an upper limit number of transactions that each organization can issue using calculation rules shared among the nodes, and refuse acceptance of the transaction of an organization whose past number of transactions exceeded the upper limit number of transactions among the organizations.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a transaction management system and a transaction management method. [Background technology]

[0002] Distributed ledger technology using blockchain (hereinafter referred to as BC) has emerged as a technology that replaces transactions that have traditionally been conducted via trusted centralized institutions such as financial institutions and governments with direct P2P (Peer to Peer) transactions between users. Various derivatives of distributed ledger technology have been proposed and continue to evolve. Its current main features are: (1) transactions between participants in a distributed ledger are finalized through consensus and approval by (any or specific) participants rather than by a centralized authority; (2) multiple transactions are compiled into blocks, recorded in a chain-like manner in a distributed ledger called a blockchain, and tampering is made virtually impossible by performing hash calculations on successive blocks; and (3) all participants share the same ledger data, making it possible for all participants to confirm transactions.

[0003] Due to the above-mentioned characteristics, distributed ledger technology using BC is being considered for application in a wide range of fields, including finance and manufacturing, as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts.

[0004] By using a platform that provides a distributed ledger (hereinafter referred to as a distributed ledger platform), information can be shared and transactions can be conducted between multiple entities (for example, a consortium in a specific industry or multiple companies related to a supply chain) without the need for management by a centralized authority.

[0005] A blockchain or distributed ledger in which only computers authorized by a specific organization can participate in transactions is called a "consortium type." In this consortium type, there is a management entity that authenticates participants. This has the advantage of speeding up transaction approval.

[0006] Taking these advantages into consideration, when DLT technology is used within a consortium of a specific industry, a consortium-type DLT platform is generally used.

[0007] Furthermore, some distributed ledger platforms are now able to manage not only transaction data but also logic describing transaction conditions in the distributed ledger, making them applicable to complex transaction conditions and diverse applications. This logic is called a smart contract (hereinafter also referred to as SC). Technology related to a distributed ledger platform with the above-mentioned SC execution function is disclosed in Non-Patent Document 1.

[0008] The distributed ledger platform accepts transactions (hereinafter referred to as TX) while reaching a consensus among the nodes that make up the distributed ledger platform at a predetermined level, executes the TX at each node, and stores the results of the TX, thereby sharing information (ledger) across multiple nodes. It also has an SC execution function that executes predetermined logic on the TX.

[0009] In addition, attempts are being made to improve the efficiency of business processes by using consortium-type BCs for cross-organizational operations. In this case, a ledger containing the transaction history of all organizations participating in the BC is shared among the organizations, which is not necessarily desirable from the perspective of confidentiality of each business. Therefore, it is conceivable that there will be cases where ledgers will be shared only between organizations that have a specific business relationship.

[0010] Therefore, Non-Patent Document 1 discloses a concept called "Channel" that logically divides a distributed ledger to deal with such cases.

[0011] In this case, the distributed ledger infrastructure is a single distributed ledger infrastructure in which all organizations participate, but is internally logically divided into multiple distributed ledger infrastructures. Hereinafter, a set of nodes belonging to this logically divided distributed ledger infrastructure will be called a "subgroup."

[0012] Nodes belonging to the above subgroups share the distributed ledger only with nodes within that subgroup, and when executing TX, they execute the SC installed for each subsystem and update the data in the distributed ledger linked to each subgroup.

[0013] As mentioned above, in a consortium-type BC, it is necessary to ensure that only computers authorized by a specific organization can participate in transactions. In the distributed ledger platform technology described in Non-Patent Document 1, client users participating in transactions and nodes constituting the BC each hold a unique digital certificate to clarify their organization and authority.

[0014] Digital certificates are issued by the certification authority of each organization and are digitally signed by the certification authority. The public key of the certification authority itself is distributed to all organizations in advance, and by using it to verify the signature written on the certificate, the validity of the certificates of client users and BC participating nodes can be confirmed.

[0015] On the other hand, in recent years, consortium-type BC has been referred to as PaaS (Platform as a Service). Several cloud vendors are emerging that provide services in the form of cloud computing services. The service is called a managed blockchain service (BC service).

[0016] In BC services, in order to reduce the construction workload of customers, the construction and operation of distributed ledger nodes and certification authorities is carried out on behalf of the customer, but it is common for the customer to build the servers equipped with business applications that access the distributed ledger themselves.

[0017] A typical example of the configuration of a BC service is shown in Patent Document 1. In Patent Document 1, a plurality of gateway nodes and load balancers are installed between a consortium-type BC and an application server.

[0018] The gateway node stores the configuration information of the distributed ledger nodes that make up the BC, and handles processes such as consensus building and approval of TX in response to requests from business applications. Meanwhile, the load balancer distributes the processing load so that processing requests from business application servers are not concentrated on a specific gateway node. [Prior art documents] [Non-patent literature]

[0019] [Non-Patent Document 1] "Hyperledger Fabric", [online], [Retrieved December 1, 2021], Internet<URL:http: / / hyperledger-fabric.readthedocs.io / en / latest / > [Patent documents]

[0020] [Patent Document 1] US20190102423A1 Summary of the Invention [Problem to be solved by the invention]

[0021] In BC services based on existing technologies such as those described in Non-Patent Document 1, multiple organizations share the same computer resources. As a result, the behavior of each organization can adversely affect the operations of other organizations. In particular, in consortium-based BC, because all organizations share the same ledger, the number of times the ledger can be accessed per unit time tends to be constant regardless of the number of participating organizations. Therefore, if a specific organization accesses the system beyond its capacity, the load may become excessive, and other organizations may not be able to access the system.

[0022] Therefore, an object of the present invention is to provide a technology that allows appropriate resource sharing among participating organizations in a BC service and enables the reliability of the BC service to be maintained at a good level. [Means for solving the problem]

[0023] The transaction management system of the present invention, which solves the above-mentioned problems, is a distributed ledger system in which a business network is made up of multiple nodes, and the nodes calculate the upper limit of the number of transactions that each of multiple organizations can issue using calculation rules shared among the nodes, and refuse to accept transactions from any organization whose number of past transactions exceeds the upper limit. Furthermore, the transaction management method of the present invention is characterized in that, in a distributed ledger system in which a business network is formed by multiple nodes, the nodes calculate the upper limit of the number of transactions that each of multiple organizations can issue using calculation rules shared among the nodes, and refuse to accept transactions from any organization whose number of past transactions exceeds the upper limit. [Effects of the Invention]

[0024] According to the present invention, it is possible to appropriately share resources among participating organizations in a BC service, and to maintain the reliability of the BC service in a satisfactory manner. [Brief explanation of the drawings]

[0025] [Figure 1] 1 is a diagram illustrating an example of the configuration of a computer system including a transaction management system according to an embodiment of the present invention. [Figure 2] FIG. 1 is a diagram illustrating an example of the configuration of a blockchain included in a distributed ledger of a distributed ledger node in this embodiment. [Figure 3] FIG. 1 is a diagram illustrating an example of the configuration of a blockchain included in a distributed ledger of a distributed ledger node in this embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of the configuration of state information included in the distributed ledger of a distributed ledger node in this embodiment. [Figure 5] FIG. 2 is a diagram illustrating an example of the configuration of gateway configuration information included in the load balancer according to the present embodiment. [Figure 6] FIG. 2 is a diagram illustrating an example of the configuration of request history information included in a load balancer according to the present embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of the configuration of an inter-organization distribution policy included in the TX restriction condition formulation logic in the initial block in this embodiment. [Figure 8] 10 is a diagram showing an example of the configuration of an SC weighting policy included in the TX restriction condition formulation logic in the initial block in this embodiment. FIG. [Figure 9] 10 is a diagram showing an example of the configuration of a TX restriction meta condition included in the TX restriction condition formulation logic in the initial block in this embodiment. FIG. [Figure 10] FIG. 10 is a diagram illustrating an example of the configuration of the TX limit upper limit of a distributed ledger node in this embodiment. [Figure 11] 10 is a flowchart illustrating an example of the overall flow of a new subgroup creation process executed by a distributed ledger node in this embodiment. [Figure 12] 1 is a flowchart illustrating an example of the overall flow of a transaction execution process executed by a distributed ledger node in this embodiment. [Figure 13] 10 is a flowchart illustrating an example of the overall flow of a subgroup configuration change process executed by a distributed ledger node in this embodiment. [Figure 14] 10 is a flowchart showing an example of the overall flow of TX restriction condition formulation logic included in the initial block in this embodiment. [Figure 15] FIG. 1 is a diagram illustrating an example of the configuration of a computer system according to an embodiment of the present invention. [Figure 16] FIG. 1 is a diagram illustrating an example of the configuration of a blockchain included in a distributed ledger of a distributed ledger node in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0026] <Network configuration> An embodiment of the present invention will be described in detail below with reference to the drawings. Figure 1 is a diagram showing an example of a network configuration of a computer system including a blockchain platform 45000 (i.e., a transaction management system) according to this embodiment. The blockchain platform 45000 shown in Figure 1 is a distributed ledger system that optimizes resource sharing among participating organizations in a BC service and enables the reliability of the BC service to be maintained.

[0027] The computer system shown in FIG. 1 is composed of a business application server 40000 and a blockchain platform 45000.

[0028] Of these, the business application server 40000 is composed of a request issuing unit 41000 and a business application 42000. The business application 42000 is an application that receives and processes requests related to transactions defined on the SC from client users who access the business application server 40000 using their terminals.

[0029] This business application transmits input contents by the client user via the request issuing unit to the load balancer 30000 of the blockchain platform 45000 via the Internet 46000.

[0030] The load balancer 30000 distributes the request including the above input content to the gateway node 10000. Upon receiving this, the gateway node 10000 issues a TX (transaction) via the transaction issuing unit 11000 and distributes it to the distributed ledger node 20000.

[0031] The issuer information attached to the above-mentioned TX is the organization ID that uniquely identifies the issuing organization, and the authentication information (private key) issued to each client user. When issuing a TX, the client user signs the TX using their own private key and sends it along with a certificate. The certificate and private key are issued in advance by the certification authority of the client user's organization.

[0032] In addition to the load balancer 30000 described above, the blockchain platform 45000 is also composed of one or more gateway nodes 10000 and one or more distributed ledger nodes 20000.

[0033] These devices are connected to each other through physical or logical communication lines. The blockchain platform 45000 is connected to one or more business application servers 40000 via a load balancer 30000 and the Internet 46000.

[0034] In this embodiment, a configuration is assumed in which there are multiple distributed ledger nodes 20000. These distributed ledger nodes 20000 are managed by multiple organizations (e.g., multiple entities) that make up a consortium. Each is managed by a single organization (e.g., a single vendor / multiple organizations / multiple vendors).

[0035] An organization may have multiple distributed ledger nodes 20000. In this case, multiple distributed ledger nodes 20000 coexist while sharing the same information, making it easier to ensure redundancy in the event of a failure.

[0036] Similarly, it is assumed that there are multiple gateway nodes 10000 and multiple business application servers 40000, and that multiple organizations use their own gateway nodes and business application servers. Also, in this embodiment, the gateway node 10000 and the distributed ledger node 20000 are shown as separate devices, but they may also be integrated into one node.

[0037] The physical entities of the business application server 40000, the distributed ledger node 20000, and the gateway node 10000 are general computers consisting of a processor, a memory, a communication unit, and a data bus connecting these together.

[0038] In the hardware configuration of the computer, the memory is SSD (Solid State Drive). It consists of suitable non-volatile memory elements such as a standard ROM (Serial Serial Port Drive) or hard disk drive, or volatile memory elements such as RAM (Random Access Memory). In addition to the programs that implement the necessary functions, these memories also store various data used by the programs for calculations.

[0039] The processor is a CPU that reads and executes the programs stored in the memory, performs overall control of the computer itself, and performs various judgments, calculations, and control processes.

[0040] The communication unit is a network interface card or the like that connects to an appropriate network such as the Internet 46000 and handles communication processing with other devices.

[0041] The gateway node 10000 shown in FIG. 1 is configured by a transaction issuing unit 11000 and node configuration information 12000.

[0042] In addition, the distributed ledger node 20000 is composed of a consensus management unit 21100, a smart contract execution / management unit 21200 (hereinafter also referred to as the SC execution / management unit), a transaction management unit 21300, a subgroup management unit 21400, a TX restriction management unit 21500, TX restriction condition information 21600, and a distributed ledger 25000.

[0043] The distributed ledger 25000 is defined for each subgroup, and the same ledger is shared among the nodes belonging to the subgroup.

[0044] The distributed ledger node 20000 accepts TX from the gateway node 10000 using the function of the transaction management unit 21300, and uses the function of the consensus management unit 21100 to reach a consensus with other distributed ledger nodes 20000 on whether the TX can be accepted.

[0045] In addition, once a consensus is reached regarding the above-mentioned TX, the distributed ledger node 20000 deploys the SC and manages the deployed SC through the function of the SC execution / management unit 21200. The distributed ledger node 20000 records the history of the TX and its execution results in the distributed ledger 25000.

[0046] In addition, the transaction management unit 21300 of the distributed ledger node 20000 accepts TX in response to requests from each node such as the gateway node 10000, and also provides a function / interface to obtain and view the history information of the TX.

[0047] In the distributed ledger system, i.e., the blockchain platform 45000, in this embodiment, the members, i.e., organizations (and their distributed ledger nodes 20000) participating in the consortium are managed by the distributed ledger 25000 maintained by the distributed ledger node 20000 of each organization.

[0048] In addition, the subgroup management unit 21400 of the distributed ledger node 2000 provides functions for registering and adding new organizations and subgroups as described above.

[0049] In addition, the blockchain platform 45000 of this embodiment is assumed to use a pair of private and public keys to authenticate participating organizations, sign TX, control SC execution authority, etc.

[0050] Therefore, the private key information of each distributed ledger node 20000 is stored and managed in the transaction manager 21300 of the distributed ledger node 20000. On the other hand, the public key information is shared among all distributed ledger nodes 20000.

[0051] The transaction manager 21300 of the distributed ledger node 20000 verifies whether the issuer of the TX is a valid authorized participant whenever it receives the TX. Note that the methods for generating a pair of public and private keys and for verifying signatures can be publicly known or well-known technologies, so explanations are omitted here.

[0052] The distributed ledger 25000 owned by the distributed ledger node 20000 stores and manages the business-related smart contract 26000 and the TX results of this smart contract (SC). The data structure of the TX results is assumed to be a blockchain 27000 that stores the TX history, and state information 28000 based on the TX execution results in table format.

[0053] In the blockchain platform 45000 of this embodiment, the members participating in the consortium, i.e., the organizations and distributed ledger nodes, are managed by each organization's distributed ledger 25000. In addition, the subgroup management unit 21400 provides functions for registering and adding new organizations and subgroups.

[0054] Furthermore, in the blockchain platform 45000 of this embodiment, it is assumed that private keys and certificates are used to authenticate participating organizations, sign TX, control SC execution authority, etc. Information on the certificate and private key unique to each distributed ledger node 20000 is stored and managed in the participating member management information 29000 of that distributed ledger node 20000. Meanwhile, information on the root certificate of each organization is shared among all distributed ledger nodes.

[0055] The distributed ledger 25000 stores and manages business-related smart contracts 26000 and TX results from SCs. As a data structure for TX results, this embodiment assumes that the TX history is stored as a blockchain 27000, and state information 28000 based on the execution results of TX is stored in table format.

[0056] On the other hand, the load balancer 30000 is composed of a request distribution unit 31000, gateway configuration information 32000, and request history information 33000. Of these, the gateway configuration information 32000 holds a list of gateway nodes 10000 in the blockchain platform 45000 and information on the access destinations.

[0057] Furthermore, when the load balancer 30000 receives information input from the business application 42000, it references the gateway configuration information 32000 and transfers the information in a round-robin manner to the gateway node 10000. At this time, the received information and its execution results are stored in the request history information 33000. <Data structure example> 2, 3, and 4 show examples of data structures stored in the distributed ledger 25000 included in the distributed ledger node 20000.

[0058] Figure 2 is an example of a blockchain 27000, one of the data structures managed by a distributed ledger 25000. In distributed ledger management using BC, multiple TXs are grouped together as blocks, and data is managed in a chained manner with each block having the hash value of the previous block. If even one bit of the value of the previous block changes, the hash values ​​of all subsequent blocks change, making tampering difficult.

[0059] In this embodiment, for the sake of simplicity, one TX is stored in one block, but the present invention is also applicable to cases where multiple TXs are stored together in one block.

[0060] 2 shows an example of such a series of blocks 27010 to 27030 in the BC 27000. Except for the initial block 27010 that stores the initial information of a subgroup, which will be described later, each of the blocks 27400 to 27040 includes TX information for either deployment or execution of the SC.

[0061] Furthermore, each of blocks 27400 to 27040 includes the hash value 27100 of the previous block, and also includes a hash value 27200 generated from state information, which will be described later.With the data structure described above, the history information of the creation of subgroups and the deployment and execution of SCs is managed as a data chain within the BC.

[0062] The initial block 27010 is an example of a block that stores the initial information of a subgroup. In this embodiment, the TX27300 of the initial block 27010 defines the ID of the subgroup linked to the distributed ledger 25000. Furthermore, the IDs and attributes of the organizations that belong to the subgroup, a list of root certificates, and the name of the distributed ledger node 20000 that represents each organization are defined. In addition, the TX restriction condition formulation logic (e.g., It contains a block (e.g., an executable binary) and a timestamp indicating when the block was created.

[0063] Blocks 27020 and 27030 are examples of blocks that store the deploy TX of the SC. Of these, the deploy TX 27400 includes a contract ID that uniquely identifies the contract, the contract logic (for example, an executable binary), and the conditions required to obtain approval of the transaction between participating organizations (the deploy TX 27410 has a similar configuration, and its description will be omitted).

[0064] In addition, the deployment TX27400 includes a contract input specification that allows users to understand the function names and arguments of the contract. In this example, "Transfer" and "Check balance" are defined as the function names of the SC with the ID "SC1", and the logic of the functions is also defined.

[0065] Furthermore, this deployment TX27400 includes the signature of the client user who issued it and the digital signature of the distributed ledger node 20000 that agreed to execute this deployment TX27400. It also includes an ID that is a unique identifier of the TX and a timestamp that indicates the time when the TX was issued.

[0066] Moreover, block 27040 is an example of a block that stores SC execution TX 27500. The execution TX 27500 in this embodiment includes the contract ID of the contract to be called, the function name of the contract to be called, and information on input arguments.

[0067] In this example, the function "Remit" of the SC with ID "SC1" is called, and its arguments are the sending organization ID, receiving organization ID, and amount, which are "Org1", "Org3", and "100", respectively.

[0068] The execution TX 2700 further includes the signature of the client user of this TX and the digital signature of the distributed ledger node that agreed to the execution of this TX. It also includes an ID that is a unique identifier of the TX and a timestamp indicating the time when the TX was issued. It also includes an ID that is a unique identifier of the TX within the distributed ledger and a timestamp indicating the time when the TX was issued.

[0069] Figure 3 is an example of a blockchain 27000, which is one of the data structures managed by the distributed ledger 25000.

[0070] Of these, the configuration change block 27050 is an example of a block that stores configuration change information for a subgroup. TX27600 in the configuration change block 27600 of this embodiment defines the IDs and attributes of organizations that will belong to the subgroup after the configuration change, a list of root certificates, and the name of the distributed ledger node 25000 that will represent each organization. In addition, it includes an ID that is a unique identifier for the TX and a timestamp that indicates the time the block was generated. The configuration of the blockchain illustrated in FIG. 3 is the same as the configuration in FIG. 2, except for the configuration change block 27600.

[0071] Figure 4 shows state information 28000 managed by a distributed ledger 25000. In distributed ledger management using BC, it is usually necessary to trace the BC to obtain the latest state (for example, the account balance in the case of virtual currency). This is inefficient processing, so there is a method of caching the latest state information separately from the BC (Non-Patent Document 1, etc.).

[0072] In this embodiment, it is also assumed that the latest state information 28000 is held. In this embodiment, a state data area is prepared for each function that the SC 26000 has.

[0073] The state information 28000 holds an ID 28010 that is an identifier of the SC 26000, an entity 28020 of the SC 26000, and an identifier 28030 of the subgroup linked to the SC 26000.

[0074] As a result, the SC execution / management unit 21200 executes the contract using the contract ID and function name as keys. , the entity of the SC can be acquired and executed. The state information 2800 also includes an internal table 28040 for holding the execution results of the SC 26000. SC Execution / Management The unit 21200 updates the contents of this internal table 28040 every time SC is executed.

[0075] The internal table 28040 shown in FIG. 4 is configured as a table called "owned amount data," and the information specified by the TX argument is overwritten as needed.

[0076] FIG. 5 is a diagram showing an example of the configuration of the node configuration information 12000 included in the gateway node 10000. As shown in FIG.

[0077] The node configuration information 12000 includes, as configuration items, a field 12010 for registering the name of the distributed ledger node 20000 to which the gateway node 10000 sends TX, and a field 12020 for registering the ID of the organization to which the distributed ledger node 20000 belongs.

[0078] 6 is a diagram showing an example of the configuration of the request history information 33000 included in the load balancer 30000. The request history information 33000 is added when a request is made from the business application server 40000 to the load balancer 30000.

[0079] This request history information 33000 includes, as constituent items, a field 33010 for registering the date and time when the request occurred, a field 33020 for registering the ID of the SC26000 that the request is attempting to execute, a field 33030 for registering the name of the function in the SC26000 that the request is calling, and a field 33040 for registering the client node signature assigned to the request.

[0080] FIG. 7 is a diagram showing an example of the configuration of an inter-organization distribution policy 28000 included in the TX restriction condition formulation logic of the initial block 27300.

[0081] The inter-organization distribution policy 28000 includes, as constituent items in the initial block 27300, a field 28010 for registering the organization type recorded together with the organization ID, and a field 28020 for registering the score assigned to the organization type.

[0082] FIG. 8 is a diagram showing an example of the configuration of an SC weighting policy 28100 included in the TX limiting condition formulation logic of the initial block 27300.

[0083] The SC weighting policy 28100 includes, as its constituent items, a field 28110 for registering the TX approval conditions of each SC26000 registered in the deploy transaction 27400, and a field 28120 for registering the score assigned to the TX approval condition.

[0084] FIG. 9 is a diagram showing an example of the configuration of a TX restriction meta condition 28200 included in the TX restriction condition formulation logic of the initial block 27300.

[0085] The TX limit meta condition 28200 includes, as constituent items, a field 28210 for registering the ID of the conditional statement included in the TX limit meta upper limit, a field 28220 for registering the TX upper limit calculation formula, and a field 28230 for registering the meta past TX calculation formula corresponding to the TX upper limit calculation formula.

[0086] FIG. 10 is a diagram showing an example of the configuration of the TX restriction condition information 21600 provided in the distributed ledger node 20000.

[0087] The TX restriction condition information 21600 includes, as constituent items, a field 21610 for registering the ID of the condition statement included in the TX restriction condition, a field 21620 for registering the ID of the organization to which the condition statement applies, a field 21630 for registering the TX upper limit value assigned to the organization, and a field 21640 for registering the past TX calculation formula corresponding to the TX upper limit value. <Flow example 1> The actual procedure of the transaction management method in this embodiment will be explained below with reference to the drawings. The various operations corresponding to the transaction management method explained below are realized by a program that is read into memory or the like and executed by each device constituting the blockchain platform 45000 (distributed ledger system) which is the transaction management system (same below). This program is composed of code for performing the various operations explained below.

[0088] 11 is a flowchart showing an example of a new subgroup creation process by the subgroup manager 21400 included in the distributed ledger node 20000 of this embodiment. The specific internal processing is shown below.

[0089] When multiple organizations on a blockchain attempt to create a new subgroup, the administrator of the BC service must reach an agreement with the participating organizations in advance and determine the subgroup ID, the participating organization's ID, the participating organization's root certificate, the name of the participating organization's representative node, and the TX restriction condition formulation logic, and then operate a designated terminal to input these into the subgroup management unit 21400.

[0090] Meanwhile, the subgroup management unit 21400 of the distributed ledger node 20000 creates an initial block based on this information (step 51010).

[0091] Next, the subgroup manager 21400 distributes the initial block created in the above step to the subgroup managers 21400 of other distributed ledger nodes 20000 (step 51020).

[0092] The subgroup management unit 21400 of each organization that receives the distribution creates a distributed ledger 25000 that includes a blockchain starting from the initial block (step 51030).

[0093] Finally, the TX restriction management unit 21500 in the distributed ledger node 2000 of each organization creates TX restriction condition information 21600 based on the TX restriction condition formulation logic and participating organization information (step 51040). The details of the procedure for creating TX restriction condition information are described in FIG. 14. <Flow example 2> FIG. 12 is a flowchart showing an example of the TX execution process of the distributed ledger node 20000, i.e., the deployment and execution of an SC.

[0094] In this case, when the gateway node 10000 receives an input of a request related to a transaction defined on the SC from the business application 42000 via the load balancer 30000, it converts the request into a TX for the distributed ledger node 20000.

[0095] Then, the gateway node 10000 issues a TX to the TX restriction management unit 21500 of any one of the distributed ledger nodes 20000 to check whether the TX to be executed violates the TX restriction conditions (step 52010). The contents of the TX include the SC name, function name, and arguments to be executed.

[0096] On the other hand, the TX restriction management unit 21500 compares the client user signature attached to the TX with the root certificate in the initial block to confirm whether it is a valid user (step 52020).

[0097] Next, the TX limit management unit 21500 identifies the participating organization of the TX sender user, and by referring to the TX limit condition information 21600, compares (A) the TX upper limit value of the organization with (B) the number of TXs issued in a certain period of time in the past calculated by the method defined in the past TX calculation formula (step 52030).

[0098] If the result of the above comparison is (A)>(B), the TX restriction management unit 21500 responds to the gateway node 10000 that TX cannot be performed (step 52040).

[0099] On the other hand, if (A)≦(B), the TX restriction management unit 21500 responds to the gateway node 10000 that TX is executable (step 52050).

[0100] If multiple combinations of TX upper limit values ​​and past TX calculation formulas are defined for the organization, the response will be that TX is executable only if (A)≦(B) for all combinations.

[0101] When calculating the number of TXs issued in a certain period of time in the past using the method defined in the past TX calculation formula described above, the TX limit management unit 21500 refers to the executed transaction 27500 on the BC 27000. On the other hand, instead of the BC 27000, the request history information 33000 provided in the load balancer 30000 may be referred to.

[0102] The gateway node 10000 issues a transaction to the TX restriction management unit 21500 of the distributed ledger node 20000 of each participating organization to obtain the approval required to execute TX (step 52060).

[0103] When the transaction management unit 21300 of the distributed ledger node 20000 receives TX from the gateway node 10000, it compares the client user signature attached to the transaction and the certificate sent at the same time with the root certificate in the initial block to verify whether they are valid (step 52070).

[0104] If the transaction is found to be valid as a result of the above verification, distributed ledger node 20000 signs the TX using its own private key (step 52080). In addition, distributed ledger node 20000 returns the signed TX to gateway node 10000 (step 52090).

[0105] On the other hand, when the gateway node 10000 receives signed TX from each distributed ledger node 20000, it considers the consensus to be complete and requests the transaction manager 21300 of any one of the distributed ledger nodes 20000 to distribute the TX (step 52100).

[0106] The transaction manager 21300 of the distributed ledger node 20000 that received the request sends the TX to the transaction distributor 21000. The transaction distributor 21000 assigns an ID to the TX and requests the representative distributed ledger node 20000 of the other organization recorded in the initial block to distribute the TX (step 52110).

[0107] The representative distributed ledger node 20000 of each organization references the participating member management information 29000 and distributes the TX to other distributed ledger nodes 20000 within its own organization (step 52120). The SC executor / manager 22000 of each distributed ledger node 20000 that receives this TX The received TX is registered in the distributed ledger 25000.

[0108] In this case, if the contents of the TX relate to the deployment of SC26000, the contract ID and contract entity are registered as state information 28000 in the distributed ledger 25000, and a block containing this TX is added to the end of the blockchain 27000.

[0109] If the contents of the TX relate to the execution of a function defined in the SC26000, the call function and input arguments specified in the TX are given to the SC26000 having the contract ID specified in the TX and executed. Then, based on the results, the contents of the distributed ledger 25000 are updated. That is, based on the execution results, the state information 28000 related to this SC26000 is updated, and the execution TX is added as the last block of the blockchain 27000 (step 52130).

[0110] In this embodiment, the broadcast processing in steps 52060 and 52070 described above is performed by the distributed ledger node 20000, but this may also be performed by another node dedicated to transaction distribution. <Flow example 3> 13 is a flowchart showing an example of a subgroup configuration change process by the subgroup manager 21400 included in the distributed ledger node 20000. The specific internal process is shown below.

[0111] When the administrator of the distributed ledger node 2000 of the organization representing the subgroup wishes to add or remove an organization participating in the subgroup, he / she operates a specified terminal to input into the subgroup management unit 21400 the ID of each participating organization after the change in participating organization, the root certificate of each participating organization, and the name of the representative node of each participating organization.

[0112] When the subgroup management unit 21400 receives this input, it creates a configuration change block that defines this information (step 53010).

[0113] Next, the subgroup management unit 21400 receives a signature for the configuration change block from the subgroup management unit 2140 of the distributed ledger node 20000 of another organization participating in the subgroup (step 53020).

[0114] Next, the subgroup manager 2140 distributes the signed configuration change block to other distributed ledger nodes 20000 in the same subgroup (step 53030).

[0115] The subgroup management unit 21400 of each organization writes the above-mentioned configuration change block to the BC 27000 (step 53040).

[0116] Finally, the TX limit management unit 21500 of each distributed ledger node 20000 recreates the TX limit upper limit information 21600 based on the TX limit condition formulation logic and participating organization information (step 53050). <Flow example 4> 14 is a flowchart showing an example of TX restriction condition formulation logic included in the initial block 27300. Specific internal processing will be described below.

[0117] The TX restriction management unit 21500 references the initial block 27300 and the configuration change block 27600 on the BC 27000 included in the distributed ledger 25000, and obtains a list of organizations that make up the subgroup (step 54010).

[0118] Next, the TX limit management unit 21500 refers to the TX upper limit calculation formula in the TX limit meta condition 28200 and the inter-organization distribution policy, and calculates the TX upper limit for each organization (step 54020).

[0119] Next, the TX restriction management unit 21500 references the deploy transaction 27400 on the distributed ledger 25000 and acquires a list of SCs 26000 on the node (step 54030).

[0120] Finally, the TX restriction management unit 21500 derives a past TX calculation formula for each organization by referring to the meta past TX calculation formula in the TX restriction meta condition 28200 and the SC weighting policy (step 54040).

[0121] The following explanation uses the example data shown in the drawings. The TX limit management unit references the initial block 27300 on the distributed ledger shown in Figure 2, and identifies "org1" and "org2" as the organizations that make up the subgroup. Next, it references the TX upper limit calculation formula in the TX limit meta conditions 28200 shown in Figure 9, calculates the TX upper limit for each organization, and records it in the TX upper limit value of the TX limit condition information shown in Figure 10.

[0122] Specifically, the tissue types of "org1" and "org2" are "normal" and "a According to the inter-organizational distribution policy (Figure 7), each score is "2" 9. Therefore, the TX upper limit values ​​shown in ID1-1 and ID2-1 in FIG. 10 are calculated from the TX upper limit calculation formula shown in ID1 in FIG.

[0123] Next, the TX restriction management unit 21500 refers to the deploy block on the distributed ledger 25000 shown in Figure 2, and identifies "SC1" and "SC2" as SCs that make up the subgroup.

[0124] Next, the TX restriction management unit 21500 calculates the past TX calculation formula for each organization by referring to the meta past TX calculation formula in the TX restriction meta condition 28200 shown in Figure 9, and calculates the record in the meta past TX calculation formula of the TX restriction condition shown in Figure 10.

[0125] Specifically, the TX approval conditions for "SC1" and "SC2" are "two or more organizations" and "three groups," respectively. According to the SC weighting policy (Fig. 8), the scores are "2" and "3". 3". Therefore, the past TX calculation formulas shown in ID1-1 and ID2-1 in FIG. 10 are calculated from the meta past TX calculation formula shown in ID1 in FIG.

[0126] It is not necessary to provide both the inter-organization distribution policy and the SC weighting policy, and either one may be omitted.

[0127] In step 52030 of FIG. 12, the TX limit management unit 21500 identifies the participating organizations of the user who sent the TX, and by referring to the TX limit condition information 21600, compares (A) the TX upper limit value of the organization with (B) the number of TXs issued during a certain period of time in the past calculated using the method defined in the past TX calculation formula.

[0128] If the participating organization of the user sending the TX is "org1" and the TX issuance time is "2021 / 12 / 0300:00:30", then according to distributed ledger 25000 shown in Figure 2, there has only been one TX in the past minute, to "SC1", and the values ​​calculated using the past TX calculation formulas shown in ID1-1 and 2-1 in Figure 10 are "2". Since both of these are below the TX upper limit, the execution of the TX is permitted.

[0129] In the above example, if the number of TXs issued over a certain period of time in the past exceeds the TX upper limit, the TX limit management unit 21500 will uniformly reject all TXs. However, instead of uniformly rejecting all TXs, different TX upper limit values ​​may be agreed upon among multiple SCs based on an index such as the importance of the SC26000, and restrictions may be applied in order from the SC26000 with the lowest priority. Also, it may be possible to restrict only some of the processes within the same SC26000.

[0130] In the SC weighting policy shown in Figure 8, scoring is performed according to the TX approval conditions, but it is also possible to use other criteria (for example, the processing load of the logic of the SC26000) to assign scores. Scoring may be performed by:

[0131] In the TX limiting condition formulation logic shown in FIG. 14, the TX upper limit value is calculated for each organization, but it may also be calculated for each client user under the organization or for each upper-level application that issues TX.

[0132] In the above example, the TX restriction management unit 21500 and the TX restriction condition information 21600 are configured to be located on the distributed ledger node 20000, but they may also be located on the gateway node 10000. In addition, the TX restriction condition formulation logic may exist as an independent SC, rather than within the initial block. <About other forms> FIG. 15 schematically shows another embodiment of the business application server 40000 and the blockchain platform 45000 assumed in this embodiment.

[0133] In this embodiment, the gateway node 10000 is configured by a transaction issuing unit 11000, node configuration information 12000, a TX restriction management unit 13000, and TX restriction condition information 14000.

[0134] On the other hand, the distributed ledger node 20000 does not have a TX restriction manager or TX restriction condition information, and the TX restriction manager 13000 and TX restriction condition information 140000 on the gateway node 10000 perform the equivalent roles. Other than the above, the contents are the same as those shown in Figure 1.

[0135] FIG. 16 is an example of another form of a blockchain 27000, which is one of the data structures managed on the distributed ledger 25000 provided by the distributed ledger node 20000.

[0136] Block 27020 is an example of a block that stores the deployment TX of SC26000. In this example, the deployment TX 27400 includes a contract ID that uniquely identifies SC26000, the logic of the SC26000 (e.g., an executable binary), and the conditions required to obtain TX approval among participating organizations. It also includes contract input specifications that allow users to understand the function names and arguments of SC26000.

[0137] In this example, "TX upper limit calculation" is defined as the function name of SC26000 with an ID of "SC0", and the logic of the function is also defined. Furthermore, the logic of this function includes the TX limit condition formulation logic shown in Figure 14, an inter-organizational distribution policy 28000, an SC weighting policy 28100, and a TX limit meta condition 28200. Other than the above, the contents are the same as those shown in Figures 2 and 3.

[0138] As described above, by using this invention, it is possible to guarantee each organization participating in a BC service a certain number of accesses to the distributed ledger that can be performed per unit time. On the other hand, by providing customers with an access limit management function using the above means, BC service vendors can ensure the reliability of the BC service performance and improve the value of the service.

[0139] The best mode for carrying out the present invention has been specifically described above, but the present invention is not limited to this and can be modified in various ways without departing from the spirit of the present invention.

[0140] According to this embodiment, it is possible to guarantee a certain number of accesses to the ledger that can be performed per unit time for each organization participating in the BC service. On the other hand, the BC service vendor can provide the customer with an access limit management function, guarantee the reliability of the performance of the BC service, and improve the value of the service. This allows appropriate resource sharing among participating organizations, thereby making it possible to maintain the reliability of the BC service.

[0141] The description in this specification makes at least the following clear: That is, the transaction management system of this embodiment may further include a predetermined node that manages configuration information of organizations that can participate in the distributed ledger system on the distributed ledger, and the plurality of nodes may calculate the upper limit of the number of transactions for each organization by applying the configuration information obtained from the predetermined node as input to the calculation rule for the upper limit of the number of transactions.

[0142] This makes it possible to calculate the upper limit of the number of transactions based on the number of participants in the distributed ledger system, which is a business platform, and the fluctuations in that number. This in turn makes it possible to more appropriately share resources between participating organizations in the BC service, and to better maintain the reliability of the BC service.

[0143] Furthermore, in the transaction management system of this embodiment, when a change occurs in the configuration information obtained from the specified node, the node may recalculate the upper limit number of transactions for each of the multiple organizations based on the transaction limit calculation rule.

[0144] This allows for dynamic calculation of the upper limit on the number of transactions, even if there is a change in the number of participants in the distributed ledger system, which serves as a business platform. This in turn allows for more appropriate resource sharing among participating organizations in the BC service, and further maintains the reliability of the BC service.

[0145] Furthermore, in the transaction management system of this embodiment, the node may hold policy information in the calculation rule for the upper limit of the number of transactions that allocates the upper limit of the number of transactions for each of the multiple organizations in a skewed manner based on the attributes of the organization.

[0146] This makes it possible to manage the upper limit of the number of transactions according to the characteristics and importance of the organization, etc. This in turn makes it possible to further improve the resource sharing situation between participating organizations in the BC service and to better maintain the reliability of the BC service.

[0147] Furthermore, in the transaction management system of this embodiment, the nodes may share, with the agreement of the participants, smart contracts, which are logic that describes the conditions of transactions conducted between organizations participating in the distributed ledger system, and may hold policy information that changes the weighting of each smart contract depending on the difference in processing load of the smart contracts when calculating the number of past transactions for each of the multiple organizations in the calculation rule for the upper limit of the number of transactions.

[0148] This allows for the upper limit of the number of transactions to be controlled based on the processing load of the smart contract, which in turn allows for more appropriate resource sharing among participating organizations in the BC service and better maintains the reliability of the BC service.

[0149] In addition, in the transaction management system of this embodiment, the node holds, for each smart contract, an endorsement policy, which is a consensus level when forming a consensus on a transaction between organizations participating in the distributed ledger system, and in the policy information regarding the weighting of the smart contract, the previous The endorsement policy may be used.

[0150] This enables accurate management of the upper limit of the number of transactions, taking into account the characteristics of endorsements as well as the processing load of the smart contracts. This in turn allows for more appropriate resource sharing among participating organizations in the BC service, and makes it possible to better maintain the reliability of the BC service.

[0151] Furthermore, in the transaction management system of this embodiment, the node may identify past transactions in each of the multiple organizations based on the timestamps of the transactions stored in the distributed ledger and information on the organizations to which the transaction executors belong, and calculate the number of such transactions as the number of past transactions.

[0152] This allows transactions to be grouped together, such as transactions issued by a specific organization within a recent specified period, and can be used appropriately to calculate the upper limit of the number of transactions. This in turn allows for more appropriate resource sharing among participating organizations in the BC service, and better maintains the reliability of the BC service.

[0153] Furthermore, the transaction management system of this embodiment may further include a load balancer that allocates transactions from a higher-level application to the nodes, the load balancer storing a history of transactions from the higher-level application as a log, and when calculating the number of past transactions for each of the multiple organizations, the nodes may identify transactions based on the transaction timestamps and information on the organizations to which the transaction executors belong, which are stored in the load balancer log, and calculate the number of such transactions as the number of past transactions.

[0154] This allows the load balancer to calculate the number of past transactions efficiently and accurately, which in turn improves the resource sharing situation between participating organizations in the BC service and makes it possible to maintain the reliability of the BC service more effectively.

[0155] In the transaction management system of this embodiment, the predetermined node may be a gateway node that performs the processes of consensus building and approval of a transaction in response to a request from the upper-level application.

[0156] This allows the gateway node that actually issues transactions to manage node configuration information and use it to timely manage the upper limit on the number of transactions, thereby further optimizing resource sharing among participating organizations in the BC service and maintaining the reliability of the BC service. [Explanation of symbols]

[0157] 10000 gateway nodes 11000 Transaction Issuer 12000 Node configuration information 20,000 distributed ledger nodes 21100 Consensus Management Department 21200 Smart Contract Execution / Management Department 21300 Transaction Management Department 21400 Subgroup Management Department 21500 TX Restriction Management Department 21600 TX Restriction Condition Information 25,000 distributed ledgers 26000 smart contracts 27000 Blockchain 28000 State Information 30000 Load Balancer 31000 Request Distribution Unit 32000 Gateway Configuration Information 33000 Request History Information 35,000 HSMs 40,000 business application servers 41000 Request Issuance Department 42,000 business applications 45,000 Cloud infrastructure (transaction management system, distributed ledger system) 46000 Internet

Claims

1. A distributed ledger system in which a business network is formed by multiple nodes, The node calculates the upper limit of the number of transactions that each of the multiple organizations can issue using calculation rules shared among the nodes, and refuses to accept transactions from any organization whose number of past transactions exceeds the upper limit of the number of transactions. A transaction management system characterized by:

2. The system further includes a predetermined node that manages, on the distributed ledger, configuration information of organizations that can participate in the distributed ledger system; the plurality of nodes calculate the upper limit of the number of transactions for each organization by applying the configuration information obtained from the predetermined node as an input to the calculation rule for the upper limit of the number of transactions; 2. The transaction management system according to claim 1, wherein:

3. The node When a change occurs in the configuration information obtained from the predetermined node, the upper limit number of transactions for each of the plurality of organizations is recalculated based on the calculation rule for the upper limit number of transactions.

3. The transaction management system according to claim 2, wherein:

4. The node The calculation rule for the upper limit of the number of transactions holds policy information for distributing the upper limit of the number of transactions for each of the plurality of organizations in a proportional manner based on the attributes of the organization.

3. The transaction management system according to claim 2, wherein:

5. The node A smart contract, which is logic that describes the terms of transactions to be conducted between organizations participating in the distributed ledger system, is shared by the participants upon agreement, The calculation rule for the upper limit of the number of transactions holds policy information for changing weighting for each smart contract according to a difference in processing load of the smart contract when calculating the number of past transactions for each of the plurality of organizations.

3. The transaction management system according to claim 2, wherein:

6. The node For each smart contract, an endorsement policy is maintained, which is a consensus standard for forming a consensus on transactions between organizations participating in the distributed ledger system; The policy information regarding the weighting of the smart contract uses the endorsement policy as a basis for the weighting.

6. The transaction management system according to claim 5,

7. The node past transactions in each of the multiple organizations are identified based on the timestamps of the transactions stored in the distributed ledger and information on the organizations to which the transaction executors belong, and the number of such transactions is calculated as the number of past transactions; 2. The transaction management system according to claim 1, wherein:

8. a load balancer that allocates transactions from a higher-level application to the nodes; The load balancer stores a history of transactions from the upper application as a log, When calculating the number of past transactions for each of the plurality of organizations, the node identifies transactions based on timestamps of the transactions and information on organizations to which transaction executors belong, which are stored in the log of the load balancer, and calculates the number of such transactions as the number of past transactions.

2. The transaction management system according to claim 1, wherein:

9. The predetermined node is A gateway node that handles the consensus and approval processes for transactions in response to requests from the host application.

3. The transaction management system according to claim 2, wherein:

10. In a distributed ledger system where a business network is made up of multiple nodes, The node calculates the upper limit of the number of transactions that each of the multiple organizations can issue using calculation rules shared among the nodes, and refuses to accept transactions from any organization whose number of past transactions exceeds the upper limit. A transaction management method characterized by the above.

Images