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

Make a list of wit/2 remainders #2470

Closed
aesedepece opened this issue Jun 10, 2024 · 1 comment
Closed

Make a list of wit/2 remainders #2470

aesedepece opened this issue Jun 10, 2024 · 1 comment
Assignees
Labels
2.0 assessment 🧐 Needs preliminary evaluation/study/assessment work discussion 💬 Does not need implementing, only discussing

Comments

@aesedepece
Copy link
Member

I started working on a list of everything that is broken, missing or lacking in the wit/2 branches.

This issue will track the completion and publication of such list, and will host the discussion on where to draw the line between what falls into the first witnet-rust 2.0 release candidate and what's left for subsequent release candidates to be released while already in testnet phase.

@aesedepece aesedepece added discussion 💬 Does not need implementing, only discussing assessment 🧐 Needs preliminary evaluation/study/assessment work 2.0 labels Jun 10, 2024
@aesedepece aesedepece self-assigned this Jun 11, 2024
@drcpu-github
Copy link
Collaborator

drcpu-github commented Jun 12, 2024

Here is a list of items which I think are required for the Witnet 2.0 release:

  • A way to handle data requests which require too many witnesses. This can either be refusing to include such a data request in a block or creating a Tally with an error. The former has as an issue that, technically, these data requests stay in the mempool forever and the requester will never get a response (unless the centralized bridge short-circuits it, but that's not the nicest solution).
  • A way to track active validators. In my opinion this is absolutely required to prevent griefing attacks where an attacker would purposely stake on inactive validator addresses to disrupt superblock consensus. I also think somehow using this active validator set would improve data request processing or even block proposals.
  • An easy way to check the withdrawer associated with a validator for easier staking transaction validation (see 059b6aa).
  • Data request resolving using the staking validators.
  • Incrementing the stake with the block reward and received fees (see 5781fc2).

Ideas for a Witnet 2.1 release:

  • Implement a slashing mechanism for nodes that are not voting on a superblock. Slashing should probably only happen when there is no superblock consensus.
  • Profit sharing between a validator and a designated second address similar to how the current block reward splitting already works. This can be used as a way to enabled delegated staking where the validator operator receives part of the reward from the staker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.0 assessment 🧐 Needs preliminary evaluation/study/assessment work discussion 💬 Does not need implementing, only discussing
Projects
None yet
Development

No branches or pull requests

2 participants