We're working on bringing Sui to an Avalanche subnet and then later hoping to work on interoperating with Aptos under a Canonical VM. Our goal for now is to support Sui smart contracts, and as much of the Sui RPC and broader ecosystem as we can. Because of the uniqueness in Sui consensus, we're trying to evaluate the effects of pulling out Sui execution and applying it to blocks as we've begun to do. We're looking for thoughts on our approach and possibly suggestions to go in another direction.
We are currently focused on implementing the Sui object-runtime in an external context, separate from Sui consensus. Our aim is to uphold comparable functionality to the Sui RPC, and we are in the process of evaluating various concepts to achieve this goal.
Before we get into our current approach, it's probably best to ask if you would do this an entirely different way. If we just want to have Sui Move and roughly a compatible RPC, but drop the consensus features, what should we do? Are there parts of this which are impossible?
Currently, we form a block roughly as just SenderSignedData: https://github.com/MystenLabs/sui/blob/main/crates/sui-types/src/transaction.rs#L1921
We didn't find a direct way to execute SenderSignedData as a ~block that isn't entangled with the consensus logic. So, we are working on logic to execute sender signed data which ultimately uses execute_transaction_to_effects: https://github.com/MystenLabs/sui/blob/fb0ce3485f498cb8e434510db929eeeb51cdadd6/sui-execution/v0/sui-adapter/src/execution_engine.rs#L56
Is this a reasonable approach? We're getting quite caught up in the integration logic. Is there something simpler we can do?
For additional context, as an Avalanche subnet, consensus is entirely handled by Avalanche. Ultimately, we want to find the simplest way from the existing source to (a) construct what would be a valid Sui block, (b) execute the transactions in that block, and (c) update some kind of state. We're open to any recommendations if they differ substantially.