Wen fraud proofs, wen mesh security?

Hey all,
I listened in on the Polygon 2.0 Twitter space this morning and they are only weeks away from what sounds a lot like mesh security. The MATIC token will soon be upgraded to POL and that can be used by stakers to secure multiple chains at the same time.

I went back and read @jtremback from Informal’s beautifully detailed post about Enabling Opt-in and Mesh Security with Fraud Votes.

He says, “Fraud proofs are an ongoing area of research and primarily intended for use with roll-ups, which are similar to consumer chains. A fraud proof allows you to prove that a validator signed an incorrect state transition, without needing to run a full node for the chain involved. A provider chain could accept proof that an incorrect state transition was signed by a validator and slash the stakers involved. This would enable Opt-in and Mesh security to function as intended. However, fraud proof implementations are perpetually six months from completion. It’s a very hard technical problem.”

He goes on to say, “To be able to launch Opt-in and Mesh security while work continues on cutting-edge fraud proof research, we can turn to a simple mechanism: the fraud vote. This would be a type of governance proposal. If (and only if ) a staker or validator had opted in to stake on a Opt-in or Mesh consumer chain, they would become eligible to be slashed by this governance proposal… This is certainly not as elegant as a fully automatic and optimized fraud proving system, but it should have much the same effect.”

“This also allows us to capitalize on an advantage that Cosmos has over rivals… The possibility of fraud votes on Cosmos allows us to innovate and get out ahead while fraud proofs are still under development…Cosmos should lean into its advantages, one of which is a robust and frequently used governance system built into the code and culture at a low level. In the case of the fraud vote system proposed here, this will allow us to increase our lead in the shared security space.”

“It should be noted that in the case of real fraud proofs, the validators applying the emergency upgrade would be slashed automatically.”

After reading it again it sounds like fraud proofs are aways off and that the temporary alternative of slashing through governance is probably considered by Jehan to be a failure (not trying to speak for him) in prop 818: Punish Equivocation on Neutron by Pupmos and Citizen Cosmos. Blocks United was among the 70% that voted NO on prop 818, which I mention just to take a little responsibility in case that vote turns out to hurt the ecosystem.

What’s my point with this post?

Polygon seems to be leapfrogging past Cosmos. As a Hub validator that worries us, because we love Cosmos and the Hub. And for the record we are a Polygon PoS validator too.

Will core contributors please comment and share a loose timeline for the arrival of fraud proofs and mesh security?

Respectfully, Matt from Blocks United

1 Like

Getting fraud proofs to work with the Cosmos SDK is unfortunately not something that we have the expertise or bandwidth to take on at the Hub team, but maybe someone from the Cosmos-SDK or Rollkit teams can comment in more detail, since they are working on these things.

Without fraud proofs, as I wrote in that post, we are left with fraud votes (or just running unsecure protocols). Fraud votes are extremely easy to implement, but could be tricky socially. I wrote about the challenges here: Informal Blog - 818 Post Mortem

Fraud votes are even trickier from a governance perspective than voting on double signs, since just running the wrong code is a slashable offense.

But anyway, once we have a use for fraud votes, deploying them is trivial. In terms of uses for fraud votes, there are two.

  • Mesh Security: Eigenlayer is similar to Mesh (based on it?), and I believe it is an optimal design for restaking/shared security. The Mesh Security team is working hard and we are supporting them on some of the tougher theoretical questions around slashing etc. I’ve also heard that there are teams working on connecting Mesh Security to Eigenlayer, which is exciting.
  • Opt-in Security: Polygon 2.0 is similar to Opt-in (AFAICT from the scant details in their paper). We have not been working on this much, since Mesh Security seems to be around the corner, and is more flexible. We are about to start on an overhaul of the ICS protocol (read-only protocol) which should make it much easier to do Opt-in Security if Mesh is delayed or something, as well as solving several other problems.

That being said, I’ve recently started thinking that selling security is not a very solid business to build on in the long term, since the endgame is that applications can get security from many providers at the lowest possible price.

I think that ultimately, applications will choose where to deploy based on alignment, and ultimately composability with other high value applications. One way to capitalize on this is to take advantage of Replicated Security’s full validator set overlap to offer consumer chains much more powerful IBC connections between each other. I’ve written more about this in the context of atomic IBC.

So while we believe that Atomic IBC gets us out in front of the security market in the long term and we’d like to focus on it in 2024, we will stay on top of more advanced shared security protocols by working to get Mesh Security deployed to the Hub and/or enabling Opt-in security.


Thanks Jehan. I appreciate your thoughtful response.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.