The initial machine state cannot contain the DApp address because of the interdependence between the two, in the case where the DApp contract is deployed through the deterministic entry point. The back-end machine needs to know the DApp address in order to generate vouchers that either target the DApp contract or include the address in the payload. This is the case for ETH, ERC-721 and ERC-1155 withdrawals. For this reason, we created the DApp address relay, which relays this information to the DApp back-end a posteriori.
One problem with this design is that the machine may malfunction while it doesn't know its address. For example, it may not be able to reimburse the user if something goes wrong during the deposit (for example, if execLayerData is malformed). The DApp back-end could "remember" to reimburse the user once it receives its address, but it only adds complexity to the back-end and front-end.
This problem is relevant because it affects the usability and programmability of Cartesi Rollups, and is hardly alleviated by the use of high-level frameworks for the back-end.
āļø Solution
Instead of relaying this information through a special type of input sent by a special type of contract, this information could be part of the input metadata. In current terms, it would be an extra argument to the EvmAdvance function signature.
This information could be consumed by high-level frameworks and presented in a nicer way to the back-end developer, as a context variable. As a result, whenever the DApp receives an EvmAdvance input, it would know the DApp address. This would remove the need for a DApp address relay.
š Context
The initial machine state cannot contain the DApp address because of the interdependence between the two, in the case where the DApp contract is deployed through the deterministic entry point. The back-end machine needs to know the DApp address in order to generate vouchers that either target the DApp contract or include the address in the payload. This is the case for ETH, ERC-721 and ERC-1155 withdrawals. For this reason, we created the DApp address relay, which relays this information to the DApp back-end a posteriori.
One problem with this design is that the machine may malfunction while it doesn't know its address. For example, it may not be able to reimburse the user if something goes wrong during the deposit (for example, if
execLayerDatais malformed). The DApp back-end could "remember" to reimburse the user once it receives its address, but it only adds complexity to the back-end and front-end.This problem is relevant because it affects the usability and programmability of Cartesi Rollups, and is hardly alleviated by the use of high-level frameworks for the back-end.
āļø Solution
Instead of relaying this information through a special type of input sent by a special type of contract, this information could be part of the input metadata. In current terms, it would be an extra argument to the
EvmAdvancefunction signature.This information could be consumed by high-level frameworks and presented in a nicer way to the back-end developer, as a context variable. As a result, whenever the DApp receives an
EvmAdvanceinput, it would know the DApp address. This would remove the need for a DApp address relay.