Many-to-Many Interoperability with Threshold Simplex #354
Replies: 1 comment 3 replies
-
|
This is really cool. It does raise some interesting thoughts about the social coordination layer. Even blockchains that are built from scratch on commonware would need an ability to share validators for bi directional comms. In this instance then, it seems practical to do:
Option 2 seems like the more interesting approach. Initial thoughts are that it would have to be a public good as it's goal would be purely connecting chains. Although you could still fund the public good by introducing a small fee for services at some point. |
Beta Was this translation helpful? Give feedback.
-
Just to clarify, no validators need to be shared for bi-directional comms (see All that needs to be communicated (once) is the "static public key" of another network's shared secret to verify posted "succinct consensus certificates". I suppose you could try to add some coordination layer on top of this but I don't feel its necessary (the unique identifier of any consensus set is unchanged across validator set reconfiguration, so nothing to communicate/keep updated over time). I suppose its "good to know who's out there" but assumed a network would be overkill just for that. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, ok I missed that. That makes it even more compelling. Will play with the example this week to get my hands dirty |
Beta Was this translation helpful? Give feedback.
-
|
Absolute ✨ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Starting with the launch of the second blockchain, connecting any blockchain to any other blockchain without additional trust assumptions has been an elusive dream. Ten years later, application developers must still settle for some version of this.
Techniques that enable consensus-secured messaging between independent blockchains (like lite clients and/or ZKPs) impose high per-message and per-connection overhead that bounds the number of external connections a single blockchain can handle to a few dozen. To go beyond this scale, some have created networks of networks to amortize the cost of any pairwise connection by storing all peer validator sets in a single location (where each blockchain trusts this overlay to provide the correct set of validators to verify any incoming message). Others have sought to provide a single execution environment where blockchains can settle to, using the settled state as a means of communication (requiring ZKPs that are prohibitively expensive to run at high throughput and/or introduce significant latency). Some have given their sequencing rights to a single builder to allow any set of chains under the purview of said builder to interact with each other. The largest group of connecting blockchains, however, have opted to employ external relayers to attest to the validity of exchanged messages because the consensus of interoperating blockchains can’t be efficiently proven on each other (or at all) in the first place.
Today, we are excited to empower application developers to take one step closer to this dream of many-to-many, consensus-secured interoperability between independent blockchains with consensus::threshold_simplex. This new consensus dialect provides Simplex-like BFT agreement and emits succinct consensus certificates for each finalized view. In a nutshell, consensus::threshold_simplex natively embeds BLS12-381 threshold cryptography into agreement to recover threshold signatures whenever 2f+1 messages are collected during any part of a view (zero message overhead compared to the previously released consensus::simplex dialect). This same technique, conveniently, also enabled us to embed a VRF (for leader election and post-facto execution randomness).
You can learn more here:
Beta Was this translation helpful? Give feedback.
All reactions