Written by neepheid, cha0sg0d, yush_g, with thoughts by ludens Note: All of the thinking in this post has already been done many times in the past, including this blog post and this research conference. Our goal with this post is to strip away all the complexity of understanding eth2 and instead discuss the specific usecase of randomness in smart contracts. Introduction -- usecases for on-chain randomness Having an on-chain source of randomness enables of host of games, NFT mints, and financial mechanisms. Currently, most Dapp developers use a randomness oracle (like Chainlink) or some version of the hash of a previous block (blockhash). As discussed below, a blockhash can be easily manipulated by a malicious actor and there is overhead and cost involved with setting up Chainlink, as well as a trust assumption on their protocol Baked into the core Ethereum protocol is a "reasonably" (defined below) random value referred to as PREVRANDAO that is generated by the proposer of each block, accessible via the difficulty opcode. This post will share some background about how the PREVRANDAO value works and propose a use case for on-chain games that enables developers to access a better source of randomness than blockhash in just a few lines of code.

Inspired by Grimes' tweet, it would be useful for all artists to be able to license out the use of their voice in exchange for a gauranteed, say, 50-50 revenue split. Either the artist or the public can upload the video: The artist themselves has a submission portal. This portal verifies the track uses the same voice as the artist (using new audio track seperation techniques that are very good), takes the payout Ethereum address, and uploads the track to all platforms on behalf of a new official profile, named say, AI Grimes. The user making the track can opt to release the track themselves and credit AI Grimes as a co-author. This should lead to added legitimacy on streaming platforms -- we expect the additional streams and assosciation is worth the 50% cut to most users. The user still needs to provide their payout address, either in the description of the track or directly on the uploading website. If you want payments to happen on chain, there are two ways to do this: Manually. I assume this is the current way it's happening. This can be an overwhelming Automatically, by proving both the right voice was used and the amount of revenue derived.Proving the Voice: Any part (i.e. Grimes' website or the uploading user) can upload a zk voice key EZKL zk-ml proof, which basically outputs a number that represents who the singer is. If the voice is the same in both tracks, itll output the same hash. We'll probably have to tune this algorithm to work with all the ways music producers mash up voices (pitch up/downs, hi/low pass filters). Proving the Revenue: You publish a zk-email proof that you received an report from Spotify in which the track racked up X streams or that the track racked up Y revenue. You can use this proof to gate a payment function on chain that automatically releases the addional money to the uploading.