Bitcoin Forum

The article primarily deals with the major problems of the PoS system trying to make it more suitable for the use of cryptocurrency and become the mainstream protocol in the future.

It can be summarized to the following points:
1. Wealth distribution
The distribution of social wealth usually obeys the Pareto’s law as the following curve shows:https://raw.githubusercontent.com/yj1190590/PoAS/master/res/3.0/q_001.png
    If everyone’s wealth grows at the same rate, the distribution will not change. As the green line shows:
https://raw.githubusercontent.com/yj1190590/PoAS/master/res/3.0/q_002.png
    In the field of cryptocurrencies, an overall growth of coins means inflation. Inflation is an incentive for the stakeholders to work. They have to earn more coins by working in order to compensate the wealth reduction caused by the inflation. To approach the ideal curve (the green line) in a PoS system, the ability of earning should depend on the number of coins they already have, or called stakes. It means that for some of the users who don’t have much coins, they also don’t have the ability to compensate the wealth reductions because their work costs are more than the earning. Those users have to choose not to work and then lose their wealth gradually (assume that the total value of the coin is not changed). It is the basic wealth redistribution rule of PoS currencies. As the red line shows:
https://raw.githubusercontent.com/yj1190590/PoAS/master/res/3.0/q_003.png
    As shown above, the users owning less coins than w tend not to participate in the wealth redistribution, and they will be constantly “robbed” by the richer ones. As time goes on, the poorer users will eventually disappear. The lower value w has, the more users will remain.

    Considering the factors influencing the value of w, there will be the following approximate equation

w*R(Inflation Rate)/(R+1) (The wealth reduction) = C(Work cost) - F(Transaction fees acquired by working)  ,
that is : w=(C-F)*(1+1/R)

   So we have three ways to lower the value of w: increase F (Transaction fees), increase R (Inflation rate) or decrease C (Work cost)

   Traditional PoS protocol works as the first way or the second way, which causes serious inflation or high transaction fees.

   Our design works as the third way. We reduce the work cost of stakeholders from working fulltime to logging in once in between 100 hours. That reduces the work time to about one ten-thousandth of before, and the value of w will decrease substantially. In addition, since we have sharply reduced the value of C, we don’t have to increase the inflation rate or the transaction fees to a fairly high level. It makes the wealth distribution model of PoS systems much more acceptable.


2. Double voting and history attack
Stakeholders participate in the wealth redistribution by handing over their stakes to the miners through an accumulating process, which will be introduced later.

   The miner plays the role of working fulltime maintaining the network. The maintenance work includes two parts: generating blocks and voting for branches. I am going to explain the branch voting process here because it is related to the solution of the most serious problems caused by “Nothing at Stake”, starting with the “double voting” problem.

   Briefly speaking, the double voting problem is a strategy for miners to vote on each fork of the chain. But in PoAS systems, the miners cyclically vote for the current main branch and publish to the network as transactions which will be recorded in the next block. We ensure that the total voting information of every branch are recorded in each chain (introduced in section 3.2.2). Thus, each vote will go public before it takes effect. Then through a specific method of counting (introduced in section 3.2.1), we guarantee that each stake will be counted no more than once no matter which part of the branch are counted. Therefore, there will be no space to make multiple votes.

   Another major problem caused by NaS is the “history attacks”: the attacker rebuilds a new branch from a historical block trying to replace the original one. This is caused by the PoS consensus mechanism itself but we considered another aspect of it: the property of “Stake”. Unlike the other competition resources such as electricity, hashpower or storage space, stake is an inner state of the blockchains and therefore the total amount of stake is fixed. As it is introduced above, no multiple voting, we can easily conclude that a branch shouldn’t have any competitor if the stakes voted to it are more than half of the total stakes.
https://raw.githubusercontent.com/yj1190590/PoAS/master/res/3.0/q_004.png
   As it is shown above, the stakes voted to the branch are more than the rest, then the root of this branch (with the red frame) will have no chance to be replaced, or to say, it’s finalized (introduced in section 3.2.1). The finalized block that we call save point limits the history attacks to its descendants, making the attacks much more difficult. There is another factor that helps out with the history attack problem but it will not be explained here (introduced in section 3.3).
   Before now, the NaS problems were solved through some complex and subjective methods, which also needs the users to perform additional operations. As it was discussed before, additional operations usually mean higher work cost, which is not healthy in the long term.

3. Wallet applications
Wallet applications usually don’t participate in the wealth redistribution because they are not involved in the process of mining. But in PoAS, wallet applications play an important role in the process of accumulating stakes which is the first stage of mining. They could profit from the system in different ways. (introduced in section 4.1), besides the wallets accumulate most of the transaction fees (introduced in section 5.1) which is not negligible because of the lower inflation rate. It will encourage the developers to be more active in making better wallet applications and that is a progress of decentralized development. In addition, it could encourage them to create sidechains with the clear profit model, which will be a progress of resolving the scalability problem.

4 Accumulating process
There are two ways of accumulating stakes: active voting and competition with network dispersity. The former one works like the delegated proof of stake: users have to choose the miners they already know about and vote their stakes to them. The latter method works more objectively and needs less operations by user: miners compete with each other using the ability called “Network dispersity”.

   Network dispersity is a concept that reflects how many dispersed units of a group are distributed to the network, which is also the ability to grab random signals on the network. As a honeycomb works: the more workers working out there, the better chance they find a usable flower, a Miner with more online Gatherers has better chance to find and win the vote from a random stakeholder. Because it is based on the network latencies which is inevitable and non-simulatable, network dispersity could be an objective resource for the miners to compete with.

   It doesn’t affect the security or fairness no matter which way we choose to accumulate stakes because most of the stakes are owned by the richest users who will tend to be balanced. (introduced in section 5.2)


full paper:
https://docdro.id/uanMOWk (https://docdro.id/uanMOWk)
or
https://www.keepandshare.com/doc15/19928/researchpaper-3-0-pdf-928k (https://www.keepandshare.com/doc15/19928/researchpaper-3-0-pdf-928k)

Please host this on a non-scammy file sharing site, I cannot download it

modified

This is incorrect. Byzantine Generals is the problem statement for all cryptocurrencies, not a class of crypto currencies itself.


Again, totally incorrect. PoS is one of the hardest consensus designs to get 'right' in the first place.  Moreover, the majority of PoS designs completely lack any form of objectivity and the commission structure of a cryptocurrency is entirely orthogonal to the consensus design.

I'm afraid I stopped reading there.

What does this has to do with Bitcoin? CMIIW should Development & Technical discussion made for Bitcoin-related development only? What I get from OP is that he want to fix PoS, so this should be in Altcoins imo.

Maybe I was wrong, it doesn't matter. Please focus on the main content of the paper other than the opening words. I am not here to debate "PoS or PoW?which one is better" problems.
I'll be preciated if you spend some time to understand the design, thank you.

I am not going to publish any coin in any form. It is just a technique discussion, shouldn't it be post here?

the BFT has nothing to do here. the BFT is about a commander node that initiates a command to other nodes (a miner claims that has solved the difficulty of a block and propagates it to other nodes). when you try to begin the proof model from block level to the transaction level, you need to follow the Chinese General Problem, that each node has its own value/command to propagate to the entire network. read about "PoCo" here in bitcointalk.


I afraid this parameter could fabricate easily. would you please elaborate this mechanism?


while your voting model doesn't fit in opportunity cost context, your model still suffers from N@S. this save point in your proposal just works as same as checksum in bitcoin. checksum doesn't solve anything. for new possible solutions, read about "flash-back-pinning" here in bitcointalk.


would you please give more information about it?

It doesn't work like checksum.

gatherers belongs to the miners competing for those broadcasted signals to win their votes.
That is why wallets should paticipate in the profit distribution.

Sorry I didn't notice this question yesterday.
Network dispersity is a concept that means how much dispersed terminals in the network. Network dispersity reflects the ability to grab informations randomly appearing in the network. Like a honeycomb full of worker  bees, the more bees working out side, the better chance they grab a random flower. it cant be fabricated easily unless you cooperate with the signal senders.
I'm not saying I eliminates NAS, which is impossible . It just resolves the most serious problems caused by NaS.

"Confirms" is votes from the stakeholders. He can vote for anyone he want anyway, but can not vote with the stake belonging to others.
Thank you for the advice! I'll consider about it.

what about the second voting in your proposal? are they protected against sibyl attack?

The first voting is to determine the right to generate the next block.
The second voitng is to determine the main branch from different forks.

About the previous question, maybe I misunderstood you.
The "Confirms" you mentioned should not be "votes" from stakeholders. Sorry about that.
Anyone can provide many confirms to those signals, but he can't fake the fastest confirm to most of them, because the network latency and the physical distance between nodes.

What is the cost of a VPS? If you wanted to dominate voting by having the fastest ping times, wouldn't that be trivially achievable by renting VPSs?

good point. Renting a VPS with several IPs could be harmful.

--------------

I also like to ask another question from our friend: "excluding the ping/latency property of this idea, what are differences with this proof model (PoAS) and Delegated Proof-of-Stake (DPoS) [1]?"


[1] https://blockonomi.com/delegated-proof-of-stake/

Modified for better understanding.

This problem was discussed in section 6(2).
Under some circumstances PoAS works like DPoS. Please read the 4th section of the summary post: https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375 (https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375)

You briefly mention the problem and that 'countermeasures' might need to be deployed, but the key issue is not addressed.

If the key issue you mentioned means the "VPS" problem, maybe you have missed the main idea of the paper or maybe I missguided you by my previous posts, I am sorry for that. Although I have a preference for it because it's objective and seems "elegant" to me, "Network Dispersity" is just one of the abilities to "accumulate stakes". If it fails, the security and fairness will not be affected because:
1.
And the competition of accumulate stakes is still fair and objective.
Even if the accumulating process is subjective, you could consider it as a sort of "public" DPoS protocol in this respect.
2.
It means that the chains will remain strong whether the "network dispersity" works or not, and the motivation of breaking the rules of network dispersity is low because of the negative ROIs.

Please enlighten me, what is the main idea of the paper, because as far as I can tell, the main idea is stake weighting with "Network Dispersity" added on top, which has horrible sybil attack problems?

Stake weighting, not with network dispersity but with accumulated stakes. Sybil attacks are also not so easy and not even valuable for attackers to apply, and it is no big deal if it really happens.
Please at least read the answer I just replied, I don't want to explain the same stuff repeatedly.
The main idea of the paper was introduced here https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375 (https://bitcointalk.org/index.php?topic=5094909.msg49129375#msg49129375).

First of all, thank you for your concern. But you don't have to be offensive because I am not your enemy but a guy who wants to share something and discuss them with someone interested. Maybe I have offended you with some unappropriate words that I didn't noticed, I appologize for that.  Anyway, all questions are welcome.

Cumulative stake weighting for branch selection is a good idea, but only when you cannot move a critical amount of stake around on a block by block basis, otherwise history attacks are still possible. This means you need a limit on the amount of stake you can move over a certain number of blocks*.

The 'network dispersity' thing is just nonsense, though.


*) See our discussion with @shunsaitakahashi on PoA - https://bitcointalk.org/index.php?topic=3913439.0

For the historical attacks that construct new branches, we provide two layers of protection.

One is the save point. Save point is a finalized block which will limit the history attacks to its escendants. It means that the attacker must collect enough stakes after the last save point which may be less than an hour earlier. That seems much harder.

The other one is the branch priority decision strategy:The branches with higher online stakes will definitely be heavier. Therefore, unless the historical stakes that an attacker possesses exceed all the online stakes of the current main branch, it will not succeed.  For example: the total stakes are made up of three equal part A，B and C. If you collect the private keys of part A and B at a history point, that's 2/3 of the total and you plan to build a new fork from the history point and replace the original one. But the owner of stake A and B must have moved their stakes to other accounts, like A', B', before they give the old private keys to you. So the original branch will have the active stakes of A'+B'+C and your branch will have the stakes of A+B. Your branch will never heavier than the original one under my strategy. Besides, your account A and B will become invalid when a new save point is established.

Not if most of the users don't break the rule and choose to paticipate in , which probably will happen because the cost of breaking it (like renting alot of VPSs over the plannet) is higher than the benifits (mining reward which is not so big, or double spending which is nearly impossible).

Yes I have read that before, and the paper, which is nice.
And the original post about the "history attack" of yours, good thinking, by the way.

But what if that is easy?

What if I own old (now empty) private keys containing more stake than the current online stake in the main branch and that is within your re-org limit? Surely I can just construct a new branch from there which will become selected as the best branch?

If the amount of current online stake dwindles due to a network outage, or other force majeure, this doesn't seem to far fetched.

Under the circumstance you described, the history attack could succeed. But if you can't control the time of your attack, what's the point of the attack?
Besides, if there is a chain with the ability of finalization, I will not confirm my transactions untill the final state is established when I am going to make an important deal.

Don't forget about bootstrapping nodes - this attack is also a bootstrap poisoning attack, as well as an attack against already up to date nodes and bootstrapping nodes cannot use your re-org depth limit.

Bootsrap attack may be a common problem of all chains with finalization. Let's talk about the difficulty and the impact of launching a successful history bootsrap-poinsoning attack in our system.

First, you have to find a history point where there are enough empty accounts that had more stakes than the average total online stakes after that history point. Apparently the longer history the point is ,the more available accounts you can get. But the longer history you look back, the less impact the event of force majeure will have, which limits the history length of that point.

Second, whatever an attack aims for, the cost will not allow you to afford so many stakes.
As the example I gave, the users who sold their empty accounts to the attacker are actually risking their assets (if the attacker succeeds ,their current assets A' and B' will become useless.) for a short-term profit which is the cost of the attack. And that risk cost should not be low enough for one to bear.  At least he can't attack constantly, that makes the influence  of the bootstrap poisoning attack limited (maybe a fork with a few victims, which won't last long).

That isn't true for bootstrap poisoning - as far as any bootstrapping node knows, there is no history available *after* their currently syncing block. A bootstrapping node will accept any valid data as canon, whereas an online node would be able to discard old forks because it has a memory of the real chain.

Moreover, I would say bootstrap poisoning is a problem for all coins which have the NaS problem. 'Finalization' is not a well defined term.


The users who sold their now empty private keys to the attacker risk nothing. They have long since profited by cashing out.

The difference between an online node and bootstraping node only exists in finalized systems. Otherwise both types of nodes will compare all existing branches obtaining same results. That's why I said the  bootstrap poisoning attack is caused by finalizatin and the history attacks are caused by NaS.
True, I was wrong about that. But there exist many objective methods that can tell the differences between the original chain and the fake one. Such as "the active account with 20% stakes never active anymore since..." or something like that. The new notes should analysis the packages they received, which is troublesome but not too hard.  Even if you manage to fetch the total accounts with 100% stakes and fake a perfect chain, which shouldn't usually happen, there still exist some subjective methods that can distinguish them. I think the influence of a successful bootsrap-poinsoning attack is acceptable.

I don't think so. 'Active since' doesn't make sense because when the attacker buys the private keys, he forks from the point where they were active and produces a fake chain with this now active stake participating. The only thing preventing this attack from succeeding is online nodes being relied upon to keep their existing fork and reject the attackers fork. But this is subjective, not objective.

I mean the 20% active accounts he didn't buy. He can't fake them as active.

You can't build a selection rule based on inactive stake. The canon chain may have a whole load of inactive stake during genuine quiet periods, you don't want to select against it during these times, because that's another attack angle.

20% active stakes suddenly become quiet at the same time and never active again, that's unusual. Why can't it trigger any alert when we are analysising?

That was an example, what I want to say is : you can't easily fake a perfect chain that can't be recognized when we compare it with the real one.

I'm saying the opposite - you can easily fake a chain by doing this. Give me one objective way of distinguishing between a history attacked chain and the real one.

"A certain proportion of active stakes suddenly become never active for a certain period of time." as I said. Isn't that objective?

Yes, but it doesn't work. That could easily happen on the canon chain during quiet periods. Or, your attacker can pay large portions of previously active stake to go quiet, then wait some amount of time and launch his attack when he knows your selection rule will favour his fork.

How does that work? Bribling?

How long does the quiet periods usually last? If I find out that the chain I accepted have some proportion of stakes suddenly disapear for two days, I'll check it again. Late, but still objective.

More importantly, in PoAS, miners are working fulltime with accumulated stakes. If you don't want the real miners suddenly stop working , which is too obvious, you have to buy the accounts of those working miners. I can't figure out how to purchase that yet.

Yes.


It cannot work. Whatever rule you come up with related to inactive stake, you can easily replicate either through bribing, or just might happen by accident.

In addition, the attackers could easily be miners as well.

You cannot cobble together a chain selection rule + some other bizarre ad-hoc rule for detecting history attacks; they have to be one and the same rule, otherwise this will just be to easy to exploit due to complexity.

Remember that between two chains, the suspecious part only appears at the forked place where we need to focus on. That means you have to limit the history point to the part where the main chain fluctuates. You can't control the history point so easily, can you?

Being a miner is not enough. He has to buy as many active miners' accounts as possible. The purpose of mentioning the miners was to explain that there should not be too many quiet periods because the voting cycle of miniers is about an hour.  (In case you didn't read through the paper, the voting cycle of the stakeholders is about 100 hours, so that the meaning of "active" in our system is an actual cyclically-publishing activity, which is different than the common sense of the meaning of "active" .)

And the miners are a group of people who are continuously benifiting from the system, not like the long since cashing out stakeholders. They should not be so easy to buy over.

Let me sum up the content we discussed:
The attacker has to:
1. Find a time point where a certain proportion (e.g. 20%) stakes and miners suddenly silent at the same time for a long period or brib enough users to do so.
2. Collect as many accounts as possible of the miners (in this case >80%) that were active at the time point above.
3. Collect enough accounts with more stakes than the average total online stakes (in this case >80%).
or
Collect accounts owning more than a certain proportion (e.g. 95%) stakes at a time point and 95% active miners' accounts at the same time point.
Then he could launch a successful bootstrap poisoning attack. I must say both of them are remarkable achievements.

The bootstraping nodes have to:
Check the forked place between two different branches and analysis if there are more than a certain proportion (in this case >5%) unusual "suddenly inactive" stakes and miners and mark the suspicous chain.

As discribed above,  a successful bootstrap poisoning attack shouldn't be very frequent, or to say unusual.
Bootstraping nodes don't need to do anything bizarre or too complex. All of those anayasis are objective but if they want to do it carfully they should pay some attention to the subjective information. This degree of subjectiveness should be acceptable for any practical objective systems. After all, even bitcoin has "subjective" fork announcements.

And what is the chain selection rule for non-bootstrapping nodes? Same? Different?

Different. With finalization, without the check above.

What about the cumulative stake rule, how does that combine?

That rule should still work if there are no suspicious chains. With a very small probabitlity, the bootsraping notes will be attacked and become the victim of a fake fork, unless they concern about fork announcements or something like that.

I'm trying to minimize the major defects of PoS including the harm of NaS, theoritically or pratically.
As I've said before:
PoS consensus mechanism is the closest protocol to replace the classic proof of work which is, seems to me, dying.  I'll be sad if there is no protocol strong enough to do that.

Reorganized the sentences and paragraphs of the English version trying to make them express more accuratly.
Think it should be reposted.