generating random no.s on the blockchain has been tough as is. altho we do have good solns now with chainlink & drand - there's a bigger problem at hand 🙋‍♀️ randomness generated thru these external beacons is not fast or too expensive, making it much harder to build dapps with web2 📲 think about it - all these use cases for gaming, betting & socials w a slow UX purely bcoz of the delay in generating random no.s #⃣ the giga chads at @Aptos just like re-engineering everything came up w their own native Randomness module to solve for this heck there is a published research paper on this authored by @alinush @bennypinkas @XiangZhuolun @sourav1547 links down beloww⬇️ @Aptos decoupling of consensus & execution is what makes it possible - the network can first commit txn ordering & revealing randomness later smth which is not currently possible on other blockchains due to malicious validator intent of altering the block. enter current external VRFs/beacons but what if we can natively do on-chain ⛓️ alsooo external RNGs work on a commit-reveal scheme involving 2 txns so the randomness consumption is not actually Instant but is sent after a few blocks (usually a 30 sec period) reqd for off-chain computation ⌨️ how does this work❓ for randomness we need Unbiasability & Unpredictability 🪄 part 1: weighted distributed key generation: first validators get a share of an encrypted secret key based on their stake before epoch change. this shared secret key can only be reconstructed by 50% or more of the stake part 2: on new epoch the validators first decrypt this secret key share & then compute VUFs on block unbiasable msgs (round no. & epoch no.). the combined VUF output constitutes the final VUF this gives us Unpredictability since > 50% stake reqd & secret sharing thru DKG ensuring Unbiasability towards those w stake <50% a super simple ex of how to use this in your move contract ⏬