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

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) 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:

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"
    ]
  }'

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:

Umrechnungsformeln und Details zum Aufladen finden Sie auf der Preisseite.

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.

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:

{
  "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.

Nächste Schritte

• Kostenlosen Plan und Preise ansehen, um den Leistungsumfang Ihres Kontos zu prüfen.
• In der Konsole anmelden, um einen API-Schlüssel zu erstellen.