Cardano 메인넷은 프로토콜 버전 10으로 업그레이드될 예정이며, 이 업그레이드는 "Plomin"이라는 하드포크를 통해 이루어짐.

업그레이드 후 주요 내용은 다음과 같음:

- 메인넷 프로토콜이 Major Version 10, Minor Version 0으로 변경됨.
- CIP-1694에 명시된 7가지 거버넌스 액션이 모두 활성화됨.
- DRep(Delegated Representatives) 투표가 모든 7가지 거버넌스 액션에 적용됨.
- SPO(Stake Pool Operators) 투표가 CIP-1694에 정의된 해당 거버넌스 액션에 적용됨.
- 헌법위원회(Constitutional Committee) 투표도 CIP-1694에 정의된 해당 거버넌스 액션에 적용됨.
- 스테이킹 보상은 평소처럼 누적 가능하지만, DRep에 위임(사전 정의된 기권/불신임 옵션 포함)한 후에만 인출 가능함.
- 여러 새로운 Plutus 프리미티브가 추가됨.

임시 Cardano 헌법에 따른 조건:

- Chang 하드포크 이후 90일 이상 경과해야 함.
- 최소 85%의 스테이크 풀들이 프로토콜 버전 10을 지원하는 노드 버전으로 업그레이드되어야 함.

이 조건들은 임시 헌법위원회와 SPO들이 Intersect의 하드포크 워킹 그룹의 준비 보고서를 바탕으로 검증함[1][2][3][4].

Plomin 하드포크는 2025년 1월 29일 21:45 UTC에 온체인으로 시행되었으며, 이는 Cardano가 완전한 커뮤니티 거버넌스로 전환한 중요한 이정표임.

이 하드포크는 중앙 권한 없이 커뮤니티가 직접 결정, 승인, 시행한 최초의 블록체인 하드포크로, 모든 에이다(₳) 보유자가 거버넌스 액션을 제안하고 투표할 수 있는 체계를 완성했음.

Plomin 하드포크는 Chang 업그레이드의 두 번째 단계로, 에이다 보유자들이 DRep에 투표권을 위임하여 네트워크 거버넌스에 참여할 수 있도록 함으로써 완전한 탈중앙화를 실현했음[1][2][3][4].

---

**주석**

- CIP-1694: Cardano Improvement Proposal 1694, 거버넌스 관련 규정 문서
- DRep: Delegated Representatives, 에이다 보유자로부터 투표권을 위임받은 대표자
- SPO: Stake Pool Operators, 스테이크 풀 운영자
- Plutus primitives: Cardano 스마트 컨트랙트 언어인 Plutus에서 사용하는 기본 함수 및 명령어
- 하드포크(Hard Fork): 블록체인 프로토콜의 비가역적 업그레이드

프로토콜 버전 10은 CIP-1694의 남은 기능을 모두 활성화하여 DRep(Delegated Representative)가 모든 거버넌스 액션에 참여하여 투표할 수 있도록 했음.

이 버전에서는 기존 프로토콜 버전 9에서 Chang 하드포크로 활성화된 3가지 거버넌스 액션(하드포크, 파라미터 업데이트, 정보 액션) 외에, 추가로 4가지 거버넌스 액션을 지원함.

새로 지원되는 거버넌스 액션은 트레저리(국고) 출금, 새로운 헌법 기록, 헌법 위원회 업데이트, 불신임 투표임.

Chang 하드포크 이후, 프로토콜은 CIP-0122, CIP-0123, CIP-0127에 정의된 새로운 Plutus 프리미티브도 지원함.

이 Plutus 프리미티브는 바이트 스트링에 대한 비트 연산, 논리 연산, 그리고 비트코인과의 호환성을 위한 RIPEMD-160 암호화 해시 기능을 제공함.

---

**주석**
DRep: Delegated Representative, 거버넌스 권한을 위임받은 대표자
Plutus 프리미티브: 에이다 스마트 계약 언어 Plutus에서 사용되는 기본 연산 기능
RIPEMD-160: 160비트 해시 함수로, 비트코인 주소 생성에 사용됨
CIP: Cardano Improvement Proposal, 에이다 개선 제안서
트레저리: 에이다 블록체인 내 국고(자금 풀)
거버넌스 액션: 블록체인 운영 규칙 변경을 위한 공식 제안 및 투표 절차
하드포크: 이전 버전과 호환되지 않는 프로토콜 업그레이드
파라미터 업데이트: 블록체인 운영 파라미터(예: 수수료, 슬롯 시간 등) 변경
정보 액션: 공식 정보 공개용 거버넌스 액션

Cardano 메인넷은 프로토콜 버전 10으로 업그레이드되며, 이 업그레이드는 "Plomin" 하드포크를 통해 이루어짐.

업그레이드 후 주요 내용은 다음과 같음:

- 메인넷 프로토콜이 Major Version 10, Minor Version 0으로 변경됨.
- CIP-1694에 명시된 7가지 거버넌스 액션이 모두 활성화됨.
- DRep(Delegated Representatives) 투표가 모든 7가지 거버넌스 액션에 대해 가능해짐.
- SPO(Stake Pool Operators) 투표가 CIP-1694에 정의된 해당 거버넌스 액션에 대해 가능해짐.
- 헌법위원회 투표도 해당 거버넌스 액션에 대해 가능해짐.
- 스테이킹 보상은 평소처럼 누적되지만, DRep에 위임한 경우에만 인출 가능함(사전 정의된 기권/불신임 옵션 포함).
- 새로운 Plutus 원시 함수들이 추가됨.

임시 카르다노 헌법에 따라, 다음 조건을 충족해야 함:

- Chang 하드포크 이후 90일 이상 경과.
- 최소 85%의 스테이크 풀들이 프로토콜 버전 10을 지원하는 노드 버전으로 업그레이드 완료.

이 조건들은 임시 헌법위원회와 SPO들이 검증하며, Intersect의 하드포크 워킹 그룹의 준비 보고서가 지원함.

기술 평가 결과:

- 기존 기능에 대한 동작 저하 없음.
- CIP-1694 기능과 노드 구현 간 일치 확인.
- 새로운 Plutus 원시 함수 정상 작동 확인.
- 보안 감사 완료(Agda로 작성된 CIP-1694 명세 및 Haskell 구현).
- 성능 테스트에서 이전 버전 대비 저하 없음.
- 지속 가능성 측면에서 거버넌스 기능 강화 및 비트코인, 이더리움과의 상호운용성 향상에 기여함.

새로운 기능:

- DRep는 모든 7가지 거버넌스 액션에 투표 가능(기존에는 정보 액션에만 제한됨).
- 4가지 신규 거버넌스 액션 추가: 국고 인출, 새 헌법/가드레일 스크립트 제안, 헌법위원회 구성 변경, 불신임 투표.
- 보상 인출은 DRep에 위임한 경우에만 가능하며, SPO 투표 기본값은 'No'이나 기권 또는 불신임으로 변경 가능.

새로운 Plutus 원시 함수는 CIP-0122, CIP-0123, CIP-0127에 정의됨:

- CIP-0122: 비트 단위 논리 연산(AND, OR, XOR, 보수), 비트 읽기/쓰기, 바이트 복제 등.
- CIP-0123: 비트 시프트, 회전, 설정된 비트 개수 세기, 첫 번째 설정 비트 찾기.
- CIP-0127: RIPEMD-160 해싱 지원 추가로 비트코인 주소 및 트랜잭션 검증 가능.

가드레일 규정과 일치하며, 주요 프로토콜 버전 변경, 최소 85% 스테이크 풀 업그레이드, 90일 경과 조건 등 모두 충족함.

Plomin 하드포크는 2025년 1월 24일 승인되어 1월 29일 21:45 UTC에 온체인으로 시행됨.

이 하드포크는 Cardano가 완전한 커뮤니티 거버넌스로 전환하는 중요한 이정표이며, 모든 ADA 보유자가 직접 또는 DRep를 통해 거버넌스에 참여할 수 있게 함.

재버전 계획은 극단적 상황에서 CIP-0135에 명시된 재난 복구 절차를 통해서만 가능함[1][2][3][4].

---

**주석**
- DRep: Delegated Representatives, 위임 대표자
- SPO: Stake Pool Operators, 스테이크 풀 운영자
- CIP: Cardano Improvement Proposal, 카르다노 개선 제안
- Plutus: Cardano 스마트 컨트랙트 플랫폼
- RIPEMD-160: 비트코인 주소 생성에 사용되는 해시 알고리즘
- 하드포크: 블록체인 프로토콜의 비호환성 업그레이드

We propose to upgrade Cardano mainnet to Protocol Version 10. This upgrade will be achieved via a Hard Fork (called "Plomin"). Following the upgrade:

1. The Cardano mainnet protocol will be upgraded to Major Version 10 and Minor Version 0;
2. All 7 governance actions that are described in CIP-1694 will be enabled;
3. DRep voting will be enabled on all 7 governance actions;
4. SPO voting will be enabled on all applicable governance actions, as defined in CIP-1694;
5. Constitutional Committee voting will be enabled on all applicable governance actions, also as defined in CIP-1694;
6. Staking rewards can be accumulated as usual, but can only be withdrawn following delegation to a DRep (including the pre-defined abstain/no-confidence options);
7. Several new Plutus primitives will be available.

In line with the Interim Cardano Constitution:

1. More than 90 days will have elapsed from the date of the Chang hard fork before ratification of this governance action;
2. At least 85% of stake pools by stake should have upgraded to a version of the node that can support protocol version 10 before ratification of this governance action.

These conditions will be verified by the Interim Constitutional Committee and SPOs, supported by readiness reports from Intersect's Hard Fork Working Group.

Protocol Version 10 enables the remainder of the CIP-1694 functionality, ensuring that DReps can participate in voting on all governance actions. It enables treasury withdrawals, the ability to record a new constitution, updates to the constitutional committee, and votes of no confidence. These are in addition to the 3 existing governance actions that were enabled for Protocol Version 9 by the Chang hard fork (hard forks, parameter updates, and info actions).

Following the hard fork, the protocol will support a number of new Plutus primitives that have been defined in CIP-0122, CIP-0123 and CIP-0127. These provide bitwise and logical operations on byte strings, plus RIPEMD-160 cryptographic hashing functionality (for compatibility with BitCoin).

We propose to upgrade Cardano mainnet to Protocol Version 10. This upgrade will be achieved via a Hard Fork (called "Plomin"). Following the upgrade:

1. The Cardano mainnet protocol will be upgraded to Major Version 10 and Minor Version 0;
2. All 7 governance actions that are described in CIP-1694 will be enabled;
3. DRep voting will be enabled on all 7 governance actions;
4. SPO voting will be enabled on all applicable governance actions, as defined in CIP-1694;
5. Constitutional Committee voting will be enabled on all applicable governance actions, also as defined in CIP-1694;
6. Staking rewards can be accumulated as usual, but can only be withdrawn following delegation to a DRep (including the pre-defined abstain/no-confidence options);
7. Several new Plutus primitives will be available.

In line with the Interim Cardano Constitution:

1. More than 90 days will have elapsed from the date of the Chang hard fork before ratification of this governance action;
2. At least 85% of stake pools by stake should have upgraded to a version of the node that can support protocol version 10 before ratification of this governance action.

These conditions will be verified by the Interim Constitutional Committee and SPOs, supported by readiness reports from Intersect's Hard Fork Working Group.

## Technical Evaluation

The submission of this governance action has been recommended by Intersect’s Hard Fork Working Group on 2024-12-10, and subsequently ratified by Intersect's Technical Steering Committee on 2024-12-11, as evidenced by [these minutes](https://app.gitbook.com/o/Prbm1mtkwSsGWSvG1Bfd/s/Yzy77cQuAEYNjeNy3YrN/about/tsc-meeting-minutes/tsc-decisions-log).

To support voting decisions by the Interim Constitutional Committee and SPOs, the Hard Fork Working Group will maintain a readiness report that will report on key metrics, including SPO, Exchange, DApp and voter readiness for the hard fork. This can be used to inform risk management.

### Functionality

The upgrade enables two main items:

1. The remainder of the CIP-1694 functionality, as described below - notably: DRep voting on all action types, the remaining governance actions, and restrictions on rewards withdrawals.
2. New Plutus primitives as described below.

Otherwise, all existing functionality from Protocol Version 9 will be maintained.

Full testing reports have been produced for the Cardano node that demonstrate:

1. No behavioral regressions for existing functionality;
2. Conformance between the specification and implementation of the Cardano node for the new CIP-1694 functionality;
3. Correct operation of the new Plutus primitives.

### Security

Security audits have been undertaken for:

1. The formal specification for CIP-1694 in Agda;
2. The ledger implementation in Haskell that corresponds to this formal specification.

### Performance

[Performance results for Cardano Node version 10.1.1](https://updates.cardano.intersectmbo.org/reports/2024-10-performance-10.1.1/) show no regressions from previous versions of the Cardano node for the standard value and Plutus benchmarks, and acceptable baseline performance for the new voting benchmark.

### Sustainability

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

## New Functionality that will be enabled by the Upgrade

### DRep Voting Changes following the Upgrade

DReps will be able to vote on all 7 types of governance action, as described in CIP-1694, and will no longer be restricted to voting on Info actions.

### New Governance Actions that will be Available following the Upgrade

Four new governance actions will be enabled as described in CIP-1694.

1. Treasury withdrawals. Funds may be withdrawn from the treasury and deposited in designated stake credentials.
2. New constitution/guardrails script. A new constitution may be proposed and/or a new guardrails script may be proposed.
3. Updates to the constitutional committee. Constitutional committee members may be removed, replaced, or new members may be elected. The threshold for Constitutional committee voting may also be changed.
4. Votes of no confidence. A vote of no confidence may be raised.

### Other Governance Changes following the Upgrade

The main other governance changes in Protocol Version 10 are:

1. Rewards will still be accumulated by Ada holders when delegating to stake pools for block production as in Protocol Version 9 and before, but these rewards can only be withdrawn once the Ada holder has also delegated their stake to a DRep for voting purposes. This vote delegation may be to a self-created DRep, to a third-party DRep, or to the pre-defined Abstain or No Confidence DReps.
2. SPO votes will default to **No**. It will be possible for SPOs to default to **Abstain** or **No Confidence** by delegating their reward address to the pre-defined DRep.

## New Plutus Primitives that will be Enabled after the Plomin 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). A separate protocol parameter update governance action has already been enacted on Cardano mainnet that updates the Plutus cost model so that these primitives will become available immediately after the Plomin Hard Fork.

### 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-0122 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
> ``

## Consistency with Guardrails

The text of the guardrails states:

*“The hard fork initiation action requires both a new major and a new minor protocol version to be specified as positive integers. As the result of a hard fork, new updatable protocol parameters may be introduced. Guardrails may be defined for these parameters, which will take effect following the hard fork. Existing updatable protocol parameters may also be deprecated by the hard fork, in which case the guardrails become obsolete for all future changes.”*

All these conditions apply to this proposal. The upgrade will have major protocol version 10 and minor protocol version 0. No new updatable parameters will be introduced or deprecated.

The relevant guardrails in the Interim Constitution are:

* **HARDFORK-01:** “The major protocol version must be the same as or one greater than the major version that will be enacted immediately prior to this change. If the major protocol version is one greater, then the minor protocol version must be zero.”
* **HARDFORK-02:** “The minor protocol version must be no less than the minor version that will be enacted immediately prior to this change.”
* **HARDFORK-03:** “At least one of the protocol versions (major or minor or both) must change.”
* **HARDFORK-04** “At least 85% of stake pools by active stake should have upgraded to a Cardano node version that is capable of processing the rules associated with the new protocol version.”
* **HARDFORK-05** “Any new updatable protocol parameters that are introduced with a hard fork must be included in this Appendix and suitable guardrails defined for those parameters.”
* **HARDFORK-06:** “Settings for any new protocol parameters that are introduced with a hard fork must be included in the appropriate Genesis file.”
* **HARDFORK-07:** “Any deprecated protocol parameters must be indicated in this Appendix.”
* **HARDFORK-08:** “New Plutus versions must be supported by a version-specific Plutus cost model that covers each primitive that is available in the new Plutus version.”
* **INTERIM-01**: “To provide sufficient time for DReps to register and campaign and for Ada holders to choose their initial voting delegations, at least 18 epochs (90 days, or approximately 3 months) must elapse after the Chang hard fork before the subsequent hard fork can be ratified. Once the subsequent hard fork is enacted, DRep voting can occur as described in CIP-1694.”

This governance action is consistent with all nine guardrails, provided attention is paid to HARDFORK-04, as described below. None of these guardrails can be checked by the automated guardrails script.

### Consistency with HARDFORK-01:

The protocol version will be changed from major version 9 (minor version 0) to major version 10 (minor version 0).

### Consistency with HARDFORK-02:

The minor protocol version will be unchanged (0 in both cases).

### Consistency with HARDFORK-03:

The major protocol version will change from 9 to 10.

### Consistency with HARDFORK-04:

The stake pool upgrade status will need to be determined prior to ratification of the governance action. If insufficient stake pools by stake have been upgraded, the action should not be ratified.

### Consistency with HARDFORK-05:

No new updatable protocol parameters will be introduced by this hard fork, so the guardrails do not need to be updated.

### Consistency with HARDFORK-06:

No new protocol parameters will be introduced by this hard fork, so a new Genesis file is not needed.

### Consistency with HARDFORK-07:

No protocol parameters are deprecated by this hard fork.

### Consistency with HARDFORK-08:

No new Plutus version is introduced. The new Plutus primitives are provided as part of Plutus v3.

### Consistency with INTERIM-01:

The Chang hard fork took place on September 1st, 2024. More than 90 days will have elapsed prior to the submission of this governance action.

## Reversion Plan

The hard fork represents a permanent change to the on-chain ledger rules. Reversion is only possible in extreme circumstances, using the disaster recovery process that is described in [CIP-0135](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0135/README.md).