5 ms·

> To me, those characteristics are: decentralized, immutable, assets; How do you achieve fully trustless decentralisation without the currency aspect, while s

by 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.
    - deleted 10y ago
      [deleted]
    - pdpi 10y ago
      > 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. You're the one who asserted that CAP-style consistency is required to prevent double-spends. Eventual consistency is a weakened form of consistency in the CAP sense. Both Bitcoin and Ethereum have eventual consistency as much more than a "theoretical" concern. In your own words: "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." The only way this is true is if you accept latencies measured in hours. For real-world applications, you absolutely need to deal with the eventual consistency (and, in fact, I've written several applications that deal with precisely that). > Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. I didn't ask how you establish consensus. I asked how the nodes federate -- if a node tries to peer with you, how do you decide whether or not to accept the node? You suggested anonymity is out the window, so who controls node identity?

by pdpi 10y ago

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.
  - deleted 10y ago
    [deleted]
  - pdpi 10y ago
    > 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. You're the one who asserted that CAP-style consistency is required to prevent double-spends. Eventual consistency is a weakened form of consistency in the CAP sense. Both Bitcoin and Ethereum have eventual consistency as much more than a "theoretical" concern. In your own words: "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." The only way this is true is if you accept latencies measured in hours. For real-world applications, you absolutely need to deal with the eventual consistency (and, in fact, I've written several applications that deal with precisely that). > Each node votes on any transaction coming through. The transaction only clears if it gets enough positive votes. I didn't ask how you establish consensus. I asked how the nodes federate -- if a node tries to peer with you, how do you decide whether or not to accept the node? You suggested anonymity is out the window, so who controls node identity?