Seed - Problems & Hypothesized Solutions - The Cooperative Blockchain Scaling Solution
Background Information
Background Information on the Bitcoin Scaling Debate
Literature Review on The Flaws of Proof-of-Work
Problem Statement
It is unknown how a cooperative mechanism affects a cryptocurrencies efficiency, nor how a blockchain protocol can meet real-time server requirements. In this context, I am describing a cooperative validation mechanism as one where every user cooperatively validates each other, rather than designated users compete for the right to be the validator.
Sub-Problems
To analyze and compare the competitive proof-of-stake mechanism to competitive proof-of-work, validating that proof-of-stake is a valid alternative from a security standpoint.
To analyze the throughput, scalability and bottlenecks of a proof-of-work mechanism, as well as a proof-of-stake mechanism.
To analyze the throughput, scalability and bottlenecks of a cooperative proof-of-stake mechanism.
To determine what an analysis of sub-problem 2’s and sub-problem 3’s results show about what can be revealed when comparing proof-of-work with proof-of-stake, as well as what can be revealed regarding comparing competitive mechanisms with a cooperative alternative.
Research Question
Following the problem statements driving this research, the research question is “How would one replace competitive proof-of-work with cooperative proof-of-stake or cooperative proof-of-work for decentralized blockchain game servers”.
Hypothesized Solution
A cooperative approach may increase the scalability of blockchain technologies by a significant margin. In a scenario where, to transact, users must validate other user’s transactions, previous transactions would become more and more trustworthy as we receive new transactions who show matching for. Currently, a transaction must be propagated to the network, sent to miners, have the miners validate it along with all other transactions in a block, spend time doing work for proof-of-work determining the nonce, and then propagate the block to the network. At this point, the transaction is valid however it is not confirmed whether the entire network agrees with this fork, therefore users must then wait for a set amount of future blocks to go through the same process and create a chain. After enough blocks are put on the chain, we can trust the block which had our transaction.
In the proposed cooperative approach, transactions themselves would contain the validation for for future transactions. Similar to IOTA’s tangle, transactions would become more secure as the transactions which validated them become more trusted or as more transactions which prove work for this transaction are received. This approach has a few interesting benefits, such as being able to receive unconfirmed transactions right away rather than wait for a block to be propagated, as well as allows for a linear progression of trust on a transaction. For example, if a transaction was received which has two blocks which validated it, and those blocks are not validated, then we can somewhat trust this transaction but not really. Let’s arbitrarily say this transaction has a trust of 20%. We can compare that to another transaction with five parent transactions, each of which have been confirmed plenty, we could then trust this transaction more, despite it not being truly confirmed. Let’s arbitrarily say that this second transaction we trust 80%. Once transactions reach full confidence in trust, they are placed into compressor blocks on the blockchain which squashes them. This is for compressing historical data, viewing the blockchain as the long-term memory and the entanglement as the short-term memory.
Following this model gives us this fuzzification of trust on a 0% to 100% scale or a 0-1 scale, which will start at 0 and either gradually approach 1 as more transaction validate, or never increase in trust if no transaction validate it (or the transactions validating it are not trustworthy).
User interfaces can then base their displayed knowledge taking advantage of this fuzzy scale. For example, in an MMO we may be comfortable drawing a user in a given x/y coordinate if we are 15% confident that they are their, allowing us to simulate the transaction’s effect in the world very quickly, simply because there is no harm in rendering the player at a given x/y position. However, whether a trade transaction items from one account to another may require full confidence that transaction before acknowledging it on their client.
Another benefit of this hypothesized approach is the asynchronous view on transaction validation. In traditional blocks, transactions may be sent in any order around the world, with jitter and general propagation time to each miner dictating the order in which a particular miner receives transactions. This means that transactions occur asynchronously around the world, but are then ordered synchronously into the blockchain. Keeping the transactions in a directed acyclic graph allows for the transactions to remain asynchronous and be executed on users computers asynchronously. Users of a module or decentralized application on the system which require low networking times may have their users send transactions directly to each other, allowing them to prioritize transactions they care about rather than ones they don’t. For example, this asynchronous approach allows for a videogame to route their users transaction sending to prioritize people in their x/y vicinity of the game, so people who would visually be noticing a position update will receive it instantly, whereas someone playing one game may not care that users in a completely different application did a trade. Outside communication between users of different modules would still be required, however the asynchronous approach allows for quicker validation of transactions a user particularly cares about.
The combination of these benefits, not waiting for miners, the fuzzification of trust and asynchronous transactions, I believe, will allow for a blockchain technology to thrive in a truly distributed manner, while maintaining low ping, low propagation time, and the potential for a more seamless UI experience for blockchain projects.
Thank you for reading! The Seed project will include a multitude of proposed changes, however this problem and hypothesized solution above is a key mechanic that I personally am excited to attempt and prove! If you enjoyed the post, please like and follow!