Or Why the Constraint Machine Will Save the Universe …

Tasked with making Radix Tempo Consensus programmable, we’ve stumbled upon a new idea we call a Constraint Machine.

Humbleness aside, we believe the Radix Constraint Machine is a solution no one has asked for but everyone needs: a scalable, decentralized, real-time/offline, programmable state machine store.

In this first article, we will go over what exactly we mean by that last part: “a state machine store”. To do that, let’s first look at the traditional database…

Traditional Databases

A traditional database is like a “book” of data. Anyone with access to it can open and read it. And anyone with its pencil and eraser can write and erase in it. In this way, “the book” is very useful for information sharing.

For more complex activity though, for example, a game of chess, using just a book and pencil would be quite challenging because of the book’s lack of rules. There is no arbiter or Guardian of the book to say “No, you can’t write that because it’s not a valid move!”.

Services

Guardians were thus created, or in software lingo, “services”. In our chess example, users no longer read and write from the book directly but must instead go through a Chess Guardian.

The Guardian then protects the data and writes any moves users tell him that the Guardian deems valid into the book. Now if someone gives the Guardian a bad move, the Chess Guardian will be there to stop the bad move from ever reaching the book.

Scaling

Now if we want 1,000s or 100,000s of users playing chess we need to “scale” our service. We can do this by adding more Chess Guardians (services) and Books (Databases).

Simple enough, or is it…

Protecting the Database

Because the books contain the source of truth of all chess games the Guardians must protect it with their lives. A single intruder who is able to sneak past a Guardian could steal a book or worse, write into the book directly and change entire games. This cannot happen!

To prevent this, walls and defenses (Firewalls) need to be built around the books. Furthermore, the books must be protected with locks and keys (Permissions) only given to the guardians and the most trustworthy of individuals.

Protecting the Database…Again!

Even with perfect defenses, accidents can occur. A trusted individual might accidentally write a bad move into a book or the book might start to show wear and tear over time and become unreadable.

To protect against all these, copiers (database redundancy) are used to copy everything a Guardian writes into one or more additional books (all of which need a lock and key as well). This way, if the original book ever gets messed up for any reason there are additional backup books which can be used.

Our chess service is now well protected…or is it…

What if our little fort was hit by a natural disaster? To protect against that we would need to create a duplicate fort far away and find a way to communicate between the two for consistency (geo-replication).

How is it that we have to do so much just to maintain a functioning, scalable service. How could something so simple be so difficult?

It comes down to a lack of synchronicity between the Guardians (rules) and the Books (data). The Guardians want to use the Book in a very specific way but it takes a monumental effort to enforce this because the book is so open. If only there were a way to combine the powers of both into one…

The Constraint Machine and The Guardian Book

And here we finally arrive to our discovery: The Constraint Machine or the Guardian Book.

What we’ve done is take the Guardians (rules) and integrated their spirit deeply with the Book (data) to create a fundamental primitive: a “Guardian Book”, so to speak, a book which on its own can understand complex, stateful rules and can enforce it.

On the outside, this Guardian Book looks like a normal book, but it has black magic which makes it, unlike any other book.
Instead of writing data on blank sheets, you interact with “live” dynamic things in the book.

Instead of writing the next chess move, you speak your next move. Once the Guardian Book determines you and your move are “worthy”, you can then see with your own eyes as the piece moves to the correct square. This is the spirit of the Guardian in the “Guardian Book”.

What does this mean in practice?

Because the Guardian and the Book are one, users can now directly interact with the book. No more Guardians, no locks, no keys, no walls, and no copiers needed. This means less infrastructure, less complexity, less cost.

To bring home the point one last time, regular books (databases) store representations of chess games, while Guardian Books (constraint machines) store actual “live” chess games (state machine store).

Volume 2…

We’ve gone through the basics of what it means for the Constraint Machine to be a state machine store but there’s so much more to uncover.

In future volumes, we will show how the Constraint Machine is:

-Fully asynchronous, real-time/offline-capable
-Programmable
-Capable of practically free branches and time travel (like git)
-Linearly scalable
-Fully distributed/decentralized (if wanted)
-The perfect match for permissionless consensus protocol, Tempo

Join The Radix Community

Telegram for general chat
​Discord for developers chat
​Reddit for general discussion
Forum for technical discussion
​Twitter for announcements
​Email newsletter for weekly updates
Mail to hello@radixdlt.com for general enquiries