Systematic Literature Review & Grey Literature Review

[Stamp9]

Related to smart contract dependencies.

[Stamp9]

Analyzing Ethereum Smart Contract Vulnerabilities at Scale Based on Inter-Contract Dependency
https://www.techscience.com/CMES/v135n2/50148

[Stamp9]

TODLER: A Transaction Ordering Dependency anaLyzER - for Ethereum Smart Contracts
https://ieeexplore.ieee.org/document/10190831

[Mokita-J]

Towards Automated Security Analysis of Smart Contracts based on Execution Property Graph
https://arxiv.org/abs/2305.14046

[Stamp9]

HoRStify: Sound Security Analysis of Smart Contracts
https://ieeexplore.ieee.org/abstract/document/10221883

[Mokita-J]

https://ieeexplore.ieee.org/abstract/document/10197106 Dynamic Analysis for Detection of Self-Destructive Smart Contracts

[Mokita-J]

https://dl.acm.org/doi/full/10.1145/3488245 Why Do Smart Contracts Self-Destruct? Investigating the Selfdestruct Function on Ethereum

[Stamp9]

The Sword of Damocles: Upgradeable Smart Contract in Ethereum

The paper examines the prevalence of upgradeable smart contracts on Ethereum, focusing on two upgrade techniques: the proxy pattern and metamorphic contracts.

It seeks to answer 4 RQs on this topic:
RQ1: Do developers care about upgradeable contracts?

A review of Ethereum StackExchange posts from 2016 to 2022 found 355 posts related to upgradeable contracts, with the proportion increasing from 20% to 70% over the years. These posts focus on requirements (49%), code issues (39%), and security concerns (5%), with security concerns becoming more prominent in recent years.

RQ2: How to detect upgradeable contracts?
For metamorphic contracts, they analyzed transaction histories involving SELFDESTRUCT and CREATE2 opcodes, along with changes in contract code, to identify upgrades.
For proxy pattern upgradeable contracts, they design a bytecode-based classifier. For feature extraction, the bytecode was disassembled into opcodes.
The classifier was benchmarked using 4,352 upgradeable and 4,352 non-upgradeable contracts. These contracts were taken from the XBlock dataset and manually labeled.
The Random Forest algorithm achieved the best results out of the 5 ML algorithms tested, with a 99.37% F1 score in a 10-fold cross-validation.

RQ3: What's the frequency of upgradeable contracts?

From the 12M blocks, a subset of contracts with TXs containing DELEGATECALL, CREATE2, and SELFDESTRUCT was collected. After running the classifier on this subset of contracts 126,500 were identified as proxy upgradeable and 28 were metamorphically upgraded. 7 of these 28 contracts were flagged as MV bots by Etherscan.

RQ4: Why do developers use upgradeable contracts?

The study manually reviewed a random sample of 300 upgraded contracts to determine the reasons for upgrades. The findings revealed that developers primarily used upgradeable contracts for functionality changes (46%), vulnerability repairs (24%), code optimizations (25%), and other factors (5%).

thanks @Mokita-J

[Stamp9]

Immutable in Principle, Upgradeable by Design: Exploratory Study of Smart Contract Upgradeability
https://arxiv.org/pdf/2407.01493

This study collected 44M deployed smart contracts to analyze the upgradeable contracts.

summary
RQ1:How prevalent are upgrade patterns in smart contracts
method: Designed policies derived from EIPs(897, 1538, 1967, 1822, 2535 + The OpenZeppelin Proxy Pattern), based on the storage slots or unique identifiers (regular expressions) used in the standards, to identify upgradeable proxy contracts
found that Upgradeable Proxy Contracts comprise only 3% and EIP-1967 is the most used.
RQ2: How likely is an upgradeable contract to be upgraded
method: analyzing logs and events from Ethereum ETL dataset(https://ethereum-etl.readthedocs.io/en/latest/)
found only 0.34% of upgradeable smart contracts are actually upgraded(4397/1.3million) and the average number of versions per contract is approximately 3.90
RQ3: What changes occur in smart contracts post-upgrade
categories: fixing vulnerabilities, feature modification (adding or deleting features), gas optimization, other category
method: Use Git diff to locate changes between different SC versions, use Smartbugs to identify vulnerabilities, and compare gas cost.
31.68% for feature modification and 22.83% for fixing vulnerability
RQ4: How does smart contract upgrading impact the activity level of the contract
method: use transaction number and version lifespan as variables to evaluate relationship between upgrades and usage
both linear regression model and random forest model show limitations in capturing the relationship between upgrades and activity.

thanks @Stamp9

[Mokita-J]

Some literature on smart contract supply chain (off-chain, i.e. npm packages, open-zeppeling):
Demystifying the Composition and Code Reuse in Solidity Smart Contracts ESEC/FSE 2023

Code cloning in smart contracts: a case study on verified contracts from the Ethereum blockchain platform ESE journal 2020

Analysis of Source Code Duplication in Ethreum Smart Contracts SANER 2021

[Stamp9]

Self-Destruct related:
Why Do Smart Contracts Self-Destruct? Investigating the Selfdestruct Function on Ethereum
https://dl.acm.org/doi/pdf/10.1145/3488245

Dynamic Analysis for Detection of Self-Destructive Smart Contracts
https://ieeexplore.ieee.org/abstract/document/10197106

[Mokita-J]

Literature on Network of Smart Contracts: #11

[Mokita-J]

Literature on Blockchain Oriented Software: #10

[Mokita-J]

In Code We Trust? Measuring the Control Flow Immutability of All Smart Contracts Deployed on Ethereum DPM 2017

[Mokita-J]

Instrumenting Transaction Trace Properties in Smart Contracts: Extending the EVM for Real-Time Security
Main Idea:
This work proposes a modified EVM that enables real-time attack detection and prevention.
Existing work for smart contract security can be described as one of these approaches:

• Use detectors that analyze transaction traces after execution and identify, but these can't stop attacks in real-time.
• Adding runtime guards to contract code to revert transactions that violate certain properties. This increases gas costs and still fails to prevent all attack types.

The proposed solution combines key aspects of both approaches.
It allows smart contracts to access prior transaction traces before execution.
Contracts can read these traces from other contracts and revert the current transaction if a property is violated.

Implementation of the Idea:
To implement this, the paper introduces a new EVM opcode, "HOOK", which developers integrate into contracts alongside a specification file detailing properties to be checked.
Past-Time Linear Temporal Logic (PTLTL) is used to express these properties.
These hooks incur no additional gas costs.

Evaluation:
The evaluation shows that 186 of 188 Forta attack detectors can be specified using PTLTL.
The remaining two require external resources such as offchain oracles which are beyond the scope of this work.

System Overhead:
According to the authors, the proposed EVM modification does not affect consensus or exacerbate storage demands.
Because the safety checks do not alter the blockchain state.
Additionally, property validation can run in parallel with EVM execution, ensuring no impact on performance.

Tools/Code/Dataset: Not found.

How it differs from what we want to do?
SCSC does not revert transactions, nor changes the EVM.
We map out dependencies over time between contracts through transaction traces.
But we don't act upon transaction execution in real time.

Implementing the solution in this paper would require updating all Ethereum nodes, whereas SCSC achieves its goals without needing any changes from the community.

Is that useful for us?
The real attack presented as a motivational example can also be used in our work.
dForce attack happened to a dForce contracts that relied on a Curve.Fi contract which had a read-only reentrancy vulnerability.
The dForce contracts were exploited (they lost ETH), even though the vulnerability was in the Curve.Fi contract.
This is a case that supports the importance of smart contract supply chain.
For modern protocols implemented on the blockchain, looking at a singular contract is not enough to assess its security.
A contract without vulnerabilities can be exploited if it depends on a vulnerable contract.

[Mokita-J]

Proxion: Uncovering Hidden Proxy Smart Contracts for Finding Collision Vulnerabilities in Ethereum.

Proxion is a tool with these features:

• Detects proxy contracts and their logic contracts.
• Identifies storage/function collisions between proxy and logic contracts.

Novelty: It can work solely on bytecode, unlike previous tools that require source code or transaction history.

Scope: Focuses on proxy contracts with delegate calls in the fallback function.

Methodology:
Proxy Detection: Dynamic analysis with a customized emulator in Octopus.
Collision Detection:

• With source code: Uses Slither.
• Without source code: Uses CRUSH for storage collision. Performs static analysis (assisted by Panoramix decompiler) for function collisions.

Evaluation:
Compared to USCHunt & CRUSH
Datasets: Smart Contract Sanctuary (329k contracts) & CRUSH (53.5M contracts)
Found 7k and 1.7M more proxies than competitors for the respective datasets.
Improved collision detection: 24% (storage), 46% (functions) --> manual analysis of the results.
[No accuracy analysis on proxy detection. The datasets don't include the ground truth for the proxy contracts that Proxion detects.]

Tool repo.

Notes on some of the tools:
Octopus is not maintained anymore so it does not have some recent opcodes.
Panoramix is the decompiler used by Etherscan.