offchainlabs / nitro Goto Github PK

As the title of the issue says. Do we want to either remove or make use of the RollupEventBridge. It's adds cost in a number of places since it adds a message to the delayed inbox

We've decided to augment the transaction receipt with a number of additional useful fields that won't be covered by the consensus hash but will be tracked by a syncing node. Next steps are to determine which additional fields we'd like to include, augment the RLP encoded receipt storage struct to include them, and then propagate them throughout the codebase where needed

Currently each address can designate an address as its preferredAggregator, and there is a single chain-wide defaultAggregator address. We want to change these into sets of addresses. This will require addition to some precompile APIs.

Caching is broken when used in multiple concurrent actions, see mymindstorm/setup-emsdk#20

https://github.com/OffchainLabs/nitro/runs/4749888147?check_suite_focus=true#step:14:804

Add full openkeystore functionality from monorepo

https://github.com/OffchainLabs/nitro/runs/4820825500?check_suite_focus=true

I'm not sure what the current behavior is for failed precompile calls, but I think optimally we'd return human readable errors in places that it makes sense. I think that would entail for user directed error messages ABI encoding the error string on return. There's hopefully a single place in the code we could put this rather than having to change many locations, though we might need to put in a different error type to differentiate from out of gas errors.

From rollup-v2 branch

For example, the gas limit configured for an RPC server's eth_call should not be affected by the L1 pricing.

https://github.com/OffchainLabs/nitro/actions/runs/1734712277

This has two purposes:

• Allows clients to figure out what size send tree they need to prove against (needed to prove withdrawals on L1)
• Allows clients to binary search to find the adjacent nodes they need to create the merkle proof.

If the beneficiary is a smart contract, it may have an assumption that if it cancels the retryable the retryable will never run and it will get the funds. That's not currently upheld if the cancel is inside the execution of the same retryable.

Right now we don't expose a user-friendly way to estimate how much a redeem will cost. A user could get the details of the retryable and execute an equivalent eth_call, but it would be a lot easier if they could simply gas estimate the redeem itself.

https://github.com/OffchainLabs/nitro/actions/runs/1688575887/attempts/1

Two major advantages of signing these are

• We don't need to trust the Redis server for correctness. Worst case of corruption there without this is we cause a reorg and post batch data that we don't get paid for
• We reduce the security risk on the Redis server since write access doesn't give you the ability to lie

These include txs where the account has no balance, has the wrong nonce, has too low of a gas limit, or has a different preferred aggregator set.

My guess is something's going wrong on shutdown, but unfortunately Go doesn't tell us what went wrong, just that it failed.

https://github.com/OffchainLabs/nitro/runs/4662794079?check_suite_focus=true

We currently test that challenges can be timed out if the amount of time since the last move is greater than the total challenge clock, but we don't have test coverage to validate that the amount of time left actually decreases. It would be useful to have a timeout test that periodically makes a move in a challenge slowly enough that it will run out of time before it reaches the end to verify that that element of the timeout process

Refactor geth's ToMessage to make it aware of the chain config or simply remove the check in InterceptRPCGasCap

We have code for taking the typed-contents of an event and creating a log, but currently there's no mechanism to go the other direction

We should decide if this behavior makes sense. One question is how does standard go-ethereum react in a similar situation. We should try and model our behavior after that

The retryable precompile redeem method has to calculate how much gas to donate to the retry attempt by calculating the amount of gas that will be left beyond the gas charged for the other operations in the precompile. It's bit tricky to maintain the math correctly so it would be great to have a test which makes sure the gas used by it is exactly equal to the gas sent.

There are a bunch of different config config options that have developed associated with the nitro node seen in

Currently we're just using the standard go flags library and we'll presumably want to move to a more comprehensive config system

We've had a good experience with koanf from the classic Arbitrum node software so I think using that probably makes sense. The alternative would be to use Geth's home brew config param library, but I think that would likely be more complex

https://github.com/OffchainLabs/nitro/runs/5008250385?check_suite_focus=true

We currently don't have an established Solidity formatting standard. We should consider establishing one and running it in CI.

Gas estimation should take into account a potential change in the L1 gas price estimate between estimation and when the tx is submitted

Zero bytes are no longer inherently cheaper in nitro due to the compression used, but due to their prevalence in calldata they are in effect easier to compress. Therefore, we should consider charging 1/4 the gas for them as L1 Ethereum does, to incentivize heuristically easier to compress data.

Depends on #143

This disables Geth's nonce handling and thus might be unsafe. We should review where it's used and what the alternatives are.

We'll probably largely copy this code over from the classic stack.

Currently this is done manually, as it was added well before the HeaderInfo system

Currently it's just in-memory, which means that validators will stop working (or re-validate all blocks?) on restart.

Database directory should by default resolve to ~/.arbitrum/mainnet/chaindata/

Fixed by #324

We have a good strategy for handling gas estimation of retryable redeems, but don't have a method for handling estimation for autoredeems. In classic we use the NodeInterface method called estimateRetryableTicket https://github.com/OffchainLabs/arbitrum/blob/005badd0f7beff05c222bf9d6d301564aa2b8f10/packages/arb-bridge-peripherals/contracts/rpc-utils/NodeInterface.sol#L54 implemented in https://github.com/OffchainLabs/arbitrum/blob/master/packages/arb-rpc-node/web3/nodeInterface.go.

Some sort of estimation system is critical for implementing autoredeems which is core functionality for retryables

In the new batch scheme, we just measure the tx size, and there's no additional fixed overhead. We should consider having getTxBaseFee always return 0 and not actually store a tx base fee.