-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
I think that this issue's severity is a little bit overestimated.
|
The user transaction will pay for this transaction, so if they spam the network, they will pay for it |
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. |
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:
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
Where in the software does this update applies to?
The text was updated successfully, but these errors were encountered: