CIP-1694 (Korean Ver.)

한국어 Cardano 프로젝트
, , , ,
1

CIP-1694

번역: Oscar Hong(Translated by Oscar Hong)

CIP 1694 - 볼테르를 위한 온체인 탈중앙화 거버넌스 메커니즘(An On-Chain Decentralized Governance Mechanism for Voltaire)

Abstract: 저희는 볼테르에 대한 새로운 요구 사항들을 지원하기 위해 카르다노의 온체인 거버넌스 시스템 개정을 제안합니다. 프로토콜 매개변수 업데이트 및 MIR 인증서에 대한 기존의 특정 거버넌스 지원 기능은 더 이상 사용되지 않으며, 일반 트랜잭션 바디(Transaction bodies)에 거버넌스 활동(Governance action), 투표(Vote)라는 두 가지 새로운 필드가 추가될 것입니다.

Abstract

카르다노의 온체인 거버넌스 시스템을 개정하여 볼테르의 새로운 요구 사항을 지원하는 것을 제안합니다. 프로토콜 매개 변수 업데이트 및 MIR 인증서에 대한 기존 전문 거버넌스 지원은 제거되며, 일반 트랜잭션 바디(Transaction bodies)에 두 개의 새로운 필드가 추가됩니다.

  1. 거버넌스 액션(Governance actions)

  2. 투표(Votes)

카르다노 유저는 누구든지 거버넌스 액션을 제출할 수 있습니다. 우리는 거버넌스 프레임워크에서 다른 기능을 수행하는 세 가지 구별된 거버넌스 바디(Governance bodies)를 소개합니다.

  1. 헌법 위원회(a constitutional committee)

  2. 위임자 대표 그룹 (a group of delegate representatives - 이하 DReps라고 함)

  3. 스테이크 풀 운영자 (the stake pool operators - 이하 SPOs라고 함)

모든 거버넌스 액션은 이들 세 거버넌스 바디 중 두 개의 바디에서 투표를 통해 승인해야 합니다. 거버넌스 액션의 유형과 거버넌스 시스템의 상태에 따라 어떤 바디가 승인해야 하는지가 결정됩니다. 승인된 거버넌스 액션은 구체적인 규칙에 따라 온체인에서 시행될 수 있습니다.

스테이크 풀과 마찬가지로, 모든 Ada 소지자는 DRep이 될 수 있으며, 자신 및/또는 다른 사람을 대표하도록 선택할 수 있습니다. 또한, 스테이크 풀과 마찬가지로, 그들은 등록된 다른 DRep에게 투표 권한을 위임할 수 있습니다. 이러한 투표 권한은 Lovelace의 전체 수로 매겨집니다.

이 제안의 가장 중요한 측면은 ”one Lovelace = 1개의 투표권"이라는 개념입니다.

Acknowledgements

첫 번째 초안

2022년 11월에 게시된 이 문서의 초안에 대해 많은 사람들이 의견을 제시하고 기여했습니다. 특히 지혜와 통찰력을 제공해 주신 아래 기재된 분들께 감사의 말씀을 전합니다:

  • Jack Briggs

  • Tim Harrison

  • Philip Lazos

  • Michael Madoff

  • Evangelos Markakis

  • Joel Telpner

  • Thomas Upfield

또한 Github 및 기타 채널을 통해 의견을 제시한 모든 분들께 감사의 말씀을 드립니다.

2023 Colorado Workshop

또한, 2023년 2월 28일과 3월 1일에 개최된 워크숍의 모든 참석자분들께 이번 CIP에 귀중한 기여를 해주시고 카르다노의 비전을 적극적으로 지지해주신 것에 대해 감사의 말씀을 전합니다. 여기에는 다음과 같은 분들이 포함됩니다:

  • Adam Rusch, ADAO & Summon

  • Addie Girouard

  • Andrew Westberg

  • Darlington Wleh, LidoNation

  • Eystein Hansen

  • James Dunseith, Gimbalabs

  • Juana Attieh

  • Kenric Nelson

  • Lloyd Duhon, DripDropz

  • Marcus Jay Allen

  • Marek Mahut, 5 Binaries

  • Markus Gufler

  • Matthew Capps

  • Mercy, Wanda

  • Michael Dogali

  • Michael Madoff

  • Patrick Tobler, NMKR

  • Philip Lazos

  • π Lanningham, SundaeSwap

  • Rick McCracken

  • Romain Pellerin

  • Sergio Sanchez Ferreros

  • Tim Harrison

  • Tsz Wai Wu

Motivation: 이 CIP가 필요한 이유는 무엇인가

  • 목표

  • 현재 설계

  • 셸리 거버넌스 설계의 단점

  • 그외(Out of Scope)

목표

저희는 탈중앙화된 의사결정의 토대를 마련하는 볼테르 시대로 향하고 있습니다. CIP1694는 카르다노의 마지막 로드맵 볼테르 단계를 뒷받침할 수 있는 온체인 거버넌스 메커니즘에 대해 설명합니다. 이 문서는 고정된 수의 거버넌스 키를 기반으로 했던 기존 카르다노 거버넌스 체계를 기반으로 하며 이를 확장합니다. 이는 제안된 볼테르 거버넌스 시스템의 일부로서 가치 있고, 중요한 것은 기술적으로 단기간에 달성할 수 있는 첫 번째 단계를 제공하는 것을 목표로 합니다.

또한 적절한 임계값 설정 및 기타 온체인 설정을 포함하여 커뮤니티의 의견을 지속적으로 수렴할 수 있는 출발점 역할을 하려고 합니다. 후속 제안은 새로운 거버넌스 요구 사항을 충족하기 위해 이 제안을 수정하고 확장할 수 있습니다.

현재 설계

셸리(Shelly) 원장 시대에 도입된 온체인 카르다노 거버넌스 메커니즘은 다음과 같은 기능을 수행할 수 있습니다.

  1. 프로토콜 매개변수 값 수정 [“하드 포크(Hard Fork)" 시작 포함]

  2. 준비금과 재무부에서 에이다(ada)를 이전 (또한 준비금과 재무부 간에 에이다를 이동)

현재 체계에서 거버넌스 작업은 거버넌스 키의 정족수의 다수(Quorum-Many)인 거버넌스 키의 승인(카르다노 메인넷의 경우 7개 중 5개)이 필요한 특수한 트랜잭션에 의해 시작됩니다. 트랜잭션 본문(Body)의 필드는 프로토콜 매개변수 변경 또는 자금 이체 시작 등 제안된 거버넌스 작업에 대한 세부 정보를 제공합니다. 각 트랜잭션은 정확히 한 가지 종류의 거버넌스 작업을 트리거할 수 있지만, 단일 작업은 두 개 이상의 프로토콜 매개변수를 변경하는 등 두 가지 이상의 효과를 가져올 수 있습니다.

  • 프로토콜 매개변수 업데이트는 트랜잭션 바디에 트랜잭션 필드 nº6 을 사용합니다.

  • 재무부 및 준비금의 이동은 Move Instantaneous Rewards(MIR) 인증서를 사용합니다.

적절하게 승인된 거버넌스 조치는 시대(Epoch) 경계에 따라 적용됩니다. (제정됨)

하드포크

프로토콜 매개변수 중 하나는 특별한 주의를 필요로 합니다: 메이저 프로토콜 버전을 변경함으로써, 카르다노는 제어된 하드포크를 실행할 수 있습니다. 이러한 종류의 프로토콜 매개변수 업데이트는 하드포크가 발생한 후에 스테이크 풀(Stake Pool)이 새로운 프로토콜 버전을 지원하기 위해 노드 버전을 업그레이드 해야하기 때문에 특별한 상태를 가지고 있습니다.

셸리(Shelly) 거버넌스 설계의 단점

현재의 디자인은 거버넌스에 대한 단순하고 과도기적인 접근 방식을 제공하기 위한 것이었습니다. 이 제안은 볼테르로 전환하면서 드러난 셸리 거버넌스 설계의 여러 가지 단점을 해결하기 위한 방법을 제시합니다.

  1. 셸리 거버넌스 설계는 에이다(ada) 보유자들의 적극적인 온체인 참여의 유인을 제공하지 않습니다. 프로토콜 변경은 일반적으로 일부 커뮤니티 기여자(Actors)들의 논의와 토론의 결과지만, 그 과정은 주로 창립 주체(Founding Entities)들에 기반하여 주도되었습니다. 모든 사람이 자신의 우려나 의사를 표명할 수 있도록 하는 것은 번거롭고 때때로 자의적인 것으로 인식될 수 있습니다.

  2. 재무부의 자금 이동은 매우 중요하고 민감한 주제입니다. 하지만 추적하기 어렵습니다. 이러한 자금 이동에 대해 더 많은 투명성과 더 많은 관리 체계를 갖추는 것이 중요합니다.

  3. 하드포크는 SPO의 특별한 취급이 필요하지만, 다른 프로토콜 매개변수 변경과 구분되지 않습니다.

  4. 마지막으로, 현재 카르다노의 창립 주체와 많은 커뮤니티 구성원이 공유하는 다소 공통된 비전이 있지만, 이러한 원칙이 기록된 명확하게 정의된 문서가 존재하지 않습니다. 카르다노 블록체인을 활용하여 공동의 카르다노 정신을 수정 불가능한 방식으로 공식적인 카르다노 헌법에 기록하는 것이 합리적입니다.

그 외(Out of scope)

다음 주제는 이 제안(CIP-1694)의 범위를 벗어난 것으로 간주됩니다.

*헌법의 내용(The contents of the constitution)

이 CIP는 온체인 메커니즘에만 초점을 맞춥니다. 초기 헌법의 조항은 매우 중요하며, 이를 수정할 수 있는 모든 절차도 마찬가지입니다. 이러한 부분은 별도의 집중적인 논의가 필요합니다.

*헌법 위원회의 구성(The membership of the constitutional committee)

이는 오프체인(Off-Chain) 이슈입니다.

*법적 문제(Legal issues)

카르다노 프로토콜이나 카르다노 헌법의 잠재적인 법적 집행 가능성은 이 CIP의 범위에서 완전히 벗어납니다.

*거버넌스 활동에 대한 오프체인 표준(Off chain standards for governance actions)

카르다노 커뮤니티는 이 CIP에 명시된 거버넌스 액션의 생성을 처리하기 위한 올바른 표준과 프로세스에 대해 면밀히 고려해야 합니다. 특히, 자금 인출(treasury withdrawal) 액션을 생성하는 데 있어 프로젝트 카탈리스트(Project Catalyst)의 역할은 이 CIP의 범위를 완전히 벗어납니다.

*에이다 보유 및 위임(Ada holdings and delegation)

민간 기업, 공공 또는 민간 기관, 개인 등이 스테이크 풀 또는 DRep에 위임하는 것을 포함하여 Ada를 보유하거나 위임하는 방법은 본 CIP의 범위를 벗어납니다.

Specification: 사양

  • 카르다노 헌법(The Cardano Constitution)

  • 헌법 위원회(The constitutional committee)

    • 불신임 상태(State of no-confidence)
    • 초기 위원회(Initial committee)
    • 위원회 교체(Replacing the committee)
    • 헌법 위원회의 규모(Size of the constitutional committee)
    • 임기 제한(Term limits)

  • 위임자 대표(Delegated representatives, DReps)

    • 사전 정의된 DRep(Pre-defined DReps)
    • 등록된 DRep(Registered DReps)
    • DRep을 위한 새로운 지분 분배(New stake distribution for DReps)
    • 투표 지분 위임에 대한 인센티브(Incentives to delegate voting stake)
    • DRep 인센티브(DReps incentives)

  • 거버넌스 액션(Governance actions)

    • 비준(Ratification)
      • 요구 사항(Requirements)
      • 제한 사항(Restrictions)
    • 제정(Enactment)
    • 수명 주기(Lifecycle)
    • 콘텐츠(Content)
    • 프로토콜 매개변수 그룹(Protocol parameters groups)

  • 투표(Votes)

    • 거버넌스 상태(Governance state)
    • 만료된 투표(Stale votes)
    • 지분 스냅샷 변경 사항(Changes to the stake snapshot)
    • 투표 지분에 관련된 정의(Definitions surrounding voting stake)

카르다노 헌법(The Cardano Constitution)

카르다노 헌법은 카르다노의 공통된 가치와 핵심 원칙을 정의하는 텍스트 문서입니다. 현 단계에서 헌법은 카르다노의 핵심 가치를 명확하게 담아내고 장기적인 지속 가능성을 보장하는 역할을 하는 정보 문서입니다. 이후 단계에서는 헌법이 전체 거버넌스 프레임워크를 주도하는 스마트 콘트랙트 기반 규칙으로 발전할 가능성을 상상해볼 수 있습니다. 그러나 현재로서는 헌법은 해시 다이제스트 값(Hash digest value)이 온체인에 기록되는 오프체인 문서로 존재할 것입니다. 위에서 설명한 바와 같이 헌법은 아직 정의되지 않았으며, 그 내용은 이 CIP의 범위를 벗어납니다.

헌법 위원회(The constitutional committee)

헌법 위원회는 헌법을 준수할 책임이 있는 개인 또는 단체(각각 한 쌍의 Ed25519 자격 증명과 연결되어 있음)를 대표하는 조직으로 정의할 수 있습니다.

온체인에서 강제할 수는 없지만, 헌법 위원회는 거버넌스 조치의 합헌성 여부에 대해서만 투표하도록 규정되어 있으며, 이 경계를 넘을 경우 (불신임 조치를 통해) 교체되어야 합니다. 다르게 말하면, 헌법 위원회와 네트워크의 행위자 사이에는 사회적 계약이 존재합니다. 헌법 위원회는 특정 거버넌스 조치를 거부할 수 있지만(불신임 투표를 통해), 해당 거버넌스 조치가 헌법에 위배되는 경우에만 그렇게 해야 합니다.

예를 들어, "카르다노 네트워크는 항상 새로운 블록을 생성할 수 있어야 한다"는 가상의 헌법 규칙을 고려한다면, 최대 블록 크기를 0으로 줄이는 거버넌스 조치는 사실상 위헌이므로 헌법 위원회의 비준을 받지 못할 수 있습니다. 그러나 규정에는 허용 가능한 최소 최대 블록 크기가 명시되어 있지 않으므로, 헌법 위원회에서 이 수치를 결정하고 그에 따라 투표해야 합니다.

*불신임 상태(State of no-confidence)

헌법위원회는 항상 다음 두 가지 상태 중 하나에 있는 것으로 간주됩니다:

  1. 신임 상태(a normal state - a state of confidence)

  2. 불신임 상태(a state of no-confidence)

‘불신임 상태’에서는 현 위원회가 더 이상 거버넌스 활동에 참여할 수 없으며, 모든 거버넌스 활동이 비준되기 전에 위원회가 교체되어야 합니다(아래 참조). 미결 상태인 거버넌스 조치는 프로토콜이 불신임 상태가 되는 즉시 중단되며, 제정되지 않습니다.

헌법 위원회는 기존의 “제네시스 위임 증명서(genesis delegation certificate)” 메커니즘과 유사한 핫키 및 콜드키 설정을 사용할 것입니다.

*초기 헌법 위원회(Initial constitutional committee)

초기 위원회는 아직 확정되지 않았습니다. 아마도 카르다노의 창립 주체 중 일부가 포함될 가능성이 높습니다.

*헌법 위원회 교체(Replacing the constitutional committee)

헌법위원회는 두 가지 방법 중 하나로 교체할 수 있습니다:

  • 정상 상태(즉, 신뢰 상태)일 경우, 현 헌법 위원회와 DRep의 승인을 모두 필요로 하는 특정 거버넌스 조치(아래 action 2 참고)를 통해 위원회를 교체할 수 있습니다.

  • 불신임 상태인 경우에도 동일한 거버넌스 조치(아래 action 2 참고)를 통해 위원회를 교체할 수 있지만, 이 경우 SPO와 DRep의 승인이 모두 필요합니다.

*헌법 위원회의 규모(Size of the constitutional committee)

셸리 거버넌스 설계와 달리, 헌법 위원회의 규모는 고정되어 있지 않습니다. 새로운 위원회가 선출될 때마다 규모가 변경될 수 있습니다(아래 action 2 참고). 마찬가지로 위원회 정족수(거버넌스 조치를 비준하는 데 필요한 위원회 찬성 투표 수)도 고정되어 있지 않으며 거버넌스 액션 2(Governance action 2)에 따라 달라질 수 있습니다. 이는 위원회 구성에 상당한 유연성을 제공합니다.

*임기 제한(Term limits)

헌법 위원회의 임기가 만료되면 시스템은 자동으로 불신임 상태에 들어갑니다. 이 제한은 거버넌스 프로토콜 매개변수로, 위원회가 거버넌스 조치를 비준할 수 있는 최대 기간 수를 지정합니다. 위원회 임기 기간이 만료되면 모든 거버넌스 조치가 중단되며 새로운 위원회를 선출해야 합니다.

동일한 위원회가 재선출되고 정족수가 변경되지 않더라도 거버넌스 액션 2(Governance action 2)가 제정될 때마다 임기 제한은 재설정됩니다. 이를 통해 에이다 보유자는 원한다면 위원회에 대한 재신임을 확인할 수 있습니다. 임기 제한은 위원회가 선출된 시점을 기준으로 계산된다는 점에 유의하세요. 기본 프로토콜 매개변수의 변경은 향후 위원회에 적용되는 임기에만 영향을 미칩니다.

위임자 대표(Delegated representatives, DReps)

주의. CIP-1694 DRep을 프로젝트 카탈리스트(Project Catalyst) DRep과 혼동해서는 안 됩니다.

*사전 정의된 DRep(Pre-defined DReps)

거버넌스에 참여하려면 각 지분 증명을 DRep에 위임해야 합니다. 일반적으로 에이다 보유자는 자신을 대신하여 투표할 등록된 DRep에 의결권을 위임합니다. 또한 사전 정의된 두 가지 DRep 옵션을 사용할 수 있습니다:

  • 기권(Abstain): Ada 보유자가 기권에 위임하는 경우, 해당 지분은 거버넌스에 참여하지 않는 것으로 표시됩니다. 체인에서 기권 위임의 효과는 위임된 지분이 활성 투표 지분의 일부로 간주되지 않는다는 것입니다. 그러나 해당 지분은 의결권 위임 인센티브(Incentives to delegate voting stake)에 설명된 인센티브의 목적으로 등록된 것으로 간주됩니다.

  • 불신임(No Confidence): 불신임에 위임하는 경우, 불신임 동의(action 1)를 제외한 모든 거버넌스 행동에 대해 해당 지분이 반대표로 계산됩니다. 이는 또한 기존 헌법 위원회를 신뢰하지 않는다는 의미이기도 합니다. 체인에 대한 불신임 위임의 효과는 이 지분이 활성 투표 지분의 일부로 간주된다는 것입니다. 모든 불신임 안건은 찬성 투표로, 그 외의 모든 안건은 반대 투표로 집계됩니다. 또한 헌법 위원회의 신뢰도를 직접 감사할 수 있는 지표로 사용될 수 있습니다.

참고. 모든 에이다 보유자는 투표에 적극적으로 참여하고자 하는 경우 자신의 지분 자격 증명을 DRep에 등록하고 자신에게 위임할 수 있습니다.

*등록된 DRep(Registered DReps)

볼테르에서는 기존 지분 증명도 등록된 DRep에 자신의 지분을 위임할 수 있게 됩니다. DRep 위임은 온체인 인증서를 통해 기존 지분 위임 메커니즘을 모방할 것입니다. 마찬가지로 DRep 등록 또한 기존의 지분 등록 메커니즘을 유사하게 적용할 것입니다.

등록된 DRep은 다음 중 하나에 해당하는 자격 증명으로 식별됩니다:

  • 인증 키(Ed25519)

  • 네이티브 또는 플루투스 스크립트

시리얼화된 DRep 자격 증명의 blake2b-224 해시 다이제스트를 DRep ID라고 합니다.

거버넌스를 위해 다음과 같은 새로운 유형의 인증서가 추가됩니다:

DRep 등록 인증서(DRep registration certificates) DRep 등록 인증서는 다음을 포함합니다:

  • DRep ID

  • Anchor

Anchor는 한 쌍의:

  • 메타데이터 JSON payload에 대한 URL

  • 메타데이터 URL의 컨텐츠에 대한 해시입니다.

이 메타데이터의 구조와 형식은 이 CIP에서 부분적으로 개방되어 있습니다. 온체인 규칙은 URL이나 해시를 확인하지 않습니다. 그러나 클라이언트 애플리케이션은 제공된 URL에서 콘텐츠를 가져올 때 통상적으로 유효성 검사를 수행해야 합니다.

DRep 만료 인증서(DRep retirement certificates) DRep 만료 인증서에는 다음이 포함됩니다:

  • DRep ID

  • DRep이 만료되는 에포크 번호

투표 위임 인증서(Vote delegation certificates)

투표 위임 인증서에는 다음이 포함됩니다:

  • 지분을 위임할 DRep ID

  • 위임자의 지분 자격증명

인증 체계(즉, 등록, 만료 또는 위임에 필요한 서명)는 기존 지분 위임 인증서 인증 체계를 기반으로 합니다.

*DRep을 위한 새로운 지분 분배(New stake distribution for DReps)

기존에 존재하는 지분 자격증명에 대한 지분 및 각 스테이크 풀에 대한 지분과 더불어 원장은 DRep별 지분 또한 정의합니다. 이 수치는 DRep의 각 찬성 투표가 보유한 지분의 양을 나타냅니다.

주의.

블록 생성에 사용되는 지분과 달리, 저희는 항상 에포크 경계에 주어진 DRep당 지분 수치의 가장 최신 버전을 사용할 것입니다.

즉, 개별 유권자가 깊은 관심을 가지고 있는 주제에 대해 DRep으로 등록하고 직접 투표할 수 있습니다. 그러나 이는 특정 에포크에서 블록 생성에 사용되는 지분과 투표에 사용되는 지분 사이에 차이가 있을 수 있음을 의미합니다.

*투표 지분 위임에 대한 인센티브(Incentives to delegate voting stake)

부트스트래핑 단계 이후, 리워드 계정은 관련 지분 자격 증명이 DRep에 위임되지 않는 한(사전 정의되거나 등록된 경우) 리워드 인출이 차단됩니다. 이는 높은 참여도와 합법성을 보장하는 데 도움이 됩니다.

*DRep 인센티브(DReps incentives)

DRep에게는 업무에 대한 보상이 필요한 것이 사실입니다. 인센티브 모델에 대한 연구는 아직 진행 중이며, 이 문제가 해결될 때까지 이 CIP의 시행을 보류하고 싶지는 않습니다.

따라서 저희의 임시 대안으로 현재 구축 중인 온체인 거버넌스 메커니즘을 통해 커뮤니티가 이러한 매우 중요한 결정에 동의할 때까지 기존 카르다노 재무부에서 Lovelace를 예탁하는 것입니다.

혹은, DRep은 이 CIP에 설명된 재무부 인출 조치(action 6)의 인스턴스를 통해 스스로 비용을 지급할 수도 있습니다. 이러한 조치는 온체인에서 감사할 수 있으며, DRep과 위임자 간의 오프체인 합의를 반영해야 합니다.

거버넌스 액션(Governance actions)

저희는 7가지 유형의 거버넌스 액션을 정의합니다. 거버넌스 액션은 트랜잭션에 의해 트리거되는 온체인 이벤트로, 기한이 있으며 그 이후에는 제정될 수 없습니다.

  • 아래 표에 자세히 설명된 규칙과 매개변수를 통해 충분한 찬성표를 모으면 액션이 비준되었다고 합니다.

  • 기한 내에 충분한 찬성 표를 얻지 못한 안건은 만료된 것으로 간주됩니다.

  • 비준이 완료된 안건은 네트워크에서 활성화되면 제정된 것으로 간주됩니다.

그러나 비준 여부와 관계없이, 불신임안이 발의되는 등의 경우 해당 안건은 비준되지 않고 기각될 수 있습니다.

Action 정의(Description)
1. 불신임 동의안(Motion of no-confidence) 현 헌법 위원회에 대한 불신임 결의안을 발의하는 동의안
2. 새로운 헌법 위원회 또는 정족수의 규모(New constitutional committee and/or quorum size) 새로운 헌법 위원회 구성원 또는 서명 정족수 규모에 대한 변경
3. 헌법 업데이트(Updates to the Constitution) 오프체인 헌법에 대한 수정으로, 텍스트 문서의 온체인 해시로 기록됨
4. 하드포크(Hard-Fork) 실행 네트워크의 이전 버전과 호환되지 않는 업그레이드를 트리거하며, 사전 소프트웨어 업그레이드가 필요합니다.
5. 프로토콜 매개변수 변경(Protocol Parameter Changes) 매개변수 변경 주요 프로토콜 버전(“하드포크”)에 대한 변경을 제외한 하나 이상의 업데이트 가능한 프로토콜 매개변수에 대한 모든 변경 사항
6. 재무부 인출(Treasury Withdrawals) (인출할 Lovelace의 양에 따라 소액, 중액 또는 대량 인출로 세분화된 재무부에서의 인출). 지갑 출금 한도는 아래에 설명되어 있습니다.
7. 정보(Info) 온체인 기록 외에는 온체인에 영향을 미치지 않는 작업입니다.

모든 에이다 보유자는 체인에 거버넌스 액션을 제출할 수 있습니다. 거버넌스 액션이 확정되면(비준, 철회, 만료 등) Lovelace 예치금을 반환받을 수 있습니다. 이 예치금은 스테이크 키 예치금과 마찬가지로 예치금 계좌에 추가됩니다.

불신임 동의안은 현재 헌법 위원회에 부여된 권한을 취소할 수 있는 극단적인 조치라는 점에 유의하시기 바랍니다. 불신임안이 통과되면 위원회가 비준한 사항이나 이번 회기에 제정될 사항을 포함해 미결된 모든 거버넌스 조치가 철회됩니다.

*비준(Ratification)

거버넌스 액션은 온체인 투표를 통해 비준됩니다. 거버넌스 활동의 종류에 따라 비준 요건이 다르지만, 항상 세 개의 거버넌스 기관 중 두 곳 이상의 기관이 참여해야 합니다. 따라서 거버넌스 액션의 유형에 따라 다음 사항이 모두 충족되면 액션이 비준됩니다:

  • 헌법 위원회가 해당 액션을 승인합니다(정족수-다수의 위원이 ‘예’ 투표).

  • DRep이 해당 액션을 승인합니다('예’에 투표한 디렙이 관리하는 지분이 등록된 총 투표 지분의 특정 임계값을 충족합니다).

  • SPO가 액션을 승인합니다('예’로 투표한 SPO가 관리하는 지분이 총 등록된 투표 지분의 특정 임계값을 충족합니다).

주의. 아래에 설명된 바와 같이 DRep과 SPO는 서로 다른 지분 분배 방식이 적용됩니다.

요구 사항(Requirements)

다음 표에서는 각 거버넌스 액션 시나리오에 대한 비준 요건을 자세히 설명합니다. 열은 다음을 나타냅니다:

  • 거버넌스 액션 유형(Governance action type): 거버넌스 액션의 유형입니다. 프로토콜 매개변수 업데이트는 세 가지 범주로 그룹화됩니다.

  • 헌법 위원회(Constitutional committee): 헌법 위원회(약어 CC) 의 ✓ 값은 정족수 이상의 헌법 위원회 위원의 ‘예’ 투표가 필요함을 나타냅니다. *값이 - 이면 헌법 위원회의 투표가 필요하지 않다는 것을 의미합니다.

  • 위임자 대표(DReps): 유효 투표 지분 수에 대한 백분율로 충족해야 하는 DRep 투표 임계값입니다. *값이 -이면 DReps 투표가 해당되지 않음을 의미합니다.

  • SPOs: 모든 스테이크 풀이 보유한 지분의 백분율로 충족해야 하는 SPO 투표 임계값입니다. *값이 -이면 SPO 투표가 해당되지 않음을 의미합니다.

Governance action type CC DReps SPOs
1. 불신임 동의안(Motion of no-confidence) - $P_1$ $Q_1$
2. 새로운 헌법 위원회 또는 정족수의 규모(New constitutional committee and/or quorum size): 정상 상태 ✓ $P_{2a}$ -
2. 새로운 헌법 위원회 또는 정족수의 규모(New constitutional committee and/or quorum size): 불신임 상태 - $P_{2b}$ $Q_{2b}$
3. 헌법 업데이트(Updates to the Constitution) ✓ $P_3$ -
4. 하드포크(Hard-Fork) 실행 ✓ $P_4$ $Q_4$
5. 프로토콜 매개변수 변경(Protocol Parameter Changes): Network group ✓ $P_{5a}$ -
5. 프로토콜 매개변수 변경(Protocol Parameter Changes): Economic group ✓ $P_{5b}$ -
5. 프로토콜 매개변수 변경(Protocol Parameter Changes): Technical group ✓ $P_{5c}$ -
5. 프로토콜 매개변수 변경(Protocol Parameter Changes): Governance group ✓ $P_{5d}$ -
6. 재무부 인출(Treasury Withdrawals) ✓ $P_6$ -
7. 정보(Info) ✓ $P_7$ -

주의. 자금 인출의 경우, 인출 한도는 해당 액션으로 인출된 Lovelace의 총 금액이며, 해당 액션이 두 개 이상의 인출을 지정하는 경우 단일 인출 금액이 아닙니다. 만약 인출 작업이 하나 이상의 인출을 지정한다면, 해당 작업에서 인출되는 각각의 금액이 아닌 총 인출 금액이 기준이 됩니다. 즉, 인출 작업이 여러 개의 인출을 지정하더라도 그 인출 작업에서 인출되는 총량이 한도를 넘어설 때에만 예외가 발생합니다.

이러한 각 임계값은 거버넌스 매개변수입니다. 초기 임계값은 카르다노 커뮤니티 차원에서 전체적으로 결정되어야 합니다.

참고. 투표를 위해 활성화된 Lovelace에 따라 임계값의 일부 또는 전부를 조정하는 것이 합리적일 수 있습니다. 예를 들어, 임계값은 등록 수준이 높은 경우 51%, 낮은 경우 75% 사이에서 조정될 수 있습니다. 또한, 출금 임계값은 출금되는 총 Lovelace에 따라 조정되거나 출금 수준에 따라 다른 임계값을 설정할 수도 있습니다.

제한 사항(Restrictions)

"재무부 인출(Treasury withdrawals)"과 “정보(Info)” 외에도, 우리는 같은 유형의 거버넌스(governance) 액션이 예기치 않은 방식으로 서로 충돌하지 않도록하는 메커니즘을 포함시켰습니다.

각 거버넌스 액션은 해당 유형의 이전 **거버넌스 액션 ID(governance action ID)**를 포함해야 합니다. 이는 같은 유형의 두 개의 액션이 동시에 실행될 수 있지만, 그렇게 되도록 일부러 디자인되어야 한다는 것을 의미합니다. 즉, 동일한 유형의 두 액션이 충돌하지 않도록 하기 위해 이전 거버넌스 액션 ID를 지정하여 현재 액션의 실행 가능 여부를 판단합니다.

*제정(Enactment)

현재 에포크(Epoch)에 비준된 법안은 다음과 같이 제정 우선순위가 정해집니다:

  1. 불신임 발의(Motion of no-confidence)

  2. 새로운 위원회/정족수(New committee/quorum)

  3. 헌법 업데이트(Updates to the Constitution)

  4. 하드포크 개시(Hard Fork initiation)

  5. 프로토콜 매개변수 변경(Protocol parameter changes)

  6. 재무부 인출(Treasury withdrawals)

  7. 정보(Info)

참고. 정보 작업은 프로토콜에 아무런 영향을 미치지 않기 때문에 온체인에 제정되지 않습니다.

불신임안(Motion of no-confidence)이 발의되어 새로운 헌법 위원회 선출 또는 헌법 변경이 성공할 경우 아직 제정되지 않은 다른 모든 거버넌스 액션(비준 여부와 관계없이)은 무효화되며, 해당 조치는 제정되지 않고 즉시 취하됩니다. 철회된 거버넌스 액션에 대한 예치금은 즉시 반환됩니다.

*수명 주기(Lifecycle)

거버넌스 액션은 에포크 경계에서만 비준 여부를 확인합니다. 비준이 완료된 거버넌스 액션은 제정을 위한 단계로 넘어갑니다.

따라서 제출된 모든 거버넌스 액션은 다음과 같이 처리됩니다:

  1. 비준 후 제정

  2. 비준되었지만 우선순위가 더 높은 조치로 인한 철회

  3. 여러 에포크를 거친 후 만료

예치금은 다음 중 하나에 해당하는 경우 즉시 반환됩니다:

  1. 비준된 거버넌스 액션의 제정

  2. 거버넌스 액션의 만료

  3. 비준된 거버넌스 액션의 철회(폐기)

일부 거버넌스 액션은 즉시(즉, 비준이 완료된 에포크와 동일한 에포크 경계에서) 발효되는 반면, 다른 거버넌스 액션은 다음 에포크 경계에서만 발효됩니다.

거버넌스 액션의 유형(Governance action type) 제정(Enactment)
1. 불신임 발의(Motion of no-confidence) Immediate
2. 새로운 위원회/정족수(New committee/quorum) Immediate
3. 헌법 업데이트(Update to the Constitution) Immediate
4. 하드포크 개시(Hard-fork initiation) Next epoch boundary
5. 프로토콜 매개변수 변경(Protocol parameter changes) Next epoch boundary
6. 재무부 인출(Treasury withdrawal) Immediate
7. 정보(Info) Immediate

*콘텐츠(Content)

모든 거버넌스 액션에는 다음이 포함됩니다:

  • 예치 금액(예치 금액은 업데이트 가능한 프로토콜 파라미터이므로 기록됨)

  • 예치금이 상환될 때 예치금을 받을 보상 주소(Reward address)

  • 액션을 정당화하는 데 필요한 메타데이터의 고정값

  • 동일한 유형의 상충하는 작업과의 충돌을 방지하기 위한 해시 다이제스트 값(앞서 설명한 대로)

또한 각 작업에는 해당 유형에 고유한 몇 가지 요소가 포함됩니다:

거버넌스 액션의 유형(Governance action type) 추가 데이터(Additional data)
1. 불신임 발의(Motion of no-confidence) 없음
2. 새로운 위원회/정족수(New committee/quorum) 인증 키 해시 다이제스트 및 쿼럼 번호(quorum number)
3. 헌법 업데이트(Update to the Constitution) 헌법 문서의 해시 다이제스트
4. 하드포크 개시(Hard-fork initiation) 새로운 (상위) 메인 프로토콜 버전
5. 프로토콜 매개변수 변경(Protocol parameter changes) 변경된 매개변수
6. 재무부 인출(Treasury withdrawal) 지분 자격 증명에서 양수 Lovelace의 매핑된 값
7. 정보(Info) -

승인된 각 거버넌스 액션에는 해당 액션을 생성한 트랜잭션 해시와 이를 가리키는 트랜잭션 본문(body) 내의 인덱스로 구성된 고유 식별자**(a.k.a 거버넌스 액션 ID)**가 할당됩니다.

*프로토콜 매개변수 그룹(Protocol parameters groups)

프로토콜 매개변수 변경 사항을 그룹화했습니다. 이를 통해 각 그룹마다 다른 임계값을 설정할 수 있으며, 별도의 투표도 지원합니다. DRep은 자신의 전문 분야를 벗어난 매개변수 변경에 대해서는 투표를 기권할 수 있습니다. 네트워크, 경제 및 기술 파라미터 그룹은 셸리(Shelley), 알론조(Alonzo), 베비지(Babbage) 시대(era)에 도입된 기존 프로토콜 매개변수를 수집합니다. 또한, CIP-1694에서 도입될 새로운 거버넌스 매개변수에 특화된 새로운 거버넌스 그룹을 도입했습니다.

**네트워크 그룹(network group)**은 다음으로 구성됩니다:

  • 최대 블록 본문(body) 크기(maxBBSize)

  • 최대 트랜잭션 크기(maxTxSize)

  • 최대 블록 헤더 크기(maxBHSize)

  • 풀 종료 최대 에포크(eMax)

  • 바람직한 풀 개수(nOpt)

  • 플루투스 실행 비용 모델(costModels)

  • 시리얼화된 자산 값의 최대 크기(maxValSize)

  • 담보 입력의 최대 개수(maxCollateralInputs)

  • 단일 트랜잭션의 최대 스크립트 실행 단위(maxTxExUnits)

  • 단일 블록의 최대 스크립트 실행 단위(maxBlockExUnits)

**경제 그룹(economic group)**은 다음으로 구성됩니다:

  • 최소 수수료 계수(minFeeA)

  • 최소 수수료 상수 (minFeeB)

  • 위임 키 Lovelace 보증금 (keyDeposit)

  • 풀 등록 러브레이스 예치금 (poolDeposit)

  • 통화 확충 (rho)

  • 재무부 확충 (tau)

  • 풀에 대한 최소 고정 보상 삭감 (minPoolCost)

  • 시리얼화된 UTxO의 바이트(byte)당 최소 Lovelace 예치금(coinsPerUTxOByte)

  • 플루투스 실행 단위 가격(prices)

  • 스크립트에 필요한 담보 비율 (collateralPercentage)

  • 풀 서약 영향력 (a0)

**기술 그룹(technical group)**은 다음과 같이 구성됩니다:

  • TODO: 위의 내용 중 일부는 여기에 해당합니다.

**거버넌스 그룹(governance group)**은 이번 CIP에 도입된 모든 새로운 프로토콜 매개변수로 구성됩니다:

  • 거버넌스 투표 임계값 (($P_1$, $P_{2a}$, $P_{2b}$, $P_3$, $P_4$, $P_{5a}$, $P_{5b}$, $P_{5c}$, $P_6$, $P_7$, $Q_1$, $Q_{2b}$, $Q_4$))

  • 헌법 위원회 임기 제한

  • 거버넌스 액션 만료

  • 거버넌스 액션 예치금(govDeposit)

  • DRep 예치금 규모(drepDeposit)

<TODO: 새로운 거버넌스 매개변수의 초기 값 결정 - 투표 임계값에 대한 일관된 조건을 결정해야 합니다. 예를 들어, 불신임 안건에 대한 임계값은 사소한 자금 인출에 대한 임계값보다 높아야 합니다.>

투표(Votes)

각 투표 트랜잭션은 다음으로 구성됩니다:

  • 거버넌스 액션 ID

  • 역할 - 헌법 위원, DRep 또는 SPO

  • 역할에 대한 거버넌스 자격 증명 증거

  • 투표와 관련된 정보를 위한 고정값(위에 정의된 대로)

  • 찬성/반대/기권 투표

SPO와 DRep의 경우, 투표(‘찬성’, ‘반대’ 또는 ‘기권’)의 수는 해당 안건의 비준 여부가 확인되는 시점에 위임된 Lovelace 수량에 비례합니다. 헌법 위원회의 경우, 각 위원은 한 표를 갖습니다.

주의. ‘기권’ 투표는 '활성 투표 지분’에 포함되지 않습니다.

기권에 대한 명시적 투표는 투표 자체를 기권하는 것과는 다릅니다(전자는 체인에 표시되지만, 후자는 표시되지 않습니다). 혼동을 피하기 위해 이 시점부터 '기권’이라는 단어는 온체인 투표를 기권한다는 의미로만 사용하겠습니다.

거버넌스 자격 증명(witness)은 기존 UTxOW 원장 규칙에 따라 원장에서 적절한 검증을 트리거합니다. 검증에는 검증키(signature key)에 대한 서명 검증과, 투표 리디머(vote redeemer) 및 스크립트의 새로운 플루투스 목적(new Plutus purpose)에 대한 유효성 검사가 포함됩니다.

하나의 자격 증명으로 각 거버넌스 액션에 대해 여러 번 투표할 수 있습니다. 올바르게 제출된 투표는 동일한 자격 증명 및 역할에 대한 이전 투표보다 우선합니다(액션이 비준되기 전에 새로운 투표를 제출하면 가장 최신 투표가 반영됨). 즉, 투표자는 원하는 경우 어떤 조치에 대한 자신의 입장을 변경할 수 있습니다. 거버넌스 조치가 비준되는 즉시 투표는 종료됩니다. 더 이상의 투표는 검토되거나 기록되지 않습니다(‘찬성’, ‘반대’ 또는 ‘기권’ 여부에 관계없이).

*거버넌스 상태(Governance state)

거버넌스 액션이 체인에 성공적으로 제출되면, 그 진행 상황은 원장 상태를 통해 추적됩니다. 특히 다음 사항이 추적됩니다:

  • 거버넌스 액션 ID (the governance action ID)

  • 액션이 만료되는 에포크 (the epoch that the action expires)

  • 예치금 금액 (the deposit amount)

  • 예치금이 반환될 때 예치금을 받을 리워드 주소

  • 해당 액션에 대한 헌법 위원회의 총 찬성/반대/기권 투표 수

  • 해당 조치에 대한 DRep의 총 찬성/반대/기권 투표 수

  • 해당 조치에 대한 SPO의 총 찬성/반대/기권 투표 수

*만료된 투표(Stale votes)

DRep과 SPO의 투표는 에포크 경계를 넘은 후 등록되지 않을 수 있으므로 무의미해질 수 있습니다. 따라서 등록되지 않은 모든 투표는 새로운 투표가 검토되기 전에 취소됩니다.

*지분 스냅샷 변경 사항(Changes to the stake snapshot)

각 에포크 경계에서 지분 스냅샷이 변경되므로, 비준되지 않은 각 거버넌스 액션의 비준 여부를 확인할 때 새로운 집계 결과를 계산해야 합니다. 즉, 투표 위임이 변경될 수 있기 때문에 DRep 또는 SPO 투표가 변경되지 않았더라도 액션이 제정될 수 있습니다.

*투표 지분에 관련된 정의(Definitions surrounding voting stake)

투표 지분과 관련된 여러 가지 새로운 조건을 정의합니다:

  • 트랜잭션 출력에 포함된 Lovelace는 다음과 같은 경우 투표가 활성화된 것으로 간주됩니다:

    • 등록된 지분 자격 증명이 포함되어 포함됩니다.
    • 등록된 지분 자격 증명은 등록된 DRep에 의결권을 위임합니다.

  • DRep(SPO) 투표 임계값이 어떤 백분율 P에 대해 충족되었다는 것은 거버넌스 액션에 대해 '찬성’으로 투표한 DRep(SPO)들에게 위임된 상대 지분의 합에서 '반대’로 투표한 DRep(SPO)들에게 위임된 상대 지분의 합을 뺀 결과가 적어도 P 이상인 경우를 말합니다. (특정 액션의 투표 임계값 = P, DRep(SPO) 찬성 지분의 합 - DRep(SPO) 반대 지분의 합 = ≥P → P에 대해 충족됨)

참고. “유통량에 대한 총 지분(the total stake in circulation)”에 대해 몇 가지 다른 정의가 있습니다. 아래를 참고하세요.

  1. UTxO와 리워드 계정의 합계

  2. UTxO, 리워드 계정, 수수료 팟(the fee pot), 예치금 팟(the deposit pot)의 합계

  3. 총 에이다(ada) 공급량(즉, 450억 에이다)에서 준비금(reserve)을 뺀 값

현재 단계에서는 이 부분에 대해 논의할 수 있도록 논의를 열어둘 예정

Rationale: 근거

  • 헌법 위원회의 역할(Role of the constitutional committee)

  • 사용자 본인 확인의 의도적 생략(Intentional omission of identity verification)

  • 다량의 에이다(ada)를 보유한 엔티티의 권한 감소(Reducing the power of entities with large amounts of Ada)

  • 스테이크 풀 지분 분배에 편승하는 행위(Piggybacking on stake pool stake distribution)

  • 표준 프로토콜 매개변수 변경으로 부터 하드포크 개시에 대한 분리(Separation of hard-fork initiation from standard protocol parameter changes)

  • 재무부 인출 vs 프로젝트 카탈리스트(Treasury withdrawals vs Project Catalyst)

  • DRep의 도입(The purpose of the DReps)

  • 비준 요건에 대한 표(Ratification requirements table)

  • 불신임 발의(Motion of no-confidence)

  • 새로운 위원회/정족수(불신임 상태) (New committee/quorum - state of no-confidence)

  • 다양한 정보(info) 거버넌스 액션의 활용성(The versatility of the info governance action)

  • 하드포크 개시(Hard-fork initiation)

  • 새로운 메타데이터 구조(New metadata structures)

  • 활성화된 거버넌스 액션의 수 제어(Controlling the number of active governance actions)

  • AVST 없음(No AVST)

헌법 위원회의 역할(Role of the constitutional committee)

언뜻 보기에 헌법 위원회는 DRep보다 더 많은 권한을 부여받은 특별 위원회처럼 보일 수 있습니다. 그러나 DRep은 언제든지 헌법 위원회를 대체할 수 있고 모든 거버넌스 조치를 비준하기 위해서는 DRep의 투표도 필요하기 때문에 헌법 위원회는 DRep보다 더 많은 권한을 가지지 않으며, 오히려 더 적은 권한을 가지고 있을 수도 있습니다. 그렇다면 헌법위원회는 어떤 역할을 하며, 왜 불필요한 존재가 아닐까요? 답은 위원회가 새로운 거버넌스 프레임워크의 부트스트래핑 문제를 해결한다는 것입니다. 실제로 방아쇠를 당기고 이 프레임워크가 온체인에서 활성화되는 순간, 헌법 위원회가 없어도 시스템이 SPO 투표에만 의존하지 않도록 충분한 DRep이 빠르게 확보되어야 할 것입니다. 저희는 아직 커뮤니티가 DRep으로 등록하는 데 얼마나 적극적일지, 다른 에이다 보유자들이 투표 위임에 대해 얼마나 적극적으로 반응할지 예측할 수 없습니다.

따라서 헌법 위원회는 적절한 시기에 시스템이 현재 상태에서 완전히 탈중앙화된 거버넌스로 전환할 수 있도록 하는 역할을 하게 될 것입니다. 또한, 장기적으로 위원회는 거버넌스 결정에 대한 판단과 지도를 위해 선출된 대표들로 구성되어 거버넌스 결정에 대한 멘토링 및 자문 역할을 수행할 수 있습니다. 무엇보다도 위원회는 항상 헌법을 준수하고 헌법의 규정에 따라 제안을 비준해야 합니다.

사용자 본인 확인의 의도적 생략(Intentional omission of identity verification)

이 CIP에는 헌법위원회 또는 DRep의 구성원에 대한 신원 확인이나 검증에 대한 언급이 없습니다.

이는 의도적인 것입니다.

저희는 커뮤니티가 신원 확인을 위해 DID와 같은 것을 제공하는 DRep에게만 투표하고 위임하는 것을 강력히 고려하기를 바랍니다. 그러나 중앙화된 오라클(centralized oracle) 없이는 신원 확인을 강제하는 것은 매우 어렵고, 이는 잘못된 방향으로 나아가는 단계라고 생각합니다.

다량의 에이다(ada)를 보유한 엔티티의 권한 감소(Reducing the power of entities with large amounts of Ada)

영향력이 큰 단체를 견제하기 위해 쿼드라틱 투표(quadratic voting)와 같은 메커니즘이 존재합니다. 그러나 "1 러브레이스, 1 투표"를 기반으로 하는 시스템에서는 지분을 소량으로 분할하여 제한 조치를 무력화시키는 것은 매우 쉽습니다. 온체인 신원 확인 시스템 없이는 이러한 장치를 도입할 수 없습니다.

스테이크 풀 지분 분배에 편승하는 행위(Piggybacking on stake pool stake distribution)

카르다노 프로토콜은 지분 증명 합의 메커니즘을 기반으로 하므로, 지분 기반 거버넌스 접근 방식을 사용하는 것이 합리적입니다. 그러나 참여자 간의 지분 분배를 기록하는 방법을 정의하는 데 사용할 수 있는 방법은 여러 가지가 있습니다. 현재 네트워크 주소에는 주소에서 자금을 잠금 해제할 수 있는 사용자를 식별하는 자격증명((a.k.a. payment credentials)과 스테이크 풀에 위임할 수 있는 자격증명(a.k.a. delegation credentials)의 두 가지 세트가 포함될 수 있다는 점을 기억하세요.

저희는 세 번째 자격 증명 세트를 정의하는 대신 거버넌스 지분 분배를 결정하기 위해 새로운 온체인 인증서를 사용하여 기존 위임 자격증명(a.k.a. delegation credentials)을 재사용할 것을 제안합니다. 이는 DRep 세트가 SPO 세트와 다를 수 있고, 그렇게 될 가능성이 높다는 것을 의미하며, 균형을 유지한다는 것을 의미합니다. 반대로 거버넌스 지분 분배는 블록 생성과 동일한 단점을 가지고 있습니다. 예를 들어, 지갑 소프트웨어 제공자는 다중 위임 체계를 지원해야 하며, Ada 보유자가 여러 DRep에 위임하고자 하는 경우 지분을 하위 계정으로 쉽게 분할할 수 있어야 하거나, 지갑이 이를 지원하지 않는 경우 Ada 보유자가 수동으로 지분을 분할해야 하는 등의 단점이 있습니다.

그러나 이 방식은 지갑 제공자의 향후 구현 노력을 최소화하고 최종 사용자가 거버넌스 프로토콜에 참여하는 데 필요한 노력을 최소화할 수 있습니다. 후자는 해당 결정에 대한 정당성을 뒷받침하기에 충분한 사안입니다. 기존 구조를 활용함으로써 시스템은 사용자에게 익숙하며 합리적으로 쉽게 설정할 수 있습니다. 이는 거버넌스 프레임워크의 성공 가능성과 참여율을 모두 극대화합니다.

표준 프로토콜 매개변수 변경으로 부터 하드포크 개시에 대한 분리(Separation of hard-fork initiation from standard protocol parameter changes)

다른 프로토콜 매개변수 업데이트와 달리 하드포크(또는 더 정확하게는 프로토콜의 주요 버전 변경)는 훨씬 더 많은 주의를 필요로 합니다. 실제로 다른 프로토콜 매개변수 변경은 소프트웨어의 큰 변경 없이 수행할 수 있지만, 하드포크는 네트워크의 과반수가 업그레이드를 통해 도입되는 새로운 일련의 기능을 지원하기 위해 카르다노 노드를 업그레이드했다고 가정합니다. 즉, 하드포크 이벤트의 타이밍은 모든 카르다노 사용자에게 미리 알려야 하며, 스테이크 풀 운영자, 지갑 제공자, 디앱 개발자, 노드 릴리즈 팀 간의 조율이 필요합니다.

따라서 이 제안은 셸리 계획과 달리 프로토콜 매개변수 업데이트와는 별개의 독립적인 거버넌스 활동으로서 하드포크 개시를 지원합니다.

DRep의 도입(The purpose of the DReps)

이 제안의 어떤 내용도 SPO가 DRep이 되는 것을 제한하지 않습니다. 왜 DRep이 필요한가요? 답은 SPO는 순전히 블록생산을 위해 선택되며, 모든 SPO가 DRep이 되고 싶어하는 것은 아니기 때문입니다. 유권자는 좋은 블록 생산자인지 여부를 고려할 필요 없이 자신의 투표권을 DRep에 위임할 수 있으며, SPO는 Ada 보유자를 대표할지 여부에 대해 선택할 수 있습니다.

비준 요건에 대한 표(Ratification requirements table)

비준 요건 표의 내용은 여기에 설명되어 있습니다. 대부분의 거버넌스 조치에는 헌법 위원회가 정족수에 도달해야 하고 DRep이 충분한 수의 ‘찬성’ 표를 얻어야 한다는 동일한 수준의 요건이 있습니다. 이러한 액션에는 다음과 같은 행위가 포함됩니다:

  • 새로운 위원회/정족수(정상 상태)

  • 헌법 업데이트

  • 프로토콜 매개변수 변경

  • 재무부 인출

불신임 발의(Motion of no-confidence)

불신임 동의안은 현재 헌법 위원회에 대한 카르다노 커뮤니티의 신뢰가 부족하다는 것을 의미하며, 따라서 헌법 위원회는 이 거버넌스 조치에 대해 어떠한 발언권도 가져서는 안 됩니다. 이러한 상황에서는 SPO와 DRep이 커뮤니티의 의사를 대변할 수 있습니다.

새로운 위원회/정족수(불신임 상태) (New committee/quorum - state of no-confidence)

불신임안과 마찬가지로, 헌법 위원회를 선출하는 것은 커뮤니티의 의사를 대변하는 SPO와 DRep의 역할에 달려 있습니다.

다양한 정보(info) 거버넌스 액션의 활용성(The versatility of the info governance action)

정보 거버넌스 액션은 체인에 대한 구속력은 없지만 여러 상황에서 유용할 수 있습니다:

  • CIP 비준

  • 새로운 원장 시대(new ledger era)를 위한 제네시스 파일 설정

  • 향후 제안에 대한 초기 피드백

하드포크 개시(Hard-fork initiation)

거버넌스 메커니즘에 관계없이 소프트웨어를 업그레이드해야 하는 것은 SPO이므로 모든 하드포크에는 SPO의 참여가 필요합니다. 따라서 저희는 하드포크 시작 거버넌스 액션에서 항상 투표를 요구함으로써 이들의 협력을 명시하고 있습니다. 헌법 위원회도 투표를 통해 하드포크의 합헌 여부를 결정합니다. 모든 지분 보유자의 의사를 대변하기 위해 DRep도 투표합니다.

새로운 메타데이터 구조(New metadata structures)

거버넌스 활동과 투표는 모두 URL과 무결성 해시의 형태로 새로운 메타데이터 필드를 사용합니다(스테이크 풀 등록을 위한 메타데이터 구조를 반영). 메타데이터는 컨텍스트를 제공하는 데 사용됩니다. 예를 들어, 헌법 위원회의 투표는 왜 그것이 헌법에 부합하는지에 대한 설명이 필요합니다. 거버넌스 액션은 해당 액션이 왜 필요한지, 어떤 전문가에게 자문을 구했는지 등을 설명해야 합니다. 트랜잭션 크기 제약으로 인해 이러한 설명 데이터가 제한되는 것을 원하지 않기 때문에 URL을 사용합니다.

그러나 이는 새로운 문제를 야기합니다. URL이 확인되지 않는 경우, 해당 액션에 대한 투표를 어떻게 처리해야 할까요? 모든 사람이 '기권’에 투표할 것으로 기대해야 할까요? 거버넌스 시스템에 대한 공격 벡터인가요? 이러한 시나리오에서는 해시 사전 이미지(hash pre-image)가 다른 방식으로 전달될 수 있지만, 상황에 대비해야 합니다. 체인에 정당성을 요약한 내용이 들어가야 할까요?

*대안: 트랜잭션 메타데이터 사용(Alternative: Use of transaction metadata)

트랜잭션 형식의 특정 전용 필드 대신 기존 트랜잭션 메타데이터 필드를 사용할 수 있습니다.

거버넌스 관련 메타데이터는 CIP-10 메타데이터 레이블을 등록하여 명확하게 식별할 수 있습니다. 그 안에서 메타데이터의 구조는 이 CIP(정확한 형식 미정)에 의해 결정될 수 있으며, 인덱스를 사용하여 투표 또는 제안 ID를 해당 메타데이터 URL과 해시에 매핑할 수 있습니다.

이렇게 하면 트랜잭션 본문에 추가 필드를 넣을 필요가 없어지지만, 제출자가 이를 놓치기 쉬워질 위험이 있습니다. 그러나 필수 메타데이터가 비어 있거나 확인되지 않는 URL을 가리킬 수 있기 때문에 제출자가 메타데이터를 제공하지 않는 것은 이미 쉬우므로 이로 인해 상황이 악화되는지는 불분명합니다.

트랜잭션 메타데이터는 원장 상태에 저장되지 않으므로, 이 대안에서 메타데이터를 액션 및 투표와 페어링하는 것은 클라이언트의 몫이며, 원장 상태 쿼리로 사용할 수 없습니다.

활성화된 거버넌스 액션의 수 제어(Controlling the number of active governance actions)

거버넌스 액션은 누구나 제출할 수 있으므로, 투표를 담당하는 사람들이 제안의 쇄도로 인해 과도한 업무에 시달리는 것을 방지할 수 있는 메커니즘이 필요합니다. 거액의 예치금은 그러한 메커니즘 중 하나이지만, 일부 사람들이 조치를 제출하는 데 장벽이 될 수 있다는 단점이 있습니다. 하지만 플루투스 스크립트를 이용한 크라우드 소싱은 언제나 예치금을 모을 수 있는 옵션이라는 점을 참고하세요.

또는 특정 시점에 많은 수의 액션이 활성화될 가능성을 받아들이고, 대신 오프체인 사회화에 기반하여 유권자들이 가치 있는 액션에 관심을 갖도록 유도할 수도 있습니다. 이 시나리오에서 헌법 위원회는 이미 DRep으로부터 충분한 표를 얻은 제안만 고려하도록 선택 할 수 있습니다.

AVST 없음(No AVST)

이 CIP의 초기 초안에는 “활성 투표 지분 임계값”, 즉 AVST라는 개념이 포함되어 있었습니다. 그 목적은 각 투표의 정당성을 보장하여, 예를 들어 러브레이스 10개 중 9개가 카르다노에 있는 수백만 개의 엔티티의 운명을 결정할 수 있는 가능성을 없애는 것이었습니다. 여기에는 실제로 두 가지 우려가 있으며, 이를 구분할 필요가 있습니다.

첫 번째 우려는 시스템을 부트스트랩하는 것, 즉 투표할 수 있는 충분한 양의 지분이 초기 단계에 도달하는 것에 대한 우려입니다. 두 번째 우려는 시간이 지남에 따라 시스템 참여가 줄어들 수 있다는 것입니다. AVST의 한 가지 문제점은 SPO가 낮은 투표 등록을 원하도록 인센티브를 제공한다는 것입니다(투표가 더 많은 비중을 차지하기 때문에). 이는 기존 SPO의 잘못이 아니라 잘못된 인센티브의 문제입니다.

따라서 저희는 두 가지 문제를 다르게 해결하기로 결정했습니다. 먼저 부트스트래핑에 대한 섹션에서 설명한 대로 부트스트래핑 문제부터 해결합니다. 그리고 '기권’과 '신뢰 없음’이라는 두 가지 특수한 경우를 포함하여 지분을 DRep에 위임하지 않는 한 (부트스트랩 단계 이후) 보상 인출을 허용하지 않음으로써 장기 참여 문제를 해결합니다.

Path to Active

승인 기준(Acceptance Criteria)

  • :black_square_button: 새로운 원장 시대는 상기 사양을 구현하는 카르다노 메인넷에서 활성화됩니다.

구현 계획(Implementation Plan)

이 CIP의 기능을 사용하려면 하드포크가 필요합니다.

이 문서는 카르다노 거버넌스에 대한 대대적인 변화를 설명합니다. 저희는 하나의 하드포크를 통해 변경 사항을 구현할 것을 제안합니다.

다음 섹션에서는 이미 확인된 다양한 구현 작업 항목에 대해 더 자세히 설명합니다. 또한, 마지막 섹션에서는 마무리해야 할 몇 가지 미해결 질문에 대해 설명합니다. 커뮤니티 워크숍과 토론을 통해 이러한 질문들이 해결될 수 있기를 바랍니다.

본 제안의 비준(Ratification of this proposal)

본 제안의 비준은 최종 거버넌스 프레임워크가 무엇인지 합의하기 위해 거버넌스 프레임워크가 필요하다는 순환적인 문제입니다. 여러 번 언급했듯이 CIP는 권위 있는 것이 아니며 거버넌스 메커니즘도 아닙니다. 오히려 전문가 커뮤니티에서 (기술적 관점에서) 타당하다고 판단한 기술 솔루션을 설명하는 것입니다.

CIP-1694는 일반적인 CIP 프로세스의 범위를 넘어서는 것이 분명하며, 따라서 특정 절차를 통해 이 CIP를 비준하고자 하는 강력한 필요성이 있습니다. 그러나 그 절차는 아직 정의되지 않았으며 아직 미해결 과제로 남아 있습니다. 최종 프로세스는 다음과 같은 다양한 아이디어가 혼합된 형태가 될 가능성이 높습니다:

  • :black_square_button: 2023년 2월~3월에 열린 콜로라도 워크숍과 같은 커뮤니티 주최 워크숍을 통해 의견을 수렴합니다.

  • :black_square_button: 충분한 참여를 통해 공개 테스트넷에서 투표를 실시합니다.

  • :black_square_button: 기존 SPO를 대상으로 투표를 실시합니다.

  • :black_square_button: 프로젝트 카탈리스트를 활용하여 기존 투표 커뮤니티의 의견을 수집합니다(비록 적극적인 지분은 적지만).

트랜잭션 본문 변경(Changes to the transaction body)

  • :black_square_button: 트랜잭션 본문에 새로운 요소가 추가되고, 기존 업데이트 및 MIR 기능은 제거됩니다. 특히 거버넌스 액션과 투표는 두 개의 새로운 트랜잭션 본문 필드로 구성될 것입니다.

  • :black_square_button: 기존 인증서에 더해 두 가지 새로운 종류의 인증서가 추가됩니다:

    • DRep 등록
    • DRep 등록 취소

마찬가지로 현재 MIR 및 제네시스 인증서도 제거됩니다.

  • :black_square_button: 플루투스 스크립트 컨텍스트에 새로운 투표 목적이 추가될 예정입니다. 이는 특히 온체인 스크립트에 대한 투표를 제공할 것입니다.

주의. 이러한 각 변경 사항에 대한 CDDL 사양을 제공할 예정입니다. 평소처럼.

기존 원장 규칙의 변경 사항(Changes to the existing ledger rules)

  • PPUP 전환 규칙이 다시 작성되어 UTxO 규칙에서 제거됩니다. 그리고 새로운 TALLY 규칙으로 LEDGER 규칙에 추가됩니다. 거버넌스 액션과 투표를 처리하고, 이를 비준하며, 현재 또는 다음 시대에 제정하기 위한 거버넌스 액션을 적절히 준비합니다.

  • NEWEPOCH 전환 규칙이 수정됩니다.

  • MIR 하위 규칙이 제거됩니다.

  • 제정을 위한 거버넌스 액션 단계를 수행하는 새로운 RATIFY 규칙이 추가됩니다.

  • 새로운 제정 규칙은 EPOCH 규칙 바로 뒤에 호출됩니다. 이 규칙은 이전에 비준된 거버넌스 액션을 제정합니다.

  • EPOCH 규칙은 더 이상 NEWPP 하위 규칙을 호출하거나 PPUP 상태에서 정족수 충족 여부를 계산하지 않습니다.

로컬 상태 쿼리 프로토콜 변경 사항(Changes to the local state-query protocol)

온체인 거버넌스 워크로드도 방대하지만, 오프체인에서 발생하는 도구와 애플리케이션의 워크로드는 훨씬 더 클 것입니다. 효과적인 거버넌스 생태계를 구축하기 위해 원장은 다양한 거버넌스 요소에 대한 인터페이스를 제공해야 할 것입니다.

투표와 DRep (탈)등록은 블록에서 직접 볼 수 있으므로 기존의 로컬 체인 동기화 프로토콜을 통해 액세스할 수 있지만, 블록에서 유추하기 어려운 정보(즉, 원장 상태를 유지해야 하는 정보)에 대한 추가 인사이트를 제공하기 위해 로컬 상태 쿼리 프로토콜을 업그레이드해야 합니다. 새로운 상태 쿼리는 (최소한) 다음과 같은 정보를 포함해야 합니다:

  • 현재 법제화 단계에 있는 거버넌스 액션

  • 비준이 진행 중인 거버넌스 액션, 찬성 지분, 반대 지분, 기권 지분의 총합 및 비율

  • 현재 헌법 위원회 및 헌법 해시 요약본

부트스트랩 단계(Bootstrapping Phase)

우리는 이 새로운 정부를 어떻게 부트스트랩할지 신중하게 결정해야 합니다. 관련된 모든 당사자가 스스로 등록하고 프로세스에 익숙해지려면 충분한 시간이 필요합니다.

초기 부트스트랩 단계에서는 특별한 규정이 적용됩니다. 첫째, 부트스트랩 단계에서는 헌법 위원회의 정족수 투표만으로 프로토콜 매개변수를 변경할 수 있습니다. 둘째, 부트스트랩 단계에서는 헌법 위원회의 정족수 투표와 충분한 SPO 투표로 하드포크를 시작할 수 있습니다. 부트스트랩 단계에서는 다른 어떤 액션도 할 수 없습니다.

부트스트랩 단계는 다음 중 하나가 발생하면 종료됩니다:

  • 충분한 양의 지분이 DRep에 위임된 경우

  • 지정된 수의 에포크가 경과한 경우(하드포크 후 몇 개월이 지난 후일 가능성이 높음)

최후 안전 조치, 부트스트랩 후(Final safety measure, post bootstrapping)

많은 분들이 실제 투표 참여율이 시스템 처리량에 부담이 되지 않을 것으로 생각하고 있다고 합니다. 하지만 부트스트랩 단계가 끝난 후에는 마지막으로 일시적인 안전장치를 둘 것입니다. 이를 통해 DRep 예치금을 낮게 정당화할 수 있을 것입니다.

아직 결정되지 않은 $X$와 $Y$의 값에 대해, 부트스트랩 단계가 끝나면 다음 에포크 경계에서의 DReps 지분 분포를 계산할 때, 지분액으로 순위가 상위 $X$개의 DReps 또는 적어도 $Y$ Lovelace를 가진 DReps만 포함합니다. 매 epoch마다, $X$값은 증가하고 $Y$값은 감소하게 되어 결국 $X$가 사실상 무한대가 되고 $Y$는 0이 됩니다. 이것은 단지 인센티브일 뿐이며, 실제로는 DRep이 투표를 제출하지 않을 수 있지만 요구 사항을 충족시키지 않는 한 투표는 계산되지 않을 것입니다.

만약 커뮤니티가 어느 순간 트래픽에 문제가 있다고 결정한다면, 더 제한적인 방법으로 DRep 수를 제한하는 하드포크를 시행할 수 있습니다.

초기 $X$값에 대한 합리적인 수는 5,000-10,000입니다. 초기 $Y$값에 대한 합리적인 수는 초기 $X$값으로 나눈 총 Lovelace의 수입니다.

이 메커니즘은 제한이 6개월에서 1년 정도의 기간이 지나면 완전히 제거될 수 있도록 완화되어야 합니다.

즉, 이는 향후 일부 DReps만 참여하도록 제한하는 일시적인 장치이며, 참여를 원하는 DRep이라면 모두 참여 가능하나, 일부 제한을 두어 참여할 수 있는 DRep의 수를 제한합니다. 이후 시간이 지남에 따라 제한이 완화되어 모든 DRep이 참여 가능해집니다.

기타 아이디어 / 공개 질문(Other Ideas / Open Questions)

서약 가중치 SPO 투표(Pledge-weighted SPO voting)

SPO 투표는 각 SPO의 서약에 따라 가중치를 추가로 부여할 수 있습니다. 이렇게 하면 게임에서 말 그대로 지분을 가진 사람들이 더 강력한 투표권을 가질 수 있는 메커니즘을 제공할 수 있습니다. 가중치는 신중하게 선택해야 합니다.

DRep의 자동 재위임(Automatic re-delegation of DReps)

DRep은 선택적으로 등록 인증서에 다른 DRep 자격 증명을 나열할 수 있습니다. DRep이 은퇴하면 모든 DRep의 위임은 자동으로 지정된 DRep 자격 증명으로 이전됩니다. 해당 DRep이 이미 은퇴한 경우, 위임은 ‘기권’ DRep으로 이전됩니다.

DRep 등록 없음(No DRep registration)

DRep 미등록 시 필요한 기능을 수행하지 않으므로, DRep을 (탈)등록하기 위해 필요한 인증서를 제거할 수 있습니다. 이는 일부 관료주의적 요소를 제거하고 DRep 등록 인증서의 일부인 고정값(anchor)을 트랜잭션 메타데이터로 옮기는 대가를 치르더라도 DRep 예치금이 제거되므로 민주성을 더욱 유동적으로 만들 수 있습니다.

일부 정부 조치에 대한 보증금 감소(Reduced deposits for some government actions)

거버넌스 액션에 적용되는 예치금은 진지하지 않은 거버넌스 액션의 범람을 방지하기 위해 존재하며, 각 액션은 카르다노 커뮤니티의 관심과 노력이 필요합니다. 저희는 합의된 오프체인 절차를 거치는 제안에 대해 이 예치금을 줄일 수 있습니다. 이는 적어도 한 명 이상의 헌법 위원들의 지지를 통해 온체인에 표시될 것입니다. 이 아이디어의 단점은 헌법 위원회에 더 많은 권한을 부여한다는 것입니다.

하드포크 제안서에 (향후) 제네시스 설정 해시를 포함(Include hash of - future - genesis configuration within hard-fork proposal)

일부 하드포크는 새로운 제네시스 설정이 필요합니다. 셸리 및 알론조 하드포크(알레그라, 메리, 바실, 발렌타인은 제외)의 경우 그랬으며, 앞으로도 그럴 수 있습니다. 현재 이 제안서에는 이러한 제네시스 설정에 대한 언급이 없으며, 암묵적으로 오프체인 합의로 가정하고 있습니다. 그러나 특정 제네시스 설정의 해시 또한 하드포크 거버넌스 작업 내에서 기록되도록 강제할 수 있습니다.

DReps / 불신임 상태에 대한 이름 변경(Renaming DReps / state of no-confidence?)

여기에 제시된 "DReps"가 프로젝트 카탈스트 DReps와 혼동될 수 있다고 여러 번 언급된 바 있습니다. 마찬가지로, 일부 사람들은 불신임 상태, 불신임 동의, 불신임 DRep을 혼동하는 경우가 있습니다.

이러한 개념에 대해 더 나은 용어를 찾을 수 있을 것입니다.

재무부 자금 이동에 대한 통화 비율 제한(Rate-limiting treasury movements)

제안된 투표와 투표 임계값을 제외하고는 재무부에서 자금이 인출되는 것을 막는 수단이 없습니다. 카르다노 재무부가 통화 정책의 매우 근본적인 요소라는 점을 감안할 때, 프로토콜 수준에서 일정 기간 동안 재무부에서 인출할 수 있는 최대 금액을 제한하는 것을 고려해 볼 수 있습니다.

Copyright

This CIP is licensed under CC-BY-4.0

한국어 번역: Oscar Hong(Korean translation: Oscar Hong)

CIP-1694 원본(CIP-1694 Original)
GitHub: https://github.com/cardano-foundation/CIPs/pull/380
Others: https://www.1694.io/

1 Like