feat: use multi-output predicates by ax0 · Pull Request #49 · 0xPARC/digital-objects-e2e-poc

ax0 · 2025-12-08T13:58:02Z

No description provided.

Co-authored-by: Andrew Twyman <artwyman@gmail.com>

…fying the proof from the blobs

@ax0

Joint work with @ax0 . Integrate multi-outputs crafting into the app_cli, update craftlib predicates & statements building. Co-authored-by: Ahmad <root@ahmadafuni.com>

…t connected to pod logic)

ed255

Overall looks good to me! I've left a few comments

ed255 · 2025-12-08T15:15:43Z

commitlib/src/predicates.rs


    pub subset_of: CustomPredicateRef,
    pub subset_of_recursive: CustomPredicateRef,
+    pub batch_def: CustomPredicateRef,


I think we're not using most of these fields. We could just remove them.

ed255 · 2025-12-08T15:17:49Z

commitlib/src/lib.rs

    // These properties are committed on-chain
    pub inputs: HashSet<Hash>,
-    pub key: RawValue,
+    // TODO: Maybe replace this with a Value -> Value map?


Or even usize -> Value and we only use numbers to index an item in a batch?
Update: I saw that we're using strings for index in craftlib. Value for index sounds good if it gives us more flexibility / ergonomics.

ed255 · 2025-12-08T15:20:30Z

commitlib/src/lib.rs

+
+        // Build ItemInBatch(item, batch)
+        Ok(st_custom!(self.ctx,
+        ItemInBatch() = (


I added a rustfmt rule so that this macro doesn't get formatted. This means it must be formatted manually.
Notice that this line is not indented.

If you have any suggestion to improve this I'd be happy to listen!

ed255 · 2025-12-08T15:20:47Z

commitlib/src/lib.rs

+
+        // Build ItemDef(item, ingredients, inputs, key, work)
+        Ok(st_custom!(self.ctx,
+                ItemDef() = (


See previous comment. Notice that this line is indented twice.

ed255 · 2025-12-08T15:31:13Z

common/src/payload.rs

-        write_elems(&mut buffer, &self.item.0);
        write_elems(&mut buffer, &self.created_items_root.0);
-        assert!(self.nullifiers.len() <= 255);
+        // TODO: What are the constraints on these lengths apart from the type casts below?


there are no other constraints really.
For convenience we use a fixed size encoding, we think that a max value of 255 ought to be enough so we encode the length as a u8.
But if that's too small we can just use a u16.

On the decoding side we may choose to have an upper limit on the length to avoid abuse, because the ETH cost of committing many items in a batch is the same as committing one single item, but the synchronizer takes more load.

ed255 · 2025-12-08T15:35:23Z

synchronizer/src/main.rs

                    }
                    Err(e) => {
-                        info!("Invalid do_blob: {:?}", e);
+                        error!("Ignoring blob due: Invalid do_blob: {:?}", e);


I understand the need to highlight this so that it stands out; but I'd like to point out that receiving an invalid do_blob is not an error from the synchronizer point of view.

Makes sense, initially when there was an error due an invalid blob (note: blob supposed to be a DO blob, but with incorrect formatting (eg. wrongly compressed plonky2 proof)) this was not being noticed but in a lower layer it was just panicking (and stopping the synchronizer completely), which is how noticed an error while adding new features (although it was not clear to detect, needed debugging to find out the cause); so from that I set it to 'warn' and returned the error (with ? instead of the old .unwrap()), but it was easy to miss along all the other logs; so, coming from a panic (.unwrap()), the error log seemed the natural step (also since it was a blob labeled as DO type with an error of formatting).
But it's true that there could be cases where somebody sends an invalid blob labeled as DO type without being an actual error, which should not be reported as an error by the synchronizer; before this PR that case would result in the synchronizer panicking, now it will log the error message.
Maybe we can change it to warn? (for sure not going back to panicking)

I wasn't aware this was panicking before! Thanks for fixing that.
A warn sounds good to me.

ed255 · 2025-12-08T15:40:58Z

craftlib/src/item.rs

        let mut s1 = empty_set.clone();
        s1.insert(&wood).unwrap();
        let mut inputs = s1.clone();
+        println!("1");


these prints should be removed

ed255 · 2025-12-08T15:41:16Z

craftlib/src/item.rs

+        let batch_hash = batch_def.batch_hash(self.params)?;
+        let dust_hash = hash_values(&[batch_hash.into(), DUST_BLUEPRINT.into()]);
+        let gem_hash = hash_values(&[batch_hash.into(), GEM_BLUEPRINT.into()]);
+        dbg!(&batch_def.ingredients.keys);


to be removed

craftlib/src/predicates.rs

ed255 · 2025-12-08T15:50:52Z

app_cli/src/lib.rs

+        })
+        .collect::<Result<Vec<_>>>()?;
+
+    // TODO instead of 'i', use 'index' (which is the blueprint (which takes


this TODO sounds good, I suggest applying this already.

…ce PoW of Stone from 3 to 2 (since now proving in general already involves more recursive steps)

ed255 · 2026-01-07T15:06:00Z

shell.nix

    wayland.dev
    wayland-protocols
-    sway
+    emacs


ed255

LGTM!

dhvanipa · 2026-01-23T19:57:41Z

commitlib/src/predicates.rs

+            ItemDef(item, ingredients, inputs, key, work, private: batch, index, keys) = AND(
+                BatchDef(batch, ingredients, inputs, keys, work)
+                ItemInBatch(item, batch, index, keys)
+                DictContains(keys, index, key)


Why is the DictContains needed if ItemInBatch already includes it?

ItemInBatch doesn't expose the key. If we want the key here we need this DictContains.

Perhaps there are better ways to do this like inlining the ItemInBatch here so that we're more space efficient.

arnaucube and others added 22 commits November 26, 2025 17:18

Port @artwyman's BatchDef, ItemInBatch, AllItemsInBatch predicates

1a2dbdd

Co-authored-by: Andrew Twyman <artwyman@gmail.com>

add st_{batch/item}_def, st_item_in_batch methods; pending update macro

e8af4c6

Adjust predicates

e73940c

WIP

2288bb7

Fix commitlib tests

de016a6

Change itemdef statement method signature

e608127

Update craftlib

3269e08

Use HashMap for keys

936c403

Update app

ecb3cc9

small fixes, identify the cause of the error at the Synchronizer veri…

e953251

…fying the proof from the blobs

Fix committing & verifying

c777b15

Merge branch 'main' into multi-outputs

ffc39b9

Form item POD in steps

94d2a49

Clean-up

345a8ad

wip draft DisassembleStone into 2 outputs predicates

85242b7

fix DisassembleStone related predicates

2c1bf8c

draft multi-outputs DisassembleStone rust statements methods

c5e0108

Complete statement methods

7cde696

(wip) integrate multi-outputs crafting into the app_cli

161b2ce

Joint work with @ax0 . Integrate multi-outputs crafting into the app_cli, update craftlib predicates & statements building. Co-authored-by: Ahmad <root@ahmadafuni.com>

add ui elems for multi-outputs DisassembleStone into Dust+Gem (not ye…

1d6d4de

…t connected to pod logic)

Fix CLI

1bb36f3

Fix mock mode toggle

9631c5c

ed255 reviewed Dec 8, 2025

View reviewed changes

ax0 added 3 commits December 9, 2025 10:13

Clippy

f853b36

Code review

6a1dbbc

Fix GUI flow

4c60ce2

ax0 marked this pull request as ready for review December 9, 2025 04:39

ax0 and others added 2 commits December 9, 2025 14:52

Remove print statements

8e222e1

fix multi-output outputs file naming (& ui icons), parametrize & redu…

6a2ddf4

…ce PoW of Stone from 3 to 2 (since now proving in general already involves more recursive steps)

arnaucube force-pushed the multi-outputs branch from c9e0c6e to a2b32a7 Compare December 9, 2025 12:48

arnaucube force-pushed the multi-outputs branch 3 times, most recently from 18726ab to 6a2ddf4 Compare December 9, 2025 15:27

ax0 added 2 commits December 11, 2025 12:45

Fix CLI

3876041

Drop unnecessary PODs when crafting

d8075cb

ed255 reviewed Jan 7, 2026

View reviewed changes

shell.nix Outdated

wayland.dev

wayland-protocols

sway

emacs

Copy link

Collaborator

ed255 Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😆

arnaucube reacted with laugh emoji

ed255 approved these changes Jan 7, 2026

View reviewed changes

rm shell.nix file

7e2d79a

dhvanipa reviewed Jan 23, 2026

View reviewed changes

Comments

Conversation

ax0 commented Dec 8, 2025

Uh oh!

ed255 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ed255 left a comment

Choose a reason for hiding this comment

Uh oh!

dhvanipa Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

4 participants

dhvanipa Jan 23, 2026 •

edited

Loading