Contract state should provide proofs from state root

[ilblackdragon]

Given contract state queried from the node, we need also to provide a proof from this state (or part of the state) to the root of the state root that's in the block header.

[ilblackdragon]

Here is how Ethereum does proofs for storage:

• EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof  ethereum/EIPs#1186
• https://github.com/ethereum/wiki/wiki/json-rpc#getproof-returns

[MaksymZavershynskyi]

Since we decided to use events differently (see Near-One/rainbow-bridge#12) this is no longer a blocker for EthDenver.

[ilblackdragon]

One important point that people need is also proof of state non existence of some data.
E.g. if specific key is been queried from the state - it would be good to have a proof that key is not in the state.

[bowenwang1996]

One important point that people need is also proof of state non existence of some data.

@ilblackdragon could you provide a use case?

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[ilblackdragon]

Use case is connecting to IBC. Pretty much IBC is using proof of non existance for expiration of the message communication - for example if message wasn't delivered and it expired, the non existnance proof can provide evidence for the other chain that message wasn't delivered and for example tokens can be released back.

…

On Tue, Aug 31, 2021 at 4:55 PM stale[bot] ***@***.***> wrote: This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABK27TPFSG2MY5ZE3EW5FDT7VTYJANCNFSM4KPNXYEA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Best regards, Illia Polosukhin

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[bhc8521]

how can i verify a contract's state provided by rpc? if it is specified to a single key-value pair, that would be helpful, thanks.

[blasrodri]

Hi! As per (2) in https://gov.near.org/t/near-polkadot-using-ibc-trustless-bridging-requests/22807 we are in need of having this. I'd like to get some mentoring/tutoring and take the issue in my hands

[mfornet]

how can i verify a contract's state provided by rpc? if it is specified to a single key-value pair, that would be helpful, thanks.

@bhc8521 you can get specific values on the state by calling an RPC method. Check it in the documentation: https://docs.near.org/docs/api/rpc/contracts#view-contract-state

[folex]

how can i verify a contract's state provided by rpc? if it is specified to a single key-value pair, that would be helpful, thanks.

@bhc8521 you can get specific values on the state by calling an RPC method. Check it in the documentation: https://docs.near.org/docs/api/rpc/contracts#view-contract-state

@mfornet view_state does not return proofs, it returns empty vec instead. Or am I missing something?

for example, some random contract on testnet:

% curl -X POST \
     -H 'Content-Type: application/json' \
     -d '{
          "jsonrpc": "2.0",
          "id": "dontcare",
          "method": "query",
          "params": {
            "request_type": "view_state",
            "finality": "final",
            "account_id": "dev-1673415696476-75551828987522",
            "prefix_base64": ""
          }
        }' \
     https://rpc.testnet.near.org
{"jsonrpc":"2.0","result":{"block_hash":"4V6Wi5nbgukprRR4NkaqK5pd6tA3xzE2mwRcM7dUuQns","block_height":113511599,"proof":[],"values":[{"key":"U1RBVEU=","proof":[],"value":"AQAAAGEAQGNSv8YBAAAAAAAAAAAAfQAAAAAAAAABAAAAbQ=="},{"key":"YQwAAAB5b2NuLnRlc3RuZXQ=","proof":[],"value":"AAAAAAAAAAAAAAAAAAAAAA=="},{"key":"YREAAABrdW1hcjIxOTEudGVzdG5ldA==","proof":[],"value":"AF7QsgAAAAAAAAAAAAAAAA=="},{"key":"YRQAAABmYXJtc3Rha2V5b2MudGVzdG5ldA==","proof":[],"value":"AOKSn77GAQAAAAAAAAAAAA=="},{"key":"bQ==","proof":[],"value":"CAAAAGZ0LTEuMC4wBAAAAFlPQ04EAAAAWU9DTgAAAAg="}]},"id":"dontcare"}

UPD:

If I pass include_proof: true, then it does generate proofs! Yaay ^__^

curl -X POST \
     -H 'Content-Type: application/json' \
     -d '{
          "jsonrpc": "2.0",
          "id": "dontcare",
          "method": "query",
          "params": {
            "request_type": "view_state",
            "finality": "final",
            "account_id": "dev-1673415696476-75551828987522",
            "prefix_base64": "",
            "include_proof": true
          }
        }' \
     https://rpc.testnet.near.org/

{"jsonrpc":"2.0","result":{"block_hash":"H8ggMmhSsQSX2UQsvKLpgEXswbMyqzdKQ1KCSajCf4XV","block_height":113513560,"proof":[[3,1,0,0,0,16,250,128,112,205,72,201,163,77,108,143,120,65,12,251,202,98,202,239,22,78,78,117,31,128,134,166,189,6,151,26,9,200,236,11,99,91,15,0,0,0],[1,135,2,172,25,44,187,213,198,212,214,210,120,117,113,112,227,4,235,115,149,107,99,171,13,95,232,249,167,222,134,72,184,76,246,93,10,160,129,101,71,169,211,30,161,106,37,233,47,36,207,206,5,94,72,5,253,129,10,208,108,27,212,18,121,1...

[folex]

Another question is: how to work around error State of contract aurora is too large to be viewed?

 % curl -X POST \
     -H 'Content-Type: application/json' \
     -d '{
          "jsonrpc": "2.0",
          "id": "dontcare",
          "method": "query",
          "params": {
            "request_type": "view_state",
            "finality": "final",
            "account_id": "aurora",
            "prefix_base64": "U1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUK"
          }
        }' \
     https://rpc.testnet.near.org
{"jsonrpc":"2.0","error":{"name":"HANDLER_ERROR","cause":{"info":{"block_hash":"AuGK66R3CaS9WrvXHJJqscqFTQMihaXb6EYLSrWTpN7J","block_height":113511537,"contract_account_id":"aurora"},"name":"TOO_LARGE_CONTRACT_STATE"},"code":-32000,"message":"Server error","data":"State of contract aurora is too large to be viewed"},"id":"dontcare"}

You see, i've used U1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUKU1RBVEUK as a prefix in the hope that if it's a long enough prefix, then zero key would satisfy and empty result would be returned.

But it seems that prefix_base64 doesn't affect the limitation on the size of contract state. Is it at all possible to view a small piece of state of a big contract?

Thanks!