The Importance and Evolution of Oracles and On-chain Verifiable Randomness

– Hi everyone. So today we're gonna be
speaking about Oracles and their significance as well as how we can overcome the limitations created by Smart Contracts using Oracles and the effect that that can have, the positive effect that that
can have on our industry. The first thing I think
it's useful to understand is the problem we're dealing with, the fundamental problem here is that Smart Contracts and Blockchains can't connect to external systems. This means that the
security model they have limits them while providing
all those great guarantees we care about in terms
of their transparency, reliability, and high amount of trust. This limitation basically
means that we can't access important pieces of data such as market events and other events that we would want to
write a contract about. This limitation, in my opinion, is what keeps our space in token land. So tokenization is the core use case of Blockchains right now, and then the trading of tokens
and the movement of tokens, and sometimes the voting
either with tokens or on certain things
related to the tokens.

Now that that's not an issue,
it's a very good thing. And I think it's seeded our, our ecosystem with a lot of
value that people can then use to use DeFi products and
do other great things. But I think our ecosystem really has and our technology has a lot more to do, and it can go beyond tokenization to do something truly, more valuable. I think what it would do is it would actually grow
the entire pie such that there would actually be
more need for tokenization, but you would have contracts, you know, from the derivatives industry, the insurance industry, the trade finance industry
being put on a Blockchain and being run much more effectively there and leading those industries
to eventually migrate all of their contracts onto the Smart Contract infrastructure that we're all building. This is really the future
that I think a lot of folks and the people, folks in our
space are working towards. This is the type of
shift I've seen before. I've seen this shift twice now. You went from programmable
money using Bitcoin Multi-sig as it's only a feature addition to moving the Bitcoin around
to these protocol contracts, where the contract was
in the protocol itself.

Then you went to a world where you could write the contracts. This is what Ethereum is very credited, very well respected for. The truth is they moved the space into an entirely new
version of what it could do. The limitation is that
what it can do right now is really generate primarily tokens and a few other Smart Contract
things related to tokens. And there's another shift
that we really wanna make towards all these real world contracts based on market events, based on insurance events
and all those events. I think that DeFi is really what this is. It's an initial beginning
of this trajectory where you have people like Synthetix, AAVE, bZx, Nexus Mutual, creating decentralized
financial derivatives, lending, various insurance products.

These products are getting attention because they're superior in certain forms, but I think there's
much, much farther to go. I think the limitations
we need to overcome is we need to first understand that all of these contracts I just showed you are actually built using external systems. So they all need market prices. They all need some kind of
data to prove that the contract should go to the next state. And this is the body of
work that we're involved in. We're involved in how do
you take Smart Contracts beyond tokenization and into a world where they can interact
with any external system, whether that's an enterprise system, a piece of data or a payment system. And that evolution is very
important because it'll, I think come to redefine our space. Now we basically focus
on a multitude of systems and a multitude of chains, and I'm gonna quickly run
through some of the key points of how we approach this problem and how we seek to solve it.

So at the core of our
approach is decentralization and the ability to have multiple
independent nodes computing and validating data so it
meets the high standards of a Smart Contract. The nodes that are validating
that data in our case are of very high quality and we have systems that
assure their quality and that actually float
information about their quality. So the more high quality a node is, the more transactions and usage it gets. We focus on high quality data and only generating the type of data that is of a sufficiently high validation to trigger a Smart Contract. And as well as crypto economic security, where we basically use
something called Staking to provide certain amount of guarantees around whether data is
delivered correctly. We then apply other security approaches with a defense in-depth
kind of approach to security that includes trusted
execution environment, zero knowledge proofs,
and other approaches. We do all of this with a absolutely amazing
open source community of node operators, developers,
researchers, and auditors that work with us
diligently to make sure that all the right inputs are
included in the system and that everything is maintained
at a highly secure level.

And then we seek to provide
all of these inputs and outputs to all the Blockchains out there so that a developer can
build Smart Contracts in whatever environment they
think is optimal for them. There are certain environments optimal for one type of contract, others for other types of contracts. Generally speaking, the
first category of problems we set out to solve and at
this point at a technical level seem to have done a good job at solving, is the avoidance of a centralized Oracle. So you don't wanna rely
on thousands of nodes for a computation and
then have a single node that is a point of failure, kind of breaks the whole
model, breaks the whole system. All you have to do is
attack that single node, and no matter how well
written your contract is, it can all fail.

So you basically first, they need to get away from centralization, which we do through decentralization and having multiple
independent node operators that compute devalidation of data to put it into various chains and allow it to be used by contracts. We actually seek to
guarantee that this data gets delivered correctly in our system. So we don't just decentralize
and validate multiple pieces of data to guarantee that
the input into a contract is at a sufficiently high level. We actually require a more, will soon require Smart
Contracts to make sure that they both are using a good data source and that the Oracle operator, the Chainlink node that's
giving the data to them commits to certain conditions.

And those conditions
are related to payment and related to reliability. This is partly the replication scheme, a replication of what service agreements seek to do in the real world. And to contrast this with
other Oracle solutions, some of them can't access paid API so they have no guarantees
of high quality data. And if they don't have service agreements or a capability like
that on their roadmap, then it's not likely
they'll be able to provide that same high level of guarantee once the data is supposed
to be transported. We also apply crypto-economic security to this dynamic, once again,
through the service agreement, which defines the conditions
under which people are both paid and the conditions under which they could end
up losing their deposit or stake as a node operator.

This provides an additional
level of assurance that the data delivered to a contract is going to be delivered correctly and that it's something
that the contract users and developers can actually
rely on the Chainlink network, the Chainlink nodes in a
specific Oracle network to deliver data of a certain quality from ideally premium APIs
'cause they have the ability to interact with premium APIs and already do on a regular basis. Once we've decentralized
the Oracle mechanism, we can reliably begin to
decentralize the data level. At that level, we have two models. One model is where data providers actually run a Chainlink node. That gives them built-in signing and the ability to sign transactions into multiple Blockchains with pretty much almost
no development effort, retaining their current infrastructure and methods of generating data and their entire API infrastructure. Then we have node operators
that query data providers that are not yet at the level
where they want to run a node. So there's a certain
flexibility in being able to include the data providers
that wanna assure their data at a higher level of security by running a node of their own.

But then you also want flexibility in that you can include data providers that don't yet wanna run a node, but they do see a reason to provide data to various Blockchains. In fact, every additional
Blockchain that we add support for expands the universe that
data providers can sell to. And that creates a virtuous cycle where a larger universe of users encourages better and
better data providers. Better and better data providers and better, better inputs generally generate better
and better applications, which creates a virtuous cycle where more and better applications create substantial
justification for data providers to then say, yes I do want to
provide data into this system. A lot of this is available today. You as a Smart Contract developer
can go to you can attain very
well-validated data feeds for multiple aggregators that are input by extremely high quality node operators at a certain frequency and at a certain level of data quality. So far, we've already seen this jumpstart certain launches of decentralized
applications in DeFi and allowed existing applications to either become more secure or very quickly launch additional markets because they don't have to create decentralized infrastructure.

They just use decentralized infrastructure that gives them all the inputs they need for that second half of the contract that isn't the core contract itself, but is all those systems that
they need to interact with. In the case of DeFi, one of those main things is price feeds. That's something that at this point, we've done a relatively good job at providing at a high level
of quality and security to DeFi applications, such that we've even now had
a few people launch with us without having to build an entire decentralized infrastructure. Now price feeds are not the only input that's important for the
growth of Smart Contracts and their use and
Blockchain-based applications. So I'm very excited to announce today that we're introducing
something called Chainlink VRF. Chainlink VRF is something that we've been working on for awhile with some of our academic partners and some of the most talented people in the Blockchain space to
generate a source of randomness as a key input that is also verifiable. There are a number of
applications that use randomness in very meaningful ways to
be able to securely exist.

It's one of those inputs
that pulling that input from some other off chain
source is sometimes problematic 'cause it's not necessarily
built for a Blockchain or using all the
capabilities of a Blockchain to provide security to
the application developer and the user. And so we're very excited to
today be releasing the initial, Testnet version of our Chainlink VRF, and to showcase what some of the things that it can make possible. As always, I think it's useful
to understand the problem we seek to solve in this context. And that problem will begin
to inform our discussion about how are we solving it
and what are the benefits of making this input the way that we are. I think the first thing
to do is to look at what is the use case for randomness. A very common use case
is Blockchain gaming. So after DeFi, Blockchain gaming is probably the largest use
case for Blockchains right now. Blockchain gaming
basically depends on users going to a Smart Contract that guarantees that a user will be fairly treated and whatever manipulation
happens in a centralized version of that same game can't
occur with the user.

So for example, the
creator of the contract, can't manipulate money away from users that deserve to get it according to the contract's conditions, or if there's some kind of digital good generated by the contract, the contract creator can't
simply take it away from a user. The guarantees of Blockchain gaming are very well-suited for users that want to interact with the contract that needs to assure the
user that they won't, for lack of a better
word begame themselves. So they won't have funds stolen from them. Now, some of the most common, or maybe even the most
common design pattern Blockchain gaming is
the use of randomness. So randomness often generates payouts to users in cryptocurrency, which they previously deposited or it generates digital goods or any other number of events that basically Blockchain games rely on.

Even in the initial version
of Blockchain gaming, you can see that it
essentially the contract, much like DeFi contracts
consists of two parts. It consists of the contract
and the conditions of the game and then it often consists of an input, which is the majority
of the time randomness. Now the design patterns that
we see in gaming so far, Blockchain gaming so far, sometimes don't deliver
on the full potential and end to end security
that DeFi is now seeking to deliver to its users through the use of highly reliable Oracles. One of the dynamics that I
think it's worth mentioning that in certain scenarios, the creator of the Blockchain game also runs the random
number generation service.

So on the one hand, the Smart Contract and the
conditions of the game, and possibly the
ownership of digital goods is on a Blockchain and
therefore not gamable, but the random number
generation that determines the amount or the value
or the relationship between that contract and the user and the cryptocurrency
they put into that contract is controlled by the game's creator. Now this leads to not the certainty, but the unfortunate possibility
that there is a chance that the game's creator could
have the same problems either by having his service
compromised by an adversary or by compromising it themselves or whatever collection of
problems that might occur. You are once again
sitting relatively close to centralized games where
one of the key inputs is still in the control of the operator.

And this is the core issue
that providing a verifiable source of randomness that can't be gamed and that is outside the control
of any interested party, such as a player, or even the creator of the game provides an additional set
of guarantees to users. Now, one of the ways that people sometimes seek to solve this, and we're just gonna go through
a few possible solutions to see how some of them don't necessarily achieve the outcome we want is they occasionally seek to use an external, random number generator
and put it on chain through an Oracle.

This is an approach that we've seen and some folks have taken. The limitation for a
decentralized Oracle system, in this context is that
a random number generator fundamentally needs to
create random numbers. So the various Oracles that would query it wouldn't get the same result. Sometimes people find
themselves using a random number generation service, and some kind of Oracle mechanism possibly made by somebody else. This unfortunately also doesn't provide the necessary level of guarantees because now they're exposed
to any kind of adversaries that gain access to the
random number generator. And in the case of cryptocurrency, it's quite attractive to
them because of the immutable nature of taking cryptocurrency that doesn't belong to somebody.

It's much tougher to
get that away from them. An adversary that compromises off-chain random number generator may, would be able to get the
cryptocurrency that's not theirs from a contract and essentially
steal it from users. Likewise, there's some
additional surface area that's created by passing
it through an Oracle, having a decentralized Oracle that going to a random number generator without any additional capabilities
like Chainlink VRF has, is a difficult and limiting proposition. It sometimes it could have
been increased surface area. Likewise, some people
seek to use the properties and the data already on chain or the data generated by
a Blockchain to generate the randomness they need. That also creates limitations where miners could sensor
the outputs of a chain such that Smart Contracts could have something stolen from them
essentially by miners.

Conversely, a Chainlink VRF is something that provides verifiable randomness. So what that means is that a Chainlink, even
a single Chainlink node providing verifiable
randomness, cannot be malicious. It receives a seed from the contract. The only thing that a
Chainlink VRF node can do is not respond. If it responds the signature and the proof that it responds with based on the seed that was
given to it by the contract, cannot be biased, cannot be gamed by the Chainlink node operator. And as long as the Smart Contract is built with the proper ordering
for the use of randomness, you now have a source of on
chain verifiable randomness that is something that users can rely on and Smart Contract developers can rely on.

Likewise, users can also provide seeds. So if someone is concerned
that a Smart Contract generator user or developer themselves
is providing the seed, then users can take part
in the providing of a seed by helping generate it and
even using multiple seeds. This essentially means that you have a source of randomness that's completely proven to, cryptographically proven to be unbiased. And as long as it's provided, it can be relied upon to
properly settle transactions and generate digital goods and do everything that randomness needs to do on chain. The benefit of Chainlink VRF is that it's built to use the unique
capabilities of Blockchains to verify that proof and
verify those signatures, which is something that
as far as we can tell no other randomness generator does. The point here is that even
a single Chainlink node is enough to provide these guarantees. And it once again, can't be malicious. All it can really do is
not provide an answer.

To improve the those
availability guarantees, we then seek to create a
system where we have more nodes and where we have multiple Chainlink nodes providing that randomness. And as that mound of
Chainlink nodes grows, you have a greater and
greater amount of randomness kind of availability. So the chances that anyone doesn't respond doesn't really affect the liveness. But once again, the key property
of verifiable randomness is already achieved. Even if only one of those
nodes provides it correctly. Threshold signatures and are you, application of threshold signatures to create threshold VRF is something that'll really help here. That's something we're
working on very heavily at the moment. And we know that it's
applicable to VRF as well to basically scale up so that thousands of nodes
are providing availability.

Even if only a portion of the nodes actually need to provide randomness or agree on, or basically
send some kind of randomness into the contract. In addition to the use of Smart Contracts, in addition to the use of
these verifiable randomness signatures and proofs,
we also use Staking. We will use Staking to basically prove or help prove that there will
be a loss for a node operator that doesn't generate
the proper randomness. In addition to the fact that
even a single note providing this proof is providing
ungamable, unbiased randomness, they will also have very
strong incentives to provide, provide this randomness consistently. The greater the fees that
users pay for the randomness. It's likely that the
greater the amount of stake that node operators put up to guarantee their availability is something
that would also increase. So basically service agreements
and the use of Staking is also applied to Chainlink VRF to provide additional guarantees beyond the cryptographic guarantees, the availability guarantees, and now the crypto-economic guarantees.

This is available today. You can go on our documentation and use it on Testnet today. We're still in the final
stages of security review, and we seek feedback and any ideas about how this can be improved or how it can be properly used to, or how it can be properly
improved to make sense, to make sure that it applies
to all the relevant use cases. One example, one exciting
example of the use cases that could benefit from
this is PoolTogether.

We're very lucky to be working with them as one of the initial
users of Chainlink VRF. PoolTogether is a no-loss savings game where it encourages people to
save by generating interest that then goes to a single winner. In their case, they'll
be using Chainlink VRF as one of its initial users. We're very excited to be working with them and to be able to provide to them a verifiable source of randomness that genuinely gives them
and their users assurances that their system is properly
making payouts to their users.

The idea is that these assurances should increase the amount of users that use Blockchain games in general, and applications like PoolTogether. Once again, making Smart
Contracts and Blockchains about something more than tokens. There are tokens obviously involved here, but the point is that Blockchain gaming with the help of a good
randomness mechanism can evolve and can grow
much faster in our opinion, This is just one of the many inputs that we're working on providing. It's one of the more exciting ones, 'cause it touches so many
Blockchain gaming startups and companies that we've
already talked with. And we know that highly
verifiable randomness is an extremely important part of how they seek to
present themselves to users and how they seek to
provide their guarantees. And we plan to continue
providing a multitude of different inputs and outputs
into various Blockchains that can benefit from things
like verifiable randomness, data and payment systems and all these other inputs and outputs.

If this is something
that's of interest to you as a developer or as somebody
who would like to collaborate and build Oracles together with us, it's a definite fact that we're
looking for extremely smart, hardworking, and globally
distributed people , that are interested in
solving this problem. We're adding members to our core team now, and we have a number of other
great inputs and outputs and innovations that we're working on, both from the security point of view, the basic, cryptographic primitive research point of view, and even just from the software
development point of view. If you're interested in these problems and you see value in helping solve them like we do, we're growing our team and we'd be very excited to speak with you about helping take Smart Contracts into the next stage of their evolution. Thank you. Hello. – Hello, Hey. – Hi Bobby. How are you? – All right, so hi everyone.

My name is Bobby. I'm the
co-founder of CoinGecko. I'll be the host for the Q and A session of Foundations – Consensus:Distributed. For those of you who are not aware of what we do at CoinGecko we are the largest independent
crypto data aggregator. We've been operational since 2014, and we track over 7,000
tokens from 400 exchanges. Every quarter we publish a
crypto report of API that is used by a hundred or so top crypto projects. I've got a few questions
prepared for you today, Sergey, so let's jump right straight into it. – [Sergey] Great. – Congrats on the launching VRF, I'm gonna ask about the VRF. What's the significance of placing trustless randomness on chain? How does Chainlink approach
placing randomness on chain? – So I think the significance is, is really that there's an
entire category of applications in in our ecosystem under the
heading of Blockchain gaming.

And it's the second largest
category, I think after DeFi. And in certain cases, if you
look at transaction volumes or the amount of transactions,
if not the overall value, then you might even consider
them the largest category. And one of the, or the
most important input that this category of applications needs in the form of a highly
reliable verifiable provably fair randomness is something that application development
teams are struggling to build. And in my experience, when
application development teams spend their time building infrastructure, it limits them and the use
of their limited resources to build the best application they can. And the best most successful
DeFi developing teams that we work with, they're thrilled to have an Oracle mechanism
that takes a certain problem off of their plate and
allows them to redistribute those technical resources towards building a better user experience or application or launching more markets.

I think the significance is that if there's a piece of infrastructure that suddenly gives Blockchain
gaming developers back 20, 30, 40, or more percent of their time, because they don't have to
build that infrastructure. It also provides superior
guarantees to their users and to other users that
would compare their system to a centralized gaming
platform of some kind. Then it allows those teams to
build something much better, expand what they've built, and it also allows the
users that they have to grow just by virtue of being able to provide the security guarantees that Smart Contracts seek to provide. Because Smart Contracts, I think, are only as attractive as
the guarantees they provide. If the guarantees they provide require verifiable randomness, which I think in many cases
in the Blockchain gaming space they do, then we hope that
that can be a catalyst for that part of our space to grow and to grow that collective
pie that I showed before. Blockchain gaming, I think is
a substantial part of that. – Nice answer. You guys have any plans to have Chainlink added on other Blockchains
in the near future. I know you guys recently
launched on Tezos, but what's the plans
for other Blockchains? – Yeah, we have an internal
framework right now that we use to add more Blockchains.

We, at some point plan to open that and to create some amount of
incentives for Blockchains to integrate with Chainlink and for people to build
those integrations, even in our community. We are speeding up the amount of Blockchains
we're integrating. It's delicate and complicated procedure. We're very lucky to work
with the core developers of many of these chains. But I think as the amount of inputs that Chainlink provides access to like VRF, like price data, weather data for insurance,
any number of other inputs, as well as outputs, I think the value of integrating Chainlink into various chains will also increase.

And therefore there will be more reason for the core developers of those chains to also see value in integrating Chainlink and to work closely with us. Right now I think the amount
of change we're in the process of integrating or working on integrating is in the double digits and it's gonna be, I think it's gonna be at a faster pace as we iron out and systematize and eventually find a way
to allow the community and the respective communities
of each Blockchain to, with a greater and greater
degree of efficiency, integrate Chainlink into their chain. And then likewise, all the
fees from each respective chain then contribute to the pool of fees, financing the security of any one resource like Chainlink VRF, such that more fees
would generally suggest that people would be
willing to put up more stake to increase the guarantees, right? So more usership would generate more fees, which would generate more stake, which would generate more security for that specific input. And likewise with many
of the other inputs. So I think that's
actually a virtuous cycle where as you go to more chains
and as you get more users, the resources of those users goes towards providing
either additional nodes or additional reasons for
people to put up more stake or additional or better data providers.

You know I'm very glad
that CoinGecko is one of, one of the data providers
that we work with. We're very happy about that. And that's kind of, I think, how that evolution looks in general terms. – What's the importance
of data quality in DeFi? How does Chainlink provide
this high quality data? – Well, Bobby, I think
you know the importance of data quality in DeFi at
a very high level I think. I think people unfortunately
assume that data aggregation and the methodologies related
to providing an accurate price that covers all the exchanges
that people want to cover and eliminates various categories of risks is some kind of either they
don't know about that problem, which to me suggests a
serious, a serious issue. Let me put it that way . Ignoring the data quality problem is a serious issue, which I don't think that the centralized systems
or hedge fund traders that use your system would do because they are in such dynamic markets that they would experience
a loss very quickly. I think that the nuance is that data quality is at this point
slightly under-appreciated.

And people believe that they can maybe just make a data aggregation service by pulling from four or five exchanges, which I think even given your experience, you know that that is just riddled with multiple failures that you know
of from your own experience. – Yup, all kinds of outlier issues, API going down from major exchanges, bad data coming out from all
these different exchanges. So all kind of things. Maybe we have time for one last question before we wrap this up, this Q and A. So I'm gonna ask this question. Chainlink has been quite
focused on crypto pricing data, but Chainlink is actually built to support all kinds of data. How has development of other
forms of data been so far? What sort of data besides
crypto data is showing interest in growth in a Chainlink ecosystem? – I think the categories
that I see growing, as you said, DeFi, I think we're excited
to see Blockchain gaming get a high quality input
and start really, really, hopefully growing more
and more and expanding because of the reasons
I mentioned earlier, more technical bandwidth and
better guarantees to users.

I think another one is insurance. So insurance is something
that moves generally slowly in the world in general. But I think that insurance products are really on a next level in the Blockchain ecosystem because they provide so much
trust guarantees to people that are not provided by
traditional insurance. I think it's just taking time for some of it to migrate, but generally speaking you're right, that Chainlink is really
a general purpose, decentralized Oracle kind
of a network and framework that is initially being
applied to price data for DeFi 'cause that's a fast growing space. I would even like to think we can accelerate how fast it grows with the appearance of
high quality Oracles and more data points with the help of great data
aggregators like yours.

And then after that, I think gaming. After that, if I had to
guess, I would say insurance. Those would be the three categories, which Chainlink is
completely set up to support. In insurance's case, I don't think it'll be
referenced contracts because insurance has
very specific requirements about a specific single piece of data related to a specific policy. And that's where
something like or other systems where you
can define very clearly about a single input that you need, but maybe other people don't need. That's what we internally
call the direct model. So right now we're doing very well on the reference data model where we're able to provide
high quality price data to the DeFi contracts that wanna be triggered off of that. Randomness is its own
entire set of problems.

And then the direct model is probably gonna come from insurance, where I wanna make a direct relationship with some IoT sensors, and
nobody else wants that data. And that's something
we've already discussed with a number of people. There's things that are slowly
moving towards production using that direct model. But once again, it's an
industry that moves slower. – Cool, very, very
interesting applications. Again, that's all the time that we have for Q and A for today.

I'd like to thank Sergey for taking the time to present to us and answering the questions that we have prepared for today. So I hand it back and
move on to the next step, next day show of Foundation. – Great. Thank you very much, Bobby. Good chatting with you again. Thank you..

You May Also Like