이더리움 프로토콜을 넘어서: 제안자-빌더 분리 (PBS)
이더리움에서 블록 생성과 블록 제안의 역할을 분리하는 디자인 패턴인 제안자-빌더 분리(PBS)에 대한 프레젠테이션입니다.
Date published: 2024년 2월 5일
이 프레젠테이션은 이더리움의 블록 생성이 단순한 모델에서 검증자, 빌더, 서처, 릴레이가 참여하는 정교한 공급망으로 어떻게 진화했는지 설명합니다. 이더리움 재단의 바나베 모노(Barnabé Monnot)는 제안자-빌더 분리(PBS)가 존재하는 이유, MEV-Boost 릴레이가 제안자와 빌더 간의 관계를 중재하는 방법, 그리고 신뢰 의존성을 줄이고 검열 저항성, MEV 분배 및 검증자 탈중앙화를 개선하기 위해 탐구되고 있는 프로토콜 내 솔루션에 대해 설명합니다.
이 스크립트는 CBER 포럼에서 게시한 원본 비디오 스크립트 (opens in a new tab)의 접근성 향상 버전입니다. 가독성을 위해 약간 편집되었습니다.
소개 (0:00)
제 이름은 바나베 모노(Barnabé Monnot)입니다. 저는 프로토콜 외부에서 일어나고 있는 일, 특히 제안자-빌더 분리(PBS)의 개념과 이것이 릴레이 및 수많은 오프체인 인프라와 함께 어떻게 운영되는지에 대해 조금 이야기해 보려고 합니다.
저는 프로토콜을 특정한 힘을 가진 추상적인 객체로 생각하는 것을 좋아합니다. 프로토콜이 가진 힘 중 하나는 특정 참여자에게 권한을 부여할 수 있다는 것입니다. 이전 발표에서 프로토콜이 검증자에게 합의 의무를 수행할 권한을 부여한다는 것을 보았지만, 그것이 그들이 하는 유일한 일은 아닙니다. 우리는 또한 트랜잭션으로 블록을 채워야 합니다. 우리는 이를 실행 의무라고 부르며, 이번 발표에서는 바로 이 부분에 초점을 맞추고자 합니다.
검증자가 빌더를 사용하는 이유 (0:46)
흥미로운 점은 프로토콜이 이러한 권한을 생성하여 검증자에게 부여함에도 불구하고, 실제로는 많은 검증자가 그 권한을 직접 행사하지 않기로 선택한다는 것입니다. 그들은 자신을 대신하여 권한을 행사할 다른 누군가에게 그 권한을 넘기기로 선택합니다. 그리고 이더리움에서 그 "다른 누군가"를 우리는 빌더라고 부릅니다.
따라서 우리가 관찰하는 바는 검증자가 합의 의무는 계속해서 직접 수행하지만, 실행 의무는 빌더에게 넘기기로 결정한다는 것입니다. 이는 사실 꽤 큰 시장입니다. 오늘날 블록의 약 90%가 외부 빌더에 의해 생성되며, 이는 머지(The Merge) 이후 3개월이 지난 2022년 12월경부터 지속된 현상입니다. 빌더가 검증자에게 지불하는 중간값은 블록당 약 120달러입니다. 매일 백만 달러가 지급되며, 12초마다 이 시장에서 한 명의 제안자와 한 명의 빌더 간에 일종의 합의가 이루어질 가능성이 열립니다.
오늘 저는 검증자가 왜 빌더를 사용하는지, 그 관계가 어디서 비롯되는지 논의하고자 합니다. 그 과정에서 MEV와 서처에 대해서도 조금 소개할 것입니다. 그런 다음 이 관계가 어떻게 중재되는지 설명하고, 현재 존재하는 릴레이와 우리가 고려하고 있는 프로토콜 내 솔루션에 대해 이야기하겠습니다. 또한 시야를 조금 넓혀보고 싶습니다. 왜냐하면 이러한 상황을 보고 "오, 이건 너무 무서운데, 탈중앙화는 어떻게 되는 거지?"라고 생각하기 쉽기 때문입니다. 저는 이것이 우리가 감수하고 있는 절충안(tradeoff)이지만, 제 생각에는 올바른 방향으로 나아가고 있다는 점을 여러분께 알려드리고 싶습니다.
단순한 모델과 MEV (3:04)
리더 선출 과정에 따라 검증자가 선택되고, 그들이 멤풀에서 가져온 트랜잭션 목록을 포함하는 블록을 생성해야 하는 단순한 블록 생성 모델을 생각해 볼 수 있습니다. 가장 단순한 모델에서는 멤풀을 모니터링하는 검증자와, 블록을 생성할 차례가 되었을 때 가장 많은 수수료를 지불하는 트랜잭션을 꺼내어 추가하는(보통 그다지 정교하지 않은 패킹 알고리즘을 사용하여) 두 당사자만 존재합니다.
지난 5년 동안 매우 극적으로 관찰된 사실은 이것이 생성자에게 막대한 권한, 특히 마지막으로 확인할 수 있는 권한(power of last look)을 부여한다는 것입니다. 그들은 사용자가 무엇을 하고 싶어 하는지, 예를 들어 사용자가 무언가를 스왑하고 싶어 한다는 것을 볼 수 있으며, 그 정보를 사용하여 자신들의 이익을 추출할 수 있습니다.
최선의 경우 이 이익은 차익 거래와 같은 자연스러운 시장 기능에서 발생합니다. 최악의 경우 샌드위치 공격과 같이 사용자의 주머니에서 직접 나올 수도 있습니다. 예를 들어, 사용자가 유니스왑과 같은 시장에서 토큰 A를 토큰 B로 스왑하는 주문을 합니다. 해당 트랜잭션은 동일한 체인에 배포된 다른 시장과 가격 불균형을 일으킬 것입니다. 생성자는 대기 중인 트랜잭션을 보고 다른 시장에서 반대 방향으로 스왑하는 자신의 트랜잭션을 삽입하여 그 과정에서 차익을 챙길 수 있습니다.
이는 생성자에게 정말 많은 권한을 부여하며 블록 생성자라는 위치를 매우 가치 있게 만듭니다. 이러한 생성자의 특권을 우리는 이제 최대 추출 가능 가치(MEV)라고 부릅니다.
서처의 역할 (5:43)
실제로는 생성자가 가치가 어디에 있는지 모를 수도 있습니다. 다소 정교하지 않은 블록 생성자가 있을 수 있습니다. 앞서 언급했듯이 충분한 자본이 있고 노드를 운영할 수 있다면 누구나 검증자가 될 수 있습니다. 실제로 저는 차익 거래를 하는 방법이나 금융 시장에 대해 아무것도 모를 수 있습니다. 제가 원하는 것은 누군가가 저에게 이러한 기회가 어디에 있는지 알려주는 것입니다. 즉, 블록 생성자로서 무엇을 하는 것이 최선인지 저에게 알려주기 위해 경쟁하는 사람들의 시장입니다.
기회를 찾는 데 매우 능숙한 이러한 주체들을 우리는 서처라고 부릅니다. 이들은 블록 생성자에게 기회를 드러내 줍니다. 서처는 공개 멤풀이나 다크 풀, 또는 프라이빗 채널을 통해 사용자가 스왑을 하는 것을 관찰한 다음 검증자에게 다음과 같이 전달할 수 있습니다. "스왑이 발생하고 있습니다. 이 스왑을 이 차익 거래와 함께 원자적(atomic) 트랜잭션 번들로 묶어서 포함시키면 차익 거래를 통해 돈을 벌 수 있습니다." 블록 생성자를 설득하기 위해 경쟁하는 많은 서처가 생기게 됩니다.
이 모델은 서처가 생성자가 번들을 원자적으로 유지할 것이라고 신뢰하는 경우에만 실제로 잘 작동합니다. 최근 이더리움에서 여러 샌드위치 공격자들에게 2,500만 달러의 손실을 입힌 공격에 대해 들어보셨을 것입니다. 근본적인 원인은 공격자가 번들의 원자성을 깨뜨리고 내용을 수신하여 재구성하고 수정하려고 시도했기 때문입니다. 이는 생성자가 이 원자성을 깨지 않을 것이라고 신뢰할 수 있는 한에서만 유지되는 매우 중요한 속성입니다.
빌더가 필요한 이유 (8:16)
생성자를 신뢰할 수 없다면 어떻게 해야 할까요? 이더리움의 머지 이후, 네트워크의 약 6%를 차지하는 우리가 알지 못하는 솔로 스테이커들이 있습니다. 서처들은 너무 위험하기 때문에 이러한 블록 제안자들에게 번들을 보내고 싶어 하지 않을 것입니다.
그래서 도달한 설계는 다음과 같습니다. 서처가 번들을 전달하고 생성자가 이를 블록에 포함시키는 대신, 우리가 당신을 위해 전체 블록을 만들어 주겠다는 것입니다. 그렇게 하면 당신은 블록에 맹목적으로 서명하기만 하면 됩니다. 그 안에 무엇이 있는지 알 필요가 없으며, 빌더가 좋은 블록을 제공하고 있다고 신뢰하면 됩니다.
이제 한쪽 끝에는 검증자가, 다른 쪽 끝에는 사용자가 있으며, 그 사이에는 시간이 지남에 따라 계속해서 밀도가 높아지는 중개자들의 전체 체인이라는 훨씬 더 깊은 체인이 생겼습니다. 빌더는 실행 부분을 담당하고 검증자는 합의를 담당합니다.
MEV-Boost 릴레이의 작동 방식 (13:01)
여러분이 제안자이고 이 시장에 진입하고 싶다고 가정해 보겠습니다. 이 블록 생성 서비스는 고전적인 공정 교환(fair exchange) 문제입니다. 두 당사자가 합의에 도달하려고 하지만 서로를 신뢰하지 않습니다. 고전 문헌에 따르면 신뢰할 수 있는 제3자 없이는 공정 교환을 할 수 없습니다.
오늘날 우리가 신뢰할 수 있는 제3자로 사용하는 것을 릴레이, 즉 MEV-Boost 릴레이라고 부릅니다. MEV-Boost는 빌더와 검증자 간의 상호 작용을 중재하는 프로토콜의 이름입니다. 릴레이는 중간에 위치하여 양측의 합의가 성사되도록 보장합니다.
릴레이는 몇 가지 역할을 합니다. 첫째, 빌더의 페이로드를 검증해야 합니다. 릴레이는 빌더가 생성하는 블록을 명확하게 확인하고 유효한지, 네트워크에 제안될 수 있는지 확인할 수 있습니다. 낙관적 릴레이(optimistic relay)라는 변형도 있는데, 여기서는 릴레이가 즉시 유효성을 확인하지 않고 블록이 최종적으로 유효하지 않을 경우를 대비해 빌더에게 담보를 요구합니다.
둘째, 빌더들은 검증자가 선택하는 빌더가 되기 위해 경쟁하며 입찰을 합니다. 릴레이는 입찰 전달자 역할을 하여 검증자에게 입찰을 보냅니다. 그런 다음 마지막 단계에서 검증자가 릴레이로부터 입찰 중 하나를 선택하면(검증자는 원하는 만큼 많은 릴레이에 연결할 수 있습니다), 여전히 블록 내용이 무엇인지 모르는 상태에서 서명하고 서명된 입찰을 릴레이로 다시 보냅니다. 이 서명된 입찰을 받으면 릴레이는 블록을 네트워크에 릴리스할 수 있습니다.
릴레이의 경제학은 복잡합니다. 일부는 공공재처럼 무료입니다. 다른 릴레이들은 수익 모델을 개발했습니다. 예를 들어 Ultrasound 릴레이는 최고 입찰가와 두 번째로 높은 입찰가의 차액을 수익으로 취하는 "입찰 조정(bid adjustment)"을 사용합니다.
신뢰와 릴레이 (17:01)
릴레이는 시스템에서 신뢰할 수 있는 제3자입니다. 릴레이가 유효하지 않은 블록을 제공한다고 가정해 보겠습니다. 서명되어 있기 때문에 사람들은 즉시 이를 알게 될 것이고, 매우 빠르게 해당 릴레이와의 연결을 끊을 것입니다. 심지어 일종의 결함 증명을 가십(gossip)할 수도 있습니다. 5개의 블록 내에 릴레이가 제대로 작동하지 않으면 사람들은 신뢰를 멈추고 연결을 끊어버릴 것입니다.
따라서 이는 신뢰를 기반으로 하지만 다소 빠르게 교체될 수 있다는 가정을 전제로 합니다. 릴레이는 검증자가 아닙니다. 반드시 스테이크를 가질 필요도 없고 이더리움과 아무런 관련이 없어도 됩니다. 오늘날 우리가 알고 사랑하는 사람들일 수도 있지만, 내일은 누구라도 될 수 있습니다.
프로토콜에 PBS 도입하기 (20:01)
우리는 릴레이의 신뢰할 수 있는 제3자 지위를 제거하려고 노력하고 있습니다. 이더리움에는 우리가 좋아하는 신뢰할 수 있는 제3자가 있으며, 그것은 바로 이더리움 자체입니다. 본질적으로 릴레이의 역할을 내재화하고 이에 대한 의존성을 선택 사항으로 만드는 프로토콜 내 솔루션을 설계할 수 있습니다.
현재 이더리움 프로토콜은 검증자가 수행하는 작업의 일부는 볼 수 있지만 빌더 네트워크에 대해서는 완전히 알지 못합니다. 우리는 이더리움 프로토콜이 제안자와 빌더 간의 상호 작용에서 신뢰할 수 있는 제3자가 되도록 추진하고 있습니다. 그런 의미에서 우리는 더 이상 릴레이에 의존할 필요가 없습니다.
빌더 제약 및 탈중앙화 강화 (22:05)
전체적인 그림을 보는 것이 중요합니다. 모든 계층에서 서로 다른 게임이 벌어지고 서로 다른 플레이어들이 서로의 돈을 가져가는 것처럼 보입니다. 이것이 전통 금융의 반복일까요? 저는 이러한 절충안이 나쁜 의도에서 비롯된 것이 아니라고 주장하고 싶습니다. 이들은 시스템을 확장하고 더 유용하게 만드는 데 도움이 된다고 생각하는 시스템의 속성에 기대려고 노력합니다.
비탈릭(Vitalik)은 블록체인이 제공할 수 있는 서비스의 근본적인 비대칭성에 대해 이야기했습니다. 합의에는 견제를 유지하는 매우 크고 탈중앙화된 사람들의 집단이 필요합니다. 하지만 어떤 서비스는 한 사람이 일을 잘 수행하고 다른 모든 사람이 그 일이 잘 수행되었는지 검증하는 것만으로 충분합니다. 블록을 생성하는 데는 단 한 명의 빌더만 필요하며, 그런 다음 모든 사람이 그것이 유효한지 검증할 수 있습니다.
오늘날에는 Beaver Build, Titan, rsync Builder라는 세 개의 지배적인 빌더가 분명히 존재합니다. 이것이 좋은 상태일까요? 그렇지 않습니다. 우리는 더 잘할 수 있습니다. 하지만 검증자만큼 많은 빌더를 갖게 될 것이라고 상상하는 것이 현실적일까요? 아마 아닐 것입니다.
우리가 진정으로 원하는 것은 정직한 다수(honest majority) 가정이 필요하지 않은 작업을 수행할 수 있는 강력한 주체들이 중간에 존재한다는 사실을 제약하고 활용하는 얇은 검증자 계층입니다.
빌더를 제약하기 위한 몇 가지 아이디어:
- 포함 목록(Inclusion lists) — 검증자가 빌더에게 "이 트랜잭션들을 블록에 포함해야 합니다"라고 지시하는 것
- 부분 블록 생성(Partial block building) — 빌더가 모든 공간을 독점하지 않도록 전체 블록을 분할하는 것
- 제3자 의존성 감소 — 프로토콜에 릴레이 역할을 내재화하는 것
검증자 탈중앙화를 강화하기 위해:
- 증명자-제안자 분리(Attester-proposer separation) — 기본적으로 검증자를 블록 생성자로 만드는 대신, 블록 생성자가 될 다른 사람들의 집단을 선택하고 역할을 분리하는 것
- 개선된 스테이킹 메커니즘 — 오늘날 이더리움의 스테이킹은 다소 초보적인 수준이며 개선될 수 있습니다.
질문 및 마무리 (27:03)
청중의 질문: 전통 금융 세계에서는 정산 시간이 이틀에서 하루로 단축되고 있습니다. 정산 시간을 12초에서 더 짧은 간격으로 줄이면 프론트러닝 문제 중 일부를 해결할 수 있을까요?
사람들은 이에 대해 이야기하고 있으며, 이를 사전 확인(pre-confirmations)이라고 부릅니다. 아이디어는 트랜잭션을 보내면 누군가가 "당신은 이 가격에, 이 상태에 포함되었습니다"라고 알려주는 것입니다. 문제는 프로토콜이 실행되는 것보다 더 빨리 정산할 수 없다는 것입니다. 12분보다 더 빠른 완결성 정산을 얻을 수 없습니다. 블록 타임보다 더 빨리 움직일 수 없습니다.
블록 타임을 단축하는 것은 어렵습니다. 왜냐하면 우리는 검증자 계층을 가능한 한 탈중앙화된 상태로 유지하고 싶어 하며, 이를 단축하면 하드웨어 요구 사항만 증가하기 때문입니다.