Building Trust in Orbit: SpaceComputer’s Blue Paper, Explained

Since Bitcoin’s launch, it has become standard for blockchain projects to publish a whitepaper early in development.

As a prelude to that, we introduced our blue paper and have been grateful for the feedback from investors, builders, and the web3 community.

As we approach the publication of our whitepaper and other major milestones, we believe it’s a good time to reintroduce the blue paper to newer community members.

To that end, please find below a simplified version of the blue paper, intended for a non-technical audience.

The original paper was authored by Daniel Exponent, Dalia Malkhi, Matej YangWao, and Filip Rezabek. The following summary may not fully capture their original intent, and some technical simplifications in this blog could introduce inaccuracies. If you would like to read the full paper, it is available here.

Blue Paper Introduction: What Are We Building?

With SpaceComputer, we are leveraging satellite infrastructure to deliver a robust and secure blockchain environment resistant to traditional cyberattacks and physical tampering. Our intent is to build the ideal solution for high-security use cases.

The blue paper explores the potential architecture and use cases of SpaceComputer and shares our rationale and design considerations with the community. With continued development, SpaceComputer aims to reduce the need to place trust in Earth-based intermediaries and continuously improve the performance of the L1.

Follow SpaceComputer on X
Click Here

Part 1: Why Satellites? 

We are building SpaceComputer on satellites because they are out of physical reach. For data storage, orbital data centers are far more secure than Earth-based ones, even if a TEE is used.

• Physical Isolation: Running in orbit, SpaceComputer nodes are very hard to reach. They cannot be physically tampered with by any data center administrator and are difficult for powerful actors, including governments, to access.
• Hardware Redundancy: SpaceComputer’s hardware components feature physical redundancy, allowing high availability for software running on them.

Currently, SpaceComputer communications with Earth depend on on-planet Iridium Network terminals, which may be subject to attacks. In the future, we plan to support direct consumer device communications to satellites, without depending on censorship-prone intermediaries. 

Part 2: SpaceComputer Use Cases

We expect SpaceComputer to be used for two use case categories: 

1. Marketplace for Celestial Services

The number of satellite launches is going up exponentially: There have been more satellite launches in the past few years than the total number of launches in the past decades. The flourishing space-based services sector includes imaging, communications, secure storage, and more. 

SpaceComputer facilitates payments and other infrastructure to service these and other applications running in orbit, providing a settlement layer, tokenization, and a new asset class that represents value in orbit.

One might ask, “why do we need a blockchain for this?” There are several reasons: 

• Decentralization: Trust in the network relies on decentralized control of the network. SpaceComputer will run on satellites operated by independent organizations, some who may launch and manage their own nodes, while others will lease resources from the network. Communication with Earth will be decentralized through independent ground stations, and eventually through personal devices.
• Upgradeability: Smart contracts enable transparent software upgrades and customization.

2. Security Services for Decentralized ProtocolsTo reach mass adoption, decentralized platforms must be able to handle sensitive information with care. In some cases, they must be able to delete this data. SpaceComputer enables these functions unlike any other technology. These protocols, dApps, and decentralized services can utilize SpaceComputer to implement critical security components, taking security to new heights with tamper-proof guarantees.
   
   Here are a few potential use cases: 

• Co-Processors: SpaceComputer can act as a trusted co-processor to securely handle computations over encrypted data, offering two major advantages: (1) full support for familiar smart contract languages (e.g., Solidity) and (2) leak-proof security owing to the physical isolation of satellites.
• Secure Custodian: SpaceComputer can serve as a secure custodian of cryptographic secrets and assets.
• Random Number Generation (RNG): Owing to the security and physical location of SpaceComputer satellites, it can offer a source of cosmic randomness, using space radiation. RNG is used for secure key creation, nonces, consensus algorithms, and smart contract randomness (like lotteries and games).
• Bulletin-board: SpaceComputer can work as a permanent, tamper-proof bulletin board that stays secure against changes, shutdowns, or bribes. For example, SpaceComputer can lock in and record any blockchain’s latest state from time to time.
• Secure deletion: Many services require the disposal of information securely, either for reasons of confidentiality or due to compliance requirements. On Earth, deleting information is very difficult: information can almost always be extracted from physical storage. Not so in space.

Part 3: SpaceComputer’s Two-Tier Architecture (This part gets technical) 

Security benefits aside, we expect Earth to have greater and cheaper storage and processing capacity than orbit for the foreseeable future. Therefore, SpaceComputer uses a two-tier design: an L1 in orbit (Celestial Chain) and an L2 on Earth (Uncelestial Chain), to which as much work as possible is offloaded.

SpaceComputer can, in principle, provide finality for two types of L2s:

1. Commit Chains: An L2 that runs its own consensus and periodically submits state commitments to an L1 (i.e., Polygon PoS, Gnosis Chain).
2. Pre-Finality Chains: An L2 system that commits state before it is actually finalized within the chain itself (i.e., Optimism, Arbitrum, Scroll).

We’re developing a new approach to pre-finality. We’ll discuss this in section 3b. 

Part 3a: Celestial Layer 1

Operating SpaceComputer’s Celestial network in space presents unique challenges: limited bandwidth between satellites, intermittent connections to Earth, and restricted onboard storage capacity. To solve these challenges, SpaceComputer’s L1’s consensus protocol (which keeps the network in sync) minimizes bandwidth use and separates data availability, execution, and sequencing (ordering of blocks).

When a satellite establishes a connection with Earth, ground stations transmit user requests (such as transactions or updates) to nearby satellites. These satellites can then distribute the information across the network and prepare it for orderly processing.

A general transaction flow is as follows:

1. A ground station sends a transaction to all satellites that are currently within range.
2. One satellite becomes the leader, responsible for proposing the transaction to the entire network.
3. Other satellites validate the leader's proposal and vote to approve or reject it.
4. Votes are either: Sent directly back to Earth, or relay it through other satellites if direct connection is unavailable.
5. Once a quorum is reached, the transaction is finalized.
6. To improve efficiency, ground stations can pre-process some transactions and send tentative results with future proposals.

Part 3b: Uncelestial Layer 2

The Uncelestial network processes transactions through a Layer 2 (L2) system operated by a committee. To enhance trust, we’ve integrated a consensus mechanism similar to state channels but with an important upgrade: users can treat L2 consensus decisions as pre-final, allowing for an extremely fast transaction experience.

For this pre-finality system to be trustworthy, it must detect forks and punish misbehaving committee members. Penalties collected from these offenders are then used to repair any resulting damage.

To enforce accountability, Uncelestial borrows a simple but powerful idea from the Ebb-and-Flow protocol. After a decision is made, participants must sign and publish a confirmation message, backed by their staked funds. This staking ensures that participants have something valuable at risk. Once enough signed confirmations are gathered, the decision is considered almost final (pre-final).

This extra step provides two major benefits:

1. It allows the main blockchain (L1) to easily verify decisions without needing to inspect off-chain activities.
2. It enables the system to quickly detect and punish dishonest behavior.

Specifically, after a decision is proposed, validators cast a final vote to confirm it. If a large majority of validators agree, the decision becomes locked in—unless a minority attempts to cheat. In that case, the system can easily identify and penalize the cheaters without needing to investigate the full complexity of the network. Offending validators lose their staked funds, helping to repair any harm and strongly discouraging future misconduct.

There are three cases of misbehavior to consider:

1. Failure to Post Updates: If an update is published but not posted to the rollup contract, any party may submit it. Updates include embedded fees to ensure posting can occur without requiring the submitter to hold a balance.
2. Confirmation of Invalid Updates: If an invalid update is confirmed, users can independently verify the update’s correctness without relying solely on Uncelestial. The L2 contract on Celestial rejects invalid updates automatically. Watchers are incentivized to monitor and report misbehavior. In the case of a dispute, users may submit fraud proofs to the SpaceComputer L1 network to safeguard their assets.
3. Confirmation of Conflicting Updates (Forks): If conflicting updates are confirmed at the same sequence position, proof can be submitted to punish the equivocators and preserve system integrity.

Finality Levels
Integrating fast pre-finality on Uncelestial with Celestial presents a continuum of trust, and therefore, we provide users with the choice of three grades of finality: pre-finality confirmation, pre-finality with backup, and finality. (We call it pre-finality, not soft-finality, as is the case for rollups, as the Uncelestial provides more security guarantees than the current rollup solutions.)

• Pre-Finality Confirmation — Rapid consensus among Uncelestial validators, enforced by slashing conditions.
• Pre-Finality with Backup — Additional verification through an independent Celestial node.
• L1 Finality — Settlement through the SpaceComputer L1, providing the highest level of security at the cost of longer finality times.

Part 4: Summary & Next Steps

SpaceComputer is a tamper-proof, satellite-based blockchain that aims to solve many of the vulnerabilities faced by Earth-based systems, including side-channel attacks, administrative tampering, and network takeovers. We host nodes on satellites and leverage the Iridium network for communication, but we aim to expand to other providers in the future. Among fitting use cases, we envision secure key management, random number generation, and confidential computations, all while ensuring finality through fitting consensus mechanisms to the constrained environment.

Next, we will narrow down our selection of individual building blocks for the L1 and L2 in order to select a suitable design that enables fast finality for users.

The original version of the bluepaper was authored by Daniel Exponent, Dalia Malkhi, Matej YangWao, and Filip Rezabek and can be found here. The above summary may not fully capture their original intent, and some technical simplifications in this blog could introduce inaccuracies.

- Follow SpaceComputer on X: https://x.com/SpaceComputerIO
- Join the SpaceCompter Telegram Chat: https://t.me/spacecomputer_public