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 Art

[0002] Conventionally, as a technology for replacing transactions that have been carried out via a reliable central authority such as a financial institution or a government with direct transactions between users by P2P (Peer to Peer), a distributed ledger technology using blockchain (hereinafter also referred to as BC) has emerged. Regarding distributed ledger technology, various derivative technologies have been proposed and continue to evolve. The main current features include: (1) In transactions between participants in the distributed ledger, the transaction is finalized by consensus formation or approval by (any or specific) participants rather than a central authority; (2) Multiple transactions are grouped as blocks and recorded in a distributed ledger called a blockchain in a chain, and by performing hash calculations on consecutive blocks, it is made practically impossible to tamper with; (3) By all participants sharing the same ledger data, it becomes possible to confirm transactions among all participants.

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

[0004] By using a base for providing a distributed ledger (hereinafter referred to as a distributed ledger base), information sharing and transactions can be carried out among multiple entities without the management by a central authority (for example, multiple companies related to a consortium or supply chain in a specific industry, etc.).

[0005] Furthermore, a blockchain or distributed ledger where only computers authorized by a specific organization can participate in transactions is called a "consortium type." In this consortium type, there is a governing body that authenticates the participants. Therefore, it has the advantage of being able to speed up transaction approval.

[0006] Taking these advantages into account, when distributed ledger technology is used within a consortium of a specific industry, a consortium-type distributed ledger infrastructure is generally employed.

[0007] Furthermore, some distributed ledger platforms are becoming capable of managing not only transaction data but also the logic that describes the transaction conditions within the distributed ledger, in order to enable application 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 that has the above-mentioned SC execution function is disclosed in Non-Patent Document 1.

[0008] In a distributed ledger infrastructure, transactions (hereinafter also referred to as TX) are accepted while consensus is reached among the nodes constituting the infrastructure at a predetermined level of agreement. Each node executes the TX and stores the results of the TX, thereby sharing information (ledgers) across multiple nodes. It also includes an SC execution function that executes predetermined logic on the TX.

[0009] Furthermore, attempts are being made to improve the efficiency of business processes by using consortium-type business consolidation (BC) for cross-organizational operations. In this case, a ledger containing the transaction history of all participating organizations would be shared among the organizations, which is not necessarily desirable from the standpoint of maintaining the confidentiality of each business. Therefore, it is conceivable that ledgers may be shared only among organizations that have a predetermined business relationship.

[0010] Therefore, Non-Patent Document 1 discloses a concept called "Channel" for logically partitioning a distributed ledger to address such cases.

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

[0012] Nodes belonging to the aforementioned subgroups share the distributed ledger only among the nodes within that subgroup, and when TX is executed, they run the SC installed for each subsystem to update the data in the distributed ledger associated with 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 infrastructure technology described in Non-Patent Literature 1, client users participating in transactions and the nodes that make up the BC each hold unique digital certificates to identify their affiliated organization and authority.

[0014] Digital certificates are issued by the Certificate Authority (CA) of each organization and are digitally signed by the CA. Furthermore, the CA's own public key is distributed to all organizations in advance, and by using this key to verify the signature written on the certificate, the legitimacy of the certificates for client users and BC participating nodes can be confirmed.

[0015] On the other hand, in recent years, consortium-type business consolidation has been replaced by PaaS (Platform as a Service). Several cloud vendors are emerging that offer services in this form. BIS is referred to as a managed blockchain service (BC service).

[0016] In BC services, to reduce the workload for customers in building their own systems, it is common practice to handle the construction and operation of distributed ledger nodes and certificate authorities on their behalf, while the construction of servers equipped with business applications that access the distributed ledger is carried out by the customer.

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

[0018] The gateway node holds configuration information for the distributed ledger nodes that make up the BC (Business Grid) and acts as an intermediary for processes such as consensus building and approval of TX (Transaction Tokens) in response to requests from business applications. On the other hand, the load balancer distributes the processing load to prevent processing requests from business application servers from being concentrated on a particular gateway node. [Prior art documents] [Non-patent literature]

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

[0020] [Patent Document 1] US20190102423A1 [Overview of the project] [Problems that the invention aims to solve]

[0021] In existing BC services, such as those described in Non-Patent Document 1, multiple organizations share the same computer resources. Therefore, the behavior of each organization can negatively impact the operations of other organizations. In particular, in consortium-type BC, due to the nature of all organizations sharing the same ledger, the number of times that can access the ledger per unit of time tends to be constant regardless of the number of participating organizations. Therefore, if a particular organization attempts to access the system beyond its capacity, it could overload the system and potentially prevent other organizations from accessing it.

[0022] Therefore, an object of the present invention is to provide a technology that makes the resource sharing situation among participating organizations in a BC service appropriate and enables the reliability of the BC service to be maintained well.

Means for Solving the Problems

[0023] The transaction management system of the present invention for solving the above problems is a distributed ledger system in which a business network is constituted by a plurality of nodes, wherein the nodes calculate, with a calculation rule shared among the nodes, the upper limit of the number of transactions that each of the plurality of organizations can issue, and for an organization among the organizations whose past number of transactions exceeds the upper limit of the number of transactions, reject the acceptance of the transaction. In addition, the transaction management method of the present invention in a distributed ledger system in which a business network is constituted by a plurality of nodes is characterized in that the nodes calculate, with a calculation rule shared among the nodes, the upper limit of the number of transactions that each of the plurality of organizations can issue, and for an organization among the organizations whose past number of transactions exceeds the upper limit of the number of transactions, reject the acceptance of the transaction.

Effects of the Invention

[0024] According to the present invention, the resource sharing situation among participating organizations in a BC service can be made appropriate, and the reliability of the BC service can be maintained well.

Brief Description of the Drawings

[0025] [Figure 1] It is a diagram showing a configuration example of a computer system including the transaction management system of the present embodiment. [Figure 2] It is a diagram showing a configuration example of a blockchain included in the distributed ledger of the distributed ledger node in the present embodiment. [Figure 3] It is a diagram showing a configuration example of a blockchain included in the distributed ledger of the distributed ledger node in the present embodiment. [Figure 4] This figure shows an example of the configuration of state information included in the distributed ledger of a distributed ledger node in this embodiment. [Figure 5] This figure shows an example of the configuration of gateway configuration information provided by the load balancer in this embodiment. [Figure 6] This figure shows an example of the configuration of request history information provided by the load balancer in this embodiment. [Figure 7] This figure shows an example of the configuration of the inter-organizational distribution policy contained within the TX restriction condition formulation logic in the initial block of this embodiment. [Figure 8] This figure shows an example of the configuration of the SC weighting policy embedded in the TX restriction condition formulation logic within the initial block in this embodiment. [Figure 9] This figure shows an example of the configuration of the TX restriction meta-conditions included in the TX restriction condition formulation logic within the initial block in this embodiment. [Figure 10] This figure shows an example of the configuration of the TX limit upper limit provided by the distributed ledger node in this embodiment. [Figure 11] This flowchart shows an example of the overall flow of the subgroup creation process executed by the distributed ledger node in this embodiment. [Figure 12] This flowchart shows an example of the overall flow of the transaction execution process performed by the distributed ledger node in this embodiment. [Figure 13] This flowchart shows an example of the overall flow of the subgroup configuration change process executed by the distributed ledger node in this embodiment. [Figure 14] This flowchart shows an example of the overall flow of the TX constraint setting logic included in the initial block in this embodiment. [Figure 15] This is a diagram showing an example of the configuration of the computer system in this embodiment. [Figure 16] This figure shows an example of the blockchain configuration included in the distributed ledger of the distributed ledger node in this embodiment. [Modes for carrying out the invention]

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

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

[0028] Of these, the business application server 40000 consists 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 via a terminal.

[0029] This business application sends the input from the client user via the request issuing unit to the load balancer 30000 on the blockchain platform 45000 via the internet 46000.

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

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

[0032] Furthermore, the blockchain platform 45000 consists of the aforementioned load balancer 30000, plus one or more gateway nodes 10000 and one or more distributed ledger nodes 20000.

[0033] These devices are interconnected 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 with multiple distributed ledger nodes 20000 is assumed. These distributed ledger nodes 20000 are multiple organizations (for example, multiple entities) that constitute the consortium. It is managed by different companies / organizations / vendors.

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

[0036] Similarly, multiple gateway nodes 10000 and business application servers 40000 exist, and it is assumed that multiple organizations will use their respective gateway nodes and business application servers individually. In this embodiment, the gateway node 10000 and the distributed ledger node 20000 are shown as separate devices, but they may be a single integrated node.

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

[0038] In the hardware configuration of the computer in question, the memory is an SSD (Solid State Drive). It consists of appropriate non-volatile memory elements such as hard disk drives, 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 types of data that the programs use for calculations.

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

[0040] Furthermore, the communication unit is a network interface card or similar device 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 Figure 1 is composed of a transaction issuing unit 11000 and node configuration information 12000.

[0042] Furthermore, the distributed ledger node 20000 consists 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] 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 receives a TX from the gateway node 10000 through the functions of the transaction management unit 21300, and the consensus management unit 21100 forms an agreement with other distributed ledger nodes 20000 on whether to accept the TX.

[0045] Furthermore, once consensus is reached regarding the aforementioned TX, the distributed ledger node 20000 will deploy the SC and the deployed SC via the SC execution / management unit 21200. The execution is performed. Distributed ledger node 20000 records the history of the TX and its execution results in distributed ledger 25000.

[0046] Furthermore, the transaction management unit 21300 of the distributed ledger node 20000 accepts TXs in response to requests from each node, such as the gateway node 10000, and provides a function / interface for acquiring and viewing the history information of those TXs.

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

[0048] Furthermore, the subgroup management unit 21400 of the distributed ledger node 2000 provides functions for registering and adding the aforementioned organizations and subgroups.

[0049] Furthermore, in the blockchain platform 45000 of this embodiment, it is assumed that a pair of private and public keys will be used to authenticate participating organizations, sign TXs, and control SC execution privileges.

[0050] Therefore, the private key information of each distributed ledger node 20000 is stored and managed in the transaction management unit 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 management unit 21300 of the distributed ledger node 20000 checks whether the issuer of a transaction (TX) is an authorized and legitimate participant whenever it receives one. The methods for generating public and private key pairs and verifying signatures are publicly known or widely accepted techniques, so no further explanation is provided.

[0052] The distributed ledger 25000, owned by the distributed ledger node 20000, stores and manages smart contracts 26000 related to business operations and the TX results of these smart contracts (SCs). The data structure for the TX results is assumed to be a blockchain 27000 for the history of TXs, and state information 28000 based on the execution results of TXs is held in a table format.

[0053] In this embodiment, the blockchain platform 45000 manages the members participating in the consortium, i.e., organizations and distributed ledger nodes, using the distributed ledger 25000 of each organization. Furthermore, 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 TXs, and control SC execution rights. Certificate and private key information unique to each distributed ledger node 20000 is stored and managed in the participant member management information 29000 of that distributed ledger node 20000. On the other hand, information on each organization's root certificate is shared among all distributed ledger nodes.

[0055] The distributed ledger 25000 stores and manages smart contracts 26000 related to business operations and TX results from the smart contracts. In this embodiment, the data structure for TX results is assumed to be a blockchain 27000 for the history of TXs, and state information 28000 based on the execution results of TXs is held in a table format.

[0056] On the other hand, the load balancer 30000 consists 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 on the blockchain platform 45000 and information on their access destinations.

[0057] Furthermore, when the load balancer 30000 receives information input from the business application 42000, it refers to the gateway configuration information 32000 and forwards it to the gateway node 10000 using round-robin. At that time, the received information and its execution result are stored in the request history information 33000. <Example Data Structure> Figures 2, 3, and 4 show examples of data structures stored in the distributed ledger 25000 provided by the distributed ledger node 20000.

[0058] Figure 2 shows an example of Blockchain 27000, one of the data structures managed by Distributed Ledger 25000. In distributed ledger management using BC, multiple TXs are grouped together as a block, and each block holds the hash value of the previous block, thus managing data in a chain-like fashion. If even one bit of the value of the preceding block changes, the hash values ​​of all subsequent blocks will change, making tampering difficult.

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

[0060] Figure 2 illustrates this sequence of blocks 27010 to 27030 in BC27000. Each of the blocks 27400 to 27040, excluding the initial block 27010 which stores the initial information for the subgroups described later, contains either SC deployment, execution, or TX information.

[0061] Furthermore, each block from 27400 to 27040 contains the hash value 27100 of the previous block and the hash value 27200 generated from the state information described later. With the data structure described above, the history information of subgroup creation, SC deployment, and execution is managed as a chain of data within the BC.

[0062] Initial block 27010 is an example of a block that stores initial information for a subgroup. In this embodiment, the TX27300 of initial block 27010 defines the ID of the subgroup associated with the distributed ledger 25000. Furthermore, it defines the IDs and attributes of the organizations belonging to the subgroup, a list of root certificates, and the names of the distributed ledger nodes 20000 that represent each organization. In addition, the TX restriction condition formulation logic (example) described later is also defined. It includes an executable binary (for example) and a timestamp indicating when the block was created.

[0063] Blocks 27020 and 27030 are examples of blocks that store SC deployment TXs. Of these, deployment TX 27400 contains a contract ID that uniquely identifies the contract, the contract logic (e.g., an executable binary), and the conditions necessary to obtain transaction approval among participating organizations (deployment TX 27410 has a similar structure and is not described).

[0064] Furthermore, the Deploy TX27400 includes a contract input specification that allows the user to understand the function names and arguments of the contract. In this example, the function names "Send" and "Check Balance" are defined for the SC with the ID "SC1," and the logic for these functions is also defined.

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

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

[0067] In this example, the SC function "Send Money" with the ID "SC1" is called, and its arguments are the sending organization ID, receiving organization ID, and amount, with their values ​​being "Org1", "Org3", and "100", respectively.

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

[0069] Figure 3 shows an example of Blockchain 27000, one of the data structures managed by Distributed Ledger 25000.

[0070] Among these, configuration change block 27050 is an example of a block that stores configuration change information for a subgroup. In this embodiment, TX27600 defines the IDs and attributes of the organizations belonging to the subgroup after the configuration change, a list of root certificates, and the names of the distributed ledger nodes 25000 that represent each organization. In addition, it includes the ID, which is a unique identifier for TX, and a timestamp indicating the time the block was generated. Note that the blockchain configuration illustrated in Figure 3 is the same as the configuration in Figure 2, except for the configuration change block 27600.

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

[0072] In this embodiment, it is assumed that the latest state information 28000 is to be held. In this embodiment, a state data area is provided for each function of the SC26000.

[0073] State information 28000 holds ID 28010, which is the identifier of SC26000, the actual SC26000 entity 28020, and the identifier 28030 of the subgroup associated with SC26000.

[0074] As a result, the SC execution / management unit 21200 uses the contract ID and function name as keys. The SC instance can be obtained and executed. Furthermore, the state information 2800 includes an internal table 28040 for holding the execution results of SC26000. SC Execution / Management Unit 21200 updates the contents of this internal table 28040 each time SC is executed.

[0075] The internal table 28040, illustrated in Figure 4, consists of a table called "Owned Amount Data," and the information specified in the TX arguments is overwritten as needed.

[0076] Figure 5 shows an example of the configuration of node configuration information 12000 provided by gateway node 10000.

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

[0078] Figure 6 shows an example of the configuration of the request history information 33000 provided by the load balancer 30000. The request history information 33000 is appended when a request is made from the business application server 40000 to the load balancer 30000.

[0079] This request history information 33000 includes the following components: a field 33010 for registering the date and time 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 attached to the request.

[0080] Figure 7 shows an example configuration of the inter-organizational distribution policy 28000, which is embedded in the TX restriction setting logic of the initial block 27300.

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

[0082] Figure 8 shows an example configuration of the SC weighting policy 28100, which is embedded in the TX constraint setting logic of the initial block 27300.

[0083] The SC weighting policy 28100 includes, as its components, a field 28110 for registering the TX approval conditions for each SC 26000 registered in the deployment transaction 27400, and a field 28120 for registering the score assigned to those TX approval conditions.

[0084] Figure 9 shows an example of the configuration of the TX restriction meta-condition 28200, which is contained within the TX restriction condition formulation logic of the initial block 27300.

[0085] The TX restriction meta condition 28200 includes the following components: a field 28210 for registering the ID of the condition statement included in the TX restriction 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 said TX upper limit calculation formula.

[0086] Figure 10 shows an example of the configuration of TX restriction information 21600 provided by the distributed ledger node 20000.

[0087] The TX restriction condition information 21600 includes the following components: a field 21610 for registering the ID of the condition statement contained 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 assigned to the organization; and a field 21640 for registering the past TX calculation formula corresponding to the TX upper limit. <Flow Example 1> The actual procedure of the transaction management method in this embodiment will be explained below with reference to the diagrams. The various operations corresponding to the transaction management method described below are realized by programs that are read into memory, etc., and executed by each device constituting the blockchain platform 45000 (distributed ledger system), which is the transaction management system (the same applies hereinafter). This program consists of code for performing the various operations described below.

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

[0089] When multiple organizations on the blockchain attempt to create a new subgroup, the BC service administrator, after obtaining prior agreement with the participating organizations, determines the subgroup ID, the IDs of the participating organizations, the root certificates of the participating organizations, the names of the representative nodes of the participating organizations, and the TX restriction condition setting logic, and then inputs this information into the subgroup management unit 21400 by operating a designated terminal.

[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 management unit 21400 distributes the initial block created in the above step to the subgroup management units 21400 of the other distributed ledger nodes 20000 (step 51020).

[0092] The subgroup management units 21400 of each organization that received the above distribution create a distributed ledger 25000, which includes a blockchain starting from the initial block (step 51030).

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

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

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

[0096] Meanwhile, the TX restriction management unit 21500 compares the signature of the client user assigned to the TX with the root certificate in the initial block to verify that it is a legitimate user (step 52020).

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

[0098] As a result of the above comparison, if (A) > (B), the TX restriction management unit 21500 responds to the gateway node 10000 that TX execution is not possible (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 sets of TX upper limits and past TX calculation formulas are defined for the organization in question, the response should be that TX execution is possible only if (A) ≤ (B) in all sets.

[0101] Furthermore, when calculating the number of TX issued over a certain period in the past using the method defined in the past TX calculation formula described above, the TX limit management unit 21500 shall refer to the executed transaction 27500 on BC27000. Alternatively, instead of BC27000, the request history information 33000 provided by the load balancer 30000 may be referred to.

[0102] Gateway node 10000 obtains the necessary authorization for TX execution from each participating organization's distributed ledger node 20000. Management department Issue a transaction to 21500 (step 52060).

[0103] When the transaction management unit 21300 of the distributed ledger node 20000 receives a TX from the gateway node 10000, it verifies the validity of the client user signature attached to the transaction and the certificate sent at the same time by comparing them with the root certificate in the initial block (step 52070).

[0104] Based on the verification described above, if the transaction is valid, distributed ledger node 20000 signs the TX using its private key (step 52080). Distributed ledger node 20000 also 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 management unit 21300 of any one of the distributed ledger nodes 20000 to deliver the TX (step 52100).

[0106] Upon receiving the above request, the transaction management unit 21300 of the distributed ledger node 20000 sends the TX to the transaction distribution unit 21000. The transaction distribution unit 21000 assigns an ID to the TX and requests the distribution of the TX to the representative distributed ledger node 20000 of the other organization recorded in the initial block (step 52110).

[0107] Each organization's representative distributed ledger node 20000 refers to the participating member management information 29000 and sends a TX to other distributed ledger nodes 20000 within its own organization (step 52120). Upon receiving this TX, the SC execution / management unit 22000 of each distributed ledger node 20000 then The received TX is then registered in distributed ledger 25000.

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

[0109] If the content of the TX concerns the execution of a function defined in SC26000, the SC26000 with the contract ID specified in the TX is executed with the specified call function and input arguments. Based on the result, the contents of the distributed ledger 25000 are updated. That is, based on the execution result, the state information 28000 for this SC26000 is updated, and the execution TX is added as the last block of 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 be performed by a separate transaction distribution dedicated node. <Flow Example 3> Figure 13 is a flowchart illustrating an example of the subgroup configuration change process of the subgroup management unit 21400 located in the distributed ledger node 20000. The specific internal processing is shown below.

[0111] When the administrator of the distributed ledger node 2000 of an organization representing a subgroup wishes to add or remove an organization from the subgroup, they operate a designated terminal and input the ID of each participating organization after the change, the root certificate of each participating organization, and the name of the representative node of each participating organization to the subgroup management unit 21400.

[0112] When the subgroup management unit 21400 receives such input, it creates a configuration change block that defines that 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 management unit 2140 distributes the signed configuration change block to the other distributed ledger nodes 20000 within the same subgroup (step 53030).

[0115] Each organization's subgroup management unit 21400 writes the above configuration change block to BC27000 (step 53040).

[0116] Finally, the TX restriction management unit 21500 of each distributed ledger node 20000 sets the TX restriction based on the TX restriction condition setting logic and participating organization information. conditions Recreate information 21600 (step 53050). <Flow Example 4> Figure 14 is a flowchart showing an example of the TX limit condition setting logic included in the initial block 27300. The specific internal processing is shown below.

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

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

[0119] Next, the TX restriction management unit 21500 refers to deployment transaction 27400 on the distributed ledger 25000 and obtains a list of SC26000 on the node (step 54030).

[0120] Finally, the TX restriction management unit 21500 refers to the meta-past TX calculation formula within the TX restriction meta-conditions 28200 and the SC weighting policy to derive the past TX calculation formula for each organization (step 54040).

[0121] The following explanation uses an example of data shown in the diagram. The TX limit management unit refers to the initial block 27300 on the distributed ledger shown in Figure 2 and identifies "org1" and "org2" as organizations constituting a subgroup. Next, it refers to the TX limit calculation formula in the TX limit meta-condition 28200 shown in Figure 9 to calculate the TX limit for each organization and records it in the TX limit value of the TX limit condition information shown in Figure 10.

[0122] Specifically, the organizational types of "org1" and "org2" are "normal" and "a They are "uditors," and according to the inter-organizational distribution policy (Figure 7), their respective scores are "2." The result is "1". Therefore, the TX upper limit values ​​shown in ID1-1 and ID2-1 in Figure 10 can be calculated from the TX upper limit calculation formula shown in ID1 in Figure 9.

[0123] Next, the TX restriction management unit 21500 refers to the deployment block on the distributed ledger 25000 shown in Figure 2 and identifies "SC1" and "SC2" as SCs that constitute 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 records the result 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 "2 or more organizations" and "3 groups," respectively. It is "above weaving", and according to the SC weighting policy (Figure 8), the respective scores are "2", This results in "3". Therefore, the past TX calculation formulas shown in ID1 and ID2-1 of Figure 10 are derived from the meta past TX calculation formula shown in ID1 of Figure 9.

[0126] It should be noted that the above inter-organizational distribution policy and SC weighting policy do not necessarily need to be implemented in their entirety; one of them may be omitted.

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

[0128] If the user sending the TX is affiliated with "org1" and the TX issuance time is "2021 / 12 / 0300:00:30", then according to the distributed ledger 25000 shown in Figure 2, there has been only one TX in the past minute, directed to "SC1". The values ​​calculated from the past TX calculation formulas shown in Figure 10, IDs 1-1 and 2-1, are both "2". Since these values ​​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 exceeds the TX limit, the TX restriction management unit 21500 uniformly rejects all TXs. However, instead of uniformly rejecting them, it is also possible to set different TX limits among multiple SCs based on indicators such as the importance of the SC26000, and restrict them in order from the SC26000 with the lowest priority. Alternatively, it is also possible to restrict only some of the processing within the same SC26000.

[0130] The SC weighting policy shown in Figure 8 assigns scores according to TX approval conditions, but other metrics (for example, the processing load of the logic in the SC26000) can also be used. You can assign scores in this way.

[0131] In the TX limit condition setting logic shown in Figure 14, the TX upper limit is calculated at the organizational level, but it may also be calculated at the client user level under the organization or at the higher-level application level that issues the TX.

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

[0133] In this configuration, the gateway node 10000 consists of a transaction issuing unit 11000, node configuration information 12000, as well as 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 management unit or TX restriction condition information; the TX restriction management unit 13000 and TX restriction condition information 140000 on the gateway node 10000 perform the same role. Everything else is the same as shown in Figure 1.

[0135] Figure 16 shows an example of another form of 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 containing a deployment TX for SC26000. In this example, deployment TX27400 includes a contract ID that uniquely identifies SC26000, the logic of SC26000 (e.g., an executable binary), and the conditions necessary for obtaining TX approval among participating organizations. It also includes a contract input specification that allows users to understand the function names and arguments of SC26000.

[0137] In this example, the function name "TX Upper Limit Calculation" is defined for SC26000 with the ID "SC0," and the function's logic is also defined. Furthermore, this function's logic includes the TX limit condition formulation logic shown in Figure 14, the inter-organizational distribution policy 28000, the SC weighting policy 28100, and the TX limit meta-condition 28200. Everything else is equivalent to what is shown in Figures 2 and 3.

[0138] As described above, by using the present invention, it is possible to guarantee a certain minimum number of accesses to the distributed ledger per unit of time for each organization participating in the BC service. On the other hand, by providing the customer with the access limit management function using the above means, the BC service vendor can ensure the reliability of the BC service in terms of performance and improve the value of the service.

[0139] Although the best mode for carrying out the present invention has been described in detail above, the present invention is not limited thereto and can be modified in various ways without departing from its essence.

[0140] According to this embodiment, it becomes possible to guarantee a certain minimum number of ledger accesses per unit of time for each organization participating in the BC service. On the other hand, the BC service vendor can provide customers with an access limit management function, thereby ensuring the reliability of the BC service in terms of performance and improving the value of the service. This will allow for appropriate resource sharing among participating organizations and enable the reliable operation of the BC service.

[0141] The following will be made clear from the description herein: that is, in the transaction management system of this embodiment, The aforementionedThe distributed ledger system may further include predetermined nodes that manage the configuration information of organizations that can participate in the distributed ledger, and these multiple nodes calculate the transaction limit for each organization by applying the configuration information obtained from the predetermined nodes as input to the rules for calculating the transaction limit.

[0142] This allows for the calculation of the transaction limit, taking into account the number of participants in the distributed ledger system, which serves as the business platform, and any changes in that number. Ultimately, this enables more appropriate resource sharing among participating organizations in the BC service, thereby maintaining a higher level of reliability for the BC service.

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

[0144] According to this, even if there are changes in the participants in the distributed ledger system, which serves as the business platform, it is possible to respond appropriately and dynamically calculate the transaction limit. In turn, this makes the resource sharing among participating organizations in the BC service more appropriate and helps maintain the reliability of the BC service even better.

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

[0146] This allows for the management of transaction limits based on the characteristics and importance of each organization. Ultimately, this enables more appropriate resource sharing among participating organizations in the BC service, thereby maintaining better reliability for the BC service.

[0147] Furthermore, in the transaction management system of this embodiment, the node may share smart contracts, which are logic describing the conditions for transactions to be conducted between organizations participating in the distributed ledger system, with the agreement of the participants, and in the rules for calculating the upper limit of the number of transactions, it may maintain policy information that changes the weighting of each smart contract according to the difference in processing load of the smart contracts when calculating the number of past transactions for each of the multiple organizations.

[0148] This allows for control over the transaction limit based on the processing load of smart contracts. Ultimately, this enables more appropriate resource sharing among participating organizations in the BC service, thereby maintaining better reliability for the BC service.

[0149] Furthermore, in the transaction management system of this embodiment, each node maintains an endorsement policy for each smart contract, which is the level of agreement when reaching a consensus on a transaction among the organizations participating in the distributed ledger system, and in the policy information regarding the weighting of the smart contracts, the basis for the weighting is stated as follows It may also be stated that the following endorsement policy will be used.

[0150] This allows for precise management of the transaction limit, taking into account not only the processing load of the smart contracts mentioned above, but also the characteristics of endorsements. Ultimately, this enables more appropriate resource sharing among participating organizations in the BC service, thereby maintaining the reliability of the BC service more effectively.

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

[0152] According to this, it becomes possible to identify transactions by grouping them together, such as transactions issued by a specific organization during the most recent specified period, and to use this information appropriately in calculating the transaction limit. In turn, this will allow for more appropriate resource sharing among participating organizations in the BC service, and enable the maintenance of better reliability for the BC service.

[0153] Furthermore, the transaction management system of this embodiment may further include a load balancer that allocates transactions from higher-level applications to the nodes, wherein the load balancer maintains a log of transaction history from the higher-level applications, and when the nodes calculate the number of past transactions for each of the multiple organizations, they identify the transactions based on the transaction timestamp and the organization to which the transaction executor belongs, which are maintained in the load balancer's log, and calculate the number of such transactions as the number of past transactions.

[0154] This allows for the efficient and accurate calculation of past transaction counts using a load balancer. Ultimately, this enables more appropriate resource sharing among participating organizations in the BC service, thereby maintaining better reliability for the BC service.

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

[0156] According to this, the gateway node responsible for actual transaction issuance will manage node configuration information, which can then be used for timely management of the transaction limit. In turn, this will allow for more appropriate resource sharing among participating organizations in the BC service, thereby maintaining better reliability of the BC service. [Explanation of symbols]

[0157] 10,000 gateway nodes 11000 Transaction Issuance Department 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 Information 25,000 Distributed Ledger 26,000 smart contracts 27,000 Blockchains 28000 State Information 30000 Load Balancer 31000 Request Distribution Unit 32000 Gateway Configuration Information 33000 Request History Information 35000 HSM 40000 Business application servers 41000 Request Issuance Department 42,000 Business Applications 45000 Cloud infrastructure (transaction management system, distributed ledger system) 46000 Internet

Claims

1. A distributed ledger system in which a business network is composed of multiple nodes, The aforementioned node calculates the maximum number of transactions that each of the multiple organizations can issue using a calculation rule shared among the nodes, and rejects the acceptance of transactions from any organization whose past transaction count exceeds the aforementioned transaction limit. A transaction management system is provided that features the following characteristics.

2. The aforementioned distributed ledger system further includes a predetermined node that manages the configuration information of an organization that can participate in the distributed ledger, The aforementioned multiple nodes calculate the transaction limit for each organization by applying the configuration information obtained from the predetermined node as input to the transaction limit calculation rule. A transaction management system according to claim 1, characterized in that...

3. The aforementioned node is When a change occurs in the configuration information obtained from the predetermined node, the transaction limit for each of the multiple organizations is recalculated based on the transaction limit calculation rule. A transaction management system according to claim 2, characterized in that...

4. The aforementioned node is The transaction limit calculation rule maintains policy information that allocates the transaction limit for each of the multiple organizations based on the attributes of that organization. A transaction management system according to claim 2, characterized in that...

5. The aforementioned node is A smart contract, which is the logic describing the terms of a transaction to be conducted between organizations participating in the aforementioned distributed ledger system, is shared by agreement among the participants. In the transaction count limit calculation rule, when calculating the past transaction count for each of the multiple organizations, policy information is maintained that changes the weighting for each smart contract according to the difference in processing load of the smart contracts. A transaction management system according to claim 2, characterized in that...

6. The aforementioned node is Each smart contract maintains an endorsement policy, which is the level of agreement used when reaching a consensus on a transaction among the organizations participating in the distributed ledger system. In the policy information regarding the weighting of the smart contract, the endorsement policy is used as the basis for the weighting. A transaction management system according to claim 5, characterized in that...

7. The aforementioned node is For each of the aforementioned multiple organizations, past transactions are identified based on the timestamp of the transaction stored in the distributed ledger and the information of the organization to which the transaction executor belongs, and the number of such transactions is calculated as the number of past transactions. A transaction management system according to claim 1, characterized in that...

8. It further includes a load balancer that allocates transactions from higher-level applications to the aforementioned nodes, The load balancer maintains a log of the transaction history from the upstream application. When the node calculates the number of past transactions for each of the multiple organizations, it identifies the transactions based on the transaction timestamp and the organization to which the transaction executor belongs, which are stored in the load balancer's log, and calculates the number of such transactions as the number of past transactions. A transaction management system according to claim 1, characterized in that...

9. The predetermined node is, It is a gateway node that, in response to requests from higher-level applications, handles the processes of transaction consensus formation and approval. A transaction management system according to claim 2, characterized in that...

10. In a distributed ledger system where a business network is composed of multiple nodes, The aforementioned node calculates the maximum number of transactions that each of the multiple organizations can issue using a calculation rule shared among the nodes, and rejects the acceptance of transactions from organizations whose past transaction count exceeds the aforementioned transaction limit. A transaction management method characterized by the following:

Images