3 ms·

Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't

by trentmc 10y ago

Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't really help anyone to argue for hours on end over this, when it's largely a matter of opinion. To me, what's more interesting is to identify what are the new characteristics (in terms of benefits) that blockchains have, above and beyond traditional distributed databases; which in turn unlock new applications or improve existing applications. To me, those characteristics are: decentralized, immutable, assets; I describe them in the article, and also in more detail in https://bigchaindb.com/whitepaper https://bigchaindb.com/whitepaper.

pdpi 10y ago
> To me, those characteristics are: decentralized, immutable, assets; How do you achieve fully trustless decentralisation without the currency aspect, while still being resilient to sybil attacks? Or are you willing to sacrifice truslessness? In which case, how are you defining decentralisation?
- trentmc 10y ago
  I define "decentralized" as "no single entity owns or controls". It can be further distinguished with "server-based decentralization" and "server-free decentralization" [1]. You only need to be Sybil tolerant if you want your validating nodes to be anonymous. There's certainly some applications where that's useful. But it's not a requirement for being decentralized. (Some will argue otherwise, and that's ok; once again it depends how you define "decentralized"; my approach is about what benefits come to the application.) [1] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc
  - pdpi 10y ago
    Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? (Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems that can and do prevent double spends) Still -- if you're willing to sacrifice anonymity for the sake of avoiding sybil attacks, then how do your nodes federate without a central authority? This is why having precise definitions matters: With each question I ask, we're eroding away the guarantees that such a system provides, and the implementation requirements with them. At what point do we just give up on "blockchains", and just adapt a run of the mill distributed log-based db instead, which gives you BFT and immutability, and where the asset layer is easy enough to add to the top?
    - lgas 10y ago
      Alternatively this is why definitions don't matter at all -- it only matters what guarantees (and other properties) a system provides, and not at all what we call it.
      - pdpi 10y ago
        That's a fair point too. I think we're in agreement, though: From the beginning, this discussion is about precisely that -- the word "decentralisation" usually entails a certain set of very specific properties so which properties, exactly, are we talking about here?
        lgas 10y ago
        Indeed.
        trentmc 10y ago
        Ditto on agreement about what properties (including guarantees) a system provides. To me, definitions are nonetheless useful to help summarize a set of properties, help communication, and more. Even if people have different definitions, the definitions typically have similar themes; they're not totally arbitrary. For example, with "decentralization" you'd find a lot of people agreeing that "no single entity owns or controls" within the same theme as other definitions.
    - trentmc 10y ago
      > Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? The best precedent is simply the long-standing difference between servers and clients in computing systems. In blockchain discourse, this difference had not been acknowledged as much; though of course a similar pattern exists between full nodes vs light/SPV clients. To my knowledge, no one else had made the clarification of "server-free" vs "server-less" as different types of decentralization. It is a useful distinction as the article discusses. > Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. As the article states, "they they never have a deterministic guarantee of a consistent order; they’re only eventually consistent (in a probabilistic sense). But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." > how do your nodes federate without a central authority? Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. > just adapt a run of the mill distributed log-based db instead ... Well in some cases that's all that people actually need; sometimes find myself referring people to Kafka and the like. But Kafka and the like are still controlled by a single admin; you can do more to decentralize. As for immutability, it's all shades of grey, and certainly being a log-based db (read-only) helps a lot. You can do more with Merkle DAGs, continuous backup to write-only media, etc. To me it's not about "eroding" guarantees. It's about saying "ok, I have this database, what properties do I want?" The potential results might be blockchain-like or not. If decentralization, immutability, or assets are potentially interesting, then a blockchain technology could be interesting. Otherwise it comes down to other questions to choose among traditional DBs.
davidgerard 10y ago
> Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't really help anyone to argue for hours on end over this, when it's largely a matter of opinion. It is true that "blockchain" is increasingly a literally meaningless marketing buzzword (e.g. R3 Corda, a "blockchain" product that brags of not actually containing a blockchain). However, this doesn't really help convince.
- trentmc 10y ago
  > increasingly a literally meaningless marketing buzzword Agree, "blockchain" is getting more diluted. To me, it still has enough information content to be useful. Just because different people have different definitions doesn't mean the information content is zero. People may agree on the broad ideas and disagree about the specifics. And as discussed in another comment, definitions are nonetheless useful to help summarize a set of properties, help communication, and more. For example, I think most people would agree a blockchain needs to have the property of having a consensus mechanism. Versus say a file system which typically doesn't.
  - davidgerard 10y ago
    Right. So what about your system is "blockchain" that, say, rsynced git repos (Merkle trees! Globally-identified hashes!) wouldn't be by that definition?
    - trentmc 10y ago
      IPFS is very close to what you describe (Merkle trees! Globally-identified hashes!) but it doesn't claim to be a blockchain because it doesn't have a consensus mechanism, let alone a way to prevent double spends. And that's ok! It's designed for different problems, like file system style blob storage. It's not about "whether something is a blockchain", it's about "what's the right tool for the job"? I see value in complementary decentralized pieces of file systems, databases, processing, and more.

by trentmc 10y ago

pdpi 10y ago

> To me, those characteristics are: decentralized, immutable, assets; How do you achieve fully trustless decentralisation without the currency aspect, while still being resilient to sybil attacks? Or are you willing to sacrifice truslessness? In which case, how are you defining decentralisation?

trentmc 10y ago
I define "decentralized" as "no single entity owns or controls". It can be further distinguished with "server-based decentralization" and "server-free decentralization" [1]. You only need to be Sybil tolerant if you want your validating nodes to be anonymous. There's certainly some applications where that's useful. But it's not a requirement for being decentralized. (Some will argue otherwise, and that's ok; once again it depends how you define "decentralized"; my approach is about what benefits come to the application.) [1] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc
- pdpi 10y ago
  Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? (Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems that can and do prevent double spends) Still -- if you're willing to sacrifice anonymity for the sake of avoiding sybil attacks, then how do your nodes federate without a central authority? This is why having precise definitions matters: With each question I ask, we're eroding away the guarantees that such a system provides, and the implementation requirements with them. At what point do we just give up on "blockchains", and just adapt a run of the mill distributed log-based db instead, which gives you BFT and immutability, and where the asset layer is easy enough to add to the top?
  - lgas 10y ago
    Alternatively this is why definitions don't matter at all -- it only matters what guarantees (and other properties) a system provides, and not at all what we call it.
    - pdpi 10y ago
      That's a fair point too. I think we're in agreement, though: From the beginning, this discussion is about precisely that -- the word "decentralisation" usually entails a certain set of very specific properties so which properties, exactly, are we talking about here?
      - lgas 10y ago
        Indeed.
      - trentmc 10y ago
        Ditto on agreement about what properties (including guarantees) a system provides. To me, definitions are nonetheless useful to help summarize a set of properties, help communication, and more. Even if people have different definitions, the definitions typically have similar themes; they're not totally arbitrary. For example, with "decentralization" you'd find a lot of people agreeing that "no single entity owns or controls" within the same theme as other definitions.
  - trentmc 10y ago
    > Care to link to sources for server-based and server-free decentralisation that aren't your own blog posts? The best precedent is simply the long-standing difference between servers and clients in computing systems. In blockchain discourse, this difference had not been acknowledged as much; though of course a similar pattern exists between full nodes vs light/SPV clients. To my knowledge, no one else had made the clarification of "server-free" vs "server-less" as different types of decentralization. It is a useful distinction as the article discusses. > Also, that blog post you linked is flat out wrong -- Bitcoin, Ethereum, et al are all instances of eventually consistent systems As the article states, they can and do prevent double spends, so we agree there. But that's not what "consistent" means in a CAP setting. As the article states, "they they never have a deterministic guarantee of a consistent order; they’re only eventually consistent (in a probabilistic sense). But let’s be generous and call them consistent, because in practice they are used that way, the workaround being higher latency as one waits for a sufficiently high probability of avoiding inconsistency." > how do your nodes federate without a central authority? Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. > just adapt a run of the mill distributed log-based db instead ... Well in some cases that's all that people actually need; sometimes find myself referring people to Kafka and the like. But Kafka and the like are still controlled by a single admin; you can do more to decentralize. As for immutability, it's all shades of grey, and certainly being a log-based db (read-only) helps a lot. You can do more with Merkle DAGs, continuous backup to write-only media, etc. To me it's not about "eroding" guarantees. It's about saying "ok, I have this database, what properties do I want?" The potential results might be blockchain-like or not. If decentralization, immutability, or assets are potentially interesting, then a blockchain technology could be interesting. Otherwise it comes down to other questions to choose among traditional DBs.

davidgerard 10y ago

> Throw a rock in the blockchain space and you'll find a different definition of blockchains, or what it means for one thing to be a blockchain or not. It doesn't really help anyone to argue for hours on end over this, when it's largely a matter of opinion. It is true that "blockchain" is increasingly a literally meaningless marketing buzzword (e.g. R3 Corda, a "blockchain" product that brags of not actually containing a blockchain). However, this doesn't really help convince.

trentmc 10y ago
> increasingly a literally meaningless marketing buzzword Agree, "blockchain" is getting more diluted. To me, it still has enough information content to be useful. Just because different people have different definitions doesn't mean the information content is zero. People may agree on the broad ideas and disagree about the specifics. And as discussed in another comment, definitions are nonetheless useful to help summarize a set of properties, help communication, and more. For example, I think most people would agree a blockchain needs to have the property of having a consensus mechanism. Versus say a file system which typically doesn't.
- davidgerard 10y ago
  Right. So what about your system is "blockchain" that, say, rsynced git repos (Merkle trees! Globally-identified hashes!) wouldn't be by that definition?
  - trentmc 10y ago
    IPFS is very close to what you describe (Merkle trees! Globally-identified hashes!) but it doesn't claim to be a blockchain because it doesn't have a consensus mechanism, let alone a way to prevent double spends. And that's ok! It's designed for different problems, like file system style blob storage. It's not about "whether something is a blockchain", it's about "what's the right tool for the job"? I see value in complementary decentralized pieces of file systems, databases, processing, and more.