Add tech explainer docs.

docs/1_basics.md

@@ -1 +1,51 @@
-placeholder
+# 1. Basics
+
+## 1.1. Overview
+
+The Innovation Game (TIG) is the first coordination protocol designed specifically for algorithmic innovation. At the core of TIG lies a novel variant of proof-of-work called optimisable proof-of-work (OPoW).
+
+OPoW uniquely integrates multiple proof-of-works to be featured, "binding" them in a manner prevents centralization due to optimizations of the proof-of-work algorithms. This resolves a longstanding issue that had hindered proof-of-work from being based on real-world computational scientific challenges.
+
+TIG combines a crypto-economic framework with OPoW to:
+
+1. Incentivise miners, referred to as Benchmarkers, to adopt the most efficient proof-of-work algorithms contributed openly to TIG. This incentive is derived from sharing block rewards proportional to the number of solutions found.
+2. Incentivise contributors, known as Innovators, to optimise existing proof-of-work algorithms and invent new ones. Their incentive is tied to sharing block rewards based on adoption of their algorithms by Benchmarkers.
+
+TIG will progressively phase in proof-of-works over time, directing innovative efforts towards the most significant challenges in science.
+
+## 1.2. Blocks
+
+In TIG, a block serves as the fundamental unit of time, roughly equivalent to 60 seconds. Blocks fulfil two primary functions:
+
+1. Timestamp for when Benchmarkers start & submit their solutions
+2. Execution of OPoW-related state transitions, determining Benchmarkers' influence and algorithm adoption, leading to the distribution of block rewards denominated in TIG tokens.
+
+## 1.3. Rounds
+
+A round spans 10,080 blocks, approximately equivalent to 604,800 seconds or 7 days. Rounds serve three primary purposes:
+
+1. Execution of algorithm related state transitions.
+2. Coordination of protocol and configuration updates, including the introduction of new challenges and voting procedures.
+3. The token emission schedule is structured around rounds.
+
+## 1.4. Token Emission Schedule
+
+TIG’s token emission schedule comprises 5 tranches, each with the same total emission of 26,208,000 TIG, but successively doubling in duration (measured in rounds):
+
+| **Tranche** | **#Rounds** | **Emissions per block** | **Emissions per round** | **Start Date** | **End Date** |
+| --- | --- | --- | --- | --- | --- |
+| 1   | 26  | 100 | 1,008,000 | 24 Nov 2023 | 30 May 2024\* |
+| 2   | 52  | 50  | 504,000 | 31 May 2024\* | 30 May 2025\* |
+| 3   | 104 | 25  | 252,000 | 31 May 2025\* | 29 May 2027\* |
+| 4   | 208 | 12.5 | 126,000 | 30 May 2027\* | 24 May 2031\* |
+| 5   | 416 | 6.25 | 63,000 | 25 May 2031\* | 14 May 2039\* |
+
+\*Approximates
+
+Post tranche 5, rewards are solely based on tokens generated from license fees paid by commercial entities purchasing licenses.
+
+## 1.5. TIG Token
+
+The [TIG token contract](../tig-token/TIGToken.sol) is derived from OpenZepplin's ERC20 standard and is deployed to Basechain at the following address: [0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B](https://basescan.org/token/0x0C03Ce270B4826Ec62e7DD007f0B716068639F7B).
+
+TIG tokens earned during a round are minted within 7 days following the conclusion of that round.

docs/2_challenges.md

@@ -1 +1,126 @@
-placeholder
+
+# 2. Challenges
+
+A challenge within the context of TIG is a computational problem adapted as one of the proof-of-works in OPoW. Presently, TIG features three challenges: boolean satisfiability, vehicle routing, and the knapsack problem. Over the coming year, an additional seven challenges from domains such as AI, cryptography, biomedical research, and climate science will be phased in.
+
+Beyond this initial set of ten challenges, TIG's roadmap includes the establishment of a scientific committee tasked with sourcing diverse computational problems.
+
+This chapter covers the following topics:
+
+1. What is the relation between Benchmarkers and Challenges
+2. How real world computational problems are adapted for proof-of-work
+3. Regulation of the network's computational load for verifying solutions
+
+## 2.1. Challenge Instances & Solutions
+
+A challenge constitutes a computational problem from which instances can be deterministically pseudo-randomly generated given a seed and difficulty. Benchmarkers iterate over nonces to generate seeds and subsequently produce challenge instances to compute solutions using an algorithm.
+
+Each challenge also stipulates the method for verifying whether a "solution" indeed solves a challenge instance. Since challenge instances are deterministic, anyone can verify the validity of solutions submitted by Benchmarkers.
+
+Notes:
+
+- The minimum difficulty of each challenge ensures a minimum of 10^15 unique instances, with even more as difficulty increases.
+
+- Some instances may lack a solution, while others may possess multiple solutions.
+
+- Algorithms are not guaranteed to find a solution.
+
+## 2.2. Adapting Real World Computational Problems
+
+Computational problems with scientific or technological applications typically feature multiple difficulty parameters. These parameters may control factors such as the accuracy threshold for a solution and the size of the challenge instance.
+
+For example, TIG's version of the Capacitated Vehicle Routing Problem (CVRP) incorporates two difficulty parameters: the number of customers (nodes) and the factor by which a solution's total distance must surpass the baseline value.
+
+TIG's inclusion of multiple difficulty parameters in proof-of-work sets it apart from other proof-of-work cryptocurrencies, necessitating innovative mechanisms to address two key issues:
+
+1. Valuing solutions of varying difficulties for comparison
+2. How difficulty with multiple parameters should be adjusted
+
+Notes:
+
+- Difficulty parameters are always integers for reproducibility, with fixed-point numbers used if decimals are necessary.
+
+- The expected computational cost to compute a solution rises monotonically with difficulty.
+
+### 2.2.1. Pareto Frontiers & Qualifiers
+
+The issue of valuing solutions of different difficulties can be deconstructed into three sub-issues:
+
+1. There is no explicit value function that can "fairly" flatten difficulties onto a single dimension without introducing bias
+
+2. Setting a single difficulty will avoid this issue, but will excessively limit the scope of innovation for algorithms and hardware
+
+3. Assigning the same value to solutions no matter their difficulty would lead to Benchmarkers "spamming" solutions at the easiest difficulty
+
+The key insight behind TIG's Pareto frontiers mechanism (described below) is that the value function does not have to be explicit, but rather can be fluidly discoverable by Benchmarkers in a decentralised setting by allowing them to strike a balance between the difficulty they select and the number of solutions they can compute.
+
+![Pareto frontier](https://en.wikipedia.org/wiki/Pareto_front#/media/File:Pareto_Efficient_Frontier_1024x1024.png)
+
+*Figure: The red line is an example of a Pareto frontier. [Sourced from wikipedia](https://en.wikipedia.org/wiki/Pareto_front)*
+
+This emergent value function is naturally discovered as Benchmarkers, each guided by their unique value function, consistently select difficulties they perceive as offering the highest value. This process allows them to exploit inefficiencies until they converge upon a set of difficulties where no further inefficiencies remain to be exploited; in other words, staying at the same difficulties becomes more efficient, while increasing or decreasing would be inefficient.
+
+Changes such as Benchmarkers going online/offline, availability of more performant hardware/algorithms, etc will disrupt this equilibrium, leading to a new emergent value function being discovered.
+
+The Pareto frontiers mechanism works as follows:
+
+1. Plot the difficulties for all active solutions or benchmarks.
+
+2. Identify the hardest difficulties based on the Pareto frontier and designate their solutions as qualifiers.
+
+3. Update the total number of qualifying solutions.
+
+4. If the total number of qualifiers is below a threshold (currently set to `1000`), repeat the process.
+
+Notes:
+
+- Qualifiers for each challenge are determined every block.
+
+- Only qualifiers are utilised to determine a Benchmarker's influence and an Algorithm's adoption, earning the respective Benchmarker and Innovator a share of the block rewards.
+
+- The total number of qualifiers may be over the threshold. For example, if the first frontier has `400` solutions, the second frontier has `900` solutions, then there are `1300` qualifiers. 
+
+### 2.2.2. Difficulty Adjustment
+
+Every block, the qualifiers for a challenge dictate its difficulty range. Benchmarkers, when initiating a new benchmark, must reference a specific challenge and block in their benchmark settings before selecting a difficulty within the challenge's difficulty range.
+
+At a high level, a challenge's difficulty range is determined as follows:
+
+1. From the qualifiers, filter out the easiest difficulties based on the Pareto frontier to establish the base frontier.
+
+2. Calculate a difficulty multiplier (capped to `2.0`)
+    * $difficulty\ multiplier = \frac{number\ of\ qualifiers}{threshold\ number\ of\ qualifiers}$
+    * e.g. if there are `1500` qualifiers and the threshold is `1000`, the multiplier is `1500/1000 = 1.5`
+3. Multiply the base frontier by the difficulty multiplier to determine the upper or lower bound.
+    * If multiplier > 1, base frontier is the lower bound
+    * If multiplier < 1, base frontier is the upper bound
+
+The following Benchmarker behaviour is expected:
+
+- **When number of qualifiers is higher than threshold:** Benchmarkers will naturally select harder and harder difficulties so that their solutions stay on the frontiers for as long as possible, as only qualifiers count towards influence and share in block rewards.
+
+- **When number of qualifiers is equal to threshold:** Benchmarkers will stay at the same difficulty
+
+- **When number of qualifiers is lower than threshold:** Benchmarkers will naturally select easier and easier difficulties to compute more solutions which will be qualifiers.
+
+## 2.3. Regulating Verification Load
+
+Verification of solutions constitutes almost the entirety of the computation load for TIG's network. In addition to probabilistic verification which drastically reduces the number of solutions that require verification, TIG employs a solution signature threshold mechanism to regulate the rate of solutions and the verification load of each solution.
+
+### 2.3.1. Solution Signature
+
+A solution signature is a unique identifier for each solution derived from hashing the solution and its runtime signature. To be considered valid, this signature must fall below a dynamically adjusted threshold.
+
+Each challenge possesses its own dynamically adjusted solution signature threshold which starts at `100%` and can be adjusted by a maximum of `0.25%` per block. This percentage reflects the probability of a solution being valid.
+
+Lowering the threshold has the effect of reducing the probability that any given solution will be valid, thereby decreasing the overall solution rate. As a result, the number of qualifiers, and subsequently the difficulty range of the challenge, will also decrease. Increasing the threshold has the opposite effect.
+
+There are 2 feedback loops which adjusts the threshold:
+
+1. **Target fuel consumption** (currently disabled). The execution of an algorithm is performed through a WASM Virtual Machine which tracks "fuel consumption", a proxy for the real runtime of the algorithm. Fuel consumption is deterministic and is submitted by Benchmarkers when submitting solutions.
+
+    Another motivation for targeting a specific fuel consumption is to maintain a fair and decentralised system. If the runtime approaches the lifespan of a solution, raw speed (as opposed to efficiency) would become the dominant factor, potentially giving a significant advantage to hardware (such as supercomputers) that prioritises speed over efficiency.
+
+1. **Target solutions rate.** Solutions rate is determined every block based on mempool proofs that are being confirmed. (Each proof is associated with a benchmark, containing a number of solutions).
+
+    Spikes in solutions rate can occur when there is a sudden surge of new Benchmarkers/compute power coming online. If left unregulated, the difficulty should eventually rise such that the solution rate settles to an equilibrium rate, but this may take a prolonged period causing a strain on the network from the large verification load. To smooth out the verification load, TIG targets a specific solutions rate.

docs/3_innovators.md

@@ -1 +1,79 @@
-placeholder
+# 3. Innovators
+
+Innovators are players in TIG who optimise existing proof-of-work algorithms and/or invent new ones, contributing them to TIG in order to share in block rewards.
+
+This chapter covers the following topics:
+
+1. The two types of algorithm submissions
+2. Mechanisms for maintaining a decentralised repository
+3. How algorithms are executed by Benchmarkers
+4. How algorithms earn block rewards
+
+## 3.1. Types of Algorithm Submissions
+
+There are two types of algorithm submissions in TIG:
+
+1. Code submissions
+2. Breakthrough submissions
+
+**Code submissions** encompass porting an existing algorithm for use in TIG, optimising the performance of an algorithm previously submitted by another Innovator, or an implementation of an entirely new algorithm. Code submissions must implement a solve_challenge function.
+
+Presently, code submissions are restricted to Rust, automatically compiled into WebAssembly (WASM) for execution by Benchmarkers. Rust was chosen for its performance advantages over other languages, enhancing commercial viability of algorithms contributed to TIG, particularly in high-performance computing. Future iterations of TIG will support additional languages compilable to WASM.
+
+**Breakthrough submissions** involve the introduction of novel algorithms tailored to solve TIG's proof-of-work challenges. A breakthrough submission is expected to yield such a significant performance enhancement that even unoptimised code of the new algorithm outpaces the most optimised code of an existing one.
+
+Support for breakthrough submissions is on TIG's roadmap.
+
+## 3.2. Decentralised Repository
+
+Algorithms are contributed to a repository devoid of a centralised gatekeeper. TIG addresses crucial issues such as spam and piracy to ensure fair rewards for Innovators based on performance, maintaining a strong incentive for innovation.
+
+To combat spam, Innovators must pay a submission fee of 0.001 ETH, burnt by sending it to the null address (0x0000000000000000000000000000000000000000). In the future, this fee will be denominated in TIG tokens.
+
+To counter piracy concerns, TIG implements a push delay and merge points mechanism:
+
+### 3.2.1. Push Delay Mechanism
+
+Upon submission, algorithms are committed to their own branch and pushed to a private repository. Following successful compilation into WebAssembly (WASM), a delay of `3` rounds ensues before the algorithm is made public where the branch is pushed to TIG's public repository. This delay safeguards Innovators' contributions, allowing them time to benefit before others can optimise upon or pirate their work.
+
+Notes:
+
+- Confirmation of an algorithm's submission occurs in the next block, determining the submission round.
+
+- An algorithm submitted in round `X` is made public at the onset of round `X + 3`.
+
+### 3.2.2. Merge Points Mechanism
+
+This mechanism aims to deter algorithm piracy. For every block in which an algorithm achieves at least `25%` adoption, it earns a merge point alongside a share of the block reward based on its adoption.
+
+At the end of every round, the algorithm from each challenge with the most merge points (exceeding a minimum threshold of `5040`) is merged into the repository's main branch. Merge points reset each round.
+
+Merged algorithms, as long as their adoption is above `0%`, share in block rewards every block.
+
+The barrier to getting merged is intentionally set high as to minimise the likely payoff for pirating algorithms.
+
+For breakthrough submissions, the vote for recognising the algorithm as a breakthrough starts only when its code gets merged (details to come). This barrier is based on TIG's expectation that breakthroughs will demonstrate distinct performance improvements, ensuring high adoption even in unoptimised code.
+
+## 3.3. Deterministic Execution
+
+Algorithms in TIG are compiled into WebAssembly (WASM), facilitating execution by a corresponding WASM Virtual Machine. This environment, based on wasmi developed by parity-labs for blockchain applications, enables tracking of fuel consumption, imposition of memory limits, and has tools for deterministic compilation.
+
+Benchmarkers must download the WASM blob for their selected algorithm from TIG's repository before executing it using TIG's WASM Virtual Machine.
+
+Notes:
+
+- The WASM Virtual Machine functions as a sandbox environment, safeguarding against excessive runtime, memory usage, and malicious actions.
+
+- Advanced Benchmarkers may opt to compile algorithms into binary executables for more efficient nonce searches, following thorough vetting of the code.
+
+### 3.3.1. Runtime Signature
+
+As an algorithm is executed by TIG's WASM Virtual Machine, a "runtime signature" is updated every opcode using the stack variables. This runtime signature is unique to the algorithm and instance of challenge, and is used to verify the algorithm used by Benchmarkers in their settings.
+
+## 3.4. Sharing in Block Rewards
+
+TIG incentivises algorithm contributions through block rewards:
+
+- `15%` of block rewards are allocated evenly across challenges with at least one "pushed" algorithm before distributing pro-rata based on adoption rates.
+
+- In the future, a fixed percentage will be assigned to the latest breakthrough for each challenge. In the absence of a breakthrough, this percentage reverts back to the Benchmarkers' pool. Given the rarity of breakthroughs, this represents a significant reward, reflecting TIG's emphasis on breakthrough innovations.