Is dfinity a dark forrest?

Developers
#1

A while ago I read this article about frontrunning transactions on ethereum.

The premise is basically this. Lets say you have some smartcontract with some eth in it and there is a possible transaction anyone could make to claim that eth and send it to their address. You could try to make that transaction, but there are bots that scan the mempool for these kind of transactions and copy them replacing the receiving address with their own and a higher gas cost thus claiming the eth for themselves.

Lets say I make a treasure hunt actor in dfinity where you can claim some cycles if you send it some secret key. Would the same problem arise? I never heard dfinity talk about a mempool but I believe you don’t know the order in which actors process messages and you could perhaps have a bad datacenter which scans for these kind of transactions on the actors that it hosts.

Am I talking nonsense here or is there something to it?

1 Like
#2

Thanks for posting the question. It is a valid concern, and in theory cannot be fully prevented (i.e., dishonest block maker can always re-order transactions). That said, there are a couple things that make IC less vulnerable to such attacks:

  1. Transactions are not picked by fees. Canisters pay for transactions instead. So a malicious 3rd party cannot simply inject their ingress messages and expect it to front-run others.

  2. IC will run its node software in secure enclaves, and traffics from end user to the node software is protected by SSL, so even data center operators will not be able to know the transaction details, or tamper with the ordering decided by the software.

  3. Once message are inducted (i.e. having gone through consensus etc. and ready for execution), their execution order is fully deterministic, and the exact ordering is subject to a number of factors, e.g., existing message queue, canister state, etc. Even if the data center operator manages to peek at the data, they would have a hard time to manipulate it (because they’ll have to do so on 2/3 of nodes, and no data center has majority for any of IC’s subnet).

  4. IC provides a secure and unpredicable source of randomness. So if a developer is really paranoid, they can implement front-running protection in their own canisters (e.g., buffering a set of messages and then random-shuffle them). No one will be able to predict the randomness, and the risk of front-running can be completely mitigated.

Hope this answers your question!

17 Likes
#3

Thank you for your elaborate answer!

#4

IMO MEV issue could be even worse than eth
1, Node onboarding and deployment process is centralized and NOT transparent for public.
2, Subnet scale is small, which means as long as you are operating a node, you have more chances to MEV.
3, Message content is accessible for nodes, no privacy protection in terms of transaction content against block maker. (On another hand, I don’t know a way to access a subnet block history except being a node operator, make it even impossible to know if attacking happened afterward).
4, It’s true that messages are not ordered by gas price but by timestamp, but I don’t see it’s a barrier for block maker to create new messages with manipulated timestamp to insert before or after the target transaction.

Unless I have assertive answers to these concerns, I wouldn’t bet my money on deFi in ICP… in eth at least you know monsters are there and you can see blood trace after they eat people. But in ICP, all things happen behind theme, you have no idea what is going on,

#5

Is this TRUE today on the mainnet? @PaulLiu

#6

No, SEV support has yet to be implemented.