refactor: remove the Addr and Hash generics in consensus

[rianhughes]

Summary

The consensus implementation currently defines Hash and Addr as generic interfaces to support flexibility across protocols. This was originally intended to allow the consensus logic to work with any hash and address types that can be represented as [4]uint.

However, in the context of the Starknet protocol, both the address and hash types are explicitly defined as felt.Felt, and this is not expected to change. As a result, the use of generics here is unnecessary and introduces avoidable complexity.

---

Motivation

• Unnecessary Boilerplate: Since Hash and Addr are used pervasively across the consensus package, requiring them to be passed explicitly as generic parameters to every struct and function results in significant boilerplate and reduces readability.

• Interface Overhead: Defining these as interfaces requires explicit type declarations, type assertions, and additional complexity that brings no real benefit in this fixed-type context.

• Improved Ergonomics: By redefining Hash and Addr as aliases (e.g., type Addr felt.Felt), we significantly reduce syntactic noise and make the code more straightforward and maintainable.

---

Change

This PR:

• Replaces the generic Hash and Addr interfaces with type aliases to felt.Felt.
• Updates the affected types and function signatures to remove unnecessary generic parameters.

This change simplifies the consensus implementation while preserving all intended functionality under the assumption of fixed felt.Felt-based types.

---

Next (this can be done in a separate PR)

Investigate whether the Hashable interface can also be removed by explicitly defining the concrete value types used in the Starknet protocol (e.g., Block, StateUpdate, etc.).

Since these types are known and fixed within the protocol, relying on an interface abstraction may be unnecessary. Replacing Hashable with concrete types could further simplify the codebase and eliminate another layer of indirection.

[codecov]

Codecov Report

Attention: Patch coverage is 98.26590% with 3 lines in your changes missing coverage. Please review.

Project coverage is 74.77%. Comparing base (65fe7e9) to head (95c64f8).

Files with missing lines	Patch %	Lines
consensus/types/action.go	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2855      +/-   ##
==========================================
- Coverage   74.83%   74.77%   -0.06%     
==========================================
  Files         206      207       +1     
  Lines       22469    22473       +4     
==========================================
- Hits        16815    16805      -10     
- Misses       4598     4607       +9     
- Partials     1056     1061       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[infrmtcs]

Why don't we use existing types in core instead? That would reduce one layer of conversion.

[rianhughes]

Yup, also happy to do that

[infrmtcs]

Why don't we use existing hash type from core instead?

[rianhughes]

Yup, also happy to do that

[infrmtcs]

I'm against this change because:

• Most of the implementation doesn't need to know the concrete type. Replacing generics by concrete types prevents the ability to write tests using other set of types. For example, if we can get a set of Tendermint tests from other implementations, there is no way to adapt to our code base except by manually rewriting using our types.
• Regarding "Interface Overhead", I don't think this reduce any overhead, because we're not using any type assertion over generic type, and the performance shouldn't be affected by type instantiation.
• The generic types help separate between the concrete implementation for Starknet and generic Tendermint logic. Inside Tendermint general package, we use generics. Outside it, we can use Starknet concrete types in consensus/starknet package.

[rianhughes]

• Most of the implementation doesn't need to know the concrete type. Replacing generics by concrete types prevents the ability to write tests using other set of types. For example, if we can get a set of Tendermint tests from other implementations, there is no way to adapt to our code base except by manually rewriting using our types.

Imo, the implementation doesn't need to work with an abstract type since it's directly tied to Starkenet. Also it's not clear to me what tests we would be taking from other implementations (that are compatible with Starknets implementation), and if we couldn't just write a simple adapter for this case (eg AdaptEthHashToFelt()). It just feels like over-engineering to me, but I may be wrong.

• The generic types help separate between the concrete implementation for Starknet and generic Tendermint logic. Inside Tendermint general package, we use generics. Outside it, we can use Starknet concrete types in consensus/starknet package.

I agree this helps separate the Starknet types and the generic Tendermint logic. I just don't think it's worth it, particularly given Starknet is using their own custom Tendermint logic, not the vanilla implementation.

It might be worth getting a third. @rodrigo-pino what are your thoughts?

[infrmtcs]

I just don't think it's worth it, particularly given Starknet is using their own custom Tendermint logic, not the vanilla implementation.

As far as I understand, the only changes in Starknet are not in the core part of the algorithm including state machine and driver, but instead in the communication part, namely proposal stream and re-broadcast.

[rianhughes]

To do: investigate if we can remove the interfaces, but keep the Tendermint-Starknet abstraction layer