Strategies for distributed decentralised computing

Decentralised databases

Recently I thought briefly about how one might implement a decentralised set of services, analogous to the idea of blockchain being a decentralised append-only database.

Suppose that one could somehow solve the issue of blockchain being append-only, so that one effectively had a relational database that was decentralised after such a fashion, via a mathematical object with a state obtained via consensus between different nodes. Then one would need controls on how the database was modified, still, in order to prevent STRIDE type security issues. This could potentially be mediated by a secondary system that was not decentralised which could adjudicate consensus regarding how things should be modified.

But the basic premise or idea which is interesting, is that one can potentially shift from a database on a single machine, to a representation of database state encoded as a mathematical object which is shared between nodes. This decentralised representation of the state of the data would be much more robust, but it evidently has governance challenges.

The question of governance for how an object-as-database-state representation can be modified is a good question. Presumably this would be controlled by client software that ran the system on each node. Each client would probably be able to establish peer to peer connections with one or more other clients in order to “vote” on a change to the database. There would be an algorithm that then would broadcast a candidate decision to neighbouring cliques of peers, and this would be backpropagated and forward propagated according to some reasonable algorithm within a particular Epoch until global consensus regarding state was reached, according to rules hammered into each and every client, per an algorithm that could provably be demonstrated to converge.

Harder would be to do away with Epochs entirely, and be able to propagate a decision at any point, and be therefore able to arrive at asynchronous consensus of the state of the database. This should still be possible to do, but it would require care regarding design of the client software, while factoring in cases wherein parts of the network might become unreachable, “lagged out” (i.e. violate time out checks), or separated, or certain nodes might go down.

Additionally, in the situation wherein a network is split and then recombines, one would need a way for two networks that start communicating with each other to determine 1) whether it makes sense for them to merge their db state, 2) how they merge their db state. i.e. one would need an emergent swarm decision-making capability / intelligence arising from properties of the client and the way they can connect with other clients, in terms of whether a network that was broken and then re-established should piece itself together again, or effectively become two separate entities / “persons”.

So that’s databases. Note that I am assuming capabilities (i.e., the ability to not just have an append-only decentralised database) that do not currently exist.*

Decentralised systems

Of course, I’m interested not just in decentralised databases. I’m interested in decentralised systems. So, how would that work?

Let’s define a system to be WLOG a virtual machine that is running some software. We can sort of do this, since patterns like kind and kink allow for a high degree of abstraction. Therefore, we’d like to abstract a representation of the state of a VM. Fortunately, there is at least one way to do that, using nixOS.

So let’s take the state of our nixOS VM and encode it as a set of objects. Presumably we’d be interested in encoding within something more complex than a set of different points in different elliptic curves; one would be after likely a richer set of mathematical structures to work with, that still reduce to moderately simple representations. Elliptic curves are useful because they have a group structure. Potentially, then, one might be interested in function spaces of elliptic curves that have group structures (i.e., at function space level) … or something slightly more exotic (eg, function spaces of elliptic surfaces/manifolds perhaps?).

Then, assuming that this is all possible, we have services in our VM that could primitively be represented as state machines, and we allow for representation of the set of states of the services in the decentralised VM to be voted on by consensus mechanisms. Then, in theory, one could do the same thing with our fictitious decentralised database capability – asynchronous back/forward propagation algorithms until consensus, rinse and repeat.

Presto, you have a distributed decentralised system!

A paper

I also found this paper recently (“Decentralized SDN Control Plane for a Distributed Cloud-Edge Infrastructure: A Survey”) which touches on some tangential ideas, and surveys some existing technologies. The technology readiness level table in the appendices is worth a quick glance if nothing else.

*But, hey, we’re theorising, so there is no need to let silly little things like stupidly difficult technical hurdles get in the way.

Tags: decentralised systems, distributed computing, random thoughts