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
Our team at @AbstractSDK is working on refactoring our smart-account implementations to be optimized for account-abstraction use-cases. Because each user on the blockchain will have an Abstract smart-account created for them, we're trying to minimize the state that is stored under the contract's namespace.
The account needs to be aware of a few contracts in order to do verification of actions or call specific functionality on them.
Our Solution
To reduce the state we've been exploring the use of instantiate2 to deterministically compute the canonical address of each contract and include them in the WASM binary directly as bytes, to be humanized at runtime. As the # of Accounts scale, this should have a significant impact on the storage use of our solution.
To get the address of any of these native contracts we do the following:
Upload a CosmWasm "blob" contract that is a minimal CW contract.
Use instantiate2 with a contract-specific salt to claim the address for that specific contract.
Migrate the blob on that address to the contract that we want to have occupy that address.
The Problem
The problem that we're facing is that this workflow does not give us the same addresses in the cw-multi-test environment due to the fact that its instantiate2 method does not incorporate the actual checksum of the blob contract.
As a result we're forced to either:
Construct our own ChecksumGenerator and use it in all our cw-multi-test uses.
We don't like this solution because as a development framework, we'd require all our users to use this exact ChecksumGenerator, which might conflict with their own requirements.
Use feature-flags to select a set of different addresses for use in cw-multi-test.
This will create conflicts in our codebase, requiring us to separate cw-multi-test tests from all other kinds of tests and would create a lot of complexity in our codebase overall.
Discussed Solution
We've internally discussed an addition to cw-multi-test that would allow users to set the checksum of a contract through the Contract trait.
pubtraitContract<C,Q = Empty>whereC:CustomMsg,Q:CustomQuery,{/// Get the checksum of the contract// Defaults to None (not API breaking)fnchecksum(&self) -> AnyResult<Option<String>>{Ok(None)}}
And then update ContractWrapper to contain an optional checksum value.
pubstructContractWrapper<
...
> where
...
{// Add an optional checksum fieldchecksum:Option<String>,}
And update the instantiate2 method to use this checksum if Some.
Doing this would allow developers to use the exact same addresses for their contracts in a test environment as a wasmd environment without requiring custom checksum generators.
Questions
Is this an acceptable solution?
The text was updated successfully, but these errors were encountered:
Hi @CyberHoward, there is PR #212 that implements the proposed solution.
Could you take a look at it and confirm if it is fully covering your requirements?
Description
Our team at @AbstractSDK is working on refactoring our smart-account implementations to be optimized for account-abstraction use-cases. Because each user on the blockchain will have an Abstract smart-account created for them, we're trying to minimize the state that is stored under the contract's namespace.
The account needs to be aware of a few contracts in order to do verification of actions or call specific functionality on them.
Our Solution
To reduce the state we've been exploring the use of
instantiate2
to deterministically compute the canonical address of each contract and include them in the WASM binary directly as bytes, to be humanized at runtime. As the # of Accounts scale, this should have a significant impact on the storage use of our solution.To get the address of any of these native contracts we do the following:
instantiate2
with a contract-specific salt to claim the address for that specific contract.The Problem
The problem that we're facing is that this workflow does not give us the same addresses in the
cw-multi-test
environment due to the fact that itsinstantiate2
method does not incorporate the actual checksum of the blob contract.As a result we're forced to either:
ChecksumGenerator
and use it in all ourcw-multi-test
uses.ChecksumGenerator
, which might conflict with their own requirements.Discussed Solution
We've internally discussed an addition to
cw-multi-test
that would allow users to set thechecksum
of a contract through theContract
trait.And then update
ContractWrapper
to contain an optionalchecksum
value.And update the
instantiate2
method to use this checksum ifSome
.Doing this would allow developers to use the exact same addresses for their contracts in a test environment as a
wasmd
environment without requiring custom checksum generators.Questions
Is this an acceptable solution?
The text was updated successfully, but these errors were encountered: