Eliminate confusion on party vs participant indices

[ggutoski]

Confusion between "party" and "participant" indices is a consistent source of bugs.

• "party" indices are in 0..share_count from keygen
• "participant" indices are in 0..participant_count from sign

eg. participant_indices[my_participant_index] == my_secret_key_share.my_index

Suggestion

Use the newtype pattern to wrap usize for party vs participant indices

• write simple methods to convert between them
• eg. my_secret_key_share.all_eks can be indexed only by party indices
• eg. in_r2bcasts can be indexed only by participant indices

You'll probably need a special collection type for each of party, participant index types that's basically a Vec that can be indexed by the index type instead of usize.

[ggutoski]

This crate looks promising: typed_index_collections - Rust. The author even lists competing crates---classy!

[ggutoski]

@sdaveas as a first step in refactoring perhaps you can start thinking about this issue. I have a few ideas so let's keep in close contact.

Some rough notes from 2021-04-28:

• This is close to useful typed_index_collection - Rust. Unfortunately, the index type is tied to the value type. So if I have a collections c,d of type Collection<T> then I could confuse indices for c with those for d.
  • Interesting but not what I want either: vec_map::VecMap - Rust
  • This might be a winner: typed_index_collections - Rust
    • Also checkout self-disclosed similar crates
    • Maybe I can simplify index derivation. Examples want me to make a struct FooId(usize) and derive From<usize> etc. But I can make a generic struct Id<T>(usize,PhantomData<T>) and then implement all the stuff I need to generically over T. Then when I want a new index type I just do

    struct Marker;
    type MyIdx = Id<Marker>;
    let vec : TiVec<MyIdx,T> = // ...

[ggutoski]

Looking ahead, I'd like our solution to this issue to also do the following:

1. integrate/replace FillVec
2. support friendly iterators

For item 2: The vision is as follows. In each protocol round I'd like to have access to two iterators:

• all iterate over all parties (including myself)
• other iterate only over other parties (not including myself)

These iterators should have access to all relevant data. eg. as all ranges over all parties 1,...,n, I can do things like all.r1bcast, all.r2bcast, etc. No need for separate iterators for r1bcast, r2bcast, etc. Also, there should be no need for cruft like as_ref, vec_ref, unwrap, etc. All the data should just be there--no Options.

It's not clear to me whether this is a realistic goal. Perhaps any solution would require lots of cruft and mem copy just to prepare the iterator, in which case it might not be worth the effort.

[ggutoski]

Fixed with the recent refactoring. See https://github.com/axelarnetwork/tofn/blob/27f567864db6836b6df704d4b9fb82066678759d/src/collections/typed_usize.rs