DEV Community: CertiK

CertiK’s Audit of the XRP Ledger Automated Market Maker - Findings and Review

CertiK — Tue, 11 Jul 2023 12:00:00 +0000

Author: Alexey Malanov, Principal Blockchain Security Expert at CertiK

Introduction

CertiK recently conducted an extensive third-party audit of an Automated Market Maker (AMM) built on the XRP Ledger. In this technical blogpost, we will present some of the key findings from our audit and discuss how Ripple and CertiK collaborated to address these findings. Our objective is to provide valuable insights to current and prospective builders of other AMMs, as well as the developers, users, and stakeholders of the XRP Ledger AMM.

Total Findings: 31

0 Critical, 0 Major, 8 Medium, 12 Minor, 11 Informational

29 Findings Resolved, 2 Minor Issues Acknowledged

About the XRP Ledger AMM

Ripple recognized the need for a non-custodial automated market maker (AMM) to add flexibility to the XRP Ledger. Ripple has chosen the most popular approach $ΓA∗ΓB=k\Gamma_A * \Gamma_B = k$ , that means that the product of asset reserves (pool balances) is preserved by swap operations.

For example, doubling one reserve in a pool via swap, leads to halving of another one.

In general:

(ΓA+ΔA)(ΓB−ΔB)=k(1)(\Gamma_A + \Delta_A)(\Gamma_B - \Delta_B) = k \tag1

Opening brackets we get:

−ΓAΔB+ΔAΓB−ΔAΔB=0(2)-\Gamma_A\Delta_B + \Delta_A\Gamma_B - \Delta_A\Delta_B = 0 \tag2

where,

$ΓA\Gamma_A$ : Reserve of asset A
$ΓB\Gamma_B$ : Reserve of asset B
$ΔA\Delta_A$ : The amount of asset A that comes into the pool
$ΔB\Delta_B$ : The amount of asset B that comes out in return

Taking into account the $TF ee$ taken from the incoming amount, from (2) we get the main formula of the swap:

ΔB=ΓBΔA(1−TFee)ΓA+ΔA(1−TFee)(3)\Delta_B = \Gamma_B \frac{\Delta_A(1-TFee)}{\Gamma_A + \Delta_A(1-TFee)} \tag3

It is also possible to deposit and withdraw liquidity proportionally to current reserves:

If:

ΔAΔB=ΓAΓB=ΓA+ΔAΓB+ΔB=SpotPrice(4)\frac{\Delta_A}{\Delta_B} = \frac{\Gamma_A}{\Gamma_B} = \frac{\Gamma_A + \Delta_A}{\Gamma_B + \Delta_B} = SpotPrice \tag4

Then the user gets:

ΔLPTokens=ΓLPTokensΔAΓA=ΓLPTokensΔBΓB(5)\Delta_{LPTokens} = \Gamma_{LPTokens} \frac{\Delta_A}{\Gamma_A} = \Gamma_{LPTokens} \frac{\Delta_B}{\Gamma_B} \tag5

where,

$ΓLPTokens\Gamma_{LPTokens}$ : Supply of LPTokens before the swap. Initially set as $ΓLPTokensInitial=ΓAΓB\Gamma_{LPTokensInitial} = \sqrt{\Gamma_A \Gamma_B}$ with the first deposit (pool creation).
$ΔLPTokens\Delta_{LPTokens}$ : LPTokens the user gets for the deposit of $(ΔA,ΔB)(\Delta_A,\Delta_B)$ .

For example, if the user doubles both asset reserves, they will get 100% of original $ΓLPTokens\Gamma_{LPTokens}$ , that is 50% of the final total.

Detailed Description and Implementation

Ripple has provided a detailed description of the features in the AMM, which can be found in their repository here.

APP-01 and APP-02: Suboptimal Single Asset Deposit Calculations – Severity: Medium – Status: Resolved

The XRP Ledger AMM allows users to perform a single asset deposit with a AMMDeposit(tfSingleAsset) transaction. This means that some part of the deposit is virtually swapped into another asset and then the usual two-asset deposit is performed. However, our audit revealed that the formulas used by Ripple for single asset deposits had some miscalibrations. Fees were always taken for the half of the deposited asset, and pool value change due to fees was not accounted for. The variable amount should be virtually swapped instead with the corresponding fee taken. As a result, users would benefit from using AMMDeposit(tfSingleAsset) followed by AMMWithdraw(tfLPToken) instead of a normal swap, as it would save on fees.

Perfect Single Asset Deposits

While the single asset deposit feature is not commonly described or implemented in traditional AMMs, it holds significant utility. Let's discuss the proposed logic for a perfect single asset deposit:

1. We want to split the amount $ΔB\Delta_B$ into two parts: $(\Delta_B - x)$ and swap $x$ for $ΔA=ΓAx(1−TFee)ΓB+x(1−TFee)\Delta_A = \Gamma_A \frac{x(1-TFee)}{\Gamma_B + x(1-TFee)}$ (equation (3)).

2. We need to determine $x$ such that the final pool reserves ratio $ΓAΓB+ΔB\frac{\Gamma_A}{\Gamma_B+\Delta_B}$ is equal to both the ratio of assets deposited $ΔAΔB−x\frac{\Delta_A}{\Delta_B - x}$ and the pool reserves ratio after the swap $ΓA−ΔAΓB+x\frac{\Gamma_A - \Delta_A}{\Gamma_B + x}$ (equation (4)).

3. Using the equation $ΓAΓB+ΔB=ΔAΔB−x\frac{\Gamma_A}{\Gamma_B + \Delta_B} = \frac{\Delta_A}{\Delta_B-x}$ and substituting $ΔA\Delta_A$ , we get the equation $(ΔB−x)(ΓB+x(1−TFee))=(ΓB+ΔB)x(1−TFee)(\Delta_B - x)(\Gamma_B + x(1-TFee)) = (\Gamma_B + \Delta_B)x(1-TFee)$ .

4. Solving this equation gives us $\Gamma_B \left(\sqrt{\left(\frac{1-TFee/2}{1-TFee}\right)^2 + \frac{\Delta_B}{\Gamma_B(1-TFee)}} - \frac{1-TFee/2}{1-TFee}\right)$ .

5. After swapping $x$ of AssetB for $ΔA\Delta_A$ of AssetA, we perform the complete assets deposit with $=ΓLPTokensΔB−xΓB+x\Delta_{LPTokens} = \Gamma_{LPTokens} \frac{\Delta_A}{\Gamma_A - \Delta_A} = \Gamma_{LPTokens} \frac{\Delta_B-x}{\Gamma_B + x}$ (equation (5)).

The final formula for the perfect single asset deposit is:

\Delta_{LPTokens} = \Gamma_{LPTokens} \frac{\Delta_B-x}{\Gamma_B + x} = \Gamma_{LPTokens} \frac{ \frac{\Delta_B}{\Gamma_B} - \left(\sqrt{ \left( \frac{1-TFee/2}{1-TFee} \right) ^2 + \frac{\Delta_B}{\Gamma_B(1-TFee)}} - \frac{1-TFee/2}{1-TFee} \right) }{1 + {\sqrt{ \left( \frac{1-TFee/2}{1-TFee} \right) ^2 + \frac{\Delta_B}{\Gamma_B(1-TFee)}} - \frac{1-TFee/2}{1-TFee} } }

Example

Let's consider an example with a significant $TF ee$ .
Let $ΔB=ΓB\Delta_B = \Gamma_B$ , $50\%$ .

The formula used by the XRP Ledger AMM gave $≈32.3%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} = \sqrt{ 1+\frac{\Delta_B(1- TFee/2) }{\Gamma_B} } - 1 = \sqrt{1+1-0.25} - 1 \approx 32.3\%$ of LPTokens.

The proposed approach recommends:

swapping $56.2%\frac{x}{\Gamma_B} = \sqrt{ \frac{1-0.25}{1-0.5}^2 + \frac{1}{1-0.5} } - \frac{1-0.25}{1-0.5} = \sqrt{1.5^2 + 2} - 1.5 \approx 56.2\%$ of AssetB
for $21.9%\frac{\Delta_A}{\Gamma_A} = \frac{\Delta_B 0.5}{\Gamma_B + \Delta_B 0.5} \approx \frac{56.2\%/2}{100\% + 56.2\%/2} \approx 21.9\%$ of AssetA
then depositing $(21.9%,43.8%)(21.9\%, 43.8\%)$ into the pool with $(78.1%,156.2%)(78.1\%, 156.2\%)$ gives $28%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} = \frac{\Delta_B-x}{\Gamma_B+x} \approx \frac{43.8\%}{156.2\%} \approx 28\%$ of LPTokens.

In other words, a single asset deposit (followed by immediate two-asset withdrawal) is more advantageous than a normal swap and would be preferred by users.

There is no difference with zero $TF ee$ .
Let $ΔB=ΓB\Delta_B = \Gamma_B$ , $0\%$ .

The formula used by the XRP Ledger AMM gave $≈41.4%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} = \sqrt{ 1 + \frac{\Delta_B}{\Gamma_B} } - 1 = \sqrt{2} - 1 \approx 41.4\%$

The proposed approach recommends:

swapping $xΓB=1+ΔBΓB−1=2−1≈41.4%\frac{x}{\Gamma_B} = \sqrt{ 1 + \frac{\Delta_B}{\Gamma_B} } - 1 = \sqrt{2} - 1 \approx 41.4\%$ of AssetB for $29.3%29.3\%$ of AssetA first
then depositing $(29.3%,58.6%)(29.3\%, 58.6\%)$ into pool with $(70.7%,141.4%)(70.7\%, 141.4\%)$
giving the pool in state $(100%,200%)(100\%, 200\%)$ and $ΔLPTokensΓLPTokens≈58.6%141.4%≈41.4%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} \approx \frac{58.6\%}{141.4\%} \approx 41.4\%$ of LPTokens - same amount

And with a reasonable $TF ee$ .
Let $ΔB=ΓB\Delta_B = \Gamma_B$ , $1\%$ .

The formula used by the XRP Ledger AMM gave $≈41.244%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} = \sqrt{ 1 + \frac{0.995\Delta_B}{\Gamma_B} } - 1 = \sqrt{1.995} - 1 \approx 41.244\%$

The proposed approach recommends:

swapping $41.63%\frac{x}{\Gamma_B} = \sqrt{ \left(\frac{0.995}{0.99}\right)^2 + \frac{\Delta_B}{0.99\Gamma_B} } - \frac{0.995}{0.99} \approx \sqrt{2.02} - 1.005 \approx 41.63\%$ of AssetB for $29.2%29.2\%$ of AssetA first
then depositing $(29.2%,58.4%)(29.2\%, 58.4\%)$ into the pool with $(70.8%,141.6%)(70.8\%, 141.6\%)$
resulting in the pool state of $(100%,200%)(100\%, 200\%)$ and $≈41.21%\frac{\Delta_{LPTokens}}{\Gamma_{LPTokens}} \approx \frac{58.4\%}{141.6\%} \approx 41.21\%$ of LPTokens.

In summary, with a reasonable $TF ee$ , the difference in LPTokens between the two approaches is negligible (41.244% vs. 41.21%). Therefore, addressing this issue aims to provide consistency rather than substantial impact.

Additional Observations

We also observed that balancer.fi initially employed the same approach as Ripple in the XRP Ledger AMM.

Also CertiK regularly conducts audits on Solidity projects that perform single asset deposits via Uniswap-like AMMs. They do it the same wrong way we have just described: half of the asset is first swapped via the pool for ETH, then another half and swapped ETH are deposited via addLiquidityETH().

        // swap tokens for ETH
        swapTokensForEth(half); 

        // how much ETH did we just swap into?
        uint256 newBalance = address(this).balance.sub(initialBalance);

        // add liquidity to uniswap
        addLiquidity(otherHalf, newBalance);

SafeMoon's implementation of swapAndLiquify()

Since during the first swap the pool reserve ratio has changed, "halves" no longer can be deposited completely, small share of ETH will be returned back by AMM. If the contract doesn't provide a way to withdraw those ETHs, they will be locked in the contract forever.

AMD-01: Protection from Front-Running – Severity: Medium – Status: Resolved

Our audit also highlighted the importance of protecting against front-running attacks targeting users of the XRP Ledger AMM. Consider a scenario where an attacker can steal the funds of a liquidity provider.

Let the pool have (1000 TokenA, 1000 TokenB) with a fair price 1:1. Let the trading fee be 0 for simplicity.
The Victim wants to AMMDeposit(tfTwoAsset, 100 TokenA, 100 TokenB). They expect to get 10% of existing LPTokens.
However, the Attaker swaps 9000 TokenB for 900 TokenA leaving the pool in state (100 TokenA, 10000 TokenB).
Since two-assets deposit must preserve the spot price (pool reserves ratio), AMMDeposit only takes (1 TokenA, 100 TokenB), moves the pool in the state (101 TokenA, 10100 TokenB), and gives 1% of LPTokens in return.
The Attacker swaps back 909 TokenA for 9090 TokenB, leaving the pool in the state (1010 TokenA, 1010 TokenB) with the original price.
The Attacker gets 9090 - 9 - 9000 = 81 TokenB profit. That was effectively stolen from the Victim.
The Victim gets 99 TokenA and 1% LPTokens instead of the expected 10% LPTokens.

This is a well-known potential issue for all AMMs.

Other AMM implementations, such as Uniswap, allow the user to set the minimum amounts accepted:

    function addLiquidity(
        address tokenA,
        address tokenB,
        uint amountADesired,
        uint amountBDesired,
        uint amountAMin,
        uint amountBMin,
        address to,
        uint deadline

Uniswap’s declaration of addLiquidity().

If amountAMin/amountBMin conditions are not satisfied, the transaction is rejected. This effectively protects the user from front-running and sudden pool spot-price changes for other reasons.

The initial design of the AMM had no similar protection. AMMDeposit(tfTwoAsset) allowed specifying amount and amount2, but they were used as maximum values consumed by the deposit operation.

Ripple heeded our advice and mitigated the issue as recommended.

AMV-01 and AMV-02: Voting on the Trading Fee – Severity: Minor – Status: Acknowledged

In the XRP Ledger AMM, the TradingFee parameter is subject to voting. Any account holding the corresponding LPTokens has the ability to cast a vote using the AMMVote transaction. The voting power is determined by the balance of LPTokens held. During the processing of AMMVote, the weights of all the votes are recalculated, and the TradingFee for the AMM instance is updated. The system remembers the votes of the top eight largest holders.

However, the voting mechanism can be susceptible to manipulation in a number of ways. Let's consider a few scenarios:

Exploiting Fees: A well-capitalized actor can exploit the system by conducting trades without incurring fees. Here's an example:
- The "Griefer" holds significant balances of TokenA and TokenB but wishes to rebalance their portfolio.
- The Griefer calls AMMDeposit(tfTwoAsset) with substantial amounts.
- Leveraging their significant LPTokens balance, the Griefer submits AMMVote(0%) to minimize the impact of fees.
- The Griefer executes the desired swap operation with minimal fees.
- Finally, the Griefer performs AMMWithdraw(tfTwoAsset) to retrieve their tokens, effectively utilizing quick liquidity deposits to avoid or minimize fees.
Vote Manipulation: A well-capitalized actor can exert influence over the voting process to the detriment of other voters. Let's examine a scenario:
- Suppose the Griefer has a weight of 81, while other traders have weights of 10 each, totaling 70.
- According to the distribution, the Griefer should have only 54% voting power.
- However, by dividing their LPTokens equally among 8 accounts and casting votes from each account, the Griefer can push out other voters, obtaining 100% voting power.
- Once the Griefer has achieved this, they can consolidate the LPTokens back into a single account.
Voting Slot Occupation: Voting slots are only updated if a voter becomes an active participant. Here's a scenario illustrating this:
- The Griefer obtains a significant amount of LPTokens through AMMDeposit.
- They divide the LPTokens equally into 8 parts, distributing them among 8 accounts, and cast AMMVote(maximum fee) from each account.
- As a result, all 8 voting slots are now occupied by accounts with substantial weights.
- Afterward, the Griefer combines the LPTokens and performs AMMWithdraw, retrieving their funds.
- Consequently, until someone obtains a significant LPTokens balance, no one can refresh the votes array.
Determining the final fee is achieved by calculating a weighted average of all the votes. However, this can lead to a situation where voters struggle to set their desired fee value due to the influence of other voters. For instance:
- Suppose a voter with a weight of 10 wishes to set the fee to 0.5%.
- At that moment, other voters with a cumulative weight of 10 have voted for a 1% fee.
- In order to attain the desired 0.5% fee, the voter is compelled to submit AMMVote(0%).
- If, over time, other voters change their desired fee to 0%, the voter must resubmit AMMVote(1%) to maintain the desired 0.5% fee.
- As a result, the voter cannot directly set the desired fee but must instead strike a balance that accommodates the preferences of other voters. This dynamic can be likened to a tug of war game.

Despite these strategies enabling users to utilize the voting feature in ways that were not originally intended, we have consulted with Ripple and decided against introducing additional constraints or altering the design. Among the scenarios mentioned, only the third one could be addressed without significant modifications, and appropriate measures were taken.

Nevertheless, analyzing potential strategies and scenarios is crucial for conducting a comprehensive risk assessment of the system.

Conclusion

The audit of the XRP Ledger AMM revealed findings specific to the project, with varying levels of severity. Of 32 identified issues, 30 were resolved as recommended, and two minor issues were acknowledged. It is common for large projects to have some implementation quirks that can be refined. Our collaboration with Ripple ensured that these findings were thoroughly evaluated and appropriate actions were taken to improve the overall security, consistency, and user experience of the XRP Ledger AMM.

By presenting these findings and the collaborative efforts between Ripple and CertiK, we aim to provide valuable insights to developers and stakeholders, enhancing the understanding of the XRP Ledger AMM's inner workings and promoting its continuous improvement.

Disclaimer: The findings and recommendations in this blogpost are based on the audit conducted by CertiK at the time of the evaluation. As technology evolves, it is essential to keep pace with updates and advancements in the field. We encourage ongoing security assessments and collaborations between project teams and security experts to ensure the highest level of security for blockchain-based systems.

Analyzing the HamsterWheel: An Advanced State Management Vulnerability in Sui's Blockchain Architecture

CertiK — Tue, 20 Jun 2023 00:42:23 +0000

CertiK’s Skyfall team identified and disclosed a series of denial of service vulnerabilities in the Sui blockchain. Among these vulnerabilities, a new type of bug stood out due to its critical severity implications which could cause the Sui network to not be able to process new transactions, effectively causing a total network shutdown. This unique attack, different from previous known ones, allows an attacker to induce an infinite loop in the validator node by merely submitting a small payload of approximately 100 bytes. Moreover, this attack creates persistent damage that endures even after the validator network reboots. We've dubbed this unique type of attack "HamsterWheel.”

Upon discovery, we responsibly reported this vulnerability to Sui through their bug bounty program. Sui's response was prompt and efficient. They confirmed the critical severity of the vulnerability and took steps to address the issue before the network’s mainnet launch. In addition to fixing this particular vulnerability, Sui also implemented preventative mitigations to lessen the potential damage caused by exploitation.

In appreciation for the responsible disclosure, Sui network awarded a $500,000 bounty award to CertiK Skyfall team.

In this blog post, we will disclose the technical aspects of this critical vulnerability, shedding light on its root cause and potential impact.

The Vulnerability In Detail

The Critical Role of Verifiers in Sui

In Move-based blockchains, such as Sui and Aptos, the safeguarding mechanism against malicious payloads rests heavily on static verification techniques. These techniques inspect user-submitted payloads before a contract is either published or upgraded on the chain. With checkers ensuring both structural and semantic correctness, the Move runtime presumes their soundness.

Figure 1: The threats of malicious payloads on Move-based chains

Sui implements a memory model that is distinct from the original Move design, deploying a customized version of Move VM for contract development. Sui goes the extra mile in strengthening its safety measures against malformed payloads. It introduces additional, customized verifiers, dubbed as Sui verifiers. These specialized verifiers cater to Sui's unique features, such as object safety and global storage access safety, among others.

Figure 2: Sui's sequence of checks against the payload

Most verifiers conduct structural assessments against the CompiledModule, the runtime representation of user-provided contract payloads. For instance, duplication-checker ensures no duplicate entries in each section, while limits-checker affirms the upper bounds of entries allowed in each section. However, more complex analyses are necessary for static checking to guarantee the semantic soundness of the untrusted payloads.

Understanding Move's Abstract Interpreter: Linear and Iterative Analysis

The Abstract Interpreter, furnished by Move, is a framework specially designed for executing complex security analysis on bytecode via abstract interpretation. This mechanism enables a more refined and accurate verification process, with each verifier being allowed to define their unique abstract state for the analysis.

Beginning its operation, the Abstract Interpreter constructs Control Flow Graphs (CFGs) from compiled modules. Each Basic Block within these CFGs maintains a set of states, namely, pre-state and post-state. The pre-state offers a snapshot of the program prior to the execution of a Basic Block, while the post-state provides an image of the program after the Basic Block's execution.

When the Abstract Interpreter encounters no backedge (or loop) in the Control Flow Graph, it follows a simple linear execution. Each BasicBlock is analyzed in sequence, with the pre-state and post-state calculated based on the semantics of each instruction within the block. The result is an accurate snapshot of the program's state at each point in the execution, which aids in verification of the program's safety properties.

Figure 3: Move Abstract Interpreter’s workflow

However, when loops are present in the control flow, the process becomes more complex. Backedges, which signal the presence of loops, require the Abstract Interpreter to carefully manage the merging of states. This is due to the interdependence between the state at the start of the loop (the pre-state of the loop header) and the state at the end of the loop (the post-state of the loop footer).

In handling backedges, the Abstract Interpreter meticulously merges the pre-state of the target Basic Block with the post-state of the current Basic Block. If discrepancies are detected in the resulting merged state, the Abstract Interpreter initiates a re-analysis, beginning from the target Basic Block with the updated merged state.

This iterative analysis process continues until the loop's pre-state stabilizes. In other words, the process is repeated until the pre-state of the loop header no longer changes between iterations, indicating that a fixed point has been reached and the analysis of the loop is complete.

Sui’s IDLeak Verifier: Customized Abstract Interpretation Analysis

Sui's blockchain platform introduces a unique object-centric global storage model, which differentiates it from the original Move design. A distinctive feature of this model is that any struct with a 'key' ability must initiate with an ID field with the ID type. The ID field is immutable and cannot be transferred to other objects, as each object must have a unique ID. To ensure this, Sui utilizes custom analysis built upon the Abstract Interpreter.

/// Sui object identifiers
module sui::object {
    ...
    struct UID has store {
        id: ID,
    }
    struct ID has copy, drop, store {
        bytes: address
    }
}

/// Sui object example
struct A has key {
    id: UID,
    b: B,
}

The IDLeak Verifier, alternatively known as the id_leak_verifier, operates in concert with the Abstract Interpreter to conduct its analysis. It forms its distinct AbstractDomain, termed as AbstractState, to oversee the status of each local variable using an AbstractValue. This value denotes whether the ID is fresh. During the process of struct packing, the IDLeak Verifier checks that only a fresh ID is allowed to be packed into a structure. It meticulously traces the data flow of local states to ensure that no existing ID is transferred to other objects.

The State Management Inconsistency in Sui IDLeak Verifier

The IDLeak Verifier integrates with the Move Abstract Interpreter by implementing the AbstractState::join function. This function plays integral roles in state management, notably in merging and updating state values. Let's examine these functions in detail to understand their operation.

enum AbstractValue {
    Fresh,
    Other,
}

pub(crate) struct AbstractState {
    locals: BTreeMap<LocalIndex, AbstractValue>,
}

impl AbstractDomain for AbstractState {
    /// attempts to join state to self and returns the result
        fn join(
        &mut self,
        state: &AbstractState,
        _meter: &mut impl Meter,
    ) -> Result<JoinResult, PartialVMError> {
        let mut changed = false;
        for (local, value) in &state.locals {
            let old_value = *self.locals.get(local).unwrap_or(&AbstractValue::Other);
            changed |= *value != old_value;  // determines the return value.
            self.locals.insert(*local, value.join(&old_value));  // update state value.
        }
        if changed {
            Ok(JoinResult::Changed)
        } else {
            Ok(JoinResult::Unchanged)
        }
    }
}

In AbstractState::join, the function takes another AbstractState as input and attempts to merge its local state with the current object's local state. For each local variable in the incoming state, it compares the variable's value to its current value in the local state (with a default value of AbstractValue::Other if not found). If the two values are unequal, it sets a 'changed' flag and updates the local variable's value in the local state by calling AbstractValue::join.

impl AbstractValue {
    pub fn join(&self, value: &AbstractValue) -> AbstractValue {
        if self == value {
            *value
        } else {
            AbstractValue::Other
        }
    }
}

In AbstractValue::join, the function compares its value with another AbstractValue. If they are equal, it returns the incoming value. If not, it returns AbstractValue::Other.

However, the conjunction of these functions can lead to a potential inconsistency. Although AbstractState::join may indicate a change (JoinResult::Changed) due to differing old and new values, the state value after the update might remain the same. This anomaly occurs due to the order of operations: the determination of changed status in AbstractState::join happens before AbstractValue::join, which doesn't reflect the genuinely updated state value. Besides, in AbstractValue::join, AbstractValue::Other dominates the joined result. Thus, if the old value is AbstractValue::Other and the new value is AbstractValue::Fresh, the updated state value remains unchanged as AbstractValue::Other.

Figure 4: A concrete example illustrating the inconsistency in State Join

This introduces an inconsistency where the Basic Block state is marked as changed, but the state value itself remains unchanged. Such inconsistency can potentially have significant implications. To understand why, it's crucial to recall the abstract interpreter's behavior in the presence of a loop within the Control Flow Graph (CFG). When encountering a loop, the abstract interpreter employs an iterative approach to merge the target (backedge) and current state. If the joined state changes as a result of this merge, the abstract interpreter triggers a reanalysis.

However, if the join operation falsely flags the state as changed, when in reality no change in value has occurred, it could lead to an endless cycle of reanalyses.

Beyond the Inconsistency: Triggering Infinite Analysis in Sui IDLeak Verifier

Leveraging this inconsistency, an attacker could craft a malicious control flow graph that tricks the IDLeak verifier into an infinite loop. The crafty control flow graph would consist of three basic blocks, BB1 and BB2, BB3. We intentionally introduce a backward edge from BB3 to BB2.

Figure 5: Malicious CFG + State construction that can cause deadloop inside IDLeak verifier

The process starts with BB2, where the AbstractValue for a particular local variable is set to ::Other. After executing BB2, the flow moves to BB3, where the same variable is set to ::Fresh. At the end of BB3, there's a backward edge that leads back to BB2.

Here's where inconsistency plays a crucial role. When the backward edge is processed, the AbstractInterpreter attempts to join the post-state of BB3 (where the variable is 'Fresh') with the pre-state of BB2 (where the variable is 'Other'). The AbstractState::join function notices the difference and sets the 'changed' flag, signaling that reanalysis of BB2 is necessary. However, the dominating behavior of 'Other' in AbstractValue::join means that the actual state of the variable remains 'Other'.

So, when the verifier continues to reanalyze BB2, along with all its successors (BB3 in this case). This looping process, once initiated, continues indefinitely. The verifier consumes all available CPU cycles, effectively causing a deadlock in transaction processing – a situation that persists even after a validator reboot. This cleverly crafted vulnerability, which we've termed the "HamsterWheel" attack, effectively brings the Sui validator to a halt.

With the conceptual attack scenario delineated and all pre-assumed verifier checkers validated, we successfully demonstrate the exploit by constructing a concrete example using the following Move bytecodes:

code = vec![
    // BB0: offset 0    locals = () 
    CopyLoc(1), 
    Call(FunctionHandleIndex::new(2)),      // new_id, stack.top = ::Fresh
    Pack(StructDefinitionIndex::new(0)),    // consume the fresh ID
    Unpack(StructDefinitionIndex::new(0)),  // unpacked id, stack.top = ::Other
    StLoc(2),                               // locals (2 => ::Other)
    Branch(6), 

    // BB1: offset 6
    MoveLoc(2), 
    Call(FunctionHandleIndex::new(1)),   // delete_id, discard local 2
    CopyLoc(1), 
    Call(FunctionHandleIndex::new(2)),   // prepare tmp_object for BB transition
    Pack(StructDefinitionIndex::new(0)), 
    StLoc(3),
    Branch(13),  

    // BB2: offset 13
    MoveLoc(3),
    Unpack(StructDefinitionIndex::new(0)),  // unpacked id, stack.top = ::Other
    Call(FunctionHandleIndex::new(1)),      // delete id, discard the tmp_object
    CopyLoc(1), 
    Call(FunctionHandleIndex::new(2)),      // new id,  stack.top = ::Fresh
    StLoc(2),                               // locals (2 => ::Fresh)
    Branch(6) 
];

The demonstration highlights the vulnerability in practice. It showcases how, through the careful crafting and manipulation of bytecodes, an attacker can trigger an infinite loop in the IDLeak verifier, where a mere 100 byte payload can consume all available CPU cycles, effectively blocking the processing of new transactions and resulting in a denial of service on the Sui validator.

The HamsterWheel Attack Causes Persistent Damage to the Blockchain Network

According to the bug bounty conditions set by Sui, for a vulnerability to reach the level of critical severity, it must exhibit a capacity to bring the entire network to a halt, impeding new transaction confirmations and requiring a hard fork for resolution. Lesser impacts, such as partial denial of service, can at best qualify as medium or high severity based on the parameters of the bug bounty program.

The HamsterWheel attack discovered by the CertiK Skyfall team carries an immense threat due to its potential to shut down the entire Sui network, an impact that earns it the classification of critical severity. To understand the gravity of this flaw, it is necessary to comprehend the intricate architecture of Sui's backend system, specifically the steps leading up to the publishing or upgrading of a transaction on the chain.

Figure 6: Outline of interactions to commit a transaction in Sui

Initially, user transactions are directed towards the Sui authorities via a Frontend RPC and pre-validation process. The Sui authorities are responsible for validating the incoming transactions. Following successful validation of the user's signature, the transactions are converted into the formation of transaction certificates.

These certificates, integral to the functioning of the network, are then propagated across the validator nodes. Before the transaction can be published or upgraded on the chain, the validator nodes scrutinize these certificates for validity. It's during this crucial stage of verification that the discovered 'deadloop' vulnerability can be exploited.

When the flaw is triggered, it leads to an indefinite hang in the verification process. It effectively hampers the ability of the system to process new transactions, causing a total network shutdown. The criticality of this vulnerability is further magnified as it persists even after a validator reboot, meaning conventional mitigations are insufficient. The exploitation of this vulnerability hence leads to a 'persistent damage' scenario, leaving a lasting impact on the entire Sui network.

Sui’s Approach to Mitigation

In response to the vulnerability, Sui confirmed the vulnerability in a timely manner and released a fix to address the critical flaw. The fix ensures consistency between the state change and the changed flag, eliminating the critical impact caused by the critical HamsterWheel attack.

// sui-verifier/src/id_leak_verifier.rs
impl AbstractDomain for AbstractState {
    /// attempts to join state to self and returns the result
    fn join(
        &mut self,
        state: &AbstractState,
        _meter: &mut impl Meter,
        meter: &mut impl Meter,
    ) -> Result<JoinResult, PartialVMError> {
          let mut changed = false;
       for (local, value) in &state.locals {
            let old_value = *self.locals.get(local).unwrap_or(&AbstractValue::Other);
-           changed |= *value != old_value;
-           self.locals.insert(*local, value.join(&old_value));
+           let new_value = value.join(&old_value);
+           changed |= new_value != old_value;
+           self.locals.insert(*local, new_value);
        }
     ...
    }
}

In order to eliminate the aforementioned inconsistency, Sui's fix consisted of a minor but crucial adjustment to AbstractState::join function. Instead of determining the changed result prior to the execution of AbstractValue::join, this fix ensures that the AbstractValue::join is carried out first. Subsequently, the changed flag is set by comparing the result of AbstractValue::join with the old_value. This way, the changed flag correctly represented whether a change was made in the final state value.

In addition to fixing this specific vulnerability, Sui also deploys mitigations to reduce the impact of future verifier vulnerabilities. According to Sui’s reply in the bug report, the mitigation is involved with a feature called Denylist.

“However, validators have a node config file that allows them to temporarily denylist certain classes of transactions. This config can be used to temporarily disable processing publishing and package upgrades. Since the bug happens while running the Sui verifier before signing a publish or package upgrade tx, and denylisting will stop the verifier from being run + drop the malicious tx on the floor temporarily denylisting these tx types is a 100% effective mitigation (though it will temporarily interrupt service for folks attempting to publish or upgrade code).

As a side note, we have had this tx denylist config file for awhile, but we also added one for certificates as a follow up item to the "validator deadloop" bug you previously reported. With this mechanism in place, we would be much more resilient to that attack: we would use the certificate denylist config to make validators forget about the bad cert (breaking the crash loop), and the tx denylist config to disable publishing/upgrades and thus prevent creation of new transactions of death. Thanks for making us think about this!”

Validators have a finite number of "ticks" (different from gas) to spend on bytecode verification before signing a transaction, if all bytecode being published in a transaction cannot be verified in that many ticks, the validator will refuse to sign the transaction, preventing it from being executed on the network. Previously, metering only applied to a chosen set of complicated verifier passes. In response to this issue, we extended metering to every verifier pass, to guarantee a bound on the work a validator performs during verification per tick. We also fixed the underlying infinite loop bug in the ID Leak verifier pass.

To summarize, the Denylist enables validators to temporarily circumvent the verifier routine by disabling the publishing or upgrading processes, effectively preventing some potential disruptions from problematic transactions. Given the Denylist mitigation in place, validators should remain operational with only a portion of their functionality disabled when facing verifier panics.

Timeline

April 27, 2023: CertiK reports the vulnerability to Sui.
April 28, 2023: Sui confirms the vulnerability, severity is pending for confirmation.
April 28, 2023: Sui patched the vulnerability in commit 7915de5.
April 30, 2023: Sui confirms the severity as CRITICAL.
May 16, 2023: Sui pays the bug bounty reward.

Conclusion

In this blog post, we delved into the technical aspects of the HamsterWheel attack identified by the CertiK Skyfall team. We explained how this innovative form of attack leverages a critical vulnerability to result in a complete network shutdown of the Sui blockchain. Additionally, we took a closer look at Sui's timely responses to fix this critical issue, sharing their approach to mitigate the Sui blockchain against future threats.

Gas Optimization in Ethereum Smart Contracts: 10 Best Practices

CertiK — Fri, 09 Jun 2023 17:17:22 +0000

Gas fees on the Ethereum mainnet have been a persistent concern, especially at times of network congestion. High demand for blockspace means high transaction fees for users. Therefore, it is crucial to optimize smart contracts and reduce gas consumption during the contract development phase. Gas optimization can lead to lower transaction costs and improved efficiency, ultimately providing a more affordable and accessible blockchain experience for users.

This article gives an overview of the Ethereum Virtual Machine's (EVM) gas mechanism, associated key concepts underlying gas optimization, as well as best practices for gas optimization when developing smart contracts.

A Brief Introduction to the EVM's Gas Mechanism

On EVM-compatible networks, "gas" refers to the unit that measures the computational effort required to execute specific operations.

The following diagram illustrates the layout of the Ethereum Virtual Machine. Here, we can see that the gas consumption is divided into three parts: operation execution, external message calls, and reading and writing from memory and storage.

Source: Ethereum.org

Since each transaction requires computational resources to execute, fees are charged to prevent endless loops and DoS attacks. The payment required to complete a transaction is referred to as the "gas fee".

After EIP-1559 (the London hardfork) went alive, the gas fee is calculated via the following formula:

Gas fee = units of gas used * (base fee + priority fee)

The base fee is burnt and the priority fee serves as an incentive for validators to add transactions to the blockchain. Setting a higher priority fee when sending a transaction can increase the likelihood of it being included in the next block. This functions as a sort of "tip" from a user to a validator.

Understanding Gas Optimization in the EVM

When a smart contract is compiled in Solidity, it is converted into a series of "operation codes", also referred to as opcodes.

Any given fragment of opcode (for example, creating contracts, making message calls, accessing account storage, and executing operations on the virtual machine) has a universally agreed cost in terms of gas, which is recorded in the Ethereum yellow paper.

After several EIPs, some of these gas costs have been changed and might have deviated from the yellow paper. For the latest information regarding costs associated with each opcode, see here.

The Fundamental Concept Behind Gas Optimization

The fundamental concept behind gas optimization is to prioritize cost-efficient actions and avoid expensive ones in terms of gas costs on EVM blockchains.

Cheap operations in the EVM include:

Reading and writing memory variables
Reading constants and immutable variables
Reading and writing local variables
Reading calldata variables such as calldata arrays and structs
Internal function calls

Expensive operations include:

Reading and writing state variables that are stored in contract storage
External function calls
Loops

EVM Gas Optimization Best Practices

In light of the fundamental concept mentioned above, we have compiled a list of gas optimization best practices for the developer community's reference. By following these practices, developers can reduce the gas consumption of their smart contracts, lower transaction costs, and create more efficient and user-friendly applications.

1: Minimize Storage Usage

In Solidity, Storage is a finite resource and is much more expensive in terms of gas usage compared to Memory. Each time a smart contract reads from or writes to storage, it incurs significant gas costs.

As defined in the Ethereum yellow paper, storage operations are over 100x more costly than memory operations. OPcodes mload and mstore only cost 3 gas units while storage operations like sload and sstore cost at least 100 units, even in the most optimistic situation.

Some ways to limit storage usage include:

Non-permanent data can be stored in Memory
Reduce Storage modifications by saving intermediate results in Memory and assign results to Storage variables only after all calculations are completed

2: Variable Packing

The number of Storage slots used and the ways developers represent the data in the smart contract affects gas usage heavily.

The Solidity compiler will pack contiguous storage variables during the compilation process, and use a 32-bytes slot as the base unit for variable storage. Variable packing means arranging variables so that multiple variables can fit in a single slot.

On the left is a poor implementation that will consume 3 storage slots. On the right is a much more efficient implementation.

By making this minor adjustment, developers can save 20,000 units of gas (it costs 20,000 gas to store a storage slot that hasn't been used before), as it will now only require two slots for storage.

Since each storage slot costs gas, variable packing helps optimize gas usage by reducing the number of slots needed.

3: Save on Data Types

One variable can be represented by multiple data types, but different data types have different operation costs. Choosing the most appropriate type will help optimize gas usage.

For instance, in Solidity, integers can be broken down into different sizes: unit8, unit16, unit32, and so on. Since the EVM performs operations in 256-bit chunks, using uint8 means the EVM has to first convert it to uint256. This conversion costs extra gas.

We can use the code in this graph to compare the gas cost for uint8 and uint256. The UseUint() function costs 120,382 gas units, while UseUInt8() costs 166,111 gas units.

In isolation, using uint256 is cheaper than uint8 here. But we also prviously recommended variable packing. If developers can pack four uint8 variables in one slot, the total cost of iterating through them will be cheaper than 4 uint256 variables. The smart contract can then read/write a storage slot once and put four uint8 variables in memory/storage in a single operation.

4: Use Fixed-Size Variables Instead of Dynamic

Using bytes32 datatype instead of bytes or strings is recommended if the data can fit in 32 bytes. In general, any fixed-size variable is less expensive than a variable-size one. If the length of bytes can be limited, use the lowest amount possible from bytes1 to bytes32.

5: Mapping vs Array

In Solidity, lists of data can be represented using two data types: arrays and mappings. However, their syntax and structure are quite different.

Mappings are more efficient and less expensive in most cases, while Arrays are iterable and packable. Therefore, it is advised to utilize mappings for managing lists of data, except when iteration is required or it is possible to pack data types.

6: Use Calldata Instead of Memory

Variables declared as function parameters are either stored at calldata or memory. One key difference between memory and calldata is that memory can be modified by the function, while calldata is immutable.

Here the principle is to use calldata instead of memory if the function argument is read-only. This avoids unnecessary copies from function calldata to memory.

In this example, which uses the memory keyword, the array values are kept in encoded calldata and are copied to memory during ABI decoding. The execution cost is 3,694 gas units for this code block.

In the second example, the value is directly read from calldata and there are no intermediate memory operations. This adjustment results in an execution cost of only 2,413 gas units for this code block, marking a 35% improvement in gas efficiency.

7: Use Constant/Immutable Keywords Whenever Possible

Constant/Immutable variables are not stored in contract storage. These variables are evaluated at compile-time and are stored in the bytecode of the contract. Therefore they are much cheaper to access compared with storage and it is recommended to use Constant / Immutable keywords whenever possible.

8: Use Unchecked When Under/Overflow is Impossible

When developers are certain that an arithmetic operation will not result in overflow or underflow, they can use the unchecked keyword introduced in Solidity v0.8.0, to avoid redundant arithmetic underflow/overflow checks and save on gas costs.

In the example below, the variable i can never overflow due to the conditional constraint i < length. Here, length is defined as uint256, meaning the maximum value i can reach is max(uint) - 1. Therefore, incrementing i within an unchecked block is deemed safe and is more gas-efficient.

Furthermore, the SafeMath library is no longer needed for compiler versions 0.8.0 and above, as overflow and underflow protection is now built into the compiler itself.

9: Modifier Optimization

The code of modifiers is placed in a modified function, and modifier code is copied in all instances where it's used. This will increase bytecode size and gas usage.

Below is one way to optimize modifier gas cost.

Before:

After:

In this example, a refractor is done to the internal function _checkOwner(), allowing the internal function to be reused in modifiers. This method saves bytecode size and gas cost.

10: Short-Circuit

In the case of ||and && operators, the evaluation is short-circuited, meaning the second condition is not evaluated if the first condition already determines the result of the logical expression.

To optimize for lower gas usage, arrange conditions so that the less expensive computation is placed first. This could potentially bypass the execution of the more expensive computation.

Bonus General Recommendations

Remove Useless Code

If a contract has functions or variables that aren't used, it is advisable to remove them. This is the most straightforward way to reduce contract deployment costs and help keep the contract size small.

Here are some practical recommendations:

Utilize the most efficient algorithms for performing computations. If the results of certain computations are directly used in the contract, consider removing these redundant calculations. In essence, any unused calculations should be eliminated.
In Ethereum, developers are rewarded with a gas refund for freeing up storage space. If a variable is no longer needed, developers should remove it using the 'delete' keyword or set it to its default value.
Loop optimization: such as avoiding expensive loop operation, combining loops if possible, and moving repeated computation out of the loop.

Use Precompiled Contracts

Precompiled contracts provide complex library functions such as encryption and hashing. They require less gas because the code doesn't run on the EVM. Instead, it runs locally on the client node. Using precompiled contracts can save gas by reducing the amount of computational work required to execute a smart contract. Some examples of precompiled contracts include the Elliptic Curve Digital Signature Algorithm (ECDSA) and SHA2-256 hashing algorithm. By utilizing these precompiled contracts in smart contracts, developers can reduce gas costs and improve the efficiency of their application.

See here for a comprehensive list of precompiled contracts supported by the Ethereum network.

Use In-Line Assembly Code

In-line assembly allows developers to write low-level, efficient code that can be executed directly by the EVM without the need for expensive Solidity opcodes. In-line assembly also allows for more precise control over memory and storage usage, which can further reduce gas costs. Additionally, in-line assembly can be used to perform complex operations that would be difficult to achieve with Solidity alone, providing more flexibility for optimizing gas usage.

The following is a code example of saving gas with in-line assembly:

Here we observed that the second case, which employs in-line assembly techniques, demonstrates much better gas efficiency compared to the standard use case.

However, using in-line assembly can also be risky and error-prone, so it should be used with caution and only by experienced developers.

Use Layer 2 Solutions

Use Layer 2 solutions to reduce the amount of data that needs to be stored and computed on the Ethereum mainnet.

Layer 2 solutions like rollups, sidechains, and state channels enable offloading of transaction processing from the main Ethereum chain, resulting in faster and cheaper transactions. By bundling a large number of transactions together, these solutions reduce the number of on-chain transactions, which in turn reduces the gas fees. Using Layer 2 solutions can also improve the scalability of Ethereum, enabling more users and applications to participate in the network without overloading it.

Use Optimization Tools and Libraries

There are several optimization tools available, such as solc optimizer, Truffle's build optimizer, and Remix's Solidity compiler.

These tools can help minimize the size of the bytecode, remove dead code, and reduce the number of operations required to execute a smart contract. In combination with other gas optimization libraries, such as “solmate”, developers can effectively reduce gas costs and improve the efficiency of their smart contracts.

Conclusion

Optimizing gas usage is an essential practice for developers to minimize transaction costs and improve the efficiency of smart contracts on EVM compatible networks. By prioritizing cost-efficient actions, minimizing storage usage, utilizing in-line assembly, and following other best practices discussed in this article, developers can effectively reduce the gas consumption of their contracts.

However, it should be noted that during the process of optimization, developers must exercise caution to prevent the introduction of security vulnerabilities. The drive to streamline code and reduce gas consumption should never compromise the inherent security of a smart contract.

As an experienced blockchain security firm, CertiK has significant expertise in this area. Our smart contract auditing services encompass gas optimization recommendations and ensure both performance and robust security. If developers are seeking expert guidance in striking the right balance between efficiency and safety, they should consider engaging us for a comprehensive and professional audit. Our team is committed to aiding developers in achieving secure, efficient, and high-performing smart contracts on all blockchain networks, EVM and otherwise.

Top 10 Security Tips for BNB Chain Builders

CertiK — Wed, 31 May 2023 18:39:25 +0000

BNB Chain is one of the most in-demand blockchains in the Web3 world thanks to its low fees, fast transactions, and rich ecosystem of projects. As with any blockchain, it's important for builders on BNB Chain to prioritize security in their development process, as any loss of user funds leads to the erosion of confidence in protocols and platforms. Security breaches and hacks are among the biggest risks developers face. In this post, we provide our top 10 security tips on for developers can reduce risk and develop secure smart contracts on BNB Chain.

#1: Protect Against Replay Attacks

Replay attacks are a common type of attack in blockchain environments that exploit vulnerabilities in signature verification processes. These attacks can have serious consequences for both users and developers, as they allow attackers to repeatedly use the same signature to gain unauthorized access to funds or other assets held by a smart contract.

To prevent replay attacks, developers must carefully design and implement their smart contract code, and to follow industry-standard best practices for signature verification and security.

This code snippet represents a basic implementation of a transfer function for a token on the BNB chain which is vulnerable to replay attacks, which would enable an attacker to repeatedly use the same signature.

function transfer(address to, uint256 value, bytes calldata signature) public returns (bool) {
    require(value <= balanceOf[msg.sender], "Insufficient balance.");
    require(_verifySignature(msg.sender, to, value, signature), "Invalid signature.");
    balanceOf[msg.sender] -= value;
    balanceOf[to] += value;
    emit Transfer(msg.sender, to, value);
    return true;
}

function _verifySignature(address from, address to, uint256 value, bytes memory signature) internal view returns (bool) {
    bytes32 messageHash = keccak256(abi.encodePacked(from, to, value));
    bytes32 ethSignedMessageHash = keccak256(abi.encodePacked("\x19Binance Signed Message:\n32", messageHash));
    address recoveredAddress = ECDSA.recover(ethSignedMessageHash, signature);
    return recoveredAddress == from;
}

This function lacks nonce or replay protection, allowing an attacker to replay a signed transfer transaction multiple times. An attacker can intercept the signed transaction and send it again to the same contract or another contract, and it will still be considered valid by the contract. This could lead to the attacker stealing the protocol’s assets. Remediations include adding a nonce in the signature or using a mapping to record the use of a signature. The exact solution may rely on the design of the project and can be modified accordingly to match the needs of specific contracts.

#2: Beware of Reentrancy Attacks

A reentrancy attack occurs when a malicious contract repeatedly calls back into a vulnerable contract before the initial invocation is complete. In other words, the attacker tricks the vulnerable contract into thinking that it is done with a transaction and is free to move on to the next one, when in reality it is still executing the attacker's malicious code. This can result in the attacker being able to manipulate the state of the contract in unexpected ways and potentially gain access to unauthorized funds.

In the following code snippet, users can withdraw funds from their account by calling the withdraw function and specifying the amount they want to withdraw. However, the withdraw function is vulnerable to a reentrancy attack because it does not properly prevent recursive calls to the function.

mapping (address => uint) public balances;

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    (bool success, ) = msg.sender.call.value(_amount)("");
    if (success) {
        balances[msg.sender] -= _amount;
    }
}

An attacker can exploit this vulnerability by creating a malicious contract that calls the withdraw function multiple times before the balance is actually deducted from their account. The function msg.sender.call sends funds to the malicious contract where the the attacker repeatedly withdraws funds, through the malicious contract receive() function before their balance is reduced to zero, effectively draining the victim contract of all its funds.

contract MaliciousContract {
    receive() external payable {
        VictimContract.withdraw();
    }
}

A simple fix would be to include a status update before any external calls.

mapping (address => uint) public balances;

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    balances[msg.sender] -= _amount;
    (bool success, ) = msg.sender.call.value(_amount)("");
    require(success, "Transfer failed.");
}

This is called the Check-Effects-Interact pattern, which is a design pattern used to prevent reentrancy attacks in smart contracts. It involves separating the state changes from the external calls to other contracts by first checking the preconditions and then updating the state before making any external calls. This way, if an external call triggers a callback that attempts to call back into the contract, the state has already been updated, preventing any unintended effects. By following this pattern, developers can ensure that their contracts are more secure and less vulnerable to reentrancy attacks. Another possible fix is to make use of a modifier to restrict multiple calls to the same function, much like OpenZeppelin’s ReentrancyGuard implementation.

#3: Be Careful With Oracles

An oracle helps smart contracts retrieve information from outside the blockchain. Often on a decentralized exchange (DEX), the price of assets is determined by an oracle mechanism that pulls the price from the last successful trade on the DEX. The problem is that this price can be manipulated easily by anyone, causing the smart contract to execute in unexpected ways. This manipulation can happen through the use of a flash loan, which allows a user to borrow huge amounts of funds without any collateral, as long as the loan is repaid within the same block. Since the price oracle in question does not protect against this type of manipulation, attackers can easily influence the price to profit from false liquidations, excessive loans, or unfair trades. This type of attack is called an "oracle manipulation attack."

The following is an example of code that is vulnerable to an oracle manipulation attack.

function getAmountOut(uint _amountIn) public returns (uint) {
    (uint reserveA, uint reserveB, ) = IUniswapV2Pair(router.WETH()).getReserves();
    uint amountOut = router.getAmountOut(_amountIn, reserveA, reserveB);
    return amountOut;
}

This contract allows users to swap Token A for Token B using the Uniswap router, but it relies on an external oracle (the Uniswap pair contract) to get the reserves of Token A and Token B in order to calculate the price. An attacker is able to manipulate the reserves of the Uniswap pair contract and can manipulate the getAmountOut function, causing the swap to be executed at an unfavorable price.

To prevent this type of attack, developers should instead make use of decentralized oracle networks that can be used to get volume-weighted average prices (VWAP) or time-weighted average prices (TWAP) on-chain for centralized and decentralized exchanges. This way, the data feeds will come from multiple data sources and price time frames, which will make the code much less susceptible to attacks and manipulation. It is important for developers to remove any oracle manipulation attack vectors in their smart contracts to prevent potential exploits.

#4: Set Proper Function Visibility Settings and Access Rights

It is important to set the visibility of functions correctly to ensure the security and integrity of the smart contract. The use of incorrect function visibility settings can cause serious security vulnerabilities, as it allows unintended users to manipulate the contract state and potentially steal funds or take control over important contract functions.

By setting the visibility of functions to private or internal, developers can restrict access to certain functions and ensure that only authorized parties can execute them. Private functions can only be called from within the contract itself, while internal functions can also be called from within contracts that inherit from the current contract. This allows developers to create more complex contracts with greater functionality, while still maintaining control over who can access certain functions.

Consider the function setAdmin() which allows anyone to set any address as a contract admin. Depending on the privileges granted to the admin address within the contract, this could potentially lead to lost funds and loss of control over the contract itself.

function setAdmin(address account) external {
    admin[account] = true;
}
By setting the function visibility to internal, this can allow only certain contract functions to internally set certain users as admins.

function setAdmin(address account) internal {
    admin[account] = true;
}

Access modifiers are an important security feature that can be used to dictate who has access to specific functions or variables within the contract. These modifiers are used to restrict the visibility of certain functions or variables to specific roles or addresses, preventing unauthorized access or manipulation of the contract's state by malicious actors. For example, a contract may have a function that only the contract owner can call, or a variable that can only be accessed by a specific set of addresses.

By leaving the visibility modifier to external and setting the the access modifier to onlyOwner, access to the setAdmin function will be restricted to only the contract owner address. This will prevent malicious external parties from taking control of certain privileged functions.

function setAdmin(address account) external onlyOwner {
    admin[account] = true;
}

Proper use of visibility and restriction modifiers can make contract management much easier. Common attacks such as reentrancy attacks, where an attacker repeatedly calls a function to manipulate the contract state, or front-running attacks, where an attacker monitors pending transactions and manipulates the contract state before a legitimate transaction is executed, can be reduced as well. By using these features appropriately, developers can enhance the security and reliability of their contracts, reduce the risk of unwanted changes or unauthorized access, and improve the overall quality and maintainability of their code.

#5: Beware of Contract Upgradability Issues

Carefully consider the contract design when deciding whether to include contract upgradability. Contract upgradability refers to the ability to modify or update the logic of a smart contract after it has been deployed on the blockchain. While upgradability can offer many advantages, such as fixing bugs, improving efficiency, or adding new features, it also introduces some risks, such as introducing new vulnerabilities, increasing complexity, or causing unintended consequences. The fact that contracts can be upgraded also raises trust issues because the proxy admin can upgrade the contract without consensus from the community. Therefore, it is important to carefully weigh the benefits and drawbacks of upgradability and determine whether it is truly necessary for a given use case. In some cases, it may be more appropriate to design a contract that is intended to be immutable and secure from the outset, rather than relying on the ability to modify it later.

When it comes to contract upgradability, there are several important practices to follow. First and foremost, it is crucial not to modify the proxy library. The complexity of proxy contract libraries, particularly with regards to storage management and upgrade mechanisms, means that even minor mistakes in modification can significantly impact the functioning of the proxy and logic contract. In fact, many high-severity proxy-related bugs discovered during audits have been caused by improperly modified proxy libraries.

Another key practice for contract upgradability is to include a storage gap in base contracts. Logic contracts must have a storage gap built into the contract code to account for new state variables that may be introduced when a new logic implementation is deployed. It is important to update the size of the gap accordingly after adding new state variables. This practice ensures that future upgrades can be made smoothly and without complications.

/**
* @dev This empty space is put in place to allow future versions to add new
* variables without shifting down storage in the inheritance chain.
* See https://docs.openzeppelin.com/contracts/4.x/upgradeable#storage_gaps
*/
uint256[45] private __gap;

Finally, it is essential to avoid using selfdestruct() or performing delegatecall()/ call() to untrusted contracts. An attacker can exploit the use of these functions to destroy the logic implementation or execute custom logic. To prevent this, it is important to verify user input and not allow the contract to perform delegatecall()/ call() to untrusted contracts. Additionally, using delegatecall() in the logic contract is not recommended, as managing the storage layout in multiple contracts can be difficult. By following these practices, developers can minimize the risk of vulnerabilities in their contract upgradability implementations.

#6: Protect Against Front-running

Front-running has been a persistent problem where users are able to exploit the delay between the submission of a transaction and its confirmation on the blockchain to make a profit. This delay is caused by the use of a mempool, a temporary storage area for unconfirmed transactions that have been broadcast to the network. All nodes in the network maintain a mempool, allowing anyone to see the pending transactions and potentially intercept and profit from them. The mempool also provides an opportunity for miners to re-order transactions to maximize their profits, creating what is known as Miner (or Maximal) Extractable Value (MEV).

The following is an example of an auction bid function that is susceptible to front-running.

function vote(uint256 bidAmount) public {
    require(bidAmount > highestBid);
    highestBid = bidAmount;
    highestBidder = msg.sender;
}

This function allows users to place bids on an auction, but it can be vulnerable to front-running attacks. Suppose a malicious user monitors the blockchain and sees that another user has submitted a high bid. The malicious user can then quickly submit a higher bid, which will be processed first and ultimately win the auction.

In the following version, users submit encrypted bids that are stored in a mapping. The bid amounts are obscured until the end of the bidding period.

function vote(bytes32 encryptedBid) public {
    encryptedBids[msg.sender] = encryptedBid;
}

function revealBid(uint256 bidAmount) public {
    require(auctionEnded);
    bytes32 encryptedBid = encryptedBids[msg.sender];
    require(encryptedBid != 0);
    require(keccak256(abi.encodePacked(bidAmount, secret)) == encryptedBid);
    require(bidAmount > highestBid);
    highestBid = bidAmount;
    highestBidder = msg.sender;
}

At the end of the bidding period, users can reveal their bids by submitting the original bid amount along with a secret value. The contract verifies that the hash of the bid amount and secret matches the stored encrypted bid, ensuring that the bid was submitted before the end of the bidding period. If the bid is higher than the current highest bid, it becomes the new highest bid. By obscuring the bid amount until the end of the bidding period, this function mitigates against front-running attacks.

Front-running and MEV have become a major concern in the blockchain community, and various solutions, such as encrypted transactions and Fair Sequencing Services (FSS), have been proposed to address these issues. Encrypted transactions can help prevent front-running by hiding transaction details from other users until the transaction is executed on the blockchain. FSS, on the other hand, can help reduce the impact of front-running and MEV by enabling secure off-chain ordering of transactions.

#7: Develop a Proactive Security Response Plan

Developing a clear and comprehensive response plan is crucial for dealing with security incidents. This plan should be regularly reviewed, updated, and tested for effectiveness. In the event of an incident, time is of the essence, so the plan should include clear steps for identifying, containing, and mitigating the situation.

A communication plan should be in place to keep stakeholders informed. Regular data backups are also important to prevent data loss. The plan should outline the recovery process for restoring data and systems to their previous state. Team members should be trained on the plan to ensure everyone understands their roles and responsibilities.

A well-prepared response plan can minimize the impact of an incident and maintain trust with users and stakeholders.

#8: Conduct Routine Audits

Routine code audits are essential for maintaining the security of your application. Working with reputable auditors who specialize in smart contract security is an essential step in the development process. The auditor will examine the code for vulnerabilities and provide recommendations for improving overall security. Prioritizing and addressing identified issues and maintaining open communication with the auditor are crucial to achieving meaningful improvements in security.

Communication with the auditor is also important, as they can help to explain their findings and provide guidance on how to address any vulnerabilities. By working together, the audit results will produce meaningful improvements to the security of the application.

Conducting routine audits is a key component of any comprehensive security strategy for BNB Chain developers. Proactively identifying and addressing vulnerabilities in the code can minimize the risk of security breaches and ensure the safety of users' funds and assets.

#9: Make Use of Bounty Programs

Expanding on the previous tip, using a bounty program is a great way to incentivize the community to search for and report security vulnerabilities in your code. By offering a reward, such as tokens or other incentives, you can encourage skilled individuals to examine your code and report any potential issues they find.

It's important to have a well-defined and transparent program with clear rules and guidelines for what types of vulnerabilities are eligible for rewards and how they will be evaluated. Reputable third-party bug bounty programs can help ensure that the program is run smoothly and that rewards are fairly distributed. Having a diverse group of bounty hunters is also important, as different people will have different areas of expertise and can focus on finding issues that others may miss.

Finally, once vulnerabilities have been reported, it's crucial to act quickly and effectively to address them. The bounty program can be a useful tool for identifying vulnerabilities, but it's up to the development team to actually fix them and improve the security of their application.

#10: Educate Users About Security Best Practices

Educating Web3 users is a crucial step in building a secure ecosystem. Keeping your customers safe helps keep your platform safe. Users should be educated on best practices for protecting their accounts and sensitive information. One of the most important aspects of user education is teaching users to avoid phishing scams. Phishing scams are designed to trick users into revealing their private keys or passwords by impersonating legitimate websites or services. Users should be advised to always double-check the URL of the website they are using and to never enter their private keys or passwords on any website that they do not trust.

Strong passwords are another essential part of personal security. Users should be encouraged to use unique and complex passwords for each of their accounts, and to avoid reusing passwords across different services. Passwords should also be stored securely, using a password manager or other secure storage mechanism.

Finally, users should be reminded to protect their private keys. Private keys are the equivalent of a user's password and should be kept secret at all times. Users should avoid sharing their private keys with anyone and store them in a secure location. They should also be advised to never enter their private keys on any website or service that they do not trust.

Conclusion

Developers building smart contracts and dApps on BNB Chain must take a comprehensive approach to security to ensure the safety of their users' funds and assets. This includes having multiple layers of security practices to ensure that the code and processes are secure and free of vulnerabilities. It is more important to be proactive in handling security vulnerabilities rather than reactive by creating a plan when exploits do occur and by properly educating all relevant users and stakeholders in security best practices. All such measures can help significantly reduce the risk of security breaches and hacks.