WIP
Scope
A place to gather brilliant thoughts regarding using peek in conflict resolution.
Problem statement
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".
Open topics
- how should the COMM event marker look like?