4 ms·

The blockchain supports untrusted nodes. This is typically not a requirement in the typical distributed commit log usecase. Also, this wouldn’t be a simplificat

The blockchain supports untrusted nodes. This is typically not a requirement in the typical distributed commit log usecase. Also, this wouldn’t be a simplification. It would increase your costs and decrease performance.

jaequery 9y ago
i was thinking if you roll your own fork of the blockchain and set the costs to free, you just roll your own miners as the distributed nodes and it can work as a distributed storage that takes care of the consensus.
- majidazimi 9y ago
  Distributed logs like kafka/pulsar/nats are essentially a blockchain technology in trusted environments. Raft/multi-paxos are already the cheapest communication bound consensus. Theoretically you can't achieve any better with current network guarantees.
- teraflop 9y ago
  On top of the extra complexity, a blockchain has much weaker consistency properties than Paxos/Raft/Kafka. Because of finite propagation delays and network packet loss, there are normally multiple valid chains at any given moment in time. Even if you assume that all nodes are benevolent, and try their best to converge on the single longest chain without needing mining fees as an incentive, you still can't know whether the chain you're querying is the "winner" unless you have an omniscient view of the entire system. So you only get eventual consistency, as opposed to sequential consistency.
  - brian_cloutier 9y ago
    This comment is correct, I've heard the property described as "probabilistic consensus". However, this part is wrong: > Because of finite propagation delays and network packet loss, there are normally multiple valid chains at any given moment in time. How often forks occur is a property of a specific system, not of "blockchain" in general. Bitcoin, for instance, usually does not have multiple chains. They do sometimes happen but generally the orphan rate is quite low. Ethereum has a much higher block rate so propagation delays are more important and forks happen there much more often. There's an improvement called Bobtail [1] which makes the network much better at estimating how much work has been done. A blockchain which adopted Bobtail would still have probabilistic consensus but would almost never have forks. Casper, Ethereum's proposed Proof of Stake system, is designed to provide "finality", what the rest of us call "consensus". Once adopted, and assuming it works, we'll have a blockchain where you can be sure that every block you see which you determine is valid is a block which the rest of the network will also decide is valid (assuming less than 1/3 of the network is byzantine). [1] https://arxiv.org/abs/1709.08750 https://arxiv.org/abs/1709.08750

jaequery 9y ago

i was thinking if you roll your own fork of the blockchain and set the costs to free, you just roll your own miners as the distributed nodes and it can work as a distributed storage that takes care of the consensus.

majidazimi 9y ago
Distributed logs like kafka/pulsar/nats are essentially a blockchain technology in trusted environments. Raft/multi-paxos are already the cheapest communication bound consensus. Theoretically you can't achieve any better with current network guarantees.
teraflop 9y ago
On top of the extra complexity, a blockchain has much weaker consistency properties than Paxos/Raft/Kafka. Because of finite propagation delays and network packet loss, there are normally multiple valid chains at any given moment in time. Even if you assume that all nodes are benevolent, and try their best to converge on the single longest chain without needing mining fees as an incentive, you still can't know whether the chain you're querying is the "winner" unless you have an omniscient view of the entire system. So you only get eventual consistency, as opposed to sequential consistency.
- brian_cloutier 9y ago
  This comment is correct, I've heard the property described as "probabilistic consensus". However, this part is wrong: > Because of finite propagation delays and network packet loss, there are normally multiple valid chains at any given moment in time. How often forks occur is a property of a specific system, not of "blockchain" in general. Bitcoin, for instance, usually does not have multiple chains. They do sometimes happen but generally the orphan rate is quite low. Ethereum has a much higher block rate so propagation delays are more important and forks happen there much more often. There's an improvement called Bobtail [1] which makes the network much better at estimating how much work has been done. A blockchain which adopted Bobtail would still have probabilistic consensus but would almost never have forks. Casper, Ethereum's proposed Proof of Stake system, is designed to provide "finality", what the rest of us call "consensus". Once adopted, and assuming it works, we'll have a blockchain where you can be sure that every block you see which you determine is valid is a block which the rest of the network will also decide is valid (assuming less than 1/3 of the network is byzantine). [1] https://arxiv.org/abs/1709.08750 https://arxiv.org/abs/1709.08750