WO2021156909A1 - スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード - Google Patents

スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード Download PDF

Info

Publication number
WO2021156909A1
WO2021156909A1 PCT/JP2020/003904 JP2020003904W WO2021156909A1 WO 2021156909 A1 WO2021156909 A1 WO 2021156909A1 JP 2020003904 W JP2020003904 W JP 2020003904W WO 2021156909 A1 WO2021156909 A1 WO 2021156909A1
Authority
WO
WIPO (PCT)
Prior art keywords
flow
smart contract
flow data
node
nodes
Prior art date
Application number
PCT/JP2020/003904
Other languages
English (en)
French (fr)
Inventor
悠介 新井
洋司 小澤
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2020/003904 priority Critical patent/WO2021156909A1/ja
Publication of WO2021156909A1 publication Critical patent/WO2021156909A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms

Definitions

  • the present invention relates to a smart contract execution method, a smart contract execution system, and a node.
  • Distributed ledger technology as a technology to replace transactions between related parties, which have been conventionally carried out via centralized institutions such as financial institutions and governments, with direct transactions by P2P (Peer to Peer) between related parties.
  • So-called blockchain: Blockchain is utilized.
  • Bitcoin is a kind of virtual currency.
  • Such distributed ledger technology is applied in a wide range of fields such as the financial field and IoT (Internet of Things) as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts in a decentralized manner. Is being considered.
  • IoT Internet of Things
  • the main features of the current blockchain are: (1) In transactions between participants on the blockchain network, the transactions are finalized by consensus building and approval by the participants (voluntary or specific) rather than the centralized authority. , (2) Collect multiple transactions as blocks, record them in a chain of beads in a distributed ledger, and perform hash calculation on consecutive blocks to make tampering virtually impossible. (3) All participants are the same. By sharing the distributed ledger, it is possible for all participants to confirm the transaction.
  • smart contract since the distributed ledger technology can be applied not only to virtual currency transactions but also to complex transaction conditions and various applications, it is possible to manage not only (transaction) data but also transaction-related logic in the distributed ledger. It is becoming. This logic is called a smart contract (hereinafter also abbreviated as smart contract).
  • the above-mentioned smart contract has the characteristic of describing transaction logic among multiple participants, and unlike a program that describes ordinary logic, it is necessary for participants to mutually check the quality and form consensus on the content. There is. In addition, the quality check must be particularly strict due to the characteristics that the execution trail of the smart contract is stored in the distributed ledger that cannot be tampered with.
  • Non-Patent Document 1 a technology of calling another smart contract from the main smart contract.
  • the smart contract has been successfully made into a component, but the program part and the business logic part of the smart contract are not separated. Therefore, when registering or renewing a smart contract, quality check and approval work for both the business logic part and the program part are required.
  • an object of the present invention is to provide a technique capable of efficiently managing and executing a smart contract by accurately responding to a situation in which business logic registration or renewal occurs frequently in the smart contract. To do.
  • each node constituting the blockchain system manages flow data composed of connections of functional nodes in which business logic is described in a distributed ledger, and is predetermined.
  • the transaction is characterized in that the corresponding flow data is read from the distributed ledger and the smart contract is executed according to the flow data.
  • the smart contract execution system of the present invention is a blockchain system composed of a plurality of nodes, and each of the plurality of nodes is composed of a connection of functional nodes in which business logic is described in a distributed ledger. It is characterized in that it manages the flow data, reads the corresponding flow data from the distributed ledger for a predetermined transaction, and executes a smart contract according to the flow data.
  • the node of the present invention is a node constituting a blockchain system, manages flow data composed of a connection of functional nodes in which business logic is described in a distributed ledger, and handles a predetermined transaction. It is characterized in that the flow data to be executed is read from the distributed ledger and the smart contract is executed according to the flow data.
  • FIG. It is a figure which shows the configuration example of the smart contract execution system in Example 1.
  • FIG. It is a figure which shows the hardware configuration example of the node in Example 1.
  • FIG. It is a figure which shows the flow creation screen example in Example 1.
  • FIG. It is a figure which shows the example of the flow table in Example 1.
  • FIG. It is a figure which shows the example of the functional node table in Example 1.
  • FIG. It is a figure which shows the example of the flow management transaction in Example 1.
  • FIG. It is a figure which shows an example of the flow management ledger in Example 1.
  • FIG. It is a figure which shows an example of the flow execution transaction in Example 1.
  • FIG. It is a figure which shows an example of the state management ledger in Example 1.
  • FIG. It is a figure which shows an example of the blockchain data in Example 1.
  • FIG. 1 It is a figure which shows the flow example of the flow execution smartphone in Example 1.
  • FIG. It is a figure which shows an example of the approval transaction in Example 2.
  • FIG. It is a figure which shows an example of the flow approval screen in Example 2.
  • FIG. It is a figure which shows an example of the flow management ledger in Example 2.
  • FIG. It is a figure which shows the flow example of the flow management smart phone in Example 2.
  • FIG. It is a figure which shows the example of the automatic approval flow in Example 3.
  • FIG. 1 is a diagram showing a network configuration example of the smart contract execution system 10 in the first embodiment. It is assumed that the smart contract execution system 10 is a blockchain system and is composed of a plurality of nodes 100, 200, 300, .... Hereinafter, unless otherwise specified, node 100 will be used in the description as a representative example of each node.
  • the node 100 is mainly composed of a smart contract execution unit 110 (in the figure, a smart contract execution unit; hereinafter, a smart contract execution unit), a distributed ledger 150, and a communication unit 160.
  • a smart contract execution unit 110 in the figure, a smart contract execution unit; hereinafter, a smart contract execution unit
  • a distributed ledger 150 a distributed ledger
  • a communication unit 160 The same configuration is used for the node 200 and the node 300.
  • the smartphone execution unit 110 is composed of a flow execution smartphone 120, a function node execution smartphone 130, and a flow management smartphone 140. It is assumed that these smartphones are shared between the nodes.
  • the functional node execution smartphone 130 is defined according to the function of each of a series of nodes in the flow data in which the business logic is described. Further, the flow execution smartphone 120 and the flow management smartphone 140 may also be divided according to the function. The functional node smartphone may be integrated into the flow execution smartphone.
  • the distributed ledger 150 held by the node 100 includes a flow management ledger T10, a state management ledger T20, and a blockchain table T30. Details of these will be described later.
  • the node 100 communicates with the client application 170 by the communication unit 160.
  • the client application 170 is an application provided in a client terminal that transmits various requests to a node 100, which is a distributed ledger node, and obtains answers corresponding to the requests.
  • a user such as a company that operates a node 100 operates a client terminal to access the node 100 and obtains necessary information through a predetermined process.
  • FIG. 2 shows an example of hardware configuration of the node 100 constituting the smart contract execution system 10.
  • the node 100 reads into the memory 103 a storage device 101 composed of an appropriate non-volatile storage element such as a hard disk drive, a memory 103 composed of a volatile storage element such as RAM, and a program 102 held in the storage device 101.
  • a computing device 104 that executes and performs integrated control of the system itself and performs various determinations, calculations, and control processes, and a communication device 105 that is connected to the network 1 and is responsible for communication processing with other nodes.
  • the storage device 101 stores the above-mentioned distributed ledger 150.
  • the client application 170 sends a transaction to each node.
  • the communication unit 160 of each node receives the transaction, and the smart contract specified by the transaction is executed by the smart contract execution unit 110.
  • the business logic defined in the flow format is read from the flow management ledger T10 of the distributed ledger 150 at the time of executing the smart contract, and the flow execution smartphone computer is executed according to the flow. It is assumed that 120 is executed and the result is saved in the state management ledger T20.
  • FIG. 3 is a diagram showing an example of the flow creation screen in the first embodiment.
  • a flow is represented by a functional node, which is a unit that performs a certain process in business logic, and its connection.
  • the flow F10 is an example of the flow, and is composed of four functional nodes F11, F12, F13, and F14.
  • the flow data configured in this way is referred to as flow data.
  • the functional node F11 is an input node A, which is a functional node that processes some input received from a transaction.
  • the function node F12 is a conditional branch node B that makes some determination such as a threshold value determination and a magnitude determination with respect to the input received from the function node F11 which is an input node.
  • the result of the determination in the function node F12 is "True”
  • the output node of the function node F13 is processed
  • if it is "False” the output node of the function node F14 is processed.
  • output nodes C and D of the functional nodes F13 and F14 are functional nodes having a function of outputting some data on the blockchain.
  • the user who creates such a flow can intuitively create the flow by using the GUI tool for creating the flow provided by the above-mentioned client application 170.
  • the flow creation screen which is a function of the client application 170 shown in FIG. 3, is composed of a function node list F15 and a flow editing screen F16.
  • the function node list F15 displays the objects of the function nodes according to the type of the function node execution smartphone 130, and receives operations such as drag and drop by the user.
  • the client application 170 instantiates the object of the function node to be operated on the flow edit screen F16.
  • the function nodes instantiated from the function node list F15 are arranged and displayed by the above-mentioned user operation, and the creation of a flow combining each function node is supported.
  • the above-mentioned user performs a predetermined operation on one function node and the other function node on the flow edit screen F16 to connect the instantiated function nodes to form a flow. Can be done. Further, the user can perform detailed settings such as parameter setting of the function node by performing an operation such as clicking a desired function node on the flow edit screen F16.
  • the flow data created by the user in this way that is, the flow data is stored in the flow management ledger T10 of the node 100 from the client application 170. Further, the flow data saved in the flow management ledger T10 is called from the flow execution smartphone 120 by another user.
  • FIG. 4 is a diagram showing an example in which the flow in the first embodiment is represented in a table format, that is, the flow table T40.
  • This flow table T40 is a table of the flow F10 of FIG.
  • the components of the flow table T40 are an index T41, a functional node name T42, a functional node type T43, its parameters T44, and a T45 representing the functional node to be executed next.
  • T46 which expresses the function of each functional node in natural language, is added as needed.
  • the input node A is a functional node that acquires the login information of the user for one week, and is connected to the conditional branch node B.
  • FIG. 5 is a diagram showing an example of a functional node in the first embodiment, that is, a functional node table T50.
  • the entity of the function node is implemented as a function node execution smart contract for each type. Alternatively, it is executed as a part of the flow execution smartphone.
  • This functional node execution smart contract is called from the main flow execution smart contract according to the flow, executes processing according to the input and parameters, and outputs the result to the next node.
  • the function node table T50 is a table showing the details of the function nodes used in the flow of FIG.
  • the components of the functional node table T50 are an index T51, a functional node type T52, a parameter T53, an input T54, an output T55, and a processing content T56.
  • the parameter T53 is set according to the type of functional node, such as the threshold threshold for the conditional branch node and point for the output node, and the value can be changed depending on the functional node instantiated.
  • the input T54 and the output T55 each represent data to be passed between the functional nodes.
  • the processing content T56 is originally written in a programming language, etc., but here it is written in a natural language because it is easy to understand. In this processing content T56, the processing content from receiving the input T53 to outputting the output T55 is described, and the parameter T53 that can be set for each functional node can be used on the way.
  • conditional branch node parameter "threshold” represents the number of days used in the continuous login determination
  • output node parameter "point” represents the amount of points given to the user.
  • FIG. 6 is a table showing an example of the flow management transaction T60 in the first embodiment.
  • the flow management transaction T60 is a transaction for managing the life cycle of the flow, which is issued by the user when the flow is registered and updated in the distributed ledger 150 or deleted from the distributed ledger 150.
  • Such a flow management transaction T60 is composed of a function name T61, a flow name T62, a flow version T63, and flow data T64.
  • the function name T61 can be assumed to be "register” for newly registering a flow, "update” for updating a created flow, “delete” for deleting a flow, and the like.
  • the flow name T62 is a unique name called from the flow execution smartphone 120
  • the version T63 is a numerical value indicating the update information. The values of such version T63 are basically added for each update.
  • the flow data T64 is an object in which the table T40 representing the flow is structured in the json format.
  • FIG. 7 shows an example of the flow management ledger T10 in the first embodiment.
  • the flow management ledger T10 illustrated is a database that reliably shares the flow registered or updated by the user as data in the blockchain between the nodes by the flow management transaction.
  • the components of this flow management ledger T10 are composed of an index T11, a flow name T12, a version T13, and a flow data T14. Similar to the flow management ledger T60 in FIG. 6, the flow name T12 is a unique name called from the flow execution smartphone 120, the version T13 is a numerical value representing the update information, and the flow data T14 is a json format of the table T40 representing the flow. It is an object structured with.
  • FIG. 8 shows an example of the flow execution transaction T70 in the first embodiment.
  • the flow execution smartphone 120 reads out the flow stored in the flow management ledger T10, and of each functional node described in the flow.
  • the function node execution smartphone 130 will be called.
  • the flow execution transaction T70 is composed of a function name T71, a flow name T72, a version T73, and an argument T74 required for the flow.
  • the flow name T72 and version T73 specify the name and version of the flow to be executed. If the specified name and version of the flow does not exist in the flow management ledger T10, the flow execution transaction T70 will return an error. On the other hand, when the specified flow exists, the flow execution smartphone 120 reads the corresponding flow from the flow management ledger T10.
  • the flow argument T74 is an array or table of inputs required to execute the flow.
  • the flow argument T74 is a unique number for each flow, and the data type is also different.
  • the user name and the weekly login information of the user are specified as the arguments of the flow required for the input of the input node A in the flow table T40 of FIG.
  • FIG. 9 shows an example of the state management ledger T20 in the first embodiment.
  • the state management ledger T20 is a database that reliably shares data created and updated by the flow called by the flow execution transaction T70 issued by the user among the nodes.
  • the state management ledger T20 does not have a specific size or type, and can be freely designed according to the use case. Since this embodiment is a use case for changing the points possessed by the user, the state management ledger T20 is composed of the index T21, the user name T22, and the user possessed points T23.
  • FIG. 10 is a diagram showing an example of the blockchain data T30 in the first embodiment.
  • the blockchain data T30 stores the execution history of the transaction processed by each node.
  • the blockchain data T30 collectively defines the execution history of a plurality of transactions as a block, and by adding the hash value of that block to the data of the next block, adjacent blocks are connected like a chain by hashing. , It is a database that is difficult to tamper with.
  • Such blockchain data T30 includes index T31, transaction ID: T32, time stamp T33, smart contract type T34 to be executed, function name T35 in the smartphone, argument T36 of the function, and data read from the distributed ledger 150 when the smartphone is executed. It is composed of Rset (Read set) T37 representing the above and Wset (Write set) T38 representing the data written in the distributed ledger 150 at the time of executing the smart contract.
  • the transaction ID T32 is a value that is automatically assigned when the block is created, and is a unique value for the transaction. Further, the time stamp T33 describes the time when the transaction is completed.
  • the smart contract type T34 either the flow management smart contract 140 or the flow execution smart contract 120 is specified as the smart contract type in this embodiment. If the function name T35 is the flow management smartphone 140, the deleter, update, delete, etc. shown by the function name T61 of the flow management transaction T60 in FIG. 6 are set. Further, in the case of the flow execution smartphone 120, the “execution” indicated by the function name T71 in the flow execution transaction T70 in FIG. 8 is set.
  • the flow execution smartphone 120 also defines an init function for data initialization that does not use a flow, and the user data is initialized by executing it first.
  • the function argument T36 collectively describes the data corresponding to the flow name T62, the version T63, and the flow data T64 in FIG. 6 in json format or the like. Further, in the flow execution smartphone 120, the data corresponding to the flow name T72, the version T73, and the flow argument T74 in the flow execution transaction T70 of FIG. 8 are collectively described.
  • Rset (T37) and Wset (T38) are data recorded when reading and writing the distributed ledger 150 when the smartphone is executed.
  • the Rset and Wset are data for determining whether or not each node has performed the same processing and for forming a correct consensus.
  • Rset saves the key when reading the data of the distributed ledger 150
  • Wset saves the key value when writing to the distributed ledger 150.
  • data of the distributed ledger 150 in which the trail is stored in Rset and Wset there is also a flow management ledger T10 in addition to the state management ledger T20.
  • the key that uniquely represents the flow which is a combination of the name and version of the flow, is stored in Rset, so that the executed flow can be uniquely specified.
  • the data by the flow management smartphone 140 and the data by the flow execution smartphone 120 are managed by the same blockchain T30, but they may be managed by different blockchains.
  • FIG. 11 is a flowchart showing an example of processing of the flow execution smartphone 120 in the first embodiment.
  • the flow execution smartphone 120 receives the values of the flow name T72, the version T73, and the flow argument T74 as inputs from the flow execution transaction T70 issued by the user (s101).
  • the flow execution smartphone 120 searches the flow management ledger T10 for a matching flow with respect to the flow name and version obtained in s101 (s102). As a result of this search, if the corresponding flow is not hit (s102: No), the flow execution smartphone 120 ends with an error.
  • the flow execution smartphone 120 reads the corresponding flow data from the flow management ledger T10 (s103). At this time, the flow execution smartphone 120 stores the key of the flow data in the Rset of the transaction execution result.
  • the flow execution smartphone 120 sets the flow argument T74 obtained in s101 to the first functional node of the flow data read in s103 (s104), and sequentially executes the functional nodes according to the processing of the flow. Therefore, the function node execution smartphone 130 is called and executed (s105).
  • Rset and Wset are added by performing processing according to input and parameters and reading and writing to the state management ledger T20 of the distributed ledger 150.
  • the flow execution smartphone 120 After executing the processing of the function node, the flow execution smartphone 120 sets the output of the processing of the function node to the input of the next function node (s107) if there is the next function node (s106: Yes), and continues the processing of the function node. To execute.
  • the flow execution smartphone 120 returns the Rset and Wset added so far (s108), and ends the process.
  • the business logic can be reused and structural analysis can be performed more easily than the conventional program format smart contract. ..
  • the flow name and version are specified, but a method in which the flow name and version are not specified is also conceivable. If the user name, group name, role name, etc. that execute the flow name are associated with the flow name when registering the flow, the user name, group name, etc. can be obtained from the information of the user who issued the transaction during the flow execution transaction. It is possible to extract the role name etc. and determine the flow to be executed automatically without specifying the flow name. The latest version is automatically used.
  • the user who registered the flow can execute the flow without making the flow user aware of the contents of the flow.
  • Example 2 the program and business logic in the smart contract are separated by saving the flow registered and renewed by the user in the flow management ledger T10 and calling it from the flow execution smartphone 120 without renewing the smart contract. , It has become possible to execute various business logics as smart contracts without renewing the program part and the accompanying approval work.
  • the user can arbitrarily register, renew, and delete the flow management transaction, and the user can also register the malicious business logic. Therefore, in the second embodiment, a mode in which the flow in which the user tries to register or renew can be controlled as usable / unusable by the approval of other users or stakeholders will be shown.
  • FIG. 12A is a diagram showing an example of the approval transaction T200 in the second embodiment. Further, FIG. 12B is a diagram showing an example of the flow approval screen F30.
  • the approval transaction T200 is issued by a stakeholder who owns another user or node after a user issues a flow management transaction such as flow registration, renewal, or deletion.
  • Such an approval transaction T200 is implemented as one function of the flow management smartphone 140, and is composed of a function name T201, a flow name T202, a version T203, an action T204, and an approver T205.
  • the function name T201 "approve” indicating approval or "reject” indicating rejection is specified.
  • the flow name T202 and the version T203 are data for uniquely designating the flow in which the approval work has been performed.
  • the action T204 represents an action to be performed when the flow is approved.
  • the flow name "flow1" represents the approval work required when updating to version "1.1”.
  • the approver T205 is composed of approved user and stakeholder information or its electronic signature information. This makes it possible to visualize who performed the approval work when registering, updating, and deleting the flow, and the trail is also stored in the blockchain data.
  • the flow is approved by stakeholders (org1, 2, %) Who have nodes different from general users.
  • the flow approval screen F30 is a part of the client application 170, and is an interface used when the user issues the above-mentioned approval transaction T200.
  • Such a flow approval screen F30 is composed of a flow designation unit F31 which is an interface for designating a flow, a flow display unit F32 for displaying a flow, and a button F33 which is an interface for selecting whether to approve or reject the flow. ..
  • the flow specification unit F31 accepts the specification of the action of the flow to be approved in addition to the specification of the flow name and version from the drop-down menu or the like.
  • the situation where the approval work is performed for the action "update" of the version "1.1" of the flow name "flow1" is shown.
  • the flow display unit F32 is a display unit that illustrates the flow designated by the above-mentioned flow designation unit F31 in the same manner as in FIG.
  • the button F33 is a button for the user who is the approver to input whether to approve or reject the flow to be displayed by the flow display unit F32. When this button F33 is clicked, the approval transaction T200 is issued from the client application.
  • FIG. 13 is a table showing an example of the flow management ledger T210 in the second embodiment. This is the addition of data related to the approval act to the flow management ledger T10 in the first embodiment shown in FIG.
  • the flow management ledger T210 of the second embodiment is composed of the index T211, the flow name T212, the version T213, the flow data T214, the current action T215, the approval status T216, and the approver list T217.
  • the action T215 stores the function name T61 of the flow management transaction T60 executed immediately before the flow. Further, the status T216 represents the status of approval or approved / rejected for the action T215.
  • approver list T217 contains a list of users and stakeholders who have issued approval or rejection transactions for the action. Conditions such as how many approvers should approve to be approved, or who should approve to be approved are determined according to policies shared in advance between users and stakeholders.
  • FIG. 14 is a diagram showing a flow example of the flow management smartphone 140 in the second embodiment.
  • the flow management smartphone 140 in the second embodiment in addition to processing the transaction of flow registration, renewal, deletion, etc., the transaction of approving the action for the flow is processed.
  • the flow registration processing flow s200 and the flow approval processing flow s210 are shown.
  • the flow management smartphone 140 receives the flow name T62, the version T63, and the flow data T64 as inputs from the flow registration transaction issued by the user (s201).
  • the flow management smartphone 140 returns an error and ends the process when a matching flow already exists in the flow management ledger T210 regarding the flow name and version obtained in s201 (s202: Yes).
  • the flow management smartphone 140 when there is no matching flow with respect to the flow name and version obtained in s201 (s202: No), the flow management smartphone 140 newly creates a key consisting of the flow name and the version. The flow data is written in the flow management ledger T210 (s203).
  • the flow management smartphone 140 specifies "register” indicating registration in action T215 and sets the approval status T216 to "approving” in order to represent the action performed on the flow (s204). Further, the flow management smartphone 140 in s204 empties the approver list and ends the process. As a result, it is possible to uniquely express a state in which the specified flow has been registered in the flow management ledger T210 but has not been approved by other stakeholders (a state in which consensus building has not yet been formed). ..
  • the flow management smartphone 140 receives the flow name T202, the version T203, the action T204, and the approver information T205 as inputs from the flow approval transaction issued by the user or the stakeholder (s211).
  • the flow management smartphone 140 returns an error and ends the process when a matching flow does not already exist in the flow management ledger T210 regarding the flow name and version obtained in s211 (s212: No).
  • the flow management smartphone 140 reads the information of the corresponding flow from the flow management ledger T210. (S213).
  • the flow management smartphone 140 sets the status of the flow to "approved” (s217) and ends the process. On the other hand, if the approver list T217 does not meet the predetermined condition (s216: No), the flow management smartphone 140 leaves the status of the flow as "approving".
  • Example 3 In Example 2 described above, an example of approving a flow by a user or a stakeholder is shown to ensure the quality of business logic. However, there may be cases where manual approval work takes time and cost, such as when a large number of users register a flow or when frequent renewals occur.
  • Example 3 when registering or renewing a flow, a mode is shown in which the quality check and approval work of the flow are automatically performed on each node.
  • FIG. 15 is a diagram showing an example of the quality check item list T300 in the third embodiment.
  • the quality check item list T300 is shared between the nodes and is managed by, for example, the distributed ledger 150. This quality check item list T300 checks the parameter range, the function node information that can be set next, etc. with the flow management smartphone 140 for each function node in the flow to be registered, and determines whether or not it is established as business logic. Used when.
  • Such a quality check item list T300 is composed of an index T301, a functional node type T302, a parameter T303, a minimum value T304, a maximum value T305, a type T306, and the following functional node T307.
  • the functional node type T302 has a one-to-one correspondence with the functional node type T52 in the functional node table T50 of FIG.
  • the parameter T303 represents a parameter that can be set by the functional node
  • the minimum value T304 and the maximum value T305 represent the settable range of the parameter.
  • the type T306 is a value that defines the type of the above-mentioned parameter T303 and serves as a reference for judging whether or not it is correct at the time of checking.
  • the type T306 is an "integer" representing an integer because it must be an integer rather than a number after the decimal point.
  • next functional node T307 is a list showing what kind of functional node can be arranged next to the current functional node type. For example, after a conditional branch node, the same type of conditional branch node and output node can be connected, but an input node cannot be connected. This can also be determined from the input and output types of each functional node.
  • the quality check item list T300 is defined by stakeholders, one list may be shared as a whole, but some or all of the list may be customized for each stakeholder so that quality check can be performed at the discretion of each stakeholder. It is also possible to make it.
  • FIG. 16 is a diagram showing an example of the automatic approval flow s300 in the third embodiment.
  • the automatic approval flow s300 is implemented in a form customized for transaction processing of flow registration and update in the flow management smartphone 140.
  • the flow management smartphone 140 receives the flow name, version, and flow data as inputs from the flow registration transaction issued by the user (s301).
  • the flow management smartphone 140 reads the corresponding line from the quality check item list T300 for each functional node in the flow data obtained in s301, and confirms that all the corresponding check items are satisfied (s302).
  • the flow management smartphone 140 writes the flow to the flow management ledger T210 (s304) and ends the process.
  • Example 3 in addition to the work of registering the business logic that is no longer necessary in Example 1 and approving the program part in the renewal, the flow that stakeholders and the like should manually perform to ensure the quality of the business logic. Approval work can also be automated.
  • the stakeholder can automatically perform the approval work while having some discretion.
  • the business logic related to business decisions is separated from the smart contract and saved in the distributed ledger in a flow format that can be customized even by those who do not have program knowledge. Then, the flow on the ledger can be called from the smart contract, and the business logic can be executed according to the flow.
  • the business logic can be executed by the smart contract without renewing the program part or performing new approval work.
  • each node shares the execution result of the transaction with respect to the transaction related to at least one of the management processes of registration, renewal, and deletion of the flow data.
  • a flow management smart contract that manages the flow data in the distributed ledger may be executed.
  • flow data which is business logic
  • processing such as consensus building based on blockchain technology
  • registration and renewal of business logic in smart contracts are frequently performed. It is possible to manage and execute the smart contract more efficiently by accurately responding to the situation that occurs.
  • each node may issue an approval transaction for approving the management process of the flow data subject to the management process in the flow management smart contract.
  • the flow data which is the business logic
  • the flow data can be appropriately managed by forming consensus among the users of each node, that is, the stakeholders.
  • each node holds a quality checklist that defines conditions that allow registration or renewal of the flow data, and in the flow management smart contract, the management process is performed.
  • the quality check of the flow data may be executed using the quality check list, and the registration or renewal of the flow data may be automatically approved.
  • the management of flow data is automated based on the quality conditions, and by extension, it is possible to accurately respond to the situation where business logic registration and renewal in smart contracts occur frequently, and the smart contract is made efficient. It becomes possible to manage and execute in a targeted manner.
  • each node holds the quality checklist managed by each user, and at the time of the quality check, the quality check of the flow data is performed using the quality checklist of the user. May be executed.
  • the management of flow data is automated based on the quality conditions desired by each stakeholder, and by extension, it is possible to accurately respond to situations where business logic registration and renewal in smart contracts occur frequently, and the smart contract is concerned. It becomes possible to efficiently manage and execute contracts.
  • each node manages each flow data in the distributed ledger by associating the attribute information of a user who can use the flow data with the node.
  • the flow data corresponding to the user may be read from the distributed ledger, and the smart contract may be executed according to the flow data.
  • smart contract execution according to flow data is automated according to the attributes of each stakeholder, and by extension, it is possible to accurately respond to situations where business logic registration and renewal in smart contracts occur frequently. , It becomes possible to efficiently manage and execute the smart contract.
  • the functional node execution smart contract when the functional node execution smart contract is defined for each type of the functional node included in the flow data in the smart contract, the node is read from the distributed ledger.
  • the functional node execution smart contract may be executed from the smart contract according to the flow data.
  • smart contract execution will be efficient, and by extension, it will be possible to accurately respond to situations where business logic registration and renewal in smart contracts occur frequently, and manage the smart contract efficiently. It becomes possible to execute.
  • each of the plurality of nodes shares the execution result of the transaction with respect to the transaction related to at least one of the management processes of registration, renewal, and deletion of the flow data.
  • the flow management smart contract that manages the flow data in the distributed ledger may be executed.
  • each of the plurality of nodes issues an approval transaction for approving the management process of the flow data subject to the management process in the flow management smart contract. , May be.
  • each of the plurality of nodes holds a quality checklist that defines conditions that allow registration or renewal of the flow data, and the management in the flow management smart contract.
  • the quality check of the flow data may be executed using the quality check list, and the registration or renewal of the flow data may be automatically approved.
  • each of the plurality of nodes holds the quality checklist managed by each user, and at the time of the quality check, the quality checklist of the user is used to obtain the flow data. It may be the one that performs the quality check.
  • each of the plurality of nodes manages each flow data in association with the attribute information of the user who can use the flow data in the distributed ledger.
  • the flow data corresponding to the user of the node may be read from the distributed ledger, and the smart contract may be executed according to the flow data.
  • each of the plurality of nodes is the distributed ledger.
  • the function node execution smart contract may be executed from the smart contract according to the flow data read from.
  • Network 10 Smart contract execution system 100-300 Node 101 Storage device 102 Program 103 Memory 104 Computing device 105 Communication device 110 Smartphone execution unit 120 Flow execution Smartphone 130 Functional node execution Smartphone 140 Flow management Smartphone 150 Distributed ledger T10, T210 Flow management ledger T20 State management ledger T30 Blockchain data T40 Flow table T50 Function node table T60 Flow management transaction T70 Flow execution transaction T200 Approval transaction T300 Quality check item list 160 Communication unit 170 Client application

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ブロックチェーンシステムを構成する各ノード１００が、分散台帳１５０において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを分散台帳１５０から読み込み、当該フローデータに従ってスマートコントラクトを実行する。

Description

スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード
　本発明は、スマートコントラクト実行方法、スマートコントラクト実行システム、およびノードに関する。
　従来、金融機関や政府等の中央集権機関を経由して実施されてきた関係者間の取引を、関係者間のＰ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）による直接的な取引に代替する技術として、分散台帳技術（いわゆる、ブロックチェーン：Ｂｌｏｃｋｃｈａｉｎ）が活用されている。当該技術の一例としては、仮想通貨の一種であるＢｉｔｃｏｉｎに関するものが存在する。
　こうした分散台帳技術は、信頼できるデータの管理や共有、並びに、契約に基づく取引の執行及び管理を非中央集権的に行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。
　現状のブロックチェーンの主な特徴としては、（１）ブロックチェーンネットワーク上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の分散台帳を共有することにより、参加者全員での取引の確認を可能とすること、などが挙げられる。
　また、分散台帳技術を仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするため、分散台帳の中で（取引）データだけでなく、取引に関わるロジックも管理可能となってきている。このロジックはスマートコントラクト（以下スマコンとも略）と呼ばれる。
　上述のスマートコントラクトは、複数の参加者間での取引ロジックを記述する特性上、普通のロジックを記述するプログラムと異なり、参加者間で相互に品質をチェックし、その内容について合意形成を行う必要がある。また、スマートコントラクトの実行証跡が、改ざん不可能な分散台帳上に保存される特性上、その品質チェックは特に厳密なものでなくてはならない。
　そのため、ビジネスロジックを頻繁に更改するケースや、多数のユーザにビジネスロジックを定義させるケースにおいては、スマートコントラクトの品質チェックや合意にかかるコストが膨大になってしまう。
　そこで従来技術として、メインとなるスマートコントラクトから別のスマートコントラクトを呼び出す技術がある（非特許文献１）。スマートコントラクトをコンポーネント化し、個別に作成・更改を可能にすることで、スマコン作成・更改に際する品質チェックを部分的に行うことが可能となる。
Ｈｙｐｅｒｌｅｄｇｅｒ　Ｆａｂｒｉｃ　ｈｔｔｐｓ：／／ｗｗｗ．ｈｙｐｅｒｌｅｄｇｅｒ．ｏｒｇ／ｐｒｏｊｅｃｔｓ／ｆａｂｒｉｃ　ｃｈａｉｎｃｏｄｅ２ｃｈａｉｎｃｏｄｅ
　上記の従来技術では、スマートコントラクトの部品化には成功しているが、スマートコントラクトのプログラム部分とビジネスロジック部分とが分離されていない。そのため、スマートコントラクトの登録、更改に際し、ビジネスロジック部分とプログラム部分の双方の品質チェック、承認作業が必要となる。
　したがって、承認作業においては、プログラムの仕様およびビジネスロジックの双方について専門知識を持つ者が承認者になり、承認作業を行う必要がある。このとき、前述のように、ビジネスロジックを頻繁に更改するケースや、多数のユーザにビジネスロジックを定義させるケースにおいては、専門知識を持つ承認者への負担が大きくなることが考えられる。
　そこで本発明の目的は、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することを可能とする技術を提供することにある。
　上記課題を解決する本発明のスマートコントラクト実行方法は、ブロックチェーンシステムを構成する各ノードが、分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行することを特徴とする。
　また、本発明のスマートコントラクト実行システムは、複数のノードから構成されるブロックチェーンシステムであって、前記複数のノードそれぞれは、分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行するものである、ことを特徴とする。
　また、本発明のノードは、ブロックチェーンシステムを構成するノードであって、分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行するものである、ことを特徴とする。
　本発明によれば、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
実施例１におけるスマートコントラクト実行システムの構成例を示す図である。 実施例１におけるノードのハードウェア構成例を示す図である。 実施例１におけるフロー作成画面例を示す図である。 実施例１におけるフローテーブルの例を示す図である。 実施例１における機能ノードテーブルの例を示す図である。 実施例１におけるフロー管理トランザクションの例を示す図である。 実施例１におけるフロー管理台帳の一例を示す図である。 実施例１におけるフロー実行トランザクションの一例を示す図である。 実施例１におけるステート管理台帳の一例を示す図である。 実施例１におけるブロックチェーンデータの一例を示す図である。 実施例１におけるフロー実行スマコンのフロー例を示す図である。 実施例２における承認トランザクションの一例を示す図である。 実施例２におけるフロー承認画面の一例を示す図である。 実施例２におけるフロー管理台帳の一例を示す図である。 実施例２におけるフロー管理スマコンのフロー例を示す図である。 実施例３における品質チェック項目リストの一例を示す図である。 実施例３における自動承認フローの例を示す図である。
　以下、本発明の実施の形態について図面を参照しつつ説明する。
＜＜実施例１＞＞
　図１は、実施例１におけるスマートコントラクト実行システム１０のネットワーク構成例を示す図である。なお、スマートコントラクト実行システム１０は、ブロックチェーンシステムであり、複数のノード１００、２００、３００、・・・から構成されているものとする。以後、特に区別しないかぎり、ノード１００を各ノードの代表例として説明に用いるものとする。
　ここで、ノード１００は、主にスマートコントラクト実行部１１０（図中ではスマコン実行部。以後、スマコン実行部）、分散台帳１５０、および通信部１６０で構成されている。ノード２００、ノード３００についても同様の構成である。
　これらの構成要素のうち、スマコン実行部１１０は、フロー実行スマコン１２０、機能ノード実行スマコン１３０、およびフロー管理スマコン１４０から構成される。なお、これらのスマコンは、ノード間で共有されているものとする。
　また、機能ノード実行スマコン１３０は、ビジネスロジックを記述したフローデータにおける一連のノードそれぞれの機能に合わせ、定義されている。また、フロー実行スマコン１２０やフロー管理スマコン１４０も、機能によって分割されていてもよい。なお、機能ノードスマコンはフロー実行スマコンに統合されていてもよい。
　ノード１００が保持する分散台帳１５０は、フロー管理台帳Ｔ１０、ステート管理台帳Ｔ２０、およびブロックチェーンテーブルＴ３０を含んでいる。これらの詳細については後述する。
　また、ノード１００は、通信部１６０によってクライアントアプリケーション１７０と通信を行う。クライアントアプリケーション１７０は、分散台帳ノードであるノード１００に、各種のリクエストを送信し、それに応じた回答を取得するクライアント端末に備わるアプリケーションである。ノード１００を運営する企業等のユーザは、クライアント端末を操作して、ノード１００にアクセスし、所定の処理を経て必要な情報を得ることになる。
＜ハードウェア構成＞
　また、スマートコントラクト実行システム１０を構成するノード１００のハードウェア構成例を図２に示す。ノード１００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なう演算装置１０４、ネットワーク１と接続し他ノードとの通信処理を担う通信装置１０５を備える。なお、記憶装置１０１には、プログラム１０２の他、上述の分散台帳１５０が格納されている。
　また、本発明のスマートコントラクト実行方法に対応する各種動作は、スマートコントラクト実行システム１０を構成する各ノード１００がメモリ１０３に読み出して実行するプログラム１０２によって実現される。
＜一般的なトランザクションの流れ＞
　ここで、上述のユーザがクライアント端末等を操作し、分散台帳ネットワークたるネットワーク１の各ノードに宛ててトランザクションを発行した場合を想定し、その際のトランザクションに関する処理について説明する。
　トランザクション発行から、対応するデータが各ノードの分散台帳に書き込まれるまでの間、一般的なブロックチェーンシステムでは以下のような処理が行われている。
（１）ユーザがクライアントアプリケーション１７０を通してトランザクションを発行する。
（２）クライアントアプリケーション１７０は、各ノードにトランザクションを送信する。
（３）各ノードの通信部１６０はトランザクションを受け取り、トランザクションで指定されたスマートコントラクトをスマコン実行部１１０で実行する。
（４）スマートコントラクトの実行結果が分散台帳１５０のステート管理台帳Ｔ２０に書き込まれる。
（５）その結果について、ノード間で合意を行い、合意が成立すれば分散台帳１５０のステート管理台帳Ｔ２０に書き込んだ結果を確定させる。
（６）これらの実行証跡はハッシュチェーンで繋がれたブロックチェーンデータＴ３０として、各ノードで共有される。
　本実施例では、このような一般的なブロックチェーンシステムにおける処理と異なり、スマートコントラクト実行時に、フロー形式で定義されたビジネスロジックを分散台帳１５０のフロー管理台帳Ｔ１０から読み込み、そのフローに従ってフロー実行スマコン１２０を実行し、その結果をステート管理台帳Ｔ２０に保存するものとする。
＜フローデータの作成とフローデータの例＞
　図３は、実施例１におけるフロー作成画面の一例を表す図である。フローは、ビジネスロジックにおける或る処理を行う単位である機能ノードと、そのつながりによって表現される。フローＦ１０は、フローの一例であり、Ｆ１１、Ｆ１２、Ｆ１３、Ｆ１４の４つの機能ノードで構成されている。こうして構成されたフローのデータを、フローデータと称する。
　図中において、機能ノードＦ１１は入力ノードＡであり、トランザクションから受けた何かしらの入力を処理する機能ノードである。また、機能ノードＦ１２は入力ノードたる機能ノードＦ１１から受け取った入力について、閾値判定や大小判定などのなんらかの判定を行う条件分岐ノードＢである。ここでは、機能ノードＦ１２での判定の結果が「Ｔｒｕｅ」であれば、機能ノードＦ１３の出力ノードを処理し、「Ｆａｌｓｅ」であれば機能ノードＦ１４の出力ノードを処理することとなる。
　また、機能ノードＦ１３、Ｆ１４の出力ノードＣ，Ｄは、ブロックチェーン上になんらかのデータを出力する機能をもつ機能ノードである。
　こうしたフローを作成するユーザは、上述のクライアントアプリケーション１７０が提供するフロー作成用のＧＵＩツール等を用いることで、直感的にフロー作成を行うことができる。図３で示すクライアントアプリケーション１７０の一機能であるフロー作成画面は、機能ノード一覧Ｆ１５とフロー編集画面Ｆ１６とで構成される。
　このうち機能ノード一覧Ｆ１５は、機能ノード実行スマコン１３０の種類に応じた機能ノードのオブジェクトを表示し、ユーザによるドラッグアンドドロップなどの操作を受ける。この場合、クライアントアプリケーション１７０は、操作対象の機能ノードのオブジェクトをフロー編集画面Ｆ１６にインスタンス化する。
　図３の例では、機能ノード一覧Ｆ１５にて、入力ノードＦ１７、出力ノードＦ１８、および条件分岐ノードＦ１９を表示した例を示している。
　一方、フロー編集画面Ｆ１６では、上述のユーザの操作で機能ノード一覧Ｆ１５からインスタンス化された機能ノードを配置、表示し、各機能ノードを組み合わせたフローの作成を支援する。
　他方、上述のユーザは、フロー編集画面Ｆ１６において、一方の機能ノードと他方の機能ノードとに対して所定の操作を行うことで、インスタンス化された機能ノード同士を連結し、フローを構成することができる。またユーザは、このフロー編集画面Ｆ１６において、所望の機能ノードをクリックする等の操作を行うことで、当該機能ノードのパラメータ設定などの詳細設定が可能である。
　本実施例では、このようにユーザが作成したフローのデータ、すなわちフローデータは、クライアントアプリケーション１７０からノード１００のフロー管理台帳Ｔ１０に保存される。また、フロー管理台帳Ｔ１０で保存するフローデータは、別のユーザによってフロー実行スマコン１２０から呼び出される。
　図４は、実施例１におけるフローをテーブル形式で表した一例、すなわちフローテーブルＴ４０を示す図である。このフローテーブルＴ４０は、図３のフローＦ１０をテーブル化したものである。フローテーブルＴ４０の構成要素は、インデックスＴ４１、機能ノード名Ｔ４２、機能ノード種類Ｔ４３、そのパラメータＴ４４、および、次に実行する機能ノードを表すＴ４５である。さらには、必要に応じて各機能ノードの機能を自然言語で表したＴ４６が追加される。
　ここでは、「１週間ごとに各ユーザのログイン情報を参照し、７日連続でログインしていたユーザには１０ｐｔを、そうでないユーザには３ｐｔを付与する」というビジネスロジックを、Ａ，Ｂ，Ｃ，Ｄの４つの機能ノードで表現している。
　入力ノードＡは、ユーザの１週間のログイン情報を取得する機能ノードであり、条件分岐ノードＢと繋がっている。
　また、条件分岐ノードＢは、パラメータとして「ｔｈｒｅｓｈｏｌｄ＝７」に設定されており、７日連続でログインしたユーザなら出力ノードＣとつなぎ、そうでない場合は出力ノードＤとつなぐ機能ノードである。
　また、出力ノードＣは、パラメータ「ｐｏｉｎｔ＝１０」と設定されており、ユーザに１０ｐｔを付与する機能ノードである。また、出力ノードＤは、パラメータ「ｐｏｉｎｔ＝３」と設定されており、ユーザに３ｐｔを付与する機能ノードである。
　図５は実施例１における機能ノードの一例を表すテーブル、すなわち機能ノードテーブルＴ５０を示す図である。機能ノードの実体は、その種類ごとに機能ノード実行スマートコントラクトとして実装される。あるいは、フロー実行スマコンの一部として実行される。
　この機能ノード実行スマートコントラクトは、フローに応じてメインとなるフロー実行スマートコントラクトから呼び出され、入力やパラメータに応じて処理を実行し、次のノードに結果を出力する。
　機能ノードテーブルＴ５０は、図４のフローで使用されている機能ノードの詳細を表しているテーブルである。本機能ノードテーブルＴ５０の構成要素は、インデックスＴ５１、機能ノード種類Ｔ５２、パラメータＴ５３、入力Ｔ５４、出力Ｔ５５、および処理内容Ｔ５６である。
　このうちパラメータＴ５３は、条件分岐ノードでは閾値ｔｈｒｅｓｈｏｌｄ、出力ノードではｐｏｉｎｔなど、機能ノードの種類によってそれぞれ設定され、それぞれインスタンス化された機能ノードによって値を変化させることができる。
　一例として、図４のフローでは、条件分岐ノードＢでは「ｔｈｒｅｓｈｏｌｄ＝７」、出力ノードＣでは「ｐｏｉｎｔ＝１０」、出力ノードＤでは「ｐｏｉｎｔ＝３」と設定している。
　また、入力Ｔ５４および出力Ｔ５５は、それぞれ機能ノード間で受け渡すデータを表している。
　また、処理内容Ｔ５６は、本来プログラミング言語などで書かれているが、ここでは理解しやすいため自然言語で記述している。この処理内容Ｔ５６では、入力Ｔ５３を受けて出力Ｔ５５を出力するまでの処理内容が記述されており、途中で機能ノードごとに設定可能なパラメータＴ５３を使用することができる。
　フローの例では、条件分岐ノードのパラメータ「ｔｈｒｅｓｈｏｌｄ」は、連続ログイン判定で用いる日数を表し、また出力ノードのパラメータ「ｐｏｉｎｔ」は、ユーザに付与するポイント量を表している。
　図６は、実施例１におけるフロー管理トランザクションＴ６０の一例を表すテーブルである。フロー管理トランザクションＴ６０は、フローを分散台帳１５０に登録、更新する際や、分散台帳１５０から削除する際に、ユーザが発行する、フローのライフサイクル管理のためのトランザクションである。
　こうしたフロー管理トランザクションＴ６０は、関数名Ｔ６１、フロー名Ｔ６２、フローのバージョンＴ６３、およびフローデータＴ６４で構成される。
　このうち関数名Ｔ６１は、フローの新規登録を行う「ｒｅｇｉｓｔｅｒ」、作成されたフローを更新する「ｕｐｄａｔｅ」、フローを削除する「ｄｅｌｅｔｅ」などが想定できる。
　また、フロー名Ｔ６２は、フロー実行スマコン１２０から呼び出されるユニークな名前であり、バージョンＴ６３はその更新情報を表す数値である。こうしたバージョンＴ６３の値は、基本的にｕｐｄａｔｅごとに加算される。
　また、フローデータＴ６４は、フローを表すテーブルＴ４０を、ｊｓｏｎ形式で構造化したオブジェクトである。
　続いて図７に、実施例１におけるフロー管理台帳Ｔ１０の一例を示す。例示するフロー管理台帳Ｔ１０は、フロー管理トランザクションによって、ユーザが登録または更新したフローを、ブロックチェーン内のデータとしてノード間で信頼性ある形で共有するデータベースである。
　このフロー管理台帳Ｔ１０の構成要素としては、インデックスＴ１１、フロー名Ｔ１２、バージョンＴ１３、およびフローデータＴ１４で構成されている。図６のフロー管理台帳Ｔ６０と同様、フロー名Ｔ１２は、フロー実行スマコン１２０から呼び出されるユニークな名前であり、バージョンＴ１３はその更新情報を表す数値、フローデータＴ１４はフローを表すテーブルＴ４０をｊｓｏｎ形式で構造化したオブジェクトである。
　なお、フロー実行トランザクションからすばやく読み出すため、フロー名Ｔ１２とバージョンＴ１３を組み合わせてキーを作成し、キーバリュー形式でフローデータを読み出すなどの設計が考えられる。
　続いて図８に、実施例１におけるフロー実行トランザクションＴ７０の一例を示す。上述のフローを利用するユーザによって、このフロー実行トランザクションＴ７０が発行されると、フロー実行スマコン１２０は、フロー管理台帳Ｔ１０に保存されているフローを読み出し、当該フローに記載されている各機能ノードの処理を行うため、機能ノード実行スマコン１３０を呼び出すこととなる。
　フロー実行トランザクションＴ７０は、関数名Ｔ７１、フロー名Ｔ７２、バージョンＴ７３、およびフローに必要な引数Ｔ７４で構成されている。
　また、フロー名Ｔ７２とバージョンＴ７３は、実行するフローの名前とバージョンを指定する。もし指定した名前とバージョンのフローがフロー管理台帳Ｔ１０に存在しない場合、フロー実行トランザクションＴ７０はエラーを返すことになる。他方、指定したフローが存在する場合、フロー実行スマコン１２０は、フロー管理台帳Ｔ１０から該当するフローを読み出す。
　フローの引数Ｔ７４は、そのフローを実行する際に必要な入力の配列もしくはテーブルである。フローの引数Ｔ７４は、フローごとに固有の数であり、またデータの型もそれぞれ異なる。実施例では、図４のフローテーブルＴ４０における入力ノードＡの入力として必要なフローの引数として、ユーザ名とそのユーザの一週間のログイン情報を指定する。
　続いて図９に、実施例１におけるステート管理台帳Ｔ２０の一例を示す。このステート管理台帳Ｔ２０は、ユーザが発行したフロー実行トランザクションＴ７０によって呼び出されたフローにより作成、更新されるデータを、ノード間で信頼できる形で共有するデータベースである。
　ステート管理台帳Ｔ２０は、特定のサイズや型などは存在せず、ユースケースによって自由に設計することができる。本実施例では、ユーザが所持しているポイントを変更するユースケースであるため、ステート管理台帳Ｔ２０は、インデックスＴ２１、ユーザ名Ｔ２２、およびユーザの所持ポイントＴ２３で構成されている。
＜ブロックチェーンデータの例＞
　図１０は、実施例１におけるブロックチェーンデータＴ３０の一例を示す図である。ブロックチェーンデータＴ３０には、各ノードで処理されたトランザクションの実行履歴が格納されている。
　ブロックチェーンデータＴ３０は、複数のトランザクションの実行履歴をまとめてブロックと定義し、そのブロックのハッシュ値を次のブロックのデータに追加することで、隣接したブロック同士がハッシュによってチェーンのように繋がれ、改ざんが困難となっているデータベースである。
　こうしたブロックチェーンデータＴ３０は、インデックスＴ３１、取引ＩＤ：Ｔ３２、タイムスタンプＴ３３、実行するスマートコントラクトの種類Ｔ３４、スマコン内の関数名Ｔ３５、当該関数の引数Ｔ３６、スマコン実行時に分散台帳１５０から読み込んだデータを表すＲｓｅｔ（Ｒｅａｄ　ｓｅｔ）Ｔ３７、および、スマコン実行時に分散台帳１５０に書き込んだデータを表すＷｓｅｔ（Ｗｒｉｔｅ　ｓｅｔ）Ｔ３８で構成されている。
　このうち取引ＩＤであるＴ３２は、ブロックが作成される段階で自動的に割り振られる値であり、トランザクションに対しユニークな値である。また、タイムスタンプＴ３３は取引が成立した時点における時刻が記載されている。
　また、スマコンの種類Ｔ３４では、スマートコントラクトの種類として、本実施例ではフロー管理スマコン１４０かフロー実行スマコン１２０のどちらかを指定する。また、関数名Ｔ３５は、フロー管理スマコン１４０であれば、図６のフロー管理トランザクションＴ６０の関数名Ｔ６１で示した、ｒｅｇｉｓｔｅｒ，ｕｐｄａｔｅ，ｄｅｌｅｔｅなどが設定されている。また、フロー実行スマコン１２０であれば、図８のフロー実行トランザクションＴ７０における関数名Ｔ７１で示した「ｅｘｅｃｕｔｅ」が設定される。
　なお、フロー実行スマコン１２０では、フローを用いない、データ初期化のためのｉｎｉｔ関数も定義されており、最初に実行することでユーザデータを初期化する。
　また、関数の引数Ｔ３６は、フロー管理トランザクションＴ６０においては、図６のフロー名Ｔ６２、バージョンＴ６３、およびフローデータＴ６４に該当するデータを、ｊｓｏｎ形式などでまとめて記述する。またフロー実行スマコン１２０においては、図８のフロー実行トランザクションＴ７０におけるフロー名Ｔ７２、バージョンＴ７３、およびフローの引数Ｔ７４に該当するデータをまとめて記述する。
　なお、Ｒｓｅｔ（Ｔ３７）とＷｓｅｔ（Ｔ３８）は、スマコン実行時に分散台帳１５０の読み書きに際して記録されるデータである。このＲｓｅｔとＷｓｅｔは、各ノードが同じ処理を行ったかどうかを判定し、正しい合意形成を行うためのデータである。
　Ｒｓｅｔは、分散台帳１５０のデータを読み込んだ際のキーを保存し、Ｗｓｅｔは、分散台帳１５０に書き込んだ際のキーバリューを保存する。実施例においては、Ｒｓｅｔ、Ｗｓｅｔに証跡が保存される分散台帳１５０のデータとして、ステート管理台帳Ｔ２０に加えフロー管理台帳Ｔ１０もある。
　そのため、フロー実行スマコン１２０において、フローの名前とバージョンを組み合わせた、フローを一意に表すキーがＲｓｅｔに保存されるため、実行したフローを一意に特定することができる。
　ここで、本実施例ではフロー管理スマコン１４０によるデータと、フロー実行スマコン１２０によるデータを、同一のブロックチェーンＴ３０で管理しているが、別々のブロックチェーンに管理してもよい。
＜スマートコントラクト実行方法＞
　図１１は実施例１におけるフロー実行スマコン１２０の処理の一例を表すフローチャートである。フロー実行スマコン１２０は、まず、ユーザから発行されたフロー実行トランザクションＴ７０から、フロー名Ｔ７２、バージョンＴ７３、およびフローの引数Ｔ７４の各値を入力として受け取る（ｓ１０１）。
　続いて、フロー実行スマコン１２０は、フロー管理台帳Ｔ１０から、ｓ１０１で得ているフロー名およびバージョンに関して一致するフローを検索する（ｓ１０２）。この検索の結果、該当するフローがヒットしなければ（ｓ１０２：Ｎｏ）、フロー実行スマコン１２０は、エラー終了する。
　一方、上述の検索の結果、一致するフローがあった場合（ｓ１０２：Ｙｅｓ）、フロー実行スマコン１２０は、該当するフローデータをフロー管理台帳Ｔ１０から読み込む（ｓ１０３）。このとき、フロー実行スマコン１２０は、トランザクション実行結果のＲｓｅｔにフローデータのキーを保存する。
　続いて、フロー実行スマコン１２０は、ｓ１０３で読み込んだフローデータの最初の機能ノードに、ｓ１０１で得ているフロー引数Ｔ７４をセットし（ｓ１０４）、当該フローの処理に従って逐次的に機能ノードを実行するため機能ノード実行スマコン１３０を呼び出して実行する（ｓ１０５）。
　機能ノード実行スマコン１３０では、入力やパラメータに応じた処理を行い、分散台帳１５０のステート管理台帳Ｔ２０に対して読み書きを行うことで、Ｒｓｅｔ、Ｗｓｅｔを追加していく。
　フロー実行スマコン１２０は、機能ノードの処理を実行後、次の機能ノードがあれば（ｓ１０６：Ｙｅｓ）、機能ノードの処理の出力を次の機能ノードの入力にし（ｓ１０７）、引き続き機能ノードの処理を実行する。
　一方、次の機能ノードがない場合（ｓ１０６：Ｎｏ）、フロー実行スマコン１２０は、これまで追加したＲｓｅｔ、Ｗｓｅｔを返し（ｓ１０８）、処理を終了する。
　＜効果＞
　上述の実施例１により、ビジネスロジックを頻繁に更改するケースや、多数のユーザにビジネスロジックを定義させるケースにおいて、スマートコントラクトのプログラム部分の更改や新たな承認作業を行うことなく、様々なビジネスロジックをスマートコントラクトとして実行することが可能になる。
　また、フローを登録、更改した証跡が、各ノードの分散台帳１５０に改ざん不可能な形で残るため、実行しているフローについて虚偽記載や改ざんをすることが不可能である。
　また、ビジネスロジックをフロー化することにより、プログラムの知識がない者でもスマートコントラクトをカスタマイズ可能となる。これにより、エンドユーザにスマートコントラクトを定義させるようなケースも実現容易となる。
　また、ビジネスロジックをフロー化して、分散台帳１５０にｊｓｏｎのようなデータ形式で保存することにより、ビジネスロジックの再利用や構造分析を、従来のプログラム形式のスマートコントラクトよりも容易に行うことができる。
　また、実施例１では、ユーザによるフロー実行トランザクション発行の際、フロー名やバージョンを指定していたが、フロー名やバージョンを指定しない方法も考えられる。フロー登録の際にフロー名に対してそれを実行するユーザ名やグループ名、ロール名などを紐づけておけば、フロー実行トランザクションの際にトランザクションを発行したユーザの情報からユーザ名やグループ名、ロール名などを抽出し、フロー名の指定なしに自動的に実行するフローを決定することができる。バージョンは自動的に最新のものを利用する。
　これにより、フローを登録したユーザは、フロー利用ユーザにフローの中身を意識させることなしにフローを実行させることができる。
＜＜実施例２＞＞
　上述の実施例１においては、スマートコントラクトの更改なしに、ユーザが登録、更改したフローをフロー管理台帳Ｔ１０に保存し、フロー実行スマコン１２０から呼び出すことで、スマートコントラクトにおけるプログラムとビジネスロジックを分離し、プログラム部分の更改やそれに伴う承認作業なしに多様なビジネスロジックをスマートコントラクトとして実行することを可能にした。
　しかし、実施例１では、フロー管理トランザクションは、ユーザが登録、更改、削除を任意に行うことができてしまい、当該ユーザが悪意をもったビジネスロジックを登録することも可能である。そこで実施例２では、ユーザが登録、更改しようとしたフローについて、他のユーザやステークホルダーの承認によって使用可能／使用不可能状態と制御できる形態について示す。
　図１２Ａは、実施例２における承認トランザクションＴ２００の一例を示す図である。また、図１２Ｂは、フロー承認画面Ｆ３０の一例を示す図である。このうち承認トランザクションＴ２００は、あるユーザがフローの登録、更改、削除などのフロー管理トランザクションを発行した後、他のユーザやノードを所持するステークホルダーによって発行される。
　こうした承認トランザクションＴ２００は、フロー管理スマコン１４０の１関数として実装されており、関数名Ｔ２０１、フロー名Ｔ２０２、バージョンＴ２０３、アクションＴ２０４、および承認者Ｔ２０５によって構成されている。
　このうち関数名Ｔ２０１は、承認を表す「ａｐｐｒｏｖｅ」か、棄却を表す「ｒｅｊｅｃｔ」が指定される。また、フロー名Ｔ２０２、バージョンＴ２０３は、承認作業を行ったフローを一意に指定するためのデータである。また、アクションＴ２０４は、そのフローが承認されたときに行うアクションを表す。
　なお、本実施例では、フロー名「ｆｌｏｗ１」が、バージョン「１．１」に更新（ｕｐｄａｔｅ）するときに必要な承認作業を表している。
　承認者Ｔ２０５は、承認したユーザやステークホルダー情報、またはその電子署名情報で構成される。これにより、フローの登録、更新、削除において、誰が承認作業を行ったかが可視化され、その証跡がブロックチェーンデータにも保存される。
　なお、本実施例ではフローの承認を行うのは一般ユーザとは異なるノードを持つステークホルダー（ｏｒｇ１，２，．．）としている。
　また、フロー承認画面Ｆ３０は、クライアントアプリケーション１７０の一部であり、ユーザが上述の承認トランザクションＴ２００を発行するときに使用するインターフェイスである。
　こうしたフロー承認画面Ｆ３０は、フローを指定するインターフェイスであるフロー指定部Ｆ３１と、フローを表示するフロー表示部Ｆ３２と、フローを承認するか棄却するかを選択するインターフェイスであるボタンＦ３３によって構成される。
　このうちフロー指定部Ｆ３１は、フロー名およびバージョンの指定に加え、承認するフローのアクションの指定をドロップダウンメニューなどで受け付ける。例では、フロー名「ｆｌｏｗ１」のバージョン「１．１」のアクション「ｕｐｄａｔｅ」について承認作業を行う状況を示した。
　一方、フロー表示部Ｆ３２は、上述のフロー指定部Ｆ３１で指定されたフローを、図３と同様に図示する表示部である。また、ボタンＦ３３は、フロー表示部Ｆ３２で表示するフローについて、承認者であるユーザが承認か棄却かを入力するボタンである。このボタンＦ３３がクリックされることで、承認トランザクションＴ２００がクライアントアプリケーションから発行されることとなる。
　また、図１３は、実施例２におけるフロー管理台帳Ｔ２１０の一例を表すテーブルである。これは、図７に示した実施例１でのフロー管理台帳Ｔ１０に、承認行為に関するデータを追加したものである。
　実施例２のフロー管理台帳Ｔ２１０は、インデックスＴ２１１、フロー名Ｔ２１２、バージョンＴ２１３、フローデータＴ２１４に加え、現在のアクションＴ２１５、承認ステータスＴ２１６、および承認者リストＴ２１７で構成されている。
　このうちアクションＴ２１５は、そのフローに対して直前に実行されたフロー管理トランザクションＴ６０の関数名Ｔ６１が格納される。また、ステータスＴ２１６は、アクションＴ２１５に対して、承認中であるか承認済み／棄却済みであるかのステータスを表す。
　また、承認者リストＴ２１７は、アクションに対し承認あるいは棄却トランザクションを発行したユーザやステークホルダーのリストが記載される。何人の承認者が承認すれば承認済みになるか、あるいは誰が承認すれば承認されるかなどの条件は、あらかじめユーザやステークホルダー間で共有されたポリシーなどに従って判断される。
＜スマートコントラクト実行方法＞
　図１４は、実施例２におけるフロー管理スマコン１４０のフロー例を示す図である。実施例２におけるフロー管理スマコン１４０では、フロー登録、更改、削除のトランザクション等を処理する他に、フローに対するアクションを承認するトランザクションを処理する。ここではフロー管理スマコン１４０の処理の一例として、フロー登録処理フローｓ２００と、フロー承認処理フローｓ２１０を示す。
　フロー登録処理フローｓ２００において、フロー管理スマコン１４０は、ユーザから発行されたフロー登録トランザクションから、フロー名Ｔ６２、バージョンＴ６３、およびフローデータＴ６４を入力として受け取る（ｓ２０１）。
　また、フロー管理スマコン１４０は、ｓ２０１で得たフロー名およびバージョンに関して、一致するフローが既にフロー管理台帳Ｔ２１０に存在していた場合（ｓ２０２：Ｙｅｓ）、エラーを返して処理を終了する。
　一方、ｓ２０１で得たフロー名およびバージョンに関して、一致するフローが存在していなかった場合（ｓ２０２：Ｎｏ）、フロー管理スマコン１４０は、新規に、当該フロー名と当該バージョンからなるキーを作成し、フローデータをフロー管理台帳Ｔ２１０に書き込む（ｓ２０３）。
　このとき、フロー管理スマコン１４０は、当該フローに対して行ったアクションを表すため、アクションＴ２１５に登録を表す「ｒｅｇｉｓｔｅｒ」を指定し、承認ステータスＴ２１６を「承認中」と設定する（ｓ２０４）。また、ｓ２０４におけるフロー管理スマコン１４０は、承認者リストを空にし、処理を終了する。これによって、指定したフローに対して、フロー管理台帳Ｔ２１０への登録は行ったが、他のステークホルダーらからの承認はされていない状態（合意形成が未だの状態）を一意に表現することができる。
　次に、フロー承認処理フローｓ２１０において、フロー管理スマコン１４０は、ユーザやステークホルダーが発行したフロー承認トランザクションから、フロー名Ｔ２０２、バージョンＴ２０３、アクションＴ２０４、および承認者情報Ｔ２０５を入力として受け取る（ｓ２１１）。
　フロー管理スマコン１４０は、ｓ２１１で得たフロー名およびバージョンに関して、一致するフローが既にフロー管理台帳Ｔ２１０に存在していなかった場合（ｓ２１２：Ｎｏ）、エラーを返し処理を終了する。
　一方、ｓ２１１で得たフロー名およびバージョンに関して、一致するフローがフロー管理台帳Ｔ２１０に存在していた場合（ｓ２１２：Ｙｅｓ）、フロー管理スマコン１４０は、該当するフローの情報をフロー管理台帳Ｔ２１０から読み込む（ｓ２１３）。
　ここで、フロー承認トランザクションからの入力であるアクションＴ２０４と、読み込んだフローで記載されていたアクションＴ２１５とが一致していなかった場合（ｓ２１４：Ｎｏ）、フロー管理スマコン１４０は、承認するアクションが異なるとしてエラーを返し処理を終了する。
　一方、フロー承認トランザクションからの入力であるアクションＴ２０４と、読み込んだフローで記載されていたアクションＴ２１５とが一致していた場合（ｓ２１４：Ｙｅｓ）、フロー管理スマコン１４０は、フローの承認者リストＴ２１７に承認者情報Ｔ２０５を追加する（ｓ２１５）。
　ここで、承認者リストＴ２１７が既定の条件を満たしていた場合（ｓ２１６：Ｙｅｓ）、フロー管理スマコン１４０は、当該フローのステータスを「承認済み」に設定し（ｓ２１７）、処理を終了する。他方、承認者リストＴ２１７が既定の条件を満たしていない場合は（ｓ２１６：Ｎｏ）、フロー管理スマコン１４０は、当該フローのステータスを「承認中」のままとする。
　ここで、図１１のフロー実行処理においては、フロー名とバージョンの確認のほかに、当該フローのステータスが「承認済み」であるかどうかのチェックを行う必要がある。また、当該フローに結び付くアクションは原則最新のひとつのみを想定しているが、複数のアクションについて、同時並行的に承認を行えるようにしてもよい。
＜効果＞
　実施例２においては、ユーザが登録、更新したビジネスロジックを表すフローに対して、他のユーザやステークホルダーが承認トランザクションを発行することによって、信頼できるビジネスロジックのみを他のユーザが利用することができる。
　また、フローの承認において、特定のステークホルダーの承認が必要になるようなポリシーを設定することで、特定のステークホルダーに不利にならないようなビジネスロジックのみを選択的に利用可能にすることができる。
＜＜実施例３＞＞
　上述の実施例２では、ビジネスロジックの品質担保のため、ユーザやステークホルダーによってフローの承認を実施する例を示した。しかし、多数のユーザがフローを登録する場合や、頻繁な更改が発生する場合など、手動での承認作業では時間とコストがかかるケースが考えられる。
　そこで実施例３では、フローの登録や更改に際し、フローの品質チェックと承認作業を各ノードで自動的に行う形態を示す。図１５は、実施例３における品質チェック項目リストＴ３００の一例を示す図である。
　品質チェック項目リストＴ３００は、ノード間で共有されており、例えば、分散台帳１５０で管理されている。この品質チェック項目リストＴ３００は、登録しようとしているフロー内の各機能ノードについて、フロー管理スマコン１４０でパラメータの範囲や次に設定できる機能ノード情報などをチェックし、ビジネスロジックとして成立するかを判断する際に使用する。
　こうした品質チェック項目リストＴ３００は、インデックスＴ３０１、機能ノード種類Ｔ３０２、パラメータＴ３０３、最小値Ｔ３０４、最大値Ｔ３０５、型Ｔ３０６、および、次の機能ノードＴ３０７などで構成されている。
　このうち機能ノード種類Ｔ３０２は、図５の機能ノードテーブルＴ５０における機能ノード種類Ｔ５２と一対一対応している。また、パラメータＴ３０３は、その機能ノードで設定可能なパラメータを表しており、最小値Ｔ３０４、最大値Ｔ３０５は、そのパラメータの設定可能範囲を表している。
　例えば、「１週間での連続ログイン日数が何日以上か」を判定する条件分岐ノードの場合、パラメータの下限は「１」、上限は「７」である。
　また、型Ｔ３０６は、上述のパラメータＴ３０３の型を定義し、チェック時にはそれが正しいかどうかを判断する基準となる値である。例えば条件分岐ノードの場合では、小数点以下の数値ではなく、整数である必要があるため、型Ｔ３０６は、整数を表す「ｉｎｔｅｇｅｒ」である。
　また、次の機能ノードＴ３０７は、現在の機能ノード種類の次にどのような種類の機能ノードを配置することができるかを表したリストである。例えば、条件分岐ノードの次には、同じ種類の条件分岐ノードや出力ノードは接続することができるが、入力ノードは接続することができない。これは各機能ノードの入力と出力の型などからも判定することができる。
　品質チェック項目リストＴ３００は、ステークホルダーが定義する場合、全体としてひとつのリストを共有してもよいが、一部あるいはすべてをステークホルダーごとにカスタマイズして、ステークホルダーごとに裁量を持った品質チェックを行えるようにすることも考えられる。
＜スマートコントラクト実行方法＞
　図１６は、実施例３における自動承認フローｓ３００の一例を表す図である。自動承認フローｓ３００は、フロー管理スマコン１４０における、フローの登録、更新のトランザクション処理にカスタマイズされる形で実装される。
　このフロー登録処理ｓ３００において、まず、フロー管理スマコン１４０は、ユーザが発行したフロー登録トランザクションから、フロー名、バージョン、およびフローデータを入力として受け取る（ｓ３０１）。
　また、フロー管理スマコン１４０は、ｓ３０１で得たフローデータ中の各機能ノードについて、品質チェック項目リストＴ３００から該当する行を読み出し、対応するチェック項目をすべて満たしていることを確認する（ｓ３０２）。
　この確認の結果、チェック項目をすべて満たしていれば（ｓ３０３：Ｙｅｓ）、フロー管理スマコン１４０は、当該フローをフロー管理台帳Ｔ２１０に書き込み（ｓ３０４）、処理を終了する。
　一方、上述の確認の結果、チェック項目のうちいずれかを満たしていなければ（ｓ３０３：Ｎｏ）、フロー管理スマコン１４０は、エラーを返して処理を終了する。
＜効果＞
　上述の実施例３においては、実施例１により不要となったビジネスロジックの登録、更改におけるプログラム部分の承認作業に加えて、ビジネスロジックの品質担保のためにステークホルダーなどが手作業で行うべきフローの承認作業も自動化することが可能である。
　これにより本実施例では、ビジネスロジックの新規登録、更改において、従来では人手で行っている品質チェックや承認作業は不要となり、ビジネスロジックを頻繁に更改するケースや、多数のユーザにビジネスロジックを定義させるケースにおいて、承認作業にかかっていたコストを大幅に削減可能である。
　また、自動承認を行った証跡や、品質チェックリスト自体もブロックチェーンによって共有されているため、承認作業が透明であるという特徴がある。
　また、ステークホルダーごとにチェック項目をカスタマイズすることで、ステークホルダーがある程度の裁量を持ちつつ、承認作業を自動で行うことができる。
　本実施形態のスマートコントラクト実行方法、スマートコントラクト実行システム、およびノードによれば、業務判断にかかわるビジネスロジックをスマートコントラクトから分離し、プログラムの知識がない者でもカスタマイズ可能なフロー形式で分散台帳に保存し、スマートコントラクトから台帳上のフローを呼び出し、そのフローに従ってビジネスロジックを実行可能となる。ひいては、ビジネスロジックを頻繁に更改するケースや、多数のユーザにビジネスロジックを定義させるケースにおいて、プログラム部分の更改や新たな承認作業を行うことなく、スマートコントラクトによるビジネスロジックの実行が可能になる。
　すなわち、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のスマートコントラクト実行方法において、前記各ノードが、前記フローデータの登録、更改、および削除の少なくともいずれかの管理処理にまつわるトランザクションに関して、当該トランザクションの実行結果を各ノードで共有し、当該フローデータを前記分散台帳で管理する、フロー管理スマートコントラクトを実行するとしてもよい。
　これによれば、ビジネスロジックたるフローデータの管理を、ブロックチェーン技術に基づく合意形成等の処理を介して行うことが可能であり、ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトをより効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行方法において、前記各ノードが、前記フロー管理スマートコントラクトにおいて、前記管理処理の対象となるフローデータの当該管理処理を承認する承認トランザクションを発行するとしてもよい。
　これによれば、ビジネスロジックたるフローデータを、各ノードのユーザすなわちステークホルダーそれぞれの合意形成を図って適切に管理することができる。ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行方法において、前記各ノードが、前記フローデータの登録または更改を許容しうる条件を規定した品質チェックリストを保持し、前記フロー管理スマートコントラクトにおいて、前記管理処理のうち、フローデータの登録または更改に関して、前記品質チェックリストを用いて前記フローデータの品質チェックを実行し、当該フローデータの登録または更改の自動承認処理を行うとしてもよい。
　これによれば、フローデータの管理を、その品質条件に基づき自動化し、ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行方法において、前記各ノードが、各ユーザが管理する前記品質チェックリストを保持し、前記品質チェックに際して、当該ユーザの品質チェックリストを用いて前記フローデータの品質チェックを実行するとしてもよい。
　これによれば、フローデータの管理を、各ステークホルダーの望む品質条件に基づき自動化し、ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行方法において、前記各ノードが、前記分散台帳において、各フローデータに対して、当該フローデータを利用しうるユーザの属性情報を紐づけて管理し、当該ノードのユーザに応じたフローデータを前記分散台帳から読み込んで、当該フローデータに従ってスマートコントラクトを実行するとしてもよい。
　これによれば、フローデータに沿ったスマートコントラクト実行を、各ステークホルダーの属性に応じて自動化し、ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行方法において、前記各ノードが、前記スマートコントラクトにおいて、前記フローデータが含む機能ノードの種類ごとに機能ノード実行スマートコントラクトが定義されている場合、前記分散台帳から読み込んだ前記フローデータに従って、前記スマートコントラクトから前記機能ノード実行スマートコントラクトを実行するとしてもよい。
　これによれば、スマートコントラクト実行を効率的なものとし、ひいては、スマートコントラクトにおけるビジネスロジックの登録や更改等が高頻度に発生する状況にも的確に対応し、当該スマートコントラクトを効率的に管理、実行することが可能となる。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、前記フローデータの登録、更改、および削除の少なくともいずれかの管理処理にまつわるトランザクションに関して、当該トランザクションの実行結果を各ノードで共有し、当該フローデータを前記分散台帳で管理する、フロー管理スマートコントラクトを実行するものであるとしてもよい。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、前記フロー管理スマートコントラクトにおいて、前記管理処理の対象となるフローデータの当該管理処理を承認する承認トランザクションを発行するものである、としてもよい。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、前記フローデータの登録または更改を許容しうる条件を規定した品質チェックリストを保持し、前記フロー管理スマートコントラクトにおいて、前記管理処理のうち、フローデータの登録または更改に関して、前記品質チェックリストを用いて前記フローデータの品質チェックを実行し、当該フローデータの登録または更改の自動承認処理を行うものである、としてもよい。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、各ユーザが管理する前記品質チェックリストを保持し、前記品質チェックに際して、当該ユーザの品質チェックリストを用いて前記フローデータの品質チェックを実行するものである、としてもよい。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、前記分散台帳において、各フローデータに対して、当該フローデータを利用しうるユーザの属性情報を紐づけて管理し、当該ノードのユーザに応じたフローデータを前記分散台帳から読み込んで、当該フローデータに従ってスマートコントラクトを実行するものである、としてもよい。
　また、本実施形態のスマートコントラクト実行システムにおいて、前記複数のノードそれぞれは、前記スマートコントラクトにおいて、前記フローデータが含む機能ノードの種類ごとに機能ノード実行スマートコントラクトが定義されている場合、前記分散台帳から読み込んだ前記フローデータに従って、前記スマートコントラクトから前記機能ノード実行スマートコントラクトを実行するものである、としてもよい。
１　ネットワーク
１０　スマートコントラクト実行システム
１００～３００　ノード
１０１　記憶装置
１０２　プログラム
１０３　メモリ
１０４　演算装置
１０５　通信装置
１１０　スマコン実行部
１２０　フロー実行スマコン
１３０　機能ノード実行スマコン
１４０　フロー管理スマコン
１５０　分散台帳
Ｔ１０、Ｔ２１０　フロー管理台帳
Ｔ２０　ステート管理台帳
Ｔ３０　ブロックチェーンデータ
Ｔ４０　フローテーブル
Ｔ５０　機能ノードテーブル
Ｔ６０　フロー管理トランザクション
Ｔ７０　フロー実行トランザクション
Ｔ２００　承認トランザクション
Ｔ３００　品質チェック項目リスト
１６０　通信部
１７０　クライアントアプリケーション

Claims (15)

  1. 　ブロックチェーンシステムを構成する各ノードが、分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行することを特徴とする、スマートコントラクト実行方法。
  2. 　前記各ノードが、
    　前記フローデータの登録、更改、および削除の少なくともいずれかの管理処理にまつわるトランザクションに関して、当該トランザクションの実行結果を各ノードで共有し、当該フローデータを前記分散台帳で管理する、フロー管理スマートコントラクトを実行することを特徴とする請求項１に記載のスマートコントラクト実行方法。
  3. 　前記各ノードが、
    　前記フロー管理スマートコントラクトにおいて、前記管理処理の対象となるフローデータの当該管理処理を承認する承認トランザクションを発行することを特徴とする、請求項２に記載のスマートコントラクト実行方法。
  4. 　前記各ノードが、
    　前記フローデータの登録または更改を許容しうる条件を規定した品質チェックリストを保持し、
    　前記フロー管理スマートコントラクトにおいて、前記管理処理のうち、フローデータの登録または更改に関して、前記品質チェックリストを用いて前記フローデータの品質チェックを実行し、当該フローデータの登録または更改の自動承認処理を行うことを特徴とする、請求項２に記載のスマートコントラクト実行方法。
  5. 　前記各ノードが、
    　各ユーザが管理する前記品質チェックリストを保持し、前記品質チェックに際して、当該ユーザの品質チェックリストを用いて前記フローデータの品質チェックを実行することを特徴とする、請求項４に記載のスマートコントラクト実行方法。
  6. 　前記各ノードが、
    　前記分散台帳において、各フローデータに対して、当該フローデータを利用しうるユーザの属性情報を紐づけて管理し、当該ノードのユーザに応じたフローデータを前記分散台帳から読み込んで、当該フローデータに従ってスマートコントラクトを実行することを特徴とする、請求項1に記載のスマートコントラクト実行方法。
  7. 　前記各ノードが、
    　前記スマートコントラクトにおいて、前記フローデータが含む機能ノードの種類ごとに機能ノード実行スマートコントラクトが定義されている場合、前記分散台帳から読み込んだ前記フローデータに従って、前記スマートコントラクトから前記機能ノード実行スマートコントラクトを実行することを特徴とする、請求項１に記載のスマートコントラクト実行方法。
  8. 　複数のノードから構成されるブロックチェーンシステムであって、前記複数のノードそれぞれは、分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行するものである、ことを特徴とするスマートコントラクト実行システム。
  9. 　前記複数のノードそれぞれは、
    　前記フローデータの登録、更改、および削除の少なくともいずれかの管理処理にまつわるトランザクションに関して、当該トランザクションの実行結果を各ノードで共有し、当該フローデータを前記分散台帳で管理する、フロー管理スマートコントラクトを実行するものである、ことを特徴とする請求項８に記載のスマートコントラクト実行システム。
  10. 　前記複数のノードそれぞれは、
    　前記フロー管理スマートコントラクトにおいて、前記管理処理の対象となるフローデータの当該管理処理を承認する承認トランザクションを発行するものである、ことを特徴とする請求項９に記載のスマートコントラクト実行システム。
  11. 　前記複数のノードそれぞれは、
    　前記フローデータの登録または更改を許容しうる条件を規定した品質チェックリストを保持し、
    　前記フロー管理スマートコントラクトにおいて、前記管理処理のうち、フローデータの登録または更改に関して、前記品質チェックリストを用いて前記フローデータの品質チェックを実行し、当該フローデータの登録または更改の自動承認処理を行うものである、
    　ことを特徴とする請求項９に記載のスマートコントラクト実行システム。
  12. 　前記複数のノードそれぞれは、
    　各ユーザが管理する前記品質チェックリストを保持し、前記品質チェックに際して、当該ユーザの品質チェックリストを用いて前記フローデータの品質チェックを実行するものである、ことを特徴とする、請求項１１に記載のスマートコントラクト実行システム。
  13. 　前記複数のノードそれぞれは、
    　前記分散台帳において、各フローデータに対して、当該フローデータを利用しうるユーザの属性情報を紐づけて管理し、当該ノードのユーザに応じたフローデータを前記分散台帳から読み込んで、当該フローデータに従ってスマートコントラクトを実行するものである、ことを特徴とする、請求項８に記載のスマートコントラクト実行システム。
  14. 　前記複数のノードそれぞれは、
    　前記スマートコントラクトにおいて、前記フローデータが含む機能ノードの種類ごとに機能ノード実行スマートコントラクトが定義されている場合、前記分散台帳から読み込んだ前記フローデータに従って、前記スマートコントラクトから前記機能ノード実行スマートコントラクトを実行するものである、ことを特徴とする請求項８に記載のスマートコントラクト実行システム。
  15. 　ブロックチェーンシステムを構成するノードであって、
    　分散台帳において、ビジネスロジックが記載されている機能ノードのつながりで構成されたフローデータを管理し、所定のトランザクションに関して、対応するフローデータを前記分散台帳から読み込み、当該フローデータに従ってスマートコントラクトを実行するものである、
    　ことを特徴とするノード。
PCT/JP2020/003904 2020-02-03 2020-02-03 スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード WO2021156909A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/003904 WO2021156909A1 (ja) 2020-02-03 2020-02-03 スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/003904 WO2021156909A1 (ja) 2020-02-03 2020-02-03 スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード

Publications (1)

Publication Number Publication Date
WO2021156909A1 true WO2021156909A1 (ja) 2021-08-12

Family

ID=77199877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/003904 WO2021156909A1 (ja) 2020-02-03 2020-02-03 スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード

Country Status (1)

Country Link
WO (1) WO2021156909A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023119398A1 (ja) * 2021-12-21 2023-06-29 株式会社東芝 ブロックチェーンシステム、ブロックチェーンシステム更新方法及びプログラム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019021792A1 (ja) * 2017-07-26 2019-01-31 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019021792A1 (ja) * 2017-07-26 2019-01-31 株式会社日立製作所 運用管理方法、運用管理システム、および、運用管理プログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KANEKO, YUSUKE ET AL.: "Use of blockchain in trade practices, practices and challenges", JOURNAL OF DIGITAL PRACTICES, vol. 10, no. 3, 15 July 2019 (2019-07-15), pages 492 - 505, ISSN: 2188-4390 *
SATO, TATSUYA ET AL.: "Scope expansions and component-based architecture design of operational smart-contract for permissioned blockchain system", IEICE TECHNICAL REPORT, vol. 118, no. 118, 28 June 2018 (2018-06-28), pages 41 - 46, ISSN: 2432-6380 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023119398A1 (ja) * 2021-12-21 2023-06-29 株式会社東芝 ブロックチェーンシステム、ブロックチェーンシステム更新方法及びプログラム

Similar Documents

Publication Publication Date Title
US10762142B2 (en) User-defined automated document feature extraction and optimization
US10936554B2 (en) Incremental rationalization in hierarchical systems
US20240179151A1 (en) Hierarchical permissions model for case management
US11048762B2 (en) User-defined automated document feature modeling, extraction and optimization
US20230148060A1 (en) Workflow application and user interface builder integrating objects, relationships, and actions
US8595288B2 (en) Enabling SOA governance using a service lifecycle approach
US20190096012A1 (en) System and method for real estate development and construction cost and risk management
US10796081B2 (en) System and method for processing electronic forms
WO2021156909A1 (ja) スマートコントラクト実行方法、スマートコントラクト実行システム、およびノード
US20150278316A1 (en) Task reduction in dynamic case management
Choudhary et al. A business process re-engineering approach to transform business process simulation to BPMN model
US20160070832A1 (en) Modeling system and method for modeling a process or system
US20160063421A1 (en) Systems and methods for service level agreement focused document workflow management
US9244651B2 (en) Document revision control
US9922059B1 (en) Case model—data model and behavior versioning
EP2940631A1 (en) Secure multiple customer relationship management interface framework
CN105844381A (zh) 基于业务变化的业务影响位置提取方法及其提取装置
Yue A Blockchain-Inspired, Multi-Layered Transaction Model for Business Process Modeling.
JP2017016307A (ja) ワークフロー情報管理装置及びそのプログラム
Garcés et al. White-box modernization of legacy applications
US20150019451A1 (en) Decision basis for benefits program
JP2013228958A (ja) ワークフローシステム、ワークフローシステムの制御方法、プログラムおよび記録媒体
US20230274082A1 (en) Smart form management systems and methods
JP7227762B2 (ja) 融資管理装置、融資管理方法、及び融資管理プログラム
Wainwright et al. Making sense of IT vendor and client relationships: A technological frames perspective

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: 20917688

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: 20917688

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP