patch protocol

[gdassori]

How the patch protocol has to be done?

Option 1, incremental patches:

Having at height 100 the current shard of unspents:
{ab, bb, df, ca, bf}

At height 101, to represent the spending of ab and the birth of cd we would have:
-ab +cd

At height 102, to represent the spending of bb, cd, and the birth of dd we would have:
-bb -cd +dd

This means we would have some sort of "chain of patches" that have to be applied, and so downloaded, with no inconsistencies (what goes out must exist).

A client would download the ~ 4MB utxo shard, and then roughly 35 bytes for any unspent going out, and the average size of anyone going in (est: the double, 70-80 bytes \ utxo).
I'd say, with an average of 3000 outpoints spent per block, and a 1024 shard, that a patch would be very less than 1kb per block.

Assuming these calculations looks worth release every 5000 blocks (30\35 days), a new shard, cause every 4000 blocks the size of patches may exceed the size of the shard itself, which should be roughly 4\5MB at the time of writing, with a 4.4GB utxo size.

---

Option 2, summary (atomic) patches:

Having at height 100 the same shard of unspents, at height 101 to represent the spending of ab and the birth of cd we have the same patch.

What changes is the patch at height 102, which is related to the original shard, so the patch at height 102 would be:
-ab, -bb, +dd and only the final state is necessary.

This way the fresh connected clients are not required to download and apply a "patch of chains" to have the current state, but the removal of entries from the local utxo DB must account that non-existing data deletions (already issued by previous patches) will be requested.

Also, even if it's true that only the last patch would be needed for a client to sync with the current utxo state, we must note that the patch file is accumulating deletions over time, and the size of the last patches before issuing a new block could have been grown a lot.

However, more calculations are needed, because if it's true that this way increases the accumulation of deletions in the last patch files, it's also notable that intermediate states are discarded (no cd at all is seen in the patch at height 102).

However, this approach would penalize the "always-on" users, who:

• download the patches incrementally, so doesn't benefit states pruning.
• are asked to download patches increasing in size for no reason.
• are asked to do inconsistent deletions.

And also requires the issuers to keep the intermediate states available for diffing and patching issuance.

Sounds very unfair and with little or no benefits for most of the network participants, I'd go for the incremental, keeping this just as remarks on why the summary option is a bad idea.