Demos Network Specifications
  • Introduction
    • What is Demos Network
    • Demos Network Architecture
  • FAQ
  • Cookbook
    • Project setup
      • Run the project (MacOS)
      • Run the project (Windows)
        • WSL 2 Setup on Windows (10 and 11 only)
        • Issue Troubleshooting
      • Run the project (Ubuntu)
  • SDK
    • Getting Started
    • WebSDK
      • Authentication
        • FIDO2 Passkeys
          • Under the Hood: FIDO2 Passkeys
      • NodeCalls
      • Transactions
        • Creating a transaction
        • Signing a transaction
        • Broadcasting a transaction
      • L2PS SDK
        • The l2ps module
        • Interacting with the L2PS
        • L2PS Messaging System
      • Instant Messaging
        • What is the Instant Messaging Protocol?
        • Architecture Overview
        • Encryption
        • Quickstart
        • Message Types
        • API Reference
        • FAQ
    • Cross Chain
      • General layout of the XM SDKs
      • EVM
      • BTC
      • Solana
      • MultiversX (EGLD)
      • NEAR
      • IBC
      • TON
      • XRPL
      • The XMScript
      • Identities
    • Demoswork
    • Cookbook
      • Demoswork
        • Creating work steps
        • Conditional Operation
        • Base Operation
        • Signing and broadcasting
      • Transactions
        • Crosschain Transaction
        • Native Transactions
      • SWAP
        • Crosschain SWAP
    • Web2
      • Quick Start
      • DAHR API Reference
        • Types
      • Making Requests
      • Identities
        • Twitter
        • GitHub
    • API Reference
    • Bridges
      • Rubic Bridge Test
    • Post Quantum Cryptography
  • Backend
    • Internal Mechanisms
      • Network Time Synchronization
      • Cross Context Identities
    • Global Change Registry
      • GCR Structure
      • How is GCR Synced?
    • Consensus Mechanism
      • Unparalleled Scalability
      • Decentralization in PoR-BFT
      • Enhanced Security
      • Comparative Advantage
      • Addressing Potential Criticisms
      • Conclusion
    • Communications Stack
    • L2PS (Subnet) Framework
      • How are L2PS transactions handled?
    • Miscellaneous
      • Browsing the Postgres DB via psql
    • Bridges
      • Rubic Bridge
    • Developers Testbed
      • Setting up the environment
      • Setting up the repository
      • Installing dependencies
      • Node Configuration
      • Running the node
  • Frontend
    • Demos Providers Discovery Mechanism
Powered by GitBook
On this page
  • User Experience
  • Node Experience
  1. Backend
  2. L2PS (Subnet) Framework

How are L2PS transactions handled?

This page describes in details how Demos network stores, manages and serves encrypted transactions within a L2PS (or subnet).

The Demos specification includes a table in the Demos blockchain database, which, as part of the Global Change Registry, is synchronised across nodes and certified by consensus.

The table is structured as follows:


@Entity("global_change_registry_subnets_txs")
export class GCRSubnetsTxs {
    @PrimaryColumn("text", { name: "tx_hash" })
    tx_hash: string

    @Column("text", { name: "subnet_id" })
    subnet_id: string

    @Column("text", { name: "status" })
    status: string

    @Column("text", { name: "block_hash" })
    block_hash: string

    @Column("integer", { name: "block_number" })
    block_number: number

    @Column("json", { name: "tx_data"})
    tx_data: EncryptedTransaction
}

As we saw in the previous chapter, each block contains a list of encrypted transactions that are part of one or more subnets. This list is used as a reference to quickly locate L2PS transactions within a block. To actually retrieve an encrypted transaction, the SDK provides methods to retrieve them from the table above.

You can quickly retrieve L2PS transactions by searching for the block number, block hash, status, subnet ID (aka public key) or tx hash. As always, the demo network only stores encrypted transactions to ensure privacy and confidentiality. However, it is easy to actually attest and verify that a transaction has been validated with a particular hash and therefore its content.

User Experience

From a user's point of view, this means that using any dApp or program that uses the SDK to make use of subnets will cause its own transactions to be applied in the table above. This concept is particularly useful for visualising how the demo network guarantees L2PS functionality.

Node Experience

As discussed in the previous chapter, nodes that participate in a L2PS will be the ones that actually store the txs in the status_subnets_txs table. A node not participating in a L2PS will only be able to provide hash references through the usual block content.

PreviousL2PS (Subnet) FrameworkNextMiscellaneous

Last updated 7 months ago