This article proposes the idea of an additional security layer that can be integrated into oracles such as Chainlink for smart contract use: random selection of node operators.
Security design of current Chainlink
Chainlink tries to solve a major problem in the field of encryption: the oracle machine problem. One of my favorite descriptions in the Chainlink white paper is the defense-in-depth approach of their team to develop protocols. The plan allows smart contract developers to adjust the following security variables, also known as "service level agreements (SLAs)," to suit their different contract situations:
- Number of node operators required for free choice
- Use on-chain verification contracts to determine high-quality nodes
- Use on-chain and off-chain reputation indicators to determine high-quality nodes
- Requires Trusted Execution Environment (TEE)
- Require node operators to hold a certain amount of mortgage assets
- Severity of punishment on malicious nodes' mortgage assets
- Amount awarded to well-behaved nodes
- How to aggregate node responses (this also controls the exact conditions on how nodes are rewarded or punished)
- Use Chainlink's own trusted and vetted node operator to resist witch attacks
- The choice of the underlying blockchain. Chainlink is a protocol that can be ported to the most secure smart contract blockchain.
So, for example. Let's say I'm a member of a development team that has a smart contract with trillions of dollars of liquidity. I can require 300 certified node operators with the highest scores on verification and reputation contracts / services, only those operators that run nodes in a trusted execution environment (TEE), and require each node to be mortgaged at least $ 1 million Link tokens punish all node operators that deviate from the average response by two standard deviations, and generously reward all node operators within two standard deviations.
- Zhu Jiaming's latest sharing: Understanding the evolution of blockchain paradigms from a futuristic perspective
- Viewpoints | From smart contracts to never-ending codes, how should Ethereum go towards compliance?
- Viewpoint | Is the exchange the only way out for the project?
- Chip giant AMD joins blockchain game alliance to empower blockchain gaming
- Monthly Report | Blockchain policy released in November, supervision and support
- Xiao Lei: Blockchain is "nuclear energy", bitcoin is "atomic bomb", who is the opponent?
Such behavior is highly secure. It may be too late, and the assumptions I mentioned above may not be realized. But this is the subtlety of the Chainlink protocol. It allows smart contract developers and the community to decide how much security is provided in a oracle for a particular smart contract. The security of smart contracts depends on its weakest link. Slinky, CEO of Chainlink, has stated that his goal is to make oracles as secure and decentralized as blockchains that run smart contracts. However, a key security feature to achieve this is missing in all of these defense layers: the choice of random node operators.
Random node operators and anti-collusion
Let's take a brief look at the consensus algorithm of Ethereum, which is the current blockchain running Chainlink. Ethereum currently runs on the PoW consensus algorithm, and there are plans to switch to PoS. In PoW, anyone can become a miner to create and verify blocks by setting mining nodes, joining the network, and finding the correct random number to mine the block.
Although this creates a permissionless network that anyone can participate in, it also creates a more collusion-resistant network. (Blue Fox Note: Anti-collusion is not easy to collude)
This collusion resistance comes from the fact that block producers are not selected by a central institution or person, but are randomly selected according to the proportion of hashing power they contribute. No entity can know for sure which node will propose the next block.
The proposed block is then checked by the entire network running the full node. The only way an attacker can initiate tampering with the blockchain through conspiracy is if the conspired group has a hash rate of more than 23%. If any substantial damage is to be caused, it is generally considered necessary to control more than 50% of the hash rate. Compare it with EOS's DPoS consensus algorithm. It selects a limited number of validators through community voting, that is, 21 representative nodes. It also suffers from possible corruption and conspiracy accusations.
my thoughts? As long as smart contract developers are choosing specific node operators, they cannot reach the same level of anti-collusion as the leading public chain. A group of known node operators is far easier to achieve collusion than node operators randomly selected from a pool. Even with a Trusted Execution Environment (TEE) like SGX, you actually need to add a trusted operator to the mix, such as Intel (Blue Fox Note: This means that in addition to trusting known node operators, In addition, we must trust the hardware manufacturers).
Here, I do not mean that Intel intentionally designs SGX with backdoors, nor does it mean that all contracts need to achieve Ethereum's underlying chain-level security, but some contracts do require this level of security. If we want to achieve this, Chainlink needs to add additional security based on secure random beacons on staking.
Solution: Ethereum 2.0 Beacon Chain + Staking
To mitigate the possible collusion of node operators in Chainlink, my suggestion is to allow smart contract developers to use secure random beacons to randomly select nodes from a pool of node operators that do not require permission. A truly secure random beacon is difficult to achieve in the blockchain, but fortunately, Ethereum has proposed to implement a secure universal random beacon, the Ethereum 2.0 beacon chain.
It is said that the beacon chain in Ethereum will produce unpredictable and unbiased randomness. It is based on the assumption that at least one validator is honest and there is no VDF ASIC hardware faster than commodity VDF ASIC hardware. Times the situation. In fact, you will see that my recommendation is essentially to use a system very similar to how Ethereum 2.0 Proof of Stake works.
Let us assume that there is a specific data stream with very high demand in many different smart contracts. For example, let us assume that one of the data streams is the ETH / USD price stream. Anyone can start a node for this data flow and join the network. However, instead of joining and waiting for a smart contract developer to choose you, you join a pool of node operators, and all nodes in this pool provide the same data flow to the smart contract.
Ethereum random beacons are triggered, and when it triggers, a new committee of the node operator is selected, and the size of the committee is determined by the SLA of the smart contract that requires the oracle service. (Blue Fox Note: SLA refers to service level agreement) Among them, the probability of a particular node being selected into the committee will be proportional to the proportion of Link tokens pledged in the pool. These nodes will provide the data flow, the data will be aggregated, and will be rewarded or punished according to the definition of the smart contract using the service.
This can be superimposed on all currently planned safety functions.
Perhaps a smart contract developer can influence the probability of a node being selected based on part of the reputation index on the chain; the higher the quality reputation, the more likely it is to be selected. Smart contracts can reward nodes that use SGX, or it can be used for current centralized authentication services where you know at least who are some of the larger nodes in the pool.
Of course, this requires a sufficiently large pool of node operators to fundamentally eliminate the threat of witch attacks beyond the certified nodes in the pool. In Ethereum, there are estimated to be tens of thousands of nodes, and it is easy to assume that most of these nodes are not controlled by a few operators pretending to be many.
I am not the first person to come up with this idea. There are several upcoming oracle networks that have also discovered that the node selection lacks randomness and have proposed their own solutions (usually they have their own PoW chain, and I have some ideas for this too. Reserved). Examples include Witnet and Tellor. There are other solutions, such as possible decentralized identity protocols. This is a very basic recommendation, far from detailed specifications and designs.
It is also possible to draw nutrition from the PoS design of Ethereum, such as during the lock-up or to impose greater penalties on nodes that are simultaneously offline. The purpose of this article is to attract more attention and hope that Chainlink and the community will take action. In the long run, we must minimize trust in third parties and minimize the threat of collusion in oracles.
Overall, I think Chainlink's current plans and developments are outstanding. The use of authentication services to resist witch attacks, combined with all the security methods mentioned above, gives it the strongest defense attributes over most other competing oracle solutions. These methods also have the added benefit of quickly booting out of the network, and may have better security in the short to medium term if there are not enough node operators.
However, in the long run, if we really want to develop the most decentralized oracle solution, if we want to achieve the same level of security and trustlessness as possible with leading public chains such as Ethereum, then One cannot simply believe that the selected group of node operators will not collude. Obtaining randomness may be the last feature that Chainlink needs to ensure its own security in the future.
Risk warning: All articles of Blue Fox Note can not be used as investment advice or recommendations. Investment is risky. Investment should consider personal risk tolerance. It is recommended to conduct in-depth inspection of the project and make good investment decisions.