Protocol Usage

Deep learning computational work passes through a total of eight stages in the Gensyn network in which the network participants perform different tasks. 

Let’s take a look at these tasks.

Submitters are the end users of Gensyn and submit ML tasks to the network. To do so. Submitters specify the details of a given task in a machine-readable format and then submit the task to the blockchain. The submission includes pre-processed training data as well as the model binary’s publicly accessible location. Object stores such as Amazon S3 but also decentralized storage providers like IPFS or Arweave can be used to store the publicly available data. 

Submitted tasks contain the following information:

Secure mapping layers can be used to construct the deep learning models to ensure privacy preservation. Additionally, the encryption of the publicly accessible training data is possible. 

When a Submitter creates a task, the required workload is estimated. The estimate is generated by first constructing and then unrolling a computational graph into the required computational operations.

A mechanism similar to Ethereum's Opcode gas values is used to calculate an estimate of the required computational work. 

The work estimate is used to calculate the transaction fee a Submitter needs to pay for submitting ML work. Excesses not used by the network are later on returned after the computation has ended.

Network parameters define the smallest quantity of ML work that Submitters can push to the blockchain in the form of a task. Submitters wishing to compute larger sets of deep learning workloads can split the work into tasks and push these asynchronously to the network. This allows Gensyn to train large-scale language models and other deep learning models. 

Verifiers periodically grab profiling tasks so that a variation threshold can be generated which is then used for proof-of-learning comparisons. Doing so allows establishing a baseline distance threshold in the proof-of-learning verification. 

Verifiers deterministically run and re-run parts of the training to generate a threshold with different random seeds to generate proofs and to check these again.

The process of running and rerunning portions of the training allows Verifiers to aggregate expected distance thresholds which are later on used to validate the non-deterministic output of the Solvers.

Whistleblowers re-run the profiling work of Verifiers and challenge them if the verification work is incorrect. To accomplish this, contract arbitration mechanisms and a graph-based pinpoint challenge are used.

A submitted task enters the common task pool after profiling. The common task pool is similar to Ethereum’s mempool. The task is removed from the pool once a single Solver has been selected. 

The computation is then performed on the Submitter’s model and training data based on the defined metadata. 

Solvers create a proof-of-learning at scheduled intervals and also store metadata from the training process. Doing so allows Verifiers to replicate the results as accurately as possible.

Solvers store model weights and indices from the training dataset periodically. This is done to identify which samples were used for generating the weight updates. By “stacking” proofs, the protocol aggregates a set of pre-trained and already proven base models. These base models can then be used for more specific tasks. 

The completion of the ML task is then registered by Solvers that make the proof-of-learning publicly accessible on the blockchain. The verification tasks are then added to the task pool from where they are picked up by Verifiers. Portions of the proof are re-run by Verifiers performing the computational work and distance calculations. 

The blockchain then uses the resulting distances to evaluate if the verification matches the submitted proof. 

Whistleblowers can randomly replicate the work of Verifiers to determine if the verification work was performed correctly. In the case of incorrect verification, Whistleblowers can challenge Verifiers to contract arbitration. 

Rewards for the arbitration process either come from Solver and Verifier deposits (in case of a true positive) or the jackpot treasury (for false positives).

Based on game theory and the chosen incentive mechanism, Whistleblowers will only choose to challenge work if they expect an appropriate compensation. The Gensyn protool calculates rewards based on the number of active Whistleblowers in one network. 

For this reason, the expected default strategy of Whistleblowers will be to join networks with a low number of Whistleblowers. They will then make a deposit, randomly pick an active task, and start the verification process.

This process is repeated until the number of other Whistleblowers in the network rises above their defined payout threshold. Once this happens, Whistleblowers may leave the network or perform other roles in the network, for example as Solver and Verifier. 

The process of contract arbitration is initiated by identifying the location of a disputed operation. The blockchain will then perform the final basic compute operation to determine if the Whistleblowers challenge was justified. 

Periodic forced errors with jackpot payouts are introduced by the protocol to help in maintaining the honesty of the Whistleblowers and to overcome the verifier’s dilemma. 

Participants are paid based on the results of the deterministic and probabilistic checks. Both the Solver and Verifier are rewarded if the work passes all checks, ensuring that the work has been performed correctly.