Skip to content

Comment on The Valley of Webhooksparent

Comments

I'm not sure what a private blockchain is, but a permissioned blockchain is one where only certain parties have keys that allow them to write blocks. You end up with a message queue optimized to eliminate anything that would lead to the inconsistency nonsense that this article is talking about as soon as it is detected. It then becomes the writer's problem to retransmit in a way that doesn't cause a problem next time, rather than the reader's problem to recover.

The craziness comes in when you'll accept blocks from anybody willing to burn enough electricity to do so, or gamble enough tokens to do so, or whatever other artificial scarcity game people like to play. But if you're only planning to consume data from the eight other companies you do business with then there's no reason to bother with any of that, you can just hard code their public keys into your consensus protocol and you've sidestepped the nonsense.

What if the keys leak and need to be rotated?

If you're exchanging public keys to configure your node with in the first place, then presumably you have a trusted side channel for that kind of thing. It's equivalent to the webhook situation re: what if the domain name changes?

If you don't have such a channel then there's always social key recovery schemes, but I don't think there's a particular pattern that you can just adopt. You're now in participate-in-the-research mode.

If the hardcoded domain name changes, then the app needs to be recompiled with new domain name and that's it. The service is instantly restored and no data needs to be updated to reflect the change. In fact, the server side doesn't even need to be made aware there was any change. It just continues serving data as normal.

If you have a blockchain, and the blockchain requires a key to write to, and there's only one key, and the private key gets stolen by malicious email attachment and posted on darkweb - what now? Do you need a whole new blockchain? What happens to data from the old blockchain, how do you verify the new data is correct? Or do you keep the blockchain and use the leaked key to revoke the key and set a new one? How do we know the new key is legitimate?

I genuinely don't know how to recover in this situation and would really like for someone to walk me through the process.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.