guenoledc
commented
2 years ago So, you are saying that in case the in turn sealer cannot make its block, after a certain time waiting all other nodes that could be next (not the last sealers N/2) should try to make a block using PoW but still earn their reward based on their carbon footprint.
So if the difficulty is 2, the hash of the block should be below a certain number - what will be that number and where will it be stored in the block?
_I believe we should perform tests on that. The difficulty is also linked to the 51% attack risk, but in our setup case, the 51% attack risk would mostly be about becoming the secondary sealer once, so the attack makes no longer sense.
The PoW would become the "blockchain failover mode" and it becomes merely an economical threshold for the attacker who want to be positioned as the default backup sealer, that would give him an incentive to do any kind of DoS on other sealers when the attacker is offturn.
Now, with PoW activated in that scenario, it is more expensive and less sure (since PoW is a probabilistic model). In that context, nowing that PoW will only be activated in failure failover mode, the nodes will not have in the usual run high carbon footprint, but only when the network is failing (wether it be on some strange network congestion event, electricity issue, but most probably when the network is under attack).
To answer the question of the difficulty in geth PoW, it is not static and rather complex.
In ETH, the difficulty is computed dynamically (along with the reward, mincapped at 2ETH now for the sealer) Spec: https://eips.ethereum.org/EIPS/eip-1234 Code: https://github.com/ethereum/go-ethereum/blob/master/consensus/ethash/consensus.go
Looking at the current geth code, we see that the difficulty computation has gone through a lot of updates (timebombs, constraints with the upcoming "merge")
The best would be to go back in ETC (original blockchain) difficulty computation https://medium.com/@cseberino/ethereum-classic-difficulty-formula-634bb2ed4ce0
and change parameters to keep the blocktime low (below 10s on PoW mode). _
Also, as a node operator, I would probably prefer not try to compete to keep my node with a as low carbon footprint as possible. I will let the other do the job
There is indeed an incentive not to do the PoW part. Therefore, the reward should be adapted when the network is in the PoW mode. There should be 2 carbon footprints: one for the POA (very easy to optimize) and one for the POW (very hard to optimize). The ratio between the 2 should take into account the estimated % of the time the network will be in failover mode
There is no better decentralization than PoW. PoW required hardware innovation, access to cheap electricity, long term economical investment with hardware setups, continuous innovation in hardware optimization, required devops and infrastructure skills, it can hardly be corrupted. The side effect is it is ignominous and absurd for the planet, it's a selfish and slighlty on the spectrum behavior from the miners community. The PoCR methodology is really fitted for a PoW context, while in the clique setup, it makes much less sense.
I like it but I find it less efficient than slashing some cryptos when the in turn node did not seal.
Slasing does not lead to a better decentralization and the difficulty to take over the network. The victim node not sealing might not even be the evil player, victim of some kind of DoS attack, that have proved to be numerous on the ethereum blockchain. Now, every function price in gaz is representing efficiently the memory/disk usage/cpu cost of miners, because some hackers launched DoS attacks in 2016 early 2017 spending roughly $12,000 in gaz to put the network down, with no economical interest (only for other networks to kill a competitor). In PoCR case, we can estimate some bad actor is willing to spend up to $100,000 in gaz to kill the network with no immediate financial reward, just to publicly show the network is not reliable for future DEFI challenges. Finally, thanks for the formalisation of the CRIP-1 (Carbon Reduction Improvement proposal 😉)
sjehan
@mdekofin @guenoledc
1. Decentralization is hard As we know, PoW is very good at random node selection using the original hardware investment as a collateral / weighting rule. PoA (clique) is merely considered as some limited consensus for private companies by the "thinkers" of modern world crypto.
https://twitter.com/vitalikbuterin/status/1309137155843817477?lang=en
Carbon footprint optimization is specifically interesting for PoW, since Ethereum now is consuming around the same electricity as Nederland.
PoS is not a solution either, as it is oligopolistic. Whales get the control, the control is easily fungible and can be easier to corrupt than setting up the biggest miner pool, which takes a lot of knowledge and time, some investor could not easily replicate. Knowledge requirements to mine is the real decentralization factor, something largely misunderstood. Similar to innovation: because innovative knowledge is largely decentralized, any highly centralized approach of an innovation factory is flawed.
In PocR, the knowledge is the ability to build efficient miners hardware infrastructure.
https://www.lynalden.com/proof-of-stake/
2. The miner innovation challenge Because mining in POA is very simple, there is no race to innovation at setting up some miner node. This had happen in PoW and reinforced the decentralization nature of the network, which will not happen in any PoS networks
https://medium.com/@fouda/the-asic-mining-race-and-where-it-is-going-afec44f021e2
" As the production of ASIC miners is now distributed between multiple players, it is not possible to have a monopoly where the manufacturer sets the prices to be the only winner."
To have innovation back in PoCR, it could be good to ask somehow a very limited in time PoW work.
3. The network stability
In a fully distributed network, we should allow greater failure rate for any single node.
We should also allow minimum requirements on node registration, for example in PoCR case, a fast automated remote audit process would ultimately be ideal.
However for POA, the attack analysis showed the major drawback is in case of the elected in-turn sealer failure: there is no real consensus on a secondary leader election, the chain get into an unsecured state where some attacker could creep in (easily being elected as the next sealer).
4. Proposal
We would like to propose pow as a second leader election mechanism (when the expected in-turn sealer fails), to prevent any attack risk, and to allow more innovation on node infrastructure setup. The PoW found hash will also reshuffle the sealing ordering of the miners, to prevent any coordinated attack on known sequence of miners (for example Sealer1 => Sealer 2 => Sealer 3 sequence could be anticipated by an attacker that will first target Sealer1, then Sealer2, then sealer3 switching in just a block-time).
The stress tests proposed in the first issue would then be accounting for a % of nodes failures evolution as a third dimension. The stress-tested node should switch to PoW with its carbon footprint assessed at that time.
A good assessment of the PoW vs clique block sealing ratio should be something like 3%. Of course, this percentage depend on the required level of investment on the networking stack (double connection / required bandwidth / fast antiDOS hardware equipment / possibly failover mechanism of an existing node). With some expensive setup, this ratio could be brought to less than 0.1%.