7 ms·

No, it doesn't. How do you build consensus around the signatures?

acdha 4y ago
The same way humans have for millennia: relying on authority, reputation, and auditing. Blockchains have enormous overhead because they’re trying to be anonymous but once you need real-world connections you’re already giving that up, which makes it much cheaper to simply rely on those existing relationships. Historically, that was things like documents being stamped or sealed by a trusted third party witness, escrow agents to hold funds or property until some transaction finished, auditors confirming that a particular good was in the expected condition, etc. In every case, anonymity would be a negative because you want to know, for example, that your notary doesn’t have a criminal history or a reputation for sloppy record keeping. In the electronic era, that could be implemented using PKI where different parties register keys (or more likely corporate CAs) and use those to sign transactions or witness having seen a particular record. That’s similar to a blockchain in terms of trust but orders of magnitude more efficient and robust since it doesn’t require a network connection to a complex distributed service.
root_axis 4y ago
What does that mean? The signatures are self-describing, you don't need to build a "consensus" around them.
- CuriousCosmic 4y ago
  How do you agree on which signatures or information are actually part of the database? How do you decide who gets to add new entries to the database? Unless there is some meaningful method for maintaining the current state and each atomic change to that state going backwards, you are losing security guarantees. You can go down the git route but history is trivially rewrite-able and while git is decentralised, it has no mechanism for coming to a consensus about which history is the right one. Now you are back to determining consensus. You can either just say "X is the authority" and use a hosted git repo but if that's not viable for your threat model, you are pretty much back to cryptocurrency style consensus (probably Proof of Stake or Proof of Authority depending on your threat model).
  - root_axis 4y ago
    Proof of work is slow, wasteful, and provides no benefits to the proposed problem (chain of custody tracking). Proof of stake makes no sense for this use case because there's nothing to stake. "Proof of Authority" is effectively just a centralized DB.
    - CuriousCosmic 4y ago
      Agreed on PoW (with the exception of Proofs of Useful Work where it is still slow but not outright wasteful). Proof of Stake makes sense here not because you are implementing your own PoS system. Instead you are using an existing system and checkpointing onto it. This changes trust assumptions (now trusting the network to operate properly) and isn't the solution for all projects. Proof of Authority also makes sense and isn't just a centralised DB. Instead it is giving trusted members of the community some fraction of the total authority and requiring a majority of the members to agree on the state for the system to progress. This is similar to but still distinct from distributed database consensus algorithms like Raft or Paxos. The primary distinction is that Raft & Paxos assume that all authenticated participants are fully trusted/non-malicious. Byzantine Paxos (and Byzantine Raft as proposed in some research papers) begin to address this by attempting to achieve Byzantine Fault Tolerance but they each make different trade-offs. Even then however they tend to lack the flexibility that some types of PoA can have in allocating trust (think of PoA as PoS where the stake is units of trust allocated to each authority). What it comes down to IMHO is that while blockchains are clearly a terrible solution when you definitively trust an organization to operate in good faith, they are still better than a lot of the alternatives when everyone doesn't fully trust any one participating org but they do collectively trust all parties to be mutually distrustful.

The same way humans have for millennia: relying on authority, reputation, and auditing. Blockchains have enormous overhead because they’re trying to be anonymous but once you need real-world connections you’re already giving that up, which makes it much cheaper to simply rely on those existing relationships. Historically, that was things like documents being stamped or sealed by a trusted third party witness, escrow agents to hold funds or property until some transaction finished, auditors confirming that a particular good was in the expected condition, etc. In every case, anonymity would be a negative because you want to know, for example, that your notary doesn’t have a criminal history or a reputation for sloppy record keeping. In the electronic era, that could be implemented using PKI where different parties register keys (or more likely corporate CAs) and use those to sign transactions or witness having seen a particular record. That’s similar to a blockchain in terms of trust but orders of magnitude more efficient and robust since it doesn’t require a network connection to a complex distributed service.

root_axis 4y ago

What does that mean? The signatures are self-describing, you don't need to build a "consensus" around them.

CuriousCosmic 4y ago
How do you agree on which signatures or information are actually part of the database? How do you decide who gets to add new entries to the database? Unless there is some meaningful method for maintaining the current state and each atomic change to that state going backwards, you are losing security guarantees. You can go down the git route but history is trivially rewrite-able and while git is decentralised, it has no mechanism for coming to a consensus about which history is the right one. Now you are back to determining consensus. You can either just say "X is the authority" and use a hosted git repo but if that's not viable for your threat model, you are pretty much back to cryptocurrency style consensus (probably Proof of Stake or Proof of Authority depending on your threat model).
- root_axis 4y ago
  Proof of work is slow, wasteful, and provides no benefits to the proposed problem (chain of custody tracking). Proof of stake makes no sense for this use case because there's nothing to stake. "Proof of Authority" is effectively just a centralized DB.
  - CuriousCosmic 4y ago
    Agreed on PoW (with the exception of Proofs of Useful Work where it is still slow but not outright wasteful). Proof of Stake makes sense here not because you are implementing your own PoS system. Instead you are using an existing system and checkpointing onto it. This changes trust assumptions (now trusting the network to operate properly) and isn't the solution for all projects. Proof of Authority also makes sense and isn't just a centralised DB. Instead it is giving trusted members of the community some fraction of the total authority and requiring a majority of the members to agree on the state for the system to progress. This is similar to but still distinct from distributed database consensus algorithms like Raft or Paxos. The primary distinction is that Raft & Paxos assume that all authenticated participants are fully trusted/non-malicious. Byzantine Paxos (and Byzantine Raft as proposed in some research papers) begin to address this by attempting to achieve Byzantine Fault Tolerance but they each make different trade-offs. Even then however they tend to lack the flexibility that some types of PoA can have in allocating trust (think of PoA as PoS where the stake is units of trust allocated to each authority). What it comes down to IMHO is that while blockchains are clearly a terrible solution when you definitively trust an organization to operate in good faith, they are still better than a lot of the alternatives when everyone doesn't fully trust any one participating org but they do collectively trust all parties to be mutually distrustful.