Author: Kyle
Foreword: “The decentralized API project API3 recently announced the completion of US$3 million in financing. Well-known investment institutions such as Placeholder and Pantera participated in the investment. In addition, because API3 focuses on the oracle track, some media referred to API3 as a “Chainlink killer” during the reporting process. “Chainlink currently occupies an absolute dominant position in the cryptocurrency oracle market. Can API3 really replace it? CLC Group CTO Burak Benligiray clarified in this article.”
Recently, the media used “Chainlink killer” to describe API3 in reports. Is this really the case? The answer is of course no, I will elaborate. Although the relationship between API3 and Chainlink is implicitly explained in our white paper and Saša’s series of articles, we can avoid future misunderstandings by clarifying it again now.
Start with the difference between API3 and Chainlink. API3 raised the issue that decentralized applications (dApps) need to access Web API, so the problem we face is API connectivity. From the perspective of security, cost efficiency, and ecosystem construction, the only feasible solution to this problem is to use a first-party oracle (oracle), which is an oracle operated by the API provider itself. In contrast, Chainlink (and similar solutions) focuses on the lack of an interface, called the oracle problem, and aims to establish this interface through a third-party oracle. As a result, neither the protocol nor the node is optimized to be operated by the API provider (because the API provider is not even in the figure below), which compromises the feasibility of the first-party oracle.
A subjective picture of our solutions in the oracle field.
See the picture above. We start with a different definition of the problem (that is, the API connection problem is more important than the oracle problem). This also determines our solution, which uses the first-party oracle. On the contrary, Chainlink aims to solve the problem of oracles through third-party oracles.
The problem being solved (no matter how you describe it) is not a problem that can be solved accidentally, but needs to consciously move directly towards the best solution. Then, it is clear why API3 and Chainlink are not direct competitors: they see a different problem and are working on different solutions.
API3 aims to solve the problem of API connectivity and solve this problem in a completely decentralized and ecosystem-driven way. Because we firmly believe that this is the right approach, in our view, other efforts to achieve different goals using different methods are not competitors that must be killed, but people doing their own things.
Rebutting “API3 is the Chainlink killer”
Let us first point out the two advantages of API3. First of all, in designing nodes, protocols, token utility, governance structures, aggregation methods, quantifiable security models, ecosystem methods, and countless other aspects of the project, we fully understand the existing oracle solutions and refer to them The advantages and disadvantages of including Chainlink. Therefore, if we provide solutions in a completely different way, we will either solve the defects or improve them.
Our second advantage is that even though we have some understanding of the existing solutions, Chainlink seems to lack a basic understanding of the most basic concepts of API3-most notably, Airnode (the first party oracle node) and The difference between API3 (DAO that builds decentralized API without first-party oracles). But when these misunderstandings started to be used as a means of controlling damage by facts, it became frustrating. This is how the misunderstanding of the “Chainlink killer” occurred. Providing correct information is the best refutation, so let’s solve some problems:
This is a completely different improvement method from API3, which requires all data providers to operate and manage a new infrastructure before they can start using it. Chainlink’s original signature data function has been supplemented by a more important function, which enables smart contracts to access any API, which API3 obviously lacks.
We will not comment on Chainlink and first-party oracles here, please refer to this article. In order to correct the problems related to API3, although Airnode is superior to alternative solutions in third-party usage scenarios, API3 chose to use the first-party oracle because the third-party oracle relies on the middleman.
The second point is that when serving high-value use cases such as DeFi, API providers that use third-party oracles as “training wheel” parameters are no longer there. At that time, the responsible thing is to let all API providers run their own nodes, or build a node that API providers can run. API3 is doing the latter. When we have cost-effective and secure first-party oracles through various APIs, why would anyone use third-party oracles for DeFi or other things again?
The Chainlink Labs representative said:
“API3 does not run its own oracles for Ethereum or other nodes, which means they are forced to rely on a centralized third party to broadcast their results. This means that API3 is completely dependent on real-time node services like Infura, as we have recently As you can see, Infura may be paralyzed for several hours in an accident. In the case of API3, this will cause several hours of downtime, which will cause it to be out of sync with the market price, thus causing huge losses to users.”
Here, I want to say that this representative of Chainlink regards the specific configuration of API3 that we have never considered (that is, only using Infura) as our entire solution. Our proposal is that API providers can keep Airnode online indefinitely by using Infura free plan and AWS free tier hosting, and it’s completely free. In fact, being completely free is a key part of our plan to implement an ecosystem consisting of hundreds of first-party oracles.
If the API provider operating Airnode is successful (for example, generating revenue by providing services for API3), then they should invest in their infrastructure, ie not using the Infura free plan, but spending proportionally to maintain the Ethereum provider subscription /Node combination to achieve the best uptime. This roadmap is a more realistic strategy for mass adoption compared to putting money on the people who operate the nodes (neither scalable nor sustainable).
Let us assume that if Infura fails, what will happen to Airnode. Airnode aims to use multiple Ethereum providers at the same time without the need for load balancers. This means that for Airnode to go down, all the Ethereum providers it uses must go down at the same time (and there is no load balancer as a single point of failure). These Ethereum providers are a combination of centralized or decentralized service providers, and they also include the addition of private Ethereum nodes if the provider chooses to maintain and operate one.
In the final analysis, the performance of decentralized APIs will prove everything, but at the same time, we don’t appreciate that our solution is bound by a joint scenario based on false assumptions.
in conclusion
We believe that there is some misleading information about the recent publicity, and Chainlink’s claims about our solution have not been verified by our facts. This article is our attempt to clear some of the contents. To reiterate:
Due to the differences in their methods, we treat Chainlink as a case study, not a competitor.
We established Airnode because we found that the existing oracle nodes are unreliable, especially for the first-party oracle usage. Therefore, we do not accept the Airnode in a pose that is less reliable than any existing nodes.
Our more reliable design extends to the way the node communicates with the smart contract platform. Specifically, it uses multiple channels at the same time, which gives it unique anti-failure capabilities.
