SlashAcks should not be persisted as string

[shaspitz]

Problem

A "slash ack" is a string which is relayed between provider and consumer to reset the consumer's outstanding downtime flag. SlashAcks are always consumer consensus addresses, but we persist and send these slash acks as a string type. This design is error prone because:

1. It does not leverage type safety (see SlashAck sent to consumer is wrong #693)
2. There are multiple formats to convert a consensus address to string

Closing criteria

Make slash acks persisted and ser/deser as pb types, not strings

Problem details

A fix to this issue should be built on top of #725. Since slash acks can be persisted as consumer cons address pb types

[shaspitz]

Note: this will likely require a state migration so I'm going push it off for a future ICS version

[shaspitz]

@yaruwangway, now that #725 is merged, this issue is able to be solved if you're interested! Lmk if you want more options for a first issue

[ameya-deshmukh]

Hi @smarshall-spitzbart is this still available?

[shaspitz]

Hi @smarshall-spitzbart is this still available?

@ameya-deshmukh sorry for the late response! Yes this issue is still open and noone is currently working on it. Are you interested in contributing?

[MSalopek]

The issue has become state breaking in the meantime.
Any changes in those parts will require a state migration, I'm not sure how feasible this is.

[shaspitz]

A solution doesn't have to be state breaking, but it would naturally have to break the wire. Solution could be implemented in such a way that it is backwards compatible tho.

Now that ICS is in production I agree that this issue is most likely not feasible. Unfortunately it is a source of technical debt.

@yaruwangway it seems we could close this issue by simply making the API for AppendSlashAck, GetSlashAcks, SetSlashAcks type safe, and remove the TODOs. The wire can keep string types to avoid complications