CoffeePool☕️

NO ->> Reduce minPoolCost to 75 ada and increase Plutus Memory Limits (Part 2)

I am voting NO on this bundled Parameter Change reducing minPoolCost from 170 to 75 ADA and increasing Plutus memory execution limits by a cumulative 25%.
I fully agree with the network sustainability concerns this proposal identifies. Block rewards have fallen from approximately 1,800 ADA at Shelley launch to around 300 ADA today as the reserve depletes, while infrastructure costs have broadly risen. Against this backdrop, reducing minPoolCost may provide a stopgap with some effect for a limited period. However, given the long-term trajectory of continuously declining rewards, this is a measure that will need to be repeated — it is not a solution. The proposal itself signals that the long-term direction points toward zero, and I understand this to be a deferral rather than a resolution. The structural causes of declining rewards are the reduction in reward supply, the treasury distribution ratio, and reserve depletion. This proposal does not address any of these; it adds only a short-term stopgap. Regardless of how minPoolCost is set, block rewards will continue to fall. Small pool operators gain temporary competitive relief, but that relief will erode as rewards decline further. The underlying pressure is not resolved; it is inherited by the next parameter adjustment cycle. And above all, sustaining a pool at 75 ADA is extremely difficult given the current ADA price.
The Plutus memory limit increases may compound this problem asymmetrically. The proposal states that performance testing was conducted using current node version benchmarks, but those benchmarks reflect well-resourced infrastructure. The operators most affected by the reward reduction are smaller pools running at or near minimum viable hardware, and it is this same population for whom incremental increases in block execution load carry the greatest marginal cost. The proposal lowers their income floor and raises their operational ceiling in a single action, without verifying whether the operators absorbing the cost increase are the same population receiving the fee reduction benefit. The proposal further states that more recent node versions provide additional performance improvements. Those improvements might otherwise have translated into reduced hardware requirements for smaller operators — a concrete cost-side benefit for the pools this proposal claims to support. By consuming that headroom through increased execution limits, this action redirects the gains from node efficiency away from SPO cost relief and toward DApp execution capacity. The operators who stand to benefit least from expanded Plutus headroom may end up bearing the cost of providing it.
The performance evaluation cited covers node versions 10.2 and 10.3, conducted by IOE's Performance and Tracing team. However, the proposal does not specify the hardware profile, delegation volume, or transaction composition used in those benchmarks, nor does it provide data on how the full 25% cumulative increase performs across the range of real SPO environments currently active on mainnet. The claim that more recent node versions provide further improvements is stated without quantification. Where benchmark scope is undisclosed and headroom estimates are unquantified, the conclusion that the increase is safe cannot be fully separated from the judgment of the team that conducted the evaluation. That is not a reason to reject the change outright, but it is a reason to require a more transparent evidential basis before enacting an irreversible parameter increase bundled with an unrelated fee reduction.
This proposal also submits two independent changes simultaneously, which means an SPO who supports one and opposes the other cannot express that position. Submission efficiency and the interests of the network as a whole do not necessarily align. Each substantive change should be deliberated independently, with a vote that reflects the actual position of the stakeholders it affects.
Finally, before reducing the minimum fee floor further, the ecosystem should focus its energy on actively debating and answering why rewards continue to decline and whether that trajectory is acceptable. The question of how the reserve-to-circulation transition is managed over the coming epochs is the prior question. This proposal assumes the answer and optimises around it.
For these reasons, I vote NO.
[Japanese version follows]
「minPoolCostを170から75 ADAに引き下げ、Plutusのメモリ実行上限を累計25%引き上げる」パラメータ変更案に対し、反対票を投じます。本提案が指摘する問題であるネットワークの持続可能性の懸念については十分に同意できます。Shelleyローンチ時に約1,800 ADAあったブロック報酬は、リザーブ枯渇に伴い現在は約300 ADAにまで低下しており、一方でインフラコストは全般的に上昇しています。こうした背景のもと、minPoolCostの引き下げは明示的に「ストップギャップ（応急措置）」として一定期間の効果があると考えられます。しかしこれは、長期的に減少し続けるリワードを念頭に置くと、繰り返さざるを得ない応急措置であり、解決策ではありません。本提案自体が長期的な方向性として0への収束を示唆していることからも、これは問題の先送りにすぎないことを理解しています。報酬低下の構造的原因は、リワード供給の減少、トレジャリー分配比率、そしてリザーブの枯渇です。本提案はこれらに対処せず、短期的な応急措置を加えるに過ぎません。minPoolCostがどう設定されようと、ブロック報酬は引き続き下落します。小規模プールオペレーターは一時的な競争力改善を得ますが、それはさらなる報酬低下とともに失われます。根本的な圧力は解消されず、次のパラメータ調整サイクルに引き継がれるだけです。そして何より、75 ADAでプールを維持し続けることは現在のADA価格を考慮すると非常に難しいと言えます。
そしてPlutusメモリ上限の引き上げは、この問題を非対称的に悪化させる可能性があります。本提案では性能テストを現行ノードバージョンのベンチマークで実施したと述べていますが、それは潤沢なインフラを前提とした環境です。報酬削減の影響を最も大きく受けるのは、最低限のハードウェアで運用している小規模プールです。ブロック実行負荷の増加が限界コストとして最も重くのしかかるのも、この小規模プール層です。本提案は一つのアクションで彼らの収入下限を引き下げ、運用上限を引き上げていますが、コスト増を吸収するオペレーターと手数料削減の恩恵を受けるオペレーターが同一かどうかを検証してはいません。さらに本提案は、より新しいノードバージョンが追加的な性能改善をもたらすと述べています。本来であればその改善は、小規模オペレーターのハードウェア要件の引き下げ、すなわち本提案が支援の対象と位置づけるプールへの具体的なコスト削減として還元されるはずのものです。しかしメモリ上限の引き上げによってそのヘッドルームを即座に消費することで、本アクションはノード効率化による果実をSPOのコスト軽減からDAppの実行余裕へと転用しています。Plutusのヘッドルーム拡大から最も恩恵を受けない層が、その提供コストを負担することになる可能性があります。
引用された性能評価はnode 10.2および10.3を対象にIOEのPerformance & Tracingチームが実施したものです。しかし本提案では、当該ベンチマークで使用されたハードウェアプロファイル、委任量、トランザクション構成を明示していません。また累計25%の引き上げがメインネットで実際に稼働している多様なSPO環境全体においてどのように機能するかを示すデータも提供されていません。より新しいノードバージョンがさらなる改善をもたらすという主張も数値的な裏付けを伴っていません。ベンチマークの範囲が非公開でヘッドルームの推定が定量化されていない場合、「引き上げは安全である」という結論を、評価を実施したチームの判断から切り離すことはできません。これは変更を全面的に否定する理由ではありませんが、無関係な手数料削減とバンドルされた不可逆的なパラメータ引き上げを承認する前に、より透明性の高いエビデンス基盤を求める十分な理由となります。
また本提案は個別の２つの提案を同時に提出しており、一方の変更に賛成し、もう一方に反対するSPOは、その立場を表明できません。提出数を効率化することと、ネットワーク全体の利益は必ずしも一致しません。実質的な変更はそれぞれ独立して審議され、影響を受けるステークホルダーが実際の立場を反映した投票を行えるべきです。
さらに、最低手数料フロアをさらに引き下げる前に、なぜ報酬が低下し続けているのか、そのトレジェクトリーは許容できるのかを確認し、活発に議論し答えを出すことに注力すべきと考えます。今後のエポックにわたるリザーブから流通への移行をどう管理するかという問いが、先に答えられるべき問いです。本提案はその答えを所与のものとして、その周辺を最適化しています。
以上の理由から、私は本提案に対して反対票を投じます。

I am voting Yes on New members of Constitutional Committee, as respecting the prior off-chain voting result.

I am voting Yes on this proposal. The van Rossem hard fork (Protocol Version 11) improves Plutus performance and capability (new primitives across CIP-0109/0132/0133/0138/0153, unified built-ins across V1/V2/V3, and native case-expressions), strengthens ledger consistency and node-level security (VRF key hash uniqueness enforced at the ledger level, and the Constitutional Committee voting restriction promoted to a ledger predicate), all as a backward-compatible intra-era upgrade that leaves transaction shape unchanged and introduces no new or deprecated protocol parameters. It is also procedurally well-vetted: recommended by Intersect's Hard Fork Working Group and endorsed by the Technical Steering Committee, with completed security audits, performance reports showing no regressions, and conformance testing across Plutus V1, V2 and V3. The action is consistent with all eight HARDFORK guardrails; the only outstanding condition is HARDFORK-04 (at least 85% of stake by pools upgraded), which the Constitutional Committee and SPOs are expected to verify before ratification. On that basis I am voting Yes.\n\n[Japanese version follows]\n\n本提案に賛成票を投じます。van Rossem ハードフォーク（Protocol Version 11）は、Plutus の性能と機能を向上させ（CIP-0109/0132/0133/0138/0153 の新プリミティブ、V1/V2/V3 でのビルトイン統一、ネイティブな case 式）、台帳の整合性とノードレベルのセキュリティを強化します（VRF 鍵ハッシュの一意性を台帳レベルで強制、Constitutional Committee の投票制限を台帳ルールへ昇格）。これらはすべて後方互換のイントラエラ・アップグレードとして実施され、トランザクション形状は不変で、新規・廃止のプロトコルパラメータもありません。手続面でも十分に検証されており、Intersect の Hard Fork Working Group が推奨し、Technical Steering Committee が承認済みで、セキュリティ監査の完了、リグレッションのない性能レポート、Plutus V1・V2・V3 全体での適合テストが揃っています。本アクションは 8 つの HARDFORK ガードレールすべてに準拠しており、残る条件は HARDFORK-04（アクティブステークの 85% 以上を占めるプールのアップグレード）のみで、これは ratification 前に Constitutional Committee と SPO が検証する見込みです。以上の理由から、私は賛成票を投じます。

I am voting "Yes" on "Adding a New Constitutional Committee Member." This is the result of the previous election held by Intersect, and no authority managed other election for this. I have joined the voting, and this means I am going to follow the result no matter who was elected (actually I voted for Cardano Curia). [Japanese version follows] 憲法委員の追加について、賛成票を投じます。本案はインターセクトが行なった選挙結果によるもので、同団体以外はこうした投票を行なっていませんでした。また、私自身も投票に参加しており、それはこの選挙結果に従うことを意味します（実際にはCardano Curiaに投票していました）。