At DeSci Labs, we have strong requirements on deterministic resolution of data, and have been thinking about the impact of the late publishing attack vector on these. The reason we have such requirements is that we are building a system for versioned PID’s to be used as a core component in safekeeping the scientific record.
In the protocol consensus docs, this is mostly neglected for the single-user controller case through the conclusion that one does not want to attack oneself. Allow me to challenge this for a bit with a parallel from our nascent protocol:
A researcher makes a scientific publication which is ultimately stored on Ceramic. This publication is later proven to be fraudulent through community review. This should contribute to a negative reputation delta for the author, and this series of events must be historically verifiable. Alternatively, imagine the author made an honest mistake and later on updates the publication, which is later on approved by the community. The trace of such interaction is very valuable to paint the full picture of the conflict.
Now, what if the offending author started the stream with an anchored but unannounced tip? It is more or less a save checkpoint, or undo button, which the author can at a time of their choosing announce, and have the protocol consensus resolve to removal of the publishing history. It would be easy for a third party to create a service for automatically generating such a failsafe mechanism for newly created streams, more or less ruining the guarantees of deterministic resolution. In this case, using this loophole does not necessarily require a high understanding of the underlying mechanics.
The original data is still there if someone is pinning it, and the CID of that very content can be found computationally from the commit ID. So what we are wondering is basically this:
- Will a Ceramic node automatically unpin the consensus-discarded commits when an earlier fork is received from the network?
- When a new node joins the network, can it discover the full historical tree of a stream? In other words, does syncing only retrieve the “main” branch?
- If someone knows the now-removed commit ID, can it be resolved by a request to a node which has already done the historical change?
- Can a node detect these historical changes when they occur, and somehow emit events when it happens? If so, we can in the worst case keep track of these branches manually.
I’m very interested in both discussion whether my assumptions are correct, and what the node/network behavior is, and possibly should be, in these cases. Thanks!