Community

ChainLink White Paper — Section 5 — ChainLink Security Services

Chainlink | 03.06| 396

I thought it’d be fun and informative to break up the whitepaper into easily-digestible chunks so that everyone can get a greater understanding of ChainLink and we can have a more focused discussion. Today, let’s look at a section of the white paper that isn’t commonly discussed in whole, Section 5, ChainLink Security Services. ChainLink Security Services encompasses 4 key security services: a validation system, a reputation system, a certification service, and a contract-upgrade service. The first three services provide guidance to users of the ChainLink system, and the last service is optional for users. We end the section with the LINK token usage.

First, the validation system actively monitors each node on the ChainLink network. Nodes will be rated within this system based on their availability and correctness. Availability is measured by the node’s ability to respond to messages specifically for the purpose of uptime statistics. This means that if your node goes offline for any reason, it will negatively affect its availability rating. However, instead of a constant network “ping” for each node, this uptime will be measured as nodes digitally sign their responses and send to other nodes (for off-chain aggregation). Correctness is measured by comparing the node’s responses to the responses provided by other nodes in a given assignment. So any deviation of the node’s response outside of what the average from all node responses returned for an assignment would negatively affect this rating. Availability and correctness of nodes will be visible on-chain, meaning node listing services will be able to display these statistics publicly about all nodes on the ChainLink network.

The reputation system will also contain on-chain history which can be publicly referenced with a listing service (and other smart contracts). This is probably the part of the Security Section that most of us are familiar with, as it defines the majority of the factors in which individual nodes are rated on (except for the two in the previous section). The reputation system keeps track of a node’s total number of assigned, completed, and accepted requests, the average time to respond, and the amount of penalty payments. The total number of assigned requests includes both the fulfilled and unfulfilled assignments (in case the node is still executing an assignment). The total number of completed requests includes all past requests and can be averaged with the assigned requests to make a completion rate for the node. The total number of accepted requests is the number of requests that have been accepted when comparing to the node’s peer responses. This can also be averaged with other metrics for an accuracy rate on the node. The average time to respond is calculated based on a node’s completed requests. And finally, the amount of penalty payments shows how much a node has locked into its assignment. The overall purpose of the reputation system is to provide incentive for nodes to product honest data in a timely manner so that they may be chosen more often.

The certification service is used to prevent nodes from cheating with their answers. One form of attack, freeloading, is discussed in other sections of the white paper, but the certification service is focused on different types of attacks, sybil and mirroring. A sybil attack is where an attacker would control multiple nodes in the ChainLink network, attempting to control enough so that their falsified answer would be accepted as the correct answer given to a smart contract. Mirroring could also be used by compromised nodes to obtain their data from one another, instead of querying a data source individually. The long-term plan against both attacks is to utilize trusted hardware (Intel SGX), but until then, the certification service will detect and help prevent these attacks by issuing endorsements of high-quality oracle providers. These endorsements would be based on the node’s rating within the validation system and would perform spot-checking of answers compared to other trusted nodes. The certification service also introduces the need for off-chain audits of nodes to ensure that they comply with security standards. Finally, the security service will perform reviews of answers after they have been given to the smart contract to ensure that the data has not been falsified.

The contract-upgrade service is an optional service that users of the ChainLink network can choose to utilize if they wish to have security updates applied to their smart contracts. If or when vulnerabilities are discovered, the contract-upgrade service would make a new smart contract based on the existing one, and migrate it along with its assignments to the upgraded contract. A flag (as an instruction of code) can be used to indicate use of the upgraded contract instead of the old one. All changes made by the contract-upgrade service would be visible on-chain and available for audit even before upgrading. Understanding that some users won’t feel comfortable with a single entity (ChainLink, in this case) controlling smart contract migration and forwarding, the power to utilize this service remains with the smart contract creator.

Finally, the LINK token usage is discussed at the end of the section. ChainLink uses the LINK token to pay node operators for retrieving and formatting data. Additional work via adapters can also be accomplished within the node’s software, including aggregation and other computation methods. A node’s uptime and other reputation-based metrics act as guarantees that the node will respond accordingly. The node operators set their own prices for data retrieval and computation to be paid in LINK tokens.

That’s it for the ChainLink Security Services section of the white paper. Everything here is summarized directly from the white paper, just hopefully in a way that makes it a little easier to understand. If you think this is a good idea to break down the sections like this, let me know and I’ll keep doing this. I don’t plan on going in any particular order (what fun would that be?) since much of the white paper can be read from any point as long as you have a general understanding of what ChainLink is doing.

Be sure to check out the white paper directly, here:


ChainLink White Paper — Section 5 — ChainLink Security Services was originally published in Chainlink on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comment 0

delete

Are you sure you want to delete this post?