{"id":"84d4c7eb-c4d0-4db6-8f29-6dd548393d51","arxiv_id":"2412.02867","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"GoldFish introduces a WebAssembly-based serverless actor platform with short-term in-memory state and actor-controlled message queuing, claiming up to 92% lower latency and 10x higher throughput than OpenFaaS and Spin.","lead":"GoldFish is a new serverless computing platform that lets small programs, called actors, keep a short-term memory between runs instead of storing every piece of data in an external database. This can cut data-exchange delays by up to 92% and raise throughput up to 10 times versus two common serverless systems, which matters for edge devices with limited resources.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Scale-to-zero claim conflicts with SUSPENDED-phase in-memory state retention; RC-1 remains unresolved.","rationale":"The reader correctly identifies the weakest assumption. The performance numbers may be internally valid, but the causal claim that the novel lifecycle delivers them while preserving serverless properties is not established. The SUSPENDED phase is the crux: if it keeps the VM alive, state persists but scale-to-zero is false; if it shuts down the VM, state is lost. The paper cannot have both, and RC-1 is left unresolved. Other weaknesses (missing stateful baselines, no error bars) are real but secondary; they affect external validity, not the internal contradiction. A single empirical check of VM residency and state survival across the timeout would resolve the contradiction. Given the open-source prototype exists, this check is feasible. The reader's CONDITIONAL verdict is appropriate.","tokens_in":14364,"tokens_out":7393,"duration_ms":71250,"concrete_test":"Instrument a GoldFish actor with an in-memory counter; send one request, then observe the actor process for a period exceeding the user-defined SUSPENDED timeout. Record (a) whether the Wasm VM process remains alive with non-zero RSS during SUSPENDED, and (b) whether a second request after the timeout sees the counter value preserved (state retained) or reset (state lost). This distinguishes true scale-to-zero (VM destroyed, state lost) from warm-idle (VM alive, state kept). The paper's RC-1 answer should be updated to reflect whichever behavior holds.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim rests on a lifecycle that preserves actor state in Wasm VM memory during SUSPENDED (Section 3.1.2) while simultaneously preserving the serverless property of scale-to-zero (Section 2.1, RC-1). These are in direct tension: retaining a VM in memory is not scale-to-zero; a true scale-to-zero implementation would destroy the VM and lose the in-memory state. The paper's RC-1 response ('actors can scale to zero in the absence of invocations while still providing the advantages of stateful functions') is a non-sequitur because SUSPENDED keeps actors alive until a user-defined timeout, after which TERMINATION releases resources. Thus, the novel mechanism only provides state continuity within an arbitrary timeout window; outside that window, it degenerates to the same remote-state or cold-start behavior it claims to avoid. The evaluation never challenges this: all workloads are continuous, so actors remain in SUSPENDED/RUNNING and the cost of a scale-to-zero event is never measured. If a deployed workflow has gaps longer than the timeout, the advertised latency/throughput gains vanish. This makes the scale-to-zero claim load-bearing for the novelty: without it, GoldFish is a warm-pool actor system, a well-known pattern, not a serverless lifecycle advancement.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes GoldFish, a WebAssembly-based serverless actor platform whose two contributions are a lifecycle model (LCM) that keeps an actor alive in a SUSPENDED phase with in-memory state between invocations, and an invocation model (SIM) with a middleware buffer that lets busy actors queue or reject messages. The authors claim these models reduce reliance on remote state services and report experiments against OpenFaaS and Spin in chained-function and workflow benchmarks, with latency reductions up to 92% and throughput improvements up to 10x. The paper includes an architecture description, prototype implementation details, and an evaluation on a single ARM64 machine with 4 cores and 8 GB of RAM.","tokens_in":14578,"tokens_out":7815,"duration_ms":80268,"significance":"If the claims are supported, the contribution is a lightweight, open-source stateful actor runtime that preserves ephemeral state inside a Wasm VM and processes bursts of related messages with lower overhead than general-purpose FaaS. The open-source prototype and concrete workload suite are genuine strengths, as is the use of Wasm for lightweight isolation. However, the significance of the results as stated depends on two unresolved points: whether the system truly preserves serverless scale-to-zero semantics while keeping state in memory, and whether the performance advantage generalizes beyond the two chosen baselines and continuous workloads. There are no formal proofs or mathematical derivations; the contributions are architectural and empirical, so the evaluation quality is load-bearing for the central claims.","major_comments":[{"comment":"The scale-to-zero claim is unsupported and possibly inconsistent with the SUSPENDED phase. Section 2.1 says GoldFish 'still scales down to zero when not in use,' and the RC-1 discussion says actors 'can scale to zero in the absence of invocations while still providing the advantages of stateful functions.' However, Section 3.1.2 defines SUSPENDED as a phase in which the actor is 'not currently processing any tasks but is ready and waiting,' with the duration determined by the user, after which the actor moves to TERMINATION and GoldFish releases resources. Since the short-term state is kept in the Wasm VM's memory, a true scale-to-zero event that destroys the VM would lose that state. The design therefore provides state continuity only within a user-defined idle timeout, and after a longer idle period it reverts to the cold-start or remote-state behavior the paper claims to avoid. The evaluation never exercises this case, because all workloads send messages continuously. Please either characterize GoldFish as a warm-pool actor system with a bounded idle-retention window, or provide a concrete mechanism such as checkpointing that preserves state across scale-to-zero, and add experiments that measure behavior across idle gaps.","section":"2.1, RC-1, 3.1.2"},{"comment":"The performance claims are not supported by the statistical and methodological detail provided. Section 6.1 states that experiments were executed seven times and averaged, but no standard deviation, confidence interval, or significance test is reported, and Figures 7-11 show no error bars. In addition, the workloads are continuous sequences of messages, so they never measure cold starts or scale-to-zero transitions, and all experiments run on a single local machine rather than a distributed edge-cloud deployment. Because the headline claims are 'up to 92% latency reduction' and 'up to 10x throughput,' the evaluation needs per-point variance, an indication of warm and cold start conditions, and ideally a comparison under idle-gap or scale-to-zero scenarios.","section":"6.1, 6.2, 6.3"},{"comment":"The chosen baselines do not support the paper's positioning against stateful serverless actor systems. OpenFaaS and Spin are general-purpose FaaS platforms, so the measured gains may largely reflect the absence of an HTTP gateway hop and the use of a warm actor pool, rather than the novel LCM and SIM mechanisms. Section 7 argues that existing actor approaches such as microActor, Durable Functions, Faasm, and Cloudburst rely on external services and incur overhead, but none of these is evaluated. Adding at least one stateful serverless baseline or a remote-state actor implementation is necessary to substantiate the claim that GoldFish's short-term in-actor state, rather than the absence of HTTP ingress, is what produces the improvements.","section":"6.2, 6.3, 7"},{"comment":"The paper has not specified the mechanism by which an actor influences message processing. The text states that GoldFish actors 'decide the processing of future messages based on the actor input' and that an actor can accept, queue, or reject a message, but Figure 6 and the surrounding flow only describe the middleware querying the actor lifecycle phase and buffer availability. There is no description of an API, host function, or protocol through which user-level code signals acceptance or rejection of a particular message before dispatch. As written, SIM reduces to a busy-actor queue with timeout-based escalation. Please specify the actor-facing control interface and demonstrate with a small example how a user function rejects or accepts a message.","section":"3.2, 4.2"}],"minor_comments":[{"comment":"There are several typos: 'Golfish' in the Section 3.1 heading, 'real-wold' in Section 6, 'Sping' in Section 6.3, and 'comercial' in Section 7.","section":"3.1"},{"comment":"The citation '[28? -30]' is malformed; it should likely be '[28-30]' or the intended references should be listed explicitly.","section":"2.2, RC-3"},{"comment":"Reporting only the mean of seven runs without any spread is insufficient; please report medians and percentiles or standard deviations, and add error bars to Figures 7-11.","section":"6.1"},{"comment":"The benchmark setup should state the concurrency level of the load generator, the client configuration, and how requests per second is measured; otherwise the throughput comparison is hard to interpret.","section":"6"},{"comment":"The sentence 'Channel ... enables actors to carry their previous state to the next one' is misleading, since state is retained in the Wasm VM or actor rather than in the channel; rephrase to describe the actor as stateful.","section":"3.1.1"},{"comment":"The open-source repository is cited without a commit hash, release tag, or dependency versions; adding a reproducibility appendix or a tagged release would help.","section":"5"},{"comment":"The claim that GoldFish 'implements the actor [as] a standard container which can be used by most open source and commercial Serverless platforms' is not demonstrated; either provide a deployment test on a second platform or soften the claim.","section":"7"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is likely acceptable after revision if the authors resolve the scale-to-zero semantics and strengthen the evaluation. I do not see evidence of misconduct; the open-source release is a positive. My main concern for the editor is the novelty positioning: the current text oscillates between a serverless actor lifecycle and a warm-pool actor runtime, and the comparative evaluation does not yet show an advantage over existing stateful serverless systems."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read GoldFish. The honest headline: it is a real piece of engineering with a clear architecture and a working open-source prototype, but the paper overclaims the one property that would make it a true lifecycle advance. What actually works is the SUSPENDED phase with a user-defined timeout plus the waiting/ready/done queues that let actors hold or reject messages. That is a useful warm-pool design for Wasm-based serverless actors, and the invocation model is a genuine if modest extension of the actor idea. The part that does not hold up is \"scale-to-zero.\" Retaining the Wasm VM memory across SUSPENDED means the actor is not at zero; destroy the VM and the short-term state is gone. The paper never resolves this, and the evaluation never measures a scale-to-zero transition. RC-1 remains a claim, not a result.\n\nCredit where due: the system is open source, the architecture is described in enough detail to rebuild, and the latency/throughput deltas against OpenFaaS and Spin are large. The related work section covers the main stateful serverless systems (Faasm, Cloudburst, μActor, Durable Functions) and the self-citation footprint is acceptable.\n\nThe soft spots are real and fixable. No error bars or significance tests; seven runs averaged is thin for 92% and 10x claims. The baselines are general FaaS platforms, not the stateful systems the paper itself identifies as closest. A head-to-head with Cloudburst or Faasm would be fairer and would separate the contribution of in-VM state from the general advantage of warm actors. The evaluation is also continuous, so the interesting question—what happens when a workflow has a gap longer than the SUSPENDED timeout—is never asked. That gap is exactly where the advantage would vanish. Memory durability and crash behavior are not discussed, which matters if the state is meant to replace remote storage.\n\nThis is a solid workshop/short-paper contribution with a promising prototype, not a finished research argument. I would send it to peer review with major revision expectations. The right next version: benchmark against stateful serverless, report variance, and either prove scale-to-zero works with short-term state or drop the phrase and present GoldFish honestly as a warm-pool actor system.","headline":"A real warm-pool actor system with a working prototype, but the scale-to-zero claim is unsupported and the evaluation lacks stateful baselines.","tokens_in":15103,"tokens_out":3745,"would_cite":true,"duration_ms":40246,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"GoldFish claims that adding a short-term memory phase to the serverless lifecycle, and letting actors govern future messages, cuts data-exchange latency by up to 92 percent and raises throughput up to 10x against OpenFaaS and Spin.","keywords":["serverless computing","WebAssembly","actor model","serverless actors","lifecycle model","invocation model","edge-cloud continuum","short-term state"],"falsifier":"Run an actor that increments an in-memory counter on each message, let it enter SUSPENDED, wait past the platform's idle scale-to-zero threshold, send the next message, and check whether the counter resets; if it resets, short-term state does not survive scale-to-zero as claimed.","tokens_in":14152,"feed_emoji":"🐟","tokens_out":7447,"duration_ms":69048,"temperature":0.7,"pith_summary":"The paper argues that the serverless function model, not the underlying hardware, is what forces workflow data through remote storage, and that this cost can be removed by treating functions as short-term actors. It introduces two models: a lifecycle model with a SUSPENDED phase in which an actor keeps its state alive between messages, and an invocation model in which a busy actor can queue or reject future messages. These are implemented in GoldFish, a WebAssembly-based serverless actor platform. Against OpenFaaS and Spin, GoldFish reports data-exchange latency reductions of up to 92 percent and throughput increases of up to 10x. The intended payoff is that ephemeral workflow data no longer needs a round-trip to an external key-value store or object storage.","feed_headline":"Serverless actors with in-VM memory cut exchange latency 92%","feed_subtitle":"GoldFish keeps short-term state between messages, beating two existing serverless platforms by up to 10x on throughput.","key_machinery":"The load-bearing mechanism is the GoldFish actor, composed of an addressable channel, a Wasm Host Interface sidecar that owns the WebAssembly VM, and the user Handler compiled to Wasm. The lifecycle phases CREATED, SUSPENDED, RUNNING, COMPLETED, ERROR, and TERMINATION let the same VM persist between messages for a user-defined period, while the invocation middleware's waiting, ready, and done queues decide whether a message goes to a suspended actor, waits for a busy actor, or is routed elsewhere. The Wasm Host Interface blocks new messages while one is being processed, giving actors single-message-at-a-time semantics without data races.","core_discovery":"The central claim is that short-term actor state can live inside the WebAssembly VM across message executions, so a chain of related events is processed by one actor instance instead of a fresh instance per request. GoldFish's lifecycle model adds SUSPENDED as a first-class phase between RUNNING and COMPLETED, and its invocation model lets the actor tell the middleware buffer whether the next message should be delivered, kept waiting, or forwarded to another actor. This removes the dominant latency cost the paper attributes to remote state services while preserving direct addressability and single-message-at-a-time processing. The reported measurements support the claim with up to 92 percent lower message-exchange latency and up to 10x higher throughput than the two baselines in sequential and fan-out experiments.","pith_inferences":["The compatibility with scale-to-zero is the point most worth probing: if an idle actor is evicted during SUSPENDED, its in-memory state vanishes, so a production deployment would need to checkpoint state to stable storage before eviction, re-introducing some remote-state cost.","The reported gains combine the lifecycle model, the message middleware, and WebAssembly, so an ablation that isolates each component would sharpen the causal claim behind the 92 percent and 10x figures.","A natural extension is to snapshot SUSPENDED state to local disk just before eviction, preserving the short-term state property while restoring the strong scale-to-zero guarantee.","The design could be tested against stateful serverless systems that tier local and remote state, to see whether purely in-memory short-term state remains competitive when workflows grow beyond a single edge node."],"forward_implications":["Actor state survives between executions for a user-defined window, so a sequence of connected workflow events can be handled by one instance rather than re-instantiating an actor per message.","Ephemeral workflow data can pass directly between actors through the middleware buffer, avoiding remote key-value store and object storage round-trips for that data.","A busy actor can reject or defer the next message, and the buffer's time and size limits eventually create a new actor, so workflows get built-in backpressure without message loss.","WebAssembly sandboxing keeps each actor isolated while remaining lightweight enough for resource-constrained edge nodes, and container-based packaging preserves interoperability with existing serverless platforms."],"supporting_citations":[{"why":"Establishes the serverless stateless design and the reliance on external services that the paper's lifecycle model is designed to avoid.","marker":"[1]"},{"why":"Provides evidence that external communication accounts for most function latency, the premise for keeping ephemeral state in the actor.","marker":"[25]"},{"why":"Shows similar latency overhead from external state and messaging services, reinforcing the same motivation.","marker":"[26]"},{"why":"Introduces a stateful serverless actor platform for edge devices that preserves state across messages, a closest predecessor for GoldFish.","marker":"[13]"},{"why":"Defines Durable Functions semantics for stateful serverless, the programming-model approach GoldFish contrasts with its lifecycle-native design.","marker":"[10]"},{"why":"Presents a stateful serverless platform that uses local and remote state tiers, a baseline design the paper argues still incurs state-management overhead.","marker":"[14]"},{"why":"Shows an actor-based serverless system for AI workflows that wraps multiple functions in one actor, an alternative strategy to GoldFish's lifecycle approach.","marker":"[12]"},{"why":"Describes a sidecar-based actor system that manages state via external storage, an architecture GoldFish avoids to cut resource usage.","marker":"[8]"},{"why":"Supplies the WebAssembly runtime shim for inter-function communication that GoldFish builds on for its Wasm host interface.","marker":"[28]"}],"fun_headline_variants":["GoldFish keeps actor state in VM, cuts latency 92%","Serverless actors with in-VM state: 92% less latency","Short-term stateful actors slash latency 92%, raise throughput 10x","GoldFish: stateful serverless actors beat OpenFaaS by 10x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The design assumes that an actor's state can remain in the WebAssembly VM while the actor sits in SUSPENDED and that this still qualifies as serverless scale-to-zero; if evicting the idle VM destroys that state, the latency and throughput advantage over remote-state systems collapses.","fun_headline_variants_meta":{"raw":{"variants":["GoldFish keeps actor state in VM, cuts latency 92%","Serverless actors with in-VM state: 92% less latency","Short-term stateful actors slash latency 92%, raise throughput 10x","GoldFish: stateful serverless actors beat OpenFaaS by 10x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000153,"raw_usage":{"total_tokens":1213,"prompt_tokens":955,"completion_tokens":258,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":571,"completion_tokens_details":{"reasoning_tokens":177}},"tokens_in":571,"tokens_out":258,"duration_ms":2880,"temperature":1.0,"reasoning_tokens":177,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T23:00:02.504235+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an actor that increments an in-memory counter on each message, let it enter SUSPENDED, wait past the platform's idle scale-to-zero threshold, send the next message, and check whether the counter resets; if it resets, short-term state does not survive scale-to-zero as claimed.","supporting_citations":[{"cited_title":"Gonzalez, Raluca Ada Popa, Ion Stoica, and David A","cited_arxiv_id":null,"evidence_quote":"Establishes the serverless stateless design and the reliance on external services that the paper's lifecycle model is designed to avoid."},{"cited_title":"Faastlane: Accelerating Function-as-a-Service workflows","cited_arxiv_id":null,"evidence_quote":"Provides evidence that external communication accounts for most function latency, the premise for keeping ephemeral state in the actor."},{"cited_title":"SAND: Towards High-Performance serverless computing","cited_arxiv_id":null,"evidence_quote":"Shows similar latency overhead from external state and messaging services, reinforcing the same motivation."},{"cited_title":"µactor: Stateful serverless at the edge","cited_arxiv_id":null,"evidence_quote":"Introduces a stateful serverless actor platform for edge devices that preserves state across messages, a closest predecessor for GoldFish."},{"cited_title":"Faasm: Lightweight isolation for efficient stateful serverless computing","cited_arxiv_id":null,"evidence_quote":"Presents a stateful serverless platform that uses local and remote state tiers, a baseline design the paper argues still incurs state-management overhead."},{"cited_title":"Jordan, and Ion Stoica","cited_arxiv_id":null,"evidence_quote":"Shows an actor-based serverless system for AI workflows that wraps multiple functions in one actor, an alternative strategy to GoldFish's lifecycle approach."},{"cited_title":"Akka actor systems","cited_arxiv_id":null,"evidence_quote":"Describes a sidecar-based actor system that manages state via external storage, an architecture GoldFish avoids to cut resource usage."},{"cited_title":"Cwasi: A webassembly runtime shim for inter-function communication in the serverless edge-cloud continuum","cited_arxiv_id":null,"evidence_quote":"Supplies the WebAssembly runtime shim for inter-function communication that GoldFish builds on for its Wasm host interface."}],"review_version":1}