Information processing method, information processing device, and program

Abstract

This information processing method acquires data to be included in transaction data stored in a distributed ledger (114a), acquires a digital signature generated by a signature method that is selected according to the data from among a plurality of signature methods (S10), and transmits transaction data including the data and the digital signature (S20).

Description

Information processing method, information processing device, and program

[0001] The present disclosure relates to an information processing method, an information processing device, and a program.

[0002] Transaction data recorded using a distributed ledger system such as a blockchain includes not only the transaction itself but also a digital signature (also simply referred to as a signature) assigned by the generator of the transaction data (see, for example, Patent Document 1).

[0003] Patent No. 7550941

[0004] However, generating and verifying a signature requires a certain amount of processing time. Using a highly secure signature method increases the time required for signature generation and signature verification, thereby reducing the throughput of the distributed ledger system. On the other hand, using a signature method with short signature generation and signature verification times makes it easier for attackers to tamper with transaction data or generate fraudulent transaction data, thereby reducing the security of the distributed ledger system. In other words, there is a trade-off between throughput and security.

[0005] Therefore, the present disclosure provides an information processing method, an information processing device, and a program that can improve throughput while maintaining the security of a distributed ledger system.

[0006] An information processing method according to one aspect of the present disclosure obtains data to be included in transaction data to be stored in a distributed ledger, obtains a digital signature generated using a signature method selected from a plurality of signature methods according to the data, and outputs transaction data including the data and the digital signature.

[0007] An information processing device according to one aspect of the present disclosure includes a first acquisition unit that acquires data to be included in transaction data to be stored in a distributed ledger, a second acquisition unit that acquires a digital signature generated using a signature method selected from a plurality of signature methods according to the data, and a transmission unit that transmits transaction data including the data and the digital signature.

[0008] A program according to one aspect of the present disclosure is a program for causing a computer to execute the above-described information processing method.

[0009] According to one aspect of the present disclosure, it is possible to realize an information processing method and the like that can improve throughput while maintaining the security of a distributed ledger system.

[0010] FIG. 1 is a diagram illustrating a configuration of an information processing system according to embodiment 1. FIG. 2 is a block diagram illustrating a functional configuration of a ledger server according to embodiment 1. FIG. 3 is a sequence diagram illustrating the operation of an information processing system according to embodiment 1. FIG. 4A is a sequence diagram illustrating the operation of generating transaction data including a signature of a signature method not stored in a ledger server according to embodiment 2. FIG. 4B is a sequence diagram illustrating a continuation of the operation illustrated in FIG. 4A. FIG. 5 is an explanatory diagram illustrating the data structure of a blockchain, which is an example of a distributed ledger. FIG. 6 is an explanatory diagram illustrating the data structure of transaction data. FIG. 7 is an explanatory diagram illustrating transaction data related to the execution of a smart contract. FIG. 8 is a flowchart illustrating processing related to the execution of a smart contract. FIG. 9 is an explanatory diagram illustrating the structures of NFTs and metadata.

[0011] (Background to the Invention of the Present Disclosure) Before describing the present disclosure, the background to the invention of the present disclosure will be described.

[0012] As described in the "Problem to be Solved by the Invention" above, there is a trade-off between the throughput and security of a distributed ledger system. For example, if the key length of the cryptographic key used to generate a signature is increased from the perspective of security, the time required to generate the signature and for miners to verify the signature will increase. This increases the time required to generate one block, reducing the throughput of the ledger system.

[0013] On the other hand, if the key length is reduced to shorten the time required to generate and verify a signature, it becomes easier for attackers to generate fraudulent signatures, thereby reducing the security of the distributed ledger system.

[0014] Therefore, the inventors of the present application conducted extensive research into information processing methods that can improve the throughput of a distributed ledger system while maintaining its security, and discovered the information processing methods described below.

[0015] An information processing method according to a first aspect of the present disclosure obtains data to be included in transaction data to be stored in a distributed ledger, obtains a digital signature generated using a signature method selected from a plurality of signature methods according to the data, and outputs transaction data including the data and the digital signature.

[0016] This makes it possible to select an appropriate signature method from among multiple signature methods depending on the data (also referred to as the data body) included in the transaction data. For example, by selecting a signature method that can improve throughput depending on the data body, it is possible to improve the throughput of the ledger system. Furthermore, for example, by selecting a signature method that can maintain security depending on the data body, it is possible to maintain the security of the distributed ledger. Therefore, according to the information processing method, it is possible to improve throughput while maintaining the security of the distributed ledger.

[0017] Also, for example, the information processing method according to the second aspect may be the information processing method according to the first aspect, in which the selected signature method is a signature method selected from the plurality of signature methods according to the asset value of the asset information included in the data.

[0018] This makes it possible to appropriately select a signature scheme that improves throughput or a signature scheme that maintains security depending on the asset information contained in the data body.

[0019] Furthermore, for example, the information processing method according to the third aspect may be the information processing method according to the second aspect, in which, when the asset value included in the data body of the transaction data exceeds a threshold, the selected signature method is more secure than when the asset value is equal to or less than the threshold.

[0020] This means that if the asset value contained in the data body is high, a signature that requires longer verification time will be assigned, allowing assets to be protected more securely and reducing the risk of the ledger system being attacked.

[0021] Furthermore, for example, an information processing method according to a fourth aspect may be the information processing method according to the third aspect, in which the signature scheme with higher security includes using an encryption key with a longer key length.

[0022] This allows assets to be protected more safely by using an encryption key with a longer key length.

[0023] Furthermore, for example, the information processing method according to the fifth aspect may be the information processing method according to the third or fourth aspect, in which the more secure signature scheme includes using a signature algorithm that is more difficult to decipher by a computer.

[0024] This allows assets to be effectively protected by using a signature algorithm with higher difficulty.

[0025] Furthermore, for example, an information processing method according to a sixth aspect may be an information processing method according to any one of the second to fifth aspects, and in obtaining the digital signature, a signature method for generating a signature for the data body may be selected from the plurality of signature methods based on the asset value, and the digital signature may be generated using the selected signature method.

[0026] This allows the device itself to generate a signature, making it easy to obtain the signature.

[0027] Also, for example, an information processing method according to a seventh aspect is an information processing method according to any one of the second to sixth aspects, and in obtaining the digital signature, the digital signature generated using a signature method selected from the plurality of signature methods based on the asset value may be obtained via a network.

[0028] This makes it possible to obtain a signature in a signature method that is not supported by the device itself, and also reduces the amount of processing required for obtaining a signature in the device itself.

[0029] Furthermore, for example, an information processing method according to an eighth aspect may be the information processing method according to the seventh aspect, in which the obtaining of the digital signature involves obtaining a first signature generated by operating a first smart contract among a plurality of smart contracts, and obtaining a second signature generated by operating a second smart contract among the plurality of smart contracts that is identified based on the first signature, and the transmitting of the transaction data involves transmitting the transaction data that includes the first signature and the second signature as the digital signature.

[0030] This includes a second signature by a second smart contract that cannot be arbitrarily selected by the generator of the transaction data, which prevents the generator from committing fraud, such as sending fraudulent transaction data, thereby improving the security of the ledger system.

[0031] Also, for example, an information processing method according to a ninth aspect may be an information processing method according to the eighth aspect, in which identification information is assigned to each of the plurality of smart contracts, and the identification information of the second smart contract among the plurality of smart contracts may be closest to the hash value of the first signature.

[0032] In this way, the use of hash values ​​can prevent the generator of transaction data from committing fraud.

[0033] Furthermore, for example, an information processing method according to a tenth aspect may be the information processing method according to the eighth or ninth aspect, further comprising verifying each of the first signature and the second signature in the mining process, and generating a block including the transaction data if the verification of each of the first signature and the second signature is successful.

[0034] This allows verification of the second signature generated by the second smart contract, which cannot be arbitrarily selected by the generator of the transaction data, thereby preventing fraudulent transaction data from being stored in a block due to collusion between the generator of the transaction data and the smart contract, thereby improving the security of the distributed ledger system.

[0035] Also, for example, an information processing device according to the eleventh aspect includes a first acquisition unit that acquires data to be included in transaction data to be stored in a distributed ledger, a second acquisition unit that acquires a digital signature generated using a signature method selected from a plurality of signature methods according to the data, and a transmission unit that transmits transaction data including the data and the digital signature.

[0036] This provides the same effect as the above-described information processing method.

[0037] A program according to a twelfth aspect is a program for causing a computer to execute the information processing method according to any one of the first to tenth aspects.

[0038] This provides the same effect as the above-described information processing method.

[0039] These general or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or as any combination of the system, method, integrated circuit, computer program, or recording medium. The program may be pre-stored in the recording medium, or may be supplied to the recording medium via a wide area communication network including the Internet.

[0040] Hereinafter, the embodiments will be specifically described with reference to the drawings.

[0041] The embodiments described below are all comprehensive or specific examples. The numerical values, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components not described in independent claims are described as optional components.

[0042] Furthermore, each figure is a schematic diagram and is not necessarily an exact illustration. Therefore, for example, the scales of the figures do not necessarily match. Furthermore, in each figure, substantially the same components are given the same reference numerals, and redundant explanations are omitted or simplified.

[0043] Furthermore, in this specification, numerical values ​​and numerical ranges are not expressions that express only the strict meaning, but are expressions that mean that they also include a substantially equivalent range, for example, a difference of about several percent (or about 10%).

[0044] Furthermore, in this specification, ordinal numbers such as "first" and "second" do not refer to the number or order of components unless otherwise specified, but are used for the purpose of avoiding confusion and distinguishing between components of the same type.

[0045] First Embodiment An information processing method according to the present embodiment will be described below with reference to FIGS.

[0046] [1. Configuration of Information Processing System] First, the configuration of an information processing system according to this embodiment will be described with reference to Fig. 1 and Fig. 2. Fig. 1 is a diagram showing the configuration of an information processing system 10 according to this embodiment. Note that Fig. 1 shows an exemplary functional configuration of the information processing system 10, and the functional configuration of the information processing system 10 is not limited to that shown in Fig. 1.

[0047] As shown in Figure 1, the information processing system 10 includes ledger servers 100a, 100b, and 100c, which are communicatively connected via a communication network. The ledger servers 100a, 100b, and 100c constitute a distributed ledger system (also called a ledger system). In other words, each of the ledger servers 100a, 100b, and 100c is one of multiple participating nodes (nodes) that make up the ledger system.

[0048] A ledger system is a system that stores information using a distributed ledger. Various data are stored in the distributed ledger of the ledger system. The data stored in the distributed ledger of the ledger system may be, for example, a token generation history and a token modification history. The token may be a non-fungible token (NFT) or a fungible token (FT). The NFT may be associated with an object in the real world. The FT may be virtual currency or legal tender. The information included in the token is not particularly limited, and may be information related to a transaction of goods or the like, or information related to the transfer of virtual currency or legal tender (hereinafter collectively referred to as coins). Information related to the transfer of coins includes, for example, the amount of coins to be transferred, the type of coin to be transferred, and information indicating the transfer source and destination. The above information may be included in the transaction data as the data body (also simply referred to as data).

[0049] The ledger system can execute processes using smart contracts (SCs) using a distributed ledger, and can generate NFTs and perform processes related to updating NFTs using smart contract processes.

[0050] The ledger server 100a is a computer server that holds and manages a distributed ledger. The ledger server 100a holds the distributed ledger and updates it while synchronizing with other ledger servers (specifically, ledger servers 100b and 100c).

[0051] The ledger servers 100b and 100c are similar to the ledger server 100a, but operate independently of the ledger server 100a.

[0052] Hereinafter, the ledger servers 100a, 100b, and 100c will also be referred to as ledger servers 100a, etc. (ledger servers 100a to 100c). Furthermore, the storage devices 101a, 101b, and 101c will also be referred to as storage devices 101a, etc. (storage devices 101a to 101c).

[0053] The ledger server 100a etc. is connected to the storage device 101a etc. The ledger server 100a etc. may be connected to the storage device 101a etc. via the communication network 300, or may include the storage device 101a etc. internally. The storage device 101a etc. has a distributed ledger in which transaction data and blocks of the blockchain are electronically recorded.

[0054] The ledger system manages a distributed ledger using a blockchain. The number of ledger servers that make up the ledger system is not limited to three, and may be one or more.

[0055] In this embodiment, the ledger server 100a is a server (miner terminal) managed by a miner who executes the mining process of the blockchain, and the ledger server 100b is a server (user terminal) managed by a user who transmits transaction data to the miner terminal. Note that the user terminal may be a server that does not hold a distributed ledger, and the server may be connected to the ledger server 100b that holds a distributed ledger via a communication network.

[0056] The information processing system 10 executes a process to improve the throughput of the ledger system while maintaining its security. Specifically, each ledger server in the information processing system 10 executes a process to dynamically change the signature method used to generate a signature to be assigned to a transaction, depending on the content of the data body included in the transaction data. Examples of changing the signature method include changing the key length or changing the signature method (also called the signature algorithm), but the following description will mainly focus on changing the key length.

[0057] For example, each ledger server uses a key length larger than the default key length when the amount of coins to be transferred for the data body is greater than or equal to a predetermined value, and uses the default key length when the amount of coins is smaller than the predetermined value.

[0058] There are various signature algorithms for generating signatures, and each signature algorithm has multiple key lengths. Examples of signature algorithms include RSA (Rivest-Shamir-Adleman) and ECDSA (Elliptic Curve Digital Signature Algorithm).

[0059] Each signature algorithm can have multiple key lengths. In the case of RSA, key lengths are 512 bits, 1024 bits, 2048 bits, 4096 bits, etc. In the case of ECDSA, key lengths are 256 bits, 521 bits, etc. Note that the signature algorithms and key lengths are not limited to those exemplified above.

[0060] The components of the ledger server 100a and the like will be described below with reference to Fig. 2. Fig. 2 is a block diagram showing the functional configuration of the ledger server 100b according to this embodiment. Since the configurations of the ledger servers 100a and 100c are similar to that of the ledger server 100b, the ledger server 100b will be used as an example for the description. Note that Fig. 2 shows an exemplary functional configuration of the ledger server 100b, and the functional configuration of the ledger server 100b is not limited to that shown in Fig. 2.

[0061] 2, the ledger server 100b includes a communication unit 111, a ledger management unit 112, an execution unit 113, a storage unit 114, and a transaction data generation unit 115. At least some of the functional units included in the ledger server 100b are realized by a processor (e.g., a CPU) included in the ledger server 100b executing a program using a memory.

[0062] The communication unit 111 is a communication interface communicatively connected to the communication network 300. The communication unit 111 may be a communication interface of a wired communication standard (e.g., Ethernet (registered trademark) or the like), or may be a communication interface of a wireless communication standard (e.g., Wi-Fi (registered trademark) or the like, or a mobile communication system (3G, 4G, 5G, or the like)). The communication unit 111 is used when a functional unit included in the ledger server 100b communicates with another device. For example, the communication unit 111 is used when a functional unit included in the ledger server 100b communicates with either the ledger server 100a or 100c. The communication unit 111 may be configured to include, for example, a communication circuit (or a communication module).

[0063] The ledger management unit 112 processes the distributed ledger 114b and transaction data. Specifically, when the ledger management unit 112 receives transaction data including command information for executing a smart contract and a signature, it verifies the digital signature included in the received transaction data and controls storage of successfully verified transaction data in the distributed ledger 114b held by the storage unit 114. When storing transaction data in the distributed ledger 114b, the ledger management unit 112 generates a block including the transaction data to be stored, and can control storage of the generated block in the distributed ledger 114b when consensus is reached with the ledger management units of the other ledger servers, ledger servers 100a and 100c.

[0064] The execution unit 113 executes information processing. The execution unit 113 can execute information processing by, for example, executing a smart contract using the distributed ledger 114b. As examples of information processing, the execution unit 113 executes information processing related to NFTs, such as processing to generate NFTs, processing related to coin transfers, and processing related to payment of mining rewards. Note that when the execution unit 113 does not use a smart contract, it executes information processing according to normal program code.

[0065] Note that smart contracts stored in the distributed ledger are executed when transaction data containing command information for executing the smart contract is stored in the distributed ledger. On the other hand, if transaction data containing a conventional signature is not stored in the distributed ledger, the command information for executing the smart contract included in the transaction is also not stored in the distributed ledger, and the smart contract is not executed.

[0066] The memory unit 114 is a storage device that stores information. The memory unit 114 stores the distributed ledger 114b. The memory unit 114 also stores the signature algorithm used to generate a signature. Each signature algorithm may have multiple key lengths. In other words, the memory unit 114 stores information that enables the key length to be dynamically changed for one signature algorithm. The memory unit 114 is realized by a non-volatile storage device (SSD or HDD) or the like.

[0067] The distributed ledger 114b stores data having a structure in which blocks, each containing one or more transaction data, are linked in a chain. The one or more transaction data stored in the distributed ledger 114b include transaction data containing the contract code of a smart contract, transaction data containing command information for executing a smart contract, or transaction data containing other information. In this embodiment, the distributed ledger 114b is a blockchain.

[0068] The transaction data generation unit 115 generates transaction data to be stored in the blockchain. For example, the transaction data generation unit 115 generates transaction data including a blockchain address held by a user, a data body to be managed in the blockchain, and a signature. Here, the encryption method used for the signature (e.g., the key length of the encryption key) is dynamically changed depending on the content of the data body included in the transaction. The transaction data generation unit 115 may also generate transaction data including the contract code of a smart contract and instruction information for executing the smart contract. Storing transaction data including the contract code of a smart contract in the distributed ledger allows the smart contract to be deployed. Storing transaction data including instruction information for executing the smart contract in the distributed ledger allows the smart contract stored in the distributed ledger to be executed.

[0069] [2. Operation of Information Processing System] Next, the operation of the information processing system 10 configured as described above will be described with reference to FIGS. 3 to 4B. FIG. 3 is a sequence diagram showing the operation (information processing method) of the information processing system 10 according to this embodiment. FIG. 3 shows processing for transaction data for transferring coins (hereinafter referred to as asset remittance Tx). The data body included in the transaction data (hereinafter referred to as Tx) is information indicating the amount of coins to be transferred (hereinafter referred to as transferred coin amount).

[0070] As shown in FIG. 3, the transaction data generation unit 115 of the ledger server 100b generates an asset remittance Tx including a signature with a key length corresponding to the amount of transferred coins (S10). Here, the signature is generated using an encryption key with a key length corresponding to the amount of transferred coins. For example, in step S10, a data body (such as the amount of transferred coins) including information to be stored in the distributed ledger 114b is acquired, a signature (digital signature) generated using a signature method selected from multiple signature methods according to the data body is acquired, and an asset remittance Tx including the acquired signature is generated. In this embodiment, the signature method is selected according to the amount of transferred coins. The data body is an example of data to be included in the transaction data.

[0071] The information indicating the transfer of coins is asset information, and the amount of transferred coins is an example of the asset value of the asset information. The communication unit 111 also functions as a first acquisition unit and a second acquisition unit.

[0072] The transaction data generation unit 115 selects a key length corresponding to the size of the amount of transferred coins from among multiple key lengths for one signature algorithm, and generates a signature using the selected key length. Correspondence information indicating the correspondence relationship (first rule) between the amount of transferred coins and key lengths is stored in the distributed ledger 114b, and the transaction data generation unit 115 compares the correspondence information with the amount of transferred coins to be transferred in the asset transfer Tx, to identify the key length of the private key for generating a signature.

[0073] The correspondence information includes information for selecting a signature scheme that is more secure when the amount of transferred coins exceeds a predetermined amount (an example of a threshold) compared to when the amount of transferred coins is equal to or less than the predetermined amount. "More secure" means that it takes more time to verify (or decrypt) the signature, for example, the length of the private key is longer.

[0074] For example, the correspondence information may include information indicating that a private key with a 384-bit key length is used when the amount of transferred coins exceeds 1 BTC (BTC: Bitcoin currency unit), and that a private key with a 256-bit key length is used when the amount of transferred coins is 1 BTC or less.For example, the correspondence information may include information indicating that a signature using secp384r1 (384-bit key length elliptic curve signature) is required when the amount of transferred coins exceeds 1 BTC, and that a signature using secp256r1 (256-bit key length elliptic curve signature) is required when the amount of transferred coins is 1 BTC or less.

[0075] The larger the key length, the longer it takes to generate a signature, but the longer the calculation time required to tamper with the signature. As mentioned above, a Tx with a small amount of transferred coins, which offers little benefit to an attacker, is signed with a small key length, and a Tx with a large amount of transferred coins is signed with a large key length. This makes it possible to effectively improve the security of the distributed ledger system, as attacks by attackers can be more mitigated with a larger amount of transferred coins Tx. Furthermore, the smaller the amount of transferred coins, the shorter the signature generation and signature verification times, which can improve the throughput of the distributed ledger system. This allows an appropriate signature method to be selected depending on the content of the transaction data, thereby improving throughput while maintaining the security of the distributed ledger system.

[0076] The correspondence information may further include information indicating the correspondence relationship (second rule) between the amount of transferred coins and the key length of the public key used to verify the signature.

[0077] The key length used for the signature is information that cannot be known to the ledger server 100a that performs mining. Therefore, the transaction data generation unit 115 may include additional information in the transaction data to specify the key length of the encryption key (e.g., public key) used for signature verification. The transaction data generation unit 115 may include additional information in the transaction data, for example, when the correspondence information is not stored in the distributed ledger 114b or when the correspondence information does not include the second rule. The additional information may be the key length of the public key corresponding to the private key used by the transaction data generation unit 115, or the key length of the private key.

[0078] Note that "higher security" may mean, for example, using a signature algorithm that is more difficult to decrypt by a computer. "Higher difficulty" means that it takes longer to decrypt the signature, and for example, a quantum-resistant signature algorithm is more difficult than a quantum-resistant signature algorithm.

[0079] Next, the communication unit 111 transmits the asset remittance Tx (S20). That is, the communication unit 111 generates transaction data including the data body for asset remittance and a digital signature. The asset remittance Tx is stored in the storage device 101a. It can also be said that the asset remittance Tx is stored in a Tx pool, which stores transaction data before it is stored in a block. The Tx pool is a temporary list that stores transaction data and is held by each node in the ledger system. It can also be said that the Tx pool exists so that miners can select Txs to mine. The communication unit 111 functions as a transmission unit.

[0080] In addition, the asset transfer Tx is not limited to being transmitted from a node constituting the information processing system 10, but may also be transmitted from an external information processing device that is communicatively connected to a node of the information processing system 10.

[0081] Next, the communication unit of the ledger server 100a acquires one or more transaction data from the storage device 101a (S30). Assume that the acquired one or more transaction data includes an asset remittance Tx.

[0082] Next, the ledger management unit of the ledger server 100a determines whether the asset remittance Tx is signed using a signature method (here, key length) corresponding to the amount of transferred coins (S40). The determination in step S40 is a process for determining whether to include the asset remittance Tx in a block. The distributed ledger of the ledger server 100a may store correspondence information indicating the correspondence between the amount of transferred coins and key lengths. The ledger management unit may perform the determination in step S40 by identifying the amount of transferred coins included in the correspondence information that matches the amount of transferred coins included in the asset remittance Tx, and further identifying the key length corresponding to the identified amount of transferred coins.

[0083] For example, if the asset remittance Tx includes the additional information, the ledger management unit of the ledger server 100a may verify the signature using a public key with a key length specified by the additional information. Specifically, the ledger management unit may verify the signature by inputting the public key and the signature as arguments to a verification function of the signature method that generated the signature and calculating the output. As a verification result, the ledger management unit may output information indicating whether the verification was successful or unsuccessful. Furthermore, if correspondence information indicating the correspondence between the amount of transferred coins and key lengths is stored in the distributed ledger 114a, the ledger management unit of the ledger server 100a may identify the key length of the public key to be used for verification from the amount of transferred coins included in the asset remittance Tx and the correspondence information, and verify the signature using a public key with the identified key length.

[0084] Next, if the ledger management unit of the ledger server 100a determines that the asset remittance Tx is not signed with a key length corresponding to the amount of transferred coins in Tx (No in S40), it creates a block that does not include the asset remittance Tx (S50). This makes it possible to prevent transaction data that is likely to be targeted by attackers, such as transaction data with a large amount of transferred coins (e.g., more than a threshold value) and signed with a signature scheme with a small key length that is easily deciphered, from being stored in a block.

[0085] Next, the execution unit of the ledger server 100a notifies the ledger server 100b (i.e., the user) of information that the asset transfer Tx has not been stored in the block (S60). The notification content may be information indicating that it has been determined that the asset transfer Tx should not be stored in the block, information indicating that the amount of transferred coins does not correspond to the signature method (here, the key length), or information indicating the signature method to be used (here, the key length).

[0086] Furthermore, if the ledger management unit of the ledger server 100a determines that the asset transfer Tx is signed with a key length corresponding to the amount of transferred coins in Tx (Yes in S40), it creates a block including the asset transfer Tx (S70). This allows only transaction data with signatures that are more difficult to decipher to be stored in a block when the amount of transferred coins is large (e.g., greater than a threshold). This reduces attacks by attackers. Therefore, it is possible to effectively improve the reliability of the information processing system 10. Note that being more difficult to decipher means that it takes longer to decipher.

[0087] Next, the ledger management unit of the ledger server 100a sends the created block to the distributed ledger 114a (S80), thereby storing the block in the distributed ledger 114a.

[0088] (Embodiment 2) Below, a proxy signing method when a node of the information processing system 10 needs to sign using a signature method that does not have a signature verification function will be described with reference to Figures 4A and 4B. Figure 4A is a sequence diagram showing the operation (information processing method) of generating transaction data including a signature using a signature method that is not stored in the ledger server 100b according to this embodiment. Figure 4B is a sequence diagram showing a continuation of the operation (information processing method) shown in Figure 4A. Note that the following description will focus on differences from embodiment 1, and descriptions of content that is the same as or similar to embodiment 1 will be omitted or simplified.

[0089] For example, let us consider a case where a user transfers 1.5 BTC. Assume that there is correspondence information indicating that asset transfers of 1 BTC or more require a signature using secp384r1 (384-bit key length elliptic curve signature). Here, assume that ledger server 100b only stores signatures using secp256r1 (256-bit key length elliptic curve signature). In this case, ledger server 100b does not store the signature key length required for the asset transfer of 1.5 BTC, so it executes a process to request the generation of a signature from another node (which may be another smart contract) that supports the signature key length.

[0090] It is assumed that the information processing system 10 includes a ledger server 100d in addition to the ledger servers 100a to 100c shown in Fig. 1. The ledger servers 100c and 100d are capable of generating signatures using secp384r1 (384-bit key length elliptic curve signatures) using smart contracts (SCs) (i.e., they are compatible with signatures using secp384r1 (384-bit key length elliptic curve signatures)).

[0091] The identification information (unique ID) of the first smart contract (first SC) is denoted as SC1. Here, the first smart contract (first SC) can generate a signature using secp384r1 (384-bit key length elliptic curve signature).

[0092] As shown in FIG. 4A , the execution unit 113 of the ledger server 100b first sends a signature request to the ledger server 100c to request the generation of a signature (S110). The ledger server to which the signature request is sent may be either 100c or 100d, or may be determined by the ledger server 100b. Information regarding the signature method stored by each node in the information processing system 10 is stored in the distributed ledger 114b, and the execution unit 113 may identify the ledger server 100c based on this information and send a signature request to the ledger server 100c. The signature request includes information necessary to determine the signature method, such as the transaction (here, information about the asset transfer of 1.5 BTC).

[0093] Next, the ledger server 100c verifies the acquired transaction (S120). If the verification is successful, the first SC generates a first signature sig(Tx, SC1), which is a signature using secp384r1 (384-bit key length elliptic curve signature), and sends it to the ledger server 100b (S130). The communication unit 111 of the ledger server 100b acquires the first signature sig(Tx, SC1) via the network. The acquired first signature (Tx, SC1) is a signature generated using a signature method selected from multiple signature methods based on the amount of transferred coins. In this embodiment, it is a signature generated by operating the first SC from multiple smart contracts.

[0094] This allows the ledger server 100b to obtain a signature using secp384r1 (384-bit long elliptic curve signature), which the ledger server 100b does not support. The first signature sig(Tx, SC1) obtained in step S130 is the signature obtained by the first proxy signature process.

[0095] If the ledger servers 100b and 100c are malicious nodes, the ledger servers 100b and 100c may collude (for example, the ledger server 100b may collude with the first SC) to generate an unauthorized Tx by attaching the signature of the SC to the Tx. Therefore, the information processing system 10 according to this embodiment further executes the processes from step S140 onward.

[0096] When an SC is created and registered in the distributed ledger or in a memory other than the distributed ledger, a unique ID is assigned to each SC. For example, this may be set as "ID of SC1":= hash("number of blocks in which SC1 is deployed") mod N, where N is a key length parameter.

[0097] Next, the execution unit 113 of the ledger server 100b searches for an SC that satisfies predetermined conditions (S140). Step S140 is a process for selecting an SC for which a signature is to be generated again for the asset transfer transaction. The predetermined conditions include a condition for using the first signature sig(Tx, SC1) generated by the first SC. For example, the predetermined condition may be that the SC has an ID value closest to hash(sig(Tx, SC1)) mod N. This selects the SC whose ID value is closest to hash(sig(Tx, SC1)) mod N. In other words, an SC that the execution unit 113 cannot arbitrarily select is selected.

[0098] 4A shows an example in which a second smart contract (second SC) stored in the distributed ledger of the ledger server 100d is selected from among multiple smart contracts because its ID is closest to the hash value of the first signature. The ID is an example of a value indicated by identification information.

[0099] Although an example of using a hash value as the predetermined condition has been described, the present invention is not limited to this, and the next SC may be determined in any manner that prevents the ledger server 100b (i.e., the user) from arbitrarily selecting an SC. For example, the SC may be selected by another method using the most recently acquired signature, or may be selected based on a statistical value (e.g., average, median, etc.) of hash values ​​of the most recent multiple signatures. Alternatively, the SC may be selected without using a signature.

[0100] Next, the execution unit 113 executes a process (S150 to S170) to acquire a second signature generated by the second SC. The processes of steps S150 to S170 are the same as the processes shown in steps S110 to S130, and therefore, a description thereof will be omitted. Note that the second signature sig(Tx, SC2) acquired in step S170 is a signature acquired by the second proxy signature process, and is a signature generated by operating a second SC that is automatically identified from multiple smart contracts based on the first signature sig(Tx, SC1).

[0101] In step S170, in addition to the second signature, information indicating a public key for verifying the second signature may be transmitted from the ledger server 100d to the ledger server 100b.

[0102] Note that the processes corresponding to steps S140 to S170 may be repeated multiple times. For example, a new SC that satisfies a predetermined condition based on the second signature sig(Tx, SC2) obtained in step S170 may be identified, a signature request may be sent to that SC, and a third signature may be generated and obtained using that SC. In this way, by determining the SC for which a signature is to be generated in step S140, it is possible to prevent the user from arbitrarily selecting an SC. The number of repetitions is not particularly limited, but may be 2 or more from the viewpoint of improving reliability, or 0 or 1 from the viewpoint of increasing speed.

[0103] If the proxy signature process is executed M times (M is a natural number equal to or greater than 2), M signatures are obtained.

[0104] Next, the communication unit 111 of the ledger server 100b transmits an asset remittance Tx (S180). The transmitted asset remittance Tx includes multiple signatures. If the number of repetitions is 0, the transaction data includes two different signatures, a first signature and a second signature. If the number of repetitions is 1, the transaction data includes three different signatures, a first signature, a second signature, and a third signature.

[0105] The asset transfer Tx is stored (added) to the storage device 101a. The asset transfer Tx stored in the Tx pool includes multiple different signatures for one asset transfer transaction. Step S180 is a process in which the ledger server 100b issues M first signatures sig(Tx, SC1), ..., Mth signatures sig(Tx, SC_M) together with Tx to the Tx pool.

[0106] Next, the communication unit of the ledger server 100a acquires transaction data from the storage device 101a (S190). Assume that the acquired transaction data includes an asset remittance Tx.

[0107] As shown in Figure 4B, the execution unit of the ledger server 100a then determines whether to include the asset transfer Tx in a block (S200). The execution unit examines each signature using the public key corresponding to each signature, and if the verification of each signature is successful, determines to include the asset transfer Tx in the block. The execution unit may, for example, verify that the following (i) first condition and (ii) second condition are satisfied, and add the asset transfer Tx to the block if the verification is successful.

[0108] (i) First condition: The i-th signature sig(Tx, SC_i) is successfully verified using the public key of each SC_i.

[0109] (ii) Condition 2: For each SC_i, ID(SC_i+1) = min_k(ID(SC_k), (hash(sig(Tx, SC_i)) mod N)).

[0110] Condition 2 is a condition for verifying whether an SC is selected to satisfy the condition "an ID whose value is closest to hash(sig(Tx, SC1)) mod N" (i.e., whether the user has not arbitrarily selected an SC after step S140). The execution unit performs verification in condition 2 by comparing the hash value with the ID of each SC. The execution unit verifies whether the SC used to generate the third signature satisfies the condition, for example, by determining whether the ID of the SC used to generate the third signature is closest to the hash value of the second signature. The execution unit verifies whether each SC used to generate the signature was arbitrarily selected, and if it is confirmed that each SC was not arbitrarily selected, it determines that (ii) the second condition is satisfied. The ID of each SC may be stored, for example, in the distributed ledger 114a.

[0111] The processes in steps S210 to S240 are the same as the processes in steps S50 to S80 shown in FIG. 3, and therefore a description thereof will be omitted.

[0112] 3 to 4B, an example in which the key length is changed depending on the amount of coins has been described, but the present invention is not limited to this. For example, the signature algorithm may be changed. For example, when the amount of coins exceeds a threshold, a signature algorithm that takes more time to decrypt may be used compared to when the amount of coins is equal to or less than the threshold. Changing the key length and changing the signature algorithm are examples of changing the signature method.

[0113] This allows for safe exception handling so that Tx can be generated even if the node does not support the required signature method, thereby achieving both availability and security for the blockchain.

[0114] In step S180, the asset remittance Tx does not necessarily include the first signature. That is, the miner may determine whether to include the asset remittance Tx in a block without verifying the first signature.

[0115] Here, the data structure of a distributed ledger, the execution of smart contracts, and the data structure of NFTs will be described with reference to Figures 5 to 9.

[0116] FIG. 5 is an explanatory diagram showing the data structure of a blockchain, which is an example of a distributed ledger.

[0117] A blockchain is a chain of blocks, which are units of record. Each block contains multiple transaction data and the hash value of the previous block.

[0118] FIG. 5 shows blocks B1, B2, and B3 included in the blockchain.

[0119] For example, block B2 contains the hash value of the previous block B1, which is calculated by performing a hash algorithm on the contents of block B1.

[0120] Furthermore, block B3 includes, as the hash value of block B2, a hash value calculated from multiple transaction data included in block B2 and the hash value of block B1.

[0121] In this way, a blockchain is structured so that blocks containing the contents of the previous block as a hash value are connected in a chain, which effectively prevents tampering with the recorded transaction data.

[0122] If past transaction data is changed (in other words, tampered with), the hash value of the block containing that transaction data will be different from the value before the change. In that case, to make the block containing the changed transaction data appear correct, all blocks after that block in the distributed ledger stored on multiple servers would have to be recreated, which is extremely difficult in reality. This feature makes it virtually impossible to tamper with transaction data contained in the blockchain.

[0123] When a node stores transaction data in a blockchain, it generates a block containing the transaction data to be stored and attempts to reach consensus on the generated block by executing processing based on a consensus algorithm with other nodes. Then, when consensus is reached, the node controls the storage of the block in the blockchain. This allows multiple nodes operating in an autonomous and decentralized manner to connect legitimate blocks to the blockchain. As a consensus algorithm, PBFT (Practical Byzantine Fault Tolerance), PoW (Proof of Work), PoS (Proof of Stake), or the like may be used. When Hyperledger Fabric is used as an example of a distributed ledger technology, a consensus algorithm does not need to be executed.

[0124] FIG. 6 is an explanatory diagram showing the data structure of the transaction data.

[0125] 6 includes a transaction body BP1 and a digital signature BP2 (also simply referred to as a signature). The transaction body BP1 is the data body included in the transaction data. The digital signature BP2 is generated by encrypting the hash value of the transaction body BP1 with the signature key (in other words, the private key) of the creator of the transaction data.

[0126] A node that receives transaction data can verify that the transaction body BP1 is legitimate (in other words, that it has not been tampered with) using the digital signature BP2 included in the transaction data. This makes it virtually impossible to tamper with the data included in the transaction body BP1. Furthermore, by storing successfully verified transaction data in the blockchain, the legitimacy of the transaction data stored in the blockchain can be maintained.

[0127] As described above, transaction data included in the blockchain is stored in a chain using the hash values ​​of the transaction data and the hash values ​​of the blocks. This allows the transaction data included in the blockchain to be stored and maintained substantially without being tampered with. This is an advantage over a database or a distributed database that simply stores a collection of data.

[0128] Fig. 7 is an explanatory diagram showing transaction data related to the execution of a smart contract. Fig. 8 is a flow diagram showing processing (information processing information) related to the execution of a smart contract.

[0129] A series of processes related to the execution of a smart contract using a distributed ledger will be described with reference to Figures 7 and 8.

[0130] In step SB1, the node stores transaction data B11, including contract code B12 that describes the processing of the smart contract, in the distributed ledger B10. For example, the node acquires transaction data B11 by receiving the transaction data B11 from an information processing device via communication or by the node itself generating the transaction data B11, and stores the acquired transaction data B11 in the distributed ledger B10. Step SB1 is performed before executing the smart contract.

[0131] In step SB2, the node stores transaction data B15, including instructions B16 for executing the smart contract, in the distributed ledger B10. For example, the node receives transaction data B15 from an information processing device via communication and stores the received transaction data B15 in the distributed ledger B10.

[0132] In step SB3, in response to the transaction data B15 including the instruction B16 being stored in the distributed ledger B10 in step SB2, the node reads the contract code B12 from the distributed ledger B10 and executes processing based on the contract code B12. The results of the processing may be included in the transaction data and stored in the distributed ledger B10.

[0133] Through the above series of processes, when the ledger system receives transaction data B15 including instructions B16 for executing a smart contract, it automatically (i.e., without manual intervention) executes the processing in accordance with the instructions B16, enabling highly efficient (i.e., high speed or short processing time). Achieving highly efficient processing has the effect of reducing power consumption. Furthermore, since no manual intervention is required, it is possible to prevent human tampering with information, fraud, or human error. Furthermore, since the results of the processing thus executed are stored in the blockchain, it is virtually impossible to tamper with the results of the processing.

[0134] FIG. 9 is an explanatory diagram showing the structure of an NFT and metadata. An NFT is a token stored in a distributed ledger and is a unique token (in other words, a non-fungible token). NFTs are standardized, for example, as ERC (Ethereum Request for Comments) 721, but are not limited to this. NFTs may conform to a different standard or may be non-standard (for example, proprietary to an organization). While ERC 721 is a standard for unique tokens, the NFTs described herein do not necessarily have to be unique tokens.

[0135] 9 shows transaction data B21 stored in the distributed ledger. The transaction data B21 stores an NFT. The NFT includes a token ID (i.e., identification information that can uniquely identify the NFT) and a metadata Uniform Resource Identifier (URI).

[0136] The NFT has metadata. The metadata may be located in a location accessible via a network (e.g., storage device B22). A metadata URI indicating the location of the metadata may be calculated using the NFT's token ID and a predetermined base URI.

[0137] The information managed as an NFT may be included in the transaction data B21 or in the metadata. Including the information managed as an NFT in the metadata has the advantage of reducing the amount of information included in the transaction data B21 (in other words, the information included in the blockchain). In this case, it can be said that the metadata contains the actual information managed as an NFT. When an image is managed as an NFT, a URL indicating the image data of the image may be managed as an NFT.

[0138] (Other Embodiments) While the information processing method according to one or more aspects has been described above based on the embodiments, the present disclosure is not limited to these embodiments. As long as it does not deviate from the spirit of the present disclosure, various modifications conceivable by a person skilled in the art to the present embodiments and embodiments constructed by combining components of different embodiments may also be included in the present disclosure.

[0139] For example, although the above embodiment uses a blockchain, it is not necessary to use a blockchain. Also, instead of a blockchain, a distributed ledger technology such as a hash graph may be used.

[0140] Furthermore, in the above embodiment, an example has been described in which the signature method is changed depending on the amount of coins transferred for asset remittance Tx, but this is not limiting, and the information processing method of the present disclosure may also be used in cases in which the signature method is changed depending on the asset value of the asset to be transferred, etc. For example, if transaction data includes information regarding vehicle rental, and the asset value of the vehicles (e.g., the purchase price of the vehicles, the number of vehicles rented, etc.) exceeds a predetermined amount or a predetermined number (an example of a threshold), the signature method may be changed to one that is more difficult to decipher than the signature method used when the asset value is equal to or less than the predetermined amount or the predetermined number. In this way, the signature method may be changed depending on the asset value of a real object.

[0141] Furthermore, at least one of the user terminal, the information processing device that executes the first SC, and the information processing device that executes the second SC in the above embodiments is not limited to being a node of the distributed ledger system, and may be realized by an information processing device external to the distributed ledger system.

[0142] Furthermore, the number of thresholds included in the correspondence information according to the above embodiment is not limited to one, but may be two or more. In other words, the number of signature methods included in the correspondence information is not limited to two, but may be three or more. This allows for detailed selection of a signature method depending on the asset value. Furthermore, changing the signature method may involve changing both the key length and the signature algorithm. Note that changing the signature method does not include changing to a signature method that is less secure than the signature method set by default. This makes it possible to ensure a minimum level of security.

[0143] Furthermore, each device in the above embodiments is specifically a computer system comprising a microprocessor, ROM (Read Only Memory), RAM (Random Access Memory), a hard disk unit, a display unit, a keyboard, a mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device achieves its function when the microprocessor operates in accordance with the computer program. Here, a computer program is composed of a combination of multiple instruction codes that indicate instructions to a computer to achieve a predetermined function.

[0144] In addition, some or all of the constituent elements of each device in the above embodiments may be configured from a single LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured to include a microprocessor, ROM, RAM, etc. A computer program is stored in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program. Furthermore, each component of each device may be individually integrated into a single chip, or some or all of the components may be integrated into a single chip. Here, the term system LSI is used, but it may also be called an IC, LSI, super LSI, or ultra LSI depending on the degree of integration.

[0145] The present disclosure may also be embodied as the methods described above. Furthermore, the present disclosure may also be embodied as a computer program that implements these methods on a computer, or as a digital signal comprising the computer program. For example, one aspect of the present disclosure may be a computer program that causes a computer to execute each of the characteristic steps included in the information processing method shown in FIG. 3 or FIG. 8.

[0146] The present disclosure may also be a computer program or a digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), semiconductor memory, or the like. It may also be a digital signal recorded on such a recording medium. The present disclosure may also be a computer program or a digital signal transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, data broadcasting, or the like.

[0147] The present disclosure may also be a computer system having a microprocessor and a memory, the memory storing the computer program, and the microprocessor operating in accordance with the computer program.

[0148] Furthermore, the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, so that the program or digital signal may be implemented by another independent computer system.

[0149] In the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0150] The order in which the steps in the flowchart are executed is merely an example for specifically explaining the present disclosure, and other orders may be used. Some of the steps may be executed simultaneously (in parallel) with other steps, or some of the steps may not be executed.

[0151] The division of functional blocks in the block diagram is an example, and multiple functional blocks may be realized as a single functional block, one functional block may be divided into multiple blocks, or some functions may be moved to another functional block.Furthermore, the functions of multiple functional blocks having similar functions may be processed in parallel or in time-sharing by a single piece of hardware or software.

[0152] Furthermore, each of the ledger servers according to the above embodiments may be realized as a single device or may be realized by multiple devices. When the ledger server is realized by multiple devices, the components of the ledger server may be distributed in any manner among the multiple devices. When the ledger server is realized by multiple devices, the communication method between the multiple devices is not particularly limited and may be wireless communication or wired communication. Furthermore, wireless communication and wired communication may be combined between the devices.

[0153] The present disclosure is useful for information processing devices and the like that manage distributed ledgers.

[0154] 10 Information processing system 100a, 100b, 100c, 100d Ledger server 101a, 101b, 101c Storage device 111 Communication unit (first acquisition unit, second acquisition unit, transmission unit) 112 Ledger management unit 113 Execution unit 114 Storage unit 114a, 114b, B10 Distributed ledger 115 Transaction data generation unit 300 Communication network B1, B2, B3 Block B11, B15, B21 Transaction data B12 Contract code B16 Instruction B22 Storage device BP1 Transaction body BP2 Digital signature

Claims

1. An information processing method comprising: acquiring data to be included in transaction data to be stored in a distributed ledger; acquiring a digital signature generated using a signature method selected from multiple signature methods according to the data; and outputting transaction data including the data and the digital signature.

2. The information processing method according to claim 1, wherein the selected signature method is a signature method selected from the plurality of signature methods according to the asset value of the asset information included in the data.

3. The information processing method according to claim 2, wherein when the asset value included in the data body of the transaction data exceeds a threshold, the selected signature method is a signature method that is more secure than when the asset value is equal to or less than the threshold.

4. The information processing method according to claim 3, wherein the signature scheme with higher security includes the use of an encryption key with a longer key length.

5. The information processing method according to claim 3, wherein the signature scheme with higher security includes the use of a signature algorithm that makes it more difficult to decrypt the signature by computer.

6. An information processing method according to any one of claims 3 to 5, wherein, in obtaining the digital signature, a signature method for generating a signature for the data body is selected from the plurality of signature methods based on the asset value, and the digital signature is generated using the selected signature method.

7. An information processing method according to any one of claims 2 to 5, wherein the digital signature is obtained via a network using a signature method selected from the plurality of signature methods based on the asset value.

8. The information processing method of claim 7, wherein the acquiring of the digital signature comprises acquiring a first signature generated by running a first smart contract among a plurality of smart contracts, and acquiring a second signature generated by running a second smart contract among the plurality of smart contracts that is identified based on the first signature, and wherein the transmitting of the transaction data comprises transmitting the transaction data that includes the first signature and the second signature as the digital signature.

9. The information processing method described in claim 8, wherein identification information is assigned to each of the plurality of smart contracts, and the identification information of the second smart contract among the plurality of smart contracts is closest to the hash value of the first signature.

10. The information processing method according to claim 8, further comprising verifying each of the first signature and the second signature in the mining process, and generating a block including the transaction data if the verification of each of the first signature and the second signature is successful.

11. An information processing device comprising: a first acquisition unit that acquires data to be included in transaction data to be stored in a distributed ledger; a second acquisition unit that acquires a digital signature generated using a signature method selected from a plurality of signature methods according to the data; and a transmission unit that transmits transaction data including the data and the digital signature.

12. A program for causing a computer to execute the information processing method according to any one of claims 1 to 5.

Images