(no title)
eudoxus | 1 year ago
Any insight as to why you think blockchains can't handle this?
The only fundemental difference between blockchains and transparency logs is the trust assumptions and censorship resistence. Its fairly easy to reason about a transparency log as a permissioned blockchain. Conversely, a blockchain could be seen as a permissionless transparency log.
JanisErdmanis|1 year ago
This is not the case. The essence of the transparency logs are thin clients which can do monitoring of the append only nature of the ledger. This allows accountability to be distributed more widelly wheras in blockchain one would need to retrieve the full ledger to do such testing.
On the other hand the responsability of adding records to the ledger in transparency log lies to a single authorithy whereas in permissionless blockchain it lies to individuals who solve the puzzle. However in practice there is centralisation of the computation power making the record inclusion also centralised.
The censorship resistance is somewhat a wicked problem. With transparency logs solve the by counter logging. In cases authorithy does not accepts a record it can be delivered to a counter authorithy. The counter authorithy also keeps records of main authorithy and thus users can eventually switch to it. This is though a manual process, but perhaps one can figure out a protocol to do such thing automatically.
kfreds|1 year ago
The fundamental value of a transparency log is to provide trivial discoverability. Say an attacker has compromised a code signing key and is using it to sign a malicious software update. Let's also assume that the attacker can distribute this update to a client that will trust it. Such a targeted attack is not trivially discoverable by the software vendor if the client's trust policy only requires a code signing signature by the compromised key. If the client's trust policy were to also require a proof that the signature is included in a trusted transparency log, the software vendor can discover the attack if it monitors the log. Note that transparency logs doesn't directly prevent attacks - it makes them discoverable.
Transparency systems based on transparency logs have five components: Log, Submitter, Client, Monitor and Auditor or Witness(es). The Log is a Merkle tree with its current root tree hash signed. In the example above the Client would be the software updating mechanism, which has a given Log in its trust policy. The Client will only trust a software update from the Submitter if the Submitter's signature and the update's hash are included in the Log. The Monitor regularly polls the Log for new entries it cares about, in this case software updates signed by the Submitter's public key. The Auditor is another party that regularly polls the Log, but the Auditor's job is not to discover log entries that constitute an attack. Instead, the Auditor's job is to monitor the Log's consistency - i.e. whether the log has removed any previously added entries. This is called a split-view attack, and it is a concern in all widely deployed transparency logs today. An alternative to Auditors is cosigning Witnesses, which proactively witness a Log's consistency, and whose witness signatures are required by the Client in order for it to trust the Log. This results in a much stronger threat model. See sigsum.org for more details on such a design.
Getting back to your comment:
- Yes, Clients are "thin", to use blockchain terminology, but they don't monitor the Log in order to detect attacks. The Log is part of their trust policy for making some trust decision, such as trusting a software update. Monitoring the Log for new entries that indicate e.g. key compromise is the Monitor's job.
- Regarding accountability: The Client's trust policy in conjunction with the Log and the Monitor increases the Submitter's accountability to the Client. Similarly the Auditors or Witnesses increases the Log's accountability to Clients, Submitter and Monitors.
- Regarding inclusion in the Log (or blockchain) I'd use the word "authority" as in who has the power to prevent something from being included. As you point out a transparency log is a central entity which has the sole power to decide what gets included or not. If the log is shut down, or its public key destroyed, nor more inclusions are possible. In this sense a blockchain is far more censorship-resistant than a transparency log. In other words, it is important that Clients trust multiple logs for redundancy. The consensus mechanism of a transparencty log is simply a public-key signature, as opposed to an emergent authority in the form of e.g. a distributed timestamp server based on SHA256. This vast difference in how the database's integrity is defined - the consensus mechanism - is why blockchains work better than transparency logs for censorship-resistant digital currency, whereas transparency logs work better than blockchains for efficient inclusion- and consistency proofs.
kfreds|1 year ago
As you point out yourself the trust assumptions are fundamentally different. As a result a transparency log can produce an inclusion proof and a consistency proof that is on the order of a few kilobytes large. A trust policy for such a verifier would be of similar size.
How large would the equivalent inclusion- and consistency proofs for a proof-of-work-based blockchain be? What would the trust policy look like? Presumably the verifier would use some historical block as a starting point, which would constitute the trust policy. It would then need to process the entire blockchain from that point and onwards up until the point of inclusion. That's way more than a few kilobytes.
Again, I haven't paid attention to blockchains for a long time so there might be some consensus mechanism out there that has solved this somehow. I'd love to be proven wrong.