S Tier: Immediate Imperative
1. Ouroboros Peras
- An overlay protocol designed to bring fast finality to Cardano’s Ouroboros consensus.
- Currently, finality on Cardano takes several minutes, which is insufficient for DeFi and UX expectations.
- Peras aims to reduce finality to just a few blocks—ideally 1 or 2—improving responsiveness.
- This benefits not only scalability but also enhances app reliability and user experience.
- It synergizes with Leios for even greater performance, making its implementation more valuable.
- Certain security features, such as grinding attack resistance, are also addressed within Peras.
- Its design allows for relatively lightweight implementation without drastically altering existing infrastructure.
- Faster finality can simplify processes for wallets, exchanges, and apps that rely on deterministic confirmations.
- Competing L1s like Solana, Near, and Avalanche already emphasize fast finality, making this crucial for competitiveness.
- Overall, it is considered a high-priority, “do-now” protocol improvement essential for Cardano’s evolution.
2. Mithril Enhancements
- A multi-signature protocol allowing lightweight clients and L2s to verify blockchain states without running full nodes.
- Enables partial validation of block history, ideal for low-resource devices and web clients.
- The initial implementation is live, but further enhancements are expected.
- Potential to become the cryptographic foundation for tools like Midgard or Hydra and other L2s.
- Applications include cross-chain communication, restaking, and proof aggregation for services.
- Considered a practical alternative to ZK proofs in Cardano’s architecture for lightweight trust.
- Comparable to Ethereum’s “light client + sync committee” functionality, but tailored for UTXO.
- Once mature, it can significantly lower the barrier to entry for new dApps and third-party integrations.
- It bridges core infrastructure and emerging platforms, accelerating L2 innovation.
- Deemed a top strategic enabler, with immediate practical utility and long-term foundational value.
3. Alternative Nodes
- The development of Cardano node implementations in languages other than Haskell (e.g., Rust, Scala, TypeScript, C++).
- Just like Ethereum has multiple nodes (e.g., Geth, Nethermind), Cardano benefits from having diverse, purpose-built nodes.
- The current Haskell implementation creates bottlenecks in terms of maintenance, debugging, and evolution.
- Projects like StarStream and Midgard can evolve more rapidly with their own custom nodes.
- Having multiple implementations encourages specification clarity and protocol robustness.
- Teams like Amaru and TxPipe are already building full-feature alternative nodes.
- These initiatives promote structural soundness and developer productivity across the ecosystem.
- They also future-proof Cardano by preparing it for consensus upgrades and VM diversity.
- While resource-intensive, it’s seen as one of the most strategic infrastructure investments.
- Overall, alternative nodes are vital to decentralization, scalability, and innovation resilience.
A Tier: Top Priority
4. Hydra Development
- Hydra is Cardano’s layer 2 scalability solution, developed through years of R&D.
- It has now entered the productization phase, with live demonstrations such as “Doom on Hydra” proving viability.
- It is ideal for use cases requiring rapid finality and microtransactions, such as multiplayer games and DEXs.
- As the only fully functional L2 currently available on Cardano, driving adoption is an urgent priority.
- Many proposals lack KPIs or clear deliverables, so future work should focus on goal-oriented development.
- Extensions like Hydra Tail and Inter-Head have been proposed, but base-level stability must come first.
- Broader Hydra adoption could set a precedent for other L2s in the Cardano ecosystem.
- Still, Hydra’s complexity and low visibility among developers require better outreach and support.
- The current roadmap includes fragmented proposals, highlighting the need for unified direction and prioritization.
- Technically mature, the main question now is how and by whom it will be used and deployed.
5. Optimization Tools (Hydra-related)
- Refers to auxiliary infrastructure to improve Hydra usability, such as collateral locking, channel orchestration, etc.
- These are ideally part of core Hydra development, but were submitted as separate proposals.
- Smooth operation of Hydra requires these tools to be in place, especially for managing complexity.
- Simplifying channel setup, participant management, and fund locking can vastly improve developer experience.
- Lack of observability in the current implementation presents a barrier to wider adoption.
- These tools serve as critical enablers that make Hydra viable for real-world product deployment.
- Use cases like games or DEXs demand robust monitoring, visibility, and tooling to ensure confidence.
- Includes features like explorer integration, security audit support, or transparency dashboards.
- This proposal focuses on “developer support tooling” rather than protocol-level enhancements.
- Considered essential and tightly coupled with Hydra development, warranting a solid A-tier placement.
6. Ouroboros Leios
- A complete redesign of the Ouroboros consensus mechanism aimed at significantly increasing throughput (TPS).
- Leios leverages parallelism and node performance, promising very high scalability potential.
- In worst-case scenarios, it degrades safely to current consensus behavior, maintaining fault tolerance.
- Its architecture is conceptually similar to Ethereum’s PBS (Proposer-Builder Separation).
- However, Leios may require substantial changes to Cardano’s base infrastructure, making it disruptive.
- Many roadmap proposals depend on Leios (e.g., fair transaction processing), making it foundational.
- Implementation is expected to take time, so parallel development is advised.
- While it doesn’t enhance finality directly, it vastly improves transaction handling under load.
- TPS targets exceed 1,000+, but that depends on trade-offs around decentralization and hardware costs.
- Overall, seen as a future-critical upgrade that must be prepared for, even if deployment is years out.
7. Decentralized Identity and Reputation Management
- DID (Decentralized Identity) is vital for on-chain authentication, trust, and governance-related use cases.
- Enables features like quadratic voting, Sybil-resistance, and verified participation.
- ZK integration allows privacy-preserving proofs (e.g., “I am from Europe” without revealing a country).
- Initiatives like Atala PRISM (by IOG) have laid the groundwork, but it’s time to move toward implementation.
- Often classified as an application-layer concern, but L1-native identity tools are increasingly seen as critical.
- Proper identity layers enable KYC, DAO participation, L2 onboarding, and role-based permissions.
- Combining identity with reputation allows on-chain trust models based on historical behavior.
- Can be extended to governance filtering, reward distribution, or even social slashing mechanisms.
- With many ZK startups entering the space, Cardano risks falling behind without action.
- Overall, this is a key foundational layer for unlocking future decentralized applications.
8. Proof of Restake
- A staking-based extension similar to Ethereum’s Eigenlayer, enabling reuse of ADA stake across multiple networks.
- Allows users to delegate stake not just to Cardano, but to additional services, protocols, or L2s.
- Restaking underpins the economic security of overlay networks like Mythril or Midgard.
- Enables “active slashing” for bad actors, opening up new decentralized service models.
- While Cardano lacks restaking use cases today, Eigenlayer’s growth suggests strong latent demand.
- When combined with UTXO’s flexibility, Cardano could offer safer, more modular staking than competitors.
- Seen as a cornerstone for interoperability and multi-layer architecture.
- Though still in early conceptual stages, it aligns directly with key trends: L2 enablement and protocol revenue.
- Integration with Mithril would greatly strengthen both proposals and ecosystem trust frameworks.
- Considered high-potential for the next phase of Cardano’s evolution, especially for unlocking revenue models.
–
B Tier: Important Initiatives
9. State-Machine Contract Environment
- A proposal to enhance support for state-machine-style smart contracts on Cardano.
- Currently, Plutus requires manual state tracking for multi-step contracts, increasing complexity.
- Abstracting state transitions could simplify logic for dApp developers and enable more advanced applications.
- Closely tied to Hydra and StarStream; the latter explores coroutine-based models to ease this burden.
- State machines are foundational in many use cases such as auctions, DEXs, and identity flows.
- Previous attempts lacked native language support, leading to inefficiencies and fragile designs.
- This proposal could involve new VMs or intermediate representations, suggesting structural changes.
- While the idea is highly useful, its execution is currently vague—no clear direction on implementation method.
- Several teams are independently working on similar goals, increasing the need for coordination.
- Overall, it’s a valuable concept, but it must be better scoped and unified before it earns a higher priority.
10. Location-Based Services and Smart Contracts
- Supports contracts that respond to users’ or nodes’ geographic locations.
- Example use cases: incentivizing node deployment in underserved areas, or verifying physical event attendance.
- This overlaps with the broader category of real-world assets (RWAs) and physical verifiability.
- Technically, it’s very difficult to trust location data (e.g., GPS spoofing) in a decentralized way.
- It’s also relevant for legal/regulatory compliance (e.g., data sovereignty or geo-fencing).
- Could power entertainment, access control, or proof-of-presence systems if implemented correctly.
- There’s still debate on whether this belongs in protocol-level changes or application-layer frameworks.
- While ideas are abundant, concrete and practical implementations are lacking at this stage.
- Potential integration with StarStream or Midnight was briefly mentioned.
- Overall, it’s broadly interesting and could unlock use cases, but lacks specificity, which keeps it in B Tier.
11. Tokenomics Design
- Refers to revisiting the foundational economic parameters of Cardano (rewards, inflation, fee structure).
- The relevance of this proposal depends heavily on its scope—adjusting pool parameters is low priority; rethinking the full economic model is high priority.
- If it includes innovations like Babble Fees (multi-asset fee payments) or external revenue streams, its importance rises.
- Competing chains (Ethereum, Solana, Avalanche) have monetized specific features successfully, e.g., DeFi, NFTs, meme coins.
- Cardano’s current incentive model is designed to shrink rewards over time, potentially unsustainable without offsetting fee revenue.
- Thus, forward-looking, innovative redesigns of the reward system are increasingly necessary.
- Discussions like A0 and K parameter changes have stalled in CIP governance due to lack of consensus.
- Treasury usage and governance-linked budgeting are intertwined with this topic.
- There’s clear value in resourcing this work, but without clarity on the target model, it cannot be rated higher.
- Important and strategic, but not yet structured enough to merit A Tier.
12. Rewards Sharing and Transaction Fees
- Focuses on restructuring transaction fees, staking rewards, and pool revenue allocation.
- While overlapping with Tokenomics Design, this item hones in on concrete operational concerns.
- Rewards are currently declining due to protocol halving and flat transaction volume.
- A balance between sustainable rewards and controlled inflation is critical for long-term viability.
- Fee management is also crucial to L2 systems and Babble Fee adoption.
- Bringing in new users requires fast, low-cost, and meaningful transaction experiences, underpinned by clear incentives.
- Governance will need to weigh in, and DReps will play a key role in adjusting parameters dynamically.
- This topic becomes even more important if alternative fee currencies are introduced.
- Ultimately, this is about how to implement policy, not define use cases—but policy is urgent.
- It’s a necessary medium-term challenge with real ecosystem implications, landing it solidly in B Tier.
13. RSnarks (Recursive SNARKs)
- This refers to cryptographic techniques that allow combining multiple ZK proofs into one recursive proof.
- Already being pursued by the Midnight project and other ZK systems within the ecosystem.
- RSnarks are also found in broader ZK tech families like Nova and Halo 2, which StarStream intends to use.
- Their relevance lies in enabling efficient proof aggregation and nested logic in ZK systems.
- While conceptually strong, many chains already use or develop RSnarks, so Cardano’s leadership here is less critical.
- The role of RSnarks in Cardano is mostly foundational for future ZK features, not directly a user feature.
- Since Midnight is already implementing RSnarks, the main chain may only need integration support.
- The challenge is not research anymore—it’s how to integrate RSnarks into usable tooling and infrastructure.
- Given the coordination and alignment required with other teams, progress depends on unified standards.
- Valuable but not urgent, this lands comfortably in the B Tier.
C Tier: Secondary Considerations
14. Inter-Head (Hydra Extension)
- A proposal to connect multiple Hydra heads together, forming a network of interconnected channels.
- The current Hydra design supports isolated “heads” (off-chain micro-ledgers) between parties.
- Inter-Head aims to evolve this into a networked model, somewhat like the Lightning Network.
- It would enable routing transactions or state across multiple heads, extending Hydra’s functionality.
- However, this concept is still in early research; no concrete design or implementation exists.
- Because Hydra adoption is still nascent, adding architectural complexity may be premature.
- Still, it’s seen as an important next-gen capability if Hydra proves successful in production.
- Inter-Head could significantly extend Hydra’s utility for large-scale applications and dApps.
- For now, the community consensus is to stabilize and productize Hydra first before adding features like this.
- It’s recognized as a long-term need, but not one to allocate significant funding toward immediately.
15. Congestion Control
- This research item addresses how to manage transaction load and prioritization during peak network usage.
- “Feeless” chains often fail under spam or congestion, showing why robust congestion control is critical.
- Cardano currently uses a basic fee market, but future upgrades will require more sophisticated mechanisms.
- The idea of spam-resistant but fair congestion management is appealing but technically complex.
- It’s also related to Fair Transaction Processing and Layer 2 traffic routing problems.
- As L2 adoption increases (Hydra, Midgard), the base layer must handle mixed transaction traffic gracefully.
- This proposal doesn’t offer concrete solutions—mostly general statements about congestion handling.
- Therefore, it’s considered research-worthy but not ready for deployment or near-term focus.
- If Leios and Peras are implemented, they could address many congestion problems structurally.
- In that context, this may be reevaluated upward, but for now, it remains a support-level study.
16. Anti-Grinding
- This proposal addresses resistance to grinding attacks in Ouroboros—where validators might simulate many possible outcomes to their advantage.
- While Ouroboros already offers some protection, improvements could make the chain more robust.
- The attack is subtle: it involves selecting favorable outcomes based on pseudo-random leader schedules.
- The proposal suggests studying lightweight defenses that don’t compromise liveness or decentralization.
- Many of these concerns may be partially mitigated by implementing Peras or Leios.
- Thus, any standalone effort on anti-grinding might be redundant if Peras solves it by design.
- Some participants advocated for integrating anti-grinding work directly into Peras design, rather than funding it separately.
- It’s a reasonable security concern but lacks immediate urgency compared to scalability or UX issues.
- Could be useful in high-security use cases, but not a general ecosystem blocker at present.
- Overall, it was considered too niche for direct roadmap inclusion, and better addressed as part of ongoing upgrades.
17. Log-Structured Merge (LSM) Trees
- LSM trees are a type of database structure that improve write performance and reduce memory overhead.
- This proposal aims to replace or augment Cardano’s current UTXO storage with LSM-like data handling.
- LSMs are widely used in systems like RocksDB, giving them proven efficiency for append-heavy workloads.
- Some work has already been done in the Haskell node, but progress is slow and complex.
- Switching to a commercial-grade LSM DB could improve syncing, transaction performance, and memory usage.
- However, such a change may cause compatibility issues with existing code, requiring deep refactoring.
- The proposal is not protocol-level and doesn’t change consensus or economic incentives.
- Rather, it improves node performance and reliability, especially under load.
- It’s seen as an overdue infrastructure improvement but lacks the urgency of other roadmap items.
- Given its practical value but low immediate impact on the broader ecosystem, it sits appropriately in C Tier.
D Tier: Low Impact
18. Auditing Tools (Hydra-related)
- A proposal to develop tools for auditing and analyzing Hydra head activity.
- The goal is to make Hydra’s internal operations more visible to developers and users.
- Currently, Hydra’s state transitions happen off-chain, making them difficult to monitor or trace.
- These tools could include explorers, logs, and dashboards that help inspect channel activity and fund flows.
- While transparency is useful, the lack of visibility is partly by design—it’s an off-chain scaling solution.
- General-purpose auditing tools may be hard to build due to use-case specificity (DEXs, games, etc.).
- The proposal lacks clarity about its scope: is it developer tooling or core infrastructure?
- Some contributors argued that too much visibility could reduce privacy benefits or add attack vectors.
- Others felt this was more of a catalyst-style proposal or dApp-layer tooling than a roadmap item.
- It’s potentially valuable but not aligned with immediate priorities—thus, categorized as D Tier.
19. Fair Transaction Processing
- Aims to provide equitable transaction processing during network congestion.
- The default model is a simple fee market—higher fees get priority, which favors wealthy actors.
- This leads to inequality and makes real-time applications like lending or liquidation vulnerable.
- Layer 2s may submit large batch transactions, further distorting transaction queue dynamics.
- Alternatives like tiered queues or user groups are discussed, but implementation is not defined.
- Leios would enable some of these designs, but only if paired with protocol-level coordination.
- There’s community disagreement about whether “fairness” should override economic incentives.
- Ultimately, the proposal is more exploratory than actionable—missing governance consensus.
- It may gain relevance post-Leios, but is not ready for implementation today.
- Placed in D Tier due to a lack of clear technical direction and unresolved philosophical concerns.
20. Nested Transactions
- Suggests allowing transactions to include other transactions as internal units, executed atomically.
- This aims to simplify dApp design by bundling complex multi-step actions into one envelope.
- Other UTXO blockchains like Fuel have experimented with similar models.
- However, critics argue this adds unnecessary complexity and deviates from Cardano’s UTXO philosophy.
- Current Plutus and infrastructure tools can already simulate nested flows using intent-based scripting.
- StarStream addresses similar goals with coroutine-like contract flows inside a new VM, offering a cleaner solution.
- Implementing nested transactions would also require major changes to wallets, explorers, and tooling.
- The idea is valid in principle, but better implemented at the VM or scripting level rather than protocol.
- Most of the benefits are already achievable with existing tools and frameworks.
- Considered over-engineered for the intended value—thus placed in D Tier.
21. ZK Fold Symbolic (Haskell-based ZK DSL)
- A proposal to develop a Haskell-based domain-specific language (DSL) for writing zero-knowledge contracts.
- Aims to provide strongly typed, symbolic tools for building ZK logic on Cardano.
- However, Haskell’s complexity has already hindered developer adoption in Plutus.
- Many developers prefer simpler languages like Aiken or Helios, which are gaining traction.
- The learning curve and low accessibility make this DSL unlikely to be widely adopted.
- It also risks repeating the mistakes of past projects like Plutus Core/QTS-CX.
- ZK tech is already being advanced via Midnight and StarStream, both using more approachable stacks.
- Some contributors suggested pivoting toward a ZK compiler or annotation system for Aiken instead.
- As it stands, the tool is niche, technically sound, but not aligned with ecosystem needs.
- Without a language shift or clearer adoption path, it remains low-impact and D Tier.
22. Multi-Resource Consensus – Minotaur
- Describes a hybrid consensus model combining multiple proof systems, like PoS + PoW.
- A research paper on this exists, mostly targeting partner chains or L2s, not Cardano mainnet.
- The goal is to allow chains to benefit from Cardano’s security while customizing their own consensus rules.
- While academically novel, hybrid models tend to be complex and harder to secure or reason about.
- Major L1s (like Ethereum) are moving away from PoW; hybrid systems face limited demand.
- Even if adopted, such consensus would likely be implemented on sidechains or sovereign rollups.
- Cardano’s treasury is not the appropriate funding source for this, as it has little mainnet relevance.
- Some utility may exist for specific partners, but should be pursued independently.
- It’s cool in theory, but practically off-topic for the current roadmap.
- Thus, it’s categorized in D Tier due to minimal ecosystem applicability.
F Tier: Not Recommended
23. Hydra Tail
- A proposed Hydra extension designed to allow many individual accounts to connect to a Hydra head.
- Traditional Hydra use focuses on peer-to-peer or small group real-time micro-ledger channels.
- “Tail” introduces the idea of many clients connecting to a head in a trustless, scalable manner—more like client-server.
- However, enabling this in a decentralized, trustless way likely requires advanced zero-knowledge (ZK) cryptography.
- The Cardano ecosystem does not yet have mature ZK infrastructure (provers, verifiers, languages) to support this.
- Earlier prototype simulations showed that the approach may not perform as expected in practice.
- Some developers now see StarStream and ZK-VMs as more realistic paths to achieving Hydra Tail functionality in the future.
- At present, the technical base is not ready, and any implementation would likely be inefficient or insecure.
- Despite its conceptual appeal, trying to build this today would be premature and wasteful.
- It’s not rejected forever—this could be re-evaluated once ZK tech on Cardano matures (possibly in 2–3 years).
24. Proofs of Useful Work
- An academic idea to replace “wasted” mining energy with computationally useful tasks (e.g., protein folding, AI model training).
- Attempts to give utility to proof-of-work (PoW) consensus by making it socially beneficial.
- Theoretically elegant, but practically very difficult to implement securely and fairly.
- Requires methods to verify arbitrary computations while preserving decentralization and non-repudiation.
- Also suffers from incentive misalignment and lack of general-purpose applicability.
- Several prior attempts on other blockchains (e.g., Gridcoin, CureCoin) failed to gain traction.
- Cardano is a PoS-based blockchain, making this concept fundamentally out of scope.
- It does not align with Cardano’s architecture or treasury priorities, and no active project is building with this.
- While it might be interesting in future academic circles, it does not belong on the Cardano roadmap.
- Thus, it’s considered completely off-topic for now and placed firmly in F Tier.
25. Governance Incentives
- A proposal to introduce direct financial incentives for DReps (Delegated Representatives) or voting participants.
- Currently, under Voltaire, there is no reward mechanism for DReps or voters in governance actions.
- The idea aims to encourage broader governance participation by aligning it with economic rewards.
- However, the Cardano community is split on whether this is even desirable.
- Critics argue that paying DReps could lead to professionalization, bribery, or vote-buying.
- There’s also no consensus yet on the best incentive structure—flat rate? performance-based? delegation-weighted?
- Technically, incentives could be implemented via smart contracts without modifying the core protocol.
- But without clear social agreement, introducing them now could harm governance legitimacy.
- Governance itself is still evolving and stabilizing; incentives may only make sense once maturity is achieved.
- Therefore, this proposal was deemed premature and placed in F Tier until broader consensus is reached.
26. Light Client Infrastructure
- Focuses on enabling lightweight nodes or clients that can interact with Cardano without storing the full blockchain.
- Intended to allow devices like mobile phones or external blockchains to verify Cardano transactions.
- The evaluation depends heavily on the exact interpretation of “light client.”
- If it refers to cross-chain integration (e.g., BTC-ADA bridges), it’s highly important.
- But if it only aims to improve wallet syncing or user experience, current solutions like Mithril already address this.
- Mithril provides cryptographic proof-of-state mechanisms that serve most light client needs.
- Additionally, projects like Midnight or StarStream may implement more robust cross-chain tools separately.
- The term “light client” was seen as ambiguous, and the proposal lacked specific implementation direction.
- Most contributors suggested rolling this into Mithril enhancements or catalyst-level tooling proposals.
- Without clarity, the item was downgraded and categorized as F Tier.
27. Consensus Innovation
- A vague catch-all category suggesting generic improvements or alternatives to the Ouroboros consensus.
- May include things like BFT upgrades, hybrid consensus models, or entirely new algorithms.
- No specific research direction or concrete roadmap is provided in the proposal.
- Several meaningful consensus upgrades (Leios, Peras) are already underway and prioritized.
- Abstract research without clear application risks wasting resources and diluting strategic focus.
- New consensus protocols, if valuable, should be submitted as separate, well-scoped proposals.
- Cardano’s roadmap is already crowded with actionable technical upgrades, making abstract “innovation” proposals impractical.
- Contributors agreed that exploratory research should be left to academia or small grants, not core roadmap funds.
- “Interesting but directionless” was the recurring sentiment.
- For lack of specificity and practical feasibility, it was rated F Tier.
28. fastBFT
- A proposal to improve the speed of Byzantine Fault Tolerance (BFT) consensus for partner chains or sidechains.
- Could benefit projects like Midnight, which aim to use BFT in closed or semi-trusted environments.
- However, fastBFT is not targeted at Cardano’s L1, and has little to no relevance to its current consensus needs.
- Projects needing this tech (e.g., Quantstamp, Midnight) should fund and develop it independently.
- Using Cardano treasury funds for BFT optimization offshoots was seen as inappropriate.
- It’s useful in limited cases but has no ecosystem-wide impact or roadmap urgency.
- Similar proposals have surfaced before but failed to demonstrate concrete outcomes.
- Even if developed, it would take years to impact L1 usage.
- Good in theory, but completely orthogonal to Cardano’s core direction.
- As such, it’s clearly placed in F Tier.
? Tier: Insufficient Information
29. Timeliness Market
- This proposal was too vague for the panel to understand and evaluate effectively.
- The term “timeliness market” suggests some form of transaction prioritization based on urgency or latency sensitivity.
- It may have intended to introduce an auction-like model where time-sensitive transactions pay a premium for inclusion.
- However, this overlaps heavily with other proposals like Fair Transaction Processing and Congestion Control.
- The brief description mentioned ensuring that “a transaction is inserted into a block even under load,” which is already part of Cardano’s consensus guarantees.
- From a technical standpoint, Peras and Leios are expected to address most real-time transaction needs once implemented.
- No architecture, use cases, or protocol changes were outlined—leaving it entirely speculative.
- It’s unclear whether this proposal targeted the mempool, the fee market, block propagation, or L2 behavior.
- Because of the overlap with other better-defined proposals, and the lack of technical depth, it couldn’t be meaningfully assessed.
- Therefore, it was placed in the “?” category—not necessarily bad, but lacking enough context to warrant a tier.
ーーー
S Tier（Immediate Imperative：即時の優先課題）
1. Ouroboros Peras
- Cardanoのコンセンサスに高速ファイナリティ（確定性）をもたらすオーバーレイプロトコル。
- 現在の確定時間は数分を要し、DeFiやUXには不十分である。
- Perasを導入することで、数ブロック、理想的には1〜2ブロックでの確定を目指す。
- スケーラビリティだけでなく、UX改善・アプリ信頼性向上にも直結する。
- Leiosと連動して使うことでさらに効果を発揮するため、重要性が高い。
- 一部、セキュリティ面（グラインディング攻撃耐性）もPeras内で解決可能。
- 実装負荷は比較的軽く、既存インフラを大きく壊さず導入できるのも利点。
- ファイナリティ強化により、ウォレットや取引所などのフローも簡素化できる。
- 他L1チェーン（例：Solana, Near, Avalanche）では高速ファイナリティが必須となっており競争上重要。
- 優先順位の高い、即着手すべきプロトコル改善とされた。
2. Mithril Enhancements
- 軽量クライアントやレイヤー2への証明分散を可能にするマルチ署名プロトコル。
- Mithrilにより、ノード全体を持たずともブロック検証ができるようになる。
- 特に低リソースデバイスやWebクライアントにとっては革新的。
- 既に初期版は稼働しているが、さらなる改良が期待される。
- 将来的にはMidgardやHydraと連動する証明基盤にもなりうる。
- クロスチェーン通信・レストーキング・ステーキング合成証明などの応用も期待。
- CardanoにおけるZK以外の実用的な「軽量信頼証明手段」として位置づけられている。
- Ethereumでいう「light client＋sync committee」相当の機能を簡潔に実現可能。
- これが成熟すれば、新興レイヤー2や外部パートナーへの橋渡しが劇的に進展。
- 現実的かつ即効性の高い「進化の加速装置」として最優先とされた。
3. Alternative Nodes（代替ノード実装）
- 公式のHaskellベースノード以外に、Rust, Scala, TypeScript, C++などでの実装を推進。
- Ethereumのように用途別（開発用、L2用、データ提供用）ノードを持つことで多様性確保。
- 現在のCardanoノードは1実装依存で、保守・バグ対応・進化のボトルネックになっている。
- 特にStarStreamやMidgardといった新しい技術は独自ノードで迅速に展開可能。
- 複数実装があれば仕様の明確化が促進され、インフラ全体の堅牢性が向上。
- 実際にAmaruやTxPipeなど複数の実装チームが進行中。
- 仕様議論や開発効率を高めるための「構造的健全性」の柱。
- Cardanoエコシステムの分散性・再構築可能性を保証する要。
- コンセンサス変更やVM追加などの未来施策の「準備」としても重要。
- 時間・労力はかかるが、エコシステムにおける最も構造的な投資とみなされた。
A Tier（Top Priority：優先的に取り組むべき課題）
4. Hydra Development
- HydraはCardanoのスケーラビリティを実現するL2プロトコルで、数年にわたるR&Dが行われてきた。
- 現在は「プロダクト化フェーズ」に入りつつあり、既にゲーム等での実証事例（Hydra Doom）も存在。
- マルチパーティによる即時決済やゲーム・DEXでの高速取引に適しており、使用拡大のタイミングを迎えている。
- 現時点で動作可能な唯一のL2であることから、採用促進は喫緊の課題。
- KPIや成果物が不明瞭な提案が多く、研究よりも「実装目標付き開発」の形で提案されるべきとされた。
- Hydra TailやInterheadなど拡張も提案されているが、ベース技術の安定化が先決。
- Hydraの普及はCardanoの「L2先行事例」として他プロジェクトにも影響を与える。
- 一方で仕様の複雑さ、認知度の低さも課題とされ、啓蒙と支援が必要。
- 現在のロードマップでは複数に分割されて提案されており、重複整理も求められる。
- 技術的完成度は高く、あとは「誰がどう使うか」の段階である。
5. Optimization Tools（Hydra関連ツール群）
- Hydraの最適化ツール、特にCollateral Lockやチャネル管理などの運用補助ツールを指す。
- 本来、Hydra開発に内包すべき内容だが、別提案として登場していたため議論に。
- Hydraのスムーズな運用・導入には必須なインフラであると見なされている。
- チャネル構成、参加ノードの認証、資金のロック管理などを簡素化することで開発者体験が向上。
- 現在の仕様では「何が起きているか」を確認する手段が乏しく、利用障壁となっている。
- このような補完的ツールにより、Hydraの採用が実際のプロダクトに結びつきやすくなる。
- 特にDEXやゲームでの応用において、「見える化」と「トレーサビリティ」は重要。
- セキュリティ監査やログ可視化などもこのカテゴリに含まれる。
- Hydraを本格的に使う開発者のための「開発者支援」策と捉えられている。
- Hydraとセットで最優先で進めるべきという意見から、Aランクに分類。
6. Ouroboros Leios
- Ouroborosコンセンサスの抜本的改良によるスループット向上（TPS増加）を目指す。
- ノードのハードウェア能力を最大限に活かせる構造となっており、スケーリングポテンシャルは非常に高い。
- 最悪時には現行と同等の耐性を保つ設計となっており、安全性も維持される。
- 概念としてはEthereumのPBS（Proposer-Builder Separation）に近い構造を持つ。
- ただし導入の際は既存エコシステムに大きな変更を与える可能性があり、慎重な導入が必要。
- Leiosに依存する提案（例：Fair Transaction Processingや優先Tx）は多く、基盤要素としての価値が高い。
- 実装は長期化が見込まれるため、今から並行して準備するのが妥当とされた。
- ファイナリティには寄与しないが、高頻度トランザクションに対するレジリエンスが大幅に向上する。
- TPS理論値では1,000以上を想定可能だが、ハードウェア依存性・非中央集権性とのバランスが課題。
- 全体として、「時間はかかるが必ず必要になるアップグレード」として評価された。
7. Decentralized Identity and Reputation Management
- DID（分散型ID）は個人認証や信頼性評価の基盤技術として、多くのユースケースで求められている。
- Quadratic Voting（平方根投票）やガバナンスにおける本人性証明でも前提となる技術。
- ZK（ゼロ知識証明）との連携により、プライバシーを保ったままの証明も可能。
- IOGによるAtala PRISMなど、既存研究が豊富にあり、製品化フェーズに移行すべきタイミング。
- 本来はアプリケーション層に分類されがちだが、L1への統合的アプローチが望まれている。
- ID層が整備されれば、KYC・DAO参加・L2への入退出などに活用可能。
- Reputation機能と併せることで、「履歴に基づく信頼構築」がブロックチェーン上で実現可能となる。
- ガバナンスやフィルタリング、報酬分配などにも応用可能で、幅広い影響が見込まれる。
- 既に複数のZKスタートアップが参入しており、他チェーンに遅れを取る前に対応が必要。
- 全体として、「新たなユースケースを創出する土台」としてA評価に。
8. Proof of Restake
- EthereumのEigenlayerに類似する「再ステーキング」技術の提案。
- 同じADAステークから、複数のネットワーク（例：L2, サービスネットワーク）に担保を提供可能に。
- MythrilやMidgardのようなオーバーレイネットワークにおける「経済的安全性」を支える。
- 一部スラッシュ（罰則）も許容することで、信頼性の高い外部サービスを構築可能。
- 現状、活用事例は少ないが、Eigenlayerの時価総額や関心からも需要は高いと予想される。
- CardanoならではのUTXO構造と組み合わせれば、より柔軟かつ安全な設計も可能。
- 相互運用や複数チェーンへの接続を支える基盤技術として期待されている。
- 提案段階では構想中心だが、「レイヤー2活性化」「インセンティブ強化」の両方に直結する。
- Mythril強化とセットで導入すれば、経済的・技術的に大きな推進力になる。
- 将来的なL2競争やインフラ多様化の基礎として、高評価された。
B Tier（Important Initiatives：重要な取り組み）
9. State-Machine Contract Environment
- Cardano上でのステートマシン（状態遷移型）のスマートコントラクト支援を強化する提案。
- 現状のPlutusでは状態遷移を実装する際に手作業で状態管理を行う必要があり、負担が大きい。
- 状態管理を抽象化することで、開発者の負担を軽減し、複雑なユースケース実装が可能になる。
- HydraやStarStreamとも関連があり、特に後者ではコルーチンベースでこれを簡素化する方向で開発中。
- ステートマシンはDEX、オークション、マルチステップ認証など多くのアプリケーションで中核となる。
- 過去にも試みはあったが、Plutusのネイティブサポートがないため非効率だった。
- 提案では新たなVMや中間言語での支援も視野に入れており、構造的な変化を含む。
- 汎用性は高いが、現時点で「どの方式で進めるか」が明確でないことがBランクの理由。
- 他チームが並行して同様の方向を模索しており、協調開発の必要性も浮上している。
- 技術的には興味深いが、全体像と方向性を整理してから進めるべきとされた。
10. Location-based Services and Smart Contracts
- 位置情報に基づいたスマートコントラクトや報酬分配の実装を支援する提案。
- 例として「特定の場所にノードを設置すれば報酬が増える」「イベント出席を証明する」などのユースケースが想定されている。
- これはReal World Asset（RWA）カテゴリの一部とも重なり、物理的な証明との融合が求められる分野。
- 技術的には位置情報の信頼性担保（GPSの偽装防止など）が大きな課題。
- また、政府規制（データ処理が国別要件を持つ場合）への対応にも関係してくる。
- エンタメ、証明、参加実績トラッキングなど、多様な実用が期待されるが標準化はされていない。
- プロトコルレベルでサポートすべきか、アプリレイヤーで吸収すべきかの議論もあり。
- 多くのアイデアはあるが、実現可能性の高いユースケースがまだ絞り切れていない。
- 一部ではStarStreamやMidnightでの活用可能性も議論された。
- 汎用的価値はあるが、先行研究や他ブロックチェーンとの差別化が必要とされている。
11. Tokenomics Design
- ステーキング報酬やインフレ率、トランザクション手数料分配といった「経済設計」の再構築を目指す。
- 提案内容によって評価が分かれる項目で、単なる報酬配分の調整であれば優先度は低い。
- 一方、Babble Fees（任意通貨支払い）や外部資金流入モデルの設計を含めるなら非常に重要。
- 他のチェーン（Ethereum、Solana等）が新たなユースケースで収益化に成功している中、Cardanoも収益化戦略が問われている。
- 報酬が半減し続けるインセンティブ設計では、長期運用の持続可能性に限界がある。
- そのため、より持続可能かつ革新的な報酬設計・エコシステム設計が求められている。
- A0, K（プール報酬パラメータ）に関するCIP提案もあるが、未だ合意形成には至っていない。
- Treasuryの活用方針も絡むため、ガバナンス面からの議論と連携が必要。
- リソースを費やす価値はあるが、「何を目指すか」によって評価が大きく変わる。
- 現段階では重要性は高いが、方向性が見えにくいためBランクに据え置かれた。
12. Rewards Sharing and Transaction Fees
- トランザクション手数料の分配構造、報酬の再設計、ステークプールの利益配分等に関わる。
- 多くはTokenomics Designとオーバーラップしているが、より具体的な課題にフォーカスしている。
- 現在、トランザクション数が伸び悩んでいる中、報酬水準が下がり続けている。
- 報酬の安定化とインフレとのバランス、参加者インセンティブの調整が不可欠。
- また、「手数料をどう徴収し、どう分配するか」は、L2やBabble Fee導入とも関係が深い。
- 新規ユーザーを獲得するには「安くて速くて意味のある取引」が必要で、それを裏付ける制度設計が求められている。
- ガバナンスを通じた調整やパラメータ変更も想定され、DRepとの連携が鍵となる。
- 特に今後のBabble Feeや外部通貨との統合が実現する場合、この部分がクリティカルになる。
- あくまで「実現手段」の議論であり、ユースケースそのものではない。
- 実装と制度調整の両面が必要な中期的課題としてBランクに配置。
13. RSnarks（Recursive SNARKs）
- 複数のゼロ知識証明を1つにまとめて検証可能にする「再帰的SNARK」の研究・実装。
- Midnightでの実装が進んでおり、Cardano全体に波及する可能性がある。
- 他のZKファミリー（Nova, Halo 2等）とも連携が可能で、ZKVM設計との接続が重要。
- 特にStarStreamではNova系技術を採用し、軽量かつ効率的なZK対応を目指している。
- ただし、Recursive SNARK自体は既に多くのプロジェクトで実用化が進んでおり、Cardanoが主導する必要性は相対的に低い。
- あくまでZKをL1上で動かす際の「前提技術の1つ」という位置づけ。
- Midnightである程度のパイロットが進んでいるため、Cardano本体ではフォロー的支援が望ましい。
- 研究というよりも「製品設計にどう組み込むか」にシフトすべき段階とされた。
- 他のZK技術とのバランスを見ながら活用すれば有効な基盤技術となる。
- 高度な理論背景とコラボレーションが必要なことから、Bランクで妥当との判断。
C Tier（Secondary Considerations：副次的だが検討価値あり）
14. Inter-Head (Hydra拡張)
- Hydraにおける“head間接続”を可能にする提案で、現行の独立headの制限を超える構想。
- 目的はHydraを単独チャネル（head）からネットワーク型チャネルへ拡張すること。
- Lightning Networkのような複数ノード間を連結した支払い経路・状態遷移が可能になる。
- 現時点では実装や検証は進んでおらず、あくまで基礎研究・構想段階。
- Hydraの普及がまだ進んでいない段階で、Inter-Headのような複雑性追加は早すぎるという声も。
- とはいえ、Hydraが本格運用された後にスケールするための重要な次世代機能でもある。
- 実現すればHydraの適用範囲が格段に広がるが、現在のフェーズでは優先度は低い。
- まずはHydra基本機能の製品化が先、という全体の合意がありCに据え置かれた。
- 初期段階での技術難易度の高さや、ユースケースの明確化不足も課題。
- 長期的に必要だが、今すぐ予算を大きく割くべきではないとされた。
15. Congestion Control
- トランザクションの混雑（ネットワーク輻輳）時における制御と優先順位付けに関する研究。
- フィーレス構造を志向するチェーン（例：IOTAなど）ではしばしば未解決の大課題。
- Cardanoは一応のフィー構造を持つが、将来の混雑時に備えた予防的設計が求められる。
- 「スパム対策なしの完全無料」は現実的でなく、何らかの調整ロジックは必要。
- 公平なトランザクション処理（Fair Processing）やレイヤー2のTx統合にも関係。
- 特にHydraやMidgardといったL2が普及した場合、L1の輻輳制御がシビアになる。
- 提案としては抽象的な方向性が多く、具体実装や効果測定のビジョンは乏しい。
- そのため、現段階では「研究価値はあるがすぐに動く優先性はない」とされた。
- LeiosやParisとの統合設計が実現すれば、改めて重要度が上がる可能性もある。
- 状況によってはBに昇格の可能性を秘めた、補完的研究テーマ。
16. Anti-Grinding
- コンセンサス攻撃手法の一種である“grinding attacks”への耐性向上を目的とする提案。
- 現在のOuroborosも一定の耐性を持つが、改善の余地があるとされる。
- grinding攻撃は、特定ノードが未来のブロックを有利に選べるように状態遷移を繰り返すもの。
- セキュリティ観点では重要だが、現実の攻撃リスクは限定的と評価された。
- LeiosやParisを導入する過程で副次的にこの課題が解決される可能性が高い。
- そのため、個別に大きな予算・リソースを割く必要はないという意見が多数。
- あくまで「セキュリティ向上の一環」であり、単独ロードマップとしての強度には欠ける。
- ただし、改良策が比較的簡易であればParisの一部として採用される余地も。
- 提案自体は妥当だが、優先順位の高さという観点ではCが妥当と判断。
- セキュリティ強化が主眼の提案群の中では、ややマニアックな側面を持つ。
17. Log-Structured Merge (LSM) Trees
- UTXOデータベースのパフォーマンス向上を目的とした新しいデータ構造（LSM Tree）への移行提案。
- LSM Treeは書き込み性能に優れており、多数のDBで採用されている（例：RocksDBなど）。
- Cardanoの既存Haskell実装に自前でLSM類似の構造を実装する動きがあるが、開発が長期化。
- 既存の商用DBを使えば簡素化できるものの、Cardanoノードへの適合調整が必要。
- LSM導入によって、データ取得の遅延やノード動作のメモリ最適化が期待できる。
- 技術的には実装難易度が低くはなく、既存コードとの互換性も課題。
- 長く懸案となっている項目であり、「そろそろ完了させるべき」という意見も。
- コンセンサスには関わらないため、安全性には影響がないが、全体UXの底上げには寄与する。
- 実装の方向性によってはAにも昇格し得るが、Cに据え置かれた理由は「費用対効果」。
- エコシステムへの即効性が薄いため、基礎整備として位置付けられている。
D Tier（Low Impact：優先度は低いが無価値ではない）
18. Auditing Tools (Hydra関連監査ツール)
- Hydraチャネルの動作や履歴を可視化・検証可能にする「監査用インデクサー」提案。
- 目的はHydraが「何をしているのか」を外部から把握できるようにすること。
- しかしHydraの設計上、オフチェーンで動くため、ブラックボックス性は意図的なものでもある。
- 監査ツールを汎用化するのは困難で、アプリごとの実装が適切とされた。
- Doom on Hydraのような限定的なアプリには向いているが、一般化には疑問。
- ツール導入により「透明性が上がる」一方で、「監視されすぎる」との声も。
- Hydraの本質的な機能改善とは離れており、開発リソースの優先度としては低い。
- Hydra関連機能が成熟すれば将来的には必要となる可能性もあるが、今ではないと判断。
- あくまで「エコシステム支援ツール」の一種であり、コア技術ではない。
- 専用ユースケースや提携先からの要求が出た時点で再評価すべきとされた。
19. Fair Transaction Processing（公平なトランザクション処理）
- 混雑時に、全ユーザーの取引が公平に処理されるための新アルゴリズム提案。
- 現状では手数料が高いTxが優先される仕組み（fee market）が基本。
- これは資本格差による「取引機会の不平等」や「フロントランニング」の温床となり得る。
- 特にDeFi、L2、アグリゲーターなど、Tx遅延に敏感なユースケースでは深刻な問題。
- Leiosの導入により、一定の改善が期待されているため、現時点では前提技術未整備。
- 手数料設計やTxキュー設計の再考が必要であり、技術的・政治的調整が多い。
- 複数のアルゴリズム（優先度別Txスロットなど）が提案されているが、実装例は少ない。
- 結論としては、まず研究とアイデアの比較検討を行い、ガバナンス投票で方針を決めるべき。
- 実装コストが高く、成果が見えにくいため「提案段階での価値は低い」とされた。
- Leios導入後の次フェーズで再度議論すべき課題とされ、Dランクに分類。
20. Nested Transactions
- 複数のトランザクションを1つにネスト（包含）して実行する機能の提案。
- UTXOモデルでは複雑な状態遷移を複数Txで処理する必要があり、分かりづらさがある。
- ネスト構造を許容することで、Txの一括管理・検証が可能になり、開発が楽になるという主張。
- 他のUTXOチェーン（Fuelなど）では導入実績があるが、「冗長・非直感的」という評価も。
- Cardanoでは意図的にUTXOを分離的に設計しており、ネスト導入は哲学的に相反。
- StarStreamのようなZK-VM設計では別の方法（連続実行やコルーチン）で問題解決を図っている。
- ExplorerやWalletなどのフロント側でも実装が難しく、採用ハードルが高い。
- 現在の技術でもPlutusで一部代替は可能なため、「必須ではない」と判断された。
- 仕様変更の割に恩恵が少なく、標準化の労力に見合わないとの見方が大勢を占めた。
- 設計思想の違いから、むしろVMレベルでの代替手段を優先すべきとされた。
21. ZK Fold Symbolic
- Haskellで開発されたZKスマートコントラクト用DSL（ドメイン特化言語）。
- 高度に抽象化されており、型安全性や検証容易性を提供することを目指している。
- しかしながら、Plutusの開発でも明らかなように「Haskellは学習コストが高い」という指摘が多い。
- 開発者の参入障壁が高く、現実的な採用が難しいと懸念されている。
- Haskellベースという点で、以前のQTS/CXの失敗も連想される。
- 他方、AikenやHeliosなど、よりシンプルな言語が人気を博している。
- 研究的には興味深いが、現在のCardano開発者コミュニティとの相性が悪い。
- すでにZK機能はMidnightやStarStreamなど他プロジェクトで実装が進行中であり、優先度は低め。
- ただし、「既存言語にアノテーション的にZKサポートを追加する」方向にシフトすれば評価も上がる可能性。
- 現段階では「方向性は良いが、実装形態が適切でない」としてDランク評価に。
22. Multi-resource Consensus – Minotaur
- 複数のコンセンサスメカニズム（PoS＋PoWなど）を組み合わせる「複合コンセンサス」。
- 概念実証的な論文が発表されており、主にパートナーチェーンやL2向けの提案。
- Midnightなど一部プロジェクトでは採用検討されているが、Cardano本体では関係が薄い。
- Ethereumなど他のL1ではすでにPoW→PoS移行が完了しており、複合型の需要は限定的。
- 複雑性が増す割に、得られるセキュリティメリットが薄いという評価も。
- そのため、「Cardanoのリソースで直接投資すべきではない」との結論に至った。
- PoW部分のセキュリティが弱い場合、逆に全体の信頼性が低下する懸念もある。
- 学術的価値は高いが、実用面ではロードマップ外との判断。
- 一部用途には魅力的だが、今は他項目に集中すべきという姿勢からDに分類。
- 「リソースに余裕があれば支援しても良い」という補足も加えられた。
F Tier（Not Recommended：現時点では推奨されない）
23. Hydra Tail
- Hydraの拡張提案の1つで、「多数の個別アカウントとHydraヘッドを接続する構想」。
- 従来のHydraは1対1、または小規模グループでの即時決済を目的としていた。
- TailではよりオープンなP2C（Peer-to-Contract）型の取引を志向している。
- しかし、これを完全なトラストレス構成で行うにはZero-Knowledge技術の応用が不可欠。
- 現状のCardanoエコシステムにはZKの本格的なインフラ（証明者、検証者、言語など）が不足。
- 以前に模擬プロトコルでの検証も行われたが、期待した性能が得られなかった。
- 今後StarStreamなどのZK-VMが整備されれば、再評価される可能性はある。
- 現段階では技術基盤が揃っておらず、開発しても十分な効果が得られないとされた。
- 「将来的には重要だが、今やっても意味がない」という趣旨でF評価。
- 2〜3年後にZK環境が整えば、A〜Bランクへの昇格も視野。
24. Proofs of Useful Work
- 「PoW（プルーフ・オブ・ワーク）を有用な計算に活用できないか」というアイディア。
- 具体的には、マイニングのように無駄なハッシュ計算ではなく、AIや折りたたみタンパク質などの実用計算を使う。
- 概念としては魅力的だが、過去にも同様の構想はあり実現困難とされてきた。
- カスタム計算を安全に検証し、なおかつコンセンサスの公平性を保つには高度な工夫が必要。
- また、ユースケースとの適合性や標準化の難しさも指摘されている。
- 研究段階では興味深いが、Cardanoのリソースを使って開発するには範囲外。
- 現在のエコシステムにおいて、直接的な関係は見られない。
- 特にCardanoがPoWベースではないことから、「根本的に方向性が異なる」とされた。
- 専門家からも「オフトピックに近い」との評価を受け、Fに分類された。
- 新興プロジェクトでのパイロット後に評価されるべき領域。
25. Governance Incentives
- DRep（Delegated Representative）や投票参加者へのインセンティブ支給を正当化・設計する提案。
- 現在のVoltaireでは、DRepに直接的な報酬制度は存在していない。
- この提案は「ガバナンスへの参加を経済的に奨励しよう」という方向性を含む。
- しかし、コミュニティの間では報酬導入の是非そのものがまだ合意形成されていない。
- 「報酬を与えると職業化・買収のリスクが増す」という反対意見も根強い。
- 実装前に社会的合意やガバナンスCIPの整備が不可欠であり、時期尚早との評価。
- 技術的にはスマートコントラクトで実現可能であり、L1の変更は不要。
- 優先順位が高い他項目に比べ、現段階では影響範囲が限られている。
- DRep制度自体が安定していない段階では実施は難しいとされ、F評価。
- 「仕組み化は必要だが、まだ先の話」という総意。
26. Light Client Infrastructure
- 軽量ノードや他チェーンからCardanoを参照するための「クライアントインフラ」整備提案。
- 目的は「外部チェーンや簡易ウォレットがCardanoを検証・参照できるようにする」こと。
- ただし、実装方式によって価値が大きく異なるため、評価が二極化。
- 外部チェーン接続のためのlight clientなら重要（例：BTC→ADAブリッジ）。
- 一方、単なるモバイルウォレットのためのlight nodeなら、既存手法で十分。
- Mithrilの強化によって実質的なlight client機能はすでに提供されつつある。
- 「何をlight clientと呼ぶか」が曖昧で、明確な要件が不足している点も課題。
- 既存のMidnight・StarStreamなどが別経路で対応しているため、優先順位が低下。
- Mithril Enhancementsとの重複を避けるため、そちらに統合すべきという意見が多数。
- 「内容によってはS評価にもF評価にもなる」という前提で、今回は後者に分類された。
27. Consensus Innovation
- 新しいコンセンサスアルゴリズムの研究・提案全般を示す抽象的項目。
- 例えばFastBFT、Minotaur、PoS変形版などが含まれるが、具体性に欠ける。
- 現在、Ouroboros Leios や Peras によって既にコンセンサス改善の道筋が明示されている。
- 新規研究を並行で進める意義はあるが、資金配分先としては弱い。
- 「実装につながらない抽象的研究に資金を投入するのは非効率」という評価。
- また、将来的に有望な新プロトコルが出た場合は、それ単独で提案されるべき。
- Cardanoの今後5年のロードマップにおいては、他の実装優先事項が多く存在。
- コア開発チームが分散している状況では、集中と選択が必要とされた。
- 「学術的には良いが、実用目的では現時点で優先順位が低い」との判断。
- 結果としてF（Not Recommended）に位置づけられた。
28. fastBFT
- BFT系コンセンサスの高速化提案で、Midnightやパートナーチェーン向けに開発中。
- Byzantine Fault Toleranceの合意速度を向上させる研究として価値はある。
- ただし、Cardano L1が対象ではなく、Layer2や独立パートナーチェーンでの利用が前提。
- MidnightやQuantstampがこの領域に注力しており、独立予算で進めるべきとの意見。
- 本体ロードマップとしては無関係であり、「完全にオフトピック」と断じられた。
- 研究は有意義だが、実装負担やリターンを考えるとCardano財源で支援する意義は薄い。
- エコシステムとしての広がりは歓迎されているが、Roadmap予算対象外。
- 過去の同様提案でも進展が乏しかったことも影響している。
- 採用されるとしても、L1に影響を与えるのは数年先となる。
- 現段階では支援に値しないという合意からFに分類された。
? Tier（Insufficient Information：評価保留）
29. Timeliness Market
- 提案内容の文脈や詳細が不明確で、Tier評価メンバー全員が内容理解に苦しんだ項目。
- 概要としては、トランザクションの「タイムクリティカル性（緊急度）」をマーケット化するような構想が想定されていた可能性がある。
- 他の案（例：Fair Transaction ProcessingやCongestion Control）と類似点も多いが、区別が曖昧。
- 説明には「ノードが生成するブロックへのTx挿入を保証する」などの記述があったが、それは既に現行プロトコルで対応済。
- コンセンサスの「Liveness性」（生存性）が既に保証されているため、この提案が何を追加で解決するのかが不明。
- 実装面でも、既にLeiosやParisが対応予定の問題と重なっており、独立性に乏しいとされた。
- 提案が具体的なユースケースや仕組み、技術案を示していなかった点も評価不能の原因となった。
- 他提案との重複や、曖昧な命名（“Timeliness Market”）により、提案意図を汲み取るのが困難だった。
- 最終的には「他の類似提案に吸収されるべき」「再提案を待つべき」という意見が一致。
- このためTierリスト上では“?”（評価不能）カテゴリに分類され、今後の明確化が求められる。