Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Celestium is developed by a team of blockchain engineers, system architects, and innovators dedicated to building the next generation of high-performance Layer 1 blockchain infrastructure. We believe that scalability should not come at the expense of decentralization. Our mission is to create a network that delivers both speed and security while remaining fully compatible with the Ethereum ecosystem.
Our team brings together expertise in distributed systems, cryptography, consensus algorithms, and high-performance software development. With a focus on innovation, we aim to push the boundaries of blockchain technology by introducing advancements like Proof of Authority + AI consensus (PoAi), parallel execution, asynchronous execution, and a custom state database called CelesDb.
At Celestium, we are committed to empowering developers and users with a scalable, efficient, and decentralized blockchain platform. We strive to foster an open and collaborative ecosystem that drives the future of decentralized applications and financial systems.
Our Vision:
Build a blockchain network capable of supporting mass adoption without sacrificing decentralization.
Enable developers to build and scale applications seamlessly with Ethereum compatibility.
Pioneer blockchain innovations that set new standards for performance and security.
We believe that the future of blockchain lies in combining cutting-edge technology with a commitment to decentralization, and we are proud to lead that journey with Celestium.
Celestium is a high-performance, Ethereum-compatible Layer 1 blockchain designed to push the boundaries of scalability while preserving decentralization and security. It leverages a unique Proof of Authority + AI (PoAi) consensus mechanism and introduces several architectural advancements to achieve throughput of 10,000 transactions per second (TPS), with single-slot finality in 1 second.
Celestium aims to address the performance bottlenecks that limit existing blockchains, such as single-threaded execution and synchronous consensus-execution coupling, without compromising on the core principles of decentralization, trustlessness, and censorship resistance.
Celestium is built on a set of core principles that guide its design and development:
Decentralization First: While optimizing for scalability and performance, decentralization remains a top priority. The protocol is designed to ensure that no single entity can compromise the network's neutrality and security.
Ethereum Compatibility: Celestium is fully compatible with Ethereum Virtual Machine (EVM) bytecode and the Ethereum RPC API, enabling developers to migrate their existing Ethereum-based applications seamlessly.
Performance and Efficiency: With innovations like parallel execution, asynchronous execution, and a custom state database called CelesDb, Celestium achieves high throughput while optimizing resource efficiency.
Celestium introduces key innovations to enhance performance and usability:
Proof of Authority + AI (PoAi): A consensus mechanism that combines the stability and efficiency of Proof of Authority with AI-driven validator selection and optimization. This approach ensures fast, secure block finality while adapting to network conditions in real-time.
CelesBFT: A pipelined, two-phase Byzantine Fault Tolerant consensus algorithm inspired by HotStuff and DiemBFT, optimized for low latency and high throughput.
Asynchronous Execution: Decoupling consensus from execution allows Celestium to process consensus and transaction execution independently. This eliminates execution bottlenecks and allows transactions to utilize the full block time for processing.
Developers can build on Celestium using familiar tools from the Ethereum ecosystem, including:
Hardhat, Foundry, and Apeworx for smart contract development and testing.
MetaMask and other popular wallets for interacting with the network.
Etherscan-style block explorers for transaction tracking and analytics.
Celestium achieves single-slot finality in 1 second, meaning that transactions are considered final and irreversible after a single block. Execution results are typically available within 1 second for full nodes. Light clients can verify state changes with a delayed Merkle root mechanism (D = 10 blocks), ensuring trust-minimized access to on-chain data.
The Celestium client is developed from scratch using C++ and Rust, focusing on performance, robustness, and modularity. The network is engineered to support future upgrades and adapt to evolving demands within the blockchain industry.
Celestium provides a next-generation blockchain platform that balances decentralization, performance, and compatibility. It empowers developers and users with:
High throughput (10,000 TPS).
Low latency (1-second finality).
Ethereum compatibility.
Advanced execution model.
Whether building decentralized applications, deploying smart contracts, or processing high-frequency transactions, Celestium delivers the infrastructure to power the next wave of blockchain innovation.
Parallel Execution: Transactions are executed in parallel where possible, leveraging multi-core systems to maximize throughput without altering the linearity of block ordering.
CelesDb: A custom-built state storage solution optimized for parallel access and asynchronous I/O, designed to handle high transaction volumes efficiently.
Optimized state storage.
Running a full node on Celestium allows you to independently validate transactions, interact with the blockchain, and support network decentralization. This section provides the steps to start and manage a full node after completing the installation process.
Ensure you have successfully installed the Celestium node software. If not, follow the steps in the Node Installation section.
Run the following command to launch your full node and connect to the Celestium Testnet:
This command will start the node, connect to the testnet, and begin syncing the blockchain.
Once the node is running, check its status with an RPC call:
Response is false → Your node is fully synced.
Response with progress data → Your node is still syncing.
Once the node is operational, you can interact with it using any Ethereum-compatible tools such as:
MetaMask: Connect your wallet to the Celestium Testnet RPC.
Hardhat or Foundry: Configure your development environment to use your local node at http://127.0.0.1:8545.
Stop the Node: Use Ctrl + C to terminate the node process.
Restart the Node: Simply run the start command again.
Check Logs: Logs are displayed in the terminal; redirect output to a file if needed.
Connect your node to wallets and development tools.
Deploy and test smart contracts.
Monitor performance and sync status.
Running a full node ensures you have direct access to Celestium network data, improving your development experience and enhancing network resilience.
Running a Celestium full node allows you to participate in the network, validate blocks, and access blockchain data directly. Follow the steps below to set up and run a Celestium node.
Ensure your system meets the minimum hardware specifications to run a Celestium node efficiently:
CPU: 16-core processor
Memory: 32 GB RAM
Storage: 2 TB NVMe SSD
Network: 100 Mbps bandwidth
Make sure you have the following installed on your machine:
Linux (Ubuntu 22.04 recommended) or any compatible Unix-based OS
CMake (for build automation)
GCC / Clang (C++ compiler)
Git (for cloning repositories)
Retrieve the Celestium client source code from the official repository:
Compile the node from source:
After building, run the node to connect to the Celestium Testnet:
Once the node is running, you can verify its status using:
A response indicating false means your node is fully synced.
Connect wallets like MetaMask to the Celestium Testnet.
Deploy smart contracts using Hardhat or Foundry.
Explore the network using .
This setup will ensure your node is ready to interact with the Celestium blockchain network.
(MetaMask, Phantom, etc.)
Wallets allow users to interact with the Celestium blockchain by sending transactions, managing tokens, and connecting to decentralized applications (dApps). Celestium is EVM-compatible, meaning it works seamlessly with popular wallets such as MetaMask and Phantom.
Click the network dropdown at the top.
Select Add Network → Add a network manually.
Enter the following details:
Network Name: Celestium Testnet
RPC URL: http://rpc-private-testnet.celestium.network
Chain ID: 252525
Currency Symbol: CLT
Block Explorer URL: http://testnet.celestium.network
Click Save.
You are now connected to the Celestium Testnet.
To view custom tokens such as Wrapped CLT (WCLT) in your wallet:
Open MetaMask.
Click Import Tokens.
Enter the token contract address (when available).
Click Add Custom Token → Import Tokens.
Phantom also supports EVM-compatible networks. Follow these steps:
Open Phantom wallet.
Go to Settings → Change Network.
Select Add Custom Network.
Enter the Celestium Testnet details:
Network Name: Celestium Testnet
RPC URL: http://rpc-private-testnet.celestium.network
Chain ID: 252525
Currency Symbol: CLT
Explorer URL: http://testnet.celestium.network
Click Save.
You are now connected to Celestium Testnet.
Once connected, you can send CLT tokens:
Click Send in your wallet.
Enter the recipient’s address.
Specify the amount of CLT.
Adjust gas fees if needed.
Confirm the transaction.
Transactions can be viewed on the Celestium Testnet Explorer using your wallet address or transaction hash.
Using wallets like MetaMask and Phantom provides a secure and user-friendly way to interact with the Celestium blockchain for sending tokens, deploying contracts, and accessing dApps.
Rust (for Rust components)
RPC URL: http://rpc-private-testnet.celestium.network
Chain ID: 252525
Currency Symbol: CLT
Block Explorer URL: http://testnet.celestium.network
Open MetaMask and click the network dropdown at the top.
Select Add Network → Add a network manually.
Enter the details from the Celestium Testnet Configuration section above.
Click Save. You are now connected to the Celestium Testnet.
To configure Hardhat for Celestium:
Replace PRIVATE_KEY with your wallet’s private key.
Create a foundry.toml file with the following content:
After setting up, verify your connection by querying the block number:
If you receive a block number response, you are successfully connected to the Celestium Testnet.
With your environment connected to Celestium, you are ready to start deploying smart contracts and interacting with the blockchain.
bash
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525bash
curl -X POST http://127.0.0.1:8545 -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_syncing",
"params":[],
"id":1
}'bash
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525 > node.log 2>&1 &bash
sudo apt update
sudo apt install build-essential cmake git curl
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/envbash
git clone https://github.com/celestium-network/celestium-client.git
cd celestium-clientbash
mkdir build && cd build
cmake ..
make -j$(nproc)bash
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525bash
curl -X POST http://127.0.0.1:8545 -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_syncing",
"params":[],
"id":1
}'module.exports = {
networks: {
celestium: {
url: 'http://rpc-private-testnet.celestium.network',
chainId: 252525,
accounts: [PRIVATE_KEY]
}
}
};toml
[profile.default]
rpc_url = "http://rpc-private-testnet.celestium.network"
chain_id = 252525bash
curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_blockNumber",
"params":[],
"id":1
}'Monitoring logs and diagnosing issues is essential to ensure that a Celestium node operates smoothly. Logs provide valuable insight into block synchronization, consensus processes, transaction execution, and potential errors.
When running a Celestium node, logs are printed to the console by default. You can also redirect logs to a file for easier review:
Real-time log view:
View last 100 lines:
Search for errors in logs:
For more detailed logs, use the --log-level flag:
Available levels:
error
warn
info (default)
If the node experiences persistent issues, resetting the local blockchain data can resolve corruption or sync failures:
If problems persist, consider:
Collecting relevant logs (node.log).
Noting system details (CPU, RAM, Disk usage).
Gathering block height and chain ID.
Submit issues to the official Celestium support channels or community forums.
Effective logging and troubleshooting ensure your node remains healthy, minimizing downtime and enhancing network participation.
Submitting a transaction to the Celestium network involves creating a signed transaction and broadcasting it to the network through an RPC node. This section provides a step-by-step guide on how to submit transactions to Celestium Testnet.
A transaction can transfer CLT tokens, interact with a smart contract, or deploy a new contract. Transactions must include:
From: Sender’s address.
To: Recipient’s address (optional for contract creation).
Value: Amount of CLT to send (in wei).
Gas Limit: Maximum gas units to consume.
Gas Price: Fee per unit of gas (in wei).
Data: Optional data payload (e.g., smart contract call).
Transactions must be signed using the sender’s private key. Popular libraries like ethers.js or web3.js can help with signing:
Replace PRIVATE_KEY and 0xRecipientAddress with your actual data.
If you sign the transaction offline, broadcast it using eth_sendRawTransaction:
Replace 0xSignedTransactionData with the signed transaction hex string.
Use eth_getTransactionReceipt to check the status:
If the receipt is null, the transaction is still pending.
Track your transaction on using your transaction hash.
Use eth_estimateGas to calculate gas before sending.
Ensure your balance covers the transaction value and gas fees.
Double-check your private key security; never expose it publicly.
This approach ensures that transactions are processed smoothly on the Celestium network.
Celestium is designed to achieve fast and deterministic finality with a block time of 1 second, ensuring that transactions are confirmed and finalized swiftly without the risk of reorganization.
Celestium operates with a block time of 1 second, meaning a new block is produced every second under normal network conditions. This is made possible by the CelesBFT consensus mechanism, which optimizes leader-based block production and validator voting processes.
Key points regarding block time:
Fixed Block Time: 1 second per block.
Consistent Throughput: Supports high transaction throughput (up to 10,000 transactions per second) without compromising network stability.
Low Latency: Suitable for applications requiring fast transaction confirmations, such as decentralized finance (DeFi) and trading platforms.
Finality refers to the point at which a transaction is considered irreversible. Celestium achieves single-slot finality, meaning a block is finalized immediately after it is included in the blockchain and receives votes from a quorum of validators.
Key Characteristics of Finality in Celestium:
This deterministic finality model is more secure and predictable compared to probabilistic finality in Proof-of-Work systems like Ethereum (pre-Merge), which may require waiting for multiple confirmations to reduce the risk of chain reorganization.
It is important to distinguish between:
Finality: Agreement on the order of transactions.
Execution Outcome: The result of executing those transactions.
In Celestium, finality is achieved in 1 second when the block is added to the chain. The execution of transactions may lag slightly behind finality but is typically completed within less than 1 second on full nodes. Users querying the state via light clients may experience a slight delay due to the Merkle root delay (D=10 blocks), but finality itself is not affected.
Fast and deterministic finality is crucial for:
DeFi Applications: Ensuring rapid transaction settlements.
High-Frequency Trading: Providing immediate certainty about trade execution.
Gaming & NFT Platforms: Reducing waiting times for in-game asset transfers.
Cross-Chain Bridges: Mitigating risks associated with chain reorganizations.
Finality and block time are foundational to Celestium’s performance-oriented design, enabling a blockchain infrastructure that supports real-time applications while preserving security and decentralization.
Celestium introduces an innovative hybrid consensus mechanism called Proof of Authority + AI (PoAi), which combines the deterministic nature of Proof of Authority (PoA) with the adaptive capabilities of Artificial Intelligence (AI). This unique approach enhances network security, validator selection, and operational efficiency.
Proof of Authority is a consensus model where a set of trusted and verified validators is responsible for producing blocks and securing the network. Unlike Proof of Work (PoW) or Proof of Stake (PoS), PoA relies on validator identity and reputation, making it efficient and energy-saving.
Key attributes of PoA:
Celestium is fully Ethereum Virtual Machine (EVM)-compatible, allowing developers to write and deploy smart contracts using Solidity, the most popular language for smart contract development. Any contract written for Ethereum can be deployed on Celestium without modification.
This section provides an overview of the smart contract development process and an example of a basic Solidity contract.
Developers can use familiar Ethereum development tools:
Optimistic Execution is a technique used in Celestium to further enhance transaction processing efficiency when executing transactions in parallel. It allows transactions to start executing before the preceding transactions in the same block have finished, under the assumption that there will be no conflicts. If conflicts arise, affected transactions are re-executed.
Consider a block containing multiple transactions:
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525 > node.log 2>&1 &Validator Identity: Validators are known, vetted entities with a public reputation.
High Throughput: PoA enables faster block production with reduced computational overhead.
Low Energy Consumption: Does not require extensive computational resources like PoW.
Celestium advances PoA by integrating AI-driven mechanisms into the validator selection and performance evaluation process. AI enhances the network's ability to dynamically assess and optimize validator operations, ensuring reliability and resilience.
AI Enhancements in PoAi:
Performance Scoring
AI monitors node uptime, block production success, and responsiveness to assign performance scores.
Anomaly Detection
Detects abnormal validator behavior, such as downtime, network attacks, or irregular activities.
Adaptive Validator Rotation
Based on AI analysis, underperforming or malicious validators can be dynamically rotated out.
Predictive Analysis
AI predicts potential node failures based on historical performance data, enabling proactive adjustments.
Validators are selected based on:
Pre-Approved Identity: Validators must undergo an identity verification process before being considered.
AI Performance Evaluation: AI continuously evaluates validators based on:
Block production success rate.
Node uptime.
Network responsiveness.
Latency and throughput metrics.
Validators who consistently perform well are rewarded with more block production opportunities, while underperforming validators face reduced participation or replacement.
Combining PoA with AI strengthens Sybil resistance:
Identity Verification: Validators are pre-vetted and publicly accountable.
Behavioral Monitoring: AI flags malicious or non-compliant validators for removal.
Automated Adjustments: Validator set adjustments are automated based on AI performance evaluations.
This approach reduces the risk of validator collusion and enhances the overall integrity of the Celestium network.
Efficiency
Faster block production and finality due to trusted validators.
Resilience
AI ensures only high-performing nodes contribute to consensus.
Security
Continuous monitoring reduces the risk of malicious behavior.
Scalability
Adaptive validator rotation supports increasing network demand.
Proof of Authority + AI (PoAi) underpins Celestium’s consensus design by combining the efficiency of PoA with the adaptive intelligence of AI. This ensures a secure, high-performance Layer 1 blockchain capable of processing 10,000 transactions per second, while maintaining robust decentralization principles.
Transactions are executed concurrently without waiting for the results of earlier transactions.
Each transaction tracks the state it reads and writes during execution (read-set and write-set).
After the transactions complete, the results are merged in block order.
If a transaction’s read-set depends on state modified by an earlier transaction in the block, and the state was different than expected, the transaction is re-executed with the updated state.
This approach ensures that, even with parallel execution, the final state is the same as if transactions had been executed sequentially.
Suppose a block contains the following transactions:
Tx1: Alice sends 10 CLT to Bob.
Tx2: Bob sends 5 CLT to Charlie.
Using Optimistic Execution:
Tx1 and Tx2 start executing in parallel.
Tx2 reads Bob’s initial balance (before Tx1), which might be insufficient.
Once the block is merged:
Tx1 updates Bob’s balance.
Tx2 detects that it used an outdated balance.
Tx2 is re-executed using Bob’s updated balance.
This re-execution is necessary because Tx2 depended on the result of Tx1.
Benefit
Description
Faster Execution
Transactions start executing without waiting for prior results.
Efficient Use of Resources
Takes full advantage of parallelism with multi-core systems.
Correct State Guarantee
Final state is identical to sequential execution.
To reduce the overhead of re-executing transactions:
Expensive operations like signature verification are cached and not repeated during re-execution.
State accessed in the initial execution is cached in memory, minimizing the cost of re-execution.
Static analysis attempts to predict dependencies between transactions and minimize conflicts.
Transactions from a block are assigned to multiple cores for parallel execution.
Each transaction optimistically reads state and performs computations.
The outputs are merged sequentially in block order.
If a transaction’s read-set conflicts with an earlier transaction’s write-set:
The transaction is re-executed.
The final state is guaranteed to match sequential execution.
The term "optimistic" refers to the assumption that most transactions will not conflict. In reality, many transactions are independent, such as:
Alice sending CLT to Bob.
Charlie deploying a smart contract.
Only dependent transactions (e.g., Bob sending CLT after receiving from Alice) require re-execution. Since conflicts are rare, this approach is highly efficient.
Aspect
Optimistic Execution
Parallel Execution
Definition
Transactions start execution before prior transactions finish.
Transactions are executed in parallel on different cores.
Key Focus
Reducing idle time by assuming minimal conflicts.
Maximizing throughput with multi-core processing.
Conflict Handling
Re-execution of transactions if conflicts are detected.
Detects dependencies; avoids some conflicts proactively.
Optimistic Execution is a critical innovation in Celestium that unlocks the full potential of parallel transaction processing. It leverages modern hardware capabilities while ensuring Ethereum-compatible deterministic state.
This approach, combined with Parallel Execution and Asynchronous Execution, enables Celestium to achieve high throughput and low-latency finality without compromising on state correctness.
Finality Time
1 second (same as block time)
Irreversibility
Once a block is finalized, it is irreversible unless a supermajority of validators act maliciously.
Quorum Requirement
A block is finalized when 2/3 of validator weight votes to approve it.
Block Time
1 second
12 seconds
Finality Time
1 second (single-slot)
12.8 minutes (2 epochs)
Reorganization Risk
Near-zero after 1 second
Possible until finality (2 epochs)
Storage read/write errors
Disk performance issues
Ensure NVMe SSD is functioning properly and has sufficient space.
debugINFO
Standard operational messages, including block finalization.
WARN
Non-critical issues, such as slow sync or network latency.
ERROR
Critical errors that could affect node functionality.
DEBUG
Detailed information (useful for development and debugging).
Node is not syncing
Network issues or wrong RPC URL
Verify network connectivity and RPC URL configuration.
High CPU or Memory Usage
Block processing or large transaction load
Ensure system meets hardware requirements; monitor with metrics.
Failed transaction execution
Gas limit too low, or contract error
Check transaction gas limit and contract logic.
Peer connection issues
Network configuration or firewall
Ensure ports are open and node can reach peers.
Hardhat – Development framework for building and testing smart contracts.
Foundry – Fast, modular toolkit for smart contract development.
Remix – Online IDE for writing, testing, and deploying Solidity contracts.
Install Hardhat:
Create a Hardhat Project:
Configure Hardhat for Celestium Testnet:
Modify hardhat.config.js:
Replace PRIVATE_KEY with your wallet's private key.
This is a basic contract to store and retrieve a number:
Create a deployment script scripts/deploy.js:
Run the deployment script:
Once deployed, you can interact with the contract using ethers.js:
Replace DEPLOYED_CONTRACT_ADDRESS with the address of the deployed contract.
Once deployed, you can verify the contract and track transactions on the Celestium Testnet Explorer.
Always test contracts on the Celestium Testnet before deploying on the main network.
Use OpenZeppelin Contracts for secure and standardized smart contract implementations.
Review gas efficiency and security best practices when writing contracts.
This guide provides the foundation to start developing and deploying smart contracts on Celestium
tail -f node.logbtail -n 100 node.loggrep "ERROR" node.log./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525 --log-level debugrm -rf celestium-data/
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525 --data-dir celestium-dataconst { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider("http://rpc-private-testnet.celestium.network");
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
const tx = {
to: "0xRecipientAddress",
value: ethers.parseEther("0.1"),
gasLimit: 21000,
gasPrice: ethers.parseUnits("1", "gwei")
};
const transactionResponse = await wallet.sendTransaction(tx);
console.log(`Transaction hash: ${transactionResponse.hash}`);curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_sendRawTransaction",
"params":["0xSignedTransactionData"],
"id":1
}'curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_getTransactionReceipt",
"params":["0xTransactionHash"],
"id":1
}'bash
npm install --save-dev hardhatbash
npx hardhat initjavascript
require("@nomicfoundation/hardhat-toolbox");
module.exports = {
solidity: "0.8.20",
networks: {
celestiumTestnet: {
url: "http://rpc-private-testnet.celestium.network",
chainId: 252525,
accounts: [`0x${PRIVATE_KEY}`],
},
},
};solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract SimpleStorage {
uint256 private storedNumber;
function setNumber(uint256 _number) public {
storedNumber = _number;
}
function getNumber() public view returns (uint256) {
return storedNumber;
}
}javascript
const hre = require("hardhat");
async function main() {
const SimpleStorage = await hre.ethers.getContractFactory("SimpleStorage");
const simpleStorage = await SimpleStorage.deploy();
await simpleStorage.waitForDeployment();
console.log(`Contract deployed to: ${await simpleStorage.getAddress()}`);
}
main().catch((error) => {
console.error(error);
process.exitCode = 1;
});bash
npx hardhat run scripts/deploy.js --network celestiumTestnetjavascript
const contractAddress = "DEPLOYED_CONTRACT_ADDRESS";
const SimpleStorage = await ethers.getContractFactory("SimpleStorage");
const simpleStorage = SimpleStorage.attach(contractAddress);
// Set a number
await simpleStorage.setNumber(42);
// Get the number
const storedNumber = await simpleStorage.getNumber();
console.log(`Stored Number: ${storedNumber}`);Celestium DEX Testnet is a decentralized exchange built on the Celestium blockchain. Below are the official smart contract addresses for the key components of the DEX.
Core Contracts
Multicall: 0xe49FCCDb659ACA606A9AbD8EC478bc7462c67CEa
Used to aggregate multiple contract read calls into a single call to improve efficiency.
Factory: 0xf467e3D49684bbDCFaFA73fC00FAeA85b180c456
The core contract responsible for creating and managing liquidity pools.
Router: 0xC24c897b5b78Da2Db8b590fc7f6f5402d8FD6754
Facilitates token swaps and liquidity provision by interacting with the factory contract.
Wrapped CLT (WCLT): 0xA316eb29ceD1277A1B22e8c16C9c66440F6A8446
A wrapped version of CLT used for liquidity pairs and swap functions.
USDT: 0xcB008c98885Fc3c24105c411111F9F0C6ee2ed36
Stablecoin available for trading pairs and liquidity pools.
Token Contracts
CelestiumFuel: 0x711e2157e573B5704084a24fC7a2EaD8aeE36972
A utility token for specific functionalities within the Celestium ecosystem.
Developers and liquidity providers can interact with these contracts using web3 libraries such as Ethers.js or Web3.js. These contracts allow:
Swapping tokens on-chain using the router contract.
Adding liquidity to pools for earning trading fees.
Fetching aggregated data via the multicall contract.
Running a Celestium node requires robust hardware to ensure optimal performance, network stability, and seamless participation in consensus processes. The following hardware specifications are recommended for validators and full nodes.
Validator nodes play a critical role in block production and consensus. These nodes must meet higher performance standards due to their responsibilities within the CelesBFT and Proof of Authority + AI (PoAi) consensus mechanisms.
Full nodes maintain a complete copy of the blockchain, validate blocks and transactions, and support network stability.
Archive nodes store the entire history of the blockchain, including pruned state data, and are mainly used by blockchain explorers, data analytics, and research applications.
High-Performance Disk I/O: Essential for Celestium’s CelesDb, which optimizes state storage access.
Parallel and Asynchronous Execution: Multi-core processors significantly improve transaction throughput.
GPU Acceleration: Enhances AI-driven validator operations and improves fraud detection efficiency in PoAi consensus.
Enable firewalls and restrict access to RPC and P2P ports.
Implement DDoS protection for validator nodes.
Use dedicated servers or cloud infrastructure with high uptime guarantees (e.g., AWS, Google Cloud, or bare-metal providers).
Investing in robust hardware ensures stability, security, and high throughput, aligning with Celestium’s goal of achieving 10,000 transactions per second through cutting-edge blockchain architecture.
Querying blockchain data on Celestium allows users and developers to retrieve information about blocks, transactions, balances, and contract states. This can be done using Ethereum-compatible JSON-RPC API methods.
Below are the most commonly used RPC methods to query data from Celestium:
Get the Latest Block Number
Returns the current block number.
Get Block Details by Number
Fetches details of a specific block.
Replace BLOCK_NUMBER with a hexadecimal block number (e.g., 0x1A for block 26).
Get Transaction Details
Fetches the details of a transaction by its hash.
Replace TRANSACTION_HASH with the transaction hash.
Get Transaction Receipt
Checks the status and logs of a transaction.
Get Account Balance
Retrieves the balance of an account in wei.
Replace ADDRESS with the account address.
You can also use libraries like ethers.js or web3.js to query blockchain data within your application:
For a user-friendly way to explore transactions, blocks, and addresses, visit the Celestium Testnet Explorer:
🔗
Querying blockchain data is essential for monitoring transactions, tracking balances, and interacting with smart contracts. Celestium’s compatibility with the Ethereum API ensures that developers can integrate with existing tools seamlessly.
Providing liquidity on Celestium Swap Testnet allows users to contribute assets to liquidity pools, enabling seamless token swaps while earning rewards from transaction fees. Follow the steps below to add liquidity to the Celestium Swap Testnet.
Before proceeding, ensure you have the following:
A MetaMask wallet or any Web3-compatible wallet.
Sufficient CLT tokens and the paired token in your wallet.
Connected to the Celestium Testnet network.
Access to .
Navigate to .
Click "Connect to a wallet" in the top-right corner.
Select MetaMask or another compatible wallet and approve the connection.
Ensure that you are connected to the Celestium Testnet.
Click on the "Liquidity" tab in the navigation menu.
Select "Add Liquidity" to proceed.
Choose CLT as the first token.
Select a second token from the available options.
Enter the amount of CLT and the corresponding amount of the second token.
Ensure both token values are correctly balanced based on the pool’s ratio.
If this is your first time adding liquidity, click "Approve" next to both tokens.
Confirm the approval transaction in your wallet.
Click "Supply" to proceed.
Review the transaction details, including pool share and expected returns.
Confirm the transaction in your wallet.
Once confirmed, your liquidity is successfully added, and you will receive Liquidity Provider (LP) tokens.
Navigate to the "Liquidity" tab.
Check the list of liquidity pairs where you have contributed funds.
Your added liquidity and earned rewards will be displayed.
Removing Liquidity: To remove liquidity, go to the "Remove Liquidity" section, select your LP tokens, and withdraw your assets.
Gas Fees: Transactions on the testnet may require a small amount of test CLT tokens.
Celestium Coin ($CLT) Tokenomics
Celestium Coin ($CLT) is designed with a well-balanced tokenomics model to ensure sustainable growth, strong liquidity, and long-term ecosystem development. Below is a detailed breakdown of the token distribution and transaction tax structure.
100,000,000 CLT
Liquidity: 90% Ensuring deep liquidity for seamless trading and price stability.
Marketing: 1.5% Allocated for strategic promotions, partnerships, and brand awareness.
Bridge Mainnet: 2% Dedicated to facilitating cross-chain interactions and bridging mechanisms.
Community Reward: 1% Designed to incentivize and reward active participation within the ecosystem.
3% for Marketing: Ensuring sustained growth, user adoption, and brand visibility.
1% for Development: Supporting the ongoing technical advancements and ecosystem expansion.
This tokenomics model ensures that Celestium remains a robust, scalable, and community-driven Layer 1 blockchain while securing long-term incentives for users, developers, and validators.
Gas fees and transaction prioritization are essential components of the Celestium network’s transaction processing system. They determine the cost of computational operations and influence the order in which transactions are included in blocks.
Gas is a unit that measures computational work required to execute operations on the Celestium blockchain. Every transaction and smart contract execution consumes gas based on the complexity of the operation.
Purpose of Gas
curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_blockNumber",
"params":[],
"id":1
}'Development: 1% Supporting continuous improvements and upgrades of Celestium's infrastructure.
Team: 1% Reserved for the core team to sustain long-term commitment and project stability.
DeFi Supply: 1.5% Allocated for DeFi-related utilities, partnerships, and ecosystem expansion.
Staking Reward: 1% Providing incentives to holders who contribute to network security and stability.
Validator Reward: 1% Rewards distributed to validators for maintaining network integrity and consensus.
500 Mbps
Not required
Archive Node
16+
64 GB
8 TB SSD
1 Gbps
Not required
CPU
8-core (16-thread) CPU, 3.0 GHz or higher (e.g., AMD Ryzen 9 / Intel Xeon)
RAM
32 GB DDR4 or higher
Storage
2 TB NVMe SSD (High-speed, for fast state access and block storage)
Network
1 Gbps dedicated connection (low latency)
Operating System
Linux (Ubuntu 22.04 LTS recommended)
GPU (Optional)
NVIDIA GPU (e.g., RTX 3080 or higher) for AI-enhanced validation tasks
CPU
4-core (8-thread) CPU, 2.5 GHz or higher
RAM
16 GB DDR4 or higher
Storage
1 TB SSD (NVMe preferred)
Network
500 Mbps connection (low latency)
Operating System
Linux (Ubuntu 22.04 LTS recommended)
CPU
16-core (32-thread) CPU, 3.2 GHz or higher
RAM
64 GB DDR4 or higher
Storage
8 TB NVMe SSD
Network
1 Gbps dedicated connection
Operating System
Linux (Ubuntu 22.04 LTS recommended)
CPU
AMD Ryzen 9 5950X (16 cores, 32 threads, 3.4 GHz)
RAM
64 GB DDR4
Storage
Samsung 980 Pro 2TB NVMe SSD
Network
1 Gbps Fiber Connection
OS
Ubuntu 22.04 LTS
GPU
NVIDIA RTX 3090 (for AI acceleration)
Validator
8+
32 GB
2 TB SSD
1 Gbps
High-end GPU
Full Node
4+
16 GB
1 TB SSD
Prevents spam and inefficient computation.
Aligns computational effort with economic cost.
Incentivizes validators to process transactions.
Gas Units
Each Ethereum Virtual Machine (EVM) opcode has a predefined gas cost. Celestium inherits these gas costs from Ethereum, ensuring compatibility.
Gas fees represent the amount a user is willing to pay to execute a transaction. They are calculated as:
Where:
Gas Used: Total gas consumed during transaction execution.
Gas Price: Amount the user is willing to pay per gas unit, denominated in CLT (native token).
EIP-1559 Fee Model
Celestium supports the EIP-1559 fee model, comprising:
Base Fee: Minimum fee per gas unit, dynamically adjusted based on network congestion.
Priority Fee (Tip): Additional fee paid to validators to prioritize transaction processing.
Max Fee: Maximum total fee the user is willing to pay per gas unit.
Effective gas fee is determined as:
Example
Gas Used
21,000
Base Fee
2 gwei
Priority Fee
1 gwei
Max Fee
5 gwei
Effective Gas Price
3 gwei
Transaction Fee
21,000 × 3 gwei = 63,000 gwei
Gas limit represents the maximum gas units a user is willing to spend for a transaction. If a transaction exceeds this limit, it fails, and the gas is still consumed.
Best Practice
Estimate gas consumption using tools like estimateGas() from libraries such as Web3.js.
Celestium utilizes a Priority Gas Auction (PGA) mechanism to prioritize transactions. Validators order transactions based on Priority Fee (Tip) in descending order. Transactions offering higher tips are processed first.
How PGA Works:
Users submit transactions with varying gas prices (priority fees).
Validators select transactions offering the highest priority fees.
High-demand periods lead to users competing by increasing tips.
Transactions with lower tips may experience delays or fail to be included.
Key Implications:
Users can expedite transaction processing by increasing the priority fee.
PGA fosters a dynamic fee market, ensuring optimal resource allocation.
Low Network Congestion: Base fee remains low, and minimal priority fees are required.
High Network Congestion: Base fee increases, and users must pay higher priority fees to secure transaction inclusion.
Monitor network conditions to avoid overpaying during low congestion.
Use EIP-1559 transactions with an appropriate max fee and priority fee to balance cost and speed.
Leverage tools like eth_gasPrice or third-party services to estimate current gas fees.
Gas fees ensure fair resource allocation and prevent spam.
Base Fee adapts dynamically; Priority Fee influences transaction speed.
Priority Gas Auction orders transactions by tips during congestion.
Users should adjust gas fees based on network conditions for cost efficiency.
Celestium’s gas model aligns with Ethereum standards, ensuring a familiar experience for developers and users transitioning from existing EVM-compatible networks.
curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_getBlockByNumber",
"params":["0xBLOCK_NUMBER", true],
"id":1
}'curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_getTransactionByHash",
"params":["0xTRANSACTION_HASH"],
"id":1
}'curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_getTransactionReceipt",
"params":["0xTRANSACTION_HASH"],
"id":1
}'curl -X POST http://rpc-private-testnet.celestium.network -H "Content-Type: application/json" --data '{
"jsonrpc":"2.0",
"method":"eth_getBalance",
"params":["0xADDRESS", "latest"],
"id":1
}'const { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider("http://rpc-private-testnet.celestium.network");
const balance = await provider.getBalance("0xADDRESS");
console.log(`Balance: ${ethers.formatEther(balance)} CLT`);Gas Fee = Gas Used × Gas PriceEffective Gas Price = Base Fee + Priority FeeEditconst Web3 = require('web3');
const web3 = new Web3('https://rpc-private-testnet.celestium.network');
async function getGasPrice() {
const gasPrice = await web3.eth.getGasPrice();
console.log('Current Gas Price:', web3.utils.fromWei(gasPrice, 'gwei'), 'gwei');
}
getGasPrice();CelesDb is a custom-built database designed to optimize the storage and retrieval of blockchain state data for the Celestium network. Unlike traditional key-value databases commonly used in blockchain clients, CelesDb is specifically tailored to meet the demands of high-throughput parallel execution and asynchronous state management.
Most Ethereum clients rely on general-purpose key-value stores like LevelDB, RocksDB, or LMDB, which internally use data structures such as B-Trees or LSM-Trees. However, Ethereum itself represents state using a Merkle Patricia Trie (MPT). This results in a mismatch between the underlying storage structure and the logical state representation, causing performance inefficiencies.
Celestium adopts Parallel Execution to maximize throughput and utilize modern multi-core processors effectively. By executing multiple transactions simultaneously, Celestium significantly improves performance compared to traditional blockchains that rely on serial transaction processing.
In most blockchains, transactions are executed sequentially. Each transaction updates the global state, and the result of one transaction can affect the next. This approach ensures correctness but creates a performance bottleneck.
Parallel execution allows multiple transactions to be executed concurrently, provided they do not interfere with each other
Feature
Description
Native Patricia Trie Implementation
CelesDb stores blockchain state directly as a Patricia Trie on disk and in memory, optimizing access times.
Asynchronous I/O (async I/O)
Supports non-blocking database operations using modern system calls (e.g., io_uring on Linux).
Parallel State Access
Designed to support parallel transaction execution, allowing concurrent reads and writes.
Low-latency Performance
Bypasses filesystem caching in certain cases for direct I/O access, reducing overhead.
Optimized for High Throughput
Supports batch writes and parallel state reads to match the demands of Celestium’s parallel execution model.
A critical feature of CelesDb is its support for asynchronous I/O operations. Since Celestium executes multiple transactions in parallel, traditional blocking I/O would cause performance bottlenecks. Instead, CelesDb uses Linux’s io_uring interface to enable non-blocking, kernel-level asynchronous I/O operations. This allows:
Multiple I/O requests to be initiated simultaneously.
CPU resources to be used for other tasks while waiting for disk operations to complete.
Reduced context switching compared to traditional thread-based blocking I/O.
Parallel transaction execution requires efficient concurrent access to state. CelesDb is designed to support:
Concurrent Reads: Multiple transactions can read state simultaneously without blocking each other.
Optimistic Writes: Transactions write to isolated state buffers during execution, reducing conflicts.
State Merging: After transactions execute, CelesDb merges state changes in block order to ensure deterministic final state.
Optimization
Description
Direct I/O Access
Avoids OS-level filesystem caching in certain cases to reduce overhead.
Batch Writes
Bundles multiple state changes into a single write operation for efficiency.
Memory-efficient Trie Nodes
Stores Patricia Trie nodes in compact formats, minimizing memory and disk usage.
Faster Block Processing: Reduces state access latency during parallel and optimistic execution.
Improved Scalability: Handles high transaction throughput by supporting parallel state access.
Lower Resource Usage: Efficient memory and disk management tailored for blockchain workloads.
Aspect
CelesDb
LevelDB / RocksDB
Data Structure
Native Patricia Trie
LSM-Tree / B-Tree
Async I/O Support
Full support via io_uring
Limited / None
Parallel Access
Built-in support for parallel reads/writes
Designed for sequential access
Blockchain State Efficiency
Optimized for Patricia Trie-based state storage
General-purpose storage
CelesDb will continue to be improved with:
Further optimizations for Patricia Trie compaction.
Caching strategies to reduce disk access for frequently read state.
Cross-platform async I/O support beyond Linux (e.g., Windows IOCP).
CelesDb is a cornerstone innovation of the Celestium blockchain, enabling high-performance state management that aligns with parallel and asynchronous execution models. This custom database ensures that Celestium can achieve scalability and efficiency without compromising on Ethereum-compatible state guarantees.
Celestium employs an optimistic execution model to parallelize transaction processing:
Transactions are optimistically executed in parallel without waiting for prior transactions in the block to complete.
Each transaction tracks the state it reads and writes (read-set and write-set).
After execution, the outputs are merged in block order:
If two transactions access different parts of the state, they merge seamlessly.
If two transactions conflict (e.g., they modify the same account), the later transaction is re-executed with updated state.
This model ensures that the final state is identical to sequential execution, preserving Ethereum compatibility.
Consider a block with these transactions:
Tx1: Alice sends 10 CLT to Bob.
Tx2: Charlie deploys a smart contract.
Tx3: Bob interacts with a DeFi protocol.
Parallel Execution:
Tx1 updates Alice and Bob’s balances.
Tx2 deploys a contract, unrelated to Tx1 or Tx3.
Tx3 involves Bob’s balance, which depends on Tx1.
What happens:
Tx1 and Tx2 execute in parallel.
Tx3 starts optimistically but fails because it reads Bob’s balance before Tx1 completes.
After Tx1 is finalized, Tx3 is re-executed with the correct balance.
Celestium uses static analysis and runtime checks to manage dependencies:
Static Analysis: Before execution, Celestium predicts potential conflicts based on transaction input data.
Runtime Conflict Detection: After execution, read-sets and write-sets are compared to detect conflicts. Conflicting transactions are automatically re-executed.
This hybrid approach minimizes unnecessary re-executions and maximizes parallelism.
Benefit
Impact
Increased Throughput
Multiple transactions processed simultaneously.
Reduced Latency
Faster execution, especially for non-conflicting transactions.
Efficient Resource Utilization
Full use of modern multi-core CPUs.
Ethereum Compatibility
Execution results are identical to serial processing.
Transactions with independent state (e.g., transfers between different users) benefit the most.
High-conflict transactions (e.g., interacting with the same contract) may require re-execution, but Celestium’s conflict detection minimizes the overhead.
Feature
Parallel Execution
Asynchronous Execution
Focus
Execution parallelism
Decoupling consensus from execution
Key Benefit
Increased throughput
Extended execution budget
Compatibility
Ethereum-compatible
Ethereum-compatible
When processing a block, Celestium’s execution engine:
Analyzes transactions for potential conflicts.
Executes independent transactions in parallel.
Detects conflicts and re-executes affected transactions if needed.
Merges results in block order to ensure final state consistency.
This approach allows Celestium to achieve high throughput while maintaining the deterministic nature of blockchain state transitions.
CPU Usage
Tracks processor load during consensus and execution tasks.
Memory Usage (RAM)
Monitors memory consumption, especially during execution.
Disk I/O
Measures read/write operations on the NVMe SSD storage.
Peers Connected
Number of peers the node is connected to.
Block Time
Measures the time taken to validate and finalize a block.
Gas Usage per Block
Tracks the average gas consumption per block.
Transaction Pool Size
Number of pending transactions in the mempool.
Network Bandwidth
Monitors data sent and received by the node.
Celestium nodes provide performance metrics via a built-in monitoring interface. You can enable and access metrics in the node’s startup command:
Metrics are typically exposed via Prometheus or logged locally for further analysis.
Install Prometheus:
Configure Prometheus to scrape Celestium metrics (e.g., localhost:9090/metrics):
Install Grafana:
Connect Prometheus to Grafana:
Open Grafana (http://localhost:3000).
Add Prometheus Data Source → http://localhost:9090.
Build custom dashboards for CPU usage, memory, block sync status, and other metrics.
Logs provide detailed information about node operations, including consensus, execution errors, and block production:
Look for key entries like:
Finalized Block: Confirmation that a block is validated.
Sync Status: Current sync progress with the network.
Execution Errors: Potential issues during transaction processing.
Set up alerts for high CPU, memory usage, or node desynchronization.
Monitor block finality time to detect performance bottlenecks.
Check peers regularly to ensure stable network connectivity.
Track disk health when running NVMe SSDs, as high throughput can affect longevity.
Monitoring node performance helps ensure reliability, prevents downtime, and allows operators to proactively address issues on the Celestium network.
Block Sync Status
Indicates if the node is in sync with the network.
bash
sudo apt update
sudo apt install prometheusyaml
scrape_configs:
- job_name: 'celestium_node'
static_configs:
- targets: ['localhost:9090']bash
sudo apt install grafanabash
./celestium-node --rpc http://rpc-private-testnet.celestium.network --chain-id 252525 --metricsbash
tail -f node.logThis guide will walk you through deploying an ERC-20 token smart contract on the Celestium Testnet using Remix , a web-based Solidity IDE.
Before proceeding, ensure you have the following:
A MetaMask wallet connected to the Celestium Testnet.
Some test CLT tokens from the .
Basic familiarity with Solidity and Remix IDE.
Open MetaMask and go to Settings > Networks > Add Network.
Enter the Celestium Testnet details:
Network Name: Celestium Testnet
Visit the .
Enter your MetaMask wallet address and request test CLT.
Wait for the tokens to be sent to your wallet.
Go to Remix IDE.
Click Create New File and name it Token.sol.
Copy and paste the following Solidity code:
Replace "Name Coin" with your token name.
Replace "TICKER" with your token symbol.
In Remix, go to the Solidity Compiler tab.
Select the Solidity Version 0.8.16.
Click Compile Token.sol.
Ensure there are no errors before proceeding.
Go to the Deploy & Run Transactions tab.
In the Environment dropdown, select Injected Provider - MetaMask.
Make sure your MetaMask is connected to Celestium Testnet.
Click Deploy and confirm the transaction in MetaMask.
Copy the contract address from Remix.
Visit Celestium Testnet Explorer.
Paste the contract address in the search bar to view details.
Add your token to MetaMask:
Open MetaMask and click Import Tokens.
Enter the contract address.
Click Add Token.
You have successfully deployed an ERC-20 token on the Celestium Testnet using Remix. This token can now be used for further development, testing, or integration with dApps.
For additional support, join the Celestium Community:
🔹 Telegram: @Celestium_Network 🔹 Website: 🔹 Faucet:
CelesBFT is the consensus protocol used by Celestium to achieve fast, secure, and deterministic finality in a decentralized environment. It is designed to handle high-throughput blockchain operations while ensuring Byzantine Fault Tolerance (BFT) and Proof-of-Authority combined with AI (PoAi) for Sybil resistance.
CelesBFT is a pipelined, two-phase consensus protocol adapted from HotStuff with enhancements from DiemBFT and Jolteon. It optimizes transaction finality and leader rotation while minimizing communication overhead.
Consensus Participants
Leader: Proposes a block containing transactions.
Validators: Validate the proposed block and vote on its validity.
Round Structure
Each consensus round consists of the following steps:
Proposal: The leader broadcasts a block proposal with a quorum certificate (QC) or timeout certificate (TC) for the previous round.
Voting: Validators verify the block and sign a YES vote if valid.
Quorum Certificate (QC): If 2f + 1 votes are received (f is the number of tolerated Byzantine nodes), the next leader aggregates the signatures into a QC.
Timeout Certificate (TC): If a block is not proposed on time, validators submit timeout messages. Upon reaching 2f + 1, a TC is formed.
A block is finalized when two consecutive certified blocks are observed:
Block k is finalized when a QC is formed for Block k+1 and a valid proposal for Block k+2 is seen.
CelesBFT uses BLS signatures for aggregating validator votes:
BLS12-381 Curve: Allows signature aggregation into a single signature.
ECDSA: Used for other message types for performance efficiency.
The blend of BLS and ECDSA ensures both performance and compactness in consensus messages.
CelesBFT can tolerate up to f Byzantine nodes in a network of 3f + 1 validators. This guarantees consensus safety and liveness as long as at least 2/3 of the validators are honest.
Single-Slot Finality: Once a block is finalized, it is irreversible unless a supermajority behaves maliciously.
Finality Time: 1 second per block, offering faster transaction confirmation compared to probabilistic finality systems like Ethereum Proof-of-Stake.
Fast Finality: Transactions are confirmed in 1 second.
Efficiency: Reduced communication complexity in the happy path.
Scalability: Supports high transaction throughput due to pipelined processing.
Security: Robust Byzantine Fault Tolerance with cryptographic signature aggregation.
CelesBFT’s combination of performance and security makes it a cornerstone of Celestium’s high-throughput Layer 1 blockchain architecture.
Celestium introduces Asynchronous Execution as a core innovation to significantly enhance transaction throughput and system performance. This approach decouples the execution of transactions from the consensus process, enabling both processes to run in parallel.
Traditional blockchains like Ethereum follow an interleaved execution model, where consensus and execution are tightly coupled:
A block proposer assembles a block and executes all transactions in it.
Validators execute the transactions before voting to agree on the block's validity.
The block is finalized only after both consensus and execution are complete.
This approach leads to performance bottlenecks because:
Execution delays block finalization.
The gas limit must be conservative to ensure execution completes within the block time.
Block time is underutilized, as consensus occupies most of it.
Celestium decouples consensus and execution into two separate processes:
Consensus Layer: Determines the order of transactions within a block without executing them.
Execution Layer: Executes transactions after a block is finalized.
Key Differences from Traditional Execution:
1. Increased Execution Throughput
Since execution is no longer constrained by consensus, the full block time (1 second) can be dedicated to execution. This results in a much higher gas limit per block and improved throughput.
2. Faster Finality
Finality is achieved in 1 second based on transaction ordering alone. Users know their transactions are included in the blockchain without waiting for execution to complete.
3. Reduced Execution Latency
Nodes can optimize execution pipelines and parallelize transaction processing, further increasing system efficiency.
4. Improved Resilience
Nodes can handle execution failures independently without delaying consensus. For example, if a node executes transactions incorrectly, it can detect this later and re-execute them correctly.
To maintain state consistency across nodes:
Each block header contains a Merkle root representing the final state.
This root is delayed by D blocks (e.g., D=10), allowing nodes time to execute and confirm the correct state.
Nodes that detect discrepancies in state can rollback and re-execute blocks until their state matches the agreed Merkle root.
This approach ensures that all nodes converge on the same state while enabling fast block finality.
Since consensus only orders transactions, failed transactions are still included in blocks.
Nodes will execute transactions later; if a transaction fails (e.g., out of gas), it will still fail consistently across all nodes.
Users can query the result after execution completes, with no effect on finality.
Asynchronous execution is a fundamental shift that allows Celestium to:
Scale beyond the limitations of single-threaded execution.
Support complex applications with higher gas limits.
Maintain fast finality and user experience without sacrificing security.
This innovation positions Celestium as a performance-optimized Layer 1 blockchain while retaining full compatibility with the Ethereum ecosystem.
After a transaction is submitted, propagated, included in a block, finalized, and executed locally, users often need to verify the outcome of the transaction. This final step ensures that the transaction was successful and allows users to retrieve relevant data such as gas usage, status, and event logs.
Users can check the outcome of a transaction by querying an RPC node using the transaction hash. This can be done using two primary JSON-RPC methods:
Finality: A block is considered finalized when a QC for the subsequent block is formed.
Sybil Resistance
Proof-of-Authority + AI (PoAi)
Block Time
1 second
Finality
Single-slot finality (block finalized after 1 second)
Delegation
Supported
Pipelined Rounds
Optimized two-phase consensus rounds with pipelining
Optimistic Responsiveness
Fast finality under normal conditions
BLS Multi-Signatures
Efficient certificate aggregation with BLS12-381 curve
Consensus + Execution
Happens together within block time.
Consensus first, execution after.
Execution Budget
Limited by consensus time.
Full block time available.
Finality
Includes execution result.
Finality is about ordering; execution follows.
Block N
Finalized (1s)
Execution begins
Block N+1
Finalized (1s)
Execution continues
Block N+D
Finalized (1s)
Merkle root confirmed
Transaction Submission
Near-instant inclusion (1s).
Order Finality
Guaranteed in 1s.
Execution Outcome
Typically available in < 1s after finality for full nodes.
Light Client Proof
Available after D=10 blocks (~10s) with Merkle proof.
https://rpc-testnet.celestium.networkChain ID: 252525
Currency Symbol: tCLT
Block Explorer URL: https://explorer-testnet.celestium.network
Click Save and switch to the Celestium Testnet network.
Test token transfers:
Use Remix to call transfer() to send tokens.
Check the balance using balanceOf().
// SPDX-License-Identifier: MIT
pragma solidity 0.8.16;
interface IERC20 {
function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address recipient, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(
address sender,
address recipient,
uint256 amount
) external returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);
}
interface IERC20Metadata is IERC20 {
function name() external view returns (string memory);
function symbol() external view returns (string memory);
function decimals() external view returns (uint8);
}
abstract contract Context {
function _msgSender() internal view virtual returns (address) {
return msg.sender;
}
function _msgData() internal view virtual returns (bytes calldata) {
this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691
return msg.data;
}
}
contract ERC20 is Context, IERC20, IERC20Metadata {
mapping(address => uint256) private _balances;
mapping(address => mapping(address => uint256)) private _allowances;
uint256 private _totalSupply;
string private _name;
string private _symbol;
constructor(string memory name_, string memory symbol_) {
_name = name_;
_symbol = symbol_;
}
function name() public view virtual override returns (string memory) {
return _name;
}
function symbol() public view virtual override returns (string memory) {
return _symbol;
}
function decimals() public view virtual override returns (uint8) {
return 18;
}
function totalSupply() public view virtual override returns (uint256) {
return _totalSupply;
}
function balanceOf(address account) public view virtual override returns (uint256) {
return _balances[account];
}
function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
_transfer(_msgSender(), recipient, amount);
return true;
}
function allowance(address owner, address spender) public view virtual override returns (uint256) {
return _allowances[owner][spender];
}
function approve(address spender, uint256 amount) public virtual override returns (bool) {
_approve(_msgSender(), spender, amount);
return true;
}
function transferFrom(
address sender,
address recipient,
uint256 amount
) public virtual override returns (bool) {
uint256 currentAllowance = _allowances[sender][_msgSender()];
if (currentAllowance != type(uint256).max) {
require(currentAllowance >= amount, "CLT20: transfer amount exceeds allowance");
unchecked {
_approve(sender, _msgSender(), currentAllowance - amount);
}
}
_transfer(sender, recipient, amount);
return true;
}
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender] + addedValue);
return true;
}
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
uint256 currentAllowance = _allowances[_msgSender()][spender];
require(currentAllowance >= subtractedValue, "CLT20: decreased allowance below zero");
unchecked {
_approve(_msgSender(), spender, currentAllowance - subtractedValue);
}
return true;
}
function _transfer(
address sender,
address recipient,
uint256 amount
) internal virtual {
require(sender != address(0), "CLT20: transfer from the zero address");
require(recipient != address(0), "CLT20: transfer to the zero address");
_beforeTokenTransfer(sender, recipient, amount);
uint256 senderBalance = _balances[sender];
require(senderBalance >= amount, "CLT20: transfer amount exceeds balance");
unchecked {
_balances[sender] = senderBalance - amount;
}
_balances[recipient] += amount;
emit Transfer(sender, recipient, amount);
_afterTokenTransfer(sender, recipient, amount);
}
function _mint(address account, uint256 amount) internal virtual {
require(account != address(0), "CLT20: mint to the zero address");
_beforeTokenTransfer(address(0), account, amount);
_totalSupply += amount;
_balances[account] += amount;
emit Transfer(address(0), account, amount);
_afterTokenTransfer(address(0), account, amount);
}
function _burn(address account, uint256 amount) internal virtual {
require(account != address(0), "CLT20: burn from the zero address");
_beforeTokenTransfer(account, address(0), amount);
uint256 accountBalance = _balances[account];
require(accountBalance >= amount, "CLT20: burn amount exceeds balance");
unchecked {
_balances[account] = accountBalance - amount;
}
_totalSupply -= amount;
emit Transfer(account, address(0), amount);
_afterTokenTransfer(account, address(0), amount);
}
function _approve(
address owner,
address spender,
uint256 amount
) internal virtual {
require(owner != address(0), "CLT20: approve from the zero address");
require(spender != address(0), "CLT20: approve to the zero address");
_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
}
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}
function _afterTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual {}
}
contract NameContract is ERC20 { // dont use space for this section
constructor () ERC20("Name Coin", "TICKER/SYMBOL") // Change your name Coin and Ticker
{
_mint(msg.sender, 100_000_000 * (10 ** 18)); // Supply of Coin & Decimals
}
}Description
eth_getTransactionByHash
Returns information about a transaction by hash.
eth_getTransactionReceipt
Returns the receipt containing the execution result.
The most common method for checking the final outcome is eth_getTransactionReceipt.
A transaction receipt is a data structure containing the execution result of a transaction:
Field
Description
transactionHash
Hash of the transaction.
blockNumber
Block number in which the transaction was included.
status
1 for success, 0 for failure.
from
Address of the sender.
to
Address of the recipient (or contract creation address).
gasUsed
Total gas used by the transaction.
Web3.js Example
cURL Example
Scenario
Meaning
Receipt is null
Transaction is pending or not found.
status == 1
Transaction was successful.
status == 0
Transaction failed (e.g., out of gas or revert).
logs contains events
Smart contract emitted events during execution.
contractAddress != null
Contract was successfully deployed.
Verifying Token Transfers: Check logs for Transfer events from ERC-20 contracts.
Contract Deployment: Retrieve the contractAddress after a successful deployment.
Gas Estimation: Analyze gasUsed and effectiveGasPrice for future transactions.
If the transaction is still pending, users can also query:
Method
Description
eth_getTransactionByHash
Returns transaction details even if it is still pending.
Always check status in the receipt before assuming success.
Monitor gas usage (gasUsed) to estimate costs more accurately.
Handle pending transactions gracefully in applications by implementing retries.
Querying transaction outcomes is a critical step in the transaction lifecycle. It provides clarity to users and developers, ensuring that transactions are executed as intended. Celestium’s Ethereum RPC compatibility allows seamless integration with existing Ethereum tools, making this process familiar and efficient for developers.
Method
Local execution refers to the process by which a node processes and executes transactions from a finalized block to determine the post-state of the blockchain. This is a critical step in ensuring that all nodes in the network arrive at the same state after a block has been added to the chain.
Once a block is finalized through the CelesBFT consensus mechanism, the block and its transactions are considered immutable and part of the blockchain's history. After finalization:
Each node begins executing the transactions contained in the block.
Execution is performed optimistically and in parallel for efficiency.
The final state is merged sequentially to ensure deterministic results across all nodes.
Local execution is carried out within the EVM-compatible runtime environment of Celestium. This allows for compatibility with Ethereum smart contracts, including contracts written in Solidity.
Key elements of the execution environment:
Gas Accounting: Each transaction consumes gas based on the complexity of its operations.
Opcode Compatibility: The same gas costs per opcode as Ethereum are used.
Parallel Execution: Transactions are executed concurrently where possible.
State Merger: Final state changes are applied sequentially to maintain consistency.
Each transaction undergoes the following steps during local execution:
Celestium employs optimistic execution and parallel transaction execution to maximize throughput:
Transactions are optimistically executed in parallel, assuming that their state accesses do not conflict.
State access tracking detects conflicts. If a conflict is found, the affected transaction is re-executed.
Final state changes are merged sequentially in the order of transactions in the block.
This approach allows Celestium to maintain Ethereum-like execution semantics while achieving high throughput.
After all transactions in a block are executed:
The final state is committed to CelesDb.
A state root hash is computed and stored as part of the block.
This hash allows light clients and other nodes to verify the state with Merkle proofs.
Users can query the result of transaction execution via RPC:
The receipt includes:
status: 1 for success, 0 for failure.
blockNumber: The block containing the transaction.
gasUsed: Amount of gas consumed.
After submitting a transaction, a user may want to verify its success:
This final step ensures users can confirm that their transactions have been successfully executed and included in the blockchain state.
Local execution is a fundamental part of Celestium’s transaction lifecycle, ensuring that every node independently verifies and applies transactions consistently. By combining parallel execution, optimistic techniques, and EVM compatibility, Celestium delivers high performance while preserving the reliability and determinism expected from blockchain systems.
Block inclusion is the process through which transactions from the mempool are selected, ordered, and packaged into a block by a validator. This block is then proposed to the network and, upon consensus, is finalized as part of the blockchain. Understanding block inclusion is crucial for developers and node operators as it determines the finalization and ordering of transactions on Celestium.
Celestium uses the CelesBFT consensus algorithm with a Proof of Authority + AI (PoAi) mechanism to produce blocks. Block production follows a rotating leader model:
In each round (every 1 second), a validator is designated as the leader.
The leader is responsible for selecting pending transactions from the mempool and constructing a block.
Validators vote on the proposed block.
If two-thirds (2/3) of the validators agree, the block is finalized and added to the blockchain.
This approach guarantees 1-second finality, meaning that once a block is finalized, it is irreversible unless a Byzantine fault occurs.
When a validator assembles a block, it follows these principles:
a. Gas Price Priority (Priority Gas Auction - PGA):
Transactions with higher gas fees (maxFeePerGas) are prioritized.
The validator aims to maximize transaction fees collected as block rewards.
b. Available Balance Validation:
The available balance of the account is checked in real-time.
Transactions that would exceed an account's available balance (considering other pending transactions) are skipped.
c. Gas Limit Considerations:
Each block has a block gas limit.
The sum of the gas limits of included transactions cannot exceed the block gas limit.
When evaluating transactions, the maximum potential cost is calculated as:
The validator verifies that the account’s available balance can cover this amount before including the transaction.
Once a block is assembled:
The leader broadcasts the block proposal to other validators.
Validators validate the block:
Check transaction validity.
Verify the block signature.
Finalization is achieved in a single slot (1 second), ensuring near-instant certainty.
After a transaction is included in a block:
It becomes part of the blockchain’s history.
It is considered final and cannot be reversed without network failure.
The transaction’s outcome (success or failure) is determined during execution.
Users can retrieve the transaction status using:
This will return the block number, status, and logs associated with the transaction.
The block gas limit restricts the amount of computational work that can be performed in a single block. It ensures that block production and propagation remain fast, maintaining Celestium’s high throughput.
Example:
Block Gas Limit: 30,000,000
Transaction 1 Gas Limit: 500,000
Transaction 2 Gas Limit: 2,000,000
The validator can include both transactions as long as their total gas limit does not exceed the block limit.
Transactions may remain in the mempool or be rejected if:
The transaction fee is too low.
The transaction requires more gas than the block gas limit allows.
The account lacks sufficient funds after other transactions are included.
The transaction depends on a nonce sequence that is not yet met.
Rejected transactions can be replaced by resubmitting with a higher gas price.
1-Second Finality: Transactions are final within a single slot.
Gas Auction Efficiency: Ensures optimal fee selection.
Balance Validation: Reduces failed transactions in blocks.
High Throughput: Block gas limits are optimized for performance.
Understanding block inclusion helps developers and users optimize transaction fees and timing, ensuring transactions are processed efficiently in Celestium’s high-performance environment.
Efficient state storage is critical for high-performance blockchains like Celestium, which aims to achieve high throughput and low-latency execution. Optimizing how blockchain state is stored and accessed directly impacts the speed of transaction processing, block validation, and node synchronization.
CelesDb is the foundation of Celestium’s state storage, but additional optimizations are applied to maximize performance and reduce resource consumption.
Blockchain state represents account balances, smart contract data, and other state variables. This state grows continuously as transactions modify it. Key challenges include:
Submitting a transaction is the initial step in interacting with the Celestium blockchain. This process involves creating a signed transaction that reflects the user's intention, whether it is sending native tokens (CLT), interacting with a smart contract, or deploying a new contract.
Understanding the transaction submission process is essential for both developers building applications on Celestium and users seeking to conduct secure and efficient blockchain operations.
A transaction in Celestium adheres to the Ethereum transaction format, following standards such as:
const Web3 = require('web3');
const web3 = new Web3('https://rpc-private-testnet.celestium.network');
async function getTransactionReceipt(txHash) {
const receipt = await web3.eth.getTransactionReceipt(txHash);
if (receipt) {
console.log('Transaction Receipt:', receipt);
if (receipt.status) {
console.log('Transaction Successful!');
} else {
console.log('Transaction Failed!');
}
} else {
console.log('Transaction is pending or not found');
}
}
getTransactionReceipt('0xYOUR_TRANSACTION_HASH');curl -X POST https://rpc-private-testnet.celestium.network \
-H "Content-Type: application/json" \
--data '{
"jsonrpc":"2.0",
"method":"eth_getTransactionReceipt",
"params":["0xYOUR_TRANSACTION_HASH"],
"id":1
}'logs
Array of logs generated during execution (events).
contractAddress
Address of the contract created, if applicable.
effectiveGasPrice
Actual gas price paid after execution.
Record transaction outcome and gas usage.
logs: Logs emitted by the smart contract.
Step
Description
Signature Verification
Validate the sender's signature.
Nonce Validation
Ensure the transaction nonce is correct.
Balance Check
Verify the sender has sufficient balance.
Gas Estimation
Calculate gas cost based on transaction complexity.
EVM Execution
Execute the transaction logic within the EVM.
State Update
Apply changes to account balances and storage.
Benefit
Description
Deterministic Execution
All nodes arrive at the same state after executing the block.
Parallel Processing
Reduces block processing time.
Fast Outcome Availability
Full nodes know transaction outcomes within 1 second.
EVM Compatibility
Supports existing Ethereum tools and contracts.
Method
Description
eth_getTransactionReceipt
Get transaction execution result.
eth_getBlockByNumber
Fetch block details, including state root hash.
Receipt Generation
Confirm that the transactions do not exceed gas limits.
Validators vote on the block.
If 2/3 of the validators agree, a Quorum Certificate (QC) is formed.
The block is finalized and propagated to the network.
Step
Description
Transaction Selection
Validator selects high-fee, valid transactions from the mempool.
Block Assembly
Transactions are bundled into a block, subject to gas and balance limits.
Block Proposal
The leader proposes the block to other validators.
Voting & QC Formation
Validators vote; 2/3 approval finalizes the block.
Block Finalization
The block is added to the blockchain; transactions are executed.
Method
Description
eth_getBlockByNumber
Retrieve block details by number.
eth_getTransactionReceipt
Get transaction status and logs.
const receipt = await web3.eth.getTransactionReceipt(txHash);
console.log(receipt);const txHash = '0xabc123...';
const receipt = await web3.eth.getTransactionReceipt(txHash);
if (receipt && receipt.status) {
console.log('Transaction Successful:', receipt);
} else {
console.log('Transaction Failed or Pending');
}Max Cost = Value + (Gas Limit * MaxFeePerGas)const receipt = await web3.eth.getTransactionReceipt(txHash);
console.log(receipt);Frequent Random Reads and Writes: Each transaction may read and write to different parts of the state.
Large State Size: As the network grows, the state can reach terabytes in size.
Efficient Proof Generation: Merkle proofs are needed for light clients, requiring efficient state root computation.
Concurrency: Supporting parallel execution demands concurrent state reads and writes without data corruption.
Optimization
Description
Trie Node Caching
Frequently accessed parts of the Merkle Patricia Trie are cached in memory to reduce disk reads.
Compact Trie Node Encoding
Trie nodes are stored in a compressed format to minimize disk usage and reduce I/O overhead.
Node Preloading
Anticipates state access patterns during execution and preloads relevant trie nodes into memory.
Batch State Updates
State changes from multiple transactions are batched into a single write operation, reducing I/O cost.
Parallel State Reads
Allows multiple transactions to read different parts of the state concurrently during parallel execution.
Asynchronous State Access
State reads and writes are non-blocking, leveraging async I/O (e.g., io_uring on Linux).
To minimize disk I/O, Celestium employs an adaptive caching strategy:
Hot State Cache: Frequently accessed accounts and contract storage slots are kept in memory.
Trie Node Cache: Patricia Trie nodes involved in recent reads or writes are cached to speed up future accesses.
Execution Context Cache: Intermediate state during parallel and optimistic execution is kept in a local context cache before merging.
This reduces redundant disk reads and accelerates transaction execution.
Each node in the Merkle Patricia Trie is represented in a compact format to:
Reduce storage size on disk.
Accelerate deserialization during state reads.
Minimize the number of I/O operations.
For example, nodes with short paths are packed into a single structure, reducing the need to traverse multiple disk blocks.
Parallel transaction execution requires the state database to serve concurrent read operations efficiently:
Lock-free reads: Reads are allowed in parallel without locking.
Snapshot isolation: Transactions read a snapshot of the state at the block start, avoiding conflicts.
Trie Segmentation: Trie nodes are segmented so that reads on different branches can proceed independently.
This ensures that parallel execution threads can access state concurrently without blocking each other.
Instead of writing state changes to disk for each transaction, Celestium:
Accumulates state updates during block execution.
Batches writes into a single I/O operation at the end of execution.
Merges updates efficiently into the Patricia Trie.
This drastically reduces the number of random disk writes and improves throughput.
Building on CelesDb’s async I/O capabilities, state reads and writes are designed to be non-blocking:
Concurrent state access requests are issued during transaction execution.
Other operations continue while waiting for disk reads/writes.
Async completion allows results to be processed as soon as they are ready.
This is crucial for parallel execution, ensuring CPU resources are never idle waiting for I/O.
Celestium leverages execution pre-analysis to predict which parts of the state will be accessed:
Static analysis of smart contract code predicts state dependencies.
State prefetching loads trie nodes into memory before execution begins.
Reduces random disk reads during execution.
This optimization works particularly well when transactions interact with the same contracts frequently.
Accounts and contract storage are designed to handle sparse keys efficiently. This is particularly useful for:
Contracts with large mappings but few actual entries.
Accounts with sparse nonces or balances across multiple tokens.
Sparse layouts ensure that empty state entries do not consume disk space unnecessarily.
During block execution, state changes are buffered in-memory before being written to disk:
Reduces disk writes during speculative execution (parallel and optimistic execution).
Accelerates transaction throughput, especially for blocks with frequent state updates.
Ensures crash consistency by logging buffered updates before committing.
Benefit
Impact
Faster Transaction Execution
Reduced disk I/O and faster state access enable low-latency execution.
Improved Parallelism
Concurrent reads and async writes support Celestium’s parallel and optimistic execution models.
Reduced Disk Wear
Batched writes and caching reduce the number of random disk writes, extending SSD lifespan.
Lower Memory Footprint
Compact encoding and adaptive caching optimize memory usage.
Scalability
Efficient handling of large state ensures Celestium can scale to millions of accounts and contracts.
Aspect
Celestium State Storage
Traditional Ethereum Clients
Trie Node Caching
Adaptive hot-state and trie caching
Basic caching, limited optimization
Parallel State Reads
Fully supported
Mostly sequential
Async I/O
Full async (io_uring support)
Blocking I/O
Batch Writes
Optimized write batching
Per-transaction writes
State storage optimizations in Celestium are purpose-built to complement parallel and asynchronous execution models. These enhancements ensure that state access is never a bottleneck, allowing Celestium to achieve high throughput without sacrificing Ethereum compatibility.
By combining custom database design (CelesDb) with advanced storage techniques, Celestium can scale to support large-scale decentralized applications while maintaining low latency and high efficiency.
EIP-2718: Typed Transaction Envelope.
EIP-2930: Optional Access Lists for Gas Optimization.
Key fields in a transaction:
Field
Description
nonce
Sequence number for the account.
to
Recipient address (or empty for contract deployment).
value
Amount of native token (CLT) to transfer.
gasLimit
Maximum gas units the transaction can consume.
gasPrice
Fee per gas unit in native token.
maxFeePerGas
Maximum fee per gas (used in EIP-1559 transactions).
The transaction is serialized using RLP (Recursive Length Prefix) encoding.
Before submitting, users often estimate gas consumption by calling:
This simulates transaction execution without broadcasting it, helping the user set a suitable gasLimit and avoid out-of-gas failures.
A transaction is signed using the account's private key. Wallets such as MetaMask or hardware wallets handle signing securely.
The signature covers the transaction fields, ensuring authenticity and preventing tampering.
After signing, the transaction is broadcast to the Celestium network through an RPC node:
RPC Call Example:
The node validates the transaction structure and the user's balance before propagating it to the network.
To prevent spam and invalid transactions, Celestium nodes check:
Sufficient Balance: Ensuring the account can cover value + gasLimit * maxFeePerGas.
Nonce Matching: The nonce must align with the account's next expected nonce.
Signature Validity: The ECDSA signature must match the sender's address.
If any check fails, the transaction is rejected with an error message.
Once validated, the transaction enters the mempool, a temporary pool of pending transactions. Validators select transactions from the mempool during block proposal, prioritizing those with higher fees.
Celestium optimizes mempool management:
Transactions are sorted by effective gas price (base fee + priority fee).
Transactions exceeding the available balance are not admitted.
Replacement Transactions: Users can speed up or cancel pending transactions by submitting a new transaction with the same nonce and higher gas fees.
Users can track their transaction's status via:
eth_getTransactionReceipt: Retrieves execution results (success, failure, gas used).
Block Explorer: http://testnet.celestium.network
Receipt Example:
Error
Cause
nonce too low
A transaction with a higher nonce has already been sent.
out of gas
Gas limit was insufficient to cover computation.
insufficient funds
Balance is too low for the transaction’s value and fees.
invalid signature
Signature does not match the transaction data.
Here is an example of submitting a transaction using Web3.js in Node.js:
Create Transaction: Specify to, value, gasLimit, data, and fee fields.
Estimate Gas (Optional): Simulate execution to set an optimal gas limit.
Sign Transaction: Use a wallet or library to sign.
Submit Transaction: Call eth_sendRawTransaction via RPC.
Validate: Node checks balance, nonce, and signature.
Propagate: Transaction enters the mempool.
Inclusion: Validator includes the transaction in a block.
Query Status: Retrieve execution results via RPC or block explorer.
Method
Description
eth_estimateGas
Estimate gas usage for a transaction.
eth_sendTransaction
Send an unsigned transaction (requires unlocked account).
eth_sendRawTransaction
Submit a signed transaction.
eth_getTransactionReceipt
Retrieve transaction result after execution.
Understanding the transaction lifecycle ensures that developers can efficiently interact with Celestium, prevent common submission issues, and optimize fee spending. Proper handling of nonce, gas estimation, and mempool behavior is crucial for seamless on-chain operations.
Accounts and transactions form the foundation of activity on Celestium. They govern how users interact with the network, deploy smart contracts, and transfer value.
Celestium follows the Ethereum account model, meaning it supports two types of accounts:
Externally-Owned Accounts (EOAs)
eth_estimateGaseth_sendRawTransaction{
"transactionHash": "0x...",
"status": "0x1", // Success (0x0 = Failure)
"blockNumber": "0x...",
"gasUsed": "0x...",
"logs": [ ... ]
}const Web3 = require('web3');
const web3 = new Web3('http://rpc-private-testnet.celestium.network');
// Sender's private key and address
const privateKey = '0xYOUR_PRIVATE_KEY';
const senderAddress = '0xYOUR_ADDRESS';
async function sendTransaction() {
const nonce = await web3.eth.getTransactionCount(senderAddress, 'latest');
const tx = {
from: senderAddress,
to: '0xRecipientAddress',
value: web3.utils.toWei('0.1', 'ether'),
gas: 21000,
gasPrice: web3.utils.toWei('10', 'gwei'),
nonce: nonce,
chainId: 252525 // Celestium Testnet
};
const signedTx = await web3.eth.accounts.signTransaction(tx, privateKey);
const receipt = await web3.eth.sendSignedTransaction(signedTx.rawTransaction);
console.log('Transaction receipt:', receipt);
}
sendTransaction();Sparse Storage Layout
Sparse Merkle Trie layout reduces storage overhead for accounts and contracts with minimal state.
Write-ahead Buffering
State changes are first written to a buffer before being committed to disk, minimizing expensive random writes.
Sparse Storage
Efficient handling of sparse state
No special optimization
maxPriorityFeePerGas
Maximum priority fee per gas for miners/validators.
data
Optional data payload (e.g., contract interaction).
signature
ECDSA signature authorizing the transaction.
Controlled by private keys.
Used by users to initiate transactions.
Can send and receive tokens.
Contract Accounts
Controlled by smart contract code.
Cannot initiate transactions independently.
Execute logic when triggered by an EOA or another contract.
Address Format
20-byte hexadecimal addresses.
Derived from the public key using ECDSA (Elliptic Curve Digital Signature Algorithm).
Example: 0x742d35Cc6634C0532925a3b844Bc454e4438f44e
Account State
Each account has the following state properties:
nonce
Number of transactions sent (EOAs) or created (contracts).
balance
Amount of native tokens (CLT) held by the account.
codeHash
Hash of the smart contract code (empty for EOAs).
storageRoot
Merkle Patricia Trie root hash representing contract storage.
Transactions are signed messages that trigger state changes on the Celestium blockchain. They are compatible with Ethereum's transaction structure and comply with EIP-2718 and EIP-2930.
Transaction Fields
nonce
Sequential number to prevent replay attacks.
gasPrice / maxFeePerGas
Amount the sender is willing to pay per gas unit.
gasLimit
Maximum gas units the transaction can consume.
to
Recipient address (or empty for contract creation).
value
Amount of CLT tokens to transfer.
data
Input data (e.g., smart contract call).
Transaction Types
Legacy Transactions
Pre-EIP-1559 transactions using gasPrice.
EIP-1559 Transactions
Use maxFeePerGas and maxPriorityFeePerGas fields.
EIP-2930 Transactions
Include access lists to optimize gas usage.
Gas and Fees
Gas represents computational effort.
Each opcode has a gas cost.
Transaction fee is calculated as:
Signed Transactions
Transactions must be signed using the sender's private key. This generates the v, r, s fields in the transaction.
Example: Signing and Sending a Transaction (Web3.js)
The native token on Celestium is CLT.
Used to pay for transaction fees (gas).
Can be transferred between accounts.
ERC-20 compliant representation of CLT.
Used in smart contracts requiring ERC-20 compatibility.
Nonces ensure that each transaction is processed in order and prevents double-spending. Transactions with duplicate or out-of-order nonces will fail or be delayed.
Best Practices:
Always retrieve the current nonce before sending a transaction:
Introduced in EIP-2930, access lists reduce gas costs by pre-declaring state slots and accounts a transaction will access.
Access List Example:
EOAs are user-controlled; Contract Accounts are code-controlled.
Transactions modify state and transfer value.
Gas is a unit of computational cost, paid in CLT.
Access lists and EIP-1559 transactions improve gas efficiency.
Celestium’s Ethereum compatibility allows developers to leverage familiar tooling, making the transition seamless for existing blockchain developers.
javaSalinEditTransaction Fee = Gas Used * Effective Gas Priceconst nonce = await web3.eth.getTransactionCount(account.address);const Web3 = require('web3');
const web3 = new Web3('https://rpc-private-testnet.celestium.network');
async function sendTransaction() {
const account = web3.eth.accounts.privateKeyToAccount('0xYOUR_PRIVATE_KEY');
const tx = {
from: account.address,
to: '0xRecipientAddress',
value: web3.utils.toWei('1', 'ether'),
gas: 21000,
maxFeePerGas: web3.utils.toWei('5', 'gwei'),
maxPriorityFeePerGas: web3.utils.toWei('2', 'gwei'),
};
const signedTx = await account.signTransaction(tx);
const receipt = await web3.eth.sendSignedTransaction(signedTx.rawTransaction);
console.log('Transaction receipt:', receipt);
}
sendTransaction();const tx = {
from: account.address,
to: '0xContractAddress',
data: '0x...',
gas: 50000,
accessList: [
{
address: '0xStorageContractAddress',
storageKeys: [
'0x0000000000000000000000000000000000000000000000000000000000000000',
],
},
],
};v, r, s
ECDSA signature fields.
Linearity in blockchain systems refers to the strict ordering of blocks and transactions to maintain consistency, prevent double spending, and ensure deterministic state transitions. Celestium enforces linearity to guarantee all nodes reach consensus on the same transaction history.
Linearity ensures that:
Blocks are arranged in a single, sequential chain.
Each block references the hash of its predecessor, forming an immutable chain.
Transactions within a block are ordered deterministically.
This structure prevents forks under normal conditions and ensures all network participants process transactions in the same sequence.
Celestium enforces deterministic block and transaction ordering through:
Block Linearity: Each block has a unique height and follows its predecessor.
Transaction Linearity: Transactions within a block are ordered based on:
Nonce (for transactions from the same account).
Priority Fee (tip) during mempool selection.
Each account’s transactions are ordered using a nonce—a sequential number representing the number of transactions sent from an account.
Example:
If a transaction with nonce 1 is missing, the network will not process nonce 2 until nonce 1 is confirmed.
Double Spend Protection: Ensures a single transaction can alter an account’s state at a time.
Consensus Finality: All validators agree on the exact order of blocks and transactions.
Replay Protection: Nonces prevent transactions from being executed multiple times.
Validators produce blocks sequentially, referencing the hash of the previous block. Each block is finalized upon consensus, ensuring no reordering can occur afterward.
Key Block Properties:
If a transaction with a lower nonce is delayed:
Higher nonce transactions from the same account are held in the mempool.
Once the missing transaction is confirmed, pending transactions are processed sequentially.
Celestium’s consensus mechanism (PoA + AI and CelesBFT) reinforces linearity by:
Assigning block production responsibilities to validators in a round-robin manner.
Using AI-driven monitoring to prevent Byzantine behavior (e.g., block omission or reordering attempts).
Achieving block finality in a single round of voting under normal network conditions.
Blocks and transactions follow a strict linear sequence.
Nonces prevent reordering within accounts.
Linear execution ensures consensus consistency and prevents state divergence.
Validators adhere to linear block production under CelesBFT consensus.
Linearity is fundamental to Celestium’s performance and security, ensuring that all nodes maintain a unified state despite network latency or adversarial conditions.
Time of arrival as a tie-breaker.
0
0xabc123
Included
1
0xdef456
Included
2
0xghi789
Pending
Height
Block number, starting from 0 (genesis block).
Parent Hash
Reference to the previous block’s hash.
State Root
Root hash representing the state after executing all transactions.
The mempool is a critical component in the transaction lifecycle of Celestium. It acts as a staging area for transactions that have been submitted by users but are not yet included in a block. The propagation of transactions through the mempool ensures that validators and other nodes in the network are aware of pending transactions, enabling their eventual inclusion in the blockchain.
Understanding mempool propagation is essential for developers and node operators to grasp how transactions move across the network before finalization.
The mempool is a temporary, in-memory data structure maintained by Celestium nodes. It holds transactions that have been:
Validated locally by the submitting node.
Not yet included in a finalized block.
Nodes continuously share their mempool content with peers to ensure network-wide transaction visibility.
Upon receiving a transaction, a Celestium node performs several validation checks before adding it to the mempool:
Balance Check: The account must have a sufficient available balance to cover value + gasLimit * maxFeePerGas.
Nonce Check: The nonce must be sequential according to the account’s transaction history.
Signature Verification: The transaction’s signature must be valid.
Transactions that fail any of these checks are rejected and not propagated.
Once a transaction passes validation and is added to the mempool, it is propagated to peer nodes:
The node broadcasts the transaction hash and basic metadata to its peers.
Peers request the full transaction data if they do not already have it.
Each node performs its own validation before adding the transaction to its mempool.
This propagation mechanism ensures that transactions spread rapidly across the Celestium network.
To prevent spam and ensure performance, Celestium nodes enforce mempool limits:
Maximum Mempool Size: A limit on the number of transactions in the mempool.
Eviction Policy: Low-fee or stale transactions may be dropped when the mempool is full.
Replacement Transactions: Users can replace pending transactions by submitting a new transaction with the same nonce and a higher fee (known as a “speed-up” or “cancel” transaction).
Nodes prioritize transactions based on effective gas price (base fee + priority fee).
One of Celestium’s innovations is real-time tracking of an account’s available balance during mempool admission. As transactions are added, the available balance is decremented:
Prevents the same funds from being spent multiple times in pending transactions.
Reduces the risk of block proposals containing invalid transactions.
This approach safeguards against denial-of-service (DoS) attacks and enhances network efficiency.
Celestium employs a gossip protocol to ensure rapid propagation of transactions:
Each node randomly selects a subset of peers to gossip new transactions.
Gossip is limited to reduce network congestion.
Peers that already have the transaction ignore redundant announcements.
This decentralized broadcasting approach ensures that valid transactions reach block proposers swiftly.
Users often need to speed up or cancel pending transactions:
Speed Up: Submit a new transaction with the same nonce and a higher gas price.
Cancel: Submit a zero-value transaction with the same nonce and a higher gas price.
Replacement transactions must meet the price bump requirement (e.g., 10-12% higher gas price) to be accepted by nodes.
Example with Web3.js:
Validators use PGA (Priority Gas Auction) to order transactions in a block:
Transactions offering higher fees per gas are prioritized.
This auction mechanism creates competition during network congestion.
Users can monitor current gas prices to optimize their fee settings.
Transactions in the mempool are not final until included in a block. Once a block is finalized (1-second finality in Celestium), transactions within that block are considered part of the immutable blockchain history.
Transaction Submission: User submits a signed transaction.
Validation: Node checks balance, nonce, signature, and gas price.
Mempool Admission: Valid transactions are added to the mempool.
Propagation: Transaction details are gossiped to peers.
Real-Time Balance Tracking: Reduces invalid transaction inclusion.
Efficient Propagation: Ensures fast transaction distribution.
Spam Protection: Limits prevent network abuse.
User Control: Supports transaction replacement and cancellation.
Understanding mempool propagation allows developers and users to optimize transaction submissions, ensuring timely and cost-efficient interactions with the Celestium blockchain.
Replacement: Pending transactions can be replaced or canceled.
Block Inclusion: Validators select transactions based on fees.
Finality: Transactions are finalized after block confirmation.
Method
Description
eth_sendRawTransaction
Submit a signed transaction.
eth_getTransactionByHash
Retrieve transaction details.
eth_getTransactionReceipt
Get transaction outcome and logs.
const tx = {
nonce: 10, // Same as the pending transaction
to: '0xRecipientAddress',
value: web3.utils.toWei('0.1', 'ether'),
gas: 21000,
gasPrice: web3.utils.toWei('20', 'gwei'), // Higher than the pending tx
};