Associative Learning Systems and Associative Learning Methods

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

[0005] , ,

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

Background Art

[0002] When learning machine learning, especially 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 enables large-scale learning while protecting privacy and reducing communication volume by having multiple clients locally hold data and only share the model and update parameters such as weights.

[0003] In conventional FL that centrally deploys a model update server, there is a problem that it is difficult to design incentives for FL participants. Therefore, Non-Patent Document 1 examines providing incentives for FL participation through reward design using tokens of blockchain technology.

Prior Art Documents

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] One possible architecture involves building a system that executes FL (Functional Project) on the blockchain, with FL progressing via smart contracts. By incorporating an FL model performance verification unit within the smart contract to evaluate the contribution of FL collaborators, a method is proposed to incentivize FL collaborators by rewarding them according to their contribution. However, while this method provides an incentive for FL collaborators to actively participate in FL, it is considered insufficient in terms of incentive design for those requesting FL.

[0006] Traditionally, for example, an improvement in the performance of an AI model through FL (Functional Streaming) is considered an incentive for those requesting FL. However, considering that the use of blockchain technology has increased the incentives for FL participants, it is necessary to design incentives that more appropriately reward FL requesters from this perspective as well. [Means for solving the problem]

[0007] A representative example of the invention disclosed in this application is as follows: The federated learning system is a system using smart contract-type blockchain technology. This system comprises 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 which includes information about token rewards that the user of the first information processing device receives from the user of the second information processing device for the sharing.

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

[0009] A representative example of the invention disclosed in this application is as follows: A federative learning method using smart contract type blockchain technology, comprising the steps of: first, sharing an initial federative learning model with a second, which is a smart contract used to share an initial federative learning model from a first, which is a smart contract used to train the model; and second, receiving a token reward when the second, which has shared the initial federative learning model. [Effects of the Invention]

[0010] According to the disclosure described above, in FL, FL clients can receive rewards in the form of tokens, and an appropriate incentive design for FL clients is realized. Any other issues, configurations, and effects not mentioned above will be clarified by the following description of embodiments for carrying out the invention. [Brief explanation of the drawing]

[0011] [Figure 1] This figure shows an example of the overall configuration of an FL system using a smart contract-type blockchain. [Figure 2] This diagram illustrates the details of an example configuration of an FL system using a smart contract-type blockchain. [Figure 3] This figure shows an example of a published task description. [Figure 4]This figure shows an example of writing information to shared storage and a distributed ledger using smart contracts for FL. [Figure 5] This figure shows an example of a statetable. [Figure 6] This figure shows an example of a smart contract configuration for FL and a distributed ledger configuration. [Figure 7] This flowchart shows an example of how to use an FL system with a smart contract-based blockchain. [Figure 8] This figure shows an example of the sequence for determining whether to participate in a task. [Figure 9] This figure shows an example of the sequence of execution for the FL start contract. [Figure 10] This figure shows an example of the sequence of executions for an initial FL model shared contract. [Figure 11] This figure shows an example of the execution sequence of an FL model weight-sharing contract. [Figure 12] This figure shows an example of the execution sequence of an FL model update contract. [Figure 13] This figure shows an example of the hardware configuration of the information processing device used in this embodiment. [Modes for carrying out the invention]

[0012] Embodiments of the present invention will be described below with reference to the drawings. The embodiments are illustrative examples for explaining the present invention, and have been omitted and simplified as appropriate for clarity of explanation. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. The positions, sizes, shapes, and ranges of the components shown in the drawings may not represent their actual positions, sizes, shapes, and ranges in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the positions, sizes, shapes, and ranges disclosed in the drawings. Examples of various types of information may be described using terms such as "table," "list," and "queue," but these types of information may also be represented by other data structures. For example, various types of information such as "XX table," "XX list," and "XX queue" may be referred to as "XX information." When describing identification information, terms such as "identification information," "identifier," "name," "ID," and "number" are used, and these terms are interchangeable. When there are multiple components with the same or similar function, they may be described using the same symbol but with different subscripts. Furthermore, when it is not necessary to distinguish between these multiple components, the subscripts may be omitted in the description. In embodiments, processing performed by executing a program may be described. Here, the computer executes the program using a processor (e.g., CPU, GPU) and performs processing defined by the program using memory resources (e.g., memory) and interface devices (e.g., communication ports). Therefore, the main entity performing the processing by executing the program may be the processor. Similarly, the main entity performing the processing by executing the program may be a controller, device, system, computer, or node having a processor. The main entity performing the processing by executing the program may be an arithmetic unit, and may include dedicated circuits that perform specific processing. Here, dedicated circuits include, for example, FPGAs (Field Programmable Gate Arrays), ASICs (Application Specific Integrated Circuits), CPLDs (Complex Programmable Logic Devices), etc. The program may be installed on a 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 includes a processor and a storage resource for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. Also, in an embodiment, two or more programs may be realized as one program, or one program may be realized as two or more programs.

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

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

[0015] An FL requester who desires to improve the performance of an AI model has an FL request server 100, and an initial FL model 111, which is an AI model to be trained by FL, is stored on the FL request server 100. Also, an FL collaborator who cooperates with FL has an FL cooperation server 200, and local training data 119 for training an AI model is stored on the FL cooperation server 200. The FL system 1 is an FL system using a smart contract type blockchain, and FL via a smart contract is executed among 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 run on a blockchain network such as EOS or Ethereum, which can implement decentralized applications (DApps) related to blockchain applications such as smart contracts. However, any network using distributed ledger technology in which the registration and management of information executed by contracts are subsequently performed by a specific administrator is acceptable.

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

[0018] As shown in Figure 2, the FL system is a smart contract type blockchain system and includes an FL request server 100 operated by FL requesters (users) and an FL cooperation server 200 operated by FL collaborators (users). These information processing devices (100, 200) are autonomously and decentralizedly connected to a peer-to-peer (P2P) blockchain network 4. In addition to the information processing devices (100, 200) shown in the figure, multiple other information processing devices are connected to 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 houses a contract issuance unit 11 that issues FL smart contracts, a blockchain control unit 12 that maintains the blockchain system in an autonomous and distributed cooperation with an information processing device connected to the network 4, a history search unit 13 that can access the record information of the distributed ledger 113 and obtain contract information, and a token management unit 14 that manages the balance of tokens exchanged via smart contracts.

[0020] The FL request server 100 is equipped with storage 110a, for example, using a magnetic disk as the medium. The storage 110a of the FL request server 100 stores the initial FL model 111, FL model evaluation data 112, distributed ledger 113, FL model weight aggregation program 114, FL start contract 115, initial FL model sharing contract 116, FL model update contract 117, and task description 118. The initial FL model 111 (initial federative 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 during the FL process. Contract information by smart contracts is recorded in the distributed ledger 113. 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 obtaining an ID to identify a collaborator at the start of FL. The initial FL model sharing contract 116 (initial federative learning model sharing contract) is a smart contract for sharing the initial FL model 111 with the FL cooperation 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 for performing model updates. The task description 118 is created as appropriate by the FL requester, and the task description 118 contains the details of the FL task request. The task request details described in the task description 118 are shared throughout the smart contract blockchain system via the task description disclosure section 101.

[0021] The FL cooperation server 200 is equipped with storage 110b, which stores the distributed ledger 113, similar to the FL request server 100. Storage 110b also stores local training data 119 and the FL model weight sharing contract 120. The local training data 119 is data used to train the initial FL model 111 shared from the FL request server 100. The FL model weight sharing contract 120 is a smart contract for sharing the model weights obtained through local training with the FL request server.

[0022] The FL cooperation server 200 is equipped with a task description viewing unit 201, and FL collaborators can access tasks via the task description viewing unit 201. Official Instructions Access unit 101 allows users to view the contents of the task description. FL participants decide 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 decision unit 202 transmits the input decision result to the FL request server 100.

[0023] Shared storage 300 is an early FL model Ru111 or Model weights and other data are saved as files, and a smart contract is used to handle file sharing between the FL request server 100 and the FL cooperation server 200. The shared storage 300 can be a centralized system where the FL request server 100 manages the files, or a decentralized system where files are managed peer-to-peer, such as IPFS (InterPlanetary File System).

[0024] The network interface 130 is an interface for connecting to an appropriate network. For example, the network interface 130 is used for the FL request server 100 and the FL cooperation server 200 to connect 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). However, this is just one example of an embodiment of the present invention, and functional units other than the blockchain system execution unit 10 do not necessarily need to be located inside the information processing device (100, 200). Therefore, it is also possible to provide the functional units on the shared storage 300, for example.

[0026] Next, we will explain an example of the contents of a task description while referring to Figure 3. Figure 3 is a diagram showing an example of a publicly available task description.

[0027] The initial FL model usage fee 1011 is set by the FL requester operating the FL request server 100. Depending on the value set for the initial FL model usage fee 1011, the FL requester can acquire 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 the following into the task description 118: the number of learning rounds 1012, which specifies the number of times the FL model update contract 117 will be executed; the type of learning data 1013, which specifies the field to which the learning model will be applied; the learning model used 1014, which specifies the base model network used in the initial FL model; the FL cooperation reward 1015, which specifies the FL cooperation reward based on the aggregated FL model accuracy evaluation results by the FL model update contract 117; the number of FL collaborators to be recruited 1016, which specifies the number of FL collaborators required to issue the FL start contract; and the number of aggregated models 1017, which specifies the number of models required to execute the FL model update contract 117.

[0029] Next, we will explain an example of information processing in shared storage, referring to Figure 4. Figure 4 shows the configuration of shared storage and an example of information writing using a smart contract.

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

[0031] Then, each time a contract to save the FL model weights to the shared storage 300 is approved, the FL model weights 303 and aggregated model weights 304 are saved to the shared storage 300, and the hash values ​​of the saved FL model weights 303 and aggregated model weights 304, along with the address information on the shared storage, are written to the distributed ledger 113.

[0032] The state table 302 stores metadata for 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 cooperation server 200.

[0033] Here, we will explain the details of the state table 302 with reference to Figure 5. Figure 5 is a diagram showing an example of a state table. The state table 302 contains the identification ID of the FL request server 100 or FL cooperation server 200 that uploaded the model weight values, the address information of the FL model weights 303 on the shared storage 300, and learning round information. The information written to the state table 302 is referenced during contract validation of the FL model weight sharing contract 120 and the FL model update contract 117 to verify whether there are any discrepancies in the contract input content.

[0034] Next, with reference to Figure 6, we will explain an example of the configuration of a smart contract for FL and a distributed ledger. Figure 6 is a diagram showing an example of the configuration of a smart contract for FL and 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 for inputting 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 entered in the task description information input unit 1151 within the record 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 the FL requester from the FL request server 100, and includes an initial model address input unit 1161 for inputting the 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 collaborator server 200, and includes a hashed FL model weight input unit 1201 for inputting the hash value of the FL model weight 303 uploaded by the FL collaborator server 200 to the shared storage 300, an FL model weight address input unit 1202 for inputting the address information of the FL model weight 303, and an FL model weight sharing approval unit 1203 that is executed when the contract is approved. 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 within the record information 1133 of the distributed ledger 113, 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.

[0038] The FL model update contract 117 is a contract issued by the FL requester from the FL request server 100, and comprises 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 the 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 performs a performance evaluation of the aggregated model using model evaluation data 112 and an 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 an FL cooperation reward input unit 1174 that inputs rewards to FL collaborators according to the model evaluation results in the aggregated model accuracy evaluation unit 1172 into the record information 1133 of the distributed ledger 113, a hashed FL model weight recording unit 1204 that records the hashed FL model weights input into 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 into the FL model weight address input unit 1202.

[0039] The distributed ledgers 113 are connected in a column to form a so-called blockchain. The distributed ledger 113 has a timestamp 1131, a hash value 1132 of the previous ledger information, and record information 1133. The timestamp 1131 is information indicating the date and time the ledger was created. The hash value 1132 of the previous ledger information is a value generated based on a hash function pre-set for the previous ledger information. The record information 1133 is the main body of the information recorded upon approval of each contract, 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, we will explain an example of the flow of using the FL system, referring to Figure 7. Figure 7 is a flowchart of an example of the flow of using the FL system with a smart contract type blockchain. The processes from s1 to s13 will be explained below.

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

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

[0043] In s3, the FL requester creates a task description 118 outlining the AI ​​model training task they wish to request using FL, in order to recruit FL collaborators. The FL requester also creates a task description 118 that includes the initial FL model usage fee 1011.

[0044] In s4, the FL requester pays a fee with tokens 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 also pays a fee to the system operator, for example, to the system management device 2 (FL system administrator).

[0045] In s5, based on the contents of the FL task description 110, it is determined whether or not the FL collaborator will participate in the task, the decision result is input to the task participation decision unit 202, and the decision result is sent to the FL request server 100.

[0046] In s6, the FL requester confirms the result of the task participation decision, and in s7, it is determined whether the number of FL collaborators has reached the target number of FL collaborators (1016) specified in the task description 118, based on the task participation decision confirmed in s6. If the answer is Yes (s7:Yes), s8 is performed; 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 collaboration 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 aggregated models 1017 specified in the task description 118. If yes (s11:Yes), s12 is performed; 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 training rounds 1012 entered in the task description 118. If the result is No (s13:No), s10 is performed; if the result is Yes (s13:Yes), the sequence ends.

[0053] Next, we will explain the details of the task participation decision while referring to Figure 8. Figure 8 is a diagram showing an example of the sequence for task participation decision. The specific operation in s5 in which the FL collaborator decides to participate in the FL based on the task description is shown in the processes from s14 to s18 below.

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

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

[0056] In s16, the task participation determination unit 202 makes a decision on whether or not the FL collaborator can participate in the task, based on the contents of the task description 118 that the FL collaborator viewed in s15.

[0057] In s17, if a decision to participate was 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 obtains a collaborator identification ID from the participation information transmitted in s17 via the task participation determination unit 202.

[0059] Next, we will explain the details of the FL initiation contract execution with reference to Figure 9. This figure shows an example of the sequence of FL initiation contract execution. The specific operations of the FL initiation contract execution s8 are shown in the following processes s19 to s25.

[0060] In s19, the task description created by the FL requester in s3. Book 118 Check the contents.

[0061] In s20 , s19 Confirmed task description Book 118 The FL requester inputs the details into the task description information input section 1151 of the FL start contract 115.

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

[0063] In s22, the FL collaborator receives the contract. That is, the FL collaborator server 200 receives the contract sent by 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 start contract 115 received in s22.

[0065] In s24, FL collaborators perform actions such as electronically signing the contract, 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 are recorded. Section 1154 Therefore, the task description information 1134 and the collaborator identification ID 1135 are recorded in the record information 1133 of the distributed ledger 113.

[0067] Next, we will explain the details of the initial FL model shared contract execution with reference to Figure 10. Figure 10 is a diagram showing an example of the sequence of the initial FL model shared contract execution. The specific operations in s9 related to the execution of the initial FL model shared contract 116 are shown in the processes from s26 to s35 below.

[0068] In s26, the FL requester sets the initial FL mode on FL request server 100. Ru111 Upload it to shared storage 300.

[0069] In s27, the FL requester retrieves the address information on shared storage 300 for the initial FL model 110 that was uploaded to shared storage 300 in s26.

[0070] In s28, the FL requester inputs the initial FL model address obtained in s27 into the initial FL model address input section 1161 of the initial FL model sharing contract 116. Ru111 Enter your address information.

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

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

[0073] In s31, the FL collaborator receives the contract. That is, the FL collaborator server 200 receives the contract sent by the FL requester in s30.

[0074] In s32, the FL collaborator inputs the initial FL model address into the initial FL model address input unit 1161. Ru111 Obtain address information and download 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 entered in the initial FL model usage fee input section 1163 of the initial FL model sharing contract 116.

[0076] In s34, FL collaborators perform actions such as electronically signing the contract, and the contract is approved.

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

[0078] Next, we will explain the details of the FL model weight sharing contract execution with reference to Figure 11. Figure 11 is a diagram showing an example of the sequence of the FL model weight sharing contract execution. The specific operations related to the execution s10 of the FL model weight sharing contract 120 are shown in the following processes s36 to s49.

[0079] In s36, the FL collaborator trains the FL model using local training data 119 on the FL collab server 200.

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

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

[0082] In step s39, the weights of the trained FL model are designated as FL model weights 303, and the FL collaborator uploads FL model weights 303 to shared storage 300.

[0083] In s40, the FL collaborator retrieves the address information on shared storage 300 for the FL model weight 303 that was uploaded to shared storage 300 in s39.

[0084] In s41, the FL collaborator inputs metadata into the statetable 302, including the weight values ​​of the FL model weights 303 uploaded in s39, the number of training rounds, the 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 into the FL model weight hash value input section 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 obtained in s40 into the FL model weight address input section 1202 of the FL model weight sharing contract 120.

[0087] In step s44, the FL collaborator sends the contract. That is, the FL collaborator server 200 sends 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 contract sent by the FL collaborator in s44 is received by the F L Request The receiver 100 receives the message.

[0089] In s46, the FL requester obtains the address information of the FL model weight 303 entered into the FL model weight address input unit 1202 and downloads the FL model weight 303.

[0090] In s47, the FL requester compares the FL model weights 303 obtained in s46 with the state table to verify that there are no errors in the FL model weights 303.

[0091] In s48, the FL requester performs actions such as electronically signing the contract, 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 record information 1133 of the distributed ledger 113.

[0093] Next, we will explain the details of the FL model update contract execution with reference to Figure 12. Figure 12 is a diagram showing an example sequence of FL model update contract execution. The specific operations related to the execution s12 of the FL model update contract 117 are shown in the following processes 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 aggregated 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 multiple 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 recording information 1133, reads out the FL model weights 303 in order from newest to oldest, for the number of aggregated models 1017 entered in the task description 118, and aggregates the model weights by averaging the weight values ​​(FedAvg).

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

[0097] In s53, hash values ​​are calculated. Specifically, the FL request server 100 uses a hash function to calculate the hash values ​​of the aggregated FL model weights obtained in s52.

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

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

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

[0101] In step 57, the FL requester quantifies the contribution of the FL collaborators. Specifically, the FL request server 100 runs the accuracy evaluation program 301, located on the shared storage 300, using the model evaluation data 112 to evaluate the accuracy of the aggregated FL learning model and quantify the contribution of each FL collaborator using Shapley values, etc.

[0102] In s58, the FL requester inputs the hash value of the aggregated FL model weight 304 calculated in s53 into the FL model weight hash value input section 1201 of the FL model update contract 117.

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

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

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

[0106] In s62, the FL collaborator receives the contract. That is, the FL collaborator server 200 receives the contract sent by the FL requester in s61.

[0107] In step s63, the FL collaborator obtains the address information of the aggregated FL model weights 304 that were input into the FL model weight address input unit 1202, and downloads the aggregated FL model weights 304.

[0108] In step s64, the FL collaborator compares the aggregated FL model weights 304 with the state table 302 to verify that there are no errors in the aggregated FL model weights 304. The FL collaborator also runs the accuracy evaluation program 301 using the model evaluation data 112 to verify that there are no errors in the token rewards entered into the FL collaborator reward input unit 1174 of the FL model update approval unit 1173.

[0109] In s65, FL collaborators perform actions such as electronically signing the contract, and the contract is approved.

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

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

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

[0113] Here, the processor 1301 is the entity that executes predetermined processing. The memory 1302 is the main memory that stores data, and the processor 1301 reads the data into the memory 1302 and processes it. The storage 110 stores various types of data. The network IF 130 is an interface used for inputting and outputting data via an appropriate network, for example, 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 connected devices.

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

[0115] Furthermore, in the first and second information processing devices, data input and output from the user can be performed by appropriate methods. For example, appropriate input and output devices may be connected to the input / output interface, and data input and output may be performed via these devices. Alternatively, an appropriate computer may be connected via the network interface, and data input and output may be performed using this computer.

[0116] Furthermore, the FL system may be configured such that, for example, it is connected to the blockchain network 4, and the shared storage 300 is located on other information processing devices different from the information processing devices (100, 200).

[0117] According to this embodiment, as an example, the following system is realized. 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 cooperation server 200, the initial FL model sharing contract 116 is equipped with an initial FL model usage fee input unit 1163 that inputs the initial FL model usage fee to be received from the FL cooperation server 200, and in exchange for sharing the initial FL model 111, the FL requester receives a reward.

[0118] Furthermore, the FL cooperation server 200 is equipped with local training data 119 for training the shared AI model, and shares the new weights obtained during training with the AI ​​model provider server via the FL model weight sharing contract 120. 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 results is paid to the FL trainer.

[0119] According to this disclosure, FL requesters can receive token rewards as an incentive in exchange for sharing the initial FL model. In other words, an incentive design is implemented for FL requesters who are the first to share the initial FL model with all nodes.

[0120] It should be noted that the present invention is not limited to the embodiments described above, and various modifications are included. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the configurations described. It is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace parts of the configuration of each embodiment with those of other embodiments. [Explanation of Symbols]

[0121] 1 FL System 2. System Management Device 4 Blockchain Network 10 Blockchain System Execution Unit 11 Contract Issuance Department 12 Blockchain Control Unit 13 History Search Unit 14 Token Management Department 100 FL Request Server (First Information Processing Unit) 101 Task Instructions Public Release Section 110 storage 111 Early FL Model 112 FL Model Evaluation Data 113 Distributed Ledger 114 FL Model Weight Aggregation Program 115 FL Start Contract 116 Initial FL Model Shared Contract (Initial Associative Learning Model Shared Contract) 117 FL Model Update Contract 118 Task Instructions 119 Local training data 120 FL Model Weight Sharing Contract 130 Network Interfaces 200 FL Cooperative Server (Second Information Processing Unit) 201 Task Instruction Manual Viewing Section 202 Task Participation Decision Unit 300 shared storage 301 Accuracy Evaluation Program 302 Statetable 303 FL Model Weight 304 Aggregated FL Model Weights 1011 Initial FL Model Usage Fee 1012 training rounds 1013 Training Data Types 1014 Learning Model Used 1015 FL cooperation reward 1016 Number of FL collaborators wanted 1017 Number of aggregated models 1131 Timestamp 1132 Hash value of the previous ledger information 1133 Record Information 1134 Task Instructions Information 1135 Collaborator Identification ID 1136 FL Model Weight Hash Values 1137 FL Model Weight Address 1151 Task Instruction Manual 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 Sharing Approval Section 1163 Initial FL Model Usage Fee Input Section 1171 FL Model Weight Aggregation Unit 1172 Accuracy evaluation unit of the aggregated FL model 1173 FL Model Update Approval Department 1174 FL Cooperation Reward Input Section 1201 FL Model Weight Hash Value Input Section 1202 FL Model Weight Address Input Section 1203 FL Model Weight Sharing Approval Unit 1204 FL Model Weight Hash Value Recording Section 1205 FL Model Weight Address Recording Unit 1301 Processor 1302 memory 1303 Input / Output Interface

Claims

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

2. The associative learning system according to claim 1, The aforementioned initial associative learning model shared contract is, The first information processing device includes a model usage fee input unit used by the user to input the reward information, An associative learning system characterized by the following:

3. The associative learning system according to claim 2, The first information processing device is The system includes a task description disclosure unit that discloses to the second information processing device a task description including model usage fees, rewards for associative learning, and the content of associative learning tasks, The second information processing device is It includes a task participation determination unit in which the user inputs whether they want to participate in associative learning. An associative learning system characterized by the following:

4. A federative learning system using smart contract-type blockchain technology, It is used to share the initial federative learning model held by a first information processing device that requests federative learning with a second information processing device that trains the model, and includes an initial federative learning model sharing contract, which is a smart contract that includes reward information in the form of tokens that the user of the first information processing device receives from the user of the second information processing device for the sharing. An associative learning system characterized by the following:

5. The associative learning system according to claim 4, The aforementioned initial associative learning model shared contract is, The first information processing device includes a model usage fee input unit used by the user to input the reward information, An associative learning system characterized by the following:

6. The associative learning system according to claim 5, The first information processing device is The system includes a task description disclosure unit that discloses to the second information processing device a task description including model usage fees, rewards for associative learning, and the content of associative learning tasks, The second information processing device is It includes a task participation determination unit in which the user inputs whether they want to participate in associative learning. An associative learning system characterized by the following:

7. A federative learning method using smart contract-type blockchain technology, The process involves the first information processing device sharing an initial associative learning model with the second information processing device, using an initial associative learning model sharing contract, which is a smart contract used to share the initial associative learning model from the first information processing device to the second information processing device that trains the model. The first information processing device obtains a token reward when the second information processing device shares an initial associative learning model. A characteristic associative learning method.

8. The associated learning method according to claim 7, The first information processing device includes the step of a user inputting the reward into the initial associative learning model shared contract, A characteristic associative learning method.

9. The associated learning method according to claim 8, The user of the first information processing device creates a task description that includes a model usage fee, a reward for associative learning, and the content of the associative learning task. The user of the first information processing device publishes the task description, The second information processing device includes the step of determining whether or not to participate in federated learning based on the contents of the task description, A characteristic associative learning method.

Images