Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relayers to implement bridge BEEFY fork equivocation detection #1260

Open
acatangiu opened this issue Jul 18, 2024 · 1 comment
Open

Relayers to implement bridge BEEFY fork equivocation detection #1260

acatangiu opened this issue Jul 18, 2024 · 1 comment

Comments

@acatangiu
Copy link

Description

Trustless bridging needs to handle a special kind of equivocation: fork equivocations.

Meaning the validators of one chain finalize one fork in the public consensus protocol of that chain, but collude to privately finalize a different fork and submit that private fork to a trustless bridge. The light-client of the trustless bridge will accept it as valid since it is "correctly" signed by a supermajority of validators.

This is highly unlikely since it requires a super-majority of honest validators to collude to cheat the bridge. But we still need some economic disincentive to doing this, to be able to keep that "highly unlikely" rating.

In the case of BEEFY bridge consensus, that disincentive is validator slashing if proven they engaged in such behaviors:

So Polkadot supports the mechanism to slash in case of misbehavior.

Required

But actual equivocation detection can only be detected by bridge relayers (or some other off-chain component watching the bridge). On Polkadot, the validators only publicly gossip the "good" commitments, and the "bad"/equivocated commitments are built in private, in secret and directly submitted to the bridge.

The only way to detect this is after the fact, when noticing a discrepancy between the finalized hash on Polkadot vs the finalized hash imported by the bridge BEEFY light client.

Once detecting this, an honest relayer can build an equivocation proof and submit it to Polkadot for a reward. This would result in the validators involved getting their stake slashed and thus provides good economic security against this type of attack.

Snowbridge relayers should implement this detection and reporting mechanism.

@acatangiu
Copy link
Author

As an example, this is how the P<>K relayers implement equivalent GRANDPA equivocation detection: paritytech/parity-bridges-common#2367

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

No branches or pull requests

1 participant