25 ms·

Whether intentionally or not the article entrenches some narrow ideas of what blockchain is. At this point talking about Bitcoin as _the_ blockchain is an ancie

by vvpan 6y ago

Whether intentionally or not the article entrenches some narrow ideas of what blockchain is. At this point talking about Bitcoin as _the_ blockchain is an ancient narrative and does not see wood for the trees. Bitcoin fulfills a certain goal but the world of blockchain (and related to them) systems has become extremely diverse, with many systems racing to fill many niches in various ways. We should drop the Bitcoin == blockchain narrative. It's a narrative for non-technical people and maximalists. We should even stop using the word "cryptocurrency". Let's take Baseline project as an example of one that defies our ideas of what blockchain is meant to do. Baseline is a protocol developed by a few parties, in particular EY and Microsoft, that means to reduce friction in _communication_ between business entities. If, say, a factory needs more parts delivered it's SAP system communicates with the supplier's Oracle system through a public mainnet protocol encrypted via Zero-Knowledge Proofs. Yes, the system could potentially also handle transfer of value, but it's more than that. It's not bitcoin, it's not a currency, transfer of values isn't even the main point, it's a system of record and communication.

0x0 6y ago
What's so wrong with a HTTPS REST API call that you need a Zero-Knowledge proof posted on a public mainnet protocol?
- vvpan 6y ago
  I think you are vastly underestimating the complexity of communication across businesses. I am not an expert in what it takes for, say, two ERP systems to sync (EY are, though). But if you have two separate companies trying to order things from each other: * You need to decide on a protocol * You need to run servers (if separate from ERP) * You need to decide on a method of authentication * Your REST API needs to be very secure (in blockchain you need to keep your keys secure, yes) * If the other party is unreachable then you need to start queuing transactions and in theory they might be lost, the system falling out of sync without paper trail. Actually they could be lost in any case, cause the other party might be buggy and "forget" to record. * Which brings to: you need secure logging of your transactions for paper trail. * You need a method of resolution in case values on each side do not match ("Billion dollar question" Baseline people refer to it as. Immutable ledgers are perfect for this.) * Probably lots more I cannot think of right now or just do not know. Using smart contracts as your protocol solves all of those plus: * You can effectively transfer value over the wire as well. No need to keep an extra payment system in sync. But yes you would need to eventually convert to fiat. * A standard protocol. If you wanted to talk to yet another company you don't need to set up yet another system and get a team to negotiate auth, security, method of audit, conflict resolution, etc. The process is, at least in theory, simpler, cheaper, more secure and reliable.

by vvpan 6y ago

0x0 6y ago

What's so wrong with a HTTPS REST API call that you need a Zero-Knowledge proof posted on a public mainnet protocol?

vvpan 6y ago
I think you are vastly underestimating the complexity of communication across businesses. I am not an expert in what it takes for, say, two ERP systems to sync (EY are, though). But if you have two separate companies trying to order things from each other: * You need to decide on a protocol * You need to run servers (if separate from ERP) * You need to decide on a method of authentication * Your REST API needs to be very secure (in blockchain you need to keep your keys secure, yes) * If the other party is unreachable then you need to start queuing transactions and in theory they might be lost, the system falling out of sync without paper trail. Actually they could be lost in any case, cause the other party might be buggy and "forget" to record. * Which brings to: you need secure logging of your transactions for paper trail. * You need a method of resolution in case values on each side do not match ("Billion dollar question" Baseline people refer to it as. Immutable ledgers are perfect for this.) * Probably lots more I cannot think of right now or just do not know. Using smart contracts as your protocol solves all of those plus: * You can effectively transfer value over the wire as well. No need to keep an extra payment system in sync. But yes you would need to eventually convert to fiat. * A standard protocol. If you wanted to talk to yet another company you don't need to set up yet another system and get a team to negotiate auth, security, method of audit, conflict resolution, etc. The process is, at least in theory, simpler, cheaper, more secure and reliable.