[BUG] The DRE node's evaluation result of the contract is inconsistent with the local‘s

[marslab2022]

Describe the bug The DRE node's evaluation result of the contract is inconsistent with the local evaluation result.

This contract（https://sonar.warp.cc/#/app/contract/xks31RaafzhE50J7a-Vg-pLY9bvF6697ApdwYNWj3pw#code） is for trading between $AR (L1) and $TAR token (L2). The seller creates a sell-order, and the buyer transfers specific amount of $AR to seller through two transactions (lock & buy) on L1, and then obtains the corresponding amount of $TAR token. The result of my local evaluation of the token contract(https://sonar.warp.cc/#/app/contract/1t-nSkHPzeo0cs-KPlU6OIJuKCJpcD7g1Dl3ubfYIBg#) is as expected - the swap is done correctly, this is the result of the local evaluation:

exchange contract result:

{
    "version": "v1",
    "code": 200,
    "data": {
        "sortKey": "000001187997,0000000000000,fc118395dfea487977670bb7f47be83d721e719657dbe616b80bbccaf799348e",
        "cachedValue": {
            "state": {
                "owner": "g-HsAODsIOoTG4MgvmeOTmqyA_RKMupujUuok-nrmkg",
                "expires": 15,
                "lockbook": {},
                "orderbook": [
                    {
                        "orderId": "JgMABGn7jJZrhXQovRbrTgEGXhjOdyUdaGTlRrUv-F0",
                        "owner": "g-HsAODsIOoTG4MgvmeOTmqyA_RKMupujUuok-nrmkg",
                        "amount": 99900000,
                        "locked": 0,
                        "lockedBy": [],
                        "price": "10000"
                    }
                ],
                "currentPrice": "10000",
                "tokenAddress": "1t-nSkHPzeo0cs-KPlU6OIJuKCJpcD7g1Dl3ubfYIBg"
            },
            "validity": {
                "JgMABGn7jJZrhXQovRbrTgEGXhjOdyUdaGTlRrUv-F0": true,
                "B2YmWXm5_RuSkGzIBS5AGWkyywiKgh2SJ8EwCcEDhJ4": true,
                "1HB3tc3HFBpFpKtPV4dw22UbjTUCaRsdBKtY3o_IoOs": true
            },
            "errorMessages": {}
        }
    }
}

TAR token contract result:

{
    "version": "v1",
    "code": 200,
    "data": {
        "sortKey": "000001187997,0000000000000,fc118395dfea487977670bb7f47be83d721e719657dbe616b80bbccaf799348e",
        "cachedValue": {
            "state": {
                "logo": "yNmrTqFZ7XpcD_YSE_QFzYD1t5eqo8mGbGHGq4CVzds",
                "name": "tar test token",
                "owner": null,
                "symbol": "TTAR",
                "balances": {
                    "g-HsAODsIOoTG4MgvmeOTmqyA_RKMupujUuok-nrmkg": 9999900000000,
                    "xks31RaafzhE50J7a-Vg-pLY9bvF6697ApdwYNWj3pw": 99900000,
                    "r586OyT4p4rf7LwHuURWmxocII1lkD7vhULRnIrFajg": 100000
                },
                "decimals": 5,
                "allowances": {},
                "description": "test token",
                "totalSupply": 10000000000000
            },
            "validity": {
                "0g7DiwllY5Ma9auEjbB9850vx8WJzX4Z0V1P196ajFY": true,
                "JgMABGn7jJZrhXQovRbrTgEGXhjOdyUdaGTlRrUv-F0": true,
                "1HB3tc3HFBpFpKtPV4dw22UbjTUCaRsdBKtY3o_IoOs": true
            },
            "errorMessages": {}
        }
    }
}

But in the DRE node, result is weired: Exchange contract result(same with local): TAR contract result(notice balances field):

To Reproduce local evalution code: https://github.com/marslab2022/mars_dre_node but with lmdb cache logic commented: versions used in test:

Expected behavior as descripted below.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: evalude on linux(debian)
• Node.js version: v16.10.0
• warp-contracts SDK version: 1.4.6
• warp-contracts plugins being used (+ versions): "warp-contracts-lmdb": "1.1.0"
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context Add any other context about the problem here.

Thanks for help!

[ppedziwiatr]

@Tadeuchi , after a quick analysis - it seems that DRE (all of them) return the state cached for the 1st interaction (the marked sort key is the sort key of the first interaction with a contract)

https://dre-1.warp.cc/contract?id=1t-nSkHPzeo0cs-KPlU6OIJuKCJpcD7g1Dl3ubfYIBg

on the other hand - manual sync - https://dre-1.warp.cc/sync?id=1t-nSkHPzeo0cs-KPlU6OIJuKCJpcD7g1Dl3ubfYIBgI&test=false - does not cause an update - as if the internal SDK state was different from the DRE '2nd' level cache.

[Tadeuchi]

Hi @marslab2022

Thanks very much for a very precise problem description! It seems that we have this issue fixed.

The problem was just as @ppedziwiatr described. DRE nodes have two layers of caching.

1. For SDK usage only (this one was evaluated properly for both contracts).
2. DRE state caching. This one is updated after contract evaluation and used for providing state for all the requests.

We made a small change, so that whenever a contract is evaluated we also update DRE layer 2 cache for all the interacting contracts.

[marslab2022]

Hi @marslab2022

Thanks very much for a very precise problem description! It seems that we have this issue fixed.

The problem was just as @ppedziwiatr described. DRE nodes have two layers of caching.

1. For SDK usage only (this one was evaluated properly for both contracts).
2. DRE state caching. This one is updated after contract evaluation and used for providing state for all the requests.

We made a small change, so that whenever a contract is evaluated we also update DRE layer 2 cache for all the interacting contracts.

Very appreciate for help of team. Will verify this issue :-)

[marslab2022]

HI @Tadeuchi , just checked out state on sonAR, and founded that existing transactions can be evaluated properly. But when I try to make a new transaction (lock & buy), the new one is not evaluated and displayed correctly.(https://sonar.warp.cc/#/app/contract/1t-nSkHPzeo0cs-KPlU6OIJuKCJpcD7g1Dl3ubfYIBg) current state on sonAR: local evaluated state:

{
    "version": "v1",
    "code": 200,
    "data": {
        "sortKey": "000001191937,0000000000000,16e4bb452f636411aa1c144e9a636efb33b7934014f9ae73f4d3171ebda0a844",
        "cachedValue": {
            "state": {
                "logo": "yNmrTqFZ7XpcD_YSE_QFzYD1t5eqo8mGbGHGq4CVzds",
                "name": "tar test token",
                "owner": null,
                "symbol": "TTAR",
                "balances": {
                    "g-HsAODsIOoTG4MgvmeOTmqyA_RKMupujUuok-nrmkg": 9999900000000,
                    "xks31RaafzhE50J7a-Vg-pLY9bvF6697ApdwYNWj3pw": 98900000,
                    "r586OyT4p4rf7LwHuURWmxocII1lkD7vhULRnIrFajg": 1100000
                },
                "decimals": 5,
                "allowances": {},
                "description": "test token",
                "totalSupply": 10000000000000
            },
            "validity": {
                "0g7DiwllY5Ma9auEjbB9850vx8WJzX4Z0V1P196ajFY": true,
                "JgMABGn7jJZrhXQovRbrTgEGXhjOdyUdaGTlRrUv-F0": true,
                "1HB3tc3HFBpFpKtPV4dw22UbjTUCaRsdBKtY3o_IoOs": true,
                "bjoShkfXcXT1gzd5gL-Wfu1Z8PRGHcqFxnQ1dEGeMmY": true
            },
            "errorMessages": {}
        }
    }
}

[marslab2022]

In case you need test new transactions, there is our under-testing dApp(https://arweave.net/ULdA2-x_KIp5MobES4UC-_3Ti-OnhDXU8Jtpj3vtSOw). Just head to trade tab and buy several tokens(set to an enough low price for testing), and check sonAR.

[ppedziwiatr]

Ok, we will investigate it further next week!

[marslab2022]

Hi, team. is there any clue to this issue, please? :-)

[Tadeuchi]

Hi @marslab2022

We investigated the issue further.

L1 transactions, when they arrive at the DRE node, are in the unconfirmed state, and so their evaluation state is not cached. We do this because we do not want to provide an unconfirmed contract state. Eventually they are confirmed, the dre nodes are updated, but it often takes some time.

The release of the new sync mechanism should resolve this issue. L1 transactions publishing will be delayed and so all the transactions will be published after they are confirmed and their order is also confirmed. This way DRE nodes will always evaluate and store the most actual and confirmed state. The new synchronization mechanism is described here: https://github.com/warp-contracts/syncer/issues/40 ETA is around a month or two.

Until then, we will probably set up a DRE node that will provide the most recent state, taking into account also the unconfirmed transactions.

[marslab2022]

Thanks for your explanation. You mean the transaction will not be evaluated unless it is confirmed. If i'm right, it should be 18 blocks to confirm, I guess?

[Tadeuchi]

Yes, we wait 18 blocks to make sure that transaction is confirmed. The newly confirmed transaction will be taken into account during the next evaluation and stored in cache. This will be triggered either by any new incoming transaction or by a manual call using sync endpoint.

[marslab2022]

Thanks. BTW, when do you plan to deploy the DRE node you mentioned? Please let me know if the deployment is complete. Thank you very much for your help.

[marslab2022]

Hi, @Tadeuchi . As you described above, The new Txwill be triggered either by any new incoming transaction or by a manual call using sync endpoint. But as I see, these transactions are still in waiting state - even though I have executed command by endpoint: https://dre-1.warp.cc/sync?id=ChpMKQ61-ng4Z16YrEI3HkFnezfJvCqgxGyhxH8z_DY

Contract: https://sonar.warp.cc/#/app/contract/ChpMKQ61-ng4Z16YrEI3HkFnezfJvCqgxGyhxH8z_DY

[Tadeuchi]

Hi @marslab2022 All the transactions should be evaluated now, but this is a valid remark. I also sometimes experience some problems when calling the sync function. We will look into it.

[marslab2022]

Hi @marslab2022 All the transactions should be evaluated now, but this is a valid remark. I also sometimes experience some problems when calling the sync function. We will look into it.

Really appreciate. Thanks for your valuable time.