# Chained Anomaly Detection Models for Federated Learning: An Intrusion Detection Case Study
## 3 Accountable Federated Learning for Anomaly Detection
### Auditing the Anomaly Models and Weight Updates on the Blockchain  
Given that the parameter server is the most security-sensitive component in the federated learning setup, we will replace the direct interaction with this server with a blockchain. This way, all deep learning clients and monitored systems can interact with the blockchains such that all interactions and autoencoder model updates are traceable. The peer-to-peer architecture of a blockchain has the additional advantage that the parameter server does not become a single point of failure, as each node has a full copy of the ledger and can compute the aggregated weight updates. Given that the federated learning process involves a large amount of weight updates, a public blockchain that relies on a proof-of-work consensus protocol, such as Bitcoin or Ethereum, is not feasible as the generation of new blocks on the ledger would be too slow. We therefore rely on a private and permissioned blockchain that supports multiple assets and mining without proof-of-work. The MultiChain [41] open source blockchain platform and its round-robin-based mechanism for permitted miners to create new blocks meets the aforementioned prerequisites. For our proof-of-concept implementation, we deploy MultiChain 2.0 (alpha 4) on 12 nodes and deploy an _ids_chain with the following commands on node _host01_with IP address 192.168.100.24:  
host01:^$ multicchain-util create ids  
host01:^$ multichainid ids -daemon  
In order for _host02_ to connect to the _ids_ chain on the blockchain, we grant its wallet address _Iamp8 AquvvPi87 LP5 BQ3 HPAKNDRnuKbb99/LTiu_the permission as follows:  
host01:^$ multichain-cli ids grant 1 amp8 AquvvPi87 LP5 BQ3 HPAKNDRnsKbb99 FLTu connect  
host02:^$ multichainid ids8192.168.100.24:6469 -daemon  
We repeat the above process for nodes _host03-host12_ where each of these nodes has its own wallet address. We then create a stream to store all updates to a machine learning model _anomaly_, store an initial model of the autoencoder in JSON format under the _init_key, and grant all other nodes--from _host02-host12_--the permission to publish to the _anomaly_ stream:  
host01:^$ multichain-cli ids create stream anomaly false  
host01:^$ multichain-cli ids publish anomaly init '{\"json\":{\"nb_layers\": 5,...}}'  
host01:^$ multichain-cli ids grant 1 amp8 AquvvPi87 LP5 BQ3 HPAKNDRnuKbb99 FLTu send  
host01:^$ multichain-cli ids grant 1 amp8 AquvvPi87 LP5 BQ3 HPAKNDRnuKbb99 FLTu anomaly.write  
Each node can then subscribe to the stream and query all items or only those with a specific key:  
host01:^$ multichain-cli ids subscribe anomaly  
host01:^$ multichain-cli ids liststreamitems anomaly # all items  
host01:^$ multichain-cli ids liststreamkeyitems anomaly init # items with the key 'init'  
On the second node _host02_, we publish a local model update as follows:  
host02:^$ multichain-cli ids publish anomaly host02_1 '{\"json\":{\"deltaweights\": [ 0.1, -0.23,... ]}}'  
MultiChain implements a consensus algorithm based on block signatures and a customizable round-robin consensus scheme. In order for the 12 nodes to start validating blocks, they must be granted the _mine_permission:  
host01:^$ multichain-cli ids grant 1 amp8 AquvvPi87 LP5 BQ3 HPAKNDRnsKbb99 FLTu mine  
The blockchain will now start mining blocks at fixed intervals. The updated weights of _host02_ can then be collected on _host01_ as follows:  
host01:^$ multichain-cli ids liststreamkeyitems anomaly host02_1 {\"method\":\"liststreamkeyitems\",\"params\":{\"anomaly\",\"host02_1\"},\"id\":^85490301-1541081528\",\"chain_name\":\"ids\"} {  
\"publishers\" : [  
\"lamp8 AquvvPi87 LP5 BQ3 HPAKNDRnuKbb99 FLTu\"  
],  
\"keys\" : [  
\"host02_1\"], \"offchain\" : false, \"available\" : true, \"data\" : { \"json\" : { \"deltaweights\" : [ 0.1, -0.23,... ] }, \"conformations\" : 52, \"blocktime\" : 1541079108, \"txid\" : \"6631960d2e75 dcae7839653979c1d9872d1a01958 fb3b93 bf76d22a5 Offd9298\" } ]  
The model update has been stored, timestamped, notarized, and confirmed on the blockchain.