이더리움 연구원 및 a16z 연구원 공동 집필: 블록 공간 할당 메커니즘
저자: mike, 이더리움 연구원; Pranav Garimidi, Tim Roughgarden, a16z 연구원
번역: 0XNATALIE
이더리움 연구원인 mike와 a16z 연구원인 Pranav Garimidi, Tim Roughgarden가 공동 집필한 논문 "On block-space distribution mechanisms"은 블록 공간 할당 메커니즘이 MEV에 어떻게 영향을 미치는지를 체계적으로 탐구한다. 먼저 프로토콜 내 메커니즘을 통해 블록 공간을 처리할 필요성을 설명하고, 「누가(Who), 무엇을(What), 언제(When), 어디서(Where), 어떻게(How)」(W^4H)라는 프레임워크를 사용하여 기존의 다양한 할당 방안들을 평가 및 비교한다. 이후 실행 티켓(execution tickets) 모델이 MEV 인식성과 할당 공정성 사이에서 어떤 균형을 이루는지 심층적으로 분석한다. 다음은 해당 논문의 번역본이다.
TL;DR: 블록 공간, 즉 거래 포함 용량은 블록체인이 생성하는 주요 자원이다. 암호화 생태계가 확장되고 전문화됨에 따라 블록 공간을 효율적으로 활용함으로써 발생하는 가치(MEV)는 허가 없는 합의 메커니즘의 경제학에서 중요한 역할을 한다. 연구 커뮤니티는 프로토콜이 MEV에 어떻게 대응해야 하는지에 대해 많은 논의를 해왔다(관련 연구 참고). 지난 몇 년간의 논의는 마치 '맹인과 코끼리' 이야기처럼, 각기 다른 관점, 해결책, 이론들이 제시되었지만 전체 그림 없이 조각조각 나뉘어 있어 서로 비교하기 어려웠다. 본 논문의 전반부는 핵심 질문들을 추출하고 기존 제안들이 이를 어떻게 다루고 있는지를 탐색함으로써, MEV라는 '코끼리'의 전체 모습을 제시하려는 목적을 가진다. 후반부에서는 실행 티켓 기반의 할당 메커니즘을 중심으로, 프로토콜 내 MEV 오라클의 정확성과 메커니즘의 공정성 사이에 존재하는 트레이드오프(trade-off)라는 새로운 통찰을 제시한다.
논문 구조: 1절에서는 포스트-스테이크(Post-Stake)의 '최종 상태(finality)' 일부로서 블록 공간 할당을 위한 프로토콜 내 메커니즘이 필요한 이유를 설명한다. 2절에서는 W^4H 질문들(누가, 무엇, 언제, 어디서, 어떻게)이라는 친숙한 프레임워크를 이용해 블록 공간 할당 메커니즘을 평가할 수 있는 다섯 가지 차원을 제시한다. 3절에서는 블록 빌더 선택 문제에 초점을 맞추며 특히 실행 티켓 모델을 탐구한다. 4절에서는 요약과 함께 향후 개방된 질문들을 제시하며 논의를 확장한다.
설명: 본 논문은 다소 길며 기술적인 내용을 일부 포함한다. 독자들은 관심 있는 부분에만 집중하는 것을 권장한다. 1, 2, 4절은 기존 제안들과 우리가 제시하는 분석 방법에 대한 광범위한 시각을 제공한다. 3절(전체 분량의 약 44%를 차지하며 모든 수학적 내용을 포함)은 실행 티켓 설계를 통해 가능해지는 할당 메커니즘에 대한 상세한 분석을 제공한다. 이 섹션은 순차적으로 읽거나 독립적으로 읽거나 아예 건너뛰어도 무방하다—선택은 독자에게 달렸다!
(1) 동기
이 복잡한 주제를 깊이 있게 파고들기 전에, 우선 블록 공간 할당 메커니즘의 필요성에 대해 간략히 설명하겠다. 포스트-스테이크(PoS)에서 검증자의 역할은 블록을 생성하고 투표하는 것이다. 아래 이미지는 Barnabé의 글 "More pictures about proposers and builders"에서 발췌한 것으로, 이를 제안(proposing)과 증거(attesting) 권리로 묘사한다.
1) 무엇인가?
블록 공간 할당 메커니즘은 프로토콜이 '제안' 또는 '블록 빌딩' 권리를 누구에게 부여할지를 결정하는 과정이다. PoS 프로토콜은 일반적으로 다음과 같은 규칙 중 하나를 사용한다:
-
블록 공간(제안) 권리 – 검증자를 무작위로 선택하여 리더로 삼고, 다음 블록 생성을 허용한다.
-
투표(증거) 권리 – 모든 검증자가 특정 시간 창 내에서 자신이 정규 헤드라고 생각하는 블록에 투표한다.
검증자는 이러한 작업 수행에 대한 보상을 받는다. 우리는 보상의 출처에 따라 이를 컨센서스 레이어(프로토콜 발행, 예: 새로 발행되는 ETH) 또는 실행 레이어(거래 수수료 및 MEV)로 분류한다:
컨센서스 레이어
a. 증거 보상 – (attestation deltas 참조).
b. 블록 보상 – (get_proposer_reward 참조).
실행 레이어
a. 거래 수수료 – (gas tracker 참조).
b. MEV(거래 정렬) – (mevboost.pics 참조).
보상 1a, 1b, 2a는 잘 알려져 있으며 프로토콜 내에서 명확하게 인식된다. 반면 MEV 보상은 거래 정렬을 통해 실현되는 가치를 완전히 측정하기 어렵기 때문에 도전 과제가 된다. 다른 보상과 달리, 블록 내 MEV 양은 사실상 알 수 없다(허가되지 않은 익명 시스템에서 각 계정 소유자와 관련된 체외 활동을 모두 추적하는 것은 불가능하다). MEV는 또한 시간에 따라 격렬하게 변동한다(예: 가격 변동 등)하여 실행 레이어 보상의 분산이 컨센서스 레이어보다 더 크다. 게다가 이더리움 프로토콜은 구현 당시 거래로부터 발생하고 추출되는 MEV에 대해 전혀 인식하지 못한다. 프로토콜의 MEV 가시성을 향상시키기 위해 많은 메커니즘이 주어진 블록의 MEV를 추정하려 하며, 이를 우리는 MEV 오라클이라 부른다. 블록 공간 할당 메커니즘은 일반적으로 그러한 오라클을 생성할 능력을 가지므로 프로토콜이 'MEV를 인식'하도록 만든다.
이러한 맥락에서 프로토콜이 왜 MEV 인식에 관심을 가져야 하는가? 한 가지 답변은: MEV 인식이 검증자들의 복잡성 수준이 다를 때에도 보상을 균등하게 유지할 수 있는 프로토콜의 능력을 높일 수 있다는 점이다. 예를 들어, 프로토콜이 모든 MEV를 정확히 소각할 수 있다면, 검증자의 인센티브는 완전히 프로토콜 내에서 통제되게 될 것이다(즉 위의 1a, 1b, 2a와 같아짐). 또는 검증자들의 복잡성과 관계없이 모든 검증자들 사이에서 MEV를 공유하는 메커니즘(예: mev-smoothing)은 더 크고 다양하며 분산된 검증자 집합을 촉진하면서도 MEV 보상을 여전히 추가적인 스테이킹 인센티브로 유지하는 것처럼 보인다. MEV 인식이 없다면, MEV를 가장 잘 추출하거나 평활화할 수 있는 검증자들(예: 블록 빌더와의 관계, 독점 알고리즘/소프트웨어, 독점 주문 흐름 접근, 규모의 경제 등으로 인해)이 비례 이상의 보상을 얻게 되고, 프로토콜에 상당한 중앙집중화 압력을 가하게 된다.
이더리움 프로토콜 설계는 어떤 대가를 치르더라도 분산된 검증자 집합을 유지하려 노력한다. 말할 필요도 없이, 하지만 완결성을 위해 언급하자면: 프로토콜의 신뢰 중립성, 검열 저항성, 허가 없음 여부는 직접적으로 분산된 검증자 집합에 달려 있다.
현재의 블록 공간 할당 방식
오늘날의 이더리움에서는 mev-boost가 약 90%의 블록을 차지하고 있다. mev-boost를 사용하면, 제안자(무작위로 선택된 검증자 리더)는 자신의 블록 빌딩 권리를 가장 높은 입찰을 제시한 입찰자에게 경매를 통해 판매한다. 아래 이미지가 이 과정을 보여준다(릴레이를 제외했는데, 이는 실제로는 빌더의 연장선에 있기 때문이다).
제안자는 블록 빌딩을 외주하는 것이 유리하다. 왜냐하면 빌더들(전문적으로 거래 정렬을 통해 MEV를 추출하는 에이전트)이 자신이 직접 블록을 구성했을 때보다 더 많은 보상을 지불하기 때문이다. 다시 말해, MEV가 존재하는 상황에서도 검증자 보상을 균등하게 유지하려는 우리의 목표를 살펴보면, mev-boost는 모든 검증자가 빌더 시장에 진입할 수 있도록 하여 독립 스테이커와 전문 스테이킹 서비스 제공업체 간의 MEV 보상이 거의 동일하게 유지되도록 한다—좋다! 그러나…
물론 mev-boost에는 여전히 이더리움 커뮤니티의 일부 구성원들을 괴롭히는 문제가 있다. 간단히 말해, mev-boost라는 약물의 부작용은 다음과 같다:
-
릴레이 – 제안자와 빌더 사이에서 블록 판매를 중개하는 이들 신뢰된 제3자들이다. 릴레이에 대한 큰 의존성은 프로토콜 전체의 취약성을 증가시킨다. 예를 들면 반복 공격, 사고, 사건 등이 릴레이를 통해 노출되었다. 또한 릴레이 자체가 고유한 수익원을 가지고 있지 않기 때문에, 더 많은(그리고 폐쇄 소스) 수익 창출 방법들(예: 서비스 형태의 타이밍 게임, 입찰 조정 등)이 시행되고 있다.
-
프로토콜 외부 소프트웨어의 취약성 – 릴레이 외에도, mev-boost 시장에 참여하려면 검증자가 추가 소프트웨어를 실행해야 한다. 독립 스테이킹의 표준 세트는 이제 네 가지 바이너리를 실행해야 한다: (i) 컨센서스 비콘 노드, (ii) 컨센서스 검증자 클라이언트, (iii) 실행 클라이언트, (iv) mev-boost. 이는 독립 스테이커에게 상당한 오버헤드를 더하며, 하드포크 중에 이 소프트웨어에 의존하는 것은 또 다른 잠재적 장애 지점이 된다. Shapella 사건과 Dencun 업그레이드를 보면 프로토콜 외부 소프트웨어로 인한 복잡성을 확인할 수 있다.
-
빌더의 중앙집중화 및 검열 – 피할 수 없는 일일 수도 있지만, mev-boost의 광범위한 채택은 빌더의 중앙집중화를 가속화했다. 세 개의 빌더가 mev-boost 블록의 약 95%(모든 이더리움 블록의 85%)를 차지하고 있다. mev-boost는 공개 호가, 1차 입찰, 승자독식 경매를 시행하고 있어 높은 수준의 빌더 중앙집중화와 전략적 입찰을 초래한다. 포함 리스트나 기타 검열 저항 도구는 아직 시행되지 않았으며, 빌더는 거래 포함 및 배제에 큰 영향력을 행사한다—(censorship.pics 참조).
-
타이밍 게임 – 타이밍 게임은 PoS 프로토콜의 근본적인 문제로 간주되지만, mev-boost는 스테이킹 서비스 제공업체들 간의 얇은 마진 경쟁을 유도한다. 또한 릴레이(me-boost 경매를 제안자 대신 수행)는 복잡한 중개자로서 타이밍 게임을 촉진한다. 따라서 특정 제공업체에 스테이킹함으로써 수익을 높일 수 있다는 마케팅이 이루어지고 있다.
(2) 열거
필수적인 '무대 설정'을 마친 후, 이제 블록 공간 할당 메커니즘의 본질을 좀 더 자세히 살펴보자.
블록 공간 할당의 구성 요소
블록 공간을 획득하는 게임을 생각해보자. MEV는 에이전트들의 참여를 유도하며, 프로토콜 내외부 소프트웨어의 조합이 규칙을 정의한다. 이 게임을 설계할 때 고려해야 할 요소는 무엇인가? 이 질문에 답하기 위해 우리는 '누가(Who), 무엇을(What), 언제(When), 어디서(Where), 어떻게(How)'라는 친숙한 수사적 패턴을 사용하며, 이를 우리는 W^4H 질문이라 부른다.
-
누가 게임 결과를 통제하는가?
-
플레이어들이 경쟁하는 상품은 무엇인가?
-
게임은 언제 발생하는가?
-
MEV 오라클은 어디서 오는가?
-
블록 빌더는 어떻게 선택되는가?
이 질문들은 단순해 보이지만, 각각을 따로 고려하면 메커니즘 설계 공간을 측정하는 하나의 축으로 볼 수 있다. 이를 입증하기 위해, 우리는 과거에 탐구된 다양한 블록 공간 할당 메커니즘의 종류들을 강조한다. 처음에는 관련성이 없어 보일 수 있지만, 그것들이 W^4H 질문에 어떻게 답하는지를 이해하면 그들 사이의 관계가 명확해진다.
실행 티켓과 기타 방법
우리는 다양한 제안 메커니즘의 개요를 제시한다. 이는 주변에 존재하는 방대한 문헌의 일부에 불과하다—(infinite buffet 참조). 아래 각 항목에 대해서는 핵심 아이디어만 요약한다(관련 연구 참조).
실행 티켓
핵심 아이디어: 블록 빌딩과 제안 권리는 프로토콜이 발행하는 '티켓'을 통해 직접 판매된다. 티켓 소지자는 무작위로 블록 빌더로 추출되며, 미리 통보받는다. 티켓 소지자는 할당된 시간 동안 블록을 생산할 권리가 있다.
블록 경매 PBS (Proposer-Builder Separation)
핵심 아이디어: 프로토콜은 무작위 리더 선출 과정을 통해 블록 생산 권리를 부여한다. 선택된 검증자는 자신의 블록을 빌더 시장에 직접 판매하거나 로컬에서 구성할 수 있다. 빌더는 경매에서 특정 블록을 약속해야 한다. mev-boost는 블록 경매 PBS의 프로토콜 외부 실례이며, 원래 제안된 ePBS는 프로토콜 내부의 동등한 개념이다.
MEV 소각 / MEV 평활화
핵심 아이디어: 위원회가 제안자가 경매에서 선택한 입찰에 최소값을 설정하는 책임을 진다. 제안자가 '충분히 큰' 입찰을 선택하도록 요구함으로써 MEV 오라클을 생성한다. MEV는 위원회 구성원들 사이에서 평활화되거나 소각된다(모든 ETH 보유자들에게 평활화).
슬롯(slot) 경매 PBS
핵심 아이디어: 블록 경매 PBS와 유사하지만, 빌더 시장에 특정 블록을 약속하지 않고 슬롯을 판매한다는 점에서 다르다—때로는 블록 공간 선물이라고도 한다. 빌더가 특정 블록을 약속할 필요가 없기 때문에, 미래의 슬롯을 현재보다 훨씬 일찍 경매할 수 있다.
부분 블록 경매
핵심 아이디어: 블록 공간의 더 유연한 단위를 판매할 수 있도록 한다. 전체 블록이나 슬롯을 판매하는 대신, 제안자가 블록의 _일부_를 판매할 수 있도록 하며, 예를 들어 블록 상단(알고리스트에게 가장 가치 있음)을 판매하고 나머지 블록 구성은 자신이 보유한다. Jito의 블록 엔진, Skip MEV lane 등 다른 PoS 네트워크에서 운영 중이다.
APS 소각 즉시 실행 경매
핵심 아이디어: Barnabé의 새로운 제안으로, 제안자가 블록 빌딩 및 제안 권리를 미리 경매하도록 강제한다. 슬롯이 미리 고정된 시간만큼 판매되며, 특정 블록을 약속할 필요는 없다. 위원회(MEV 소각/평활화와 동일)가 입찰이 충분히 크도록 보장한다.
이 제안들이 W^4H 질문에 어떻게 답하는지를 비교함으로써, 그것들이 동일한 설계 공간 내의 다른 부분임을 알 수 있다.
W^4H 적용: 비교 분석
각 W^4H 질문에 대해, 위 제안들 사이의 다양한 트레이드오프를 설명한다. 간결성을 위해 각 제안마다 모든 질문을 분석하지는 않고, 각 질문별로 나타나는 핵심 차이점에 초점을 맞춘다.
누가 게임 결과를 통제하는가?
-
실행 티켓 메커니즘에서는 프로토콜이 티켓 소지자를 무작위로 선택함으로써 게임의 승자를 결정한다.
-
블록 경매 PBS에서는 제안자(프로토콜이 선출한 리더)가 게임의 승자를 일방적으로 선택한다.
-
MEV 소각 메커니즘에서는 제안자가 여전히 승자를 선택하지만, 승리한 입찰은 위원회의 제약을 받으므로 제안자의 자율성이 줄어든다.
경쟁 대상은 무엇인가?
-
블록 경매 PBS에서는 전체 블록이 판매되지만, 입찰은 블록 내용을 약속해야 한다.
-
슬롯 경매 PBS에서는 전체 블록이 판매되지만, 특정 블록 내용을 약속할 필요는 없다.
-
부분 블록 PBS에서는 블록의 일부가 판매된다.
게임은 언제 발생하는가?
-
블록 경매 PBS에서는 경매가 슬롯 기간 중에 발생한다.
-
슬롯 경매 PBS에서는 블록 내용 약속이 필요 없으므로, 여러 슬롯(예: 32개) 전에 경매가 발생할 수 있다.
-
실행 티켓 메커니즘에서는 티켓이 고정된 사전 통보 기간의 슬롯에 할당된다.
MEV 오라클은 어디서 오는가?
-
MEV 소각/평활화 메커니즘에서는 위원회가 선택된 입찰이 충분히 크도록 강제하며, 이 입찰이 바로 오라클이 된다.
-
실행 티켓 메커니즘에서는 티켓의 총비용이 오라클이 된다.
블록 빌더는 어떻게 선택되는가?
-
블록 경매 PBS에서는 외주된 블록 생산은 모두 승자독식이며, 최고 입찰자가 블록 빌딩 권리를 얻는다.
-
실행 티켓 메커니즘에서는 다양한 할당 메커니즘을 구현할 수 있다. 예를 들어 원래 제안에서는 티켓을 무작위로 선택하며, 메커니즘은 '티켓 수에 비례하여 분배'된다. 이 경우 최고 입찰자(가장 많은 티켓을 가진 자)는 단지 가장 높은 당첨 확률을 가지며, 블록 빌딩 권리를 보장받지는 않는다.
위 내용이 난해하게 느껴진다면 걱정하지 말라. 다음 섹션에서 이러한 다양한 할당 메커니즘을 깊이 있게 살펴볼 것이다.
동기 재확인
계속 진행하기 전에, 우리의 초기 동기를 다시 한번 상기해보자:
블록 공간 할당 메커니즘은 MEV가 존재하는 상황에서도 검증자 보상의 동질성을 유지하는 것을 목표로 한다.
이것은 좋은 기초이지만, 이것이 유일한 목표라면 왜 mev-boost를 계속 사용하지 않을까? 기억하라, mev-boost는 우리 최종 프로토콜이 저항해야 할 수 있는 부정적인 영향들을 가지고 있다. 우리는 블록 공간 할당 메커니즘의 다른 네 가지 잠재적 설계 목표를 강조한다:
-
더 넓은 범위의 빌더 경쟁을 장려한다.
-
검증자와 빌더 사이의 신뢰 가능한 상호작용을 허용한다.
-
기반 레이어 프로토콜에 MEV 인식을 통합한다.
-
검증자 보상에서 MEV를 완전히 제거한다.
주의할 점은 (1,2,3)은 비교적 논란이 적지만 (4)는 더 논란이 많다는 점이며, (3)을 전제로 한다. 프로토콜은 MEV 보상을 제거함으로써 컨센서스 레이어 보상(프로토콜이 통제하는 부분)이 전체 시스템 인센티브를 더 정확하게 반영하도록 만들 수 있다. 이것은 스테이킹 거시경제와 프로토콜 발행 등의 문제에도 연결되며, 정치적으로 더 민감한 논의가 될 수 있다. 반면 MEV 보상은 네트워크 사용의 부산물이며, MEV는 네이티브 토큰의 가치 포획 메커니즘으로 간주될 수 있다. 우리는 여기서 이러한 문제를 해결하려 하지 않지만, 다양한 선택지가 메커니즘 설계에 어떻게 영향을 미치는지를 탐구할 것이다.
우리는 이러한 기대에 부합하기 위해 프로토콜 설계 수준에서 무엇을 할 수 있을까? 위에서 언급했듯이, 고려해야 할 많은 트레이드오프가 있지만, 다음 섹션에서는 '블록 빌더는 어떻게 선택되는가?'에 초점을 맞춰 일부 개선을 시도할 것이다.
(3) 질문
편집자 주: 앞서 언급했듯이, 이 섹션은 다른 섹션보다 더 길고 기술적이다—시간(또는 관심)이 제한적이라면 4절로 바로 넘어가도 좋다.
부분 목표: 두 가지 가장 익숙한 블록 제안 권리 할당 방식(이를 우리는 '비례 전액 지불(Proportional-all-pay)'과 '승자독식(Winner-take-all)'이라 부른다) 사이에서, MEV 오라클의 질과 메커니즘의 공정성 간의 정량적 트레이드오프를 보여주는 것.
우리는 다음 하위 섹션들을 통해 이 목표를 달성할 것이다:
기초
실행 티켓이 가능하게 하는 할당 메커니즘을 깊이 파고들기 전에, 먼저 모델을 설정해야 한다. 다음과 같은 규칙으로 실행 티켓을 판매하는 프로토콜을 생각해보자:
-
가격은 1 WEI로 고정되며,
-
티켓은 무제한으로 구매 및 판매할 수 있다.
참고: 이러한 형태의 실행 티켓은 실제로 두 가지 독립적인 스테이킹 메커니즘(증거용과 제안용)을 만드는 것과 동일하다. 프로토콜에 대한 티켓 재판매를 허용하지 않는 등의 작은 설계 변경은 시장 작동에 큰 영향을 미칠 수 있지만, 이는 본 논문의 초점이 아니다. 우리는 이미 존재하는 티켓 소지자 집합 내에서의 블록 공간 할당 문제에 좁게 집중할 것이다.
흥미롭게도, 프로토콜 관점에서 블록 생산자와 증거자는 독립적인 개인이며—개인은 스테이킹할지 티켓을 구매할지 결정함으로써 프로토콜의 어느 부분에 참여할지 선택해야 한다. 제2차 티켓 시장은 오늘날의 mev-boost처럼 적시에 블록 빌딩 권리를 경매하는 장소로 발전할 수 있다.
또한 빌더는 프로토콜과 직접 상호작용하여 실행 티켓을 구매할 수 있지만, 그들의 자본은 거래소 간 차익거래를 포착하는 데 더 적합할 수 있다. 따라서 그들은 경매 시기에 블록 공간을 제2차 시장에서 구매하는 것을 선호할 수 있다.
왜 우리는 이러한 고정 가격 무제한 공급 메커니즘에 국한되어야 하는가? 두 가지 이유가 있다:
1. 복잡한 시장이 컨센서스 레이어에서 구현 가능한지 불확실하다. 클라이언트 최적화는 소비자용 하드웨어를 가진 검증자라도 네트워크에 참여할 수 있게 한다. 이 요구사항은 고속 경매, 바인딩 커브, 기타 티켓 판매 메커니즘과 호환되지 않을 수 있다. 판매된 티켓 수, 체인 상 티켓 판매에 포함된 MEV(메타-MEV?!), 그리고 티켓 판매 시간(및 타이밍 게임)에 관한 문제들은 실행 레이어가 다루는 문제에 더 가깝고, 하드웨어 요구사항을 제한하면서는 이더리움 컨센서스가 합리적으로 구현하기 어려운 문제들이다.
「ET 시장 관련 거래의 포함은 이 거래가 비콘 블록에 포함되든 실행 페이로드에 포함되든 관계없이 MEV를 유발할 수 있다.」—Barnabé, "More pictures about proposers and builders"에서.
2. 비록(큰 가정이지만) 프로토콜이 더 엄격한 티켓 판매 시장을 구현할 수 있다고 하더라도, 해당 메커니즘의 설계 공간은 매우 크다. 바인딩 커브, 1559 스타일의 동적 가격 책정, 경매 등 다양한 가격 책정 메커니즘이 논의되어 왔으며, 이에 대해 일반적인 진술을 하는 것은 본 논문의 범위를 벗어난다.
따라서 우리는 프로토콜 내부의 복잡성이 최소화되는 '무제한, 1 WEI 고정 가격' 버전의 실행 티켓에 집중한다. 이 프레임워크 안에서 우리는 아마 여러분이 궁금할 법한 질문을 던질 수 있다. "주어진 실행 티켓 소지자 집합에서 승자는 어떻게 선택되는가?" …… 간단해
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
a16z
