- Intersect의 Parameter Committee는 이전에 권장된 두 가지 독립적인 프로토콜 파라미터 변경 사항을 하나로 묶은 단일 파라미터 업데이트 거버넌스 안건을 제안했음.

- minPoolCost: minPoolCost를 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 인하함.

- Plutus 메모리 유닛 제한(파트 2/2): maxTxExecutionUnits[memory]를 16,500,000에서 17,500,000 유닛으로(+6.1%) 늘리고, maxBlockExecutionUnits[memory]를 72,000,000에서 77,500,000 유닛으로(+7.6%) 늘려 연계된 파트 1 안건에서 시작된 두 단계 누적 25% 인상을 완료함.

- 이 두 변경 사항은 서로 무관함.

- 하나는 스테이크 풀 고정 수수료 하한선을 낮추고, 다른 하나는 Plutus 스크립트 실행 여유 공간을 늘림.

- 제출 효율성을 높이고 SPO들이 minPoolCost에 대해 의견을 제시할 수 있도록 이 안건에 함께 묶였음.

- 이 안건으로 인해 다른 프로토콜 파라미터나 Plutus 비용 모델 설정은 변경되지 않음.

■ 주석
*minPoolCost: 스테이크 풀 운영의 최소 고정 비용
***SPO: 스테이크 풀 운영자(Stake Pool Operator)

- minPoolCost: minPoolCost는 2023년(PCP-001)에 340 ₳에서 170 ₳로 인하되었으나, 준비금 기반 블록 보상의 지속적인 감소로 인해 그 혜택이 크게 약화되었음.

- 2023년 변경 이후 ~28.3%로 떨어졌던 단일 블록 풀에 대한 위임자 페널티는 그후 ~52.8%로 다시 올랐으며, 해결되지 않을 경우 2028년 2월(에포크 758경)에 100%에 이를 것으로 예상됨.

- IO Research의 최신 인센티브 보고서는 높은 고정 수수료 하한선이 대형 운영자에 의한 시빌(Sybil) 스타일의 스테이크 단편화를 억제하기보다 오히려 선호하게 만든다는 입장으로 선회했음.

- PCP-006(Cerkoryn, 2026)은 비례적인 minPoolMargin(CIP-0023)이라는 보다 구조적인 해결책을 기다리며 증거 기반의 중간 단계로서 75 ₳로의 추가 인하를 제안함.

- Plutus 메모리 유닛 제한: 이 2단계 변경의 파트 1은 가이드라인 MTEU-M-04 및 MBEU-M-03에 따라 허용되는 최대 단일 에포크 금액만큼 maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]를 늘렸음.

- Intersect Parameter Committee가 권장하고 Technical Steering Committee가 비준한 전체 25% 인상을 단일 에포크 내에서 개별 안건이 maxTxExecutionUnits[memory]는 2,500,000 유닛, maxBlockExecutionUnits[memory]는 10,000,000 유닛을 초과하여 늘릴 수 없기 때문에 파트 1 단독으로는 달성하지 못했음.

- 본 안건은 나머지 부족한 부분을 채워 두 파라미터를 원래 권장된 목표 값으로 맞추고, 이전 제한으로 인해 제약을 받던 DApp 개발자의 애로사항을 줄여줌.

■ 주석
*Sybil: 한 개인이 여러 개의 신원을 만들어 네트워크를 조작하려는 공격 방식
***DApp: 탈중앙화 애플리케이션

- minPoolCost 기술 평가 및 위원회 절차: 현재 170 ₳ 설정은 2023년 Intersect Parameter Committee가 권장하고 CIP-1694에 따른 온체인 파라미터 업데이트 거버넌스 안건이 도입되기 전인 에포크 445(2023년 10월)에 제정되었음.

- 75 ₳로의 추가 인하 제안은 Cerkoryn이 작성하여 2026년 3월 30일 Cardano Forum에 게시한 PCP-006의 주제이며, 수락 기준의 일환으로 Intersect Technical Steering Committee(TSC)의 승인을 명시적으로 요청했음.

- TSC는 2026년 7월 9일 이 인하를 비준했으며, 본 거버넌스 안건과 아래의 증거 기록은 해당 승인 절차와 후속 온체인 투표를 지원하기 위한 것임.

- minPoolCost 인플레이션 모델 및 보상 경제 하락: 셸리(Shelley) 출시 시점에 minPoolCost는 당시의 ₳ 가격, 인플레이션 일정, 예상 SPO 운영 비용을 기준으로 산정되었음.

- 준비금이 고갈됨에 따라 블록당 보상이 블록당 약 1,800 ₳에서 약 300 ₳로 떨어졌으며, 인프라 비용은 전반적으로 상승하여 2020년 이후 세 가지 입력값이 모두 크게 변동했음.

- PCP-001 부록 데이터를 보면 minPoolCost는 에포크당 한두 개의 블록만 생성하는 소규모 풀의 전체 보상에서 지나치게 큰 비중을 차지함.

- minPoolCost 경쟁 다이내믹스 및 트레저리 영향: 위임자는 풀의 예상 스테이킹 수익률(RoS)을 확인할 수 있으므로 minPoolCost 하한선에서 운영되는 소규모 풀은 대규모 풀에 비해 구조적으로 불리함.

- minPoolCost를 낮춘다고 해서 특정 SPO가 수수료를 낮추도록 강제되는 것은 아니지만, 하한선에 있는 소규모 풀들이 새로운 낮은 하한선을 채택하여 경쟁력이 향상될 것으로 기대됨.

- 이는 stakePoolTargetNum(k)과 직접적으로 관련이 있으며, 향후 k를 인상하기 전에 소규모 풀의 건강한 생태계가 경제적으로 생존 가능해야 하므로 이번 인하를 통한 소규모 풀 경제성 개선은 대안이 아닌 선행 필수 단계임.

- minPoolCost 인하는 트레저리 유입을 미미하게 감소시키며, Parameter Committee 경제 실무 그룹은 2023년 인하와 관련하여 트레저리 잔액이 예상치를 상회하므로 장기적인 경제 안정성에 위험이 없다고 평가했음.

- minPoolCost 시빌 공격 고려사항: 손실을 보면서 풀을 운영하여 지배적 지분을 확보하려는 공격자에게 최소 비용 하한선을 부과하는 것이 시빌 완화를 위한 minPoolCost의 원래 근거였음.

- PCP-001의 2023년 분석에 따르면 비근시안적 게임 이론 균형 하에서는 시빌 공격을 방지하는 데 minPoolCost가 엄격히 필요하지는 않지만, 악의적 행위자 모델 하에서는 실질적인 비용을 부과함.

- IO Research의 최신 보고서는 높은 고정 수수료 하한선이 고정 수수료를 반복 수취하기 위해 지분을 여러 풀로 쪼갤 수 있는 대자본 운영자의 시빌 스타일 지분 단편화를 억제하기보다는 오히려 선호하게 만든다고 결론지었음.

- 이에 따라 보안을 이유로 높은 하한선을 유지하는 주장이 약화되었으므로 0으로 즉시 이동하는 대신 75 ₳로의 추가 단계적 인하를 권장함.

- 2023년 이후의 실증적 증거: PCP-001 당시에는 없었던 2년간의 2023년 이후 데이터를 사용할 수 있게 되었음.

- 2023년에 제기된 '바닥으로의 경쟁(race to the bottom)' 우려와 달리 시장은 새로운 하한선으로 무너지지 않았으며, 340 ₳는 축소 후에도 여전히 주요 고정 수수료 설정으로 남았고 소규모 및 경쟁력 있는 풀만 낮은 하한선을 채택했음.

- IOR 보고서는 활성 풀 1,614개 중 873개 운영자(54%)가 일관된 블록 생성을 위한 약 3백만 ₳ 위임 임계값 아래에 머물러 있는 생태계 계층화를 기록하고 있으며, 이는 2023년 인하만으로는 근본적인 구조적 압력을 해결하지 못했음을 나타냄.

- 라이브 안건 PCP-006 및 향후 방향: 2026년 3월 30일 기준 PCP-006(Cerkoryn)은 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준으로 회복하도록 170 ₳에서 75 ₳로 인하할 것을 요청하며, 이는 minPoolMargin 파라미터(CIP-0023)와 같은 구조적 해결책이 구현될 때까지의 임시 방편임.

- minPoolCost의 장기적 궤적은 파라미터 업데이트의 점진적 인하(CIP-0074)나 CIP-0023을 통한 구조적 교체를 통해 0 또는 기능적 무의미함을 향하고 있음.

- CIP-0082는 이러한 순서와 일치하는 minPoolCost 및 stakePoolTargetNum(k) 전반의 단계적 결합 로드맵을 제시함.

- 본 제안은 장기적인 구조적 프로세스와 독립적으로 지금 당장 이용할 수 있는 단기적이고 저위험인 단계임.

- minPoolCost 제안된 파라미터 변경: minPoolCost는 현재 설정인 170,000,000 Lovelace(170 ₳)에서 75,000,000 Lovelace(75 ₳)로 약 55.9% 감소함.

- 가이드라인과의 일치성: PARAM-05(거버넌스 핵심 파라미터에 대한 DRep 투표)에 따라 minPoolCost는 거버넌스 시스템에 핵심적인 파라미터에 포함되며, 원장의 비준 규칙에 의해 자동으로 강제되는 표준 DRep 과반수 임계값(활성 투표 지분의 50% 초과)의 대상이 됨.

- PARAM-06(3개월 통지): PCP-006은 2026년 3월 30일 Cardano Forum에 게시되었으며, 본 거버넌스 안건은 2026년 6월 30일 이전에 제출되지 않으므로 통지 기간을 충족하고 PCP-001(2023) 및 2022년 이후의 커뮤니티 주도 논의를 바탕으로 함.

- MPC-01: 제안된 설정(75,000,000 Lovelace)은 양수임.

- MPC-02: 제안된 설정은 500,000,000 Lovelace 상한선보다 훨씬 낮음.

- MPC-03: 제안된 75 ₳ 설정은 PCP-006에 따라 단일 블록 풀에 대한 위임자 페널티를 초기 셸리 수준에 가깝게 복원하도록 보정되었음.

- Plutus 메모리 제한 기술 평가: 두 Plutus 메모리 파라미터에 대한 전체 25% 인상은 2025년 5월 8일 Intersect의 Parameter Committee가 권장하고, 2025년 10월 1일 Intersect의 Technical Steering Committee가 비준했음.

- 이 권장과 비준은 전체 2단계 변경을 다루므로, 승인된 계획의 후반부를 구현하는 본 안건은 별도의 위원회 권장을 요구하지 않음.

- Plutus 메모리 제한 테스트넷 배포: 연계된 두 안건 전반에서 제안된 전체 목표 값(maxTxExecutionUnits[memory] 17,500,000 및 maxBlockExecutionUnits[memory] 77,500,000)은 2026년 7월 프리뷰(Preview) 테스트넷에서 함께 시험되었음.

- Plutus 메모리 제한 기능, 보안 및 성능: 본 안건의 효과는 단일 블록 내에서 Plutus 스크립트가 더 많은 작업을 수행할 수 있도록 하여 DApp 개발자와 사용자의 애로사항을 줄이는 것임.

- Praos 타이밍 보장이 유지되므로 특정 보안 우려는 제기되지 않음.

- maxTxExecutionUnits[memory]를 늘려도 성능에 영향이 없으며, maxBlockExecutionUnits[memory] 인상의 영향은 노드 버전 10.2 및 10.3을 사용하여 IOE의 Performance and Tracing 팀이 평가한 결과 중요한 타이밍 지표에서 적절한 여유 공간이 있음을 나타냄.

- Plutus 메모리 제한 제안된 파라미터 변경: 시작점 maxTxExecutionUnits[memory] 14,000,000, maxBlockExecutionUnits[memory] 62,000,000에서 파트 1은 각각 16,500,000(+17.9%), 72,000,000(+16.1%)으로 인상되었고, 파트 2(본 안건)는 각각 17,500,000(+6.1%), 77,500,000(+7.6%)으로 인상되어 누적으로는 둘 다 25.0% 인상됨.

- 이는 단일 블록에 들어갈 수 있는 최대 크기 트랜잭션 수(4개)에 대한 용량을 유지함.

- Plutus 메모리 제한 가이드라인과의 일치성: PARAM-03a(핵심 운영 파라미터에 대한 SPO 투표 필요)에 따라 maxBlockExecutionUnits[memory]는 블록체인 운영에 핵심적이므로 DRep 투표 외에도 활성 블록 생성 지분의 50% 초과라는 SPO들의 집단적 찬성이 필요하며, 이는 원장에 의해 자동으로 강제됨.

- PARAM-04a(3개월 통지): 25% 전체 목표를 다룬 2025년 7월 7일의 오프체인 게시를 통해 충족되었으므로 이 두 번째 단계를 위해 새로운 통지 기간이 필요하지 않음.

- NETWORK-01(2에포크당 1개 이하의 변경): 동일한 두 파라미터를 변경한 파트 1 이후 2에포크 이상 지나서 본 안건이 제정됨.

- NETWORK-02(상관관계가 없는 한 에포크당 1개의 네트워크 파라미터): maxTxExecutionUnits[memory]와 maxBlockExecutionUnits[memory]는 직접적인 상관관계를 가지며 본 안건에 의해 변경되는 유일한 네트워크 파라미터임.

- MTEU-M-01/02/03/04: 17,500,000은 40,000,000 상한선 미만이고, 양수이며, 이전 설정인 16,500,000보다 크고, 1,000,000 유닛 증가를 나타내며, 이는 에포크당 최대치인 2,500,000 유닛 이내임.

- MBEU-M-01/02/03/04a: 77,500,000은 120,000,000 상한선 미만이고, 양수이며, 5,500,000 유닛 증가를 나타내고, 이는 에포크당 최대치인 10,000,000 유닛 이내임.

- MEU-M-01: maxBlockExecutionUnits[memory]는 maxTxExecutionUnits[memory]보다 작지 않아야 하며 77,500,000은 17,500,000보다 현저히 큼.

- 결합된 가이드라인 참고: 본 안건은 minPoolCost(거버넌스 시스템에 핵심적, PARAM-05)를 maxBlockExecutionUnits[memory](블록체인 운영에 핵심적, PARAM-03a)와 함께 변경하므로 표준 DRep 투표 외에 SPO 투표를 유발함.

- 두 임계값 모두 특별다수제가 아닌 단순 과반수이며, SPO는 활성 블록 생성 지분의 50% 초과라는 집단적 지원으로 찬성해야 하고 보안 관련 파라미터 변경에 대한 온체인 곤잘레스(Conway) 제네시스 파라미터는 0.51(51%)로 설정됨.

- SPO들은 PARAM-05 자체의 요구사항이라기보다는 번들링의 결과로 minPoolCost를 포함하여 번들링된 안건 전체에 대해 투표함.

- DRep 임계값은 CIP-1694의 프로토콜 파라미터 그룹 규칙을 따르며, 안건이 여러 그룹에 걸쳐 있는 경우 두 그룹의 DRep 임계값 중 더 높은 값이 전체 안건에 적용됨.

- minPoolCost는 네트워크 파라미터가 아닌 경제/거버넌스 파라미터이므로 상관관계가 있는 메모리 제한 쌍과 함께 포함된다고 해서 여러 네트워크 파라미터의 번들링을 제한하는 NETWORK-02가 적용되지 않음.

- 복원 계획: minPoolCost는 보상 분배에만 영향을 미치고 블록 생성, 전파, 실행 제한과는 무관하므로 0으로 줄어들지 않은 이상 보안이나 성능 위험이 미미함.

- 모니터링을 통해 낮은 하한선을 악용하는 시빌 스타일 지분 단편화나 예상치 못한 트레저리 영향 등의 부작용이 발견되면 후속 안건을 통해 minPoolCost를 170 ₳로 복원할 수 있음.

- 그러나 minPoolCost는 풀이 인증서를 등록하거나 업데이트할 때만 강제되므로 온체인에 이미 있는 인증서에 소급 적용되지 않음.

- 결과적으로 하한선이 75 ₳인 동안 선언된 비용을 170 ₳ 미만으로 낮춘 SPO는 파라미터가 나중에 복원되더라도 170 ₳로 다시 올리도록 강제될 수 없으며 기존 등록은 다음에 새 인증서를 제출하기로 선택할 때까지 유효함.

- 따라서 복원은 새로운 풀 등록과 복원 후 자발적으로 재등록하는 풀에만 제한되며, DApp이나 스크립트 재작업을 강제하지 않음.

- Plutus 메모리 제한: 이 변경은 전반적인 네트워크 성능에 미치는 영향이 미미하거나 없으며 복원될 필요가 없을 것임.

- 후속 파라미터 업데이트 안건을 통해 maxTxExecutionUnits[memory]를 파트 1 이후 설정인 16,500,000으로, maxBlockExecutionUnits[memory]를 파트 1 이후 설정인 72,000,000으로 복원할 수 있으나 그렇게 하면 더 높은 제한을 활용해 온 DApp 개발자와 사용자에게 지장을 줄 수 있음.

- 둘 중 하나만 복원하면 단일 블록에 들어가는 전체 크기 Plutus 스크립트 트랜잭션 수가 변경되지만 해롭지는 않을 것임.

■ 주석
*RoS: 스테이킹 수익률(Return on Staking)
***Preview: 카르다노의 테스트넷 환경 중 하나