You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the context of the Output Unification effort, there will be a single event for all output executed called, intuitively, OutputExecuted. This event can be listened to by outsiders to index what on-chain side effects have taken effect until any given point. For example, if you are monitoring the assets locked in a given application, there are two main routes: polling or folding.
You can monitor deposits via the InputAdded event emitted by the InputBox contract. If the input is coming from a portal, you can decode the input and figure out who transferred, what asset, how much, and to which application.
Previously, if you wanted to monitor withdrawals, you'd have to listen to events emitted by each token contract supported by the application. Now, if you're indexing this kind of information for all applications that use Cartesi, the problem only gets harder.
Furthermore, it would be impossible to monitor Ether withdrawals, since they do not necessarily trigger events that can be listened to from outside the blockchain.
Of course, you could go another way, and ask the user to input a GraphQL endpoint, and from there extract the output blob. But then you're relying on a centralized solution. Why not use the blockchain for this information, since that's where it actually happens, right?
✔️ Solution
We can modify the OutputExecuted event to include the output blob. With this, it would be much easier to monitor deposits as well as any other on-chain action taking place. Also, you wouldn't have to monitor several token contracts. Instead, you'd only have to monitor the InputBox and Application contracts.
📚 Context
In the context of the Output Unification effort, there will be a single event for all output executed called, intuitively,
OutputExecuted
. This event can be listened to by outsiders to index what on-chain side effects have taken effect until any given point. For example, if you are monitoring the assets locked in a given application, there are two main routes: polling or folding.You can monitor deposits via the
InputAdded
event emitted by theInputBox
contract. If the input is coming from a portal, you can decode the input and figure out who transferred, what asset, how much, and to which application.Previously, if you wanted to monitor withdrawals, you'd have to listen to events emitted by each token contract supported by the application. Now, if you're indexing this kind of information for all applications that use Cartesi, the problem only gets harder.
Furthermore, it would be impossible to monitor Ether withdrawals, since they do not necessarily trigger events that can be listened to from outside the blockchain.
Of course, you could go another way, and ask the user to input a GraphQL endpoint, and from there extract the output blob. But then you're relying on a centralized solution. Why not use the blockchain for this information, since that's where it actually happens, right?
✔️ Solution
We can modify the
OutputExecuted
event to include theoutput
blob. With this, it would be much easier to monitor deposits as well as any other on-chain action taking place. Also, you wouldn't have to monitor several token contracts. Instead, you'd only have to monitor theInputBox
andApplication
contracts.📚 Requirements
The text was updated successfully, but these errors were encountered: