While we tend to choose to ignore the noise from the Chainlink community, we feel obliged to react in this instance due to the gravity of the accusation.
- MakerDAO does not participate in nor benefit from liquidations in neither the Maker Protocol nor other protocols.
- The fact that these slanderous accusation have been repeated not once, but three times, by the official Chainlink evangelist, reflects poorly on the integrity of the Chainlink community.
- ChainLinkGod has dug up an old, known, and publicly disclosed issue that has since been remediated, and that is about to be permanently fixed by a production upgrade that is in the final stage of its roll-out.
- The irony is that while the Maker Protocol was able to easily fix the issue, the Chainlink architecture is built in such a way that this cannot be avoided.
To be absolutely clear, MakerDAO and the Maker Foundation do not participate in liquidations, neither in the Maker Protocol nor in other protocols such as dYdX.
MakerDAO and the Maker Foundation have never profited or indirectly benefited from the use or sale of privileged price information.
A few months ago, the Oracle Domain Team discovered a hidden undocumented state-size dependency within scuttlebutt, a p2p gossip network utilized by the MakerDAO Oracles. This was well documented both in the forum and discussed on the public Governance & Risk call multiple times.
This was concerning, as it could potentially be used by a malicious actor to spam the network. Two solutions were formulated, one short-term and one long-term.
Short term: Patch scuttlebutt to raise the state size limit
Long-Term: Integrate libp2p as a parallel gossip network to ensure 100% uptime in case either scuttlebutt or libp2p experienced an exploit, bug, or spam attack.
The short-term solution was to patch scuttlebot to bump up the state size to a high enough threshold that spam attacks become uneffective. However, as this change was nested deep in the dependency tree of scuttlebutt, it was unclear whether this might have adverse effects higher up in the stack.
Oracles are a mission critical piece of infrastructure for DeFi protocols. Failure is absolutely not an option. Adding code to a production system securing billions of dollars of value is something that needs to be handled delicately with an abundance of caution. Therefore, the decision was made to test the solutions for an extensive period of time before deployment into production.
In this interim period, it necessitated that access to the scuttlebutt network be restricted such that no malicious actor could abuse the attack vector we had publicly disclosed.
While necessary, it was a bit problematic, in that it gave Feeds and existing Relayers privileged access to signed price messages that were not public anymore. Fortunately, the pace of adaptability and innovation in DeFi is incredible. Liquidators without access to the scuttlebutt network started intercepting oracle updates in the mempool and front-running them. This leveled the playing field again among liquidators while the Oracle Domain Team developed and tested the proposed solutions.
The Oracle Domain Team completed testing of the Scuttlebot state size patch and rolled it out into production on 4/13/21. Development of the libp2p integration was also progressing favorably.
As many who follow DeFi closely are acutely aware. The growth of Flashbots in recent months has been astounding. To provide some context, Flashbots moves gas-price auction bidding wars between bots from the mempool to a special flashbot dark pool. The key advantage being that the loser(s) of a bidding war for a particular MEV opportunity, don’t end up having to pay for transactions that don’t “win.” In the case of Oracles this was slightly problematic because it meant price update weren’t being leaked into the mempool anymore, cutting off a segment of liquidators that were relying on that mechanism.
Fortunately, present day, the development of the libp2p integration has been completed, and rolled out to the production Oracle network in an upgrade earlier this month. However, the configuration option to activate libp2p has not been triggered yet as we undergo some final stability checks on the production network. As soon as these checks are completed in the coming weeks, libp2p will be activated, and network access can revert to being completely permissionless.
The irony is that while Maker was easily able to fix the issue, the ChainLink architecture on the other hand has a fundamental design flaw such that this cannot be avoided. This is because it lacks the separation between Feeds and Relayers that the Maker Oracles have had from the beginning.
The MakerDAO Oracle architecture separates the roles of Feeds (price submitters) and Relayers (Oracle updaters). This means that by providing permissionless access and opportunity to be a Relayer, anyone can update a MakerDAO Oracle and extract MEV. Chainlink on the other hand does not separate the role of price submitter and Oracle updater. This means all MEV in Chainlink Oracles is completely monopolized by the Chainlink Feeds (price submitters), an exclusive group whose membership is controlled by Chainlink.
Chainlink randomly selecting a Feed to be the role of Oracle updater for each price update does not fix this problem, it just socializes gains among the privileged Feed validator set. This is not the case in an open permissionless network like the MakerDAO Oracles where anyone can be a Relayer to push Oracle updates.