# What is DeepSafe A Crypto Random AI Verification Network DeepSafe is a Crypto Random AI Verification Network that ensures trustless verification of on-chain and off-chain data, addressing the critical need for integrity in decentralized systems. It validates AI Agent inputs and outputs, bridging blockchain and AI. As these technologies converge, DeepSafe’s role in providing tamper-proof verification is vital. Its vision is to become the standard for cross-chain, cross-system data verification, fostering a secure, scalable ecosystem. DeepSafe leverages advanced cryptographic techniques, including Ring VRF, MPC, and TEE. Ring VRF generates random numbers to select verification nodes, ensuring unpredictable, secure processes. MPC uses threshold signatures and dynamic node rotation for robust, collaborative validation. TEE protects sensitive data with hardware-level isolation. Together, these technologies deliver decentralized, tamper-resistant verification. The Cryptographic Random Verification Agent (CRVA), a DeepSafe innovation, orchestrates verification by randomly selecting nodes via Ring VRF and using zero-knowledge proofs for privacy. Integrated with LLM-powered deep search, CRVA enables rapid, intelligent data retrieval and validation, addressing issues like AI hallucinations and unreliable oracles. DeepSafe empowers applications like AI Agent validation, DeFi oracles, cross-chain interoperability, supply chain transparency, and privacy-preserving compliance. By ensuring reliable data across systems, DeepSafe aims to drive innovation and trust in decentralized ecosystems, inviting collaboration to shape a secure future. # Roadmap and Milestones This section outlines the public roadmap for DeepSafe, detailing past achievements, current progress, and future plans for the Crypto Random AI Verification Network. #### January 2024 * [x] Released DeepSafe WhitePaper and YellowPaper, outlining design principles and vision. * [x] Optimized Bitcoin-to-Layer2 bridge for enhanced efficiency and reliability. * [x] Designed framework for DeepSafe economic model, ensuring balanced incentives and inflation control. #### February 2024 * [x] Launched BRC20 cross-chain bridge for asset exchange between Layer2s and Bitcoin. * [x] Completed audit of Bitcoin cross-chain bridge contract. * [x] Released test version of Bitcoin Taproot Escape Hatch module. * [x] Initiated Alpha testnet and gathered community feedback. #### March 2024 * [x] Launched test version of economic model for evaluation. * [x] Integrated cross-chain support for multiple Bitcoin Layer 2 networks. * [x] Incorporated Trusted Execution Environment (TEE) into testnet for enhanced security. #### April 2024 * [x] Launched Beta testnet for comprehensive testing. * [x] Released test version of Forced Exit module for reliable withdrawals. #### May 2024 * [x] Conducted integration testing and performance optimization. * [x] Launched incentivized Beta testnet, rewarding community participation in cross-chain transaction testing. * [x] Upgraded Beta testnet, improving Tokenomics, CRVA nodes, and staking requirements. #### June 2024 * [x] Completed audit of EVM cross-chain bridge contract. * [x] Launched EVM cross-chain functionality, supporting major EVM-compatible blockchains and Layer 2s. * [x] Enabled liquidity cross-chain solutions for BTC, ETH, USDT, and USDC. * [x] Integrated mainstream Web3 wallets and UTXO-based blockchains. #### July 2024 * [x] Upgraded CRVA nodes for improved stability and security. * [x] Launched DeepSafe Bot on Telegram, supporting staking and cross-chain transactions. * [x] Enabled cross-chain support for RUNES tokens and completed audit of RUNES cross-chain bridge contract. * [x] Launched TON cross-chain functionality. * [x] Hosted joint reward events with major wallet partners. #### August 2024 * [x] Integrated BRC20 and RUNES cross-chain functionality with Nervos Network (UTXO-based). * [x] Optimized DeepSafe Bot, surpassing 1 million Telegram users. * [x] Launched global ambassador program. * [x] Started “DeepSafe Tech Daily” series to educate community on CRVA and BTCFi innovations. #### September 2024 * [x] Integrated Fractal Bitcoin (UTXO-based) with BTC and BRC20 cross-chain functionalities. * [x] Launched Pioneer Nodes Plan. * [x] Released test version combining Taproot, CRVA, and HTLC for decentralized asset custody. * [x] Released test version of infrastructure for BTC-collateralized stablecoins. * [x] Optimized DeepSafe Bot, reaching over 2 million Telegram users. #### October 2024 * [x] Launched Beta Mainnet testing with 20 Validator and 30 CRVA nodes. * [x] Completed snapshot for Beta Testnet Airdrop, rewarding contributors. #### November 2024 * [x] Announced Round #2 of Beta Testnet Airdrop. * [x] Released stable version of decentralized restaking functionality. #### December 2024 * [x] Optimized DeepSafe Bot, reaching over 3 million Telegram users. #### January 2025 * [x] Released stable version of infrastructure for BTC-collateralized stablecoins. #### February 2025 * [x] Conducted comprehensive core code security audits. * [x] Expanded community ambassador program and Key Opinion Leaders (KoLs). #### March 2025 * [x] Launched new test version of economic model for evaluation. * [x] Expand CRVA nodes to 400. #### April 2025 * [x] Release Light Paper for Crypto Random AI Verification Network. * [x] Launch Beta on public testnet with full API/SDK access. #### May 2025 * [x] Develop new Economic Model for DeepSafe. * [x] Release decentralized self-custody Bitcoin solution with one-way and two-way channel mapping. #### June 2025 * [x] Deploy BTC self-custody infrastructure leveraging Taproot, Timelock, and CRVA. #### Q3 2025 * [x] Release the [Decentralized Verification Layer Whitepaper](https://github.com/deepsafe/whitepaper/blob/main/DeepSafe_A_Cryptography_Random_Verification_Layer.pdf). * [ ] Launch Mainnet. * [ ] Expand validator nodes. * [ ] Hold wallet airdrop campaigns with major exchanges. #### Q4 2025 * [ ] Release AI Agent SDK. * [ ] Integrate DeFi & DEX transaction verification. * [ ] Launch omni-chain order book exchange (Beta). #### Q1 2026 * [ ] Launch AI agent verification module (Beta). * [ ] Release BTCFi lending module. * [ ] Activate buyback & burn mechanism. * [ ] Develop RWA verification toolkit. #### Q2 2026 * [ ] Launch AI validation marketplace (Beta). * [ ] Release institutional custody APIs. * [ ] Expand global compliance and regional partnership. #### Q3 2026 and beyond * [ ] Activate buyback & burn mechanism. * [ ] Full support for Layer2, PayFi, and DAO governance signatures. * [ ] Strengthen partnerships with top exchanges and RWA platforms. # CRVA Keyring Device A basic introduce of keyring service CRVA Keyring Device is a physical hardware that runing our keyring program in SGX environment to manage secret keys with MPC. ### **Basic Concepts** 1. **Device Secret Key**: This is a special derived secret key by SGX environment. This secret key stands for this hardware's identity. We get this secret key by call intel sgx interface `get_secret_key` and derive by `0x0002` which means *SGX\_KEYPOLICY\_MRSIGNER*. 2. **DeviceId**: Public key of **Device Secret Key**. It will be registered to chain. 3. **Enclave Secret Key**: We need another identity stands for this SGX environment running specific code. So we get a secret key by call intel sgx interface `get_secret_key` and derive by `0x0001` which means *SGX\_KEYPOLICY\_MRENCLAVE*. This is unique with different hardware and code. 4. **EnclaveId**: Public key of **Enclave Secret Key**. We register this identity to chain and there will be a map from **DeviceId** to **EnclaveId**. 5. **EnclaveHash**: This is a unique hash stands for running code hash which is generated when we build the code environment. This hash will be reported by SGX attestation proof. We use this hash to ensure all devices are running specific code version. 6. **MrSigner**: We have a registered identity at Intel, when we build the docker image, our identity will be included. Running this image will print **MrSigner** identity which can ensure the image's builder. 7. **Owner**: This is an account decided by hardware maintainer. Rewards for this device will be send to the owner account on chain. ### **Device State** 1. **Working**: Device owner should have enough pledge for this device on chain. Then device owner should send `join_service` to chain. Device will do all works(e.g. MPC, RingVRF, heartbeat, consensus*)*. **Owner** will get extra reward for this device's work. Owner **SOULD NOT** close the device hardware or program at this state. 2. **Exiting**: Device owner can send `exit_service` to chain. Device will not join new committees until this device exit all committees, and will send `report_standby` transaction automatically. Owner **SOULD NOT** close the device hardware or program at this state. 3. **Standby**: This is default state when device first registered. Device can change to **Standby** when device finishall works and report standby successfully. At this state, device will only send heartbeat but not be checked. Owner **CAN** close the device hardware or program at this state. ### **Dependency Server(Monitor)** Monitor is a dependent service also running in SGX environment which is responsible to keep monitor all chains that our server should handle. Monitor should synchronize chain blocks and check block correctness. \ Device will check the source transaction's existence from monitor server when meet a **Sign** mission for corss chain work. Device should set config of monitor type: 1. **Local**: Each device should run a local monitor for device, and device will register this to chain for more rewards. 2. **Public**: Device can check information from our official monitor but less rewards. This is default for device. Then device will: 1. Bind monitor info to chain at register process. 2. Check monitor chains' synchronize state p*eriodically*. **Local** mode will compare with **Public** monitor. If block height is not enough, device will not join work and it may be punished for influncing **Sign** work. 3. Check source chain transactions from monitor before **Sign** corss chain transactions. ### **Committee** Device's final target is to serve our **Committee**, let's talk about committee before device's concret work. **Committee** is a group of members runing MPC to maintain a secret key which is used to manage assets and it can sign for any message. To keep the secret key's safety, there will be multi forks of MPC members. A device may join multi forks for one committee using its temporary identity(mostly only one fork). Following pictrue is the committee's lifetime, the lifetime is defined as **GlobalEpoch**:
1. **EpochBlocks**: Total blocks of this **GlobalEpoch**. 2. **ApplyBlocks**: Blocks to apply committee's epoch change(**KeyHandover**). 3. **RvrfBlocks**: Blocks for devices send RingVRF proofs to send temporary i*dentity for this epoch*. 4. **ReserveBloks**: As the name, it is currently reserved. 5. **ChangeBlocks**: Blocks for committees' **KeyHandover** work. Device will report result if success. Withing **GlobalEpoch** changes, committe's members will handover secret keys by epoch. ### **Device Works** When device's state change to **Working**, it will mainnly do the following works by chain events: 1. **RingVRF**: Device should run generate RingVRF proof to generate a temporary identity to join current **GlobalEpoch**. The identity may be chosen to join some committees' work. 2. **KeyGenerate**: MPC work that chosen device with temporary identity should do. It will finally generate committee's secret keys and public key. The result will be signed and reported by one of the identities. 3. **KeyHandover**: For every **GlobalEpoch**, committee will try to share secret keys from old epoch identities to new epoch identities by MPC. If this success, the chain will generate event *pallet\_committee::event::ApplyEpochChange during* **ApplyBlocks**, and old identities will delete secret keys, new identities will take all MPC works of this committee. For creating period, fork 0 run **KeyGenerate** and then run **KeyHandover** to share secret keys to other forks. 4. **Sign**: This MPC work is triggered by many chain events(e.g. *pallet\_channel::event::NewTransaction*) and current epoch identities should handle this work. ### **Extend Read** #### **A. Device Consensus** There are two important state on chain: 1. **snapshots**: Collection of **EnclaveIds** of **Working** device. It is updated at start of each **GlobalEpoch**. 2. ***candidates***: Collection of temporary identities generated by devices' **RingVRF**. It is updated at the end of **RvrfBlocks** of **GlobalEpoch**. Devices should have a consensus of important chain state about **snapshots** and **candidates** for committees' **KeyGenearate** and **KeyHandover** works. This consensus **SHOULD** be confirmed for every **GlobalEpoch**. Why we need this consensus? At normal situation, committee's secret keys are distributed in different devices and the device's data are encrypted by SGX. But if a malicious owner who have multi devices want to get the full secret key of an committee. He may run the **Database Backup Attack**. **Database Backup Attack**: Device's work is proceed by chain events and the node for device is configured by owner. So a malicious device owner can: 1. Backup database for every **GlobalEpoch**. 2. After committee's next epoch change applied, devices will expose their identities to get rewards. 3. Malicious owner may find that his devices have enough keys to recover a full secret key for a specific committee(we choose committee members by random). 4. Malicious owner can send fake events and fake storage(e.g. **snapshot** and **candidates**) to their deviecs backup database and devices may run **KeyHandover** to share keys to some fake devices(created by the owner). **Consensus Process** **CourtMember**: The **snapshot** will be collected and will be member of court. This is decided by previous epoch consensus. 1. At the start of **GlobalEpoch**, the **snapshot** will be updated. **CourtMembers** of previous epoch will vote for the state of **snapshot**. If the votes is greater than half of pervious **CourtMembers**, the **snapshot** is confirmed for new **GlobalEpoch** and **snapshot** will be current **CourtMembers**. If the votes not enough, the **CourtMembers** of previous epoch will be the new **snapshot** and current **CourtMembers** will not change. 2. At the end of **RvrfBlocks**, current **CourtMembers** will vote for the state of **candidates**. If the votes is greater than half of current **CourtMembers**, the state is confirmed and all **KeyHandover** will choose members from **candidates**. If the votes is not enough, **candidates** will be cleared and device will not do **KeyGenerate** and **KeyHandover** works. If someone want to attact this system by **Database Backup Attack**, he should control at least more than half devices of specific epoch's **CourtMembers**. #### B. Device network and communication 1. Devices are connected by p2p network. But only registered device can join this p2p network since all device will verify corresponding peer's SGX attestation proof. 2. Device will keep broadcast heartbeat info to p2p network. Device should receive enough(more than half **CourtMembers**) heartbeats to join committee. Owner should ensure device's network is available. # SPV SPV plays a crucial security role in the overall system operation by preventing malicious signatures caused by fraudulent information sources . how it works: It registers on the blockchain through remote attestation , and then runs multiple blockchain light clients inside SGX to provide transaction verification services for the monitor . It uses a key generated by SGX to sign the response, and the monitor verifies the signature through the public key registered by SPV on the chain to ensure that the SPV's response originates from a genuine SGX program with specific code . There are two modes for SPV integration with the monitor: **public** and **local** . In **public mode** , all monitors can use the public SPV to verify transactions and validate the synchronization status of SPVs operating in **local mode** . In **local mode** , each monitor is paired with a dedicated SPV to ensure decentralization of verification sources and mitigate risks from malicious validators. The public mode's role in cross-validation aligns with SPV-based structural arrangements for unified supervision, as seen in financial infrastructure projects. The local mode's emphasis on decentralization reflects SPV design principles in distributed systems, such as those in blockchain projects, to prevent single points of failure. Each light client is built on the open-source implementation of its corresponding blockchain to ensure security , adhering to the security requirements specified in protocols like bitcoin spv and ethereum light client solution. #### Security Assurance **1. Intel SGX Remote Attestation Overview** Intel SGX Remote Attestation is a critical security feature that enables verification of the authenticity and integrity of an enclave running in an untrusted environment. This process involves three core components: the application's enclave, the Intel-provided Quoting Enclave (QE), and the Provisioning Enclave (PvE) . The attestation workflow ensures that only trusted enclaves—verified by Intel's architecture—are allowed to operate, establishing a foundation for secure computation even when the underlying OS or infrastructure is compromised. **2. Intel SGX Key Architecture** Intel SGX utilizes a layered key hierarchy to protect sensitive data. A **Secret Key** (e.g., the *Processor Root Key* ) is derived dynamically during each system boot to encrypt memory contents, reducing risks if the key is exposed. Additionally, enclaves can generate cryptographic key pairs for specific operations (e.g., signing or sealing data). These keys are isolated within the enclave and never exposed externally, ensuring confidentiality and integrity. **3. Registering the Public Key (PK) on the Blockchain** To enable trustless verification, the public key (PK) corresponding to the SGX-generated secret key is registered on a blockchain. This process typically involves: * **Remote Attestation Integration** : The enclave connects to an Intel-certified Remote Attestation server (e.g., Fireblocks' SGX service) to retrieve and bind the secret key securely. * **Blockchain Registration** : During the on-chain registration process, nodes verify the **remote attestation** and validate the **enclave measurement hash (MRENCLAVE)** to ensure that only programs with the **specific, pre-approved code** can pass verification. The PK is stored immutably on the blockchain, acting as a tamper-proof reference for verifying data origins. **4. Signing Data with the Secret Key and Blockchain Verification** Once the PK is registered: * The enclave uses its secret key to sign data (e.g., transaction payloads or computations) internally. * The signature and public key (PK) are appended to the response of the monitor's request. The monitor can verify the authenticity using the PK pre-registered on the blockchain, ensuring that the response content was generated within the SGX enclave, preventing forgery or tampering. This workflow combines SGX's hardware-backed security with blockchain's decentralized trust model, ensuring end-to-end integrity and authenticity guarantees. **Scheme of verification of each chains** 1. **BTC's SPV (Simplified Payment Verification) Scheme** * SPV allows lightweight Bitcoin clients to verify transactions without downloading the entire blockchain. * It works by downloading only **block headers** (80 bytes per block) and using **Merkle proofs** to confirm a transaction's inclusion in a specific block. * SPV nodes rely on full nodes to provide transaction data and proofs, but they independently validate the blockchain's consensus rules (e.g., proof-of-work, chain difficulty). * Security trade-offs: Vulnerable to **long-range attacks** if malicious full nodes withhold or falsify data, requiring SPV clients to connect to multiple peers for redundancy. 2. **Ethereum's Light Client Protocol** * Ethereum light clients (e.g., **Light Ethereum Subprotocol / LES** ) enable devices to interact with the network while storing only **block headers** and critical state data. * They verify **header chain validity** (via PoW/PoS consensus) and request specific data (e.g., account balances, smart contract states) from full nodes, which are cryptographically authenticated using **Merkle Patricia Trie proofs** . * In **EIP-4895** (post-Merge), light clients rely on **sync committees** (randomly selected validator subsets) to validate beacon chain headers and cross-check execution layer data. * Security: Requires trust in the **honesty of at least one honest full node** ; mitigated via randomized peer sampling and fraud proofs in Layer 2 contexts. # RingVRF **Overall** In this project, committee members need to be rotated to achieve time-limited security for private key shards. Therefore, a method is required to select different batches of committee members. Simultaneously, the identities of committee members must be kept confidential to prevent them from colluding with each other and launching attacks against signatures. Thus, a method is needed to identify committee members holding specific private keys without revealing their identities. **Core Objectives** 1. **Secure Committee Rotation**\ Enables periodic rotation of committee members holding private key shards for time-limited security. 2. **Identity Confidentiality**\ Prevents committee member identification to avoid collusion attacks on signatures. 3. **Anonymous Key Ownership Proof**\ Allows a member to prove their public key belongs to a specified set without revealing which one. > **In essence**: Ring VRF lets a user prove their public key is in set {pk₀,...,pkₙ₋₁} and generate verifiable random output `v` using private key `sk`, while **hiding their specific public key index** `ℓ`. so we introduced **Ring VRF algorithm.** **The purpose of the Ring VRF algorithm is:** To allow a user to prove that the public key corresponding to their private key exists within a set of public keys, **without revealing which specific public key they possess.** RVRF = {((pk0, . . . , pkN−1 , r, v),sk, )|∈ {0, . . . , N − 1} s.t. (pk\` ,sk) ∈ Rpk ∧ v ← PRFsk(r)} The inputs to the algorithm are a **public set of public keys** and a **random number**. Pedersen commitment is used as the commitment scheme. The algorithm achieves its core functionality **by utilizing** the one-out-of-many protocol. Additionally, a **sub-proof** guarantees that both the commitment value `c` (from the Pedersen commitment) and the PRF result `v` correspond to the same private key (`sk`). **Algorithm Definition** **Inputs/Outputs** * **Input**: * Public key set {pk₀,...,pkₙ₋₁} * Random seed r ∈ {0,1}\* * **Output**: * Random value `v = PRFₛₖ(r)` * Proof `π` verifying both: 1. `pkₗ ∈ {pk₀,...,pkₙ₋₁}` for some `ℓ` 2. `v` was correctly generated from `sk` #### **Key Components** **1. Pseudorandom Function (PRF)** * **Definition**: `PRFₛₖ(r) := H(r)ˢᵏ` * **Parameters**: * Cyclic group `G` of prime order `q` with generator `g` * Hash function `H: {0,1}* → G` * **Security**: Computes verifiable random output bound to `sk`. **2. Pedersen Commitment** * **Role**: Hides prover's index `ℓ` and secret `sk`. * **CRS**: Commitment key `ck = h` (public parameter). **3. One-out-of-Many Protocol** * **Core innovation**: Proves `∃ℓ` such that `pkₗ ∈ {pk₀,...,pkₙ₋₁}` without revealing `ℓ`. * **Achieves**: Full anonymity within the public key set. **4. Consistency Sub-Proof** * **Critical guarantee**: Links Pedersen commitment `c` and PRF output `v` to the **same private key `sk`**. * **Prevents**: Forgeries using mismatched keys. #### **Protocol Workflow** **Prover (sk holder)**: 1. Compute `v = H(r)ˢᵏ` 2. Generate Pedersen commitment to `sk` 3. Use **One-out-of-Many** to prove `pkₗ ∈ {pk₀,...,pkₙ₋₁}` 4. Run **sub-proof** linking commitment and `v` to `sk` 5. Output `(v, π)` **Verifier**: 1. Validate One-out-of-Many proof (key membership) 2. Verify consistency between commitment and `v` 3. Confirm `v` is correctly derived from `r` # Introduction to TEE A Trusted Execution Environment (TEE) is engineered to assure the confidentiality and integrity of computations. It constitutes an isolated compartment capable of storing sensitive data and issuing attestations to verify the accuracy of computations. In practice, Intel SGX and ARM Trustzone are popular candidates of TEE. Key Characteristics of TEE: * Isolation: Code and data inside the TEE are isolated from the rest of the system. * Integrity: Ensures that the computations performed are not tampered with. * Confidentiality: Protects sensitive data from being exposed during computation. Although a few side-channel attacks have been explored against those TEE candidates, new designs and fixes are proposed on a monthly basis. Hence, We uses TEE as an acceptable hardware shield to ensure privacy and logical correctness of key component data. In our research, our benchmarks are executed on the Intel SGX platform for its readily deployed remote attestation infrastructure; however, we emphasize that our protocol can also be implemented on any other TEE platforms. ## Device remote Attestation Device remote attestation is a crucial security process that allows a relying party, such as a server or service, to verify the authenticity of a specific device. In the context of cybersecurity, attestation serves as a means to ensure that a device is genuine, has not been tampered with, and is operating as expected. This process is particularly important for devices that play a critical role in user authentication and data protection, such as hardware security keys. The attestation process typically involves the generation of an attestation statement by the device, which includes a cryptographic signature and other metadata. The relying party then verifies the attestation statement by checking the cryptographic signature and metadata, confirming that the statement came from a genuine device. This verification process provides an added layer of security, ensuring that only trusted devices can access sensitive information and services. ## On-chain Device Remote Attestation In the traditional device attestation process, a relying party, such as a server or service, is responsible for verifying the authenticity of a device. However, this approach has limitations in terms of transparency and accessibility. To address these issues, we have implemented a novel approach by replacing the relying party with an on-chain contract. In this new model, the attestation statement generated by the device is verified and stored on a blockchain. This approach offers several advantages: * It provides a transparent and tamper-proof record of the attestation, as the attestation statement is immutably stored on the blockchain. * It allows anyone to publicly access and verify the attestation statement, enhancing the trustworthiness of the attestation process. By leveraging the decentralized and secure nature of blockchain technology, we can ensure that the device attestation process is more robust, transparent, and accessible to all.
# Getting Started Welcome to DeepSafe! ### Overview Here are the key steps to familiarize yourself with **DeepSafe**: 1. [**Network Information**](/develop-guide/network-configuration)**:** Get to know the chain configuration information of DeepSafe. 2. [**Wallet Setup**](/develop-guide/wallet-setup)**:** Set up your EVM wallet like MetaMask to handle Token(DEF) on DeepSafe. ### Node Related 1. [**Hardware**](/develop-guide/hardware): Get to know the requirements of the hardware for the node and CRVA. 2. [**CRVA Maintaining**](/user-guide/crva-maintaining): How to set up the code script of node service step by step. 3. [**CRVA Farming**](/user-guide/crva-farming): How to run or join the node service and manage the node. ### Useful Links * Explorer： Blockchain Explorer: CRVA Explorer [https://scan.deepsafe.network/crvas](https://scan.deepsafe.network/dhcs/) CRVA Farming # CRVA Maintaining ### Create Wallet Account You can create a new wallet address directly within the browser plugin wallet like MetaMask and export the private key for later use. ### Remote SSH server login To log into the SSH server via the account password set when purchasing the server and the public IPv4 address automatically assigned to the instance by the cloud service provider. **Option 1.** The built-in system terminal: * For Mac systems and native Linux systems, you can use the built-in terminal simulator to log in. * For Windows systems, you can use the built-in PowerShell tool to log in. You need to run PowerShell as administrator and install the OpenSSH plugin. The plugin installation tutorial link is as [**Get started with OpenSSH for Windows**](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=powershell) login Method: After opening the terminal, enter "ssh username\@public IP address" (e.g. ssh test\@1.1.1.1), then enter the password according to the prompt to complete the login. **Option 2.** The third-party SSH login tools: Third-party SSH login tools such as Xshell, PuTTY, SimpleRemote, Terminus, etc. You can refer to the relevant product tutorials to log in by yourself. **Option 3.** The built-in server method of cloud service: Different cloud service providers may provide their online server management consoles, through which you can log in graphically, such as logging in to EC2 instances on Amazon Web Services through the EC2 console page. Please refer to the help documents provided by each cloud service provider.
### Install runtime environment ```powershell # Install the Docker runtime environment sudo curl -fsSL https://get.docker.com | bash -s docker sudo systemctl enable docker sudo systemctl start docker # Check if the Docker service started correctly sudo systemctl status docker # Use "ctrl+c" to resume command status sudo chmod 666 /var/run/docker.sock docker version # Download the docker-compose program sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose # Install docker-compose sudo chmod +x /usr/local/bin/docker-compose docker-compose --version ``` ### Create a node storage directory and startup file {% hint style="success" %} Exposing the node's external IP is important to increase CRVA's stability ``` --public-addr ... Public address that other nodes will use to connect to this node. This can be used if there's a proxy in front of this node. PUBLIC_ADDR example: "/ip4/8.8.8.8/tcp/30333" ``` {% endhint %} ```powershell # Create a node storage catalog mkdir -p bool-beta-testnode/node-data # Enter the node storage catalog cd bool-beta-testnode # Adjust user permissions chmod 777 node-data # Add a configuration file # You can also use "cat > docker-compose.yaml" first and then use "vim docker-compose.yaml" # Then paste the the remaining code between "< docker-compose.yaml < ports: - 9944:9944 - 30333:30333 EOF # Start the service docker-compose up -d ``` Synchronizing blocks will take more time, and we provide snapshots to speed up chain startup. Reference run a chain via snapshot. To confirm whether the node has synchronized to the latest height, you can use the log command `docker-compose logs -f --tail 200 | grep finalized` to check if the `finalized` height has reached the `target` height. If it has, the synchronization is successful. {% hint style="info" %} Some of the built-in terminals will recognize space characters as indent characters during code copying, which may lead to YAML program runtime errors. Please check and replace it. {% endhint %} ### Configure the sgx server ```powershell # Back to root catalog cd .. # Pull github repositories git clone https://github.com/deepsafe/def-mining-scripts.git # Install the sgx driver apt update apt install build-essential automake autoconf libtool wget python libssl-dev dkms wget https://download.01.org/intel-sgx/latest/linux-latest/distro/ubuntu18.04-server/sgx_linux_x64_driver_1.41.bin bash sgx_linux_x64_driver_1.41.bin # View sgx status cd def-mining-scripts && ./sgx-detect ``` ### Modify keyring.toml configuration file Please check out the latest CRVA bootnodes **here** in advance and do the replacement if changed. {% hint style="info" %} **`external_multiaddrs:` Exposing the server's external IP is important, thereby increasing the reward.** ``` example: external_multiaddrs = ["/ip4/127.0.0.1/tcp/38700"] ``` {% endhint %} ```powershell # Enter the configuration mode of keyring.toml file vim configs/keyring.toml # Modify the file internally as follows: node_ws_url = "ws://127.0.0.1:9944" # import your wallet public address starting with "0x" and do the replacement device_owner = "0x0000000000000000000000000000000000000000" # database path db_path = "/host/data" # tokio console port console_port = 5555 #This corresponds to using an image, epid=1, dcap=2 attestation_style = 2 exe_policy = { Multiply = { executors = 8 } } # database start option [db_option] create_if_missing = true atomic_flush = true [network_config] port = 38700 boot_nodes =["/ip4/172.210.130.200/tcp/38701/p2p/12D3KooWQBrkBWb3tLoUpxqXebxg1Eab24LfcFP3hv37ZF2c6qgz","/ip4/20.81.161.179/tcp/38701/p2p/12D3KooWMDqap7HMjA6nos1HpHpWt8JBcPepnZgYSd5PPmovAqD7"] share_peer_interval = 30 only_global_ips = true protocol_id = "betatestnet" #external_multiaddrs = ["/ip4/127.0.0.1/tcp/38700"] ``` ### Modify sgx\_default\_qcnl.conf file {% hint style="warning" %} Try the local solution [**here** ](/user-guide/crva-maintaining/local-lan-configuration-for-sgx)if you can't find the solutions for the cloud services below. {% endhint %} ```powershell # Enter the configuration mode of qcnl.conf file vim configs/sgx_default_qcnl.conf # Modify the file internally as follows: # Ali Cloud # [Region-ID] is the region of the server you purchased, like cn-hongkong and etc. # you can refer to https://help.aliyun.com/document_detail/140601.html { "pccs_url": "https://sgx-dcap-server.[Region-ID].aliyuncs.com/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } # Tencent Cloud { "pccs_url": "https://sgx-dcap-server-tc.bj.tencent.cn/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168, "verify_collateral_cache_expire_hours": 168 } # Microsoft Cloud { "pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/", "use_secure_cert": true, # To accept insecure HTTPS cert, set this option to FALSE "retry_times": 6, "retry_delay": 10, "pck_cache_expire_hours": 168 } ``` ### Modify docker-compose file (Optional) You need to change the configuration here and replace the "\" underneath only when the official image version is updated, please refer to this link for the exact version information. {% hint style="info" %} Before changing version numbers, make sure your device is in Standby status, or not registered. Otherwise, you will be punished. {% endhint %} The latest version of the image is: [**v0.12.19**](https://github.com/deepsafe/def-mining-scripts/blob/master/docker-compose.yml#L5) ```powershell # Enter the configuration mode vim docker-compose.yaml # Modify the file internally as follows: version: "3" services: def-occlum-keyring: image: deepsafe/def-occlum-keyring: restart: always network_mode: "host" environment: RUST_LOG: info,p2p_net=debug volumes: - ./configs:/configs - ./data:/root/occlum_instance/data - ./configs/sgx_default_qcnl.conf:/etc/sgx_default_qcnl.conf devices: - /dev/sgx/enclave:/dev/sgx/enclave - /dev/sgx/provision:/dev/sgx/provision command: bash -c 'cp /configs/keyring.toml /root/occlum_instance; apt update;apt install curl -y;source /root/.bashrc; cd /root/occlum_instance; occlum print mrsigner; occlum print mrenclave; occlum run /bin/bnk-watcher run /host/keyring.toml' ``` ### Start CRVA Service ```powershell # Start CRVA service docker-compose up -d # View node service Logs docker-compose logs --tail 200 -f # Check P2P connection Logs docker-compose logs --tail 200 -f |grep 'Current peers' ``` ### Update Device Version Please maintain your image of the CRVA server by updating it with the latest official version. You can follow this step by step: #### 1. Exit the service Device upgrades must be performed on "**Standby"** status. If the device is on "Serving" status, it must be exited before starting the upgrade. If the device is on "Exiting" status, wait up to one day until the process is complete before proceeding. #### 2. Update the script file ```powershell # Shut down the script and back up your data docker-compose down && mv data/ data-bak/ # Replace the image version of the device # 0.12.x is your current version and 0.12.0 is the latest version sed -ri 's/0.12.x/0.12.19/g' docker-compose.yaml # Restart the service docker-compose up -d ``` Then check out the version of your device on the [**Node Explorer**](https://dhc.boolscan.com/beta_testnet/).
#### 3. Rejoin the service You can join the service again after all the steps above are done and wait until the device changes to "Serving" status. #### 4. Remove backup data (Optional) ``` rm -rf data-bak/ ``` ### Case Study If you're facing problems in the setup process, try to find a solution [**here**](/user-guide/case-study). # Local LAN Configuration for SGX To realize local LAN Configuration for SGX, you need to start a local LAN PCCS service locally or on the LAN, and then change the `pccs_url` in the `sgx_default_qcnl.conf` file on all local CRVAs to the local LAN PCCS link (for example, if the PCCS service is deployed on `host1`, then it should be "pccs\_url": ""). You may refer to the steps for more details: ### Applying for an Intel API Key You'll need to acquire an Intel API key to utilize Intel's Software Development Kit (SDK) for Intel SGX (Software Guard Extensions). This key grants you access to Intel's resources and enables you to develop and deploy SGX-based applications. **Steps:** 1. **Create an Intel Developer Zone Account:** If you don't already have one, create an account on the Intel Developer Zone website. 2. **Navigate to the Intel API Key Management Page:** Once logged in, go to the Intel API Key Management page. 3. **Select the "Intel SGX SDK" Product:** Choose the "Intel SGX SDK" product from the list of available products. 4. **Provide Required Information:** Fill out the requested information, including your name, organization, and project details. 5. **Submit the Request:** Review the information you've provided and submit the request. Intel will evaluate your request and notify you of the outcome. {% embed url="" %}
### Installing a Local LAN PCCS Service ```powershell Ubuntu18.04： curl -fsSL https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu $(lsb_release -cs) main" sudo curl -sL https://deb.nodesource.com/setup_16.x | sudo bash - sudo apt-get install -y nodejs sudo apt install cracklib-runtime -y sudo apt-get install sgx-dcap-pccs libsgx-dcap-default-qpl systemctl status pccs Ubuntu24.04: sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential curl wget openssl libssl-dev pkg-config sudo echo 'deb [arch=amd64] https://download.01.org/intel-sgx/sgx_repo/ubuntu focal main' | sudo tee /etc/apt/sources.list.d/intel-sgx.list curl -fsSL https://download.01.org/intel-sgx/sgx_repo/ubuntu/intel-sgx-deb.key | sudo apt-key add - sudo apt update curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs=20.11.1-1nodesource1 sudo apt install cracklib-runtime -y sudo apt install -y sgx-dcap-pccs libsgx-dcap-default-qpl systemctl status pccs ```
During the installation process, enter the API key you applied for earlier, and set a password for PCCS. Here, we will use "pccs12345678" as an example.
Once you have completed the above steps, you can skip the remaining steps by simply pressing the Enter key.
If you encounter a situation during installation where it prompts that the password is too weak, don't worry. Just keep pressing the Enter key. After exiting, reinstall pccs, and this issue should not occur again.
The above steps indicate that the PCCS service installation is complete. However, upon restarting the service, the following error message is encountered:
#### Solution: Step 1. Install the register tool for SGX ```powershell sudo apt install sgx-pck-id-retrieval-tool ``` Step 2. Modify the configuration file ``` cat /opt/intel/sgx-pck-id-retrieval-tool/network_setting.conf ``` PCCS\_URL=
Step 3. Use the PCK ID Retrieval Tool ``` PCKIDRetrievalTool ```
``` systemctl status pccs ```
Step 4. Enable the SGX function If the error message persists, you may need to reseat the motherboard battery, reset the machine's BIOS, and re-enable the SGX feature, as shown in the following image:
Step 5. Run the PCK ID Retrieval Tool Keep running the tool until the registration has been done.
Step 6. Start the CRVA processes Once SGX registration is successful, you can start the CRVA processes. However, due to data caching, you may encounter the following error message upon the first attempt:
Try more attempts until the registration has been done.
# Run a chain via snapshot ## Workflow of running a chain node * Download snapshot Method 1: ``` wget https://chain-snapshot-data.bool.network/beta-testnet-node-snapshot-latest.zip ``` * Replace data beta-testnet-node-snapshot-latest.zip has been downloaded. Unzip the beta-testnet-node-snapshot-latest.zip to the specified chain node data directory, replace the original data directory node-data, and then restart the chain service node. Assume that your link node data directory is `~/bool-beta-testnode` ``` mv ~/bool-beta-testnode/node-data ~/bool-beta-testnode/node-data_old unzip beta-testnet-node-snapshot-latest.zip -d ~/bool-beta-testnode/ ``` * (Optional) Modify docker-compose.yaml Modify the node's docker-compose.yaml configuration to remove `--state-pruning archive` and `--block-pruning archive` ``` sed -i '/--state-pruning archive/d;/--blocks-pruning archive/d' docker-compose.yaml ``` * Start the chain service node ``` docker-compose up -d ``` # CRVA Farming For [CRVA Farming](https://crva.deepsafe.network/beta_testnet), there are two type of roles which called "Owner" and "Voter". * Owner is the person running the CRVA, which can be the project owner, KOL, community leader, etc. * Voter is the person who delegates his/her DEF to the node for farming DEF staking rewards. User can choose to be a owner or a voter or both. {% content-ref url="/pages/kZwgRJ0bDMwvFp2SBrtk" %} [For CRVA Voter](/user-guide/crva-farming/for-crva-voter) {% endcontent-ref %} {% content-ref url="/pages/BYV0UANUB84zoZCQuZhZ" %} [For CRVA Owner](/user-guide/crva-farming/for-crva-owner) {% endcontent-ref %} # For CRVA Voter Any token holders can participate in the voting progress of CRVAs to share the staking rewards by delegating their token.
### Vote CRVAs Click on the "Vote" button on the right of the statistics cards, select the CRVAs that need to participate (single selection only), input the quantity of token delegating on the node, and submit a voting transaction. Please be aware of the voting limits below. * The maximum quantity for a single CRVA is **3000 voters** * The minimum voting quantity of each CRVA is **200 DEF** Note: Only the CRVAs selected on-chain as the committee nodes will receive the era income and the voters will receive token rewards depending on their staking rate. Choose wisely if you want to farm the maximum return from your staking. Here are some useful tips for you: * "Standby": Consider it as a community support option. * "Service": It is a wise option for all new voters as you can start farming ASAP from the next rewards era. * "Exiting": Forget about it. It is a bad option if you are not an Owner.
### Change Staking Click the "Update" button on the list, then change the staking amount down or up depending on your needs and submit a transaction on chain. Click the "Unstake All" button to unstake all your staking amount from the node.
Note: the changes will only take effect on-chain until the next era. Please be patient for waiting up to about **60 minutes** if you choose to raise the staking amount. However, if you choose to reduce the staking amount, you should to claim it manually after **24 hours**. ### Rewards Distribution In each reward era, the staking rewards will be given automatically to the wallet address, depending on the share percentage of the total staking. # For CRVA Owner
### List Devices After completing the configuration with the cloud server, you can use the **CRVA dashboard** to configure your device. The system will automatically show the device of the corresponding cloud server according to the connected wallet address (DEF is required as the gas). The default status is "Standby". ### Stake CRVA Option 1. Click the "Launch" button in the device's menu and the system will automatically calculate the remaining token to meet the requirement for the CRVA. Option 2. Click the "Vote" button to vote 20000 DEF for the node you own. Option 3. Click the "Vote" button to start with 10000 DEF and wait for other voters to join the crowdfunding progress until 100%. Please be aware of the node limits below. * The minimum staking for a CRVA's Owner is **10000 DEF** * The minimum requirement for a CRVA to join the service is **20000 DEF** ### Join Service When the node staking threshold is met, the node service of the current device can be formally activated by clicking the "Join Service" button in the device's menu. Then the device will turn into the "Service" status, which means it has joined the CRVA network. Note: the image version of the device must be the [**latest**](https://github.com/boolnetwork/mining-scripts/blob/master/docker-compose.yml) or the device will not be able to join service. ### Checkout Rewards If the node operates without anomalies such as disconnections, the node rewards will be released automatically at the end of every reward era. You can check out the total rewards on the statistics cards and the device rewards from the device list respectively. Note: The reward distribution ERA of CRVAs is **1,200 blocks**, about **60 minutes**. ### Manage Device Users can perform the administrative operations such as: * "Launch": do a quick staking to meet the minimum requirement of the device for the owner; * "Transfer Device": transfer the permissions of CRVA and the staked tokens to others together; * "Bond Stake ID": bind the DID of this device to another SID so as to use the staked amount of the other SID; * "Join Service": join the current device to the CRVA network. Please note that your device must be updated to the latest version or it may fail to join the service. The button will be displayed when the minimum requirement for a CRVA to join the service is done; * "Update Commission": change the commission rate. The higher the rate is, the more rewards will be distributed to the owner's address; * "Refuse New Voters": stop receiving the stakings from new voters; * "Allow New Voters": allow receiving the stakings from new voters; * "Remove Device Voters": remove the voters from the current ; * "Exit Service": apply to exit the current device from the CRVA network. The button is only displayed in the "service" status; * "Remove Device": shun down the device from the CRVA lists in any status. Here are the consequences:\ 1\. **1000 DEF** will be charged as the punishment which will be deducted from the owner's staking shares if you perform in the status of "Service" or "Exiting" as a force quit.\ 2\. All the staking of DEF will be returned to the voters' wallet address.\ 3\. The current device will be removed from the CRVA device lists.\ 4\. All the node income of the current era collected on-chain will be **burned directly as a punishment**. Note: The operations like "Launch", "Update Commission" and "Remove Device Voters" above need to wait until the next rewards era to be activated. ### Stop Service Please follow the following steps one by one if you want to stop the node service: 1. The owner can exit the CRVA network by **"Exit service"** to change the device status to "Exiting" **without penalty** or perform a forced quit directly by **"Remove Device" with a forced quit penalty** to get the refund immediately. 2. If you choose to exit without penalty, you will need to wait up to **one day** which is 144 heartbeat circles to complete the exiting process and the device status will be changed to "Standby". 3. Click the **"Remove Device"** button to remove your device and get your DEF refund from the current device. Removing the device with **"Standby"** status **will not incur a penalty**. 4. Shut down the physical device or the cloud server when all the above actions are completed. You can log in to the cloud service client like Microsoft Cloud and delete the virtual machine you purchased to prevent the cloud service provider from deducting fees. ### The Punishment Here are some important rules for the owner: * Disconnect Penalty: The device is required to keep the heartbeat connections per heartbeat cycle which lasts **10 mins**. The failure of disconnection for more than **2 heartbeat cycles** will result in a penalty of **0.5DEF** per heartbeat cycle. The penalty will be only charged to **the owner**. * Forced Quit Penalty: **1000 DEF** will be charged as the forced quit penalty when the owner decides to perform "Remove Device". The penalty will be only charged to **the owner**. * Automatic Exit: The system will auto-perform "Exit Service" for the devices that disconnect for more than **10 heartbeat cycles**. However, the device with the exiting status still needs to submit heartbeat connections. # Case Study ### Case 1
```jsx git clone https://github.com/occlum/enable_rdfsbase.git cd enable_rdfsbase make && make install #if still error，remake && reinstall ``` ### Case 2
* Mirror is incorrect. * Curl is not installed in the container. ### Case 3
* Install curl within the container. * Missing sgx\_default\_gcnl.conf or sgx\_default\_qcnl.conf file ### Case 4
* Mirror version is not correct, please check the mirror ID. * Wrong version ### Case 5
Mirroring is wrong, this time apply epid mirroring on Azure. ### Case 6
Configuration file error, private key length is not correct. ### Case 7
Check current configuration of max\_map\_count: `cat /proc/sys/vm/max_map_count` Not persistent way to modify the max\_map\_count: `sysctl -w vm.max_map_count=3097152` To make the changes persistent you should modify `/etc/sysctl.conf` and then (optionally) execute `sysctl -p` to apply the changes without reboot ``` echo "vm.max_map_count=3097152" >> /etc/sysctl.conf sysctl -p ``` ### Case 8
If you are using the v0.11.9 image version of CRVA, the Linux kernel version of the Operating System must be greater than 6.2. Another option is to reinstall the operating system, using at least 22.04 Ubuntu version. ### Case9
If the "current peers" is **0**, it means your device can not be connected through the P2P network. You should check the internet connection and the public IP first. Then you should check the security configuration of the cloud service which you can refer to the official docs for help. ### Case 10
For images with versions greater than `v0.12.8`, you need to add the `run` command to the startup command line, for example `occlum run /bin/bnk-watcher run /host/keyring.toml`. ### Case 11
If you are using Ubuntu 24.04, you might encounter the `libssl.so.1.1: cannot open shared object file` error when running the ./sgx-detect script. This issue arises because the system lacks the OpenSSL 1.1 library. Ubuntu 24.04 uses OpenSSL 3.0 by default, but some programs may still rely on the older OpenSSL 1.1 version. Forcing the installation of OpenSSL 1.1 might cause other issues, so it's advisable to disregard this problem. ### Case 12
When encountering the above issue, it is likely because the image has not been pulled. To resolve this, execute `docker pull hub.bool.network/deepsafe/def-node:v0.11.9` to download the image. Subsequently, execute `docker tag hub.bool.network/deepsafe/def-node:v0.11.9 deepsafe/def-node:v0.11.9` to modify the image name to correspond with the configuration file docker-compose.yaml. Then, run `docker-compose up -d` again and use `docker-compose logs -f --tail 200` to check the logs and ensure the application is running normally. # Guardian NFTs ### What is a Guardian NFT? A **Guardian NFT** is your exclusive access pass to becoming a **CRVA (Cryptographic Random Verification Agent)** node operator in the DeepSafe Network — the world’s first cryptographic random verification layer powered by advanced technologies like **ZKP**, **Ring VRF**, **MPC**, and **TEE**. By acquiring a Guardian NFT, you unlock the right to operate a CRVA node, joining an elite group of **400** blockchain guardians who support and secure DeepSafe’s decentralized verification network. #### Key Highlights * Limited Supply: Only 400 Guardian NFTs are available. * Node Ownership: Each Guardian NFT, combined with a TEE server, grants the right to operate one CRVA node. * Bonus Rewards: Refer others to earn Bonus NFTs (max supply: 400). * Token Airdrop: 100,000 DeepSafe tokens per Guardian NFT, with a 1-year lock + 1-year linear release. * Future Privileges: Eligible for all future DeepSafe ecosystem airdrops. * Tradable & Transferable: All NFT benefits are transferable. *** ### How to Purchase Guardian NFTs? Follow these steps to acquire a Guardian NFT in the DeepSafe Network: {% content-ref url="/pages/kL0NsJq0pLtCiE2Qhhl1" %} [Prerequisites](/genesis-nodes/guardian-nfts/prerequisites) {% endcontent-ref %} {% content-ref url="/pages/Z8IrnDSchtXApy7gtftq" %} [User Guide](/genesis-nodes/guardian-nfts/user-guide) {% endcontent-ref %} # Prerequisites Before participating in the Guardian NFTs purchase, please make sure you have completed the following: ### 1. Apply for the whitelist Ensure you have successfully applied and been approved for the DeepSafe whitelist. ### 2. Set up a supported EVM-compatible wallet You will need a wallet that supports EVM networks, such as [**MetaMask**](https://metamask.io/). {% hint style="warning" %} **Note**: You must prepare a **brand-new EVM wallet** that **has never interacted with DeepSafe or any DeepSafe-related ecosystem projects**. {% endhint %} ### 3. Connect to the BSC Network In your MetaMask wallet, switch to the **Binance Smart Chain (BSC) network**. {% hint style="success" %} Not sure how to switch to the BSC network? Check out [How to Add Binance Smart Chain (BSC) in MetaMask](/genesis-nodes/wallet-setup/how-to-add-binance-smart-chain-bsc-in-metamask). {% endhint %} ### 4. Prepare BNB for Gas Fees Make sure you have a sufficient amount of **BNB** in your wallet to cover transaction gas fees. ### 5. Prepare USDT for Payment Ensure you have enough USDT ready for the purchase. {% hint style="success" %} Make sure to use the correct USDT contract address on BSC: [**0x55d398326f99059fF775485246999027B3197955**](https://bscscan.com/token/0x55d398326f99059fF775485246999027B3197955). Please verify the address carefully before proceeding. {% endhint %} ### 6. Import USDT into MetaMask If USDT is not already displayed in your MetaMask, manually import it by adding the above USDT contract address on BSC. {% hint style="success" %} If USDT is not displayed in your MetaMask, you need to manually import it by adding the USDT contract address on BSC. \[[Learn how to import USDT into MetaMask →](/genesis-nodes/wallet-setup/how-to-import-usdt-into-metamask-bsc)] {% endhint %} ### 7. Have your DeepSafe Invitation Code ready An invitation code is required to complete your purchase. # User Guide Follow these steps after completing the prerequisites to purchase your Guardian NFTs. ## Step 1: Open Purchase Page & Connect Wallet You have two options: ### **Method 1: Use Invite Link** * Paste your **inviter’s link** into your browser (*e.g.,* [*https://deepsafe.network/guardian?inviteCode=BVD39M*](https://deepsafe.network/guardian?inviteCode=BVD39M))

Open the purchase page via invite link

* Click **Connect Wallet** in the top right corner. * Choose **MetaMask**. * Confirm the connection request in the MetaMask popup.

Connect your wallet

Choose MetaMask

Confirm the connection

* Click **Sign In** on the Guardian NFTs page. * In the MetaMask popup, confirm the signature request (Message: “Welcoming! + login + nonce”).

Sign to log in

Confirm the signature

### **Method 2: Manually Enter Invite Code** * Enter the [Guardian NFTs purchase page](https://deepsafe.network/guardian).

Enter the purchase page

* Click **Connect Wallet** in the top right corner. * Choose **MetaMask**. * Confirm the connection request in the MetaMask popup.

Connect your wallet

Choose MetaMask

Confirm the connection

* Enter your **invite code** (e.g., BVD39M) manually on the site and click “**Sign In**” on the Guardian NFTs page. * In the MetaMask popup, confirm the signature request (Message: “Welcoming! + login + nonce”).

Manually enter invite code and click Sign In

Confirm the signature

## Step 2: Purchase Guardian NFTs * Click **Pay**. * Confirm the spending cap (**15,000 USDT**) and [**Mint Contract Address**](https://bscscan.com/address/0xf6f63AD36fa7bbC771Ae133Dd01f750958E3228A) in MetaMask. * Approve and confirm the transaction. {% hint style="warning" %} **DeepSafe NFT Mint Contract (BSC):** **0xf6f63AD36fa7bbC771Ae133Dd01f750958E3228A** {% endhint %}

Click Pay

Confirm spending cap

Confirm payment

## Step 3: Purchase Successful * A Transaction Successful popup will appear. * Click **View tx** to view details on [BSCScan](https://bscscan.com/) (optional). * In a few moments, you can view your **Guardian NFT** under **My Assets**. * You can also click the Guardian NFT in My Assets to be redirected to BSCScan and view the detailed NFT information. > *Note: BSCScan may not display the NFT video properly due to its interface limitations.* {% hint style="warning" %} **Guardian NFT Contract Address (BSC):** **0x6957AB51703cB693535bA5fb9D670E8B6fC13B26** {% endhint %}

Purchasing in progress

Purchase completed

Guardian NFT details on BSCScan

*** ## Bonus Opportunity After purchasing a Guardian NFT, you will receive a **unique invite code**.

Get invite code & earn Bonus NFTs

By inviting others, you may be eligible to receive **Bonus NFTs**. 👉 [Learn more about **Bonus NFTs**](/genesis-nodes/bonus-nfts) *** ## Notes * You can only purchase **1 Guardian NFT per transaction**, but **multiple purchases** are allowed. * The total community-available supply of Guardian NFTs **varies per batch**, with an overall **maximum cap of 400**. * Stay updated on Guardian NFT availability and announcements by following [**DeepSafe’s official website**](https://deepsafe.network/), [**Twitter**](https://x.com/DeepSafe_AI), [**Telegram**](https://t.me/DeepSafe_Official), and other social channels. # Bonus NFTs ### What is a Bonus NFT? A Bonus NFT is a transferable reward NFT granted to users who successfully invite others to purchase Guardian NFTs. * Maximum supply: Capped at 400 units. * Eligibility: You must hold at least one Guardian NFT and have someone purchase via your invite code. *** ### How to Earn Bonus NFTs #### Step 1: Buy a Guardian NFT Purchase at least one Guardian NFT to get your unique invite code. #### Step 2: Share Your Invite Code Send your invite code to friends, communities, or partners. #### Step 3: Someone Uses Your Code to Buy Once someone completes a Guardian NFT purchase using your code, you will automatically receive 1 Bonus NFT. {% hint style="warning" %} **Bonus NFT Contract Address (BSC):** **0x97fF7b57e01a59be6b54419ED32DF7D778D5a108** {% endhint %} *** ### Example Scenario #### 👤 Before Bob Makes a Purchase | Name | Guardian NFTs | Invite Code | Bonus NFTs | | ----- | ------------- | ----------- | ---------- | | Alice | ✅ | ✅ | ❌ | | Bob | ❌ | ❌ | ❌ | * ✅ Alice does **not** have a Bonus NFT.
* ✅ Bob does **not** hava an invite code.
#### 👥 After Bob Uses Alice’s Code to Buy | Name | Guardian NFTs | Invite Code | Bonus NFTs | | ----- | ------------- | ----------- | ---------- | | Alice | ✅ | ✅ | ✅ | | Bob | ✅ | ✅ | ❌ | * ✅ Alice **receives** 1 Bonus NFT.
* ✅ Bob now **has** his own invite code.
*** ### Notes * You can earn multiple Bonus NFTs by inviting more users. * Invitees must complete the purchase using your invite code. * Bonus NFTs will be visible in the My Assets section after confirmation. *** 🔗 [Back to Guardian NFTs Guide](/genesis-nodes/guardian-nfts) # Verifier NFTs \ is a transferable NFT asset that represents early participation as a verifier in the DeepSafe network, with a total supply limited to 2,000 units. Coming Soon # Contract Addresses
Contract NameAddressLInk
Mint0xf6f63AD36fa7bbC771Ae133Dd01f750958E3228AView on BscScan
Guardian NFTs0x6957AB51703cB693535bA5fb9D670E8B6fC13B26View on BscScan
Bonus NFTs0x97fF7b57e01a59be6b54419ED32DF7D778D5a108View on BscScan
# Wallet Setup # How to Add Binance Smart Chain (BSC) in MetaMask ### Step 1: Open the network selection Click the Ethereum icon at the top left of your MetaMask wallet.

Open network selection.

### Step 2: Add BSC network Select **“Add Binance Smart Chain (BSC) network”** from the list.

Add BSC network.

### Step 3: Approve the network Click **“Approve”** to add BSC to your MetaMask.

Approve BSC network.

### Step 4: Confirm the network switch Check that the active network is now **Binance Smart Chain (BSC)**.

Confirm BSC is active.

# How to Import USDT into MetaMask (BSC) ### Step 1: Set MetaMask to BSC and Click “Import Tokens” Make sure MetaMask is set to the BSC network, then click on **Import Tokens.**

Set MetaMask to BSC and click “Import Tokens.”

### Step 2: Paste USDT Contract Address Copy the BSC USDT contract address and paste it into the search field in MetaMask. {% hint style="warning" %} USDT Contract Address: **0x55d398326f99059fF775485246999027B3197955** {% endhint %}

Paste the USDT contract address.

### Step 3: Select Tether USD and Click “Next” Select **Tether USD** and click Next.

Select Tether USD and click “Next.”

### Step 4: Click “Import” Click Import to add USDT to your wallet.

Click “Import” to finalize.

### Step 5: USDT Appears in MetaMask Now you can see USDT in your MetaMask wallet.

USDT is now in your MetaMask wallet.

# Network Configuration To start building on DeepSafe, you need to add the corresponding network's configurations to your development environment, e.g. MetaMask, Hardhat configuration files, etc. In the following, we provide the default configurations for interacting with different environments regarding the chain. ## Mainnet #### DeepSafe Beta Mainnet:
VariableValue
Network nameDeepSafe Beta Mainnet
RPC URL (http)https://betamainnet-rpc-node-http.deepsafe.network
RPC URL (wss)wss://betamainnet-rpc-node-http.deepsafe.network
Chain ID10011
Currency symbolDEF
# System Configuration The chapter introduces the DeepSafe's chain parameters to facilitate developers or users to better understand the system. ### Basic Chain Variable Parameters
VariableBeta Mainnet ValueBeta Testnet Value
Block Time6 s3 s
Chain Name DeepSafe Beta MainnetDeepSafe Beta Testnet
Token SymbolDEFtDEF
Token Decimals1818
Total Issuance1 billion1 billion
Protocol IDdeepsafe_beta_mainnetdeepsafe_beta_testnet
Maximum Block Weight20000000000002000000000000
Block Gas Limit6000000060000000
Weight Per Gas2500025000
EVM Chain ID10011481
Gas fee ratio

50%-miner

20%-burn

30%-treasure

50%-miner

20%-burn

30%-treasure

Existential Deposit00.0000000000000005
### Validator Variable Parameters
VariableBeta Mainnet ValueBeta Testnet Value
Epoch Duration100 block200 block
Sessions Per Era243
Epoch10 min10 min
Era4 h30 min
Bonding Duration1 era1 era
Maximum Nominations1616
Maximum Validators100100
Maximum Nominators10001000
Minimum Validator Bond100000 DEF100000 tDEF
Minimum Validator Bond100 DEF200 tDEF
### CRVA Variable Parameters
VariableBeta Mainnet ValueBeta Testnet Value
Incentive Epoch Duration300 block (30 min)600 block (30 min)
Committee Epoch Blocks600 block (60 min)800 block (40 min)
Committee Apply Blocks200 block300 block
Committee Rvrf Blocks100 block100 block
Committee Change Blocks200 block300 block
Committee Slot Number1010
Committee Maximum Duplicate33
Committee Maximum Members1515
Committee Minimum Members55
Committee T,N ratiogt 1 / 2ge 2/3
Committee Service Fee0.1 DEF1 tDEF
Device Heartbeat Session10 min10 min
Device Reward Session8 h60 min
Device Minimum Mint Pledge100000 DEF20000 tDEF
Device Offline Punish0.5 DEF10 tDEF
Device Maximum Voter2003000
Device Force Exit Punish1000 DEF1000 tDEF
Device No heartbeats Allowed20 min20 min
Device Force Exit Waiting100 min100 min
Device Maximum Exit Waiting1 day1 day
Device Maximum No Heartbeat20 min20 min
Device Minimum Commission15%15%
Device Minimum Vote Bond200 DEF200 tDEF
Device Owner Minimum Bond100000 DEF20000 tDEF
Device Base Reward Rate10%10%
Device Minimum Exit Bond Rate95%80%
Device Unlock Time1 day1 day
Device Base Score00
Device Advanced Score00
Foundation Reward Rate75%75%
### Govern Variable Parameters
VariableBeta Mainnet ValueBeta Testnet Value
Govern Preimage Base Deposit10000 DEF10000 tDEF
Govern Preimage Byte Deposit0.001 DEF0.001 tDEF
Govern Proposal Bond5 Permill 5 Permill
Govern Proposal Bond Minimum1 DEF1 tDEF
Govern Spend Period1 day1 day
Govern Maximum Approvals100100
Govern Spend Payout Period30 days30 days
Referenda Submission Deposit100 DEF100 tDEF
Referenda Alarm Interval1 block1 block
Referenda Undeciding Timeout28 days28 days
Referenda Maximum Queued100100
Conviction Vote Locking Period30 days30 days
Conviction Maximum Votes512512
Treasury Motion Duration3 days3 days
Treasury Maximum Proposals2020
Treasury Maximum Members99
Treasury Motion Duration14 days14 days
Treasury Maximum Proposals100100
Treasury Maximum Members100100
*** # Wallet Setup To interact with DeepSafe and manage Token on this network, setting up a MetaMask wallet is essential. Follow these steps to configure MetaMask for DeepSafe: ### Installing Wallet Install the wallet browser extension or mobile app if you haven't already. MetaMask: [https://metamask.io/download](https://metamask.io/download/) OKX: [https://www.okx.com/download](https://www.okx.com/download/) Bitget: [https://web3.bitget.com/en/wallet-download](https://web3.bitget.com/en/wallet-download/) TP: ### Wallet Import or Creation Import existing EVM wallets into the wallet or create new wallets specifically for managing Token on DeepSafe. ### Network Configuration Configure the network to interact with the DeepSafe. Add the network [details](/develop-guide/network-configuration), including the RPC endpoints and chain ID, to enable seamless communication. # Hardware {% content-ref url="/pages/NsgqYeGwsvh5KTpmP6P5" %} [Recommend List](/develop-guide/hardware/recommend-list) {% endcontent-ref %} # Recommend List {% hint style="danger" %} NOTE that CRVAs **MUST support Intel® SGX2** (TEE hardware). {% endhint %} ### Physical Machine * CPU: Intel Xeon 4310 \* 1 * Memory: 16G DDR4 ECC REG \* 8 * Storage Disk: 1.92T SATA SSD \* 1 * System Disk: 480G SATA SSD \* 1 * Network: Gigabit Ethernet (Integrated RJ45 1000Gb \* 2 + Independent 1000Mbps \* 1 ) * Power: 2 hot-swappable supplies (Support 550W 1+1 redundancy) * Others: PCI-E Gen.4 x8 slots \* 2 / PCIe Gen.4 x16 slots \* 3 ### Cloud Service * AliCloud: g7t, c7t, r7t * Tencent Cloud: M6ce * Microsoft Cloud: DCsv3, DCdsv3 # Purchase Guide ### AliCloud * **Purchase Links:** [**https://ecs-buy.aliyun.com/**](https://ecs-buy.aliyun.com/) * **Buyer's Guide:** Note: The ecs.g7t series, ecs.c7t series, and ecs.r7t series all support Intel® SGX2. {% embed url="" %} * **Configuration Reference:** Payment Type: **Yearly & Monthly | Volume Based Payment** Territory: **China (HONG KONG)** Instance: **Security Enhanced g7t，ecs.g7t.xlarge，8vCPU 32GiB** Mirror: **Ubuntu 18.04 64-bit UEFI Edition** System Disk: **ESSD cloud disk 2048GiB** Public IP address：**Assign public IPv4 addresses** Bandwidth billing model: **by fixed bandwidth** Bandwidth：**20Mbps** Management Settings: **Password** * **Reference quote:** **￥5231.2/month | ￥6.855/hour + ￥1.000/GB** ### Tencent cloud * **Purchase Links:** [**https://buy.cloud.tencent.com/cvm**](https://buy.cloud.tencent.com/cvm) * **Buyer's Guide:** Note: The Security Enhanced Memory M6ce supports Intel® SGX2 and is only in stock in Shanghai and Beijing. {% embed url="" %} * **Configuration Reference:** Configuration mode: **Customized** Billing Mode: **Yearly and Monthly | Volume Based Billing** Region: **China - Hong Kong, China** Instance: **M6Ce.2XLARGE64 (Security Enhanced Memory Type M6ce, 8-core 64GB)** System: **Ubuntu Server 20.04 LTS 64-Bit** Storage: **Universal SSD Cloud Drive - 2048GiB** Bandwidth: **20Mbps** Login: **Password (self-set)** * **Reference quote:** **4Core32GB：￥3187.54/month | ￥3.41/hour + ￥0.80/GB** ### Microsoft cloud * **Purchase Links:** [**https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM**](https://portal.azure.com/#create/Microsoft.VirtualMachine-ARM) * **Buyer's Guide:** Note: The **DCsv3** series and **DCdsv3** series support Intel® SGX2 in the following regions: Central Canada, Eastern United States, Eastern United States2, Western United States, Western United States2, Central United States, South Central United States, Northern Europe, Western Europe, Eastern Japan, Western Japan, Northern Switzerland, Southeast Asia, Northern Italy, Central India, and Southern United Kingdom. {% embed url="" %} * **Configuration Reference:** Virtual Machine Name: **Set it up yourself** Region: **(Asia Pacific) Southeast Asia** Image: **Ubuntu Server 20.04 LTS - x64 Gen2** Size: **Standard DC4s\_v3-4 vcpus, 32 GiB RAM (US$350.40/month)** Authentication Type: **Password** Username: **Set by yourself** Password: **Self-set** OS Disk Size: **2TiB (P40)** * **Reference quote:** **0.4800USD/hr** ### Google cloud No available TEE models ### Amazon cloud No available TEE models # Testnet {% hint style="info" %} The testnet is for developers' use only. {% endhint %} {% content-ref url="/pages/w4V3AQ9YrJVGxYYdk8c3" %} [DeepSafe Chain](/develop-guide/testnet/deepsafe-chain) {% endcontent-ref %} {% content-ref url="/pages/tYgZIKK6XoLfKNqlt5sI" %} [CRVA Nodes](/develop-guide/testnet/crva-nodes) {% endcontent-ref %} # DeepSafe Chain DeepSafe Chain is developed based on Polkdot Substrate framwork and implements **Nominated Proof-of-Stake (NPoS)** consensus algorithm to improve the overall security of the network. Nominators and Validators are two vital roles in a NPoS network. Nominators are responsible to nominate the most reliable nodes to validate new blocks within the network. Validators refer to nodes that have been nominated by nominators and are allowed to verify new transactions and earn rewards for their contributions to the network security. Developers can follow guides provided in [Node operators](/develop-guide/testnet/deepsafe-chain/node-operators) to run their individual nodes within the DeepSafe Chain, and further become [Validators ](/develop-guide/testnet/deepsafe-chain/validators)to maintain the network consensus. # Node operators ## Node configuration ### Prerequisites Below is a list of standard requirements for running nodes on the DeepSafe chain: 1. **Operating system:** \ Ubuntu 18.04 or Linux Kernel 5.16. 2. **Hardware:** * CPU: 4 Cores * Memory: 16GB RAM * Storage: 1TB SSD/HHD * Network: At least 20Mb bandwidth with an independent IP address ## Node initialization ### Download binaries {% hint style="warning" %} Compiling from binaries is temporarily unsupported since the network is not open-source at the Testnet stage. {% endhint %} ### Using Docker **Docker** is the only avaliable way to operate nodes on Bool chain at the alpha testnet stage. Developers can quickly run nodes through the images posted by Bool team via the following command: ```shell docker run -p 30333:30333 boolnetwork/bnk-node:alpha-testnet --validator --chain=alpha_testnet --name ``` If you prefer to run in the backstage, please add `-d` on docker command. If you prefer to persist the node's data on the host machine, please add`-v ./data:/data` on docker command. If you intend to run an RPC service that is exteranlly accessibe for applications or third-party applicaitions, such as Polkadot.js, please add following flags to run a full node: * `--unsafe-rpc-external`: Listen to all RPC interfaces. * `--unsafe-ws-external`: Listen to all Websocket interfaces. More details can be found be executing the following command: ```shell docker run --rm boolnetwork/bnk-node:alpha-testnet --help ``` ## Examples ### Node initialization ``` 2024-01-30 08:08:26 BoolNetwork Node 2024-01-30 08:08:26 ✌️ version 0.10.0-f53ea677650 2024-01-30 08:08:26 ❤️ by BoolNetwork, 2022-2024 2024-01-30 08:08:26 📋 Chain specification: BoolNetwork Alpha Testnet 2024-01-30 08:08:26 🏷 Node name: grandiose-voyage-2878 2024-01-30 08:08:26 👤 Role: AUTHORITY 2024-01-30 08:08:26 💾 Database: RocksDb at /bool/.local/share/bnk-node/chains/boolnetwork_alpha_testnet/db/full 2024-01-30 08:08:26 ⛓ Native runtime: moonbase-194 (moonbase-2.tx1.au2) 2024-01-30 08:08:31 🔨 Initializing Genesis block/state (state: 0x5e9c…3f30, header-hash: 0x1808…0b78) 2024-01-30 08:08:31 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-01-30 08:08:36 👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-01-30 08:08:36 🏷 Local node identity is: 12D3KooWFBrtXis73pD5aVbmyRNAGzCKaZ3q9VZFHgPmL3RNDEyH ``` ### Node sync ``` 2024-01-30 08:09:06 No device mining and no deposit 2024-01-30 08:09:06 ⚙️ Syncing 262.4 bps, target=#146111 (3 peers), best: #8016 (0x6811…5d1c), finalized #7788 (0x883a…fe33), ⬇ 82.6kiB/s ⬆ 0.9kiB/s 2024-01-30 08:09:06 [8188] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:06 [8188] 💸 generated 3 npos targets 2024-01-30 08:09:06 [8188] 💸 new validator set of size 3 has been processed for era 14 2024-01-30 08:09:09 [8788] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:09 [8788] 💸 generated 3 npos targets 2024-01-30 08:09:09 [8788] 💸 new validator set of size 3 has been processed for era 15 2024-01-30 08:09:10 No device mining and no deposit 2024-01-30 08:09:11 ⚙️ Syncing 233.9 bps, target=#146112 (3 peers), best: #9186 (0x5d6c…2de1), finalized #8988 (0xa05e…64df), ⬇ 71.5kiB/s ⬆ 1.2kiB/s 2024-01-30 08:09:11 [9388] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:11 [9388] 💸 generated 3 npos targets 2024-01-30 08:09:11 [9388] 💸 new validator set of size 3 has been processed for era 16 2024-01-30 08:09:14 [9988] 💸 generated 3 npos voters, 3 from validators and 0 nominators 2024-01-30 08:09:14 [9988] 💸 generated 3 npos targets 2024-01-30 08:09:14 [9988] 💸 new validator set of size 3 has been processed for era 17 2024-01-30 08:09:14 No device mining and no deposit 2024-01-30 08:09:16 ⚙️ Syncing 268.2 bps, target=#146114 (3 peers), best: #10527 (0x31ca…9b7d), finalized #10240 (0xf654…d810), ⬇ 82.8kiB/s ⬆ 1.1kiB/s 2024-01-30 08:09:16 [10588] 💸 generated 3 npos voters, 3 from validators and 0 nominators ``` ## FAQ #### Why are nodes out of sync? If the number of peers on your node is unstable and occasionally reaches 0, causing normal synchronization, try adding port mapping on your router to your public IP: 30333-> node's internal IP: 30333, and Set the firewall to allow port 30333 to connect.
# Validators Before following the steps below, please make sure you have started a node according to the [Node operators](/develop-guide/testnet/deepsafe-chain/node-operators). Use the `docker ps -a | grep bnk-node | awk '{print $1}'` command to get the \. ### Set node key In order to become a validator, a developer need to set [Session Keys](https://wiki.polkadot.network/docs/learn-cryptography#session-keys) to the node. A general configuration procedure is given as follows: Firstly you have to enter the Docker operation environment: ```shell docker exec -it bash ``` Retrieving your Session Keys using the following command: ```shell curl -X POST http://127.0.0.1:9944 -H "Content-type: application/json" -d '{"id":1,"jsonrpc":"2.0","method":"author_rotateKeys","params":[]}' ``` Your result should be resemble to this sample: ```shell {"jsonrpc":"2.0","result":"0x963d40e26c1d69acf3f75f96cd7782576382713b650d2ea81f5c8dbeb3797e1f17df3a8ab0d3a2dc3218972fdebe47a4463523ae1bbc0a6c91f3b33ace76c0eb","id":1} ``` {% hint style="info" %} Remember to store the public key set you obtained, such as '`0x96***0eb'` in the above example, since it is required in subsequent operations. {% endhint %} ### Request tBOL Use [Faucet](https://faucet.bool.network/) to get test tokens for your controller, which is your MetaMask 's account. Option 1. You can get tBOL automaticly by sending USDT on BSC, Polygon, Optimism to the belowing address directly. For example, send 1 USDT to get 10 tBOL. Token release intervals may take up to 5 minutes. ``` 0x2000B83c88DC238B66A9E72e1B62C446d39ceef7 ``` Option 2. Get a free tBOL airdrop whitelist by interacting on cross-chain apps built by BOOL eco-partners. The more you interact, the more tBOL you can claim. ## Set validator Navigate to the [`Control Panel` - `Node section`](https://dashboard.boolscan.com/node?network=devnet) and choose **To Be Validator** (if you have become a nominator, you need to stop first, and then select 'To Be Validator')
Set parameters, including commission, allows third parties to join, and RotateKey: * **Commission**: The percentage of the reward received by the validator when the reward is distributed. If the rewards are the same, the lower the commission means that the nominators will receive more rewards. * **Allowing third parties to join**: if permitted, a third party may become a nominator for the validator, but not otherwise. * **RotateKey**: it is used to bind the account and validate the node relationship（`0x96***0eb` generated by the previous step）. * **Set the amount of pledge and income distribution**: * Continue Pledge: Continue to pledge funds to the account when claiming the reward. * Direct benefit: The rewards will not continue to be pledged, but transferred to the personal spendable account.
Submit a transaction to become a validator, you need to wait for some epoch. Once selected, those who do not participate in block production will be punished accordingly, and part of the pledge will be deducted. # CRVA Nodes CRVA nodes should support TEE hardware, such as SGX, to support the interactions of CRVAs in DeepSafe. # Prerequisites {% hint style="danger" %} NOTE that CRVA nodes **MUST support Intel® SGX2** (TEE hardware). {% endhint %} ## Basic Requirements * Operating system: Ubuntu 18.04 * CPU: 8 cores and support SGX2 * Memory: 32GB RAM * Storage: 2TB SSD * Network: At least 20Mb bandwidth with an independent IP address ## Recommended Physical Machine * CPU: Intel Xeon Ice Lake (16 cores) * Memory: 64GB DDR4 * Storage Disk: 2TB SSD * System Disk: 480GB SSD * Network: Gigabit Ethernet ## Recommended Cloud Service * AliCloud: \ **ecs.g7t, ecs.c7t, ecs.r7t** {% embed url="" %} * Tencent Cloud: \ **M6ce** {% embed url="" %} * Microsoft Cloud: \ **DCsv3, DCdsv3** {% embed url="" %} # Quick Start An overview of running a node equipped with TEE to provide CRVA services. ### Download binaries ```shell git clone https://github.com/boolnetwork/mining-scripts.git cd mining-scripts ``` {% hint style="warning" %} Please ensure that your CPU supports SGX before carrying on. We found this [guide](https://www.intel.com/content/www/us/en/support/articles/000028173/processors.html) might be helpful to you. {% endhint %} ### Configuration You should `cd configs` to configure several parameters before running further scripts. More specifically, expect the following parameter that should be paid special attention, the rest can be left as default values: * `keyring.toml` * `identity`: The account that interacts with the Bool chain. It is the owner of the device and can perform multiple actions: signing transactions, registering devices, activating devices, receiving network rewards, etc. ### Create An Identity Account Run the script: ```shell docker run -it --rm boolnetwork/bnk-node:release identity generate ``` Outputs (sample): ```shell Secret seed: 0x71235e1458ce9d140c8b8ded28ccc1e32e62c340aef51a65e1350a387dbe08a6 Public key (hex): 0x0248e7f02dcc9f7061a090b67dede93d7381847e94955aee7996603d2225e9f77e Account ID: 0x34a5572cb21d34354e3091564d5edc7b791e9d5f ``` Request tBOL by sending USDT(supports BSC, Polygon, Optimism) to: **0x2000B83c88DC238B66A9E72e1B62C446d39ceef7** ### General Commands Start the mining service via `docker-compose` #### Start mining ```shell docker-compose up -d ``` #### Check status ```shell docker-compose logs ``` #### Stop mining ```shell docker-compose down ``` #### Updating ```shell docker-compose pull ``` ### # Press-Kit ## Logo Group 1
## Logo Group 2
## Logo Group 3
## Logo Group 4
## Banner
## Banner for Collaboration