ocean.py directly supports hardware wallets

[LoznianuAnamaria]

Target user: data scientists who are moving around data with significant value. Having a private key stored locally is not secure enough. Rather, they want a private key that never hits their computer, let alone the internet. So they need hardware wallets.

Inspiration from Brownie

Here's an example of how Brownie does it:

Brownie allows the use of hardware wallets via Clef, an account management tool included within Geth

To use a hardware wallet in Brownie, start by installing Geth. Once finished, type the following command and follow the on-screen prompts to set of Clef:

clef init

Once Clef is configured, run Brownie in one command prompt and Clef in another. From within Brownie:

>>> accounts.connect_to_clef()

Again, follow the prompts in Clef to unlock the accounts in Brownie. You can now use the unlocked accounts as you would any other account. Note that you will have to authorize each transaction made with a ClefAccount from within clef.

[trentmc]

FYI we tested out this flow for use in df-py. It works.

• df-py Github issue
• df-py README's HOWTO

[calina-c]

With some clarity from the brownie implementation, I can now shed some more light onto this issue. Part of it was actually discussed during our brownie planning call, but I will repeat here for reference.

With brownie, hardware wallets should now be supported in all contract calls. I did not test this, but we can use any type of account with brownie for this kind of call. There is no more custom wallet, just accounts. I do not see any reason why hardware wallets would be an exception.

However, the real issue lies with the provider communication. When signing requests for provider, we use the private key of the wallet as part of the signature. With remote accounts or hardware wallets, this private key is not accessible to us. That makes a lot of sense from a security POV, actually.

@alexcos20 is there any workaround for the signing? If we fix the communication with provider, there is no other place in ocean.py that would require knowledge of the private-key post-wallet creation.

[trentmc]

If we don't have a simple solution for everything, that's fine for now imo, because there's a workaround: data scientists will move tokens from a hardware wallet to a "hot" wallet with private key stored in client-side envvar. This is what we do for df-py ops, for example.

[calina-c]

I can confirm publishing assets works. However, signed provider requests still have the same problem. There is no private key and it should be replaced with something else. What could we use?

Also, if I run clef without the --advanced flag, my requests get rejected with Transaction contains data, but the abi signature could not be found

[trentmc]

@trizin iirc you played around with hw wallets * brownie half a year or so ago. Any tips here?