Owners: @Giacomo Pasini

Reviewers: 🔺@David Rusu 🔺@Álvaro Castro-Castilla 🔺@Thomas Lavaur 🔺@Mehmet

Introduction

The Bedrock Mantle layer is the foundation of the Nomos architecture, on top of which the Nomos ecosystem can grow and flourish. However, it is not the place where most of the activity will happen. Instead, different portions of the ecosystem, which we will call Zones, will focus and specialize on different services and functions and attract the relevant user base. The Bedrock Mantle layer's main purpose is to provide the tools to build and manage these zones and coordinate communications.

In order for this layer to remain lightweight, it focuses on data availability and verification rather than execution. In particular, Sovereign Zones will be able to post their data and receive a guarantee that it will be available for their clients to read (through Data Availability Network Specification). Native Zones on the other hand will be able to define their state transition function (STF) and prove to the Bedrock layer their correct execution.

In the Nomos ecosystem, we see the opportunity for many different zone design choices to arise and flourish. Namely, there are two approaches to building Zones on Nomos:

• Native Zones. We provide a common protocol, described in Zones Specification, to favour strong interoperability while maintaining privacy, and we call Native Zones those that adhere to it.
• Sovereign Zones. Conforming to the native zone protocol is not required, the design space is open and zones are free to make different choices. Instead of providing separate operations for every possible choice, zones can simply use or ignore the infrastructure provided, for example by leveraging only the subset of tools they’re interested in. After all, they will only pay for what they use. Zones that do not implement the full functionality of Native Zones are called Sovereign Zones.

This document specifies how zones can interact with the Bedrock Mantle layer to perform their functions.

Overview

Zone Updates

At a high level, there are two main operations: create and update, which rather unsurprisingly describe how a zone first appears in the Nomos ecosystem and how it can evolve and perform its functions.

Internally, native zones have the following components:

• A partition of a common ledger (See Common Ledger Specification)
• A place to store zone-specific data
• A description of what the zone does, in the form of a State Transition Function (STF)

An important aspect of Native zones is that they are permissionless: everybody can update the state of a zone as long as it follows the zone rules. A consequence of this is that we need to make sure that the data needed for the continuation of zone activity is available, as to prevent situations where a malicious actor updates of a zone and delete all of the data, impairing future progress. To avoid this, every update will check the availability of the necessary data to continue execution, as defined in the zone STF.

Executor Coordination