Decentralise the Log, Not the Server
Rethinking open-source infrastructure with Logos
Logos
Maintaining consistent state in an application used by multiple users across multiple devices is hard. Whether it’s a password manager, a collaborative document platform, or a multiplayer video game, the moment a second device enters the picture, you’re forced to confront a set of tradeoffs in terms of decentralisation and ease of implementation. This trade-off space makes it difficult to implement applications that adhere to the open-source, decentralised ethos, which is a critical aspect of digital freedom.
Sharing program state between devices
Self-hosting
The most obvious solution for sharing an application’s state is to run your own server. To do this, you can decompose the application into a backend running on your server that holds the state, and a frontend running on each user’s computer that connects to the backend. This works in principle, and for technically sophisticated users, it can work well in practice.
However, it requires a non-trivial amount of ongoing maintenance: you need to manage networking, handle TLS certificates, and make sure the machine is actually reachable when you need it. Most people, including most developers, do not want to spend their evenings configuring a reverse proxy so their phone can sync notes with their laptop.
The friction of self-hosting is not just a minor inconvenience. It represents a genuine economic cost in the form of limiting the range of potential self-hosted applications. When self-hosting is more burdensome than the application's utility, people abandon it and move to managed hosting – not because they prefer it, but because the path of least resistance leads there.
This results in a whole design space of networked applications that could exist, but don’t because self-hosting is just too cumbersome for those use cases. In economic terms, this loss of potential productivity can be described as deadweight loss: value that’s destroyed by inefficiency rather than transferred elsewhere. See Figure 1 for an illustration.
In other words, it often happens that the person who wanted a self-hosted solution ends up with a hosted one, not because it better serves their interests but because the alternative was too burdensome.
Managed hosting
As mentioned, managed hosting elegantly solves the operational burden. A third party runs the infrastructure, handles availability, and absorbs the complexity. For many use cases, this is a perfectly reasonable tradeoff. However, for anyone who cares about avoiding centralisation – whether for reasons of privacy, censorship resistance, or simply a preference for not relying on a single company's uptime and terms of service – managed hosting is exactly the kind of arrangement they were trying to avoid in the first place.
Custom decentralised protocols
An alternative that may come to mind is building a custom peer-to-peer synchronisation protocol. On paper, this is appealing: you get the decentralisation properties you want without depending on anyone else's infrastructure.
In practice, building a correct, efficient, and reasonably attack-resistant sync protocol is extraordinarily difficult. Handling conflict resolution, partition tolerance, message ordering, and network reliability across heterogeneous devices is a research problem in its own right. For large applications with dedicated engineering teams, this investment may be worthwhile. For a personal application or hobby open-source project, it’s wildly disproportionate to the problem being solved. The complexity cost puts custom decentralised protocols out of reach for most developers.
Sharing state via replicated logs
To build an effective collaborative application that doesn’t rely on managed hosting, we need to rethink the way we approach shared application state. Instead of trying to get users to agree on the state, we can instead get them to agree on a sequence of state transitions, known as replicated logs.
What are replicated logs?
Replicated logs are records of state changes that are distributed to all participants, allowing them to reconstruct the state independently. The key insight is that if two parties can agree on an ordered sequence of operations, they will independently arrive at the same state by applying those operations in that order. The state itself does not need to be transmitted, only the operations do. The receiver applies these operations to their existing state and arrives at the same result as every other receiver who has seen the same ordered sequence.
Why replicated logs?
Most application state is relatively stable. Between updates, the data sitting in your password manager, task list, or SQL database does not change. A full-state synchronisation approach would need to transmit this entire stable payload on every sync cycle, which is wasteful. In the common case where most of the state remains unchanged between updates, replicating logs is far more efficient than any snapshot-based approach.
This model is not new. It underlies some of the most mature distributed systems in use today. Cryptocurrencies maintain consensus over an ordered sequence of transactions, with each node deriving the current UTXO set or account state locally by replaying that history. Relational databases have used similar ideas for decades: database management systems such as MySQL maintain write-ahead logs (WALs) or binary logs that allow replica databases to stay in sync with a primary database by replaying operations rather than copying data pages wholesale.
Replicated logs using Logos channels
The Logos Blockchain can serve as the medium for distributing logs to participants. Each user or device can run or connect to a Logos node, which will pull updates from the blockchain. This model is made possible using Logos channels.
Logos channels
Logos channels, also known as Mantle channels, are ordered sequences of messages that are inscribed on the Logos Blockchain. Each channel is associated with a Logos Zone, a purpose-built environment for Logos applications that define their own state model. A Zone's sequencer(s) – the node(s) responsible for updating the Zone state – post state transitions to the channel as they process them. Other nodes that follow that channel (indexers) can replay those transitions locally and maintain an up-to-date copy of the Zone's state.
Logos channels maintain message ordering through a hash chain structure, where each message references its parent message. This parent-child relationship ensures that messages form a consistent sequence regardless of how the underlying Logos Blockchain may fork or reorganise. If the blockchain undergoes a reorganisation, channel messages will be reincluded in the correct order on the new canonical chain. An example of how messages from two Mantle channels can be written to the Logos Blockchain is shown in Figure 2 below.
Logos nodes enforce message ordering by verifying that each new inscription operation correctly references the most recent message in that channel. If a message doesn't reference the expected parent hash, it will be rejected during validation.
How channels facilitate log replication
Using Logos channels for log replication is straightforward. In the Logos Blockchain’s case, the application in question is implemented as a Logos Zone. The Zone's sequencer, which holds write authority, executes the application and, as it applies each update, publishes a corresponding record to the Zone's channel on the blockchain.
A node that wants to replicate the Zone's state – an indexer – simply follows the channel. It reads updates in order, applies them to its local state, and ignores updates posted to channels it is not interested in. Because the channel enforces the same ordering for all followers, every indexer that has consumed the same logs from the channel will have derived the same state, regardless of when they began following the channel.
Comparison to Ethereum
Of course, implementing decentralised applications on the blockchain is not a new idea. However, the simple replicated log approach of the Logos Blockchain differs from the typical approach of blockchains like Ethereum, which is less well-suited to small-scale applications with shared state.
Ethereum's goal is to function as a unified decentralised computer: a single execution environment in which all applications run. This ambition creates inherent scaling tension. Every Ethereum node is expected to execute every transaction, which means the computational cost of any application is borne by the entire network. All applications are also forced into the EVM execution model, which constrains what kinds of state machines they can implement. The result is a system that is expressive but expensive to scale, and in which application-level diversity is bound by the shared execution environment.
The Logos Blockchain is built around a different abstraction. Rather than a universal computer, it is fundamentally a system for maintaining decentralised, ordered logs published by Zones. This changes the scaling story significantly: a node does not need to execute updates from every Zone, only the Zones it cares about. You follow the channels relevant to your application and ignore the rest.
This design also means that each Zone can define its own state model and execution environment – there is no requirement to fit your application into a single global VM. Future updates that add data availability sampling will further extend these scaling advantages, making the architecture progressively more capable as the network matures.
Example use case: An SQL password manager
The problem
The above may seem abstract, so consider a common, practical scenario: you want to synchronise a password manager across your laptop, phone, tablet, and other devices. You want a simple solution. You do not want to hand your passwords to a hosted service, and you do not want to run a full server with all the maintenance overhead that entails. What you need is a way for your devices to stay in sync on a relatively small amount of data, with your primary device holding write authority and the others following along in read-only mode.
The MySQL primary-replica model
Before we describe the solution built on Logos Blockchain, let’s conceptualise the solution via a tried-and-true replicated log model, as implemented in MySQL's replication architecture. A primary database accepts both reads and writes and maintains a binary log of every SQL transaction it executes. Replica databases connect to the primary, consume that binary log, and replay the same transactions against their own local databases.
The result is that replicas maintain a state that is consistent with the primary, without the primary needing to push full snapshots or the replicas needing to maintain any write authority. This model is illustrated in Figure 3.
For the password manager problem, this model maps cleanly. The primary device – the laptop – can play the role of the MySQL primary, with read and write access. All other devices – the phone, the tablet, the car's entertainment system – serve as replicas, consuming the transaction log and maintaining read-only copies of the database.
Logos Blockchain SQL password manager
To implement this model with Logos Blockchain, you implement the password manager application as a Sovereign Zone. Logos contributors have already prepared a Zone SDK that makes writing sequencers and indexers a breeze.
In our example, the main device runs a sequencer for that Zone, which functions as the read-write primary. The sequencer runs the password manager application locally and publishes each SQL transaction to the Zone's channel as a plaintext inscription on the blockchain. This is the binary log equivalent: an ordered, durable, publicly reachable record of every state change.
All other devices run indexers, each of which follows the Zone's channel, reads the SQL transactions in the order they were posted, and applies them to its local database. Because the Logos Blockchain enforces a canonical ordering of Zone updates at the consensus layer, every indexer that has consumed the same channel history will have applied the same transactions in the same order, and will therefore hold an identical copy of the password manager state. There is no need for the indexers to communicate with each other or with the sequencer directly; the channel mediates everything.
This architecture reproduces the MySQL primary-replica pattern without requiring a server, without trusting a third party, and without implementing any custom synchronisation logic. The blockchain handles ordering and durability; the Zone SDK handles the mechanics of running a sequencer and indexer; the application developer handles only the application logic itself.
A working demonstration of a password manager implemented on the Logos Blockchain can be found here.
Conclusion
Building your desired decentralised application has never been easier. The Logos Blockchain testnet is live, there are instructions on how to run a node, and the Zone SDK does most of the work of building a Zone application for you. If you run into any trouble, there’s a large and growing community of builders who are happy to help on Discord.
We're building infrastructure to revitalise civil society. We need developers, designers, writers, and activists to help shape it. Build on Logos. Run a node. Take part in what comes next.
Discussion
Dr. Corey Petty
Logos
Dr. Corey Petty
Logos
Logos
Logos
Logos
Logos
Logos
Logos
Logos
Logos
Logos