inphi / optimism-rosetta Goto Github PK

Context: maticnetwork/polygon-rosetta#25

This is not an issue on Optimism right now because our l2geth is based on an older version of geth that isn't affected by this bug. However, post-bedrock, we'll be using the latest upstream, vanilla geth.

The estimateGas Value arg isn't used on Optimism so it won't hurt to add it right now to avoid breakage in the future.

Describe the bug
I am not able to get the response that includes the OP token transaction when calling /block API, I think the reason is we need to update the new contract address here: https://github.com/Inphi/optimism-rosetta/blob/master/optimism/client.go#L483, we can expose it as env var or config instead of hardcode

Describe the bug
The block and account balance issues have been fixed, many thanks! I find another issue on /construction/preprocess with the following error:

2022/02/28 22:11:42 REQUEST /construction/preprocess network_identifier:{"blockchain":"Optimism","network":"Testnet"} intent:[{"operation_identifier":{"index":0},"type":"PAYMENT","account":{"address":"0x9670d6977d0b10130E5d4916c9134363281B6B0e"},"amount":{"value":"-100000000000","currency":{"symbol":"OP","decimals":18,"metadata":{"token_address":"0xF8B089026CaD7DDD8CB8d79036A1ff1d4233d64A"}}}},{"operation_identifier":{"index":1},"related_operations":[{"index":0}],"type":"PAYMENT","account":{"address":"0x705f9aE78b11a3ED5080c053Fa4Fa0c52359c674"},"amount":{"value":"100000000000","currency":{"symbol":"OP","decimals":18,"metadata":{"token_address":"0xF8B089026CaD7DDD8CB8d79036A1ff1d4233d64A"}}}}] metadata:null
2022/02/28 22:11:42 ERROR /construction/preprocess error:{"err":{},"client_err":{"code":4,"message":"Unable to parse intent","retriable":false,"details":{"context":"unable to find match for operation: at index 0"}},"retry":false}
2022/02/28 22:11:42 check:construction status server shutting down
[MEMORY] Heap: 4078.060371MB Stack: 1.343750MB System: 4235.299797MB GCs: 3

Error: request failed: /construction/preprocess {Code:4 Message:Unable to parse intent Description:<nil> Retriable:false Details:map[context:unable to find match for operation: at index 0]}: unable to preprocess: unable to create transaction

The root cause is in matchTransferOperations function: https://github.com/Inphi/optimism-rosetta/blob/master/services/construction_service.go#L712, we still use CALL operation type to match, but OP token transfer contract call uses PAYMENT as operation type.
To fix this, I think we need to ensure matchTransferOperations supports both CALL for native token and PAYMENT for OP/ERC20 token

Describe the bug
I find a reconciliation issue on mainnet:

Error: reconciliation failure: active reconciliation error for 0x40C539BBe076b91FdF681E6B4B84bd1Fe1F148d9 at 1502839 (computed: 0ETH, live: 100000000000000ETH)

The problem is for 0x40C539BBe076b91FdF681E6B4B84bd1Fe1F148d9(seems like it’s a contract account) at height 1502839, the computed balance is different from the live balance

I check the /block at height 1502839 and notice that the SELFDESTRUCT operation deducts 100000000000000 from the account, that’s why the computed balance is 0. But from the explorer https://optimistic.etherscan.io/tx/0x3ff079ba4ea0745401e9661d623550d24c9412ea9ad578bfbb0d441dadcce9bc seems like there is no any funds transfer/deduction from the account with the SELFDESTRUCT operation. To fix this, we may need to handle the SELFDESTRUCT properly for /block

{
                        "operation_identifier": {
                            "index": 2
                        },
                        "type": "SELFDESTRUCT",
                        "status": "SUCCESS",
                        "account": {
                            "address": "0x40C539BBe076b91FdF681E6B4B84bd1Fe1F148d9"
                        },
                        "amount": {
                            "value": "-100000000000000",
                            "currency": {
                                "symbol": "ETH",
                                "decimals": 18
                            }
                        }
                    }

Describe the bug
I test our testing account 0x9670d6977d0b10130E5d4916c9134363281B6B0e at height 1241242, then get the following response

{
    "block_identifier": {
        "index": 1241242,
        "hash": "0x9743df7f8f49faa952401c9ab3628f813016a9c42194a759d5cc636b216338d4"
    },
    "balances": [
        {
            "value": "1009271209351159315",
            "currency": {
                "symbol": "ETH",
                "decimals": 18
            }
        }
    ],
    "metadata": {
        "code": "0x",
        "nonce": 74
    }
}

The response doesn’t return the balance of the OP token, I think we need to investigate and fix it, also FWIW we can always use this transaction https://kovan-optimistic.etherscan.io/tx/0x0a0cfe735e0fc3549db81d07670e98d18d9f909de44ef9ad0446725b0d7a806c for quick testing as it’s the OP token transfer transaction for our testing account

Describe the bug
I find an issue related to /block API for ERC20 token with the following errors:

Error: unable to fetch block 11516: Amount.Value is not an integer: <nil>: amount is invalid in operation 2 invalid operation in transaction 0x859431549be32cccca16c3f41ca8c9d4ffc73eca7eb75ba0868b0d6b6aa336e7: /block: /block not attempting retry: unable to sync to 1410879: unable to sync to 1410879

Manually try the /block API on 11516 can also detect the <nil> amount

{
                        "operation_identifier": {
                            "index": 2
                        },
                        "type": "CALL",
                        "status": "SUCCESS",
                        "account": {
                            "address": "0x0000000000000000000000000000000000000000"
                        },
                        "amount": {
                            "value": "<nil>",
                            "currency": {
                                "symbol": "ETH",
                                "decimals": 18
                            }
                        }
                    }

I think root cause may be from here: https://github.com/Inphi/optimism-rosetta/blob/master/optimism/client.go#L764, which doesn’t handle the error properly and results in <nil> amount

Overview

Average gas usage on optimism is at least 30-50% more than L1. On some days, we see gas usage up by 200-500% (etherscan has charts on this). So I'm concerned that tracing an entire block rather than per transaction would be too expensive for op-geth. Tracing consumes alot of CPU, memory and I/O for the response back and we've seen each of these resources being exhausted for legacy geth.

I'd prefer that we trace individually by transaction. But for now, let's add a TODO here so we don't forget to treat this properly.

Additional context
#77 (comment)

Describe the bug
We notice the difference on genesis hash between /network/status and /block, for testnet
Response of /network/status

{
    "current_block_identifier": {
        "index": 1423803,
        "hash": "0x3d286b93b8524a64aad1f60ef3d5ff1f52a4b3b59acfcfce6f499e5c0fd1509e"
    },
    "current_block_timestamp": 1646850196000,
    "genesis_block_identifier": {
        "index": 0,
        "hash": "0x41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d"
    },
    "sync_status": {
        "current_index": 1423803,
        "target_index": 1423803
    },
    "peers": null
}

Respsone of /block

{
    "block": {
        "block_identifier": {
            "index": 0,
            "hash": "0x02adc9b449ff5f2467b8c674ece7ff9b21319d76c4ad62a67a70d552655927e5"
        },
        "parent_block_identifier": {
            "index": 0,
            "hash": "0x02adc9b449ff5f2467b8c674ece7ff9b21319d76c4ad62a67a70d552655927e5"
        },
        "timestamp": 0,
        "transactions": []
    }
}

The genesis hash from /network/status is 0x41941023680923e0fe4d74a34bdac8141f2540e3ae90623718e47d66d1ca4a2d but the genesis hash from /block is 0x02adc9b449ff5f2467b8c674ece7ff9b21319d76c4ad62a67a70d552655927e5. I think root cause is that we hardcode genesis hash for /network/status from here: https://github.com/ethereum-optimism/optimism/blob/develop/l2geth/params/config.go#L31, but it’s different from the live genesis hash

Debugging transactions using a noop tracer executes pretty quickly. For example, running the rosetta call_tracer on 0x47cecb28aeb8c029644b772e9e99e3305d06562fd53c239c2a20c278089231d7 takes several minutes to compute. Whereas, awith a noop call tracer, tracing completes in under 10 seconds.

This suggests that we could improve the call tracing somewhat via scripting to avoid timeouts. One idea I have in mind is splitting up the work of executing a call trace into multiple work units. Each work unit will trace a fraction of the execution. Once all work units are complete, they can be concatenated as a single large transaction trace. The idea here is each workunit is less likely to timeout individually. We may even be able to run multiple work units in parallel and exploit multiprocessing on l2geth. Of course, figuring out how to split up tracing is key.

Another idea is to offload VM execution log parsing to the rosetta server. Perhaps it'll be fast to transmit the entire unprocessed execution trace to be processed in optimized Go code, rather than doing it in the suboptimal javascript engine running on geth.

Is your feature request related to a problem? Please describe.
L1 node inside rosetta server: https://github.com/Inphi/optimism-rosetta/blob/master/Dockerfile#L40 needs to be removed. IMO, we specify the remote l1 node in data transport layer container and specify l2 node as env var in our rosetta server, so the l1 node (from https://github.com/ethereum/go-ethereum) inside rosetta server can be removed.

Description

Previously, we have explicitly ignored transaction traces to avoid excessive bloat in the returning Rosetta transaction.metadata.trace field.

We should be either (or both): structuring and returning transaction traces as well as adding a config flag for whether the trace field should be populated in the transaction metadata.