Protocol combinators

[fjarri]

We have several different situations where we need to build on top of an existing protocol or combine several of them:

1. Modifying messages the node sends, keeping Round::Protocol the same. This is useful for writing tests.
2. Chaining two protocols together. This is useful e.g. for joining Presigning and Signing in CGGMP.
3. Executing two independent protocols simultaneously. See Add a zip combinator for protocols #61, will be implemented in another PR.
4. Building on top of an existing protocol, adding features. See Add an extend combinator for protocols. #62, will be implemented in another PR.

• Scenario 1 done as misbehave. Override macro and its machinery is removed from testing.
• Scenario 2 done as chain.

Also:

• Renamed FirstRound trait to EntryPoint. It is not bound on Round anymore.
• Added Protocol type and ENTRY_ROUND constant to EntryPoint.
• EntryPoint and FinalizeOutcome::AnotherRound now use a new BoxedRound wrapper type.
• Added an impl of ProtocolError for () for protocols that don't use errors.
• Added a dummy CorrectnessProof trait.
• RoundId now supports nesting.

Notes:

• Naming is kind of awkward. Suggestions?
• Random idea: should EntryPoint::new take &self? This way we can basically formalize the concept of protocol constructors used in synedrion.
• Should misbehave go into testing? Or gated behind the testing feature?
• Should we keep the default value of EntryPoint::ENTRY_ROUND, or make the user define it explicitly every time?
• The system with From bounds in the chain combinator is a little awkward, since we have to clone stuff for the first protocol. Some kind of a "splitting" trait might be more idiomatic, to split the full inputs into the inputs for Protocol 1 and the inputs for Protocol 2.
• Also it requires us to impl From for the type from the original protocol, which may be foreign in practice.

[coveralls]

Pull Request Test Coverage Report for Build 11823590883

Details

• 403 of 615 (65.53%) changed or added relevant lines in 11 files are covered.
• 7 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-2.5%) to 68.992%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
manul/src/session/session.rs	24	26	92.31%
manul/src/session/evidence.rs	8	16	50.0%
manul/src/protocol/object_safe.rs	38	48	79.17%
manul/src/combinators/misbehave.rs	143	156	91.67%
manul/src/protocol/errors.rs	0	22	0.0%
manul/src/protocol/round.rs	17	53	32.08%
manul/src/combinators/chain.rs	159	280	56.79%

Files with Coverage Reduction	New Missed Lines	%
manul/src/protocol/object_safe.rs	7	78.1%

Totals
Change from base Build 11602146783:	-2.5%
Covered Lines:	1731
Relevant Lines:	2509

---

💛 - Coveralls

[dvdplm]

Naming ideas:

• Init
• Start
• Gateway
• ProtocolStart
• InitRound
• Kickoff

Can you elaborate a bit on why "FirstRound" is a bad name? I kind of liked it because it's very descriptive.

[fjarri]

It was logical when FirstRound was bound on Round, but it's not anymore. Now it's more like a Round factory.

[fjarri]

This will be especially true if we make it stateful (see the note in the PR description).

[dvdplm]

"empty token type": you mean like a ZST e.g. struct ProtoC?

[fjarri]

Yep. Do you think "zero-sized type" would be more understandable here? Technically, it doesn't have to be zero-sized, it's just never instantiated by the crate.

[dvdplm]

I think "token" is the correct term to use here, but given the world we live in, I suspect readers may confuse "token" with "cryptocurrency token".
Given you have a "usually" here, it doesn't have to be technically exact, it's more of a suggestion.

How about "Usually it will be a (possibly zero-sized) marker type."? Otherwise "token type" is fine too.

[dvdplm]

• Naming is kind of awkward. Suggestions?

I'm struggling with this. I don't love EntryPoint but it's pretty clear what it is/does. Let's go with that and if either of us have a brilliant idea we'll revisit.

• Random idea: should EntryPoint::new take &self? This way we can basically formalize the concept of protocol constructors used in synedrion.

I like this!

• Should misbehave go into testing? Or gated behind the testing feature?

I like misbehave to be difficult to misuse. Today we want to use it in tests, so let's put it there until we need it. I can totally envision a scenario where the core team wants to build a malicious node to test on (private?) testnets so maybe it'd be useful to have misbehave under a feature, but let's do that when the need arises.

• The system with From bounds in the chain combinator is a little awkward, since we have to clone stuff for the first protocol. Some kind of a "splitting" trait might be more idiomatic, to split the full inputs into the inputs for Protocol 1 and the inputs for Protocol 2.

• Also it requires us to impl From for the type from the original protocol, which may be foreign in practice.

Hmm. I like the idea of a "splitting" trait, but I don't have a strong opinion on this.

[dvdplm]

This LGTM. I left a few more thoughts&nitpicks – feel free to make the changes or not and then merge.

[fjarri]

Random idea: should EntryPoint::new take &self? This way we can basically formalize the concept of protocol constructors used in synedrion.
Hmm. I like the idea of a "splitting" trait, but I don't have a strong opinion on this.

This is actually coming in #68

[fjarri]

I remember seeing your comment about tinyvec vs smallvec, and, having looked at them, I agree that tinyvec is preferable.