“No one is bound to compute useless hashes forever. There is just trust, trust in the fact that the validators are so invested in that particular blockchain that they will work in its favor.”
(the work doesnt have to be useless either)
1 Like
So is POS being explored for Zcash’s future potentially? Would be very cool to earn more ZEC for staking. Sort of like a savings account.
Obviously not … But i agree with you…
2 Likes
Zooko did seem to show interest in POS… I never read a post from the official team saying it was definitely ruled out. Only for next year upgrade since there is not enough time…
Boxalex, any opinion on Tezos? They seem to also work quite steadily in the background, and seem to be able to go through the bear market without issue thanks to their huge financial reserve…
It has been declared that POS is NOT an option for 2019 and 2020 as bevor introduction it needs 1 year lead/research time. Means the soonest for POS being an option would be October 2021 and as said allready, it’s not being explored so far. I can’t find any reference, proposal or voting for POS on the Zcash gifthub…
how does one stop an entity from stake grinding without setting-up checkpoints?
what exactly do you mean? As a non native English i have a bit of problem to understand exactly what you have in mind and it would be nice if you formulate it a bit easy or give a scenario/example that explains it further
“stake grinding attack, the attacker has a small amount of stake and goes through the history of the blockchain and finds places where their stake wins a block. In order to consecutively win, they modify the next block header until some stake they own wins once again.”
This doesn’t seem to be really an issue as there are different mechanisms/designs/approaches to prevent this to happen:
How does validator selection work, and what is stake grinding?
In any chain-based proof of stake algorithm, there is a need for some mechanism which randomly selects which validator out of the currently active validator set can make the next block. For example, if the currently active validator set consists of Alice with 40 ether, Bob with 30 ether, Charlie with 20 ether and David with 10 ether, then you want there to be a 40% chance that Alice will be the next block creator, 30% chance that Bob will be, etc (in practice, you want to randomly select not just one validator, but rather an infinite sequence of validators, so that if Alice doesn’t show up there is someone who can replace her after some time, but this doesn’t change the fundamental problem). In non-chain-based algorithms randomness is also often needed for different reasons.
“Stake grinding” is a class of attack where a validator performs some computation or takes some other step to try to bias the randomness in their own favor. For example:
- In Peercoin, a validator could “grind” through many combinations of parameters and find favorable parameters that would increase the probability of their coins generating a valid block.
- In one now-defunct implementation, the randomness for block N+1 was dependent on the signature of block N. This allowed a validator to repeatedly produce new signatures until they found one that allowed them to get the next block, thereby seizing control of the system forever.
- In NXT, the randomness for block N+1 is dependent on the validator that creates block N. This allows a validator to manipulate the randomness by simply skipping an opportunity to create a block. This carries an opportunity cost equal to the block reward, but sometimes the new random seed would give the validator an above-average number of blocks over the next few dozen blocks. See here and here for a more detailed analysis.
(1) and (2) are easy to solve; the general approach is to require validators to deposit their coins well in advance, and not to use information that can be easily manipulated as source data for the randomness. There are several main strategies for solving problems like (3). The first is to use schemes based on secret sharing or deterministic threshold signatures and have validators collaboratively generate the random value. These schemes are robust against all manipulation unless a majority of validators collude (in some cases though, depending on the implementation, between 33-50% of validators can interfere in the operation, leading to the protocol having a 67% liveness assumption).
The second is to use cryptoeconomic schemes where validators commit to information (i.e. publish sha3(x) ) well in advance, and then must publish x in the block; x is then added into the randomness pool. There are two theoretical attack vectors against this:
- Manipulate
xat commitment time. This is impractical because the randomness result would take many actors’ values into account, and if even one of them is honest then the output will be a uniform distribution. A uniform distribution XORed together with arbitrarily many arbitrarily biased distributions still gives a uniform distribution. - Selectively avoid publishing blocks. However, this attack costs one block reward of opportunity cost, and because the scheme prevents anyone from seeing any future validators except for the next, it almost never provides more than one block reward worth of revenue. The only exception is the case where, if a validator skips, the next validator in line AND the first child of that validator will both be the same validator; if these situations are a grave concern then we can punish skipping further via an explicit skipping penalty.
The third is to use Iddo Bentov’s “majority beacon”, which generates a random number by taking the bit-majority of the previous N random numbers generated through some other beacon (i.e. the first bit of the result is 1 if the majority of the first bits in the source numbers is 1 and otherwise it’s 0, the second bit of the result is 1 if the majority of the second bits in the source numbers is 1 and otherwise it’s 0, etc). This gives a cost-of-exploitation of ~C * sqrt(N) where C is the cost of exploitation of the underlying beacons. Hence, all in all, many known solutions to stake grinding exist; the problem is more like differential cryptanalysis than the halting problem - an annoyance that proof of stake designers eventually understood and now know how to overcome, not a fundamental and inescapable flaw.
A good read about POS Security (including the Grinding Attack!):
Securing Proof-of-Stake Blockchain Protocols
My personal opinion is that POS is way more secure than POW for several reasons:
- it eleminates the main threat, mining pools…
- attacks and take overs are way more expensive
- counter measures can be made/designed way more easy compared to POW.
i said “how do you stop these types of attacks without centralized checkpoints.”
I’am not sure, as i’am not a DEV how centralized the different approaches/designs against the grinding attack vector are. These must/should be commented by someone that 100% understands the countermeasures described in the 2 articles i posted.
My personal understand from the article is that it’s solved by design in the meaning no centralization for fixing this problem is involved, but i’am not an expert here for sure and i might be totally wrong.
Actually it would be interesting to compare POW versus POS attacks and the level of centralization that is involved to prevent/fix attacks on both. Than we would have a clearer picture which design uses more centralization to prevent/fix the various attacks, not?
Other interesting question directly compared to current ZEC state would be:
- How much centralization and possible attack vector do we have with the current ZEC mining pool distribution? Right now we have 6 mining pools that control 75% of the hashpower from which 3 alone control over 51%…
so, you admit you know close to nothing about securing a PoS block chain, but you still advocate for it.
1 Like
I’am not a dev so i don’t have to know the details on how exactly each detail in a complicated algo and design has to work. Reading the solutions by experts is enough for me to believe it’s secure, it has a future and it’s superior to POW…
Calling this close to nothing just becuse i’am not an expert to explain/know how much centralization each counter measure involves is far from being fair…
Maybe you can contribute with more details?
Anybody runs a ZEN secure node and can share experience? Rewards? Difficulty to setup?
I used to run zen super node. Rewards are received for each day your node is online 95% of the time, but they are paid out weekly. Difficulty to set up i would say 5/10.
Is it worth it? No. You earn some zen while it dropping in value. Best time to sell Zen was day before super nodes launched.
Also just want to paste this here in this topic:
1 Like
thinking coda protocol might possibly make checkpointing unnecessary. need to dig a little deeper.
I’am researching a bit myself right now about coda. So far i got that much out:
-
Tezos has or is working on something very similar to Coda (the article is from June 2018 so i’am not sure in which state they are as Tezos so far wasn’t one of the POS coins i have tested and investigated closer!)
-
Coda seems to have it’s roots in dPOS, which makes me think it can easyly used/adapted in every POS design as well.
-
Coda might be more decentralized than dPOS and might be the next step. I could imagine that CODA might as well get implented/designed to be used in POS designs, just logical if it holds what it promises.
-
some main differences in the approach:
Kadena believes that smart contracts must be human readable.
Tezos believes all smart contracts must be formally verified.
Rchain believes that smart contracts should run concurrently across dapp chains and be formally verified.
Coda believes everything must run through SNARKs in order to guarantee that even tiny nodes can verify the integrity of chains, thereby maximizing the probability of maintaining maximum decentralization in perpetuity. -
Coda won’t be patented but stay open source, another thing i’am sure, in case it’s successfull, it will be adopted by POS designs immediatly if it fixes some flaws or weak points that might be present in POS like designs…
Resources:
Very interesting read about the different approaches including Coda: