Vitalik 최신 연구: LSDFi 프로토콜과 유동성이 어떻게 변화해야 탈중앙화를 향상시키고 합의 과부하를 줄일 수 있을까?

원문 제목：《탈중앙화 개선 및 합의 오버헤드 감소를 위한 프로토콜 및 스테이킹 풀 변경 사항》

저자：Vitalik Buterin

편집：bayemon.eth, ChainCatcher

특별히 Mike Neuder, Justin Drake 및 기타 분들의 피드백과 검토에 감사드립니다. 또한 Mike Neuder, Dankrad Feist 및 arixon.eth가 이전에 유사한 주제로 발표한 글도 참조하시기 바랍니다.

현재 이더리움의 발전 현황은 대량의 이중 스테이킹(two-tiered staking)을 포함하고 있다고 할 수 있습니다. 여기서 말하는 이중 스테이킹은 두 종류의 참여자가 있는 스테이킹 모델을 의미합니다.

1. 노드 운영자 Node Operator：노드를 운영하며 자신의 명성을 담보로 일정량의 자본을 스테이킹합니다.
2. 위임자 Delegator：위임자들은 일정량의 이더리움을 스테이킹하며, 최소 금액이 없고 담보 외의 다른 참여 방식에 대한 추가 제한이 없습니다.

이러한 새로운 이중 스테이킹은 대량 참여를 통해 유동성 스테이킹 토큰(LST)의 스테이킹 풀을 생성하여 이루어집니다. (Rocket Pool과 Lido가 이러한 모델입니다).

하지만 현재의 이중 스테이킹에는 두 가지 결함이 있습니다:

1. 노드 운영자의 중앙화 위험：현재 모든 스테이킹 풀에서 노드 운영자를 선택하는 메커니즘이 여전히 지나치게 중앙화되어 있습니다.
2. 불필요한 합의 부담：이더리움 L1의 각 Epoch마다 약 800,000개의 서명을 검증해야 하며, 이는 단일 슬롯에 대해 엄청난 부담입니다. 또한 유동성 스테이킹 풀에 필요한 자금이 많지만, 네트워크 자체는 이러한 부담으로부터 충분한 이익을 얻지 못하고 있습니다. 따라서 이더리움 네트워크가 합리적인 분산성과 안전성을 달성할 수 있다면, 각 스테이커가 시간에 따라 서명할 필요 없이 이러한 해결책을 채택하여 각 시간대의 서명 수를 효과적으로 줄일 수 있습니다.

본 문서에서는 위의 두 가지 문제를 해결하는 방안을 설명합니다. 우선 가정해 보겠습니다. 대부분의 자본이 현재 형태로 직접 스테이킹 노드를 관리하고 각 슬롯에서 정보를 서명하며 예금을 잠그고 자금을 재분배하는 것을 원하지 않는 사람들에게 있다면, 이러한 상황에서 이들은 여전히 네트워크의 탈중앙화와 안전성에 의미 있는 기여를 할 수 있는 역할을 할 수 있을까요?

현재의 이중 스테이킹은 어떻게 작동하는가?

현재 가장 인기 있는 두 개의 스테이킹 풀은 Lido와 Rocket Pool입니다. Lido의 경우 참여하는 두 당사자는 다음과 같습니다:

1. 노드 운영자: Lido DAO의 투표로 선출되며, 이는 사실상 LDO 보유자에 의해 선출된다는 의미입니다. 누군가 Lido 스마트 계약 시스템에 ETH를 예치하면 stETH가 생성되며, 노드 운영자는 이를 스테이킹 풀에 투입할 수 있습니다(하지만 인출 증명서와 스마트 계약 주소가 연결되어 있어 운영자는 임의로 인출할 수 없습니다).
2. 위임자: 누군가 Lido 스마트 계약 시스템에 ETH를 예치하면 stETH가 생성되며, 노드 운영자는 이를 스테이킹으로 사용할 수 있습니다(마찬가지로 인출 증명서와 스마트 계약 주소가 연결되어 있어 운영자는 임의로 인출할 수 없습니다).

Rocket Pool의 경우는 다음과 같습니다:

1. 노드 운영자: 누구나 노드 운영자가 될 수 있으며, 8 ETH와 일정량의 RPL 토큰을 제출하면 됩니다.
2. 위임자: 누군가 Rocket Pool 스마트 계약 시스템에 ETH를 예치하면 rETH가 생성되며, 노드 운영자는 이를 스테이킹으로 사용할 수 있습니다(마찬가지로 인출 증명서와 스마트 계약 주소가 연결되어 있어 운영자는 임의로 인출할 수 없습니다).

위임자 역할

이러한 시스템(또는 미래의 잠재적인 프로토콜 변경으로 활성화될 새로운 시스템)에서 제기해야 할 핵심 질문은 다음과 같습니다: 프로토콜의 관점에서 위임자를 설정하는 의미는 무엇인가?

이 질문의 깊은 의미를 이해하기 위해, 우리는 먼저 게시물에서 언급된 프로토콜 변경 사항, 즉 처벌을 2 ETH로 제한할 경우를 생각해 보겠습니다. Rocket Pool은 노드 운영자의 스테이킹 금액을 2 ETH로 낮추고, Rocket Pool의 시장 점유율은 100%로 증가할 것입니다(스테이커와 ETH 보유자에게 rETH가 무위험해짐에 따라 거의 모든 ETH 보유자가 rETH 보유자 또는 노드 운영자가 될 것입니다).

rETH 보유자의 수익률이 3%라고 가정하고(프로토콜 내 보상 및 우선권 수수료 + MEV 포함), 노드 운영자의 수익률이 4%라고 가정해 보겠습니다. 또한 ETH의 총 공급량이 1억 개라고 가정합니다.

계산 결과는 다음과 같습니다. 복리 계산을 피하기 위해 우리는 일 단위로 수익을 계산합니다:

이제 Rocket Pool이 존재하지 않는다고 가정하면, 각 스테이커의 최소 예치금이 2 ETH로 낮아지고, 유동성 총량 상한이 625만 ETH가 되며, 노드 운영자의 수익률이 1%로 낮아집니다. 다시 계산해 보겠습니다:

공격 비용의 관점에서 이 두 가지 상황을 고려해 보겠습니다. 첫 번째 경우에서 공격자는 위임자로 등록하지 않을 것입니다. 왜냐하면 위임자는 본질적으로 인출 권한이 없기 때문에 의미가 없기 때문입니다. 따라서 그들은 모든 ETH를 스테이킹하고 노드 운영자가 되기를 원할 것입니다. 스테이킹 총량의 1/3에 도달하기 위해서는 208만 개의 이더리움을 투입해야 합니다(공정하게 말하면, 이것은 여전히 상당히 큰 숫자입니다). 두 번째 경우에서 공격자는 자금을 투입하기만 하면 되며, 스테이킹 풀 총량의 1/3에 도달하기 위해 여전히 208만 개의 이더리움을 투입해야 합니다.

스테이킹 경제학과 공격 비용의 관점에서 볼 때, 두 가지 경우의 최종 결과는 완전히 동일합니다. 노드 운영자가 보유한 ETH 총 공급량 비율은 매일 0.00256% 증가하고, 비노드 운영자가 보유한 ETH 총 공급량 비율은 매일 0.00017% 감소합니다. 공격 비용은 208만 ETH입니다. 따라서 이 모델에서 위임자는 의미 없는 Rube Goldberg 기계가 된 것처럼 보이며, 합리적인 커뮤니티는 중개인을 제거하고 스테이킹 보상을 대폭 줄이며 스테이킹의 ETH 총량을 625만 개로 제한하려는 경향이 있습니다.

물론 본 문서는 스테이킹 보상을 4배 줄이고 스테이킹 총량을 625만 개로 고정하자는 주장을 하지 않습니다. 반대로, 본 문서의 주장은 잘 작동하는 스테이킹 시스템은 위임자가 시스템 전반에서 중요한 책임을 져야 한다는 핵심 속성을 가져야 한다는 것입니다. 또한 위임자가 커뮤니티의 압력과 이타주의적 동기에 의해 올바른 행동을 취하는 데 큰 영향을 받는다면, 그것도 괜찮습니다. 결국, 이것이 오늘날 사람들을 탈중앙화되고 높은 안전성을 갖춘 스테이킹 솔루션을 추진하도록 유도하는 주요 힘입니다.

위임자의 책임

위임자가 스테이킹 시스템에서 의미 있는 역할을 할 수 있다면, 그 역할은 무엇일까요?

저는 두 가지 유형의 답변이 있다고 생각합니다:

• 위임자 선택: 위임자는 자신의 이해관계를 어떤 노드 운영자에게 위임할지를 선택할 수 있습니다. 노드 운영자가 합의 메커니즘에서 가지는 "가중치"는 그들에게 위임된 총 스테이킹에 비례합니다. 현재 위임자 선택 메커니즘은 여전히 제한적이며, 즉 rETH 또는 stETH 보유자는 자신의 ETH를 인출하고 다른 풀로 전환할 수 있지만, 위임자 선택의 실제 가용성을 크게 높일 수 있습니다.
• 합의 메커니즘 참여: 위임자는 합의 메커니즘에서 일정한 역할을 수행할 수 있으며, 책임은 전액 인수보다 "가벼운" 방식으로, 긴 탈퇴 기간이나 감축 위험 없이도 노드 운영자를 견제하는 역할을 할 수 있습니다.

위임자 선택권 강화

위임자 선택권을 강화하는 세 가지 방법이 있습니다:

1. 풀 내 투표 도구 개선
2. 풀 간 경쟁 증가
3. 위임권 고정화

현재 풀 내에서 투표하는 것은 사실상 비현실적입니다: Rocket Pool에서는 누구나 노드 운영자가 될 수 있으며, Lido에서는 투표가 LDO 보유자에 의해 결정되며, ETH 보유자에 의해 결정되지 않습니다. Lido는 LDO + stETH 이중 거버넌스에 대한 제안을 했으며, 이들은 새로운 투표를 차단하는 보호 메커니즘을 활성화하여 노드 운영자가 추가되거나 제거되는 것을 방지할 수 있습니다. 이는 어느 정도 stETH 보유자에게 발언권을 부여합니다. 그럼에도 불구하고 이러한 권한은 여전히 제한적이며, 더 강력해질 수 있습니다.

풀 간 경쟁은 오늘날 존재하지만 상대적으로 약합니다. 주요 도전 과제는 작은 스테이킹 풀의 스테이킹 토큰이 낮은 유동성을 가지며 신뢰를 얻기 어렵고, 애플리케이션의 지원을 거의 받지 못한다는 것입니다.

우리는 처벌 금액을 2 또는 4 ETH와 같은 작은 수치로 제한함으로써 앞의 두 가지 문제를 개선할 수 있습니다. 그런 다음 나머지 ETH는 안전하게 예치하고 즉시 인출할 수 있어, 양방향 교환이 작은 스테이킹 풀에서도 여전히 유효하게 됩니다. 우리는 LST를 관리하기 위한 총 발행 계약을 생성함으로써 세 번째 문제를 개선할 수 있습니다(ERC-4337 및 ERC-6900이 지갑에 사용되는 계약과 유사함), 이를 통해 해당 계약을 통해 발행된 모든 스테이킹 토큰이 안전하다는 것을 보장할 수 있습니다.

현재 프로토콜 내에서 고정된 위임 권한은 존재하지 않지만, 이러한 상황은 미래에 존재할 가능성이 있습니다. 이는 위에서 언급한 아이디어와 유사한 논리를 포함하겠지만, 프로토콜 수준에서 구현됩니다. 고정화의 장단점에 대해서는 이 글을 참조하십시오.

이러한 아이디어는 현 상태에 대한 개선이지만, 그들이 제공할 수 있는 이점은 제한적입니다. 토큰 투표 거버넌스에는 문제가 있으며, 궁극적으로 모든 형태의 비유인 위임 선택은 단지 토큰 투표의 형태일 뿐입니다. 이는 제가 위임 지분 증명에 대해 가장 불만족스러운 점입니다. 따라서 더 강력한 합의 참여 방식을 구현하는 것을 고려하는 것도 가치가 있습니다.

합의 참여

유동성 스테이킹의 현재 문제를 고려하지 않더라도, 현재의 독립 스테이킹 방법에도 제한이 있습니다. single-slot finality를 사용할 경우, 이상적인 상태에서 각 슬롯은 약 100,000에서 1,000,000개의 BLS 서명을 처리할 수 있습니다. 우리가 서명을 집계하기 위해 재귀 SNARKs를 사용하더라도, 서명의 추적 가능성을 위해 각 서명에 참여자의 비트 필드를 부여해야 합니다. 이더리움이 글로벌 규모의 네트워크가 된다면, 완전한 분산화된 비트 필드 저장도 충분하지 않습니다: 각 슬롯의 16MB는 약 6400만 명의 스테이커만 지원할 수 있습니다.

이 관점에서 스테이킹을 더 높은 복잡도의 감축 가능 층과 낮은 복잡도의 층으로 나누는 것은 가치가 있습니다. 높은 복잡도의 층은 각 슬롯에서 유효하지만, 참여자는 10,000명만 있을 수 있으며, 낮은 복잡도의 층은 가끔 호출되어 참여할 수 있습니다. 낮은 복잡도의 층은 완전히 감축을 면할 수 있거나, 참여자에게 기회를 무작위로 부여하여 몇 개의 슬롯 내에서 예치하고 감축 대상이 될 수 있습니다.

실제로 이는 검증자의 잔액 상한을 높이고, 이후 잔액 임계값(예: 2048 ETH)을 증가시켜 어떤 기존 검증자가 더 높은 복잡도 또는 낮은 복잡도 층에 들어갈지를 결정할 수 있습니다.

다음은 이러한 소액 스테이킹 역할이 어떻게 작동하는지에 대한 몇 가지 제안입니다:

1. 각 슬롯에서 무작위로 10,000명의 소액 스테이커를 선택하여 그들이 해당 슬롯을 대표할 수 있다고 생각하는 내용을 서명할 수 있습니다. 소액 스테이커를 입력으로 사용하여 LMD GHOST 분기 선택 규칙을 실행합니다. 소액 스테이커가 주도하는 분기 선택과 노드 운영자가 주도하는 분기 선택 간에 일정한 불일치가 발생할 경우, 사용자의 클라이언트는 어떤 블록도 최종 확인으로 수용하지 않으며 오류를 표시합니다. 이는 커뮤니티가 상황을 해결하도록 강제합니다.
2. 위임자는 거래를 보내 네트워크에 온라인 상태이며 다음 한 시간 동안 소액 스테이커로 활동할 의사가 있음을 알릴 수 있습니다. 노드에서 보내는 메시지(블록 또는 증명)는 계산되며, 노드와 무작위로 선택된 한 위임자가 노드의 확인 정보를 서명해야 합니다.
3. 위임자는 거래를 보내 네트워크에 온라인 상태이며 다음 한 시간 동안 소액 스테이커로 활동할 의사가 있음을 알릴 수 있습니다. 각 기간마다 무작위로 10명의 위임자를 포함 목록 제공자(inclusion list provider)로 선택하고, 10,000명의 추가 위임자를 유권자로 선택합니다. 이들은 k 슬롯 이전에 선택되며, 체인에서 온라인 상태를 확인하는 메시지를 게시할 수 있는 k 슬롯 창을 부여받습니다. 각 확인된 선택의 포함 목록 제공자는 포함 목록을 게시할 수 있으며, 각 포함 목록에 대해 해당 포함 목록의 거래를 포함하거나 일반적으로 선택된 유권자의 투표를 포함해야 하며, 그렇지 않으면 블록은 무효로 간주됩니다.

이러한 소규모 스테이킹 노드들의 공통점은 그들이 각 슬롯에 적극적으로 참여할 필요가 없으며, 심지어 경량 노드만으로도 모든 작업을 수행할 수 있다는 것입니다. 따라서 노드 배포는 합의 층을 검증하는 것만 필요하며, 노드 운영자는 애플리케이션이나 브라우저 플러그인을 통해 이를 구현할 수 있습니다. 이러한 애플리케이션이나 브라우저 플러그인은 대부분 수동적이며, 계산 오버헤드, 하드웨어 요구 사항 또는 기술적 전문 지식의 요구가 낮고, 심지어 ZK-EVM과 같은 고급 기술이 필요하지 않습니다.

이러한 "소규모 역할"들은 모두 하나의 공통 목표를 가지고 있습니다: 51%의 다수 노드 운영자가 거래 검열을 수행하는 것을 방지하는 것입니다. 첫 번째와 두 번째는 다수가 최종성을 복원하는 것을 방지할 수 있습니다. 세 번째는 검열에 더 직접적으로 초점을 맞추지만, 다수 노드 운영자의 선택에 더 쉽게 영향을 받을 수 있습니다.

이러한 아이디어는 프로토콜 내에서 이중 스테이킹 솔루션을 구현하는 관점에서 작성되었지만, 스테이킹 풀의 기능으로도 구현될 수 있습니다. 다음은 몇 가지 구체적인 구현 아이디어입니다:

1. 프로토콜 관점에서 각 검증자는 두 개의 스테이킹 키를 설정할 수 있습니다: 하나는 지속 스테이킹 키 P이며, 바인딩된 호출 가능한 이더리움 주소와 연결되어 있으며, 다른 하나는 빠른 스테이킹 키 Q입니다. 노드의 분기 선택 서명 정보는 P로 표시되며, 서명된 정보는 Q로 표시됩니다. 만약 PQ 저장 결과가 일치하지 않으면 어떤 블록의 최종 확인도 수용되지 않으며, 유동성 풀은 무작위로 대표를 선택하는 책임을 집니다.
2. 프로토콜은 대체로 변경되지 않지만, 해당 검증자의 공개 키는 해당 기간 동안 P+Q로 설정됩니다. 감축을 위해 두 개의 감축 가능한 메시지가 서로 다른 Q 키를 가질 수 있지만, 동일한 P 키를 가질 것입니다; 감축 설계는 이러한 상황을 처리해야 합니다.
3. Q 키는 프로토콜 내에서 블록의 포함 목록에 서명하고 검증하는 데만 사용될 수 있습니다. 이 경우 Q는 단일 키가 아닌 스마트 계약이 될 수 있으며, 따라서 스테이킹 풀은 이를 사용하여 더 복잡한 투표 논리를 구현하고 무작위로 선택된 제공자로부터 포함 목록을 수용하거나 포함 목록이 사용 불가능하다는 충분한 투표를 수용할 수 있습니다.

결론

올바르게 구현된다면, 지분 증명 설계의 미세 조정은 두 가지 문제를 동시에 해결할 수 있습니다:

1. 오늘날 독립 지분 증명을 수행할 자원이나 능력이 없는 사람들에게 지분 증명에 참여할 기회를 제공하여 그들의 손에 더 많은 권력을 보존할 수 있습니다: (i) 어떤 노드를 지원할지를 선택할 권리와 (ii) 완전한 운영 지분 증명 노드보다 더 가벼운 방식으로 합의에 적극적으로 참여할 수 있는 기회. 모든 참여자가 이 중 하나 또는 두 가지 옵션을 선택하지는 않겠지만, 어떤 참여자가 이 중 하나 또는 두 가지 옵션을 선택하면 현 상태에 비해 상당한 개선이 이루어질 것입니다.
2. 이더리움 합의 층이 각 슬롯에서 처리해야 하는 서명 수를 줄입니다, 단일 슬롯 최종성 제도 하에서도 약 10,000개와 같은 작은 수치로 줄일 수 있습니다. 이는 탈중앙화에도 도움이 되며, 모든 사람이 검증 노드를 운영하기 더 쉽게 만듭니다.

이러한 솔루션은 다양한 추상적 수준에서 문제를 해결할 수 있는 방법을 찾을 수 있습니다: 지분 증명 프로토콜 내에서 사용자에게 부여된 권한, 지분 증명 프로토콜 간의 사용자 선택, 그리고 프로토콜 내에서의 설정. 이러한 선택은 신중하게 고려되어야 하며, 일반적으로 프로토콜의 복잡성과 프로토콜 경제학의 변경 정도를 최소화하면서도 여전히 원하는 목표를 달성하는 최소한의 실행 가능한 설정을 선택하는 것이 가장 좋습니다.