Federated learning system and federated learning method

Abstract

To provide a technology for giving an appropriate incentive to a Federated learning (FL) client who provides an initial FL model first in an FL system.SOLUTION: An FL system using a smart-contract-based blockchain technology includes: a first information processing device having an initial FL model; and a second information processing device for training the initial FL model provided from the first information processing device. In the FL system, the first information processing device comprises an initial FL model sharing contract that is a smart contract used for sharing the initial FL model with the second information processing device, and that includes reward information on a reward as a token that a user of the first information processing device receives from a user of the second information processing device for the sharing of the initial FL model.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a federated learning system and a federated learning method. [Background technology]

[0002] In machine learning, especially when learning complex models such as deep neural networks, it is important to collect a large amount of diverse learning data. Federated Learning (FL) is an approach that realizes large-scale learning while protecting privacy and reducing communication traffic by having many clients hold data locally and share only the model and update parameters such as weights.

[0003] In conventional FL, where model update servers are deployed centrally, it is difficult to design incentives for FL participants. Therefore, a study is being conducted in Non-Patent Document 1 on providing incentives for FL participation through reward design using tokens of blockchain technology. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] AR Short, HC Leligou and E. Theocharis, “Execution of a Federated Learning process in a smart contract,” 2021 IEEE International Conference on Consumer Electronics (ICCE), 2021, pp. 1-4, doi: 10.1109 / ICCE50685.2021.9427734. Summary of the Invention [Problem to be solved by the invention]

[0005] One possible architecture is to build a system that executes FL on the blockchain, and the FL progresses through a smart contract. A method is proposed in which a reward according to the FL contribution is given as an incentive to FL contributors by providing an FL model performance verification unit in the smart contract to evaluate the contribution of FL contributors. However, while the above method gives FL contributors an incentive to actively participate in FL, the incentive design for FL requesters is considered to be insufficient.

[0006] Conventionally, for example, the improvement of the AI ​​model's performance through FL is considered to be an incentive for FL clients. However, considering that the incentive for FL participants has increased due to the use of blockchain technology, it is considered necessary to design incentives that more appropriately provide incentives to FL clients from this perspective as well. [Means for solving the problem]

[0007] A representative example of the invention disclosed in the present application is as follows. The federated learning system is a system using smart contract type blockchain technology. This system includes a first information processing device having an initial federated learning model, and a second information processing device that trains the initial federated learning model provided by the first information processing device. The first information processing device includes an initial federated learning model sharing contract, which is a smart contract used for sharing the initial federated learning model with the second information processing device and includes reward information in the form of tokens that a user of the first information processing device receives from a user of the second information processing device in response to the sharing.

[0008] A representative example of the invention disclosed in the present application is as follows: The federated learning system is a system using smart contract type blockchain technology. This system is used to share an initial federated learning model owned by a first information processing device that requests federated learning with a second information processing device that trains the model, and includes an initial federated learning model sharing contract, which is a smart contract that includes reward information in the form of tokens that a user of the first information processing device receives from a user of the second information processing device in return for the sharing.

[0009] A representative example of the invention disclosed in the present application is as follows: A federated learning method using smart contract-type blockchain technology, comprising the steps of: a first information processing device sharing an initial federated learning model with a second information processing device by using an initial federated learning model sharing contract, which is a smart contract used for sharing an initial federated learning model from a first information processing device to a second information processing device that trains the model; and a step of the first information processing device obtaining a reward in the form of tokens when the second information processing device shares the initial federated learning model. Effect of the Invention

[0010] According to the present disclosure described above, the FL client can receive a reward in the form of tokens in the FL, and an appropriate incentive design for the FL client is realized. Note that the problems, configurations, and effects other than those described above will become clear from the following description of the embodiment of the invention. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of the overall configuration of an FL system using a smart contract type blockchain. [Diagram 2] This is a diagram to explain the details of an example configuration of an FL system using a smart contract type blockchain. [Diagram 3] FIG. 13 is a diagram showing an example of a published task description. [Figure 4]A diagram showing an example of information writing to the shared storage and distributed ledger by a smart contract for FL. [Diagram 5] FIG. 13 is a diagram illustrating an example of a state table. [Figure 6] A diagram showing the configuration of a smart contract for FL and an example of the configuration of a distributed ledger. [Figure 7] 1 is a flowchart showing an example of the process of using an FL system using a smart contract type blockchain. [Figure 8] FIG. 11 is a diagram illustrating an example of a sequence for determining whether to participate in a task. [Figure 9] FIG. 13 is a diagram illustrating an example of a sequence of FL-initiated contract execution. [Figure 10] FIG. 13 is a diagram illustrating an example of a sequence of execution of an initial FL model shared contract. [Figure 11] FIG. 13 illustrates an example sequence of FL model weight sharing contract execution. [Figure 12] FIG. 13 is a diagram illustrating an example of a sequence of FL model update contract execution. [Figure 13] FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device used in the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment is an example for explaining the present invention, and appropriate omissions and simplifications are made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings. As examples of various information, the various information may be described using expressions such as "table," "list," and "queue," but the various information may be expressed using data structures other than these. For example, various information such as "XX table," "XX list," and "XX queue" may be expressed as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are mutually interchangeable. When there are multiple components having the same or similar functions, they may be described by using the same reference numerals with different subscripts, or when there is no need to distinguish between these multiple components, the subscripts may be omitted. In the embodiment, a process performed by executing a program may be described. Here, a computer executes the program using a processor (e.g., CPU, GPU), and performs the process defined by the program while using a storage resource (e.g., memory) and an interface device (e.g., communication port), etc. Therefore, the subject of the process performed by executing the program may be the processor. Similarly, the subject of the process performed by executing the program may be a controller, device, system, computer, or node having a processor. The subject of the process performed by executing the program may be a calculation unit, and may include a dedicated circuit that performs a specific process. Here, the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device), etc. The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource that stores the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in the embodiment, two or more programs may be realized as one program, and one program may be realized as two or more programs.

[0013] In the embodiment, a federated learning technology using a smart contract type blockchain will be described. According to the embodiment, by improving the incentives of FL, contributions from an economic perspective can be expected.

[0014] First, an overview of the overall configuration of an FL system using a smart contract type blockchain will be described with reference to Figure 1. Figure 1 is a diagram showing an example of the overall configuration of an FL system using a smart contract type blockchain.

[0015] An FL requester who wishes to improve the performance of an AI model has an FL request server 100, which stores an initial FL model 111, which is an AI model to be trained by the FL. In addition, an FL collaborator who cooperates with the FL has an FL cooperation server 200, which stores local training data 119 for training the AI ​​model. The FL system 1 is an FL system that uses a smart contract type blockchain, and FL is executed via a smart contract between each node participating in the FL system 1. The FL system management device 2 is a server owned by an FL system administrator who manages the FL system 1.

[0016] In this embodiment, the FL system 1 is assumed to be executed by a blockchain network such as EOS or Ethereum, which can realize distributed applications (DApps) related to the application of blockchain such as smart contracts. However, any network using distributed ledger technology in which the registration and management of information executed by contracts is subsequently performed by a specific administrator can be used.

[0017] Next, a detailed example of the configuration of an FL system will be described with reference to Fig. 2. Fig. 2 is a diagram showing details of an example of the configuration of an FL system using a smart contract type blockchain.

[0018] As shown in FIG. 2, the FL system is a smart contract type blockchain system, and includes an FL request server 100 operated by an FL requester (user), and an FL cooperation server 200 operated by an FL collaborator (user). These information processing devices (100, 200) are connected in an autonomously distributed manner to a peer-to-peer (P2P) blockchain network 4. Note that in addition to the information processing devices (100, 200) shown in the figure, multiple information processing devices are connected to the network 4. For example, multiple AI model update servers used by other FL participants and multiple AI model training servers used by other FL requesters may be connected.

[0019] The FL request server 100 and the FL cooperation server 200 are equipped with a blockchain system execution unit 10, which stores a contract issuance unit 11 that issues FL smart contracts, a blockchain control unit 12 that maintains the blockchain system in autonomous and decentralized cooperation with information processing devices connected to the network 4, a history search unit 13 that can access the recorded information in the distributed ledger 113 and obtain contract information, and a token management unit 14 that manages the balances of tokens exchanged via smart contracts.

[0020] The FL request server 100 includes a storage 110a using, for example, a magnetic disk as a medium. The storage 110a of the FL request server 100 stores an initial FL model 111, FL model evaluation data 112, a distributed ledger 113, an FL model weight aggregation program 114, an FL start contract 115, an initial FL model sharing contract 116, an FL model update contract 117, and a task description 118. The initial FL model 111 (initial federated learning model) is an AI model specific to the FL request server before training by FL. The FL model evaluation data 112 is data used to evaluate the accuracy of the FL model in the FL process. The distributed ledger 113 records contract information by a smart contract. The FL model weight aggregation program 114 is a program that aggregates FL model weights shared from the FL cooperation server 200. The FL start contract 115 is a smart contract for acquiring an ID for identifying a collaborator at the start of an FL. The initial FL model sharing contract 116 (initial federated learning model sharing contract) is a smart contract for sharing the initial FL model 111 to the FL collaborative server 200. The FL model update contract 117 is a contract for evaluating the accuracy of the model aggregated by the model weight aggregation program 114 and executing model update. The task description 118 is appropriately created by the FL requester, and the contents of the FL task request are described in the task description 118. The task request contents described in the task description 118 are shared with the entire smart contract type blockchain system via the task description publication unit 101.

[0021] The FL cooperating server 200 includes a storage 110b, and the storage 110b of the FL cooperating server 200 stores a distributed ledger 113, similar to the FL request server 100. The storage 110b also stores local training data 119 and an FL model weight sharing contract 120. The local training data 119 is data for training the initial FL model 111 shared by the FL request server 100. The FL model weight sharing contract 120 is a smart contract for sharing model weights obtained by local training with the FL request server.

[0022] The FL cooperation server 200 includes a task description viewing unit 201, and an FL collaborator can access the task content disclosure unit 101 via the task description viewing unit 201 and view the contents of the task description. The FL participant determines whether or not to participate in the FL based on the contents of the task description 118 viewed via the task description viewing unit 201, and the task participation determination unit 202 conveys the input determination result to the FL request server 100.

[0023] The shared storage 300 stores the initial FL model 101, model weights, etc. as files, and is responsible for sharing files between the FL request server 100 and the FL cooperating server 200 by smart contract. The shared storage 300 may be a centralized type in which the FL request server 100 manages files, or a decentralized type in which files are managed in a peer-to-peer manner such as IPFS (InterPlanetary File System).

[0024] The network interface 130 is an interface for connecting to an appropriate network. The network interface 130 is used, for example, for connecting the FL request server 100 and the FL cooperation server 200 to the blockchain network 4.

[0025] In this embodiment, the functional units necessary for the present invention are provided on the information processing device (100, 200), but this is only one example of an embodiment of the present invention, and functional units other than the block chain system execution unit 10 do not necessarily need to be present inside the information processing device (100, 200). Therefore, it is also possible to provide functional units on the shared storage 300.

[0026] Next, an example of the contents of a task description will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of a published task description.

[0027] The initial FL model usage fee 1011 is set to an arbitrary value by the FL requester who operates the FL request server 100. Depending on the value set in the initial FL model usage fee 1011, the FL requester can obtain tokens in exchange for sharing the initial FL model 111 with the FL cooperation server 200 via the initial FL model sharing contract 116.

[0028] The FL requester inputs into the task description 118 the number of learning rounds 1012, which indicates the number of times the FL model update contract 117 will be executed, the type of learning data 1013, which indicates the field to which the learning model will be applied, the learning model used 1014, which indicates the base model network used in the initial FL model, the FL cooperation reward 1015, which indicates the FL cooperation reward based on the FL model accuracy evaluation result after aggregation by the FL model update contract 117, the number of FL collaborators wanted 1016, which indicates the number of FL collaborators required to issue an FL start contract, and the number of aggregated models 1017, which indicates the number of models required to execute the FL model update contract 117.

[0029] Next, an example of information processing in the shared storage will be described with reference to Fig. 4. Fig. 4 is a diagram showing the configuration of the shared storage and an example of information writing in a smart contract.

[0030] On a blockchain, it is not easy to directly transmit and receive large files between the FL request server 100 and the FL cooperating server 200. Therefore, the shared storage 300 is configured using a technology (such as IPFS) that can assign unique address information to stored files. The FL requester then uploads the initial FL model 111 from the storage 110a of the FL request server 100 onto the shared storage 300, and shares the initial FL model 111 by transmitting the address information to the FL cooperating server 200 via the initial FL model sharing contract 116.

[0031] Then, each time a contract to store the FL model weight in the shared storage 300 is approved, the FL model weight 303 and the aggregated model weight 304 are stored in the shared storage 300, and the hash values ​​of the stored FL model weight 303 and aggregated model weight 304 and the address information on the shared storage are written to the distributed ledger 113.

[0032] The state table 302 stores meta-information of the FL model weights 303, which is referenced during contract verification. The accuracy evaluation program 301 is called when the FL model update contract 117 is executed, and the evaluation data 112 uploaded from the FL request server 100 to the shared storage 300 is used to evaluate the accuracy of the aggregated model and to evaluate the contribution of the FL cooperating server 200.

[0033] Here, the state table 302 will be described in detail with reference to Fig. 5. Fig. 5 is a diagram showing an example of a state table. Written in the state table 302 are the identification ID of the FL request server 100 or the FL cooperation server 200 that uploaded the learning model weight 303, which is the value of the model weight, the address information of the FL model weight 303 on the shared storage 300, learning round information, etc. The information written in the state table 302 is referenced to verify whether there is any discrepancy in the contract input contents when verifying the FL model weight sharing contract 120 and the FL model update contract 117.

[0034] Next, a configuration example of a smart contract for FL and a configuration example of a distributed ledger will be described with reference to Fig. 6. Fig. 6 is a diagram showing a configuration example of a smart contract for FL and a configuration example of a distributed ledger.

[0035] The FL start contract 115 is a contract issued by the FL requester from the FL request server 100, and includes a task description information input unit 1151 that inputs the FL task information described in the task description 118, and an FL start approval unit 1152 that is executed when the contract is approved. The FL start approval unit 1152 includes a task description information recording unit 1153 that records the FL task information input to the task description information input unit 1151 inside the recorded information 1133 of the distributed ledger 113, and a collaborator identification ID recording unit 1154 that records the collaborator identification ID 1135.

[0036] The initial FL model sharing contract 116 is a contract issued by an FL requester from the FL request server 100, and includes an initial model address input unit 1161 for inputting address information of the initial FL model 111 uploaded to the shared storage 300, and an initial FL model sharing approval unit 1162 that is executed when the contract is approved. The initial FL model sharing approval unit 1162 includes a model usage fee input unit 1163 for inputting the initial FL model usage fee 1011.

[0037] The FL model weight sharing contract 120 is a contract issued by an FL collaborator from the FL collaborating server 200, and includes a hashed FL model weight input unit 1201 that inputs a hash value of the FL model weight 303 uploaded by the FL collaborating server 200 to the shared storage 300, an FL model weight address input unit 1202 that inputs address information of the FL model weight 303, and an FL model weight sharing approval unit 1203 that is executed at the time of contract approval. The FL model weight sharing approval unit 1203 includes a hashed FL model weight recording unit 1204 that records the hashed FL model weight input to the hashed FL model weight input unit 1201, and an FL model weight address recording unit 1205 that records the FL model weight address information input to the FL model weight address input unit 1202, inside the record information 1133 of the distributed ledger 113.

[0038] The FL model update contract 117 is a contract issued by the FL requester from the FL request server 100, and includes an FL model weight aggregation unit 1171 that aggregates the FL model weights 303 shared from the FL cooperation server 200 by the initial FL model sharing contract 116, a hashed FL model weight input unit 1201 that inputs the hash value of the aggregated model weights, an FL model weight address input unit 1202 that inputs address information of the aggregated FL model weights 304 uploaded by the FL requester to the shared storage 300, an aggregated model accuracy evaluation unit 1172 that evaluates the performance of the aggregated model using the model evaluation data 112 and the accuracy evaluation program 301, and an FL model update approval unit 1173 that is executed when the contract is approved. The FL model update approval unit 1173 includes, within the recorded information 1133 of the distributed ledger 113, an FL cooperation reward input unit 1174 that inputs rewards to FL contributors based on the model evaluation results in the aggregated model accuracy evaluation unit 1172, a hashed FL model weight recording unit 1204 that records the hashed FL model weights input to the hashed FL model weight input unit 1201, and an FL model weight address recording unit 1205 that records the FL model weight address information input to the FL model weight address input unit 1202.

[0039] The distributed ledgers 113 are connected in series to form a so-called blockchain. The distributed ledger 113 has a timestamp 1131, a hash value 1132 of the previous ledger information, and recorded information 1133. The timestamp 1131 is information indicating the date and time when the ledger was generated. The hash value 1132 of the previous ledger information is a value generated based on a hash function preset for the previous ledger information. The recorded information 1133 is the main body of information recorded upon each contract approval, and for example, task description information 1134, collaborator identification ID 1135, FL model weight hash value 1136, and FL model weight address 1137 are recorded.

[0040] Next, an example of the flow of using the FL system will be described with reference to Fig. 7. Fig. 7 is a flowchart showing an example of the flow of using the FL system using a smart contract type blockchain. The processes of s1 to s13 will be described below.

[0041] In s1, the FL requester and the FL collaborator pay a certain fee to the FL system and register their respective information processing devices as the FL request server 100 or the FL collaborator server 200.

[0042] In s2, the FL system provides a certain amount of tokens to the requester or collaborator who registered in s1 the FL request server 100 or the FL cooperation server 200. The provided tokens are managed by the token management unit 14.

[0043] In s3, the FL requester creates a task description 118 that describes the task content of the AI ​​model training that the FL requester wants to request in FL in order to recruit FL collaborators. The FL requester creates the task description 118 by inputting information including the initial FL model usage fee 1011.

[0044] In s4, the FL requester pays a fee in the form of a token and publishes the FL description 118 created in s3 on the FL system via the task description publication unit 101. In s4, the FL requester pays a fee to the system operator, for example, to the system management device 2 (FL system administrator).

[0045] In s 5 , the FL collaborator determines whether or not to participate in the task based on the contents of the FL task description 110 , and the determination result is input to the task participation determination unit 202 , and the determination result is transmitted to the FL request server 100 .

[0046] In s6, the FL requester checks the result of the task participation decision, and in s7, it is determined whether the number of FL collaborators has reached the number of FL collaborators recruited 1016 written in the task description 118 as a result of the task participation decision checked in s6. If the answer is Yes (s7: Yes), s8 is performed, and if the answer is No (s7: No), s6 is performed.

[0047] In s8, the FL start contract 115 issued by the FL requester from the FL request server 100 is executed.

[0048] In s9, the initial FL model sharing contract 116 issued by the FL requester from the FL request server 100 is executed.

[0049] In s10, the FL model weight sharing contract 120 issued by the FL collaborator from the FL collaborating server 200 is executed.

[0050] In s11, the FL system determines whether the number of executions of the FL model weight sharing contract 120 has reached the number of aggregate models 1017 described in the task description 118. If Yes (s11: Yes), s12 is performed, and if No (s11: No), s10 is performed.

[0051] In s12, the FL model update contract 117 issued by the FL requester from the FL request server 100 is executed.

[0052] In s13, the FL system determines whether the number of executions of the FL model update contract 117 has reached the number of learning rounds 1012 entered in the task description 118. If the answer is No (s13: No), s10 is performed, and if the answer is Yes (s13: Yes), the sequence ends.

[0053] Next, the details of the task participation determination will be described with reference to Fig. 8. Fig. 8 is a diagram showing an example of a sequence of the task participation determination. The specific operation of s5, in which the FL collaborator determines whether to participate in the FL based on the task description, is shown below in the process of s14 to s18.

[0054] In s14, the FL request server 100 makes the task description 118 created by the FL requester public to the FL collaborators via the task description publicizing unit 101.

[0055] In s15, the FL cooperation server 200 acquires the data of the task description 118 published by the FL requester, and the FL cooperation party views the contents of the task description 118 via the task description viewing unit 201.

[0056] In s16, the FL collaborator determines whether or not to participate in the task via the task participation determination unit 202 based on the contents of the task description 118 viewed in s15.

[0057] In s17, if the decision to participate is made in s16, the FL cooperation server 200 transmits participation information via the task participation decision unit 202.

[0058] In s18, the FL request server 100 acquires the helper identification ID from the participation information transmitted via the task participation determination unit 202 in s17.

[0059] Next, the details of the FL start contract execution will be described with reference to Fig. 9. This is a diagram showing an example of the sequence of the FL start contract execution. The specific operations of the FL start contract execution s8 will be shown in the following processing of s19 to s25.

[0060] In s19, the FL requester checks the contents of the task description 110 created in s3.

[0061] In s20, the FL requester inputs the contents of the task description 110 confirmed in s15 into the task description information input section 1151 of the FL starting contract 115.

[0062] In s21, the FL requester transmits the contract. That is, the FL request server 100 transmits the FL initiation contract 115 to the FL collaborator via the contract issuing unit 11.

[0063] In s22, the FL cooperator receives the contract. That is, the FL cooperator server 200 receives the contract transmitted from the FL requester in s21.

[0064] In s23, the FL collaborator verifies whether there are any errors in the task description information input section 1151 of the FL starting contract 115 received in s22.

[0065] In s24, the FL collaborator performs an operation such as electronic signature and the contract is approved.

[0066] In s25, the FL start approval unit 1152 is executed, and the task description information recording unit 1153 and the collaborator identification ID recording unit 1134 record the task description information 1134 and the collaborator identification ID 1135 in the record information 1133 of the distributed ledger 113.

[0067] Next, details of the execution of the initial FL model shared contract will be described with reference to Fig. 10. Fig. 10 is a diagram showing an example of a sequence of the execution of the initial FL model shared contract. Specific operations of s9 related to the execution of the initial FL model shared contract 116 will be shown in the following processes of s26 to s35.

[0068] In s26, the FL requester uploads the initial FL model 110 on the FL request server 100 onto the shared storage 300.

[0069] In s27, the FL requester obtains address information on the shared storage 300 of the initial FL model 110 uploaded to the shared storage 300 in s26.

[0070] In s28, the FL requester inputs the address information of the initial FL model 110 acquired in s27 to the initial FL model address input unit 1161 of the initial FL model sharing contract 116.

[0071] In s29, the FL requester inputs the value input in the initial FL model usage fee 1011 of the task description 118 to the initial FL model usage fee input section 1163 in the initial FL model sharing approval section 1162 of the initial FL model sharing contract 116.

[0072] In s30, the FL requester transmits the contract. That is, the FL request server 100 transmits the initial FL model sharing contract 116 to the FL collaborator via the contract issuing unit 11.

[0073] In s31, the FL cooperator receives the contract. That is, the FL cooperator server 200 receives the contract transmitted from the FL requester in s30.

[0074] In s32, the FL collaborator obtains the address information of the initial FL model 110 inputted in the initial FL model address input section 1161, and downloads the initial FL model 111.

[0075] In s33, the FL collaborator verifies whether there are any errors in the initial FL model 111 obtained in s32 and whether there are any errors in the initial FL model usage fee input section 1163 of the initial FL model sharing contract 116.

[0076] In s34, the FL collaborator performs an operation such as electronic signature and the contract is approved.

[0077] In s35, the initial FL model sharing approval section 1162 is executed, and tokens are paid from the FL collaborator to the FL requester in the amount equal to the value inputted in the initial FL model usage fee input section 1163.

[0078] Next, details of the FL model weight sharing contract execution will be described with reference to Fig. 11. Fig. 11 is a diagram showing an example of a sequence of the FL model weight sharing contract execution. Specific operations related to the execution s10 of the FL model weight sharing contract 120 will be shown in the following processes of s36 to s49.

[0079] In s36, the FL collaborators train the FL models using the local training data 119 on the FL collaborating servers 200.

[0080] In s37, the FL collaborator server 200 obtains the weights of the FL model that the FL collaborator trained using the local training data 119.

[0081] In s38, the FL cooperation server 200 calculates a hash value of the FL model weight obtained in s37 using a hash function.

[0082] In s39, the FL collaborator uploads the weights of the FL model after training as FL model weights 303 onto the shared storage 300.

[0083] In s40, the FL collaborator obtains address information on the shared storage 300 of the FL model weights 303 uploaded to the shared storage 300 in s39.

[0084] In s41, the FL collaborator inputs into the state table 302 the weight values ​​of the FL model weights 303 uploaded in s39, as well as metadata such as the number of learning rounds, an address, and collaborator identification ID information.

[0085] In s42, the FL collaborator inputs the hash value of the FL model weight 303 calculated in s38 to the FL model weight hash value input unit 1201 of the FL model weight sharing contract 120.

[0086] In s43, the FL collaborator inputs the address information of the FL model weight 303 acquired in s40 to the FL model weight address input unit 1202 of the FL model weight sharing contract 120.

[0087] In s44, the FL collaborator transmits the contract. That is, the FL collaborator server 200 transmits the FL model weight sharing contract 120 to the FL requester via the contract issuing unit 11.

[0088] In s45, the FL requester receives the contract. That is, the FL cooperation server 100 receives the contract transmitted by the FL cooperation party in s44.

[0089] In s 46 , the FL requester acquires the address information of the FL model weight 303 inputted to the FL model weight address input unit 1202 , and downloads the FL model weight 303 .

[0090] In s47, the FL requester checks the FL model weight 303 acquired in s46 against the state table to verify whether the FL model weight 303 is correct.

[0091] In s48, the FL client performs an operation such as electronic signature and the contract is approved.

[0092] In s49, the FL model weight sharing approval unit 1203 is executed, and the FL model weight hash value recording unit 1204 and the FL model weight address recording unit 1205 record the FL model weight hash value 1136 and the FL model weight address 1137 in the recording information 1133 of the distributed ledger 113.

[0093] Next, details of the FL model update contract execution will be described with reference to Fig. 12. Fig. 12 is a diagram showing an example of a sequence of the FL model update contract execution. Specific operations related to the execution s12 of the FL model update contract 117 will be shown in the following processes of s50 to s66.

[0094] In s50, the FL requester confirms that the number of executions of the FL model weight sharing contract 120 matches the number of aggregate models 1017 entered in the task description 118.

[0095] In s51, the FL model weight aggregation program 114 is executed, and the FL model weight aggregation program 114 aggregates a plurality of FL model weights 303 shared via the FL model weight sharing contract 120. The FL model weight aggregation program 114, for example, refers to the state table 302 and the recorded information 1133, reads out the FL model weights 303 in order from the most recent to the least recent, the number of which is the number of aggregated models 1017 entered in the task description 118, and aggregates the model weights by averaging the weight values ​​(FedAvg), etc.

[0096] In s52, the FL requester acquires the FL model weights. That is, the FL request server 100 acquires the new aggregated FL model weights aggregated in s51.

[0097] In s53, a hash value is calculated. That is, the FL request server 100 calculates a hash value of the aggregated FL model weight using a hash function from the aggregated FL model weight acquired in s52.

[0098] In s54, the FL requester uploads the weights of the aggregated FL model onto the shared storage 300 as aggregated FL model weights 304.

[0099] In s55, the FL requester obtains the address of the aggregated FL model weight 304 uploaded in s54.

[0100] In s56, the FL requester inputs into the state table 302 the weight values ​​of the aggregated FL model weights 304 uploaded in s54, as well as metadata such as the number of learning rounds, addresses, and collaborator identification ID information.

[0101] In s57, the FL requester quantifies the contribution of the FL collaborators. That is, the FL request server 100 executes the accuracy evaluation program 301 arranged on the shared storage 300 using the model evaluation data 112 to evaluate the accuracy of the FL learning model after aggregation, and quantifies the contribution of each FL collaborator using the Shapley value or the like.

[0102] In s 58 , the FL requester inputs the hash value of the aggregated FL model weight 304 calculated in s 53 to the FL model weight hash value input unit 1201 of the FL model update contract 117 .

[0103] In s59, the FL requester acquires address information on the shared storage 300 of the aggregated FL model weights uploaded to the shared storage 300 in s54. The address information is input to the FL model weight address input unit 1202.

[0104] In s60, the FL requester inputs the distributed value of the FL cooperation reward 1015 entered in the task description 118 into the FL cooperation reward input section 1174 of the FL model update approval section 1173, based on the contribution evaluation of each FL collaborator by the accuracy evaluation program 301 in s57.

[0105] In s61, the FL requester transmits the contract. That is, the FL request server 100 transmits the FL model update contract 117 to the FL collaborator via the contract issuing unit 11.

[0106] In s62, the FL cooperator receives the contract. That is, the FL cooperator server 200 receives the contract transmitted from the FL requester in s61.

[0107] In s 63 , the FL collaborator obtains the address information of the aggregated FL model weight 304 inputted to the FL model weight address input section 1202 , and downloads the aggregated FL model weight 304 .

[0108] In s64, the FL collaborator compares the aggregated FL model weights 304 with the state table 302 to verify whether there are any errors in the aggregated FL model weights 304. In addition, the FL collaborator executes the accuracy evaluation program 301 using the model evaluation data 112 to verify whether there are any errors in the reward based on tokens input to the FL cooperation reward input unit 1174 of the FL model update approval unit 1173.

[0109] Under s65, the FL collaborator performs an operation such as electronic signature to approve the contract.

[0110] In s66, the FL model update approval unit 1173 is executed, and the FL model weight hash value recording unit 1204 and the FL model weight address recording unit 1205 record the FL model weight hash value 1136 and the FL model weight address 1137 in the recording information 1133 of the distributed ledger 113. In addition, when the FL model update approval unit 1173 is executed, tokens are paid from the FL requester to the FL collaborator in the amount equal to the value input to the FL cooperation reward input unit 1174.

[0111] Next, an example of the hardware configuration of an information processing device used in the system of this embodiment will be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the hardware configuration of an information processing device used in this embodiment.

[0112] 13, the information processing device is configured as a computer that performs information processing. The information processing device can include, for example, a processor 1301, a memory 1302, a storage 110, a network IF 130, and an input / output IF 1303.

[0113] Here, the processor 1301 is a subject that executes a predetermined process. The memory 1302 is a main storage device that stores data, and the processor 1301 reads the data into the memory 1302 and processes it. The storage 110 stores various data. The network IF 130 is an interface used for inputting and outputting data via an appropriate network, for example, used for inputting and outputting data via the blockchain network 4. The input / output IF 1303 is an interface used for inputting and outputting data with a connected device.

[0114] The FL request server 100 (first information processing device) and the FL cooperation server 200 (second information processing device) can have the same hardware configuration, for example. The blockchain system execution unit 10, the task description publication unit 101, the FL model weight aggregation program 114, the FL start contract 115, the initial FL model sharing contract 116, the FL model update contract 117, the FL model weight sharing contract 120, the task description viewing unit 201, the task participation determination unit 202, and the like can be realized by appropriately using various types of hardware.

[0115] In the first information processing device and the second information processing device, data input from the user and data output can be performed in an appropriate manner. For example, an appropriate input device and an output device may be connected to the input / output IF, and data input / output may be performed through these. Also, an appropriate computer may be connected via a network IF, and data input / output may be performed using this computer.

[0116] Furthermore, the FL system may be configured, for example, such that the shared storage 300 is connected to the block chain network 4 and is located in an information processing device other than the information processing devices (100, 200).

[0117] According to this embodiment, the following system is realized as an example. That is, it is a smart contract type blockchain system, in which the FL request server 100 has an initial FL model 111, and when sharing the initial FL model 111 with the FL cooperating server 200, an initial FL model usage fee input unit 1163 is provided in the initial FL model sharing contract 116 for inputting the initial FL model usage fee received from the FL cooperating server 200, and in exchange for sharing the initial FL model 111, the FL requester receives a reward.

[0118] The FL collaborating server 200 also has local training data 119 for training the shared AI model, and shares new weights obtained by training with the AI ​​model providing server via the FL model weight sharing contract 120. Then, when a certain number of weights have been shared, the FL model weights are aggregated and the aggregated FL model is evaluated via the FL model update contract 117, and a reward based on the evaluation result is paid to the FL trainer.

[0119] According to the present disclosure, an FL client can receive an incentive in the form of a token reward in exchange for sharing the initial FL model. That is, an incentive design is realized for the FL client who first shares the initial FL model with all nodes.

[0120] The present invention is not limited to the above-described embodiment, but includes various modifications. For example, the above-described embodiment has been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to the embodiment having all of the configurations described. It is possible to replace a part of the configuration of an embodiment with the configuration of another embodiment, and it is also possible to add the configuration of one embodiment to the configuration of another embodiment. Furthermore, it is also possible to add, delete, or replace a part of the configuration of each embodiment with the configuration of another embodiment. [Explanation of symbols]

[0121] 1 FL System 2 System Management Device 4. Blockchain Network 10 Blockchain System Execution Department 11 Contract Issuance Department 12 Blockchain control section 13 History Search Unit 14 Token Management Unit 100 FL request server (first information processing device) 101 Task Description Public Section 110 Storage 111 Early FL model 112 FL model evaluation data 113 Distributed Ledgers 114 FL model weight aggregation program 115 FL Starting Contract 116 Initial FL model sharing contract (initial federated learning model sharing contract) 117 FL Model Renewal Contract 118 Task Description 119 Local Training Data 120 FL model weight sharing contract 130 Network Interface 200 FL cooperation server (second information processing device) 201 Task Description Viewer 202 Task Participation Judgment Department 300 Shared Storage 301 Accuracy Evaluation Program 302 State Table 303 FL Model Weights 304 Aggregated FL model weights 1011 Initial FL model usage fee 1012 training rounds 1013 Training data type 1014 Use learning model 1015 FL cooperation reward 1016 Number of FL collaborators wanted 1017 Aggregated Models 1131 Timestamp 1132 Hash value of the previous ledger information 1133 Record Information 1134 Task Description Information 1135 Collaborator ID 1136 FL model weight hash value 1137 FL model weight address 1151 Task description information input section 1152 FL Start Approval Department 1153 Task description information recording unit 1154 Collaborator Identification ID Recording Section 1161 Initial model address input section 1162 Initial FL Model Shared Approval Section 1163 Initial FL model usage fee input section 1171 FL model weight aggregation part 1172 Aggregated FL model accuracy evaluation part 1173 FL Model Renewal Approval Department 1174 FL Cooperation Reward Input Unit 1201 FL model weight hash value input part 1202 FL model weight address input section 1203 FL Model Weight Sharing Approval Section 1204 FL model weight hash value record section 1205 FL model weight address record section 1301 Processor 1302 Memory 1303 Input / Output Interface

Claims

1. A federated learning system using smart contract-type blockchain technology, A first information processing device having an initial association learning model, and a second information processing device that trains the initial association learning model provided from the first information processing device, The first information processing device is and an initial federated learning model sharing contract which is a smart contract used for sharing the initial federated learning model with the second information processing device and includes reward information by tokens that a user of the first information processing device receives from a user of the second information processing device for the sharing. A federated learning system characterized by:

2. 2. The federated learning system of claim 1, The initial federated learning model sharing contract includes: a model usage fee input unit used by a user of the first information processing device to input the remuneration information; A federated learning system characterized by:

3. The federated learning system according to claim 2, The first information processing device is a task description publishing unit that discloses a task description including a model usage fee, a reward for the associative learning, and a task content of the associative learning to the second information processing device; The second information processing device is A task participation determination unit is provided for a user to input whether or not the user will participate in the federated learning. A federated learning system characterized by:

4. A federated learning system using smart contract-type blockchain technology, The initial federated learning model sharing contract is a smart contract that is used to share an initial federated learning model owned by a first information processing device that requests federated learning with a second information processing device that trains the model, and includes reward information in the form of tokens that a user of the first information processing device receives from a user of the second information processing device in response to the sharing. A federated learning system characterized by:

5. The federated learning system according to claim 4, The initial federated learning model sharing contract includes: a model usage fee input unit used by a user of the first information processing device to input the remuneration information; A federated learning system characterized by:

6. The federated learning system according to claim 5, The first information processing device is a task description publishing unit that discloses a task description including a model usage fee, a reward for the associative learning, and a task content of the associative learning to the second information processing device; The second information processing device is A task participation determination unit is provided for a user to input whether or not the user will participate in the federated learning. A federated learning system characterized by:

7. A federated learning method using smart contract type blockchain technology, A step in which the first information processing device shares the initial federated learning model with the second information processing device by using an initial federated learning model sharing contract, which is a smart contract used for sharing the initial federated learning model from the first information processing device to a second information processing device that trains a model; When the second information processing device shares the initial federated learning model, the first information processing device acquires a reward in the form of a token. A federated learning method comprising:

8. The associative learning method according to claim 7, A step of a user of the first information processing device inputting the reward into the initial federated learning model sharing contract, A federated learning method comprising:

9. The method of associative learning according to claim 8, further comprising: A step in which a user of the first information processing device creates a task description including a model usage fee, a reward for associative learning, and a task content of the associative learning; a step of a user of the first information processing device publishing the task description; A step in which a user of the second information processing device determines whether or not to participate in the associative learning based on the contents of the task description. A federated learning method comprising:

Images