Enable precompiles in testnet

[CharlieMc0]

Precompiles should be enabled in testnet so we can test them out on a real network and get feedback from network users. It also gives the web app team time to integrate these new features into the front end. And gives the SRE team time to build monitoring.

This should be enabled in testnet only for now.

[kingpinXD]

The PR for enabling is ready to be merged, but I think we should consider enabling the contracts one by one , in the order of Prototype -> Bank -> Staking For context, this is what we have so far

Available Precompiled Contracts

1. Prototype Contract (Address: 0x0000000000000000000000000000000000000065)

This contract provides utility functions for address conversion and gas pool queries.

Methods:

• bech32ToHexAddr(string bech32) view returns (address addr): Converts a bech32 address to hexadecimal address
• bech32ify(string prefix, address addr) view returns (string bech32): Converts a hex address to bech32 address
• getGasStabilityPoolBalance(int64 chainID) view returns (uint256 result): Returns the balance of the gas stability pool for a given chain ID

2. Bank Contract (Address: 0x0000000000000000000000000000000000000067)

This contract primarily provides the Lock and Unlock functionality to convert between ZRC20 and Cosmos tokens

Methods:

• deposit(address zrc20, uint256 amount) returns (bool success): Deposits ZRC20 tokens and mints corresponding Cosmos tokens
• withdraw(address zrc20, uint256 amount) returns (bool success): Withdraws Cosmos tokens and converts them back to ZRC20 tokens
• balanceOf(address zrc20, address user) view returns (uint256 balance): Retrieves the Cosmos token balance for a specific ZRC20 token and user

3. Staking Contract (Address: 0x0000000000000000000000000000000000000066)

This contract provides staking functionality.

Methods:

• stake(address staker, string validator, uint256 amount) returns (bool success): Stakes tokens with a validator
• unstake(address staker, string validator, uint256 amount) returns (int64 completionTime): Unstakes tokens from a validator
• moveStake(address staker, string validatorSrc, string validatorDst, uint256 amount) returns (int64 completionTime): Moves stake from one validator to another
• getAllValidators() view returns (Validator[] validators): Returns all validators
• getShares(address staker, string validator) view returns (uint256 shares): Returns staker's shares in a validator
• distribute(address zrc20, uint256 amount) returns (bool success): Distributes ZRC20 tokens as staking rewards
• claimRewards(address delegator, string validator) returns (bool success): Claims staking rewards for a delegator

[CryptoFewka]

What is the mechanism we have / need to have to activate a precompile for use? I assumed based on context that it is (currently) inherently linked to a mandatory software upgrade rather than having an on-chain parameter we can toggle on and off as we desire.

[kingpinXD]

We don't have an on-chain parameter to toggle individual contracts. The contracts are in the state when starting the node application, so we need to upgrade to add new contracts. I dont think a migration script would be needed but we can test that out before merginf any of the related prs

[lumtis]

Now that precompiles are part of the security review, why not enabling it on testnet then mainnet in the same release?

[CharlieMc0]

Originally I'd hope to get them included in v30 so we had lots of time to test them on testnet.

1. If there is no toggle, if we enable it on v31 in testnet and realize we need to disable it again before mainnet it'll require a new release and new testnet upgrade. Essentially we have no rollback plan.

2. Since the testing time for v30 -> v31 will be shorter it seems like a big change to roll out quickly. I could be wrong, but my understanding was these precompiles can be complicated and it would be good to get real world testing on testnet first in case there are performance of stability related issues.

[CharlieMc0]

If the team thinks it's low risk I am open to enabling them at upgrade time but I think the one by one strategy @kingpinXD outlined would be safest. Even if it means it rolls our more slowly.

[lumtis]

Task to revisit after Cosmos EVM migration

[lumtis]

Closing as the precompile will be supported on the new Cosmos EVM module