Awarded: ICDevs.org - Bounty #28 - EVM Utility Canister - $6,000

Developers Bounties
1

EVM Utility Canister - #28

Current Status: Discussion

  • Discussion (01/09/2023)
  • Ratification (01/09/2023)
  • Open for application (01/09/2023)
  • Assigned
  • In Review
  • Closed

Offical Link

Bounty Details

  • Bounty Amount: $6,000 USD of ICP at award date
  • ICDevs.org Bounty Acceleration: For every ICP sent to 8e6a56cf83240d1f07afe5002d8ce3574e2bde9ede8c4a8964cd6b53c40d0c22, ICDevs.org will add .25 ICP to this issue and .75 ICP to fund other ICDevs.org initiatives.
  • Project Type: Team
  • Opened: 01/09/2023
  • Time Commitment: Days
  • Project Type: Library
  • Experience Type: Intermediate - Rust; Intermediate - Evm;

Description

This rust canister allows motoko canister to query it with data to receive EVM compliant transactions that can be signed via t-ECDSA and submitted to EVM networks.

This bounty gives the opportunity to

  • learn rust
  • learn about signing transactions
  • learn about evm transactions
  • learn about t-ecdsa

Motoko currently is missing a number of libraries needed to encode, interpret, and sign evm transactions and data. Rust has most of these libraries and many of them have been used in the rust No Key Wallet project. Until these libraries are converted to motoko, it would be nice to have a utility canister that does most of this work for a motoko canister. This will involve async communication and may incur long transaction times, but it will at least let motoko devs get started with EVM based transactions while those motoko libraries are being developed.

  • Create a proper candid type for passing an EVM transaction to the utility canister and return the encoded bytes and hash that is needed to be signed. Support multiple network ids and transaction types like Legacy, EIP1559, EIP2930.
  • Create a proper candid type for passing in an evm witness, root, and receiving back a verification that the data is part of the tree under that root.
  • Expose RLP encoding and candid type
  • Expose a keccak hashing function
  • Expose functions similar to ethereumjs-monorepo/packages/util at master · ethereumjs/ethereumjs-monorepo · GitHub

To apply for this bounty you should:

  • Include links to previous work writing tutorials and any other open-source contributions(ie. your github).
  • Include a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.
  • Give an estimated timeline on completing the task.
  • Post your application text to the Bounty Thread

Selection Process

The ICDevs.org developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.

Funding

The bounty was generously funded by the DFINITY Foundation. If you would like to turbocharge this bounty you can seed additional donations of ICP to 8e6a56cf83240d1f07afe5002d8ce3574e2bde9ede8c4a8964cd6b53c40d0c22. ICDevs will match the bounty 0.25:1. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to donations@icdevs.org. More information about how you can contribute can be found at our donations page.

FYI: General Bounty Process

Discussion

The draft bounty is posted to the DFINITY developer’s forum for discussion

Ratification

The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.

Assigned

A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission

Awarded

The award has been given and the bounty is closed.

Other ICDevs.org Bounties

5 Likes
2

We are giving @LiveDuo first refusal for this bounty because of the amazing work on evm-sign and the significant overlap in functionality.

3

Hey @skilesare, thanks the option.

We will be working on other things for the next few weeks (which may end up been an application for a grant at some point) and we have to take a step back from bounties for a while.

If someone else comes around in the meantime they should be able to pick the bounty up and we will be happy to share what we’ve learned during #27. If not, we’ll probably be applying in a few weeks.

2 Likes
4

Hey @skilesare I would like to pickup this bounty. I’ve already did creation and signing of ETH transactions in bridge repo.

I’ve already started working on candid files. You can find it here: GitHub - icopen/evm_utils_ic

Regarding the implementation I would like to use crates:
sha3 for keccak
rlp or fastrlp for rlp (I will check which ones leaves smaller footprint)

1 Like
5

Thanks. Good luck and keep us up to date on your progress.

I’ve submitted you to a board vote, but I’d expect it to pass: https://77i6o-oqaaa-aaaag-qbm6q-cai.ic0.app/axon/1/proposal/8

6

Hey I have a question regarding EVM witness. I was looking in to the JSON-RPC and could not find anything usefull except for hash root value. Can I add endpoint to verify patricia trees to make it generic?

7

If that makes sense and is the best way forward I think it makes sense.

8

I’ve commited work on bounty, part of the utils are already done. RLP encoding is also done. I’m in the middle of transaction parsing and encoding. I’ve also picked library for patricia tree verification.

1 Like
9

I’ve finished coding work on the library :slight_smile: . I have few questions to the community regarding the API:

  1. Right now I’m using Byte Arrays (candid vec u8) as an default way of passing hashes and raw data. I can convert it to hex string (0x ethereum style). What is the preferred way?

  2. Transaction is a variant with Legacy, EIP1559 and EIP2930, each variant includes Signature object that will be filled if it is possible. We can transform it into another version, however I think it will be easy to use in motoko.

If you have any other questions regarding the function I will be hapy to help.

Last thing to do is updating the readme and publishing the canister so that anyone can use it.

10

  1. I think that using vec u8 (vec nat8) is much cheaper for passing around. Hex strings use up to four bytes per character so a 32 byte hash will be almost 256 bytes on the wire. Probably practically negligible, but the cycles will eventually add up as these will likely be passed across subnet boundaries and you have to pay a toll for each byte in the message.

  2. I don’t have enough knowledge of this. I’ll ping @timo and @Manu as they probably have some lessons learned from the past and the BTC stuff that would apply here. Maybe there are some other folks. I believe that @dieter.sommer did a deep dive into the EVM stuff a few months ago and likely has some good advice.

11

I’ve uploaded new version of the library. All the functions are implemented. I’ve added js tests to check functions output against ethers library. Also I’ve filled readme. I think this one is finished. Should I add something more to this library?

12

I’ve created a simple example in Motoko that interacts with EVM Utility Canister: Internet Computer Content Validation Bootstrap

I hope you will enjoy it.

1 Like
13

Submitted for approval:

@icme, @aiv, @quint, @mparikh, please vote :slight_smile:

1 Like
14

Hi @stopak! The u64 data type for the value in the transaction struct is a bit tight for encoding the amount of Wei for a transfer as it caps at somewhat over 18 Ether, considering the 18 decimals. Would it make sense to use a larger data type for this, and potentially other values that Ethereum encodes with 256 bits, e.g., something like an u256 like here. Created an issue on GitHub for this to discuss.

2 Likes
15

@stopak : Thanks for picking up the discussion on GitHub on the u64 type.

One more question: I’ve only briefly looked at the code and it seems to me that the public key argument to the pub_to_address method can accept a compressed or regular ECDSA key. That is, you can just take the public key part of the response of the public_key function of the threshold ECDSA implementation of the IC and use it as input to derive an address. Is this understanding correct? Thank you!

16

Fixed and deployed to github and production.

17

From what I have found, yes.

  • This function supports parsing compressed (33 bytes, header byte 0x02 or
  • 0x03), uncompressed (65 bytes, header byte 0x04), or hybrid (65 bytes, header
  • byte 0x06 or 0x07) format public keys.
1 Like
18

Excellent, the threshold ECDSA public_key returns a key in 33-byte compressed format with an 0x02 or 0x03 lead byte indicating the sign of the y-coordinate of the elliptic curve point, so it should indeed work to use such keys as input.

Thanks!

19

can someone please give the repo link , plus update it to complete rather than discussion

20

Hey, here is link to repo: GitHub - icopen/evm_utils_ic