architecture-of-atlaspad.md

description
Technical Detail of Our zkApp Design

🛠 Architecture of "Atlaspad"

Architecture of zkApp Launchpad

Platform Design and Layers

0. Frontend Layer

The Frontend/Backend Layer is the interface between the user and the platform, providing a responsive UI that adjusts to various devices and screen sizes, enhancing accessibility and ensuring a consistent user experience. The Web Client facilitates seamless interaction with blockchain services, while the AI Chatbot serves as an on-demand guide for user assistance and support.

Architecture Highlights:

1. Responsive Platform UI: Adapts to any device, offering a frictionless user interface.
2. Web Client: Ensures robust performance and reliable transactions.
3. AI Chatbot: Provides intelligent support, enhancing user engagement.
4. Crypto Dashboard: Enhancing user engagement.

Why It's the Right Choice:

- The responsive UI is a must in today's multi-device world, ensuring no user is left behind.
- A dedicated Web Client is essential for maintaining a secure and stable connection to blockchain networks.
- The AI Chatbot is not just a support tool but a feature that can significantly enhance user retention and satisfaction.\

Layer Schemata

1. User Interface Layer

Components:

**- **MetaMask Plugin: The interface through which the user interacts with Ethereum and other EVM compatible networks. It provides crypto wallet functionality and gives the user the ability to send and receive tokens on the network.
**- **Mina Wallet App (AtlasPad): An interface with manual transaction capability for users without an automated wallet.

Functionality:

- Users initiate presale or staking transactions through this layer and manage the authentication process.
- Authentication based on Merkle Tree and token allocation information is entered through this layer.

User Interface Layer

2. Application Layer

Components:

**- **ZK Application (ZK-App): Software running on the Mina network that ensures the privacy and security of user transactions using zero-knowledge proofs.
**- **Presale and Refund Modules: Provides users with the ability to purchase or refund tokens.

Functionality:

- This layer utilizes the lightweight nature of the Mina network, allowing users to prove transactions while protecting their credentials.
- Users can perform presale transactions or request a refund if needed.

Application Layer

3. Network Layer

Components:

**- **Main Network: Hosts the presale and staking modules and contains separate oracles for each blockchain.
**- **EVM Network: Represents EVM-compatible networks such as Binance Smart Chain (BSC), Ethereum (ETH), Avalanche (AVAX) and is used for presale transactions.
**- **Mina Network: The network where ZK-App runs and user data is stored.

Functionality:

- Each blockchain network uses its own oracle for price information and other external data.
- Users can perform staking transactions and stake their tokens through this layer.

Network Layer

4. Data Storage and Verification Layer

The Data Layer employs Merkle Mountain Ranges for data integrity and offers off-chain storage with homomorphic encryption for enhanced security. It also utilizes IPFS or Celestia for data availability, ensuring that the launchpad’s data remains accessible and immutable.

Components:

**- **Merkle Tree(MMR-Merkle Mountain Ranges): Data structure that stores users' token allocations and authentication information.
The Merkle Proof consists of a construction that shows how to locate an input (OutX) in the total set of outputs MMR.

Merkle Mountain Ranges is a structure used as an alternative to traditional Merkle trees. Merkle Mountain Ranges is a fully additive structure and items are added from left to right. MMR can be seen as a list of fully balanced binary trees of elements or as a single binary tree cut from the top right. MMR is used in the Grin project to store kernel, outputs and range proofs.

Structure and Functions:

• Height: The height of each node in the MMR is obtained from the row to which it is added.

• Hashing and Branching: The parent nodes in MMR contain the hash of its two children. Grin uses the Blake2b hash function and always adds the position of the node before hashing. For example, if a leaf contains l, index n and data D:

  {% code title="merkle.js" %}

  Node(l) = Blake2b(n | D)

  {% endcode %}

• Bagging the Peaks: A process is used to find the peaks in the MMR. The first left-hand peak is always the highest and always has a position "filled with ones". The position of the first peak can be expressed as 2^n - 1,which is smaller than the total size of the MMR. To find the other peaks, we move to their right siblings. This process is repeated until the positions of the peaks are determined.

• Pruning: In Grin, some of the data in MMRs can be removed over time. In doing so, some leaves become redundant and their hashes can be removed. When enough leaves are removed, the existence of their parent nodes may also become redundant. Therefore, a significant portion of the MMR can be pruned by removing its leaves.
  
  Merkle Proof includes the following:
  - The hash of the leaf representing OutX.
  - The hash of the overall root in the tree.
  - A sequence of hashes representing all MMR vertices (this shows that together they form the overall root).- A list of sibling hashes to enable the construction of the branch from OutX to the top.
  - A list of sibling positions (left/right) to ensure the correct reconstruction of the branch. Merkle Proof is used to prove that a node is below its vertex and show that the vertexes form the overall root.

Merkle Tree

Coinbase Output:

The wallet holds a Merkle Proof (and the corresponding block hash) for each unused coinbase output. In order to spend the coinbase output, the block hash and Merkle Proof must be provided on entry. This is used to verify coinbase maturity and does not require full block data.

Wallet Verification:

**- **Initial Setup: Each user's wallet is associated with a unique leaf in the MMR. When a user registers or makes their first transaction, their wallet's public information and a unique identifier (nullifier) are hashed and added to the MMR.

**- **zk-Proof Generation: When a user initiates a session, they generate a zk-Proof that attests to the existence of their wallet's hash in the MMR without revealing the wallet's actual details. This proof can confirm the wallet's validity and the user's ownership securely and privately.

Transaction Processing:

**- **Transaction Verification: When a transaction is initiated, the MMR is used to verify that the participating wallets are valid and have not been double-spent. This verification is done by generating a zk-Proof that attests to the presence of the wallets' identifiers in the MMR and the absence of these identifiers in the list of spent nullifiers.

**- **Update Mechanism: Once a transaction is verified and completed, the MMR is updated. This update includes appending new transactions and pruning spent outputs, which is critical for maintaining the MMR's efficiency and compactness.

**- **ZK Proofs: Cryptographic proofs used to protect users' privacy while verifying the validity of their transactions.

Functionality:

- The Merkle Tree is required for users to prove their identity and token allocation in each session.
- ZK Proofs allow users to prove the authenticity of their transactions without revealing any personal information on the network.

Architecture Highlights:

- Off-Chain Storage with Homomorphic Encryption: Provides a secure way to compute on encrypted data.
- IPFS or Celestia Data Availability: Offers decentralized storage solutions for persistent data availability.

Data Layer

5. Oracle Layer

Our primary objective is to incorporate the use of oracles into our system. To achieve this, we are planning to write a distinct Oracle for each Ethereum Virtual Machine (EVM) network that is connected to our zkApp. This is a deliberate strategy we are adopting in order to ensure robust and efficient communication and interaction between the various networks. We believe this is the most optimized and least compromising strategy available.

• In Atlas Oracle we will create ABIs to integrate with external data providers (contracts and user). These ABI functions will communicate with Merkle Tree to work with other MINA wallets to write an Oracle in each network.

Oracle

Oracle Layer

6. Wallet Layer:

Especially when we encourage the use of MINA's wallet and associate the EVM-based wallet with the MINA wallet, EVM users will be indirectly encouraged into the MINA ecosystem as our platform will create an interlinked MINA wallet for them seamlessly (if they lack it) behind the scenes and more zkApp projects will come for our Launchpad. The Wallet Layer is where financial management takes place. It encompasses core functionalities such as transaction management and user wallet services. Cross-chain compatibility and blockchain network communication signify the layer's ability to interact smoothly across different blockchain infrastructures.

Architecture Highlights:

**1. **Core Function/Implementation: Manages all wallet operations with high security and efficiency.

**2. **User Wallets/Transaction Management: Provides users with full control over their transactions and funds.

**3. **Cross-Chain Compatibility: Ensures the wallet can operate over multiple blockchains, increasing its utility.

zk-Wallet

Why It's the Right Choice:

- The focus on core wallet functionalities ensures a secure and reliable financial environment.
\

Wallet Layer

Technology:

- ZK launchpad investigates interactions of the complex structure between ever-growing blockchain ecosystem
- Provides asset management across multiple blockchains such as mina and EVM blockchains- Improves the privacy and security of user with the use of Merkle Trees and zero-knowledge proofs.

• In the zkApp section of our Launchpad, when a user provides their MetaMask wallet, zkApp associates an Atlaspad Mina wallet with the user (client side) and returns it. To examine this process in detail, you can refer to the diagrams available in the links.

• Launchpad utilizes MMR Merkle Tree algorithms in zkApp's offchain database and performs nullifier operations for access tokens to conduct zk-proof verifications.

• There is no KPI due to zkApps

---

System Components

1. Client Side:
- MetaMask: A crypto wallet plugin that enables trading on EVM-compliant networks.
- Merkle Tree: The data structure where users store their token allocations.

2. ZK Application (ZK-App):
- An application that runs on the Mina network and uses zero-knowledge proof.
- It has presale and redemption functionality.

3. Main Network:
- Includes presale and staking modules.
- It hosts a separate oracle (data source) for each blockchain.

4. EVM Network:
- Includes example networks such as Bnb, Eth, Avalanche.
- It is used for presale functions and is integrated with an oracle.\

Scenerio of Atlaspad

Functionality:

Presale Operations
- Users access the presale module through MetaMask and manage their tokens on EVM-compliant networks.
- In this process, users' credentials and allocated token amounts are stored in the Merkle tree.

Staking Operations
- Users can stake their tokens by accessing the staking module on the main network.
- Since each network has its own oracle, price information and other external data from different networks is provided through these oracles.

Security and Privacy
- ZK-App uses zero-knowledge proof technology to prove the authenticity of transactions while protecting the user's identity.
- Users can make secure and confidential transactions by leveraging the lightweight and privately protected nature of the Mina network.

Result
- The Atlaspad ZK launchpad provides a secure and privacy-focused platform for crypto trading.
- The Merkle tree and zero-knowledge proof technologies are used create a secure experience for users, while ensuring that presale and staking functions are fully reliable, easy and efficient.\

---

Contract List

Contract Networks

Oracle Contract(s) ``-solidity
TokenLocker Contract ``-solidity
TokenStake Contract ``-solidity
TokenBurn Contract ``-solidity
TokenAirdrop Contract ``-solidity
TokenWithdraw Contract ``-solidity
TokenSwap Contract ``-solidity
NFTmint Contract ``-solidity
TokenClaim Contract ``-solidity
PrivatePresale Contract ``-solidity
PublicPresale Contract ``-solidity
MinaPresale Contract - o1js
Mina Claim Contract - o1js

---

LINKS FOR ARCHITECTURE

Main Diagram: https://drive.google.com/file/d/1TXYCXCvuAvhIo7zmdxKimLUGs5smcgjy/view?usp=sharing
Scenerio: https://drive.google.com/file/d/1DgexHczhWePgODLLV_dy7FFIkoeXTh4Q/view?usp=sharing
Contract Diagrams: https://drive.google.com/drive/folders/1SL3oP_tLkIEL3JHTayTLrU5p--DCpPRM?usp=sharing
Merkle Schemata: https://drive.google.com/file/d/1OwpVW72CFFoyO6lY3W4--BYSQ6N64s4_/view?usp=sharing
Layer Schemata: https://drive.google.com/file/d/1QXcNxSSMq9EMT4AaGGbuvP_UaezNQuqK/view?usp=sharing
Website: www.atlaspad.io
Non-zk Old Docs Page (for finance): https://docs.atlaspad.io
All: https://drive.google.com/drive/folders/1Ka_RfkbvvfnM5Xze6W0rnwX--EQNN4jd?usp=sharing
​​​​​​​Excalidraw: https://excalidraw.com/#room=c11c88dfb9c671a78113,tJiNKtr1vd9St9ZwMlZ-Fg