News for hackers. Stuff that matters.

twokei

Why wouldn't there be failures only under a complete network partition? So long as one node in one partition may communicate with another node in another partition, then writes may still be performed.

Availability would be what is sacrificed in the advent that a node is partitioned away from the main network.

Yep! Just to clarify, this is entirely hypothetical! I want to know the value-add people would put on such a database if it were to exist.

There's little insight from what I've seen in the database market as to what people really want the most out of a database, or what makes a database "appealing" to people apart from its reputation from being time-tested.

Gotcha! Makes sense to me :). What price tag would you put on this software?

There's been a pretty interesting development from what I've seen on annual licensing fees for enterprise features, with the code open-sourced.

It would be possible if say for example, the database was fully replicated in a masterless fashion.

The tradeoff is slower writes (there are ways to make it so that the more nodes you replicate across, write latency won't be affected!).

Reads will scale linearly for the more nodes you replicate across.

So, the novelty in some sense is fast replication of data in a masterless fashion (without any leader such as, for example in Raft or Paxos).

If this protocol was surprisingly simple (which dumbs down the complexity of the software significantly), would you pay for this sort of database?

Ask HN: How much would you pay for an extremely scalable, resilient database?

Let's say that there was a database with a magic consensus protocol that allows it to easily scale from one to tens to hundreds to thousands to tens of thousands of nodes.Tens of thousands of transactions may be performed per second, each taking about 1 to 4 seconds to be applied (sufficing for any use cases that are not necessarily near-real time).The database supports procedural functions...

( Read More... | 14 comments | 8 points | on HN )
Re:Why Proof-of-Work Does Not Scale on Sunday August 11, 2019 @02:54AM (#20666754)
The difficulty adjustment algorithm for Bitcoin is unfortunately very naive - there is a reason blockchain timestamps have a 2 hour deviation.

For some data, look into orphan blocks: https://www.blockchain.com/btc/orphaned-blocks

Re:Why Proof-of-Work Does Not Scale on Friday August 09, 2019 @10:30PM (#20659783)
A fork could be created just by taking the existing longest chain, and attempting to append a block to the frontiers blocks parent, or even to the frontier block itself. It's pretty simple. The time between blocks still is non-deterministic, and not often is there realistically a clear winner.

There existing n forks, even at a bare minimum of 3 forks of the same height is very common, especially if you consider how many miners there are in the entirety of the Bitcoin network.

Re:LF: Fully Decentralized Fully Replicated Key/Value Store on Thursday August 01, 2019 @05:11AM (#20582264)
Interesting - would love your thoughts, why is it that DAGs aren't very scalable?
Unfortunately not, but thanks for the tidbit on Noise (the crypto protocol).

We're open to integrating with best practices in a manner that makes the library more secure, and everyone happy.

Halfway through the paper, it describes a new approach to creating trustless, decentralized cloud computing markets via. cryptographic resource attestation.

To simplify it out, the resource attestation model allows one to bind a virtual currency to some amount of computational time and resources.

It allows users to securely rent away their smart devices when they're idle to developers, researchers, startups, and enterprises who really need large amounts of compute power for cheap prices.