6 ms·

Doesn't that somewhat depend on how you define a blockchain? Blockchain doesn't inherently require proof of work/stake/etc, just a chain where each block contai

Doesn't that somewhat depend on how you define a blockchain? Blockchain doesn't inherently require proof of work/stake/etc, just a chain where each block contains a hash of the previous block(s). Proof of work/stake just happens to be a popular implementation detail because of cryptocurrencies.

beaconstudios 8y ago
what you're describing is a Merkle tree. Blockchains are essentially Merkle trees with a distributed consensus algorithm. Take away the consensus algorithm and you're back to Merkle trees.
- zellyn 8y ago
  https://twitter.com/whitequark/status/946886702932557824 https://twitter.com/whitequark/status/946886702932557824 https://twitter.com/hikari_no_yume/status/933791331146784768 https://twitter.com/hikari_no_yume/status/933791331146784768 More seriously, some people apparently consider git a blockchain: https://medium.com/@shemnon/is-a-git-repository-a-blockchain-35cb1cd2c491 https://medium.com/@shemnon/is-a-git-repository-a-blockchain...
  - deleted 8y ago
    [deleted]
  - pdpi 8y ago
    Git histories absolutely are something in the blockchain family of data structures, yes, but they’re not a blockchain proper: the defining chacteristic of such data structures is that they use hashes instead of pointers as references to elements. Merkle trees and blockchains are analogous to trees and singly linked lists, respectively, while git histories are DAGs. Where things got murky was that the cryptocurrency crowd started to talk about the blockchain that backs Bitcoin in terms where the consensus layer was left implicit (our own Linux vs GNU/Linux story if you want to see it that way), then people less knowledgeable about cryptography started pouring in, they learned a bunch of new terminology, and along the way missed the nuance about the consensus layer being left implicit, so in their minds (and the world at large, eventually) blockchain means the combined data structure and consensus layer — It’s fairly obvious that git doesn’t meet the requirements for this definition of “blockchain”.
  - greggyb 8y ago
    Git has a great proof-of-work and consensus mechanism in its original application. Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
- deleted 8y ago
  [deleted]
- Faark 8y ago
  Hm when I hear "tree", i'd expect it to be at least somewhat balanced. Wikipedia also has "Hash chain" and seems to be a better fit to me, but at that point we are basically arguing semantics. But yes, "blockchain" as used today is more than what we are talking about.
- benchaney 8y ago
  That is not what a merkle tree is. In a merkle tree, only the leaf nodes contain data (or hashes of data).
zeroxfe 8y ago
I think at a minimum, blockchains also require some kind of byzantine consensus mechanism to manage mutations over a (potentially) hostile p2p network. (Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)
- decentralised 8y ago
  Maybe nitpicking, but a blockchain can have a Proof of Authority, Proof of Elapsed Time or some other consensus mechanism that is not byzantine fault tolerant.
- zaarn 8y ago
  IMO any consensus mechanisms that all participants can agree on is sufficient, including where a single human approves each block. As long as everyone agrees that this is fine, it's sufficient for a blockchain.
bytematic 8y ago
A linked list then essentially?
nabla9 8y ago
In your opinion, is git source repository a blockchain if you cryptographically sign each commit? How about ZFS filesystem?
- deegles 8y ago
  You don't have to cryptographically sign each commit, it's just a blockchain where the difficulty is "a single valid SHA256"!
  - nabla9 8y ago
    I know. That's why I wrote if to make it closer to blockchain
bunderbunder 8y ago
At least for the purposes of the flowchart, it seems to be defined that way. Otherwise, the "Are you having hard time agreeing on who controls the data store?" bubble would be a bit out-of-place. That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability. Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?
- pythonaut_16 8y ago
  I think perhaps one effective use by a central entity is to have trust centralized but proof of work is distributed. An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid. E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
  - bunderbunder 8y ago
    That reads to me as yet another scenario where blockchain is the stone in the soup. If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did. If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did. The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't. As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.

beaconstudios 8y ago

what you're describing is a Merkle tree. Blockchains are essentially Merkle trees with a distributed consensus algorithm. Take away the consensus algorithm and you're back to Merkle trees.

zellyn 8y ago
https://twitter.com/whitequark/status/946886702932557824 https://twitter.com/whitequark/status/946886702932557824 https://twitter.com/hikari_no_yume/status/933791331146784768 https://twitter.com/hikari_no_yume/status/933791331146784768 More seriously, some people apparently consider git a blockchain: https://medium.com/@shemnon/is-a-git-repository-a-blockchain-35cb1cd2c491 https://medium.com/@shemnon/is-a-git-repository-a-blockchain...
- deleted 8y ago
  [deleted]
- pdpi 8y ago
  Git histories absolutely are something in the blockchain family of data structures, yes, but they’re not a blockchain proper: the defining chacteristic of such data structures is that they use hashes instead of pointers as references to elements. Merkle trees and blockchains are analogous to trees and singly linked lists, respectively, while git histories are DAGs. Where things got murky was that the cryptocurrency crowd started to talk about the blockchain that backs Bitcoin in terms where the consensus layer was left implicit (our own Linux vs GNU/Linux story if you want to see it that way), then people less knowledgeable about cryptography started pouring in, they learned a bunch of new terminology, and along the way missed the nuance about the consensus layer being left implicit, so in their minds (and the world at large, eventually) blockchain means the combined data structure and consensus layer — It’s fairly obvious that git doesn’t meet the requirements for this definition of “blockchain”.
- greggyb 8y ago
  Git has a great proof-of-work and consensus mechanism in its original application. Proof-of-work is code that passes tests and consensus is "Linus said 'ok'".
deleted 8y ago
[deleted]
Faark 8y ago
Hm when I hear "tree", i'd expect it to be at least somewhat balanced. Wikipedia also has "Hash chain" and seems to be a better fit to me, but at that point we are basically arguing semantics. But yes, "blockchain" as used today is more than what we are talking about.
benchaney 8y ago
That is not what a merkle tree is. In a merkle tree, only the leaf nodes contain data (or hashes of data).

zeroxfe 8y ago

I think at a minimum, blockchains also require some kind of byzantine consensus mechanism to manage mutations over a (potentially) hostile p2p network. (Yes, private permissioned blockchains aren't necessarily p2p, but I'd argue that they need to use byzantine consensus too -- otherwise there's no reason not to just use a managed database instead.)

decentralised 8y ago
Maybe nitpicking, but a blockchain can have a Proof of Authority, Proof of Elapsed Time or some other consensus mechanism that is not byzantine fault tolerant.
zaarn 8y ago
IMO any consensus mechanisms that all participants can agree on is sufficient, including where a single human approves each block. As long as everyone agrees that this is fine, it's sufficient for a blockchain.

bytematic 8y ago

A linked list then essentially?

nabla9 8y ago

In your opinion, is git source repository a blockchain if you cryptographically sign each commit? How about ZFS filesystem?

deegles 8y ago
You don't have to cryptographically sign each commit, it's just a blockchain where the difficulty is "a single valid SHA256"!
- nabla9 8y ago
  I know. That's why I wrote if to make it closer to blockchain

bunderbunder 8y ago

At least for the purposes of the flowchart, it seems to be defined that way. Otherwise, the "Are you having hard time agreeing on who controls the data store?" bubble would be a bit out-of-place. That said, if you don't have something like that, then most the rest of the bubbles don't make a whole lot of sense, either. When there's one central authority, they have the ability to unilaterally rewrite history, so you've also lost any features that flow from that not being possible, such as strong auditability. Git seems like a decent litmus test. Is git, rebase and all, a blockchain technology, or merely a blockchain-like technology?

pythonaut_16 8y ago
I think perhaps one effective use by a central entity is to have trust centralized but proof of work is distributed. An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid. E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.
- bunderbunder 8y ago
  That reads to me as yet another scenario where blockchain is the stone in the soup. If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did. If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did. The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't. As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.