congrats on the paper! It was very interesting to compare POSDAO to the mPoS approach we’re taking for the Trustlines Blockchain. I’ve been told here would be a good place to provide feedback and ask some questions about it.
Why are those paid to the chain validators? Wouldn’t it be more natural
to pay them to the bridge validators?
In the reference implementation you use xDAI for transaction fees and
the native token for staking, arguing that price stability is important
for users but not so much for stakers. But couldn’t one also argue that
it’s exactly the other way around? Stakers will likely hold many more
tokens than users, even in a less liquid form, so they should be more
interested in a stable price.
I’m curious if you’ve done the math on various allocation strategies to
find if there’s an optimum and what it is (I’ve seen the simulations in
the appendix, but it should be possible to get an analytic solution).
What’s best for candidates, in case they got some additional tokens to spend: (1)
Increase their candidate stake, (2) get a new candidate slot, (3) or
delegate to themselves? It should not be (3) because then there will
likely not be a lot of people willing to become validators. If it’s (2)
you could get rid of dynamic stake sizes entirely and just have a fixed
amount. Intuitively, (1) feels like the best outcome (but I don’t know
if it actually makes a difference).
What’s best for delegates? Delegate to (1) “saturated” (i.e. for which
the 1/3 clause is already in effect) or (2) “unsaturated” candidates? I
would guess (2), which could mean that they’d attempt to pressure
candidates into splitting their stake into multiple candidate slots.
Long range attacks
I think the only solution is explicit checkpointing (i.e. “weak
subjectivity”), finalization of the consensus protocol as you seem to rely on doesn’t help. The
problem is that a new node in the network doesn’t know which finalized
fork appeared earlier.
You say if validators don’t reveal in the last reveal round of a staking
period, they are treated as malicious. Doesn’t this run into censorship
attacks by the block proposers at the end of each round?
In general, RANDAO appears very problematic for validator sampling and
also hard to analyze (what if few validators in a row collude? What if
they try to amplify their influence over time, i.e. to get more more and
more slots over time?). Have you looked into other schemes, such as
DFinity-style threshold signatures or Ethereum PoW block hashes (with
their own pitfalls of course)?
The POSDAO seems to face a similar challenge as our mPoS approach: While
everything works fine if the security assumption is met (some kind of
honest majority), there’s only limited accoutability in case of
misbehavior (as it isn’t provided by the underlying consensus protocol).
Our approach is to solve this by adding a slashing mechanism, and also
by having the socially plausible threat of forking, leaving the attacker’s stake locked for
a long time (similar to what you do in case of RANDAO last revealer
attacks). I guess in your case, the fact that the attackers stake is
tied to the value of the token leads to some amount of accountability.
Do you have any thoughts on this? Are you considering adding a slashing
mechanism later, e.g. in the Honey Badger implementation, or do you
think this is not necessary?
Especially for small chains, bridge validators will have a lot of power
as they control both the token supply on the side and on the main chain.
I think this is dangerous. E.g., they can (threaten to) stop doing their
job and the token value and with it the security of the chain will
plummet. In case of a fork, they control what the canonical chain is
(the chain their main chain bridge contract is referencing and that is thus
tracked by exchanges). They can also set arbitrary restrictions on who
can transfer staking tokens between the chains, and therefore restrict
who can and who can’t become a validator. One could argue that this
makes the security model of the chain fall back to PoA.
I don’t see an easy solution for this though. One way is to only have a bridge main->side using the same validator set for bridge and chain, and nothing in the other direction. Depending on the chain, this can be sufficient, but I see of course why this is not a viable solution in general.
If I understand correctly, this allows a 50% majority to remove other
validators. Doesn’t this reduce the security model from 2/3 honest
majority to 1/2? Do you log any proof of misbehavior, in order to allow
other nodes/validators to check why someone is reported and if this was
What are the changes you’ve made to Parity, in particular to Aura? Just
the finality condition (1/2 -> 2/3) or is there more? Do you think they
will be merged back into the official Parity repo at some point?