AIP56 - Proof of DF Discussion

[kristjank]

Discussion related to: https://blog.ark.io/introducing-proof-of-double-forgery-7393ff1f7bfa

[n4ru]

Okay, cool. So basically slasher for DPoS. I'm on board with the idea in general.

Unfortunately...

How do you actually solve the network issue related to double forging blocks? This is more important than the punishment. This only treats a symptom and disincentivizes attacks with intentional double forging. In Ark, this does nothing because nobody /intentionally/ double forges. The network will still brick, and you can't actually punish someone until a future block is accepted by most nodes, but if it is then the double forging is already sorted. This punishes intentional bad actors but does nothing to actually fix the existing problem.

This is a solution for a problem ARK doesn't have, which punishes honest delegates for a problem ARK does have. Really bad idea.

[zillionn]

@n4ru Did you read the blog post? https://blog.ark.io/introducing-proof-of-double-forgery-7393ff1f7bfa

Intentional or not, if you double forged, you'll be punished. You don't like the solution but if it's strengthening the network, then it's a good one.

[vulet]

As Alessio said from chat, "if the punishment is by publickey then the malicious actor will just register a new delegate".

[roks0n]

It's not strengthening it as double forge will still occur. The resolution mechanism isn't guaranteed to work all the times which means any malicious actor can still trigger an "apocalyptical" event. This means this more or less punishes delegates that are accidentally double forging.

It's adding unnecessary extra complexity which can introduce targeted attack on delegates and who know what else.

I believe @moazzamak had some ideas how to prevent double forging in form of AIP 25 and AIP 27?

Note that above is a sum-up based on the discussion with @n4ru and Alessio.

[Jarunik]

The network will not reach step 7 as the network will split in step 6 and break down. So all activity after step 6 won't do anything.

[doubled1c3]

@vulet at present price that malicious actor would need access to over $1m USD worth of vote weight to execute a DF using a brand new delegate, they wouldn't be able to immediately attack again unless they were self forging.

My understanding is this DF rule would not prevent DF but also wasn't designed to. I was under the impression that it would act as a protocol level alert system so the other forging delegate nodes can reach consensus on who messed up and then take actions to ignore the culprit's fraudulent chain all on a protocol level instead of a 'scrambling and take manual action' level (with snapshots etc). Perhaps I misunderstand.

[zillionn]

Well, if we could just ignore/prevent the DF at all, that will definitely be the better solution...

[n4ru]

@zillionn Did you read the blog post?

It's doing the opposite of strengthening the network.

[alessiodf]

@doubled1c3 I am breaking with tradition and interacting with GitHub because you are perpetuating an ideology that seems to be institutionalised within the Ark Team and really has to change.

You are intending to build an ecosystem of bridgechains. Not only Ark. Everybody must stop being blinded to issues that may not affect the main chain but do in fact affect most/all bridgechains. The team says so many malicious actor vectors are not a problem because the barrier to entry is so high for Ark, but it is a problem for the other bridge chains where it costs pennies only to accrue enough vote weight to become a delegate. You, and we, owe it to them to make sure their bridgechains are safe and secure. This goes against that.

It genuinely seems like only Ark matters in this ecosystem.

I do not approve of this AIP.

[doubled1c3]

@alessiodf ah of course, the small chains would not have the barrier of high token price being integrated into the security model. Thanks for highlighting this

[zillionn]

@n4ru I guess I got it wrong what exactly this AIP is doing. I agree now, just punishing without fixing the consensus is not a long-term solution.

[moazzamak]

Personally I'm not against slasher algorithms to maintain consensus. But this AIP focuses on trying to prevent forks (caused from DF in this case) from happening which I think is a bad target to aim at since there's no way that it can be guaranteed due to how real life networks work. IMO A better target to focus on would be fork resolution and ensuring that the risk of double spend attacks is minimized despite forks happening (P.S: this is exactly what I try to solve in AIP25 so maybe give that a look).

[fix]

As mentioned in the post, this solution prevents from an attack where a delegate can double forge to mess with network. This is a weakness for all PoS based consensus. Because it cost nothing to do this. With this proposal it costs something.

Now true that double forge also happens accidentally. This proposal does NOT intend to solve that. The way to fix this is to improve code stability and make sure all delegates are good enough to deploy the code to prevent this. V2 brought the capabilities to remove the necessity to have several fallback forgers.

The proposal is NOT about solving accidental double forgery.

[alessiodf]

As mentioned in the post, this solution prevents from an attack where a delegate can double forge to mess with network

No it doesn't.

With this proposal it costs something.

No it doesn't.

V2 brought the capabilities to remove the necessity to have several fallback forgers.

No it doesn't.

Now true that double forge also happens accidentally. This proposal does NOT intend to solve that. The way to fix this is to improve code stability and make sure all delegates are good enough to deploy the code to prevent this

The fact you admit that double forging happens accidentally is good enough reason for why this must never see the light of day. Innocent people would be punished.

The proposal is NOT about solving accidental double forgery.

Proposal states: We have also worked out a similar condition for DPoS together with introducing a simple yet powerful punishment consensus rule to prevent double forgery. No ifs or buts or "excluding accidental cases".

[fix]

@alessiodf i am sorry to see you are unable to have a sensible discussion. I think your brain is unable to understand the difference between consensus rule and implementation.

I recommend you to play somewhere else.

[alessiodf]

Excuse you? If you decided to open your eyes, improve your English, and read the debate that was happening on Slack (and all of my previous input regarding other issues there) you would see I contribute to many sensible discussions. You have just single handedly demonstrated how out of touch you are and your remark is not worthy of the position and esteem you hold yourself in.

May I suggest you go back to lobbying the French government or whatever you do nowadays and stay out of coding matters. I can authoritatively state that, as the person who has uncovered more security bugs in Ark code than anyone else - including saving your project from being completely exploited - almost all of those bugs were down to your own personal sloppy code. So if anyone should "play somewhere else", for the safety and protection of this project, it's you.

Now, moving on from your insult suggesting my lack of intelligence, which I more than reciprocate in your general direction having seen the quality of your "work", for the benefit of someone who obviously suffers from either a language barrier or sheer incompetence and can't understand the point I'm making, I shall elaborate. Just for you.

As mentioned in the post, this solution prevents from an attack where a delegate can double forge to mess with network

It doesn't prevent an attack because this is a reactionary approach and does not stop double forgery from happening in the first place. It's also flawed because existing "consensus rules" would prevent the next delegate in line that would detect double forgery from being able to actually propagate its block to tell the rest of the network after double forgery took place. Consequently there is no "prevention" in this proposal. It reacts to what happens but does not prevent it and does nothing to stop the network from grinding to a halt after the first double forgery attempt.

With this proposal it costs something.

It doesn't cost anything because a self-sufficient delegate can register a new delegate and revote for themselves. Sure in the case of many public Ark delegates who depend on the votes of others, it raises a stumbling block. But there are many self-sufficient delegates who do not depend on the votes of others, and in other forks where the barrier to delegacy is very low, this does not cost anything. A corporate bad actor with deep pockets wanting to act maliciously would not be inconvenienced at all.

V2 brought the capabilities to remove the necessity to have several fallback forgers.

As demonstrated as recently as yesterday on mainnet, Core v2 remains vulnerable to attacks to take nodes offline, and even without attacks, v2 nodes randomly miss blocks on an almost daily basis unlike v1. It is quite frankly astonishing that you feel fallbacks are not necessary as v2 code is not perfect. Especially the parts you wrote.

The proposal is NOT about solving accidental double forgery.

You should update the blog post that claims it's so groundbreaking to fix double forgery if it has caveats.

There we go. Now if you don't mind, I'll carry on resuming my security research to keep your project alive. You're welcome.

[n4ru]

@fix OH NO NO NO 🍿

[MatthewDC]

I can see that there is a lot of passion here and I know everyone involved just wants what is best for ARK. I'd ask that everyone involved, team included, try to refrain from personal attacks and stay focused on the matter at hand. Constructive responses across the board will help further the conversation and help us get to the best possible solution. Personal attacks and sarcasm will only distract from our intended purpose of posting the AIP.

I understand some of the arguments against the proposal and we had a great discussion in the public slack about some potential alternatives last week. We will be taking all options under advisement and working to refine the proposal with the solution that is best for ARK.

If you have additional ideas or potential constructive feedback outside of the discussion that was already had (i.e. Tendermint), please post them here so we can continue to do additional research for refining the proposal.

Thank you to everyone who is here commenting and getting involved in making ARK better. Let's all try to remember why we are here and help find positive solutions to push the technology forward.

[github-actions[bot]]

Stale issue message