Contents of the first commmunity announcement on Verus' discord. All dates c+p. They are pinned to #pbaas-development in the discord
miketout03/13/2019
@everyone as I've mentioned recently, us devs have been heads down on development lately, with a focus on PBaaS. Since it's really something new, and we are making great progress. It seems like a good time to start discussing how everything will work and what technologies are being used to implement a system that will bring a new dimension to cryptocurrency, an economy of blockchains that can work together, creating incentives for the entire system to become more secure, with each still an independent chain project, or blockchain database for a short-lived application like poll or election.
I will spend a few minutes now to introduce PBaaS and what it will enable, as well as some of the technologies that have been implemented or are in the process of being implemented that will make it work. As I said earlier, I can't promise to be around to discuss all the time. Sometimes, I may even be scarce, but I will make an effort to stop in, especially if we can generate some good technical discussion, or if this helps people to understand PBaaS enough to make more use of it when it is available.
First, what is it... PBaaS stands for "public blockchains as a service", and refers not just to the ability to start a blockchain at Amazon or on Microsoft Azure or even on your own servers. It means that the Verus network will soon provide everyone with the ability to start blockchains, and pay reasonable amounts of Verus to have hash power, participants, cross chain transactions and applications across the entire Verus ecosystem, (and of course, still interoperable with Komodo), and strengthened security across all chains as it scales. There are other capabilities planned, even in early releases, but let's start with how we can achieve those goals and break it down a bit.
Let's start with one example, a poll, as described in the vision paper. To start my poll, I would post a transaction defining the blockchain required to run it. I could select participants in any way I'd like, either allow them to join freely, or before ID services are available, which will be well after the first availability of PBaaS, I can send each person a specific authorization to participate. As part of the definition of the chain, I will say the first Verus block that will kick off mining and staking of the chain. I will also post a pool of rewards for mining and staking, because after all, this is a poll, and although voters will have enough money on the chain to vote, because they were authorized, I don't want miners or even stakers to have new coins that they might use for voting. That means, all native staking and mining rewards on my poll chain are zero, but I will pay a certain amount of Verus as reward for each block mined, staked, and in some cases, but often not, notarized.
So, for miners on the Verus network, there would now be a new chain to mine along with Verus that will provide some additional reward, a reward that I, as the poll operator, paid to run the chain. If that chain or poll is interesting to me as a miner, either because I know about it, or it pays particularly well, then I can add it to my mining, likely at a lower difficulty than Verus, especially if there are many chains using the system, but still with a Verus reward for each block mined, so I can supplement my Verus mining rewards with money that is actually part of an economy of services.
While it might seem easy to mine on one chain and pay rewards on another from a pool, it actually carries some interesting cryptographic and security challenges, challenges that we are solving in Verus with a completely automated and decentralized protocol, that scales, strengthens the security of Verus, and provides some truly exciting capabilities as the system grows.
Before we can do any of that, we have to answer the basic question of "how can we trust that the Verus chain should pay a reward from a mining pool to a miner of another chain?"
This might seem like a simple thing to do, after all, it's blockchain, but we have to make another assumption, while some people will certainly run both chain daemons to get these rewards, many people will not. As a result, we must have a way to prove to those on the Verus chain who know nothing about my poll chain that a miner who mined a block, or a staker who staked a block on that chain can spend Verus from the pool of rewards intended for those people.
To achieve a cross chain proving system that strengthens the cross chain proofs each time it is used, I started out, as mentioned, expecting to use a Merklix tree. At this time, we are using what is known as a bit of a twist on or maybe enhanced implementation of Merkle Mountain Ranges. Merkle Mountain Ranges are constant append hash data structures that guarantee log2 overhead growth as size of hashed elements. Rather than implement in the usual way, I've done a highly optimized version that uses minimal memory overhead and is kept up to date automatically in the daemon for every block. In addition, this data structure commits at every block to both the exact amount of work in that block and the exact amount of stake, as measured by the Verus Proof of Power algorithm. For every block, the root of the Verus (or any PBaaS chain's) MMR can be used to prove any and every block or transaction that came before it in the blockchain, as well as it's exact power. Using this capability, we are also adding the root of the MMR for the previous block to every block in the chain, including one copy of that number for every merge mined block across all blockchains, which currently looks like it will be limited to between 8 and 11 additional chains per block.
Now, we can look at a recent research paper that proves an optimal method for proving the correctness of a blockchain in the minimum amount of size. This technique, when applied to the Ethereum blockchain was able to prove it in about 400 KB. Of course, the research paper only covered proof of work, and did not provide a solution for how to combine that with proof of stake, but we have used similar levels of proof and security, with a Merkle Mountain Range, to make each and every attempt to spend the reward from a block, yet another notarization that validates the correct blockchain, effectively creating a validation chain inside the Verus chain that allows Verus to prove transactions on any merge mined PBaaS chains and vice versa.
https://eprint.iacr.org/2019/226.pdf
Since in a system where we are running the poll example, the voters will have the ability to stake and mine, and non-voters will only have the ability to mine, the voters themselves can ensure the security of their voting chain, as described in the vision paper.
As another example, think of just bootstrapping a project using a PBaaS chain, someone might start the chain with low native rewards and high Verus rewards to kick off the process, which might even be 100% contributed by the Verus community, but over time, a chain that is an actual crypto project with its own value and rules/function, even if it starts as a PBaaS chain, can actually operate as an independent, merge-mineable chain that offers its own native rewards, and can still retain the ability to prove itself across other chains in the Verus ecosystem.
To enhance the PoS security for a multi-chain proof environment and leverage it as a unique strength in a cross-chain system, we have implemented the first header-proof we are aware of for a UTXO-based staking system, which will serve as both PoS fake-stake prevention, even at the level of headers, and also, it will enable the PoS header itself to provide a uniquely strong cross chain notarization, one that can be proven wrong without requiring any synchronization of the originating blockchain. As a result, self-reinforcing cross-chain security fits like hand and glove with Verus proof of power.
Well. Hopefully, this is a good start and might spur some questions. I'm going to go back to developing. I'll pin these posts here and stop in to see if people would like to discuss.