Many-to-Many Interoperability with Threshold Simplex
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).
So, how does this help? Prior to initialization, the validators of a new consensus::threshold_simplex network run a DKG to generate a shared threshold secret (that no individual validators knows the value of). Each validator then uses their share of this secret to sign consensus messages, recovering threshold signatures that can be verified using the public key of the shared secret. With resharing, a network utilizing consensus::threshold_simplex can retain the same BLS12-381 public key across arbitrary reconfiguration (i.e. validator set changes). These recovered threshold signatures are then packaged into ~240-byte certificates (roughly the size of an average transaction) and then broadcast to any other consensus instance interested in the latest finalized output. With this certificate (just a single BLS12-381 signature verification) and the open block format of consensus::threshold_simplex, arbitrary data can be exchanged and proven about an external blockchain (e.g. state referenced by a state root in a finalized block).
Threshold DKG and resharing in Byzantine environments is still relatively novel (with massive advancements introduced even over the last 3 years). To ensure consensus::threshold_simplex can be paired with the latest, greatest, and safest ideas, DKG and resharing are decoupled from the consensus construction itself. To help developers get off the ground, however, we released our own construction that scales to hundreds of participants (favoring a synchrony bound over ZKPs and a “public board”). If you want to use your own technique, plug it in!
To demonstrate how consensus::threshold_simplex can be used, we implemented a proof-of-concept bridge between two independent consensus instances called examples::bridge. In this demo, each consensus instance exchanges succinct consensus certificates about the other (and checks their validity during block verification). Block election is driven by the embedded VRF (the leader of view v+1 is only known at the conclusion of view v). You can run this demo yourself or watch the walkthrough:
If your application could benefit from exchanging succinct consensus certificates with other blockchains that can verify BLS12-381 signatures (looking at you EIP-2537), reach out!