Cartesi DApps advance their state when they receive inputs, which currently correspond to arbitrary payloads sent via the InputBox contract on the base layer (L1).
In order to process any data from the base layer, currently the only possibility is to add a smart contract to explicitly relay information to the DApp in a trusted manner. For instance, to acccess the price0CumulativeLast variable of a UniswapV2Pair contract, you currently would need to deploy a UniswapRelay smart contract, with a method like relayPrice0CumulativeLast(address pair, address dapp). This method would then retrieve that variable from the specified pair, and add an input to the DApp with that information. The DApp back-end would have also have to be coded to explicitly trust inputs coming from UniswapRelay’s address, and know how to process them.
This approach dramatically limits the amount of integration that Cartesi DApps can have with the base layer. Allowing more general access would open up a wide range of capabilities for Cartesi DApps, including the following:
-
DApps that take advantage of the Cartesi Machine’s computing and programmability power to do all kinds of analytics over base layer data. This is particularly rich for DeFi, allowing things like DEX analysis tools (like this proposal) and all sorts of risk analyses (e.g., to enable smart lending with conditions calculated according to each client’s profile). It may also be very interesting for base layer governance, since it would trustlessly allow thorough inspection and analysis of its own state. Maybe even things like TheGraph could be done via a Cartesi DApp.
-
DApps that respond to transactions that are not explicitly aware of them. It would become possible for DApps to receive base layer block hashes as their inputs, and from there access any desired general base layer state from that block or prior blocks. This way, DApps could respond to activity on e.g. Uniswap, without that activity having to be aware of the existence of Cartesi!
-
Allow sequencers such as Espresso to be properly used. When using those, inputs generally arrive from outside the base layer (e.g., from an Espresso network). However, inputs that relay critical information from the base layer, such as deposits, still need to be processed. The correct way for a Cartesi DApp to process data from both sources is to have it access the sequencer commitment on L1 as well as any other base layer input of interest (e.g., the InputBox). Without general access to base layer data, we would need to have some client observing sequencer commitments, and explicitly relaying every commitment to the DApp
Implementation-wise, the way forward to achieve this funcionality is clear: a dehashing device with a namespace for the base layer (e.g., namespace “ethereum”). The most basic primitive would be for the device to return block data given a block hash, and allow navigation from there throughout the blockchain state. However, there are open questions as to how to make this more usable for DApp back-end code, including whether we would allow access to contract storage, blockchain events, or both.