sim31
commented
1 month ago Potential solution
Simplest (and currently seems like the most robust) way to fix this would be for ORNode to ignore proposals created by accounts which have no Respect (instead of listening to ProposalCreated events listen to WeightedVoteIn and in case vote is on a proposal ORNode hasn't seen before - create it). ORClient should detect when it is not able to put proposal to ORNode because it does not have any Respect and should not throw any errors in that case. During breakout room submission scenarios, it's a matter of time until some Respect holder will submit the same result. Then ORNode should add votes from accounts that have no Respect that have been submitted so far (EmptyVoteIns should either be cached for limited amount of time or ORNode should retrieve older logs). This would take care of the only scenario where we have to listen to votes from accounts with no Respect.
Currently ORNode listens to
ProposalCreatedevents of Orec contract and stores a record for each such proposal. Orec allows accounts with no respect to create proposals. This is intentional in order to avoid adding complexity to breakout result submission frontends - they would have to make sure that the first submission is from some existing Respect-holder.But this introduces a DOS attack vulnerability - accounts with no Respect could spam with many proposals thus forcing ORNode to use a lot of storage and potentially crashing.
The successful attack would not be cheap:
By itself this attack would not enable any effects on smart contract state. But it could crash ORNode, which in turn might stop frontends from working (until the ORNode database is cleaned up by someone and it is restarted).
There's currently no incentive for this attack as well because OREC is currently not used for controlling any funds and there are no plans for it to do so in the near future.
Nevertheless, this should be fixed eventually.