Wait! Reentracies are good now?

Transcript

Hello everyone. Re-entrance have a dangerous reputation. Today I want to show you where reentency can actually be useful and how its use has changed over the past years. I'm Dominic PR uh lead auditor at chain security co-founder together with my colleagues and we've been doing all things of blockchain security since 2017. So now the DA hack has made re-entry infamous. But how does that reputation compare to what contract actually do today? Let's look into the data here. Re-entrance means entering in contract while an earlier call to it is still active. We sampled Ethereum blocks throughout each six month period over the last six years to track what's

actually happening on chain. The top plot shows the shelf transaction with internal calls which involve re-entry. That share rose from about 5% in 2017 to around 20% around T5 summer and roughly to a third by mid 2024. Since then it has been fairly stable. The bottom plot shows the amount of re-entrant calls within one transaction that uses re-entrance C. Earlier it was limited to around two re-entrant calls but lately this spike to up to five re-entrant calls in an average re-entrant transaction. So let's see what's going on. The next plot shows which types of calls are driving the increase in

re-entrance. And the results are clear, right? It's a graph on the top left. It's a normal calls. In orange, we display re-entrant calls which are plain eve transfer. And in green, we have re-entrant calls that simply do a static call which cannot change state. Um, interestingly, the spike in the green curve comes from a few contracts only. Now we look at the same categories but at shares of the detected re-entrren call. 71% are the regular calls. 9% are simple plain e for transfers and greens are static calls. So these static calls are calls. Um when we call a contract further down we are called back into our

contract to read some state. Most often it's reading the balance of our contract. Our last plot shows which contracts are involved here. And here one project stands out. It's unis swap v4. It accounts for around 54% of all transactions using re-entrancy. Now why would a protocol deliberately build around this pattern? Let's look what unis swap v4 does. The benefit is that the router can combine several operation before settling the result. Pool manager calls the router back and the router re-enters the pool manager to perform multiple operations before the operation finally concludes.

For example, the first swap creates a rep credit which is consumed by the second. The rep div stays within the manager. The router pays the initial USDC and gets the final die out. Re-entrancey is what enables this sequencing. Safe gives you a different use case for re-entrance. Here an approved transaction can change the set of signos. Safe checks that the transaction has been signed by the proper set of signos before calling itself in a re-entrant call actually doing the update operation.

Configuration changes therefore pass to the wallet's general authorization function. The boundary here is authorization. So, we saw re-entrance lets us build powerful features. That's amazing, right? But caution, we need to be careful. For example, your own contract can still be totally fine and finish correctly while another protocol loses money because during the re-entry, it trusts a temporary inconsistent state of your contract. Our curve disclosure uses this with a re only re-entry. While curve is mid withdrawal, the recipient calls the lender. The lender reads the virtual price based on this temporary temporary

pool state and values the collateral. Based on this inflated valuation, it lets the borrower receive more tokens than it should have. The ghetto does not change curve state. Curve is totally fine. Curve has no problem and continues executing and finishes correctly. But the third party protocol that trusted this temporary inflated value has a problem now. So yes, re-entrances can be useful by design. We saw it enables composition in unis swap. We saw the authorizer self and safe and you can build many more great things with it. But you need to be careful.

You need to especially be careful what intermediate states other protocols might observe during this inconsistent state. So when you build retrain transis ask what can be called what or others can observe and what must hold before your transaction completes successfully. For the fault curve analysis I put up a QR code to our blog post. And that's it for my talk. Thank you for listening. Thank you so much, Dominic. We're going to do questions now. Anyone has a question and we'll have this wonderful box to ask it.

Who wants the box? All right. Well, Dominic, what made you want to tell us about this redemption story today? So when I started with blockchain right there was right this infamous DAO hack with the re-entrance was used to exploit the contract. I mean back before smart contract existed right back before different actors on the public blockchain interacted with each other the concept of re-entrancey wasn't really known right so back then everyone was surprised and we learned the hard way. Initially when I started everyone was super scared about re-entrancey and try to detect re-entrances but actually now over the years we have learned that

actually using re-entrance on purpose we can build great things and still be secure. So we wanted to see what's actually happening on chain and did some investigations. >> Thank you. >> Thank you. We all like a good uh happy ending don't we? Okay. Is there any more question? Then we wrap it up and move on to the next