BAC — A Tree-Based Approach to Blockchain Efficiency, Part II
A TLDR of Part I, in order to understand the technical solution proposed to what troubles blockchain:
- Inefficiency is the root cause hindering blockchain adoption and development.
- All current solutions for making blockchain tech and the layers on top of it more efficient — that is, faster and less-resource intensive — compromise either the blockchain’s stability or security.
Where does that leave us?
In a macro sense, very far from the faith we had in 2017, faith in blockchain’s power to transform the world for the better.
In a micro sense, at a seeming stalemate as to how to carry out Satoshi’s vision, given form over a decade ago now.
TOWARDS A SOLUTION
BAC is working on a solution. But to understand or judge its viability, let us first quickly get to the heart of the problem, from a technological standpoint.
For blockchain believers, it is very hard to admit to the key problem with the tech, because that tech must be considered a vast improvement, a priori, in order to support all the wonderful visions of what we would like to do with it.
And indeed, random seed generation, twin private and public key with one way hash — are all a triumph of trustless encryption. Miners competing to confirm blocks of transactions — a miracle of decentralization.
But thus far, blockchain tech has failed to consider the end user. Thus the ongoing delay in delivering on blockchain’s promise, let alone building a popular Dapp on top of one, when a photo-touchup app can go from zero to ten million users in a matter of months.
How has it failed the end user? Simply put, using the blockchain for her own purposes exposes her to considerable computing power requirements, and the need to synchronize mountains of data that have nothing to do with her.
Isn’t this constant synchronization of terabytes of data what makes decentralization possible, though, and thus something for users to put up with, and developers to work around?
We don’t think so. As mentioned at the beginning of Part I, division of labor is a universal principle for efficiency, whether chicken sandwiches, reliable cars, or a healthy immune system is the desired output.
Furthermore, such division of labor can be applied to a decentralized system. The goal is to use as close to the minimal amount of resources necessary as possible, while still ensuring data security and speedy transactions.
THE SOLUTION DEFINED
Clarifying the attribution of each address will enable rapid location and node traversal of an address. The binary tree is an excellent choice for such clarification, for which LevelDB — an open-source key value store — can be used as a container, like MySQL, but faster and more efficient.
BAC is expanding on the binary tree concept with the term “Trading Account Tree”, wherein each leaf of the tree corresponds to an address.
HOW DOES IT WORK?
First, a pair of public and private keys and addresses are generated utilizing the traditional blockchain approach. When a user obtains a valid private key and initiates a transaction, the address is sent to a miner, who will be selected based on the current queue at the time of the transaction.
The address will then generate a unique serial number, e.g. “HAAAAAAA”, which is more suitable for sorting and classification, in order to optimize levelDB function.
That serial number will be an important basis for searching and sorting data within the tree, otherwise known as traversal . In the entire binary tree, the distribution follows the following rules:
• The right subtree stores the sibling nodes of the top node. The address is uniformly created by the top node.
• The left subtree stores the subaddress of the current node.
Get xiongzhend’s stories in your inbox
Join Medium for free to get updates from this writer.
• When a left subtree occurs, the left subtree points to the left child, otherwise the left subtree is pointed to its precursor.
• When the right subtree occurs, the right subtree points to the right child, otherwise the right subtree field points to its successor
• The entire transaction account tree structure does not have the same address repeated on different nodes.
- If there are N nodes, there are 2N chain domains, and non-empty chain domains are N-1
There will be three kinds of nodes in the system:
- The Miner node which will locally save all completed transaction data within the tree structure and which will be responsible for the transaction packaging, data validation, and responses to data synchronization requests,
- The Witness node, which will save all tree nodes locally, construct and complete transaction data, be responsible for data validation, and respond to data synchronization requests,
- The Ordinary node, for submitting transactions.
In summary, the tree structure can quickly locate the relative position of the address, effectively obviating the need for blocks in more traditional systems.
Data will be saved efficiently, allowing a model with the following benefits:
• Greatly reduced data compression pressure for common nodes, as only relevant content needs to be synchronized, making it much more convenient for nodes to join and leave the network.
• Witness nodes are voluntarily joined, allowing large organizations to ensure data security.
- Each time the miner completes the packaging of the corresponding term, a version is generated for the current tree data and broadcast in order to synchronize with the entire network.
In addition to saving the serial number and address information of the account, the node of the transaction account tree also stores the transaction data of the current account. This is called a BTXO model, similar to Bitcoin’s, which contains two parts, VIN and VOUT, both kept separately.
With the transaction record of an account, the user’s balance can be obtained through an unspent transaction output (UTXO), a classic Bitcoin transaction structure for address balances. When the user initiates a transfer, the user needs to first sign the transaction through the private key and then broadcast it to the miner.
Transactions will not be placed in a block, but will be written to the VIN and VOUT of their respective accounts. With traditional blockchain,
the function of the block is to deal with hash transactions, similar to the clothes and daily necessities packed into a suitcase when traveling.
Said suitcase is easy to carry, but BAC has evolved the classification of transactions, so there is no need for all items in the suitcase to be unpacked before selecting the desired item.
Current miners confirming the transactions will generate a patch — that is, an update to the networks’ binary trees, relative to that of the previous miner, by using the longest common sub-block algorithm (the longest common sequence chunk), then broadcasting the resulting patch to other miners and witness nodes in the network.
GREAT PROGRAMMING — REAPPLIED
If this evolved protocol sounds a lot like version management software such as SVN or GIT, indeed it is. The trees of the future grow from yesterday’s seeds. That is to say, good architectures can be revisited and relearned from.
However, the difference lies in the fact that SVN or GIT reflects the data (or the copy of the value), while the blockchain reflects the transfer of data (or value) in most cases. Thus the breakthrough of trading through an account tree.
Among them, the patch is similar to the block in the traditional blockchain, an increment of recorded data. A further similarity
is that the data here has been classified according to attribution, and is not unordered. So the traditional blockchain and BAC can be thought of as different routes to the same destination. The former is flat but not direct, requiring of a user more time and resources. The latter takes a steeper mountain road, but can reach the target directly.
For those who find the foregoing rather technically abstruse, please bear in mind the heart of BAC’s proposition. We will prove that transactions can be fast, cryptographically secure, un-tamperable, decentralized, while still being efficient. In the case of blockchain, the inefficiency lies in the excess of unrelated data attendant on every transaction. The binary tree structure will be an evolutionary step in the utility of distributed ledger technology. Follow BAC to be apprised of further developments.
