*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
I am and have been a big fan of Chainlink since their ICO. It was one of the few ICOs in its time that was attempting to solve an important problem in the space; the oracle problem. Combining this goal with a stellar technical team, great collaborations, no hype marketing, a humble CEO, and a decentralized open source ethos, Chainlink was easy for me to get behind.
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
Let’s take a quick look at the consensus algorithm of Ethereum, the blockchain Chainlink currently runs on. Ethereum currently runs on a Proof-of-Work (PoW) consensus algorithm, with plans to switch to Proof-of-Stake (PoS). In PoW anyone can become a miner to create and validate blocks by setting up a mining node, joining the network, and hashing out blocks in search for the correct nonce. While this creates a permissionless network anyone can join, it also creates a more collusion resistant network. This collusion resistance comes from the fact that block producers are not selected by a central authority (or anyone) but rather randomly selected in proportion to how much hash power they contribute. No entity deterministically knows which node will propose the next block.
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
My proposal to help alleviate the node operator collusion problem in Chainlink is to allow smart contract developers to randomly select node operators from a permissionless pool of node operators using a secure randomness beacon. A truly secure randomness beacon is difficult to achieve in blockchain, but luckily Ethereum already has a proposal for a secure universal randomness beacon, the Ethereum 2.0 beacon chain. The beacon chain in Ethereum creates unpredictable and unbiasable randomness on the assumption at least one of the Ethereum validators is honest and there isnt VDF ASIC hardware faster than a large multiple of the speed of commodity VDF ASIC hardware. In fact you will see my proposal is essentially to use a system that is very similar to how Ethereum 2.0’s Proof of Stake works.
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.
Conclusion
I was not the first person to think of this idea, several other upcoming oracle networks have seen the lack of randomness in node selection and have come up with their own solutions (typically their own PoW chain, which I also have reservations about). Check out Witnet and Tellor as examples. There are other solutions as well, such as a possible decentralized identity protocol, if anyone ever figures that out. This is a very basic proposal and far from a fleshed spec or design. More could be taken from Ethereum’s PoS design, such as a lock in period or larger penalties for nodes going offline at the same time. Perhaps I will write a more detailed design in a forthcoming article. The purpose of this was more of a call to action to the Chainlink team and community; we must minimize both the amount of trust in third parties, and the threat of collusion in oracles in the long run.
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
https://vitalik.ca/general/2019/04/03/collusion.html
https://link.smartcontract.com/whitepaper
https://tellor.io/whitepaper/
https://witnet.io/witnet-whitepaper.pdf
