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

EPoSe Movement #3 - EPoS implementation #154

Open
Xecute0101 opened this issue Mar 9, 2021 · 1 comment
Open

EPoSe Movement #3 - EPoS implementation #154

Xecute0101 opened this issue Mar 9, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@Xecute0101
Copy link
Contributor

Xecute0101 commented Mar 9, 2021

As a succession of EPoW, QWC will be implementing EPoS consensus along with EPoW finalizing the first chapter of EPoSe.

EPoS development will include major updates and features for nodes and wallets and again as a pioneer of new norm in crypto, these codes will be QWC original.

Also parameters such as mining difficulties and block time of 120 seconds will become much more flexible to make our chain adaptive.

The uptime without staking nodes will also be able to participate in the network as promised.

Another managing software for blockchain and software will be deployed to keep all the network up to date.

An exciting development challenge waits ahead. Join us.

@nnian nnian added the enhancement New feature or request label Mar 9, 2021
@Xecute0101
Copy link
Contributor Author

Xecute0101 commented Mar 19, 2021

Stage 1. EPoS (Egalitarian Proof of Stake) Design and Implementation

  • This is a preliminary step before completing EPoSe (Egalitarian Proof of Service).

  • Here we define following terms:

a. Full Staking Nodes - nodes nominated from single staking transaction or a group of staking transactions, while holding entire blockchain data. These nodes generate blocks and can process all txs that require ring signature validations below connected GRB nodes' height. When wallet requires a full scan, Full Staking Nodes are used. When a block is issued by one of the staking nodes, a major portion of block reward is sent to the nominating wallet address(es). These nodes cannot receive transaction fees.

b. GRB (Genesis Reference Block) Nodes - nodes that only holds a portion of the blockchain from a specific height running up to the most recent block without staking. These nodes validates blocks generated by Full Staking Nodes and process txs that only requires ring signature validation above GRB height. GRB nodes will receive evenly distributed block rewards from the remainder from (block reward schedule - Full Staking Node reward).

c. Block Producer - One of Full Staking Nodes group that issues blocks.

d. Block Validator - Blocks are validated by the rest of Full Staking Nodes and the entire GRB nodes.

e. Future Blocks / Transactions - This is a feature that is required for staking reward distributions. Mining reward has been issued immediately with a confirmation buffer of 10 blocks.

This has been wallet-side safety measure under PoW/EPoW development. We will enforce that the spent transactions are not included in the recent 10 blocks from nodes.

When a node is nominated by one or multiple staking transactions, the staking amount of coin with particular spent key(s) cannot be spent until the block height reaches the maturity period of staking.

To make this work, all staking transactions will be locked by issuing a future transaction in a future block. This block cannot be modified or altered and the staking will be released at its maturity. To reduce block size thereby to reduce transaction size, all staking transactions will be processed after performing consolidation function implemented from Block version 6.0

Internode Consensus level will have to be 100%.

Since many people have issues with node synchronizations, a node will only be recognized as a fully function node based on its current version continuous uptime, the number of incoming/outgoing inter-node connections and other various assessments.

We will also move away from checkpoints but after PoS implementation, because it will not be necessary all blocks will be 100% forged without a fork.

The next phase is EPoSe (Egalitarian Proof of Service) Design and Implementation, which involves creating a hybrid environment between EPoW/EPoS. However, we will reevaluate future developments after EPoS implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants