pallet-revive: expensive reverse lookup needed since ReviveApi.call requires SS58 origin but contracts use H160 msg.sender

[BigTava]

Problem

When performing a read-only dry-run via ReviveApi.call, the origin parameter must be an SS58 account address. Inside the contract, msg.sender resolves to the corresponding H160 (EVM) address. This means that to read data stored under a specific user's msg.sender, the caller must first reverse-lookup the H160 → SS58 mapping via Revive.OriginalAccount storage.

This is a significant bottleneck for apps that need to enumerate data across many contracts.

Concrete example

The DotNS Store contract stores values per-user:

mapping(address user => string[] userValues) private values;

function getValues() external view returns (string[] memory) {
    return values[msg.sender]; // keyed by caller's H160
}

A StoreFactory deploys one Store per user. To enumerate all values across all stores, an app must:

1. Call StoreFactory.getAllDeployedStores() → 363 store addresses
2. For each store, call Store.owner() → get the owner's H160
3. For each H160, query Revive.OriginalAccount → get the SS58 address
4. Call Store.getValues() with the SS58 as origin, so msg.sender matches

Step 3 is the bottleneck: 363 individual substrate storage queries, each requiring a state proof through the light client.

Steps 1, 2, and 4 can all be batched via Multicall3 (a single ReviveApi.call per batch). Step 3 cannot — it's a pallet storage query, not a contract call.

Possible solutions

1. Accept H160 directly as origin in ReviveApi.call — if the caller passes a 20-byte address, skip the SS58→H160 mapping and use it as msg.sender directly. This would eliminate the reverse lookup entirely for read-only dry-runs.

2. Provide a batch/multi-key query for Revive.OriginalAccount — allow querying multiple H160→SS58 mappings in a single RPC call (e.g. state_queryStorageAt with multiple keys, or a dedicated runtime API).

3. Add a ReviveApi.call_as(h160, contract, data) variant — explicit API for "call this contract as if msg.sender were this H160 address", for dry-run/simulation purposes only.

4. Expose OriginalAccount as a contract-callable precompile — so the reverse lookup can be batched through Multicall3 alongside other contract calls.

[BigTava]

@smiasojed Following your suggestion, I tried using ReviveApi.eth_transact to pass the H160 owner directly, eliminating the expensive H160→SS58 reverse lookup entirely:

const result = await api.apis.ReviveApi.eth_transact({
  from: ownerH160,           // H160 directly — no SS58 lookup needed
  to: storeContract,         // Store contract address
  input: getValuesCalldata,  // encoded Store.getValues()
});

Results

7 out of 10 stores work. 3 large stores fail with proof_size exceeding the 4MB block limit:

store[0] → ❌ proof_size: 4514457 > allowed: 4194304
store[1] → ✅ 156 labels
store[2] → ✅ 296 labels
store[3] → ✅ 20 labels
store[4] → ✅ 12 labels
store[5] → ✅ 2 labels
store[6] → ✅ 59 labels
store[7] → ✅ 19 labels
store[8] → ❌ proof_size: 5954911 > allowed: 4194304
store[9] → ❌ proof_size: 6119535 > allowed: 4194304

Reproduction script

#!/usr/bin/env node
// Repro: ReviveApi.eth_transact proof_size limit
// Dependencies: polkadot-api, @noble/hashes  |  Run: node repro.mjs
import { createClient } from "polkadot-api";
import { Binary, FixedSizeBinary } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws-provider/node";
const { keccak_256 } = await import("@noble/hashes/sha3.js");

const STORE_FACTORY = "0x030296782F4d3046B080BcB017f01837561D9702";
const ZERO = "0x0000000000000000000000000000000000000000";

const sel = (sig) => "0x" + Array.from(keccak_256(new TextEncoder().encode(sig)).slice(0, 4), b => b.toString(16).padStart(2, "0")).join("");
const SEL_GET_ALL = sel("getAllDeployedStores()");
const SEL_GET_VALUES = sel("getValues()");
const SEL_OWNER = sel("owner()");

function decodeAddressArray(hex) {
  hex = hex.replace(/^0x/, "");
  const off = parseInt(hex.slice(0, 64), 16) * 2;
  const len = parseInt(hex.slice(off, off + 64), 16);
  return Array.from({ length: len }, (_, i) => "0x" + hex.slice(off + 64 + i * 64 + 24, off + 64 + i * 64 + 64));
}

function decodeAddress(hex) { return "0x" + hex.replace(/^0x/, "").slice(24, 64); }

async function ethTransact(api, to, data, from) {
  const r = await api.apis.ReviveApi.eth_transact({
    from: FixedSizeBinary.fromHex(from), to: FixedSizeBinary.fromHex(to),
    input: { data: Binary.fromHex(data) },
    authorization_list: [], blob_versioned_hashes: [], blobs: [],
  });
  if (!r.success) throw new Error(r.value?.value ?? JSON.stringify(r.value));
  const d = r.value?.data;
  return typeof d === "string" ? d : d?.asHex?.() ?? d?.toHex?.() ?? "0x";
}

const provider = getWsProvider("wss://sys.ibp.network/asset-hub-paseo");
const client = createClient(provider);
await client.getFinalizedBlock();
const api = client.getUnsafeApi();

const stores = decodeAddressArray(await ethTransact(api, STORE_FACTORY, SEL_GET_ALL, ZERO));
console.log(`Found ${stores.length} stores\n`);

for (let i = 0; i < Math.min(10, stores.length); i++) {
  const store = stores[i];
  try {
    const owner = decodeAddress(await ethTransact(api, store, SEL_OWNER, ZERO));
    const raw = await ethTransact(api, store, SEL_GET_VALUES, owner);
    const labelCount = parseInt(raw.replace(/^0x/, "").slice(64, 128), 16);
    console.log(`store[${i}] → ✅ ${labelCount} labels`);
  } catch (err) {
    const m = String(err.message);
    const ps = m.match(/proof_size: (\d+)\).*?proof_size: (\d+)\)/);
    console.log(ps
      ? `store[${i}] → ❌ proof_size: ${ps[1]} > allowed: ${ps[2]}`
      : `store[${i}] → ❌ ${m.slice(0, 120)}`);
  }
}

client.destroy();

[smiasojed]

store[0] → ❌ proof_size: 4514457 > allowed: 4194304

I think you hit the limit modified by @pgherveou : MaxEthExtrinsicWeight = 0.5.
To use the full block proof_size, you can’t use an ETH transaction. We could increase the limit to 0.7, but that has other side effects.

[BigTava]

@smiasojed Thanks. Is there another workaround I should try? Do you have anything in the pipeline that would let me run these queries?

[smiasojed]

if your contract call requires more than 4MB of proof_size - you need to switch to substrate extrinsics or you need to limit the size of data you store in single extrinsic. Another option is to rethink the limits we have in chain configuration but it is a longer story.