Spec: unified MEMMOVE accelerator by nicole-graus · Pull Request #986 · yetanotherco/lambda_vm

nicole-graus · 2026-09-11T15:02:52Z

Description

Specifies the accelerator implemented in #984.

New MEMMOVE chapter covering memcpy, memmove, memset and commit. The destination domain and the read/write timestamp order are decoded from the entry point, never chosen by the caller: is_set from the syscall number, is_commit from which bus the first row accepted from, both carried inside MEMMOVE_NEXT so a sequence cannot change functionality midway.
COMMIT is now one row per ecall: it keeps the syscall number and the x254 update, and defers the byte loop over COMMIT_DEFER. CNB is retired.
Adds the ADDNW template, which is what rules out a sequence closing into a ring.
Allocates ECALL -30 (copy) and -32 (memset), and lists -31 as reserved for HINT so it is not handed out twice.

…ontract

github-actions · 2026-09-11T15:03:04Z

Kimi Code Review

⚠️ Review failed: Kimi API request failed with status 401

Automated review by Kimi (Moonshot AI)

github-actions · 2026-09-11T15:03:48Z

Codex Code Review

Medium — Commitment indexing becomes inconsistent above 4 GiB. In memmove.toml:350, ADDNW normalizes dst_incr into two 32-bit limbs, but COMMIT and the existing commitment-domain convention represent indices as [index, 0]. After crossing 2^32, subsequent rows emit addresses such as [8, 1] instead of [2^32 + 8, 0]. These are different memory tuples, so otherwise valid commitments cannot balance against the verifier’s output. Preserve scalar indexing for commitments, or update the producer and verifier to use normalized indices consistently.

github-actions · 2026-09-11T15:53:46Z

Kimi Code Review

⚠️ Review failed: Kimi API request failed with status 401

Automated review by Kimi (Moonshot AI)

github-actions · 2026-09-11T15:54:46Z

Codex Code Review

Medium — Commitment indices change representation after 4 GiB (memmove.toml). dst_incr normalizes the commitment index into two 32-bit limbs, while COMMIT and the verifier use [index, 0]. A write spanning index 2^32 therefore emits [0, 1] where the verifier expects [2^32, 0], making valid output unprovable. Preserve the existing field-valued index arithmetic for commitments, or update the producer and verifier to use the same normalized representation.

erik-3milabs

First set of comments. Primary change request: the COMMIT chip should be completely integrated into the MEMMOVE chip; no COMMIT chip should be needed after this PR is done.

Once this is done, I'd be happy to give this another review!

erik-3milabs · 2026-09-14T13:50:47Z

The commit chip can be integrated in the MEMMOVE chip entirely: use the is_commit flag to select the right ecall code (feel free to update the commit ecall nr if required).

Also, note that memmove/memcpy/memset all return a void*, i.e., an address of sort. The same write statement can be used to return the proper return value for the commit chip.

Yes, we can do that. We kept it because Robin suggested keeping it for the ecall number and the x254 update. We can integrate it, the total number of columns will shrink but the cost per-row of MEMMOVE goes up (COMMITS interactions will be paid by all the rows of MEMMOVE).

erik-3milabs · 2026-09-14T13:53:21Z

+[[variables.auxiliary]]
+name = "tail"
+type = "Bit"
+desc = "Whether this row moves a single byte rather than eight"
+pad = 1
+
+[[variables.auxiliary]]
+name = "count_lt8"
+type = "Bit"
+desc = "Whether $#`count` < 8$, i.e. whether this row may not move eight bytes"
+pad = 1


consider merging these two variables into, e.g., "single".

Note that count < 8 => tail = 0 is equivalent to tail = 1 => count >= 8. This means that we can transform the link between them into

LT[single; count, 8] with multiplicity mu-single.

This would require introducing a single = 1 => mu = 1 constraint to ensure there is no negative multiplicity here.

You're right. I will implement it

Fixed it here eb8c87c

erik-3milabs · 2026-09-14T13:55:00Z

+[[constraints.width]]
+kind = "interaction"
+tag = "ALU"
+input = ["count", ["cast", 257, "DWordWL"], ["opsel", "LT"]]
+output = ["arr", 1, 0]
+multiplicity = "first_ecall"
+ref = "memmove:c:bound"


why are we restricting ourselves to count < 257, again?

In fact, why would we even need to range check count in the first place? Given that it is read from memory, we can assume it is a properly formatted value, and we use the SUB chip to decrement it appropriately, which also requires the decremented value to be range checked.

Recommendation: drop the constraint all together.

We want to avoid one ecall to add a lot of rows and make an epoch unprovable. We kept that restriction from #874. Do you say it isn't a problem to have many rows for one cycle?

erik-3milabs · 2026-09-14T13:56:33Z

+[[constraints.commit]]
+kind = "interaction"
+tag = "memory"
+input = [2, ["arr", ["+", ["idx", "dst", 0], "i"], ["idx", "dst", 1]], 0, ["idx", "value", "i"]]
+iter = ["i", 0, 7]
+multiplicity = ["idx", "commit_lane", "i"]
+ref = "memmove:c:commit_value_out"
+
+[[constraints.commit]]
+kind = "interaction"
+tag = "memory"
+input = [2, ["arr", ["+", ["idx", "dst", 0], "i"], ["idx", "dst", 1]], 1, ["idx", "value", "i"]]
+iter = ["i", 0, 7]
+multiplicity = ["-", ["idx", "commit_lane", "i"]]
+ref = "memmove:c:commit_value_in"


what is the reason you haven't used MEMW here? Doing so should reduce this chip considerably, as we reduce 16 interactions to 2.

you're right, I will change it.

Fixed it here c96a174.

erik-3milabs · 2026-09-14T14:26:17Z

+[[constraints.read_input]]
+kind = "template"
+tag = "REG"
+input = [10, "dst", "timestamp"]
+output = "dst"
+cond = "first_ecall"
+ref = "memmove:c:read_dst"
+
+[[constraints.read_input]]
+kind = "template"
+tag = "REG"
+input = [11, "src", "timestamp"]
+output = "src"
+cond = "first_ecall"
+ref = "memmove:c:read_src"
+
+[[constraints.read_input]]
+kind = "template"
+tag = "REG"
+input = [12, "count", "timestamp"]
+output = "count"
+cond = "first_ecall"
+ref = "memmove:c:read_count"


what definition of memset are you using here? The one I found doesn't have a src, yet here we are reading it from 11.

Yes, I agree. src is where the stub writes the bytes, since the accelerator doesn't fill just copies those bytes. But since it's always dst − 8 we can derive it instead of passing it, and then that constraint becomes a definition rather than a check.

I was changing it in the code and realized that if we don't include src and we don't read it from x11, then the multiplicity should be f_ncommit * (1 − is_set) with a degree 2, since that read already has multiplicity f_ncommit and we would need to switch it off for memset. And a degree 2 would need an other column.

erik-3milabs · 2026-09-14T14:30:27Z

+[[constraints.incr_decr]]
+kind = "template"
+tag = "ADDNW"
+input = ["src", ["arr", "step", 0]]
+output = ["cast", "src_incr", "DWordWL"]
+cond = ["-", "μ", "end"]
+ref = "memmove:c:src_incr"


Note that by inlining the ADD chip, we can even reconstruct src_incr[3] from src_incr[2], src[1] and carry[0] since carry[1] = 0. This saves a column.

Same applies to dst_incr.

True, I'll change it.

Changed it in e43cad6. Note that src_incr[3] is used in the address we send on MEMMOVE_NEXT bus, so now we have to derive it there, making it a bit messier.

erik-3milabs · 2026-09-14T14:31:07Z

+
+These concern the _first_ row of a sequence, where the values come from the register file or from `COMMIT`; every later row receives them over `MEMMOVE_NEXT`, where @memmove:c:range_src_incr, @memmove:c:range_dst_incr and @memmove:c:range_count_decr range-check three of the four on the sending side.
+`timestamp` is range-checked by neither side and holds only because it travels unchanged from the `ECALL` at the root.
+@memmove:a:dst is not discharged at all on a commitment sequence (@memmove:aside:index).


what does it mean to "discharge" an assumption?

We meant that an assumption is discharged when you can point to something that actually guarantees it. In that line we wanted to say that nothing guarantees it.
I agree it is confusing, I will rephrase it.

Done here c2bf432.

erik-3milabs · 2026-09-14T14:31:35Z

+
+== Selecting the functionality
+@memmove:c:receive_ecall receives the system call number as $2^32 - 30 - 2 dot #`is_set`$, so `is_set` is decoded from the `ECALL` the guest executed rather than chosen.
+Note that the low limb of that tuple is a line in `is_set` and so reaches every system call number in the negative range: @memmove:c:range_is_set is what excludes them, and it therefore carries the whole decoding argument.


... is a line in ...

what does that mean?

A linear function in is_set. I will reword it

Done here 013d433.

erik-3milabs · 2026-09-14T14:37:17Z

+
+= The Accelerated Memory Operations standard
+The Ethereum Foundation's Accelerated Memory Operations standard fixes what an accelerated `memcpy`, `memmove` and `memset` must provide.
+#footnote([Accelerated Memory Operations; eth-act/zkevm-standards, commit `e6a4cc0`. #link("https://github.com/eth-act/zkevm-standards/tree/e6a4cc0/standards/accelerated-memory-operations")[[src]]])


link is broken.

Fixed in 5ce3ef4.

Co-authored-by: Erik <159244975+erik-3milabs@users.noreply.github.com>

…m the functionality selector

nicole-graus added 4 commits September 11, 2026 09:27

Specify the unified MEMMOVE accelerator

d266134

Correct the MEMW_A admission condition and the memset limb-boundary c…

250c654

…ontract

tighten the chapter

538a5d7

Align the chapter with conventions

35ce3ef

nicole-graus marked this pull request as ready for review September 11, 2026 15:53

erik-3milabs requested changes Sep 14, 2026

View reviewed changes

nicole-graus and others added 7 commits September 16, 2026 11:06

Update spec/chapters/memmove.typ

4426bdc

Co-authored-by: Erik <159244975+erik-3milabs@users.noreply.github.com>

Merge tail and count_lt8 into one single bit

eb8c87c

Route the commit write through MEMW by deriving its memory domain fro…

c96a174

…m the functionality selector

Derive the top halfword of each position increment instead of storing it

e43cad6

change 'not discharged' by 'no guarantee'

c2bf432

reword 'line' by 'linear function'

013d433

fix link

5ce3ef4

Conversation

nicole-graus commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

github-actions Bot commented Sep 11, 2026

Kimi Code Review

Uh oh!

github-actions Bot commented Sep 11, 2026

Codex Code Review

Uh oh!

github-actions Bot commented Sep 11, 2026

Kimi Code Review

Uh oh!

github-actions Bot commented Sep 11, 2026

Codex Code Review

Uh oh!

erik-3milabs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nicole-graus commented Sep 11, 2026 •

edited

Loading