…idation (#220)

**Motivation**

Fetch cancun time from DB when validating payload v3 timestamp

<!-- Why does this pull request exist? What are its goals? -->

**Description**

* Store cancun_time in db
* Use the stored cancun_time when validating payload timestamp in
`eth_newPayloadV3`
* Replace update methods for chain data in `Store` with
`set_chain_config`

Bonus:

* Move `NewPayloadV3Request` to its corresponding module and update is
parsing to match the rest of the codebase

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is part of #51

**Motivation**

Having a way to obtain lates/earliest/pending/etc block numbers

<!-- Why does this pull request exist? What are its goals? -->

**Description**

* Add get and update methods for earliest, latest, finalized, safe &
pending block number to `Store` & `StoreEngine`
* Resolve block numbers from tag in rpc methods

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but fixes many and enables others

…pts & withdrawals (#225)

**Motivation**

These roots are currently being calculated using `from_sorted_iter` but
without being sorted beforehand. This PR replaces this behavior with
inserting directly into the trie to ensure that it is ordered, then
computing the root (The same fix that has been previously applied to
storage root)

**Description**

Fixes `compute_transactions_root`, `compute_receipts_root` &
`compute_withdrawals_root`
<!-- A clear and concise general description of the changes this PR
introduces -->

**Notes**

After this change, the payloads created by kurtosis local net now pass
the block hash validations in `engine_NewPayloadV3`
<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is needed for #51

Co-authored-by: Federica Moletta <federicamoletta@MacBook-Pro-de-Federica.local>

…ierOrHash` (#374)

**Motivation**
Checking that the hex values for the block field of rpc requests have a
"0x" prefix and returning the correct rpc error if they don't

<!-- Why does this pull request exist? What are its goals? -->

**Description**
* Replace `Deserialize` iml of `BlockIdentifier` &
`BlockIdentifierOrHash` with a `parse` method that returns the correct
`RpcError` upon failure and checks for correct prefixes
* Move `BlockIdentifier` & `BlockIdentifierOrHash` to a separate module
under rpc/types
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #371

**Motivation**

Being able to create a `Trie` struct representing the world state based
on the engine's internal value store (reading from a specific table in
the case of libmdbx or map in the case of in_memory). The created trie
would also use the given block's state root as its root in order to
query historical data build new blocks based on the previous block's
state, and easily process re-orgs

<!-- Why does this pull request exist? What are its goals? -->

**Description**
Added features:
* Add `world_state` method to `StoreEngine` api, which builds a `Trie`
from a block number and the engine's internal database (or value store)

Code refactors:
* Remove `DB` generic from `Trie` and instead store `Box<dyn TrieDB>`
(This is because the generic wouldn't allow us to return a single
generic `Trie<DB>` from different `StoreEngine` implementations)
* Store `Arc<Database>` instead of `&'a Database` in libmdbx impl of
`TrieDB` (This is so we can box it)
* Store `Arc<Database>` instead of `Database` in
`engine::libmdbx::Store` (Complies with above change)

Misc:

* Add `Trie::new_temp` test-feature gated method to simplify trie
creation in tests

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is needed for #391

---------

Co-authored-by: Tomás Arjovsky <t.arjovsky@gmail.com>

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
This pr implements peers revalidation loop.

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->
In the discovery protocol, every `10min` (this could be any number
actually), we need to ping back those peers whose last ping was 24hs ago
to re-validate the endpoint proof, if they don't ping back, we replace
them with one from the replacements list.

Changes: 
- Discovery main function now spawns two tokio tasks:
`discover_peers_server` (the one we already had) and
`peers_revalidation`.
- `UdpSocket` and `KademliaTable` were modified to be thread/concurrent
safe.
- `peers_revalidation` implements a tokio interval that lasts `10min`
and works in the following way:
1. First we get the peers to revalidate: those that haven't pinged for
24hs.
2. We check if each peer has been already pinged in the last iteration.
If not, jump to step `3`, otherwise to step `4`.
3. We invalidate the endpoint proof and ping it so that we can
revalidate the proof. Finally, we pushed the peer to a list so that we
can validate it in the next iteration.
4. We check if the peer is proven. If not, it means it hasn't ping back,
so we replace it with the latest pushed peer from the replacement list.
If there isn't a replacement, we simply remove the peer from the bucket.

This implementation is supported by some custom unit tests and e2e
tests.

<!-- Link to issues: Resolves #111, Resolves #222 -->

Advances on issue #154.

**Motivation**
Migrate handling of account state from DB tables into a state trie

<!-- Why does this pull request exist? What are its goals? -->

**Description**

Refactor how we interact with account state across the codebase:
- Replace `apply_state_transitions` with `get_state_transitions`, which
returns a list of `AccountUpdates` and add the method
`Store::apply_account_updates` which applies the changes on top of the
given block's state and returns the new state root after the updates.
- Remove methods that allowed modifying account state from `Store` (such
as add_account, remove_account, add_account_info, etc)
- `Store` methods that fetch account state data now receive a
`block_number` argument so that historical state can be accessed

Other:
* Fix value of `withdrawals_root` & `parent_beacon_block_root` for
non-cancun `Genesis`
* [Ef-Tests] initialize store from Genesis struct
* Update rpc requests to look for historical data where applicable
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #272

---------

Co-authored-by: Tomás Arjovsky <t.arjovsky@gmail.com>

**Motivation**

Move account storage  storage tries

<!-- Why does this pull request exist? What are its goals? -->

**Description**
* Add a `TrieDB` implementation for dusport libmdbx tables (the idea
here is to use the same table for multiple tries, so one of the keys
will be used to indicate which trie nodes are being stored (in the case
of storage trie this will be the account's address) and the other key
will be the node hash)
* Replace current storage backend with tries
* Remove public methods to mutate storage from `Store`
* `Store::get_storage_at` now also receives a block_number so it can
fetch historical data

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->
Closes #349

---------

Co-authored-by: Tomás Arjovsky <t.arjovsky@gmail.com>

**Motivation**
Adding support for Trie::get_proof so we can use it in rpc endpoint
etc_getProof

<!-- Why does this pull request exist? What are its goals? -->

**Description**

* Add `Trie` method `get_proof`
* Add protests for `Trie::get_proof`

Other:


* Replace `NodeHasher` with `NodeEncoder`, which behaves similarly, but
instead of building up the node's hash, it builds up the node's encoded
format, leaving the hashing to a later instance

* Add method `encode_raw` for all node variants


* Add `NodeHash` method `from_encoded_raw` which will hash the encoded
node returned by the `NodeEncoder`
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is needed in order to implement #291

**Motivation**
Currently, our Store contains an `Arc<Mutex<dyn StoreEngine>>`, but the
mutex is not really needed for the libmbdx backend, it is only needed
for the InMemory one. This means we should be able to move the mutex
into the in memory engine and leave the libmdbx mutex-free.
This PR proposes moving this mutex into the InMemory engine and changing
the structure of `Store` to:
```
pub struct Store {
    engine:  Arc<dyn StoreEngine>
}
```


<!-- Why does this pull request exist? What are its goals? -->

**Description**

* Change `Store.engine` type from `Arc<Mutex<dyn StoreEngine>>` to ` E:
StoreEngine`,
* Wrap in memory store engine in `Arc<Mutex<>>`
* Rename implementations of `StoreEngine` to `LibmdbxStoreEngine` &
`InMemoryStoreEngine` and expose them publicly
* Add method `new_temp` for `Store` to be used in tests instead of
creating and removing directories "by hand".

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #issue_number

**Motivation**

Remove usage of `merkle_patricia_tree` and replace it with our own trie
implementation

**Description**

* Promote modules `trie` & `rlp` to their own crate
* Add method `compute_hash_from_unsorted_iter` for `Trie`

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #439

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #issue_number

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
- We need better docs to describe or dev workflow, why we are building
this project and why we'll use in the future.
**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

---------

Co-authored-by: Martin Paulucci <martin.c.paulucci@gmail.com>
Co-authored-by: fmoletta <99273364+fmoletta@users.noreply.github.com>

**Motivation**

This PR adds the arithmetic operations for LEVM

**Description**

Adds the implementation of this group of opcodes with tests

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #457 
Closes #458
Closes #459 
Closes #460 
Closes #461
Closes #462
Closes #463 
Closes #464
Closes #465 
Closes #466 
Closes #467

<!-- Why does this pull request exist? What are its goals? -->

<!-- A clear and concise general description of the changes this PR
introduces -->
**Description**
Implements and unit tests the following comparison opcode operations:
- `LT`
- `GT`
- `SLT`
- `SGT`
- `EQ`
- `ISZERO`

<!-- Link to issues: Resolves #111, Resolves #222 -->
Closes #468, #469, #470, #471, #472 and #473.

**Motivation**
Implement and test the `KECCAK256` opcode.
<!-- Why does this pull request exist? What are its goals? -->

<!-- A clear and concise general description of the changes this PR
introduces -->
**Description**
- Add `sha3` dependency.
- Write new `Memory::load_range` function.
- Implement the operation's logic.
- Test different case scenarios.

<!-- Link to issues: Resolves #111, Resolves #222 -->
Closes #482.

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->

While the rpc-compat tests can be made to work without the
totalDifficulty field by updating the execution api crate, the engine
tests panick as they still rely on it.
This PR aims to fix this issue (at least until the hive engine test
suite is updated) by reverting the removal of the field and using a
previous version of the execution api crate which still has this field

<!-- A clear and concise general description of the changes this PR
introduces -->
* Reverts #347 
* Updates hive rev to a version using a previous version of
execution-apis that still uses the totalDifficulty field
(lambdaclass/hive#6)

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is needed in order to run engine tests

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #490
Closes #491 
Closes #489 
Closes #494

---------

Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

**Motivation**

Add basic block building to forkChoiceUpdatedV3

<!-- Why does this pull request exist? What are its goals? -->

**Description**

* Expand engine_forkChoiceUpdated:
   - Add validations
   - Fix fork state update conditions
   - Add basic block building

With these changes hive engine tests no longer fail after calling
engine_forkChoiceUpdatedV3. We still need to implement engine_getPayload
to progress further
NOTE: Some fixes over this code have been included in #571 (Computing
the state root for newly built payloads instead of using the parent
state root)
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, is part of #344

**Motivation**

Adds most of block information opcodes to the VM

**Description**

- Adds the implementation of all block information opcodes except
selfbalance and blobhash, which needs the implementation of accounts and
transactions
- Adds tests for the implemented opcodes

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #502
Closes #503
Closes #504
Closes #505
Closes #506
Closes #507
Closes #508
Closes #510
Closes #511

---------

Co-authored-by: Luca Lazcano <64329820+lazcanoluca@users.noreply.github.com>
Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

…g pipeline (#571)

Depends on #540 
**Motivation**
Being able to run the full basic block building pipeline
(forkChoiceUpdated -> getPayload -> newPayload)
CURRENT_STATUS: I could successfully run some tests that ran the above
sequence, we still need to add transactions sent by sendRawTransaction
endpoint to the payload in order to fully build blocks
<!-- Why does this pull request exist? What are its goals? -->

**Description**
* Add rpc endpoint `engine_getPayloadV3`
* Compute new state root (after applying beacon_root contract &
withdrawals) when building a new payload (`engine_forkChoiceUpdated`)
* Set new block as canonical in `engine_newPayloadV3` (TEMP FIX for not
being able to fetch non canonical blocks)

Missing work (for a later PR)
* Fetch transactions from the mempool and add them to the block
* Populate BlobsBundle 

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes None, but is part of #344

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
Adds the `log<n>` opcodes for the VM

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->
Adds the implementation of all the `log<n>`operations with tests for
different cases
- create all the types of `logs`
- multiple `logs`
- logs in static calls

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #501

---------

Co-authored-by: Luca Lazcano <64329820+lazcanoluca@users.noreply.github.com>
Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

**Motivation**
Implemented `CALLDATALOAD`, `CALLDATASIZE`, `CALLDATACOPY`,
`RETURNDATASIZE`, `RETURNDATACOPY`

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #517 
Closes #518 
Closes #519 
Closes #525 
Closes #526

---------

Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
Start the L1 watcher implementation, who will be looking for events from
L1 Inbox contract.

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->
The watcher does a loop polling new logs from an L1 contract. It will
need further work, since it's a basic PoC.

<!-- Link to issues: Resolves #111, Resolves #222 -->

---------

Co-authored-by: ilitteri <ilitteri@fi.uba.ar>
Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

**Motivation**

Fix current Makefile as it's broken
<!-- Why does this pull request exist? What are its goals? -->

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #issue_number

**Motivation**
- One of the milestones is to have an endpoint to fetch transaction
logs, which describe events emitted
by certain addresses.
**Description**
- Add parser and handler for the mentioned endpoint.
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #333

**Motivation**

We need to have a ProofDataProvider that serves as an interface to
communicate with the prover.
<!-- Why does this pull request exist? What are its goals? -->

**Description**

The ProofDataProvider listen 2 types of messages: ProofData Requests and
ProofData Submits. The first ones are asked by the prover to start a new
proof job. The second one is used by the prover to inform that the proof
generation is ready.
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

---------

Co-authored-by: ilitteri <ilitteri@fi.uba.ar>

…606)

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
This avoid us to repeat the JSON-RPC specification on every request we
want to make with EngineAPI.

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->
The trait `Into<RpcRequest>` was implemented for every used EngineAPI
request structure (e.g. `NewPayloadV3Request`) so we can create an
Engine request and then convert it to an `RpcRequest`.

<!-- Link to issues: Resolves #111, Resolves #222 -->

**Motivation**

Add SP1 mock prover so it's easy later to integrate the real one.

**Description**

The prover generates a proof for the nth (the ID) fibonacci number. It
should be easy later to integrate with a real ELF

<!-- Link to issues: Resolves #111, Resolves #222 -->

---------

Co-authored-by: ilitteri <ilitteri@fi.uba.ar>

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
Adds the storage related opcodes to LEVM

**Description**

Adds the `Db` struct with accounts, and the storage for such accounts

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #487 
Closes #488

---------

Co-authored-by: Juan Ignacio Medone Sabatini <74007712+juanimedone@users.noreply.github.com>

**Motivation**
Implement `GAS` opcode, which requires a first global handling of gas
consumption.
<!-- Why does this pull request exist? What are its goals? -->

**Description**
- Uses `VM::gas_limit` and `VM::consumed_gas` for handling all opcodes
static and dynamic gas consumption.
- Check if gas is enough before executing each one of them.
- Save `warm_addresses` in `VM`.
- Fixes a `jump` bug and a `CALL` test.
- Adds gas checks to the tests. 
- `CALL`'s `code_execution_cost` is still to be implemented (#605). 
<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #493 and #587.

---------

Co-authored-by: Paolo Belforte <75280184+belfortep@users.noreply.github.com>
Co-authored-by: iinaki <llorensinaki22@gmail.com>

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #issue_number

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
Add the `CREATE` and `CREATE2` opcodes for levm

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->

- Adds the `CREATE` and `CREATE2` opcodes for levm
- Add `nonce` field for accounts
- Different test cases for the opcodes

<!-- Link to issues: Resolves #111, Resolves #222 -->

Closes #528 
Closes #533

---------

Co-authored-by: iinaki <llorensinaki22@gmail.com>