WIP
A place to gather brilliant thoughts regarding using peek in conflict resolution.
The current implementation of conflict resolution for blocks lives https://github.com/rchain/rchain/blob/dev/casper/src/main/scala/coop/rchain/casper/EstimatorHelper.scala and boils down to
b1AncestorChannels.intersect(b2AncestorChannels).nonEmpty |
Two validators V1 and V2 are deploying rholang.
The first step for this mechanism to work is to charge for a deploy (move rev from deployers vault to validators vault)
This means looking up deployers vault from the vault map (held by the RevVault contract).
The way rholang currently deals with this action is by generating a consume and a produce (destroy, create new).
Since there is no way of knowing if the data changed or not - the new values diverge as they were created by different validators - this will conflict and create a contention point.
But rholang will be able to 'peek' - deliver the value without modifying the content of the tuplespace.
Now this means that the log will contain a COMM event that is marked as 'peek' which essentially means "I can safely ignore conflicts with other peeks on this channel".
This writeup is a follow up to an ongoing discussion regarding "conflicts during rev transfers".
Two types of change need to be identified:
To be able to track the 1st case the random part of a term is used.
The second part is tricky: on one hand it is inefficient to change the random part of a piece of data every time it's read but at the same time this allows the system to track execution paths (event log).
This has been proven problematic when a "hacked peek" was introduced in Registry (https://github.com/rchain/rchain/pull/1817).
Current implementation of RSpace requires external sources to point out that a value is peeked (rholang syntax) and it depends on the above sequence number to be able to properly replay deploys.
All of the above is discussed because of one goal: merge blocks that collide on same channels.
High level overview of the scenario discussed:
User A transfers rev to User B using validator V1. This results in:
User C transfers rev to User D using validator V2. This results in:
both blocks contain data on moving rev and at some point in the chain there will be a need to merge the separate states.
Currently the block merging rules will fail this attempt for various reasons, which all boil down:
This restriction can be further specified as:
To address the first limitation peek was proposed and partially implemented.
The second limitation needs to be solved in merging rules.
A new approach has been proposed that could solve a larger class of problems than peek:
RSpace could track the data part during contract execution and identify what changed and what didn't. It would still produce an event log but it could then intervene on checkpoint creation essentially making the peeked data be transparent (reverting the value and the random part to the initial value). This makes the conflict resolution rules that are needed for contracts pretty straight forward - anything marked by RSpace as "changed" will can be a conflict, the rest can be safely ignored.
This boils down to:
block B1_1 and B1_2 from the previous example would represent only the states of the rev vault balances that changed during respective deployments, ignoring most of the data fetching.
The event logs would be easily prunable enabling a simple check (channels B1_1 do not intersect with B1_2? it's ok to merge).
The upside is that this keeps the rules contained in one spot and makes the a "one layer" concern. It also enables a straight forward implementation of trie merging in the tuplespace.
The downsides are: