Ideal Labs x DF: Milestone 2 Update

Ecosystem
1

Hey everyone,

I’m Tony from Ideal Labs, along with @carloskiron @juangirini and @colemanirby, where we’re building the Ideal network (prev. ETF network) under the Decentralized Futures program. I’m excited to share our latest developments! We’re building an “interoperable and decentralized entropy layer”, an MPC solution that produces threshold BLS signatures that enable publicly verifiable on-chain randomness and timelock encryption capabilities. Our goal is to enable interoperable randomness beacons, allowing for it to be consumed across-chains. In this post I want to share our progress and get input on our future plans as we near the completion of our second milestone. You can find a high-level overview with underlying motivations for the solution here.

TL;DR:

  • The Ideal Network is an MPC solution for producing verifiable randomness and timelock encryption

  • In our second milestone, we re-envisioned our consensus mechanism (which produces threshold BLS sigs) as a post finality gadget (the ETF-PFG) based on BEEFY.

  • Next steps: Develop tools for dapps using randomness and timelock through the Ideal Network, and research practical witness encryption using Circom and timelock encryption.

Overview

In our first iteration of our consensus mechanism, our implementation functioned at the block authorship level similarly to drand, where each block author was responsible for producing a BLS signature within each block they produced. While this technically worked, it brought severe limitations, such as requiring forkless consensus (i.e., limited to Aura), being difficult to secure and scale, and requiring significant waiting times for secure timelock encryption. Our first milestone used this limited mechanism to build out basic functionality for enabling a ‘timelocked transactions’ mechanism, based on the scheduler pallet. In our second milestone, we focused on securing and scaling the network. In order to accomplish this, we required a slight re-imagining of our protocol.

ACSS and Aggregatable BLS Sigs

The core idea of our protocol is that each authority produces an IBE secret (as in “identity based encryption”), which is a BLS signature, where the identity is associated with a given block. In our initial version we distributed the master secret key of the system to each member of the validator set. Obviously, this is difficult to secure and scale, so our first order of business was to introduce a secret sharing scheme. Specifically, we developed a scheme adapted from Long live the Honey Badger by Miller et al., which allows us to enable ‘asynchronous committee secret sharing’, meaning we can seed our protocol with a ‘resharing’ of a secret that allows each member of the validator set recover their own shares when required. You can find the core implementation of our ACSS scheme here.

To integrate this into Substrate, we must have that each authority has a BLS keypair. Rather than trying to somehow construct a “BLS Aura”, we redefined how our scheme works, re-imagining it as a post-finality gadget based on BEEFY. We call this the ETF (encryption to the future) Post-Finality Gadget. To integrate our scheme into existing constructions of BLS signatures in Substrate, we rewrote our underlying scheme to use Efficient Aggregatable BLS Signatures with Chaum-Pedersen Proofs by @burdges @AlistairStewart @oana and Syed Lavasani (not sure of his handle), which is implemented in the w3f/bls crate.

etf_finality_layer.drawio(2)
etf_finality_layer.drawio(2)1676×1540 205 KB

The gadget is seeded with an initial validator set and an initial ‘resharing’ of a secret on genesis. Each of the validators use their designated resharing to recover their secret key for the round, which they use to produce a threshold BLS signature (a.k.a. IBE secret). We currently configure the network to do this on top of every finalized block, producing a rapid and cheap stream of signatures.

Unlike BEEFY, the point of our PFG is not to bridge the underlying Ideal network to the outside world, but instead to use the stream of justifications to produce a randomness beacon, where each justification contains threshold BLS signatures that can be interpolated to get the ‘round randomness’. Through a relayer (demo version here) and light client, the signatures can be used in the context of smart contracts, pallets, or across chains.

In the future, we want to support cross-chain bridging wherein the ETF-PFG can produce signatures in sync with a bridged chain’s finality instead. This would allow users of the bridged chain to be able to use their own blocks and state to perform timelock encryption, instead of encrypting messages in terms of ‘Ideal Network Blocks’.

In the diagram below, we show how a contract could either call a contract that receives signatures from another contract (a ‘beacon’ contract), or from its pallet-equivalent. Here is a basic ‘rock paper scissors’ implementation. It fetches signatures from a ‘beacon’ contract and uses the result (code) to determine the outcome of a round of player-vs-system rock-paper-scissors.

milestone1.drawio
milestone1.drawio911×331 12.9 KB

Next Steps

  • We are working on setting up our project in github, which will allow the development progress to be easily known.

  • We are now reaching the final leg of our Decentralized Futures grant, where we develop our equivalent ‘polkadotjs’ interface along with tooling required to build dapps that allows for easy integration of randomness and usage of timelock encryption in contracts and web interfaces.

  • We are currently collaborating with Chainsafe Systems to develop web3 gaming solutions that leverage timelock encryption and onchain randomness through the Ideal Network. In our next phase, we plan to expand our solution by enabling interoperability for our randomness beacon construction.

  • We are also interested in implementing a practical witness encryption scheme using Circom, ACSS, and our timelock encryption scheme. Such a mechanism could allow for new kinds of fully on-chain applications to be built, such as conditional access and ownership mechanisms. We aim to initially use our solution in the context of web3 gaming, where it can be used to enable conditional access to in-game assets, perhaps certain items are unavailable to a type of character or only usable if they have reached a certain level. As another example, it could ensure players can only unlock new levels or achievements if they can prove they finished the previous ones.

We would love to hear your thoughts on our approach and any suggestions you might have for improving our protocol or expanding its use cases. What are your thoughts on integrating timelock encryption into gaming solutions?

Thanks for reading!

Tony Riemer (@driemworks )

3 Likes
2

We’ve two implementations of that paper: w3f/ring-vrfs/nugget_bls does the full protocol on the pairing friendly cure, which proves correct gossiped bls sigs. w3f/bls only does the two sided bls key, so it’s supports aggregation, but not efficent gossip. We’ll deploy in in beefy using and ed25519 or secp256k1 signature, plus slashing if disagreement occurs. This is more efficent, but much more code. nugget_bls is slower, but does not require slashing. It’s possible a parachain doing this for themselves wants nugget_bls for simplicity, but all the slashing code for w3f/bls exists, so if you’re good at extracting parts of the relay chain staking for usage on a parachain then hey whatever.

There are two components of drand, the PVSS required for randomness, and the full DKG + threshdol VRF required for GitHub - drand/tlock: Timelock Encryption made practical. The Go `tlock` library and the `tle` cmd line tool home to encrypt towards the future. Imho, the first priority here should be “drand bridge” pallets, which do either, but preferably drand/tlock, because many users could survive using drand’s own randomness, and the “bridge” is only a pallet, not actual bridge infrastructure. I’ll try to reconstruct what I wanted done differently in drand/tlock, but mostly just the ability for encryptors to decrypt early voluntarily. This is extremely easy, but we’re happy to give grant money for it. It’s likely a good on-boarding task for a junior cryptography person.

Alistair noticed parachains semi-solve the bandwidth scalaing problem of DKGs. This is a Big Fucking Deal, but you should discuss it with us. Alistair noticed other protocols, some of which simplify the DKG. We’re not rushing to do them, but agaiun you should discuss them with us. We’re unlikely to cheer on on grant money for full DKGs without first discussing them.

3

Thanks for the insights! I always appreciate your super detailed responses.

Efficient gossip will probably be more very important for us, so it seems that nugget_bls could be a better fit. We may want to introduce a slashing mechanism at some point though. Can you elaborate on why w3f/bls requires slashing but nugget bls doesn’t?

Imho, the first priority here should be “drand bridge” pallets, which do either, but preferably drand/tlock

This is what we’re aiming to do in our next steps, though initially in a simple/semi-centralized way. My thoughts are that we more or less just need a relayer component that subscribes to justifications (since we implemented as a PFG based on BEEFY), interpolates them, and then sends them to a light client (i.e. smart contract or pallet). Would that be ‘enough’?

I’ll try to reconstruct what I wanted done differently in drand/tlock, but mostly just the ability for encryptors to decrypt early voluntarily

We would definitely be interested in collaborating/working with you on something like this. Our current impl of tlock uses AES-GCM in conjunction with BF-IBE, where we lock the sk used for AES-GCM for a future round. The encryptor knows the sk so they can decrypt whenever they want, but others must wait for the threshold sigs to be produced in the future round. Not sure if this is what you had in mind though.

Alistair noticed parachains semi-solve the bandwidth scalaing problem of DKGs

This is super cool! We’re definitely open to discussing this and/or collaborating in some way.

4

Polakdot has efficent gossip using w3f/bls + ed25519/ecdsa + slashing. It’s really this slashing code that nugget_bls saves you.

I think a “bridge” here is purely about syncronizing clocks, so it’s more like provide the tools, tell people what they should do, and then let each pallet user ensure they’ve solved the timing problem. It’s imho not “centralized” in the usual sense, just “user must read the instructions”.

Afaik, drand has two flavors, PVSS and threshold VRF (tlock), but both flavors authenticate the time within the value they hash-to-curve. In other words, if you verify a drand output then it already includes the time claim by the league of randomness nodes.

We do not however know the exactly time mapping between polkadot slots and drand slots, but if anyone, including chains, verifies a drand output then they know drand has some later time.

How do we make sure people do not post ancient drand outputs claiming they’re recent drand outputs? We’ll have a pallet that’s monotonic increasig of course.

We could fix the time mapping in governance too, so then your drand bridge pallet could freeze if polakdot or drand gets massively delayed, but that’s probably acceptable.

As for other automation, I’m unsure if drand can sign off on external messages, but you might trust if simply enough participants vote the cited drand time is not too late. An off-chain state channel game could’ve participants use their local time. A parachain could’ve honest parachain nodes post small blocks with more recent times if the posted time lags too much. I’m unsure how much these matter if the pallet enforces monotonicity, and governance enforces some slot mapping.

Yes, that derived symmetric keys from the BF-IBE, which maybe all you require, and is the fastest option. We’ve another project that should derive public-secret key pairs, not yet supported by the tlock code, so we’ll do some fork or PR to tlock eventually.

It’s intuitively simple: DKGs have a malicious dealer problem, which could be solved by expensive ZKPs. Instead, we realize that polakdoit itself is a proof system, so we just make commitments in parachain blocks, which approval checkers verify. We should be able to do larger DKGs than others, but if the results are more secure than curated dealers schemes like drand really depends upon your threat model (polakdot validators vs google+cloudflare+etc).