trace_対debug_：どのtracing namespaceを使うべきか
トランザクションが実際に何を行ったか——すべての内部コール、すべてのstate変更——を正確に知る必要に迫られたことがあるなら、2つのEVM tracing namespaceに出会っているはずだ。両者は混乱するほど重複し、無視できないほど異なる。これはその実践的な地図である。
debug_ namespace
debug_traceTransactionとdebug_traceCallはgethネイティブだ。これらは設定可能なtracer（デフォルトのstruct logger、あるいはcallTracerやprestateTracerといったbuilt-in）を実行し、opcodeレベルまたはコールレベルの詳細を返す。callTracerが主力である：値、gas、revert理由を伴う完全な内部コールツリーを返し、それこそがほとんどのアプリケーション開発者が実際に求めているものだ。
trace_ namespace
trace_transaction、trace_block、trace_filterはOpenEthereum/Erigon由来だ。trace_filterが際立っている：自分でトランザクションを再実行することなく、from/toアドレスによってブロック範囲にわたる内部コールをクエリできる——価値の流れを追跡したり、あるアドレスの活動を再構築したりするのに非常に有用だ。この範囲フィルタのパターンに相当するきれいなdebug_の手段は存在しない。
両者の選択
特定のトランザクションハッシュがあってそのコールツリーが欲しいなら、debug_ callTracerを使え。アドレスまたはブロック範囲があって、それに触れるすべての内部コールが欲しいなら、trace_filterを使え。opcodeレベルのgasプロファイリングには、struct loggerを伴うdebug_を使う。これらすべては、履歴ブロックに対して実行するにはarchive stateを必要とする——full nodeは最近の履歴しかtraceできない。
よくある質問
両方のnamespaceはすべてのチェーンで利用できるのか？
いいえ。利用可否はクライアントに依存する。Erigonベースのnodeはtrace_とdebug_の両方を公開する。一部のop-stackやその他のクライアントはdebug_を公開するが、完全なtrace_セットは公開しない。対象チェーンのメソッドリファレンスを確認せよ。
なぜtracingは通常のコールよりはるかに高価なのか？
tracingはインストルメンテーションを伴ってEVM上でトランザクションを再実行し、履歴tracingはそのブロックのarchive stateを必要とする。演算とストレージの両方が単純な現在state読み取りより重いのだ。
関連記事
チャージして、キーを取得し、リリース。
セルフサーブ。暗号資産またはカードで支払い。クレジットで従量課金——重いプリミティブは高く、単純なものは安価。
APIキーを取得