You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Critical: sect_k1_base_field is not a valid binary field; it uses integer modulus (2^{163}), producing a ring with zero divisors. It also references the wrong specialization. libs/algebra/include/nil/crypto3/algebra/fields/sect/sect_k1/base_field.hpp:47
Critical: m31_base_field has an incorrect modulus and FFT metadata. It overlaps with the correct mersenne31 implementation. libs/algebra/include/nil/crypto3/algebra/fields/m31/base_field.hpp:37
High: Generic fpn extensions are incorrectly classified as prime fields because they lack the marker expected by is_extended_field. This affects random generation and marshalling dispatch. libs/algebra/include/nil/crypto3/algebra/fields/fpn.hpp:33 and libs/algebra/include/nil/crypto3/algebra/type_traits.hpp:124
Medium: There are three inconsistent field-recognition mechanisms:
Stronger C++ Field/FieldValue concepts: type_traits.hpp:168
Medium: Pubkey defines another, incompatible field trait using different required members. libs/pubkey/include/nil/crypto3/detail/type_traits.hpp:440
Medium: Identical mathematical fields are represented by incompatible C++ types:
goldilocks vs goldilocks64_base_field
m31 vs mersenne31
Medium: fp2, fp3, fp4, tower extensions, and fpn duplicate field metadata but expose different contracts. Their arithmetic implementations should remain specialized where performance requires it.
Recommendation
Yes, the concepts overlap and should be consolidated, but consolidate the type contract, not all arithmetic implementations:
Make Field and FieldValue the canonical public concepts.
Add explicit prime_field_tag and extension_field_tag, plus consistent base_field_type and extension_degree metadata.
Make fpn satisfy the same extension-field contract as specialized extensions.
Remove field_base and migrate the old structural and pubkey traits to the canonical concepts.
Alias goldilocks64_base_field to goldilocks and m31 to mersenne31.
Quarantine sect_k1_base_field until proper polynomial-basis (GF(2^m)) arithmetic exists.
Add compile-time conformance tests for every field type.
The safest incremental first change is fixing fpn classification and adding conformance tests before replacing existing traits.
Findings
Recommendation
Yes, the concepts overlap and should be consolidated, but consolidate the type contract, not all arithmetic implementations:
The safest incremental first change is fixing fpn classification and adding conformance tests before replacing existing traits.