Ideal Labs | Updates & Next Steps

Tech Talk
1

Hey everyone,

I’m Tony, a co-founder of Ideal Labs. Our team was formed out of the PBA2 cohort and we have spent the past year and a half collaborating to build and refine the Ideal Network, where we aim to bring secure, verifiable randomness :game_die: to the Polkadot ecosystem. As we approach the end of the year, we want to share an update with the community on the results we’ve accomplished, our plans for the future, and how the community is involved in them.

Recently, we completed the final leg of our Decentralized Futures grant, where we deeply explored verifiable randomness beacons and secure mechanisms for implementing them in decentralized and trustless ways. We have discussed with researchers around the world, read authors from Chaitin to Lévy and beyond, and, with the outcome of our work, we have developed a deep understanding of these mechanisms along with timelock encryption. As we move into the next phase of development, we want to share our progress so far and we would love to hear comments, thoughts, and critiques from the community on our work, our plans for the future and how we will accomplish them. Ultimately, this project is something built for and used by you. We are considering requesting funding from the KSM or DOT treasuries to accelerate our development.

In our journey so far, we:

  • developed a robust and flexible timelock encryption library that works against various types of randomness beacons (e.g. against Drand Quicknet or the Ideal Network PFG (see below)).
  • built a post-finality gadget where workers produce threshold BLS signatures as part of a randomness beacon protocol.
  • constructed several proof-of-concept applications, including shielded transactions with timelock encryption, sealed-bid second-price auctions, rock-paper-scissors, and other experiments with web3 gaming.
  • devised formalization for (publicly verifiable) randomness beacons based on stochastic processes.
  • developed a “V1” Drand-Bridge pallet which was granted retroactive funding through the Kusama treasury. There are several projects within and outside of the ecosystem who are currently investigating inclusion of the Drand pallet into their runtimes, and others who expressed a desire to acquire said randomness without requiring invasive surgery.
  • implemented a keyless crypto wallet protocol called Murmur. It uses secure OTP code generation and timelock encryption to enable wallets that use short passwords as seeds. Murmur was awarded third place in the 2024 OneBlock+ Polkadot Hackathon in Bangkok.
  • have a testnet running on Paseo with an MVP version of the Ideal Network deployed.

The ultimate goal of the Ideal Network is to function as a “Randomness-Beacon-as-a-Service” for the Polkadot ecosystem and beyond. While we have developed methods for bringing verifiable randomness from external sources (Drand) and generating it ourselves (the ETF-PFG), our next phase involves making it available to any parachain that needs it. More specifically, we are gearing up for an initial launch of the Ideal Network as a Drand-Bridge to the Polkadot ecosystem. For those unfamiliar, Drand is a distributed and battle-tested verifiable randomness beacon. For our initial deployment the IDN would behave as an oracle for ingestion of Drand pulses. By initially relying on Drand as our source of randomness, we can focus our efforts on the verification, delivery, and economics of the chain while we continue research and development on the Ideal Network beacon.

We have already been approached by developers on several parachains who have expressed interest in consuming verifiable randomness for various purposes, however, this would be available to any parachain that needs. These new capabilities have the potential to benefit the entire ecosystem. The randomness would be usable in runtimes, consensus engines, contracts, and beyond. It can be used to acquire verifiable randomness for many different kinds of protocols, such as verifiable lotteries, candle and Vickrey auctions, randomness in web3 gaming, NFT minting, airdrop distribution, and more. In addition to these, it admits a timelock encryption scheme and the many protocols it enables.

Roadmap

Below is a tentative roadmap for the IDN over the next year. While this is subject to change, it outlines our high-level intentions to position the IDN as a “randomness beacon as a service” for Polkadot.

  • Q1 2025: V0 - Drand Bridge and Initial Rollout
    • Integrate verifiable randomness from Drand into the Ideal Network.
    • Enable randomness delivery to parachains.
    • Set the foundation by creating a Drand-Bridge to Polkadot and/or Kusama.
    • Allow developers to experiment with verifiable randomness across chains.
  • Q3: 2025 V1 - Native Randomness Beacon and Timelock Encryption
    • Deploy a native randomness beacon built directly on finalized blocks, seeded using a secure distributed key generation scheme
    • The beacon is more efficiently verifiable (so, cheaper) than the Drand beacon (using DLEQ proofs instead of pairings).
    • Enable timelock encryption to future blocks and the Murmur keyless wallet protocol
  • V2 - Randomness-Beacon-as-a-Service (RaaS) and Enhanced Use Cases
    • Transition the Ideal Network into a “Randomness-Beacon-as-a-Service” platform.
    • Support protocol-specific beacons, offering unique randomness for each consumer.
    • Introduce event-based randomness production and support for alternative randomness beacon protocols.
    • Enable multi-beacon timelock encryption and beacon aggregation via Merkle Clock

V0 of the IDN injects verifiable randomness into the Polkadot ecosystem, however, it places reliance on an external system that functions without consensus or economic incentives to align the blockchain-based infrastructures. While Drand is free to consume, its clock ‘ticks’ at a rate independent of a blockchain. As a result, on-chain timelock decryption becomes tricky, as messages must be encrypted to future “rounds” of the Drand protocol, but it is not always possible to predict the round when the blockchain will fetch the pulse.

In the next iteration of the network (V1) we would aim to deploy a more efficient randomness beacon that runs natively on the Ideal Network. This beacon would be produced on top of finalized blocks in the Ideal Network through the ETF-PFG. By relying on DLEQ proofs instead of pairings for signature verification, we gain an excellent performance improvement with this version of the network, where we also expect lower costs. In addition, it makes timelock encryption much easier for blockchain, as it allows for encryption “to future blocks” as opposed to arbitrary future rounds of Drand.

The next iteration (V2) would then position the IDN as a “Randomness-Beacon-as-a-Service”, where it would allow protocol-specific beacons to be enabled through the IDN. This enables various new use cases, such as providing unique randomness to each consumer, event-based production of randomness, support for alternative randomness beacon protocols, multi-beacon timelock encryption, and more. In addition, we would introduce a beacon aggregation mechanism based on the idea of a Merkle Clock, adding abilities for temporal comparisons across beacons and a new ‘layer’ of trust between chains (e.g. A beacon outputs when an NFT on chain A is minted, another beacon outputs when an NFT on chain B is minted, and something on chain C is unlocked when pulses from both beacons are acquired without ever communicating with chains A or B).

Roadblocks

Our solution relies on the usage of Arkworks host functions to provide optimizations for cryptographic operations. Without these, the relay chain is unable to verify our blocks in time and we are unable to trustlessly verify randomness. There are various workarounds for this, such as trusting the OCW to verify the pulse offchain or relying on a 2/3rds approval from some committee who each verify the pulse, but this carries increased costs. Ideally, a relay chain should be upgraded to use the optimized Arkworks host functions before our solution can function properly. We have a slot on Paseo at the moment, but we can’t trustlessly verify Drand pulses yet.

There are some unanswered questions and other unknowns related to this, and we would love to get feedback from the community. More specifically, this is related to the delivery of randomness across parachains and cost models associated with it. There are several different ways to approach this.

Idea 1: XCM Request and Response

A parachain sends a randomness request to the Ideal Network and the network responds with the latest randomness, or desired round.

Idea 2: XCM Subscription and Dispatcher

This is effectively an ‘automated’ version of (1). A parachain subscribes to the IDN randomness and it is automatically dispatched to the subscriber whenever the network verifies a new pulse.

Idea 3: External Relayer and Light Client

An external relayer component can subscribe (for free) to the randomness and inject via a light client or similar. This would likely be more useful for non-parachain solutions than parachains, though it would allow a parachain to potentially consume randomness without requiring runtime upgrades (but requires the Arkworks host functions to be introduced).

Idea 4+: Suggest Something!

Beyond delivery mechanisms for randomness, there is the issue of the trust placed in the OCW in the initial version of the pallet. This can be eliminated by introducing an extra voting round where validators issue signatures to verify pulses of randomness. Similar to block finalization with Grandpa, if at least ⅔ of validators produce signatures on a pulse, it is considered valid.

Conclusion

If you’re interested in supporting our work, direct critiques, feedback, comments, or even just “hey that’s interesting”’s would be greatly appreciated! We are considering requesting funding from either the KSM or DOT treasuries to complete work on V0. This includes:

  • Making the Drand bridge more efficient and production ready by undergoing code audits.
  • Building out the randomness delivery layer and economics of the solution.
  • Provisioning infrastructure to stand up the network.
  • Deploying the network as a Drand-bridge to DOT or KSM, and beginning to provide randomness to consumers. Ideally, we would also ask for funding to perform further R&D on the next iteration of the network as well. To summarize, we would likely request funding from the community, specifically for completing development of V0, to cover hosting/infrastructure costs, and to allow us to secure a core on KSM or DOT (whichever seems most appropriate to get started).

Contact Information

https://idealabs.network

Join our Discord

hello@idealabs.network

14 Likes
2

Exciting to read about this! I really hope we as a community can carry the initiative forward. I see so many use cases for this!

Randomness-Beacon-as-a-Service (RaaS)

I like this, exactly what the Polkadot Cloud is about :slight_smile:

Idea 2: XCM Subscription and Dispatcher

Can you at this point already provide an estimate on the cost per byte of randomness? Would be interesting to compare against other solutions on other blockchains as well. My thinking is that subscriptions could work especially well if the randomness is cheap enough. It provides a very convenient overall experience. For example contracts benefit from this: There is no longer any need to request randomness first hand, it is just there.

4 Likes
3

@Cyrill

Can you at this point already provide an estimate on the cost per byte of randomness?

I don’t have an exact estimate, but at a high level there are three routes that the cost could take. One option is if the arkworks host functions are enabled on the relay, and the other is if they’re not, and a third is a hybrid of the first two.

Assuming the host functions are enabled, then we only need to fetch a pulse from Drand and verification can be done trustlessly on-chain. There’s virtually no networking overhead since it can be done by a single worker. We only store the drand pulse in this case, so a signature (48 bytes), randomness (32 bytes), and the round number (8 bytes). I assume this would be very cheap, with the costs incurred being due to the on-chain verification of a single pulse along with the fees associated with XCM dispatching and such.

The other route would be if we don’t rely on the arkworks host functions and would require a bit more effort to build, but would result in a more trustless and decentralized solution. In this case, we would rely on an committee (e.g. the set of collators) to fetch pulses, verify them offchain, and then submit signatures that the pulse is valid. This reduces trust in the system even beyond verification of drand pulses (by that I mean we don’t rely on an OCW to fetch pulses, since it isn’t guaranteed to execute anyway), however it carries greater computational and storage costs. This second approach is most likely the “right” approach. I don’t have an exact estimate, but it would be a higher cost than (1), but with less trust.

I think ideally a combination of both solutions would be my preferred approach, where workers fetch pulses from Drand, produce sigs on them that they gossip between each other, then once 2/3rds produce sigs on a pulse some chosen leader submits it on-chain to be trustlessly verified (so collators don’t do this offchain). The “IDN Beacon” discussed in the post uses DLEQ proofs for signature verification, so we can also expect for the solution to become ‘cheaper’ in the future.

3 Likes
4

To add another potential mechanism for delivery of randomness:

It appears that with the latest release of ink!, we can now send and execute XCM from smart contracts. I haven’t verified or tried this yet, but it seems reasonable to say we might be able to do a sort of “hybrid” between ideas 2 and 3 above, where we have a sort of ‘XCM subscription’ model where the randomness is dispatched to a smart contract directly, thus not necessarily requiring a runtime upgrade (unless you don’t support contracts).

4 Likes
5

Another angle is to have ZK proofs of the BLS signature over the random bytes and round number.
This way will be easy to verify in many contexts.
Idk if the proof generation could match the rate of randomness production or should be aggregated somehow and from an economical point of view how it stands…

2 Likes
6

Hey Tony, I really like this project—great work, keep it up! Idea 3 seems particularly exciting as it could extend use cases beyond parachains, and having more consumers could drive down costs, benefiting everyone. It would be fantastic to eventually see multiple delivery options available too!

2 Likes
7

You’ve done som pretty remarkable work here. Congrats!!

Just one question out of curiosity on the goal of Ideal Network becoming a “Randomness-Beacon-as-a-Service”. What are the trust assumptions that another parachain would have to take, if using Ideal Network as its randomness beacon? For example, would it have to rely on Ideal Network’s collators for the liveness of the randomness beacon? Or in other words, if Ideal Network is stalled, does it stop receiving new random seeds?

On the topic of how the randomness beacon delivery could look like, and speaking from the point of view of a potential consumer, I’d prefer Idea 2 (subscription based).

3 Likes
8

would it have to rely on Ideal Network’s collators for the liveness of the randomness beacon? Or in other words, if Ideal Network is stalled, does it stop receiving new random seeds?

Effectively, yes. In the ‘final’ version, which is still a bit tentative, consumers would rely on the IDN collators to produce randomness. In terms of trust, it could require less trust than the initial Drand bridge approach as it would rely on a more decentralized committee (and likely PoS, but not committing to that yet) as opposed to the OCW approach.

4 Likes
9

The short answer is yes. But on the consumer side (pallet or contract), there should be a fallback mechanism. This mechanism should switch to whatever randomness source the consumer is currently using, which means that the worst-case scenario would be the current scenario.
By the way, we are working on creating a pallet and a contract that consumers can deploy on their network to address this situation.

2 Likes
10

We recently opened a discussion on Polkassembly as an initial step to submitting a proposal to the Polkadot treasury to deploy a trustless drand bridge parachain that focuses on low-latency, low-cost distribution of randomness to consumers. Ideal Network: The Randomness Layer for Polkadot's World Computer | Polkassembly. You can expect an official proposal to be submitted over the next couple of weeks,

1 Like
11

Following up on this, we have submitted the full proposal here: Ideal Network: The Randomness Layer for Polkadot's World Computer | Polkassembly.

2 Likes
12

Sounds reasonable, and great if you can provide that pallet!

1 Like