You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 23, 2022. It is now read-only.
Currently a lite client must check 2/3 + 1 signatures.
I believe that the lite client could instead check that 1/3 + c signed the header hash, and you get a sliding scale of guarantees in exchange for better efficiency.
When c > 0, the lite client is guaranteed that upon seeing conflicting satisfying commits, the 1/3 assumption has been broken. Upon learning this, the client can feel free to panic / abandon the chain until manual override, etc.
For 0 < c < 1/3, the lite client increases its odds of catching the double-signing node.
When c > 1/3, the lite client is guaranteed that upon seeing conflicting satisfying commits, it can create a fraud proof for at least one entity.
Since seeing a successful fork is such an extreme event, it seems likely to me that many lite clients may find it sufficient to be aware of the fork and deal w/ it via social consensus, and to not have to be able to submit the fraud proof.
(This whole point is moot once aggregate signatures are in. Then theres no advantage to only verifying a partial amount)
I believe that the lite client could instead check that 1/3 + c signed the header hash
Do you mean when fully verifying the commit? It's possible that +1/3 precommit a block that doesn't get committed (ie. there's no fork), even if <1/3 are faulty. Ie. with four equal power validators A, B, C, D where A is faulty, A&B could precommit BLOCK in round 0, but C and D might never see those, and A, C, D could precommit (and thus commit) BLOCK2 in round 1. A light client that trusted BLOCK based on the +1/3 from A&B would be fooled even though only A was malicious. So we have to verify the +2/3 commit.
But we do use +1/3 to see if we can skip ahead, and that's what bisection is based on, and we do use a trust_level for that, which runs from +1/3 to +2/3.
Currently a lite client must check 2/3 + 1 signatures.
I believe that the lite client could instead check that
1/3 + c
signed the header hash, and you get a sliding scale of guarantees in exchange for better efficiency.c > 0
, the lite client is guaranteed that upon seeing conflicting satisfying commits, the1/3
assumption has been broken. Upon learning this, the client can feel free to panic / abandon the chain until manual override, etc.0 < c < 1/3
, the lite client increases its odds of catching the double-signing node.c > 1/3
, the lite client is guaranteed that upon seeing conflicting satisfying commits, it can create a fraud proof for at least one entity.Since seeing a successful fork is such an extreme event, it seems likely to me that many lite clients may find it sufficient to be aware of the fork and deal w/ it via social consensus, and to not have to be able to submit the fraud proof.
(This whole point is moot once aggregate signatures are in. Then theres no advantage to only verifying a partial amount)
Moved from: informalsystems/tendermint-rs#54 (comment)
The text was updated successfully, but these errors were encountered: