Forem: THE CODE DOCTOR

03.DEFI ATTACKS - Falsche Slippagekalkulation

THE CODE DOCTOR — Wed, 02 Oct 2024 10:16:02 +0000

Die Slippage-Parameter sollten in etwa als "minTokensOut" definiert sein – also die minimale Anzahl an Token, die der Nutzer bei einem Swap akzeptieren würde. Alles, was davon abweicht, sollte als Warnsignal betrachtet werden, da dies höchstwahrscheinlich einen fehlerhaften Slippage-Parameter darstellt.

Zur Veranschaulichung könnte man sich diesen vereinfachten Code aus OpenZeppelins Audit von Origin Dollar ansehen. Hierbei wird gezeigt, dass falsche oder ungenaue Slippage-Parameter potenziell zu einem ungewollten Verlust von Vermögenswerten führen können, wenn der minimale Token-Ausgang nicht korrekt festgelegt ist.

function withdraw(address _recipient, address _asset, uint256 _amount
) external onlyVault nonReentrant {
    // ...

    // Calculate how much of the pool token we need to withdraw
    (uint256 contractPTokens, , uint256 totalPTokens) = _getTotalPTokens();

    uint256 poolCoinIndex = _getPoolCoinIndex(_asset);
    // Calculate the max amount of the asset we'd get if we withdrew all the
    // platform tokens
    ICurvePool curvePool = ICurvePool(platformAddress);
    uint256 maxAmount = curvePool.calc_withdraw_one_coin(
        totalPTokens,
        int128(poolCoinIndex)
    );

    // Calculate how many platform tokens we need to withdraw the asset amount
    uint256 withdrawPTokens = totalPTokens.mul(_amount).div(maxAmount);

    // Calculate a minimum withdrawal amount
    uint256 assetDecimals = Helpers.getDecimals(_asset);
    // 3crv is 1e18, subtract slippage percentage and scale to asset
    // decimals
    // @audit not using user-provided _amount, but calculating a non-sensical
    // value based on the LP tokens
    uint256 minWithdrawAmount = withdrawPTokens
        .mulTruncate(uint256(1e18).sub(maxSlippage))
        .scaleBy(int8(assetDecimals - 18));

    curvePool.remove_liquidity_one_coin(
        withdrawPTokens,
        int128(poolCoinIndex),
        minWithdrawAmount
    );

    // ...
}

Und die korrigierte Version nach dem Audit:

curvePool.remove_liquidity_one_coin(
    withdrawPTokens,
    int128(poolCoinIndex),
    _amount
);

Auditoren sollten sicherstellen, dass die Slippage-Parameter klar definiert sind und keine versteckten Risiken für den Benutzer darstellen.

Weitere Beispiele findest du in den folgenden Verweisen:
1 - [H-15] Wrong slippage protection on Token -> Token trades,
2 - Ineffective slippage mechanism when redeeming proportionally,
3 - Slippage/Minimum amount does not work during single-side redemption,
4 - Illuminate's PT doesn't respect users' slippage specifications for underlying,
5 - Oracle slippage rate is used for checking primary and secondary ratio,
6 - WithdrawPeriphery uses incorrect value for MAX_BPS which will allow much higher slippage than intended,
7 - ,
8 - [M-05] Wrong slippage check,
9 - IchiSpell applies slippage to sqrtPrice which is wrong and leads to unpredictable slippage.

02.DEFI ATTACKS - Keine Verfallsfrist/Deadline

THE CODE DOCTOR — Tue, 01 Oct 2024 07:39:46 +0000

Fortgeschrittene Protokolle wie Automated Market Makers (AMMs) können es den Benutzern ermöglichen, einen Deadline-Parameter festzulegen, der eine zeitliche Begrenzung erzwingt, bis zu der die Transaktion ausgeführt werden muss. Ohne einen Deadline-Parameter kann die Transaktion im Mempool verbleiben und zu einem viel späteren Zeitpunkt ausgeführt werden, was möglicherweise zu einem schlechteren Preis für den Benutzer führt.

Protokolle sollten die Deadline nicht auf block.timestamp setzen [mehr dazu], da ein Validator die Transaktion zurückhalten kann, und der Block, in den sie schließlich aufgenommen wird, den block.timestamp enthält. Dies bietet also keinen Schutz.

Protokolle sollten Benutzern, die mit AMMs interagieren, ermöglichen, Verfallsfristen festzulegen. Ohne eine solche Frist besteht eine potenzielle kritische Anfälligkeit für Verluste, insbesondere wenn auch kein Slippage-Parameter festgelegt wurde. Untersuchen Sie diesen schwerwiegenden Fund aus Sherlocks BlueBerry Update 1-Wettbewerb.

// 2. Swap rewards tokens to debt token
uint256 rewards = _doCutRewardsFee(CRV);
_ensureApprove(CRV, address(swapRouter), rewards);
swapRouter.swapExactTokensForTokens(
    rewards,
    0, // @audit no slippage, can receive 0 output tokens
    swapPath,
    address(this),
    type(uint256).max // @audit no deadline, transaction can 
    // be executed later at more unfavorable time
);

Hier ist „minTokensOut“ auf 0 fest codiert, sodass der Swap potenziell 0 Tokens zurückgeben kann. Der Deadline-Parameter ist auf den Maximalwert von uint256 fest codiert, sodass die Transaktion lange zurückgehalten und zu einem viel späteren und ungünstigeren Zeitpunkt für den Benutzer ausgeführt werden kann. Diese Kombination aus fehlendem Slippage- und Deadline-Parameter setzt den Benutzer dem potenziellen Verlust aller seiner eingesetzten Tokens aus!

Weitere Beispiele:
1 - The createMarket transaction lack of expiration timestamp check,
2 - [M-01] Stableswap - Deadline do not work,
3 - [M-01] Missing deadline checks allow pending transactions to be maliciously executed
4 - [M-01] Missing deadline checks allow pending transactions to be maliciously executed,
5 - [M-01] _harvest has no slippage protection when swapping auraBAL for AURA,
6 - Users are forced to swap all reward tokens with no slippage protection

01.DEFI ATTACKS - Kein Slippage Parameter

THE CODE DOCTOR — Mon, 30 Sep 2024 12:52:21 +0000

Slippage bezieht sich auf den Preisunterschied zwischen dem Zeitpunkt, an dem ein Marktteilnehmer einen DeFi-Tauschhandel einreicht, und dem tatsächlichen Preis, wenn der Handel ausgeführt wird. Dieser Unterschied ist normalerweise vernachlässigbar, kann jedoch in Zeiten hoher Volatilität und bei Tokens mit geringer Liquidität erheblich sein. Slippage kann dazu führen, dass der Benutzer mehr oder (häufig) weniger Tokens erhält, als er erhalten hätte, wenn der Handel sofort abgewickelt worden wäre.

DeFi-Plattformen sollten den Benutzern die Möglichkeit geben, einen Slippage-Parameter "minTokensOut" festzulegen – also die Mindestanzahl an ausgegebenen Tokens, die vom Tausch erhalten werden sollen. Der Tausch wird zurückgesetzt, wenn die vom Benutzer angegebene Mindestanzahl an Tokens nicht erreicht wird. Es gibt mehrere häufige Implementierungsfehler in DeFi-Systemen, auf die Entwickler und Prüfer achten sollten.

Kein Slippage-Parameter
DeFi-Plattformen müssen den Nutzern die Möglichkeit bieten, einen Slippage-Parameter festzulegen: die Mindestanzahl an Tokens, die sie von einem Swap zurückerhalten möchten. Prüfer sollten immer auf Swaps achten, bei denen der Slippage-Wert auf 0 gesetzt ist.

// 1. Beispiel:
IUniswapRouterV2(SUSHI_ROUTER).swapExactTokensForTokens(
    toSwap,
    0, // @audit min return 0 tokens; no slippage => user loss of funds
    path,
    address(this),
    now
);

//2. Beispiel: 
function _swapLidoForWETH(uint256 amountToSwap) internal {
    IUniswapSwapRouter.ExactInputSingleParams
        memory params = IUniswapSwapRouter.ExactInputSingleParams({
            tokenIn: address(ldo),
            tokenOut: address(weth),
            fee: UNISWAP_FEE,
            recipient: address(this),
            deadline: block.timestamp,
            amountIn: amountToSwap,
            amountOutMinimum: 0,
            sqrtPriceLimitX96: 0
        });
    uniswapRouter.exactInputSingle(params);
}

Dieser Code gibt an, dass der Benutzer bereit ist, eine Mindestmenge von 0 Tokens aus dem Swap zu akzeptieren, was den Benutzer einem katastrophalen Verlust von Mitteln durch MEV-Bot-Sandwich-Angriffe aussetzt. Plattformen sollten auch einen sinnvollen Standardwert festlegen, falls der Benutzer keinen Wert angibt. Benutzerdefinierte Slippage-Parameter müssen jedoch immer die Standardeinstellungen der Plattform überschreiben.

Weitere Beispiele:
1 - [H-07] RubiconRouter.swapEntireBalance() doesn’t handle the slippage check properly,
2 - [H-31] Unused slippage params,
3,
4 - [H-12] feePool is vulnerable to sandwich attack.,
5 - [H-07] Missing slippage checks,
6 - MainVault.rebalanceXChain doesn't check that savedTotalUnderlying,
7 - Withdrawals from IchiVaultSpell have no slippage protection,
8,
9 - rebalanceLite should provide a slippage protection,
10,
11,
12,
13 - [M-04] YearnTokenAdapter allows a maximum loss of 100% when withdrawing,
14 - [M-20] In reimburseLiquidityFees() of SponserVault contract swaps tokens without slippage limit so its possible to perform sandwich attack and it create MEV,
15 - [M-01] _harvest has no slippage protection when swapping auraBAL for AURA,
16 - [M-12] Sandwich attacks are possible as there is no slippage control option in Marketplace and in Lender yield swaps,
17 - [M-01] VaderPoolV2.mintFungible exposes users to unlimited slippage,
18 - [M-02] sNOTE.sol#_mintFromAssets() Lack of slippage control,
19 - [M-14] UniswapHelper.buyFlanAndBurn is a subject to sandwich attacks,
20 - [M-04] CvxCrvRewardsLocker implements a swap without a slippage check that can result in a loss of funds through MEV,
21 - 5.5 Harvester.harvest swaps have no slippage parameters,
22 - [M-02] regerralFeePool is vulnerable to MEV searcher,
23,
24,
25 - [M-05] No slippage control on deposit of IbbtcVaultZap.sol,
26 - [M-01] Improper implementation of slippage check,
27 - [M-02] Frontrunning in UniswapHandler calls to UniswapV2Router,
28,
29 - 0x52 - ConvexSpell#closePositionFarm removes liquidity without any slippage protection,
30 - User-supplied slippage for decrease orders is ignored,
31 - Collateral tokens that cannot be automatically swapped to the PnL token, cannot have slippage applied to them,
32 - Slippage is not respected if PnL swap associated with a decrease order fails.

Einsatz von transfer oder send und das Out-of-Gas-Problem

THE CODE DOCTOR — Thu, 26 Sep 2024 09:17:11 +0000

Ja, in Solidity kann es beim Einsatz von transfer oder send zu einem Out-of-Gas-Problem kommen, besonders wenn der Empfänger ein Smart Contract ist, der teure Operationen in seiner fallback- oder receive-Funktion ausführt.

Erklärung des Problems:

transfer und send sind beides Methoden, um Ether an einen anderen Account zu schicken.
Sie schicken standardmäßig 2300 Gas mit, um den Empfang zu ermöglichen. Das ist normalerweise genug, um eine einfache fallback- oder receive-Funktion auszuführen.
Falls der Empfänger aber mehr als diese 2300 Gas benötigt, schlägt die Transaktion fehl.

Beispiel:
Angenommen, du hast einen Smart Contract, der Ether an einen anderen Vertrag sendet. Wenn der Empfängervertrag in seiner fallback-Funktion eine komplexe Operation hat, könnte der Gasverbrauch über 2300 Gas liegen, was zu einem Out-of-Gas-Fehler führt.

Beispiel Smart Contract:

// Vertrag A sendet Ether an Vertrag B
contract A {
    function sendEther(address payable _to) public payable {
        // Versucht, 1 Ether zu senden
        _to.transfer(1 ether); // Oder _to.send(1 ether);
    }
}

// Vertrag B hat eine teure fallback-Funktion
contract B {
    // Diese Funktion wird bei Empfang von Ether aufgerufen
    fallback() external payable {
        // Hier wird eine teure Operation durchgeführt
        for (uint i = 0; i < 1000; i++) {
            // Komplexer Rechenaufwand
        }
    }
}

Was passiert hier:

Vertrag A versucht, Ether an Vertrag B zu senden.
Vertrag B hat eine fallback-Funktion, die teure Rechenoperationen ausführt.
transfer schickt nur 2300 Gas mit, aber die fallback-Funktion in Vertrag B braucht mehr Gas, um die Schleife durchzuführen.
Da 2300 Gas nicht ausreichen, schlägt die Transaktion fehl und es kommt zu einem Out-of-Gas-Fehler.

Lösung:
Um das zu vermeiden, kann man statt transfer oder send die Funktion call verwenden, die es ermöglicht, mehr Gas mitzuschicken:

// contract A sends Ether using call with more gas
contract A {
    function sendEtherWithCall(address payable _to) public payable {
        (bool success, ) = _to.call{value: 1 ether}(""); // Unbegrenztes Gas
        require(success, "Transfer failed.");
    }
}

Mit call kannst du beliebig viel Gas mitgeben, sodass der Empfänger genug Gas für seine Operationen hat.

Zusammenfassen gehen beim Out-of-Gas-Fehler keine Gelder verloren – nur das verbrauchte Gas.

Der Ether bleibt sicher beim Sender (Vertrag A).
Der Absender trägt nur die Gasgebühren, die während des Versuches aufgebraucht wurden.
Der Empfänger (Vertrag B) erhält keinen Ether, da die Transaktion nicht erfolgreich war und zurückgerollt wurde.

Was ist der ERC-404 Token-Standard?

THE CODE DOCTOR — Fri, 28 Jun 2024 11:44:24 +0000

Was ist der ERC-404 Token-Standard?
Der ERC-404 ist ein neu entwickelter Token-Standard, der von den Entwicklern ctrl und Acme von Pandora Labs erfunden wurde. Einfach ausgedrückt, handelt es sich um eine Kombination aus ERC-20 und ERC-721 Token.

Welches Problem löst ERC-404?
Das Hauptziel von ERC-404 besteht darin, NFTs (Non-Fungible Tokens) liquide zu machen, sodass sie gehandelt und als Sicherheiten oder Liquidität für DeFi-Protokolle genutzt werden können. Darüber hinaus wird ein Konzept der fraktionierten Eigentümerschaft eingeführt, bei dem mehrere Benutzer einen Teil eines NFTs besitzen können. Dies ermöglicht es einer größeren Anzahl von Benutzern, zuvor unzugängliche Token zu erwerben.

Technische Eigenschaften von ERC-404

Fraktionierte Eigentümerschaft: Wie bei ERC-20 Token können ERC-404 Token in Bruchteile unterteilt werden, was es mehreren Benutzern ermöglicht, einen Anteil an einem einzigen NFT zu besitzen.
Einzigartigkeit: Wie bei ERC-721 Token bleibt jeder ERC-404 Token einzigartig und repräsentiert ein individuelles digitales Gut.
Liquidität: ERC-404 Token können einfacher gekauft, verkauft und gehandelt werden, was die Liquidität von NFTs erhöht und sie für Investoren und DeFi-Enthusiasten zugänglicher macht.

Zusammenfassung
Der ERC-404 Token-Standard kombiniert die Vorteile von ERC-20 und ERC-721 Token, indem er sowohl die Teilbarkeit von ERC-20 als auch die Einzigartigkeit von ERC-721 bietet. Dies erleichtert den Handel und die Nutzung von NFTs in DeFi-Protokollen und ermöglicht fraktionierte Eigentümerschaft, wodurch NFTs für eine größere Anzahl von Benutzern zugänglich werden.

Technischer Überblick

Es ist ganz einfach und kann leicht mit einem Diagramm erklärt werden:

Funktionsweise des ERC-404 Tokens
Beim Transfer eines ERC-404 Tokens überprüft der Kontrakt, ob die Anzahl der Tokens, die der Benutzer besitzt, ganzzahlig oder mit Dezimalstellen ist.

Einfach erklärt:

Ganzzahlig: Wenn ein Benutzer eine ganze Zahl (1, 2, 3, usw.) besitzt, erhält er ein vollständiges NFT.
Mit Dezimalstellen: Wenn ein Benutzer eine Dezimalzahl besitzt, erhält er einen Bruchteil des ERC-721 Tokens in fungiblen Tokens.

Beispiel
Nehmen wir an, ein Benutzer möchte 69.420 ERC-404 Tokens erhalten:

Der Benutzer erhält 69 ERC721 Tokens (ganze NFTs).
Der Benutzer erhält 42 ERC20 Tokens (fungible Tokens), die den Dezimalanteil repräsentieren.

Technische Details der _transfer() Funktion
In der _transfer() Funktion des ERC-404 Smart Contracts wird diese Logik umgesetzt. Hier wird geprüft, ob der Token-Betrag ganzzahlig oder mit Dezimalstellen ist, und entsprechend umgesetzt:

Ganzzahliger Betrag: Der gesamte Betrag wird als ein einzelnes NFT behandelt.
Dezimalbetrag: Der Betrag wird in zwei Teile aufgeteilt:

Ein Teil als ganzer ERC-721 Token.
Ein anderer Teil als ERC-20 Token, der den Dezimalanteil darstellt.

Diese Logik stellt sicher, dass Benutzer entweder ganze NFTs oder Bruchteile davon in Form von fungiblen Tokens (ERC20) erhalten. Dadurch wird die Interoperabilität und Handbarkeit von NFTs im DeFi-Bereich verbessert.

// Burn für bestimmte Adressen überspringen, um Gas zu sparen if (!whitelist [from]) { uint256 tokens_to_burn = (balanceBeforeSender / unit) (balance0f [from] / unit); for (uint256 i = 0; i < tokens_to_burn; i++) { _burn(from); } } if (!whitelist [from]) { uint256 tokens_to_mint = (balanceOf[to] / unit) (balanceBeforeReceiver / unit); for (uint256 i = 0; i < tokens_to_mint; i++) { _mint(to); } }

Wichtige Hinweise zum ERC-404 Token-Standard
Der ERC-404 Contract erbt nicht von ERC-20 oder ERC-721. Stattdessen handelt es sich um einen neu entwickelten Smart Contract, der Funktionen und Mechanismen seiner Vorgänger implementiert.
Wichtige Punkte:

Neuer Smart Contract: Der ERC-404 Contract ist eigenständig und nicht von ERC-20 oder ERC-721 abgeleitet. Er integriert jedoch deren Funktionen und Mechaniken.
Experimentell und nicht geprüft: ERC-404 Tokens sind experimentell und wurden noch nicht auditiert. Sie haben keine Ethereum Improvement Proposal (EIP) und sind daher momentan nicht von allen Protokollen anerkannt.
Sicherheitsrisiken: Da sie nicht vollständig geprüft sind, weisen ERC-404 Tokens mehrere Sicherheitslücken auf, die später im Artikel beschrieben werden.
Keine Token-IDs: Im Gegensatz zu ERC-721 Tokens, die eindeutige Token-IDs besitzen, haben ERC-404 Tokens keine Token-IDs, ähnlich wie ERC-20 Tokens. Zusammenfassung Der ERC-404 Token-Standard kombiniert zwar die Funktionen von ERC-20 und ERC-721, ist jedoch ein eigenständiger Contract ohne direkte Vererbung von diesen Standards. Aufgrund seines experimentellen Charakters und fehlender Audits bestehen derzeit Sicherheitsrisiken und Kompatibilitätsprobleme mit bestehenden Protokollen.

Anwendungsfälle des ERC-404 Token-Standards

Die ersten ERC-404 Tokens wurden in diesem Jahr veröffentlicht, und es gibt bereits mehr als 20 solcher Tokens mit einer Gesamtkapitalisierung von über 300 Millionen Dollar (Stand: März 2024). Schauen wir uns an, wie diese Tokens genutzt werden können.

Reale Vermögenswerte (RWAs)
ERC-404 Tokens erleichtern den Handel und den Kauf realer Vermögenswerte, wie zum Beispiel Häuser oder Luxusprodukte. Benutzer können Bruchteile teurer und illiquider Tokens besitzen, was den Handel vereinfacht und die Möglichkeit eröffnet, zusätzliche Erträge zu erzielen.

Dezentrale Finanzen (DeFi)
Der Hauptgrund ist, dass NFTs durch ERC-404 Tokens liquider werden und als Sicherheiten für Kredite und Darlehen oder als Liquidität für Protokolle genutzt werden können. Dies eröffnet eine Vielzahl neuer Investitionsmöglichkeiten in dApps.

Gaming
Da In-Game-Assets fraktioniert werden, haben Entwickler mehr Freiheit bei der Gestaltung von Spielmechaniken und -ökonomien. Für Benutzer wird es einfacher, In-Game-Assets zu kaufen und zu handeln.

Zusammenfassung
Der ERC-404 Token-Standard bietet vielfältige Anwendungsmöglichkeiten in verschiedenen Bereichen. Er ermöglicht den Handel mit realen Vermögenswerten, verbessert die Liquidität von NFTs für den Einsatz in DeFi-Protokollen und vereinfacht den Handel von In-Game-Assets in der Gaming-Industrie.

Reale Beispiele für ERC-404 Tokens
Die drei bekanntesten ERC-404 Kollektionen sind derzeit Pandora, DeFrogs und Monkees. Schauen wir uns Pandora genauer an — es war der allererste ERC-404 Token und umfasst 10.000 NFTs, die mit weiteren 10.000 ERC-20 Tokens verknüpft sind. Beim Minten eines PANDORA-Tokens erhalten Benutzer 1 NFT.

Mechanismus von Pandora

Threshold: Es gibt eine festgelegte Schwelle, wie viele Tokens jeder Benutzer haben darf. Wenn ein Benutzer mehr als die festgelegte Anzahl besitzt, erhält er ein neu gemintetes NFT. Besitzt er weniger, wird das NFT verbrannt.
Wert und Seltenheit: Dieses ständige Minten und Verbrennen von Tokens erneuert den Wert und die Seltenheit jedes Non-Fungible Tokens.

Technische Umsetzung
Früher im Artikel haben wir einen Ausschnitt aus dem ERC-404 Vertrag gezeigt, der speziell für Pandora verwendet wird. Dieser Codeabschnitt enthält eine spezifische Buchführung, die überprüft, ob das NFT eines Benutzers gemintet oder verbrannt werden soll.

Zusammenfassung
Pandora ist ein bahnbrechendes Beispiel für die Nutzung des ERC-404 Token-Standards. Durch das ständige Minten und Verbrennen wird der Wert und die Seltenheit der NFTs dynamisch gehalten, was die Attraktivität und den Handelswert dieser Tokens erhöht.

Sicherheitsüberlegungen zum ERC-404 Token-Standard
Der ERC-404 Token-Standard ist noch experimentell und nicht vollständig mit bestehenden Protokollen kompatibel. Daher gibt es zwei Hauptprobleme, die beachtet werden sollten:

Unklare Standards und Mechaniken: Viele Entwickler sind nicht ausreichend über den ERC-404 Token-Standard informiert, und es gibt keine formale Ethereum Improvement Proposal (EIP), die diesen Standard standardisiert. In der Zukunft könnten sich daher erhebliche Unterschiede in den Mechanismen der ERC-404 Tokens ergeben.
Inkompatibilität mit Protokollen: Aktuelle Protokolle können nicht zu 100 % genau mit solchen Tokens arbeiten. Dies eröffnet eine Vielzahl von Sicherheitslücken, die mit willkürlichen externen Aufrufen oder einfach fehlerhaften Interaktionen verbunden sind. Solche Schwachstellen können dazu führen, dass Benutzer Geld verlieren, da sie möglicherweise nicht die erwarteten Ergebnisse erzielen.

Schlussfolgerung
ERC-404 Tokens haben das Potenzial, eine Innovation im Web3-Bereich darzustellen, indem sie die besten Eigenschaften der beiden Haupt-ERC-Standards kombinieren. Dies eröffnet neue Horizonte für Entwickler und Benutzer, um DeFi besser und benutzerfreundlicher zu gestalten.

Jedoch ist zu beachten, dass ERC-404 derzeit ein experimenteller Standard ist, der ohne formale EIP und mit Inkompatibilitäten zu bestehenden Protokollen kommt. Daher können Benutzer unerwartete Verluste und Fehler erleben, während sie mit solchen Tokens interagieren, und böswillige Akteure haben mehr Möglichkeiten für Angriffe. Es ist wichtig, dass Entwickler und Benutzer sich dieser Risiken bewusst sind und entsprechende Sicherheitsmaßnahmen treffen, um ihre Interaktionen sicher zu gestalten.

Was ist der Unterschied zwischen der Call- und Apply-Methode?

THE CODE DOCTOR — Mon, 28 Feb 2022 13:53:11 +0000

Der Unterschied zwischen call u. apply besteht darin, wie die Argumente an die aufgerufene Funktion übergeben werden. In apply werden die Argumente als Array und bei call getrennt durch ein Komma übergeben.

const object1 = {
    result: 0
}
const object2 = {
    result: 0
}
function reduceAdd() {
    let result = 0
    for (let i = 0, len = arguments.length; i< len; i++){
        result += arguments[i]
    }
    this.result = result
}
reduceAdd.apply(object1, [1, 2, 3, 4, 5, 6]) //21
reduceAdd.call(object2, 1, 2, 3, 4, 5, 6) //21