---
title: "Serangan inflasi setoran pertama ERC-4626: bagaimana pembulatan dapat menghapus saham"
description: "Pelajari bagaimana donasi langsung dapat memanipulasi nilai tukar vault ERC-4626 yang kosong, membulatkan saham penyetor menjadi nol, serta cara implementasi dan pengguna membatasi risikonya."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Serangan inflasi setoran pertama ERC-4626: bagaimana pembulatan dapat menghapus saham
> Hanya untuk tujuan edukasi; bukan nasihat investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Serangan inflasi setoran pertama menargetkan vault ERC-4626 yang kosong atau hampir kosong. Penyerang menyetor jumlah yang sangat kecil untuk menerima saham pertama, lalu mentransfer aset dasar langsung ke vault. Donasi ini meningkatkan `totalAssets()` tanpa meningkatkan `totalSupply()`, sehingga setiap saham yang ada menjadi lebih bernilai.
Jika setoran korban dikonversi pada nilai tukar yang telah dimanipulasi, pembagian bilangan bulat dapat membulatkan hasil ke sedikit saham atau nol. Aset korban tetap berada di vault, sedangkan penyerang, sebagai pemegang saham yang beredar, dapat menebus klaim yang telah digelembungkan. Ini merupakan masalah manipulasi nilai tukar dan slippage, bukan cacat pada antarmuka ERC-4626 itu sendiri.
## Cara kerjanya
Dalam vault sederhana tanpa biaya atau offset pelindung, saham yang dicetak untuk setoran kira-kira sebesar `assets * totalSupply / totalAssets`. ERC-4626 mewajibkan perhitungan saham untuk jumlah aset tertentu menguntungkan vault dengan pembulatan ke bawah. Pada nilai tukar normal, kerugian pembulatan sangat kecil, tetapi ketika harga saham telah digelembungkan, setoran yang bernilai kurang dari satu saham dapat kehilangan 100% akibat pembulatan.
Serangan ini bergantung pada detail implementasi. Transfer langsung ERC-20 dapat meningkatkan aset yang dicatat vault tanpa mencetak saham, terutama ketika `totalAssets()` membaca saldo token vault. Penyerang juga harus mendahului korban selagi pasokan saham masih sangat rendah. Vault yang menggunakan akuntansi berbeda atau pertahanan eksplisit mungkin tidak rentan dengan cara yang sama.
## Contoh
Asumsikan vault kosong yang rentan dimulai dengan rasio 1:1. Penyerang menyetor 1 unit aset dan menerima 1 saham, lalu mendonasikan 999 unit secara langsung. Vault kini memiliki 1,000 aset yang mendukung 1 saham. Korban menyetor 999 unit, sehingga perhitungan sederhananya adalah `999 * 1 / 1,000 = 0` saham setelah pembulatan bilangan bulat.
Vault kemudian memiliki 1,999 aset, sedangkan hanya 1 saham milik penyerang yang ada. Jika setoran mengizinkan hasil nol saham dan tidak ada biaya atau batasan lain, penyerang dapat menebus saham tersebut untuk seluruh 1,999 aset: setoran awal 1 unit, donasi 999 unit, dan setoran korban 999 unit. Laba kotor penyerang adalah 999 unit milik korban sebelum biaya transaksi.
## Risiko dan pertahanan
Pengembang dapat mengurangi risiko dengan menyediakan likuiditas awal yang berarti, membakar atau mengunci saham awal, mewajibkan hasil minimum setidaknya satu saham, atau memakai desain nilai tukar dengan aset virtual dan saham virtual. Implementasi OpenZeppelin menambahkan jumlah virtual dan mendukung presisi saham tambahan melalui offset desimal; dalam model yang didokumentasikan, saham virtual menangkap sebagian dari setiap donasi, sehingga manipulasi menjadi tidak menguntungkan atau jauh lebih mahal. Setiap pertahanan memiliki asumsi dan harus diuji terhadap transfer langsung, batas pembulatan, biaya, kerugian, serta perilaku token yang tidak biasa.
Pengguna dan integrator harus memperlakukan `previewDeposit()` sebagai penawaran, bukan jumlah minimum yang dijamin. Kirim setoran melalui fungsi atau router yang memberlakukan jumlah saham minimum yang dapat diterima dan membatalkan transaksi jika batas tersebut tidak tercapai. Sebelum menyetor ke vault baru atau yang pasokan sahamnya tipis, periksa `totalAssets()`, `totalSupply()`, rumus konversi implementasi, dan apakah transfer token yang tidak diminta memengaruhi akuntansi. Penawaran front-end yang menguntungkan tidak melindungi transaksi yang urutan eksekusinya dapat diubah.
## Kesalahpahaman umum
- **Mitos 1: ERC-4626 sendiri menjamin nilai tukar yang aman.** Standar ini mendefinisikan antarmuka umum dan perilaku pembulatan; standar ini tidak membuat setiap implementasi kebal terhadap manipulasi nilai tukar.
- **Mitos 2: Memanggil `previewDeposit()` tepat sebelum `deposit()` menjamin hasil tersebut.** Status on-chain dapat berubah di antara panggilan atau sebelum eksekusi. Jalur setoran memerlukan batas minimum saham yang dapat diberlakukan.
- **Mitos 3: Hanya menolak setoran nol saham akan menghilangkan serangan.** Hal itu mencegah hasil paling ekstrem, tetapi penyerang masih dapat menyebabkan setoran menerima sedikit saham dan mengalami kerugian pembulatan yang besar. Pertahanan harus membatasi slippage yang dapat diterima, bukan sekadar mewajibkan hasil bukan nol.
## Topik terkait
- [Standar Vault ERC-4626](/id/crypto/erc4626-vault/)
- [Bukti penipuan](/id/crypto/fraud-proof/)
- [Pengambilalihan initializer kontrak yang dapat ditingkatkan](/id/crypto/initializer-takeover/)
- [Kontrak pintar](/id/crypto/smart-contract/)
- [Simulasi transaksi](/id/crypto/transaction-simulation/)
## Sumber
- [ERC-4626: Vault Tertokenisasi](https://eips.ethereum.org/EIPS/eip-4626) - Ethereum Improvement Proposals (diakses: 2026-08-20)
- [Standar Vault Tertokenisasi ERC-4626](https://docs.openzeppelin.com/contracts/4.x/erc4626) - OpenZeppelin (diakses: 2026-08-20)
- [Implementasi ERC4626 OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC4626.sol) - OpenZeppelin (diakses: 2026-08-20)
Source: https://wiki.fcontext.com/id/crypto/erc4626-inflation-attack/index.mdx