Add pallet-contracts integration with Subtensor chain extension

[silva-fj]

Summary

This PR integrates the pallet-contracts module into the Subtensor runtime, enabling wasm smart contract functionality with a custom chain extension for accessing Subtensor-specific features.

Key Features

1. Custom Chain Extension (Function ID: 1001)

   • Allows contracts to query stake information (get_stake_info_for_hotkey_coldkey_netuid)
   • Provides read-only access to Subtensor state from within contracts

2. Restricted Call Filter

   • Whitelisted operations:
     • SubtensorModule::add_stake
     • SubtensorModule::remove_stake
     • SubtensorModule::unstake_all
     • SubtensorModule::unstake_all_alpha
     • SubtensorModule::move_stake
     • SubtensorModule::transfer_stake
     • SubtensorModule::swap_stake
     • SubtensorModule::add_stake_limit
     • SubtensorModule::remove_stake_limit
     • SubtensorModule::swap_stake_limit
     • SubtensorModule::remove_stake_full_limit
     • SubtensorModule::set_coldkey_auto_stake_hotkey
     • Proxy::proxy
     • Proxy::add_proxy
     • Proxy::create_pure

3. Conservative Configuration

   • Memory limits: 1GB for runtime, 2GB for validators
   • Maximum code size: 128KB
   • Call stack depth: 5 frames
   • Transient storage: 1MB

Breaking Changes

None - This is an additive change that doesn't affect existing functionality.

[masterdubs]

This proposal is groundbreaking, it open lot of native doors integration.
As soon as it is merged we will use it in Hippius for alpha handling.

[camfairchild]

This is using the proxy/multisig deposit formula
So around 0.001 TAO per byte and 0.02 TAO per storage item.

[silva-fj]

I have updated the deposit format to mirror the substrate example reference:

15% of the existential deposit per key, 6% per byte.

[camfairchild]

I saw something in the docs saying the APIs for the extrinsics we allow has to remain stable.

We solve this in the frontier (EVM) pallet by using precompiles with stable APIs but the underlying extrinsics can change.

Possibly we should do the same because I'm not sure if we can guarantee the stability of any of the extrinsics at-present

[camfairchild]

Also, @silva-fj let's actually remove the proxy::create_pure because I'm uncertain how the contract would be able to grab the resultant Pure proxy account that was created. It's only in an event created after the fact

[silva-fj]

I saw something in the docs saying the APIs for the extrinsics we allow has to remain stable.

We solve this in the frontier (EVM) pallet by using precompiles with stable APIs but the underlying extrinsics can change.

Possibly we should do the same because I'm not sure if we can guarantee the stability of any of the extrinsics at-present

Yes that's correct, the whitelisted dispatchables should remain stable. This is not exactly as critical as on EVM contracts because ink contracts can be upgradable (just like the runtime). But ideally a stable API should be provided.

This can be accomplished with chain extensions, by exposing an API that remains stable while the underlying dispatchables could be changed

[camfairchild]

This is not exactly as critical as on EVM contracts because ink contracts can be upgradable (just like the runtime).

EVM contracts use an upgradeable pattern as well.

This can be accomplished with chain extensions, by exposing an API that remains stable while the underlying dispatchables could be changed

Possibly we can also just agree that the API is not stable and any contracts implementing the calls can check the runtime version to see if it has changed/if their current contract version (self-imposed) supports it.

i.e. like a guard clause