Complete Ethereum & Celo library and wallet implementation in Rust. https://docs.rs/ethers
Go to file
Dan Cline d5de795382
Use EIP155 for all signers with empty transaction `chain_id` (#1198)
* remove error when signing with a different chain

 - a chain_id mismatch between the signer and the transaction is valid
   since the behavior is the same between two signers with different
   chain ids
 - a specified chain_id should be signed regardless of the chain_id of
   the signer
 - refactor `sign_hash` to no longer take an `eip155` flag - it now
   _just_ signs hashes. EIP155 is specific to transactions, so we
   now normalize the `v` value in `sign_transaction_sync`

* use signer chain_id for tx in trezor signer

 - use the trezor signer's chain_id if the transaction's chain_id
   doesn't exist
 - sets the chain_id in both `sign_tx` and the Signer implementation's
   `sign_transaction`

* use signer chain_id for tx in ledger signer

 - use the ledger signer's chain_id if the transaction's chain_id
   doesn't exist
 - sets the chain_id in both `sign_tx` and the Signer implementation's
   `sign_transaction`

* prefer transaction chain_id in aws signer

 - uses the signer chain_id if the transaction chain_id doesn't exist
 - refactor `sign_digest_with_eip155` to take an input chain_id, so the
   signer chain_id is not used every time. If we want to enforce
   transaction and signer chain ids to be consistent, this should be
   undone

* add private key signing test for an empty chain_id

* Apply suggestions from code review

Co-authored-by: Matthias Seitz <matthias.seitz@outlook.de>

* Update ethers-signers/src/ledger/mod.rs

Co-authored-by: Georgios Konstantopoulos <me@gakonst.com>
Co-authored-by: Matthias Seitz <matthias.seitz@outlook.de>
2022-05-02 11:51:25 -07:00
.github Ensure a consistent chain ID between a signer and provider in SignerMiddleware (#1095) 2022-04-10 10:55:30 -07:00
assets release: 0.6.0 (#611) 2021-11-23 21:23:12 +02:00
bin docs: add contributing.md 2020-06-15 18:05:29 +03:00
ethers-addressbook chore(deps): bump once_cell from 1.9.0 to 1.10.0 (#987) 2022-03-04 05:29:34 -08:00
ethers-contract feat: Relax `Clone` requirements when `Arc<M>` is used (#1183) 2022-04-27 15:33:22 +03:00
ethers-core chore(deps): bump syn from 1.0.91 to 1.0.92 (#1194) 2022-04-29 04:26:24 -07:00
ethers-etherscan feat(etherscan): add ClientBuilder type (#1193) 2022-04-29 04:25:52 -07:00
ethers-middleware feat: Relax `Clone` requirements when `Arc<M>` is used (#1183) 2022-04-27 15:33:22 +03:00
ethers-providers refactors ipc transport internals (#1174) 2022-04-24 16:09:56 +02:00
ethers-signers Use EIP155 for all signers with empty transaction `chain_id` (#1198) 2022-05-02 11:51:25 -07:00
ethers-solc test(solc): add another link with remapping test (#1191) 2022-04-28 07:07:08 -07:00
examples feat(provider): add RwClient (#1016) 2022-04-13 13:21:52 -07:00
scripts fix(examples): adjust breaking changes and detect failures in ci (#1040) 2022-03-16 06:26:48 -07:00
src ethers-addressbook crate (#769) 2022-01-07 12:12:21 +02:00
.gitignore add support for polygon and avalanche (#606) 2021-11-22 11:02:28 +02:00
CHANGELOG.md fix: add to and from into the transaction receipt to follow spec (#1184) 2022-04-27 15:40:59 +03:00
CONTRIBUTING.md Refactor crate determination in new ethers-macro crate (#555) 2021-11-05 15:00:01 +02:00
Cargo.lock chore(deps): bump syn from 1.0.91 to 1.0.92 (#1194) 2022-04-29 04:26:24 -07:00
Cargo.toml chore: add examples with required features (#1109) 2022-04-04 15:33:06 -07:00
LICENSE-APACHE Dual license under MIT/Apache 2 (#28) 2020-06-18 08:20:20 +03:00
LICENSE-MIT Dual license under MIT/Apache 2 (#28) 2020-06-18 08:20:20 +03:00
README.md Cleanup of links and requirements in README (#1163) 2022-04-21 19:23:51 +02:00
rustfmt.toml chore: add rustfmt.toml (#537) 2021-10-29 14:29:35 +02:00

README.md

ethers.rs

Complete Ethereum and Celo wallet implementation and utilities in Rust

Github Actions Telegram Chat Crates.io

Documentation

Extensive documentation and examples are available here.

Alternatively, you may clone the repository and run cd ethers/ && cargo doc --open

You can also run any of the examples by executing: cargo run -p ethers --example <name>

Add ethers-rs to your repository

[dependencies]

ethers = { git = "https://github.com/gakonst/ethers-rs" }

Running the tests

Tests require the following installed:

  1. solc (>=0.8.10). We also recommend using solc-select for more flexibility.
  2. ganache-cli
  3. geth

In addition, it is recommended that you set the ETHERSCAN_API_KEY environment variable for the abigen via Etherscan tests. You can get one here.

EVM-compatible chains support

There are many chains live which are Ethereum JSON-RPC & EVM compatible, but do not yet have support for EIP-2718 Typed Transactions. This means that transactions submitted to them by default in ethers-rs will have invalid serialization. To address that, you must use the legacy feature flag:

[dependencies]

ethers = { git = "https://github.com/gakonst/ethers-rs", features = ["legacy"] }

Polygon support

There is abigen support for Polygon and the Mumbai test network. It is recommended that you set the POLYGONSCAN_API_KEY environment variable. You can get one here.

Avalanche support

There is abigen support for Avalanche and the Fuji test network. It is recommended that you set the SNOWTRACE_API_KEY environment variable. You can get one here.

Celo Support

Celo support is turned on via the feature-flag celo:

[dependencies]

ethers = { git = "https://github.com/gakonst/ethers-rs", features = ["celo"] }

Celo's transactions differ from Ethereum transactions by including 3 new fields:

  • fee_currency: The currency fees are paid in (None for CELO, otherwise it's an Address)
  • gateway_fee_recipient: The address of the fee recipient (None for no gateway fee paid)
  • gateway_fee: Gateway fee amount (None for no gateway fee paid)

The feature flag enables these additional fields in the transaction request builders and in the transactions which are fetched over JSON-RPC.

Features

  • Ethereum JSON-RPC Client
  • Interacting and deploying smart contracts
  • Type safe smart contract bindings code generation
  • Querying past events
  • Event monitoring as Streams
  • ENS as a first class citizen
  • Celo support
  • Polygon support
  • Avalanche support
  • Websockets / eth_subscribe
  • Hardware Wallet Support
  • Parity APIs (tracing, parity_blockWithReceipts)
  • Geth TxPool API
  • WASM Bindings (see note)
  • FFI Bindings (see note)
  • CLI for common operations

Note on WASM and FFI bindings

You should be able to build a wasm app that uses ethers-rs (see the example for reference). If ethers fails to compile in WASM, please open an issue. There is currently no plan to provide an official JS/TS-accessible library interface. we believe ethers.js serves that need very well.

Similarly, you should be able to build FFI bindings to ethers-rs. If ethers fails to compile in c lib formats, please open an issue. There is currently no plan to provide official FFI bindings, and as ethers-rs is not yet stable 1.0.0, its interface may change significantly between versions.

Getting Help

First, see if the answer to your question can be found in the API documentation. If the answer is not there, try opening an issue with the question.

Join the ethers-rs telegram to chat with the community!

Contributing

Thanks for your help improving the project! We are so happy to have you! We have a contributing guide to help you get involved in the ethers-rs project.

If you make a Pull Request, do not forget to add your changes in the CHANGELOG and ensure your code if properly formatted with cargo +nightly fmt and clippy is happy cargo clippy, you can even try to let clippy fix simple issues itself: cargo +nightly clippy --fix -Z unstable-options

This library would not have been possibly without the great work done in:

A lot of the code was inspired and adapted from them, to a unified and opinionated interface, built with async/await and std futures from the ground up.

Projects using ethers-rs