Closed obycode closed 1 year ago
I just chatted with @rafaelcr about confirmed that this proposed solution will not be a problem for the API, as there are several other cases where the API uses print events.
I support this approach for easy maintainability and using the same Clarity Implementation as L1. I certainly prefer the contract calls instead of maintaining a separate copy of clarity. Thanks @obycode !
Thinking this through further, it should act very similarly to the way the pox contract is used. There is a real boot contract that the users' of the subnet and their contracts interact with, and then in the miner, the information is read from this contract to take action.
In the current implementation, there are some minor changes to the
clarity
library from stacks-blockchain to support some new builtins:stx-withdraw?
,ft-withdraw?
, andnft-withdraw?
.If instead of adding these as builtins, they were contract-calls to a boot contract on the L2, then we could use the clarity crate and not have to deal with all of the headaches associated with keeping a separate copy of clarity.
This would require also removing the new event types in the subnet Clarity implementation, but the boot contract could emit standard contract events (prints) instead.