Wallet integration

[vlopes11]

Tasks

Frontend

• Create an example CLI application for sov-bank
• Create an example Web application for sov-bank

Encoding Library

• feat: add no-std to rollup-interface #1077
• feat: add sov-modules-core #1126
• feat: add serde feature for non-native serialization #1141
• feat: add try_from slice for signature & keys #1145
• feat: initial implementation sov-snap-generator#1
• Define the fallback strategy for more than 255 enum variants

Metamask Snap

• feat: initial sov-snap implementation sov-snap#1
• feat: add borsh schema to sign transaction sov-snap#3
• feat: add wasm tx generator for snap sign sov-snap#4
• feat: add package structure sov-snap#5
• Support Metamask socket request to unlock CLI applications outside the browser

Sequencer

• Implement an example sequencer for sov-bank

Summary

An integration interface that will receive transactions from various frontends and forward them to the sov-sequencer, so these can be received by the rollup.

Frontend

Can be any tool that invokes the TypeScript Sovereign Metamask Snap, including but not limited to browsers (natively) and CLI applications (probably through WASM modules).

Encoding Library

Will be responsible for receiving a human friendly transaction format, and encode it as Borsh. The Borsh encoded transaction will be the one included on-chain; hence, will be the signed transaction.

This library is expected to be implemented per rollup. As SDK, we should have some tooling that will generate automatically such library, per message. This means we might face challenges with enums discriminants. One example is if we are to encode the CallMessage of sov-bank: as per specification, Borsh will constrain us to 255 variants, that are probably enough. However, we need a fallback strategy in case more variants are required.

Metamask Snap

Will be responsible for signing transactions, provided a Metamask key seed. It means that any system that supports Metamask will also have the ability to sign transactions for the rollup.

Also, such library should support interacting with metamask via network socket so applications outside a browser context will be able to access the service. It means the library should potentially, on request, make available a network socket for CLI applications. Naturally, this socket would be critical - as it can sign transactions - and some security wards must be in place.

Sequencer

The sequencer will receive the signed transaction via RPC, and will broadcast them into the rollup.

It must be agnostic regarding the encoding strategy. For this task, we will use as input the signed transaction from the Metamask Snap, but we might as well take input from a HW wallet. With a payload as simple as (transaction, signature, public key), that would be trivial.

Note: public key might be optional here, as a transaction might either contain the public key, or a zero-knowledge proof that will take the signature and transaction as argument, and check the validity. This would unlock privacy-preserving transactions. However, if we assume that to be the case, we might want a trait that defines a transaction validity, such as fn(&self, signature: S) -> bool

[cemozerr]

Looks great. Excited to see the results!

[vlopes11]

We will make RuntimeCall from demo-stf as WASM module to be consumed by the library, and expose it to typescript.

A next step is to make any DispatchInfo exportable this way, with a similar interface, that can be consumed by any Snap.