microsoft / scitt-ccf-ledger

Supply Chain Integrity Transparency and Trust ledger application using Confidential Consortium Framework (CCF)
MIT License
35 stars 16 forks source link

Remove unused prefix tree support #216

Closed ivarprudnikov closed 1 week ago

ivarprudnikov commented 2 weeks ago

Prefix tree is an experimental feature designed to enable a better search for receipts. This is not used at the moment so I am tempted to remove it from the codebase (it will still be in git history though)

achamayou commented 2 weeks ago

@andpiccione the purpose of the prefix tree was to provide an efficient way to snapshot the state of the feeds, and allow the cheap extraction of read receipts from that snapshot, even outside the enclave.

The idea is that you can sign the prefix tree every so often (create a write receipt over the root of the prefix tree), and with that write receipt + proofs you extract from the read receipt, you can get transparent signed statements that say "Today, foo is version 5, bar is version 8 (with proofs to each feed)". You can do this from anywhere, assuming you dump that write receipt and the contents of the prefix tree. This is obviously attractive if you have a single global instance of the service, because you just need to work out snapshot distribution and that gives every relying party all the information they need (sort of, there are issues with intra-day updates obviously).

In practice, there is one very substantial drawback that means this is unlikely to ever be practical: you must keep (and distribute) state that's linear in the number of feeds you track, whereas the current design only requires state that's constant size.

The outside the enclave bit is also irrelevant at this point, but more importantly, distributing write receipts with their respective artefacts is a lot more efficient on average, works independently of the number of instances of the transparency service, and is not susceptible to refresh delays. If you want to provide a centralised, indexed repository of write receipts, a database works very well. The only feature you lose from the prefix tree is the notion of completeness (i.e. being able to prove there was no feed foobar at a given transaction id), but that's an audit scenario more than an relying party use case.

My understanding is that there are no plans to make use of this feature, and I don't see anything that would change that, so I agree with @ivarprudnikov that it is right to remove it.

ivarprudnikov commented 1 week ago

@andpiccione does the above answer your question?