#type-state #evm #revm #api #transaction #information #shortcut

no-std trevm

A typestate API wrapper for the revm EVM implementation

21 releases (11 breaking)

new 0.14.2 Oct 24, 2024
0.12.1 Oct 16, 2024
0.1.1 Jul 26, 2024

#386 in Magic Beans

Download history 245/week @ 2024-07-25 476/week @ 2024-08-01 357/week @ 2024-08-08 617/week @ 2024-08-15 194/week @ 2024-08-22 124/week @ 2024-08-29 150/week @ 2024-09-05 88/week @ 2024-09-12 164/week @ 2024-09-19 65/week @ 2024-09-26 290/week @ 2024-10-03 160/week @ 2024-10-10 358/week @ 2024-10-17

890 downloads per month

MIT/Apache and maybe AGPL-3.0

615KB
3.5K SLoC

Trevm

⚠️ Trevm is experimental software and not considered ready for production use. ⚠️

Trevm is a typestate API wrapper for revm. It provides an ergonomic way to interact with the revm API, shortcuts for common tasks, and straightforward API extensibility. Trevm does NOT try to provide low-level EVM management, but rather to shortcut and simplify common tasks like simulating transactions.

Trevm is NOT a replacement for revm. It is a wrapper around the revm API. It is NOT a drop-in upgrade, integrating trevm into your project will require changes to your code.

See the documentation on docs.rs for information on usage.

Why use Trevm?

Trevm is for building complex high-level flows on top of the low-level revm API. It provides a state machine that ensures you can only take actions that are valid in the current state. This makes it easier to reason about the state of your EVM instance and ensures you don't make mistakes.

Trevm is useful for:

  • full node implementations
  • block builders
  • searchers
  • any other transaction simulation usecase

Limitations

Trevm is a work in progress and is not feature complete. In particular, trevm does not currently have lifecycle support for blocks before Shanghai. This means it cannot produce correct post-block states for blocks before Shanghai.

The Trevm State Machine

Trevm provides a state machine that represents the internal state of a revm EVM instance. It ensures that at each step you can only take actions that are valid in the current state. This is done by using the typestate pattern.

As you progress between states, the API will change to reflect the available operations. For example, you can't call open_block() on a EvmNeedsTx state, as the block is already open. You can't call close_block() on a EvmReady state, without explicitly clearing or running the transaction that has been ready.

typestates are cool

Dependencies

~28–39MB
~692K SLoC