Purpose of this page
...
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