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-644Getting issue details... STATUS 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 - RCHAIN-2866Getting issue details... STATUS . No further action required today.
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 - an you expand on: Dan - |