ACP-113: Provable Virtual Machine Randomness

[avalanche-foundation-admin]

Proposes a mechanism to generate verifiable, non-cryptographic random number seeds on the Avalanche platform. This method ensures uniformity while allowing developers to build more versatile applications.

https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/113-provable-randomness

[tactical-retreat]

By request, adding my use case here.

I previously posted this: ava-labs/subnet-evm#909

I also commented into this discussion: #112 (comment)

I'm basically looking for a faster replacement for Chainlink VRF for games that need on-chain randomness that cannot be disputed. Currently we provide users an option between Chainlink and an in-house, non-verifiable randomness implementation (for speed).

ACP-113 would allow us to get the speed of our current implementation without any of the 'trust me bro' inherent in our current implementation.

[Nuttymoon]

Chiming in to say that I have talked to at least 3 L1 teams who told me they were very interested in this. It would be a good reason to spin up a dedicated chain as reducing verifiable randomness costs significantly for projects.

So 100% in support of this ACP!

[genshimaro]

I’m GenshiMaro, one of the founders of PLYR L1. This is something we really need for our games! We’ve been eagerly waiting for this ACP to be included. We currently have 5 games in development that require a strong RNG. Let’s make it happen! We need this!

[iamcryptofennec]

Fennec from PLYR L1, Yes! this is what we are waiting for. We really need Provable Random onchain feature for our products (games).

[s2n-Gribbly]

I have seen a number of the proposed L1s through Retro9000 cite ACP-113 as something they are looking to include. It seems this would be a great addition to have ASAP.

[MadGraph]

This is absolutely essential for most of the L1s being built.
I believe this would be a game changer feature to finally be freed from third parties like Chainlink that are super expensive at scale

[HyperPatrick]

I believe this ACP would really benefit Avalanche as for now everyone is relying on Chainlink VRF that is :
a - Very Expensive
b - Very Slow

As builders we would have an edge compared to builders on L2's.

[meaghanfitzgerald]

Given the recent increase in interest, would love to know if you would be willing to use this vrf despite the known vulnerability, mentioned in a previous discussion:

despite this known vector of attack, would you use the VM randomness generated via ACP-113 in an on-chain implementation?

One potential attack vector involves collusion among multiple proposers to manipulate the random number selection. These attackers could strategically choose to propose or abstain from proposing blocks, effectively introducing a bias into the system. By working together, they could potentially increase their chances of generating a random number favorable to their goals.

However, the effectiveness of this attack is significantly limited for the following reasons:
- Limited options: While colluding attackers expand their potential random number choices, the overall pool remains immense (2^32 possibilities). This drastically reduces their ability to target a specific value.
- Protocol's countermeasure: The protocol automatically eliminates any bias introduced by previous proposals once an honest proposer submits their block.
- Detectability: Exploitation of this attack vector is readily identifiable. A successful attack necessitates coordinated collusion among multiple nodes to synchronize their proposer slots for a specific block height ( the proposer slot order are known in advance ). Subsequent to this alignment, a designated node constructs the block proposal. The network maintains a record of the proposer slot utilized for each block. A value of zero for the proposer slot unequivocally indicates the absence of an exploit. Increasing values correlate with a heightened risk of exploitation. It is important to note that non-zero slot numbers may also arise from transient network disturbances.

While this attack is theoretically possible, its practical impact is negligible due to the vast number of potential outcomes and the protocol's inherent safeguards.

@Nuttymoon @genshimaro @iamcryptofennec @s2n-Gribbly @MadGraph @HyperPatrick
cc: @tsachiherman

[dirtycajunrice]

We would love to use this on C-Chain despite the “vulnerability”. Atomic randomness is paramount to a speedy user experience. The multi-transaction-multi-block-wait options that exist from third parties today have an average interaction period of ~20s from request submission to randomness received. How can we get this ACP expedited?

[adamWIZ-crypto]

20 seconds is definitely too much, especially when it comes to games. Here, the user must have a good experience.

[newdawncrypto]

We could REALLY use ACP-113 getting adopted because for a true blockchain game like ours, having VRF ensures that players aren't waiting 10, 20, 30 or more seconds for complex in-game transactions and instead have a smoother and more seamless gaming experience.

Without VRF, true blockchain games are impossible on Avalanche. That's the simple truth. It will be a win-win adopting this.

[danmancs]

This functionality is critical to significant aspects of our project, without it, our ability to utilise c-chain for many of our planned transactional interactions is severely limited.

[travelslow1975]

Hopefully ACP-113 will still be integrated in the C-Chain. MMORPG games on the blockchain could actually become 'playable'. As Avalanche is known as gaming chain it's detrimental to implement, to attract players from outside blockchain space.

[meaghanfitzgerald]

Hi everyone,

First and foremost, I want to thank everyone who contributed to the discussion around ACP-113. The enthusiasm and thoughtful engagement from the community have been incredible, and it’s clear that there’s a strong desire to bring verifiable randomness into the Avalanche ecosystem. This is a challenging but exciting problem, and your input has been invaluable in shaping the conversation.

After careful consideration, ACP-113 has been marked stale. While the proposal sparked a lot of excitement and generated meaningful discussion, the security concerns outlined in the document ultimately outweigh the current utility of the proposed mechanism. Specifically, the requirements for safely utilizing the randomness—such as defining a security threshold, waiting for a sufficient number of blocks, and mitigating griefing attacks introduce complexities that make the construction difficult to implement securely at this time.

That said, this is not the end of the road for verifiable randomness on Avalanche! The work done here has laid a strong foundation for future exploration, and we remain highly motivated to introduce a robust and secure Verifiable Random Function (VRF) into the ecosystem. The challenges highlighted in ACP-113 have helped us better understand the problem space and will guide us as we explore alternative mechanisms.

If you have ideas or proposals for alternative approaches, please don’t hesitate to share them. The door is always open for collaboration, and we’re excited to see what the community comes up with next.

[newdawncrypto]

That is really disappointing @meaghanfitzgerald because without VRF, there is no "true" blockchain gaming on Avalanche possible. I believe it should be a greater priority than it seems to be for the Avalanche Foundation. "Future exploration" is no enough and is just code for "We're not going to do it,"

I need only direct you to what you shared in December:

"While this attack is theoretically possible, its practical impact is negligible due to the vast number of potential outcomes and the protocol's inherent safeguards."

Why, then, are you considering ACP-113 stale? Something doesn't make sense here. Not implementing VRF will categorically prevent an actual blockchain game from being possible on Avalanche.

[Ocma]

I’m not a cryptography or VRFs expert but on-chain randomness is a huge deal - especially for gaming, where players need quick, seamless results. Relying on external oracles like Chainlink can be slow and expensive, which can really hurt the user experience and overall adoption.

I believe that other chains like Algorand already offer built-in randomness, making them more attractive for developers who need fast and cost-effective solutions. If Avalanche doesn’t implement something similar, projects might start looking elsewhere.

Could an approach be to introduce ACP-113 as an optional precompile or gate it behind a protocol feature flag? This way only projects that explicitly choose to use it can access it, allowing for controlled adoption. It would let developers start using it in real-world scenarios while giving time to refine security measures before full-scale deployment...

Avalanche needs to keep a competitive edge by offering tools that devs truly need, and not having a built-in randomness solution could push some projects to other ecosystems. I really hope we can find a way

[Pyramid6-CU]

How can Avalanche continue advertising itself as the “gaming blockchain” when it currently doesn’t offer the VRF functionality critical to seamless gaming??

Developers on Avalanche request you relook and prioritize ACP-113 and provide us with a timeline for implementation on the best gaming network on the blockchain. Groundbreaking projects like @thecosmicuniverse are being held up and subpar without VRF.

At Avalanche, let’s lead the VRF effort and continue to be the blockchain of choice for gaming!

Cheers!

[gijoefym]

Must have! 100% please make it happen.

[gijoefym]

Must add! 100% please 🙏 add this feature.