Hi: I have been working on this consense mechanism since I posted it last time. This is a new version of research paper after struggling with the language expression skills. Let me introduce the protocol in brief. 1)This study aims to determine a pow-like protocol with less energy consumption. 2)The ability "Nertwork dispersity" is defined as As a greater number of dispersed online terminals work together, the faster they can acquire
randomly distributed information in the network due to network latency. This type of “ability”
is referred to as “network dispersity,” 3)The protocol can be seemed as a kind of PoS mechanism because of using the "stake" ability, but without its most common problems like NaS and wealth concentration issue. 4)Data can be finalized. 5)It's a fully discentralized system without any special node like "Validators" and doesn't need any outside resources or third-party processes. The full paper is shown here(disabled). If there are any questions, please let me know. Thanks. |
|
|
|
Hi Shunsai, Block approvers own >50% of the stake. If they approve blocks containing conflicting approvals, that will invite many forking related attacks on the chain including double spend. Approvers can approve another block containing all valid approvals, so they don't benefit by violating the rule. Would a rational stakeholder approve a block that may lead the devaluation of their asset without providing them any benefit? I think not. (This has the same basis as PoS.)
What I mean was the block creators benifit from violating the rule, not the approvers. They could receive more approvals from using both unconflictful and conflictful contents. Isn't that right? Regardless of the benifit anyway, why does anyone doing their duty when there is no evidence and no punishment for not doing so? What if somebody use an incomplete mining application? In absence of >50% approvals, no new blocks will be created in those slots. It may not sound that good at first but this is the best policy. It's preferable to not process any transactions than to risk the entire blockchain. Once the connectivity is restored, the stakeholders will approve (or reapprove) the set of blocks offered on top of the previously approved block. As a matter of experience, >50% online stake is very unusual. The problem of getting stuck is critical because it could happen anytime and last a very long period of time, not just under network separation. Shouldn't you find a way to deal with that? All block based chains like Proof-of-Approval including Bitcoin and Ethereum, have the so called probabilistic finality. The newest 'n' blocks in the chains are not considered stable. For Bitcoin, users want that 'n' to be 6 blocks or more. For Proof-of-Approval, it is just 1 block. In this respect, the word "stable" is meaningless when the onchain data could still be changed and that's why Bitcoin and Ethereum are called "nonfinality". Protocols like PBFT and Casper provide finalites by the collaboration of Valiators but I didn't see "finality" in your protocol. |
|
|
|
Hi Shunsai: Multiple block creators publish block-approval-blocks for their own created blocks. While they are sent to all the nodes, block-approval-blocks are not stored themselves in the chain, their contents are.
Conflicting block approval is detected by looking at all block-approval-blocks published on the network in the same slots. It is the next block creator's responsibility to check for these conflicts and not use contents of a block-approval-block that contains such a conflict. In addition, the approvers for the next block will also check for these conflicts and would not approve blocks that contains a conflicting approval from the previous slot.
The punishment for a conflicting-approver is that they do not earn approval award since their approvals do not go in the chain.
What if the block creators don't obey the rule? They could use the conflict approvals anyway and that seems better to them because more approvals means better chance to win. And more importantly, there will be no evidence while they did so. Then why does anyone obey the rule for his own benifit? Once there is >50% stake approval on a successor block, there can only be one and only one predecessor block under the honest majority stake assumption even with network outage. If in case a block cannot receive >50% approval, then no new blocks will get published. Those slots will go empty until a >50% approval is achieved. Then how to prevent getting stucked when there are not so many positive users paticipating in the competition if the quorum stake is >50%? The protocol achieves finality after 1 block - not instant finality. PBFT and related protocols that build consensus on transaction level and publish a single block per slot have the real instant finality.
This near instant finality helps with Bribe attack but not with History (aka Costless Simulation) attack. It is because the "finality" is in the short timespans where the stakes of the parties have not changed dramatically. History attack, on the other hand, is powered by dramatic stake changes which can only occur in the longer timespans.
Since the "finality" is not the actual finality, what's the meaning of it? Because the data on chain is still not 100% certain. |
|
|
|
|
Hi Shunsai:
1.According to my understanding, the approvals stored in each block-approval-block are the approvals for the current block. So where are the conflicted approvals stored? If they are not stored in the history blocks, how could you tell a stackholder approves conflicted blocks. In other words, according to what should you punish the double-approving behavior to prevent "nothing at stake" problem?
2. About the instant finality. If you determine the realchain so quickly, how could you prevent the blockchain from spliting into different forks for ever when there happens something that separate the network temporaryly, like intercontinental optical fiber cable fracture?
3. About the history attacks. Why don't you just mention that the protocol has instant finality? Because that resolved all the history attacks if it works.
|
|
|
|
So, as an attacker creating a fork, I poison the main branch by using my stake in the main branch and in another branch thereby increasing the odds the main branch will be discarded in favour of my competing fork which contains no 'double-active' stake.
Besides that you have to have enough stake in your branch which is not active in the main branch and that is difficult to achieve. Because the is no objective way to tell the difference between the main chain and the competing fork with historical keys - both appear to have the same amount of 'online stake'.
In my protocol the online stake can be precisely counted so that the difficulty can be adjusted by a different way from the PoW protocol. We can calculate the difficulty by using the amount of online stake and that will ensure the fake branch grows slower than the main. In other protocols, we can build a kind of math model to restrict the blockrate into a certain range according to the current blockrate and difficulty to make sure that the higher mining power generate blocks faster than the lower. In other words, there are objective methods to tell the difference between different mining power by refering to the current blockrates and the difficulties. |
|
|
|
Either you select the canon chain based on highest stake, or you don't. If your standard rule is to select based on highest stake, then your secondary rule must use some other criteria. If that is the case, then you don't have 33% attack tolerance anymore, you have a lesser tolerance which will be exploitable much more easily.
The first rule is the longest or heaviest branch; the second rule is according to the proportion of the double-active stake: the lower proportion, the higher probobility to be choose to the main branch. There could be some complex judgment basis but they basically follow those rules. By the way , I still don't get why the fake chain can catch up with the speed of the main chain. Since the growth speed is determined by the online stake, why would a branch with partial stakes grow faster than the one with full stakes? |
|
|
|
...try to trigger your other rule to discard the canon chain as fake...
Have you thought about how? Take notice the proportion is measured by stake. So you have to fake the activities on the fake chain using the active private keys on the main chain. it wont, but for the sake of argument, lets assume it will What is the other reason it wont work? So now instead of one rule for selecting the correct fork you have two rules. There may be more than two rules in Pos system, such as : the first N blocks are not reorganizable. |
|
|
|
I've found a solution in an other post for this problem that might help. https://bitcointalk.org/index.php?topic=3603859.msg36995026#msg36995026First of all the reorganizition is designed to prevent forks. Under normal circumstances, some stakeholders would be active(trading or mining) in both branches (caused by NaS too) if there appears a fork. According to the probability there will be similar stake proportion of "double-active" users between both branches. But if the branch is a fake chain built by the attackers, they will be disproportionate —— the proportion mentioned above in the mainchain will be much less than that in the fake one, unless you have bought every account, which is impossible. Under this circumstance, the branch should never be accepted no matter how long it is. This operation is also nessesary to prevent some group of users from getting extra advantage by unfair means when forks come. By the way, the situation you have mentioned:"any syncing node querying at random will find his fake nodes with fake history" could be resolved by controling the p2p links—— each node only needs to build connection with a certain number of nodes with the fastest response speed. The attacker needs to try through a lot of past blocks so that the longer range he seeks, the better chance he would success. But the longer range he starts the fork, the more obvious the disproportion will be. I think that might increase the difficulty you launch an attack, after all you gain those private keys by "buying". |
|
|
|
I have thought seriously about the problem you posted and maybe I have found a way to mitigate it. It's useful to any PoS protocols. First of all the reorganizition is designed to prevent forks. Under normal circumstances, some stakeholders would be active(trading or mining) in both branches (caused by NaS too) if there appears a fork. According to the probability there will be similar stake proportion of "double-active" users between both branches. But if the branch is a fake chain built by the attackers, they will be disproportionate —— the proportion mentioned above in the mainchain will be much less than that in the fake one, unless you have bought every account, which is impossible. Under this circumstance, the branch should never be accepted no matter how long it is. This operation is also nessesary to prevent some group of users from getting extra advantage by unfair means when forks come. By the way, the situation you have mentioned:"any syncing node querying at random will find his fake nodes with fake history" could be resolved by controling the p2p links—— each node only needs to build connection with a certain number of nodes with the fastest response speed. The attacker needs to try through a lot of past blocks so that the longer range he seeks, the better chance he would success. But the longer range he starts the fork, the more obvious the disproportion will be. I think that might increase the difficulty you launch an attack, after all you gain those private keys by "buying". |
|
|
|
It's all NaS in the end. Every problem that PoS has is due to NaS.
edit: in any case, what I've posted isn't 'long' range, but instead *any* range.
I know what you mean with "NaS" but I used that word with the meaning of the "double voting problem". If the problem mentioned at that post is still unresolved, I must say that's the problem we haven't resolved yet. But we have at least resolved the first one. |
|
|
|
Words like 'sealed' have little meaning in any system where block generation has zero cost.
I recommend you to read the article "Transactions as Proof-of-Stake" by Daniel Larimer whose idea was close to mine in this respect. |
|
|
|
All stake based protocols suffer from NaS - yours included.
I hope this could explaine: The difference is that when the votes take effect, they are already sealed in the existing blocks. That makes the common problem of PoS such as “nothing at stake” or “stake grinding” resolved. |
|
|
|
My point was, if you only achieve the security model of PoS with this technique, why bother at all?
We assume that you are right that it has the same security level as PoS, which actually not(you will know that if you read the section "51% attack"). At least the new model don't have the common flaws of PoS such as the wealth concentration issue or "nothing at stake" problem. And provides incentives to build open development multi-chain systems which may be a progress in the field of cryptocurrency. Provide an incentive for developers to build extend projects which ensures the sustainability and extendibility of the system. |
|
|
|
My point was, if you only achieve the security model of PoS with this technique, why bother at all?
We assume that you are right that it has the same security level as PoS, which actually not(you will know that if you read the section "51% attack"). At least the new model don't have the common flaws of PoS such as the wealth concentration issue or "nothing at stake" problem. |
|
|
|
You cannot objectively verify claimed network latency, so you cannot build a consensus using this concept. I think you have realised this, so you've stake weighted your consensus to compensate....
You are right, that was one reason that I use stake to measure the power of voting. But it was not a compensation because the "stake" property plays other important roles like “balance the mining power”. you could see it here: https://github.com/yj1190590/PoND/blob/master/README_eng.md#compete-for-the-voters. At best this will leave you with the security model of PoS.
You can consider it as a kind of PoS mechanism in this respect, that's OK. But from some other respects it has many differences from PoS. About this question, you could refer to: https://github.com/yj1190590/PoND/blob/master/README_eng.md#faqs if you'd like to. At worst you will have all kinds of sybil attack problems related to the nuances of your implementation. Sybil attacks are not so easy just because I use the "stake" property like you said. |
|
|
|
Proof of Stake protocol is less secure than Proof of Work. Calling it more successful is naive. It has it's costs and it's benefits.
It trades security for energy consumption, it isn't better, it is just different.
I have never said that PoS is better than PoW. I said PoS is the most successful one of the other alternative protocols, isn't it ? All the other protocols are following the same logic, like Proof of Activity, Proof of Burn, Proof of Storage, Proof of Elapsed Time, and so on. "Proof of Stake" (PoS) protocol is the most successful one of them... |
|
|
|
I stopped reading the paper at this point. I'm afraid this paper reads like a blog post from someone who just read about cryptocurrencies for the first time.
I don't quite catch the point of you but if there were any misunderstandings caused by the grammar and syntax, I'm very sorry about that becsuse I'm not a native English speaker. If you have any point of view that is against mine, would you please tell me in a direct way because I don't want to miss the main idea again. Thanks. |
|
|
|
github上面应该很多人才的，难道没有人为你的构想提出意见和建议吗？ 我觉得楼主应该是有一个比较靠谱的计划的，希望你成功。
有关注的，但没有给建议的。github不方便做宣传推广，我只做展示页面在用。 |
|
|
|
|
Show Posts
