aleph.org

aleph comparison notes

paper

https://arxiv.org/pdf/1908.05156.pdf

tl;dr (from an incomplete reading)

NB: I read this over the weekend and am probably confused on some of the points, but I wanted to get what I did retain down before I forgot.

Aleph is a fully asyncronous multimode protocol for building a blockchain-style over a DAG of “units”.

A unit is a list of parent signatures, a list of transactions, and some other metadata. A unit must point to other units from other nodes that are in prior rounds. This is the DAG, pointing back to some genesis unit. Once a unit is produced, it is broadcast using RBC over all units.

Units become part of the linear ordering when enough of the parents have become part of the linear ordering. The precise ordering of these units (when coalescing into a round, we need to order the units, then determinstically order the transactions they contain, forming a block/round. This separation between the linear ordering and the dispersal of units is critical, and complete. There are only two sub-protocols here, and they can operate largely asynchronously with respect to each other. Units are dispersed and agreed upon by one process, then there is another consensus ordering process running a different protocol which decides on how to finally order them.

Their randomness process is, when amortized, extremely cheap: while it requires a O(N^2 log N) setup, each query (new roll of randomness) is only O(N).

things we can use/learn

1. Multi-mode: it’s totally possible for us to default to a PBFT-like optimistic mode until there is some proof (in this case likely some threshold of invalid signatures in the signature phase, then fall back to RBC for some time period or until the next election.
2. BLS signatures: more validation that they can work in this context.
3. Shamir: this paper contains a more worked-out version of our experimental shamir RBC that we can use to guide our design.
4. Separation: the paper’s most interesting contribution in my mind is the separation of BFT-tolerant data transmission and BFT-tolerant round/block construction. I’m not sure how we could use this yet, but it’s an interesting thing to think about.
5. Randomness beacon: Their common coin is quite complex, but has a number of appealing properties, in that it can be setup once (more cheaply than our DKG) and then reused many times more cheaply.