bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 16쪽 중 15쪽
;
* **Why:** The assistant starts from a baseline model and calibrates using your early episodes. Initial adjustments on the model's side can be dramatic.
* **How to fix:** Continue recording and training on at least *five episodes* before expecting stable improvements and a more accurate outputting from your model. 
***
### When to Report an Issue
If you’ve tried the above steps and the problem persists:
* Collect your terminal output and Docker logs
* Include the CodeAssist version (`git rev-parse HEAD` in your repo)
* [Open a GitHub issue here](https://github.com/gensyn-ai/codeassist/issues) or share logs in the `#codeassist-support` channel on the [Gensyn Discord](https://discord.gg/gensyn)
{% hint style="success" %}
If you need additional support, you can [open a ticket](https://github.com/gensyn-ai/codeassist/issues) or [visit our Discord.](https://discord.com/invite/gensyn) 
{% endhint %}
# Litepaper
The hyperscale, cost-efficient compute protocol for the world’s deep learning models
{% hint style="info" %}
***Published February 2022***
**Please note that this version of the Litepaper is out-of-date.** The Gensyn team have made multiple changes to the protocol design, including but not limited to:
1. Replacing the Substrate L1 chain build (and associated canarynet / mainnet functionality) with a custom Ethereum rollup, following significant advancements in our off-chain infrastructure. Note: we also no longer use Rust in our stack.
2. A more robust audit strategy for checking work
3. Introducing a cryptographic proof system to dynamically monitor training
4. Stronger game theoretic guarantees
5. A novel proof of availability system for proof guarantees
6. An ML compiler and reproducible ML runtime
This [research will be published separately](https://www.gensyn.ai/research), but please use this Litepaper as introduction to the problem + solution vectors.
{% endhint %}
## Background
The computational [complexity](https://arxiv.org/pdf/2007.05558.pdf) of state-of-the-art Artificial Intelligence (AI) systems is [doubling every 3 months](https://openai.com/blog/ai-and-compute/), vastly outstripping compute supply. As a founding team--whether we've been publishing research into the evolution of deep neural architectures or building hurricane damage prediction models--we've experienced these limits first hand.
GPT-3 175B, the largest GPT-3 model proposed by OpenAI in [Brown et al. (2020)](https://arxiv.org/abs/2005.14165) used a cluster of 1,000 NVIDIA Tesla V100 GPUs for training - roughly equivalent to 355 years of training on a single device. DALL-E from [Ramesh et al. (2021)](https://arxiv.org/abs/2102.12092), another Transformer model from OpenAI, has 12 billion parameters and was trained on over 400 million captioned images. OpenAI bore the cost of training DALL-E but controversially refused to open source the model, meaning that perhaps one of the most important state-of-the-art multimodal deep learning models remains inaccessible to all but a select few. The huge resource requirements for building these [foundation models](https://arxiv.org/abs/2108.07258) create significant barriers to access, and, without a method to pool resources whilst still capturing value, will likely cause stagnation in AI advancement. Many believe that these generalised models are the key to unlocking Artificial General Intelligence (AGI), making the current method of training in isolated, artificial silos seem absurd.
Current solutions which provide access to compute supply are either [oligopolistic and expensive](https://www.cnbc.com/2021/09/05/how-amazon-web-services-makes-money-estimated-margins-by-service.html#:~:text=Bernstein%27s%20analysts%20estimated%20that%20in,a%2061%25%20gross%20margin%20overall.) or simply [unworkable](https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf) given the complexity of compute required for large-scale AI. Meeting the ballooning demand requires a system which cost-efficiently leverages *all* available compute (as opposed to today’s \~40% global processor utilisation). Compounding this problem right now is the fact that the compute supply itself is hamstrung by [asymptotic](https://github.com/karlrupp/microprocessor-trend-data) advances in microprocessor performance - alongside [supply chain](https://www.theguardian.com/business/2021/mar/21/global-shortage-in-computer-chips-reaches-crisis-point) and [geopolitical](https://www.scmp.com/tech/big-tech/article/3129710/tsmc-chief-blames-geopolitical-tensions-chip-shortage-plays-down) chip shortages.
We’ve spoken with more than 150 CTOs, machine learning (ML) researchers, and ML engineers who consistently describe the painful trade-off between purchasing their own hardware and sacrificing scalability, or renting scalable cloud resources for vastly increased costs. They recognise that cloud costs are typically inflated by provider profit margins and often wonder why on-demand, serverless-style compute doesn’t exist for their ML work.
Voluntary grid computing services like [SETI@Home](https://setiathome.berkaeeley.edu), [Folding@Home](https://foldingathome.org/), and [BOINC](https://boinc.berkeley.edu/) demonstrate that trustless, voluntarily-networked, latent compute can be used to solve some of humanity’s biggest problems. However, they predominantly solve [embarrassingly parallel](https://books.google.co.uk/books?id=vfvPrSz7R7QC\&q=embarrasingly\&redir_esc=y#v=onepage\&q=embarrasingly\&f=false) problems such as 3D rendering, where computational work can be trivially split and verified owing to its state independence. ML problems (besides niche tasks like hyperparameter optimisation) are inherently state dependent, requiring new methods for both parallelisation and verification. Volunteer networks also function only by modelling participants as rational actors in a philanthropic system; adding financial transactions drastically changes the incentive mechanisms and introduces the spectre of exploitation.
Decentralised blockchain protocols extend the concept of grid computing into financially-incentivised, trustless environments. Specifically, [Ethereum](https://ethereum.org/en/whitepaper/) moved the space beyond the transaction use-cases of [Bitcoin](https://bitcoin.org/en/bitcoin-paper) to more general on-chain computational work. This was achieved by incorporating a Turing-complete language (Solidity) and rewarding compute providers through variable gas fees. 
Ethereum, however, achieves trustless consensus only via extremely expensive on-chain replication of work. This is completely unsuitable for deep learning. Training a small MNIST neural network (\~400M processor operations) takes \~8 minutes on an average laptop but would take \~80 days on Ethereum at a cost of approximately $32m. To address this, [Truebit](https://arxiv.org/abs/1908.04756) showed that it's possible to perform simple computational work off-chain (and thus with less overhead) and prove to the chain that it was performed correctly. They achieved this by modelling participants as financially-rational actors and carefully constructing incentive structures. Specifically, they solved the [verifier's dilemma](https://dl.acm.org/doi/abs/10.1145/2810103.2813659) by intermittently requiring workers to produce incorrect work and awarding verifiers with a jackpot if they spot it.
Despite these improvements, the work must still be replicated off-chain. This is unsuitable for activities with extreme computational expense (e.g. deep learning), and a cost-efficient off-chain compute system must exist if deep learning work is to be serviced in a trustless way.
## Problem
A protocol which trustlessly connects and verifies off-chain deep learning work in a cost efficient way has five main challenges.
### Work verification
In order to build a truly trustless compute network, with economic incentives for participation, the network must have a way to verify that deep learning computational work has actually been performed as promised. Central to this problem is the state dependency of deep learning models; that is, each subsequent layer in a deep learning model takes as an input the output of the previous layer. Therefore, to validate work has been completed at a specific point, all work up to and including that point must be performed. We’ll cover this in more detail later but it’s a fundamental problem that until now has had no viable solutions.
### Market
A marketplace for compute is subject to the same supply and demand issues that any new marketplace faces, with a few unique challenges too. Principally there is a cold-start issue, where supply and demand liquidity need to roughly match from the beginning in order to grow successfully. In order to capture latent compute supply, there must be a clear reward for participants to pledge their compute time. Computational work must be tracked and proportional payments made to the providers in a timely manner. For more traditional marketplaces, this is performed using intermediaries which handle administration and onboarding, with minimum payouts to reduce overheads. Unfortunately, this approach becomes costly to scale and results in a threshold equilibrium where only a small portion of the supply can be economically captured.
### Ex-ante work estimation
Similar to Ethereum, ML computational work is subject to the [halting problem](https://arxiv.org/abs/1901.03429) - where it is at times impossible to quantify the amount of computational work required by a defined task and more specifically whether it will ever end (or halt). In the context of deep learning, this has become more significant relatively recently as models and frameworks have switched from static graph construction to dynamic construction and execution.
### Privacy
With the growth of stronger personal privacy regulations around the world (e.g. [GDPR](https://gdpr.eu/tag/gdpr/), [CCPA](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.\&part=4.\&lawCode=CIV\&title=1.81.5), [LGPD](https://iapp.org/media/pdf/resource_center/Brazilian_General_Data_Protection_Law.pdf)), privacy-conscious design and development has become an expected practice for organisations. Whilst large amounts of ML research can be performed on open datasets, final model fine-tuning often uses proprietary user data. More specifically, in our interviews with ML engineers and CTOs, they indicated that data privacy was orders of magnitude more important than model privacy.
### Parallelisation
State of the art deep learning models are typically trained in parallel over large clusters of hardware in order to access scale that is unachievable with a single device. The techniques required to achieve this parallelisation have improved drastically through recent research, with current state-of-the-art transformer models like Switch Transformers proposed by [Fedus, Zoph, and Shazeer (2021)](https://arxiv.org/abs/2101.03961) now inherently highly parallelised by nature. Combining the performance requirements of the ML work with the untrusted and unreliable nature of the compute sources means that a high degree of parallelisation is essential in any solution.
## Solution
### Gensyn Protocol
The Gensyn Protocol is a layer-1 trustless protocol for deep learning computation that directly and immediately rewards supply-side participants for pledging their compute time to the network and performing ML tasks. The protocol requires no administrative overseer or legal enforcement, rather facilitating task distribution and payments programmatically through smart contracts. As described above, the fundamental challenge in building this network is the verification of completed ML work. This is a highly complex problem that sits at the intersection of complexity theory, game theory, cryptography, and optimisation.
A simple solution is to check the honesty of workers by re-doing their work. At a bare minimum, this requires a doubling of the operations required ('single replication'); however, even with replication, the issue of trust remains unless the verifying party is the actual requestor of the work (in which case, they wouldn't request the work as they'd simply perform it themselves). Therefore, ensuring the honesty of the verifying party can generate an infinite chain of replication, where each new verifier is required to check the work of the previous verifier.
We solve this verification problem by interlocking three key concepts into a robust solution that is $$\gt 1,350 %$$more efficient than existing best-practice replication methods; in doing so, it solves the infinite-chain problem. The key concepts are:
#### Probabilistic proof-of-learning
Following [Jia et al. (2021)](https://arxiv.org/abs/2103.05633), we use the metadata from gradient-based optimisation processes to construct certificates of work performed, which can be verified quickly through replication of certain stages.
#### Graph-based pinpoint protocol
Following [Zheng et al. (2021)](https://arxiv.org/abs/2105.04919), we use a multi-granular, graph-based pinpoint protocol and cross-evaluator consistent execution to allow verification work to be re-run and compared for consistency, and ultimately confirmed by the chain itself.
#### Truebit-style incentive game
Following [Teutsch and Reitwießner (2019)](https://arxiv.org/abs/1908.04756), we use staking and slashing to construct an incentive game ensuring each financially-rational participant behaves honestly and performs their intended tasks.
### Participants
These concepts are used to construct a system with four main participants: Submitters, Solvers, Verifiers, and Whistleblowers.
#### Submitters
Submitters are the end-users of the system, providing tasks that will be computed and paying for units of work completed.
#### Solvers
Solvers are the main workers of the system, performing the model training and generating proofs to be checked by Verifiers.
#### Verifiers 
Verifiers are key to linking the non-deterministic training process to a deterministic linear computation, replicating portions of the Solvers’ proofs and comparing distances with expected thresholds. 
#### Whistleblowers
Whistleblowers are the final line of defence, checking Verifiers’ work and challenging in the hope of receiving a jackpot payout.
### Usage
Typical protocol usage will pass through eight stages, with the above roles performing specific tasks.
#### Task Submission 
Tasks take the form of three specific pieces of information:
1. Metadata describing the task and hyperparameters;
2. A model binary (or skeleton architecture); and
3. Publicly accessible, pre-processed training data.
In order to submit a task, Submitters specify the details of the task in a machine-readable format and submit these to the chain along with the publicly accessible locations of the model binary (or machine-readable architecture) and pre-processed training data. The publicly available data could be stored in a simple object store such as [Amazon’s S3](https://aws.amazon.com/s3/) or in a decentralised store like [IPFS](https://ipfs.io/), [Arweave](https://www.arweave.org/), or [Subspace](https://subspace.network/).
For privacy-preservation, models can be constructed using secure mapping layers (a form of functional encryption) as proposed by [Lan, Liu, and Li (2020)](https://arxiv.org/abs/2007.15145) and the publicly accessible training data encrypted. In this way, models can be trained on ciphertext with a small accuracy penalty ($$\lt0.5%$$).
When submitting a task, an estimate of required work is generated by constructing and unrolling a computational graph into the required operations. These operations are weighted using values similar to [Ethereum's Opcode gas values](https://ethereum.org/pt/developers/docs/evm/opcodes/) in order to calculate a rough sum of computational work to be performed. The transaction fee paid by the Submitter can then use this estimate, with any excess (e.g. due to pessimistic profiling) returned to the Submitter after computation. Crucially, unrolling the graph requires set limits to be placed on logic which can trigger the halting problem. 
Tasks form the smallest quantity of ML work that can be pushed to the protocol. Using parallelisation, larger computational workloads can be split into sets of tasks and pushed to the network asynchronously. Using this approach, large-scale language models and other state-of-the-art models can be built, as [Diskin et al. (2021)](https://arxiv.org/abs/2106.10207) demonstrated with volunteer compute.
#### Profiling
The profiling process establishes a baseline distance threshold for the proof-of-learning verification. Verifiers will periodically grab profiling tasks and generate variation thresholds for proof-of-learning comparisons. To generate a threshold, a Verifier will deterministically run and re-run portions of the training with different random seeds, generating and checking their own proofs. In doing this, the Verifier will build up an aggregate expected distance threshold that can later be used as a threshold to validate the non-deterministic work of the Solvers.
In order to ensure the honesty of the Verifiers when generating the distance thresholds, Whistleblowers are expected to re-run the profiling work and challenge Verifiers where appropriate, using the same graph-based pinpoint challenge and contract arbitration mechanisms described below.
#### Training
Following profiling, the task enters the common task pool (analogous to the Ethereum mempool). A single Solver is selected to perform the task and the task is removed from the task pool. The Solver performs the task according to the metadata submitted by the Submitter and using the model and training data supplied. Whilst performing the training task, the Solver also generates a [proof-of-learning](https://arxiv.org/abs/2103.05633) by checkpointing at a scheduled interval and storing metadata from the training process (including parameters) so that the following optimisation step can be replicated as accurately as possible by a Verifier.
#### Proof generation
Proof generation follows the process outlined in [Jia et al. (2021)](https://arxiv.org/abs/2103.05633), whereby Solvers periodically store the model weights or updates along with the corresponding indices from the training dataset identifying the samples that were used to generate the weight updates. The checkpoint frequency can be tuned to provide stronger guarantees or to save on storage space. Proofs can be “stacked”, meaning that a proof can start from the random distribution used to initialise the weights or from pre-trained weights generated with their own proof. This allows the protocol to build up a set of already-proven, pre-trained base models (i.e. [foundation models](https://arxiv.org/abs/2108.07258)) which can be fine-tuned for more specific tasks.
#### Verification of proof
Following task completion, Solvers register the completion of the task with the chain and present their proof-of-learning in a publicly accessible location for access by Verifiers. Verifiers pick up verification tasks from a common task pool (again analogous to the Ethereum mempool) and perform the computational work to re-run portions of the proof and perform distance calculations. The resulting distances are then used by the chain (along with the threshold calculated during the profiling stage) to determine whether the verification matches the proof.
#### Graph-based pinpoint challenge
Following verification of the proof-of-learning, Whistleblowers can replicate Verifier work in order to check that the verification work itself has been performed correctly. In the event that a Whistleblower believes that verification has been performed incorrectly (maliciously or not) they can challenge the Verifier to contract arbitration in order to receive a reward. This reward 프로젝트로 돌아가기
