Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spam Attack in current Oracle design #1527

Closed
doubiliu opened this issue Apr 1, 2020 · 3 comments
Closed

Spam Attack in current Oracle design #1527

doubiliu opened this issue Apr 1, 2020 · 3 comments
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@doubiliu
Copy link
Contributor

doubiliu commented Apr 1, 2020

Summary or problem description

In the current Oracle design, the Oracle memory pool is used to cache Oracle transactions and wait for responses from Oracle nodes.In this process, you can transfer the balance of the Oracle transaction sender account by sending a transfer transaction, so that the Oracle transaction fails to execute because the account balance is insufficient to pay the fees when it is on the chain.

Steps to reproduce the behavior:

  1. Use the same account to send a lot of Oracle transactions, and these Oracle transactions all visit a time-consuming website
  2. Wait for a certain time, send a transfer transaction, transfer the gas in the account

At this time, when all Oracle transactions get external data and are ready to be moved into the memory pool, they will be kicked out due to insufficient fees.

Not only Oracle, any cache operation in parallel with block synchronization may have this problem

Do you have any solution you want to propose?
This is a serious problem.This will cause the Oracle node to suffer losses and waste computing resources and bandwidth.

Maybe we can have the following methods to avoid this problem:

Option A: Use a condition timer to put the waiting response on the chain.
Option B: lock account balance, can only be withdrawn after Oracle transaction execution.
Option C: TBD.

I personally support option A. Conditional timer on the chain is really a good proposal.But if it is executed off-chain, it will encounter the same problem.

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • Other:Oracle
@doubiliu doubiliu added the Discussion Initial issue state - proposed but not yet accepted label Apr 1, 2020
@realloc
Copy link

realloc commented Apr 1, 2020

I think that this issue's severity is a little bit overestimated.

  1. The problem with slow external resources can be solved by setting timeouts for getting the result. Even in case of massive spam attack it could not be very harmful, considering modern computer's power.

    The average desktop on 10Mbits Internet channel can handle tens of thousands of http connections/requests per second and bandwidth is almost free for the volumes required for serving Neo Blockchain Oracle needs.

    If all agree that this attack is possible and significant, then maybe it would be better/cheaper to consider this in economical model, rather then introduce technical sophistications.

  2. Mempool clog can be solved by setting Oracle TX TTL in attributes.

    Because Neo has Turing-complete SmartContracts, if all OracleTXs called from particular invocation failed to be complete in time, maybe it will be better to fail that invocation together with all dependent OracleTXs or re-evaluate original invocation to get new OracleTXs list.

    Anyways Spam attack like the one you've described may be detected and prevented without complicated conditional timers.

@shargon
Copy link
Member

shargon commented Apr 1, 2020

The user transaction will pay for this transaction, so if they spam the network, they will pay for it

@roman-khimov
Copy link
Contributor

IIUC the original intention laid out in #1276 was to allow Oracle transactions to enter unverified part of the general mempool, so it's true that for these transactions there won't be any guarantee of having enough balance to pay for the fees. But I think it can easily be changed if one is to put Oracle transactions into verified pool (what I've got from staring at code for a while is that this part is probably not yet implemented), just don't pick them for the next block until they have all dependencies (Oracle responses) resolved.

And in its essence this problem doesn't seem to be that much different of a mempool reverification problem (#338, #814 and #1140) to me. New block can make some mempooled transactions invalid whether Oracle ones or not. It was the same even with UTXO model, some inputs might get used in the new block and there is no other way to resolve this conflict but throw away conflicting transactions (making their processing expenses a waste).

That's why I don't think Oracle transactions require any additional mechanisms wrt this issue, they have the same problems regular transactions have and if we want to optimize something for regular transactions, Oracle ones will benefit from this too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

No branches or pull requests

5 participants