Source-linked AI summary
Decentralized & Collaborative AI on Blockchain
Justin D. Harris, Bo Waggoner
TL;DR
Centralized machine learning can rely on proprietary datasets and charge for predictions, while this paper proposes collaborative data collection and smart-contract-hosted model updates. The framework combines configurable incentives with a public model; its examples emphasize small, compressible inputs because Ethereum storage and gas costs constrain larger deployments.
Problem
Machine-learning data can be proprietary, and access to model predictions may be sold per query.
Source: §I · p. 1, A. Overview · p. 1Method
The framework combines smart-contract data handling and model updates with configurable incentives for contributions.
Source: §I · p. 1, §II · p. 2Results
The paper presents a configurable blockchain framework for collecting data and training models, with ideal scenarios involving varying data and generally agreed-upon labels.
Source: §VIII · p. 8Takeaways & Limitations
The model is intended as a shared, publicly visible resource that can persist across decentralized nodes.
Source: A. Public, Persistent & Decentralized · p. 7Ethereum memory and gas costs constrain examples toward small, compressible inputs and can make large model deployments costly or transaction-prone.
Source: B. Limitations · pp. 2–3
Abstract
from arXiv · showhide
Machine learning has recently enabled large advances in artificial intelligence, but these tend to be highly centralized. The large datasets required are generally proprietary; predictions are often sold on a per-query basis; and published models can quickly become out of date without effort to acquire more data and re-train them. We propose a framework for participants to collaboratively build a dataset and use smart contracts to host a continuously updated model. This model will be shared publicly on a blockchain where it can be free to use for inference. Ideal learning problems include scenarios where a model is used many times for similar input such as personal assistants, playing games, recommender systems, etc. In order to maintain the model's accuracy with respect to some test set we propose both financial and non-financial (gamified) incentive structures for providing good data. A free and open source implementation for the Ethereum blockchain is provided at https://github.com/microsoft/0xDeCA10B.
I. INTRODUCTION
The paper proposes a modular framework for collaboratively improving a publicly accessible machine-learning model, addressing proprietary data and pay-per-query prediction access. Smart contracts coordinate data submission and model updates, while incentive mechanisms aim to encourage useful contributions and discourage manipulation.
I. INTRODUCTION
- The framework lets anyone provide data or freely access predictions, and proposes three incentive-mechanism designs to encourage participation while discouraging manipulation.The proposed mechanisms are justified as examples with different advantages.Source: §I · p. 1
- Earlier systems either restricted trained-model access to a marketplace or lacked continual collaborative updating, while this work targets proprietary data and paid prediction access.The cited systems are DInEMMo and DanKu.Source: §I · p. 1
A. Overview
- A smart contract coordinates data validation, storage, and model updates; prediction uses the model contract’s off-chain function.Contributions can make the dataset public through blockchain transaction history or emitted events, and bad submissions may incur penalties.Source: A. Overview · p. 1
B. Machine Learning and Blockchain Background
- The framework applies to networks agreeing on a shared computation sequence; Ethereum inference can be free when code execution does not write to the blockchain.The paper says the design is not limited to Ethereum.Source: B. Machine Learning and Blockchain… · p. 2
C. Staking a Deposit
- Staked deposits can simplify enforcement because users cannot be forced to pay a smart-contract penalty; the data-submission flow may require a stake.The figure also describes storing data and metadata on-chain before updating the model.Source: C. Staking a Deposit · p. 2, Figure 1 · p. 2
D. Organization
The paper describes incremental-learning models and their deployment on Ethereum, alongside incentive mechanisms for data contributions. Its examples focus on small, compressible inputs because blockchain memory and transaction costs constrain larger models and data.
D. Organization
- The paper’s organization proceeds from the data handler and model, through incentive mechanisms and implementation, to blockchain rationale, potential issues, and future work.Source: D. Organization · p. 2
II. MACHINE LEARNING MODELS
- Ethereum examples favor models that can update efficiently with one sample, which may lower gas costs; nearest-centroid and online-learning models are suggested options.The framework can use supervised or unsupervised models, and the model architecture is tied to the chosen incentive mechanism.Source: §II · p. 2
A. Initial Model
- A partly trained initial model may attract inference users and can help validate contributions for some mechanisms, but pretraining or high accuracy is not always needed.Source: A. Initial Model · p. 2
B. Limitations
- Ethereum memory costs favor small, compressible inputs; large contracts can incur high gas costs and risk transaction rejection.The paper estimates uploading MNIST at 275 ether at 4 gwei; it reports a roughly 8 million gas limit at the time and notes oversized models can be added in multiple transactions.Source: B. Limitations · pp. 2–3
C. Experiment
- Adding features raises initial deployment cost, while the cost of adding data is similar because contributed features have a sparse representation.The experiment uses a single-layer perceptron trained on IMDB reviews; Table I is identified as reporting gas costs for model interactions.Source: C. Experiment · p. 3
III. INCENTIVE MECHANISMS
- The paper presents a baseline with no financial incentives and describes test-set performance as a natural proxy for rewarding correct data contributions.If no test set can be provided, the paper says other performance measures can be considered; it leaves further analysis of each mechanism to future work.Source: §III · p. 3
A. Gamification
The section proposes participation incentives ranging from voluntary contribution and gamification to a bounty-funded prediction-market mechanism. The bounty design uses an outside provider’s test data to reward contributions that improve model performance.
A. Gamification
- The no-financial-incentive baseline relies on contributors’ willingness to collaborate for a common good, with points and optional badges as gamified recognition.Points or badges could reflect contribution volume, diversity, label variety, or regularity; efficient on-chain or off-chain computation of these metrics needs further study.Source: A. Gamification · p. 3
B. Rewards Mechanism Based on Prediction Markets
- An outside provider supplies reward funds and a test dataset, with participants rewarded according to how much they improve model performance on that test data.The authors describe this as a monetary reward-based design extending collaborative machine-learning contest proposals and.Source: B. Rewards Mechanism Based on… · p. 3
1) Overview:
- The mechanism begins with a provider committing a bounty, loss function, and test dataset, then participants stake currency while adding data until an end condition is met.The provider commits to the test data and reveals a small random fraction initially; the mechanism can begin another cycle if a new provider commits test data.Source: 1) Overview · p. 3
A. Commitment Phase
The bounty mechanism commits the provider to test data, collects staked participant updates, and pays rewards based on model performance on the revealed test set. Its reward calculation links better successive models to greater participant rewards while iterating a unit stake to support larger bounties.
A. Commitment Phase
- The provider deposits bounty B, defines loss L(h, D), commits to 100 hashed test-data parts, reveals 10 selected parts, and specifies an end condition.The provider later uploads the remaining 90 partial datasets for commitment checking.Source: A. Commitment Phase · p. 4, C. Reward Phase · p. 4
B. Participation Phase
- Each participant stakes one currency unit and provides data that updates the model; participation continues until the specified end condition is met.The mechanism retains participants who can restake at least one unit and pays each their resulting balance.Source: B. Participation Phase · p. 4, C. Reward Phase · p. 4
C. Reward Phase
- In the reward phase, the provider uploads the test dataset for commitment verification, after which the contract determines participant rewards.The loss function L(h, D) is clipped to [0, 1] by the contract.Source: C. Reward Phase · p. 4, Figure 2
2) Reward calculation.:
- For B = 1, successive participants pass forward loss-based payments, so better-performing updates leave contributors with more reward and total net payout equals L(h0, D)−L(hT, D).For larger B, the mechanism iterates B times with one-unit stakes; participants drop out if losses leave them unable to restake.Source: 2) Reward calculation · p. 4
3) Untrusted provider, commitment, and value burning:
The bounty design addresses provider manipulation through advance test-data commitments and value burning, while a separate self-assessment mechanism uses an existing model to validate contributions without an outside test-set provider. The latter depends on the deployed model already classifying samples with accepted accuracy.
3) Untrusted provider, commitment, and value burning:
- A provider could manipulate the test dataset or collaborate with participants, so the design combines cryptographic commitment with value burning.The provider must expect to lose the entire bounty and participate only if the trained model’s value justifies that cost.Source: 3) Untrusted provider, commitment, and… · pp. 4–5
- The commitment reveals a random 10% of the test data in advance, deterring a provider from using incorrect labels to profit from honest participants’ losses.Failure to comply leaves the bounty stuck in the contract rather than refunded.Source: 3) Untrusted provider, commitment, and… · p. 4
C. Deposit, Refund, and Take: Self-Assessment
- Self-assessment uses a deployed model as a proxy validator: contributors deposit with labeled data, can reclaim deposits if the model still agrees after time t, and validated contributors can claim deposits tied to data the model rejects.Other contributors are expected to submit a different label within time t when a sample is incorrect or invalid.Source: C. Deposit, Refund, and Take:… · p. 5
1) Time to Wait for Refund:
The refund wait should allow time for corrections, with the appropriate duration depending on model sensitivity. Deposits can discourage spam and overly frequent updates, supporting a more consistent prediction experience.
1) Time to Wait for Refund:
- The refund wait t should allow time for corrections, with one week suggested as an example; very sensitive models risk refunds preceding corrections and require careful experiments.Less sensitive models may need longer to learn new use cases, while t could vary with sample properties, submission frequency, or model certainty.Source: 1) Time to Wait for Refund · p. 5
2) Varying Deposit:
- Deposits are intended to enable rewards for valid data, inhibit frequent model changes, and reduce spam, making repeated updates costly and predictions more consistent.The paper illustrates the consistency concern with a personal assistant responding differently to repeated spoken requests.Source: 2) Varying Deposit · p. 5
3) Taking Another’s Deposit:
The deposit-sharing rules reward contributors who report data the model disagrees with, while adding eligibility and payout constraints intended to discourage abuse. The reporter’s share can change as claims are made.
3) Taking Another’s Deposit:
- A reporter must be someone other than the original contributor, have prior refunded data, and report a label the current model disagrees with.These conditions are intended to prevent contributors from reclaiming deposits for their own bad data and to require reporters to have previously submitted data treated as good.Source: 3) Taking Another’s Deposit · p. 5
- The reward is shared among good contributors, and using another account to reclaim a deposit requires waiting for refunds on good data.Sharing the reward is intended to protect against Sybil attacks.Source: 3) Taking Another’s Deposit · pp. 5–6
- The reward should exceed a minimum to cover transaction costs, and the data handler must track the remaining claimable deposit.The reward is defined for a contributing reporter who reports data with deposit d.Source: 3) Taking Another’s Deposit · pp. 5–6
- Because n(c) changes while reporters claim their shares, later reporters may receive a smaller proportion of the deposit.The section points to possible solutions in III-C5.Source: 3) Taking Another’s Deposit · p. 6
4) Biasing the Model:
The section discusses bias risks from rewarding data the model already recognizes, rules for reclaiming unclaimed deposits, a simulation setup, and implementation choices for Ethereum.
4) Biasing the Model:
- Contributors may favor examples the model already classifies correctly, biasing it toward data it already “knows”; designers must consider duplicates and similar data.The proposed deposit-and-refund process still imposes transaction fees, and the incentive mechanism may reject excessive duplicate or similar data.Source: 4) Biasing the Model · p. 6
5) Preventing Lock-ups:
- The lock-up rules let the creator claim the remaining refund after tc, then let anyone claim it after ta if the creator does not.The parameters require tc > t and ta ≥ tc > t; the section also describes a possible td for contributors with refunded submissions.Source: 5) Preventing Lock-ups · p. 6
6) Experiment:
- The simulation began with a Perceptron trained on 8% of the IMDB reviews training dataset, using 1,000 binary features for the most frequent words.The simulation then introduced the remaining 92% of the training data over time; one honest and one malicious contributor represented many contributors.Source: 6) Experiment · p. 6
A. Floating Point Numbers
- Because Ethereum does not support floating-point numbers, examples represent them as scaled integers and perform operations with that transformation in mind.The passage gives multiplication by 10^9 as an example of nine decimal places of precision.Source: A. Floating Point Numbers · p. 6
B. Inversion of Control
The framework uses composition-based smart-contract design and presents blockchain benefits including public model access, version rollback, evolution, and transparent execution. The discussion also flags training-capable systems as having specific vulnerabilities.
B. Inversion of Control
- The implementation favors composition over inheritance for clarity, while noting that inheritance can cost less in Ethereum smart contracts.Ownership and publicity of contained contracts also require consideration.Source: B. Inversion of Control · p. 6
V. BENEFITS OF BLOCKCHAIN
- In a simulation, accuracy remains maintainable and honest contributors profit even when the adversary spends about twice as much on deposits but submits data only one sixth as often.Figure 3 compares balance percentages and model accuracy for the Bad Agent and Good Agent.Source: Figure 3 · p. 6
A. Public, Persistent & Decentralized
- A model deployed on a blockchain is shared and publicly visible, and the authors say it can persist across decentralized nodes.Source: A. Public, Persistent & Decentralized · p. 7
B. Versioning
- Users can revert to an earlier model version by choosing a prior blockchain block, potentially judging it with their own hidden test set.Source: B. Versioning · p. 7
C. Models Evolve Over Time
- Smart contracts allow models to evolve as their environment changes, such as by recognizing novel words.Source: C. Models Evolve Over Time · p. 7
D. Transparency & Trust
- Code on Ethereum is public and execution results can be evaluated deterministically, so contributors can trust model updates and compensation.The model's update method is public, but only the CollaborativeTrainer that owns the model can call it because it manages the incentive mechanism.Source: B. Inversion of Control · p. 6, D. Transparency & Trust · p. 7
VI. POTENTIAL ISSUES
- The framework analyzes vulnerabilities specific to systems where models can be trained, alongside issues already addressed for static models.Source: §VI · p. 7
A. Submitting Bad Data
The section considers risks from malicious or ambiguous contributions, network congestion, and deposits, then identifies model types and approaches for future work.
A. Submitting Bad Data
- A wealthy, determined agent can corrupt a deployed model with incorrect or nonsensical training data.The proposed response is to make bad submissions costly and unbeneficial; transaction fees, version rollback, and analysis to salvage good data are also described.Source: A. Submitting Bad Data · p. 7
B. Ambiguous Data
- Ambiguous labels can put contributors’ funds at risk, so the authors advise keeping submitted data unambiguous.The passage uses “The movie is okay” with “happy” or “sad” labels as an example.Source: B. Ambiguous Data · p. 7
C. Overwhelming the Network
- Network congestion can disrupt adding data because each contribution requires a new transaction, while inference can run locally through reads.The passage says inference should not be affected and is normally free.Source: C. Overwhelming the Network · p. 7
D. Requiring a Deposit
- Deposits may be unfamiliar to new contributors, and popular blockchains also require small transaction fees.A third party could hide deposit costs by validating contributions and rewarding users under its own scheme.Source: D. Requiring a Deposit · p. 7
VII. FUTURE WORK
- The authors call for more research on which model types work well within the framework.Source: §VII · p. 7, A. Models · p. 7
1) Unsupervised Models:
- Although the examples focus on supervised classifiers, test sets and incentive mechanisms can also validate contributions for unsupervised models.Suggested directions include clustering for outlier detection and generative models such as autoencoders and GANs.Source: 1) Unsupervised Models · p. 7
2) Complex Models:
The framework outlines options for using complex models, recovering corrupted models, and addressing incentive and privacy concerns. It concludes that it currently suits efficiently updated models and learning problems with varying data and generally agreed-upon labels.
2) Complex Models:
- Off-chain precomputation and fine-tuning encoded inputs are proposed to reduce on-chain work, with a static encoder preferred.The encoder may change slightly if fine-tuning inputs remain similar to previously seen training data.Source: 2) Complex Models · p. 8
3) Recovering Corrupted Models:
- A corrupted model’s collected data can be refined, then used to train a replacement model for private production use or a new collaborative training instance.Clustering is one example of data refinement.Source: 3) Recovering Corrupted Models · p. 8
B. Incentive Mechanisms
- Further exploration and experiments are needed to determine which incentive mechanisms work well with which model types.Source: B. Incentive Mechanisms · p. 8
C. Privacy
- The initial privacy scope is data safe to publish publicly; future work could submit model updates instead of raw data.Weather queries are given as an example of data without personal information.Source: C. Privacy · p. 8
VIII. CONCLUSION
- The framework targets efficiently updated models and is best suited to varying data with generally agreed-upon labels.Scaling to more complex models is left for future research.Source: §VIII · p. 8