Skip to content
This repository has been archived by the owner on Feb 23, 2022. It is now read-only.

Lite clients checking between 1/3 + 1 and 2/3 +1 sigs #59

Closed
ValarDragon opened this issue Nov 12, 2019 · 2 comments
Closed

Lite clients checking between 1/3 + 1 and 2/3 +1 sigs #59

ValarDragon opened this issue Nov 12, 2019 · 2 comments

Comments

@ValarDragon
Copy link
Contributor

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)

Moved from: informalsystems/tendermint-rs#54 (comment)

@ebuchman
Copy link
Contributor

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.

So I think we can close this?

@ValarDragon
Copy link
Contributor Author

Ah you're 100% right. Thanks for the explanation!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants