Sicherheit & Cross-Chain-Entwicklung

Reentrancy-Angriffe

Reentrancy bleibt die beruehmteste Smart-Contract-Schwachstelle. Sie tritt auf, wenn ein externer Aufruf den Contract wieder betritt, bevor Zustandsaktualisierungen abgeschlossen sind, sodass ein Angreifer Gelder abziehen kann, indem er wiederholt withdraw aufruft, bevor der Saldo genullt wird.

Die Loesung hat zwei Ebenen: Zustand vor externen Aufrufen aktualisieren (Checks-Effects-Interactions) und OpenZeppelins ReentrancyGuard als zweite Verteidigungslinie verwenden. Modernes Solidity 0.8+ eliminiert Integer-Overflow als beitragenden Faktor, aber das grundlegende Reentrancy-Pattern gilt weiterhin.

// VERWUNDBAR — externer Aufruf vor Zustandsupdate
function withdraw() external {
    uint256 amount = balances[msg.sender];
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] = 0; // Zu spaet!
}

// SICHER — Zustandsupdate vor externem Aufruf + Guard
function withdraw() external nonReentrant {
    uint256 amount = balances[msg.sender];
    balances[msg.sender] = 0; // Zustand zuerst aktualisiert
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

Zugriffskontrolle

Rollenbasierte Zugriffskontrolle trennt Admin-, Operator- und Pauser-Privilegien. Dies verhindert, dass ein einzelner kompromittierter Schluessel das gesamte Protokoll kontrolliert. OpenZeppelins AccessControl bietet eine kampferprobte Implementierung mit Rollenhierarchien.

Kritische Operationen — Aenderung von Reward-Raten, Pausieren des Contracts, Upgrade-Implementierungen — sollten unterschiedliche Rollen erfordern. Die DEFAULT_ADMIN_ROLE kann andere Rollen vergeben und entziehen, daher sollte sie von einem Multi-Sig oder Timelock-Contract gehalten werden, niemals von einer einzelnen EOA.

import "@openzeppelin/contracts/access/AccessControl.sol";

contract SecureProtocol is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
    bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");
    bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");

    constructor() {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(ADMIN_ROLE, msg.sender);
    }

    function setRewardRate(uint256 newRate) external onlyRole(ADMIN_ROLE) {
        require(newRate <= 10000, "Rate too high");
        rewardRate = newRate;
    }

    function pause() external onlyRole(PAUSER_ROLE) { paused = true; }
    function unpause() external onlyRole(ADMIN_ROLE) { paused = false; }
}

Oracle-Sicherheit

Preis-Oracle-Manipulation ist einer der haeufigsten DeFi-Angriffsvektoren. Ein Protokoll, das einem einzelnen Preisfeed ohne Validierung vertraut, ist anfaellig fuer Flash-Loan-getriebene Preismanipulation, veraltete Daten bei Netzwerkueberlastung und Oracle-Ausfallzeiten.

Verteidigung in der Tiefe bedeutet: Staleness pruefen (Preise aelter als ein Schwellenwert ablehnen), Plausibilitaet validieren (negative Preise oder extreme Abweichungen vom letzten bekannten guten Preis ablehnen) und Multi-Oracle-Aggregation mit gewichteter Abstimmung implementieren. Wenn alle Oracles ausfallen, sollte das Protokoll pausieren statt mit schlechten Daten zu arbeiten.

function getWeightedPrice() public view returns (uint256) {
    uint256 totalWeight = 0;
    uint256 weightedSum = 0;

    for (uint256 i = 0; i < oracleKeys.length; i++) {
        OracleData memory oracle = oracles[oracleKeys[i]];
        if (!oracle.isActive) continue;

        try oracle.feed.latestRoundData() returns (
            uint80, int256 price, uint256, uint256 updatedAt, uint80
        ) {
            if (price > 0 && block.timestamp - updatedAt <= 3600) {
                weightedSum += uint256(price) * oracle.weight;
                totalWeight += oracle.weight;
            }
        } catch {
            continue; // Fehlgeschlagenes Oracle ueberspringen
        }
    }

    require(totalWeight > 0, "No valid oracles");
    return weightedSum / totalWeight;
}

Testen und Verifizierung

Ein produktionsreifer DeFi-Contract braucht Unit-Tests fuer jede Funktion, Integrationstests fuer komplexe Workflows, Fuzz-Tests fuer zufaellige Eingabemuster und idealerweise formale Verifizierung fuer kritische Invarianten. Zielen Sie auf mindestens 95 % Testabdeckung vor jedem Audit.

Fuzz-Testing findet Randfaelle, die manuelle Tests uebersehen. Fuehren Sie Hunderte zufaellige Einzahlungs-/Auszahlungssequenzen durch und stellen Sie sicher, dass die Gesamteinlagen immer der Summe der Einzelsalden entsprechen. Formale Verifizierungstools wie Certora koennen mathematisch beweisen, dass Invarianten fuer alle moeglichen Eingaben gelten.

describe("Fuzz Testing", function () {
  it("Should maintain state consistency across random operations", async function () {
    for (let i = 0; i < 100; i++) {
      const user = Math.random() > 0.5 ? user1 : user2;
      const action = Math.random() > 0.5 ? "deposit" : "withdraw";
      const amount = ethers.parseEther((Math.random() * 100).toFixed(2));

      try {
        if (action === "deposit") {
          await token.connect(user).approve(await protocol.getAddress(), amount);
          await protocol.connect(user).deposit(amount);
        } else {
          const balance = await protocol.userDeposits(user.address);
          if (balance > 0n) {
            const w = amount > balance ? balance : amount;
            await protocol.connect(user).withdraw(w);
          }
        }
      } catch (error) {
        expect(error.message).to.match(/(InsufficientBalance|InvalidAmount)/);
      }
    }

    const total = await protocol.totalDeposits();
    const b1 = await protocol.userDeposits(user1.address);
    const b2 = await protocol.userDeposits(user2.address);
    expect(total).to.equal(b1 + b2);
  });
});

Auditvorbereitung

Vor der Beauftragung eines Auditors durchlaufen Sie eine gruendliche Pre-Audit-Checkliste. Codequalitaet: umfassende NatSpec-Dokumentation, konsistenter Stil, keine unbenutzten Imports, alle TODOs geloest, Gas-Optimierungen angewendet. Sicherheit: Reentrancy-Schutz, Zugriffskontrollen, Eingabevalidierung, Oracle-Manipulationsschutz, Notfall-Pause-Mechanismus.

Testanforderungen: Unit-Tests fuer alle Funktionen, Integrationstests fuer komplexe Workflows, Randfall-Tests, Fuzz-Tests und Abdeckung ueber 95 %. Dokumentation: technische Spezifikation, Architekturdiagramme, bekannte Einschraenkungen, Deployment-Anleitung und ein Notfallverfahren-Runbook.

Cross-Chain-Architektur

Multi-Chain-DeFi erfordert eine Chain-Abstraktionsschicht, die Chain-IDs auf RPC-URLs, Contract-Adressen, Block-Explorer und native Waehrungen abbildet. Dies laesst Ihr Frontend dynamisch zwischen Ethereum, Polygon, Arbitrum und Base wechseln, ohne fest kodierte Logik im gesamten Codebase.

Cross-Chain-Einzahlungen verwenden ein Bridge-Contract-Pattern: Token auf der Quell-Chain sperren, Nachricht ueber die Bridge senden und Token auf der Ziel-Chain praegen oder freigeben. Der empfangende Contract muss validieren, dass die Nachricht von der Bridge und von der korrekten Quell-Chain-Protokolladresse kam. Implementieren Sie immer Replay-Schutz und beruecksichtigen Sie die Finalitaetsgarantien jeder Chain.

function depositCrossChain(uint256 amount, uint256 targetChain)
    external nonReentrant
{
    require(chainProtocols[targetChain] != address(0), "Unsupported chain");
    IERC20(depositToken).transferFrom(msg.sender, address(this), amount);

    bytes memory message = abi.encode(msg.sender, amount);
    bytes32 messageId = bridge.sendMessage(
        targetChain,
        chainProtocols[targetChain],
        message
    );

    emit CrossChainDeposit(msg.sender, amount, targetChain, messageId);
}

function receiveMessage(
    uint256 sourceChain, address sourceAddress, bytes calldata message
) external {
    require(msg.sender == address(bridge), "Only bridge");
    require(sourceAddress == chainProtocols[sourceChain], "Invalid source");
    (address user, uint256 amount) = abi.decode(message, (address, uint256));
    userDeposits[user] += amount;
    totalDeposits += amount;
}