Abstract: Digital utilization of certificate data with respect to attribute data representing attributes of an entity managed by an institution. An institution apparatus 100 receives a certificate data request (S201) and generates certificate data (S202) and acquires, at or around the time, verification data for the certificate data (S203). The apparatus 100 sends to the terminal 110 the certificate data 300 and the verification data 400 (S204). The terminal 110 sends to the verification apparatus 120, requiring verification of attributes of an individual using the terminal 110, the certificate data 300, and sends one or more pieces of attribute data of attributes to be certified and hash values of respective pieces of attribute data obtained by excluding those attribute data from the verification apparatus 400, after adding a signature based on a secret key corresponding to a public key included in the certificate data 300 (S205).

Abstract: Signature handling for a block for which consensus was formed in blockchain network which requires signatures from plurality of nodes to form consensus for block adoption. After completion of the setup, first node 110 sends a first message including a generated block to N nodes (S301). Each node evaluates the validity of the block on basis of the rule for consensus formation (S302). If the block is valid, the node sends a second message which includes signature si, by secret key share f(xi), with respect to a hash value h of the block for which consensus is to be formed (S303-1). After k signatures are collected at jth node, the node merges these signatures to generate a signature corresponding to a public key PK (S304). A block for which consensus is to be formed has signature SK·h appended thereto and is added to blockchain of each node (S306).

Abstract: A method of recordation request of a compound transaction to a blockchain distributed network, comprising steps of: the first node constituting the distribution network signing a compound transaction in which a plurality of sources of assets exist by a secret key of the node, when there is a remaining source by which the compound transaction needs to be signed, the first node transmitting the compound transaction to a second node constituting the distributed network, and when there is no remaining source by which the compound transaction needs to be signed, the first node transmitting the compound transaction to a third node constituting the distributed network to request recordation to the distributed network.

Abstract: The reliability of a second public key which is part of a second key pair generated in association with a first key pair is certified. A generating apparatus 210 provides certification data to a receiving apparatus 220 (S301). The receiving apparatus 220 transmits a certification request requesting a certification that the second public key PK2 is in a parent-child relationship with the first public key PKI to a certifying apparatus 230 (S302). In this example, the certification request includes the certification data, but if the certification data is provided directly from the generating apparatus 210 to the certifying apparatus 230, the certification request does not need to include the certification data. The certifying apparatus 230 verifies the certification data by calculating a verification formula for the certification data in response to the certification request (S303).

Abstract: A method for storing a transaction that represents an asset transfer in a distributed network, wherein a transaction processing speed is greatly improved. A first partial network 110 included in a distributed network receives a transaction 200 generated by a user terminal 140 and representing the transfer of assets 203 from a source identifier 201 to a destination identifier 202 and generates a block that includes the transaction 200 to perform a consensus building process for adoption of the block in the first partial network 110 (S303). Each node, storing asset states of the source identifiers processable by each node, records the transfers of assets from the source identifiers described in one or a plurality of transactions included in the block added through the consensus building (S304). By determining source identifiers processable in each partial network, transactions are processed in parallel.

Abstract: A consensus building method suitable when f Byzantine failure nodes (f is an integer equal to or larger than 1 and smaller than N/3) are assumed in a network having N nodes (N is an integer equal to or larger than 1) participating in consensus building, comprising the steps of: receiving a first message from other node which communicates that the other node determined a message including data subject to consensus building valid as a proposal, when the number of received first messages reach a predetermined value Q, transmitting a second message to each node which communicates that it is accepting the proposal, and when the number of received first messages do not reach the predetermined value Q, transmitting a third message to each node which communicates that it is dismissing the proposal, when the number of received second messages reach a predetermined value Q, transmitting a fourth message to each note which communicates that it is treating the proposal as agreed in the network, and when the number of rec

Abstract: Proving reliability of a second public key of a second key pair generated in association with a first key pair. A generator 210 calculates and stores x·H(n) which is proof data and ax·H(n), when the second public key ax·g1 which is of the second key pair is generated (S301). The generator 210 provides the calculated proof data to a receiving apparatus 220 (S302) which has received the proof data, transmits a proof request to the proving apparatus 230 for requesting a proof that the second public key ax·g1 is generated by an owner of the first public key a·g1 (S303). In response to the proof request, the proving apparatus 230 verifies the proof data by calculating a verification formula for the proof data (S304). The proving apparatus 230 transmits the verification result as a response to the proof request from the receiving apparatus 220 (S305).

Abstract: The purpose of the present invention is to facilitate utilization of digital signature. First, a device 120 acquires data to be signed and a signature (S501). Then, the device 120 verifies the signature by determining, using a public key, whether the signature has been given by an owner of the public key (S502). The verification of the signature may be performed at a verification apparatus (not shown) that the device 120 can access, and the verification result may be returned to the device 120. When the verification of the signature has been successful, the device 120 displays a document image 201 with a predetermined seal overlaid, on the display of the device 120 (S503). In this way, the user of the device 120 can visually confirm that the digital signature has been given by someone having approval authority.

Abstract: A smart contract using non-deterministic external data to be deterministically executed in a blockchain network. A first node 101 generates a new block from one or a plurality of transactions accumulated in a memory pool (S201). Concerning a transaction that invokes a smart contract, the first node 101 refers to an external system for non-deterministic external data used therein and stores the acquired data in the block (S202). The generated block is transmitted as a proposal to a plurality of nodes participating in consensus formation (S203) and undergoes validation in each node (S204). Here, the validation is performed with respect to the external data in addition to the transaction. Subject to the satisfaction of a prescribed condition in the validation process, each node adds the block to the blockchain of each node (S205).

Abstract: Provided is a method for efficiently enabling access to a past transaction in a blockchain network. A first node 101 generates a new block from one or more transactions accumulated by using, as a memory pool, the storage unit 101C or a storage device or a storage medium accessible from the first node 101 (S201). When an adoption of the generated block is agreed upon in the blockchain network (100), the generated block is added to the blockchain at each node (S202). In an embodiment of the present invention, various consensus algorithms can be used, but it is required that the algorithm has finality. Each node generates and stores an identifier for uniquely identifying each transaction based on the height of the added block and the order within the block (S203).

Abstract: Signature handling for a block for which consensus was formed in blockchain network which requires signatures from plurality of nodes to form consensus for block adoption. After completion of the setup, first node 110 sends a first message including a generated block to N nodes (S301). Each node evaluates the validity of the block on basis of the rule for consensus formation (S302). If the block is valid, the node sends a second message which includes signature si, by secret key share f(xi), with respect to a hash value h of the block for which consensus is to be formed (S303-1). After k signatures are collected at jth node, the node merges these signatures to generate a signature corresponding to a public key PK (S304). A block for which consensus is to be formed has signature SK·h appended thereto and is added to blockchain of each node (S306).

Abstract: In this method for validating a transaction in a blockchain network, validation speed is increased. A first node 101 receives a transaction (tx) (S201). The first node 101 gives the received tx as an input to a Bloom filter (S202). The Bloom filter is generated on the basis of past one or more txs included in a blockchain. When the Bloom filter returns true, the first node 101 searches a dictionary by using txid of the to-be-validated tx as a key, and determines presence or absence thereof (S203). The dictionary is generated on the basis of one or more txs included in past blocks on which consensuses were formed. When a search result of the dictionary is false, it is determined that a to-be-validated transaction is valid, and also when the Bloom filter returns false, It is determined that the to-be-validated tx is similarly valid (S204).

Abstract: A consensus building method suitable when f Byzantine failure nodes (f is an integer equal to or larger than 1 and smaller than N/3) are assumed in a network having N nodes (N is an integer equal to or larger than 1) participating in consensus building, comprising the steps of: receiving a first message from other node which communicates that the other node determined a message including data subject to consensus building valid as a proposal, when the number of received first messages reach a predetermined value Q, transmitting a second message to each node which communicates that it is accepting the proposal, and when the number of received first messages do not reach the predetermined value Q, transmitting a third message to each node which communicates that it is dismissing the proposal, when the number of received second messages reach a predetermined value Q, transmitting a fourth message to each note which communicates that it is treating the proposal as agreed in the network, and when the number of rec

Abstract: Processing method at a node constituting one of one or more lower networks in a network with an upper network and the one or more lower networks lower to the upper network. The node generates a block with a transaction which causes transfer of an asset from a lower network in which the node is included to the upper network. The node finalizes the block under a condition that approvals from predetermined number of the nodes constituting the lower network in which the node is included is obtained to add the block to a transaction history between that lower network and other networks. Transfer of the asset to the upper network is allowed in response to finalization of the block under a condition that the total amount of asset transfer to the upper network including the transaction does not exceed the total amount of asset transfer from the upper network.

Abstract: A method of recordation request of a compound transaction to a blockchain distributed network, comprising steps of: the first node constituting the distribution network signing a compound transaction in which a plurality of sources of assets exist by a secret key of the node, when there is a remaining source by which the compound transaction needs to be signed, the first node transmitting the compound transaction to a second node constituting the distributed network, and when there is no remaining source by which the compound transaction needs to be signed, the first node transmitting the compound transaction to a third node constituting the distributed network to request recordation to the distributed network.

Abstract: The present invention achieves reliability of recording as well as expanding the fields of application in a network wherein transactions for which transaction information is noted are divided into blocks and imported into a distributed database. Nodes of the network are composed and classified as public nodes and private nodes. The public nodes fulfil the role of generating a transaction to be recorded. Processing for recording to the distributed database thereafter is carried out through the cooperation of private nodes. Transaction generation is allowed on a broad basis for the public nodes, which may include unreliable nodes, while processing for recording to the distributed database is restricted to the reliable private nodes.