Content uploaded by Aaron Y.
Author content
All content in this area was uploaded by Aaron Y. on Aug 11, 2024
Content may be subject to copyright.
Crynux Hydrogen Network (H-Net):
Decentralized AI Serving Network on Blockchain
Henry Lee, Luke Weber, Max Weng, Young Wong, Aaron Y. *
Crynux AI Lab
Abstract
Crynux Hydrogen Network (H-Net) represents a pio-
neering decentralized AI service network that harnesses the
power of blockchain technology. Crynux H-Net not only
guarantees efficient task execution but also fosters partic-
ipant integrity and robustly thwarts malicious actors. The
consensus mechanism of Crynux H-Net utilizes a combi-
nation of theoretical methodologies and economic strate-
gies to enhance authentication capabilities. Dual-phase
pHash disclosure and sequential node selection synergisti-
cally shield against manipulation, while collateral-based pe-
nalization effectively discourages malicious behavior, safe-
guarding network integrity and efficiency. Introducing Re-
lay, Crynux H-Net optimizes the usability and overall effi-
ciency of the network. Additionally, within the paradigm of
Crynux dApp development, Crynux H-Net showcases the
Image Generator as an illustrative example, demonstrating
its versatility and potential for application. Crynux H-Net
paves the way for a secure, transparent, and efficient future
of AI serving, empowering developers and users alike.
1 Introduction
Artificial Intelligence (AI) has transcended mere tech-
nological marvel to become a pervasive force shaping our
world. Yet, alongside its transformative potential lurks a
growing concern: the specter of centralized control and its
implications for data privacy, algorithmic bias, and resource
monopolization [3] [1].
Traditionally, the process of training and deploying AI
models follows a structured paradigm. First, data collection
involves the aggregation, processing, and refining of data
for training purposes. Next, model training entails selecting
*Corresponding Author. Email: c@crynux.ai
an architecture and training the model using specialized AI
chips, a resource-intensive process both in terms of time and
energy. Finally, the trained model is deployed to serve live
user traffic.
However, each stage of this process raises concerns as-
sociated with centralization. Data collection threatens user
privacy, centralized model hosting raises the specter of AI
misuse, and the resource-intensive nature of AI model train-
ing fuels worries about monopolistic control by large AI
corporations.
We propose Crynux Hydrogen Network (H-Net), a pi-
oneering effort to illuminate a path towards a decentral-
ized AI serving network. This novel architecture leverages
blockchain technology to foster an ecosystem of trust, fair-
ness, and efficiency in AI inference, breaking free from the
shackles of centralized control.
The architecture of Crynux H-Net represents a sophisti-
cated framework underpinned by blockchain technology. It
orchestrates AI tasks seamlessly by fostering collaborative
interactions among Crynux Nodes, Crynux dApps, Smart
Contracts, and Relays. This collaborative ecosystem aims
to instill trust, fairness, and efficiency in AI inference.
Crynux Nodes form the network’s backbone, responsible
for executing tasks and ensuring result authenticity through
rigorous consensus mechanisms. These nodes meticulously
handle task acquisition, execution, and validation, maintain-
ing network integrity while facing penalties for any fraudu-
lent activities. In contrast, Crynux dApps seamlessly utilize
Crynux H-Net for AI tasks, adhering to a structured work-
flow for task submission, monitoring, and result retrieval.
Smart Contracts on the blockchain play a pivotal role in
ensuring trust and fairness. They govern interactions be-
tween Crynux Nodes and dApps, facilitating task schedul-
ing, verification, and payment escrow, preventing dishonest
behavior and safeguarding against premature charges
The Relay, acting as an intermediary, efficiently man-
1
Figure 1: Crynux H-Net Architecture Overview
ages large off-chain data, thereby enhancing data accessibil-
ity and reducing on-chain congestion. However, challenges
related to data availability and network reachability signify
potential areas for enhancement, particularly through the in-
tegration of decentralized storage networks.
The consensus protocol stands as a linchpin for Crynux
H-Net’s integrity, employing a meticulous voting mecha-
nism and similarity comparison to ensure valid results. This
protocol leverages the disclosure of pHashes through a dual-
phase on-chain process, thereby safeguarding against mali-
cious manipulation and ensuring reliability in AI task exe-
cution.
Beyond the watchful eye of the consensus protocol,
Crynux H-Net employs an economic disincentive to ensure
honest participation: collateral-based penalization. Each
node stakes a designated amount of tokens upon joining the
network. Misconduct, such as submitting fraudulent results,
triggers this collateral to be slashed, acting as a powerful
deterrent against malicious behavior.
This interplay of a robust consensus protocol and a well-
designed penalization scheme safeguards Crynux H-Net
from malicious actors, upholding network integrity and pro-
moting efficient execution. Nodes are incentivized to op-
erate honestly, fostering trust within the decentralized AI
ecosystem.
The main contribution of this paper can be summarized
as follows:
• Proposing, designing, and implementing Crynux H-
Net as a pioneering and practical blockchain network
for decentralized AI model serving.
• Designing a consensus mechanism for decentralized
AI model serving and conducting an analysis of its ef-
fectiveness.
• Developing Crynux dApp on Crynux H-Net as a
paradigm for decentralized AI applications.
2 Related Work
As the tentacles of Artificial Intelligence (AI) reach
deeper into our lives, concerns regarding its centralization
2
have risen in tandem. This centralization breeds anxieties
about data privacy, algorithmic bias, and the consolidation
of power in the hands of a few. Fortunately, amid these con-
cerns, a surge of innovative efforts is paving the way for a
paradigm shift: decentralized AI.
Blockchain is the foundational brick of decentralization.
It was first introduced as a decentralized ledger technology
[2]. Blockchain’s ability to foster trust and consensus with-
out a central authority has inspired a wave of decentralized
applications and infrastructures. Ethereum [19], with its
introduction of smart contracts, further fuelled this move-
ment by providing a platform for automating agreements
and tasks. These combined technologies form the funda-
mental building blocks upon which decentralized AI can be
erected.
Recognizing the importance of data privacy in AI,
techniques like federated learning[10] and differential
privacy[7] have emerged. Federated learning allows mod-
els to be trained on distributed data residing on individual
devices, minimizing the need for centralized data storage.
Differential privacy, on the other hand, adds statistically
controlled noise to data outputs, protecting private informa-
tion while still enabling accurate computations. Google and
Apple, among others, have already begun integrating these
technologies into their applications.
Federated learning [10] and differential privacy [7] are
efforts to preserve user data’s privacy when training an AI
model. Many applications from Google and Apple are al-
ready making use of these technologies.
The marriage of blockchain and federated learning [14]
presents a natural progression, offering an avenue for incen-
tivizing data contribution and fostering trust within decen-
tralized networks. However, this technology mostly focuses
on data sharing.
Interest in resolving the challenge of decentralized AI
serving is reaching a fever pitch[11]. Platforms like Neb-
ula AI[16] offer AI marketplaces where users can lever-
age the computational power of distributed GPU workers.
SingularityNET[15] builds an open marketplace for AI ser-
vices. Numerai[4] employs an auction mechanism to gauge
data scientists’ confidence in their models. DaiMoN[17], on
the other hand, explores the use of ”Proof-of-Improvement”
for decentralized model training, further fueling the innova-
tion in this space.
3 System Architecture
Figure 1 presents a high-level overview of the Crynux
H-Net architecture, a decentralized AI serving network on
blockchain technology. The system comprises several key
components:
•Crynux Nodes: These are the workhorses of the net-
work, providing computational power by executing AI
inference tasks submitted by applications. Nodes are
incentivized with tokens for their contributions.
•Crynux dApps: These are applications that leverage
the Crynux network for AI inference. They submit
tasks to Crynux Nodes, specifying the required com-
putation and paying for it with tokens. Once the task
is complete, the dApp receives the results.
•Smart Contracts: Both Crynux Nodes and dApps in-
teract with the network through smart contracts de-
ployed on the underlying blockchain. These contracts
play a crucial role in ensuring trust and fairness:
–Task Verification: Smart contracts guarantee that
nodes actually execute the tasks and do not at-
tempt to cheat by providing fabricated results.
This protects Crynux dApps from paying for in-
accurate or incomplete work.
–Payment Escrow: Smart contracts hold Crynux
dApp payments in escrow until the correspond-
ing task is successfully completed by a node.
This ensures that nodes receive their rewards
only for valid work, while Crynux dApps are not
charged prematurely.
•Relays: Large data, such as task arguments or images,
can be cumbersome to store directly on the blockchain.
Relays address this challenge by acting as intermedi-
ary agents between Crynux Nodes and Crynux dApps.
They handle the off-chain storage and retrieval of such
data, improving data availability and network accessi-
bility.
By combining these components, Crynux H-Net creates
a secure and efficient platform for decentralized AI infer-
ence. The blockchain ensures trust and transparency, while
the smart contracts and relays facilitate seamless interac-
tion and data management. This architecture unlocks the
potential of decentralized computing for a wide range of AI
applications.
3.1 Crynux Node
Crynux Nodes act as the on-chain workers, execute AI
inference tasks and verify results on the blockchain.
Task Aquisition and Preparation: Unpon activation,
the Crynux Node diligently scans the blockchain for new
tasks submitted by Crynux dApps. Once a promising op-
portunity arises, the Crynux Node establishes a connection
with the Relay to retrieve the complete task requests. This
information typically includes the ID of a pre-trained model
3
hosted on HuggingFace1or the URL of a LoRA model [9]
stored on Civitai2.
Computation and Execution: With detailed task re-
quests, the Crynux Node leverages its local hardware re-
sources, usually high-performance AI Accelerators, to exe-
cute the AI inference. This involves running the specified
model on the provided input data, ultimately generating the
desired results.
Consensus and Proof of Work: To uphold the in-
tegrity of the network and safeguard against malicious ac-
tors, Crynux Nodes adhere to a robust consensus proto-
col. This protocol requires the Crynux Node to perform ad-
ditional computations, specifically, calculating a similarity
metric for the generated results. This value is disclosed on
the blockchain, serving as transparent proof of the Crynux
Node’s efforts.
Reward: When other Crynux Nodes independently
replicate the task and obtain similar results, the result from
the Crynux Node is verified, leading to token rewards for
its valuable contribution. This incentivizes nodes to consis-
tently deliver accurate and reliable outcomes.
Penalty Mechanism: Conversely, if significant dis-
crepancies emerge between the reported results and sub-
sequent validations, the Crynux Node faces consequences.
Its staked tokens are slashed, reallocating them to the net-
work’s incentivization pool, and the node itself is excluded
from the Crynux H-Net. This harsh penalty safeguards the
platform’s integrity and discourages fraudulent behavior.
Section 4 provides a more comprehensive delve into the
intricacies of Crynux Node operations, including their inter-
play with other architectural components within the Crynux
H-Net framework.
3.2 Crynux dApp
Crynux dApps represent the driving force behind utiliz-
ing the platform’s AI inference capabilities. Developed by
independent developers, these applications leverage Crynux
H-Net as a powerful infrastructure service, offloading their
computational needs onto the network of Crynux Nodes.
Crynux dApps follow these steps to utilize Crynux H-
Net:
•Task Definition: The Crynux dApp generates the task
specification, outlining the desired AI operation and
input data.
•Secure Commitment: To ensure transparent pricing
and prevent resource abuse, the Crynux dApp commits
the required payment in tokens by submitting a hash of
the task request to the blockchain.
1https://huggingface.co
2https://civitai.com
•Network Activation: Upon blockchain confirmation,
the Crynux dApp transmits the complete task details to
the Relay, formally entering the execution pipeline.
•Patient Await: The Crynux dApp then enters a wait-
ing state, monitoring the blockchain for the ”task suc-
cess” event. This event serves as a reliable notification
that the assigned Crynux Node has successfully com-
pleted the computation.
•Result Retrieval: Once the ”task success” event is
broadcasted, the Crynux dApp confidently retrieves
the generated results from the Relay, completing the
inference cycle.
•Internal Integration: The Crynux dApp can seam-
lessly integrate the results into its own internal work-
flow, fulfilling its intended purpose.
Section 5 contains a detailed illustration and concrete ex-
ample of this workflow in action. example to demonstrate
the workflow.
3.3 Smart Contract
The blockchain plays a critical role in Crynux H-Net by
hosting and executing smart contracts that govern the inter-
action between Crynux Nodes and Crynux dApps. Crynux
H-Net’s smart contracts are designed to operate on any
blockchain platform that supports them, offering developers
increased flexibility and portability. These self-executing
contracts ensure trust and fairness within the network, de-
void of any centralized control.
The blockchain maintains a transparent and tamper-
proof ledger recording the current state of the network, in-
cluding a list of active Crynux Nodes and their status. This
decentralization eliminates the need for a central author-
ity, empowering the community to uphold the network’s in-
tegrity.
Crynux Nodes have the autonomy to join or exit the net-
work at will. However, a minimum stake of tokens is re-
quired for onboarding, incentivizing responsible participa-
tion and deterring malicious behavior. Furthermore, the po-
tential for token slashing in case of detected cheating en-
sures accountability and discourages fraudulent activities.
To mitigate bias and guarantee fairness, smart contracts
randomly select three available Crynux Nodes to execute
each task submitted by a Crynux dApp. This distributed
approach minimizes the influence of any single node and
enhances resilience against malicious actors. To ensure
the authenticity of results, Crynux Nodes disclose crypto-
graphic hashes of their generated outputs on-chain. Sub-
sequently, the smart contract automatically compares these
hashes, detecting and penalizing any discrepancies through
4
token slashing. This mechanism incentivizes nodes to de-
liver accurate and reliable results.
3.4 Relay
The introduction of Relay serves as a critical enabler
for Crynux H-Net’s scalability and user experience. Tra-
ditional blockchains struggle with storing large data objects
like task requests and results due to limitations in block size
and transaction fees. Relay addresses this bottleneck by act-
ing as a dedicated off-chain storage solution.
Relay securely stores both task requests and generated
results during a lifecycle of the task, making them read-
ily accessible to authorized participants, i.e., Crynux dApps
and Crynux Nodes. This off-chain approach significantly
reduces on-chain transaction costs and improves network
efficiency.
However, there are two limitations of Relay:
•Data Availability: A potential vulnerability arises if
Relay’s storage system experiences failure. Nodes
wouldn’t be able to retrieve task requests, hindering
task completion. Furthermore, the blockchain lacks
the capability to directly verify data accessibility on
Relay, hindering its ability to detect and penalize nodes
that cannot access task data[18]. This scenario could
potentially cripple the system.
•Network Reachability: Another challenge pertains to
network reachability. When Crynux dApps and Nodes
reside in disparate subnets, direct communication be-
comes impossible, a well-known issue in P2P net-
works. To address this, Relay strategically positions
itself within the public network, where it’s accessible
to all participants. This enables it to act as an interme-
diary hub, facilitating communication between Crynux
dApps and Nodes regardless of their subnet locations.
While Relay effectively tackles the current data storage
and accessibility concerns, decentralized storage networks
offer a promising long-term solution. Integrating such a net-
work would provide several advantages:
•Enhanced Data Resilience: Decentralized storage
guarantees data persistence and eliminates single
points of failure, mitigating the risk of data loss even if
Relay encounters issues.
•Blockchain Verification: Smart contracts could di-
rectly interact with the decentralized storage network,
verifying the existence and accessibility of data, fur-
ther strengthening the network’s integrity and account-
ability.
3.5 Blockchain Task
Crynux H-Net leverages the blockchain to orchestrate
and secure the tasks submitted by Crynux dApps. This pro-
cess follows a well-defined lifecycle comprising three dis-
tinct phases: Task Creation, Task Execution, and Result Re-
trieval. Each phase employs specific mechanisms to ensure
efficient execution, prevent malicious behavior, and incen-
tivize network participation.
3.5.1 Task Creation
The Crynux H-Net task lifecycle commences with task cre-
ation, orchestrated by the Crynux dApp. This crucial phase
involves several key steps:
The task lifecycle begins with the Crynux dApp ini-
tiating the process by submitting a task request to the
blockchain. This request triggers a smart contract invoca-
tion, responsible for:
•Task Validation and Scheduling: The smart contract
validates the request and schedules the task for execu-
tion, ensuring optimal resource utilization within the
network.
•Candidate Pool Selection: To become eligible for
task execution, Crynux Nodes must stake a designated
amount of tokens, demonstrating their commitment
to the network and serving as a financial safeguard
against misconduct. This staking process adds the
Crynux Node to the candidate pool from which tasks
are randomly selected.
•Node Selection: The smart contract employs a ran-
domized selection strategy to choose three available
nodes from the candidate pool. This distributed ap-
proach mitigates the risk of collusion and promotes
fairness among participating nodes.
However, certain conditions can lead to transaction re-
versal:
•Insufficient Crynux dApp Tokens: If the Crynux
dApp’s wallet lacks the necessary CNX tokens to cover
the task cost, the transaction will be automatically re-
verted.
•Limited CNX Allowance: The Crynux dApp might
not have granted sufficient spending allowance to the
task contract, resulting in transaction failure.
•Network Resource Scarcity: In rare cases, a lack of
available nodes within the network may trigger trans-
action reversal.
5
Figure 2: Crynux Task Creation
Once the transaction is confirmed, the Crynux dApp up-
loads the task requests to the Relay. To ensure data consis-
tency and synchronization, the Relay will wait until it re-
ceives the ”TaskCreated” notification from the blockchain.
After the task requests are uploaded to the Relay, the task
creation process is completed.
3.5.2 Task Execution
Following selection, each Crynux Node independently ex-
ecutes the assigned task using its local hardware resources.
The Crynux Node retrieves the task requests from Relay and
verifies the local availability of the specified models. If ab-
sent, the models are downloaded from the provided URLs
or Hugging Face ID.
Download failures due to invalid links or network issues
trigger retries within a designated timeout period. Exceed-
ing the timeout results in task cancellation. Model compat-
ibility errors (e.g., mismatched versions) are reported to the
blockchain.
The extracted task is sent to the Crynux Node’s execution
engine for processing. The engine performs comprehensive
validation and identifies potential configuration errors (e.g.,
a SDXL3Lora model combined with a SD1.5 base model).
3https://stability.ai
Such errors are reported to the blockchain. Successful exe-
cution generates the desired results.
To prevent result manipulation, each node calculates a
Perceptual Hash (pHash) for its generated results. For im-
ages, this pHash captures the image’s essential visual fea-
tures, acting as a tamper-proof fingerprint.
The disclosure process for a node starts by submitting a
hash of the combination of the pHash and a random num-
ber, and then disclosing the actual pHash to the blockchain
after receiving the ”CommitmentsReady” events from the
blockchain, which will only be emitted when the blockchain
receives all the 3 commitments.
The blockchain compares the pHashes from all three
nodes. Matching pHashes from at least two nodes indicate
a successful task and trigger token rewards for participat-
ing nodes. Significant pHash discrepancies (exceeding a
pre-defined Hamming distance threshold) indicate potential
cheating. The identified node faces token slashing penalties
and removal from the network. In the unlikely scenario of
all three pHashes being distinct, the task is aborted, and a
”TaskAborted” event is emitted.
Upon successful consensus, the ”TaskSuccess” event is
broadcasted, notifying relevant parties to proceed. Results
will be uploaded to the Relay.
This rigorous execution and result disclosure protocol
safeguards the integrity of Crynux H-Net’s AI inference
6
process, fostering trust and accountability within the net-
work.
Below is a state transition graph to list all the possible
state of the task and the nodes:
The orange arrows indicates all the possible states and
transitions of the task containing reported errors. The
single-letter tag with blue background on the transition line
indicates an emitted event.
The ”TaskSuccess” event selects one of the nodes to up-
load the images to the relay. The selected node, after re-
ceiving the TaskSuccess event, will upload the images to
the relay, and then report to the Blockchain that the images
have been uploaded. The Blockchain will mark the task as
completed then, the state storage for the task on-chain will
be cleared.
3.5.3 Result Retrieval
The Crynux dApp monitors the blockchain for the events.
Upon receiving the ”TaskSuccess” event, the Crynux dApp
proceeds to retrieve the results from the Relay.
Some abnormal situations need to be handled by the
Crynux dApp. The Relay will return ”400 File Not Found”
response if the results haven’t been uploaded from Crynux
Nodes. In cases of ”TaskAborted” events, the Crynux dApp
acquires the abort reason from the event arguments and ini-
tiates appropriate retry mechanisms if necessary.
4 Consensus Mechanism
While the Crynux H-Net system demonstrates function-
ality without introducing the blockchain, a crucial concern
revolves around preventing Crynux Nodes from undermin-
ing its integrity by returning fraudulent results. Therefore,
we introduce a consensus mechanism on the blockchain to
address this challenge.
Crynux H-Net employs a blockchain-based token sys-
tem, referred to as CNX, to incentivize and reward partic-
ipants. This incentivization model promotes engagement
and efficient network operation.
4.1 Consensus protocol
The Crynux Network leverages a robust consensus pro-
tocol to address two key challenges: deterring malicious
participants and incentivizing honest execution. In a per-
missionless setting where anyone can join, accountability
and trust become paramount. Without safeguards, mali-
cious nodes could exploit the system by submitting random
results or fabricating outputs without performing the com-
putation.
Crucially, the consensus protocol is implemented en-
tirely through smart contracts on the blockchain, so that
it can tackle these issues by ensuring verifiable computa-
tion and incentivized honesty. This eliminates the need for
a central authority or trusted third party, who could intro-
duce vulnerabilities or abuse their power. By automating
the protocol on the blockchain, we achieve a tamper-proof
and transparent system that fosters trust and incentivizes se-
cure computation within the Crynux Network.
4.1.1 Result Validation through Voting Mechanism
The validation of results employs a straightforward pro-
cess of comparing outcomes obtained from three randomly
selected Crynux Nodes. Upon task submission to the
blockchain by the Crynux dApp, the system randomly se-
lects three available Crynux Nodes and prompts them to
commence the task. These Crynux Nodes individually exe-
cute the task and report their results to the blockchain. The
blockchain then compares these results to ascertain the pres-
ence of any fraudulent activities by the Crynux Nodes.
4.1.2 Similarity Comparison
The inherent technical constraints, such as reproducibility
of model inference, pose challenges in generating precisely
identical results across diverse devices. This underscores
the inherent randomness in the realm of machine learning.
Fortunately, exact results replication is unnecessary. In-
stead, computing a similarity score between two results suf-
fices, provided the score meets the Crynux dApp’s accep-
tance criteria. While alternate methods exist to generate
similar results at a lower computational cost compared to
performing model inference, the network deems results ac-
ceptable as long as their similarity meets the Crynux dApp’s
threshold.
Crynux H-Net leverages the Perceptual Hash (pHash)
methodology to determine image similarity. Each node
submits the pHash of the results to the blockchain, which
then calculates the Hamming Distance [12] between two
pHashes [6], generating a similarity score as the basis for
result validation.
4.1.3 Dual-Phase On-Chain Result Disclosure
Direct submission of the pHash to the blockchain is avoided
to mitigate potential interception by malicious nodes, pre-
venting their manipulation of generated data.
A two-phase commitment-disclosure protocol is imple-
mented to address this concern.
Phase 1 - Commitment Submission On-Chain
Crynux Nodes generate a local random number, concate-
nate it with the pHash, and compute the hash of this combi-
nation. This resultant hash serves as the commitment, sub-
mitted alongside the random number onto the blockchain.
7
random number ←generate random number()
commitment ←hash(p hash +random number)
submit to blockchain(commitment, random number)
This commitment ensures the confidentiality of the
pHash. The blockchain awaits the submission of commit-
ments and corresponding random numbers from all three
nodes before proceeding to phase 2.
Phase 2 - On-Chain pHash Disclosure
Honest nodes safely disclose their pHash to the
blockchain at this stage. The blockchain validates the sub-
mitted pHashes using the commitments and random num-
bers from the prior step. Successful validation prompts the
blockchain to proceed to the next step, comparing pHashes
between nodes. Failure leads to rejection of the pHash.
During the prior step, malicious nodes remain unaware
of other nodes’ pHashes until they submit an incorrect com-
mitment on-chain. Even if a malicious node intercepts a
correct pHash from another node during phase 2, it becomes
futile since the incorrect commitment submitted earlier can-
not pass validation with the correct pHash on-chain. This
prevents any subsequent manipulation based on newly in-
tercepted correct data.
4.1.4 Random Number Generation on the Blockchain
The generation of random numbers on the blockchain
stands as a pivotal element crucial to the network’s secu-
rity. Ethereum 2.0 [19] introduces prevrando as a potential
source for random numbers, while other blockchains com-
monly rely on the block hash of the last confirmed block.
More intricate methods, such as Verifiable Random Func-
tions (VRF) [13], also exist, albeit with increased complex-
ity. Yet, within the context of our scenario, none of these
methods alone are deemed sufficiently secure.
An exploitable vulnerability arises concerning result val-
idation efficacy. An attacker could potentially monopolize
multiple nodes and manipulate their selection for a single
task. With two or more of the attacker’s nodes chosen for
a task, fraudulent submission of identical fake results to de-
ceive the blockchain becomes feasible.
In cases where the attacker hosts the blockchain node,
thereby controlling block production, knowledge of the last
block hash, prevrando, or VRF selection precedes confir-
mation of the ”CreateTask” transaction by the subsequent
block. This advance information grants the attacker an op-
portunity to discern if their nodes are chosen for a task,
allowing the rejection of ”CreateTask” transactions where
manipulation is unachievable, i.e., where two or more of
the attacker’s nodes are not selected.
Strategically organizing consecutive blocks, the attacker
gains the ability to influence the selection of nodes for sub-
sequent tasks. It’s essential to note that this manipulation
doesn’t extend to VRF methods wherein randomness origi-
nates outside the blockchain. However, VRF methods intro-
duce their unique risks, outside the scope of this discussion.
Recognizing that executing such an attack necessitates
control over a substantial number of nodes within the entire
network, Crynux H-Net opts to overlook this issue. Instead,
it relies on prevrando for supported blockchains and the last
block hash for others, acknowledging the inherent risks but
deeming them acceptable within its operational framework.
4.1.5 Sequential Node Selection
In scenarios where the attacker lacks direct control over task
selection outcomes, an alternate strategy emerges: when the
attacker’s sole node is selected for a task, honest computa-
tion ensues. However, if two or more of the attacker’s nodes
are selected, legitimate computation is skipped, and fraudu-
lent results are submitted. Unfortunately, the network lacks
mechanisms to detect and counteract this behavior.
The fundamental concept here revolves around prevent-
ing anyone, including a malicious actor, from determining
whether multiple nodes under their control execute the same
task. Concealing selected addresses using Verifiable Ran-
dom Functions (VRF) [5] and obscuring task IDs from se-
lected nodes via Zero-Knowledge Proofs (ZKP) [8] may
seemingly safeguard the process. However, a determined
attacker can still infer if two of their nodes are performing
the same task by scrutinizing task requests.
An alternative avenue, sequential node selection,
presents itself as a solution. In this approach, the blockchain
selects nodes one by one, awaiting each node’s submission
of commitment before proceeding with the next selection
round. When an attacker’s node gets selected to execute
a task, the attacker remains unaware if their nodes will be
chosen again in subsequent rounds, eroding their confidence
in submitting fraudulent results at this stage.
If an attacker’s nodes are selected twice within a single
task, discovering their selection in the second round arrives
too late for submitting fake results since a legitimate com-
mitment was already provided in the preceding round.
While sequential node selection offers a poten-
tial resolution, it significantly elongates task execution
time—approximately tripling it compared to parallel selec-
tion. Similar to the manipulation of random numbers dis-
cussed earlier, executing this attack requires control over a
significant portion of the network, leading Crynux H-Net to
disregard this approach. Instead, it opts for a parallel execu-
tion schema to enhance application usability, prioritizing a
better user experience over the increased security measures
offered by sequential node selection.
8
4.2 Collateral based Penalization
Following the identification of malicious behaviors
through the aforementioned validation framework, the fo-
cus shifts to implementing penalties for these actions.
Penalization operates through requiring nodes to stake a
designated number of tokens on the blockchain upon net-
work entry. In instances where a node engages in malicious
behavior and is identified as such, the staked tokens face
forfeiture.
Failing to penalize malicious behaviors inevitably leads
to a persisting issue of nodes submitting fraudulent results
to the network. Even if these behaviors are detectable and
managed by the blockchain, their existence heightens the
risk of task failures, consequently reducing network effi-
ciency.
Crucially, improper penalization opens avenues for at-
tackers to exploit the system statistically, potentially under-
mining its integrity and security. Therefore, the imposition
of appropriate penalties becomes paramount in safeguard-
ing the network against such attacks.
4.2.1 Probability-Based Attack Strategies
Despite the increased detectability of individual malicious
actions within a single task, attackers retain the ability to
manipulate the system by initiating multiple nodes. Each
of these malicious nodes is focused on a singular goal: dis-
seminating identical fraudulent results across the network.
This strategy maintains the possibility that two or more of
these malicious nodes may be selected for the same task,
ultimately leading to the attacker’s success regardless of the
efficacy of the Blockchain’s validation process.
This successful outcome for the attacker hinges on the
probability of occurrence. Even with penalties for mali-
cious behavior, a high probability of success provides at-
tackers with a profitable opportunity to exploit the system.
4.2.2 Expected Gain Analysis
The probability of a successful attack, defined as the like-
lihood of the attacker having more than two of its nodes
selected for a task, can be expressed as:
p(h, d) = C2
d∗C1
h+C3
d
C3
d+h
where hrepresents the count of honest nodes, and dis
the number of malicious nodes owned by the attacker.
The anticipated profit from cheating is calculated as:
E=p∗k−(1 −p)∗s
where kdenotes the task price in tokens, and srepresents
the number of staked tokens for a node.
Increasing the staked tokens scan reduce the expectation
Eto zero or even below. If Efalls below zero, attacking the
system by spawning more false nodes becomes financially
unviable. Such an attack would likely lead to financial loss
rather than gain for the attacker.
Network safety is contingent upon the calculated value
of the staked tokens s. Given the network size (total node
count) and a targeted ratio of malicious nodes considered
safe for the network, the probability of a successful attack
pis established. By setting Eto zero, the requisite staked
tokens for a single node scan be determined through the
formula:
s=p∗k
1−p
4.3 Task Error and Timeout
The network’s architecture as a loosely coupled peer-
to-peer (P2P) network, encompassing home computers and
even laptops, precludes any reliance on node reliability.
Nodes can lose network connectivity abruptly, remaining
marked as available or in the process of task execution on
the blockchain.
Similarly, Crynux dApps aren’t inherently dependable
either. Tasks initiated by Crynux dApps might encounter
issues rendering them unexecutable, such as mismatched
combinations like an SD1.5 base model paired with a SDXL
LoRA model.
4.3.1 Task Error Reporting
When a node encounters an irrecoverable exception dur-
ing task execution, it promptly reports this error to the
blockchain. This error report assumes the standard format
of a task result on the blockchain. Should more than two
nodes report an error for the same task, the task is termi-
nated. Additionally, if a node reports an error while the
remaining two nodes provide correct computation results,
the errant node faces token slashing.
While Crynux H-Net permits model downloads from ex-
ternal links, network issues during model downloads can
pose challenges. Differentiating whether these issues affect
all three nodes uniformly or represent temporary glitches
remains challenging.
To prevent the inadvertent penalization of honest nodes,
error reporting should only occur when a node is absolutely
certain that the error lies within the task requests and not due
to network issues. Other cases should be managed through
the timeout mechanism.
If the task is aborted due to error reporting, the tokens
will not be returned to the Crynux dApp, since the Crynux
Nodes have already spend some resources on the task, and
it is the Crynux dApp to blame for the task error.
9
In the event of task termination due to error reporting,
tokens will not be returned to the Crynux dApp. This de-
cision is based on the resources already expended by the
Crynux Nodes for the task, with accountability for the task
error attributed to the Crynux dApp.
4.3.2 Time Cancellation on Timeout
In compliance with the consensus protocol, commitments
from all three nodes are required. However, if a selected
node becomes inactive before submitting its commitment
to the blockchain, the remaining two nodes, alongside the
associated Crynux dApps, encounter an indefinite waiting
period, causing significant disruption.
To address this issue, a timeout mechanism is introduced.
After a predefined duration, all three nodes and the as-
sociated dApps are permitted to submit a cancellation re-
quest for the task on the blockchain. Upon submission,
the blockchain promptly aborts the task, alleviating the pro-
longed wait.
4.3.3 Evaluating Potential Gains through Timeout-
Based Attacks
The introduction of the timeout mechanism introduces a
new vulnerability into the network. An attacker, initiating
multiple Crynux Nodes, strategically waits for the timeout
when they realize that no more than two of their nodes are
selected for a task. This tactic aims to evade penalization
and enables the submission of fraudulent results in other in-
stances.
Distinguishing between intended offline actions and ac-
cidental ones is challenging. Technically, eliminating this
behavior isn’t feasible as long as the timeout mechanism
persists. However, we can limit the intention behind such
actions through economic means.
By regulating the duration of the timeout period, we can
restrict the maximum number of tasks a malicious node
could undertake within a specific timeframe.
Given a fixed probability pof a successful attack, and as-
suming a timeout period tin seconds, considering the total
number of tasks a malicious node could perform in a day n,
the equation is:
ˆ
t∗n∗p+t∗n∗(1 −p) = 86400
Here, ˆ
tdenotes the estimated time required for a regular
task execution. The maximum number of successful mali-
cious tasks nma node could engage in a day is then:
nm=n∗p=86400 ∗p
ˆ
t∗p+t∗(1 −p)
The total income an attacker could gain in a day, by
launching dnodes, is:
Imax(p, t) = nm∗k∗d=86400 ∗p∗k∗d
ˆ
t∗p+t∗(1 −p)
where krepresents the price of a single task, and dis the
number of malicious nodes the attacker starts to achieve the
probability p.
Each of the dnodes the attacker initiates necessitates
staking stokens. Therefore, the total stake for one day for
the attacker is:
T(p) = s∗d=p∗k∗d
1−p
The income can be interpreted as the interest accrued
from staking tokens for a day. Consequently, the daily in-
terest rate is:
IRmax(p, t) = Imax (p, t)
T(p)=86400 ∗(1 −p)
ˆ
t∗p+t∗(1 −p)
Increasing the timeout period tdiminishes the interest
rate, potentially making it unappealing for anyone to pur-
sue.
4.3.4 Increase staking for Timeout Reduction
Extending the timeout duration results in a decreased inter-
est rate, enhancing network security at the expense of pro-
longed waiting periods for applications and honest nodes.
To further curtail the timeout period, an increase in the
stipulated staking amount can be implemented. Let’s intro-
duce a value denoted as st, an addition to the staking re-
quirement. Consequently, the total tokens the attacker must
stake within a day would be:
T(p)=(s+st)∗d=p∗k∗d
1−p+st∗d
By strategically selecting an appropriate value for st, a
balance can be achieved between the risk of attacks and the
network’s operational efficiency.
4.3.5 Conllusion among Attackers
For an increased likelihood of success, control over ma-
licious nodes typically remains centralized under a single
attacker. Collaboration between two attackers to orches-
trate a timeout attack proves challenging. Such an attack
necessitates one attacker to accurately ascertain whether a
selected node belongs to another attacker or is indeed an
honest node, crucial for synchronizing fake results. To err
on the side of caution, assuming the node is honest becomes
the safer choice.
10
Interestingly, this scenario brings positive implications.
Malicious Crynux Nodes belonging to one attacker might
be used to validate another attacker. Consequently, the
probability of a successful attack diminishes as the number
of attackers escalates.
Below presents calculated statistics considering various
network sizes and malicious Crynux Nodes:
Given the following settings:
Task price 3 CNX
Estimated exeuction time of a task 60 sec
Timeout perioud 300 sec
Num of staking for timeout attack 5,000 CNS
Table 1: Settings of the example Crynux H-Net
The stipulated staking requirements and the correspond-
ing annual interest rates (IR) are displayed below, assuming
all malicious Crynux Nodes pertain to a single attacker:
The figure demonstrates that when the network expands
to 10,000 total nodes, with a 5-minute timeout requirement
and necessitating 5,000 CNX staking, the network’s secu-
rity prevails as long as an attacker initiates no more than
300 nodes, entailing a cost of 1,500,000 CNX tokens.
However, achieving the displayed interest rates relies on
the network operating at maximum capacity, implying every
node engaging in continuous task execution without idle pe-
riods. The interest rate is subject to decline when tasks are
not consistently executed across the network.
5 Crynux dApp
Crynux dApps leverage the Crynux H-Net as an infras-
tructure service by sending AI model inference tasks to
Crynux H-Net, and retrieving results back.
Within Crynux H-Net, Crynux dApps interact with
blockchain nodes via smart contracts, and retrieve data from
the Relay.
Outlined below is the high-level workflow represented in
the sequential graph:
5.1 Develop Paradigm
Developing a Crynux dApp can follow these steps:
1. The task initiation process commences on the
Blockchain. To create the task on-chain, the Crynux
dApp requires a wallet containing sufficient CNX to-
kens to cover task execution costs and a small amount
of ETH for gas fees.
2. The Crynux dApp triggers the workflow by invoking
the ”CreateTask” method of the smart contract using
the prepared wallet. The method receives the hash of
the task requests, utilized by the Crynux Nodes to au-
thenticate the actual task requests relayed from the Re-
lay.
3. The smart contract transfers the required CNX tokens
from the Crynux dApp wallet to its address. These
tokens are held until the task’s completion, returning
to the Crynux dApp wallet if the task isn’t successfully
finalized.
4. The smart contract randomly selects three nodes and
emits three ”TaskCreated” events (each featuring a dis-
tinct node address) to alert the Crynux Nodes about the
task.
5. Following the on-chain transaction confirmation, the
Crynux dApp dispatches the authentic task requests to
the Relay.
6. The Crynxu dApp awaits the ”TaskSuccess” event
from the blockchain. Upon receipt, the Crynux dApp
retrieves the results from the Relay, signifying the
completion of the task workflow.
It’s important to note that the Crynux dApp is not re-
quired to validate the result since the Relay has already per-
formed this verification process.
5.1.1 Wallet Preparation
A compatible Ethereum wallet must be generated to fa-
cilitate Crynux dApp interactions with smart contracts on-
chain. This wallet serves as the conduit for invoking smart
contracts.
To enable seamless task execution, the wallet must con-
tain an adequate reserve of CNX tokens to cover task
costs. Continuous monitoring of the wallet’s balance by the
Crynux dApp is imperative.
Additionally, ETH tokens must be available in the wallet
to cover transaction gas fees.
Upon invocation of the ”CreateTask” method from the
Crynux dApp to the Task Contract, a specific amount of
CNX tokens is transferred to the Task Contract’s address.
This transfer ensures that Nodes are assured of payment
upon task completion.
To enable this transfer, the Task Contract must be au-
thorized to utilize CNX tokens from the Crynux dApp wal-
let. As CNX is a standard ERC20 token, this authorization
process involves invoking the Approve method of the CNX
Token Contract from the Crynux dApp wallet. The Task
Contract’s address is provided during this approval process.
For scenarios where the Crynux dApp anticipates fre-
quent task creation, approving a larger quantity of tokens
in a single authorization transaction can be advantageous
11
# Honest
Nodes
# Malicious
Nodes
# staking
for timeout
# staking
total
Annual IR
(%)
7 3 15,000 15,000.67 451.67
70 3 15,000 15,000.01 7.15
700 30 150,000 150,000.14 10.09
7000 30 150,000 150,000.00 0.11
9970 30 150,000 150,000.00 0.05
9900 100 500,000 500,000.03 0.62
9700 300 1,500,000 1,500,000.80 5.56
9500 500 2,500,000 2,500,003.65 15.30
Table 2: Staking required and corresponding IR on different size of network
to minimize gas fees. This approach remains secure as the
Task Contract’s functionalities are rigidly hardcoded, limit-
ing its capabilities exclusively to defined behaviors.
5.1.2 Task Creation
Once the JSON string containing the task arguments is pre-
pared, the Crynux dApp initiates the ”CreateTask” transac-
tion on the Blockchain.
The ”CreateTask” method within the Task Contract in-
volves two arguments:
• taskHash: This represents the keccak256 hash of the
JSON string containing the task arguments.
• dataHash: Reserved for potential future functionali-
ties and currently remains unused. The application can
pass 32 zero bytes as a placeholder.
Upon sending the transaction, the Crynux dApp should
retrieve the creation result before proceeding. Blockchain
reversion might occur due to various reasons, such as insuf-
ficient CNX tokens in the Crynux dApp wallet.
A thorough enumeration of potential reasons for transac-
tion reversion can be found in the source code. If a trans-
action is reverted, no corresponding event will be emitted.
Therefore, querying the creation result becomes possible
only through the transaction hash or the receipt from the
transaction creation.
Once the task creation transaction is confirmed, the sub-
sequent step involves uploading the actual JSON string of
the task requests to the Relay.
The Relay actively monitors the blockchain for all task
creations. When the ”TaskCreated” event is emitted on-
chain, the Relay records both the task ID and the address
of the task creator (i.e., the Crynux dApp wallet). the Relay
necessitates that the task request originates from the same
task creator identified on-chain.
The signature generation entails utilizing ECDSA with
the same curve as Ethereum. This process involves the Kec-
cak256 hash of a string generated by including all query and
body parameters (excluding timestamp and signature) in a
JSON string. These parameters are alphabetically sorted
and concatenated with the current Unix timestamp.
5.1.3 Waiting for Results
Upon completion of the task, the blockchain emits either the
”TaskSuccess” or ”TaskAborted” event. If ”TaskSuccess” is
emitted, the Crynux dApp gains access to results from the
Relay. Conversely, ”TaskAborted” denotes task failure.
Similar to task creation, various reasons might trigger
task failure during execution. This could stem from task ar-
gument schema mismatches, improper consensus protocol
execution by Nodes, or extended task duration on a single
Node. The specific reason for failure is detailed within the
emitted event.
In case of task abortion, CNX tokens might be returned
to the Crynux dApp wallet based on the culpability for
task failure. This decision determines whether the Crynux
Nodes receive payment despite task incompletion.
Crynux dApps can monitor relevant Blockchain events
using two methods. The first involves continuous tracking
of new blocks and filtering for ”TaskSuccess” and ”Task-
Aborted” events. This method demands meticulous han-
dling of block continuity, especially in the event of appli-
cation crashes or prolonged inactivity, which might cause
delays in keeping pace with new blocks.
The alternative method entails extracting the task ID
from the task creation transaction, saving it, and periodi-
cally querying the Blockchain for the latest task status. Un-
like the tracking approach, this method obviates the need
for ongoing block tracking. However, its efficiency is com-
paratively lower due to the increased number of potentially
irrelevant queries.
The final step involves retrieving results from the Relay.
Similar to previous interactions, this step necessitates sig-
nature and timestamp inclusion. The URL serves as a direct
binary stream link to access the results.
12
5.2 Image Generator
Crynux H-Net serves as the backbone infrastructure for
Crynux dApps, and one such application is the Image
Generator (accessible at https://ig.crynux.ai). This web-
based interface empowers users to create images within
their browsers, bridging the gap for devices lacking capa-
ble GPUs. Accessibility is extended to all users through
browser compatibility.
Users leverage Image Generator’s interface to select dif-
ferent models, generating images via prompts. Supported
models include SD1.5 and SDXL. Furthermore, users can
incorporate LoRA models from Civitai, enhancing base
models to create stylized images. The application also sup-
ports OpenPose ControlNet for character image generation.
A fundamental distinction from traditional web applica-
tions lies in the task execution method. In Crynux dApp,
tasks are initiated on the blockchain and computed by dis-
tributed nodes, as opposed to being serviced by a central-
ized server. Image verification through blockchain consen-
sus ensures authenticity and prevents fraudulent image gen-
eration.
The blockchain maintains a roster of available Crynux
Nodes. When a user generates an image via Image Genera-
tor, a task is transmitted to the blockchain, which randomly
selects three Crynux Nodes from the network roster to exe-
cute the task.
These chosen Crynux Nodes locally process the task.
Upon completion, each Crynux Node publishes a similar-
ity score on the blockchain. This data is compared to detect
any node attempting to evade computation by submitting ar-
bitrary scores to conserve local resources. Validated correct
results trigger the return of images to the application, and
nodes receive their compensation.
The process of image generation begins with user input
within Image Generator’s interface (Figure 7a). Upon se-
lecting base and LoRA models and clicking ”Generate Im-
age,” a modal popup displays the task’s progress. This task
is then confirmed on the Blockchain, with event logs view-
able in the block explorer (Figure 7c). As the task executes,
the Crynux Node’s WebUI reflects its status transition from
”idle” to ”executing” (Figure 7b).
Further node logs (Figure 7d) and additional event logs
in the block explorer signal the completion of local exe-
cution and the initiation of the consensus protocol on the
Blockchain. Successful task completion presents the gen-
erated images in Image Generator, while the Crynux Node
returns to an idle status, accompanied by a 10-token incre-
ment in the wallet.
The most important thing in the decentralized network
is the consensus protocol, which ensures that all the nodes
are behaving honestly. Since beside the rules defined in the
consensus protocol, there is nothing else to control what a
node can do. They join and quit the network freely. Nobody
knows who they are and where they are. They will try to
exploit all the vulnerabilities in the consensus protocol to
get more tokens at lower cost.
6 Discussion
Crynux H-Net stands as an innovative and secure plat-
form driving decentralized AI inference on the blockchain.
This framework adeptly tackles the core obstacles of trust,
fairness, and transparency inherent in decentralized AI
computing. Its architectural design not only ensures the ef-
ficient execution of AI tasks but also incentivizes integrity
among participants while fortifying defenses against mali-
cious entities. This pioneering approach heralds a future of
heightened security and decentralization across diverse sec-
tors, laying the groundwork for expansive AI applications.
A standout feature of Crynux H-Net lies in its emphasis
on verifiable computation and incentivized honesty, man-
ifested through a robust consensus protocol. The integra-
tion of dual-phase pHash disclosure and sequential node
selection mechanisms effectively shields against manipu-
lation attempts. Additionally, collateral-based penalization
serves as a potent deterrent against fraudulent behavior, re-
inforcing the network’s commitment to security, engender-
ing trust, and fostering widespread adoption, particularly
within sensitive applications.
Nonetheless, the journey towards complete decentral-
ized AI is replete with challenges, notably pertaining to de-
centralized model training and hosting, preserving privacy
in training data, and implementing zero-knowledge proofs.
The ongoing evolution of the Crynux Network in future
releases remains pivotal, necessitating continuous research
and development efforts. These endeavors are fundamental
in refining the network’s capabilities to ensure result trust-
worthiness and cultivate a secure and reliable ecosystem for
decentralized AI applications.
References
[1] D. Acemoglu. Harms of ai. Technical report, National
Bureau of Economic Research, 2021.
[2] N. S. Bitcoin. Bitcoin: A peer-to-peer electronic cash
system, 2008.
[3] E. Brynjolfsson and A. Ng. Big ai can central-
ize decision-making and power, and that’sa problem.
MISSING LINKS IN AI GOVERNANCE, page 65,
2023.
[4] R. Craib, G. Bradway, X. Dunn, and J. Krug. Nu-
meraire: A cryptographic token for coordinating ma-
13
(a) Image Generator dApp (b) WebUI of Crynux Node
(c) Blockchain Explorer (d) Crynux Node logs
Figure 7: Crynux dApp: Image Generator
14
chine intelligence and preventing overfitting. Re-
trieved, 23:2018, 2017.
[5] Y. Dodis. Efficient construction of (distributed) ver-
ifiable random functions. In Public Key Cryptog-
raphy—PKC 2003: 6th International Workshop on
Practice and Theory in Public Key Cryptography Mi-
ami, FL, USA, January 6–8, 2003 Proceedings 6,
pages 1–17. Springer, 2002.
[6] L. Du, A. T. Ho, and R. Cong. Perceptual hashing for
image authentication: A survey. Signal Processing:
Image Communication, 81:115713, 2020.
[7] C. Dwork. Differential privacy. In International col-
loquium on automata, languages, and programming,
pages 1–12. Springer, 2006.
[8] U. Fiege, A. Fiat, and A. Shamir. Zero knowledge
proofs of identity. In Proceedings of the nineteenth an-
nual ACM symposium on Theory of computing, pages
210–217, 1987.
[9] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li,
S. Wang, L. Wang, and W. Chen. Lora: Low-rank
adaptation of large language models. arXiv preprint
arXiv:2106.09685, 2021.
[10] J. Koneˇ
cn`
y, H. B. McMahan, F. X. Yu, P. Richt´
arik,
A. T. Suresh, and D. Bacon. Federated learning:
Strategies for improving communication efficiency.
arXiv preprint arXiv:1610.05492, 2016.
[11] V. Lopes and L. A. Alexandre. An overview of
blockchain integration with robotics and artificial in-
telligence. arXiv preprint arXiv:1810.00329, 2018.
[12] S. McKeown and W. J. Buchanan. Hamming distribu-
tions of popular perceptual hashing techniques. Foren-
sic Science International: Digital Investigation, 44:
301509, 2023.
[13] S. Micali, M. Rabin, and S. Vadhan. Verifiable ran-
dom functions. In 40th annual symposium on foun-
dations of computer science (cat. No. 99CB37039),
pages 120–130. IEEE, 1999.
[14] Y. Qu, M. P. Uddin, C. Gan, Y. Xiang, L. Gao, and
J. Yearwood. Blockchain-enabled federated learning:
A survey. ACM Computing Surveys, 55(4):1–35, 2022.
[15] SingularityNet. Singularitynet: White paper: Sin-
gularitynet: A decentralized, open market and inter-
network for ais. tech. rep, 2017.
[16] N. A. Team. Nebula ai (nbai)—decentralized ai
blockchain whitepaper, 2018.
[17] S. Teerapittayanon and H. Kung. Daimon: A de-
centralized artificial intelligence model network. In
2019 IEEE International Conference on Blockchain
(Blockchain), pages 132–139. IEEE, 2019.
[18] I. Weber, V. Gramoli, A. Ponomarev, M. Staples,
R. Holz, A. B. Tran, and P. Rimba. On availability for
blockchain-based systems. In 2017 IEEE 36th Sympo-
sium on Reliable Distributed Systems (SRDS), pages
64–73. IEEE, 2017.
[19] G. Wood et al. Ethereum: A secure decentralised gen-
eralised transaction ledger. Ethereum project yellow
paper, 151(2014):1–32, 2014.
15
