Access Traces in Modern Systems

• Access traces are recorded logs of access events that preserve temporal order and contextual data across various systems.
• Methodologies transform raw logs into structured data via DAG reconstruction, SQL simplification, and time series modeling for effective analysis.
• Practical applications include security diagnosis, workload simulation, anomaly detection, and synthetic trace generation in diverse network contexts.

Searching arXiv for recent and relevant papers on access traces across workflow, database, blockchain, and mobile-network contexts. Across recent systems, security, database, and mobile-network research, access traces appear as recorded histories of access-related events that preserve temporal order, control context, or both. The cited literature uses traces for several distinct but structurally comparable purposes: workflow traces model workloads as directed acyclic graphs arriving over time in datacenters, clouds, and HPC infrastructures; Ethereum execution traces record low-level calls inside transactions for forensic reconstruction; web-application traces log SQL queries together with the conditions that trigger them; and mobile cloud-access traces capture round-trip-time sequences for QoE-sensitive testing (Versluis et al., 2019, Wang et al., 3 Sep 2025, Zhang et al., 2024, Rege et al., 2021). In each setting, the trace is not merely an audit artifact: it becomes the substrate for reproducible experimentation, policy extraction, anomaly scoring, or synthetic trace generation.

1. Trace classes and problem settings

The literature does not present a single canonical trace type. Instead, it defines access traces relative to the access phenomenon being studied. In workflow research, the trace unit is a workload composed of workflows, tasks, resources, and transfers. In Ethereum security analysis, the trace unit is a transaction-level sequence of low-level calls. In policy extraction for web applications, the trace unit is a transcript of query and branch events. In mobile-network testing, the trace unit is a time series of cloud access times.

Domain	Trace form	Primary use
Workflow systems	Workflows (DAGs) arriving over time, plus system resources	Simulation, validation, characterization
Ethereum	Chronologically ordered flat trace $\mathcal{T} = [call_0, call_1, \dots, call_n]$	Security diagnosis and attack-chain reconstruction
Ruby-on-Rails applications	Transcripts of Query and Branch records	Access-control policy extraction
Mobile cloud access	RTT time series $X = [x_1 \dots x_Z]$	Synthetic trace generation for QoE testing

This breadth is reflected in the scale and operational role of the traces. The Workflow Trace Archive (WTA) is an open-access archive containing ${>}48$ million workflows captured from ${>}10$ computing infrastructures, and it explicitly addresses the fact that realistic traces are used infrequently, with realistic, open-access traces used even less frequently (Versluis et al., 2019). Ote treats the database back end of a Rails application as a decision tree over inputs and extracts policy by observing under exactly which Boolean conditions each SQL SELECT fires (Zhang et al., 2024). TraceLLM treats execution traces as the missing link between suspicious transactions and exploitable contract behavior, especially for unverified contracts and proxy-based architectures (Wang et al., 3 Sep 2025). The mobile QoE work treats cloud access time as a stochastic process whose variability depends on RRC states, MNO-specific retransmission configurations, handovers triggered by user mobility, and network load (Rege et al., 2021).

A plausible implication is that “access trace” is best understood as a methodological category rather than a single format: a trace is whatever sequence or structured log preserves the causal or temporal evidence needed to reproduce, explain, or constrain access behavior.

2. Data models and formal representations

The most explicit schema in the cited work is the WTA unified trace schema. WTA models an entire workload as a set of workflows arriving over time, plus system resources, through seven top-level record types: Workload, Workflow, Task, TaskState, Resource, ResourceState, and DataTransfer. The core fields illustrated in the report include workload_id, start_date, end_date; workflow_id, arrival_time, num_tasks, nfr_dict, critical_path_len; and task_id, submit_time, runtime, req_cores, parents, and children (Versluis et al., 2019). Optional fields are carried in a JSON or dict column, nfr_dict supports user-defined non-functional requirements such as deadlines and priorities, and every top-level record has a format_version string so that readers can check the version and gracefully ignore unknown fields.

Ote uses a different abstraction. Its basic object is the “conditioned query,” first described as a pair

$(Q,\;\Phi)$

where $Q$ is a parameterized PSJ query and $\Phi$ is a concrete Boolean formula over session parameters, request parameters, and values returned by earlier queries. Operationally, Ote represents a conditioned query as the triple

$$\bigl(\; \textit{sql}\;,\;\textit{params}\;,\;\Phi\;\bigr)$$

with

$\Phi \;=\; \bigwedge_{j=1}^k \theta_j,$

where each $\theta_j$ is either an equality or null-check on a parameter or result-column (Zhang et al., 2024). This representation is explicitly designed to compile into SQL view definitions that express the application’s implicit access-control policy.

TraceLLM begins from a flat call trace but immediately reconstructs a tree. After collecting low-level events

$X = [x_1 \dots x_Z]$0

it builds a forest of call trees and formalizes each call structure as a directed tree

$X = [x_1 \dots x_Z]$1

where each node $X = [x_1 \dots x_Z]$2 is an invocation instance, $X = [x_1 \dots x_Z]$3 gives its contract address, and each edge carries

$X = [x_1 \dots x_Z]$4

(Wang et al., 3 Sep 2025). This shift from flat trace to structured call graph is crucial because the later anomaly model operates on root-to-leaf paths rather than on isolated events.

The mobile-network work represents an access trace as a time series

$X = [x_1 \dots x_Z]$5

of RTT samples collected at fixed intervals $X = [x_1 \dots x_Z]$6, and standardizes each series by

$X = [x_1 \dots x_Z]$7

The resulting supervised one-step-ahead pairs are $X = [x_1 \dots x_Z]$8 with $X = [x_1 \dots x_Z]$9 (Rege et al., 2021). Compared with workflow or execution traces, this representation is minimal, but it is sufficient for transfer learning and iterative synthetic generation.

3. Trace acquisition, logging, and curation

WTA emphasizes archival accessibility and stable consumption. Its public website provides a sortable table of approximately 95 workloads, each with DOI links to Zenodo, and per-trace HTML “report cards” with summary statistics, CDFs, and plots. Each workload is published as Parquet files with Snappy compression; raw Parquet bundles live on Zenodo; and the source code repositories for parsing, analysis, and simulation are MIT-licensed. The contribution workflow is explicit: submit raw logs or traces with provenance information, convert and anonymize if needed into Parquet, run automated validation and report-card generation, and then publish the workload on the website with a minted Zenodo DOI (Versluis et al., 2019). The report characterizes these choices as supporting discoverability, reproducibility, and community-driven growth.

Ote acquires traces through concolic execution of Ruby-on-Rails code. It hooks only methods that issue SQL, branch on Ruby primitives or query-result emptiness, or pull data out of a previous query; uninstrumented code runs concretely and never spawns new symbolic branches. The driver repeatedly chooses a test vector consisting of a small, bounded symbolic database, with each table given at most two symbolic rows, plus symbolic session and request parameters. Execution returns a linear “transcript” composed of Query and Branch records, while a prefix-tree of branch outcomes is maintained so that an SMT solver can invert the last branch in a leaf prefix and thereby explore a new path (Zhang et al., 2024). This acquisition method is bounded but targeted at the query core of the application.

TraceLLM acquires execution traces through a multi-stage pipeline. A parser receives either a natural-language description of an incident or high-signal alerts from “Key Opinion Leaders” on X, uses Retrieval-Augmented Generation with a domain-specific database to normalize names and date ranges, and emits structured JSON containing contract addresses and a block interval. A detector then operates against a local Ethereum full node, using eth_getCode, debug_traceCall, and debug_traceTransaction. It includes an Implementation Detector for proxy resolution, a Creator Detector for discovering contracts factory-deployed by the same account, and a Transaction Detector that collects all transactions touching each scoped address and maps function selectors to human-readable names when available (Wang et al., 3 Sep 2025). The output is a chronologically ordered flat trace for every relevant transaction.

The mobile QoE work acquires access traces through packet-level measurement. An ICMP ping, or TCP/HTTP with timestamps, is sent at fixed intervals such as ${>}48$0 ms from a device to a server, recording RTTs over traces such as ${>}48$1 samples, approximately 4 hours at 500 ms. Each trace is labeled with context, including network, location, and mobility, and stored in an archive of context-tagged traces (Rege et al., 2021). This measurement-driven acquisition is the prerequisite for later transfer-learning adaptation.

4. Analysis, simplification, and generation techniques

The cited work uses trace analysis for substantially different objectives. WTA characterizes workload diversity along several axes: workflow size distributions; structural patterns such as pipeline, scatter, gather, shuffle, and standalone; arrival patterns by day of week and hour of day; Hurst exponent estimated via R/S analysis; approximate maximum concurrent ready tasks as a measure of parallelism; critical-path length and critical-path runtime; task interarrival times; and an optional diversity index

${>}48$2

The report states that scientific and engineering traces are dominated by pipelines, whereas industrial traces are dominated by scatters, and that trace diversity materially affects simulation outcomes (Versluis et al., 2019).

Ote transforms raw transcripts into policy by successive simplification. For each query in a transcript, it constructs a conditioned query whose condition is the conjunction of all prior branch conditions and all prior non-empty query conditions. It then applies a multi-step simplifier: eliminate conditions guaranteed by schema constraints or trivial implication, propagate equalities, remove duplicate query conditions, merge two conditioned queries that differ in exactly one atom, and drop subsumed queries. For each distinct parameterized query ${>}48$3, it forms the disjunction

${>}48$4

rewrites this into a minimal DNF, and compiles the result into a SQL view. A final pruning pass uses Blockaid to ask whether the union of the other views already implies a candidate view, dropping redundant views if so (Zhang et al., 2024).

TraceLLM uses access traces for anomaly scoring and attack reconstruction. From each call tree it enumerates root-to-leaf paths and computes five feature groups: path fanout, path depth, path frequency, semantic anomaly score over a set of high-risk method names, and TF-IDF of method tokens. These features are concatenated into ${>}48$5, and anomaly probability is computed by logistic regression: ${>}48$6 The highest-ranked paths are flagged as suspicious. In parallel, code is retrieved from Etherscan when available or decompiled via Panoramix and then refined by a large LLM. The analyzer extracts the 1-hop enclosing subgraph

${>}48$7

around each suspicious path and provides this, together with refined pseudocode and balance changes, to a final LLM prompt that narrates the attack chain and identifies attacker and victim addresses, vulnerable functions, and exploitation logic (Wang et al., 3 Sep 2025).

The mobile-network work uses traces as training data for a transfer-learning generator. It selects a source model by minimum Dynamic Time Warping distance between the target trace and pre-trained archive traces, freezes the first ${>}48$8 LSTM layers, fine-tunes the remaining layers and dense output by minimizing MSE with Adam at a small learning rate ${>}48$9, and then generates synthetic traces by one-step iterative prediction from an initial seed history. Because the dense output uses the ProbAct activation

${>}10$0

the generation process preserves outliers and long tails without external clipping (Rege et al., 2021).

5. Empirical results and demonstrated uses

WTA is designed for trace-driven experiments, and its reported findings emphasize heterogeneity rather than a single workload model. The archive includes more than 48 million workflows from more than 10 infrastructures, with approximately 95 workloads exposed through the public site. The accompanying analysis reports significant differences in characteristics, properties, and workflow structures between workload sources, domains, and fields, and argues that these differences matter in simulation (Versluis et al., 2019). The recommended experimental workflow is explicit: browse the archive, download Parquet bundles from Zenodo, optionally anonymize further, validate and inspect, preprocess or subsample if needed, run a simulator or scheduler, report response time, slowdown, makespan, NSL, and resource utilization, and test on at least one scientific and one industrial workload.

Ote was evaluated on three real Rails applications—Diaspora*, Autolab, and The Odin Project—covering 15 handlers in total. The reported summary includes handlers such as People#stream, with 1.18 M paths and 3.26 M conditioned queries simplified to 201, and Posts#show, with 0.25 M paths and 1.67 M conditioned queries simplified to 209. Lessons#show (Odin) is reported with 75 K paths and 73 K conditioned queries simplified to 153. End-to-end wall-clock times ranged from 1–10 hours per handler, dominated by path exploration, and each handler’s SQL policy had at most a few dozen views after processing. The extracted policies revealed several errors in handwritten policies, including inadvertently allowing “disabled” courses to be read by TAs, missing certain foreign-key guards, and a subtle bug in Autolab in which a mis-named lazy-load column caused the exam? check to be a no-op (Zhang et al., 2024).

TraceLLM reports results on both a benchmark with expert reports and a larger real-world incident set. On 27 incidents with ground-truth expert reports, it identifies attacker and victim addresses with 85.19% precision and produces automated reports with 70.37% factual precision, compared with 44.44% for the best code-only plus trace baseline. On 148 real-world Ethereum incidents, it achieves 82.43% precision on address identification. In anomaly-path detection, Leave-One-Group-Out evaluation over 15 labeled incidents, comprising 11,228 paths and 1,530 true attack paths, yields recall ${>}10$1, ahead of Random Forest at ${>}10$2 and GNN baselines at approximately ${>}10$3. For decompilation, Panoramix alone yields 70.25% judged consistent by three independent LLM judges, while the Panoramix-plus-LLM-refine pipeline reaches 78.77%, an 8.52-point improvement. For subgraph depth, ${>}10$4 gives precision ${>}10$5 with approximately 62 k tokens, whereas ${>}10$6 provides no accuracy gains but uses 2–3${>}10$7 more tokens (Wang et al., 3 Sep 2025).

The mobile-network study evaluates synthetic access traces through application QoE reproduction rather than only through trace-fit metrics. With a target-environment sample of approximately 6000 RTT samples, the fine-tuned models provide 20–50% SMAPE improvement over training from scratch and are 1.1–1.8${>}10$8 faster to obtain. In an Instagram photo-sharing case on LTE indoors at home, the real LTE trace yielded median Above-The-Fold Time of approximately 5.3 s, the normal-distribution model approximately 4.6 s, and the synthetic trace approximately 5.3 s; long-tail AFT at the 90th percentile was underestimated by more than 8% with the normal model and by less than 3.5% with the synthetic model. In a Conversations XMPP chat case over mixed LTE and WiFi, the real median delivery-receipt latency was approximately 0.20 s, the normal model approximately 0.21 s, and the synthetic model approximately 0.20 s; worst-case latency was 0.4 s under the normal model versus real 1.34 s, while the synthetic model produced 1.33 s (Rege et al., 2021).

6. Reproducibility, limitations, and methodological tensions

A recurrent theme is that access traces are valuable only insofar as they remain inspectable, replayable, and sufficiently faithful to the originating environment. WTA operationalizes this through DOI-backed Parquet bundles, per-object version tags, automated validation, report cards, and open-source parsers, analysis notebooks, and simulator code. Its validation checks include parent-child pointer consistency, runtime > 0, arrival_time within the workload time span, absence of DAG cycles, and presence of required fields for each record type. The recommended reporting practice is to cite the WTA DOI or DOIs, the trace version, and the tool versions, and to archive any custom filtering or preprocessing code (Versluis et al., 2019).

At the same time, the literature is explicit about incompleteness and approximation. Ote cannot guarantee absolute completeness because of bounded concolic search, and it cannot guarantee minimality because predicate minimization is NP-hard (Zhang et al., 2024). TraceLLM reduces token cost and search space by restricting explanation to a 1-hop enclosing subgraph, and the reported token-efficiency results indicate that deeper subgraphs do not necessarily improve accuracy (Wang et al., 3 Sep 2025). The mobile-network work addresses the difficulty of trace diversity and limited real-trace coverage by transfer learning rather than by claiming a universal generator (Rege et al., 2021). WTA, for its part, highlights that the field still underuses realistic and open-access traces, which suggests that experimental conclusions may remain sensitive to narrow workload choices (Versluis et al., 2019).

A common misconception is that a trace is self-explanatory once collected. The cited work points in the opposite direction. Workflow traces require schema normalization, validation, and diversity analysis before they can support meaningful simulation. SQL transcripts require logical simplification and compilation before they become explicit policy. EVM execution traces require call-tree reconstruction, anomaly scoring, function-name recovery, and code alignment before they become forensic evidence. RTT sequences require standardization, context labeling, and adaptation before they become realistic synthetic inputs. This suggests that the informational value of an access trace lies not only in the recorded events themselves but also in the transformations that make the trace analytically and operationally usable.