Page Comparison

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.

...

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
History	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	One of the central requirement questions about the auditability of Revs is whether RChain needs to store Rev transaction history forever, or just for some amount of time. For the sake of argument, let’s say RChain needs to store it for years… I’ve been thinking a bit tonight about how a Rev history mechanism could be kept separate from the Rev balance map (as described above a few hours ago), so the primary Rev comm events are not slowed down. In some other domains, such as electric grid operations with which I’m familiar, transactional operational and historian systems are separated so the operational demands are never unnecessarily blocked. In those systems the historian software can buffer transaction logs and catch up with its writes to the history database after peak loads, except in extreme cases. Old history (after a few years if there is no business need to retain it) can be archived or purged. In the case of RChain, a separate historian mechanism (i.e., one or more contracts to keep history) for Rev could be created and receive from the main Rev contract a journal of each payment transaction (Alice pays Bob, or Alice pays fees to run code). The Rev Historian contract(s) would then write (journal) to disk at every block consensus. That set of “write to history” protocols could be contract-specific (e.g. only for Revs) and would be aware of block time, and clique depth could be computed. An index could be written on top of the historian to support queries, explorers, etc. Let’s pose the following questions: How would one conduct an audit of Rev controlled in normal (single public key) wallet contract? How would one conduct an audit of the total amount of Rev? I know that in the more modern world with DHTs, systems can now scale more linearly. However, in the current RChain architecture, the burdens of tuplespace memory and storage are very big issues. So, if we can remove some of the burden of history off the tuplespace, it might have a better chance of scaling.	Ed	Chris - It seems unnecessary to store in the tuplespace. We could use a block explorer approach

	Maybe another way to look at this is that we're rolling WalletCheck into the mint/rev contract and expanding it to serve as a hitching post after Genesis. But we can't move purses around independently... So not quite the same. How does an entry keyed by name get created? I guess a key holder does a special kind of send... I suppose this allows economic "side chains" that can use full concurrency Oh... A key shouldn't be necessary to get in the map with a zero balance. Maybe bundle0 should be used as the hashing function		Chris - an you expand on: `Maybe bundle0 should be used as the hashing function` Dan - bundle0 is a one-way function to something that's good for comparison and not much else I think it's cheaper to compute than a secure hash And it's 100% guaranteed collision-proof
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 - Cheers, thanks for the answers. #3 was meant specifically during Rev issuance. My question was if it's technically possible to generate a wallet with REVS at genesis without knowing the private key of the original RHOC address. As in, if a user can sign a specific message from the address with RHOCS (showing they control the private keys), a wallet with the REVS will be generated. I guess, this would be more like a token swap, instead of an "issuance". Using 3rd party tools to generate the pairs from question #2 is indeed fair enough. Still, maybe a good point to add to the FAQ.
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.

Wallet proposal (Note: we decided to rename terms such that "wallet" is not used for on-chain components)

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

Versions Compared

Old Version 18

New Version Current

Key

Purpose of this page

Recommendation and discussion following Jan. 24 session

Next steps