You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, SE2 stores private keys in .env files. This is dangerous as it may lead to accidental leaking of private keys through git commits or showing the file on a local machine to unwelcome eyes. However, that was the best solution for awhile...Until now!!
Expected Behavior
Thanks to rplusq's work on Foundry, we successfully have a solution, through Keystores, to the issues present with the .env implementations.
Foundry's integration allows you to store a private within a Keystore, lock the contents behind a user defined password, and even if the password is known, you would still need access to the creator's local machine to access the private key.
In the demo yarn generate creates a new wallet and creates a keystore using cast wallet import ${randomWallet.address} --private-key ${randomWallet.privateKey}, then yarn deploy accesses the keystore through some black magic to call the deploy script with the private key from within the keystore!
The developer's experience stays exactly the same and experiences the exact same results, aside from the migration from .env to keystores.
Please let me know your thoughts and feel free to suggest any improvements to the implementation!
Thank you!!
Steps To Reproduce
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Hey @Hotmanics thanks for this! I think this is the way to go.
It feels that we are going to have foundry as a default in SE2, and having hardhat as an option in the NPX installer (We just migrated the CLI branch to https://github.com/scaffold-eth/create-eth)
So we'll clean / update the Foundry branch before merging, and let's include this too.
Is there an existing issue for this?
Which method was used to setup Scaffold-ETH 2 ?
npx create-eth@latest
Current Behavior
Currently, SE2 stores private keys in .env files. This is dangerous as it may lead to accidental leaking of private keys through git commits or showing the file on a local machine to unwelcome eyes. However, that was the best solution for awhile...Until now!!
Expected Behavior
Thanks to rplusq's work on Foundry, we successfully have a solution, through Keystores, to the issues present with the .env implementations.
Keystores are integrated through https://eips.ethereum.org/EIPS/eip-2335 to securely hash a private key.
Foundry's integration allows you to store a private within a Keystore, lock the contents behind a user defined password, and even if the password is known, you would still need access to the creator's local machine to access the private key.
Here is a demo of a SE2 Foundry project implementing the new functionality:
https://github.com/Hotmanics/scaffold-eth-2-foundry-keystore-demo
In the demo
yarn generate
creates a new wallet and creates a keystore usingcast wallet import ${randomWallet.address} --private-key ${randomWallet.privateKey}
, thenyarn deploy
accesses the keystore through some black magic to call the deploy script with the private key from within the keystore!The developer's experience stays exactly the same and experiences the exact same results, aside from the migration from .env to keystores.
Please let me know your thoughts and feel free to suggest any improvements to the implementation!
Thank you!!
Steps To Reproduce
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: