Features and Concepts

Splinter allows the same network to do two-party private communication, multi-party private communication, and network-wide multi-party shared state, all managed with consensus. A Splinter network enables multi-party or two-party private conversations between nodes using circuits and services.

  • A node is the foundational runtime that allows an organization to participate in the network.

  • A circuit is a virtual network within the broader Splinter network that safely and securely enforces prvacy scope boundaries.

  • A service is an endpoint within a circuit that sends and receives private messages.

A Splinter application provides a set of distributed services that can communicate with each other across a Splinter circuit.

Designed for privacy

The key concepts of Splinter are fundamentally anchored to privacy.

  • Circuits define scope and visibility domains.

  • Shared state, a database updated by smart contracts, is visible only to the services within a circuit.

Distributed and flexible

Splinter works across a network.

  • State agreement is achieved via the Merkle-radix tree in Transact, allowing multiple services to prove they have the same data down to the last bit, cryptographically.

  • Consensus is provided for creating real distributed applications. Splinter currently includes two-phase commit for 2- or 3-party conversations.

  • Connections are dynamically constructed between nodes as circuits are created.

Agile with smart contracts

  • Smart contracts capture business logic for processing transactions.

  • Runtime deployment of smart contracts means no need to upgrade the Splinter software stack to add business logic.

  • Sandboxed WebAssembly smart contracts keep the network safe and ensure determinism.

  • Scabbard, an out-of-the-box Splinter service that runs Sawtooth Sabre smart contracts across nodes, coordinated with consensus.

Designed for applications

  • State delta export allows an application to materialize the Merkle-radix tree database to another database such as PostgreSQL. Applications can read from the materialized database (just like any other web application).

  • Admin services provide applications with a REST API to dynamically create new circuits, based on business need.

  • Authorization for circuit management can be delegated to application code and defined by business policies.