# **DINX Yellow Paper**

### Background
Prior to the release of DINX, all inscription protocols in the market followed a similar principle. Protocol information is transmitted on-chain through UTXO/CallData, and off-chain indexers decode and process this information according to the protocol standards.
The above method has several drawbacks:
1. **Latency Issues:** Off-chain indexers need to fetch data from the blockchain and then decode and process it. This process can cause significant delays, especially when dealing with large amounts of data, potentially failing to meet real-time requirements.
2. **Reliability Issues:** Off-chain indexers rely on external services. If these services fail or are attacked, the entire data processing chain can be affected, leading to data inconsistency or loss. There is also a risk of inconsistency between on-chain data and data processed by off-chain indexers, particularly when errors occur during data synchronization or processing. Ensuring data consistency requires additional mechanisms and methods.
3. **Security Issues:** The security of off-chain indexers depends on the implementation and deployment environment. If attacked, it could lead to data leaks or tampering. Additionally, on-chain data may face risks of interception or tampering during transmission.
4. **Complexity Issues:** This approach requires handling both on-chain and off-chain data, resulting in high development and maintenance costs. Parsing and indexing on-chain protocol information requires a deep understanding of blockchain and data indexing technology, increasing the complexity of development and maintenance. As the data volume increases, the load on off-chain indexers also increases, potentially leading to performance bottlenecks and affecting system scalability.
DINX provides a more efficient and reliable solution through its distributed index architecture, better addressing the needs for large-scale data processing and real-time queries.

### Project Introduction
DINX, short for Distributed Indexer, aims to offer a more efficient and reliable solution through its innovative distributed index architecture. By introducing Layer 1.5 architecture, multi-signature index verification, performance reliability proof validation nodes, and OP fraud proof, DINX ensures the consistency and security of inscription data, significantly enhancing market trust and reliance on data indexing systems.
The DINX system not only inherits the security and decentralization characteristics of Layer 1 public chains but also introduces the scalability and high-performance features of Layer 2 solutions. It can quickly handle large-scale datasets and support real-time queries, making it a universal solution suitable for all inscription indexing environments.

### Market Analysis
The current blockchain inscriptions market increasingly demands efficient, secure, and reliable data indexing. Historical events have exposed the flaws and vulnerabilities of existing indexing mechanisms, causing market confusion and user frustration. These incidents also highlighted the inadequacies of current indexing systems in handling large-scale data and real-time queries.

<table>
<tr>
<th style="width: 15%;">Platform</th>
<th style="width: 15%;">Date</th>
<th style="width: 20%;">Issue</th>
<th style="width: 35%;">Details</th>
<th style="width: 5%;">Source</th>
</tr>
<tr>
<td>Binance</td>
<td>November 27, 2023</td>
<td>Inconsistent ORDI Indexing</td>
<td>About 5 million ORDIs suspected of being issued due to inconsistent exchange indexing, causing holdings to exceed total supply by $100 million.</td>
<td><a href="https://www.coinlive.com/news-flash/341902">Link</a></td>
</tr>
<tr>
<td>OKX</td>
<td>December 30, 2023</td>
<td>Fake Asset Vulnerability in Ordinals Sats</td>
<td>Vulnerability in the OKX Web3 Wallet's Ordinals trading market, with fake sats being displayed in pending orders.</td>
<td><a href="https://www.coinlive.com/news-flash/411149">Link</a></td>
</tr>
<tr>
<td>Base20</td>
<td>February 2, 2024</td>
<td>Base Indexer BUG</td>
<td>A "negative attack" during index transfer verification caused data anomalies in Base20 indexer, triggering panic among users.</td>
<td>Internal verification, Base20 statement</td>
</tr>
<tr>
<td>UniSat</td>
<td>April 24, 2024</td>
<td>Double-spending attack on Unisats resulting in losses exceeding $1 million.</td>
<td>There's a risk of incorrect balance recording or double-spending due to flaws in the indexer's logic. This was evident in the double-spending attack on UniSat, resulting in losses exceeding $1 million.</td>
<td><a href="https://www.certik.com/resources/blog/7vy7jA7QaS4eWzQx4NX6ef-ordinals-and-the-brc-20-standard-overview-and-risk-analysis">Link</a></td>
</tr>
<tr>
<td>UniSat</td>
<td>June 12, 2024</td>
<td>Rats Indexer Issue</td>
<td>An issue with Runes indexing. Runes transfer function has been temporarily paused.</td>
<td><a href="https://x.com/unisat_wallet/status/1800489553154941174">Link</a></td>
</tr>
</table>

## System Architecture
### Layer 1.5 - Blockchain-Based Database
DINX uses a blockchain-based database to unlock new storage media, constructing a virtual blockchain to store all transaction data types for various types of protocols. This blockchain is referred to as Layer 1.5, a new blockchain architecture positioned between Layer 1 and Layer 2, designed to provide efficient storage and data management capabilities. It inherits the security and decentralization of Layer 1 public chains while introducing the scalability and high performance of Layer 2 solutions. Through this architecture, DINX provides an efficient storage layer for managing and indexing large-scale transaction data.
- **MPT Tree Structure:** Data is stored using a Merkle Patricia Tree (MPT) structure to ensure efficient storage and quick retrieval. The MPT tree structure can effectively organize and manage large amounts of data, offering strong data consistency and integrity verification capabilities. All stored data can be verified through hash values, ensuring data integrity and immutability.
- **Virtual Presence:** Layer 1.5 is a virtual chain, different from traditional physical blockchains, focusing on efficient data storage and processing rather than full consensus characteristics. DINX uses this virtual chain, employing a unique data storage structure to store all verified inscription data efficiently.
- **Multi-Protocol Support:** Layer 1.5 supports various protocol types for data storage and management, compatible with protocol standards in different application scenarios.

## Multi-Signature Index Verification
When protocol beacon nodes submit data proofs to Layer 1.5, they must be verified by a protocol committee through multi-node signature verification. Only when more than half of the signing nodes approve the data will it be submitted to the corresponding farm pool in Layer 1.5. This serves as the first firewall for maintaining inscription data consensus.
Suppose the protocol committee consists of N nodes, and each node signs the submitted data. The signature result for each node is $S_i$ (where $i$ is the node number). When at least half of the nodes (i.e., $\lceil \frac{N}{2} \rceil$) sign and verify the data, it is considered valid.

Let $validSignatures$ represent the number of valid signatures:
$validSignatures \geq \lceil \frac{N}{2} \rceil$

The calculation is as follows:
$H = \text{Hash(data)}$
$S_i = \text{Sign}{SKi}(H)$

When $\text{Verify}_{PK_i}(S_i, H) = \text{True}$, it is considered a valid signature. When the number of valid signatures meets the condition $validSignatures \geq \lceil \frac{N}{2} \rceil$, the data is submitted.

After each data submission, a virtual block $n$ of Layer 1.5 is constructed based on the corresponding block height of Layer 1. The virtual block $n$ contains the $\text{RootHash}_{n-1}$ of the previous virtual block $n-1$ as $\text{PreHash}_n$. The computed $\text{RootHash}_n$ becomes the $\text{PreHash}_{n+1}$ of the next virtual block.

Thus, a virtual chain structure tree is constructed, with the root node changing as protocol transactions increase. The root hash $H_{root}$ is the top-level hash of the entire tree, used to verify the tree's integrity:
- Leaf node hash: $$H_{leaf} = \text{Hash(d)}$$
- Branch node hash: $$H_{branch} = \text{Hash}(H_{child1} \parallel H_{child2} \parallel \cdots \parallel H_{child_n})$$
- Root hash: $$H_{root} = \text{Hash}(H_{branch1} \parallel H_{branch2} \parallel \cdots \parallel H_{branch_n})$$
Thus, DINX ensures the first layer of efficient, secure, and consistent communication between Layer 1 and Layer 1.5.

### Reliability Proof
DINX divides the overall validation into countless probabilistic verification topics. When probabilistic verification reaches a sufficiently high level, it can counterprove the reliability of the overall validation, ensuring the second layer of DINX consensus.
We can prove the reliability of any virtual block:
- $P$ represents the probability that the submitted state data is correct.
- $Q$ represents the probability that the submitted state data is incorrect.
- $n$ represents the number of verifications within the challenge period.
- $ϵ$ represents the error probability of each verification, i.e., the probability that a correct state is mistakenly identified as fraudulent.

The probability of a single verification being correct is $1 - ϵ$. Suppose that out of $k$ verifications, at least $m$ verifications are correct. We can use the binomial distribution to calculate the reliability of the overall verification.
Single verification reliability formula: $R = 1 - ϵ$
Multiple verification reliability formula: Let $B(n,p)$ represent the binomial distribution, indicating the number of successes out of $n$ independent trials, where the probability of success is $p$.
$$R_{\text{multiple}} = \sum_{k=m}^{n} \binom{n}{k} P^k (1 - P)^{n - k}$$ where $\binom{n}{k}$ is the binomial coefficient, representing the number of combinations for choosing $k$ successes out of $n$ trials.

### Proof Rewards
In the DINX system, to encourage users to actively participate in data validation and submit reliability proofs, we introduce a verification mechanism based on smart contracts. When users submit a reliability proof, it can be automatically verified by a smart contract, and the user is rewarded accordingly.
To ensure fair distribution of rewards, DINX has added the following limitations:

**Verification Frequency**
Within a single Layer 1.5 block, only N provers are allowed to receive rewards. This means that multiple users cannot receive rewards for submitting the same or different fraud proofs within the same block, preventing duplicate rewards.
**Interval Absolute Value**
After a proof is submitted and confirmed, the next block submitter’s proof virtual block number must be absolutely larger than the previous confirmed block. This ensures the random distribution of blocks and prevents users from submitting proofs concentrated in specific blocks. Specifically, the absolute block value is:

$$||\text{VirtualBlock}_n - \text{VirtualBlock}_{n-1} || \geq \frac{\text{Height}}{4}$$
where $\text{VirtualBlock}_n$ is the current submitted virtual block number, $\text{VirtualBlock}_{n-1}$ is the previous confirmed virtual block number, and $\text{Height}$ is the current block height.

**Proof Reward Decrement**
To prevent users from repeatedly submitting the same virtual block proof within the interval and to encourage users to submit proofs for undeveloped virtual blocks, all user-submitted virtual block proofs will be recorded in times. Each virtual block can receive up to 3 rewards, with each reward halved. The specific formula is as follows:

- The initial reward for the first submission is $R$
- The reward for the second submission is $\frac{R}{2}$
- The reward for the third submission is $\frac{R}{4}$

If a virtual block has been submitted more than 3 times, no further rewards will be given.

### OP Fraud Proof
Optimistic Rollup Fraud Proof (OP Fraud Proof) is a mechanism used to ensure data correctness and security in blockchain scaling solutions, commonly used in Optimistic Rollup (ORU) schemes. In the constructed blockchain-based database of DINX, it serves as the third layer of inscription data consensus.
DINX improves blockchain throughput and efficiency by moving most computation and storage to the Layer 1.5 EVM virtual machine. However, to ensure the correctness of data processing results, a mechanism is needed to prevent malicious actors from submitting incorrect results. This is where fraud proofs come in:
- **Transaction Submission:** Transactions are processed by several traditional inscription nodes adopting PoS consensus. They are first processed off-chain and filtered according to rules, then submitted collectively to the corresponding farm contract in Layer 1.5 via multi-signature. Nodes need to stake a symbolic amount of the corresponding inscription protocol to become valid registered nodes.
- **Optimistic Assumption:** The submitted state data is assumed to be correct, and the blockchain temporarily accepts the newly submitted data and state root without immediately verifying its correctness, thus calculating the index state.
- **Challenge Period:** After new state submission, there is a predetermined challenge period during which anyone can challenge the submitted state root, suspecting it contains fraudulent behavior.
- **Fraud Proof:** If someone raises a challenge, they must provide fraud proof, demonstrating that the submitted state root is incorrect. Fraud proof typically includes a set of transaction data and computation steps, showing the calculation process from the previous state root to the current state root and pointing out the errors. When fraud proof reaches a certain amount, a rollback procedure is initiated. Layer 1.5 will roll back to the corresponding block height, repair the data, and recalculate and update all state roots for that height and subsequent heights.

## Consensus Mechanism
In the DINX system, the consensus mechanism is the core to ensure data consistency and correctness among all nodes in a distributed system. DINX adopts an innovative scheme combining multiple consensus mechanisms to enhance system security, scalability, and efficiency.
**1. Basic Consensus Mechanism: PoS (Proof of Stake)**
DINX constructs a Layer 1.5 public chain using PoS (Proof of Stake) as the basic consensus mechanism to build a blockchain-based database for storing all inscription protocol data.
**2. Multi-Signature Index Verification**
In the DINX system, data submission and verification adopt a multi-signature index verification mechanism. This mechanism ensures the correctness and security of the data submitted to Layer 1.5.
**3. Reliability Proof**
DINX ensures the reliability of the submitted state data through probabilistic verification. The overall validation is divided into numerous probabilistic verification topics, and when probabilistic verification reaches a sufficient level, it can counterprove the overall validation's reliability.
**4. OP Fraud Proof (Optimistic Rollup Fraud Proof)**
DINX introduces the OP fraud proof mechanism on Layer 1.5 as the third layer of inscription data consensus firewall. This mechanism ensures the correctness of data processing results and prevents malicious actors from submitting incorrect results.

## System Modules

### Smart Contracts
#### System Contract
The Protocol System Contract serves as the entry point and dispatch center for all protocol data submissions, managing all operations related to the protocol. The System Contract collaborates with the Factory Contract and MPT Contract to ensure data uniqueness, constructs the MPT tree, and creates new Tick instance contracts through the Factory, updating the corresponding Tick contract status to maintain data timeliness and verifiability.
#### Factory Contract
The Factory Contract is mainly used to deploy and manage protocol-specific contract instances. Through the Factory Contract, DINX can dynamically create and initialize contract instances under different protocols, achieving modular and flexible contract deployment.
- The Factory Contract is responsible for creating specific contract instances under different protocols (e.g., ATick Contract, BTick Contract). This design allows new contract instances to be generated dynamically as needed, without manual deployment each time.
- The Factory Contract not only creates but also manages these contract instances, including initialization, configuration, and maintenance tasks.
- Through predefined logic and permission control, the Factory Contract ensures that only authorized users and nodes can create and manage contract instances.
#### MPT Contract
The MPT (Merkle Patricia Tree) Contract mainly constructs the virtual block height of the protocol to maintain the protocol's virtual chain structure. The MPT Contract also provides effective output and verification of reliability proof and OP fraud proof, ensuring data integrity and consistency.
#### Tick Contract
The protocol specifies an EIP contract specification, defining methods for scheduling and coordinating operations within the protocol, ensuring that all operations are executed in an orderly manner according to predefined logic.
### RPC
As a Layer 1.5 public chain, DINX will maintain a PoS blockchain infrastructure, with a complete set of RPC interfaces available for real-time access to the DINX blockchain's operational status and on-chain parameters.

### API (Beta)
**1. GET /api/protocolA/block/{blockHeight}**

{
    "blockHeight": 123,
    "rootHash": "0xabc123...",
    "previousHash": "0xdef456...",
    "proved": 3,
    "transactions": [
        "0x789...",
        "0x456..."
    ]
}

**2. GET /api/protocolA/{address}/{tick}/balance**

{
    "address": "0xabc123...",
    "balance": "100.50"
}

**3. GET /api/protocolA/{address}/{tick}/history**

{
    "protocol": "Type of protocol",
    "tick": "",
    "address": "0xabc123...",
    "transactions": [
        {
            "transactionHash": "0x789...",
            "blockHeight": 123,
            "timestamp": "2024-01-01T00:00:00Z",
            "daHash": "0x...",
            "hash": "0x...",
            "data": {},
        },
        {
            "transactionHash": "0x789...",
            "blockHeight": 124,
            "timestamp": "2024-01-01T00:00:00Z",
           "daHash": "0x...",
            "hash": "0x...",
            "data": {},
        }
    ]
}

## Commercial Value
DINX will provide convenient services as an essential infrastructure in the inscription ecosystem, offering efficient data processing and verification services for wallets, exchanges, and other third-party services, enhancing decentralization, breaking the monopoly of existing index operators, and enabling ordinary users to participate in index verification.

#### Decentralization
**- Open Participation Mechanism:** The DINX system has designed an open participation mechanism, allowing any user to participate in data validation and index verification. Compared to traditional centralized indexing solutions, DINX significantly increases the system's degree of decentralization. This mechanism effectively breaks the monopoly of single index operators, making the data verification process more transparent and fair.
**- Distributed Indexing:** Through a distributed indexing architecture, DINX distributes data processing and verification across multiple nodes, reducing dependence on single index operators, enhancing the system's resistance to attacks, and improving data processing reliability. Ordinary users can participate in index data verification without deep technical backgrounds, greatly lowering the threshold for index participation.
**- Multi-Protocol Support:** DINX supports data storage and management of various protocols, promoting interoperability and the development of a decentralized ecosystem across different protocols.

#### Aggregated Inscription Functionality for Third-Party Services
**- Wallet Applications:** Wallet services can integrate DINX's API interfaces to provide users with efficient inscription data submission and query functions. Additionally, wallets can leverage DINX's decentralized validation mechanism to enhance user data security and reliability.
**- Exchanges:** Exchanges can use DINX's distributed indexing and verification services to achieve efficient management and verification of transaction data, ensuring the authenticity and immutability of transaction data. By integrating DINX's API, exchanges can offer more efficient and secure trading services.
**- Decentralized Applications (dApps):** Developers can use DINX's services to build various decentralized applications, such as decentralized social platforms, supply chain management systems, etc. These applications can fully utilize DINX's decentralization characteristics and efficient data management functions, enhancing user experience and data security.

## Economic Model
The economic model will be announced upon official launch.