One Felt type for on-chain and off-chain code

[greenhat]

Why

As we discussed on our calls while I was working on #808 having two separate Felt types for the on-chain and off-chain code is quite painful:

• Semantically equivalent type defined twice (Word, Asset, AssetId, etc);
• Two Felt serialization crates introduced in Typed note inputs #808;
• Potentially two Word serialization crates needed for Typed account storage definition and initialization #789 (keys and values have to be stored as Word);

How

I wonder if using conditional compilation and a cargo feature would allow us to have one Felt type in both on-chain and off-chain code.

Something along these lines:

// Felt(f32): only on wasm WITHOUT the `true-felt` feature
#[cfg(all(target_arch = "wasm32", not(feature = "true-felt")))]
pub struct Felt(f32);

// Felt(u64): non-wasm OR wasm with `true-felt` enabled
#[cfg(any(not(target_arch = "wasm32"), feature = "true-felt"))]
pub struct Felt(u64);

The true-felt feature is needed for the web-client that builds Rust code for the wasm target (right?). The web-client would be built with the true-felt feature enabled to have u64 felt.

Obviously we would have to do it in a separate, very slim crate (miden-felt?) that would be at the bottom of our dependency chain with winter-math and miden (SDK) depending on it. And another crate (miden-core-types?) with the core types like Word, Asset, AssetId, Recipient, etc. that we want to share between the on-chain and the off-chain code that would be a dependency for miden-base and miden (SDK).

Pros:

• User-defined types can live in a separate crate that can be used as a regular crate dependency in their on-chain and their off-chain code;
• One Felt/Word serialization crate;

Cons:

• Changes to the miden-felt and miden-core-types crates would require more effort to propagate everywhere;

If you think this approach is worth pursuing I could whip up a PoC to test the idea.

@bitwalker @otrho @bobbinth Thoughts?

[greenhat]

Pinging @Al-Kindi-0

[greenhat]

The cheap way to test this idea would be to make a miden-felt crate with this unified Felt (float for Wasm and wrap miden-core::Felt for other targets) type and use it in miden (SDK, on-chain) and revamped unified Felt serialization introduced in #808.

[Al-Kindi-0]

I think this should be possible and the most natural place for this would be in our crypto crate.
cc @huitseeker @adr1anh

[greenhat]

Thank you Al! This is encouraging.

To be clear in my comment above (#853 (comment)) I was describing the proof-of-concept that we want to try to test our assumptions that it'll actually work. If it works, we will do it the right way, going all the way down to the BaseElement(u64) definition in the winter-math and switching to the new unified Felt there and everywhere through our ecosystem of crates.

[Al-Kindi-0]

Sounds good, it shouldn't be too difficult to get a quick PoC going, I believe.
Just a note, as of the current VM release, we have switched to p3-miden-goldilocks and pretty soon we will switch to the p3-goldilocks dependency.

[greenhat]

PoC is ready and working. See my findings and ideas in the PR desc #865