3 ms·
It seems to me that CT (or its operators?) should take a lesson from adversarial blockchains (cryptocurrency) here: a new state should not be propagated without
by amluto 4y ago
It seems to me that CT (or its operators?) should take a lesson from adversarial blockchains (cryptocurrency) here: a new state should not be propagated without verification.
I think that, for CT, this should be fairly straightforward. Some machine with access to the signing keys should generate new nodes and signatures and push those internally to some front-end machines. The latter (on separate physical machines) should fully validate the result before propagating it any farther. No outside user sees the result until at least, say, 3 machines fully validate it. Then, if validation fails, the state could be rolled back internally.
When a rollback occurs, the signing machine would think it’s signing a new, conflicting state, but that’s fine: no one outside the log operator has seen the old conflicting state.
- j16sdiz 4y agoIn Blockchain, there are concurrent, multiple, anonymous appends to that log. That's why you need concenses. In CT, all append are controlled. Nothing is anonymous.
- lima 4y agoA distributed consensus mechanism provides byzantine fault tolerance - which is helpful even with trusted actors, as this event demonstrates.
- amluto 4y agoIt shouldn’t even need much distribution or any protocol change. If every CT operator required three separate nodes to validate a proposed new block before distributing that block, then the only way to corrupt the log would be for an invalid block to pass verification three times (due to a bug or to a vanishingly unlikely coincidence of hardware errors) or for something to accidentally publish the block without verification. Unlike cryptocurrency, this would require no fancy public protocols, negligible computational resources, and no additional verification overhead outside the log operator at all.
- deleted 4y ago[deleted]