6 ms·

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 pro

by smt88 4y ago

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.

WrtCdEvrydy 4y ago
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!
- andreareina 4y ago
  That's not the full story, certificate transparency logs (and many other applications) achieve that without using a blockchain.
  - yokem55 4y ago
    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.
    - Dylan16807 4y ago
      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?
      - WrtCdEvrydy 4y ago
        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...
        Dylan16807 4y ago
        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.
    - ulrikrasmussen 4y ago
      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.
      - acdha 4y ago
        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.
      - yokem55 4y ago
        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.
- Nursie 4y ago
  > 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.
  - namdnay 4y ago
    Yeah, a git repo covers 99% of these pseudo-blockchain usecases
    - chaxor 4y ago
      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.
      - ZiiS 4y ago
        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.
- mnd999 4y ago
  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.
  - kenniskrag 4y ago
    Not really with crypto, if you use a a not forever secure crypto algo.
    - mnd999 4y ago
      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.
    - newswasboring 4y ago
      This argument is equivalent to saying a data center isn't secure because a nuclear bomb can fall on it.
  - tokamak-teapot 4y ago
    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.
- kenniskrag 4y ago
  Can be removed/rewinded if you are in a shorter chain of the fork while the block was mined.
namdnay 4y ago
Kind of off-topic: in what kind of weird organisation is a product manager dictating engineering decisions?!
- deanCommie 4y ago
  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.
- smt88 4y ago
  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.
  - isolli 4y ago
    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).
v-erne 4y ago
>>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.
- function_seven 4y ago
  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.
  - Drakim 4y ago
    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.
    - function_seven 4y ago
      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.
  - inkyoto 4y ago
    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.
jasmer 4y ago
" 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.
truemotive 4y ago
> 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

by smt88 4y ago

WrtCdEvrydy 4y ago

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!

andreareina 4y ago
That's not the full story, certificate transparency logs (and many other applications) achieve that without using a blockchain.
- yokem55 4y ago
  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.
  - Dylan16807 4y ago
    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?
    - WrtCdEvrydy 4y ago
      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...
      - Dylan16807 4y ago
        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.
  - ulrikrasmussen 4y ago
    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.
    - acdha 4y ago
      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.
    - yokem55 4y ago
      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.
Nursie 4y ago
> 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.
- namdnay 4y ago
  Yeah, a git repo covers 99% of these pseudo-blockchain usecases
  - chaxor 4y ago
    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.
    - ZiiS 4y ago
      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.
mnd999 4y ago
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.
- kenniskrag 4y ago
  Not really with crypto, if you use a a not forever secure crypto algo.
  - mnd999 4y ago
    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.
  - newswasboring 4y ago
    This argument is equivalent to saying a data center isn't secure because a nuclear bomb can fall on it.
- tokamak-teapot 4y ago
  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.
kenniskrag 4y ago
Can be removed/rewinded if you are in a shorter chain of the fork while the block was mined.

namdnay 4y ago

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

deanCommie 4y ago
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.
smt88 4y ago
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.
- isolli 4y ago
  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).

v-erne 4y ago

>>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.

function_seven 4y ago
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.
- Drakim 4y ago
  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.
  - function_seven 4y ago
    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.
- inkyoto 4y ago
  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.

jasmer 4y ago

" 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.

truemotive 4y ago

> 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