<aside> 💡
While Bedrock relies on a broad base of participants to provide the most essential functionality to the Logos Blockchain, this functionality is extended by a variety of specialised Bedrock Services. These Services give Logos more privacy and scalability, and allow it to be more resilient and serve its Zones more efficiently.
Participation in Bedrock Services, is more complex than running a Logos node. These protocols require agreed-upon sets of active participants to ensure their correct operation. For example, LogosDA divides DA nodes into subnetworks that store one share of every data blob - a process that depends on knowing which nodes are DA nodes. Similarly, Blend nodes must keep track of connections to other Blend nodes for message relaying. As a result, it is not possible to allow dynamic participation in Bedrock Services as it exists for Bedrock. Participation in a Bedrock Service is therefore not incumbent upon a node unless it opts in.
The Logos Blockchain currently supports two Bedrock Services that extend and enhance the basic functionality of Bedrock, with another service planned for a future release. They may also overlap with each other, since nodes can choose to participate in several services at a time. Much of the functionality for these services is used by components found in Bedrock.
The Data Availability Service, also known as LogosDA, provides additional scalability by sharding data from Zones and Sovereign Rollups to reduce the data processed by each node. At the same time, the service ensures that the data remain publicly available for enough time to allow it to be replicated by any interested party, allowing it to be downloaded if desired by any participant in the network. This is accomplished by encoding this data with error-correcting codes and distributing shares of that data between groups of DA nodes. Parties who wish to verify the data’s availability can do so very quickly using sampling and cryptographic techniques and with minimal hardware requirements.
The Blend Network Service enhances Logos’ privacy guarantees by virtually eliminating the likelihood of linking the proposer of a block to the block they propose. It does this by encrypting the proposal message several times and selecting a random path of Blend nodes that can decrypt it at each stage. The final node in the path will then broadcast the transaction to the network, obscuring its origin. As a result, the Blend Network Service improves the Private Proof of Stake of Cryptarchia by making it harder to learn a node’s relative stake from its proposal frequency by analysing network patterns.
<aside> ❗
The Executor Network Service remains in a state of active research at the time of writing.
</aside>
The Executor Network Service allows any participating node to serve as a state transition executor for any Zone. Using execution tickets to create a schedule of nodes with exclusive execution rights for predetermined timeslots makes Zone execution simpler and allows for smoother executor handover in the optimistic case. The permissionless execution facilitated by the Executor Network effectively makes Zones into virtual blockchains run by a decentralized network of readily-available executors. Knowing in advance who will execute a given zone within a particular block range allows for the executor coordination required for cross-Zone transactions.
Despite the differences between the various Services extending Bedrock, they all make use of some common protocols. Logos nodes that choose to participate in a Bedrock Service explicitly declare their intent by using the Service Declaration Protocol (SDP). The goal of the SDP is to create a single repository of identifiers to determine which nodes have opted into which Services at a given time.
The SDP provides a standardised mechanism for Logos nodes to declare their participation in specific services, demonstrate activity, and withdraw when desired. It operates around a schedule measured by service-specific timeframes known as sessions. This protocol creates a single repository of identifiers used to establish secure communication between nodes and manage service participation.
The SDP consists of three basic steps, each of which represents a type of message sent by a participating node to Mantle: