There are a few “blockchain”-like systems that use Merkle trees or some other consensus algorithm that we use every day that are “easier” than blockchains proper.
Certificate Revocation Lists (CRLs) are a signed tree, similar to a Merkle (there’s some complexity, but we’ll go with it) that is/was used to distribute when certificates should no longer be trusted, from a central source. Nodes in the tree were signed by a signing key, similar to how we process hash trees.
For the use in the article, you definitely can have signed time-series lists, these are linked timestamping data structures, and you can use them to validate that an article or node is definitely from the source you expected in the order that you expected.
Also, things like etcd make use of RAFT for consensus, allowing multiple nodes in a cluster to keep a consistent state.
Hence why I said “blockchain”-like in my comment :)
Fabric, the various other private permissioned blockchains (Substrate in various modes, &c.) have their purposes too, and there are (D)PoS blockchains that are in use for private usage.
I wouldn’t say it’s “marketing” per se, it’s more that people don’t really need blockchains generally when they think they do.
If your DB exists inside one org - sure. If your DB is shared between multiple orgs and you want to concentrate on tech, not on legal… Maybe time-series database won’t cut it.
What attack, exactly, do you fear that is allowed by giving your partner orgs append-only access to a DB, but is not possibly by giving them append access to your blockchain?
I note that the article explicitly addresses the ‘partners who don’t trust each other’ use case.
For example, a private ledger allows data to be shared and seen by different parties who do not need to trust each other because of the software’s rules – this could be a bank and a regulator sharing data access to customer trades data. I would argue that such data access could be done via the business logic layer sitting on top of the database layer to provide data to outside parties.
giving your partner orgs append-only access to a DB
Because it requires your partner to trust that you do not do funny stuff on DB yourself. Simplest attack - place a buy before appending a large incoming buy order, and place a sell just after it. Free money. Happens on public blockchains all the time.
BTW, this article is a dumpster fire. It is full of false claims, half-truths and just irrelevant bullshit. The guy who wrote it knows his time-series databases and knows almost nothing about blockchain design space.
Blocks are added to the blockchain at regular time intervals. For each block of data, there is an associated timestamp.
Yes. Trains also arrive at different time points. Is Amtrak a blockchain? How is this even relevant?
Data replication: Each node in the blockchain holds the entire history of transactions. If one node is compromised, we rely on the others to provide the full history. Again, this concept has been in effect for decades with traditional databases: if one database fails, we may want another as a backup.
False. There are multiple types of nodes. There are chains where history can be truncated - chains with snapshots. Reason for nodes to have the full state is an ability to validate every state transition. Data availability is an important concern, but it is secondary since the need to share some data can be removed with the help of zksnarks / bulletproofs.
full history of all individual transactions ordered by time; this is how blockchain nodes work
No, this is not how blockchains work. They implement total global ordering of events. But the order is logical, not time based. E.g. both Bitcoin and Ethereum include transactions in the order defined by the fee paid - from txes paying high fees, to txes paying low fees. Total global order of transactions plus deterministic execution equals ability to arrive to the same final state. It has very little to do with time.
Blockchains would have multiple parties (i.e., nodes) to agree for a specific transaction. There are consensus algorithms such as Raft and Paxos in traditional databases akin to a voting mechanism.
This bit is just lazy. Consensus determines the order of inclusion of transactions. Nothing more.
Long 256 format: This is the format of crypto public addresses. At QuestDB we have built a data type that is better than a string to efficiently write and read Long 256 blockchain addresses.
Irrelevant. This is a wrong layer. See Tendermint. It provides a total ordering on a set of binary blobs. Binary blobs are untyped, and Tendermint knows nothing about details of business logic of the application it is running.
This reminds me how a bunch of blockchain peddlers that made their way into a meeting of a municipal IT steering committee, trying to sell their “block-chain based authentication mechanism”. They did not read eIDAS and GDPR (nor the related local laws) did not read the public service information systems law, nor the cybernetic security law and showed that they had zero understanding of the fact, that if public administration screws up proving someone’s identity and that someone is harmed by that, the administration is held liable.
It is several times easier to write a contract between couple of parties detailing how you share data and who is responsible for what, adjust your respective privacy policies and use a couple of regular databases than “putting it all onto a blockchain”, potentially being liable for publishing personal information that cannot ever be deleted.
And frankly, I am pretty confident writing small-scale contracts myself, without being a lawyer. Continental Law tends to provide mostly sane defaults (to a point it is safe to sign most of the common contracts without any additional clauses apart from the mandatory ones) and since overly unfair contracts are invalid and courts are expected to read into what the signatories meant, you only need lawyers in high-risk situations or once something blows up.
And if you need it to scale, just use adhesive contract (terms of service) with one organization acting as a steward. If you need it to be neutral, association is both the simplest of corporations to fund and also the simplest to administer (almost no accounting) providing democratic (one member = one vote) decision-making by default.
What you decide to do will depend a lot on the specifics of your use-case. You might decide to run your own proof of authority blockchain, or to run some other BFT protocol such as HotStuff. You also might communicate using a public blockchain. However, what you must not do is run your own proof of work blockchain. Your comment correctly identifies one of the reasons why doing so is a bad idea.
Web of Trust style, ala Proof of Authority, doesn’t actually handle adversarial consensus, only who can publish to the blockchain, so often you’ll see another consensus algorithm underneath that layer, like IBFT, Raft, what-have-you, if you’re concerned with adversaries within the trusted nodes
of course! It’s a really interesting space, and there’s lots of nuances to it all. We obviously deal with it a lot at work, more than other folks may in their day to day
Yeah this is my understanding of the value of enterprise blockchains. It’s more about getting diverse organisations to run a database together in an interoperable manner without one of them becoming the “owner” of the database or similar. I’ve never actually worked in such a large organisation so I have no idea if this rings true.
This is generally the case; my company reviews blockchains quite frequently, as well as their installations, and we’ve seen this comment often. Having said that, I haven’t seen as much success from that sort of thing; very often it’s a pilot, and doesn’t go much further than that.
There seems to be rather little substance to the article. Am I too cynical for getting the impression that they’re just peddling their product, and doing a good job of collecting upvotes from the general (deserved) anti-blockchain sentiment?
Hmm, depending on what you mean by blockchain. I think the whole PoW is the biggest part that is probably not required. Hash chains, linked timestamping, etc. have been used for quite some time before blockchains for many things that people now sell as “new blockchain technology”.
There are a few “blockchain”-like systems that use Merkle trees or some other consensus algorithm that we use every day that are “easier” than blockchains proper.
Certificate Revocation Lists (CRLs) are a signed tree, similar to a Merkle (there’s some complexity, but we’ll go with it) that is/was used to distribute when certificates should no longer be trusted, from a central source. Nodes in the tree were signed by a signing key, similar to how we process hash trees.
For the use in the article, you definitely can have signed time-series lists, these are linked timestamping data structures, and you can use them to validate that an article or node is definitely from the source you expected in the order that you expected.
Also, things like etcd make use of RAFT for consensus, allowing multiple nodes in a cluster to keep a consistent state.
Generally, when customers ask me if they need a blockchain, I refer to NIST IR 8202, which has this hilarious flowchart.
Etcd is a blockchain in the same way Hyperledger Fabric is one. The only true blockchains are public ones. The rest is marketing.
Hence why I said “blockchain”-like in my comment :)
Fabric, the various other private permissioned blockchains (Substrate in various modes, &c.) have their purposes too, and there are (D)PoS blockchains that are in use for private usage.
I wouldn’t say it’s “marketing” per se, it’s more that people don’t really need blockchains generally when they think they do.
If your DB exists inside one org - sure. If your DB is shared between multiple orgs and you want to concentrate on tech, not on legal… Maybe time-series database won’t cut it.
What attack, exactly, do you fear that is allowed by giving your partner orgs append-only access to a DB, but is not possibly by giving them append access to your blockchain?
I note that the article explicitly addresses the ‘partners who don’t trust each other’ use case.
This
is not compatible with this:
Because it requires your partner to trust that you do not do funny stuff on DB yourself. Simplest attack - place a buy before appending a large incoming buy order, and place a sell just after it. Free money. Happens on public blockchains all the time.
BTW, this article is a dumpster fire. It is full of false claims, half-truths and just irrelevant bullshit. The guy who wrote it knows his time-series databases and knows almost nothing about blockchain design space.
Yes. Trains also arrive at different time points. Is Amtrak a blockchain? How is this even relevant?
False. There are multiple types of nodes. There are chains where history can be truncated - chains with snapshots. Reason for nodes to have the full state is an ability to validate every state transition. Data availability is an important concern, but it is secondary since the need to share some data can be removed with the help of zksnarks / bulletproofs.
No, this is not how blockchains work. They implement total global ordering of events. But the order is logical, not time based. E.g. both Bitcoin and Ethereum include transactions in the order defined by the fee paid - from txes paying high fees, to txes paying low fees. Total global order of transactions plus deterministic execution equals ability to arrive to the same final state. It has very little to do with time.
This bit is just lazy. Consensus determines the order of inclusion of transactions. Nothing more.
Irrelevant. This is a wrong layer. See Tendermint. It provides a total ordering on a set of binary blobs. Binary blobs are untyped, and Tendermint knows nothing about details of business logic of the application it is running.
You are not avoiding any “legal”.
This reminds me how a bunch of blockchain peddlers that made their way into a meeting of a municipal IT steering committee, trying to sell their “block-chain based authentication mechanism”. They did not read eIDAS and GDPR (nor the related local laws) did not read the public service information systems law, nor the cybernetic security law and showed that they had zero understanding of the fact, that if public administration screws up proving someone’s identity and that someone is harmed by that, the administration is held liable.
It is several times easier to write a contract between couple of parties detailing how you share data and who is responsible for what, adjust your respective privacy policies and use a couple of regular databases than “putting it all onto a blockchain”, potentially being liable for publishing personal information that cannot ever be deleted.
And frankly, I am pretty confident writing small-scale contracts myself, without being a lawyer. Continental Law tends to provide mostly sane defaults (to a point it is safe to sign most of the common contracts without any additional clauses apart from the mandatory ones) and since overly unfair contracts are invalid and courts are expected to read into what the signatories meant, you only need lawyers in high-risk situations or once something blows up.
And if you need it to scale, just use adhesive contract (terms of service) with one organization acting as a steward. If you need it to be neutral, association is both the simplest of corporations to fund and also the simplest to administer (almost no accounting) providing democratic (one member = one vote) decision-making by default.
How do you realistically prevent a 51% attack though…?
What you decide to do will depend a lot on the specifics of your use-case. You might decide to run your own proof of authority blockchain, or to run some other BFT protocol such as HotStuff. You also might communicate using a public blockchain. However, what you must not do is run your own proof of work blockchain. Your comment correctly identifies one of the reasons why doing so is a bad idea.
WoT?
Web of Trust style, ala Proof of Authority, doesn’t actually handle adversarial consensus, only who can publish to the blockchain, so often you’ll see another consensus algorithm underneath that layer, like IBFT, Raft, what-have-you, if you’re concerned with adversaries within the trusted nodes
Thank you, that’s helpful.
of course! It’s a really interesting space, and there’s lots of nuances to it all. We obviously deal with it a lot at work, more than other folks may in their day to day
Enterprise organisations are also vulnerable to 51% attack. You can buy 51% of the shares, then burn the whole thing to the ground.
Yeah this is my understanding of the value of enterprise blockchains. It’s more about getting diverse organisations to run a database together in an interoperable manner without one of them becoming the “owner” of the database or similar. I’ve never actually worked in such a large organisation so I have no idea if this rings true.
This is generally the case; my company reviews blockchains quite frequently, as well as their installations, and we’ve seen this comment often. Having said that, I haven’t seen as much success from that sort of thing; very often it’s a pilot, and doesn’t go much further than that.
There seems to be rather little substance to the article. Am I too cynical for getting the impression that they’re just peddling their product, and doing a good job of collecting upvotes from the general (deserved) anti-blockchain sentiment?
Following up on this, I wonder how many of the first upvotes for this story were by all those “green” users co-invited at the same time as OP? https://lobste.rs/u#copple invited 6 users), and their only activity so far is this other QuestDB story: https://lobste.rs/s/rxeycs/my_journey_making_database.
Fond memories of rrdtool
Hmm, depending on what you mean by blockchain. I think the whole PoW is the biggest part that is probably not required. Hash chains, linked timestamping, etc. have been used for quite some time before blockchains for many things that people now sell as “new blockchain technology”.