1/ #Chainlink VRF v2 is now live on mainnet, serving as an upgrade for the ecosystem’s most widely adopted verifiable randomness solution
The result? Five significant improvements in cost-efficiency and configurability
Let’s break it down 🧵👇
2/ For context, Chainlink Verifiable Random Function (VRF) is a secure random number generator (RNG) purpose-built for smart contract applications
Each RNG value is backed by a cryptographic proof that is verified on-chain, preventing manipulation from oracles, users, and miners
3/ Since its release, Chainlink VRF v1 has fulfilled over 3M requests for randomness and now serves over 2,300 smart contracts across multiple blockchains
VRF v2 introduces a subscription management contract that allows smart contracts to pre-fund multiple requests using a single $LINK balance, rather than transferring $LINK each time
This reduces the gas costs of VRF requests by up to 60% 🤯
5/ Furthermore, with this new subscription contract, VRF requests are no longer priced in static amounts of $LINK
Rather, the amount of $LINK paid scales depending on the gas costs of the fulfillment transaction plus a static fee on-top (similar to the Keepers billing model)
7/ Variable Callback Gas Limit:
Users can now adjust how much gas is spent when a VRF response is delivered, allowing for more complex logic in the same transaction as the RNG value is received
Critical tasks using RNG can be completed right away, even during network congestion
8/ This parameter can now be set to a maximum of 2M gas on Ethereum, which is 10x higher than the previous limit!
This functionality is made possible by the subscription contract offering dynamic pricing based on gas consumed
This max parameter will vary by blockchain
9/ Custom Block Confirmations:
Users can can define how many block confirmations must pass since request before verifiable randomness is generated & delivered on-chain
This can range from a 3-block minimum to a 200-block maximum
In comparison v1 was fixed at 10 blocks on Eth
10/ Providing the ability to configure the block confirmation number allows users to strike their own balance between security (protection against chain re-orgs) and the latency of response
An improved Coordinator contract allows users to request multiple random numbers in a single request transaction
The fulfillment of all of the RNG values is also delivered in a single transaction back to the user contract
12/ By batching request and delivery of RNG into singular transactions, significant gas cost savings is achieved (slightly akin to OCR for price feeds)
This is particularly useful for high frequency applications on blockchains with higher gas fees
13/ Unified Billing:
VRF v2 enables multiple smart contracts (up to a max of 100) to fund their RNG requests from a single $LINK subscription contract balance managed by the developer
14/ This allows developers who manage many contracts that each need randomness to reduce gas costs and simplify fund management for more complex use cases and situations
Now easier than ever to use VRF across many different dApps offered by the same developers
15/ The above five improvements introduced by #Chainlink VRF v2 provides developers access to even cheaper and more flexible randomness
All while retaining the same security properties that make VRF so useful and versatile for dApps
"Fair election is important for DAOs. However, the most developed system, Quadratic Voting, is exposed to the Sybil attack. We developed Governor C which is Sybil resistant QV based on Chainlink-VRF." devpost.com/software/gover…
Oracle Data Feeds on zkRollups are a complete game changer economics wise
A Data Feed with hundreds of nodes posting thousands of updates per batch has the same L1 gas cost footprint as a price feed with 1 node posting 1 update per batch
How?
zkRollups like @dydxprotocol don't post the raw tx data on-chain, rather they post compressed state diffs (state differences from batch n and batch n+1)
A Data Feed is an on-chain reference contract with a variable that holds an aggregated value that's updated by oracles
So no matter how many oracle nodes or updates there are, there will only ever be at most 1 state diff per batch for a Data Feed, since updates always touch the same state variable
Signature verification and data aggregation is succinctly proven within the validity proof
1/ I want to give some perspective on the economics of #Chainlink services, both in their existing form today and how it will evolve into the future
This includes many nuances regarding user fees, cost-efficiency, network subsidies, economies of scale, and sustainability
🧵
2/ The ultimate long term goal is that all Chainlink services become self-sustaining through user paid fees
Many services already achieve this today, but how pricing is determined and the role of $LINK in terms of demand for these services is a common question
3/ I'll start with Chainlink Any API as it's the easiest to conceptualize
Any API enables smart contracts to fetch data from any off-chain data source via Chainlink nodes, which can be operated either by DevOps teams or the data providers themselves