Today I’m going to be discussing transaction squashing, a proposition I have for our Seed blockchain in order to keep the end blockchain size small. This proposition is only possible due to the way we plan to use both a blockchain and a tangle under the hood in order to maximize the benefits of each and remove miners from the equation. Although I do not explicitly refer to the previous writings, topics discussed in them will be used here. Below are relevant writings that you may want to reference if any portion of this blog feels too knew to you.
Dev. Design - Cryptography, Public Key Encryption & Hashing
Dev. Discussion - Merkle Tree’s
Dev. Discussion - Tangle vs Blockchain (Part 1)
Dev. Discussion - Tangle vs Blockchain (Part 2)
Transaction squashing is the simple concept of merging sequential changes into one single change. In Github, a technology created to allow for open source code contributions, they use a directed acyclic graph (DAG) to manage their user code changes commits, and have proven the ability to squash multiple sequential commits into one merged commit, while still being done from a DAG. Without going into the specifics, transaction squashing would be very different under the hood in its implementation, however the general idea is the same.
In layman’s terms, sure my bank keeps track of all my transactions in a big list, but after I trust that these transactions did occur, what I write on my sticky note is “+$500 this month”, not save every separate transaction that sums up to the increase in my bank statement. Once we trust all the transactions implicitly, we figure out what the total changed amount is. This simple concept I believe can be applied to blockchain storage in order to severely reduce blockchain sizes.
The reason we find ourselves asking this question comes down to the predicament of our blockchain scaling issue. Our system is attempting to achieve realtime networking requirements, therefore a high throughput, low latency blockchain. This goal is to achieve two transactions a second for transactions that explicitly state they require this express treatment. If we assume the minimum viable product goal is to power 50,000 active users sending two transactions a second worth of data. If each transaction averages 500 bytes of data in size, then our blockchain in this worst case scenario would grow at a rate of three gigabytes per minute. This is obviously not a sustainable growth, however this is the biggest size assuming no pruning was done. Transaction squashing is a concept I think may help make this feat manageable.
Transaction squashing would be the act of taking separate transactions, isolating their effect on the world, and condensing sequential changes into one update. For example, suppose a scenario where a user Bob sends ten coins to a user Jane on ten separate occurrences. This would be ten different transactions of 10 coins from user A to B, however this could be squashed into one update denoted as “Bob sent one hundred coins to Jane”. We simply sum the effects on the world, ten +10’s, and merge them into one +100.
In theory, storing blocks of squashed transactions is simply storing the changes that occurred in a group of transactions. We could look at the genesis block, apply all squashed transaction blocks to the genesis block, and end up with the same end world state.
Our system stores the transactions in a constantly evolving directed acyclic graph (DAG) as they come in to each user. This DAG ends up being built as a DAG very similar in nature to a Merkle DAG, that is a Merkle Tree in which different parents be built on the same children. One interesting property of Merkle DAG’s is they lack a true Merkle Root, meaning many of the benefits of Merkle Tree’s is not present in the same way we’re used to. However, a very interesting benefit they still maintain from Merkle Tree’s is that you can grab any node and view it as an independent Merkle Tree, in which the chosen node is the Merkle root. This allows us to selectively grab Merkle Tree’s of transactions out of the DAG.
Another interesting property of the DAG is that transactions get trusted out of order, since their validation is based on a number of factors. This means certain parts of the DAG can be trusted while others can’t. In transaction squashing, we would take the trusted transactions and extracted Merkle tree’s of trusted transactions out of the DAG of unconfirmed transactions.
Because of the lack of miners, a lean, simple, deterministic approach must be taken for the protocol, as users themselves must take trusted transactions and build blocks out of them in a way that users can’t abuse the system causing excess triggering of this mechanisms. A simple solution is to require that if a transaction comes through with a certain amount of leading zero’s, and that transaction reaches a certain threshold of trust, it would get isolated along with its children nodes in the DAG and squashed together. This leading zero requirement assures that a user cannot easily attack the network by spamming it with requests for squashing. A hash must happen to generate a leading amount of zero’s, meaning the data inside must generate it. In Bitcoin, miners would attempt to find these leading zero’s, trying to find the nonce to prove they found it. In ours, we do not have a nonce, as we do not want users to trigger it on purpose, we want it to trigger systematically over time. For example, potentially it simply requires the first either bits be zero, would would be roughly every 256 transactions. This can be abused to a limited extent by users as users do have a limited control over the data to send, however they simply would have to keep trying transactions till they find one they want to execute that has these leading zero’s. The lack of nonce severely limits their options on ways to modify the transaction in order to generate more hashes and find the proper hash.
These squashed transactions pulled out of the DAG each become their own block in the system. However, rather than contain multiple transactions, they simply contain the squashed changes in data and all extra required info needed for validation (such as signatures, hashes and public keys used). Because these blocks are created through a tree of already transactions pulled out of the DAG, we don’t require a miner to do the validation work for us, nor a miner to sign it and propagate it. We can simply look at the Merkle root, the specific transaction that caused the squashing mechanism to operate, and treat that Merkle root as the signature for this testament block. This is because the Merkle root proves the validity of its leaf nodes data, as if any leaf node had any different data, it would generate a separate leaf Merkle root.
We can further squash testament blocks together to create a more condensed testament block. When a testament block is created out of transactions pulled from the DAG, it is a first generation testament block. When multiple first generation blocks get condensed together, they create a second generation block, so on and so forth. This system is similar to counting, where the number one million is not denoted by a million unique symbols, but is instead denoted by ten unique symbols (0 to 9) over seven unique positions (1,000,000). We may have nine unique first generation blocks, but on the tenth we would squash them and represent it by a single “ten” block in a separate column.
Each generation block would require all important information from the previous one. I believe it can be achieved that it simply requires the header data of the squashed testament blocks and the squashed transaction of squashed transactions. This would keep the blockchain lean and keep the number of blocks low.
In short, I believe we can take transactions and put them in a DAG initially of unverified transactions. If a transaction in this DAG has a hash with a certain amount of leading zero’s, we should isolate it from the DAG and take it and its children nodes out, creating a Merkle Tree where the selected node with leading zero’s is our Merkle Root. These transactions can be squashed, their causal-effect relationships merged together, creating a block which represents a single update to apply to the ledger. This block, despite being lean, would still require all the public keys, transaction hashes and signatures from the blocks it merged, as well as the proven validation they did for other transactions. This upgrade block is known as a first generation testament block. After a testament block is created with a certain amount of leading zero’s in its hash, slightly more zero’s required than for the first generation block, we then squash it and all other generation blocks on the table that are equal to it in generation. Therefore, if a second generation block is created it can also trigger the mechanism to merge it with all other second generation testament blocks, creating a third generation block. This pattern can continue indefinitely, keeping the blockchain optimally lean.
This ends my proposition on transaction squashing I have where I went over how I believe this can be achieved. Next we will analyze this and question possible flaws, benefits and unforeseen side effects of implementing such a system. If you enjoyed this content, an up vote or follow are always appreciated!
