Jump Crypto: 코드로 토큰 위임 거버넌스의 독립성을 어떻게 보장할 수 있을까?

원문 저자: Nihar Shah, Joe Howarth

원문 편집: aididiaojp.eth, Foresight News

TL;DR

• 토큰 위임 프로그램은 강력한 거버넌스를 구현할 수 있지만, 토큰 보유자가 즉시 위임 권한을 철회할 수 있기 때문에 토큰 위임의 독립성이 제한됩니다.

• 독립성이 요구되는 토큰 보유자, 예를 들어 기관 보유자에게는 토큰 위임 계약에 명확한 잠금 기간을 포함할 것을 권장합니다.

• 우리는 Maker 계약을 통해 시연하며, 의사 결정이 상호적이거나 토큰 보유자가 긴급 경로를 트리거할 경우 거버넌스가 잠금 기간을 우회할 수 있는 기능을 추가했습니다.

소개

지난 2년 동안, 토큰 위임의 개념은 점점 더 인기를 얻고 있습니다. 토큰 위임은 토큰 보유자가 그들의 체인 상 투표권을 다른 사람에게 위임하는 것을 의미하며, Maker, Compound, Uniswap을 포함한 주요 프로토콜도 커뮤니티 거버넌스를 위해 토큰 위임 방식을 사용하고 있습니다. 토큰 위임은 거버넌스 수준을 높이고, 학생 그룹, 비영리 조직 및 커뮤니티 리더를 포함한 커뮤니티의 번영을 촉진합니다.

위임된 토큰에는 두 가지 특별한 장점이 있습니다. 가장 직접적인 이점은 거버넌스를 더 효율적으로 만들 수 있다는 것입니다. 권한 부여 계획이 없다면, 일부 커뮤니티 구성원의 관련 이익이 적거나 충분한 시간이 없어서 수십 개의 제안을 정리하고 복잡한 거버넌스 계획을 이해해야 투표에 참여해야 합니다. 위임 계획을 통해 일부 전문가들은 더 현명하고 일관되며 중요한 결정을 내릴 수 있습니다. 많은 경우, 대의 민주주의는 직접 민주주의보다 장점이 있으며, 암호화 시장도 예외는 아닙니다.

지난해부터 토큰 위임의 두 번째 장점이 부각되기 시작했습니다: 중립성. 예를 들어, 일부 토큰 보유자는 막대한 보유량을 가지고 있으며 경쟁 프로토콜에서 토큰을 보유할 수 있습니다. 이러한 보유자는 분산되고 공정한 커뮤니티를 구축하기 위해 헌신하고 싶어할 수 있으며, 투표권을 위임하는 것은 그들이 중립성을 유지하는 것으로 간주되도록 보장하는 방법입니다.

두 번째 장점은 토큰 위임 프로그램에만 의존해서는 안 되며, 토큰 보유자와 독립적인 특별한 조건이 필요합니다. 예를 들어 a16z의 Jeff Amico는 그의 기사에서 토큰 위임의 원칙을 설명하며, "각 대표가 토큰 보유자와 독립적으로 그들이 적절하다고 생각하는 방식으로 투표할 수 있도록 권한을 부여하는 것"의 중요성을 강조했습니다. 그러나 대부분의 기존 토큰 위임 프로토콜은 이러한 독립성을 강제하지 않으며, 특정 경우에는 이러한 독립성이 중요한 거버넌스 제안 이전에 의도적으로 훼손될 수 있습니다.

이 문서는 코드 기반의 간단한 해결책을 제공합니다: 프로토콜에 잠금 기간 기능을 추가하여, 토큰 보유자가 잠금 기간 동안 수탁자의 거버넌스 권한을 철회할 수 없도록 합니다. 또한 우리는 이 개념의 참조 사례를 만들고, Maker의 프로토콜과 호환되는 선택적 양방향 비긴급 및 단방향 긴급 우회 기능을 추가했습니다.

잠금 기간은 모든 보유자 위임 관계에 적합하지 않습니다. 효율성을 고려하여, 토큰 위임을 사용하는 소액 토큰 보유자는 언제든지 투표권을 철회할 수 있는 권리를 계속 가져야 하며, 커뮤니티는 두 가지를 분리하여 대규모 토큰 보유자와 프로토콜 간의 위임 관계를 재구성할 수 있습니다. 보유자는 자유롭게 권한을 부여하고, 위임자는 독립적으로 투표할 수 있습니다.

실락원: 위임 철회

토큰 위임은 높은 잠재력을 가진 것으로 일반적으로 여겨지지만, 비판을 받지 않는 것은 아닙니다. 이론적으로나 실제로 토큰 위임 프로그램은 권한 부여에 대한 규범을 간과하기 쉬워, 건전한 거버넌스를 구축하려는 의지를 약화시킵니다.

예를 들어 DeFi Watch의 Chris Blec는 a16z가 주장하는 위임 계획의 선택과 상호작용의 명확성을 적극적으로 주장해왔습니다. Blec는 거버넌스 제안이 한두 명의 보유자에 의해 완전히 승인된다면, 투표 대표와 토큰 보유자 간의 관계에 대한 의문을 불러일으킬 것이라고 지적했습니다.

이러한 위험은 실제로 존재합니다. 예를 들어 Maker의 Poll 819 외에도 더 잘 알려진 LOVE 투표가 있습니다. 이 투표는 주로 대출 감독 기관의 선택과 권력 분산 및 효율성에 대한 광범위한 커뮤니티 거버넌스 논의에 관한 것이며, 이 제안은 매우 논란이 많고 격렬했습니다(이 투표는 Maker 투표의 참여 기록을 만들었으며, 이 문서를 작성할 당시에도 그 기록은 여전히 유지되고 있습니다). Luca Prosperi는 더 광범위한 투표 과정을 자세히 기록했지만, 주로 토큰 위임과 관련된 세부 사항에 중점을 두었습니다.

이는 중요한 시점에서 거버넌스 제안이 토큰 위임 프로그램을 우회할 수 있음을 나타냅니다. 예를 들어 Maker의 창립자 Rune Christensen은 위임 기간 동안 제안 권한을 변경하여 투표 결과에 영향을 미쳤습니다. Christensen은 공개적으로 해당 제안에 반대했지만, 그는 거의 모든 MKR 토큰을 위임했습니다. 그러나 2주간의 투표 창 동안, 그는 찬성 또는 기권 투표를 한 대표의 권한을 철회하고, 이러한 토큰을 투표하지 않은 다른 대표에게 다시 권한을 부여했습니다. 이러한 재분배는 Christensen과 찬성 투표를 한 대표 간의 근본적인 분열을 숨기기 위한 전술로 보입니다. 투표 종료 후 3일 이내에 Christensen은 다시 찬성 투표를 한 대표에게 대표권을 돌려주었습니다. 이 패턴은 아래 그림과 같습니다:

법적 해결책

토큰 위임 프로그램은 더욱 개선될 필요가 있습니다. 한 가지 해결책은 법적 계약을 통해 권한 부여와 강제 집행의 독립성을 보장하는 것입니다. 예를 들어 a16z의 위임 계획에서는 대표가 거버넌스 권한을 보유하는 최소 기간을 약속합니다. 만약 대표의 투표가 이해 상충이 있다면, 이는 토큰 보유자가 거버넌스 권한을 회수할 위험을 줄일 수 있습니다. 더 일반적으로, 이는 토큰 보유자가 그들의 대리인에게 가할 수 있는 압력을 제한합니다.

이 원칙은 공공 Github 저장소에 배치된 법적 계약에 의해 강제됩니다. 법적 계약의 핵심 사항은 제6조에 있으며, 여기에는 "해당 대표가 그들의 계약 거버넌스 의무를 이행하지 못할 경우를 방지하기 위해, 본 계약의 초기 기간은 발효일로부터 [N]개월로 하며, 토큰 보유자는 기간 만료 전에 본 계약을 종료할 수 없다."고 규정되어 있습니다.

그러나 법적 메커니즘은 차선책입니다. 우리는 a16z를 의심하지 않지만, 그들의 발자취를 따르는 사람들은 그렇게 고귀하지 않을 수 있습니다. 법적 계약의 집행 비용은 매우 높고 비대칭적인 권력 분포를 내포하며, 불투명한 협상도 포함됩니다. 덜 신경 쓰는 토큰 보유자의 손에 법적 계약은 의미 있는 검토를 거의 받지 못합니다.

따라서 투명성과 집행 가능성에 대한 너무 많은 가정에 의존하기 때문에, 법적 계약은 토큰 위임 프로그램을 일반적으로 확장하고 강화하는 잘못된 메커니즘이 될 수 있습니다.

제안: 법이 아닌 코드

이 문서는 간단한 해결책을 제안합니다: 법적 계약이 아닌 스마트 계약. 다시 말해, 잠금 기간을 스마트 계약에 직접 내장하여 위임의 독립성을 보호하는 것입니다. 이는 사전에 매우 투명하고, 사후에 쉽게 집행할 수 있으며, 가장 중요한 것은 일반적으로 간단한 기술적 구현입니다.

우리는 Maker 계약을 통해 시연합니다. 대부분의 핵심 위임 논리는 VoteDelegate.sol 계약에 존재하며, 특히 lock 및 free 함수에 주목해야 합니다. 이들은 요구 사항을 완전히 충족할 수 있습니다. 토큰 보유자는 lock 함수를 사용하여 토큰을 묶고 그들의 거버넌스 권한을 할당하며, free 함수를 사용하여 이러한 토큰과 관련된 거버넌스 권한을 회수합니다.

몇 가지 간단한 수정도 가능합니다. 먼저 계약 생성자 호출 시 _lockupPeriod라는 변수를 정의합니다. 둘째, 보유자는 initialUnlock 함수를 호출하여 잠금 해제 카운트다운을 시작합니다. 셋째, 잠금 기간이 준수되었는지 확인하기 위해 free 함수를 약간 수정해야 합니다.

잠금 기간을 내장함으로써, 토큰 위임 프로그램은 더욱 공개적이고 신뢰할 수 있게 되며, 법이 아닌 코드에 의해 위임자의 독립성이 보장됩니다.

긴급 우회 기능

물론, 잠금 기간이 항상 바람직한 것은 아닐 수 있으며, 우리는 스마트 계약을 적절히 수정할 수 있습니다.

먼저, 수탁자와 토큰 보유자는 서로 위임 관계를 종료하는 데 동의할 수 있습니다. 이 경우 우회 기능을 제공할 수 있으며, 이는 delegatorBypassLockup이라는 간단한 함수를 통해 구현할 수 있습니다. 이 함수는 위임자가 지체 없이 거버넌스 권한을 포기할 수 있게 해줍니다. (참고로, 매개변수 isDelegatorBypassEnabled는 계약 시작 시 이 기능을 활성화할 수 있습니다.)

둘째, 토큰 보유자가 위임자를 단독으로 우회하는 긴급 상황이 발생할 수 있습니다. 예를 들어, 대리인이 매우 무책임하거나 적대적인 방식으로 행동하는 경우가 있습니다. 물론 이러한 상황은 자주 발생하지 않을 것입니다.

좋은 해결책은 토큰 보유자가 되돌릴 수 없게 토큰을 소각하여 잠금 기간을 우회할 수 있도록 허용하는 것입니다. 이는 쉽게 구현할 수 있습니다. 계약 초기화 시, 토큰 소유자는 EmergencyUnlockBurnPercent 값을 설정합니다(최대 100%까지 가능). 그런 다음 free 함수를 수정하여 토큰 보유자가 긴급 경로를 선택했는지 확인합니다. 그렇다면, 소각되지 않은 토큰의 몫만 반환하고 나머지 몫은 소각합니다. 우리는 여기에서 해당 논리의 일부를 보여줍니다:

완전한 토큰 라이브러리

이 문서에서 논의된 모든 기능과 수정된 함수 요청은 다음의 공개 Github 저장소에서 찾을 수 있으며, Maker 구조에 대한 모든 필요한 변경 사항도 포함되어 있습니다. 우리는 의견과 제안을 환영하며, 이 계약이 생산에 배포될 수 있다고 믿습니다.

미래 비전: 조합 가능성

토큰 위임 프로그램은 더욱 풍부해질 수 있으며, 우리는 토큰 위임 계약의 조합 가능성이 다음 혁신의 물결을 열 것이라고 믿습니다. 예를 들어, 대표가 그들의 투표권을 다른 대표에게 위임할 수 있다면 어떻게 될까요?

이러한 관계는 위임자를 더욱 독립적으로 만들 수 있습니다. 예를 들어, 토큰 보유자는 그들의 토큰을 학생 그룹에 위임할 수 있습니다. 반대로, 학생 그룹은 이러한 권리를 거버넌스 목록의 개인 구성원에게 위임할 수 있으며, 토큰 보유자에게 정확한 신원을 공개할 필요가 없습니다. 따라서 토큰 보유자가 부드러운 압력을 가하고 싶어도, 그들이 겨냥해야 할 사람이 누구인지, 그리고 누구가 그들의 이익을 지지하거나 반대하는지조차 알지 못할 것입니다.

조합 가능성은 또한 더 풍부한 계약과 결합되어, 토큰 보유자와 대리인 간의 더 창의적인 상호작용을 허용할 수 있습니다. 예를 들어, 토큰 보유자가 위임자로부터 토큰을 단독으로 인출할 수 있도록 허용되지만, 최단 잠금 기간이 종료된 후에만 토큰을 받을 수 있도록 할 수 있습니다. 조합 계약은 이를 실현하는 방법이 될 것입니다.

결론

잠금은 모든 사람에게 적합하지 않습니다. 예를 들어, 토큰 위임 프로그램의 초기 효율성 장점에 끌린 사람들은 잠금이 불필요하다고 느낄 수 있습니다. 그러나 잠금은 중립성을 유지하고자 하는 특정 토큰 보유자(예: 창립자, 기관 보유자 등)에게 매우 유용합니다.

중요한 것은, 우리는 명확히 하고 싶습니다. 일부 토큰 보유자는 그들의 대리인에게 큰 독립성을 부여하고 싶어하며, 다른 토큰 보유자는 더 엄격한 감독 관계를 구축하고 싶어합니다. 현 상황은 이러한 모든 사람들을 동일한 스마트 계약으로 강제하며, 그들이 조합된 공개 선언과 법적 문서를 통해 그들의 진정한 의도를 표현하도록 강요합니다. 해당 계약은 각 토큰 보유자가 그들에게 가장 적합한 프레임워크를 선택할 수 있도록 하며, 기대하는 잠금 기간, 상호 우회 기능 및 긴급 소각 매개변수를 포함합니다. 전체 과정은 체인 상에서 발생하며, 모든 사람이 볼 수 있고, 아무도 감시할 필요가 없습니다.