Skip to content
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

Merged
merged 5 commits into from Apr 20, 2018
Merged

Hybrid Casper FFG #1011

merged 5 commits into from Apr 20, 2018

Conversation

djrtwo
Copy link
Contributor

@djrtwo djrtwo commented Apr 20, 2018

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.

##### 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.
Copy link
Member

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?

Copy link
Contributor

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.

@ghost
Copy link

ghost commented Apr 20, 2018

Opposing this hardfork. this will harm miner's profit.

@Arachnid
Copy link
Contributor

Would you like this merged as a draft?

@djrtwo
Copy link
Contributor Author

djrtwo commented Apr 20, 2018

Yes. Thank you!

@Arachnid Arachnid merged commit 622e647 into ethereum:master Apr 20, 2018
@ascendantlogic
Copy link

@akx20000a Proof of Stake has been on the roadmap for years now. This should be a surprise to no one. Are you just trolling?

@5chdn
Copy link
Contributor

5chdn commented Apr 20, 2018

Are you just trolling?

Since he is core developer of an alternate Ethereum chain, I assume he is trolling.

@atlanticcrypto
Copy link
Contributor

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?

@CryptoBlockchainTechnologies
Copy link

@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.

@djrtwo
Copy link
Contributor Author

djrtwo commented Apr 20, 2018

@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.

@djrtwo
Copy link
Contributor Author

djrtwo commented Apr 20, 2018

Please take further discussion to djrtwo#5

@jamesray1
Copy link
Contributor

@djrtwo this discussion could be locked by an EIP editor if you prefer.

@collincusce
Copy link

collincusce commented Apr 21, 2018

@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.

@t-nelis
Copy link

t-nelis commented Apr 21, 2018

@collincusce You're thinking of Casper CBC, not Casper FFG.

@zirekm
Copy link

zirekm commented Apr 21, 2018

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.

@atlanticcrypto
Copy link
Contributor

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?

@MicahZoltu
Copy link
Contributor

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.

Arachnid pushed a commit to Arachnid/EIPs that referenced this pull request May 2, 2018
* Hybrid Casper FFG EIP

* [hybrid-casper-ffg] add EIP version number and rename file

* [hybrid-casper-ffg] fix broken sighash link
@jamesray1
Copy link
Contributor

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.

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.

@ChihChengLiang
Copy link

Hi dear EIP editors,
@djrtwo and I just learned that a new EIP state "Abandoned" was introduced last year. This draft is no longer pursued by the original authors and can safely be marked as "Abandoned".
Thank everyone who ever worked on or participated in this draft for your contribution.

@djrtwo
Copy link
Contributor Author

djrtwo commented Mar 3, 2020

Agreed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet