In this article I argue that depending on how one programs one’s client, one can build a Consistent and Partition Tolerant or Available and Partition Tolerant system on top of Bitcoin or really any block chain. And no, that isn’t a contradiction and no this doesn’t violate the CAP theorem.
[Note: Lots of updates in response to feedback]
Block chains can be strongly consistent but not in the normal deterministic sense we are used to from consensus protocols like Paxos. Instead the strong consistency is probabilistic. That is, if one waits for long enough then the probability of a particular transaction being removed from the chain falls to negligible levels. This then provides the basis for a protocol that can treat the block chain as strongly consistent, where the protocol is “Wait until a transaction is X blocks deep in whatever chain one sees”.Read More
It turns out that building a distributed database with ACID behavior (aka a block chain) isn’t easy, it requires a lot of code and a lot of processing. As a result block chains like Bitcoin can process around 4 transactions/second. A pretty slow pace for a globe spanning system. To work around this and other issues I explore below, we hear more and more about off block chain storage. But it turns out that if you store off the chain then you lose the chain’s ACID guarantees. In many cases that loss is fine but it does call into question if the use case that can leverage off chain storage really needs the chain at all.
[Update: Thank you to Shawn Cicoria for pointing out that my original price quote for storing a Gigabyte of data in Ethereum was off by a factor of 32. My mistake is that I did the calculations forgetting that the gas price is per Ethereum Word which is 32 bytes.]Read More
My day job has required me to look into issues related to using the block chain in the enterprise. This lead me to a simple question - why would an enterprise be interested in the block chain for running its own business?Read More
Previously I waxed poetic about the amazing powers of Serval to create mesh based Internet infrastructure for developing and less developed countries (LDCs). The thesis being that if we had meshes of Wifi endpoints that could move data around without charge then people could have local applications on their smart phones that run peer to peer and could take advantage of this infrastructure. But how do we build those apps? That is where Thali comes in. But yes, we need more. See below.Read More
Smart phones are showing up in the poorest of countries. Even the Internet is showing up but it’s still quite expensive. But for a reasonable price we can deploy Wifi based local mesh infrastructures that can let people run applications on their smart phones and communicate locally with people around them. We have the technology! Below I explain what that technology is and why it’s all Serval's fault.Read More
I needed to figure out how many Wifi endpoints which had a range of around 300 feet would be needed to form a mesh that covers a square mile. I do a bunch of 1/2 baked math below to estimate that 138 endpoints would be needed for complete coverage.Read More
Serval is a project that wants to enable mobile phones to work no matter what. They have built mesh technology to let mobiles make voice calls as well as share data and have an app available on Android to use this technology. This is a technology that Thali could potentially really leverage. In the first section below I give a quick walk through of Serval. In the next section I compare and contrast Serval and Thali’s ways of solving similar problems. Then I conclude that hopefully we can reach a point where Thali just runs on top of Serval.Read More
I went to SF to meet with folks from the city of SF to discuss how we could use Thali to help improve recovery after a major earthquake. The meeting was both productive and eye opening. Our next steps are to put together a proof of concept to hopefully use in a live trial later this year. Below is an explanation of the who, the what, the why and most interesting as a geek, the how. Technologies and emergencies don’t necessarily mix so we have to think hard about how to make things better, not worse.Read More