Toccata & Fugue in the Key of Blockchain
By: Jillian Ada Burrows
Tags: Technology, Git, Bitcoin, Programming, Blockchain

Toccata & Fugue in the Key of Blockchain

Variations of Blockchain Based Protocols

This article assumes some basic knowledge about blockchain and is best read after reading my last article on how Bitcoin creates trust. This gets into some computer science-y stuff — if you feel it’s particularly opaque, please let me know.

Blockchain is probably most familiar from the role it plays in cryptocurrencies, where it stores the distributed ledger. The term blockchain came into use after Bitcoin called its main data structure a chain of blocks. However, the general form of the data structure existed since 1992 [1]. The data structure was cemented when Haber & Stornetta wrote “Secure Names for Bit-Strings” in 1997 [2]. Eleven years later, the first modification to the structure was made, adding the nonce for Bitcoin’s proof of work scheme [3].

The origins of the underlying data structure has everything to do with ensuring a document or set of documents can be proved published in a particular form at a certain time. In this context, a document could be an image, audio file, movie, or other computer file. This is incredibly general and adaptable to many different circumstances.

The structure is really simple, though the nomenclature makes it sound scary. It is a directed acyclic graph (DAG) with a Merkle tree at each node [see note 1 for a verbal explanation]. For a visual reference, below is the visual representation of the structure. The node IH(t-1) has the same tree structure below it. The connections between each IH(t) to IH(t-1) define the directed acyclic graph. Only the leaf nodes, which a labeled with single letters, have data — the rest of the nodes are just hashes which verify the content in the layers below. In reality, the Merkle tree is always modified to help gain some efficiency.

The basic structure for blockchain. It shows the link from the current node to the previous one along with the Merkle tree contained in the current node. This is from Secure Names for Bit-Strings [2].

Cryptocurrency

There are plenty of articles detailing how Bitcoin generates trust. The gist is all nodes use the relationships between the tokens, transactions, and blockchain to verify the transactions. If there is ever a branching of the train the nodes keep working until one branch of the chain gets longer and then all nodes use that branch as the reality of the network. When the next branch happens, rise and repeat. Proof of work is only a small part of why the chain is trustworthy, as there are many other constraints. As has been demonstrated by other tokens, there are other methods of proving trustworthiness to write to the blockchain, such as proof of stake [4], proof of space [5], verifiable delay functions [6].

Git SCM

There is a project called Git, invented by Linus Torvalds in 2006 [7][8]. Git is used by many programmers for managing changes to source code. It actually uses a lot of the same structures. Git is a super set of blockchain. It has more structures in it, including a second DAG for notes. Each branch of a repo is a pointer to a particular commit (node in a DAG). While in normal use a branch will often share much of the DAG from another branch, it doesn’t have to share any part of the DAG.

I had this idea earlier this month and posted a thread on Twitter about it.

Git stores all of the files in a particular commit as Merkle tree like structure. This means its primary data structure is a DAG of trees— just like Bitcoin’s primary data structure. It does differ in that while Bitcoin requires the entire history of the DAG to be downloaded, Git can technically only download a snapshot of a specific point in the DAG and incremental updates are possible, because it doesn’t store the files in the tree — just a hash of the blob of content. In this particular case, using a Merkle tree inspired structure allows for quickly determining changes between each tree structure [see note 2].