Real-Time Tick Data
Financial Tick Data for Smart Contracts
The first problem the Morpher Chain solves is the Data for Smart Contracts. The data will be readily available through special contract calls, caught by the validator, and directly answered without much EVM interaction. On another EVM compatible chain, this will either trigger a callback or simply will be unanswered - in other words, its backwards compatible.
There is several ways to achieve this, for example:
- Introducing a new OP Code for Smart Contracts. This way a contract could fire an opcode and get back a specific value
- Doing a callback simulation by which a new transaction will be inserted by a validator in the same block that answers a callback directly
- Write before Read simulation: A contract that reads a value, e.g. for AAPL, will read an existing smart contract. The EVM catches this contract call, updates the storage slot accordingly, before the read is done.
Method 1: Custom OP Code
It would extend the current VM opcodes of the EVM and get a new opcode for getting the asset-prices. This functionality has been added to YUL in March 2021 https://github.com/ethereum/solidity/issues/11430 and is now available as verbatim calls. It would be possible to use a new opcode that simply does not exist on a regular EVM and would simply return nothing. The drawback is, its not backwards compatible and potentially errors out.
The EVM handler has a custom opcode implemented and look up the last tick price for a specific asseti of the type “typeOfAsset” and returns the value directly at the time where its needed.
This, of course, has the drawback of not being backwards compatible, because the extended OP code makes Morpher-Chain an EVM Superset of the EVM.
On other clients not implementing the EVM opcodes it might error out or simply not work, but it is very fast.
Method 2: Callback Block Injection ✅
Another method is a callback block injection, which solves the following Problem:
In current systems the flow is to set off a call to an Oracle Smart Contract at B block-number. An external entity would then listens to an Event, which then answers itself with a transaction in B+N blocks after the initial transaction started. Where N ≥ 1.
In the Morpher Chain the transaction can be answered in the same block, causing zero delay, with the most updated tick data.
It is worth highlighting here that the only delay introduced is the one on the wire - that is, between the validator and the broker. The operation itself does not cause any delay as the most updated tick data is already available at the time of mining the block and will be used to provide the EURUSD rate.
This method is also fully backwards compatible to other chains. On chains not supporting callback block injection, it will default back to answering with a callback in a following transaction after the event was emitted. Just as a regular transaction would. It can then also make use of any secure enclave model Provable Things provides or API3 does with
Method 3: Write-before-Read or Simulated-Read
Another method could be a write-before-read or a simulated read.
This would mean a contract A would call an Oracle Contract. Upon calling this contract the EVM would intercept that call and either update the storage slot of the called Oracle Contract with the right value, or outright simulate the storage slots value.
Discussion
All three methods could be implemented on a custom chain. Since oracles are already known to work with the request/callback flow, the Method 2, Callback injection is the preferred method.
Another point is the economics. A Data Provider needs to be rewarded for providing good data feeds. In this case, an oracle call can directly forward native gas tokens or any other erc20 based tokens to the data provider through the request model. It also opens up more options for a smart contract based governance model for data providers which work cross chain.