Hacker News Reader

Comment by smt88 | Hacker News Reader

I had a real experience that perfectly reflects the research presented here (safer ledgers useful, blockchains are not).

I accidentally got wrapped up in a project to automate some HR functions, and the product manager demanded that it must be blockchain because blockchains are the future.

It turns out that append-only databases are well-suited for HR records, and (especially when dealing with things like background checks, immigration papers, etc.) it doesn't hurt to have a history with cryptographically-verifiable date stamps.

We used an existing database that did all of the above, told everyone it was blockchain, and released the product.

That was a great strategy for a few years until everyone realized blockchain was a boondoggle, and now you never need to work with anyone who still believes in it. You can just understand their mention of blockchain to be a sign that you need to avoid doing business with them.

View on HN

" it must be blockchain because blockchains are the future."

Wow, that's next level PM cringe.

I'm glad you were able to jujitsu your way around it.

Blockchains are great for one-thing... guarantee that data is being appended and never modified.

When you want to display a record, you can aggregate the data historically and allow people to see changes and attribute them to users and time but you can always see what was originally added.

However that's kinda risky for HR because anything committed to that DB will be there... forever!

That’s an event sourcing architecture, and something like Kafka will do it much better than a blockchain.

The forever problem can be, ironically, resolved with crypto. If you encrypt each employer record with an employee key then, if the employee data needs to be deleted you just delete the key and the data is gone.

How about for sharing data between semi-co-operating companies?

One problem with sharing data between multiple parties is that you need somewhere central to store it, somewhere that's ultimately trusted. If you decide to trust one party, they could still make mistakes, have downtime, stop supporting the project that requires the shared data, or go rogue.

I'm perhaps too ignorant of blockchain, but could it help with this scenario? Does it give a better promise of availability and more trust in its consistency and integrity?

edit: I'm thinking here of a blockchain whose only users are this group of companies, not a public system. I don't know if a blockchain becomes useless when it is only used by a small group.

Not really with crypto, if you use a a not forever secure crypto algo.

This argument is equivalent to saying a data center isn't secure because a nuclear bomb can fall on it.

The usual reason for doing this is to convince auditors or lawyers that the system is in compliance with GDPR or similar legislation, not to resist the attention of three letter agencies. If you can say you’re using industry standard / government approved crypto it should be fine.

> Blockchains are great for one-thing... guarantee that data is being appended and never modified.

in a distributed, trustless fashion

If it's not distributed or trustless, you can do the same without the blockchain.

Yeah, a git repo covers 99% of these pseudo-blockchain usecases

A git repo is a blockchain...

Git is why people like blockchains so much - the value is clear, since it's what we interact with all day.

Git is a Merkle tree but to be a full blockchain it would need a consensus algorithm. Clones can add diffrent commits; nothing ensures they agree.

That's not the full story, certificate transparency logs (and many other applications) achieve that without using a blockchain.

This is true as long as you trust the issuer of the transparency log to not go back and re-write the history of the log. That's a trust assumption that most folks are fine with, but it should be explicitly be understood to be there.

A blockchain takes that trust assumption and spreads it out amongst the social consensus of the chain, so re-witing of history could only occur if there is a consensus to do so.

Who is both internal enough to get a copy of your HR database but external enough that their logs can't be changed as easily as a non-blockchain system's?

Honestly, it might be possible to do this magic by having the third party issue a signing certificate based on a hash.

Send me a hash as new data is added to your DB and I cut you a cert... the next cert includes hash of the last cert plus the new hash you just gave me...

An external service that signs and dates [a hash of] your database is very viable! But at that point there's no longer a distributed ledger.

Isn't the whole idea of certificate transparency to detect that situation? That's why the system also has auditors which would detect such tampering.

CT doesn’t require anonymity: the trust in CT comes from the tamper-evident design creating a risk to your reputation if you cheat. Once you have third-party trust relationships you no longer benefit from the expensive blockchain mechanism designed to work without them.

The challenge is that if a discrepency is shown, how do you know who is lying? The whistleblowers or the CT log vendor? A consensus mechanism built on top of the log would be able to show the 'history of the history' to enable folks to make better determinations on who to trust or not.

The CT log vendor is signing entries, so although you don't know what the "true" state of the log is, you know that you cannot trust the CT log vendor.

Can be removed/rewinded if you are in a shorter chain of the fork while the block was mined.

>>It turns out that append-only databases are well-suited for HR records

It may seem so, bu then You find out what are Your governments limit's for storing workers data, and Your company lawyers forces You to make it possible to delete everything that past that limit to limit legal risk and be gdpr compliant. And at this moment You find out that world is not constant and far from Your ideal model of spherical cow.

Can we design an append-only database that also allows for deletions if you replace those deletions with a direct reference to the hash that was once computed at that point in the chain?

Yes, I know this isn’t strictly “append only”, but it still gives the ability to prevent silent updates and silent deletes. Any record that’s deleted must be replaced with something that indicates that it was deleted.

If the database is distributed you have no way of enforcing that the other peers don't keep shadow copies of the data that is supposed to be deleted.

If you know you can trust all your peers to act in good faith, then you might as well just use a regular database as none of your peers will edit old records due to being good actors.

Yeah, what I'm describing is more like a journaled database, not bLoCkChaIn tEcHnOloGy.

There's a chain for sure, but nothing that allows it to be decentralized, or 100% immutable, etc.

Such a database already exists, and it is called AWS QLDB.

Deleting a document revision in QLDB does not actually delete it, but rather moves the last known revision into a shadow history table that accompanies every table in QLDB. The full document change history lookup has to accommodate in the code path a fallback to the history table when a document revision can't be located in the main data entity table. If no document revision exists in either table, it has never existed in the database.

Use envelope encryption and wipe the key after the fact.

Bonus: use a committing AEAD mode and use the previous record as AEAD when writing the record.

You can keep the ciphertext in the ledger forever. Zeroing out the wrapped key makes it unretrievable.

Small nitpick: "You" and "Your" don't need to be capitalized. It makes reading the text a bit weird.

Thank you [see what I did here :)] for pointing this out - I'm not native and on top of that used to learn german (never went anywhere with it, but the capitalization of every noun somehow stayed with me longer than necessary).

Add english oddities such as capitalizing first person pronoun (which I do, as you probably noticed) and it's kinda easy to be oblivious that I do this.

Kind of off-topic: in what kind of weird organisation is a product manager dictating engineering decisions?!

In most of them.

It's not difficult: You simply dictate requirements that can be only solved by one engineering solution.

But that, in essence, is part of the challenge with blockchain. People treat it as a self-describing requirement. ("This must be on the blockchain") rather than a technical solution for a dubious set of problems most people don't have.

It was a small startup, so "product manager" wasn't a narrow role with clear boundaries. Their job was to bridge the clients and the software team, and they insisted that clients would jump at the chance to have a blockchain vendor.

They're not wrong. When a prospective client asks us if we do AI, we have to say yes, otherwise we will lose them on the spot. At least in this case it's not really wrong (we do machine learning).

> I accidentally got wrapped up in a project to automate some HR functions, and the product manager demanded that it must be blockchain because blockchains are the future.

Stomps on brake with both feet

Reply on news.ycombinator.com