2.0 Translator refactor

[rozzaswap]

Refactor translator to capture the following for each block:

• [x] State diff values for account & accountstate tables
• [x] Some data structure for tracking the transaction height and new values for both gasprice and revision number
• [x] Transaction raw bytes
• [x] For each transaction, the receipt data (logs, results) but internal transactions are not needed

[guilledk]

Should of groomed this issue way earlier, but here it goes:

overview

The high level goal is to adapt translator for the new Telos EVM 2.0 architecture, where instead of implementing the RPC service ourselves using elasticsearch as database, we are gonna use the newish reth ethereum implementation.

In this new architecture translator still plays the same role but instead of dumping blocks to elastic we are gonna drive a custom consensus client, that will then drive the execution client with its own db and APIs.

objective

First we need to create a new binary format that can be stored to disk and then read by the consensus client when it needs history, and for live reading we are gonna expose the live feed over a socket.

Its important to have in mind translator is written in typescript and the consensus client is rust.

tasks

• [x] Abstract database Connector in order to make new db backend
• [x] Change config format to reflect new db backend options
• [x] Create binary format
  • [x] Implement nodejs client for the format
  • [x] Implement rust client for the format (only reading and streaming)
• [x] Implement Connector using the new format
  • [x] Writing/Reading history
  • [x] Live streaming
• [x] Implement telos-consensus-client block reader
  • [x] Reading history
  • [ ] Live reading
• [x] Testing
  • [x] Start & stop from no data, with data, from genesis etc
  • [ ] Index & verify integrity by hash matching
  • [x] from deploy block
  • [ ] full EBR

[guilledk]

Ok looks like new plan, 2.0 translator will be deprecated in favour of the new telos-translator-rs, still we should continue to use the 2.0 translator branch to import its data into reth.

During the translator 2.0 development we got it to a point where we can import the blocks from the arrow files into reth, we have managed to import up to block 263M~ where we just hit a problem likely related to a diference between our telos.evm contract evm executor and reth's, waiting on @aamirpashaa to find diference as we capture both optraces for the tx in question.

Idea now is to keep this branch arround and use it to import up to head block at which point we will confirm block hashes