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!

14 Likes
#3

Thank you for your elaborate answer!