Well, at least AI is going to be better than the blockchain hype. No one knew what “blockchain” was, how it worked, or what could be used for.
I had a very hard time explaining once you put something in the chain, you can’t easily pull it back out. If you wanted to verify documents, all you have to do is put a hash in a database table. Which we already had.
It has exactly one purpose: prevent any single entity from controlling the contents. That includes governments, business executives, lawyers, judges, and hackers. The only good thing is every single piece of data can be pulled out into a different data structure once you realize your mistake.
Note, I’m greatly oversimplifying all the details and I’m not referring to cryptocurrency.
> has exactly one purpose: prevent any single entity from controlling the contents.
I'd like to propose a different characterization: "Blockchain" is when you want unrestricted membership and participation.
Allowing anybody to spin up any number of new nodes they desire us the fundamental requirement which causes a cascade of other design decisions and feedback systems. (Mining, proof-of-X, etc.)
In contrast, deterring one entity from taking over can also be done with a regular distributed database, where the nodes--and which entities operate them--are determined in advance.
Sure, blockchain development has always been deeply tied to ideas of open membership and participation. I like those ideas too.
But that's a poor definition of a blockchain. A blockchain is merely a distributed ledger with certain properties from cryptography.
If you spin up a private bitcoin network, it's a blockchain even if nobody else knows or cares about it. Now, are non-open blockchains at all useful? I suspect so, but I don't know of any great examples.
The wide space between 'membership is determined in advance' and 'literally anyone can make a million identities at a whim' is worth exploring, IMO.
> A blockchain is merely a distributed ledger with certain properties from cryptography.
If we charitably assume "blockchain" has some engineering meaning (and it isn't purely a word for marketing/scamming) then there's some new aspect which sets it apart from the distributed-databases we've been able to make just fine for decades.
Uncontrolled participation is that key aspect. Without that linchpin, almost all the other new stuff becomes weirdly moot or actively detrimental.
> If you spin up a private bitcoin network, it's a blockchain even if nobody else knows or cares about it.
That's practically a contradiction in terms. It may describe the ancestry of the project, but it doesn't describe what/how it's being used.
Compare: "If you make a version of Napster/Gnutella with all the networking code disabled, it's still a Peer-to-Peer file sharing client even when only one person uses it."
I interpreted "private" from the comment above yours to mean membership determined by some authority. So your example doesn't hold well, because networking would still be enabled in the file sharing fork, but on a private network rather than the open internet.
You misunderstand. The analogy wouldn't be Napster with networking code disabled. The analogy is Napster on a LAN. Only those on the LAN can access it so it's not open to the world, but nonetheless you've still got a p2p file-sharing client.
And yes. I'm using the engineering definition. I don't believe in letting a gaggle of marketers and scammers define my terms. A blockchain is a specific technology. It doesn't mean 'whatever scam is happening this week', even if said scam involves a blockchain.
I don't blame you for associating blockchains with scams and fully open projects, that's undeniably what we've seen it used for. But that's not what defines a blockchain.
"A scalpel can only be used for surgery"
"If you use a scalpel to cut a steak, it's still a scalpel."
"There must be some new aspect to scalpels! We've been able to make steak knives for decades!"
On reflection I was incorrect to mention Napster, which (at least in its most-popular incarnation) was still centralized for indexing and searching, with P2P only for bulk file data. Please pretend said "Gnutella" alone.
> The analogy is [the P2P application] on a LAN.
The analogy is the P2P application where regular clients can only discover a Special Master Client that must be running on a fixed IP, which only permits connections if you have credentials for a user-account arranged in advance.
In each case, the system's centerpiece feature is being voided, but that feature is different between them.
1. For "Blockchain", the centerpiece is unrestricted participation. (Other decentralization is an indirect effect.)
2. For P2P file sharing, the centerpiece is how nobody needs to run an expensive/vulnerable central server, but it wasn't a contradiction in terms to have a private peer-network.
This is a debate over semantics, let's conclude by presenting our competing definitions.
A blockchain is ledger shared between multiple computers. Entries in this ledger contain the cryptographic hash of the previous entry, creating an append-only data structure where existing records cannot be modified.
While blockchains are generally used in p2p and open networks, this isn't a requirement. Bitcoin was a blockchain when Nakamoto was the only node. Popularity and openness are not required to meet this technical definition.
> No one knew what “blockchain” was, how it worked, or what could be used for.
Not the blockchain itself, but the concept of an immutable, append only, tamper-proof ledger underpinning it is a very useful one in many contexts where the question of authenticity of datasets arises – the blockchain has given us a ledger database.
The ledger database is more than just a hash as it also provides a cryptographic proof that the data is authentic via hash chaining, no ability to delete or modify a record, and the entire change history of any record. All these properties make the ledger databases very useful in many contexts, especially the ones where official documents are involved.
I have heard an argument for git before, and it is a viable fit for some use cases.
The problem, however, stems from the fact that the git commit history can be modified, which automatically disqualifies git in many other use cases, e.g. official government-issued documents, financial records, recognition of prior learning, and similar – anywhere where the entire, unabridged history of records is required.
There is no such a thing as «subsequent commits» in git.
Commits in git are non-linear and form a tree[0][1]. A commit can be easily deleted without affecting the rest of the tree. If the git commit represent a subtree with branches dangling off it, deleting such a commit will delete the entire subtree. Commits can also be moved around, detached and re-attached to other commits.
True but irrelevant. You can't remove a commit in a way that someone else with a copy of the repo can't detect, in exactly the same way and for the same reason that you can't remove a blockchain entry without making instantly obviously to later items.
Very much relevant. The definition of the ledger database includes immutability of datasets as a hard constraint[0][1]. The mere fact that the git commit history can be altered automatically disqualifies git from being an acceptable alternative to the ledger database in highly regulated environments.
If strict compliance is not a hard requirement (open source project are the prime example), git can be used to prove provenance, provided you trust the signer’s public key or allowed signers file.
It is immutable in exactly the same way. The git commit history cannot by altered, except in the same sense that you could manually edit the backing store of a blockchain to alter the data, and with the same consequence that the alteration would be instantly noticeable in either case.
Consider a leaf commit (or a leaf which is a subtree of commits). I am a person with nefarious intentions, and I delete the leaf commit, forcefully expire the reflogs, or force garbage collect them. At that point, there is no longer remaining evidence in git that the commit ever existed. If git were to be used to record a history of criminal offences, I would be able to single-handedly delete the last offence by running «git reflog expire --expire=now --all» followed by «git gc --aggressive --prune=now».
Ledger databases, on the other hand, do not have the «delete» operation. The «update» operation does not factually update the document/record and creates a new revision instead (just as git does), whilst retaining a full history of updates to the document/record. This is the fundamental difference.
If you're running a blockchain on a single node, it's exactly like running Git on that single node. You can mutate the data locally, even with something as simple as reverting to a backup. Voila, it never happened.
If you're running Git on multiple nodes, it's exactly like running a blockchain on multiple nodes. You can mutate your own local copy, but that doesn't mutate mine, and the set of commits is functionally identical to the union of commits from every node. You can't delete a commit without deleting it from every clone.
Yes, that is the problem that is impossible to address with git due to its decentralised nature, which is a feature.
A typical scenario that disqualifies git in certain scenarios is as simple as a master repository and a few local copies of varying degree of vintage. Then the master has had its commit history changed, reflogs purged and GC'd, and the local copies will never have the knowledge of what the master could have had in the past.
git is perfectly acceptable in many scenarios, but if the immutability has to be enforced, in regulatory WORM requirements (SEC 17a-4, ISO 14641 or similar) with
1. Certified write-once, read-many retention, legal holds and tamper-evidence anchored to trusted time sources are mandatory;
2. Authoritative time and ordering – git commit timestamps are user-supplied and easily forged;
3. Granular access control and selective disclosure – git tends to replicate whole histories and the ledger can provide the proof of single record only;
4. Structured queries and point-in-time views at scale – git has no native time-travel queries, secondary indexes or ACID multi-record transactions across millions of records with consistent snapshots;
5. Independent third-party verification – if external parties (e.g. state auditors) must verify recorded events, verifiable receipts or Merkle proofs that stand alone are needed. git commits and optional signatures are not receipts and are hard to validate without access to the repository.
6. Consensus or anchoring needs – if integrity must be prove against a hostile or nefarious party, anchoring or consensus is required. git has no native consensus; ledger databases can anchor state hashes to public chains or quorum-backed authorities.
… git is not a really option.
git can be hardedned, though, by signing commits and tags, forbidding force-pushes server-side, mirroring to append-only storage and periodically anchoring repository state to a public timestamping service. It still will not meet strict ledger-grade assurances, but it can raise the bar for internal use. The sheer amount of work required to accomplish that makes a solid case for a dedicated ledger database.
I often feel that immutability is very much over-rated and goes against real word. Lot of legal system is build on reverting things. Thus things being harder to revert is not actually desirable property.
No. Official and legal records detest the in place changes, love a full history of changes, and also love to walk the entire history of changes back. You do not have to convince me, you can talk to the state auditors instead to get their perspective.
Consider two simple and common scenarios (there are more): citizenship certificates and the recognition of prior learning.
1. Citizenship – the person with the name of Joanna Doe in the birth certificate was issued with a citizenship certificate in the same name. As time goes by, Joanna Doe changes the legal name to Joanna Smith; the citizenship certificate is reissued with the new legal name. We do not want to truly update the existing record in the citizenship database and simply change Doe -> Smith as it will create a mismatch with the name in the birth certificate. If we use a ledger database, an update operation will create a new revision of the same record and all subsequent simple query operations will return the latest updated revision with the new name. The first revision, however, will still be retained in the table's cryptographically verifiable audit/history log.
Why should we care? Because Joanna Smith can accidentally throw their new citizenship certificate away and later they will want to renew their passport (or the driver's licence). The citizenship certificate may be restored[0] by presenting the birth certificate in the original name and the current or expired passport, but the passport is in the new name. From a random system's point of view, Joanna Doe and Joanna Smith are two distinct individuals with no apparent link between them. However, the ledger database can provide proof that it is the same person indeed because the unabridged history of name changes is available, it can be queried and relied upon.
2. Recognition of prior learning – a person has been awarded a degree at institution A. Credits from Institution A contributed to a degree at Institution B. The degree at B is revoked due to issues with source evidence (i.e. Institution A). The ledger database makes such ripple effects deterministic – a revocation event at B triggers rules that re-evaluate dependent awards and enrolments at partners, with a verifiable trail of who was notified and when. If Institution A later corrects its own records, Institution B and downstream bodies can attach a superseding record rather than overwrite, preserving full lineage. The entire drama unfolded will always be available.
2½. Recognition of prior learning (bonus) – an employer verified the degree on the hiring date. Months later it is revoked. The employer can present a ledger proof that, on the hiring date, the credential existed and was valid. It reduces dispute risk and supports fair-use decisions such as probation reviews rather than immediate termination.
All this stuff is very real and the right tech stack (i.e. the ledger DB) reduces the complexity tremendously.
[0] Different jurisdictions have different rules but the procedure is more or less similar amongst them.
> but the concept of an immutable, append only, tamper-proof ledger underpinning it is a very useful one
Which is why blockchains have become such a ubiquitous technology. They're literally everywhere. Can't swing a cat without hitting a blockchain nowadays.
You have responded to the wrong comment. I have presented a case that concerns ledger databases, not the blockchains. If one doesn't understand the difference between the two, it is probably a good idea to refrain from chiming in.
As long as you can't guarauntee that the data you put onto a blockchain is trustworth in the first place, whatever you put on a blockchain is not 'tamper-proof'.
Therefore the ONLY thing you can handle on a blockchain 'tamper-proof' is stuff only existing on the blockchain itself. Which means basically nothing.
And there is a second goal post which was moved: the ignorance about a blockchain being 'tamper-proof'. 51% attack are real, you don't know if a country just owns and controls a lot of nodes and the latest rumor: NSA was involved in blockchain creation. You don't know if something is hidden in the system which gives one entity an edge over others.
Yes, that kind of database was so in demand, the AWS version, "Amazon Quantum Ledger Database" was hugely successful. Oh wait, it was a flop and is being shut down....
No snark required. Whatever the reason for discontinuing QLDB was, it has been replaced with the pgAudit[0] Postgres extension in AWS. I did look into using QLDB for a project involving the management of financial records about 4 years ago and found it to be a somewhat unwieldy to use document database.
Demand for ledger databases is strong in the government and elsewhere where compliance is a non-negotiable. Microsoft have their own on the offer[1] as well.
"hodl" - I think r/WallStreetBets came up with that. Perhaps not - its too ubiquitous, similar to teh. r/WSB did originate the eating green crayons thing along with smooth brain monkeys etc
I simply mixed and matched and riffed in an old school "lock up your daughter" meme.
Sorry, I don't have a Spongebob illustration. I do words.
I had a very hard time explaining once you put something in the chain, you can’t easily pull it back out. If you wanted to verify documents, all you have to do is put a hash in a database table. Which we already had.
It has exactly one purpose: prevent any single entity from controlling the contents. That includes governments, business executives, lawyers, judges, and hackers. The only good thing is every single piece of data can be pulled out into a different data structure once you realize your mistake.
Note, I’m greatly oversimplifying all the details and I’m not referring to cryptocurrency.