WO2018142948A1 - 信用度管理システムおよび信用度管理方法 - Google Patents

信用度管理システムおよび信用度管理方法 Download PDF

Info

Publication number
WO2018142948A1
WO2018142948A1 PCT/JP2018/001320 JP2018001320W WO2018142948A1 WO 2018142948 A1 WO2018142948 A1 WO 2018142948A1 JP 2018001320 W JP2018001320 W JP 2018001320W WO 2018142948 A1 WO2018142948 A1 WO 2018142948A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
evaluation
smart contract
execution transaction
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2018/001320
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
竜也 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to US16/483,486 priority Critical patent/US11102001B2/en
Priority to SG11201907267VA priority patent/SG11201907267VA/en
Publication of WO2018142948A1 publication Critical patent/WO2018142948A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention relates to a credit management system and a credit management method.
  • Non-Patent Document 1 uses a virtual currency called bitcoin to perform a settlement transaction without requiring a centralized authority such as a bank.
  • a node called a minor executes a determination of legitimacy regarding transaction data (hereinafter also referred to as a transaction) on the P2P network, and calculates a specific hash value called a proof of work. Confirmation processing is performed at.
  • the transactions thus confirmed are collected into one block and described in a distributed ledger called a block chain (hereinafter also referred to as BC).
  • BC distributed ledger
  • BC is being studied for application in a wide range of fields such as the financial field and IoT (Internet of Thing) as a mechanism for reliable data management / sharing and transaction execution / management based on contracts.
  • IoT Internet of Thing
  • BC platform a platform that provides BC
  • information can be shared and traded among multiple entities without management by a centralized authority (for example, related to consortiums and supply chains in specific industries). Multiple companies).
  • BC is not only a simple virtual currency transaction such as Bitcoin, but also has a mechanism that can be applied to complex transaction conditions and various applications. You can also manage logic. This logic is called a smart contract (hereinafter also referred to as SC).
  • SC smart contract
  • the BC base (Non-patent Document 2, Non-patent Document 3) having the above-mentioned SC execution function manages the SC itself and the input data for the SC.
  • the SC itself is like a function (s).
  • the input data is like an SC to be called, a function name, and an argument given to the function. If the execution function of the SC is used, a transaction can be executed in accordance with a predefined contract.
  • the SC and its input data are managed in a chain with a signature in the BC. Therefore, by having the BC base having the SC execution function, the registrant of data and logic becomes clear, and it can always be confirmed that there is no change in the registered contents.
  • the SC may be stored in the distributed ledger in a binary or encrypted state and may be a black box for the user, a means to evaluate / trust the quality of the SC is very important It becomes.
  • Non-patent document 4 a method in which the SC provider conducts SC testing and verification in advance in a development environment (outside of BC).
  • Non-Patent Document 5 a technique in which a specific approval organization examines a program has been proposed, and this can be applied to SC examination.
  • an object of the present invention is to provide a technique for confirming and evaluating the reliability of the quality of the smart contract itself by a plurality of third parties other than the smart contract provider, without the management by the central authority.
  • the credit management system of the present invention that solves the above problems is a system comprising a plurality of verification nodes each holding a distributed ledger and a plurality of transaction issuing nodes that issue transactions to the verification nodes, each of the verification nodes Manages the smart contract, the smart contract execution transaction, and the evaluation execution transaction for the smart contract in the block chain managed by each, and each of the verification nodes is for an evaluation specified by the predetermined transaction issuing node. Including the predetermined value of the smart contract and the output value when the predetermined value is input to the smart contract, and managing the verification result of the smart contract included in the evaluation execution transaction, or And it manages including a force value in the state information, characterized in that.
  • the credit management method of the present invention is a credit management method for a distributed ledger system comprising a plurality of verification nodes respectively holding a distributed ledger and a plurality of transaction issuing nodes for issuing transactions to the verification nodes.
  • Each of the plurality of verification nodes in the distributed ledger system manages the smart contract and the execution transaction of the smart contract and the evaluation execution transaction for the smart contract in the block chain, and is specified by the predetermined transaction issuing node. Including a predetermined value for evaluation, and an output value when the predetermined value is input to the smart contract, including the verification result of the smart contract included in the evaluation execution transaction, or Managing including a force value in the state information, characterized in that.
  • the present invention it is possible to confirm and evaluate the reliability of the quality of the smart contract itself by a plurality of third parties other than the smart contract provider without management by the central authority.
  • a distributed ledger system 10 as a credit management system is an information processing system including a plurality of nodes such as a verification node 3 and a client node 4 as illustrated in FIG.
  • each node in such a distributed ledger system 10 receives an execution transaction for evaluation (hereinafter referred to as an evaluation execution transaction) for the SC from any other node, the actual execution transaction for the SC (using the evaluation execution transaction)
  • the actual execution transaction for the SC (using the evaluation execution transaction)
  • the SC is executed, and each history of the execution execution transaction and the evaluation execution transaction and the execution result are managed and retained on the distributed ledger. To do.
  • each node can share the execution history of the above-described evaluation execution transaction among participants in the BC network.
  • the BC network in the present embodiment is a network including a verification node 3 and a client node 4 that use a predetermined smart contract together.
  • Such a distributed ledger system 10 includes one or more verification nodes 3 and one or more client nodes 4 as described with reference to FIG. These devices are connected to the network 1 through a physical communication line 2.
  • the verification nodes 3 described above are managed by a plurality of entities (for example, a plurality of operators). Further, it is assumed that one or more SC providers and a plurality of SC users use different client nodes 4 respectively.
  • the verification node 3 includes the transaction management unit 31, the smart contract execution unit 32 (hereinafter also referred to as the SC execution unit 32), the member management unit 33, the reference API 34, the smart contract evaluation management unit 35, and the smart contract monitoring.
  • the transaction management unit 31 includes an agreement formation processing unit 311.
  • the verification node 3 accepts a transaction from, for example, the client node 4 by the function of the transaction management unit 31, and forms an agreement to accept the transaction with another verification node by the function of the agreement formation processing unit 311. Do.
  • the verification node 3 performs SC deployment, production execution for the deployed SC, and evaluation execution processing for the deployed SC via the function of the SC execution unit 32, and transaction history. And the execution result are recorded in the distributed ledger D1.
  • the reference API 34 of the verification node 3 provides a function of acquiring / browsing history information of the evaluation execution transaction in response to a predetermined request from another node.
  • the member management unit 33 of the verification node 3 provides a predetermined registration process regarding members (nodes) participating in the BC network, a new issue of keys used for transaction processing, an authentication function, and the like. It is assumed that the member management unit 33 in this embodiment performs authentication of a participating member, signature on a transaction, control of SC execution authority, and the like using a private key / public key pair issued to each member.
  • the public key information D22 used for the above member management is stored and managed on the participating member management information D2.
  • the transaction management unit 31 when the transaction management unit 31 receives a transaction from a predetermined node, the transaction management unit 31 appropriately checks whether the issuer of the transaction is an authorized participant through the function of the member management unit 33. Since this function itself is a known technique, description thereof is omitted.
  • the block chain D11 and the state information D12 are stored and managed.
  • the block chain D11 and the state information D12 include information about the actual execution transaction (D110, D120) and information about the evaluation transaction (D111, D121), respectively. Holding both.
  • the client node 4 includes a functional unit including a transaction issuing unit 41 and a data group including participating member management information D2.
  • the user or provider of the SC issues various transactions via the transaction issuing unit 41 of the client node 4 and transmits them to the verification node 3.
  • the client node 4 uses the member authentication information (secret key D21) stored in the participating member management information D2 as issuer information to be given to the transaction. It is assumed that the public key D22 of the participating member management information D2 is exchanged between each client node 4 and the verification node 3.
  • FIG. 2 is a block diagram illustrating a physical configuration of the verification node 3 according to the first embodiment.
  • the verification node 3 in the present embodiment is a computer including an interface 100, a processor 101, and a memory 102.
  • the interface 100, the processor 101, and the memory 102 are connected by a data bus 103.
  • the verification node 3 having such a configuration communicates with the network 1 via the interface 100.
  • the processor 101 is an arithmetic device such as a CPU.
  • the memory 102 is a storage area for holding programs and data.
  • the processor 101 reads a program from the memory 102 via the data bus 34 and executes it. By executing this program, each functional unit illustrated in FIG. 1 is mounted.
  • FIG. 3 shows a block chain D11 managed on the distributed ledger D1.
  • BC type distributed ledger management a plurality of transactions in a predetermined time zone are collected as a block, and each block has a hash value of a block in the previous time zone, thereby managing the data in a daisy chain.
  • the block chain D11 shown in FIG. 3 is a block chain in which blocks D112 to D115 are connected.
  • Each of the blocks D112 to D115 shown here includes information such as a block D112 being a deployment transaction, a block D113 being a production execution transaction, and a D114 being an evaluation execution transaction.
  • each of the blocks D112 to D115 includes time stamp information at the time of generating the block. Further, each of the blocks D112 to D115 includes a hash value of the previous block in the series of block chains D11, and includes a hash value generated from state information D12 described later.
  • each transaction of deployment, production execution, and evaluation execution is managed as a data chain in the block chain D11.
  • the block D112 is an example of a block storing a deployment transaction.
  • the deployment transaction of the present embodiment includes a contract ID that uniquely identifies the SC and an SC entity (for example, an executable binary).
  • the deployment transaction includes a contract input specification for allowing the user to grasp the function name and the argument of the SC.
  • the deployment transaction includes an issuer ID for identifying the issuer of the deployment transaction, that is, the provider.
  • the deployment transaction includes an electronic signature used for verifying that the issuer and the data are not falsified. This electronic signature is generated by using the secret key of each BC network participating member (that is, SC provider or user) issued by the member management unit 33, and can be verified by the public key that forms the pair. .
  • the block D113 is an example of a block that stores a production execution transaction.
  • the production execution transaction of the present embodiment includes the contract ID of the smart contract to be called, and the function name and information of the argument to be input.
  • the block D113 includes an issuer ID for identifying the issuer of the actual execution transaction, that is, the user.
  • the block D113 includes an electronic signature used for verifying that the issuer and the data are not falsified.
  • the block D114 is an example of a block that stores an evaluation execution transaction.
  • the evaluation execution transaction of the present embodiment includes a contract ID that uniquely identifies a smart contract, a function name thereof, and information on an argument to be input, as in the case of a production execution transaction.
  • the block D114 includes an issuer ID for identifying the issuer of the evaluation execution transaction, that is, the user.
  • the block D114 includes an electronic signature used for verifying that the issuer and the data have not been falsified.
  • This block D114 further includes an evaluation ID and an expected value as information on the evaluation of the smart contract, that is, the verification result.
  • an evaluation ID is introduced as an identifier for uniquely identifying a series of evaluation scenarios. Furthermore, the mutual influence between evaluations can be eliminated by making the data area used in the state information D12 independent for each evaluation ID.
  • the above-mentioned expected value is a value expected for the execution result of this evaluation execution transaction or its allowable range.
  • the execution result of the evaluation execution transaction is also stored and held in the block D114 of the evaluation execution transaction. Normally, the execution result of a transaction can be obtained by tracing the BC and re-executing each transaction. However, since the execution result of the evaluation execution transaction is assumed to be referred to by the user, it is inefficient to re-execute each time. Therefore, the execution result is also stored in the evaluation execution transaction.
  • the block D114 of the evaluation execution transaction is evaluation determination information that is a result of determining whether or not the execution result of the evaluation execution transaction satisfies the expected value (for example, “OK” if the expected value is satisfied, “NG” if not satisfied). Is stored and retained.
  • FIG. 4 is a diagram illustrating a data configuration example of the state information D12 managed on the distributed ledger D1.
  • BC-type distributed ledger management in order to acquire (latest) state (for example, account balance in the case of virtual currency), it is usually necessary to follow BC. In this case, since the processing efficiency is low, there is a method of caching the latest state information separately from the BC (Non-patent Document 3, etc.).
  • This embodiment also assumes that the node holds the latest state information.
  • a state data area is prepared for each smart contract. Therefore, the state information D12 holds a contract ID that uniquely identifies the smart contract and the entity of the contract.
  • the SC execution unit 32 can acquire and execute the smart contract entity using the contract ID as a key. Further, the state information D12 includes an internal table for holding the execution result of the SC.
  • Each node updates the contents of this internal table each time a transaction is executed.
  • This internal table has a data area (D120, D121) for each transaction of production execution and evaluation execution.
  • D120, D121 data area for each transaction of production execution and evaluation execution.
  • the distributed ledger D12 shown in FIGS. 3 and 4 shows a specific example in which the block chain infrastructure is applied to a business contract related to freight transportation utilizing IoT.
  • a supply chain is assumed in which a plurality of transporters relay the transportation of cargo when shipping a certain cargo from a factory to a retail store.
  • the operator contracts that the supplier who violates the humidity standard is liable for all losses because inspection is required and shipment stops if the maximum humidity of the cargo exceeds 80% during transportation. It will be concluded between.
  • each cargo is an IoT device, which is equipped with a humidity sensor and periodically acquires and records the cargo humidity information (some sort of IoT data).
  • Each transporter's node registers the humidity information recorded each time the transport is completed by the transporter on the BC and automatically executes the smart contract corresponding to the business contract, so that it is the same among multiple contractors. Reliable data can be shared, and processing based on contracts can be executed automatically.
  • the SC deployed in block D112 shown in FIG. 3 is an SC that realizes the business contract described above.
  • This SC is provided by the “manufacturer A” as the issuer as the contract ID “freight transportation contract”, and the following functions are defined.
  • Transport is called by the transporter's node at the time when transport by each transporter is completed, and as input arguments, the cargo ID identifying the target cargo, transporter information, and humidity information obtained from the humidity sensor If the maximum humidity exceeds 80% within the SC, it is determined whether or not there is a breach of contract, and if it is violated, a penalty is calculated according to the excess humidity (according to the humidity). Pay-as-you-go calculation). The result is stored in the state information D12, and the amount of penalty is returned as a return value.
  • the block D113 shown in FIG. 3 is an example of a production execution transaction that calls the above-described function “transport ()”. This example shows that the transaction is when the transportation of the cargo ID “123” by the “transporter A” is completed and the humidity information obtained from the sensor is “60%”.
  • the state information D12 updated by this execution is the line of the cargo ID “123” in the internal table in D120.
  • the transporter since the SC is provided by the manufacturer, the internal processing of the SC is a black box for the transporter who is the user. Therefore, the transporter only knows the input argument specification of this SC function. That is, the user cannot determine whether the calculation formula processed inside the SC is valid or not. For example, in this example, whether or not a penalty is generated when the humidity is exactly 80%, whether the calculation result of the penalty corresponding to the excess humidity matches the user's assumptions, and the like.
  • the execution function of the evaluation execution transaction in this embodiment can be utilized.
  • the block D114 illustrated in FIG. 3 is an example of a block in which an evaluation execution transaction for the above-described smart contract function “transport ()” is stored.
  • transporter B transports the cargo ID “345” by the “transporter B” as the evaluation ID “1” and the humidity information is “85%”.
  • the transporter sets as an expected value that “penalty ⁇ 1000”.
  • Transporter B This enables “Transporter B” to detect that the internal processing of the SC does not meet his / her expectations before the actual execution.
  • this history is also shared with other users, so that if there is a similar evaluation history, it can be confirmed whether the user satisfies the expectation without evaluating the user himself / herself.
  • FIG. 5 is a flowchart showing an example of a new registration process for members who participate in the BC network.
  • the member management unit 33 of the verification node 3 receives a member registration request from another node such as the client node 4 (S101).
  • the above-mentioned member registration request includes a member ID that uniquely identifies the requested member.
  • the member management unit 33 generates a pair of the secret key D21 and the public key D22 by using a predetermined key generation tool or the like, and associates it with the member ID received in S101 (S102).
  • the member management unit 33 broadcasts the member ID to be newly registered and the public key D22 generated in S102 to other nodes (S103).
  • Each information of the member ID and the public key D22 broadcast here is stored as participating member management information D2 on each node.
  • the member management unit 33 returns the secret key D21 generated in S102 to the node that made the above-described member registration request (S104).
  • the node that has received this secret key D21 stores it as its own secret key D21 in the participating member management information D2.
  • a pair of private key and public key generated as described above is used to authenticate BC network members, sign transactions, and control SC execution authority.
  • the client node side issues a transaction digitally signed with the secret key issued by the member management unit 33, while the verification node side uses the public key of the client node.
  • Identity verification can be realized by verifying the corresponding electronic signature.
  • a publicly known or well-known technique may be applied to a method for generating a pair of a public key and a private key, a method for signature verification, and a method for associating a key and an ID.
  • FIG. 6 is a diagram illustrating a flow example 2 of the credit management method.
  • the transaction management unit 31 of the verification node 3 receives a transaction from a transaction issuer such as the client node 4 (S201).
  • the transaction management unit 31 determines the type of transaction received in S201 (S202), and performs the types found by this determination, that is, SC deployment, production execution, and evaluation execution.
  • the transaction management unit 31 blocks the received transaction with another verification node 3 as a block. Consensus building processing is performed as to whether or not it can be added to the end of the chain D11 (S204). As a specific consensus formation processing method, a known or well-known technique may be applied.
  • PBFT Practical Byzantine Fault Tolerance
  • PBFT is an algorithm that requires an agreement by more than a fixed (two-thirds) node among all nodes participating in consensus building (ie, verification nodes).
  • the verification node 3 first broadcasts the received transaction to all the verification nodes 3 participating in the network, and each verification node 3 performs signature verification on the transaction and falsifies. Confirm that the transaction has not been performed and the validity of the transaction contents, and broadcast the confirmation result to the other verification nodes 3.
  • confirmation by a certain number or more of verification nodes 3 is obtained, the fact that preparation for approval of the transaction is completed is broadcast to other verification nodes 3.
  • the consensus building is completed when the approval preparation completion by a certain number of verification nodes 3 has been confirmed.
  • the transaction management unit 31 registers the SC included in the transaction in the distributed ledger D1 via the SC execution unit 32 (S205). Specifically, based on the contents of the transaction, the contract ID and contract entity of the state information D12 are registered, and a block including the deploy transaction is added to the end of the block chain D11.
  • the transaction management unit 31 returns the execution result of the above-described deployment transaction to the node that issued the transaction (S206), and ends the process.
  • the transaction management unit 31 performs an agreement formation process with another verification node 3 as in the case of the deployment transaction (S207). ).
  • This consensus building process is the same as S204.
  • the transaction management unit 31 executes the SC via the SC execution unit 32 (S208). Specifically, for the SC with the contract ID specified in the production execution transaction (assuming that it has already been registered), execute it with the call function and input arguments specified in the production execution transaction. To do.
  • the transaction management unit 31 updates the contents of the distributed ledger D1 based on the execution result (S209). Further, the transaction management unit 31 updates the state information D12 related to the smart contract based on the execution result described above, and adds the actual execution transaction as the last block of the block chain D11.
  • the transaction management unit 31 returns the execution result (for example, the return value of the function) of the actual execution transaction to the node that issued the transaction (S210), and ends the process.
  • execution result for example, the return value of the function
  • the transaction management unit 31 performs a consensus formation process in the same manner as the deployment transaction (S211). This consensus building process is the same as S204.
  • the transaction management unit 31 executes the SC with the evaluation execution transaction as an input via the SC execution unit 32 (S212). Specifically, for the SC with the contract ID specified in the evaluation execution transaction (using the same binary as the production execution transaction), the call function and input arguments specified in the evaluation execution transaction are given and executed. .
  • the transaction management unit 31 updates the state information D12 related to the smart contract in the distributed ledger D1 based on the result of the smart contract execution described above (S213). At this time, the transaction management unit 31 stores the state information D12 in a data area for the evaluation execution transaction for each evaluation ID, which is prepared separately for the actual execution transaction. Further, the transaction management unit 31 adds the evaluation execution transaction and its execution result as the last block of the block chain D11.
  • the transaction management unit 31 returns the execution result of the evaluation execution transaction (for example, the return value of the function and the evaluation determination) to the transaction issuer (S214), and ends the process.
  • FIG. 7 is a diagram showing a flow of obtaining an evaluation execution transaction history by the reference API 34.
  • the reference API 34 receives an evaluation execution transaction history acquisition request issued from the client node 4 or the like (S301).
  • the contract ID of the SC to be acquired is always specified, and the calling function name, user, evaluation ID, and expected value may be specified as necessary.
  • the reference API 34 When the reference API 34 receives the above request, the reference API 34 acquires all the blocks storing the history of the evaluation execution transaction related to the designated SC from the block chain D11 of the distributed ledger D1 (S302).
  • reference API 34 groups the history of evaluation execution transactions acquired in S302 for each evaluation ID (S303).
  • the reference API 34 processes the history of evaluation execution transactions grouped in S303 (for example, as an array in JSON (Java Script (registered trademark) Object Notification) format) and returns it to the requesting node (S304). Exit.
  • JSON Java Script (registered trademark) Object Notification) format
  • the provider and the user can evaluate the transaction for the provided SC.
  • the evaluation result is managed together with the actual execution transaction in a series of BC data, and can be shared with other participants.
  • This mechanism allows the SC user to confirm / evaluate whether the SC can be trusted without control by the centralized authority.
  • the users of each node can confirm / evaluate the reliability of the SC at any time, there is also an effect of suppressing the provision of a poor quality SC by a malicious provider.
  • the reliability of the smart contract can be improved as compared with the conventional centralized evaluation method.
  • the sharing of information on the reliability has the effect of reducing labor compared to the case where a third party individually verifies the smart contract.
  • the evaluation execution transaction is identified, and the evaluation execution of the transaction using the same input as the production can be performed by using the same smart contract entity as the production on the data area different from the production execution transaction. This has the effect that the smart contract can be evaluated without contaminating the data of the actual execution transaction.
  • the smart contract evaluation management unit 35 uses the history D111 of the evaluation execution transaction on the block chain D11 to determine the degree to which the SC or the provider can be trusted.
  • a smart contract credit rating (hereinafter also referred to as SC credit rating), which is a quantitative indicator, is calculated, and the result is stored and retained on a smart contract credit calculation result D3 (hereinafter also referred to as SC credit calculation result D3).
  • SC credit rating which is a quantitative indicator
  • FIG. 8 is a flowchart showing an example of smart contract credit calculation processing based on the history of evaluation execution transactions.
  • the SC evaluation management unit 35 acquires all evaluation execution transaction histories for each SC from the block chain D11 of the distributed ledger D1 via the reference API 34 (S401). Taking FIG. 3 as an example, the block D114 and the like are acquired.
  • the SC evaluation management unit 35 calculates the SC credit of each function and the entire SC based on the information of the user (issuer) and the evaluation determination included in each evaluation execution transaction acquired in S401 ( S402).
  • the SC reliability for each function of each SC is obtained by the ratio of the number of cases where the evaluation judgment information is “OK” instead of “NG” in all cases of the evaluation execution transaction.
  • the evaluation performed by the user rather than the provider is regarded as a more objective and reliable evaluation and is weighted. For example, when the user of the evaluation execution transaction is not the provider of the smart contract, the weight is doubled.
  • the number of SC evaluation executions by “Manufacturer A” is 10, of which 10 are “OK” ⁇
  • the number of SC evaluations performed by “Transporter A” is 5, of which 4 are “OK” ⁇
  • the number of SC evaluations performed by “Transporter B” is 15, of which 13 are “OK”
  • the SC credit of each SC is obtained by the average value of the SC credit of each function calculated as described above.
  • the SC evaluation management unit 35 calculates the SC credit of the provider based on the SC credit calculation result for each SC provider (S403).
  • the calculation is performed based on an average value of SC credits for all SCs by a certain provider.
  • the SC evaluation management unit 35 stores the SC credit calculation result obtained as described above in the SC credit calculation result D3 (S404), and ends the process.
  • FIG. 9 shows an example of the data structure of the SC credit calculation result D3.
  • the calculation result of the SC reliability is held on the table in this way.
  • the trustworthiness D304 is managed in association with the SC provider D301, the SC contract ID (D302), and the function name D303.
  • the evaluator D305 information on the BC network member that performed the smart contract evaluation, that is, the credit calculation may be stored.
  • the row D311 indicates the SC reliability of a certain function
  • the row D312 indicates the SC reliability of a certain SC
  • the row D313 indicates the SC reliability of a certain provider.
  • the calculation is based on the ratio of “OK” as a simple example.
  • the calculation may be performed by multiplying the number of evaluations performed. Thereby, for example, when the evaluation is insufficient because the number of trials and tests is small, the reliability can be calculated to be lower.
  • Example 3 Next, an example in which transaction execution is controlled using the history of evaluation execution transactions will be described.
  • the configuration of the computer system as the distributed ledger system 10 in the present embodiment is the same as that in the first embodiment or the second embodiment described above.
  • SC reliability is used as a determination criterion for transaction execution control
  • the configuration of the second embodiment is used.
  • SC reliability is not used, the configuration of the first embodiment is used.
  • FIG. 10 is an example of a flowchart including the production execution determination process based on the evaluation status of the smart contract. Since this flowchart is almost the same as FIG. 6, only the difference will be described here.
  • the transaction management unit 31 determines whether or not production can be executed based on the evaluation status related to the SC (S216).
  • the transaction management unit 31 executes the actual execution transaction in the same manner as in S207 to S210.
  • the transaction management unit 31 does not perform the actual execution and cannot execute the transaction issuing node (for example, an error message). ) Is returned (S216), and the process is terminated.
  • the evaluation result (SC credit calculation result) of the smart contract or whether the evaluation execution transaction is already stored in the corresponding block chain can be used for the execution control of the transaction based on the trust of the smart contract. it can.
  • a queue with transaction priority is prepared between S201 and S202, and a transaction to be preferentially executed according to the evaluation status is conceivable.
  • Example 4 Next, an example of using not only the evaluation execution transaction but also the history of the actual execution transaction as a variation of the SC reliability calculation in the second embodiment will be described.
  • the configuration of the computer system as the distributed ledger system 10 in the present embodiment is the same as that in the second embodiment, and only the internal SC reliability calculation process is different.
  • FIG. 11 shows a flow example of smart contract credit calculation processing based on the history of each transaction of production execution and evaluation execution.
  • the expected value of the evaluation execution transaction is applied to the production execution transaction. Also consider the gap in expected values between evaluation execution transactions. As a precondition for the realization, it is possible to match evaluation executions or each transaction of evaluation execution and actual execution by partial matching.
  • the SC user designates an important argument that affects an expected value among input arguments at the time of issuance.
  • “cargo ID” among the input arguments is not important in the evaluation (that is, it may be an arbitrary value), and “humidity information” is important.
  • “cargo ID” among the input arguments is not important in the evaluation (that is, it may be an arbitrary value)
  • “humidity information” is important.
  • not a specific fixed value but a range of input values and input conditions may be defined for the input argument.
  • the SC evaluation management unit 35 acquires all the history of evaluation execution transactions and actual execution transactions for each SC from the block chain D11 of the distributed ledger D1 via the reference API 34 (S501). Same as S401 except that the actual execution transaction is also targeted.
  • the SC evaluation management unit 35 matches the evaluation execution transactions acquired in S501, extracts the conflicting expected values, and determines the minority by the majority of users who issued the conflicting transactions. The transaction is excluded from the transactions to be calculated (S502).
  • an evaluation execution transaction with an expected value “1000 ⁇ a penalty ⁇ 2000” is executed by the users “transporter A” and “manufacturer A” for the same input, and a transaction with an expected value “a penalty 0” Is executed by the user “transporter B”.
  • the SC evaluation management unit 35 excludes the latter transaction.
  • This method is an example for dealing with a case where expected values are contradictory, and weighting may be performed based on, for example, the user's own credit rating.
  • the SC evaluation management unit 35 matches the evaluation execution transaction and the production execution transaction, and evaluates the matched production execution transaction by applying the expected value of the evaluation execution (S503).
  • the SC evaluation management unit 35 determines the SC credit rating for each function and for the entire SC based on the user (issuer) included in the transaction used without being excluded in S502 to S503 and the evaluation determination information.
  • the SC credit of the provider is calculated (S504 to S505), and the result is stored in the SC credit calculation result D3 (S506). This process is the same as the process of S402 to S404 except that the transaction used as the calculation target is different.
  • the configuration of the computer system as the distributed ledger system 10 of the present embodiment is different in that the configuration of the smart contract monitoring unit 36 (hereinafter referred to as the SC monitoring unit 36) functions in the configurations of the first to fourth embodiments.
  • the SC monitoring unit 36 functions in the configurations of the first to fourth embodiments.
  • FIG. 12 is a flowchart showing an example of processing for monitoring the soundness and credibility of the SC by automatically issuing an evaluation execution transaction.
  • the SC monitoring unit 36 generates an evaluation execution transaction at every elapse of a predetermined time (S601: YES) (S602).
  • the target evaluation execution transaction may be defined in advance, or may be diverted by referring to the history of the evaluation execution transaction.
  • the important items of the input argument are defined for the evaluation execution transaction, or the range and the input condition for the input argument are defined, and the SC monitoring unit 36 automatically manages some information of the evaluation execution transaction. It may be generated. Furthermore, one or more evaluation execution transactions may be generated.
  • the SC monitoring unit 36 transmits the evaluation execution transaction generated in S602 to the transaction management unit 31 (S603).
  • the transaction management unit 31 receives the evaluation execution transaction transmitted in S603 and executes the SC according to the flow shown in FIG.
  • the SC monitoring unit 26 receives the execution result of the SC in the transaction management unit 31 (S604).
  • the SC monitoring unit 36 generates an alert and records a monitoring result based on the execution result obtained in S604 (S605). For example, when the evaluation determination in the execution result obtained in S604 is “NG”, the SC monitoring unit 36 performs, for example, alert notification to an external monitoring system and transmission of an alert mail to an operation manager or SC user.
  • a record of the monitoring result a record is generated from the execution date and time, “OK” and “NG” of the evaluation determination and the time taken for processing, and this is registered in a predetermined log management database or the like An analysis of an operation tendency such as a normal operation rate may be performed later.
  • FIG. 13 shows a configuration example in which each functional unit is arranged on a separate server.
  • each Example the example which the client node 4 and BC network participant respond
  • the present invention is not limited to such a configuration.
  • Each BC network participant may not have the client node 4, but each BC network participant may access the verification node 3 via the client node 4 by accessing the client node 4 from an external terminal.
  • the client node 4 may manage key information of a plurality of BC network participants.
  • an evaluation execution transaction may be realized as an option of the production execution transaction.
  • the present invention can also be realized by providing an evaluation ID and an expected value as information on an extended area of a production execution transaction, that is, information for identifying whether or not evaluation execution is performed and input information for evaluation execution.
  • an example in which various mechanisms for performing SC evaluation execution are realized as functions on the BC base side, but can also be created as functions on the SC side (internal functions or SC common parts).
  • an implementation method is conceivable in which a transaction having a specific identifier (for example, the beginning of user information starts with “test_”) is handled as an evaluation execution transaction.
  • certainty is lost as compared with the case where it is implemented by the function on the BC base side.
  • the provider implements and provides this function, the user cannot confirm the credibility.
  • the provider switches the internal logic according to this identifier, it cannot be detected. Furthermore, it becomes difficult to manage the data space for production and evaluation separately.
  • SC users can confirm / evaluate the reliability of the SC without management by the centralized authority.
  • Providing a mechanism that anyone can confirm / evaluate the credibility of the SC at any time has the effect of deterring poor quality SC provision by a malicious provider.
  • the reliability is improved because the third-party perspective is included compared to the conventional evaluation method that is centrally and unilaterally performed by a specific central organization.
  • the sharing of information on the reliability can reduce the labor compared with the case where a third party individually verifies.
  • the distributed ledger system includes a predetermined value for evaluation specified by a predetermined node and an output value when the predetermined value is input to the smart contract.
  • the verification result may be managed by being included in the evaluation execution transaction.
  • the distributed ledger system determines the credit regarding at least one of the smart contract execution transaction and other evaluation execution transactions based on a predetermined evaluation execution transaction included in the block chain. It is also possible to further execute processing that is calculated by an algorithm.
  • the distributed ledger system may further execute processing for controlling whether or not the smart contract can be executed according to the calculated high creditworthiness.
  • the distributed ledger system is configured so that at least one of the smart contract provider and the user registers the evaluation execution transaction in the block chain according to whether the evaluation execution transaction is registered. It is also possible to further execute a process for controlling execution.
  • the distributed ledger system may manage predetermined information regarding each of the execution transaction and the evaluation execution transaction in different data areas in the distributed ledger.
  • the distributed ledger system may automatically issue the evaluation execution transaction at a predetermined timing and execute the verification of the smart contract.
  • the distributed ledger system may preferentially process the execution transaction among the execution transaction and the evaluation execution transaction within a predetermined period.
  • each of the nodes includes a predetermined value for evaluation specified by a predetermined node and an output value when the predetermined value is input to the smart contract. May be included in the evaluation execution transaction for management.
  • At least one of the nodes has a credit quality related to at least one of the smart contract execution transaction and other evaluation execution transactions based on a predetermined evaluation execution transaction included in the block chain. It is good also as what further performs the process calculated by a predetermined algorithm.
  • At least one of the nodes may further execute a process for controlling whether or not the smart contract can be executed according to the calculated high degree of trust.
  • At least one of the nodes is configured according to whether the evaluation execution transaction is registered in the block chain by at least one of a provider and a user of the smart contract. It is also possible to further execute a process for controlling whether or not to execute.
  • each of the nodes may manage predetermined information regarding each of the execution transaction and the evaluation execution transaction in different data areas in the distributed ledger.
  • At least one of the nodes may automatically issue the evaluation execution transaction at a predetermined timing and execute the verification of the smart contract.
  • At least one of the nodes may process the execution transaction preferentially among the execution transaction and the evaluation execution transaction within a predetermined period.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
PCT/JP2018/001320 2017-02-06 2018-01-18 信用度管理システムおよび信用度管理方法 Ceased WO2018142948A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/483,486 US11102001B2 (en) 2017-02-06 2018-01-18 Trust management system and trust management method
SG11201907267VA SG11201907267VA (en) 2017-02-06 2018-01-18 Trust management system and trust management method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-019531 2017-02-06
JP2017019531A JP6931999B2 (ja) 2017-02-06 2017-02-06 信用度管理システムおよび信用度管理方法

Publications (1)

Publication Number Publication Date
WO2018142948A1 true WO2018142948A1 (ja) 2018-08-09

Family

ID=63040554

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/001320 Ceased WO2018142948A1 (ja) 2017-02-06 2018-01-18 信用度管理システムおよび信用度管理方法

Country Status (4)

Country Link
US (1) US11102001B2 (enExample)
JP (1) JP6931999B2 (enExample)
SG (1) SG11201907267VA (enExample)
WO (1) WO2018142948A1 (enExample)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109544354A (zh) * 2018-10-19 2019-03-29 中国平安人寿保险股份有限公司 基于区块链的再保结算方法、电子装置及可读存储介质
CN109741155A (zh) * 2019-01-29 2019-05-10 长沙理工大学 一种电力余量交易方法及相关装置
CN110519246A (zh) * 2019-08-15 2019-11-29 安徽师范大学 基于信任区块链节点的信任度计算方法
WO2019101237A3 (en) * 2019-03-06 2019-12-26 Alibaba Group Holding Limited Managing housing scores using smart contracts in blockchain networks
EP3680777A1 (en) 2019-01-11 2020-07-15 Fujitsu Limited Communication device and communication method used in distributed computing environment
WO2020206956A1 (zh) * 2019-04-09 2020-10-15 苏宁云计算有限公司 一种智能合约的管理方法及系统
US10861039B2 (en) * 2017-04-12 2020-12-08 Royal Bank Of Canada Bid platform
CN112561624A (zh) * 2020-11-06 2021-03-26 国网安徽省电力有限公司信息通信分公司 一种基于区块链的多维度因子的动态信用评价方法及系统
JPWO2021125109A1 (enExample) * 2019-12-19 2021-06-24
JP2021136470A (ja) * 2020-02-21 2021-09-13 株式会社LayerX データ管理方法
EP3837660A4 (en) * 2018-08-17 2022-03-30 Telefonaktiebolaget LM ERICSSON (PUBL) METHOD AND SYSTEM FOR PREDICTING VIOLATIONS OF INTELLIGENT CONTRACTS USING DYNAMIC STATE SPACE GENERATION
US20220138848A1 (en) * 2020-11-05 2022-05-05 Hitachi, Ltd. Electronic trading system and data concealment method for electronic trading system
JP2022530582A (ja) * 2019-06-28 2022-06-30 ビートダップ ソフトウェア インク． ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法
US12289381B2 (en) 2019-06-28 2025-04-29 Beatdapp Software, Inc. System and method for continuous tracking of media playback using blockchain
WO2025203636A1 (ja) * 2024-03-29 2025-10-02 株式会社Ｎｔｔドコモ ランキング装置及びランキング方法

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10810004B2 (en) 2017-06-30 2020-10-20 Oracle International Corporation System and method for managing a public software component ecosystem using a distributed ledger
GB2561935B (en) * 2017-11-24 2019-05-22 Zeetta Networks Ltd A system for providing an end-to-end network
MX2020007773A (es) * 2018-01-22 2020-10-28 Grainchain Inc Sistema y metodo para sistema informatico seguro, distribuido.
US12093908B2 (en) * 2018-03-22 2024-09-17 NEC Laboratories Europe GmbH System and method for secure transaction verification in a distributed ledger system
US10796022B2 (en) * 2018-05-16 2020-10-06 Ebay Inc. Weighted source data secured on blockchains
CN109146679B (zh) * 2018-06-29 2023-11-10 创新先进技术有限公司 基于区块链的智能合约调用方法及装置、电子设备
CN108964924B (zh) * 2018-07-24 2020-06-05 腾讯科技（深圳）有限公司 数字证书校验方法、装置、计算机设备和存储介质
JP7195016B2 (ja) * 2018-08-24 2022-12-23 株式会社Standage トランザクション処理方法、システムおよびプログラム
JP7098734B2 (ja) * 2018-08-29 2022-07-11 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 ブロックチェーンシステム、及びブロックチェーンシステムの制御方法
JP7320099B2 (ja) * 2018-08-29 2023-08-02 ｄｏｕｂｌｅ ｊｕｍｐ．ｔｏｋｙｏ株式会社 ブロックチェーンシステム、及びブロックチェーンシステムの制御方法
KR102116373B1 (ko) * 2018-08-30 2020-06-03 에이치닥 테크놀로지 아게 가상기계를 이용한 스마트 컨트랙트 시스템 및 그 처리 방법
JP7062571B2 (ja) * 2018-10-05 2022-05-06 株式会社日立製作所 組織管理支援システム、組織管理支援方法、および、組織管理支援装置
US11303442B2 (en) * 2018-10-09 2022-04-12 International Business Machines Corporation Blockchain notification board storing blockchain resources
US11520773B2 (en) 2018-10-09 2022-12-06 International Business Machines Corporation Blockchain notification board storing blockchain resources
KR102131292B1 (ko) * 2018-10-19 2020-07-07 빅픽처랩 주식회사 블록체인 기반 신뢰도 정보 관리방법
JP7181455B2 (ja) * 2018-11-13 2022-12-01 日本電信電話株式会社 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
JP7504804B2 (ja) * 2018-12-11 2024-06-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ データ管理方法、データ管理システム及びプログラム
KR102152360B1 (ko) * 2018-12-28 2020-09-04 달리웍스 주식회사 IoT 서비스를 위한 블록체인 기반 데이터 신뢰성 제공 시스템 및 방법
JP2020113209A (ja) * 2019-01-16 2020-07-27 株式会社Ｌｃｎｅｍ 情報処理システム
JP7257172B2 (ja) * 2019-02-14 2023-04-13 富士通株式会社 通信プログラム、通信装置、および、通信方法
CN110009513A (zh) * 2019-02-18 2019-07-12 平安科技（深圳）有限公司 针对相互保险的理赔方法、装置、设备及可读存储介质
JP7171469B2 (ja) * 2019-02-22 2022-11-15 株式会社日立製作所 構成変更管理方法、構成変更管理システム、およびノード
JP7231449B2 (ja) * 2019-03-18 2023-03-01 株式会社日立製作所 信用分析支援方法、信用分析支援システム、およびノード
JP7137077B2 (ja) * 2019-04-02 2022-09-14 日本電信電話株式会社 ブロックチェーンシステム、承認端末、利用者端末、履歴管理方法、および、履歴管理プログラム
JP7316081B2 (ja) * 2019-04-03 2023-07-27 株式会社日立製作所 分散台帳装置、分散台帳システム、及び分散台帳管理方法
JP7221799B2 (ja) * 2019-05-31 2023-02-14 株式会社日立製作所 情報処理システム、及び情報処理システムの制御方法
WO2019179533A2 (en) 2019-07-02 2019-09-26 Alibaba Group Holding Limited System and method for issuing verifiable claims
WO2019179535A2 (en) 2019-07-02 2019-09-26 Alibaba Group Holding Limited System and method for verifying verifiable claims
CN111213147B (zh) 2019-07-02 2023-10-13 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
CN111164594B (zh) * 2019-07-02 2023-08-25 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
US11057189B2 (en) * 2019-07-31 2021-07-06 Advanced New Technologies Co., Ltd. Providing data authorization based on blockchain
US11251963B2 (en) 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Blockchain-based data authorization method and apparatus
US11252166B2 (en) 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Providing data authorization based on blockchain
CN110602236B (zh) * 2019-09-20 2021-12-14 腾讯科技（深圳）有限公司 节点控制方法、节点控制设备及存储介质
CN110688677B (zh) * 2019-09-24 2020-12-22 北京海益同展信息科技有限公司 用于执行智能合约的方法和装置
CN110688428B (zh) * 2019-09-24 2021-01-26 北京海益同展信息科技有限公司 用于发布智能合约的方法和装置
CN110659907B (zh) 2019-09-24 2021-11-12 北京海益同展信息科技有限公司 用于执行智能合约的方法和装置
KR102269174B1 (ko) * 2019-10-07 2021-06-24 고려대학교 산학협력단 스마트 컨트랙트 검증 장치 및 방법
JP7273312B2 (ja) 2019-11-12 2023-05-15 富士通株式会社 通信プログラム、通信方法および通信装置
EP4084398A4 (en) 2019-12-26 2023-01-04 Fujitsu Limited TRANSMISSION CONTROL METHOD, TRANSMISSION CONTROL PROGRAM AND INFORMATION PROCESSING DEVICE
US11310051B2 (en) 2020-01-15 2022-04-19 Advanced New Technologies Co., Ltd. Blockchain-based data authorization method and apparatus
JP7384044B2 (ja) * 2020-01-16 2023-11-21 富士通株式会社 検証方法、検証装置及び検証プログラム
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities
JP7473911B2 (ja) * 2020-04-21 2024-04-24 清水建設株式会社 施工情報管理システム、及び施工情報管理方法
CN111581280A (zh) * 2020-04-23 2020-08-25 傲林科技有限公司 一种基于区块链的业务处理方法、装置及存储介质
EP4141773A4 (en) 2020-04-24 2023-06-07 Fujitsu Limited CONTROL METHOD, CONTROL PROGRAM AND CONTROL DEVICE
KR102378377B1 (ko) * 2020-11-13 2022-03-24 고려대학교 산학협력단 스마트 컨트랙트 내의 취약 트랜잭션 시퀀스 획득 장치 및 방법
CN112651741B (zh) 2021-01-04 2024-06-18 北京京东乾石科技有限公司 基于区块链的数据处理方法和装置
CN114371917A (zh) * 2022-01-07 2022-04-19 中国工商银行股份有限公司 基于区块链的需求处理方法、系统、存储介质及电子设备
US20230412386A1 (en) * 2022-06-15 2023-12-21 The Johns Hopkins University Distributed Ledgers for Enhanced Machine-to-Machine Trust in Smart Cities
CN116151826B (zh) * 2023-04-04 2023-08-01 广东电力交易中心有限责任公司 一种基于区块链的电力交易终端信任管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150332283A1 (en) * 2014-05-13 2015-11-19 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain proof-of-work, systems and methods
JP2016170530A (ja) * 2015-03-11 2016-09-23 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法
JP2017220710A (ja) * 2016-06-03 2017-12-14 日本電信電話株式会社 契約合意方法、合意検証方法、契約合意装置および合意検証装置
JP2018036893A (ja) * 2016-08-31 2018-03-08 ヤフー株式会社 生成プログラム、生成装置及び生成方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017019488A1 (en) * 2015-07-24 2017-02-02 Castor Pollux Holdings SARL Device, system, and method for transfer of commodities
DE102015114215A1 (de) * 2015-08-27 2017-03-02 Rwe Ag Versorgungssystem und verfahren zum betreiben eines versorgungssystems
US10762504B2 (en) * 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
US10346428B2 (en) * 2016-04-08 2019-07-09 Chicago Mercantile Exchange Inc. Bilateral assertion model and ledger implementation thereof
US11128603B2 (en) * 2016-09-30 2021-09-21 Nec Corporation Method and system for providing a transaction forwarding service in blockchain implementations
US10715331B2 (en) * 2016-12-28 2020-07-14 MasterCard International Incorported Method and system for providing validated, auditable, and immutable inputs to a smart contract

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150332283A1 (en) * 2014-05-13 2015-11-19 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain proof-of-work, systems and methods
JP2016170530A (ja) * 2015-03-11 2016-09-23 株式会社Ｏｒｂ 仮想通貨管理プログラム、及び仮想通貨管理方法
JP2017220710A (ja) * 2016-06-03 2017-12-14 日本電信電話株式会社 契約合意方法、合意検証方法、契約合意装置および合意検証装置
JP2018036893A (ja) * 2016-08-31 2018-03-08 ヤフー株式会社 生成プログラム、生成装置及び生成方法

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10861039B2 (en) * 2017-04-12 2020-12-08 Royal Bank Of Canada Bid platform
US12475471B2 (en) 2018-08-17 2025-11-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for prediction of smart contract violation using dynamic state space creation
EP3837660A4 (en) * 2018-08-17 2022-03-30 Telefonaktiebolaget LM ERICSSON (PUBL) METHOD AND SYSTEM FOR PREDICTING VIOLATIONS OF INTELLIGENT CONTRACTS USING DYNAMIC STATE SPACE GENERATION
CN109544354A (zh) * 2018-10-19 2019-03-29 中国平安人寿保险股份有限公司 基于区块链的再保结算方法、电子装置及可读存储介质
CN109544354B (zh) * 2018-10-19 2024-06-11 中国平安人寿保险股份有限公司 基于区块链的再保结算方法、电子装置及可读存储介质
US11150942B2 (en) 2019-01-11 2021-10-19 Fujitsu Limited Communication device and communication method used in distributed computing environment
EP3680777A1 (en) 2019-01-11 2020-07-15 Fujitsu Limited Communication device and communication method used in distributed computing environment
CN109741155A (zh) * 2019-01-29 2019-05-10 长沙理工大学 一种电力余量交易方法及相关装置
WO2019101237A3 (en) * 2019-03-06 2019-12-26 Alibaba Group Holding Limited Managing housing scores using smart contracts in blockchain networks
US10984492B2 (en) 2019-03-06 2021-04-20 Advanced New Technologies Co., Ltd. Managing housing scores using smart contracts in blockchain networks
WO2020206956A1 (zh) * 2019-04-09 2020-10-15 苏宁云计算有限公司 一种智能合约的管理方法及系统
JP7576244B2 (ja) 2019-06-28 2024-10-31 ビートダップ ソフトウェア インク． ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法
JP7727946B2 (ja) 2019-06-28 2025-08-22 ビートダップ ソフトウェア インク． ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法
US12489825B2 (en) 2019-06-28 2025-12-02 Beatdapp Software Inc. System and method for scalably tracking media playback using blockchain
US12289381B2 (en) 2019-06-28 2025-04-29 Beatdapp Software, Inc. System and method for continuous tracking of media playback using blockchain
US12155736B2 (en) 2019-06-28 2024-11-26 Beatdapp Software Inc. System and method for scalably tracking media playback using blockchain
JP2022530582A (ja) * 2019-06-28 2022-06-30 ビートダップ ソフトウェア インク． ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法
JP2023162204A (ja) * 2019-06-28 2023-11-08 ビートダップ ソフトウェア インク． ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法
CN110519246B (zh) * 2019-08-15 2021-09-28 安徽师范大学 基于信任区块链节点的信任度计算方法
CN110519246A (zh) * 2019-08-15 2019-11-29 安徽师范大学 基于信任区块链节点的信任度计算方法
JPWO2021125109A1 (enExample) * 2019-12-19 2021-06-24
JP7576566B2 (ja) 2019-12-19 2024-10-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、装置、及び、プログラム
WO2021125109A1 (ja) * 2019-12-19 2021-06-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、装置、及び、プログラム
JP2021136470A (ja) * 2020-02-21 2021-09-13 株式会社LayerX データ管理方法
US20220138848A1 (en) * 2020-11-05 2022-05-05 Hitachi, Ltd. Electronic trading system and data concealment method for electronic trading system
CN112561624B (zh) * 2020-11-06 2024-01-05 国网安徽省电力有限公司信息通信分公司 一种基于区块链的多维度因子的动态信用评价方法及系统
CN112561624A (zh) * 2020-11-06 2021-03-26 国网安徽省电力有限公司信息通信分公司 一种基于区块链的多维度因子的动态信用评价方法及系统
WO2025203636A1 (ja) * 2024-03-29 2025-10-02 株式会社Ｎｔｔドコモ ランキング装置及びランキング方法

Also Published As

Publication number Publication date
US11102001B2 (en) 2021-08-24
JP6931999B2 (ja) 2021-09-08
SG11201907267VA (en) 2019-09-27
JP2018128723A (ja) 2018-08-16
US20200021439A1 (en) 2020-01-16

Similar Documents

Publication Publication Date Title
JP6931999B2 (ja) 信用度管理システムおよび信用度管理方法
JP7429755B2 (ja) 検査システム、検査方法、およびコンピュータプログラム
US11599555B2 (en) Data manifest as a blockchain service
US11562228B2 (en) Efficient verification of machine learning applications
Malik et al. Trustchain: Trust management in blockchain and iot supported supply chains
US10942994B2 (en) Multicomputer processing for data authentication using a blockchain approach
US12348642B2 (en) Token-based identity validation via blockchain
KR102173426B1 (ko) Did 환경의 프라이버시 보호를 지원하는 공개키 인프라구조 기반 서명 및 검증 시스템과 방법
de Azevedo Sousa et al. An analysis of the fees and pending time correlation in Ethereum
US11159537B2 (en) Multicomputer processing for data authentication and event execution using a blockchain approach
US11423409B2 (en) Electronic transaction device, electronic transaction verification device, and electronic transaction method
US20200394552A1 (en) Aggregated maching learning verification for database
US20130290226A1 (en) System and method for social graph and graph assets valuation and monetization
US11874804B2 (en) Load balancing based blockchain transaction submission
US20240289783A1 (en) Systems and methods for verifying cryptographically secured communications between users using non-transferable tokens
US12265628B2 (en) Secure device validator ledger
CN113487436B (zh) 业务处理的方法、装置、电子设备和存储介质
US20250343768A1 (en) Systems and methods for executing multi-party validations for complex communications across multiple computer networks using bifurcated digital signing processes
EP3542300B1 (en) Method for operating a peer-to-peer application
JP2020204898A (ja) 分散台帳システムの運用管理方法、分散台帳システムの運用管理システム、および分散台帳システムの運用管理プログラム
US11854101B1 (en) Systems, methods, and storage media for interfacing at least one smart contact stored on a decentralized architecture with external data sources
EP3761207B1 (en) Method for entrusting blockchain operations contents
CN111656804B (zh) 分布式系统的监测
CN112926979A (zh) 结合区块链通信的支付信息处理方法及区块链信息平台
CN111553683B (zh) 具有智能合同的可验证分析学平台

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18748121

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18748121

Country of ref document: EP

Kind code of ref document: A1