What is Unification?
To give context of the problem being solved, one should understand that Unification began as a “2nd layer” protocol – Drawing from the core teams collective experience in enterprise consulting and software development – UND was originally designed to be solely a “data liquidity” protocol which would allow enterprises to standardize/tokenize their data and place it in a liquid format to be bought/sold/transferred over a blockchain. What we were building was not “sexy,” rather it was fulfilling a very lucrative, yet possibly boring need for enterprises and the future of data.
As the team spent better part of a year developing the codebase and engaging in early enterprise outreach – over the course of hundreds of conversations and then subsequent verification of realities, it became quite apparent that it was not possible to create a functional “2nd layer” when in practical reality there was no “1st layer” that worked in any way that would be functional for any sort of serious enterprise trying to do “work”.
By “work” we mean the daily mundane – sometimes automated execution of smart contracts that happen in the thousands/tens of thousands/millions and are not directly related to any sort of immediate monetary gain/loss of money/tokens.Early concept chains such as ETH and EOS gained prominence in 2017-18 and laid out a vision of how things “should be” – but limitations were quickly exposed when it became apparent that current technological constraints would not allow “all the smart contracts in the world” to validated by any single blockchain.
Even with the best of intentions, when placed in a “n+1” scaling situation any “closed” system quickly achieved critical mass and all of the “work” transactions got pushed to the back while “high value” transactions such as coin-speculation, (erc-20) gambling, (EOS) and pseudo-gambling (crypto-kiddies etcetera) would by nature clog the network.
The other side of the solution that has been approaching from the corporate side has been the deployment of fully private “consortium” blockchains as proposed by offerings such as Corda and Hyperledger. Being built on the “linux/redhat” model – the idea was to create open source software that “does useful things” and then bill for consulting to implement and maintain. This would effectively and instantly solve the “scalability” issue as the required amount of validators is (n) – ie. .whatever the deployer determines and only transactions allowed by the validators will be allowed on the network.
Meaning that these fully “private” implementations are useful in theory – but depending on use case can sometimes be regulated to nothing more than a glorified database so that someone can say “we are on the blockchain”.