-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hybrid Casper FFG #1011
Hybrid Casper FFG #1011
Conversation
##### Enable Casper Fork Choice | ||
The ability to enable/disable the Casper Fork Choice. A suggested implementation is `--casper-fork-choice`. | ||
|
||
This setting should ship as default disabled in client versions during the initial casper fork. This setting should ship as default enabled in subsequent client versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation behind this? We'll have the nodes with different fork choice rules active on the net, which seems to increase the probability of the unintentional fork?
Why give the user an option to change consensus rules at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two fork choice rules can only diverge if either 51% of miners or 51% of validators are faulty.
The reason why we need to give clients a choice is to make it easier to revert back to PoW fork choice in case there is any issue with the PoS consensus in the short term.
Opposing this hardfork. this will harm miner's profit. |
Would you like this merged as a draft? |
Yes. Thank you! |
@akx20000a Proof of Stake has been on the roadmap for years now. This should be a surprise to no one. Are you just trolling? |
Since he is core developer of an alternate Ethereum chain, I assume he is trolling. |
Let's talk network security during finality epochs. All other things being equal, using this EIP's block reward reduction to 0.60, network hashrate would be cut some percentage between 0-80, with a skew to the higher side. This range is large as other resource base use economics would be impacted by the move of hashrate, and is thus not easy to model behavior (in the time it takes me to write this post). Let's assume for a second that all 80pct moves from the eth mainnet, and is now working to produce "widgets". The eth mainnet, using current levels as a base, is then operating with approximately 40-50TH of "network security" PoW miners. While this is now only a 50 block window at risk, this is still a large risk, and I'm not sure that this is going to be sufficient to secure the chain. With Bitmain purportedly operating 27TH of E3s, this is a serious centralization risk on the security side. What economic analysis or modeling has been done to target the correct block reward under this hybrid PoS/PoW EIP? |
@Njcrypto this is exactly why we need to solve the ASIC threat BEFORE we roll out POS. We need to be 100% sure that Bitmain or any other ASICs will not cause ETH to become centralized. Bitmain is primarily a BTC company. I am sure they would enjoy nothing better than causing disruption to ETH progress by exploiting any security risk that might arise when POS is implemented. |
@Njcrypto Miners cannot revert finalized blocks, greatly reducing the effect of 51% attacks and censorship. There are also built in client mechanisms to coordinate minority forks in the event of an attack. |
Please take further discussion to djrtwo#5 |
@djrtwo this discussion could be locked by an EIP editor if you prefer. |
@CryptoBlockchainTechnologies I was under the impression that since PoS doesn't require heavy calculations to validate transactions, ASICs wont be necessary. Validators would use their staked pool as what is essentially collateral for validation. In the even they behave well, they are rewarded. In the event they do not, their staked collateral is at risk. Nothing requires heavy computing power to sign valid blocks, so what would the purpose of the ASIC be? Perhaps I misunderstood something, though, so help me out. |
@collincusce You're thinking of Casper CBC, not Casper FFG. |
I think the only logical hybrid proof concept make the "proof of stake" as the quick and first level proof of every transaction and so these PoS block contents are protected by the stakes of the PoS nodes until they're added to the block chain (to commit the PoS blocks they must go with the Valid PoS signature) in a PoW manner. So PoW blocks do not directly include transactions from the Mempool but include only PoSpool which increases/decreases with the number of transactions + consensus rule which will make an optimization of PoS/PoW capacities. |
As the alternative discussion channel requested is not being responded to or viewed, I am going to repost here. Has this block reward reduction been made on an arbitrary basis? What economic modeling or assumptions have gone into this? Why 0.6 versus 0.06 or 2.6? Where should these ideas be discussed without "we can lock this EIP discussion if you prefer"? What is the correct medium? |
Gitter, GitHub issue in this repository (rather than Pull Request), http://ethereum-magicians.org/, http://ethresear.ch/ are all good places to discuss this sort of thing. As to the formula for calculating what the block reward should be, it is really complicated and incredibly hard to calculate. Most (all?) blockchains just pick a really big number and run with it. Somewhere in the past I described what would be required to actually calculate the necessary block reward size given some time-to-finality target (I don't have a link handy) but it turns out that actually figuring out all of the input values for the function is extremely hard. |
* Hybrid Casper FFG EIP * [hybrid-casper-ffg] add EIP version number and rename file * [hybrid-casper-ffg] fix broken sighash link
Nevertheless, despite being a tricky problem, it should be tackled or at least be approximated as best as possible, and the approximation could then be refined over time. |
Hi dear EIP editors, |
Agreed! |
This EIP provides a specification for transitioning Ethereum to a hybrid PoW/PoS consensus model using Casper FFG.
Discussions around EIP: djrtwo#5
Technical discussion around client/testnet development can be found in this gitter channel.