POSDAO Whitepaper feedback and questions

#1

I like the idea of a xDai chain with a possibility to stake tokens. It is definitely a new concept and avoids the problem of a native coin for every chain. I am already looking forward to see if this is an appealing concept for validators.

General: It is not clear to me what the target audience is for the paper. It seems that the problem this chain is solving isn’t that clear, or it could be made clearer in the introduction.
General: The reference implementation starting on page 35 feels like a separate paper and is more of a repetition. IMO it should be split in two papers.
General: In contrast to POA Network, there seems to be no identity at risk for the validators. Is this not at all planned or just not for the POSDAO chain?
MAX_VALIDATORS … what do you expect to be the upper limit?
4.3: “report on malicious validators” … is that done manually by every validator or is there some form of automation?
4.4. It would be interesting to have a description / reference how the selections process for active candidate pools works.
4.5. Does the withdrawal of tokens during an active validator epoch have any effect on the payout at the end of the epoch?
5.1.3. “the larger the candidate’s pool,” … doesn’t this lead directly to a few very large candidate pools?
5.2. Is there no use for the current Governance DApp’s in POA Network?
5.2. Initialization parameters - “Number of Validators” … This gives the impression as if it is set in stone at the start of the network.
6.1.1. “Varying block rates based on network performance” … that is basically clear, but shouldn’t there be a minimum block time and in case of long network latency, it just increases until the sufficient amount of signatures is collected?
6.1.2. I would not call them “elected validators” … it is rather “randomly selected validators” - right?
6.2.2. “validator pool” is not defined and caused quite some misunderstanding for me. Maybe a “validator syndicate”?
6.2.3. How can a delegator find the candidate pools and select one? Is there the intention to measure “pool” reputation and generate some rating?
6.2.4. I didn’t see any mentioning of an additional pool for additional funds filled by inflation and voted upon, like we have now in POA and ARTIS. If the staking token has value, it might be possible to get something into a pool for e.g. development work.
7.5.1. How is an “active” pool defined? I assume you mean “active candidate pool”.
“banned pool” --> “banned candidate pool”.
“Running nodes in the cloud is not recommended (for security reasons)”, what do you mean with that?
7.5.2. “known individuals” - I assume this means that there are Terms of Service, which specify, who is operating the bridge.
7.5.3. “extremely expensive” is kind of unclear. What does this mean?
8.4. How can locked funds, not owned by the bridge operator, be used as collateral for Compound? It is like I use someone else’s house as a collateral for a loan :wink:
9.4. Constants … can they be adjusted through a hard fork / voting or not at all?

Summary: I could imagine that a clear target group should help to get a better directed paper. The implementation part is much clearer for me. The selection of constants for POSDAO xDai chain is not explained, where it is derived from. In comparison to POA it has lost some nice features like the additional pool, the identity part (I understand that is deliberate) and the voting mechanism. More critical for me is that there seems to me a high danger of concentration in a few massive pools.

5 Likes
#2

@tze42 thank you for the questions! I’ll try to answer some of these:

MAX_VALIDATORS … what do you expect to be the upper limit?

We expect to see maximum 19 validators.

4.3: “report on malicious validators” … is that done manually by every validator or is there some form of automation?

This is implemented in Parity as an automated process: https://wiki.parity.io/Validator-Set.html#reporting-contract

Does the withdrawal of tokens during an active validator epoch have any effect on the payout at the end of the epoch?

The withdrawals from active validator pool are not allowed: if a delegator wants to withdraw their funds, they can order withdrawal during the staking epoch and then claim ordered amount on the next staking epochs. When a new staking epoch begins, the staking amounts made during the previous epochs are snapshotted and used for calculating reward during the current staking epoch. So, any changes in the staking amounts during the current staking epoch don’t affect the reward to be distributed during the current staking epoch.

“the larger the candidate’s pool,” … doesn’t this lead directly to a few very large candidate pools?

It can depend on the total amount staked for each of the pools. If the pool is almost empty, it should be more profitable for a delegator to stake on that empty pool instead of choosing filled pool.

We also introduced a limit of pool delegators (this will be outlined in v1.1 of the Paper) for the technical reasons (calculations limits within 5-seconds block).

Is there no use for the current Governance DApp’s in POA Network?

These DApps are made for POA consensus contracts which very differ from the POSDAO ones. We are going to create a separate Staking DApp for our POSDAO contracts.

Initialization parameters - “Number of Validators” … This gives the impression as if it is set in stone at the start of the network.

There defined a number of initial validators who will start the network and work during at least the very first (initial) staking epoch.

“validator pool” is not defined and caused quite some misunderstanding for me. Maybe a “validator syndicate”?

The “pool” word can be related both to “candidate” and “validator”. “validator pool” means “the pool of the candidate which became a validator”.

How can a delegator find the candidate pools and select one? Is there the intention to measure “pool” reputation and generate some rating?

The delegator will see the list of all active pools through the Staking DApp (or by reading the list directly from the smart contract). As for the reputation: the users will see how many times the pool was selected as a validator, how many blocks it skipped and how many times it didn’t reveal their secret (this can be treated as a measurement of honesty to a certain degree).

I didn’t see any mentioning of an additional pool for additional funds filled by inflation and voted upon, like we have now in POA and ARTIS. If the staking token has value, it might be possible to get something into a pool for e.g. development work.

The inflated tokens are supposed to be distributed among the pools of the validators as a reward.

How is an “active” pool defined? I assume you mean “active candidate pool”.

A pool is treated as an active if the address of this pool staked into it at least CANDIDATE_MIN_STAKE tokens. If the candidate withdrew all their funds from their pool, the pool becomes inactive.

“banned pool” --> “banned candidate pool”

Right because if the pool is banned, it is already not a validator, so the banned pool is always candidate’s. The banned pool cannot be elected, though, so it’s not a candidate until the ban period is expired.

“Running nodes in the cloud is not recommended (for security reasons)”, what do you mean with that?

We should have written “unsecured cloud” there.

Constants … can they be adjusted through a hard fork / voting or not at all?

Yes, the values can be changed through deploying a new version of contract’s implementation (we have upgradable contracts with eternal storage). Some of the values can be changed just through calling specified contract functions. These upgrade/config actions can only be performed by the owner which is a MultiSig contract with a voting mechanism.

The selection of constants for POSDAO xDai chain is not explained, where it is derived from.

Yes, we should add in the Paper a few explanations how we got those values. Thanks.

5 Likes
#3

@tze42 Thanks again for your thoughtful comments and questions. As you noticed, we are trying to reach several audiences with this white paper.

We include a general overview of Proof of Stake, the details and rationale for implementing the POSDAO algorithm, and possible attack mitigations to provide an overview for a broad community audience. This community includes individuals who may have a general interest in blockchain, may want to learn about staking their own ERC20 tokens, or are specifically interested in Proof of Stake, xDai, blockchain governance, security or other topics. This is a diverse group, so some concepts may be overly simplified or redundant for readers with more experience.

We also include the reference implementation for a technical audience interested in specific details. These readers could probably skip directly to the reference implementation and understand how the algorithm works without reading the entire paper. We should include this pointer to clarify and help readers more easily find the information they need.

Our aim is to create a single point of reference for the POSDAO algorithm, where all information is available in one place and can be referenced by section. We plan to create additional targeted posts related to sections of the paper and will also create a FAQ that should help different audiences further understand the details and benefits of the algorithm. Hopefully this will improve the usability of the paper for a diverse audience group - we will continue to discuss and appreciate your feedback!

2 Likes
#4

Understood. Is there any other way how the continuous node development will be financed?

#5

I was not aware that something like that exists.

#6

Sounds good. If you direct the interested readers into the right directions, it won’t feel like a repetition if someone already knows that the paper should address several different audiences.

#7

Is there any other way how the continuous node development will be financed?

Sorry, what do you mean by development? If you are asking about technical support of the network, it would be provided by the POA/POSDAO team. If you mean financial expenses of validators to hold their nodes, they are supposed to be covered by the rewards described in the white paper.

#8

Just recently there was a discussion about who finances the node software core development for Ethereum and there are also frequent complaints about the unfair value distribution towards node software core developers.
In Zcash 25% of the block reward was directed towards development to make sure that is out of discussion.
I understand that in POSDAO there is no such scheme implemented and therefore I was asking if there is anything undescribed, where you make sure that core development is financed in a sustainable way.

1 Like
#9

it’s out of the scope of the consensus. From what I know it’s usually:

  • early mining (Bitcoin, Monero) with coin price appreciation
  • premine of coins by the R&D team (almost every protocol)
  • taxation per block per period (ZCash foundation, Beam)
  • EmissionFunds distribution managed by validators (POA, EOS)
  • grants from foundations (Ethereum, Web3 Foundation, Tezos) for protocols built on their ecosystem

Also some non common ways:

  • merge and acquisition by other protocols
  • dilution of liquid tokens authorized by protocol/ or governance
  • corporate sponsorship like in most non-crypto open source projects
2 Likes