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

Upgradability #1994

Closed
MaksymZavershynskyi opened this issue Jan 21, 2020 · 5 comments
Closed

Upgradability #1994

MaksymZavershynskyi opened this issue Jan 21, 2020 · 5 comments
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc) C-epic Category: an epic

Comments

@MaksymZavershynskyi
Copy link
Contributor

Nearcore node should support being upgraded, this includes:

  • Discussion on how we want upgradability to work:
    • Do we want the node to be upgraded automatically or manually by the user?
    • Who determines the output?
    • In what cases the upgrade needs to be backward compatible?
    • etc.
  • Design and implementation of config upgradability;
  • Design and implementation of binary upgradability.
@MaksymZavershynskyi MaksymZavershynskyi added A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc) C-epic Category: an epic labels Jan 21, 2020
@behaviary
Copy link
Contributor

behaviary commented Feb 3, 2020

Nearcore node should support being upgraded, this includes:

  • Discussion on how we want upgradability to work:

    • Do we want the node to be upgraded automatically or manually by the user?
    • Who determines the output?
    • In what cases the upgrade needs to be backward compatible?
    • etc.
  • Design and implementation of config upgradability;

  • Design and implementation of binary upgradability.

Wanted to port last bullet point of this issue: #1951

  • “Create incentive for nodes to upgrade efficiently/quickly

Good actors with bad node hygiene will damage the health of the network. We need to create incentives for upgrading quickly (this is not relevant if we choose automatic upgrades). Likewise we may need to punish people with out of date nodes.

@lexfrl
Copy link
Contributor

lexfrl commented Feb 13, 2020

Likewise we may need to punish people with out of date nodes.

Note: It's not relevant to the upgradability itself. It's related to the consensus algorithm.
If majority of nodes are following the protocol it means they will be updated. It turns out that the remaining nodes will not follow protocol and fork - and thus will be punished by the consensus.

@ilblackdragon ilblackdragon added this to the MainNet milestone Mar 18, 2020
@ilblackdragon
Copy link
Member

Large discussion on upgradability have happened here - https://commonwealth.im/near/proposal/discussion/261-upgradability

@stale
Copy link

stale bot commented Jul 1, 2021

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

@stale stale bot added the S-stale label Jul 1, 2021
@bowenwang1996
Copy link
Collaborator

Protocol upgradability is implemented. See https://nomicon.io/ChainSpec/Upgradability.html for details

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-transaction-runtime Area: transaction runtime (transaction and receipts processing, state transition, etc) C-epic Category: an epic
Projects
None yet
Development

No branches or pull requests

5 participants