Bitcoin Forum
April 20, 2024, 02:32:25 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: A Stake-Based Double-Voting Consensus Protocol  (Read 743 times)
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 09, 2019, 06:53:30 AM
Last edit: April 08, 2019, 02:05:39 AM by yj1190590
Merited by ABCbits (1)
 #1

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:
    If everyone’s wealth grows at the same rate, the distribution will not change. As the green line shows:

    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:

    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.

   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
or
https://www.keepandshare.com/doc15/19928/researchpaper-3-0-pdf-928k
1713580345
Hero Member
*
Offline Offline

Posts: 1713580345

View Profile Personal Message (Offline)

Ignore
1713580345
Reply with quote  #2

1713580345
Report to moderator
If you want to be a moderator, report many posts with accuracy. You will be noticed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
monsterer2
Full Member
***
Offline Offline

Activity: 351
Merit: 134


View Profile
January 09, 2019, 09:42:07 AM
 #2

Please host this on a non-scammy file sharing site, I cannot download it
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 09, 2019, 10:29:25 AM
 #3

Please host this on a non-scammy file sharing site, I cannot download it
modified
monsterer2
Full Member
***
Offline Offline

Activity: 351
Merit: 134


View Profile
January 09, 2019, 11:11:46 AM
Merited by suchmoon (4), ABCbits (1)
 #4

Quote
Till date, the continuous development of the blockchain consensus protocol is broadly divided
into three systems: Proof of Work (PoW), Proof of Stake (PoS), and Byzantine Fault Tolerant

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

Quote
..although the PoS system does not have some of the BFT’s characteristics like high throughput and low commissions, has more advantages in terms of code complexity, the degree of decentralization, and objectivity

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.
elda34b
Sr. Member
****
Offline Offline

Activity: 910
Merit: 351


View Profile
January 09, 2019, 11:22:06 AM
 #5

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.
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 09, 2019, 11:24:52 AM
Last edit: January 10, 2019, 09:11:20 AM by yj1190590
 #6


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.
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.
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 09, 2019, 11:29:57 AM
 #7

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.
I am not going to publish any coin in any form. It is just a technique discussion, shouldn't it be post here?
mixoftix
Full Member
***
Offline Offline

Activity: 124
Merit: 178

..


View Profile WWW
January 09, 2019, 11:39:52 AM
Merited by suchmoon (4), ABCbits (1)
 #8

Quote
Till date, the continuous development of the blockchain consensus protocol is broadly divided into three systems: Proof of Work (PoW), Proof of Stake (PoS), and Byzantine Fault Tolerant (BFT).

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.

Quote
Utilizing network dispersity to gather stakes can provide a non-simulatable competitive mechanism while achieving the goal of making majority of the users active at the same time.

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

Quote
Thus, if the branch obtains more than half of the total stakes of the whole system within a voting cycle, it is impossible to have a competitive branch. We denoted the branch as “Finalized,” and the block at the root of the branch as “save point.” Any historical attacks that occur before the save point will be rejected; Thus, the NaS problem is solved.

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.

Quote
Conflict of Interest
Patent NO. : CN201811633256.0

would you please give more information about it?

Development of "Azim Blockchain" is in progress..
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 09, 2019, 12:01:39 PM
 #9

this save point in your proposal just works as same as checksum in bitcoin.
It doesn't work like checksum.
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 10, 2019, 01:45:51 AM
 #10

I haven't read the paper throughfully. but here are my opinions/question :
1. Frankly i don't see the point of the gatherer, why don't the stakeholders include vote information on their transaction and broadcast it
gatherers belongs to the miners competing for those broadcasted signals to win their votes.
Quote
2. Based on how people manage/use their wallet, i doubt majority of users would bother change configuration of their wallet. IMO this means miners who cooperate with wallet developer would have huge advantage
That is why wallets should paticipate in the profit distribution.
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 10, 2019, 10:28:46 PM
Last edit: January 11, 2019, 12:37:22 AM by yj1190590
 #11

I afraid this parameter could fabricate easily. would you please elaborate this mechanism?
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.
Quote
while your voting model doesn't fit in opportunity cost context, your model still suffers from N@S.
I'm not saying I eliminates NAS, which is impossible . It just resolves the most serious problems caused by NaS.
mixoftix
Full Member
***
Offline Offline

Activity: 124
Merit: 178

..


View Profile WWW
January 11, 2019, 10:00:18 AM
 #12

it cant be fabricated easily unless you cooperate with the signal senders.
Quote

thank you. however in page 8, (frauds and attacks) you write a bit about sibyl attack, but I think having several different entities in a network could make it vulnerable in front of sibyl attack. look, there is a question, how much does it may cost for a dishonest person to provide many fake CONFIRMS for himself and win the fee/reward?

P.S.:

honestly, forget the patent part of your proposal.  this is better you provide your proposal with a MIT License, then people may get interested in your job. in one case, even a GPL-3 License caused failure during integration of hyperledger and ethereaum:

https://www.ethnews.com/hyperledger-fails-ethereum-integration-due-to-licensing-conflicts

Development of "Azim Blockchain" is in progress..
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 11, 2019, 01:46:30 PM
 #13


thank you. however in page 8, (frauds and attacks) you write a bit about sibyl attack, but I think having several different entities in a network could make it vulnerable in front of sibyl attack. look, there is a question, how much does it may cost for a dishonest person to provide many fake CONFIRMS for himself and win the fee/reward?
"Confirms" is votes from the stakeholders. He can vote for anyone he want anyway, but can not vote with the stake belonging to others.
Quote
P.S.:

honestly, forget the patent part of your proposal.  this is better you provide your proposal with a MIT License, then people may get interested in your job. in one case, even a GPL-3 License caused failure during integration of hyperledger and ethereaum:

https://www.ethnews.com/hyperledger-fails-ethereum-integration-due-to-licensing-conflicts
Thank you for the advice! I'll consider about it.
mixoftix
Full Member
***
Offline Offline

Activity: 124
Merit: 178

..


View Profile WWW
January 11, 2019, 01:58:30 PM
 #14

"Confirms" is votes from the stakeholders. He can vote for anyone he want anyway, but can not vote with the stake belonging to others.

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

Quote
3. Consensus Process

We rely on two types of votes, namely the vote from stakeholders for miners and the vote from the miner node for the current main branch, to reach a consensus that will be introduced below.

Development of "Azim Blockchain" is in progress..
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 11, 2019, 02:41:31 PM
 #15


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.
monsterer2
Full Member
***
Offline Offline

Activity: 351
Merit: 134


View Profile
January 16, 2019, 11:08:34 AM
 #16

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?
mixoftix
Full Member
***
Offline Offline

Activity: 124
Merit: 178

..


View Profile WWW
January 19, 2019, 11:47:23 AM
 #17

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/

Development of "Azim Blockchain" is in progress..
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 26, 2019, 07:33:31 AM
 #18

Modified for better understanding.
yj1190590 (OP)
Member
**
Offline Offline

Activity: 199
Merit: 15


View Profile
January 26, 2019, 09:36:45 AM
Last edit: January 26, 2019, 11:55:59 AM by yj1190590
 #19

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.


This problem was discussed in section 6(2).
Quote

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]?"

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
monsterer2
Full Member
***
Offline Offline

Activity: 351
Merit: 134


View Profile
January 27, 2019, 11:20:29 AM
 #20

This problem was discussed in section 6(2).

You briefly mention the problem and that 'countermeasures' might need to be deployed, but the key issue is not addressed.
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!