Certificate Transparency: Public, verifiable, append-only logs

The author abruptly dismisses blockchain technologies as an approach to this problem, but then goes on to propose a peer-to-peer network that shares some important features with a blockchain:

"Monitoring logs, obtaining consistency and inclusion proofs, and so forth can be done by directly querying the log, but checking for consistent views is more difficult. To do this, the various log clients will gossip. In the long run, this could occur over a variety of protocols—XMPP, SMTP, peer-to-peer connections, etc.—but our first suggestion is to piggyback gossip on TLS. Whenever a client connects to a server, it sends a few items to the server, which the server may verify or merely cache; in return the server sends a few items back from its cache. This establishes what is effectively a peer-to-peer network between the clients."

Except that here, there seem to be multiple trees of hashes (one per domain, if I'm understanding correctly) compared to Bitcoin's single root block.

Given the similarities, I'm left wondering what the fundamental differences really are between a blockchain and this newly proposed P2P network. The new type of network does no proof of work, but it has no need to avoid double spending as it isn't a currency, so that seems fine. What else is different?

Certificate Transparency has one glaring issue. The Merkel tree proofs can only prove a certificate is present (not that it is absent). The current proposal does not require "examiners" of the Merkle tree to be provided with the entire contents of the Merkle tree. This means blank check certificates can be issued to governments and companies, be validated and not be detected unless we catch their use in the act.

The whole idea of using a Merkle tree to "save energy" is a bit of a sham. The tree produced is imbalanced and will contain a chain of O(N) hashes to validate a certificate, which is the same cost as a signed block chain system (no proof of work).