(It is NOT an Altcoin introduction, please don’t move it to the other sections.)

This is a major algorithm of a chain-based proof-of-stake consensus protocol using the process of cyclical voting. It applies a finalization period in about one round of voting with a relatively simple mechanism. I think it might be considered in optional schemes as a supplementary in the future. The following is a brief introduction of it and there is the link of the full paper at the bottom of this post, if someone is interested.

Consensus processes
Consensus processes are divided into the following steps:
(1) Vote generation: Stakeholders generate votes using the probability based on the stakes held, gain the qualification for voting, and become miners to build blocks.

(2) Competition for building blocks: Miners generate blocks and gain awards using the probability based on the generated number of votes.

(3) Confirmation of canonical chain: Miners vote on blocks in cycles, and the branch winning the most votes is recognized as the canonical chain.

(4) Block finalization: When the count result meets certain conditions, this result cannot be changed under a given assumption (2/3 of the nodes are honest). Then, the situation is called block finalization, the branch finalized is the final canonical chain, and the data in finalized blocks are the final data.

Votes Generation
Stakeholders perform operations on random numbers from the current constants (block hash, timestamp, etc.) and compare them with the number of their stakes to meet a condition, in which the demander qualifies for voting. This condition is denoted as

VRF_VoteProof < Account_stakes,

where Account_stakes refer to the stakes of the account. The higher the number of stakes, the higher the possibility to meet this condition, generating votes according to stakes. The stakeholder who qualifies for voting generates a vote and publishes it on the network to be registered as a miner (or voter). The registration record is packed into the block as the transaction record.

Introducing qualification for voting decreases and flexibly controls the number of validators so that different projects strike a balance between safety and response speed.

Competition and generation of blocks
Stakeholders participate in the building and maintenance of the blockchain after becoming miners. To gain awards, miners would have to compete with each other for the right to build blocks:

(1) A random number operation is conducted based on constants (such as timestamp and block hash) by miners. When the expected results reach a certain target and meet the requirements to generate blocks, it is denoted as

Block_Proof < target * votes * efficiency,

where target refers to difficulty, which controls the speed of block generation; votes refers to the votes owned by miners and is directly proportional to the possibility of block generation; and efficiency refers to the efficiency of block generation, which is affected by various factors and introduced in the paper.

(2) When the requirements for block generation are met, the miner will pack the voting records along with the transactions that he received into a block and will publish them on the network.

Confirmation of canonical chain
Starting with the Genesis block, miners in cycles (e.g., “10 blocks” or “120 s”) select a branch from the previous canonical chain, sign the address of the top block, and publish the result on the network, which is called the voting. Voting records are packed into the block like transactions. The process of confirming the current canonical chain compares the priority of branches from the voting records and determines the branch (also a chain) with the highest priority.

Priority of branches
The weight of a branch is the number of total votes gained by the root and all its descendants. From this calculation method, the comparison of two chains in priority begins from their common ancestors and the weight of the respective branches they belong to be calculated. The heavier one takes priority. To find the canonical chain, we should compare the existing competitive branches one by one and find the chain with the highest priority (as shown in Fig. 1 ).



Block finalization
The finalization process of chain-based protocols, different from BFT protocols, does not need multiple rounds of voting to keep the strictly synchronized state among nodes. When the first round of voting reaches a consensus, we only need to determine that this consensus is a supermajority decision rather than identifying whether all nodes have received the results. Therefore, finalization can be completed in one round of voting in an ideal condition. However, to guarantee that the finalized chains do not conflict (i.e., safety) and voters have opportunities to amend their votes to avoid situations where the chain cannot be finalized forever (i.e., liveness), the situation becomes complex, requiring new voting rules and resulting in delayed finalization.

New voting rules
From the mechanism of cycle voting, when dishonest users do not exceed 1/3, we determine that provided one branch wins more than 2/3 of total votes during one cycle, this branch should not have competitors and could be finalized. However, to guarantee that all finalized branches do not conflict with each other, we need a continuous finalization link starting from the Genesis block. This also requires that the votes are consistent. Thus, we modify the voting rule by adding the following rules on the first voting rule:

(1) The interval between the target blocks of two votes taken by a miner is larger than or equal to one voting cycle; otherwise, the miner will be punished.

The additional rules are:
(2) Each vote requires a backward connection to the voter’s previous vote called the “source.” The votes without connection to the source are called “sourceless votes” that do not weigh anything as the amendment to wrong votes. However, it can serve as the source of later votes.

(3) The Genesis block is the first finalized block and can be used as the source of later votes without violating other rules.

(4) Votes whose source is located at the finalized block are called “rooted votes.” Only rooted votes have weight, thus progressively producing subsequent finalized blocks. Meanwhile, the ancestor blocks of the finalized block are also regarded as finalized. The “rooted votes” can be transmitted forward. The details mentioned here are presented in Fig. 3 and Fig. 4.
*(Transmission means that if c is a rooted vote, the vote connecting c as a source is also rooted.)



Safety and liveness
The principle to guarantee safety is simple: the voter only connects each vote to the next one, and thus, votes are unkept as an end-to-end link (as shown in Fig. 3) if there exist conflicting votes, so his voting link will not have conflict. Now that the voting links of single voters do not have conflicts, the finalization points generated based on the continuous voting links will not conflict either, thus guaranteeing safety (as shown in Fig. 5 ).



However, this cannot meet the requirements for liveness because it is very likely that more than 1/3 of votes will be taken on wrong branches after a fork appears. Once such a case appears, the finalization link breaks without recovery. Therefore, to keep liveness, first, become aware of such case—we call it “key fork”; then, we allow the sources of the next votes to move back to the fork position from the current targets. This provides a hesitation space to the voters and allows them to correct their previous decisions and return to the canonical chain (as shown in Fig. 6 ). Lastly, we delay the finalization point to the fork position.



Awareness and positioning of the key fork
To become aware of the key fork, we adjust some finalization conditions. The previous condition in which “more than 2/3 of the total votes be gained during one voting cycle” is replaced with “more than 2/3 of the total votes be gained during one voting cycle and the distance between the targets and the sources of those votes is less than two cycles.” Therefore, only the branch selected by continuous votes (their intervals are not more than two cycles) can be finalized. This condition concentrates the sources of all votes that can reach finalization in the range of two cycles before the finalization point (as shown in Fig. 7 ). This way, we need only to inspect whether there are sufficient votes in this range.



When a key fork is detected, we find the fork point and the corresponding hesitation period using a backtracking algorithm.
When block a at height h is generated, we use a natural number n to represent the temporary “hesitation period” at the position of a, and the block at a height of h − n is called the temporary “retracement point,” which is generally equal to the fork point. The value of n is based on the following calculation results:
(i) If the votes gained by the chain within two voting cycles before a (including) exceed 2/3 of the total votes, n = 0.
   *(For the same voter, only the final vote is calculated.)

(ii) If the abovementioned votes are less than or equal to 2/3 of the total votes, all votes with the target at a height of h are traced back to a height of h − 1 and traced back to h − 2 with those votes whose target are at a height of h − 1. By parity of reasoning, when traced back to h − i, if the condition in Clause (i) is satisfied, n = i.

(iii) The height of the temporary retracement points at Position a cannot be lower than that of the actual retracement point at the position two cycles before a.

(iv) The actual retracement point at Position a is taken from the earliest temporary retracement point during two cycles after Position a (including), and the actual hesitation period N also results from this.
*(Therefore, in the worst case, a block has to wait for two cycles after it is generated until it can be finalized. However, provided that one chain after this block gains 2/3 of the votes during those two cycles, there will be no retracement point earlier than this block, and we can get the actual retracement point right then so that it can be finalized immediately.)

Voting retracement and delayed finalization
After the hesitation period is gained, the voting retracement and block finalization processes are shown as follows:

(1) Each vote of a miner only uses the block of his previous vote target or the block that traces back within N steps (including) from it as the source. N value is taken from the actual hesitation period at the height of the miner’s previous voting target in the related chain, and miners who violate this rule will be punished (as shown in Fig. 8 ).

(2) Count from the root, when a branch obtains more than 2/3 of the total votes in one voting cycle and the distances between the sources and targets of those votes are less than two voting cycles, the finalization condition is satisfied. However, the finalized block is not the branch’s root b but the actual retracement point B at Position b (as shown in Fig. 9 ).



By this method, generally (in an ideal case), all N values are zero. We can complete the finalization around the 2/3 voting cycle after the block is generated. Some forks with serious divergences can extend the length of several cycles; however, the average finalization time should be far less than two cycles. With poor network situation or votes being scattered because of attacks, we can become aware of the fork in advance and delay the finalization, relax the requirements for voting, and improve the fault tolerance of the system to prevent hostile attacks of swinging to extend the depths of a fork from causing the loss of liveness.

Conclusions
The above sections describe the primary algorithm of this protocol. Because it was designed using the chain consensus and PoS, the algorithm inherited some of their advantages, such as the low energy consumption of PoS, high fault tolerance of chain consensus for the network environment, more validators, and more loose requirements for them. While guaranteeing safety and activity, the algorithm provides the finalization ability with a delay of less than one voting cycle.

Here is the full paper and you could see it for more detail: https://github.com/yj1190590/Consensus/

我去年在中文区发过一个共识协议的设计文档，之后忙了一段别的事情，但是一直都在做相关的改进。
现在这个版本我感觉已经比较完善了，但是发在英文区技术板块之后被移到了山寨币板块，很快被淹没了，所以我又回中文区来试试，看看有没有人感兴趣。
我先谈一下主要设计思路，以免设计文档过于枯燥没人看下去：

我们先看看一个争议很大的问题，“PoS 还是 PoW？”
我先明确我的看法，我认为将来PoS必然要代替PoW。PoW的支持者现在最主要的依据就是它消耗了成本，所以就比较安全。但实际上消耗成本与安全性之间并没有因果关系，我们只要解决好PoS存在的一系列技术上的问题（主要是多重投票和历史攻击的问题），安全性不应该比PoW更低。即使不谈能源消耗的问题，我们从技术本身来看，PoW中的"工作量"用了一种不可控制的外部资源，用不可控制的外部资源来竞争很可能形成大规模的合作行为，影响到系统安全（参考https://vitalik.ca/general/2019/04/03/collusion.html的讨论），“矿池”就是一个例子；而PoS使用的是区块链内部资源进行竞争，首先总量上不变，这会有巨大的好处，我们后面会谈，其次“权益”是账户的基本属性，人们不会大量的共享他们的账户信息，也就很难进行大规模的合作。

既然不局限于PoW，那我们再来看看一个共识机制的选择问题，到底是忠实于中本聪的链式共识还是用BFT(拜占庭容错)系列、DPoS(授信PoS)或者是DAG(有向无环图)结构呢？
所有共识体系的核心都离不开验证人（比如比特币中的矿工）角色，选择验证人都要通过竞争的过程(算力更高或者权益更高或者获得投票最多)，这个过程决定了系统的安全性。但是竞争过程又有潜在的风险：
1）使用不可控制资源(工作量、获得选票的能力、硬盘容量等)引起大规模合作的风险；
2）对获胜者的激励如果不足，会导致缺乏足够的竞争者，给攻击者带来可乘之机，降低系统安全；
3）如果激励充足，又会导致财富集中化，参考https://github.com/yj1190590/PoAS第一条的叙述（英文的，暂未翻译成中文，请将就看），进而造成参与者减少。

对于一个以货币功能作为主导的账本来说，安全性的降低是难以接受的；而对于一个面向所有人的公共链来说，参与者的减少也是难以接受的。通过大规模地减少验证节点，以提高性能的方式（BFT和DPOS）会极大的加剧上述问题，所以我认为不可取。所以，为了避免1），选择只有PoS；为了避免严重的2）或3），我们只能放弃BFT和DPoS。但是即使不加剧，2）和3）的问题仍然存在，有没有什么方法能避免呢？答案是有，关键点就在于，让低权益的用户通过先合作（类似于投票）来降低工作强度，再与高权益的用户进行竞争（还是参考https://github.com/yj1190590/PoAS第一条）。也就是在3）的问题上把用户参与的问题解决了。我原先觉得DAG结构也有可能做到同样的事情，但是在异步方式下我没有找到能够让权益保持同步的方法，所以设计中还是使用了链式共识。

确定了链式PoS共识的方向之后，现在第一个问题是解决此结构下的缺陷，然后如何保留PoW的优点（比如简单高效的验证、客观性等)。现在的设计解决了现存的NaS问题（多重投票和历史攻击），客观性也基本得到保证(参考：https://bitcointalk.org/index.php?topic=5094909.0 的讨论)，验证上虽然没法做到等同于PoW的高效，但不影响重要功能（跨链验证等）。

接下来的目标是考虑的是还有哪些特性能够保留下来。

首先是性能，虽然无法在单条链上做到BFT和DPOS的高性能和DAG的扩展性，但是链式共识也有其扩展规模的方法，即多链结构，比如侧链或者分片。多链方案的分层结构实际上在安全方面更加合理，但是我认为没有简单明确的盈利方式（锁定汇率使得币价不能升值）导致了多链项目到很难得到大规模的应用。一个偶然的情况是，聚集权益的机制下，钱包程序会直接参与到挖矿活动中去，使开发者获得收入。这样刚好解决了跨链项目的盈利模式问题，这会改变很多事情，我希望这能更好地解决扩展性问题。

显式最终性(explicit finality)也是一个很重要的特性，会带来许多的好处，比如提高确认速度和避免历史攻击，而在链式共识上通常不具备这种属性。利用前面提到的权益总量不变的特点，和两类投票的方式，这个能力也被成功地实现了。

总的来说，PoAS是一种优化的链式PoS协议。以我个人的理解，应该在虚拟货币的应用上具有一定的价值，欢迎发表自己的看法，谢谢你们花时间阅读。

这里是简介，英文的，不想看可以略过https://github.com/yj1190590/PoAS/
中文版的设计文档PDF在这里： https://docdro.id/oKEhuNR

It was moved from the technical section and I didn't notice that.
Although this is not actually an altcoin discusstion but about consensus protocols, I am going to refresh it once trying to let more people see it.

Resonable suggestions, thank you.
I am considering doing them later, but I am not sure I have enough time.

IP address is not a key element of my design, so I am not focusing it.The gatherer nodes don't represent any group of users and they are usually a piece of code running on the client applications owned by a provider (miner). So the gaterers are not rewarded during the accumulative process. The main purpose of a miner is to capture voting signals with those subordinate nodes.

Gaterers are p2p nodes so they are based on IP addresses. They don't belong to common users but the miners so changing wallet doesn't affet their ownerships.
That's the character of proof of stake isn't it?
Partly correct. But it is limited. Please refer to "chapter 5. Security".

I posted a design paper of a consensus protocol a few days ago(https://bitcointalk.org/index.php?topic=5157592.0), but didn't receive any response. I am not sure whether it was because the protocol is not valuable or because I didn't explain it well. I hope it was the second reason. So inspite that there was already a breif introduction, I'm going to explain it in a simpler way: from the begining of my research. I hope there will be more people to be interested.

I decided to design a new protocol begining with some personal understanding with the debates of the existing protocols.

The first debate: PoW or PoS?
To my understanding, I prefer PoS, because the "work" of PoW is an uncontrolable external resource. Despite the energy consumption issue, using an uncontrolable external resource as a competitive material will probably cause large-scale collusions, which could impact the security. "mining pools" is an example of that. From this aspect, PoS uses an internal resource of the system. First of all, the total amount of stakes is fixed, which leads to a big advantage and I will introduce that later. Secondly, as a fundermental property of an account, stakes will not be shared among users in quantities. Therefore, large-scale collusions will be very difficult to occur.

The second debate: Chain, BFT,DPoS or DAG?
As far as I know, there are two ways to choose validators in all consensus systems: through competition (e.g. more hashpower or more stakes) or through cooperation (e.g. delegated by stakeholders). Each of them has the following potentinal risk:

The former way results in wealth concentration (plenty of incentive) which causes user reductions (referring to the first point of:https://github.com/yj1190590/PoAS), or lack of competitors (not much incentive) which causes security reductions; the latter results in the probability of large-scale collusions as PoW does (referring to https://vitalik.ca/general/2019/04/03/collusion.html), which causes security problems too.

Security reductions are unacceptable for currency-functional chains and user reductions are hardly acceptable for public chains. Sharply reducing the validator nodes (BFT and DPOS) for perfomance will greatly aggravate those problems, so I think they should not be used in currency-functional public chains.

Is it possible to prevent all of those problems? It was the first question for me to find out. The answer is yes. The key is to let lower-ability users compete with higher-ability ones through a cooparative process (stake accumulating) using a chain-based mechanism, which ensures security and participation rate at the same time. From then on, I decided to design a new consensus protocol. I have thought DAG can do the same, but didn't find how to synchronize the state of stakes in an asynchronous system. So I chose the chain-based system in my design.

After determining the structure of chain-based PoS consensus, the second goal was to compensate its defect (mostly NaS problems) and keep the advantage of PoW (e.g. efficient verification and objective boot straping) as far as possible. As a result, present NaS problems are solved; objectivity basically remains (referring to https://bitcointalk.org/index.php?topic=5094909.0);verifications are still not as effecient as in PoW but it doesn't affect important functions such as cross-chain verifications.

My next goal was to consider what other features can be applied in my design.
First of all, scalability. Although not being able to achieve the performance of BFT or DPoS and the scaling ability of DAG, chain-based consensus has its ways to expand the scale, which are multichain solutions such as side-chains or sharding. Multi-layer structures are actually better for safty factors, but to my understanding, a lack of clear and simple profit model keeps the expanding projects from being widely used (because the currency value is locked). Unpurposely, under the mechanism of accumulating stakes, the wallet applications will be involved in the mining process sothat their provider could directly profit from the system. It just solves the problem of profit model and will change many things. I hope it is helpful for scaling solutions.

Explicit finality is an other important feature that brings many advantages such as fast confirmation and avoiding historical attacks. It's a feature that most (I'm not sure is it all) of the chain-based protocols don't have. Using the property of fixed amount of stakes that is mentioned above and a double voting method, the feature of explicit finalities is successfully applied.

That's all I have to explain. In short, PoAS is an optimized chain-based PoS protocol. To my understanding, it should be valuable for the use of cryptocurrencies.

All suggestions and opinions are welcome! thank you for your time!



breif introduction and the full paper are here:
https://github.com/yj1190590/PoAS/

Sorry for following up so slowly. I was delayed by something unexpected.
Any suggestions and comments are welcome. Thank you for your time!
https://github.com/yj1190590/PoAS/

Major changes：
Some redundant chapters are removed.
Sections about the security and fairness are added.
Modified the rule of network dispersity competition to ensure fairness.

Related post：
Discussion about the probobility of historical attack:https://bitcointalk.org/index.php?topic=5094909.0

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

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.

Different. With finalization, without the check above.

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.

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.

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.

How does that work? Bribling?

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

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.

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?

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

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.