Completed: ICDevs.org Bounty #27b - NoKeyWallet - Rust - up to $10k

skilesare · October 21, 2022, 6:56pm

Rust NoKey Wallet - #27b

Current Status: Discussion

Discussion (10/21/2022)
Ratification
Open for application
Assigned
In Review
Closed

Official Link

Bounty Details

Bounty Amount: $5,000 USD of ICP at award date - $5000 USD of ICP Match Available
ICDevs.org DFINITY Foundation Grant Match Available: $2000 USD of ICP at award time - (For every ICP sent to 8e6a56cf83240d1f07afe5002d8ce3574e2bde9ede8c4a8964cd6b53c40d0c22, ICDevs.org will add $40 USD of ICP at award date to the bounty, up to the first 125 ICP donated, After 125 ICP, donations to the above address will add .25 ICP to this issue and .75 ICP to fund other ICDevs.org initiatives)
Project Type: Team
Opened: 09/05/2022
Time Commitment: Weeks
Project Type: Library
Experience Type: Intermediate - Rust;

Description

This Rust class is allows for canisters to hold assets on other EVM based chains.

This bounty gives the opportunity to

learn Rust
learn about signing transactions
learn about evm transactions
learn about t-ecdsa
learn about managing nonces

The NoKey wallet is a stable class that any Rust canister can add that will allow it to act as a wallet for Evm-based chains. It should implement the following features:

Derive a t-ecdsa key according to a consistent derivation scheme.
Save that derivation for the user in a (Nat,Text) pair.
Sign Evm-based transactions with a t-ecdsa key selected by the wallet owner. The transaction will be passed in as part of the sign function sign(rawtrx, {#derivation([Nat], #named(id)}, nonce, other Info?, saveHistory)
Keep a history of signed transactions.
Enable clearing the history
Provide an upgrade strategy, preferably using stable vars.
Suggest and follow a safe nonce generation/management scheme that protects the user.

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 $40:1 ICP for the first 125 ICP out of the DFINITY grant and then 0.25:1 after that. 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.

Matches

DFINITY Foundation Grant: - $5000 USD of ICP at award date

Other ICDevs.org Bounties

LiveDuo · October 21, 2022, 8:04pm

Hey,

I’m interested along with @nikolas-con for this bounty.

Design Overview

The project will have 2 parts, a rust library with unit tests and an example project with an ICP canister and a simple frontend. We will also make a Readme on how to use the library and how to import the Rust library in other projects.

Rust library

Functions: create_public_key, get_caller_public_key, sign_raw_transaction, get_caller_transactions, clear_caller_history, stable_save and stable_restore
Dependencies: At the moment we are editing the signed transaction hex manually and we don’t use external libraries other than ic_cdk, ic_cdk_macros, candid. In the final version we probably use a few libraries to sign the transaction instead of doing it manually.
Consideration: The library should support different types of EVM transactions (eg. eip-2718, eip-1559, history)

Example project (Rust canister + React frontend)

Functionality: Connect wallet (Plug wallet), Create Ethereum wallet, Transfer ETH
Dependencies: ethers, hardhat, ethereumjs-tx, react

The example project will show how to use the library. It will be a simple No Key wallet with ICP.

Estimated timeline

Create a POC that signs an EVM transaction on ICP - Done
Setup a proper project to accommodate the library (including tests, example project etc) - 1w
Add functions to the Rust library to create user public key and manage transactions history and nonces - 2w
Handle different transaction types - 2w
Implement stable save and restore - 1w
Add unit tests for the Rust library - 2w
Implement example project to showcase a no key Ethereum wallet 1w

Open-source contributions

IDLE Finance bounty #18

IDLE Finance bounty #11

Open Source project (I maintain)

skilesare · October 21, 2022, 9:15pm

I’d also love to see a way to just submit a raw transaction…no reason this wallet couldn’t sign the creation of it’s own contracts on evm chains.

I’ve asked the board to approve and I don’t for see any issues. Let’s focus on the Rust version for you all…I’d love another group to do the motoko version and coordinate with you all on it. It could/should probably use the same interface and setup.

LiveDuo · October 23, 2022, 10:40am

For the main library we are looking to fully support raw transactions, whether they are transfers, contract calls or smart contract creation transaction.

At the moment our POC works with Ethereum (and a local Hardhat instance). Later will have to look into other EVM chains and see if there are any changes necessary.

Sure thing, we are happy to help.

LiveDuo · November 16, 2022, 9:35am

Hey @skilesare ,

We have made significant progress with the library.

Here’s the repository:

So far we’ve built the main functionality to create (and store) EVM addresses and sign (and store) transactions on behalf of the canister. We also added support for Legacy, EIP1559 and EIP2930 transaction types and different chain ids (eg. Ethereum testnets, Avalanche, BSC etc).

Up next:

Handle nonce differently for each EVM chain
Add more unit tests
Add two more e2e tests (for creating a smart contracts / ERC20 transfers)
Work on the “no key wallet” example canister to make more visually pleasing

Might also be a good time to have a look on the repo just to check we are on the same page. Also, what should we call the rust crate for this library?

skilesare · November 17, 2022, 2:37am

Guys…this looks amazing so far. I don’t have a great answer on the Rust question as I don’t know my way around that ecosystem much. Can a rust dev make a comment?

paulyoung · November 17, 2022, 3:24am

I don’t know much about the EVM but I took a quick look and had some initial thoughts on the randomness and private keys in the wallet:

I imagine it’s better to use the randomness from the IC instead of the getrandom crate
- Here’s an example: ic-auth-tokens/lib.rs at 76113cbaa8b788b1989a9d5ef0868cdb12ee46af · codebase-labs/ic-auth-tokens · GitHub
People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

neeboo · November 17, 2022, 7:07am

Maybe supporting standard derived path would be much better. We will open-source something soon, we can discuss later

ccyanxyz · November 17, 2022, 10:04am

This can be useful: GitHub - rocklabs-io/ic-web3: Ethereum RPC client for canisters on the IC, ic-web3 can help access Ethereum RPC endpoints and sign/send Ethereum transactions from within canisters.

skilesare · November 17, 2022, 2:29pm

This particular package is using t-ecdsa I believe.

paulyoung · November 17, 2022, 3:54pm

I don’t think so:

github.com

nikolas-con/ic-evm-tx/blob/e21cf38c8e2775e47f0001f36f1af6afb6d8c66c/lib/no_key_wallet/Cargo.toml#L15-L15


      
          getrandom = { version = "0.2.8", features = ["js"] }

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L60-L68


      
          //! ### WebAssembly support
          //!
          //! This crate fully supports the
          //! [`wasm32-wasi`](https://github.com/CraneStation/wasi) and
          //! [`wasm32-unknown-emscripten`](https://www.hellorust.com/setup/emscripten/)
          //! targets. However, the `wasm32-unknown-unknown` target (i.e. the target used
          //! by `wasm-pack`) is not automatically
          //! supported since, from the target name alone, we cannot deduce which
          //! JavaScript interface is in use (or if JavaScript is available at all).

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L70-L74


      
          //! Instead, *if the `js` Cargo feature is enabled*, this crate will assume
          //! that you are building for an environment containing JavaScript, and will
          //! call the appropriate methods. Both web browser (main window and Web Workers)
          //! and Node.js environments are supported, invoking the methods
          //! [described above](#supported-targets) using the [`wasm-bindgen`] toolchain.

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L76-L81


      
          //! To enable the `js` Cargo feature, add the following to the `dependencies`
          //! section in your `Cargo.toml` file:
          //! ```toml
          //! [dependencies]
          //! getrandom = { version = "0.2", features = ["js"] }
          //! ```

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L83-L84


      
          //! This can be done even if `getrandom` is not a direct dependency. Cargo
          //! allows crates to enable features for indirect dependencies.

github.com

rust-random/getrandom/blob/v0.2.8/src/lib.rs#L86-L89


      
          //! This feature should only be enabled for binary, test, or benchmark crates.
          //! Library crates should generally not enable this feature, leaving such a
          //! decision to *users* of their library. Also, libraries should not introduce
          //! their own `js` features *just* to enable `getrandom`'s `js` feature.

skilesare · November 17, 2022, 4:03pm

Ah…ok. @LiveDuo we should be using t-ecdsa to sign these in a secure way. It may be ok to have a switch and just use a random key if a dev wants that kind of security, but it is likely not something that would be used in production. (Might be great for testing though).

LiveDuo · November 17, 2022, 6:11pm

@skilesare @paulyoung
We are using the sign_with_ecdsa system call to sign transactions. The getrandom library is only used for getting a random private key in unit / integration tests.

We enabled the js cargo flag because cargo build tries to include the getrandom library and has issues with wasm32-unknown-unknown target.

If there’s a better way to get randomness in unit / integrations tests we are happy to look into it. We will try changing the getrandom dependency to dev-dependencies and see if that works. Also, happy to change the js cargo flag if there’s a better way.

github.com

nikolas-con/ic-evm-tx/blob/master/lib/no_key_wallet/src/lib.rs#L133


      
          let caller = get_derivation_path(principal_id);
          
          
let request = SignWithECDSA {
              message_hash: message.clone(),
              derivation_path: vec![caller],
              key_id: key_id.clone(),
          };
          
          
let (res,): (SignWithECDSAReply,) = ic_call(
              Principal::management_canister(),
              "sign_with_ecdsa",
              (request,),
          )
          .await
          .map_err(|e| format!("Failed to call sign_with_ecdsa {}", e.1))?;
          
          
let rec_id = get_rec_id(&message, &res.signature, &user.public_key).unwrap();
          
          
let signed_tx = tx.signed(res.signature.clone(), rec_id).unwrap();
          
          
STATE.with(|s| {

github.com

nikolas-con/ic-evm-tx/blob/master/lib/no_key_wallet/src/utils.rs#L54


      
          }
          
          
pub fn string_to_vev_u8(str: &str) -> Vec<u8> {
              (0..str.len())
                  .step_by(2)
                  .map(|i| u8::from_str_radix(&str[i..i + 2], 16).unwrap())
                  .collect::<Vec<u8>>()
          }
          
          
#[cfg(test)]
          pub fn generate_random_private_key() -> libsecp256k1::SecretKey {
              loop {
                  let mut ret = [0u8; 32];
                  getrandom::getrandom(&mut ret).unwrap();
                  if let Ok(key) = libsecp256k1::SecretKey::parse(&ret) {
                      return key;
                  }
              }
          }
          #[cfg(test)]
          pub fn create_raw_legacy_tx(arg: EVMTransactionLegacy) -> Vec<u8> {

LiveDuo · November 17, 2022, 6:12pm

People seem to agree that a private key stored in a canister would be very difficult to exfiltrate but not impossible.

Are there actionable things around this? Should we include a warning in the Readme file?

paulyoung · November 17, 2022, 6:18pm

That makes sense. Moving to dev dependencies makes that clearer.

A consumer of this crate might still see that and do the same thing, but my main concern was that the library itself was using it.

paulyoung · November 17, 2022, 6:22pm

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

LiveDuo · November 17, 2022, 6:28pm

Given that it’s just used for creating a private key for testing we can possibly get by without it. An option is to hardcode an example private key for our tests.

LiveDuo · November 17, 2022, 6:33pm

As an author I would over-communicate the risks involved so that people don’t overlook them or feel misled.

I tried to do that here: GitHub - codebase-labs/ic-auth-tokens: Generate authentication tokens based on the randomness provided by the Internet Computer

As a consumer I would really appreciate it being called out up front.

There were a few forum discussion about the issue. Might be a good idea to include links to those too.

I came across a discussion about increasing the subnet size for the ecdsa signing canisters a few weeks ago. I was under the impression that the subnet will increase in size to (partially?) mitigate the issue.

LiveDuo · November 17, 2022, 6:43pm

Looking forward seeing how far how you guys gone.

We thought about supporting the standard derivation path and we probably end up doing it. We are thinking about providing two signing functions - one with only the required parameters for those that don’t know Ethereum as much and one with more parameters that gives developers more flexibility.

Do you have any use cases in mind?

paulyoung · November 17, 2022, 9:33pm

I’m trying to understand the motivation for storing the private key. It seems unnecessary.

If that’s the case and you’re relying on tECDSA then I would encourage consumers of the crate to do the same (perhaps by doing that in the wallet?)