US-12619984-B2 - Transaction management system and transaction management method

US12619984B2US 12619984 B2US12619984 B2US 12619984B2US-12619984-B2

Abstract

In a transaction management system which is a distributed ledger system in which a business network is formed of a plurality of nodes, the node calculates an upper limit of the number of transactions that can be issued by each of a plurality of organizations according to a calculation rule shared among the nodes, and refuses to accept the transaction from an organization of the organizations of which the number of transactions in past exceeds the upper limit of the number of transactions.

Inventors

Takayuki Nagai
Nao Nishijima
Takahiro SAGARA

Assignees

HITACHI, LTD.

Dates

Publication Date: 20260505
Application Date: 20230307
Priority Date: 20220415

Claims (11)

1 . A transaction management system that is a distributed ledger system in which a business network is formed of a plurality of nodes, each node calculates an upper limit of a number of transactions that can be issued by each of a plurality of organizations according to a calculation rule shared among the nodes, and refuses to accept a transaction from an organization of the organizations of which the number of transactions in past exceeds the upper limit of the number of transactions, the transaction management system comprises a predetermined node that manages configuration information of an organization on a distributed ledger for the organization that can participate in the distributed ledger system, and 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 input to the calculation rule for the upper limit of the number of transactions.
2 . The transaction management system of claim 1 , wherein each node, recalculates the upper limit of the number of transactions for each of the plurality of organizations based on the calculation rule for the upper limit of the number of transactions when the configuration information obtained from the predetermined node is changed.
3 . The transaction management system of claim 1 , wherein each node, holds, in the calculation rule for the upper limit of the number of transactions, policy information for allocating the upper limit of the number of transactions for each of the plurality of organizations according to an attribute of the organization.
4 . The transaction management system of claim 1 , wherein the nodes, share a smart contract, which is logic describing a condition of a transaction to be carried out between organizations participating in the distributed ledger system, upon agreement between participants, and in the calculation rule for the upper limit of the number of transactions, when a number of past transactions for each of the plurality of organizations is calculated, policy information is held that changes for each smart contract according to a difference in a processing load of the smart contract.
5 . The transaction management system of claim 4 , wherein each node, holds an endorsement policy, which is a consensus level when forming a transaction consensus among organizations participating in the distributed ledger system, for each smart contract.
6 . The transaction management system of claim 1 , wherein each node, specifies a transaction as a past transaction in each of the plurality of organizations based on a timestamp of the transaction stored in the distributed ledger and each piece of information of an organization to which a transaction executor belongs, and calculates a number of transactions as the number of past transactions.
7 . The transaction management system of claim 1 , further comprising: a load balancer that allocates transactions from another application to the nodes, wherein the load balancer holds a history of the transactions from the higher-level application as a log, and when the number of past transactions for each of the plurality of organizations is calculated, each node specifies a transaction based on a timestamp of the transaction and each piece of information on an organization to which a transaction executor belongs, which are held in the log of the load balancer, and calculates a number of transactions as the number of past transactions.
8 . The transaction management system of claim 1 , wherein the predetermined node, is a gateway node that acts on behalf of each process of consensus building and approval of a transaction in response to a request from another application.
9 . The transaction management system of claim 1 , wherein the configuration information includes a field for registering the name of each node which belongs to each organization and to which a transaction is to be transmitted by a gateway node and a field for registering an ID of each organization, respectively.
10 . A transaction management method, wherein in a distributed ledger system in which a business network is formed of a plurality of nodes, the method comprising the steps of: calculating, by each node, an upper limit of a number of transactions that can be issued by each of a plurality of organizations according to a calculation rule shared among the nodes, and refusing to accept a transaction from an organization of the organizations of which the number of transactions in past exceeds the upper limit of the number of transactions, managing, by a predetermined node, configuration information of an organization on a distributed ledger for the organization that can participate in the distributed ledger system, and calculating, by each node, 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.
11 . The transaction management method of claim 10 , wherein the configuration information includes a field for registering the name of each node which belongs to each organization and to which a transaction is to be transmitted by a gateway node and a field for registering an ID of the organization, respectively.

Description

CROSS-REFERENCE TO RELATED APPLICATION This application claims priority pursuant to Japanese patent application No. 2022-067734, filed on Apr. 15, 2022, the entire disclosure of which is incorporated herein by reference. BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transaction management system and a transaction management method. 2. Description of Related Art Distributed ledger technology using a block chain (hereinafter, also referred to as BC) has emerged as a technology that replaces a transaction that has traditionally been carried out via a reliable centralized institution such as a financial institution and a government with a direct transaction by Peer to Peer (P2P) between users. Various derivative technologies have been proposed for distributed ledger technology, and they continue to evolve. Main features of a current situation include (1) in a transaction between participants in a distributed ledger, the transaction is finalized through consensus building and approval by (any or specific) participants rather than by a centralized institution, (2) collecting a plurality of transactions as a block, recording them in a distributed ledger called a block chain in a daisy chain, and performing hash calculation on consecutive blocks to make tempering virtually not possible, and (3) enabling all participants to confirm transactions by sharing the same ledger data. From the features described above, 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 a transaction based on a contract. By using a platform (hereinafter, distributed ledger platform) that provides a distributed ledger, it is possible to share information and conduct a transaction among a plurality of entities without being managed by a centralized institution (for example, a consortium in a specific industry or a plurality of companies involved in a supply chain). A block chain or a distributed ledger in which only a computer authorized by a specific organization becomes a participant in a transaction is called a “consortium type”. In this consortium type, there is a management entity that authenticates a participant. Therefore, there is an advantage in that speed of transaction approval can be increased. Based on the advantage, when distributed ledger technology is used within a consortium in a specific industry, a consortium-type distributed ledger platform is generally used. Further, in some distributed ledger platforms, it is becoming possible to manage not only transaction data but also logic that describes a transaction condition in distributed ledgers, in order to be able to handle complex transaction conditions and diverse applications. This logic is called a smart contract (hereinafter, also referred to as SC). Non-Patent Literature 1 “Hyperledger Fabric”, [online], [searched on Dec. 1, 2021], Internet <URL: http://hyperledger-fabric.readthedocs.io/en/latest/>discloses technology related to a distributed ledger platform having the SC execution function described above. On the distributed ledger platform, information (ledger) is shared on a plurality of nodes by accepting a transaction (hereinafter, also referred to as TX) while building consensus at a predetermined consensus level among nodes forming the distributed ledger platform, executing the TX at each node, and storing a result of the TX. It also has an SC execution function that executes a predetermined logic for the TX. Attempts have also been made to improve efficiency of a business process by using a consortium-type BC for an inter-organizational cross work. In this case, a ledger that stores a transaction history of all organizations participating in the BC will be shared among the organizations, which is not necessarily preferable from a viewpoint of maintaining confidentiality of each company. Therefore, it is conceivable that a ledger is shared only by organizations that have a predetermined transaction relationship. Therefore, Non-Patent Literature 1 discloses a concept called “Channel” that logically divides a distributed ledger in response to such a case. The distributed ledger platform in this case is a single distributed ledger platform in which all organizations participate, but is internally logically divided into a plurality of distributed ledger platforms. A set of nodes belonging to this logically divided distributed ledger platform is hereinafter referred to as a “subgroup”. Nodes belonging to the subgroup described above share the distributed ledger only with the nodes in the subgroup, and when executing the TX, execute the SC installed for each subsystem, and update data of the distributed ledger linked to each subgroup. As described above, the consortium-type BC requires that only computers authorized by a specific organization can participate in transa