Wallet
- Kelly Foster
- Chris Boscolo
- Dan Connolly
Purpose of this page
The goal of this page is to consolidate documents and Jira tickets related to wallets for the purpose of supporting the team learning about this features, status of implementation, and open questions prior to the working session Jan. 23-25.
Action requested Please edit this page as needed to add or correct information and create a list of issues to address during the working session.
Mercury requirements
Please see features.md for user stories related to wallets. These are the priority and focal point for our work.
- https://github.com/rchain/rchain/pull/2127 - Ed's open PR
- https://github.com/rchain/rchain/pull/2037 - Ovidiu's open PR
- https://github.com/rchain/rchain/pull/2032 - Ovidui's open PR
Relevant wiki pages
Other resources
Google sheet with recommendations and ideas from Dan and Ed
Relevant Jira issues
Open questions and ideas
Add your questions and ideas below
Jan. 23 charge to the wallet team
- Bootstrap issue Provide recommendation for how to handle the bootstrap problem where someone doesn't have REV and wants to set up a wallet
- Purse security
- Concern - code in Dan's demo needs revision to assure accuracy of reporting correctly
-
RCHAIN-644 - Security audit / Formal verification of contracts Done RCHAIN-2559
- Miller recently discussed a formal spec for purses in his SFBW talk:
- Auditing
- Be able to see a transaction log of all REV spent
- Unforgeable name as the nonce
- Purpose of the nonce is to prevent replay
- Is this the right approach?
- Concern that this will work with parallelism
- Greg: Unforgeable names should be the nonce in all cases
- See Ovidiu's write up Locker contract
- Ticket created for replay issue
Recommendation and discussion following Jan. 23 session
Posted by Chris Boscolo in Discord
I wanted to give a mini recap of some decisions we made that are a pretty significant departure from the current purse/wallet paradigms that we have been working on.
We decide that for Rev on RChain would use a map to represent owner -> Rev account balance. This would be handled via the Rev Smart contract. With this approach there are a few simplifications to how we use and track Rev:
1. All account balances can be queried obtained via this map
2. All transactions (Rev Transfers) happen via this smart contract making auditing very straight-forward
3. owner map keys can either be a representation of their public key pair OR hash of an unforgeable name held by a multisig smart contract
4. Users can receive Rev simply by creating a EC keypair and sharing the pubkey-hash with the entity sending it.
5. Deployments can be signed with a key in this map to pay for the execution of the deployed code. (Handled by the Capser contract.) We believe this simplification to wallets will make it easier to build wallet/deployment tools as well as shrinking the surface area of code that needs to be audited for security flaws.
Discussion
| Theme | Question | Asker | Discussion |
|---|---|---|---|
| Concurrency | Will this design create a bottleneck in terms of performance, because it would reduce the concurrency that would otherwise occur? Even for the same owner sending lots Rev transactions, we want to allow concurrency if possible. | Ed | Joshy - Unless some fancy commutativity check is implemented, this will impose a total ordering over all rev transactions |
| Concurrency | I've let it sink in for a little while, and I think my reaction is slightly sad to lose the concurrency model, but ultimately glad that decisions were made and we're moving forward. I'm wondering whether we could write the map-based rev contract to allow moving tokens in and out of the central map contract to and from purses/utxos. Wheels are turning in my head, and I'd be interested in writing some rholang if it sounds useful. | Joshy | Chris - The dev team talked about using a concurrent map to preserve concurrency |
| Concurrency | If unforgeable names can also be used as map keys (I see no benefit from hashing them) then maybe the interesting security properties are preserved. It does seem to impose a total order on transactions, but since we have postponed namespaces/sharding, maybe that's doesn't make much difference. | Dan | |
| Contract | How large might this contract grow in terms of the memory and storage footprint it will need? | Ed | Joshy -The contract will grow linearly in the number of keypairs used |
| Contract | Will the whole contract need to fit in memory at one time? | Ed | Joshy -This is probably not a good place to be optimizing storage, but I'm not really sure |
| Consensus | Does the whole REV contract state need to achieve consensus as one block, or can consensus occur in sub-sections? | Ed | Joshy -yes. consensus over the etire state every block. This means the dag will likely contain a chain-of-rev transactions e) If anything this will save space over the purse model by not having separate contracts for every rev wallet. Side question: does RChain store a complete tuplespace poststate in every block? |
| Consensus | If as one block, does this imply most block sizes will be large? | Ed | Joshy -If anything this will save space over the purse model by not having separate contracts for every rev wallet. Side question: does RChain store a complete tuplespace poststate in every block? |
| History | Will it keep its own on-chain history, or is that some DHT stored on-chain on the side, or derived by some other client or indexing service crawling through the block history? | Ed | Joshy -history will be stored on-chain |
How long will REV transaction history be kept?(edited) | Ed | Joshy -recent history will necessarily be kep back until the most recent finalized block. Probably validators will keep older history around much longer than that. | |
| History | Where will a wallet dApp retrieve the history of the user’s Rev sends, receives, and fees? | Ed | |
| History | How will RChain systems architecture separate what the database industry used to call OLTP, OLAP, and near real-time analytics? | Ed | |
| History | Ed | Chris - It seems unnecessary to store in the tuplespace. We could use a block explorer approach | |
Chris - an you expand on: Dan - | |||
| Map | The map tracks REV balance, but it's not the way to communicate your wallet address | Chris | Ovidiu - For each wallet containing REV there is an entry in the map Dan - Shared example of a contract https://github.com/Agoric/PlaygroundVat/blob/master/examples/contract/makeMint.js#L20 |
| Who has access to update the map? | Ovidiu | Chris - The REV contract. This replaces a component of the current MakeMint strategy Dan - Need to assure you can do atomic updates. | |
| Hardware wallet | 1. Does the current progress on the wallets make it easier to determine whether hardware wallets will be supported during the launch of Mercury? What are the expectations from the dev team? | Mr. T | Ed - The key management and signing capabilities of HW wallets are pretty distinct from the wallet dApp's interaction with the nodes. If the design of the transactions to be signed is similar to Ethereum (and @dckc: has done work on this), then HW wallet integration should be relatively straightforward. A wallet dApp prepares a transaction and sends it (or a hash of it) to the HW wallet (through a HW wallet-specific software integration) to be signed. Once signed, the wallet dApp sends it to the blockchain node. Note that the features.md list https://github.com/rchain/rchain/blob/dev/docs/features.md does not include integration with a HW wallet as a requirement for Mercury launch, and I agree with that. Integration with HW wallet can be added later by the co-op or a 3rd party wallet dApp provider. |
| Hardware wallet | 2. In case HW wallets are not supported, what would the process be like if you used multiple addresses containing RHOCS on a single HW wallet? Will a mnomic phrase be supported which will generate all underlying addresses? Maybe this is a point which could be clarified in the FAQ as well (support for mnomic phrases or not). | Mr. T | Ed - HD wallets, whether HW or SW, can generate lots of key-pairs. These key-pairs can be regenerated by other wallets or standalone tools, such as https://iancoleman.io/bip39/ . HD wallets are currently not on the Mercury features list, and I agree with that. Similar to the above, 3rd party wallet providers can supply HD capabilities. Dan - No, you can't get rev at Genesis without the private key of an Ethernet account with RHOC |
| Hardware wallet | 3. Would it technically be possible to sign a message to proof ownership of an address, instead of exposing the private key /mnomic phrase of a HW wallet? In this case the HW wallet wouldn't be exposed. Or is the private key necessary to create the JSON files/ wallets? | Mr. T | Ed - Once a wallet dApp has integration with the particular HW wallet product, the private key does not need to leave the HW wallet. I expect that multiple wallet dApps will emerge after Mercury launch with various capabilities. The co-op supplied wallet must at a minimum support the import and use of a private key. Mr. T - |
| Keys | public keys vs addresses, and ecrecover | Dan | Chris - the entry in a map is always a hash of the public key. The public key is always provided at deployment. This is still TBD as part of implementation conversation. Chris - we don't need ecrecover (like ETH). Chris - Discussion about which curve to use (ETH or ed...). We would still need the claim process at genesis to claim REV. |
Recommendation and discussion following Jan. 24 session
After further discussion, there was some a lot of concern that the above Map based approach would not leverage the concurrent capabilities of the RChain platform. So we spent the day walking through how to satisfy the Wallet requirements using the original OCAP Purse composition.
Next steps
- REV contract
- Two parts need to be done in Scala
- Need a Rholang primitive to support unforgeable name lock box (this can be added as a 2nd step if needed)
- TO DO - add picture and description of lock box idea
- Jan. 24 session - Team to sort out next steps for other aspects of implementation and sort out next steps
- Block explorer
- Block explorer