Should HyperSDK Programs Prevent Re-Entrancy?

[patrick-ogrady]

Over the last few years, re-entrancy has been used to successfully attack (https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/) a number of smart contracts (like the DAO on Ethereum).

We have the opportunity to disable re-entrancy altogether while building HyperSDK Programs and are currently in search of good reasons not to do so. Please leave a comment if you have any thoughts!

Related Tweet: https://twitter.com/_patrickogrady/status/1686388809272033282

[patrick-ogrady]

How OpenZeppelin contracts protects against re-entrancy in the EVM: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/fa680739e9c29e18670d44ae47dc1bc49de95629/contracts/security/ReentrancyGuard.sol

[patrick-ogrady]

Here are the CosmWASM semantics:

• https://github.com/CosmWasm/cosmwasm/blob/main/SEMANTICS.md
• https://book.cosmwasm.com/actor-model.html

[miohtama]

One of the main cited use cases of re-entrancy is flash loans and it is hard to unbundle this from the re-entrancy. There are other legit re-entrancy use cases, like hooks and such, but on this particular message let's just discuss flashloans:

On flashloans

Flashloan is a tool, a means to end. Currently flashloan use cases include

• Arbitrage without capital (risk free trades and high-frequency trading games)
• Moving loans between different lending protocols (Aave, Compound, etc.)
• Oracle price manipulation and exploits

The question should not be "do we need flashloans" but "What are the beneficial use cases, and how do we enable them or do we need to enable them"

• Better solution to arbitrating is Protocol-owned builders or similar models where any arbitrage opportunity is captured by protocol itself and then paid back to the user, instead of it going to an external arbitrager. Many kind of mechanisms include making this kind of "backrunning of trades" fair, keeping prices is lock and contributing arbitrage opportunity profits back to their creator (a retail trader). Other examples include MEV Blocker, Cowswap, UniswapX.
• Solana has a vibrant DeFi ecosystem without flashloans

Both Solana and Osmosis (and other Cosmos SDK chains) prevent re-entrancy.

[patrick-ogrady]

For context, here is the execution path for interacting with flash loans on AAVE:

• https://docs.aave.com/developers/v/1.0/tutorials/performing-a-flash-loan
• https://docs.aave.com/developers/v/1.0/tutorials/performing-a-flash-loan/...-in-your-project

[miohtama]

For the reference, here is a list of major historical re-entrancy attacks

[patrick-ogrady]

Agoric views: https://www.youtube.com/watch?v=38oTyVv_D9I

Recommended here: https://twitter.com/364mhz/status/1686483058688749568

[patrick-ogrady]

Solana: https://docs.solana.com/developing/programming-model/calling-between-programs#reentrancy

[patrick-ogrady]

Sui example of flash loan with "hot potato" pattern: https://github.com/MystenLabs/sui/blob/main/sui_programmability/examples/defi/sources/flash_lender.move

    /// A "hot potato" struct recording the number of `Coin<T>`'s that
    /// were borrowed. Because this struct does not have the `key` or
    /// `store` ability, it cannot be transferred or otherwise placed in
    /// persistent storage. Because it does not have the `drop` ability,
    /// it cannot be discarded. Thus, the only way to get rid of this
    /// struct is to call `repay` sometime during the transaction that created it,
    /// which is exactly what we want from a flash loan.

[patrick-ogrady]

May be required for EIP-2535:https://eips.ethereum.org/EIPS/eip-2535

Source: https://twitter.com/neirenoir/status/1686458097022156810