Posts

Showing posts with the label Merkle Tree

Merkle Trees — Not Just For Blockchains

Image
(Apologies, I couldn’t resist the image/pun). Regardless, you   know   that hash trees have been used to validate data ( since, well, 1979 I guess ) in all sorts of arena, from databases like Cassandra, Dynamo, and Riak, to version control systems like git and subversion, to a host of file systems. They weren’t invented just for Bitcoin   Anyhow, here’s another nifty use case — using merkle trees to do immutable deploys of websites at   Netlify . Why immutable deploys? A bunch-a reasons, including •   atomic deploys and instant rollbacks , • the ability to   accurately   preview deploys   (by dereferencing the name from the content, you just point the name at the new hash behind the scene), • split testing   (transparently routing requests to different versions of the site), and a whole bunch more. The way they do this is pretty nifty • They identify and store all files based on the hashes of the content (not the names!) • A de...

Immutability for your K-V stores

Image
How do you  guarantee  that the data in your database is immutable? In particular, I’m talking about data that you  don’t want to change — things like call-records, historical data, transaction logs, etc. Of course, you could use something like  Datomic , or you could architect your application/data-structures/tables/… from the ground up to be immutable, but that could be … problematic. Especially problematic, in fact, given that I’m referring to your  existing  databases that have all this stuff in it — good luck trying to convince the business side of the house that you need to re-architect  everything ! Theoretically , this data should already be immutable, but, the reality is that there are  so many  attack vectors. 1. One of your developers could go in and tweak the data — you’d never know 2. Oh, only the DBA has access? What if  they  tweak it? 3. Worse, what if somebody hacks into your system? 4. Even worse, ...