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

Protocol + Feature Control #29

Open
5-mark opened this issue Mar 23, 2022 · 4 comments
Open

Protocol + Feature Control #29

5-mark opened this issue Mar 23, 2022 · 4 comments
Assignees
Labels
Chain Story User Story

Comments

@5-mark
Copy link
Contributor

5-mark commented Mar 23, 2022

User Story

As GameDAO Council I want to be able to control availability of protocol features:

  • enable / disable protocol features via council vote
  • emergency stop and restart
  • immediate or blocktime based

Acceptance Criteria

Each major milestone contains different features, but the public availability may be phased in or out at different points in time or even may or may not be available on network a,b,c.

As launch support, we want to create a smooth transition from initial deployment to fully functional protocol suite. To achieve this, we want to enable features after periods, e.g.:

  1. Tokensale
  2. Token Generation
  3. Protocol Core Launch
  4. DID, DAO
  5. Staking
  6. Voting
  7. Grants
  8. Fundraising

Additional Information

Discussion:

How to test

  1. create a voting to enable feature x on block y
  2. see x enabled on chain at destination block y

to be specified:

  • expose state via graphql
@5-mark 5-mark self-assigned this Mar 23, 2022
@5-mark 5-mark added Story User Story Chain labels Mar 23, 2022
@2075 2075 changed the title Config Pallet to switch on and off features Feature Control Mar 25, 2022
@2075 2075 changed the title Feature Control Protocol + Feature Control Mar 25, 2022
@vayesy
Copy link
Contributor

vayesy commented Apr 1, 2022

@5-mark assuming some extrinsic is disabled.
There are two options how it can be blocked from execution.

  1. Extrinsic is not listed in available endpoints and not possible to be called. This is similar to when extrinsic doesn't exist.
  2. Extrinsic exists but returns error upon execution.

Could you please specify which one is expected as a result of disabling any extrinsic?

@2075
Copy link
Member

2075 commented Apr 1, 2022

I would see something the way ensure_signed works, like ensure_enabled where it checks if the extrinsic is e.g. whitelisted/signed/root.

to make things simpler, we could/should also enable on pallet level.

what do you think?

@vayesy
Copy link
Contributor

vayesy commented Apr 1, 2022

Yes, that's the simplest approach I could think of.

In general I see this feature the next way.

  1. New pallet to control availability of other pallets/extrinsics.
    This pallet will expose few helper methods for other pallets to validate if those pallets and extrinsics are available.
    It will also provide API (extrinsics with root only access or outcome of a vote?) to mark specific pallet/extrinsic as enabled/disabled and store that value in storage.
  2. Invoke helper methods in the extrinsics to validate for access, based on storage value and raise an error in case if needed.
    In case access is granted, proceed with pallet/extrinsic specific logic.

@5-mark 5-mark added the BR-present to be presented to team label May 27, 2022
@5-mark 5-mark removed the BR-present to be presented to team label Aug 18, 2022
@vovacha
Copy link
Contributor

vovacha commented Oct 26, 2022

Moved: playzero/zero-network#185

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

No branches or pull requests

4 participants