chore: move protocol components from `miden-lib` to `miden-objects` by PhilippGackstatter · Pull Request #2191 · 0xMiden/protocol

PhilippGackstatter · 2025-12-17T12:03:58Z

Refactors the codebase to separate protocol and standards library code. The idea here is that miden-objects will eventually become miden-protocol and miden-lib will become miden-standards.

Main changes

Moved transaction kernel and related components from miden-lib to miden-objects, including kernel procedures, memory layout, advice inputs, and event IDs
Extracted standards library into StandardsLib in miden-lib. So, now we have three libraries, TransactionKernel::library, MidenLib and StandardsLib.
Split build.rs into two, one in objects and one in lib. A shared module was setup that should be kept in sync; however I could not find an easy way to actually share that code. In particular, using an include! in both build.rs scripts technically works when using cargo but rust-analyzer would always show an error.
CodeBuilder was left in miden-lib.
- Moving it to objects is possible, but it would not be able to contain StandardsLib by default, which seems desirable. We'd need an extension trait in lib for that.
- Having it in objects would be nice to simplify assembly of some components, but it's easy enough to work around that with TransactionKernel::assembler directly.
Updated imports across miden-tx and miden-testing
Notably, the AccountInterface is not being moved in this PR. While I think it should eventually live in the protocol crate, I realized it depends too tightly on AccountComponentInterface whose definition consists of references to standard components, and so it doesn't make sense to me to actually move it to objects now. I think we should do this as part of the account (component) interface refactor. Until that time, there's probably no real problem with leaving it in miden-lib.

Review

I tried to keep commits organized as much as possible, and so reviewing by commit should make things a bit easier. Changes in miden-tx and miden-testing are almost all contained in one of the last commits, which consists only of fixing imports.

Open Questions

The CodeBuilder dynamically links StandardsLib. The assumption is that StandardsLib will always be present in the executor and prover host's mast stores. Is this the right choice?

Follow-Up

In a follow-up, I would:

Rename objects and lib into protocols and standards.
Reorganize MidenLib with the miden namespace into miden::protocol.
Reorganize StandardsLib with the miden::contracts namespace into miden::standards.

part of #1563

…name

…/miden-base into andrew-migrate-to-v20-vm

…ndards

bobbinth · 2025-12-18T01:14:11Z

I'm about to start reviewing the PR - so, haven't looked at code in detail yet, but I was imagining this slightly differently:

We'd keep miden-objects largely unchanged.
We'd split miden-lib into miden-protocol and miden-standards

My understanding is that miden-lib in this PR is basically what I was thinking miden-standards would be. And miden-objects and miden-protocol are merged - correct? If so, the main question is whether merging these two simplifies things in some ways (not saying we shouldn't do it, just trying to think through pros and cons).

PhilippGackstatter · 2025-12-18T01:33:06Z

My understanding is that miden-lib in this PR is basically what I was thinking miden-standards would be. And miden-objects and miden-protocol are merged - correct?

Yes 👍

We'd keep miden-objects largely unchanged.

We'd split miden-lib into miden-protocol and miden-standards

I see, I think there was a misunderstanding then. I thought we wanted a single miden-protocol crate that contained all protocol related parts, which includes the types from miden-objects, since these also define part of the protocol.
And miden-objects would later be reintroduced and build on top of miden-protocol to provide pretty much only serialization for the types exposed by it, e.g. tx, block, note, etc.

I think having a single protocol crate like with this PR may allow us to keep protocol-related things more nicely together. For instance, the block building process is currently split in objects and lib, i.e. build_block must be in lib because of the dependency on TransactionKernel. In this PR, this becomes a method on ProposedBlock. I imagine we can come up with a nicer structure for other parts as well, maybe TransactionInputs and others.

I think when we touched objects in the past, we frequently also touched lib which is due to the relatively tight dependency and I don't see a significant downside to merging the two, or a significant upside in keeping them separate.

So I think I slightly prefer the approach in this PR, but would also be fine with trying the split into three crates.

bobbinth

Looks good! Thank you! I left some comments inline - but they are pretty small. I did not review the build.rs files in too much details - so, would be good to get another set of eyes on them.

The CodeBuilder dynamically links StandardsLib. The assumption is that StandardsLib will always be present in the executor and prover host's mast stores. Is this the right choice?

Yes - this will be a guarantee of the network: the standards library will always be available (and in fact, every version of the standards library will be assumed to be available to all network participants).

So I think I slightly prefer the approach in this PR, but would also be fine with trying the split into three crates.

I think it is fine to keep as is. A big part of my original motivation was to reduce the amount of work - but since the work has been done already, not much point in rolling it back.

I do think in the future we'll introduce a different incarnation of miden-objects - this will probably contain basic objects and their serialization/deserialization code, but not much else.

crates/miden-lib/src/account/auth/ecdsa_k256_keccak.rs

crates/miden-lib/src/standards_lib.rs

crates/miden-objects/src/protocol.rs

crates/miden-objects/src/lib.rs

crates/miden-objects/src/transaction/mod.rs

crates/miden-objects/src/transaction/kernel/mod.rs

crates/miden-objects/src/account/header.rs

crates/miden-objects/src/block/proposed_block.rs

bobbinth

All looks good! Thank you! I left just one small nit inline - but we can easily address it in a follow-up.

bobbinth · 2025-12-18T22:16:33Z

crates/miden-objects/src/protocol.rs

nit: I would probably rename this file into protocol_lib.rs to keep the naming consistent with standards_lib.rs.

…ndards

…ocol-and-standards

…xMiden#2191)

Fumuran and others added 30 commits December 10, 2025 18:41

refactor: rust code updated

787e3e8

refactor: building state

d4db19d

refactor: updating tests part 1

81a9040

refactor: updating tests -- event error WiP

191adeb

refactor: update component procs usage, update proc imports

a4f98a7

Merge branch 'next' into andrew-migrate-to-v20-vm

bd5f15b

refactor: update imports in nullifier_tree, update formatting

96d1c37

chore: update changelog

facd51f

docs: fix docs

b6e5295

chore: use 0.20.1 version of the VM

3feb14a

Merge branch 'next' into andrew-migrate-to-v20-vm

a1cdf82

docs: remove LibraryPath mention from docs

a0f5f08

refactor: rename stdlib to core lib

de4774a

refactor: remove in_debug_mode

69f392c

Merge branch 'next' into andrew-migrate-to-v20-vm

ce37ad5

chore: Pull well-known dependencies out of account (component) interface

bff89f9

chore: Move ERR_AUTH_... to the epilogue category

7a17e6f

chore: refactor error constant extraction for better modularity

aeaa25c

chore: add changelog

9128ed2

refactor: update changelog, clean code, rename get_procedure_root_by_…

c538b88

…name

Merge branch 'andrew-migrate-to-v20-vm' of https://github.com/0xMiden…

24d6195

…/miden-base into andrew-migrate-to-v20-vm

Merge remote-tracking branch 'origin/next' into andrew-migrate-to-v20-vm

b7c165d

Merge branch 'andrew-migrate-to-v20-vm' into pgackst-protocol-and-sta…

cf010a8

…ndards

chore: move add_assets_to_account to basic wallet

5506d90

fix: remove wallet import in miden::active_note

172e0e4

chore: Move AccountInterface::get_procedure_digests to interface ext

6fa7c96

chore: explain tx kernel, protocol and standards errors

79a30ab

chore: use protocol.rs for error file name

ecaccf8

fix: protocol error import

2ba3136

chore: move tx kernel and miden lib to miden-objects

8c3e0f5

PhilippGackstatter added 4 commits December 17, 2025 19:01

chore: remove unused dependencies

39403e5

chore: add changelog

4afb8df

fix: broken doc links

be913d1

fix: imports in doc tests

fe69c28

PhilippGackstatter requested review from bobbinth and mmagician December 17, 2025 12:17

bobbinth approved these changes Dec 18, 2025

View reviewed changes

PhilippGackstatter mentioned this pull request Dec 18, 2025

Remove error type re-exports #2196

Closed

PhilippGackstatter added 6 commits December 18, 2025 11:38

chore: rename MidenLib to ProtocolLib

dad217b

chore: improve KERNEL_PROCEDURES import

cf7db6a

chore: reorganize kernel module

391f3cf

chore: improve method names

f5f56cc

fix: "protocolib" typo

162b541

chore: rename more occurrences of miden lib to protocol lib

396fd2d

This was referenced Dec 18, 2025

feat: rename miden-objects into miden-protocol and miden-lib into miden-standards #2197

Merged

refactor: Implement component schemas #2193

Merged

bobbinth approved these changes Dec 18, 2025

View reviewed changes

huitseeker and others added 5 commits December 18, 2025 20:49

chore: adjust deny.toml to allow duplicate syn version

ee817bf

Merge branch 'next' into andrew-migrate-to-v20-vm

442b87c

refactor: fix merge errors

f746d23

Merge branch 'andrew-migrate-to-v20-vm' into pgackst-protocol-and-sta…

4046db9

…ndards

Merge branch 'pgackst-protocol-and-standards' into pgackst-split-prot…

0b2bf9b

…ocol-and-standards

Base automatically changed from pgackst-protocol-and-standards to next December 20, 2025 08:11

bobbinth added 2 commits December 20, 2025 00:21

Merge branch 'next' into pgackst-split-protocol-and-standards

edc885c

chore: fix merge issues

0a7e31f

bobbinth merged commit fb0b6e9 into next Dec 20, 2025
18 checks passed

bobbinth deleted the pgackst-split-protocol-and-standards branch December 20, 2025 08:43

afa7789 pushed a commit to afa7789/miden-base that referenced this pull request Jan 15, 2026

chore: move protocol components from miden-lib to miden-objects (0…

55909b4

…xMiden#2191)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: move protocol components from `miden-lib` to `miden-objects`#2191

chore: move protocol components from `miden-lib` to `miden-objects`#2191
bobbinth merged 64 commits intonextfrom
pgackst-split-protocol-and-standards

PhilippGackstatter commented Dec 17, 2025 •

edited

Loading

Uh oh!

bobbinth commented Dec 18, 2025

Uh oh!

PhilippGackstatter commented Dec 18, 2025

Uh oh!

bobbinth left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bobbinth left a comment

Uh oh!

bobbinth Dec 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

PhilippGackstatter commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Main changes

Review

Open Questions

Follow-Up

Uh oh!

bobbinth commented Dec 18, 2025

Uh oh!

PhilippGackstatter commented Dec 18, 2025

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

bobbinth Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

PhilippGackstatter commented Dec 17, 2025 •

edited

Loading