Chainlink provides trustlessness by requesting the same data from multiple independent and competing oracles, and reaches a consensus from the responses. If the oracles are not independent and competing, they can collude to manipulate the result, which would degrade the trustlessness of the smart contract that relies on it.

Currently, it is not possible to determine who is operating an oracle. Then, a single individual can operate multiple oracles without anyone else’s knowledge. These oracles would neither be independent nor competing, which poses a risk to Chainlink’s trustlesness guarantees. Using these oracles to manipulate the outcome of a Chainlink request is called a Sybil attack.

A more subtle version of a Sybil attack is off-chain freeloading. Although Chainlink has a protection mechanism against on-chain freeloading (see the commit-reveal scheme in the Chainlink white paper), multiple nodes ran by a single individual can share API answers off the chain. By serving a request with two of their oracles, an attacker can halve their API call costs and be able to underbid the market while degrading the security of the aggregated answer.

In this article, we will be introducing Nodary, the first oracle certification service for node operators to prove that their oracle cannot be used for Sybil attacks to an arbitrary level of certainty.

Types of Sybil attacks

Sybil attacks happen when a single individual controls multiple oracles, but how does that happen anyway? Let us go over the most likely scenarios.

1. Oracle botnets

Unless you are not aware by now, node operators are going to be prime targets for hackers. Hackers are going to use compromised oracles to form botnets and perform Sybil attacks at the most opportune moment. Therefore, a node set up and operated with poor OPSEC practices is a Sybil attack risk.

2. Node-as-a-service (NaaS)

NaaS is a business model where a third party sets up/configures/manages a node operator’s node. The client here is typically a LINK investor or an API provider who does not want to run an independent node. Since the NaaS provider will likely be serving multiple node operators, this constitutes a Sybil attack risk.

3. Smurfing

Associating each oracle with a real identity is not enough to eliminate the Sybil attack risk. The attacker may set up multiple oracles to control themselves and have others get their identities associated with these oracles.

Economics of Sybil attacks

Why should the node operators care if the smart contracts are the victims? Imagine if there was no way to distinguish between an honest oracle and an attacker. Attackers can bid lower because manipulative Sybil attacks have additional incentives and off-chain freeloading reduces operating costs. As a result, honest node operators would get pushed out of the market and it would only make sense to run a node if you were malicious. The resulting oracle network would simply not be able to function outside of the trusted nodes. Therefore, a defense against Sybil attacks is urgently necessary.

What can be done?

Since an important aspect of our problem definition — real identities — is a part of the off-chain world, some part of the solution should also lie in that domain. However, calling the cypher police is not the answer. Although this sounds ridiculous, the reputation service based on previous performance is exactly that. Here, a third party reputation provider keeps good boy-points for each oracle, and the risk of losing these points is supposed to deter node operators from performing attacks.

The problem with Sybil attacks is that they are going to be attempted only when the attacker is positive that they control the majority of the nodes answering a request. Therefore, a successful Sybil attack is not likely to be detected at the aggregation step, and wouldn’t result in the attacker losing reputation points.

Another gruesome Sybil attack.

Since we can’t detect Sybil attacks, we need preventative measures. The method that will likely see a lot of use initially is for the smart contract developers to only use the oracles that they trust (i.e., a non-digital reputation network). However, this method is prone to centralization, not scalable, and excludes independent node operators.

We came up with a solution where the node operator can demonstrate publicly that they don’t constitute a Sybil attack risk up to a desired certainty. In a market where some oracles can provide this proof while others can’t, we predict that smart contract developers are going to exclusively prefer the ones that can.

Prisoner’s dilemma

You probably know about this one: Two accomplices in a crime have been arrested and are being interrogated. Each prisoner has two options, they can accuse the other or stay silent. There are three possible outcomes:

If both accuse each other, each of them serves two years.

If one accuses the other and the other stays silent, the accuser walks free and the accusee serves three years.

If both stay silent, each of them serves one year.

In this case, although cooperation yields the optimal collective outcome (a total of two years being served), since the prisoners are self-interested, they choose to betray to achieve the best outcome for themselves. This causes both of them to betray each other, resulting in a worse individual outcome compared to cooperation.

The take-home message is this: If we don’t want two accomplices to cooperate, we need to create an incentive for one of them to betray the other.

Nodary with bounty mechanic

Nodarization starts by CLC Group vetting the identity of a node operator, and associating it with their oracle contract address. Then, we deploy a special escrow contract for this oracle address, which the owner node operator deposits LINK in. This contract releases its funds to the address that proves control of the respective oracle contract. The amount of LINK deposited in this contract demonstrates the oracle’s Sybil attack resistance.

A simpler explanation: Let’s say you are Nodarized and have staked a large amount of LINK in your escrow contract. If I can signal to the escrow contract that I can control your oracle contract, I get your staked LINK.

“So I’m going to paint a huge target on my back?!” Yes you will. In biology, this is called the handicap principle. The most well-known example to this is a peacock’s tail.

Although an extravagant tail handicaps the peacock, it also acts as an unfakeable signal of fitness for the females.

By staking a large sum in this escrow contract, node operators will be able to prove to smart contract developers in an incontestable way that no other person has control over their nodes, because otherwise, this other person would have betrayed them and withdrawn their funds. This proof is as strong as the amount staked in the escrow contract.

Now let us consider the attack types again:

1. Oracle botnets

When a hacker compromises a Nodarized oracle, it is going to be in their best interest to withdraw the funds from the escrow contract as soon as possible. If they don’t withdraw the funds and have the oracle wait to be used in a botnet attack, the oracle will likely be compromised by another hacker and they are going to withdraw the funds (leaving the botnet attacker with a useless node). Therefore, having a large amount of collateral in your Nodary pot is going to prove to smart contract developers that your node security is stellar.

2. Node-as-a-service (NaaS)

If the NaaS provider is able to perform a Sybil attack with the clients’ nodes, they can also withdraw their collateral from the escrow contract. Therefore, Nodary allows the NaaS clients to render themselves vulnerable against the NaaS provider. Assuming that the clients have deposited a sufficiently large amount of LINK in their pots, there are two possible outcomes:

The NaaS provider is trustworthy and the Nodary pot remains untouched.

The NaaS provider is malicious and attacks the Nodary pots as soon as it is sufficiently rewarding to do so.

In both of these cases, the smart contract developer remains secure. Therefore, by choosing Nodarized oracles with large pots, smart contract developers will be able to protect themselves from NaaS-related Sybil attacks.

Another way of looking at this is that NaaS clients are going to quantify the trustworthiness of a particular NaaS provider on-chain by the collective amount of LINK staked in their Nodary pots. Assuming that every NaaS provider is finitely trustworthy (i.e., would betray for enough incentive), Nodary also has an overall decentralizing effect on the network, as it applies a downward pressure on the maximum number of clients a NaaS can serve.

3. Smurfing

Here, the two accomplices are the malicious node operator and the person whose identity is being used. Then, we should create an opportunity for the owner of the identity to betray the malicious node operator. A new mechanic comes into play: The owner of the identity can repeat the identity vetting procedure with CLC Group and request the contents of the escrow contract to be sent to an arbitrary address. Like the other two cases, smurfing gets riskier as the staked amount increases.

Shortcomings

An obvious problem with the proposed scheme is the solution to smurfing, which requires CLC Group to be able to withdraw funds from the escrow contract. As a solution, we will let the user limit the amount that will be withdrawn from their escrow contract when CLC Group verifies that they have been smurfing. For example, a user stakes 100,000 LINK, and limits their smurfing resistance at 20,000 LINK.

If someone proves control of the oracle, they can withdraw 100,000 LINK;

If someone proves identity with CLC Group, they can withdraw 20,000 LINK, updating smurfing resistance to be 0 LINK automatically.

In the long run, we are planning to solve the problem with smurfing resistance by doing the identity vetting in a trustless manner using the Chainlink network. However, this solution will not be available in the near future.

A more minor issue is a way to circumvent the smurfing resistance. The malicious node operator may stake LINK in their pot, perform the attack and withdraw the staked LINK before the identity owner is able to prove their identity with CLC Group. This problem can easily be overcome by implementing a feature in the smart contract that prevents frequent actions. We expect the community to come up with more loopholes to help us iron this out.

Monetization

You are probably wondering how we are going to monetize this. As announced earlier, Nodary will be a subscription service with a fixed fee and periodic identity vetting. We will not take a percentage out of the staked collateral, because we don’t want to discourage users from using the service or staking large amounts.

Note that we have preferred to keep the Nodary pot in LINK, rather than ETH. This is because a large amount of LINK being staked at escrow contracts for long times is going to induce scarcity, which is going to increase the LINK price. We are sure that LINK investors are going to welcome this effect.

Since Nodary pots will be kept in LINK, certification emerges as an alternative to the extremely risky per-job stakes built in the protocol. Effectively, Nodary can be thought of as a second layer Chainlink solution. We have claimed to be developing ecosystem-scale solutions, and one way to achieve that is to work near the protocol level.

Q&A

— But it’s centralized?!

Indeed, Nodary is the first and only centralized oracle certification service for Sybil attack-resistance.

— Does this mean NaaS users can’t get Nodarized?

It is perfectly fine to get NaaS from a provider that you trust. Nodary only requires you to back your judgement up with the size of your pot. If you are not comfortable with staking a large amount at your pot because you have reason to mistrust your NaaS provider, you should be prevented from getting high value jobs, and Nodary will ensure that.

— What about pools?

As explained in our white paper, pools with multiple nodes behind a single oracle contract do not constitute a Sybil attack risk, and thus can get Nodarized.

— Doesn’t this encourage people to hack nodes?

As mentioned earlier, hackers are going to hack anyway, and Chainlink nodes are easily monetizable targets. With Nodary, we turn hackers into bounty hunters. By taking down unfit nodes, they are going to be serving the network by improving its resilience instead of being a net negative effect.

— Why do you need periodic identity vetting?

There are two reasons:

For the identity verifications to be reliable, they need to be kept fresh.

High-profile data sources require KYC. We will be using Nodary to make this procedure frictionless. Periodic renewal allows us to adapt our identity vetting procedure to match the changing requirements.

Announcement

We had updated our launch plan for some time now, but needed to share the details of Nodary for you to be able to appreciate the weight of the changes. As you may remember, we were planning to do an open launch, meaning that any node operator was going to be able to connect to the Honeycomb API marketplace at launch.

We have decided that we are going to be able to launch earlier and iterate faster with a closed beta. Moreover, if we get enough people in this beta, we can still serve our entire catalog to the Chainlink network in a robust manner.

We need a group of elite independent node operators to assist us with their feedback while we develop this beta version, and we can’t think of a better alternative for this than our shareholders. This way, the closed beta participants are going to have a very strong incentive to help make Honeycomb its best possible version. In return, we will support the participants to become a new generation of independent node operators, pool operators, Chainlink consultants, and prospective business associates to CLC Group.

We are going to invite the presale contributors with the 50 largest total contributions to the closed beta (the contribution to the crowdsale counts, not the amount of CLCG being held). These node operators are going to have complete access to our entire API catalog, and they are going to get one year of free Nodarization when the service is launched. The closed beta users will still pay for their calls. See our recent article to understand what running a Honeycomb node is going to be like.

Some notes:

A top 50 contributor can transfer their closed beta access until August 1st (1 month after the crowdsale closes). The receiver can be a U.S. citizen. If this is going to be a trade, you can consult with us.

Your contribution is for the CLCG tokens. Closed beta access is merely an offering, which can be revoked upon misconduct.

The closed beta will continue as long as needed. We will regulate the number of closed beta users.

See our CLCG token and crowdsale contracts at

https://github.com/clc-group/clcg-presale

Visit our website for contribution instructions

http://clcg.io/tokensale/