There are various emerging design decisions to be made when structuring a softwares blockchain, as well as whether to use a blockchain at all. The Seed project will take a hybrid approach between a blockchain solution and the more recently emerged directed acyclic graph (DAG) solution. The intention is to initially have transactions be connected through a DAG, validating each other as they come in. Once transactions become valid, they get squashed down into testament blocks on the blockchain half which represent condensed updates of the world. This approach aims at minimizing the required propagation time and validation time while also drastically reducing the blockchain storage size.
Entanglement is the Seed implementation of a directed acyclic graph (DAG) solution, heavily inspired by IOTA’s tangle. The concept of entanglement is instead of organizing the transactions into blocks and blocks into a list, the DAG has all the lists in one large mess, where the transactions link to each other. Effectively, each transaction validates multiple other transactions, and this creates an ever growing web where the confidence we have in a transactions validity is based on the confidence we have in the transactions which validated it. It’s similar to how pressure works, where the dirt deeper into the earth feels more pressure than the dirt sitting at the top. Transactions deeper into the tangle are heavily trusted, as they have a lot of pressure coming from the transactions above it which validate it.
Directed Acyclic Graph solutions have become a very prominent contender for a blockchain alternative technology. Relying on transactions to validate other transactions removes the requirement of miners, making the validation process a truly distributed process rather than a decentralized process run by several miners. The DAG approach is much more ecologically friendly, as the mining process in proof-of-work cryptocurrencies is a very computationally expensive process. The DAG approach does require a form of proof-of-work present in validating previous transactions, it isn’t the same as the expensive blockchain equivalent. Where blockchain transactions are executed synchronously, DAG transactions arrived and are executed asynchronously. There is no true order, however DAG’s can be flattened if required.
Transactions in the DAG are validated by other transactions. Therefore, there are a number of factors that play a role in how confident we are in a transactions validation. The number of parents who validate the transaction plays a role, as well as the trustworthiness of the parents. The children transactions that were validated by the inspected transaction are also analyzed, as if any of those children are not valid, that also raises red flags for any transactions that claimed such child was valid.
This validation process allows for the fuzzification of trust. That is, the ability to inspect the trust we have in a transaction on a quantitative comparable scale. A certain user interface can require certain transactions are 15% trusted before executing, while others can wait for 100% confirmation before trusting, depending on the activity and use case requirements. This fuzzification of trust gives an interesting dynamic, rather than the binary “confirmed” or “unconfirmed” equivalent found in blockchain technology.
A DAG of transactions can be viewed as a Merkle DAG. If each transaction header had a merkle hash built from the hashes of the transactions it validated, aggregated with its own hash, we would build a variable of the Merkle DAG where each node represents both their children hashes and their own data, rather than just one or the other.
This DAG can then be pruned by a mechanism being referred to here as Merkle Tree Node Extraction. This is effectively where a node can be selected from the DAG, and analyzed as if it was a tree where the selected node acts as the Merkle root of the tree. We can prune out a Merkle Tree of transactions, containing the selected transaction and all its children.
This extraction method can be utilized for long term storage transfers. The DAG acts as a short term storage of transactions where users validate each other in a distributed manner. Once transactions who meet a certain criteria reach maximum validation, we do a merkle tree node extraction on the selected transaction, pulling it and its children out of the DAG, passing it over to our blockchain for permanent longterm storage. The criteria would most likely turn into a pseudo-random criteria, such as triggering on every transaction who’s hash starts with a certain number of leading zero’s.
Blockchain is the most commonly used technology for building cryptocurrencies. The first success of its kind was Bitcoin created by Satoshi Nakamoto in 2009. Blockchains traditionally require a unique type of user known as a miner to take transactions from users, line them up synchronously into a list and build them into a block. They would then do a computationally expensive mechanism known as mining in order to solve a sort hard of cryptographic puzzle. These blocks contain essentially all the data and are immutable. The entire blockchain is stored.
Our blockchain in Seed differs from traditional blockchains. First and foremost, we do not have miners because all transaction validation is preprocessed by the DAG before being moved over to the blockchain. Users deterministically create their own blocks in a way that is the same for all users, removing the requirement of miners completely. Secondly, in traditional cryptocurrencies a block represented a grouping of valid transaction data, whereas our blockchain represents the condensed effects on the ledger that a grouping of transactions caused. Transactions, when being pruned out of the DAG and moved over to the blockchain, get squashed together, with their effects and minimal validation info (such as signatures and hashes) being aggregated into one block. These blocks each represent an update on the world that these transactions then caused.
Similar to traditional blockchains, the genesis block is the initial block on the network. In Seed, the generation block will include the deployment logic of the initial module in the system, the Seed cryptocurrency. In theory any ledger should be able to start at the genesis block, apply all testament blocks, and then get to a up to date view of the world efficiently.
The squashed transactions that get pulled out of the DAG each become their own block in the system known as a First Generation Testament Block. 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.
When the Entanglement has a transaction who meets the required criteria for extraction and reaches full validation, this transaction is pruned out of the DAG, pulled out along with its children and all their children’s children. However, the Testament Block stores a squashed view of these transactions. The intermediary communication step between these two transaction containers is transaction squashing.
Transaction squashing is the concept of merging multiple transactions into one central update, ignoring the non-essential information. Transaction squashing in practice 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.
Transaction squashing cannot remove all data, as information required for validation cannot be removed. Such information includes public keys, transaction signatures and transaction data hashes. What can be discarded, however, is the bulk data inside a transaction describing its effects on the world, which is instead replaced by the lean data of what changed amongst all the transactions merged.
Seed - Introduction - The Decentralized Cooperative Networking Approach
Seed - Literature Review - The Flaws of Proof-of-Work
Seed - Dev. Discussion - Merkle Tree’s
Seed - Dev. Discussion - Tangle vs Blockchain (Part 1)
Seed - Dev. Discussion - Tangle vs Blockchain (Part 2)
Seed - Dev. Discussion - Transaction Squashing - Proposition (Part 1)
Seed - Dev. Discussion - Transaction Squashing - Considerations For Jitter (Part 2)
Thanks for reading! The internal debate on transaction squashing has not been fully complete, however it is at the point where we are confident moving forward. There will be, however, another blog or two dissecting it to come. If you enjoyed what yo
