Page Comparison

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
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
AuditHistory	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

	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

...

Versions Compared

Old Version 15

New Version 16

Key

Purpose of this page