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

Improved Mechanism for ETH 2.0 Staking #2794

Merged
merged 28 commits into from
Jul 22, 2020
Merged

Conversation

zhous
Copy link
Contributor

@zhous zhous commented Jul 17, 2020

We really need your support. Yes, it's a big thing. :)

@MicahZoltu
Copy link
Contributor

This PR appears to be for saving SVG images for contracts, but the title of this PR is "Improved Mechanism for ETH 2.0 Staking". Was there perhaps a mistake? Also, I think I just reviewed a very similar PR for SVG images a few minutes ago, is there a reason this is being opened again as a separate PR?

@zemse
Copy link
Contributor

zemse commented Jul 17, 2020

I see there are two files in here. May be the previous PR's files from the fork's master are carried forward in here. @zhous you can create a separate branch for the new EIP so that your other pending EIPs doesn't get included.

Add links to the discussions.
EIPS/eip-2794.md Outdated
We propose a new staking protocol with an honor system to replace ETH 2.0's staking mechanism in which a node must stake 32 ETHs to be a validator and thus expose ETH 2.0 to extremely high risks. This proposal will bring strong and reliable security to ETH 2.0's staking.

## Motivation (Risk Analysis)
According to the latest released specifications of ETH 2.0, phase 0 needs to be activated by at least 16,384 nodes and this will lock at least 524288 ETHs till phase 1. In additon Ethereum's outshining potentials and future will undoubtedly attract more people to do this staking and cause more ETHs to be locked. Furthermore the ***ETH 2.0 Economics*** section in the official document "Ethereum Roadmap" discusses Staking Rewards from one million validators to 0ne hundred million and if this comes true a large amount of ETHs will be locked. All these factors will very likely drive ETH's price dramatically up.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0ne should be one

EIPS/eip-2794.md Outdated
Comment on lines 87 to 94
## Conclusion
Our proposal presents a solution for mass exit of validators and eliminates two consequences that will cause devastating damages to ETH 2.0.
- Active validators are tempted to exit and sell staked ETHs due to ETH's price hikes.
- Active validators will get rewards when they perform an exit. Their rewards will not be associated with ETH's price hikes. Thus validators will not be tempted to speculate on ETH and will not be tempted to perform an exit for this speculation.
ETH's price hikes will not affect the real cost (the number of ETHs) for potential validators. ETH's price will not be positively associated with the cost of staking. In the long term a validator's income will increase and more people will likely join staking but the number of ETHs needed for staking for a validator will decrease. As more validators serve in the system the aforementioned extreme scenario will less likely happen.
This proposal motivates more people to be validators and enhances validators' loyalty(work and behave properly) by rewarding validators with honor tokens. These honor tokens (including their logo images) will be permanently saved on Ethereum. This is the first ever proposal to reward Ethereum's contributors with honor and will greatly incentivize validators.

All in all, this proposal provides a solution for security and safety of ETH 2 Staking.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document doesn't fully follow the format of the Template. Can you please update it to match the template, including all necessary sections (like the copyright, the security section, specification, etc.)?

Copy link
Contributor Author

@zhous zhous Jul 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working with my partner but we're busy. We just need time to finish it. It's good to tell people in advance that there's a potential risk and also there's a better solution described. I mean at least we have already described the important part of this solution first.

@zhous
Copy link
Contributor Author

zhous commented Jul 20, 2020

This PR appears to be for saving SVG images for contracts, but the title of this PR is "Improved Mechanism for ETH 2.0 Staking". Was there perhaps a mistake? Also, I think I just reviewed a very similar PR for SVG images a few minutes ago, is there a reason this is being opened again as a separate PR?

Actually there're two EIP mixed. I just don't know why I pulled a request based on a new EIP but it worked like this.

zhous added 3 commits July 20, 2020 18:41
Fixed some typing errors.
Added an important part.
Fixed one typing error.
@MicahZoltu
Copy link
Contributor

MicahZoltu commented Jul 21, 2020

Please split this into two separate PRs that can be reviewed and merged separately. Actually, at a glance it appears that this is still meant to be an ETH staking PR yet it still has the SVG stuff in it. You will need to create a separate branch for the SVG stuff and the staking stuff, then change this PR to point at the staking branch.

zhous added 3 commits July 21, 2020 11:27
Changed the link for discussion
A little bit lost! One EIP one branch??
@eip-automerger
Copy link

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

  • Contains new file EIPS/eip-2794.md

EIPS/eip-2569.md Outdated
[Image Storage Solution Based on Ethereum Sharding](https://www.deme.app/full#12)
[Image Storage Solution Based on Ethereum Sharding,2019](https://naturaldao.io/en/collaboration/blog/65-storage-shading.html)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Submit these as a separate PR and this will auto-merge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Submit these as a separate PR and this will auto-merge.

I'm sorry but I really don't know how to make them separate.
Does it mean I have to fork ethereum:master again, create a new branch and submit another EIP (let's say EIP-xxxx) for the ETH staking proposal, and then delete the file eip-2794.md in the old repository?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on how you are going about this. What you want is one fork of the ethereum repository with two branches on it, both of which build off of ethereum/master. One of the branches would contain one of the change sets and the other would contain the other change set. How you get there from here depends on what tool you are using.

Once you have the two change sets on different branches, you would then create one or more GitHub Pull Requests (or update your existing ones) so that each is a pull request of a different branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always do this on my PC's browser. So now I'd like to keep EIP-2569 with no change. How can I move EIP-2794 into a new branch and keep the same number?
Thanks indeed!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The easiest way to resolve the issue using the GitHub UI would be to navigate to https://github.com/ethereum/EIPs/tree/master/EIPS and click at the top to create a new file. Name it eip-2794.md and copy the latest version of it into that file. Commit and create pull request on the following screen.

Then go to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2569.md and click the edit icon on top of the file and make remake the changes you made to EIP-2569. At the bottom of the page when you commit, make sure to tell it to create a new branch!. Proceed to create a pull request on the following screen.

Copy link
Contributor Author

@zhous zhous Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then go to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2569.md and click the edit icon on top of the file and make remake the changes you made to EIP-2569. At the bottom of the page when you commit, make sure to tell it to create a new branch!. Proceed to create a pull request on the following screen.

There's no such a selection and it automatically created a new branch. After it's done, I created a pull request.
Now I'm here: #2815. And it says:
You’re all set—the zhous:patch-3 branch can be safely deleted.
Can I really delete the branch now?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, you still have two files in this EIP, so it would appear that you didn't include all of your changes in the previous one. Just repeat that same process for the changes to eip-2569.md that are present here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dear Sir, I have made them one in branch "https://github.com/zhous/EIPs/tree/patch-5/EIPS"(eip-2569.md), and another one in branch "https://github.com/zhous/EIPs/tree/patch-4/EIPS"(eip-2794.md). Now I'm totally lost...

@zhous
Copy link
Contributor Author

zhous commented Jul 21, 2020

Please split this into two separate PRs that can be reviewed and merged separately. Actually, at a glance it appears that this is still meant to be an ETH staking PR yet it still has the SVG stuff in it. You will need to create a separate branch for the SVG stuff and the staking stuff, then change this PR to point at the staking branch.

OK, I'm trying to make this PR to a new branch.

Made changes suggested by Collaborators
EIPS/eip-2569.md Outdated

By calling our proposed interfaces we assume users are accessing an SVG image.
An EIP-2569 compatible contract MUST have a method with the signature getTokenImageSvg(uint256) view returns (string memory) and a method with the signature setTokenImageSvg(uint256 tokenId, string memory imagesvg) internal.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setTokenImageSvg(uint256 tokenId, string memory imagesvg) internal

Internal functions aren't generally part of a standard. Only publicly visible functions and functionality should ever be standardized.

Updated the whole proposal based on EIP-1's definitions
@ethereum ethereum deleted a comment Jul 21, 2020
@ethereum ethereum deleted a comment Jul 21, 2020
@eip-automerger eip-automerger merged commit 0cb0e9e into ethereum:master Jul 22, 2020
tkstanczak pushed a commit to tkstanczak/EIPs that referenced this pull request Nov 7, 2020
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
Arachnid pushed a commit to Arachnid/EIPs that referenced this pull request Mar 6, 2021
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
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.

5 participants