# Vor dem Senden simulieren: Transaktionen mit eth_simulateV1 im Probelauf ausführen

> Source: https://docs.blockvectra.com/de/guides/simulate-transactions/

Bevor Transaktionen an ein Blockchain-Netzwerk übertragen werden, ermöglicht ein Probelauf Entwicklern, Ausführungsergebnisse zu analysieren, Zustandsübergänge von Verträgen zu überprüfen und Event-Logs vorab einzusehen. Dadurch lassen sich unnötige Gas-Gebühren durch fehlschlagende Verträge (Reverts) vermeiden.

Die Ethereum-Ausführungsschicht (Execution Layer) bietet mehrere Möglichkeiten, Transaktionen vor dem Absenden zu evaluieren:

* `eth_call`: Führt einen einzelnen schreibgeschützten Aufruf (Message Call) ohne dauerhafte Zustandsspeicherung über aufeinanderfolgende Aufrufe hinweg aus.
* `eth_estimateGas`: Berechnet das für die Ausführung erforderliche Gas-Limit, liefert jedoch keine sequenziellen Zustandsübergänge über mehrere Transaktionen oder vollständige Event-Logs.
* `eth_simulateV1`: Definiert in der Standardspezifikation der Ethereum Execution APIs ermöglicht diese Methode die sequenzielle Simulation mehrerer Transaktionen über Blöcke hinweg, akkumuliert Zustandsänderungen zwischen Transaktionen und unterstützt das Überschreiben von Blockparametern sowie Kontozuständen.

## Unterstützte Chains und Methodenrichtlinien

Netzwerkfunktionen werden dynamisch über `GET /v1/chains` bereitgestellt. Lesen Sie `methods.allow` aus dieser Antwort aus, um zu sehen, welche Chains `eth_simulateV1` zulassen; eine Chain, in der die Methode nicht aufgeführt ist, weist den Aufruf mit dem JSON-RPC-Fehler `-32601` ab (`method not available`, wird nicht berechnet).

### Node-Zustandsbedingungen

`eth_simulateV1` ist eine Zustandsabfragemethode:

* **Sync-Schranke (`-32010`)**: Wenn der Node der Ziel-Chain noch synchronisiert und noch nicht bereit ist, gibt der Aufruf `-32010` zurück (`node is syncing`, wird nicht berechnet).
* **State-Fenster (`-32011`)**: Auf Robinhood Chain geben Anfragen für Blöcke, die älter als `state_window_blocks` der Chain (`GET /v1/chains`) sind, oder die die Block-Tags `safe`, `finalized` oder `earliest` verwenden, `-32011` zurück (wird nicht berechnet). Der Standard-Block-Tag ist `latest`.

## Anforderungsstruktur und einfaches Beispiel

Gemäß der Spezifikation der Ausführungsschicht ([Ethereum Execution APIs eth\_simulateV1 Definition](https://ethereum.github.io/execution-apis/api/methods/eth_simulateV1)) akzeptiert `eth_simulateV1` zwei Positionsparameter:

1. **Payload-Objekt**:
   * `blockStateCalls` (erforderliches Array): Ein Array von simulierten Blockobjekten. Jedes Objekt enthält ein Array von Transaktionsaufrufen `calls`, optionale Block-Header-Überschreibungen `blockOverrides` und optionale Kontozustandsüberschreibungen `stateOverrides`.
   * `validation` (optionaler Boolean, Standardwert `false`): Bei `false` verhält sich der Aufruf wie `eth_call`; bei `true` werden alle EVM-Validierungen mit Ausnahme von Signaturprüfungen ausgeführt.
   * `traceTransfers` (optionaler Boolean): Bei `true` werden Event-Logs für native Token-Transfers zurückgegeben.
2. **Block-Tag** (optionaler String, Standardwert `'latest'`): Blocknummer, Block-Hash oder Block-Tag.

### Grundlegendes Beispiel: Probelauf eines ERC-20-Transfers

Das folgende Beispiel führt einen Probelauf für einen ERC-20-Aufruf `transfer(address,uint256)` auf Robinhood Chain aus. Ersetzen Sie `$BLOCKVECTRA_API_KEY` durch Ihren tatsächlichen API-Schlüssel:

**cURL**

```bash
export BLOCKVECTRA_API_KEY=rgw_your_api_key

curl -s "https://api.blockvectra.com/v1/robinhood_mainnet" \
  -H "Content-Type: application/json" \
  -H "x-api-key: $BLOCKVECTRA_API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_simulateV1",
    "params": [
      {
        "blockStateCalls": [
          {
            "calls": [
              {
                "from": "0x1111111111111111111111111111111111111111",
                "to": "0x2222222222222222222222222222222222222222",
                "data": "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
                "value": "0x0"
              }
            ]
          }
        ]
      },
      "latest"
    ]
  }'
```


  **TypeScript (viem)**

```ts
import { createPublicClient, http } from "viem";

const apiKey = process.env.BLOCKVECTRA_API_KEY!;
const client = createPublicClient({
  transport: http(`https://api.blockvectra.com/v1/robinhood_mainnet/${apiKey}`),
});

// Call eth_simulateV1 directly via viem's client.request
const simulationResult = await client.request({
  method: "eth_simulateV1" as any,
  params: [
    {
      blockStateCalls: [
        {
          calls: [
            {
              from: "0x1111111111111111111111111111111111111111",
              to: "0x2222222222222222222222222222222222222222",
              data: "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
              value: "0x0",
            },
          ],
        },
      ],
    },
    "latest",
  ],
});

console.log(simulationResult);
```


### Antwortstruktur analysieren

Gemäß der Ethereum-Ausführungsspezifikation enthält das Feld `result` ein Array von simulierten Blockergebnissen (Block Results) mit folgendem Schema:

#### Felder auf Block-Ebene

* `number`: Blocknummer des simulierten Blocks (Hex-String).
* `hash`: Simulierter Block-Hash (32-Byte-Hex-String).
* `parentHash`: Hash des übergeordneten Blocks (Parent Block).
* `timestamp`: Block-Zeitstempel (Hex-String).
* `gasLimit`: Gas-Limit des Blocks.
* `gasUsed`: Insgesamt verbrauchtes Gas über alle simulierten Aufrufe in diesem Block hinweg.
* `baseFeePerGas`: Basisgebühr pro Gas-Einheit für den Block (Base Fee per Gas).
* `miner`: Coinbase-Adresse, die die Blockgebühren erhält.
* `calls`: Array der Ausführungsergebnisse für jeden simulierten Aufruf.

#### Felder auf Aufruf-Ebene (Elemente des `calls`-Arrays)

* `status`: Aufrufstatus als Hex-String. `0x1` signalisiert Erfolg, während `0x0` einen Fehler oder Revert anzeigt.
* `gasUsed`: Durch diesen Aufruf tatsächlich verbrauchtes Gas (Hex-String).
* `maxUsedGas` (optional): Maximal verbrauchtes Gas während der Ausführung vor Rückerstattungen.
* `returnData`: Hex-codierte Rückgabedaten. Bei einem erfolgreichen ERC-20-Transfer enthält dies das boolesche `true`; bei einem Revert enthält es den Error-Selektor oder die Revert-Daten.
* `logs`: Array von Event-Logs, die durch den Aufruf ausgelöst wurden. Bei Erfolg enthält es Event-Logs wie `Transfer`:
  * `address`: Vertragsadresse, die das Event ausgelöst hat.
  * `topics`: Array von 32-Byte-Topic-Hashes (`topics[0]` ist der Hash der Event-Signatur, wie z. B. die Signatur des `Transfer`-Events).
  * `data`: Hex-codierte, nicht-indizierte Event-Daten.
  * `blockNumber`, `blockHash`, `transactionHash`, `transactionIndex`, `logIndex`, `removed`.
* `error` (im Fehlerfall vorhanden): Objekt mit `code` (`3` bei einem Revert, `-32015` bei einem VM-Fehler) und `message` (z. B. `execution reverted`).

## Preise und CU-Gewichtungen

BlockVectra misst den Verbrauch in Compute Units (CU). Die Gewichtung für jede JSON-RPC-Methode wird dynamisch über `GET /v1/plans` veröffentlicht:

**CU-Gewichtung pro Aufruf**

| Methode | CU pro Aufruf |
| --- | --- |
| `eth_simulateV1` | 20 |
| `eth_call` | 15 |
| `eth_estimateGas` | 20 |

Umrechnungsformeln und Details zum Aufladen finden Sie auf der [Preisseite](https://blockvectra.com/de/pricing/).

Abgelehnte Anfragen — einschließlich Node-Synchronisierung (`-32010`), außerhalb des State-Fensters (`-32011`) oder nicht verfügbarer Methode (`-32601`) — werden nicht berechnet. Die vollständigen Abrechnungsregeln finden Sie unter [Welche Anfragen kostenlos sind](https://docs.blockvectra.com/de/guides/billing-rules/).

## Verwendung mit KI-Agenten und MCP

Autonome KI-Agenten können `eth_simulateV1` direkt über den Model Context Protocol (MCP)-Server von BlockVectra aufrufen.

Das schlüsselbasierte Tool `rpc_call` ermöglicht das Ausführen von JSON-RPC-Methoden auf unterstützten Chains. Der API-Schlüssel muss in den HTTP-Headern des MCP-Clients konfiguriert werden (`x-api-key: {api_key}` oder `Authorization: Bearer {api_key}`) und darf niemals in Tool-Parametern oder Konversations-Prompts übergeben werden.

Beispielhafter Aufruf-Payload für das `rpc_call`-Tool auf Robinhood Chain:

```json
{
  "chain": "robinhood_mainnet",
  "method": "eth_simulateV1",
  "params": [
    {
      "blockStateCalls": [
        {
          "calls": [
            {
              "from": "0x1111111111111111111111111111111111111111",
              "to": "0x2222222222222222222222222222222222222222",
              "data": "0xa9059cbb00000000000000000000000033333333333333333333333333333333333333330000000000000000000000000000000000000000000000000de0b6b3a7640000",
              "value": "0x0"
            }
          ]
        }
      ]
    },
    "latest"
  ]
}
```

Agenten können `status === "0x1"` prüfen, um die Gültigkeit von Vertragsinteraktionen zu verifizieren und den Gas-Verbrauch vor dem Absenden von Raw-Transaktionen zu bewerten. Einrichtungs- und Nutzungsanweisungen finden Sie im [Leitfaden zur Integration von KI-Agenten](https://docs.blockvectra.com/de/guides/ai-agents/).

## Nächste Schritte

* [Kostenlosen Plan und Preise ansehen](https://blockvectra.com/de/pricing/#free), um den Leistungsumfang Ihres Kontos zu prüfen.
* [In der Konsole anmelden](https://console.blockvectra.com/login/?next=%2Fkeys%2F), um einen API-Schlüssel zu erstellen.