Pivoting on the DAN

I came across an article a few months ago by Dan Hughes, founder of a DeFi-focused proof-of-stake project, Radix, that opines that blockchains can’t scale. It makes many points (all of them correct), such as

• Scalability, Security, Decentralisation. Pick 2.
• Sharding still requires co-ordination and some sort of global state.
• Side- or state-chains scale, but do not interoperate easily and require things like bridges, which are hard to get right.

We’ve been thinking about these exact issues (and more) while developing Tari. If you’ve been following along, you’ll be aware of our position on these, but in case you’ve just joined the party, here’s a tl;dr:

Scalability, Security, Decentralisation. Pick 2.

We’ve discussed this very point at length within the Tari community and take it as near-axiomatic that scaling a level 1 blockchain network is not feasible.

Our intention was always to build a base layer proof-of-work based network that prioritises decentralisation and security over speed and latency and supplement this with one or more second layer networks than emphasise scalability and speed. Notice that we explicitly pick 2 different goals on two different layers to get everything we want.

Sharding still requires co-ordination

It’s always bugged me that the sharding proposals of Ethereum and friends seem to shrug off the idea that there still needs to be some sort of global co-ordination to avoid double spends. It feels like a fundamental blocker, to be honest. Dan talks about this in his article too. Sexy ideas like ZK-rollups can help make this process pretty efficient, but it still requires some sort of global lock-step, and I agree with Dan; this leads to either centralisation or a massive brake on scalability.

The obvious “solution” here is to run independent side-chains, so that there is no global state! It’s a cop-out, but it kinda makes sense, right?

Let’s take a real-world analogy: If I want to securely store the hundred gold bars I wish I had, I rent space in a bank vault. I am very happy that there is a lengthy and thorough procedure in place in case I ever want to move or sell those bars. I also don’t mind paying the hefty price tag for the security protocols, guards, CCTV and insurance costs that come with storing my gold in a bank vault because well, gold.

But when I go to the gym and want to secure my phone and wallet, I do not want to put them in a bank vault. Can you imagine? It’s a ridiculous idea! A small locker secured with a $10 padlock is more than sufficient. But everyone who uses a Layer One network for small transactions is using (and paying for, even if they don’t realise it) a bank vault to store their phone and wallet. Or worse, the security and/or decentralisation of the network is shit, and everyone is using a gym locker to store everything, including their gold bars!

With Tari, the philosophy has always been to let you use (and pay for) the level of security, scalability and decentralisation that you need. Ultimately we decided to take the independent side-chain approach. Asset owners could pick the number of validators to manage their assets, effectively giving them control of the speed-security-decentralisation triangle.

We knew that while this approach had many advantages, we would ultimately have to address cross-chain interactions.

Which brings us to…

Side- or state-chains scale, but do not interoperate easily

We could bite the bullet and say, “yeah, we just won’t support side-chain interactions” but that would destroy one of the key value propositions of a decentralised digital assets network: the idea of permissionless innovation and interoperability. If Sarah identifies an opportunity to build a business based on tokens that are issued from a different contract, she should be able to do so with as little friction as possible.

We’ve been mulling over this problem for a long time and RFC-312 discusses several strategies that Tari side-chains could use to play nicely together. Admittedly, all of them pose significant technological hurdles.

The most common strategy is to use bridge contracts to allow side-chains to communicate with each other. And there’s no denying the fact: Building secure bridges is hard. To whit, hack1, hack2, hack3, and hack4, in 2022 alone.

Why bring all of this up?

It turns out that Dan wasn’t just being a typical crypto-twitter negative nellie. He has actually developed a little-known consensus algorithm called Cerberus that he believes solves the scalability problem once and for all.

Colour me sceptical. We’ve all heard this a million times before. Cardano, Solana, Near, Blahcoin have all claimed to have “solved” scaling, but inevitably all fall victim to the blockchain trilemma once you dig a little deeper.

I also say little-known, because to my knowledge, only Radix is developing Cerberus, and almost anyone I’ve spoken to in this space have never heard of it.

But after reading the paper I felt like “Holy, shit. I think he’s nailed it”. It was almost like reading the Bitcoin white paper again, not to blow too much smoke up Dan’s ass :) But honestly, Cerberus is really, really clever.

It’s elegant, relatively simple, handles cross-contract interactions by design and scales linearly (as claimed).

To be blunt, it’s just better than what we’re building. The core developers have been discussing this for some time, and there’s broad consensus that we should just pivot to using Cerberus. This is a move that I and fluffypony support.

How does it work?

The version of Cerberus (there are several flavours) that I’m picturing for Tari is basically a version of Hotstuff where the relationship between Validator Nodes and Contract State is turned on its head.

I can’t give a full description of a BFT consensus algorithm in a few sentences – there will be RFCs for that – but I will try and sketch out the ‘big idea’ behind Cerberus and encourage the interested reader to go and read a bit more.

Instead of VNs managing state for a given contract, VNs manage predetermined pieces of state, out of the entire universe of possible states! This mapping is essentially random, so that state management is automatically load-balanced across all nodes in the network. Furthermore, as nodes join the network, the portion of the overall state space a VN is responsible for shrinks accordingly, meaning that capacity essentially scales with the number of nodes.

Since this mapping of state to VN is deterministic, anyone can verify that nodes claiming to have reached consensus on a state change are in fact the ones that were tasked with that role.

This is the secret sauce of Cerberus, and when it clicks for you (you may have to read the Cerberus paper or read Radix’s Infographic series), you’ll understand why it’s so exciting.

VNs can join and leave the network permissionlessly (within limits - we add measures to prevent Sybil attacks and maintain a level of computational stability), but in turn need to be prepared to handle instructions for any contract in the network; this is a trade-off in the consensus algorithm design that I feel is well worth the benefits.

It should then be fairly obvious that if VNs are reaching consensus on small bits of state rather than information related to specific contracts, inter-contract interactions just work (TM).

What does this mean?

Well firstly, it means that Tari gets a better DAN.

What’s also quite interesting is if we couple the Cerberus Layer 2 to our Mimblewimble base layer as in the original DAN design, we actually gain several advantages over a pure proof-of-stake system (like Radix) that I’ll talk about in a future post.

It also means that there are implications on the development timeline for the DAN. Interestingly, the core maintainers have done an assessment and concluded that overall, we don’t lose too much: we’ve gone back a step or two, but now have an easier road to DAN v1.0.

There are also some implications for a mainnet release. The broad consensus among the core developers is that we should launch the base layer without a fully functional DAN, and bring the DAN online in a smooth and orderly fashion.

There will be a community discussion on this topic on the Tari Discord on 2022-09-26 at 09:00 UTC. So make sure you don’t miss it!