-
Notifications
You must be signed in to change notification settings - Fork 1
Graphene Architecture
The framework under the hood — how Pixa processes, stores, and replicates data.
Pixa does not run on custom-built infrastructure. It runs on Graphene — a blockchain framework originally developed for BitShares, adopted by Steem, inherited by Hive, and now powering Pixa. Graphene is engineered for high throughput, low latency, and deterministic execution.
This guide describes the architecture at the systems level: how data is structured, how plugins extend functionality, how memory is managed, and what makes Graphene capable of handling a social media workload.
Graphene is an open-source blockchain framework designed for applications that require high transaction volume and near-instant confirmation. It was created by Dan Larimer (also behind BitShares and EOS) and has been battle-tested across multiple production chains since 2014.
| Property | Value |
|---|---|
| Language | C++ |
| Consensus support | Delegated Proof-of-Stake (DPoS) |
| Block interval | Configurable (3 seconds on Pixa) |
| Theoretical throughput | Up to 300,000 transactions per second |
| State storage | Shared memory (memory-mapped files) |
| Extension model | Plugin architecture |
Graphene stores the current state of the blockchain in a shared memory database — a memory-mapped file that acts as both RAM and persistent storage simultaneously.
Chain state is the current snapshot of all data on the blockchain at this moment: every account, every balance, every post, every vote, every witness configuration. It is the result of replaying every block since genesis.
Traditional databases (PostgreSQL, MySQL) use disk I/O with caching layers. Graphene bypasses this by mapping the entire database directly into memory. The operating system's virtual memory subsystem handles paging between RAM and disk transparently.
| Approach | Read speed | Write speed | Complexity |
|---|---|---|---|
| Traditional database | Moderate (disk + cache) | Moderate | High (queries, indexes) |
| Shared memory (Graphene) | Very fast (direct access) | Very fast (direct access) | Low (pointer-based) |
This is what enables Graphene to process tens of thousands of transactions per second — state lookups and modifications happen at memory speed, not disk speed.
State size grows with the chain. As more accounts, posts, and tokens are created, the shared memory file expands. Node operators must provision sufficient RAM to hold the active state for optimal performance.
Graphene represents all blockchain data as objects stored in the shared memory database. Every entity — accounts, posts, votes, tokens, witnesses — is an object with a unique ID.
| Object type | What it represents | Example ID format |
|---|---|---|
| Account | A user's identity and settings | 1.2.X |
| Post (Comment) | A published piece of content | 1.6.X |
| Vote | A user's vote on a post | Stored within post object |
| Witness | A registered block producer | 1.5.X |
| Dynamic global properties | Network-wide parameters | 2.0.0 |
| Vesting (PXP) | Staked token balance | Part of account object |
Through direct memory pointers. Because the database is memory-mapped, accessing an object is as fast as dereferencing a pointer — no query parsing, no index lookup, no network round-trip.
Graphene's core handles only the essentials: consensus, block production, and state management. Everything else is implemented through plugins — modular extensions that add functionality without modifying the core.
A plugin is a self-contained module that hooks into the blockchain's event system. It can observe transactions, maintain its own indexes, and expose its own API endpoints.
| Layer | Responsibility | Examples |
|---|---|---|
| Core | Consensus, block application, state management | Block production, transaction validation |
| Plugins | Extended features, APIs, indexing | Condenser API, account history, market data |
The plugin architecture means the blockchain can be extended without hard forks to the core. New features — such as an NFT system — can be developed and deployed as plugins, reducing risk and increasing modularity.
Node operators choose which plugins to run based on their role:
| Node type | Plugins typically enabled |
|---|---|
| Witness node | Minimal — core + witness plugin |
| API node | Full — all API plugins for serving queries |
| Seed node | Minimal — core + P2P networking |
Every user action on Pixa — posting, voting, transferring, staking — is a transaction containing one or more operations. Here is the lifecycle of a transaction:
The user's client (Pixagram, a third-party app, or a CLI tool) constructs a transaction with the desired operations, signs it with the appropriate private key, and broadcasts it to the network.
The transaction propagates through the peer-to-peer network. Nodes receive it, validate the signature and basic formatting, and relay it to other peers. It enters the mempool — a waiting area for unconfirmed transactions.
The next scheduled witness collects transactions from the mempool and packages them into a block. The block is signed with the witness's block signing key and broadcast.
Every node that receives the new block applies it — executing each transaction's operations against the chain state. Balances update, posts are created, votes are recorded. This step must be deterministic — every node must arrive at the exact same state after applying the same block.
After enough subsequent blocks are produced (typically one full round of 21 blocks), the block becomes irreversible — it cannot be undone by any chain reorganization.
User action → Transaction → Broadcast → Mempool → Block inclusion → State applied → Irreversible
Deterministic means the same input always produces the same output. This is critical because every node independently replays every block. If any node reached a different result, the chain would fork.
Graphene achieves determinism by:
- Using fixed-point arithmetic (no floating-point rounding errors)
- Processing operations in strict sequential order within each block
- Rejecting any operation with ambiguous or platform-dependent behavior
Every node on the Pixa network, running the same software version, will arrive at the exact same chain state after applying the same blocks. This is the foundation of consensus.
When a witness produces a block, it must reach all other nodes quickly — before the next witness's 3-second slot begins.
Pixa nodes connect to each other in a mesh topology. Each node maintains connections to multiple peers. When a node receives a new block, it validates it and immediately relays it to all connected peers.
Seed nodes are well-known, stable nodes that new nodes connect to when first joining the network. They provide an initial set of peers for bootstrapping.
Before relaying a block, each node verifies:
- The block is signed by the correct scheduled witness
- All transactions in the block are valid
- Applying the block produces a consistent state
Invalid blocks are rejected and not relayed.
Pixa's primary modification to the Graphene framework is in how post content is used. Standard Graphene (as inherited from Steem) stores blog post bodies as UTF-8 text. Pixa leverages this same field to embed Base64-encoded pixel art images.
| Steem/Hive usage | Pixa usage |
|---|---|
| Text blog posts (Markdown) | Pixel art as Base64 + metadata |
| External image links | On-chain image data |
| Unlimited content types | Pixel art exclusively |
The underlying storage mechanism is identical — UTF-8 text in the post body. The difference is semantic: Pixa's frontends (Pixagram, PixaPics) interpret the content as encoded images and render them accordingly.
The upcoming NFT plugin will extend Graphene further by adding new object types (NFT tokens) and new operations (mint, transfer, set royalty) to the core.
| Component | Role | Implementation |
|---|---|---|
| Shared memory database | Stores all chain state | Memory-mapped file, pointer-based access |
| Object model | Represents accounts, posts, tokens, witnesses | Typed objects with unique IDs |
| Plugin system | Extends functionality without core changes | Modular plugins for APIs, indexing, features |
| Transaction pipeline | Processes user actions into state changes | Construct → broadcast → mempool → block → apply |
| Deterministic execution | Ensures all nodes agree on state | Fixed-point math, strict operation ordering |
| P2P network | Distributes blocks and transactions | Mesh topology with seed nodes |
| Pixel art extension | Stores images on-chain via post bodies | Base64-encoded data in UTF-8 text field |
Graphene is the engine that makes Pixa possible — fast enough for social media, flexible enough for pixel art storage, and proven across a decade of production use on multiple blockchains. Every block, every vote, every pixel art post flows through this architecture.