Log In Sign Up

DaiMoN: A Decentralized Artificial Intelligence Model Network

We introduce DaiMoN, a decentralized artificial intelligence model network, which incentivizes peer collaboration in improving the accuracy of machine learning models for a given classification problem. It is an autonomous network where peers may submit models with improved accuracy and other peers may verify the accuracy improvement. The system maintains an append-only decentralized ledger to keep the log of critical information, including who has trained the model and improved its accuracy, when it has been improved, by how much it has improved, and where to find the newly updated model. DaiMoN rewards these contributing peers with cryptographic tokens. A main feature of DaiMoN is that it allows peers to verify the accuracy improvement of submitted models without knowing the test labels. This is an essential component in order to mitigate intentional model overfitting by model-improving peers. To enable this model accuracy evaluation with hidden test labels, DaiMoN uses a novel learnable Distance Embedding for Labels (DEL) function proposed in this paper. Specific to each test dataset, DEL scrambles the test label vector by embedding it in a low-dimension space while approximately preserving the distance between the dataset's test label vector and a label vector inferred by the classifier. It therefore allows proof-of-improvement (PoI) by peers without providing them access to true test labels. We provide analysis and empirical evidence that under DEL, peers can accurately assess model accuracy. We also argue that it is hard to invert the embedding function and thus, DEL is resilient against attacks aiming to recover test labels in order to cheat. Our prototype implementation of DaiMoN is available at


Label Embedding Network: Learning Label Representation for Soft Training of Deep Networks

We propose a method, called Label Embedding Network, which can learn lab...

GUDN A novel guide network for extreme multi-label text classification

The problem of extreme multi-label text classification (XMTC) is to reca...

Decentralized & Collaborative AI on Blockchain

Machine learning has recently enabled large advances in artificial intel...

One Line To Rule Them All: Generating LO-Shot Soft-Label Prototypes

Increasingly large datasets are rapidly driving up the computational cos...

Cleaning and Structuring the Label Space of the iMet Collection 2020

The iMet 2020 dataset is a valuable resource in the space of fine-graine...

The Dataset Nutrition Label (2nd Gen): Leveraging Context to Mitigate Harms in Artificial Intelligence

As the production of and reliance on datasets to produce automated decis...

I Introduction

Network-based services are at the intersection of a revolution. Many centralized monolithic services are being replaced with decentralized microservices. The utility of decentralized ledgers showcases this change, and has been demonstrated by the usage of Bitcoin [1] and Ethereum [2].

The same trend towards decentralization is expected to affect the field of artificial intelligence (AI), and in particular machine learning, as well. Complex models such as deep neural networks require large amounts of computational power and resources to train. Yet, these large, complex models are being retrained over and over again by different parties for similar performance objectives, wasting computational power and resources. Currently, only a relatively small number of pretrained models such as pretrained VGG [3], ResNet [4], GoogLeNet [5], and BERT [6] are made available for reuse.

One reason for this is that the current system to share models is centralized, limiting both the number of available models and incentives for people to participate and share models. Examples of these centralized types of systems are Caffe Model Zoo 


, Pytorch Model Zoo 


, Tensorflow Model Zoo

[9], and [10].

In other fields seeking to incentivize community participation, cryptocurrencies and cryptographic tokens based on decentralized ledger technology (DLT) have been used [1, 2]. In addition to incentives, DLT offers the potential to support transparency, traceability, and digital trust at scale. The ledger is append-only, immutable, public, and can be audited and validated by anyone without a trusted third-party.

In this paper, we introduce DaiMoN, a decentralized artificial intelligence model network that brings the benefits of DLT to the field of machine learning. DaiMoN uses DLT and a token-based economy to incentivize people to improve machine learning models. The system will allow participants to collaborate on improving models in a decentralized manner without the need for a trusted third-party. We focus on applying DaiMoN for collaboratively improving classification models based on deep learning. However, the presented system can be used with other classes of machine learning models with minimal to no modification.

In traditional blockchains, proof-of-work (PoW) [1] incentivizes people to participate in the consensus protocol for a reward and, as a result, the network becomes more secure as more people participate. In DaiMoN, we introduce the concept of proof-of-improvement (PoI). PoI incentivizes people to participate in improving machine learning models for a reward and, as an analogous result, the models on the network become better as more people participate.

One example of a current centralized system that incentivizes data scientists to improve machine learning models for rewards is the Kaggle Competition system [11], where a sponsor puts up a reward for contestants to compete to increase the accuracy of their models on a test dataset. The test dataset inputs are given while labels are withheld to prevent competitors from overfitting to the test dataset.

In this example, a sponsor and competitors rely on Kaggle to keep the labels secret. If someone were to hack or compromise Kaggle’s servers and gain access to the labels, Kaggle would be forced to cancel the competition. In contrast, because DaiMoN utilizes a DLT, it eliminates this concern to a large degree, as it does not have to rely on a centralized trusted entity.

However, DaiMoN faces a different challenge: in a decentralized ledger, all data are public. As a result, the public would be able to learn about labels in the test dataset if it were to be posted on the ledger. By knowing test labels, peers may intentionally overfit their models, resulting in models which are not generalizable. To solve the problem, we introduce a novel technique, called Distance Embedding for Labels (DEL), which can scramble the labels before putting them on the ledger. DEL preserves the error in a predicted label vector inferred by the classifier with respect to the true test label vector of the test dataset, so there is no need to divulge the true labels themselves.

With DEL, we can realize the vision of PoI over a DLT network. That is, any peer verifier can vouch for the accuracy improvement of a submitted model without having access to the true test labels. The proof is then included in a block and appended to the ledger for the record.

The structure of this paper is as follows: after introducing DEL and PoI, we introduce the DaiMoN system that provides incentive for people to participate in improving machine learning models.

The contributions of this paper include:

  1. A learnable Distance Embedding for Labels (DEL) function specific to the test label vector of the test dataset for the classifier in question, and performance analysis regarding model accuracy estimation and security protection against attacks. To the best of our knowledge, DEL is the first solution which allows peers to verify model quality without knowing the true test labels.

  2. Proof-of-improvement (PoI), including detailed Prove and Verify procedures.

  3. DaiMoN, a decentralized artificial intelligence model network, including an incentive mechanism. DaiMoN is one of the first proof-of-concept end-to-end systems in distributed machine learning based on decentralized ledger technology.

Ii Distance Embedding for Labels (DEL)

In this section, we describe our proposed Distance Embedding for Labels (DEL), a key technique by which DaiMoN can allow peers to verify the accuracy of a submitted model without knowing the labels of the test dataset. By keeping these labels confidential, the system prevents model-improving peers from overfitting their models intentionally to the test labels.

Ii-a Learning the DEL Function with Multi-Layer Perceptron

Suppose that the test dataset for the given -class classification problem consists of (input, label) test pairs, and each label is an element in , where denotes the set of integers. For example, the FashionMNIST [12] classification problem has image classes and (input, label) test pairs, where for each pair, the input is a greyscale image, and the label is an element in .

For a given test dataset, we consider the corresponding test label vector , which is made of all labels in the test dataset. We seek a -specific DEL function , where denotes the set of real numbers, which can approximately preserve distance from a predicted label vector (inferred by a classification model or a classifier we want to evaluate its accuracy) to , where . For example, we may have and . The error of , or the distance from to , is defined as

where is the indicator function, and .

Finding such a distance-preserving embedding function is generally a challenging mathematical problem. Fortunately, we have observed empirically that we can learn this -specific embedding function using a neural network.

More specifically, to learn an -specific DEL function , we train a multi-layer perception (MLP) for as follows. For each randomly selected , we minimize the loss:

where is the MLP parameters, and is a modified cosine distance function defined as

The MLP training finds a distance-preserving low-dimensional embedding function specific to a given . The existence of such embedding is guaranteed by the Johnson-Lindenstrauss lemma [13, 14], under a more general setting which does not have the restriction about the embedding being specific to a given vector.

Ii-B Use of DEL Function

We use the trained DEL function to evaluate the accuracy or the error of a classification model or a classifier on the given test dataset without needing to know the true test labels. As defined in the preceding section, for a given test dataset, is the true test label vector of the test dataset. Given a classification model or a classifier, is a predicted label vector consisting of labels inferred by the classifier on all the test inputs of the test dataset. A verifier peer can determine the error of the predicted label vector without knowing the true test label vector, by checking instead of . This is because these two quantities are approximately equal, as assured by the MLP training, which minimizes their absolute difference. If is deemed to be sufficiently lower than that of the previously known model, then a verifier peer may conclude that the model has improved the accuracy of the test dataset. That is, the verifier peer uses as a proxy for .

Note that the DEL function is -specific. For a different test dataset with a different test label vector , we will need to train another . For most model benchmarking applications, we expect a stable test dataset; and thus we will not need to retrain frequently.

Iii Training and Evaluation of DEL

In this section, we evaluate how well the neural network approach described above can learn a DEL function with and

. We consider a simple multi-layer perceptron (MLP) with 1024 hidden units and a rectified linear unit (ReLU). The output of the network is normalized to a unit length. The network is trained using the Adam optimization algorithm 

[15]. The dataset used is FashionMNIST [12], which has classes and (input, label) test pairs. The true test label vector is thus composed of these 10,000 test labels.

To generate the data to train the function, we perturb the test label vector by using the GenerateData procedure shown.

1:procedure GenerateData()
2:     Pick a random number in
3:     Pick a random set in
4:     Initialize as with
5:     for  do
6:         Pick a random number in
8:     end for
9:     return
10:end procedure

First, the procedure picks , the number of labels in to switch out, and generates the set of indices , indicating the positions of the label to replace. It then loops through the set . For each , it generates the new label to replace the old one. Note that with this procedure, the new label can be the same as the old label.

Figure 1:

The training and testing loss as the number of epochs increases.

We use the procedure to generate the training dataset and the test dataset for the MLP. Figure 1 shows the convergence of the network in learning the function . We see that as the number of epochs increases, both training and testing loss decrease, suggesting that the network is learning the function.

Figure 2: Correlation between error (%) in with respect to and the distance between them in the embedding space under .

After the neural network has been trained, we evaluate how well the learned can preserve error in a predicted label vector inferred by the classifier. Figure 2 shows the correlation between the error and the distance in the embedding space under . We see that both are highly correlated.

Iv Analysis on Defense Against Brute-force Attacks

In this section, we show that it is difficult for an attacker to launch a brute-force attack on DEL. To learn about the test label vector that produces under a known , the attacker’s goal is to find such that , for a small . There are possible instances of to try, where is the number of classes. Note can be very large. For example, for a test dataset of 10 classes and 10,000 samples, we have , and . The attacker may use the following brute-force algorithm:

1:procedure BruteForceAttack()
2:     Pick a random set of values in
3:     for  do
4:         if  then
5:              return
6:         end if
7:     end for
8:end procedure

The success probability (

) of this attack where at least one out of tried instances for is within the distance of is

where is the probability that .

We now derive and show its value is exceedingly small for a small , even under moderate values of . Assume that the outputs of

is uniformly distributed on a unit (

-1)-sphere or equivalently normally distributed on an

-dimension euclidean space [16]. Suppose that . We align the top of the unit (-1)-sphere at . Then, is the probability of a random vector on a (-1)-hemisphere falling onto the cap [17] which is

where is the dimension of a vector, is the angle between and a vector on the sphere, and is the regularized incomplete beta function defined as:

In the above expression, is the incomplete beta function, and is the beta function defined as:

Figure 3 shows the probability as the distance () from decreases for different values of . We observe that for a small , this probability is exceedingly low and thus to guarantee attacker’s success (), the number of samples () of needed to be drawn randomly is very high. For instance, for a 10% error rate, and , the probability is and the number of trials needed to succeed is . In addition, the higher the , the smaller the and the larger the . For example, for a 10% error rate, and , the probability is and the number of trials needed to succeed is .

Figure 3: The probability as distance decreases for varying .

V Analysis on Defense Against Inverse-mapping Attacks

In this section, we provide an analysis on defense against attacks attempting to recover the original test label vector from . We consider the case that the attacker tries to learn an inverse function using a neural network. Suppose that the attacker uses a multi-layer perceptron (MLP) for this with 1024 hidden units and a rectified linear unit (ReLU). The network is trained using Adam optimization algorithm [15]

. The loss function used is the squared error function:

We generate the dataset using the two procedures: GenerateInverseDataNearby and GenerateInverseDataRandom shown. The former has the knowledge that the test label vector is nearby, and the latter does not. We train the neural network to find the inverse function and compare how the neural network learns from these two generated datasets.

1:procedure GenerateInverseDataNearby()
4:     return
5:end procedure

The GenerateInverseDataNearby procedure generates a perturbation of the test label vector , passes it through the function , and returns a pair of the input

and the target output vector

used to learn the inverse function .

1:procedure GenerateInverseDataRandom()
2:     Pick a random number in
4:     return
5:end procedure

The GenerateInverseDataRandom procedure generates a random label vector where each element of the vector has a value representing one of the C classes, passes it through the function and returns a pair of the input and the target output vector used to learn the inverse function .

Figure 4: Error () in percentage as the number of epochs increases for data generated with random and near .

Figure 4 shows the error as the number of training epochs increases. On one hand, using the data generated without the knowledge of the test label vector using the GenerateInverseDataRandom procedure, we see that the network does not reduce the error as it trains. This means that it does not succeed in learning the inverse function and therefore, it will not be able to recover the test label from its output vector . On the other hand, using the data generated with the knowledge of the test label vector using the GenerateInverseNearby procedure, we see that the network does reduce the the error as it trains and has found the test label vector from its output vector at around 40 epochs. This experiment gives an empirical evidence that without the knowledge of , it is hard to find .

Vi Proof-of-Improvement

In this section, we introduce the concept of proof-of-improvement (PoI), a key mechanism supporting DaiMoN. PoI allows a prover to convince a verifier that a model improves the accuracy or reduces the error on the test dataset via the use of DEL without the knowledge of the true test label vector . PoI is characterized by the Prove and Verify procedures shown.

As a part of the system setup, a prover has a public and private key pair (, ) and a verifier has a public and private key pair (, ). Both are given our learnt DEL function , , the set of test inputs , and the current best distance achieved by submitted models, according to the distance function described in Section II.

Let be the message digest function such as IPFS hash [18], MD5 [19], SHA [20] and CRC [21]. Let denotes a message signed by a secret key .

Let be the classification model for which will generate a PoI proof . The model takes an input and returns the corresponding predicted class label. The Prove procedure called by a prover generates the digest of and calculates the DEL function output of the predicted labels of the test dataset by . The results are concatenated to form the body of the proof, which is then signed using the prover’s secret key . The PoI proof shows that the prover has found a model that could reduce the error on a test dataset.

1:procedure Prove()
4:     return
5:end procedure

To verify, the verifier runs the following procedure to generate the verification proof , the proof that the verifier has verified the PoI proof generated by the prover .

1:procedure Verify()
2:     Verify the signature of with
3:     Verify the digest:
4:     Verify the DEL function output:
5:     Verify the distance:
6:     if all verified then
7:         return
8:     end if
9:end procedure

The procedure first verifies the signature of the proof with public key of the prover . Second, it verifies that the digest is correct by computing and comparing it with the digest in the proof . Third, it verifies the DEL function output by computing and comparing it with the the DEL function output in the proof . Lastly, it verifies the distance by computing and sees if it is lower than the current best with a margin of , where is an improvement margin commonly agreed upon among peers. If all are verified, the verifier generates the body of the verification proof by concatenating the PoI proof with the current best distance and . Then, the body is signed with the verifier’s secret key , and the verification proof is returned.

Vii The DaiMoN System

In this section, we describe the DaiMoN system that incentivizes participants to improve the accuracy of models solving a particular problem. In DaiMoN, each classification problem has its own DaiMoN blockchain with its own token. An append-only ledger maintains the log of improvements for that particular problem. A problem defines inputs and outputs which machine learning models will solve for. We call this the problem definition. For example, a classification problem on the FashionMNIST dataset [12] may define an input as a 1-channel pixel input whose values are ranging from 0 to 1, and an output as 10-class label ranging from 1 to 10:

Each problem is characterized by a set of test dataset tuples. Each tuple () consists of the test inputs , the DEL function , and the DEL function output on the true test label vector .

A participant is identified by its public key with the associated private key . There are six different roles in DaiMoN: problem contributors, model improvers, validators, block committers, model runners, and model users. A participant can be one or more of these roles. We now detail each role below:

Problem contributors contribute test dataset tuples to a problem. They can create a problem by submitting a problem definition and the first test dataset tuple. See Section VII-B on how additional test tuples can be added.

Model improvers compete to improve the accuracy of the model according to the problem definition defined in the chain. A model improver generates a PoI proof for the improved model and submit it.

Validators validate PoI proofs, generate a verification proof and submit it as a vote on the PoI proofs. Beyond being a verifier for verifying PoI, a validator submits the proof as a vote.

Block committers create a block from the highest voted PoI proof and its associated verification proofs and commit the block.

Model runners run the inference on the latest model given inputs and return outputs and get paid in tokens.

Model users request an inference computation from model runners with an input and pay for the computation in tokens.

Vii-a The Chain

Each chain consists of two types of blocks: Problem blocks and Improvement blocks. A Problem block contains information, including but not limited to: the block number, the hash of the parent block, the problem definition, the test dataset tuples, and the block hash. An Improvement block contains information, including but not limited to: the block number, the hash of the parent block, PoI proof from model improver , verification proofs from validators , and the block hash. The chain must start with a Problem block that defines the problem, followed by Improvement blocks that record the improvements made for the problem.

Vii-B The Consensus

After a DaiMoN blockchain is created, there is a problem definition period . In this period, any participant is allowed to add test dataset tuples into the mix. After a time period has passed, a block committer commits a Problem block containing all test dataset tuples submitted within the period to the chain.

After the Problem block is committed, a competition period begins. During this period, a model improver can submit the PoI proof of his/her model. A validator then validates the PoI proof and submit a verification proof as a vote. For each PoI proof, its associated number of unique verification proofs are tracked. At the end of each competition period, a block committer commits an Improvement block containing the model with the highest number of unique verification proofs, and the next competition period begins.

Vii-C The Reward

Each committed block rewards tokens to the model improver and validators. The following reward function, or similar ones, can be used:

where is the regularized incomplete beta function, is the distance of the block, is the current best distance so far, and is a parameter to allow for the adjustment to the shape of the reward function. Figure 5 shows the reward function as the distance decreases for different current best distance for . We see that more and more tokens are rewarded as the distance reaches 0, and the improvement gap increases.

Figure 5: The reward function as the distance decreases for varying current best distance for .

Each validator is given a position as it submits the validation proof: the -th validator to submit the validation proof is given the -th position. The validator’s reward is the model improver’s reward scaled by : , where is the validator’s position, and denotes the set of integers greater than zero. This factor encourages validators to compete to be the first one to submit the validation proof for the PoI proof in order to maximize the reward. Two is used as a base of the scaling factor here since

Vii-D The Market

In order to increase the value of the token of each problem, there should be demand for the token. One way to generate demand for the token is to allow it to be used as a payment for inference computation based on the latest model committed to the chain. To this end, model runners host the inference computation. Each inference call requested by users is paid for by the token of the problem chain that the model solves. Model runners automatically upgrade the model, as better ones are committed to the chain. The price of each call is set by the market according to the demand and supply of each service. This essentially determines the value of the token, which can later be exchanged with other cryptocurrencies or tokens on the exchanges. As the demand for the service increases, so will the token value of the problem chain.

Model runners periodically publish their latest services containing the price for the inference computation of a particular model. Once a service is selected, model users send a request with the payment according to the price specified. Model runners then verify the request from the user, run the computation, and return the result.

To keep a healthy ecosystem among peers, a reputation system may be used to recognize good model runners and users, and reprimand bad model runners and users. Participants in the network can upvote good model runners and users and downvote bad model runners and users.

Vii-E System Implementation

DaiMoN is implemented on top of the Ethereum blockchain [2]. In this way, we can utilize the security and decentralization of the main Ethereum network. The ERC-20 [22] token standard is used to create a token for each problem chain. Tokens are used as an incentive mechanism and can be exchanged. Smart contracts are used to manage the DaiMoN blockchain for each problem.

Identity of a participant is represented by its Ethereum address. Every account on Ethereum is defined by a pair of keys, a private key and public key. Accounts are indexed by their address, which is the last 20 bytes of the Keccak [20] hash of the public key.

The position of the verifiers is recorded and verified on the Ethereum blockchain. As a verifier submits a vote on the smart contract on the Ethereum blockchain, his/her position is recorded and used to calculate the reward for verifier.

The InterPlanetary File System (IPFS) [18] is used to store and share data files that are too big to store on the Ethereum blockchain. Files such as test input files and model files are stored on IPFS and only their associated IPFS hashes are stored in the smart contracts. Those IPFS hashes are then used by participants to refer to the files and download them. Note that since storing files on IPFS makes it public, it is possible that an attacker can find and submit the model before the creator of the model. To prevent this, model improvers must calculate the IPFS hash of the model and register it with the smart contract on the Ethereum blockchain before making the model available on IPFS.

Viii Discussion

One may compare a DEL function to an encoder of an autoencoder 

[23]. An autoencoder consists of an encoder and a decoder. The encoder maps an input to a lower-dimensional embedding which is then used by the decoder to reconstruct the original input. Although a DEL function also reduces the dimensionality of the input label vector, it does not require the embedding to reconstruct the original input and it adds the constraint that the output of the function should preserve the error or the distance of the input label vector to a specific test label vector . In fact, for our purpose of hiding the test labels, we do not want the embedding to reconstruct the original input test labels. Adding the constraint to prevent the reconstruction may help further defense against the inverse-mapping attacks and can be explored in future work.

Note that a model with closer distance to the test label vector () in the embedding space may not have better accuracy. This results in a reward being given to a model with worse accuracy than the previous best model. This issue can be mitigated by increasing the margin . With the appropriate setting, this discrepancy should be minimal. Note also that as the model gets better, it will be easier for an attacker to recover the true test label vector (). To mitigate this issue, multiple DEL and reward functions may be used at various distance intervals.

By building DaiMoN on top of Ethereum, we inherit the security and decentralization of the main Ethereum network as well as the limitations thereof. We now discuss the security of each individual DaiMoN blockchain. An attack to consider is the Sybil attack on the chain, in which an attacker tries to create multiple identities (accounts) and submit multiple verification proofs on an invalid PoI proof. Since each problem chain is managed using Ethereum smart contracts, there is an inherent gas cost associated with every block submission. Therefore, it may be costly for an attacker to overrun the votes of other validators. The more number of validators for that chain, the higher the cost is. In addition, this can be thwarted by increasing the cost of each submission by requiring validators to also pay Ether as they make the submission. All in all, if the public detects signs of such behavior, they can abandon the chain altogether. If there is not enough demand in the token, the value of the tokens will depreciate and the attacker will have less incentives to attack.

Since we use IPFS in the implementation, we are also limited by the limitations of IPFS: files stored on IPFS are not guaranteed to be persistent. In this case, problem contributors and model improvers need to make sure that their test input files and model files are available to be downloaded on IPFS. In addition to IPFS, other decentralized file storage systems that support persistent storage at a cost such as Filecoin [24], Storj [25], etc. can be used.

Ix Related Works

One area of related work is on data-independent locality sensitive hashing (LSH) [26] and data-dependent locality preserving hashing (LPH) [27, 28]. LSH hashes input vectors so that similar vectors have the same hash value with high probability. There are many algorithms in the family of LSH. One of the most common LSH methods is the random projection method called SimHash [29]

, which uses a random hyperplane to hash input vectors.

Locality preserving hashing (LPH) hashes input vectors so that the relative distance between the input vectors is preserved in the relative distance between of the output vectors; input vectors that are closer to each other will produce output vectors that are closer to each other in the output space. The DEL function presented in this paper is in the family of LPH functions. While most of the work on LSH and LPH focuses on dimensionality reduction for nearest neighbor searches, DEL is novel that it focuses on learning an embedding function that preserves the distance to the test label vector of the test dataset. For the purpose of hiding the test label vector from verifier peers, it is appropriate that DEL’s distance preserving is specific to this test vector. By being specific, finding the DEL function becomes easier.

Another area of related work is on blockchain and AI. There are numerous projects covering this area in recent years. These include projects such as SingularityNET [30], [31] and Numerai [32]. SingularityNET and are decentralized AI marketplace platforms where anyone can provide AI services for use by the network, and receive network tokens in exchange. This is related to the DaiMoN market, where model runners run inference computation for model users in exchange for tokens. Numerai has an auction mechanism where participants stake network tokens to express confidence in their models’ performance on forthcoming new data. The mechanism will reward participants according to the performance of their models on unspecified yet future test data, their confidence, and their stake. While these platforms all use a single token, DaiMoN has a separate token for each problem. It also introduces the novel ideas of DEL and PoI, allowing the network to fairly reward participants that can prove that they have a model that improves the accuracy for a given problem.

X Conclusion

We have introduced DaiMoN, a decentralized artificial intelligence model network. DaiMoN uses a Distance Embedding for Labels (DEL) function. DEL embeds the predicted label vector inferred by a classifier in a low-dimensional space where its error or its distance to the true test label vector of the test dataset is approximately preserved. Under the embedding, DEL hides test labels from peers while allowing them to assess the accuracy improvement that a model makes. We present how to learn DEL, evaluate its effectiveness, and present the analysis of DEL’s resilience against attacks. This analysis shows that it is hard to launch a brute-force attack or an inverse-mapping attack on DEL without knowing a priori a good estimate on the location of the test label vector, and that the hardness can be increased rapidly by increasing the dimension of the embedding space.

DEL enables proof-of-improvement (PoI), the core of DaiMoN. Participants use PoI to prove that they have found a model that improves the accuracy of a particular problem. This allows the network to keep an append-only log of model improvements and reward the participants accordingly. DaiMoN uses a reward function that scales according to the increase in accuracy a new model has achieved on a particular problem. We hope that DaiMoN will spur distributed collaboration in improving machine learning models.

Xi Acknowledgment

This work is supported in part by the Air Force Research Laboratory under agreement number FA8750-18-1-0112 and a gift from MediaTek USA.