My librustzcash "Hello World" project

ChileBob · March 31, 2021, 1:08pm

Anyone willing to give some hints on adding stuff to librustzcash ? I’m finding the Rust part really hard & could use some help.

So far I have :-

built librustzcash
got FFI working from Perl
built a Perl-librustzcash thing that gets the zaddr from a full viewkey (yaay!! Hello World!)
I can also get ‘ak’ & ‘nk’ from the viewkey, other simple stuff

The part I’m stuck on is adding a function to rustzcash.rs to call try_sapling_note_decryption() (in librustzcash/zcash_primatives/src/note_encryption.rs) & accessing its return values.

Very basic Rust stuff that has me horribly confused - functions with Types, functions with Some/None

Here’s what I have so far :-

// ChileBob’s failing attempt to be clever
//
#[no_mangle]
pub extern “C” fn librustzcash_decrypt_note (
height: u32,
ivk: *const [c_uchar; 32],
epk: *const [c_uchar; 32],
cmu: *const [c_uchar; 32],
enc_ciphertext: *const [c_uchar; 580],
ret_addr: *mut [c_uchar; 43],
ret_value: *mut [c_uchar; 8],
ret_memo: *mut [c_uchar; 512],
) → u32 {

// NOTE: Added to ‘use’ section at top to import function from zcash_primatives::note_encryption
// note_encryption::{sapling_ka_agree, try_sapling_note_decryption},

// try_sapling_note_decryption(
// height,
// &jubjub::Scalar::from_bytes(&*ivk).unwrap(),
// &jubjub::SubgroupPoint::from_bytes(&*epk).unwrap(),
// &bls12_381::Scalar::from_bytes(&*cmu).unwrap(),
// &*enc_ciphertext
// );
//
// Pain points :-
//
// - function has a Type, where does that come from?
// <P: consensus::Parameters>
// not a function arg (compiler objects to 6 args, expecting 5)
//
// - values returned as a tuple within Option - ‘Some’, how to access?
// try_sapling_note_decrypt() : Option<(Note, PaymentAddress, MemoBytes)>

// if the decrypt works, update FFI values for :-
// - ret_addr (43-byte array, sapling address)
// - ret_value (8-bytes, value in zatoshis, convert from u64?)
// - ret_memo (512-bytes, memo contents, null padded)
0       // set/clear return value, 1 = success, 0 = fail 
}

Autotunafish · March 31, 2021, 3:11pm

Some/none is a result type, functions can return other types (everything is under some type header) or nothing but you have to define what type goes in and comes out.
You can do it!

ChileBob · March 31, 2021, 3:18pm

I really hate that damned crab…

blender

Autotunafish · March 31, 2021, 3:23pm

Im a total newb and it seems like you already have a better grasp on functions than I do. Its just tricky because its radically safer. The devs on the zfnd discord have a lil rust thread and they might be able to get you squared away, I’ll find the link

ChileBob · March 31, 2021, 3:26pm

Same here, total newb - your pointer to function Types helps, thanks!

I asked a couple of short (and probably very dumb) questions on discord #public-community-dev & got answers, but I really don’t like to bother the devs with this trivial stuff. They have more important things to do than teach me Rust

Edit: Only two compiler errors left - thank-you nuttycom!!

Edit: Now reached that wonderful point where the compiler doesn’t complain but the code still dies - I’m also calling this progress!!!

Edit: Still stuck getting the ‘cmu’ & ‘epk’ from an array of bytes…

github.com

ChileBob/zcash/blob/a26c48c91ddf10c80c7d35e1a4ed9fca06ffbbb4/src/rust/src/rustzcash.rs#L1287


      
          
          
unsafe {    // lets put all this in an unsafe block 'cos we're playing with raw pointers
          
          
    let ref_ivk: [u8; 32] = *raw_ivk;
              let ref_cmu: [u8; 32] = *raw_cmu;
              let ref_ephemeral_key:  [u8; 32] = *raw_ephemeral_key;
              let ref_enc_ciphertext: [u8; 580] = *raw_enc_ciphertext;
          
          
    let ivk = SaplingIvk(jubjub::Fr::from_bytes( &ref_ivk ).unwrap() );   
          
          
    let cmu = bls12_381::Scalar::from_repr(ref_cmu).unwrap();                               // <- borked, causes panic, unwrap()
              let ephemeral_key = jubjub::ExtendedPoint::from_bytes(&ref_ephemeral_key).unwrap();     // <- also borked
          
          
    let enc_ciphertext = &ref_enc_ciphertext;
          
          
    match try_sapling_note_decryption ( 
                  &zcash_primitives::consensus::MAIN_NETWORK,     // use Network type & Network::MainNetwork for runtime selection
                  BlockHeight::from_u32(height),                  // 
                  &ivk,
                  &ephemeral_key,
                  &cmu,

ChileBob · April 4, 2021, 1:47am

So this is where I am now, Rust has stopped complaining and if I reverse the byte-order for ‘cmu’ & ‘epk’ given by ‘zcash-cli decoderawtransaction’ the code doesn’t die !

All this is great but it fails to decode test data (one of these outputs should be decryptable) :-

https://github.com/ChileBob/Ystream/blob/fa50a30cdadedd23ebaa88e7bfa9d68b3c53f8df/test-result.txt

Autotunafish · April 4, 2021, 4:53am

Typically the unwrap call is kind of discouraged because of the else → panic trait unless you’re sure it would be there but sometimes the method doesn’t exist particulary for pointers because its just an address in memory and if you printed it with the debug flag it would be like 0x561764a2d000 or something.
(Sry im a lil distracted, house is a disaster gotta clean tomorrow and thinking about a circuit for a little project for morse code which I may be overthinking its gonna be cool

House is still a disaster )

ChileBob · April 6, 2021, 3:00pm

Still trying to figure this out…pretty sure I’m force feeding junk to my jubjub.

dilbert

(Edit: Moved to #General 'cos I’m really stuck)

hanh · April 6, 2021, 4:55pm

What are you trying to do?

ChileBob · April 6, 2021, 5:05pm

Using librustzcash to decode shielded outputs with a viewkey - ‘payment detector’

I’m getting the output data from ‘zcash-cli decoderawtransaction’, using librustzcash to get the ivk from the fvk & trying that key on the output to see if it belongs to the key with librustzcash try_sapling note _decrypt().

hanh · April 6, 2021, 5:08pm

You wanna get the plain note out of it?

ChileBob · April 6, 2021, 5:11pm

Yes indeed !! That’s the plan

hanh · April 6, 2021, 5:11pm

Callable from Perl?

ChileBob · April 6, 2021, 5:12pm

that part already works already - I have perl code that uses librustzcash via FFI::Platypus

hanh · April 6, 2021, 5:13pm

What function signature do you want?

ChileBob · April 6, 2021, 5:15pm

Here’s the function I’ve been trying to write : librustzcash_decrypt_note()

github.com

ChileBob/zcash/blob/e278766f2daeb1a60827bae99516d1f1a6db2b37/src/rust/src/rustzcash.rs#L1259


      
              0
          }
          
          
#[no_mangle]
          pub extern "C" fn librustzcash_getrandom(buf: *mut u8, buf_len: usize) {
              let buf = unsafe { slice::from_raw_parts_mut(buf, buf_len) };
              OsRng.fill_bytes(buf);
          }
          
          

          
// ChileBob's failing attempt to be clever
          
          
#[no_mangle]
          pub extern "C" fn librustzcash_decrypt_note ( 
                  height: u32,                            //block height
                  raw_ivk: *const [u8; 32],               // raw pointers, cant update or access outside of 'unsafe' 
          
          
                                                // NOTE: bytes from zcash-cli decoderawtransaction
                  raw_cmu: *const [u8; 32],               // NOTE: byte order reversed
                  raw_ephemeral_key:  *const [u8; 32],    // NOTE: byte order reversed
                  raw_enc_ciphertext: *const [u8; 580],   // NOTE: original byte order

hanh · April 6, 2021, 5:23pm

OK, I’ll try to help you tomorrow.

Autotunafish · April 6, 2021, 5:27pm

Have you tried a Box taking the pointer? Ive not played with box types much but I think thays someting they do.
(Also I think that match should return an expression maybe)

ChileBob · April 6, 2021, 6:09pm

Reading pointers is not the problem as rust is getting the bytes I send by FFI, its more like the bytes from zcashd are not what rust expects - maybe a different encoding? Dunno, I have limited understanding of what happens at this level.

adityapk00 · April 6, 2021, 6:41pm

The Rust FFI, although well designed, is fraught with unexpected issues. You also have to worry about ownership, because passing stuff across the FFI boundary means the rust compiler can’t understand it, so ownership and lifetimes become very complex and hard to debug.

I’ve found that the easiest way to pass things around is strings. You take whatever data you want to send, do a base-64 encode into a string, and then pass the string into/from rust. Then, on the other side, you decode the base64 string into bytes. This way, only strings pass the FFI boundary, and that makes everything much easier.

See how this is implemented in Zecwallet here, where strings are passed/returned across the Javascript <-> Rust boundary via FFI.

github.com

adityapk00/zecwallet-lite/blob/master/native/src/lib.rs#L119


      
          
          
    let lightclient =
                  match LightClient::new_from_phrase(seed, &config, birthday as u64, overwrite) {
                      Ok(l) => l,
                      Err(e) => {
                          return format!("Error: {}", e);
                      }
                  };
          
          
    // Initialize logging
              let _ = lightclient.init_logging();
          
          
    let lc = Arc::new(lightclient);
              LightClient::start_mempool_monitor(lc.clone());
          
          
    LIGHTCLIENT.lock().unwrap().replace(Some(lc));
          
          
    format!("OK")
          };
          
          
Ok(cx.string(resp()))