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
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
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
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
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
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
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
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,
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
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
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
Instead of VNs managing state for a
contract, VNs manage predetermined pieces of state, out of the
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
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
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
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
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
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!