About Tezos Delegate Gallery Navigate
Tezos Korea Community
  • 테조스 개정 절차
    Tezos Korea Community Tezos Korea Community


    Amending Tezos Korean Infograhphic - [Source : Tezos Korea Foundation]

    Amending Tezos English Infograhphic - [Source : Tezos Korea Foundation]

    TRUE 1기 멤버 “세오”님이번역해주신 글입니다.

    테조스 거버넌스 체계 개요배경

    테조스는 하드포크 하지 않고 프로토콜 업그레이드를 제안, 선택, 테스트, 활성화가 온체인에서 가능하게 하는 자체 개정 블록체인 네트웍이다.
    이 글에서 테조스 개정절차가 실제로 어떻게 작용하는지 및 빠른시일내 절차를 개정하는 몇가지 방안을 제안할 것이다. “컨센세스에서 투표권리를 분할하는 것 또는 개정안이 어떻게 온체인에서 후원 받아야 하는지”와 같은 보다 심층적인 문제는 이 글에서는 논외이지만 향후 고려되어야 할 중요한 주제이다.
    이 글은 테조스 베이킹의 기본지식을 안다고 가정한다. 시작전에 “스스로 베이커로 살아보기”와 테조스 지분증명 서류를 추천한다.
    *베이킹의 “사이클”과 혼동되지 않도록 “선출 사이클”이라는 표현이 아닌 “개정 절차”라고 표현한다.
    테조스 개정 절차에 대한 이해
    테조스 개정절차는 4개의 별도의 기간으로 나눠진다.
    제안기간, 탐구 또는 “테스팅”을 위한 투표 기간(1차 투표), 테스팅 기간, 승격을 위한 투표 기간(최종 투표)
    4개의 별도 기간은 각각 8번의 베이킹 사이클을 갖는다. (예: 32,768 블록 또는 대략 22일 18시간), 즉, 제안에서 실제 활성화까지 거의 3개월정도의 기간으로 구성된다.
    아래의 절차도의 요약과 같이 어떠한 단계에서라도 다음 단계로 진행되지 못하면 처음의 제안 기간으로 회귀한다. 달리 말하면, 다음 단계로 진행불가는 전체 개정절차를 다시 시작한다는 것을 의미한다.
    이것은 6월에 테조스의 제네시스(태초) 블록이 적용된 이후 정확하게 일어난 일이다. 제안이 없는 경우, 새로운 제안기간은 블록1이후 매 8사이클에서 재 시작되었다.
    그럼 이것이 어떻게 작동하는가?

    1. 제안 기간
      테조스 개정절차는 제안기간으로 시작한다. 이 기간에 베이커는 제안 활동을 통해 온체인에서 제안한다. 이 제안 활동은 “소스(제안하는 베이커)”, “기간(제안내에 명시한 특정기간)”, “제안 해시(오카멜 파일< .ml/.mli>을 압축한 해시)” 3가지를 매개변수로 한다.
      테조스 개정 절차
      베이커는 제안기간내에 최대 20개를 제안할 수 있다. 제안시 베이커는 그 개정안에 대한 투표도 한다. 이때 기간 초기에 보유한 롤수에 상응해서 투표가능하다.
      테즈스캔에서 해당 개정안들을 볼 수 있다.
      타 베이커들은 제출된 개정안들에 투표를 할 수 있다. 백서상에 기술되었듯이 각 베이커는 최대 20개 개정안에 투표 가능하다. (승인투표)
      제안 기간 말기에 투표결과를 확인하고 가장 많이 ‘좋아요’를 받은 제안은 다음 단계(탐구 투표 기간)로 진행된다. 제안이 없거나 제안들이 동수의 투표결과를 갖게 되면 새로운 제안 기간이 시작된다.
    2. 1차 투표(탐구 투표 기간 또는 현재 프로토콜상 테스팅 투표)
      이 기간에 베이커들은 이전 단계에서 ‘좋아요’ 1위 개정안에 투표할 수 있다.
      투표는 투표 활동을 통해 온체인에서 이루어진다. 이 투표 활동은 ‘소스’, ‘n기간’, ‘제안’, ‘투표의사’로 구성된다. 이때, ‘소스’는 베이커이고, ‘n기간’은 투표기간, ‘제안’은 개정안 내용, ‘투표의사’는 찬성/반대/기권의 3가지 형태이다.
      제안 기간에서와 마찬가지로 베이커의 투표수는 탐구 투표 기간 시작시에 베이커가 보유한 롤수를 기준으로 한다. 각각의 베이커는 투표기간에 한번의 투표활동(상기 4개 매개변수)을 보낼 수 있다.
      8사이클이 끝나면 네트워크가 투표결과를 계산한다. 투표 참여율 (전체 투표권 대비 “찬성”, “반대” 및 “기권”의 합계)가 정족수를 충족하고 (아래에 설명 됨) 기권표를 제외한 베이커의 80 % 절대다수가 승인하면 개정안은 테스트 기간으로 진행됩니다.
      정족수 또는 80% 절대다수가 충족되지 않으면 개정절차는 처음으로 돌아가 개정절차의 첫단계인 제안 기간을 재 시작한다.
      제안 기간과 비교시 눈에 띄는 차이점은 탐구 투표 기간이 끝나면 Q_t가 이전 정족수이고 q_t가 전체 참여율일 때 정족수는 다음과 같이 갱신된다.
      이 식은 과거 참가율의 지수이동평균과 맞추어 정족수를 조정한다.
      제네시스 블록에서는 정족수가 80%로 시작하였고 첫 탐구 투표 기간의 마지막까지 80%를 유지한다.
    3. 테스팅 기간
      탐구 투표 기간의 절대다수가 개정안을 승인하면 테스팅 기간 (8사이클)은 테스트넷 포크로 시작된다. 테스트넷 체인은 테조스 메인체인과 병행하게 종료전 48 시간 동안 실행된다. 보수적으로 설정한 이 48 시간은 테스트넷 체인을 메인체인으로 인식하는 위험을 줄이기 위해서이다.
      2014년 백서에 설명된 대로 개정안은 작은 표준 라이브러리에는 접근할 수 있지만 샌드박싱되어 여타 시스템 호출은 할 수 없다.
      테스팅 기간의 목적은 해당 개정안이 프로토콜에 가치가 있는 개정인지를 평가하는 것이다.
      테스트넷 체인에서 해당 업그레이드는 컨텍스트를 손상시키지 않아야 하고 해당 업그레이드가 채택되면 지속적으로 유효한 상태 변환을 해야 한다. 즉 테스트 체인에 개정안(프로토콜)이 적용되면 오류, 정상 여부를 확인할 수 있다. 그러나 개정안이 가치 있고 안전한지 여부를 결정하기에는 48 시간의 자체 테스트는 너무 짧다. 결과적으로 개정안에 맞추어 구동되는 테스트넷은 테스팅 기간중 48시간을 제외한 나머지 ~ 7.3 사이클 동안 오프체인으로 실행될 것이다. 이는 베이커가 해당 개정안을 평가하고 그 특성을 논의 할 수 있게 한다.
    4. 승격(메인넷에 적용) 투표 기간
      테스팅 기간이 끝나면 실질적으로 메인넷에 개정안 적용을 위한 승격 투표 기간이 시작된다. 이 기간에 네트워크는 오프체인 에서 진행된 토론을 기반하여 해당 개정안을 채택할지 여부와 테스팅 기간 동안의 행위를 결정한다
      탐구 투표 기간에서와 마찬가지로 베이커는 투표 활동을 통해 투표의사를 제출하며, 투표는 승격 투표 기간 시작시의 보유하는 롤 수에 비례하여 가중치가 적용된다. 탐구 투표 기간과 마찬가지로, 각 베이커는 투표기간에 한번의 투표활동을 보낼 수 있다
      승격 투표 기간이 끝나면 네트워크는 투표수를 계산한다. 참여율이 최소 정족수를 충족하고 기권표를 제외한 베이커의 80 % 절대다수가 찬성하면 해당 개정안이 새로운 메인넷으로 활성화된다.
      위 조건이 충족하지 못하면 개정절차가 다시 처음 단계인 제안 기간으로 돌아간다. 최소 정족수는 탐사 투표 기간 종료시 사용 된 것과 동일한 공식을 사용하여 조정된다:
      개정된 프로토콜이 활성화되면 다시 새로운 제안 기간이 시작되고 개정 프로세스가 새로 시작된다.

    테조스 개정절차 개정안

    현재 테조스 개정 절차는 프로토콜뿐만 아니라 개정 절차 자체도 개정하기 위해 간단하지만 효과적인 메커니즘으로 설계되었다.
    현재 설계는 초창기의 테조스를 개선하는데 매우 적합하지만 현재 온체인에서 프로토콜 개선을 구현할 수 있는 다섯 가지 방안을 아래에서 살펴본다.
    또한 온체인과 동등한 오프체인의 건전성을 독려하는 방안도 있다. 마음에 떠오르는 두 가지 예는 코스모스 프로젝트의 게임오브스테이크와 명성/지분을 기준으로 하는 토론 포럼으로 테스트넷에 인센티브가 주어지는 것이다. 하지만 이 것들은 본 글의 논의 범위를 벗어난다.

    1. 제안 기간의 연장 및 제안 비용 도입
      제안 기간을 12 또는 16 사이클로 늘리면 제안을 둘러싼 토론과 조정에 더 많은 시간을 할애 할 수 있다. 또한 개정안이 첫 8사이클 내에 제출되어야 하는 요건은 다음 단계인 탐사 투표 기간으로 진행되기 전에 충분히 개정안을 논의할 시간을 보장한다. 이 요건은 제안 기간 내에 제안이 제출되지 않거나 ‘좋아요’ 몇 개 받지 못한 제안만 제출되다가 기간 마감에 갑자기 제안들을 제출하는 것(눈치작전)을 방지한다.
      베이커가 정당한 제안을 악의적인 또는 평범한 제안과 구별함에 있어 조정 비용을 지불하는 경우 개정안 품질은 현재 테조스 네트워크에서 보통 수준의 위험성을 나타낸다. 궁극적으로 개정안에 투표하는 것은 저렴해야 하지만, 스팸 및 경박한 개정안을 방지하기 위해서 개정안 제안에는 비용이 부과된다.
      개정안 제안시 500 테지(xtz)를 보증금으로 선납하는 것은 네트워크 초창기에 제안 스팸의 위험을 줄이는 간단하면서도 합당한 예방책으로 보인다
      대안으로, 일정기간동안 묶이는 보증금을 더 높이 (예: 2,500 xtz) 으로 책정하되 제안 기간내 해당 개정안이 최소 10 % 이상 ‘좋아요’를 받게 되면 그 보증금은 제안자에게 반환될 수 있다.
    2. 투표 시작 시점이 아닌 투표 종료 시점에 투표권 인정
      각 투표 기간이 시작할 때 베이커가 보유하는 롤을 계산하기 때문에 투표가 일단 시작되면 델리게이터(위임자)는 자신이 위임한 델리게이트(수임자)를 변경하지 못한다. 이것은 위임자에게 투표기간 시작전에 델리게이터(수임자)가 표명한 투표의사를 투표시에 지킬 것이라 믿도록 강제한다.
      투표 기간의 시작시점이 아닌 종료시점에 투표자의 롤수를 계산하면 위임자는 그 수임자가 어떻게 투표하는지 확인한 후에 자신의 지분을 이동시킬 수 있다. 적어도 현재로서는 이런 경우에 수임자는 개정안을 찬성하는 사람들을 위한 수임주소를 하나 만들고 반대하는 사람들을 위한 다른 수임주소를 만들게 한다. 이렇게 하면 위임자는 자신들이 선호하는 수임자를 유지하면서 여전히 개정 절차에 영향력을 유지할 수 있다.
      처음에는 위임자가 베이킹 권리를 수임자에게 제공하기 전에 7사이클을 기다리는 것이 직관적으로 보이지 않을 수 있다. 실제로는 롤이 7 사이클 이후에만 베이킹 권한에 영향을 미치더라도 위임할 때 실시간으로 카운트된다.
      수임자 변경은 또한 거래 비용을 발생시킨다. 위임자가 원하는대로 투표를 하는 수임자를 새로 찾는 것은 검색 비용이 들게 된다. 비록 그 수임자가 원하는대로 투표하더라도 지불구조 또는 신뢰성에 문제가 있을 수도 있다. 또 다른 우려 사항은 투표 기간에 수임자를 변경하는 위임자들에게 수임자가 보복을 시도 할 수 있다는 것입니다. 한 가지 가능한 해결책은 위임자가 수임자의 투표권을 비밀리에 무효화시키는 것이다.
    3. 테스트체인 기간 연장 및 전체 테스팅 기간 연장
      전체 테스팅 기간을 8에서 12 사이클로 늘리면 투표자에게 개정안의 속성을 평가하고 논의할 수 있는 더 많은 시간과 데이터를 제공하게 된다.
      그렇긴 하지만 개정된 프로토콜의 이틀 간의 테스트넷 체인 적용은 그 프로토콜의 지속성을 평가할 수 있는 충분한 시간이 아닐 수 있다. 테스트넷 체인을 일주일 동안 실행하면 온체인에서 테스트 체인의 사실감을 점짐적으로 향상시킬 수 있다.
      개정안이 테스팅 기간 훨씬 이전에 오프체인 환경에서 테스트된다면 그 테스트 기간은 더 많은 “평가 기간”으로 발전 할 것이다
      또 다른 가능성은 탈중앙자치조직(DAO) 또는 선출된 위원회가 허가한 온체인에서 테스트넷을 구축하는 것입니다. 이 위원회의 의사 결정 재량을 좁게 규정할 수 있다. 예로, 개정안에 대한 추가 평가를 위해 시간 보충용 사이클을 정해 승격 투표 기간으로의 진행을 지연시키는 것이다. 반대로, 보다 공격적인 접근 방식은 미리 정한 기간(예: 8 또는 16 사이클)에서 개정안을 승격 투표 기간으로 진행시킬지 위원회가 투표로 정할 수 있다.
    4. 정족수
      테조스의 정족수 조정 체계는 투표에 낮은 참여 및 코인 분실의 결과로 발생할 수 있는 정체를 피하는 간단하면서도 강력한 도구이다. 그러나 낮은 참여도로 계속된 투표 기간 (예: 1 년)은 정족수를 낮은 수준으로 끌어 내릴 수 있으므로 개정안이 많은 지지없이 통과할 수 있다. 부정 행위는 “반대”표를 동원하여 차단할 수는 있지만, 최소 정족수를 설정하는 것이 추가적인 보호장치가 될 수 있다.
      한 가지 가능성은 투표기간내에 절대다수 기준을 참여율에 따라 조정하는 것이다. 이 모델에서 네트워크는 60 %의 참여율인 경우 절대다수 기준은 80%이고 50 %의 참여율인 경우 절대다수 기준을 90%를 요구한다.
      또는 정족수 비율을 평균 참여율보다 크게 할 수도 있습니다. 예를 들면:
      이 공식에 따라 평균 참여율이 0 %이면 네트워크는 정족수 비율을 20 %로 유지합니다. 평균 참가율이 50 %라면 최소 정족수 비율은 60 %가 되며 평균 참가율이 80 %이면 최소 정족수 비율은 84 %가 됩다.
    5. 개정안 활성화(메인넷 적용) 지연
      현재의 테조스 프로토콜은 승격 투표 기간이 끝날 때 바로 개정안을 활성화한다. 그러나 네트워크가 새로운 프로토콜을 준비할 수 있도록 미리 정한 베이킹 사이클 수 이후에 활성화 하는 것이 현명하다 (특히 그 프로토콜이 합의 자체에 대한 변경을 포함하는 경우). 이것은 또한 완충역할로 다음 제안 기간의 시작을 늦추어 베이커가 새로운 프로토콜의에 적응할 수 있게 한다.
      RPC개정
      이번 주 프로토콜3업데이트는 RPC 호스트를 추가함으로써 개정 절차를 지원한다. 이를 통해 테조스 커뮤니티는 개정안과 상호 작용하고, 정족수를 확인하고, 투표수를 확인하고, 이 글에서 언급된 다른 중요한 개정 관련 데이터를 참조 할 수 있다.
      결론
      테조스는 여러 단계 개정 절차를 구현한다. 이 절차는 베이커가 공식적으로 개정안을 제안하고, 선택하고, 테스트하여 해당 개정안을 온체인에서 활성화가 가능하게 한다.
      그러나 블록체인 거버넌스가 아직은 초기단계이고 그리기에 직접적으로 비슷한 경험도 아직 거의 없다.
      따라서 이런 환경에서 우리가 보다 신중하게 접근하고 더 주의를 기울여야 한다. 개정안 품질을 높이도록 독려하고, 중대형 델리케이트의 책임감을 갖도록 하고 테스팅 기간을 늘리는 것이 테조스 개정을 개정(개선)하기 위한 합리적인 첫 단계로 보인다. 그러나 이것들은 단지 시작점인 것이다.
      가장 중요한 것은 개정절차를 진행하면서 초기 경험부터 배운다는 것이다. 초기에 개정절차가 성공적이라도 우리는 기존 시스템의 한계, 특히 장기적으로 투표에 의존하는 한계를 경계할 필요가 있다. 따라서 보완적 체계들(예: Futarchy, programmatic constitutionalism 및 on-chain councils)을 탐구하는 것도 중요하다.
      결국, 블록체인 거버넌스는 단지 “다음” 업그레이드에 관한 것이 아니라 오랫동안 수십억 명의 사용자가 아니라면 수억 명의 사람들이 지속적으로 채택 할 수 있는 인터넷 기반의 제도를 만드는 것에 관한 것이어야 한다. 테조스 개정 과정을 소개하는 것은 그 목표를 향한 한 걸음을 목표로 한다.

    테조스는 하드포크 하지 않고 프로토콜 업그레이드를 제안, 선택, 테스트, 활성화가 온체인에서 가능하게 하는 자체 개정 블록체인 네트웍이다.
    이 글에서 테조스 개정절차가 실제로 어떻게 작용하는지 및 빠른시일내 절차를 개정하는 몇가지 방안을 제안할 것이다. “컨센세스에서 투표권리를 분할하는 것 또는 개정안이 어떻게 온체인에서 후원 받아야 하는지”와 같은 보다 심층적인 문제는 이 글에서는 논외이지만 향후 고려되어야 할 중요한 주제이다.
    이 글은 테조스 베이킹의 기본지식을 안다고 가정한다. 시작전에 “스스로 베이커로 살아보기”와 테조스 지분증명 서류를 추천한다.
    *베이킹의 “사이클”과 혼동되지 않도록 “선출 사이클”이라는 표현이 아닌 “개정 절차”라고 표현한다.
    테조스 개정 절차에 대한 이해
    테조스 개정절차는 4개의 별도의 기간으로 나눠진다.
    제안기간, 탐구 또는 “테스팅”을 위한 투표 기간(1차 투표), 테스팅 기간, 승격을 위한 투표 기간(최종 투표)
    4개의 별도 기간은 각각 8번의 베이킹 사이클을 갖는다. (예: 32,768 블록 또는 대략 22일 18시간), 즉, 제안에서 실제 활성화까지 거의 3개월정도의 기간으로 구성된다.
    아래의 절차도의 요약과 같이 어떠한 단계에서라도 다음 단계로 진행되지 못하면 처음의 제안 기간으로 회귀한다. 달리 말하면, 다음 단계로 진행불가는 전체 개정절차를 다시 시작한다는 것을 의미한다.
    이것은 6월에 테조스의 제네시스(태초) 블록이 적용된 이후 정확하게 일어난 일이다. 제안이 없는 경우, 새로운 제안기간은 블록1이후 매 8사이클에서 재 시작되었다.
    그럼 이것이 어떻게 작동하는가?
    1. 제안 기간
    테조스 개정절차는 제안기간으로 시작한다. 이 기간에 베이커는 제안 활동을 통해 온체인에서 제안한다. 이 제안 활동은 “소스(제안하는 베이커)”, “기간(제안내에 명시한 특정기간)”, “제안 해시(오카멜 파일< .ml/.mli>을 압축한 해시)” 3가지를 매개변수로 한다.
    테조스 개정 절차
    베이커는 제안기간내에 최대 20개를 제안할 수 있다. 제안시 베이커는 그 개정안에 대한 투표도 한다. 이때 기간 초기에 보유한 롤수에 상응해서 투표가능하다.
    테즈스캔에서 해당 개정안들을 볼 수 있다.
    타 베이커들은 제출된 개정안들에 투표를 할 수 있다. 백서상에 기술되었듯이 각 베이커는 최대 20개 개정안에 투표 가능하다. (승인투표)
    제안 기간 말기에 투표결과를 확인하고 가장 많이 ‘좋아요’를 받은 제안은 다음 단계(탐구 투표 기간)로 진행된다. 제안이 없거나 제안들이 동수의 투표결과를 갖게 되면 새로운 제안 기간이 시작된다.
    2. 1차 투표(탐구 투표 기간 또는 현재 프로토콜상 테스팅 투표)
    이 기간에 베이커들은 이전 단계에서 ‘좋아요’ 1위 개정안에 투표할 수 있다.
    투표는 투표 활동을 통해 온체인에서 이루어진다. 이 투표 활동은 ‘소스’, ‘n기간’, ‘제안’, ‘투표의사’로 구성된다. 이때, ‘소스’는 베이커이고, ‘n기간’은 투표기간, ‘제안’은 개정안 내용, ‘투표의사’는 찬성/반대/기권의 3가지 형태이다.
    제안 기간에서와 마찬가지로 베이커의 투표수는 탐구 투표 기간 시작시에 베이커가 보유한 롤수를 기준으로 한다. 각각의 베이커는 투표기간에 한번의 투표활동(상기 4개 매개변수)을 보낼 수 있다.
    8사이클이 끝나면 네트워크가 투표결과를 계산한다. 투표 참여율 (전체 투표권 대비 “찬성”, “반대” 및 “기권”의 합계)가 정족수를 충족하고 (아래에 설명 됨) 기권표를 제외한 베이커의 80 % 절대다수가 승인하면 개정안은 테스트 기간으로 진행됩니다.
    정족수 또는 80% 절대다수가 충족되지 않으면 개정절차는 처음으로 돌아가 개정절차의 첫단계인 제안 기간을 재 시작한다.
    제안 기간과 비교시 눈에 띄는 차이점은 탐구 투표 기간이 끝나면 Q_t가 이전 정족수이고 q_t가 전체 참여율일 때 정족수는 다음과 같이 갱신된다.
    이 식은 과거 참가율의 지수이동평균과 맞추어 정족수를 조정한다.
    제네시스 블록에서는 정족수가 80%로 시작하였고 첫 탐구 투표 기간의 마지막까지 80%를 유지한다.
    3. 테스팅 기간
    탐구 투표 기간의 절대다수가 개정안을 승인하면 테스팅 기간 (8사이클)은 테스트넷 포크로 시작된다. 테스트넷 체인은 테조스 메인체인과 병행하게 종료전 48 시간 동안 실행된다. 보수적으로 설정한 이 48 시간은 테스트넷 체인을 메인체인으로 인식하는 위험을 줄이기 위해서이다.
    2014년 백서에 설명된 대로 개정안은 작은 표준 라이브러리에는 접근할 수 있지만 샌드박싱되어 여타 시스템 호출은 할 수 없다.
    테스팅 기간의 목적은 해당 개정안이 프로토콜에 가치가 있는 개정인지를 평가하는 것이다.
    테스트넷 체인에서 해당 업그레이드는 컨텍스트를 손상시키지 않아야 하고 해당 업그레이드가 채택되면 지속적으로 유효한 상태 변환을 해야 한다. 즉 테스트 체인에 개정안(프로토콜)이 적용되면 오류, 정상 여부를 확인할 수 있다. 그러나 개정안이 가치 있고 안전한지 여부를 결정하기에는 48 시간의 자체 테스트는 너무 짧다. 결과적으로 개정안에 맞추어 구동되는 테스트넷은 테스팅 기간중 48시간을 제외한 나머지 ~ 7.3 사이클 동안 오프체인으로 실행될 것이다. 이는 베이커가 해당 개정안을 평가하고 그 특성을 논의 할 수 있게 한다.
    4. 승격(메인넷에 적용) 투표 기간
    테스팅 기간이 끝나면 실질적으로 메인넷에 개정안 적용을 위한 승격 투표 기간이 시작된다. 이 기간에 네트워크는 오프체인 에서 진행된 토론을 기반하여 해당 개정안을 채택할지 여부와 테스팅 기간 동안의 행위를 결정한다
    탐구 투표 기간에서와 마찬가지로 베이커는 투표 활동을 통해 투표의사를 제출하며, 투표는 승격 투표 기간 시작시의 보유하는 롤 수에 비례하여 가중치가 적용된다. 탐구 투표 기간과 마찬가지로, 각 베이커는 투표기간에 한번의 투표활동을 보낼 수 있다
    승격 투표 기간이 끝나면 네트워크는 투표수를 계산한다. 참여율이 최소 정족수를 충족하고 기권표를 제외한 베이커의 80 % 절대다수가 찬성하면 해당 개정안이 새로운 메인넷으로 활성화된다.
    위 조건이 충족하지 못하면 개정절차가 다시 처음 단계인 제안 기간으로 돌아간다. 최소 정족수는 탐사 투표 기간 종료시 사용 된 것과 동일한 공식을 사용하여 조정된다:
    개정된 프로토콜이 활성화되면 다시 새로운 제안 기간이 시작되고 개정 프로세스가 새로 시작된다.

    테조스 개정절차 개정안

    현재 테조스 개정 절차는 프로토콜뿐만 아니라 개정 절차 자체도 개정하기 위해 간단하지만 효과적인 메커니즘으로 설계되었다.
    현재 설계는 초창기의 테조스를 개선하는데 매우 적합하지만 현재 온체인에서 프로토콜 개선을 구현할 수 있는 다섯 가지 방안을 아래에서 살펴본다.
    또한 온체인과 동등한 오프체인의 건전성을 독려하는 방안도 있다. 마음에 떠오르는 두 가지 예는 코스모스 프로젝트의 게임오브스테이크와 명성/지분을 기준으로 하는 토론 포럼으로 테스트넷에 인센티브가 주어지는 것이다. 하지만 이 것들은 본 글의 논의 범위를 벗어난다.
    1. 제안 기간의 연장 및 제안 비용 도입
    제안 기간을 12 또는 16 사이클로 늘리면 제안을 둘러싼 토론과 조정에 더 많은 시간을 할애 할 수 있다. 또한 개정안이 첫 8사이클 내에 제출되어야 하는 요건은 다음 단계인 탐사 투표 기간으로 진행되기 전에 충분히 개정안을 논의할 시간을 보장한다. 이 요건은 제안 기간 내에 제안이 제출되지 않거나 ‘좋아요’ 몇 개 받지 못한 제안만 제출되다가 기간 마감에 갑자기 제안들을 제출하는 것(눈치작전)을 방지한다.
    베이커가 정당한 제안을 악의적인 또는 평범한 제안과 구별함에 있어 조정 비용을 지불하는 경우 개정안 품질은 현재 테조스 네트워크에서 보통 수준의 위험성을 나타낸다. 궁극적으로 개정안에 투표하는 것은 저렴해야 하지만, 스팸 및 경박한 개정안을 방지하기 위해서 개정안 제안에는 비용이 부과된다.
    개정안 제안시 500 테지(xtz)를 보증금으로 선납하는 것은 네트워크 초창기에 제안 스팸의 위험을 줄이는 간단하면서도 합당한 예방책으로 보인다
    대안으로, 일정기간동안 묶이는 보증금을 더 높이 (예: 2,500 xtz) 으로 책정하되 제안 기간내 해당 개정안이 최소 10 % 이상 ‘좋아요’를 받게 되면 그 보증금은 제안자에게 반환될 수 있다.
    2. 투표 시작 시점이 아닌 투표 종료 시점에 투표권 인정
    각 투표 기간이 시작할 때 베이커가 보유하는 롤을 계산하기 때문에 투표가 일단 시작되면 델리게이터(위임자)는 자신이 위임한 델리게이트(수임자)를 변경하지 못한다. 이것은 위임자에게 투표기간 시작전에 델리게이터(수임자)가 표명한 투표의사를 투표시에 지킬 것이라 믿도록 강제한다.
    투표 기간의 시작시점이 아닌 종료시점에 투표자의 롤수를 계산하면 위임자는 그 수임자가 어떻게 투표하는지 확인한 후에 자신의 지분을 이동시킬 수 있다. 적어도 현재로서는 이런 경우에 수임자는 개정안을 찬성하는 사람들을 위한 수임주소를 하나 만들고 반대하는 사람들을 위한 다른 수임주소를 만들게 한다. 이렇게 하면 위임자는 자신들이 선호하는 수임자를 유지하면서 여전히 개정 절차에 영향력을 유지할 수 있다.
    처음에는 위임자가 베이킹 권리를 수임자에게 제공하기 전에 7사이클을 기다리는 것이 직관적으로 보이지 않을 수 있다. 실제로는 롤이 7 사이클 이후에만 베이킹 권한에 영향을 미치더라도 위임할 때 실시간으로 카운트된다.
    수임자 변경은 또한 거래 비용을 발생시킨다. 위임자가 원하는대로 투표를 하는 수임자를 새로 찾는 것은 검색 비용이 들게 된다. 비록 그 수임자가 원하는대로 투표하더라도 지불구조 또는 신뢰성에 문제가 있을 수도 있다. 또 다른 우려 사항은 투표 기간에 수임자를 변경하는 위임자들에게 수임자가 보복을 시도 할 수 있다는 것입니다. 한 가지 가능한 해결책은 위임자가 수임자의 투표권을 비밀리에 무효화시키는 것이다.
    3. 테스트체인 기간 연장 및 전체 테스팅 기간 연장
    전체 테스팅 기간을 8에서 12 사이클로 늘리면 투표자에게 개정안의 속성을 평가하고 논의할 수 있는 더 많은 시간과 데이터를 제공하게 된다.
    그렇긴 하지만 개정된 프로토콜의 이틀 간의 테스트넷 체인 적용은 그 프로토콜의 지속성을 평가할 수 있는 충분한 시간이 아닐 수 있다. 테스트넷 체인을 일주일 동안 실행하면 온체인에서 테스트 체인의 사실감을 점짐적으로 향상시킬 수 있다.
    개정안이 테스팅 기간 훨씬 이전에 오프체인 환경에서 테스트된다면 그 테스트 기간은 더 많은 “평가 기간”으로 발전 할 것이다
    또 다른 가능성은 탈중앙자치조직(DAO) 또는 선출된 위원회가 허가한 온체인에서 테스트넷을 구축하는 것입니다. 이 위원회의 의사 결정 재량을 좁게 규정할 수 있다. 예로, 개정안에 대한 추가 평가를 위해 시간 보충용 사이클을 정해 승격 투표 기간으로의 진행을 지연시키는 것이다. 반대로, 보다 공격적인 접근 방식은 미리 정한 기간(예: 8 또는 16 사이클)에서 개정안을 승격 투표 기간으로 진행시킬지 위원회가 투표로 정할 수 있다.
    4. 정족수
    테조스의 정족수 조정 체계는 투표에 낮은 참여 및 코인 분실의 결과로 발생할 수 있는 정체를 피하는 간단하면서도 강력한 도구이다. 그러나 낮은 참여도로 계속된 투표 기간 (예: 1 년)은 정족수를 낮은 수준으로 끌어 내릴 수 있으므로 개정안이 많은 지지없이 통과할 수 있다. 부정 행위는 “반대”표를 동원하여 차단할 수는 있지만, 최소 정족수를 설정하는 것이 추가적인 보호장치가 될 수 있다.
    한 가지 가능성은 투표기간내에 절대다수 기준을 참여율에 따라 조정하는 것이다. 이 모델에서 네트워크는 60 %의 참여율인 경우 절대다수 기준은 80%이고 50 %의 참여율인 경우 절대다수 기준을 90%를 요구한다.
    또는 정족수 비율을 평균 참여율보다 크게 할 수도 있습니다. 예를 들면:
    이 공식에 따라 평균 참여율이 0 %이면 네트워크는 정족수 비율을 20 %로 유지합니다. 평균 참가율이 50 %라면 최소 정족수 비율은 60 %가 되며 평균 참가율이 80 %이면 최소 정족수 비율은 84 %가 됩다.
    5. 개정안 활성화(메인넷 적용) 지연
    현재의 테조스 프로토콜은 승격 투표 기간이 끝날 때 바로 개정안을 활성화한다. 그러나 네트워크가 새로운 프로토콜을 준비할 수 있도록 미리 정한 베이킹 사이클 수 이후에 활성화 하는 것이 현명하다 (특히 그 프로토콜이 합의 자체에 대한 변경을 포함하는 경우). 이것은 또한 완충역할로 다음 제안 기간의 시작을 늦추어 베이커가 새로운 프로토콜의에 적응할 수 있게 한다.
    RPC개정
    이번 주 프로토콜3업데이트는 RPC 호스트를 추가함으로써 개정 절차를 지원한다. 이를 통해 테조스 커뮤니티는 개정안과 상호 작용하고, 정족수를 확인하고, 투표수를 확인하고, 이 글에서 언급된 다른 중요한 개정 관련 데이터를 참조 할 수 있다.
    결론
    테조스는 여러 단계 개정 절차를 구현한다. 이 절차는 베이커가 공식적으로 개정안을 제안하고, 선택하고, 테스트하여 해당 개정안을 온체인에서 활성화가 가능하게 한다.
    그러나 블록체인 거버넌스가 아직은 초기단계이고 그리기에 직접적으로 비슷한 경험도 아직 거의 없다.
    따라서 이런 환경에서 우리가 보다 신중하게 접근하고 더 주의를 기울여야 한다. 개정안 품질을 높이도록 독려하고, 중대형 델리케이트의 책임감을 갖도록 하고 테스팅 기간을 늘리는 것이 테조스 개정을 개정(개선)하기 위한 합리적인 첫 단계로 보인다. 그러나 이것들은 단지 시작점인 것이다.
    가장 중요한 것은 개정절차를 진행하면서 초기 경험부터 배운다는 것이다. 초기에 개정절차가 성공적이라도 우리는 기존 시스템의 한계, 특히 장기적으로 투표에 의존하는 한계를 경계할 필요가 있다. 따라서 보완적 체계들(예: Futarchy, programmatic constitutionalism 및 on-chain councils)을 탐구하는 것도 중요하다.
    결국, 블록체인 거버넌스는 단지 “다음” 업그레이드에 관한 것이 아니라 오랫동안 수십억 명의 사용자가 아니라면 수억 명의 사람들이 지속적으로 채택 할 수 있는 인터넷 기반의 제도를 만드는 것에 관한 것이어야 한다. 테조스 개정 과정을 소개하는 것은 그 목표를 향한 한 걸음을 목표로 한다.

    Source : Amending Tezos

답변은 로그인 후 가능합니다.