From the Linera SDK we know that we need to run a Linera service node then client can access the blockchain through that node. But in the most case, people will access blockchain with client such as browser extension, desktop application. So what will be the wallet like in future? And for most blockchains, due to that chain data is public, so the client do not need to keep any chain data and just need to access public chain node rpc interface. How will be that processed in Linera in future?
Interesting question!
As far as I know, in the future, the Linera Wallet will be represented as browser extension, and wallets are going to include a node and are meant to sign blocks.
Looking forward to more insights on this!
Not sure about the final design and implementation about that.
But as I can imagine, will that invade browser low level stack too deep ? The extension has to implement all features of the service node, may be with some frontend libraries like libp2p-js to build a p2p service, am I right ?
And the browser extension has another problem: sometimes (or sometime) it’ll broke then you lose all data of the extension (I lose 750 USDC before due to a late backup of private key, hahaha), i’m not sure if it could be solved elegantly for the service node (for metamesk, you just need to backup your private key before use it).
Hey @kikakkz, Great questions!
-
Indeed, in the future, we want web3 apps to be able to connect easily to a trusted user wallet. Instead of a local binary tool, this wallet will be implemented as a browser extension (and perhaps later mobile and desktop apps). We plan to start working on the browser extension very soon.
-
We generally try to empower users and avoid RPC services as much as possible, so the wallet browser extension will hold a local node for the chains owned by the user. In our current design, this means embedding a Wasm VM in the extension so that the user wallets can execute their own transactions and maintain a trusted local state.
-
Thanks to the microchain approach, maintaining user chains locally should not require storing too many blocks. Also, blocks and execution states should be small. If the blocks are lost, the extension will just have to download them again from the network and rebuild the local chain state. What must be persisted is a small amount of data required for the security of the wallet. (This includes user keys and some important block headers.) Some browsers provide secure cloud storage: together with passphrase-based encryption, this should be enough to get us started until we have more options available (such as hardware wallets or external wallet services).
Well, that’s explain a lot. I’m eager to start the first implementation of the wallet as a part of the login system of ResPeer.
@ma2bd will the official team has some draft design about the wallet implementation ? I’m very interesting to do some early research for that.
Thanks @kikakkz. We’ll let you know when we get started. My current mental model for the wallet implementation is really like running the CLI tool linera service
except in a browser extension, with proper key management, and a “connect” button on web pages.