Architecture of Architectures (Multi-Chain)
Baseledger can be thought of as an architecture of architectures in the context of supporting pluggable, interoperable consensus across Layer 1 and Layer 2 (together, a “Protocol Pair”). The proper notation for defining a Protocol Pair is as a tuple, i.e.:
  • where Layer 1 represents the layer for storing final states, for a notarized “exit” of a business process (an exit can be the storing of a final proof and/or the conversion into a token)
  • where Layer 2 represents the layer for representing distributed business workflows and zero-knowledge proofs to be rolled up into Layer 1
Each peer, in this context, retains full independence from the network consensus mechanism which is used to create crypto economic incentives related to network security, privacy, quality of service and governance. A network peer (or Node) can be containerized, run on bare metal, or public cloud infrastructure, etc. An organization which runs a Node is referred to as an Operator.
The required (and optional) software interfaces are provided by the core Baseline Protocol packages. The infrastructure interfaces provided by this specification underscore how a collection of microservice, messaging and peer-to-peer client components, when viewed as a single homogenous appliance, comprise a Baseline-compliant full node representing a single network peer. Alternatively, a leaf node is a light client node — that anyone can run from anywhere — and provide redundancy around peering and configurations for the network.
The Baseledger network consensus mechanism underlying any Protocol Pair is Tendermint consensus. This consensus ensures each operator running a Baseledger full or leaf node remains synchronized with the rest of the ecosystem.
With this architecture, Baseledger can run autonomously and/or coordinate other Multi-Chain setups with Protocol Pairs, being candidates for reference support upon the launch of the Baseledger mainnet.
Copy link