Plutus V3 Cost Model은 Chang#2 하드포크(프로토콜 버전 10) 이후 활성화될 새로운 Plutus primitives를 지원하기 위해 파라미터 업데이트 거버넌스 액션을 통해 업데이트될 예정임.

기존 Plutus 비용 모델 설정은 변경되지 않음.

이 새로운 primitives는 Chang 하드포크로 활성화된 프로토콜 버전 9에서는 활성화되지 않음[3].

Plutus 비용 모델은 Plutus 스크립트 실행에 필요한 자원(컴퓨팅 단계 및 메모리)을 예측하고 제어하기 위해 설계된 것으로, 네트워크 과부하 방지 및 실행 비용 예측 가능성을 제공함[1][4][5].

업데이트된 Plutus V3 비용 모델은 스크립트 실행에 필요한 CPU 및 메모리 자원에 따른 비용을 반영하여, 온체인 수수료 산정에 정확성을 높임[5].

---

**주석**
- *Primitives*: 프로그래밍 언어에서 기본 제공되는 연산자나 함수 등의 기본 구성 요소
- *Parameter Update governance action*: 블록체인 네트워크에서 프로토콜 파라미터를 변경하기 위한 거버넌스 절차
- *Hard fork*: 블록체인 프로토콜의 비호환성 업그레이드
- *Execution units*: 스크립트 실행에 필요한 CPU 및 메모리 단위
- *Plutus*: Cardano 블록체인에서 사용하는 스마트 계약 언어

Protocol Version 10 하드포크 이후, 12개의 새로운 Plutus primitives가 비트 연산과 암호화 작업을 위해 제공됨.

이 하드포크는 "Plomin" 하드포크로 불리며, 2024년 12월 11일에 메인넷에 적용될 예정임[1].

이 새로운 Plutus primitives는 CIP-0122, CIP-0123, CIP-0127에 정의되어 있으며, Chang#2 하드포크 이후 사용할 수 있도록 비용 모델 설정이 제공됨[2][4].

Chang#2 하드포크는 온체인 거버넌스를 완전하게 활성화하며, CIP-1694에 명시된 기능들을 지원함. 이로 인해 DRep 투표, 재무 출금, 헌법 기록 및 위원회 업데이트 등이 가능해짐[1][5].

Cardano 노드 버전 10.1.1 이상이 이 하드포크를 통과할 수 있으며, 10.1.4 버전은 DoS 공격 방어 기능도 포함하고 있음[3][5].

요약하면, Protocol Version 10 하드포크(Plomin)와 Chang#2 하드포크를 통해 12개의 새로운 Plutus primitives가 활성화되고, 이를 위한 비용 모델이 설정되어 비트 연산 및 암호화 작업에 활용 가능해졌음[1][2][4].

---

**주석**
- Plutus primitives: Cardano 스마트 컨트랙트 언어인 Plutus에서 제공하는 기본 함수 또는 연산 단위
- CIP: Cardano Improvement Proposal, Cardano 개선 제안서
- DRep: Delegated Representative, 위임 대표
- SPO: Stake Pool Operator, 스테이크 풀 운영자
- DoS: Denial of Service, 서비스 거부 공격

Plutus V3 비용 모델이 Chang #2 하드포크(프로토콜 버전 10) 이후 사용할 새로운 Plutus 원시 함수들을 지원하도록 파라미터 업데이트 거버넌스 액션을 통해 갱신될 예정임. 기존 Plutus 비용 모델 설정은 변경되지 않음. 새로운 원시 함수들은 프로토콜 버전 9(Chang 하드포크 적용 버전)에서는 활성화되지 않음.

기술 평가에 따르면, 이 변경사항은 2024년 10월 10일 Intersect의 파라미터 위원회에서 권고되었고, 2024년 10월 18일 Intersect 기술 운영 위원회에서 만장일치로 승인되었음.

기능적으로는 Chang#2 하드포크 이후 12개의 새로운 Plutus v3 원시 함수가 활성화되어 비트 연산과 암호학적 해싱 기능이 강화되고, 비트코인과 이더리움과의 상호운용성이 향상됨. 비용 모델은 기존 Plutus V3 비용 모델에 추가되는 형태로 변경되며, Plutus V1과 V2 비용 모델에는 변화가 없음.

보안 측면에서는 특별한 우려가 없으며, Chang#2 하드포크를 지원하는 새로운 원시 함수에 대한 보안 보고서가 제공될 예정임.

성능 면에서는 표준 벤치마킹 절차에 따라 비용 모델 설정이 이루어졌고, 최대 블록 및 트랜잭션 실행 단위 제한으로 인해 노드 성능에 영향이 없을 것으로 예상됨.

지속 가능성 측면에서 이번 업그레이드는 Plutus의 비트 연산 및 암호 기능을 확장하고 비트코인 및 이더리움과의 상호운용성을 개선함.

새로운 Plutus 원시 함수들은 세 가지 CIP(CIP-0122, CIP-0123, CIP-0127)에 정의되어 있음.

- CIP-0122: 비트 단위 논리 연산(AND, OR, XOR, 보수), 특정 위치 비트 읽기/쓰기, 바이트 복제 기능 포함
- CIP-0123: 비트 시프트, 회전, 설정된 비트 개수 세기(popcount), 첫 번째 설정 비트 찾기 기능 포함
- CIP-0127: RIPEMD-160 해싱 함수 추가로 비트코인 주소 및 트랜잭션 검증 가능, ECDSA 및 Schnorr 서명과 함께 비트코인 및 이더리움과의 상호운용성 강화

각 원시 함수는 CPU 및 메모리 단위 비용 모델을 가짐.

비용 모델 변경은 기존 Plutus V3 비용 모델에 추가되는 형태이며, Plutus V1과 V2 비용 모델에는 영향 없음.

거버넌스 가드레일(PCM-01, PCM-02, PCM-03)에 부합하며, 벤치마킹을 통한 비용 모델 설정, 새로운 원시 함수 도입에 따른 비용 모델 업데이트, 비용 값이 음수가 아님을 확인함.

필요시 기존 비용 모델로 되돌릴 수 있음.

추가 참고로, Chang #2 하드포크는 2024년 12월 20일경(epoch 529)부터 준비가 시작되어 2025년 1월 초부터 1월 말 사이에 최종 실행될 예정임(Plomin 하드포크로 명명됨)[1][3][5].

We propose to update the Plutus V3 Cost Model via a Parameter Update governance action to enable the new Plutus primitives that will be available following the Chang#2 hard fork (to Protocol Version 10). Existing Plutus cost model settings will not be changed. Note that the primitives will not be enabled in Protocol version 9 (as enabled by the Chang hard fork).

Following the hard fork to Protocol Version 10, 12 new Plutus primitives will be available for bitwise and cryptographic operations. This governance action provides cost model settings so that these primitives can be used following the Chang#2 hard fork.

We propose to update the Plutus V3 Cost Model via a Parameter Update governance action to enable the new Plutus primitives that will be available following the Chang #2 hard fork (to Protocol Version 10). Existing Plutus cost model settings will not be changed. Note that the new primitives will not be enabled in Protocol version 9 (as enabled by the Chang hard fork).

## Technical Evaluation

The changes described in this governance action have been recommended by Intersect’s Parameter Committee on 2024-10-10, as evidenced by [this post in the Cardano Forum](https://forum.cardano.org/t/oct-10-2024-voltaire-era-parameter-committee-intermediate-state/137361), and subsequently ratified unanimously by Intersect's Technical Steering Committee on 2024-10-18.

### Functionality

As described below, 12 new Plutus v3 primitives will be enabled following the Chang#2 hard fork. These will provide new bitwise and cryptographic hashing functions that have a variety of uses, and which will enhance interoperability with BitCoin and Ethereum. The revised Plutus v3 cost model will enable those new primitives. The changes are all additions to the existing Plutus V3 cost model. No changes will be made to the cost model values for any existing Plutus primitives or to the Plutus V1 and V2 cost nodels.
### Security

No specific security concerns are raised by this change. A security report will be provided for the new Plutus primitives to support the Chang#2 hard fork.

### Performance

In line with [Plutus benchmarking procedures](https://github.com/IntersectMBO/plutus/blob/master/plutus-core/cost-model/CostModelGeneration.md), [standard benchmarking has been undertaken on a reference machine](https://github.com/IntersectMBO/plutus/blob/master/plutus-core/cost-model/data/benching-conway.csv) to determine these cost model settings and to align them with existing Plutus primitives. Since Plutus script execution times and memory usage are bounded by `maxBlockExecutionUnits[steps/memory]` and `maxTxExecutionUnits[steps/memory]`, there will be no overall performance impact on the node from these new cost model settings.

### Sustainability

The upgrade provides new Plutus functionality that will enhance its bitwise and cryptographic capabilities and provide better interoperability with BitCoin and Ethereum.

## New Plutus Primitives that will be Enabled after the Chang#2 Hard Fork

The new Plutus primitives are defined in three CIPs: [CIP-0122](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0122), [CIP-0123](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0123) and [CIP-0127](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0127).

### CIP-0122
Bitwise operations, both over fixed-width and variable-width blocks of bits, have a range of uses, including data structures (especially succinct ones) and cryptography. Currently, operations on individual bits in Plutus Core are difficult, or outright impossible, while also keeping within the tight constraints required on-chain. While it is possible to some degree to work with individual bytes over BuiltinByteStrings, this isn't sufficient, or efficient, when bit manipulations are required.

The new Plutus primitives defined by CIP-0122 are:

- Bitwise logical AND, OR, XOR and complement;
- Reading a bit value at a given index;
- Setting bits value at given indices; and
- Replicating a byte a given number of times.

> ``
> andByteString, orByteString, xorByteString, complementByteString, readBit, writeBits, replicateByte
> ``

### CIP-0123
The new bitwise operations that are defined in CIP-0123 extend the set that is provided by CIP-0123 to provide a usefully 'complete' set of bitwise operations.

The new Plutus primitives defined by CIP-0123 are:

- Bit shifts and rotations
- Counting the number of set bits (popcount)
- Finding the first set bit

> ``
> shiftByteString,
> rotateByteString,
> countSetBits,
> findFirstSetBit
> ``

### CIP-0127
The integration of the ECDSA and Schnorr signatures over the secp256k1 curve into Plutus was a significant step towards interoperability with the Ethereum and Bitcoin ecosystems. However, full compatibility is still impossible due to the absence of the RIPEMD-160 hashing algorithm in the Plutus interpreter. This is a fundamental component of Bitcoin's cryptographic framework.

Adding RIPEMD-160 support to Plutus enhances the potential for cross-chain solutions between Cardano and Bitcoin blockchains and complements the set of primitives which are already available. It will allow for the verification of Bitcoin addresses and transactions on-chain. This addition also enables the verification of signed messages that identify the signer by the public key hash, which has not yet been witnessed on the Bitcoin blockchain.

The new Plutus primitive defined by CIP-0127 is:

- [RIPEMD-160 hashing](https://homes.esat.kuleuven.be/~bosselae/ripemd160/pdf/AB-9601/AB-9601.pdf)

> ``
> ripemd_160
> ``

Each of the new primitives has both CPU and memory unit cost models.

## Differences to the current Plutus cost model that will be enacted by this governance action.

The full difference from the current on-chain Plutus V3 cost model settings is shown below. These changes are all additions to the existing Plutus V3 cost model. There are no changes to the Plutus V1 or V2 cost models.

"andByteString": {
"cpu": {
"arguments": {
"intercept": 100181,
"slope1": 726,
"slope2": 719
},
"type": "linear_in_y_and_z"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_max_yz"
}
},
"orByteString": {
"cpu": {
"arguments": {
"intercept": 100181,
"slope1": 726,
"slope2": 719
},
"type": "linear_in_y_and_z"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_max_yz"
}
},
"xorByteString": {
"cpu": {
"arguments": {
"intercept": 100181,
"slope1": 726,
"slope2": 719
},
"type": "linear_in_y_and_z"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_max_yz"
}
},
"complementByteString": {
"cpu": {
"arguments": {
"intercept": 107878,
"slope": 680
},
"type": "linear_in_x"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_x"
}
},
"readBit": {
"cpu": {
"arguments": 95336,
"type": "constant_cost"
},
"memory": {
"arguments": 1,
"type": "constant_cost"
}
},
"writeBits": {
"cpu": {
"arguments": {
"intercept": 281145,
"slope": 18848
},
"type": "linear_in_y"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_x"
}
},
"replicateByte": {
"cpu": {
"arguments": {
"intercept": 180194,
"slope": 159
},
"type": "linear_in_x"
},
"memory": {
"arguments": {
"intercept": 1,
"slope": 1
},
"type": "linear_in_x"
}
},
"shiftByteString": {
"cpu": {
"arguments": {
"intercept": 158519,
"slope": 8942
},
"type": "linear_in_x"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_x"
}
},
"rotateByteString": {
"cpu": {
"arguments": {
"intercept": 159378,
"slope": 8813
},
"type": "linear_in_x"
},
"memory": {
"arguments": {
"intercept": 0,
"slope": 1
},
"type": "linear_in_x"
}
},
"countSetBits": {
"cpu": {
"arguments": {
"intercept": 107490,
"slope": 3298
},
"type": "linear_in_x"
},
"memory": {
"arguments": 1,
"type": "constant_cost"
}
},
"findFirstSetBit": {
"cpu": {
"arguments": {
"intercept": 106057,
"slope": 655
},
"type": "linear_in_x"
},
"memory": {
"arguments": 1,
"type": "constant_cost"
}
},
"ripemd_160": {
"cpu": {
"arguments": {
"intercept": 1964219,
"slope": 24520
},
"type": "linear_in_x"
},
"memory": {
"arguments": 3,
"type": "constant_cost"
}
}

## Consistency with Guardrails

The relevant guardrails in the Interim Constitution are:

- **PCM-01:** "Cost model values must be set by benchmarking on a reference architecture"
- **PCM-02:** "The cost model must be updated if new primitives are introduced or a new Plutus language version is added"
- **PCM-03:** "Cost model values should not be negative"

This governance action is consistent with all three guardrails. None of these guardrails can be checked by the automated guardrails script.

### Consistency with PCM-01

The new cost model settings have been validated by the IO Engineering Plutus Core developer team against the same reference machine and implementation as the existing mainnet Plutus cost model settings.

### Consistency with PCM-02

The cost model has been updated because new Plutus primitives will be introduced following the upgrade to Protocol Version 10.

### Consistency with PCM-03

None of the new cost model values is negative.

## Reversion Plan

The changes can be reversed if necessary by reinstating the current set of Plutus cost model values, omitting any settings for the new primitives.