SIPO DRep： Transaction / Block Memory Units Increase（Part 1） 提案について― 提案の概要・詳細解説と、SIPO DRepとしての「Yes」評価とスタンス 

Increase Transaction and Block Memory Units (Part 1 of 2)
Governance Action Type：Protocol Parameter Change

Submitted: 15th Jan 2026 (Epoch 606)
Expires: 14th Feb 2026 (Epoch 613)

Governance Action ID:
gov_action1cgdsp7g0rr7wgqp7maptpvx525fxuqwfgm5qe3f5r20ew5x2772sq0m5y83
Legacy Governance Action ID (CIP-105):
c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf795#0

投票結果：https://adastat.net/governances/c21b00f90f18fce4003edf42b0b0d455126e01c946e80cc5341a9f9750caf79500

Plutusメモリ制限引き上げ提案とは何か― Transaction / Block Memory Units Increase（Part 1）をどう見るか ―

SIPOです。

今回は、現在ガバナンス投票にかけられている

「Increase Transaction and Block Memory Units（Part 1 of 2）」

というプロトコル・パラメータ変更提案について、概要から詳しい解説、そして SIPO DRepとしてのスタンス を整理して共有します。

提案の概要

本提案は、Intersect の Parameter Committee によって提出された、

Plutusスクリプトが利用できるメモリ実行上限を引き上げる プロトコルパラメータ変更です。

変更点は以下の2つです。

• トランザクション単位（per-transaction）
  • maxTxExecutionUnits[memory]
  • 14,000,000 → 16,500,000
• ブロック単位（per-block）
  • maxBlockExecutionUnits[memory]
  • 62,000,000 → 72,000,000

いずれも、Cardano憲章で定められた ガードレールの最大許容幅内 に収まっています。

なお本提案は 2段階構成（25%増） のうちの 第1段階（Part 1） であり、後続の増加は別のガバナンスアクションとして、最低2エポック後に改めて提案される予定です。

何が変わるのか（開発者・ユーザー視点）

今回の変更は、Plutusの設計思想やコストモデルを変えるものではありません。

あくまで、

「これまで安全性の観点から余裕を持たせていたメモリ上限を、検証結果に基づいて解放する」

という性格の調整です。

これにより、

• 複雑なロジックを1トランザクションにまとめやすくなる
• 不自然なトランザクション分割が減る
• 過剰な最適化をしなくても設計できる
• UX（署名回数・Tx数）の改善につながる

といった、実務的で即効性のある改善が期待されます。

既存DAppも、コードを書き直さずに恩恵を受けられる可能性がある点も重要です。

技術的背景と安全性

この提案が成立している背景には、ここ1〜2年の間に進んだ Plutus実行系の最適化と計測精度の向上 があります。

• ノード v10.2 / v10.3 を用いた詳細ベンチマーク
• Praos のブロック生成・伝播時間への影響評価
• Preview / PreProd テストネットでの実地検証

これらの結果から、

• ブロック伝播（3秒目標 / 5秒95%）
• ネットワーク安定性
• SPO運用負荷

のいずれにも 十分なヘッドルームがある ことが確認されています。

そのため今回の変更は、

• セキュリティを緩めるものではなく
• ネットワークを重くするものでもなく

「検証済みの余地を、段階的に使う」 という位置付けです。

ブロックチェーン全体で見た位置付け

多くのL1では、

「TPSを上げる」「ブロックを大きくする」といった、

やや単純なスケーリング手法が取られがちです。

一方でCardanoは、

• 実行単位（steps / memory）を明示的に管理
• 伝播時間を前提とした設計
• ベンチマークとガバナンスを前提にした段階的変更

という、研究主導・運用重視型のアプローチを取っています。

今回の提案は、

Cardanoが「派手な性能競争」ではなく、

持続的に使われ続けるL1であること

を優先していることを示す、象徴的なアップデートだとSIPOは考えています。

SIPO DRepとしてのスタンス

SIPO DRepとして、本提案（Part 1）には 賛成（YES） の立場を取ります。

理由は明確です。

• 十分な技術検証とテストネット実績がある
• 憲章ガードレールを完全に順守している
• 開発者・ユーザーにとって実利が大きい
• SPOやネットワークへの追加リスクが小さい

一方で、SIPOの賛成は 無条件ではありません。

本提案は2段階構成であり、

後続のPart 2については、今回の変更がメインネットでどのように機能するかを確認したうえで、改めて判断すべき だと考えています。

つまり、

「Part 1は妥当。Part 2は自動承認ではない」

という立場です。

この線引きを明確にすることこそが、

DRepとしての責任ある判断だとSIPOは考えています。

まとめ

今回の提案は、地味ではありますが、

• Cardanoのガバナンスが機能していること
• 技術的成熟に合わせて段階的に前進できていること

を示す、非常に重要な一歩です。

SIPOとしては、

検証された進歩には賛成し、未検証な飛躍には慎重である

という姿勢を、今後も一貫して取り続けます。

---

Increasing Plutus Memory Limits— SIPO’s View on the Transaction & Block Memory Units Update (Part 1)

This is SIPO.

In this post, we would like to share an overview, detailed explanation, and our position as a DRep regarding the governance action “Increase Transaction and Block Memory Units (Part 1 of 2)”, which is currently up for vote.

Proposal Overview

This governance action, submitted by the Intersect Parameter Committee, proposes an increase to the Plutus script memory execution limits at both the transaction and block levels.

The proposed changes are:

• Per-transaction
  • maxTxExecutionUnits[memory]: 14,000,000 → 16,500,000
• Per-block
  • maxBlockExecutionUnits[memory]: 62,000,000 → 72,000,000

All changes are fully within the Constitutional guardrails and represent the maximum permitted increase per epoch.

This proposal is Part 1 of a two-step (25%) increase, with any subsequent increase requiring a separate governance action and fresh evaluation.

What This Means in Practice

This update does not change Plutus’ design principles or cost model.

Instead, it unlocks previously reserved headroom, based on new benchmarking data.

For developers and users, this means:

• Fewer forced transaction splits
• More expressive logic per transaction
• Reduced over-optimization
• Improved user experience

Importantly, existing applications may benefit without requiring redesign, and SPOs are not exposed to additional operational burden.

Technical Background and Safety

Extensive benchmarking using node versions 10.2 and 10.3, combined with Preview and PreProd testnet deployments, confirms that:

• Block propagation targets remain satisfied
• Praos timing guarantees are preserved
• Network stability is not compromised

This is a measured, evidence-based adjustment, not a relaxation of security assumptions.

Broader Blockchain Context

Rather than pursuing headline TPS numbers, Cardano continues to prioritize:

• Explicit execution budgets
• Predictable network behavior
• Governance-driven, incremental upgrades

From SIPO’s perspective, this proposal reflects Cardano’s long-term philosophy:

sustainable, high-quality scaling over short-term performance optics.

SIPO DRep Position

As SIPO DRep, we vote YES on this proposal.

We do so because it is:

• Technically sound and well-benchmarked
• Fully compliant with governance guardrails
• Clearly beneficial to developers and users
• Low-risk for network operations

However, our support is explicitly limited to Part 1.

Any future increase (Part 2) should be evaluated independently, based on real mainnet data after this change is enacted. Approval of this proposal should not be interpreted as automatic approval of subsequent increases.

Closing

This proposal may not be flashy, but it is an important signal that Cardano’s governance and technical processes are working as intended.

SIPO will continue to support validated progress, while remaining cautious and data-driven about future expansions.