feat: environment logs

[Autoparallel]

Work Done

In this PR, I update the ArbiterDB to also store a HashMap of block numbers to logs emitted in that block. As a bonus, we:

• Close feat: Implement get_logs() #869

---

OLD STUFF HERE

Idea

What I'm trying to do here is allow the Environment to store a global_db: BTreeMap<U256, CacheDB> so that each KV pair in the global_db will be a representation of the state at the end of the block, including logs that were emitted.

The goal here is to create a workable db organized by blocks so that (middleware or otherwise) requests that can take in a block_number can be satisfied by lookup in this db. Furthermore, if we can take this global_db and output it into hard storage, we can use this for extracting data from and analysis with. Tools like cryo become more of an option for us, and we could conceivably avoid having to use the events::Logger.

Progress

• Added 3loc to the ArbiterInspector that will collect logs into the evm.
• Added logic in the Instruction::BlockUpdate that will add the current CacheDB into the global_db and clear the logs.

Questions

• There is a tradeoff here of storing the whole state each time versus storing diffs. Storing the whole state can cause bloat in memory and is in some sense unnecessary. However, computing diffs could be inefficient in speed and would cost more in reconstruction of state later on.
  • What is the right choice?
  • Do we provide optionality here?
  • Can we look towards reth for inspiration on how to handle this nicely?
• Can we offload some of this additional complexity with concurrency/parallelism? The events::Logger uses its own thread to do work. Perhaps we could do something of the same sort.
• What will benchmarks say here? We definitely need to do some and compare against Anvil yet again.
• If we don't want to store the whole chain state for any of the above reasons or otherwise, we can certainly just store logs which is a great start!
  • What is the minimal set of items to store to give excellent end-user analysis tooling? Sometimes having the right things emitted as logs is tough.
  • What ways can we collect the "right set of items" that could be ergonomic and efficient? For instance, perhaps we can set up inspectors in such a way to monitor specific contract state if that is really our goal. Inspectors can monitor if certain storage locations are hit for sure, but this could be tough to implement properly.

---

Let's please discuss this. I think that something along these lines and leading into an arbiter-analysis crate that uses Rust-eth tools like cryo could reduce complexity in using the data output by Arbiter if done correctly.

[0xJepsen]

You dirty dog doing the weekend cook session 🧑🏼‍🍳

[0xJepsen]

I am very curious what the speed implications are for this. I agree that benchmarks are important.

[Autoparallel]

The least expensive would be to just store the logs which shouldn't be too bad at all.

[0xJepsen]

Whats the intuition of calling it tip? Like it's the front of a queue? Or top of a stack? The latest?

[0xJepsen]

🌝

[0xJepsen]

this seems pretty clear and straightforward to me. I think this is a good step towards the right abstraction of blocks