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.
Please see features.md for user stories related to wallets. These are the priority and focal point for our work.
Google sheet with recommendations and ideas from Dan and Ed
Jan. 23 charge to the wallet team
|
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.
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 - |