Chainlink and Randomness: A Needed Security Layer

Zak Ayesh
Zak Ayesh
Nov 15, 2019 · 8 min read
Image Source:

*Update 08/16/20: As this article has gotten a fair amount of attention I would like to update it with some new information. One is I have become an official Chainlink Advocate since 11/2019. Also Sergey has addressed why this type of design (dubbed “Security by Obscurity”) is not ideal for the blockchain oracle problem which can be seen in this talk (specifically around 18:00). I agree with him and not just because I am now an advocate, and felt it was important to disclose everything. Also Chainlink has released their own VRF which can be used to securely generate randomness on-chain. I think there are still interesting ideas in this article so i’ll keep it up, don’t stop learning!

In this article, I will present an idea for an additional security layer that I hope can be integrated into Chainlink for smart contracts to take advantage of: random node operator selection. I assume some background knowledge of Ethereum, Chainlink, crypto-economics, and consensus algorithms.

Current Chainlink Security Design

With the release of the first iteration of the protocol earlier this year, and the subsequent rise of Chainlink as the dominant oracle network, it has since been an exciting time for me and everyone involved in the ecosystem. One of my favorite things about the Chainlink whitepaper was the team’s defense in depth approach to developing the protocol. The plan was to allow a smart contract developer the ability to adjust the following security variables, in what is called a Service Level Agreement (SLA) to suit their unique contract conditions:

  • Selection of as many node operators they desire.
  • Use of on-chain validation contracts to decide on high quality nodes.
  • Use of on-chain and off-chain reputation metrics to decide on high quality nodes.
  • Require use of Trusted Execution Environments (TEEs).
  • Require a certain amount of collateral be held by node operators.
  • The severity of penalties on the collateral of misbehaving nodes.
  • The amount of payment awarded to well behaved nodes.
  • How node responses will be aggregated (this also controls the exact conditions of how nodes are rewarded and punished).
  • Use of Chainlink’s own trusted and vetted node operators for Sybil resistance.
  • Choice of base layer blockchain. Chainlink is a protocol that can be ported to whatever the most secure smart contract blockchain is at any given time.

So, for example say I am part of a future development team that has a smart contract with trillions of dollars flowing through it. I can require 300 certified node operators with the highest scores on validation and reputation contracts/services, select only node operators which run their node in a TEE, require each node to have at least $1,000,000 of Link token as collateral, punish all node operators greater than two standard deviations away from the average response, and handsomely reward all node operators within two standard deviations of the average.

That’s a lot of security! It may be overkill (and perhaps impossible to fulfill in my example), but that’s the elegance of the Chainlink protocol; it allows smart contract developers, and thus communities, to decide on how much security is needed in the oracles for any given smart contract. Smart contracts are only as strong as their weakest link (pun intended) and Sergey, Chainlink’s CEO, has stated in the past that his goal is to allow oracles to be just as secure and decentralized as the blockchains that smart contracts run on. But one key security feature is missing in all of these defense layers to achieve that goal: random node operator selection.

Random Node Operators and Collusion Resistance

Blocks are then checked by the entire network running full nodes and the only way an attacker can begin to alter the blockchain through collusion is if the colluding group has over 23% of the hash rate (see selfish mining). For any substantial damage to occur it is commonly agreed that over 50% of the hash rate must be controlled. Compare this to EOS’s DPoS consensus, which limits validators to a community voted and known 21 delegate nodes, and the resulting accusations of corruption and collusion that have been thrown at that blockchain.

My point? As long as smart contract developers are picking specific node operators, they cannot achieve the same level of collusion resistance as leading public blockchains. It is much easier to collude within a set of known node operators rather than in a pool of randomly selected operators. Even with a TEE like SGX, you’re essentially adding one more trusted operator into the mix (Intel in this example). I’m not saying Intel will definitively design SGX with back-doors purposefully or all contracts will need the same level of security as the Ethereum base layer, but some will. If we want to accomplish that goal, Chainlink needs to add another layer of security; a secure randomness beacon on top of staking.

Solution: Ethereum 2.0 Beacon Chain+Staking

Lets say there are certain data feeds that are eventually in high demand across many different smart contracts, for example, let’s say one of those data feeds ends up being the ETH/USD feed. Anybody can start up a node for this data feed and join the network. But instead of joining and waiting for a smart contract owner to select you, you join a pool of node operators also feeding the same data to contracts.

The Ethereum randomness beacon fires off, and when it does, a new committee of node operators is selected, whose size is determined by the consuming smart contract’s SLA. The probability of a particular node being included in this committee would be proportional to the amount of Link it has staked over the total amount of Link staked into that pool. From there the nodes will feed in data, have that data aggregated, and be rewarded or punished as defined by the consuming smart contract.

This can stack on top of all the currently planned security features. Perhaps a smart contract developer could affect the probability of a node being selected partially based on its on-chain reputation metrics; higher quality reputation results in a higher probability of a node being selected. A smart contract could give bonuses to nodes that are using SGX or this could be used with the current centralized certification service, in which you at least know who some of the bigger nodes in the pool are.

Of course, this requires a large enough pool of node operators to essentially negate the threat of Sybil attacks outside of the certified nodes in the pool. In Ethereum, there are an estimated tens of thousands of nodes, which makes it easy to assume most of these nodes are not controlled by only a couple of operators pretending to be more (among other defenses coming in ETH 2.0). But if Chainlink becomes as big as I, and many others, expect it to; then it’s not inconceivable to think there could be very large pools of node operators joining to take advantage of the demand for certain data feeds.


Overall, I think Chainlink’s current plans and development are excellent. Using the certification service for Sybil resistance combined with all the other security methods outlined above gives it some of the strongest defense properties out of many of the other competing oracle solutions coming into the fray. These also have the added benefit of quickly bootstrapping the network and possibly having better security in the short to medium term while there aren’t many node operators. However, if we truly want to develop the most decentralized oracle solution in the long run, one that allows security and trustlessness as close to the same level as leading public blockchains such as Ethereum, we must not simply trust that a select group of node operators aren’t colluding. Access to randomness may be the last feature that Chainlink needs to secure itself as the leading oracle network far into the future.

The good news; with a development team that has proved more than competent, a truly passionate community, all the original security features being added, and the needed randomness infrastructure being laid out, I don’t doubt Chainlink will be able to adapt and adopt.

Further Reading

The Startup

Get smarter at building your thing. Join The Startup’s +794K followers.

Sign up for Top 10 Stories

By The Startup

Get smarter at building your thing. Subscribe to receive The Startup's top 10 most read stories — delivered straight into your inbox, once a week. Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Zak Ayesh

Written by

Zak Ayesh

Engineer, Chainlink community advocate and blockchain enthusiast. Lover of traveling, piano, and doggos.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +794K followers.

Zak Ayesh

Written by

Zak Ayesh

Engineer, Chainlink community advocate and blockchain enthusiast. Lover of traveling, piano, and doggos.

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +794K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store