Extract signing and account management methods from nucypher.blockchain.eth.Client to a new Signer class
Implement Clef as one of this new Signers.
Over the last months, we have been increasingly aware of the limitations of requiring a full blockchain client running in local. Even light nodes are not light enough and very error-prone.
An alternative that we've discussed many times is to implement some sort of "wallet" or "signer", while using an external blockchain client (e.g., a self-managed but remote ethereum node, or directly, providers like Infura). However, we've been reluctant to "get our hands dirty" with implementing a wallet ourselves (which, IMHO, it's a wise position).
Our recent experience with incentivized testnet has shifted the balance towards facilitating lives of node operators and stakers, and implement some kind of light-weight signing functionality (see @KPrasch's awesome PoC in #1629) that can be combined with external blockchain clients.
When it comes to engineer a solution that accommodates this functionality, I think we need to solve a problem on the scope of our current blockchain client interface (i.e., nucypher.blockchain.eth.client.Web3Client). The problem is that our current clients are meant to be used both as a blockchain clients (e.g., executing calls, sending TXs, etc) and as signers (e.g., signing TXs, unlocking accounts, etc). My proposal is to extract the signing API from the client to a separate Signer interface.
That would have many advantages:
Support for cool hybrids like "local signing + Infura" or, much better, "Clef+Infura". I've been personally advocating for the latter for a few months. In fact, you could even have different pluggable signers, such as:
Ethereum clients such as geth (via Clef), parity, etc.
Clef (geth's new standalone signer) [see the "Clef" section in the Geth v1.9.0 blog post]
A pure software wallet (e.g., using private keys stored in files)
MetaMask?
HW wallets not supported by Geth/Clef
"Old" clients (e.g., geth), which are both clients and signers, could be supported as well, just separated in two classes (i.e., client and signer).
Assuming we go down this road, I personally vote for at least implementing support for Clef, for several reasons:
No need to re-invent the wheel and implement a wallet ourselves.
Already compatible with geth (i.e., a user can/should use geth and clef at the same time)
It's the direction that geth maintainers want to take wrt to account management in the long run.
Bundled support for EIP-191 version 0 (fixing #1566 along the way)
Programmatic rules for automatic signing: instead of having an envvar with the account password, Clef allows to define fine-grained rules for automatic signing of specific transactions (e.g, confirmActivity).
cygnusv
commented
4 years ago
TL;DR:
nucypher.blockchain.eth.Clientto a newSignerclassImplement Clef as one of this new
Signers.Over the last months, we have been increasingly aware of the limitations of requiring a full blockchain client running in local. Even light nodes are not light enough and very error-prone.
An alternative that we've discussed many times is to implement some sort of "wallet" or "signer", while using an external blockchain client (e.g., a self-managed but remote ethereum node, or directly, providers like Infura). However, we've been reluctant to "get our hands dirty" with implementing a wallet ourselves (which, IMHO, it's a wise position).
Our recent experience with incentivized testnet has shifted the balance towards facilitating lives of node operators and stakers, and implement some kind of light-weight signing functionality (see @KPrasch's awesome PoC in #1629) that can be combined with external blockchain clients.
When it comes to engineer a solution that accommodates this functionality, I think we need to solve a problem on the scope of our current blockchain client interface (i.e.,
nucypher.blockchain.eth.client.Web3Client). The problem is that our current clients are meant to be used both as a blockchain clients (e.g., executing calls, sending TXs, etc) and as signers (e.g., signing TXs, unlocking accounts, etc). My proposal is to extract the signing API from the client to a separateSignerinterface.That would have many advantages:
Assuming we go down this road, I personally vote for at least implementing support for Clef, for several reasons:
confirmActivity).