Issue with double hashing of code in DeployGlobalContract action

[frolvanya]

https://testnet.nearblocks.io/txns/DuSJsFHrDeCprVfVvpWinQd6nYmYzCWLo5hHnuqUgyHr?tab=execution

near_primitives::views::ActionView::DeployGlobalContract has a field code, but in reality it's a code_hash, so we try to deploy global code hash like EXXAovPjpJNsScZuX6qd9Ypag9P7N1ispyU2ypauQVGY it becomes 67RrrvBk6k7oFv9Gi6Qex8H657tWUDqz9v79nnYgtX7Ta in nearblocks after another round of hashing, which is confusing for users. Can we remove double hashing for DeployGlobalContract variant?

More details can be found here:
https://near.zulipchat.com/#narrow/channel/295558-core/topic/nearblocks.20Deploy.20Global.20Contract.20code_hash.20mismatch/with/564840887

[andrewklau]

Hi @frolvanya

When we index/receive the code arg we received with DeployGlobalContract: S/AHRT758DDYMuyOIKyQXm2J6gbrXSSy8NGwDnUOFzY=.

How do we get the "actual" code hash (EXXAovPjpJNsScZuX6qd9Ypag9P7N1ispyU2ypauQVGY) from this?

For reference this code arg we are getting comes from near lake/neardata

We don't do any additional processing from what we receive

[frolvanya]

$ http POST https://archival-rpc.testnet.fastnear.com jsonrpc=2.0 id=dontcare method=EXPERIMENTAL_tx_status params:='{"tx_hash": "DuSJsFHrDeCprVfVvpWinQd6nYmYzCWLo5hHnuqUgyHr", "sender_account_id": "abc", "wait_until": "FINAL"}' | jq

Raw rpc call gives me this hash:

"DeployGlobalContract": {
    "code": "yPl3djv2wODdYDiH32CPAvcMRFoUb2ON8B0EksOnRq0="
}

Which is the correct initial hash of wasm

$ node -e "const b='yPl3djv2wODdYDiH32CPAvcMRFoUb2ON8B0EksOnRq0=',a='123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz',d=Buffer.from(b,'base64');let n=0n;for(const x of d)n=(n<<8n)+BigInt(x);let s='';while(n){s=a[Number(n%58n)]+s;n/=58n;}console.log(s||a[0]);"

EXXAovPjpJNsScZuX6qd9Ypag9P7N1ispyU2ypauQVGY

But near-lake returns multiple different hashes (correct one in transactions, but receipt_execution_outcomes has a double hashing problem). I'll look more into it
qq.json

[frolvanya]

Turns out there was a regression on near-indexer side that was introduced as a part of 2.10 release. Here's a patch: near/nearcore#14840