Proposal Aliasing: Improving Governance UX with Human-Readable Metadata

Research and Development
1

Currently, protocol proposals on Tezos are identified solely by their cryptographic hash (e.g., PtTallin...). This creates a cognitive load for bakers and community members. I suggest introducing an optional Alias field (simple UTF-8 string) to the protocol proposal signature to provide immediate human readability.

The Problem

  • Bakers’ Risk: It is easy to misidentify hashes during the Proposal periods. Identical prefixes can lead to voting errors.
  • Vanity Hashing Overhead: Teams often spend significant computational resources “vanity mining” a protocol hash just to make it somewhat recognizable. This is an unnecessary barrier to entry.
  • Auditability: Reviewing historical governance data currently requires looking up external databases to find the “community name” for a past hash.

Proposed Solution: Proposal Aliasing

Instead of teams trying to hash a protocol with a vanity prefix to produce a meaningful name, we could introduce a simple Alias/Metadata string field at the protocol level.

Key Mechanics:

  1. Simple String Field: An optional UTF-8 string submitted during the propose operation.
  2. On-Chain Uniqueness: The governance protocol will enforce that only one alias of its kind can exist in the voting system at any given time.
  3. Similarity Protection (Levenshtein Distance): To prevent “impersonation” or “typo-squatting” (e.g., proposing Tallinn_v2 vs Tallinn_vZ), the protocol should enforce a minimum Levenshtein distance between active proposal aliases.
    • Logic: If a proposed alias is too mathematically similar to an existing one, the operation is rejected.

Pros & Cons

Pros

  • UX Clarity: Bakers see “TeamX_Scaling_Fix” instead of a raw hash in their logs and dashboards.
  • Resource Efficiency: Removes the need for vanity hashing, allowing teams to focus on code rather than mining a recognizable hash.
  • Error Reduction: Drastically reduces the chance of a baker voting for the wrong proposal due to visual similarity.

Cons

  • Signature Change: Requires an update to the propose function signature.
  • Gas Overhead: Implementing Levenshtein distance checks on-chain adds a small gas cost to proposal submissions.
  • State Growth: Adds a minor amount of extra data to the governance state.

Addressing Concerns: Security and Trust

It is important to acknowledge that this is not a “perfect” system. Bad actors could still inject misleading aliases to try and confuse others. However:

  • Status Quo: This is no different from the current situation. Even now, a malicious actor can inject a vanity-prefixed proposal that contains junk code. No need for hashing.

  • Bakers’ Responsibility: The ultimate gatekeepers are the Bakers. This proposal doesn’t create new vulnerabilities; it simply provides a more accessible label for the human beings making the decisions. The social layer of Tezos already filters for “official” vs “malicious” proposals; this just makes that filter easier to read.

3 Likes