Architecture

Ramestta is a Proof-of-Stake side chain to Polygon, built using the same proven architecture that powers Polygon. The network consists of two main layers: Heimdall (consensus) and Bor (execution), working together to provide fast, secure, and low-cost transactions.

The Layer Stack

Heimdall - Consensus Layer

Heimdall is the heart of the Ramestta network. It manages validators, block producer selection, spans, the state-sync mechanism between Polygon and Ramestta, and other essential aspects of the system. It uses the Cosmos-SDK and a forked version of Tendermint, called Peppermint.

Key Responsibilities

Heimdall Modules

Key Management

Each validator uses two keys to manage activities on Ramestta:

• Signer Key (Hot Wallet): Kept on the node, used for signing Heimdall blocks, checkpoints, and other signing activities. Requires RAMA tokens for Heimdall fees.
• Owner Key (Cold Wallet): Kept secure, used for staking, re-stake, changing signer key, withdraw rewards, and managing delegation. Transactions via Polygon chain.

Bor - Execution Layer

Bor is the core execution layer that processes all transactions. It operates on the principles outlined in EIP-225, following the Clique consensus protocol. Bor produces blocks and executes smart contracts with full EVM compatibility.

Block Production

Sprint Duration: 16 blocks
Span Duration: 1600 blocks  
Producer Count: 4 validators per span
Block Time: ~2 seconds
Bor Chain ID: 1370

Validator Selection Process

1. Validators are assigned slots proportionally based on their stake
2. Historical Polygon block data is used as a seed to shuffle the validator array
3. Validators are selected based on producer count maintained by governance
4. Tendermint's proposer selection algorithm chooses a producer for each sprint
5. Backup producers are designated in case primary fails (with wiggle time delay)

Consensus Mechanics

In Ramestta's PoS system:

• Stake: Participants stake RAMA tokens on Polygon's staking contract to become validators
• Selection: The bor module in Heimdall selects active validators as block producers
• Spans: A span is a defined set of blocks with a specific subset of validators
• Sprints: Within a span, each sprint designates a single block producer
• Difficulty: In-turn blocks have higher difficulty than out-of-turn signatures
• Fork Resolution: Forks are resolved by selecting the chain with highest cumulative difficulty

Checkpoints

Checkpoints are vital components of the Ramestta network, representing snapshots of the Bor chain state. These checkpoints are attested by a majority of the validator set before being validated and submitted on Polygon contracts.

Checkpoint Lifecycle

1. Heimdall selects the next proposer using Tendermint's leader selection algorithm
2. Proposer creates checkpoint with Merkle root of Bor blocks
3. Validators verify and sign the checkpoint (requires 2/3+ agreement)
4. Checkpoint is submitted to Polygon's RootChain contract
5. Success triggers ACK transaction; failure triggers NO-ACK and proposer change

Checkpoint Structure

interface CheckpointBlockHeader {
  Proposer: HeimdallAddress;   // Validator who proposed
  StartBlock: number;          // First Bor block in range
  EndBlock: number;            // Last Bor block in range
  RootHash: Hash;              // Merkle root of block hashes
  AccountRootHash: Hash;       // Merkle root of account state
  TimeStamp: number;           // Checkpoint timestamp
}

State Sync

State Sync is the mechanism that transfers data from Polygon to Ramestta. This enables cross-chain communication and ensures consistency between layers.

How State Sync Works

1. StateSynced event is triggered on Polygon's StateSender contract
2. Heimdall validators listen for and validate these events
3. Events are passed to the Bor layer via the state-sync mechanism
4. Bor executes system calls to update state at the start of every sprint
5. Receiver contract on Bor implements IStateReceiver interface

interface IStateReceiver {
    function onStateReceive(
        uint256 stateId,
        bytes calldata data
    ) external;
}

Genesis Contracts

Ramestta deploys several genesis contracts that are essential for network operation:

Network Comparison

* Soft finality at Ramestta level. Full finality achieved after checkpoint to Polygon.

Use Cases