5 ms·

When I request a ride, the _system_ gives me... To explain what you're missing, I have to talk about how decentralized networks are actually implemented. Thin

by adamjs 12y ago

When I request a ride, the _system_ gives me... To explain what you're missing, I have to talk about how decentralized networks are actually implemented. Think of the "system" as a large crowd of people in a room. Only certain people in the room have the information you want. It is totally unfeasible to ask every person in the room, you can only ask the three guys closest to you. What do you do? The best strategy to maximize query performance mimics the real-world— each person occasionally gossips information to each other, which replicates data across a network and increases the chance that someone nearby will have the answer you seek. The problem then comes down to trust-- say you ask three guys nearby a question: "Do you know if there are any cabs nearby?" Let's say those three guys did happen to know of a cab nearby but wanted it for themselves (they just got an invite to this AWESOME party in the Haight), so they lie to you and take the cab for themselves. Or, in an alternative case— they are all three sons of a rather horrible cab driver and tell you that he is the ONLY one available. If we had a global view of the system, the chances of this abuse might be minimized but this is just not feasible in real-world implementations. There's also other implications for privacy (nodes in the middle might log your queries) which might also introduce new vectors for abuse.

jacquesm 12y ago
You could dump your ratings in the bitcoin blockchain. Decentralized, hard to forge, automatically archived in lots of places and outside of centralized control. Thinking about it this way, the real value of bitcoin might not be in the coins but in the blockchain itself. It's essentially a write-only log that you can append to by paying a minimal fee.
- matt_kantor 12y ago
  > the real value of bitcoin might not be in the coins but in the blockchain itself. Absolutely. Blockchains are much more general and useful than a Bitcoin-centric view assumes them to be. See http://namecoin.info http://namecoin.info, https://ethereum.org https://ethereum.org, http://bitshares.org http://bitshares.org, and http://proofofexistence.com http://proofofexistence.com for examples.
- adamjs 12y ago
  I wrote earlier that information must be transmitted with a "paper-trail" for it to be independently verifiable by every node. The bitcoin block chain is essentially a single, massive "paper-trail" that could potentially be used like a shared database for synchronizing information across nodes. Using the block chain as a single, shared, decentralized database is an interesting solution but has serious flaws when used as you describe: 1. Transactions are not added immediately (and by added, I mean a consensus has been reached by a majority of the network on the state of the block chain), it can take up to 10 minutes for confirmation to be reached [1] with modern networks and hardware. 2. Each transaction increases the size of the block chain. To independently verify a transaction, each node must have a complete copy of the block chain which is about 21 GB today [2], and growing ~1 GB per month. This rate is expected to increase with time which presents one of the biggest flaws of Bitcoin today. Several strategies exist to reduce the size (pruning of the data, using lightweight clients that only store headers instead of full data) but all of these reduce the ability for an individual node to verify a transaction. 3. Transactions can fail for various reasons: data is too large, transaction fee too low, fork in the blockchain, orphaned blocks, etc. What's even worse is that you won't know (and can't try submitting the transaction again) until confirmation fails ~10 minutes later. 4. Transactions fees for storing arbitrary data in the block chain is dependent upon the real-world price of bitcoin. What's more, once the block reward approaches zero (the reward is cut in half approx. every four years) the rewards of mining will shift entirely to voluntary transaction fees. This will likely cause transaction fees to increase. 5. The block chain is only secure as long as there doesn't exist a single group with a majority of processing power (it is kept in check by competition between miners). If a monopoly develops it can abuse the system very readily. These various reasons (latency, size, failure, fee increases over time) make the block chain a pretty bad back-end for the implementation of a shared, decentralized database of a real-time P2P app. The idea isn't completely unsalvageable however, another way of looking at the problem is to realize that the block chain file itself is used as a shared resource between many "threads". Each thread has its own local copy but reconciliation must be performed across all threads to ensure consistent state (which introduces huge amounts of synchronization and contention). To parallelize the problem, we must reduce the amount of resource contention required. The best way to do that is to use separate databases (eg, separate block chains) for separate, logical clusters of threads. Eg, for a ridesharing app, you can use a separate database (block chain) for each city. This way, only the data that is relevant to each thread must be synchronized. There's a few problems with this approach (could allow local monopolies to develop more readily) as well but it better emulates natural models for decentralized systems. It might also be better to use a hybrid approach based on the type of data involved: 1. Use a secure DHT (distributed hash table) to store data that isn't necessarily transactional (such as individual ratings that could be aggregated via an unstructured query). 2. Use a local block chain to synchronize shared resources (such as driver availability). [1] https://blockchain.info/charts/avg-confirmation-time https://blockchain.info/charts/avg-confirmation-time [2] https://blockchain.info/charts/blocks-size?timespan=all https://blockchain.info/charts/blocks-size?timespan=all
rycfan 12y ago
You've just described some possible flaws in a p-2-p system. Are there no flaws in the current cab system? Are there no flaws in Uber? You've pointed out why it can't be perfect. You haven't proven that it can't work. Perfect is the enemy of good. It doesn't have to be perfect. I was going to say it just has to be better than our current system. But it doesn't. It just has to be legal. Maybe it's better, maybe it's worse. But we're allowed to give it a try (generally speaking -- maybe not in California, but possibly in another state that doesn't have the same rules). If the flaws you point out occur often enough, then people will stop using it and the experiment will fail.

by adamjs 12y ago

jacquesm 12y ago

You could dump your ratings in the bitcoin blockchain. Decentralized, hard to forge, automatically archived in lots of places and outside of centralized control. Thinking about it this way, the real value of bitcoin might not be in the coins but in the blockchain itself. It's essentially a write-only log that you can append to by paying a minimal fee.

matt_kantor 12y ago
> the real value of bitcoin might not be in the coins but in the blockchain itself. Absolutely. Blockchains are much more general and useful than a Bitcoin-centric view assumes them to be. See http://namecoin.info http://namecoin.info, https://ethereum.org https://ethereum.org, http://bitshares.org http://bitshares.org, and http://proofofexistence.com http://proofofexistence.com for examples.
adamjs 12y ago
I wrote earlier that information must be transmitted with a "paper-trail" for it to be independently verifiable by every node. The bitcoin block chain is essentially a single, massive "paper-trail" that could potentially be used like a shared database for synchronizing information across nodes. Using the block chain as a single, shared, decentralized database is an interesting solution but has serious flaws when used as you describe: 1. Transactions are not added immediately (and by added, I mean a consensus has been reached by a majority of the network on the state of the block chain), it can take up to 10 minutes for confirmation to be reached [1] with modern networks and hardware. 2. Each transaction increases the size of the block chain. To independently verify a transaction, each node must have a complete copy of the block chain which is about 21 GB today [2], and growing ~1 GB per month. This rate is expected to increase with time which presents one of the biggest flaws of Bitcoin today. Several strategies exist to reduce the size (pruning of the data, using lightweight clients that only store headers instead of full data) but all of these reduce the ability for an individual node to verify a transaction. 3. Transactions can fail for various reasons: data is too large, transaction fee too low, fork in the blockchain, orphaned blocks, etc. What's even worse is that you won't know (and can't try submitting the transaction again) until confirmation fails ~10 minutes later. 4. Transactions fees for storing arbitrary data in the block chain is dependent upon the real-world price of bitcoin. What's more, once the block reward approaches zero (the reward is cut in half approx. every four years) the rewards of mining will shift entirely to voluntary transaction fees. This will likely cause transaction fees to increase. 5. The block chain is only secure as long as there doesn't exist a single group with a majority of processing power (it is kept in check by competition between miners). If a monopoly develops it can abuse the system very readily. These various reasons (latency, size, failure, fee increases over time) make the block chain a pretty bad back-end for the implementation of a shared, decentralized database of a real-time P2P app. The idea isn't completely unsalvageable however, another way of looking at the problem is to realize that the block chain file itself is used as a shared resource between many "threads". Each thread has its own local copy but reconciliation must be performed across all threads to ensure consistent state (which introduces huge amounts of synchronization and contention). To parallelize the problem, we must reduce the amount of resource contention required. The best way to do that is to use separate databases (eg, separate block chains) for separate, logical clusters of threads. Eg, for a ridesharing app, you can use a separate database (block chain) for each city. This way, only the data that is relevant to each thread must be synchronized. There's a few problems with this approach (could allow local monopolies to develop more readily) as well but it better emulates natural models for decentralized systems. It might also be better to use a hybrid approach based on the type of data involved: 1. Use a secure DHT (distributed hash table) to store data that isn't necessarily transactional (such as individual ratings that could be aggregated via an unstructured query). 2. Use a local block chain to synchronize shared resources (such as driver availability). [1] https://blockchain.info/charts/avg-confirmation-time https://blockchain.info/charts/avg-confirmation-time [2] https://blockchain.info/charts/blocks-size?timespan=all https://blockchain.info/charts/blocks-size?timespan=all

rycfan 12y ago

You've just described some possible flaws in a p-2-p system. Are there no flaws in the current cab system? Are there no flaws in Uber? You've pointed out why it can't be perfect. You haven't proven that it can't work. Perfect is the enemy of good. It doesn't have to be perfect. I was going to say it just has to be better than our current system. But it doesn't. It just has to be legal. Maybe it's better, maybe it's worse. But we're allowed to give it a try (generally speaking -- maybe not in California, but possibly in another state that doesn't have the same rules). If the flaws you point out occur often enough, then people will stop using it and the experiment will fail.