Best practices for implementing node communication and TSS in Polkadot

[TheGhoul21]

I'm working on implementing a threshold signature scheme (TSS) in a Polkadot-based project and have two related questions about the implementation approach:

1. What is the recommended way to implement direct node-to-node communication using the Polkadot SDK's libp2p integration? I'm specifically looking for best practices and patterns for handling peer message exchange.
2. For implementing FROST signatures, are there existing Polkadot SDK features or modules that would be appropriate to use? I'm trying to determine whether to implement this directly using the underlying cryptographic primitives or if there are higher-level SDK components I should leverage on more specifically.

I've already read the Substrate and Polkadot SDK documentation but couldn't find any real help and would appreciate guidance on the most idiomatic way to implement these features within the Polkadot ecosystem.

[burdges]

Are you wanting regular sized threshold signatures for accounts and wallets? Or larger things for concensus?

At this point FROST has become a confusingly overloaded term, and the name carries some unfortinate baggage, but..

At least for accounts, we've schnorrkel code from Olaf in https://github.com/w3f/schnorrkel/pulls but I'ven ot yet merged them, due to wanting to review them more closely. I'm happy to get another pair of eyes on them. :)

If concensus, there are a few different strateigies for larger automated DKGs, which all bring some complexities, so this becomes a messy topic. Afaik there is no perfect Olaf/Frost flavor for Ed25519, but one could be created with some care, and maybe someone already did it.

[TheGhoul21]

we did in fact already implement the basic multi signature framework with the implementation of FROST by zcash.
What we're looking for right now is how to let peers (nodes) communicate to each other. I think that we should use either of these:

• FullNetworkConfiguration.html#method.add_notification_protocol
• FullNetworkConfiguration.html#method.add_request_response_protocol

Basically meaning that we let the NetworkWorker know about protocols that are allowed to be handled.

Then I think we should use the underlying mspc channel for communication in both directions (rx and sx).

In this way we should actually be able to have access to the underlying libp2p in the correct way.

BTW: thanks for your comment. I believe I didn't address properly your question: we don't really want to have an external signature scheme, but we want it to be inside the node business logic, because it will be needed to be handled by some on-chain behaviour that will trigger some "off-chain" behaviour (not really offchain, but makes things easier to explain)

[burdges]

Accounts or consensus?

[TheGhoul21]

Accounts

[kayabaNerve]

If you want to use FROST, you presumably need to make it robust? That would require a higher-level protocol for managing attempts.

You could use ROAST, or you could use hdevalence's idea of placing signature data on a blockchain. The participants are the first t to submit, the idea naturally extended by eliminating participants who misbehave, deprioritizing participants who timeout.

For the former, you can model P2P channels using notifications AFAIK (gossipsub for anything broadcast). For the latter, a pallet.

On paper, statement_store may be useful for that role? But only somewhat. It supports encrypted statements yet probably not with the properties desirable for PedPoP, if in an adversarial environment? Yet a similar comment will likely exist for any generic encryption layer.

It's really hard to give advice on your architecture without far more context on your design goals however. This is just my scratches on the problem, with the context provided, as someone who regularly works with FROST in practice and uses libp2p/Substrate. Apologies if this was unhelpful.

[TheGhoul21]

Thank you for the helpful explanation. We're implementing TSS to enable an agent to execute transactions autonomously. Through TSS, any node on our blockchain can sign these transactions since the agent is shared across all nodes and its execution could happen on any node. Since no single node holds the complete private key we need TSS which allows any node to conduct transactions on behalf of the agent.

Regarding the enhancing of FROST's robustness, we were exploring concepts similar to ROAST, such as implementing peer exclusion with cooldown periods. After review, we've decided to adopt the ROAST framework as it perfectly aligns with our use case's requirements.

Since we prefer not storing the rounds on the blockchain (for two main reasons: 1. latency, 2. security 3. bonus: space), the gossiping was our choice. I managed to implement the GossipEngine during the weekend and it works fine.

I guess that as soon as we sign each message sent through and ensure that peers are actual peers and not bad actors, this could actually be the way to go.