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?
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?
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).
@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.
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.
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.
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.