Sovereign-Labs / sovereign-sdk

A framework for building seamlessly scalable and interoperable rollups that can run on any blockchain
https://sovereign.xyz
Apache License 2.0
375 stars 106 forks source link

Have a more generalized structure and process to create utils for each module #957

Open dubbelosix opened 1 year ago

dubbelosix commented 1 year ago

We ran into this issue when trying to create nft-utils. The sov-nft-module provides calls to create collections, mint nfts in collections. However creating a collection and minting a large number of NFTs to it would be too complicated to do using the sov-cli. To do so programmatically, it made sense to import the runtime from demo-stf and then create a serialized transaction as follows

    let mint_nft_message =
        RuntimeCall::<DefaultContext, MockDaSpec>::nft(CallMessage::<DefaultContext>::MintNft {
            collection_name: collection_name.to_string(),
            token_uri,
            token_id,
            owner: UserAddress::new(owner),
            frozen: false,
        });
    Transaction::<DefaultContext>::new_signed_tx(
        signer,
        mint_nft_message.try_to_vec().unwrap(),
        nonce,
    )

We foresee a general pattern where each module might require utils to programmatically interact with the Call Messages to create transactions and perhaps other utlities.

For now nft-utils has been placed at the root, but it would be good to design a generalized structure for utils so that developers of modules also have a process to follow and some templates they can use as a guideline. Eg: bank utils, sequencer utils as well.

Note: placing this in the module directly causes a circular dependency since the runtime imports the module but the util needs the runtime to generate the call message

bkolad commented 1 year ago

The utils for a specific module should not depend on the Runtime but only on the individual module. The reason is that if someone changes the Runtime (by removing the module) it will break the util specific code.