Keep eth address to fetch runtimes data

[buberdds]

Issue raised by Tadej (while using staker dApp as far as I remember) / for frontend sync meeting.

acc without address_preimage (keep eth addr)
https://pr-1564.oasis-explorer.pages.dev/mainnet/sapphire/address/0x95D683e4365209E5ce64f2e26e00C23207fe7Ec3
https://explorer.dev.oasis.io/mainnet/sapphire/address/0x95D683e4365209E5ce64f2e26e00C23207fe7Ec3

acc with address_preimage (works the same way)
https://pr-1564.oasis-explorer.pages.dev/mainnet/sapphire/address/0x8Bba8906467831962Ed5E524F4Bc47733CBF3b27
https://explorer.dev.oasis.io/mainnet/sapphire/address/0x8Bba8906467831962Ed5E524F4Bc47733CBF3b27

Notes: (thx @Andrew7234)

• the address preimage is populated whenever nexus encounters the corresponding evm address of a given oasis style address
• any evm transaction (evm.Create or evm.Call) should create preimage
• the consensus deposit txs are part of the consensusaccounts module and not the evm module, so the tx body of consensus deposit only includes the oasis-style addresses in the tx body and thus Nexus isn’t aware of the corresponding evm address

[github-actions]

Deployed to Cloudflare Pages

Latest commit:	2a8b2700c38a3dc4f13e1afb42b14c028c96afbf
Status:	✅ Deploy successful!
Preview URL:	https://dbe8e57c.oasis-explorer.pages.dev
Alias:	https://pr-1564.oasis-explorer.pages.dev

[lukaw3d]

@lubej @csillag are checks like this still needed to handle some empty state

[buberdds]

oasisAddress used to be async. Since it is sync now and address is always true (loader would fail earlier if not) then I think it is not use to handle empty state

[lukaw3d]

I would refactor this as:

const fallbackMaybeEthAddresses = [params?.rel]
const fallbackEthAddressesMap: { [oasis1Address: string]: `0x${string}` } =
  Object.fromEntries(
    fallbackMaybeEthAddresses.filter(isValidEthAddress).map((eth) => [getOasisAddressOrNull(eth), toChecksumAddress(eth)])
  )

return {
  ...tx,
  to_eth: tx.to_eth ?? fallbackEthAddressesMap[tx.to],

[buberdds]

if address map is preferable way than we don't need an array, fromEntries, filter, map as we deal with a single address. Added a new commit with helper function.

[lukaw3d]

Hm, looks like we really don't have any EVM queries that support multiple address fields. nevermind

[lukaw3d]

Something broke search:

• Before: 6 results https://explorer.dev.oasis.io/search?q=oasis1qzmqhh4r8g2u49aja0qsvzu68jxxk8jrw5pfc9ul
• After: 2 results https://pr-1564.oasis-explorer.pages.dev/search?q=oasis1qzmqhh4r8g2u49aja0qsvzu68jxxk8jrw5pfc9ul

[buberdds]

Ok, search will behave the same way. Discord test is failing (not related to changes)

[lukaw3d]

Ooooh, so searching for "0x95D683e4365209E5ce64f2e26e00C23207fe7Ec3" would have still found the 4 results

[buberdds]

Yes, search functionality is not affected by this PR. For now we want to tweak account view with eth address once you navigate from dApp. Will look at search later this week.