search

vegaprotocol / specs

Specs, designs and requirements 🦔
MIT License
7 stars 2 forks source link

Client side POW spam protection #399

Open tamlyn10 opened 4 years ago

tamlyn10 commented 4 years ago

We need to figure this out and write a spec for it!

tamlyn10 commented 3 years ago

@Vegaklaus document: https://docs.google.com/document/d/1DN7E5NvsiKIhtTHB2VjnlP9J8hhGDRXKJr1AUXSw_O0/edit#heading=h.5o7dyi25t6u1

edd commented 3 years ago

@barnabee Barny to progress, but it's less important than validators

edd commented 3 years ago

Our current dumb implementation of rejecting TXs for users without an account (see: https://github.com/vegaprotocol/vega/issues/3287) means that we have a crappy situation whereby nothing is ever emitted on the event bus for (for example) an order that someone submits, but isn’t allowed to. Or an LP while they’re disabled. This means it’s never in the APIs.

The reason for that is that we don’t want nodes gossiping TXs that can never be valid. When we have client side POW as a more delicate alternative, can we remove the existing check so that we can make the APIs more complete?

Note: The reason that the validator that sees the invalid TX does not emit an event on the event bus is so that the event bus output can be compared across machines. If this is not valid, then we could add an event anyway.

cc @barnabee / @Vegaklaus

barnabee commented 3 years ago

It sounds like we might want a flag on events to show which are expected to be deterministic "chain events" and which are local "node events"?

I don't think we should start gossiping these. Rejecting them is good.

Is it even a problem re: APIs given that I think the /sync endpoint tells you the submit fails and why? I guess being able to query the rejections on a node might be nice but also seems unusual and maybe not good on a public node (should you also be able to query a history of requests that failed basic validation or to a not found endpoint)?

ashleyvega commented 3 years ago

Regarding good/bad/ugly tx being tracked through the system, I hope we eventually get to the app behaving in such a way that:

I hope there will eventually be zero middle ground of tx being successfully accepted and then black-holed, because this is unfriendly to beginner users and API client developers.

barnabee commented 3 years ago

Does that middle ground exist today? (if you don't specifically ask for it by using a version of the API that doens't wait for the response)

edd commented 3 years ago

Does that middle ground exist today? (if you don't specifically ask for it by using a version of the API that doens't wait for the response)

There is one current case, which is submitting an LP provision on a network where it is disabled: https://github.com/vegaprotocol/vega/blob/b0dad9b051c99afd28e0664659691310e1cf367e/execution/market.go#L3174-L3176

Because this happens when it is executed, rather than when it is committed (like other rejections) it is just lost forever. I added it to https://github.com/vegaprotocol/vega/issues/3287 but then removed it, as that commit will go in to the same release as not including* the LP rejection. So. Soon there will be no black hole. Right now, there is one.

* This is intentional - in develop, this code doesn't exist