Hello guys
can anyone review and poke holes in the below solution to the N@S and WS for Proof-of-Stake chains? This has been proposed by Mike Toutonghi, developer of
Verus, and announced a few days ago. I'm not a dev but I've trying to raise awareness and ask for feedbacks, unfortunately it's hard to get it through the noise.
First a little background:
Crypto Conditions, or CC, are utxo-based smart contracts for Komodo-based blockchains. The specifications were created by Ripple engineers and
proposed to IETF as a standard. Komodo is a Zcash fork and the first blockchain to implement them, also adding more enhancements and creating a way to make custom consensus rule changes.
Verus is a fork of Komodo and both projects are collaborating with respective enhancements. The lead developer of Verus is
Mike Toutonghi as I wrote above. Maybe you've heard the name because he's the ex CTO of Parallels and the chief architect of .NET when he worked at Microsoft.
This solution is going to be live on mainnet on october 28th when Verus also upgrades to Sapling.
There's not a paper yet but it has been explained in a
Medium article that I will quote here (omitting the first half that explains what N@S and WS are in layman terms).
Verus Crypto Conditions
To effectively use CCs for Verus’ purposes, Mike extended some of the capabilities of Crypto Conditions, particularly adding more meta data definitions and allowing CC transactions to act more like “normal” transactions. With the modified CCs Verus is able to implement powerful functionality that extends the flexibility and resultant power of the Verus blockchain in preparation for PBaaS and the services which will be able to be coded into blockchains in the future.
Stake Guard is the first Verus Crypto Condition to be released and it’s what solves the “nothing at stake” problem and performs the “magic”.
Stake Guard — The Proof of Stake Crypto Condition
This new CC which Verus has developed and is adding to the blockchain, works in conjunction with a newly modified signing script when staking and spending a reward.
The result is a blockchain-level Crypto Condition which handles all staking transaction spends, either processing them as usual for normal shakers, or allowing any cheated stake transaction containing its stake block reward to be spent by anyone who can prove its indeed a cheaters stake. No double spending occurs at any point, to cheat the cheater had a real stake plus additional cheat attempts at any given block. Only the legitimate stake reward can be spent when proven.
Here’s how it works.
1. When staking a new block, a new format of transaction called a Staking Transaction is generated. This transaction format is enforced and utilizes the Stake Guard at the minting of the new block. It contains more meta data, such as the public key of the staker who signed it, the UTXO, the block height, and previous block height.
2. If a cheater has tried to stake on more forks at the same block height, that cheat attempt is also recorded. Anyone scanning the blockchain can see it and verify that it’s indeed a cheat attempt, as the data is there immutably and without the ability to manipulate things like UTXO or information about the blockchain at the time of the stake.
3. For the community, this is an opportunity of 100 blocks to look for any such cheat attempts and tuck them away to take at that cheat transactions maturity. Also important to note: UTXO can only be spent once, so there’s no risk of double spending at this point. And the cheater’s one valid block reward is able to be taken by anyone who sees it and spends it at block maturity.
4. After 100 blocks when any block reward is spent, it passes through the Stake Guard Crypto Condition script which evaluates the spend transaction for 1 of 2 things:
Condition a — Is this spend being signed by the Public Key which staked it?
Condition b — Is proof presented in the OP_RETURN that this is a cheater’s block reward?
Result— Depending on one of the two conditions being met, Stake Guard will validate or reject the spend.
5. Condition a: if a normal staker is trying to shield their stake reward, their public key is being passed automatically to Stake Guard which compares it to the public key in the meta data of the stake transaction on the blockchain. They match, so it signs it as normal and the staker has their reward.
6. Condition b: if the public key of the spender does NOT match the original staker public key, Stake Guard verifies that the cheat transaction proof has been submitted in the OP_RETURN.
7. The proof of a cheated transaction, the data bits packed up from that duplicate stake transaction which the Cheat Hunter found, is passed in an OP_RETURN and the Stake Guard CC evaluates and confirms that it is indeed a verifiable cheated transaction. It does this by comparing the matching UTXOs of the legitimate and cheated staking transactions, their respective previous block heights, and their respective block heights at the time they were generated. In fact, this is another case of validating signatures to cryptographically verify that the stake transaction was properly signed, meaning proof of cheating cannot be forged.
8. If Stake Guard confirms the cheat transaction is indeed a cheat, the spend of the cheaters stake reward at the time of the cheat, is signed using the Stake Guard’s key and spent to the shielded address provided by the person who claimed the cheater’s reward. The wallet of the person who found the cheat reward is paid the block reward and it disappears from the cheater’s wallet.
Decentralized Anti-Cheat Staking
As mentioned above, for legitimate stakers the Stake Guard CC will function normally, signing the coinbase reward transaction when they spend it with their own Public Key…all in the background and at the blockchain level.
If, however, the 1 of 2 evaluation sees the public key of the person trying to spend it doesn’t match that of the original staker it simply verifies the person trying to take the free money from the cheater has proven that this is indeed a cheated transaction which they discovered and if so, will let them take it.
This can be done by anyone who knows how to pack up the data after scanning and finding cheat attempt staking transactions…but will also be implemented into the mining software by Verus to perform the attempted spend of the cheaters reward block when mining at the block where that cheat reward matures.
No Incentive to Cheat
The cheaters one single legitimate reward block out of the two attempts they made to double spend, is no longer locked in to be spent by them alone. Anyone can now spend this by simply proving to the Stake Guard CC the verified cheat transaction hash in an OP_RETURN.
So, while even the cheater can try to run and grab it with the rest of the network, or try to spend it before anyone else, now the odds are stacked against them… and why even cheat? Afterall, there is no double spend available due to the fundamental way in which the blockchain is modified with this Stake Guard.
It simply makes no sense, using the same logic PoW uses, decentralizing the process of catching and being rewarded for finding cheat transactions by getting the cheaters reward, and makes legitimate staking more rewarding by itself. And if cheaters do try anyway, the legitimate staker has a better chance of even claiming those rewards which the system makes publicly visible.
Chain Power and Nonce
Another important change being implemented in this new Verus upgrade is moving away from Chain Work to what Verus is calling Chain Power. Chain Power is now replacing Chain Work, solving the threat of Weak Subjectivity.
Chain Work
Within chain work, the block index is a sequential index of block entries which “knows the height” of the chain. As you build and add blocks, you add the entry to the block index.
This way at any point you have a maintained value that reflects the chain work at that point. The Chain Work is normally a sum of the proof of work difficulty, for any set of blocks.
Chain Power
Chain Power is a 50% of one value and 50% of another value comparative calculation. It’s a tracking of both Work and Stake.
Chain Work is based on a number that everyone calculates the same on every block. You can’t be completely sure of the time and date someone makes a block. So on a very small scale someone could make it seem like they had a little more work, just for a moment.
With Chain Power Verus will not just take the Proof of Stake difficulty, it also takes the actual nonce random amount of work from every block, adding it as additional Stake Power. This way no two blocks will match and there’s no way to manipulate this value.
This nonce “work” number will be added to the Stake Difficulty. Someone can’t just grind away at this as a result.
And so, Verus, as a “hybrid” combination of Proof of Stake and Proof of Work, will now have a value which is calculated from a comparison between Stake and Work. If stake power is at 20% and work power is at 30% for example, that is a sum total of 50% Chain Power.
What this means is, to attack the blockchain in a way in which weak subjectivity is a problem, the attacker would need to have more than 50% of either staking or mining power given the above example.
The implications of this are massive, making a hybrid Chain Power blockchain like Verus a weak subjectivity resistant chain and adding capabilities that far outweigh the security of traditional Chain Work in Proof of Work chains.
I also quote Toutonghi's direct reply to a question:
Q. What are the weaknesses of your approach?
miketout:
That’s a great question. First, let me explain how it works. The nice thing about the solution is that it’s simple, similar to the Bitcoin protocol. There are no locked funds or voting pools. The premise is this:
The nothing at stake problem asserts that it is more profitable to sign all forks, as doing so, although bad for the network, can raise the chances of the validator earning the block.
If you make it always a statistically losing proposition to try to cheat by signing multiple forks, the nothing at stake problem goes away.
This is in contrast to the approaches to date, which generally want you to commit more stake in a way that can be slashed. Instead, it works like this… any transaction can win, and if so, it becomes the source of your staking transaction. Your wallet creates the staking transaction, which includes some information binding it to the specific block you are staking on, signs it to be able to spend its source, and puts it and the coinbase transaction in the block with certain matching information.
The coinbase reward transaction is the Stake Guard contract and will validate a spend for one of the following cases:
The spend is signed by the originally intended recipient of the coinbase transaction.
The spend is signed by the Stake Guard contract and contains a stake transaction spending the same source transaction and bound to another block of a fork.
That means that if someone cheats, the cryptographic proof of them cheating spends any reward they would have made to someone else, likely the miner of the block at which that coinbase matures. Meaning that there is something at stake if you cheat. You will make less, meaning most people won’t try it, and those who do will make money for everyone else.
I’m pretty hard pressed to come up with any fundamental weaknesses in the model, but for the implementation, one could argue that the rule that a cheat proof must be a transaction targeting the same or higher block height might let a few cheats go by. I’d still say that statistically, it will always be the wrong thing to do to cheat, and that I’d rather err on the side of false negative than false positive when dealing with people’s rewards.
So what's your opinion? I wonder what Andrew Poelstra will say about it
