Comenzando con TheRPC
Referencia de API
API de Ethereum
Core API
Guías
Ethereum/Debug API/debug_traceBlock

debug_traceBlock

El método debug_traceBlock devuelve un rastreo completo de todos los opcodes invocados de todas las transacciones incluidas en el bloque especificado. Este método proporciona información completa de ejecución de bajo nivel, esencial para la depuración, análisis de seguridad y optimización del comportamiento de transacciones a través de múltiples contratos dentro del contexto de un solo bloque.

Casos de Uso

  • Depurar transacciones complejas e interacciones dentro de un contexto de bloque específico
  • Analizar el flujo de ejecución de contratos inteligentes a través de múltiples transacciones
  • Optimizar el uso de gas identificando patrones ineficientes en múltiples transacciones
  • Realizar auditorías de seguridad de contratos desplegados en condiciones reales
  • Verificar que el comportamiento de las transacciones coincida con los resultados y especificaciones esperados
  • Entender interacciones complejas entre múltiples contratos en entornos de producción
  • Analizar patrones de ejecución de máquina virtual para investigación y optimización
  • Investigar fallos de transacciones a nivel de opcode
  • Verificar la corrección de rutas de ejecución complejas en contratos inteligentes
  • Identificar patrones de uso de gas en entornos de producción
  • Depurar y analizar la ejecución exacta de transacciones dentro de bloques históricos
  • Rastrear todas las llamadas internas a través de un bloque completo de operaciones

Detalles del Método

Este método rastrea la ejecución de todas las transacciones en un bloque a nivel de opcode.

Parámetros:

El bloque codificado en RLP para rastrear

Opciones de rastreo para configurar la salida de depuración

Establecerlo a true desactiva la captura de almacenamiento

Establecerlo a true desactiva la captura de memoria

Establecerlo a true desactiva la captura de pila

Usar un trazador personalizado (disponibles: callTracer, prestateTracer, 4byteTracer, etc.)

Anula el tiempo de espera predeterminado de 5 segundos para el rastreo basado en JavaScript

Devuelve:

Array de rastreos de transacciones dentro del bloque

Gas utilizado por la transacción

Si la transacción falló

El valor de retorno de la transacción

Array de registros estructurados de operaciones EVM

Posición del contador de programa

El opcode ejecutado

Gas restante

Costo de gas para esta operación

Profundidad de llamada

Contenido de memoria EVM (si no está desactivado)

Contenido de pila EVM (si no está desactivado)

Cambios de almacenamiento (si no está desactivado)

Ejemplo de Respuesta (Simplificado)

{
	"jsonrpc": "2.0",
	"id": 1,
	"result": [
		{
			"gas": 21000,
			"failed": false,
			"returnValue": "",
			"structLogs": [
				{
					"pc": 0,
					"op": "PUSH1",
					"gas": 68232,
					"gasCost": 3,
					"depth": 1,
					"stack": [],
					"memory": [],
					"storage": {}
				},
				{
					"pc": 2,
					"op": "MSTORE",
					"gas": 68229,
					"gasCost": 12,
					"depth": 1,
					"stack": ["0x60", "0x40"],
					"memory": [
						"0000000000000000000000000000000000000000000000000000000000000000",
						"0000000000000000000000000000000000000000000000000000000000000000"
					],
					"storage": {}
				}
				// ... more operations
			]
		}
		// Additional transaction traces...
	]
}

Respuesta con callTracer

Cuando se utiliza la opción callTracer, la respuesta se formatea como un gráfico de llamadas para cada transacción:

{
	"jsonrpc": "2.0",
	"id": 1,
	"result": [
		{
			"type": "CALL",
			"from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
			"to": "0xdac17f958d2ee523a2206206994597c13d831ec7",
			"value": "0x0",
			"gas": "0x13458",
			"gasUsed": "0x8fc",
			"input": "0xa9059cbb0000000000000000000000001f9840a85d5af5bf1d1762f925bdaddc4201f984000000000000000000000000000000000000000000000002b5e3af16b1880000",
			"output": "0x0000000000000000000000000000000000000000000000000000000000000001",
			"calls": [
				{
					"type": "STATICCALL",
					"from": "0xdac17f958d2ee523a2206206994597c13d831ec7",
					"to": "0x1f9840a85d5af5bf1d1762f925bdaddc4201f984",
					"gas": "0x8fc",
					"gasUsed": "0x54b",
					"input": "0x70a08231000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
					"output": "0x0000000000000000000000000000000000000000000000000000000000000000"
				}
			]
		}
		// Additional call traces...
	]
}

Trazadores Disponibles

Geth proporciona varios trazadores incorporados que formatean la salida de diferentes maneras:

  1. Trazador predeterminado: Registros detallados de ejecución a nivel de opcode
  2. callTracer: Se centra en la jerarquía de llamadas entre contratos
  3. prestateTracer: Muestra el estado del contrato antes de la ejecución
  4. 4byteTracer: Rastrea estadísticas de uso del selector de funciones
  5. noopTracer: Trazador mínimo para pruebas de rendimiento
  6. opCountTracer: Cuenta las ocurrencias de cada opcode

También puede utilizar trazadores personalizados basados en JavaScript para análisis especializados.

Trabajando con Bloques Codificados en RLP

Este método requiere un bloque codificado en RLP como entrada:

  • Puede obtener un bloque codificado en RLP desde eth_getBlockByHash con el segundo parámetro establecido en false
  • La codificación incluye todos los campos de cabecera de bloque y datos de transacción en formato binario
  • Para fines de prueba, puede utilizar un RLP de bloque conocido de la red
  • Herramientas como web3.js o ethers.js pueden ayudar a extraer y codificar bloques correctamente
  • Los bloques extraídos manualmente aseguran que está analizando exactamente el estado que necesita

Diferencias con debug_traceBlockByNumber y debug_traceBlockByHash

Mientras que los tres métodos proporcionan rastreos de transacciones a nivel de bloque:

  • debug_traceBlock acepta un bloque codificado en RLP como entrada
  • debug_traceBlockByNumber acepta un número de bloque o etiqueta (por ejemplo, "latest")
  • debug_traceBlockByHash acepta un hash de bloque
  • Todos los métodos devuelven formatos de rastreo idénticos
  • Este método es útil cuando ya tiene los datos del bloque codificados en RLP

Consideraciones de Rendimiento

  • Rastrear bloques completos es extremadamente intensivo en recursos, especialmente para bloques con muchas transacciones
  • El tamaño de la respuesta puede ser muy grande para bloques con transacciones complejas
  • Considere usar las opciones disableMemory, disableStack o disableStorage para un mejor rendimiento
  • Para análisis de gráficos de llamadas solamente, el callTracer es mucho más eficiente
  • Los trazadores JavaScript pueden requerir tiempos de espera más largos para bloques complejos
  • Las consultas contra bloques históricos requieren un nodo de archivo
  • El rastreo de bloques con muchas transacciones puede agotar el tiempo de espera en nodos públicos
  • Para bloques de alto volumen, considere rastrear transacciones individuales en su lugar
  • El tiempo de respuesta aumenta con el tamaño del bloque y la complejidad de la transacción
  • Para bloques con transacciones complejas, se recomiendan trazadores especializados

Notas Importantes

  • Este método requiere que las APIs de depuración estén habilitadas en el nodo (--http.api=eth,debug,net,web3)
  • No todos los clientes de Ethereum admiten este método (principalmente Geth con APIs de depuración habilitadas)
  • El parámetro de bloque codificado en RLP debe estar formateado correctamente para que el método funcione
  • Para bloques más antiguos, se requiere un nodo de archivo para acceder al estado histórico
  • El método proporciona rastreos detallados para todas las transacciones en el bloque, lo que puede resultar en respuestas muy grandes
  • Diferentes clientes de Ethereum pueden producir formatos de rastreo ligeramente diferentes
  • El formato de salida depende del trazador utilizado y puede cambiar entre versiones de cliente
  • Los valores de memoria y pila se representan en hexadecimal y pueden necesitar decodificación

Ver también

¡Ayúdanos a Mejorar!
Comparte esta página y ayúdanos a crear un producto aún mejor para ti.