Commit graph

4 commits

Author SHA1 Message Date
Ahmad Kaouk
0618e84268
feat: set POV gas limit ratio to zero for solo chain (#313)
Set `GasLimitPovSizeRatio` to 0 across all runtime environments
(mainnet, stagenet, testnet) since DataHaven operates as a solo chain
and doesn't need to account for Proof-of-Validity size constraints that
parachains require.

  ## ⚠️ Breaking Changes ⚠️
  - `GasLimitPovSizeRatio` is now set to 0 across all runtimes
  - Gas calculations will no longer account for POV size constraints
2025-11-27 11:14:41 +01:00
Ahmad Kaouk
55e973b8f0
fix: change pallet_evm alias to EVM to fix eth_getCode (#213)
## Summary
- rename the FRAME alias for `pallet_evm` from `Evm` to `EVM` across the
mainnet, stagenet, and testnet runtimes
- adjust benchmarks, configuration modules, genesis builders, and
runtime tests to rely on the new alias
- keep precompile genesis setup and proxy/precompile tests aligned with
the updated names

  ## Context
Frontier’s `StorageOverrideHandler` (see
`fc_storage::StorageQuerier::account_code`) reads contract bytecode from
`pallet_evm::AccountCodes` using the constant `PALLET_EVM = b"EVM"` to
build the storage key:
  `twox_128("EVM") ++ twox_128("AccountCodes") ++ …`

Our runtimes exported `pallet_evm` as `Evm`, so substrate stored
bytecode under the *camel-cased* prefix (`twox_128("Evm")`). Every call
that ultimately hits the storage override—including `eth_getCode`,
`eth_call`, and state queries during replay—therefore failed to locate
code for *any* account (deployed contracts and precompiles alike).
Renaming the alias to `EVM` realigns the storage prefix with Frontier’s
  expectations so the override layers can pull bytecode correctly.

  ## Testing
  - `cargo check -p datahaven-node`
  - `cargo build --release -p datahaven-node`
- `eth_getCode 0x0000000000000000000000000000000000000802` → returns
`0x60006000fd`
  
## Storage Migration
Renaming a pallet alias changes the storage prefix for all pallet data.
Without migration, existing EVM data (smart contracts, account codes,
storage) would become inaccessible.

  **Migration details:**

  - **Type**: Multi-Block Migration (MBM)
- **Storage migrated**: `AccountCodes`, `AccountCodesMetadata`,
`AccountStorages`
  - **Migration ID**: `datahaven-evm-mbm` (version 0 → 1)

  **Testing the migration:**

  ```bash
  # Build runtime with try-runtime
cargo build --release --features try-runtime -p
datahaven-stagenet-runtime

  # Test against stagenet
try-runtime \
--runtime
./target/release/wbuild/datahaven-stagenet-runtime/datahaven_stagenet_runtime.wasm
\
      on-runtime-upgrade \
      --blocktime 6000 \
      --checks all \
      --disable-spec-version-check \
      live --uri wss://dh-validator-0.datahaven-kt.xyz
```

  Test results from stagenet:
  -  Migration completes in 1 block
  -  PoV size: ~5.3 KB
  -  Weight consumption: <0.1% of block capacity
  -  All 39 keys successfully migrated

  ## ⚠️ Breaking Changes ⚠️
If you are manually computing storage keys for the EVM pallet (e.g., directly querying chain state), you must update your code to use the new storage prefix:
  - Old prefix: twox128("Evm") = 0x8b90cb...
  - New prefix: twox128("EVM") = 0x6a5e91...

  All EVM-facing interfaces remain unchanged.
2025-10-10 17:48:52 +00:00
Steve Degosserie
91e29700a3
feat: Bump client version to v0.2.0 & runtime spec_version to 200 (#194) 2025-09-29 23:35:12 +02:00
Ahmad Kaouk
788e5efaa4
feat: Add proxy Precompile (#155) 2025-09-12 09:45:26 +02:00