(EDITED) following README example - slower proving time?

[AdamISZ]

Following in with the same setup and intent as in #9 , I now get this error, which seems to be a failure on a sanity check verification in src/main.rs line 238:

waxwing@here:~/code/output-zero$ cargo run --release -- --utreexo-acc "`cat acc.json`" --utreexo-proof "`cat proof.json`" --leaf-hash '3baea3c5fbc3afb0ec11379416a68a1e2a64df318ea611f58213e87c50d8ccd1' --prove --priv-key '6fc5d9e0dcd0cad79cea037a28850abe4a661d7a2c2de72311feea912acc5dbf' --receipt-file 'receipt.bin'  --msg 'this is message' --tx-hex "`cat tx.hex`" --vout 1 --block-height 226735 --block-hash '00000019cfb5ef098766c4602dbfbb7351ad61a71c2f451d80feb2eb65563b63'
   Compiling methods v0.1.0 (/home/waxwing/code/output-zero/methods)
method: Starting build for riscv32im-risc0-zkvm-elfethods(build)                                                                                                    
method:     Finished `release` profile [optimized] target(s) in 0.06s
   Compiling host v0.1.0 (/home/waxwing/code/output-zero/host)
    Finished `release` profile [optimized + debuginfo] target(s) in 48.93s
     Running `target/release/host --utreexo-acc '{"leaves":34524681,"roots":["51230bd5bfe0deef7b2ced1f352efe2fd1e9d0cda1ad016687703b72265c5454","3d208c1237c05d9338f4070f30932d7cb338e1fe8db8675d95d39be1b3a31d23","7337b48efafd5eaec6047f4990e8d69528809eeaf81e895edd973d616c99d207","be5b07aa2de312cd58a68ad4e0dcd79e623ad45df3833847cfa25c62e8d4ed73","991f3f993672384f947c8f341a25936fe0e4170e0a37581c0c9fa51bb5209764","309f62258e0aeb8558ee207422afd3eb812334029e2380ce44f3c03720e404ab","c3194b0dba1557b8f8b61cd7d8f36b8575553ab5cfff7460929c2278773c53eb","6a286acb0adcd230fba8aed0c3b2be12b98757baec2c5435b2c34bf6b5279dba","2e56c97b521de2c5d0a30aa2c5e1dce3ae3fcf157ebdc0d9560e72735c742777","f127465e6e485934b3621f8ac2c0c0f8e322140358f943e9a57dc41d0babdbfe","f233eeb0296d5ec7da5a07fa39e7ea11e53a1365ae3fd6bb9df42e4070ba7456"]}' --utreexo-proof '{"hashes":["afaa8281747115a062853c99c00c2ed79ba2ac0e2c75e407e3806aa2c389e9ad","7f90fe4a848deb0e60278c7c3a0f16c02f54aaf437a511d1c64aa7add60b5ea0","55987cd5983ab8eb3f3d38f9f107a79e8aa08642ad47e5a8c0765e5ef3f2dc30","f266fcb10a06aca8c0860fb79503d4dea3de19e467ee416801cd5b92faaaae91","7e84391f6c43ffdcb5185da7037910f7f9d8798276d522e6dd9c57b4be3e1075","a7b2f2ecc5288693521b78756190e966ae49e6a6f0db6e7e4a5be11bea7682f4","0c4cede28fb2eb50c2975484ddaaf275e7821126a54fe0d1bc5ed375521d2799","237c6c8b39c6fb4c4414ca4a7ad534e8079fc00503ef7e0f44e82e0c42c22031","8a61b05d1ae4f015346405ab9d9f8aa7d515db80ac9e704401db9612f672102e","05c522c0c0fdb129ac12d648f83bc18b4e5d93dddc126a4e4a3875a5679bdcde","b781706010e9afd74a761ab751a45cd3142cc5b609216b0952f0148518f3c62b","60c604f84e2d89da5fbb2622788970c5eaa48533e6d63e19cf4354fba7a24b14","e6e241a2b5cedc1e76e95bff8265ca7022dde4a9eea45209fd64fec5cfa763f0","fdb01a7b10fec966372bbc7844124b88bbe93609ed6f82150df9a162def7e57c","6e898b3014996df83ee996baa51b445d27cb85f0b4af823c4393c751209a30eb"],"targets":[134100388]}' --leaf-hash 3baea3c5fbc3afb0ec11379416a68a1e2a64df318ea611f58213e87c50d8ccd1 --prove --priv-key 6fc5d9e0dcd0cad79cea037a28850abe4a661d7a2c2de72311feea912acc5dbf --receipt-file receipt.bin --msg 'this is message' --tx-hex 020000000001019dc9a8bebdacf1f8730c433e38ab31b1cca10e1be967cd77d7364ce72c5e88f80100000000fdffffff0202b632c8f4020000225120aac35fe91f20d48816b3c83011d117efa35acd2414d36c1e02b0f29fc3106d90eb3d010000000000225120985861caff70a7e1a5086296c351e75f197ec4f9144c52c467d5306c4e261e4c01400bb8fa91077362283324f1141334467c45f7e15af1e8113dc4158697efcca1e94424e2699833ec8f1a116be3bf61eee9af81693223005df619d1c6d00966830a00000000 --vout 1 --block-height 226735 --block-hash 00000019cfb5ef098766c4602dbfbb7351ad61a71c2f451d80feb2eb65563b63`
priv: 6fc5d9e0dcd0cad79cea037a28850abe4a661d7a2c2de72311feea912acc5dbf
pub: bd70caa34056cc4bb2b66f44e038c52f1f87f4fb20703f6209617bb58a032a5d
address: tb1pnpvxrjhlwzn7rfggv2tvx508tuvha38ez3x993r865cxcn3xrexqn9t6jl
using default proof type
txid: 48356de0a84cd6022ff84a70f805922ec7c799c1a01d683b8c906d38824e71e2, block_hash: 00000019cfb5ef098766c4602dbfbb7351ad61a71c2f451d80feb2eb65563b63 vout: 1 height: 226735
lh: 0x3baea3c5fbc3afb0ec11379416a68a1e2a64df318ea611f58213e87c50d8ccd1
proving 3baea3c5fbc3afb0ec11379416a68a1e2a64df318ea611f58213e87c50d8ccd1
proof: Proof { targets: [134100388], hashes: [afaa8281747115a062853c99c00c2ed79ba2ac0e2c75e407e3806aa2c389e9ad, 7f90fe4a848deb0e60278c7c3a0f16c02f54aaf437a511d1c64aa7add60b5ea0, 55987cd5983ab8eb3f3d38f9f107a79e8aa08642ad47e5a8c0765e5ef3f2dc30, f266fcb10a06aca8c0860fb79503d4dea3de19e467ee416801cd5b92faaaae91, 7e84391f6c43ffdcb5185da7037910f7f9d8798276d522e6dd9c57b4be3e1075, a7b2f2ecc5288693521b78756190e966ae49e6a6f0db6e7e4a5be11bea7682f4, 0c4cede28fb2eb50c2975484ddaaf275e7821126a54fe0d1bc5ed375521d2799, 237c6c8b39c6fb4c4414ca4a7ad534e8079fc00503ef7e0f44e82e0c42c22031, 8a61b05d1ae4f015346405ab9d9f8aa7d515db80ac9e704401db9612f672102e, 05c522c0c0fdb129ac12d648f83bc18b4e5d93dddc126a4e4a3875a5679bdcde, b781706010e9afd74a761ab751a45cd3142cc5b609216b0952f0148518f3c62b, 60c604f84e2d89da5fbb2622788970c5eaa48533e6d63e19cf4354fba7a24b14, e6e241a2b5cedc1e76e95bff8265ca7022dde4a9eea45209fd64fec5cfa763f0, fdb01a7b10fec966372bbc7844124b88bbe93609ed6f82150df9a162def7e57c, 6e898b3014996df83ee996baa51b445d27cb85f0b4af823c4393c751209a30eb] }
thread 'main' panicked at host/src/main.rs:238:5:
assertion `left == right` failed
  left: Ok(false)
 right: Ok(true)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

running current master f1cf542

[AdamISZ]

OK this was my error, but the way it happened may be of interest to you:

I was re-using the old proof.json file from the earlier run, and only updated acc.json, so I guess these two are "out of sync", hence the above failure.

Now it's running fine after I updated proof.json.

[AdamISZ]

I got this result:

Proving took 918.84798707s

I'm using: Asus Vivobook with 40GB RAM (top indicated it was using about 20% of that, only), 12 i7 cores on (as mentioned) ubuntu 22.04. So this is a pretty vanilla consumer device. It seemed like it was using on average 10 cores according to top output.

I'm writing this out as a datapoint, but I'm curious as to whether there's some other configuration detail I could have changed to avoid the slower time?

[AdamISZ]

I removed the CUDA feature from the Cargo.toml under host/ , but that isn't the culprit; proving time was basically the same.

Edit: related perhaps, in the risc0-zkvm crate description of features, for the feature "metal", it says "Deprecated - Metal GPU acceleration for the prover is now enabled by default on Apple Silicon."

[AdamISZ]

Verification shows receipt verified in 182.014537ms so that part seems to be in line with what's expected.

[halseth]

I removed the CUDA feature from the Cargo.toml under host/ , but that isn't the culprit; proving time was basically the same.

Edit: related perhaps, in the risc0-zkvm crate description of features, for the feature "metal", it says "Deprecated - Metal GPU acceleration for the prover is now enabled by default on Apple Silicon."

My guess is that the laptop you are using doesn't have a supported GPU, and hence will be much slower creating the proofs.

The one I've been using (Macbook M1) has Metal GPU acceleration, and this is supported by default. If you do have a CUDA compatible GPU I would check this guide in order to enable it: https://dev.risczero.com/api/generating-proofs/local-proving#nvidia-gpu

Your proving time of 15 minutes is actually better than I expected if there is no GPU acceleration in use. It will be interesting to see how much we can get this down by optimizing the zk application :)

[AdamISZ]

For the MuSig2 example I got 1470s proving and 264ms verifying, fwiw.

[halseth]

@AdamISZ I did bump some dependencies and precompiles, that significantly improved proving time on my machine using succint proof type (proving 119s->50s).

Could you try the musig2 branch at this commit: 1bfa7d8

[AdamISZ]

Could you try the musig2 branch at this commit: 1bfa7d8

Sure:

Proving took 943.570568146s
receipt verified in 179.769317ms

[AdamISZ]

I was thinking this morning, hmm, did I watch a video while that was running? Maybe a slightly unfair test? 😆

So here is another run without videos!:

Proving took 746.71451634s
receipt verified in 148.614997ms

Probably more in line with what you were expecting, I'd guess.

[halseth]

Nice, pushed some more optimizations: 3b67d8c

Seems like the ECC multiplication during Musig key aggregation that is the main bottleneck at this point

[AdamISZ]

Seems like the ECC multiplication during Musig key aggregation that is the main bottleneck at this point

So is that profiling the execution time "within the zkVM" of risc0? I'm a little vague in my mind on what's going on. Also I can't see in that picture how the time is divided up?

Since the ECC operations are not native, it makes a ton of sense that they would be very slow (big advantage for the Curve Trees approach, but, can of worms..). But I don't really understand what I'm looking at. I tried clicking the image in case something was cropped but it's just blank. What do the colors indicate? Also I'm seeing SHA512 referred to, but KeyAgg only uses SHA2 (double) in tagged hashing.

[AdamISZ]

Nice, pushed some more optimizations: 3b67d8c

Proving took 576.646058605s
receipt verified in 109.893574ms

[AdamISZ]

Seems like the ECC multiplication during Musig key aggregation that is the main bottleneck at this point

But I don't really understand what I'm looking at.

OK I looked at it with fresh eyes this morning and removed my "read things left to right" bias 😆 .. it isn't hard to grok what the diagram is saying, indeed it says what you said, pretty clearly.

[halseth]

Since the ECC operations are not native, it makes a ton of sense that they would be very slow

So, I did think about this a bit, and wondering if this approach is sane:

Instead of doing the key aggregation and signature verification in zero-knowledge, I make the taproot output key have this form:

P_tap = P + beta*G

Where beta is a blinding factor (this must be coordinated by the channel counterparties) and P is the aggregated key from the [bitcoin_key1, bitcoin_key2] as before.

Now when the gossip message is received, you do the signature check against [node_key1, node_key2, bitcoin_key1, bitcoin_key2] as before.

We also attach a ZK proof showing that P+beta*G is in the UTXO set, without revealing beta or beta*G.

This avoids all expensive ECC multiplication and we end up with the utreexo inclusion check being the most heavy operation (proving time 30 sec on my machine) (this can likely be optimized by choosing a different hash function):

@AdamISZ What do you think, is this a sane approach? Also maybe curve trees could be used here?