1. Design Principles
Sphinx aims to design an oracle that can cope with the size of current DeFi assets and adapt to the future DeFi operating environment as it grows. The design philosophy satisfies the following principles.
1.1 The First Principle
The oracle should be attack resistant in the same order of magnitude as the size of the assets using the oracle protocol.
Once the value of the contract increases in a DeFi project, hunters in the decentralized network will inevitably resort to various extreme means to find a way to break through. The oracle's resistance to attack should match the size of the assets managed by the protocol. Even the most upright centralized oracle machine operator may come under pressure from bribes, intimidation, and regulation to the point where it is overwhelmed and eventually has to succumb.
Thus the centralized model cannot scale and satisfy the first principle. In contrast, the decentralized indirect oracle model relies on a decentralized infrastructure to automatically and randomly select nodes to read off-chain data. However, a multi-node data collection and honor system cannot fundamentally solve the problem. Penalizing nodes that fail to provide accurate prices after the event is too late as losses have already occurred. The oracle's first principle requires that prices should originate directly from the chain and that users who provide oracle prices should use real money to form real and accurate prices. By doing this mistakes are avoided rather than punished.
1.2 The Second Principle
The speed and scalability of the oracle should match the application scenarios of smart contracts.
In addition to ensuring that the oracle is attack-resistant, i.e., the price must be true and accurate, the speed and scalability of the oracle is also required according to the application scenario of the DeFi protocol. If the protocol requires a second-level prognosticator, the prognosticator should be adapted to it; if the protocol requires real-time expansion of the type or source of prices, the prognosticator should be matched to it. However, it should be noted that the second principle should not conflict with the first principle. Under the current TPS that the blockchain can carry, faster is not better. A balance between speed and resistance to attack is needed the moment the price prediction machine has met all the requirements of the current DeFi protocol. This is why Uniswap V2 introduces TWAP (Time Weighted Average Price) . This is a good way to avoid price manipulation in many cases of attacks using flash loans.
1.3 The Third Principle
High throughput, cross-chain compatibility consistency provides higher composability for cross-chain DeFi.
In addition to the attack resistance, timeliness, and scalability of the oracle, the ability to provide uniform prices across different public chains is equally important. The Ethereum network hosts a significant portion of DeFi applications, but is prone to severe network congestion, leading to a significant decline in availability and user experience. Meanwhile, public chains such as the Binance Smart Chain, Tron, Polkadot, Cosmos, Cardano, Near, and Solana are also expanding their own DeFi ecologies. The ability of protocols on different public chains to adopt a unified oracle price provides a further basis for DeFi's Lego characteristics and reduces the security problems caused by arbitrage between different systems.
On the basis of satisfying the first and second principles, the oracle should try to provide cross-chain solutions. Data validation on top of different master chains should be efficient and trust-free. Using Inter-Blockchain Communication protocol (IBCP) or one-way bridges to provide low-latency oracle prices and meeting the response speed and throughput that matches the performance of public chains.