Integration and Debugging
After you create a dependency mapping json for your contract, you will want to verify its correctness by testing it on a local Sei network.
You can follow the steps below to register the dependency mapping:
// register dependency using CLI
seid tx accesscontrol register-wasm-dependency-mapping dependency_mapping.json --from $KEY --fees 2000usei --chain-id $CHAIN_ID
// verify the dependency is correctly registered
seid q accesscontrol wasm-dependency-mapping $CONTRACT_ADDRESS
Remember to instantiate your contract with an admin account, otherwise you won't be authenticated to register dependencies for that contract
It's possible that your contract may have errors with dependencies after initially defining them, and this can be identified via robust testing with a local sei environment. While testing contract using local sei, devs can search for the keyword
invalid concurrentin their sei chain output in order to find errors relating to parallelization. Below is an example of what the output may look like:
We can interpret the errors in the above INFO logging in the
Missing Access Operation:in the following way:
- AccessType: represents READ or WRITE access of the operation
- StoreKey: represents which Sei Cosmos module's KV store had a usage that wasn't declared in the contract dependencies. You can use the Resource Types appendix to find the corresponding resource type.
- Identifier: a hex string used to identify the key that was being accessed in the KV store. Using this identifier, one can infer the specific resource type by the key prefix used (the first segment of the hex value) and this can be used for identifying what kind of resourcetype needs to be declared.
In the above image, we see that there is a missing dependency with the following elements:
- AccessType -
- StoreKey -
- Identifier -
By referring to Store Key we can figure out the
wasmStoreKey corresponds to the
wasmtypes.StoreKeyis the key to find the right list of ResourceTypes in the ResourceTypePrefix.
Here the identifier begins with
03as the hex value of the key. By referring to the wasm keys in the ResourceTypePrefix, we can figure out that the prefex
0x03refers to the
ResourceType_KV_WASM_CONTRACT_STOREand the corresponding resource type in the Resource Types is
Using the information above, we can create a dependency that should cover the requirement flagged in the logs as such:
This should be sufficient to resolve the dependency error, but for better dependency specification, we would like to as closely replicate the identifier as possible. We can identify that the next segment of the identifier matches a parsed contract address, which can be identified using
seid keys parse identifer[2:34](aka the 32 characters after the first two which were the store prefix). For the above example, the characters
b8789fc7e7456bde8a20801c73ea12ecef7e7a3cfe97ff9b8e8841fb98402e6bare parsed to be
sei1hpufl3l8g44aaz3qsqw886sjanhhu73ul6tllxuw3pqlhxzq9e4sn6dgntas the contract address.
Using this, we can specify the dependency to be generated using the contract address:
Now, we have specified the contract store dependency specific to our contract so that it can operate concurrently to other wasm contracts. By repeating this investigative process, we can build the dependencies for all missing dependencies and have a functioning concurrent wasm contract.
After we fix the dependency mapping json, we can follow the Parallelization Dependency Mapping Integration guide to register the dependency and verify the correctness again.
This section is still under work
: There may be scripts to further automate the debugging process and interpreting errors in parallel dependencies in the future, however do not currently exist.