Owner: @Álvaro Castro-Castilla

<aside> 🚨 This document contains flawed solutions. It's kept for historical purposes. Contains an explanation of the problems as well as explored solutions that served to continue further research.

</aside>

Introduction

The objective is to provide a great user experience: low-latency state updates with credible finality. We attempt to achieve this without compromising in any of our foundational tenets: decentralization, censorship resistance, permisionless-ness and privacy. Not only that, but along the way we achieve an improvement in decentralization and censorship resistance.

We propose achieving this via preconfirmations, ie providing near-instant cryptoeconomic guarantees of transactions inclusion/execution to users. However, during the journey towards solving this, we encounter the challenges derived from the probabilistic nature of the finality of consensus in the Base Layer. Tackling this, as the reader of this document will soon realize, becomes a prerequisite to make preconfirmations both feasible and useful.

The Main Roadblock: Reorgs and MEV

There are two key properties of our consensus protocol that combine in a very negative way, getting on the way of providing a smooth user experience in higher layers:

• Very long finality time
• Knowledge of leadership lottery winning turns for the full epoch in advance

Long Finality Times

Cryptarchia has exceedingly long finality times, due to its probabilistic nature (using Cardano's parameter as reference here):

• 100% finality (weak subjectivity): 2160 blocks (~12 hours)
• Many applications consider a block final after 15-30 blocks (~5-10 minutes), with a 4.98% chance of a fork.

This is acceptable (although not without its undesirable consequences) in p2p transactions, where the worst that can happen is that users have to wait for very long in this direct account-to-account transactions. However, this problem becomes more preeminent in the case of a generalized chain that offers shared state computation (dapps), like Nomos. These finality times are certainly not conducive to the UX that we want to obtain in Zones.

A priori Knowledge of Leadership

Validators know one epoch in advance when they are going to be selected. While this is private (only each node knows about its own selection in the epoch), and achieves our PPoS objective, it has several negative outcomes:

• It disincentivizes small validators, which will know in advance that will not be selected, thus choosing to leave the network until next epoch. This has an undesired effect in network stability, resiliency, decentralization and security.
• It gives large validators an additional MEV edge: long-range or multi-block MEV. Multi-block MEV refers to attacks done on consensus economically motivated to obtain MEV:
  • Withholding attack. A validator that holds several consecutive winnings can use this knowledge to withhold the blocks and release them at the time of is own interest.
  • Long-range reorgs. A validator that holds many winnings in an epoch could potentially construct a heavier fork by itself (and bribed associates).
• Loss of Adaptiveness, easier collusion, reduced effectiveness of privacy measures…

This a priori knowledge is one of the biggest weaknesses of the current design of Cryptarchia. Fixing this will get us closer to the ideal.