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

Conversation

Projects
None yet
@djrtwo
Contributor

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.

djrtwo added some commits Apr 18, 2018

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

This comment has been minimized.

@gumb0

gumb0 Apr 20, 2018

Member

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?

This comment has been minimized.

@vbuterin

vbuterin Apr 20, 2018

Collaborator

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

This comment has been minimized.

ghost commented Apr 20, 2018

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

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Apr 20, 2018

Would you like this merged as a draft?

@djrtwo

This comment has been minimized.

Contributor

djrtwo commented Apr 20, 2018

Yes. Thank you!

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

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@ascendantlogic

This comment has been minimized.

ascendantlogic commented Apr 20, 2018

@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

This comment has been minimized.

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

This comment has been minimized.

Contributor

atlanticcrypto commented Apr 20, 2018

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

This comment has been minimized.

CryptoBlockchainTechnologies commented Apr 20, 2018

@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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

djrtwo commented Apr 20, 2018

Please take further discussion to djrtwo#5

@jamesray1

This comment has been minimized.

Contributor

jamesray1 commented Apr 21, 2018

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

@collincusce

This comment has been minimized.

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

This comment has been minimized.

t-nelis commented Apr 21, 2018

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

@zirekm

This comment has been minimized.

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

This comment has been minimized.

Contributor

atlanticcrypto commented Apr 23, 2018

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

This comment has been minimized.

Contributor

MicahZoltu commented Apr 23, 2018

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 added a commit to Arachnid/EIPs that referenced this pull request May 2, 2018

Hybrid Casper FFG (ethereum#1011)
* Hybrid Casper FFG EIP

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

* [hybrid-casper-ffg] fix broken sighash link

johnhforrest added a commit to codex-protocol/EIPs that referenced this pull request Jul 10, 2018

Hybrid Casper FFG (ethereum#1011)
* Hybrid Casper FFG EIP

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

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

This comment has been minimized.

Contributor

jamesray1 commented Aug 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment