EIP-7805: 포크 선택 강제 포함 목록 (FOCIL)

Ethereum Cat Herders의 PEEPanEIP 에피소드 141입니다. 진행자 푸자 란잔(Pooja Ranjan)이 이더리움 재단 Robust Incentives Group의 연구원이자 EIP-7805 (새 탭에서 열림)의 공동 저자인 토마스 티에리와 줄리안 마를 모시고 포크 선택 강제 포함 목록(FOCIL)에 대해 설명합니다. 이더리움에 프로토콜 수준의 검열 저항성이 필요한 이유, 메커니즘의 작동 방식, 그리고 구현 현황을 다룹니다.

이 대본은 Ethereum Cat Herders가 게시한 원본 비디오 대본 (새 탭에서 열림)의 접근성 향상 버전입니다. 가독성을 위해 약간의 편집을 거쳤습니다.

소개 (0:35)

Pooja Ranjan: 안녕하세요. 이더리움 개선 제안(EIP)을 깊이 있게 살펴보고 생태계에 미치는 영향을 탐구하는 유일무이한 프로그램, PEEPanEIP에 오신 것을 환영합니다. 이번 에피소드는 141회로, Ethereum Cat Herders에서 제공합니다. 저는 진행자 Pooja Ranjan이며, 오늘은 포크 선택 강제 포함 목록(Fork-choice enforced Inclusion Lists)인 EIP-7805에 대해 이야기해 보겠습니다.

2024년 11월에 문서화된 EIP-7805는 현재 초안 상태인 표준 트랙 핵심 제안입니다. 이 제안은 검증자 위원회가 모든 블록에 일련의 트랜잭션을 강제로 포함할 수 있도록 하는 것을 목표로 합니다. Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann, Jihoon Song이 공동 작성한 이 제안은 향후 업그레이드를 위해 활발히 논의되고 있습니다.

이번 에피소드에서는 EIP-7805의 세부 내용과 그 의미, 그리고 이더리움 생태계에 미칠 잠재적 영향에 대해 살펴보겠습니다. 이 제안에 대해 더 자세히 이야기하기 위해 Thomas Thiery와 Julian Ma를 모셨습니다. PEEPanEIP에 오신 것을 환영합니다.

Thomas Thiery: 초대해 주셔서 감사합니다.

Julian Ma: 네, 초대해 주셔서 정말 감사합니다.

Pooja Ranjan: 제안의 개요와 현재 진행 상황, 그리고 이더리움 메인넷에서 언제쯤 만나볼 수 있을지 기대가 됩니다. 하지만 시작하기 전에, 우리 커뮤니티는 이 작업의 배후에 있는 연구원과 개발자들에 대해 알아가는 것을 좋아합니다. 본인 소개와 현재 참여 중인 프로젝트, 그리고 이더리움 생태계에서의 여정에 대해 조금 나누어 주시겠어요?

게스트 소개 (2:14)

Julian Ma: 네, 제가 먼저 시작하겠습니다. 저는 Thomas와 마찬가지로 이더리움 재단의 Robust Incentives Group에서 연구원으로 일하고 있는 Julian입니다. Robust Incentives Group은 프로토콜의 경제학을 매우 폭넓게 다루고 있습니다. 저희 중 일부는 EIP-1559와 같은 트랜잭션 수수료 메커니즘을 연구해 왔고, 다른 일부는 주로 경제적 인센티브에서 비롯된 합의 레이어 공격을 연구해 왔습니다.

저의 경우, 기본 수수료 파생상품을 연구하는 인턴십으로 시작해서 그 이후에 정규직으로 합류했습니다. 저는 주로 제안자-빌더 분리(PBS)와 MEV 관련 주제를 연구해 왔으며, 지금은 이 EIP와 함께 FOCIL을 통한 포함 목록(inclusion lists)에 집중하고 있고, 증명자-제안자 분리(attester-proposer separation)도 기대하고 있습니다. 저는 이론적인 작업으로 시작해서 이더리움 내에서 제안되고 구현될 수 있는 EIP로 발전시키는 파이프라인을 통해 연구를 실제 프로덕션으로 가져오는 것에 가장 큰 기대를 걸고 있습니다.

Thomas Thiery: 저는 Thomas입니다. 저 역시 이더리움 재단의 Robust Incentives Group에서 연구를 하고 있습니다. 제 배경은 사실 신경과학 박사 학위인데, 지금과는 매우 달랐죠. 하지만 블록체인과 분산 시스템에 호기심이 생겨서 조금 다른 것을 시도해보고 싶었고, Dune이라는 암호화폐 데이터 회사에 합류했습니다. 그곳에 잠시 머물렀지만 연구를 다시 하고 싶어졌고, 운 좋게도 이더리움 재단(EF)과 Robust Incentives Group에 합류할 수 있었는데 지금까지 정말 좋았습니다.

저도 비슷한 주제를 연구해 왔습니다. 제가 합류했을 때 MEV가 꽤 큰 화두였습니다. 흥미롭게도 제 첫 연구 게시물은 아주 작은 규모였지만, 포함 지연(inclusion delays)과 검열 저항성(censorship resistance)에 관한 것이었습니다. 최근까지는 그 주제에 대해 깊이 파고들지 않았습니다. 지난 6개월에서 1년 동안 저는 검열 저항성과 포함(inclusion) 측면에서 더 활발하게 활동해 왔습니다. 연구 아이디어로 시작해서, 매우 흥미로웠지만 우리가 이야기할 세부 사항 중 일부가 빠져 있던 이전 아이디어들을 개선하고, 제안을 내놓고, 이제는 제가 대화를 나눈 대부분의 사람들이 이더리움에 좋은 추가 기능이 될 것이라고 생각하는 구현체와 데브넷을 갖게 되어 정말 기쁩니다.

Pooja Ranjan: 공유해 주셔서 감사합니다. 개발자들의 배경을 알게 되는 것은 항상 영감을 줍니다. 서로 다른 분야에서 와서 궁극적으로 이더리움 생태계에 기여하고 있다는 점이 흥미롭습니다. 오늘 프레젠테이션이 준비되어 있는 것으로 알고 있습니다. 그럼 지체하지 않고 바로 살펴보겠습니다.

프레젠테이션: FOCIL의 목표 (5:16)

줄리안 마: 완벽합니다. 정말 감사합니다. EIP-7805, 즉 FOCIL이 어떻게 작동하며 우리가 왜 이것을 하려고 하는지에 대한 짧은 프레젠테이션으로 시작하고자 합니다. 이 프레젠테이션은 대화를 시작하기 위한 것이므로, 나중에 토론할 시간을 남겨두기 위해 너무 깊이 들어가지는 않겠습니다.

FOCIL의 주요 목표는 이더리움의 신뢰할 수 있는 중립성을 높이는 것입니다. FOCIL은 현재 단일 제안자나 블록 빌더가 하나의 슬롯 내에서 가지고 있는 포함 독점권을 제거함으로써 이를 수행합니다. 대신, FOCIL은 여러 검증자가 각 블록에 트랜잭션을 포함시켜 블록을 구축하는 데 기여할 수 있도록 합니다.

더 높은 수준의 목표는 우리가 체인 중립성이라고 부르는 특성을 추구하는 것입니다. 이는 수수료를 지불하는 대기 중인 트랜잭션이 사용 가능하고 온체인에 포함될 공간이 있다면 반드시 포함되어야 함을 의미합니다. 우리는 이 특성이 충분히 충족된다면 이더리움의 신뢰할 수 있는 중립성이 높아질 것이라고 믿습니다.

왜 FOCIL이 필요하며, 왜 지금인가요? (6:09)

Julian Ma: 왜 이런 것이 필요할까요? 현재 거의 모든 검증자는 블록 생성을 MEV-Boost에 위임하고 있습니다. MEV-Boost는 빌더가 블록 생성 권한을 얻기 위해 입찰하는 프로토콜 외부 시장입니다. 이 시장에서는 단 두 개의 주체만이 사실상 지배하고 있으며, 이는 전체 블록의 90%가 단 두 주체에 의해 생성된다는 것을 의미합니다.

여기서 우리는 이더리움이 더 이상 로컬 블록 생성으로부터 신뢰할 수 있는 중립성을 확보할 수 없다는 것을 알 수 있습니다. 과거에는 가능했습니다. 처음에는 전 세계에 위치한 제안자들이 각자 로컬에서 블록을 생성했으며, 이는 모든 트랜잭션이 포함된다는 것을 의미했습니다. 하지만 이제 블록 생성이 이러한 고도화된 주체들에게 위임됨에 따라, 이것만으로는 더 이상 충분하지 않습니다. 따라서 더 강력한 검열 방지 조치를 도입할 필요가 있으며, FOCIL은 이를 위한 가장 잘 알려진 방법입니다.

왜 지금 FOCIL을 도입해야 할까요? 현재는 빌더들이 검열을 많이 하지 않는다고 생각할 수 있지만, 규제나 경제적인 이유로 언제든지 검열을 시작할 수 있습니다. 그리고 경제적 검열은 결코 간과해서는 안 될 문제입니다. 또한 검열이 비교적 적을 때 FOCIL을 도입하는 것이 좋습니다. 그래야 이를 기본값이자 표준으로 자리 잡게 할 수 있기 때문입니다. 모든 검증자는 관할권이나 경제적 인센티브와 관계없이 포함 목록(inclusion list)을 작성하게 되며, 이는 시장 불안정을 거의 초래하지 않습니다. 반면, 모든 빌더가 검열을 하고 있을 때 FOCIL을 도입하려고 한다면 아마도 훨씬 더 어려울 것입니다.

또한, 최근 베이스드 롤업(based rollups)이 점점 더 주목받고 있으며, 이들은 이더리움의 블록 생성에 크게 의존하게 될 것입니다. 이더리움이 가진 시퀀싱을 제공하고자 한다면, FOCIL을 통해 신뢰할 수 있는 중립성을 확보하는 것이 필수적입니다.

그리고 관점에 따라 다르겠지만, 잠재적으로 FOCIL은 확장성 개선에도 도움이 될 수 있습니다. 오늘날 이더리움은 여전히 로컬 블록 생성에서 검열 저항성을 확보하고 있습니다. 만약 이더리움이 FOCIL과 같은 다른 방식을 통해 검열 저항성을 확보할 수 있다면, 블록 빌더에 대한 기대치를 높이고 예를 들어 더 많은 블롭을 허용할 수도 있을 것입니다. 하지만 잠재적으로 이는 FOCIL 없이도 가능할 수 있습니다. 따라서 FOCIL은 푸사카(Fusaka) 업그레이드에 도입되도록 제안되었습니다.

FOCIL 작동 방식 (8:10)

줄리안 마(Julian Ma): 이제 FOCIL이 어떻게 작동하는지 설명해 드리겠습니다. 기본부터 시작해서 전체 메커니즘을 파악할 때까지 단계별로 살펴본 다음, 이 전체 메커니즘이 우리가 원하는 속성을 어떻게 충족하는지 알아보겠습니다.

이전에 마이크 노이더(Mike Neuder)도 제안한 바 있는 포함 목록(inclusion list)의 기본 아이디어는 어떤 방식으로든 블록을 제약하는 트랜잭션 목록이 있다는 것입니다. 예를 들어, 트랜잭션 A와 B가 포함된 포함 목록이 있고, 프로토콜에서 인정하는 누군가가 이에 서명하면, 이 트랜잭션들은 반드시 어떤 블록에 포함되어야 합니다. FOCIL은 이 점을 변경하지 않습니다. 이를 기반으로 구축되며, 누가 이 목록을 생성하고 어떻게 이 목록을 강제하는지에 더 중점을 둡니다.

그렇다면 이 목록은 누가 생성할까요? 이것이 FOCIL 프로토콜이 작동하는 첫 번째 단계입니다. 각 슬롯마다 16명의 검증자가 포함 목록 위원회 멤버로 선택됩니다. 이 위원회 멤버들은 각각 멤풀을 관찰하고 자신만의 포함 목록을 구성합니다. 하나의 포함 목록은 약 8킬로바이트, 즉 평균적인 트랜잭션 약 20개 정도여야 하며, 이는 전체적으로 평균 약 320개의 트랜잭션을 의미합니다.

두 번째 단계는 이러한 포함 목록을 배포하는 것입니다. 포함 목록 위원회 멤버들은 글로벌 토픽을 통해 자신들의 포함 목록을 배포하며, 이를 직접 블록에 포함시키지는 않습니다. 이들은 슬롯의 9초가 되기 전에 이 작업을 수행해야 하며, 이때 증명자(attester)들은 로컬 포함 목록에 대한 뷰(view)를 고정(freeze)합니다. 다음 단계에서 보게 되겠지만, 이름(포크 선택 강제 포함 목록, fork-choice enforced inclusion lists)에서 알 수 있듯이 이 포함 목록을 실제로 강제하는 주체는 증명자들입니다. 이들은 9초에 자신이 강제할 포함 목록에 대한 뷰를 고정하며, 이는 스플릿 뷰(split-view) 공격을 방지합니다. 블록 생성자는 포함 목록을 관찰하고 누락된 포함 목록으로 인해 부정적인 영향을 받지 않도록 확인할 수 있는 몇 초의 여유 시간이 있으므로, 이 설정에서 블록 생성자에게는 위험이 없습니다.

그런 다음 마지막 단계인 강제(enforcement)로 넘어갑니다. 앞서 말씀드렸듯이, 강제는 포크 선택을 통해 이루어집니다. 증명자들은 블록이 포함 목록 조건을 충족하는 경우에만 해당 블록에 투표합니다. 이들은 글로벌 토픽으로 전송된 포함 목록을 관찰하고, 이 포함 목록에서 본 트랜잭션들의 집계 목록을 만든 다음, 이 모든 트랜잭션이 블록에 있는지 확인하는 방식으로 이를 수행합니다. 이 확인을 통과하면 블록에 투표합니다. 포함 목록의 모든 트랜잭션이 블록에 있지는 않지만 블록이 가득 찬 경우도 있을 수 있습니다. 이 경우에도 증명자들은 블록에 투표합니다. 따라서 블록에 트랜잭션이 포함되어 있지 않으면서 블록이 가득 차지 않은 경우가 아니라면, 증명자들은 블록에 투표합니다.

전체 메커니즘을 요약하자면 다음과 같습니다. 각 슬롯에서 16명의 위원회 멤버가 포함 목록 위원회 멤버로 선택됩니다. 이들은 멤풀을 관찰하고 포함 목록 객체를 구성하여 마감 시간(이 경우 9초) 전에 글로벌 토픽을 통해 배포합니다. 빌더는 이러한 포함 목록을 관찰하고 자신이 본 모든 트랜잭션을 블록에 포함시킵니다. 그런 다음 증명자들은 9초 이전에 포함 목록에서 본 모든 트랜잭션이 실제로 블록에 있는지 확인합니다. 이 확인을 통과하면 블록에 투표하고, 다음 슬롯으로 넘어가 동일한 설정이 다시 발생합니다.

IL Boost 및 비혼잡성 (11:07)

Julian Ma: Mike의 이전 EIP와 그 이후의 개발 과정에서 제기된 포함 목록(inclusion list)에 대한 큰 우려 중 하나는 "IL Boost" 또는 비혼잡성(uncrowdability)입니다. 이는 포함 목록 제안자가 포함 목록을 구성할 권리를 판매하고 싶어 할 수 있다는 사실을 의미합니다. 블록 구성에서도 이러한 현상이 발생하고 있기 때문에 이는 매우 타당한 우려입니다. 이 권리를 판매하면 정교한 빌더들로 구성된 중앙화된 시장이 형성됩니다.

우리는 다음과 같은 특성 때문에 FOCIL이 이러한 MEV-Boost와 유사한 시장, 즉 흔히 IL Boost라고 불리는 문제에 대해 강력한 방어력을 갖추고 있다고 주장합니다. FOCIL은 트랜잭션의 순서를 보장하지 않습니다. 포함 목록의 어느 위치에 트랜잭션을 넣든, 블록 빌더가 적절하다고 판단하는 방식에 따라 순서가 정해집니다. 예를 들어, 목록에 차익 거래 트랜잭션을 포함시킨다고 해도, 빌더가 해당 차익 거래가 실제로 실행되도록 블록의 맨 위에 그 트랜잭션을 배치할 가능성은 매우 낮습니다. 대신 빌더가 직접 차익 거래를 실행할 가능성이 높습니다.

또한, 프라이빗 주문 흐름(private order flow)은 불가능합니다. 이러한 포함 목록은 글로벌 토픽을 통해 분산되므로, 빌더가 블록을 구성하기 전에 트랜잭션이 공개됩니다. 포함 목록을 통해 프라이빗 주문 흐름이 블록에 들어가는 것은 불가능합니다.

세 번째로, 슬롯당 여러 명의 포함 목록 제안자가 존재합니다. 판매할 가치가 있는 무언가가 있다 하더라도, 16명의 포함 목록 위원회 구성원 모두가 이 포함 목록을 구성할 동일한 가능성을 가지므로, 포함 목록 제안자 간의 경쟁으로 인해 그 가치는 0으로 떨어질 것입니다.

마지막으로, 이러한 포함 목록은 블록 생성자가 작업을 수행하기 3초 전에 생성됩니다. 포함 목록이 확정된 후 블록 생성자가 작업을 수행하기 전까지 3초 동안 추가 정보가 도착하는데, 이는 일반적으로 MEV 유형의 트랜잭션과 매우 밀접한 관련이 있습니다. 즉, 정보의 우위가 거의 없다는 것을 의미합니다. 사실, 포함 목록을 MEV의 수단으로 사용하려는 사람들에게는 오히려 정보의 불리함이 존재합니다.

이러한 이유로, 우리는 어떤 개별 포함 목록 제안자도 MEV의 근본적인 정의인 포함, 순서 지정 또는 제외 권한을 갖지 않는다고 생각합니다. 따라서 포함 목록은 MEV의 대상이 되어서는 안 됩니다.

프레젠테이션 요약 (13:09)

줄리안 마: 이 짧은 프레젠테이션을 요약하자면 다음과 같습니다. FOCIL은 여러 검증자가 블록 생성에 기여할 수 있도록 하여, 단일 제안자의 포함 독점을 방지하고 이더리움의 신뢰할 수 있는 중립성을 강화합니다. 우리는 지금 FOCIL을 구현하는 것이 필요하다고 생각합니다. 왜냐하면 현재 언제든지 검열을 시작할 수 있는 지배적인 빌더가 단 두 곳뿐이며, 이는 그들이 이익을 얻을 수 있는 경제적인 이유 때문일 수 있기 때문입니다. 기반 롤업이 이더리움의 시퀀싱 속성을 사용하기를 원할 것이기 때문에 블록 생성은 더 많은 부하를 견뎌야 할 수 있습니다. FOCIL은 검열하는 주체가 적을 때 훨씬 더 원활하게 출시될 것입니다. 첫째, 검증자가 포함 목록을 작성하는 것이 기본값이 됨을 의미하기 때문이며, 둘째, 검열하는 빌더와 그렇지 않은 빌더 간의 시장 불안정성이 줄어든다는 것을 의미하기 때문입니다. 마지막으로, FOCIL은 잠재적으로 확장에 도움이 될 수 있으며, 이는 우리가 더 깊이 파고들 수 있는 주제일 것입니다.

이 짧은 프레젠테이션을 할 수 있는 시간을 내주셔서 감사합니다. 관심 있는 분들을 위해 EIP로 연결되는 QR 코드를 보여드리고 싶었습니다.

푸자 란잔: 짧은 프레젠테이션과 제안에 대한 개요를 설명해 주셔서 정말 감사합니다.

Q&A: EIP-7805는 EIP-7547과 어떻게 다른가요? (14:17)

Pooja Ranjan: 발표에서도 언급되었던 이전 제안인 마이크 노이더(Mike Neuder)의 제안 7547, 포함 목록(inclusion list)에 대한 첫 번째 질문으로 Q&A 시간을 시작하겠습니다. 해당 제안과 7805의 FOCIL 간의 기본적인 차이점을 이해하고 싶습니다. 발표에서 IL Boost와 혼잡 불가능성(uncrowdability)에 대해 부분적으로 다루셨는데요. 이에 대해 조금 더 설명해 주실 수 있나요?

Julian Ma: 7805가 7547과 어떻게 다른지에 대해서는 아마 토마스(Thomas)가 가장 잘 대답할 수 있겠지만, 저도 조금 말씀드릴 수 있습니다. 우선, FOCIL은 동일한 슬롯을 위한 것인 반면, 7547은 다음 슬롯을 위한 것이었습니다. 동일 슬롯 속성은 포함 목록을 온체인에 저장할 필요가 없다는 것을 의미하기 때문에 몇 가지를 더 쉽게 만듭니다.

혼잡 불가능성 속성과 관련해서는, 이것은 매우 흥미롭고 미묘한 부분입니다. 우리 제안의 기반이 된 훌륭한 제안인 7547에서는 포함 목록이 블록의 맨 아래에 무조건적으로 추가되며 한 사람에 의해 만들어집니다. 이것은 우리 제안과는 몇 가지 다른 속성을 가지고 있습니다. 첫째, 트랜잭션이 정렬됩니다. 미래에는 블록 하단 차익 거래(bottom-of-block arbitrage)가 매우 가치 있을 수 있으며, 실제로 토마스의 연구 중 일부는 이곳이 잠재적으로 가치 있는 위치가 될 수 있음을 강조했습니다. 포함 목록을 구성할 권리를 갖는다는 것은 블록에서 가장 마지막으로 행동하는 사람이 된다는 것을 의미하며, 일부 경우에는 이것이 가치 있을 수 있습니다. 둘째, 단 한 사람에 의해 만들어지기 때문에 포함 목록 위원회 구성원들 사이의 이러한 경쟁 효과가 없습니다. 1인 위원회는 블록 하단에 트랜잭션을 포함할 수 있는 전적인 권리를 가지며, 이 또한 그 가치를 더 높일 수 있습니다. 셋째, 무조건적인 속성이 있는데, 이는 블록 생성자가 무엇을 하든 상관없이 여러분의 트랜잭션이 어쨌든 온체인에 포함된다는 것을 의미합니다. 따라서 포함에 필요한 최소한의 보장을 넘어, 어느 정도 가치를 더할 수 있는 몇 가지 추가적인 보장을 가지고 있습니다.

Thomas Thiery: 또 다른 큰 차이점은 우리가 가진 포함 목록 제안자의 수입니다. 이전 제안에서는 슬롯 n의 제안자가 슬롯 n+1의 제안자가 강제해야 하는 포함 목록을 만드는 메커니즘이 있었습니다. 여기서 두 가지 큰 특징이 있습니다. 첫째, 1슬롯 지연이 있어서 포함 목록의 트랜잭션은 다음 제안자에 의해 다음 슬롯에 포함되기만 하면 됩니다. 그리고 실제로 포함 목록을 만드는 제안자는 단 한 명뿐입니다. FOCIL에서는 16명입니다. 이것은 엄청난 차이를 만듭니다. 왜냐하면 이제 전체 메커니즘이 의도한 대로 작동하려면 16명의 IL 위원회 구성원 중 단 한 명만 정직하면 되기 때문입니다. 이전에는 단일 주체에 의존했던 반면, 이는 실제로 훌륭한 검열 저항 메커니즘을 가질 확률을 배가시킵니다.

그리고 몇 가지 더 기술적인 세부 사항이 있습니다. 계정 추상화와 일부 호환되지 않는 문제가 있었고, 누군가 두 개의 다른 포함 목록을 보내는 것을 의미하는 IL 이중 서명을 처리하기 어려웠습니다. 블록 이중 서명은 잘 알려진 문제이며 프로토콜에 의해 페널티를 받지만, 이전 제안에서는 모든 것이 온체인으로 진행되었기 때문에 이상한 엣지 케이스(edge case)들도 처리해야 했고, 이를 수용하는 것이 쉽지 않았습니다. FOCIL에서는 포함 목록이 온체인으로 가지 않습니다. 단지 P2P 합의 레이어 네트워크를 통해 브로드캐스트될 뿐입니다. 조금 기술적인 내용이지만, 계정 추상화로 인해 발생하는 이러한 엣지 케이스나 IL 이중 서명으로 네트워크를 두 개의 뷰로 분할하는 공격을 처리하는 데 있어 큰 차이를 만듭니다.

Pooja Ranjan: 정말 감사합니다. 제안 7547에 대해 더 자세히 알고 싶은 분들을 위해, 마이크 노이더와 함께 녹화한 PEEPanEIP 에피소드 130에서 전반적인 개요를 제공하고 있습니다. 저는 항상 경쟁하는 제안들을 보는 것을 좋아합니다. 그것이 생태계와 체인의 발전을 위한 것이라는 것을 알기 때문입니다. 채팅창에 몇 가지 질문이 보이네요. 카타야(Kataya) 님을 모시고 질문을 들어보겠습니다.

제안자는 16개의 목록을 모두 포함해야 하나요? (19:05)

Kataya: 안녕하세요, 감사합니다. 제 질문은 다음과 같습니다. 블록 제안자가 각 위원회 구성원으로부터 하나씩, 총 16개의 포함 목록(inclusion list)을 받게 되나요? 그리고 이 목록에 있는 모든 트랜잭션을 포함해야 하나요?

Thomas Thiery: 네, 맞습니다. 모든 목록, 즉 우리의 경우 16개 목록에 있는 모든 트랜잭션의 합집합을 구합니다. 당연히 중복이 있을 수 있으므로 합집합을 구한 다음 중복을 제거합니다. 하지만 증명자(attester)들이 블록을 유효하다고 간주하려면 모든 목록의 모든 트랜잭션이 블록에 포함되어야 하는 것이 맞습니다.

Pooja Ranjan: 채팅창에 올라온 다음 질문은 Justin님의 질문입니다. Justin, 게스트 분들을 위해 질문을 직접 읽어주시겠어요?

포함 목록의 프라이빗 멤풀 트랜잭션 (19:55)

저스틴: 제가 질문을 너무 많이 했네요. 프라이빗 멤풀의 트랜잭션을 포함 목록에 넣지 못하게 하는 것이 무엇인지 묻고 싶었는데, 충분히 답변이 된 것 같습니다. 어차피 빌더가 본인이 적절하다고 생각하는 대로 순서를 정할 것이고, 트랜잭션이 IL에 올라가면 공개된다는 점을 고려하면 전혀 문제가 없는 것 같습니다. 그래서 이치에 맞는 것 같네요. 감사합니다.

토마스 티에리: 줄리안이 언급했듯이 그것도 하나의 고려 사항이었습니다. 우리는 FOCIL과 포함 목록이 MEV 트랜잭션, 프라이빗 오더 플로우(private order flow) 또는 사전 확인(preconfirmations)을 포함하는 데 사용되는 것을 정말 원하지 않았습니다. 궁극적으로 우리가 원하는 것은 검열 저항성이며, 주의하지 않으면 어떤 메커니즘이든 가치 있는 트랜잭션을 포함하기 위한 수단으로 변질되기 매우 쉽기 때문입니다. 트랜잭션을 포함 목록에 포함시키면 자동으로 공개되어 누구나 볼 수 있고, 순서가 보장되지 않으며, 빌더가 블록 내 어디에든 포함시킬 수 있다는 사실 때문에 가치 있는 트랜잭션에는 그다지 적합하지 않습니다.

따라서 퍼블릭 트랜잭션이 있어서 이를 포함 목록에 포함시키기 위해 퍼블릭 멤풀에 제출하거나, 가치 있는 프라이빗 트랜잭션이 있어서 FOCIL을 거치지 않는 경우 중 하나일 것입니다. 더 나은 방법들이 있기 때문입니다. 빌더에게 직접 연락하여 프라이빗 채널을 통해 전송하게 될 것입니다.

푸자 란잔: 공유해 주셔서 감사합니다. 다음 질문은 라디슬라우스 님이 해주셨네요.

FOCIL과 확장성 (21:41)

Ladislaus: 안녕하세요 여러분. 방금 말씀하신 FOCIL과 확장성 문제와 관련된 질문입니다. 최근 우리 모두가 보았듯이 이더리움 확장에 대한 논의가 있었고, 말씀하신 대로 소수의 빌더로 인한 병목 현상이 존재합니다. 개인적으로 저는 FOCIL이 로컬 빌딩(local building)에 다시 힘을 실어주는 것이라고 생각하며, 대역폭 요구 사항이나 전반적인 노드 요구 사항을 늘리기 전에 프로토콜에 반드시 포함되어야 할 필수 요소라고 봅니다. 이에 대해 어떻게 생각하시는지, 그리고 앞서 언급하신 것처럼 FOCIL 없이 확장할 수 있는 다른 잠재적인 방법에 대해서도 자세히 설명해 주실 수 있을까요?

Julian Ma: 질문 감사합니다. 먼저 FOCIL을 통한 확장에 대해 말씀드리겠습니다. 현재 검증자의 90%가 MEV-Boost를 통해 블록 구성을 외주에 맡기고 있으며, 이러한 고도화된 주체들은 당연히 최소 하드웨어 요구 사항보다 더 많은 대역폭을 보유하고 있습니다. 예를 들어, 이들은 아무런 문제 없이 블록에 더 많은 블롭을 포함할 수 있습니다. 하지만 흥미로운 점은 이더리움이 신뢰할 수 있는 중립성이나 검열 저항성을 위해 로컬 블록 빌딩에 의존하고 있다는 것입니다. 왜냐하면 이 두 고도화된 주체는 이더리움의 검열 저항성을 구축할 수 있는 기반이 아니기 때문입니다.

따라서 이더리움 프로토콜은 여전히 로컬 블록 빌딩이 가능하도록 설계되어야 하며, 실제로 우리는 이것이 MEV-Boost와 비교하여 수익성이 떨어지지 않도록 설계합니다. 이것이 이더리움의 설계 방향이지만, 실제로는 당연히 MEV-Boost가 훨씬 더 수익성이 높습니다. 첫째, 이러한 고도화된 블록 빌더들은 더 복잡한 알고리즘을 가지고 있고, 둘째, 훨씬 더 많은 프라이빗 오더 플로우(private order flow)를 보유하고 있기 때문입니다. 최근 Data Always의 연구에 따르면 MEV-Boost 블록에 훨씬 더 많은 트랜잭션이 포함되어 있다는 것을 보여주었습니다. 그것만으로도 더 많은 수익을 창출합니다.

그럼에도 불구하고, 프로토콜은 프로토콜 규칙 내에서 특정 검증자가 다른 검증자보다 수익성이 떨어지게 만드는 어떠한 강제성도 없도록 설계되었습니다. 우리가 그 규칙을 유지하고자 한다면 FOCIL이 필요합니다. 그래야 로컬 블록 빌더가 포함 목록(inclusion list)에 기여하고 이를 통해 검열 저항성을 유지할 수 있기 때문입니다. 하지만 이 규칙을 없애고, 기본적으로 로컬 블록 빌더는 일정 수의 블롭을 포함할 수 있지만, 더 고도화된 블록 빌더는 로컬 블록 빌더가 직접 블록을 생성할 때 감당할 수 없는 수준까지 더 많은 블롭을 포함할 수 있다고 정할 수도 있습니다. 따라서 최대치를 최저 하드웨어 요구 사항에 맞추는 규칙을 유지하려면 FOCIL이 필요합니다. 만약 그 규칙을 완화해도 괜찮다면, 확장을 위해 FOCIL이 필요하지 않을 수도 있습니다.

Thomas Thiery: 제 생각에도 매우 비슷합니다. 하지만 현재 이더리움은 이상한 위치에 있습니다. 대부분의 블록을 생성하기 위해 고도화된 빌더에 의존하고 있지만, 이들은 단 두 곳의 주체에 불과하기 때문에 검열 저항성 측면에서 좋지 않기 때문입니다. 만약 그들이 임의의 이유로 트랜잭션이나 특정 주소를 검열하기로 결정한다면, 기본적으로 우리는 검열 저항성이나 무허가성(permissionlessness)을 잃게 되며, 이는 매우 중요한 문제입니다. 이는 그들이 원하는 어떤 참여자라도 온체인 참여를 검열하거나 제한할 수 있다는 것을 의미하며, 이는 매우 나쁜 상황입니다.

그리고 우리가 유지하고 있는 검열 저항성 속성도 훌륭하지 않습니다, 그렇죠? 대부분의 블록이 이 두 빌더에 의해 생성되기 때문에, 기본적으로 하나의 로컬 블록 빌더가 선출되어 평소에 검열되던 모든 트랜잭션을 포함하는 블록을 제안할 때까지 기다려야 하는데, 이는 결코 좋은 상황이 아닙니다. 이는 해당 사용자들이 자신의 트랜잭션이 실제로 온체인에 포함될 때까지 10개, 12개, 혹은 그 이상의 수많은 블록을 기다려야 한다는 것을 의미합니다.

따라서 우리는 홈 스테이커와 로컬 블록 빌더를 반드시 유지하고자 합니다. 왜냐하면 그들이야말로 검열 저항성을 보존하는 주체이기 때문입니다. 동시에 오늘날에는 이들을 활용하는 것조차 완벽하지 않습니다. 두 빌더에 의해 검열될 경우 트랜잭션이 포함되기까지 여전히 많은 시간을 기다려야 하기 때문입니다. FOCIL을 사용하면 검열 저항성을 보장하는 참여자(우리의 경우 포함 목록 위원회 구성원)가 블록을 생성하는 사람과 다를 수 있는 환경으로 나아가게 됩니다. 저는 이것이 매우 흥미로운 환경을 열어준다고 생각합니다. 이제 가치 있는 블록을 생성하는 것과 검열 저항성에 기여하는 것 모두를 동일한 참여자에게 의존할 필요가 없기 때문입니다. FOCIL은 그 중요한 방향으로 나아가는 첫걸음으로 볼 수도 있습니다. 두 가지 매우 다른 임무가 있는데, 오늘날 우리는 동일한 검증자 노드에게 이 두 가지를 모두 수행하도록 요구하고 있으며, 이는 상당한 긴장을 유발하기 때문입니다.

Pooja Ranjan: 정말 감사합니다. 다음 질문은 Luis 님이 해주실 것 같네요.

트랜잭션 선택 기준 (26:46)

Luis Pinto: 시작하고 몇 분 뒤에 참여하긴 했지만, 전체 네트워크에서 트랜잭션 선택을 탈중앙화하는 것으로 보입니다. 제 생각에는 아주 좋은 방향입니다. MEV와 검열에 맞서 싸울 수 있으니까요. 그리고 증명자(attester)가 이 역할을 맡는다는 점이 정말 마음에 듭니다. 미래에는 무상태성(statelessness)과 무상태 클라이언트 덕분에 증명자의 하드웨어 요구 사항이 빌더보다 훨씬 낮아질 것이기 때문입니다. 매우 낮은 사양의 하드웨어로도 실행할 수 있게 되므로, 시스템이 매우 탈중앙화될 것입니다. 여기서 주요 과제는 이러한 포함 목록(inclusion list)의 트랜잭션 선택 기준을 정의하는 것 같습니다. 우선순위 수수료를 기준으로 할지, 블롭의 수를 기준으로 할지 등 변수가 너무 많습니다. 강제하려고 생각 중인 기준이 어느 정도 정해졌나요?

Thomas Thiery: 좋은 질문입니다. 두 가지 측면이 있습니다. 첫 번째는 매우 중요한 부분으로, 증명자를 블록을 구축하거나 제안하는 사람들과 분리하려는 시도에 관한 것입니다. 이것이 바로 증명자-제안자 분리(APS, attester-proposer separation) 연구의 핵심이며, Julian이 이 분야에서 많은 연구를 진행했습니다. 우리는 이를 역할의 언번들링(unbundling)이라고 부르며, 이를 통해 프로토콜의 의무에 더 잘 부합하도록 만듭니다. 제가 방금 공유한 게시물에서 가능한 분리 방식에 대해 썼는데, 이는 매우 열려 있는 주제이며 사람들의 더 많은 의견을 듣고 싶습니다. 이 게시물에서 저는 증명자, 현재 IL(포함 목록) 위원회 구성원인 포함자(includer), 그리고 실행 제안자 또는 빌더를 분리했습니다. 저는 이것들이 근본적으로 다른 의무라고 생각하며, 어쩌면 각각에 대해 다른 역할을 부여해야 할지도 모릅니다.

그리고 포함 규칙에 대해서는, 아주 좋은 질문입니다. 저희도 꽤 많이 고민했고, 두 가지 결론에 도달했다고 생각합니다. 첫 번째는 규칙의 다양성을 원한다는 것입니다. 모든 클라이언트에 대해 우선순위 수수료 내림차순으로 정렬하는 것과 같은 단일 규칙을 원하지 않습니다. 그렇게 되면 꼼수를 써서 멤풀을 재정렬하여 자신의 트랜잭션만 IL에 포함되도록 시도할 수 있기 때문입니다. 하지만 트랜잭션이 멤풀에서 대기한 시간을 고려하는 규칙을 포함하여 다양한 규칙이 있고, 서로 다른 클라이언트가 주로 우선순위 수수료와 멤풀 대기 시간을 중심으로 비슷한 성격의 각기 다른 규칙을 구현한다면, 이를 악용하기가 매우 어려워지며 프로토콜은 훨씬 더 견고해집니다. 또한 이는 오늘날 이더리움이 가진 클라이언트의 다양성을 활용하고, 클라이언트가 주관적인 선택을 할 수 있도록 하는 좋은 방법이라고 생각합니다. 저희가 염두에 둔 규칙은 있지만, 클라이언트 역시 자신에게 가장 적합한 규칙을 선택할 수 있다고 생각합니다. 모두가 우선순위 수수료로 정렬하는 완전히 똑같은 규칙을 가지지만 않는다면 괜찮을 것입니다.

Luis Pinto: 알겠습니다. 그렇다면 이 기준 또한 분산시켜서, 포함 목록을 구축하는 주체가 각자의 기준을 갖도록 하는 것이군요. 아니면 이것이 프로토콜의 일부가 되는 건가요?

Julian Ma: 포함 규칙은 프로토콜의 일부가 되지 않을 것입니다. 첫째, 강제하기가 매우 어렵고, 둘째, 사실 아무것도 강제하지 않는 것이 더 낫습니다. 위원회 구성원이 스스로 결정하도록 허용하거나, 클라이언트 팀이 그들을 대신하여 트랜잭션을 포함하는 방법을 결정하도록 둔다면, 네트워크에 어느 정도의 견고함을 만들어낼 수 있습니다. 서로 다른 선호도를 가진 사람들이 각기 다른 방식으로 포함하게 될 것이며, 이는 시스템을 공격하기가 더 어려워진다는 것을 의미합니다.

Luis Pinto: 알겠습니다. 감사합니다.

EIP-7702, ePBS 및 PeerDAS와의 호환성 (30:43)

Pooja Ranjan: 정말 감사합니다. 제가 이해하기로 이 제안은 펙트라 다음 업그레이드인 푸사카를 위해 이미 제안되었습니다. 그리고 푸사카에 현재 진행 중인 다른 EIP들이 포함될 수도 있고 안 될 수도 있다는 점을 고려할 때, 계정 추상화를 위한 7702, ePBS, PeerDAS와 같은 제안들과 관련하여 FOCIL의 호환성 상태는 어떤지 궁금합니다.

Thomas Thiery: 좋은 질문입니다. 포함 목록(inclusion list)의 역사 덕분에 저희에게 약간의 이점이 있었습니다. 앞서 언급했듯이, 7547은 포함이 고려되었다가 호환성 문제로 거절되었습니다. 그래서 저희는 새로운 제안을 하기 전에 이러한 문제들을 해결하는 데 매우 신중을 기했습니다. 사람들이 당연히 같은 질문을 던지며 이 제안을 살펴볼 것이라는 걸 알고 있었기 때문입니다.

저희는 계정 추상화 팀과도 이야기를 나누었고, Potuz 및 Terence와도 많은 대화를 나누었기 때문에 매우 자신 있습니다. Terence는 저희를 적극적으로 돕고 있으며 ePBS와 FOCIL 모두 작업해 왔기 때문에, 호환성 여부를 확인하는 것이 매우 쉬웠습니다. 다른 어떤 EIP와도 호환성 문제가 없다고 확신합니다. ePBS의 경우, 실행 페이로드를 합의 블록에서 분리하기 때문에 전체 슬롯 타이밍이 변경되며, 이제 페이로드가 제안되기 전에 만들어져야 하는 포함 목록(IL) 생성도 추가되므로 타이밍에 주의해야 합니다. 따라서 타이밍에 신경 써야 하지만, 제가 기억하기로 Potuz 및 Terence와 마지막으로 이 문제에 대해 이야기했을 때 치명적인 호환성 문제는 전혀 없었습니다. 호환성 측면에서는 상황이 좋다고 생각합니다.

Pooja Ranjan: 다행이네요. Jihoon 님도 HackMD를 공유해 주셨는데, ePBS와의 호환성에 대해 구체적으로 더 알고 싶은 분들을 위해 리소스에 추가하도록 하겠습니다. 그리고 네, Mike와의 지난 대화에서 기억하기로는 계정 추상화 호환성 문제 때문에 제안이 포함되지 않았던 것 같습니다. 그래서 이 문제가 이미 해결되었다니 정말 다행입니다.

FOCIL 및 다중 슬롯 MEV (33:04)

Pooja Ranjan: FOCIL 웹사이트인 meetfocil.eth.limo에 추가된 문서와 세부 정보를 살펴보던 중 다중 슬롯 MEV라는 용어에 대해 알게 되었습니다. Julian은 또한 개발자들이 이를 동등한 수준으로 유지하려는 바람과 노력에도 불구하고, 일반적으로 MEV-Boost가 수익성이 있다고 언급했습니다. FOCIL이 이를 어떻게 방지할 수 있을지 궁금합니다.

Julian Ma: 질문해 주셔서 감사합니다. 먼저 FOCIL과 MEV에 대해 말씀드린 다음, 다중 슬롯 MEV로 넘어가겠습니다. FOCIL이 반드시 MEV를 방지하는 것은 아니며, 이는 정확히 우리가 MEV 부분과 포함(inclusion) 부분을 분리하고자 하기 때문입니다. 우리가 보기에 그렇게 하는 것이 중요한데, 그렇지 않으면 IL Boost와 같은 종류의 시장이 생겨나기 때문입니다. 그러한 논리에 따라, 만약 포함 목록(inclusion list)이 추출 가능한 MEV의 양을 제한할 수 있다면 포함 목록을 구축하는 것은 매우 가치 있는 일이 될 것이고, 사람들은 이를 중심으로 시장을 형성할 것입니다. 우리의 설계는 최소한의 포함 보장을 제공하기 위해 존재합니다. 즉, 포함 목록 위원회 구성원이 되는 것이 그다지 큰 가치를 지니지 않으며, 16명의 구성원이 존재하므로 정교한 생산자들의 시장이 형성되지 않는다는 것을 의미합니다.

이제 다중 슬롯 MEV에 대해 말씀드리겠습니다. FOCIL은 일부 문제를 완화하지만, 모든 문제를 완전히 해결하지는 않습니다. 이는 검열 저항성 제공과 MEV에 대한 해결책을 동시에 제공하는 것 사이의 양립 불가능성 때문입니다. FOCIL이 하는 역할은 수수료만 지불하면 어떤 트랜잭션이든 포함될 수 있도록 허용하는 것이며, 이는 다중 슬롯 MEV 문제를 어느 정도 해결합니다. 여기서 다중 슬롯 MEV란 한 주체가 연속으로 두 개의 블록을 제어할 경우 더 많은 MEV를 추출할 수 있는 상황을 말합니다.

FOCIL은 트랜잭션을 삽입할 수 있게 해주기 때문에 일부 문제를 완화합니다. 예를 들어, 어딘가의 포지션에서 부실 채권을 청산하는 트랜잭션을 삽입해야 하는 경우, 제안자가 여러분을 검열하고 다음 블록에서 여러분으로부터 MEV를 추출하려고 시도하더라도 이를 수행할 수 있습니다.

모든 문제를 해결하지 못하는 이유는 한 사람이 다른 사람보다 더 많은 정보를 갖게 되는 경제적 특성인 역선택(adverse selection) 때문입니다. 다중 슬롯 MEV의 한 가지 예는 두 블록에 걸쳐 차익 거래를 추출하는 것입니다. 여기서 블록 빌더는 첫 번째 블록에서는 차익 거래를 추출하지 않고 두 번째 블록에서 추출합니다. 이것이 두 슬롯 모두에서 차익 거래를 추출하는 것보다 블록 빌더에게 더 수익성이 높을 수 있음을 보여주는 몇 가지 이론적 결과가 있습니다. 차익 거래자가 원칙적으로 자신의 트랜잭션을 포함 목록에 포함시켜 일종의 차익 거래가 발생하도록 강제할 수 있기 때문에, FOCIL이 이 부분에서 도움이 될 것이라고 생각할 수 있습니다. 실제로 그렇긴 하지만, 차익 거래자가 FOCIL에 트랜잭션을 제출하는 것은 인센티브에 부합하지 않습니다. 트랜잭션이 제출된 시점과 블록 빌더가 조치를 취할 수 있는 시점 사이에 여전히 3초의 시간이 있기 때문입니다. 차익 거래를 시도하고 있고 외부 시장에서 가격이 끊임없이 변동하고 있다면, 여러분보다 늦게 행동하는 블록 빌더보다 훨씬 적은 정보를 가지고 있기 때문에 3초 전에 미리 확정하고 싶지 않을 것입니다. 빌더가 더 많은 정보를 가지고 있기 때문에 역선택이 발생합니다. 추가적인 3초 동안 외부 시장의 가격이 여러분에게 불리하게 움직여 여러분에게 손해가 되는 상황이라면 빌더는 여러분이 이기도록 내버려 둘 것이고, 자신이 이기는 것이 더 유리하다면 자신이 이기도록 할 것입니다.

따라서 FOCIL은 트랜잭션이 역선택을 겪지 않는 다중 슬롯 MEV 부분을 해결합니다. 역선택이 존재하는 트랜잭션의 경우 조금 더 복잡하지만, 어느 정도 문제를 완화해 줍니다. 원칙적으로는 현재 상황보다 나아지게 만들지만, 여전히 해결해야 할 과제가 조금 남아 있습니다.

Pooja Ranjan: 잘 알겠습니다. 공유해 주셔서 정말 감사합니다. MEV 문제를 해결하기 위해 많은 연구가 진행 중인 것으로 알고 있는데, 적어도 원칙적으로는 현재 상황보다 더 도움이 될 것이라는 점을 알게 되어 기쁩니다.

트레이드오프와 과제 (36:44)

푸자 란잔: 토마스가 앞서 언급한 IL 이중 서명(equivocation)과 관련하여 질문이 하나 있습니다. 제안의 보안 고려 사항 섹션을 보면 합의 활성도(consensus liveness), IL 이중 서명, 페이로드 구성과 같은 꽤 많은 점들이 언급되어 있는 것을 확인했습니다. 가장 큰 트레이드오프는 무엇이라고 생각하시나요? 혹은 더 많은 연구가 필요하여 이 제안이 현재 상태 그대로 다음 업그레이드에 포함되는 것을 막을 수 있는 요소가 있을까요?

토마스 티에리: 솔직히 말씀드리면, 보안 고려 사항 섹션은 주로 우리가 보안에 대한 우려를 충분히 고민하고 해결했다는 것을 보여주기 위한 것이었다고 생각합니다. 우리가 알지 못하는 보안 문제에 대해 미해결 질문을 남겨두기보다는 그런 목적이 더 큽니다. 보안 고려 사항 측면에서 큰 장애물이나 문제는 없다고 생각합니다.

트레이드오프에 대해 말씀드리자면, 아주 좁은 관점에서 볼 때 FOCIL이 검증자에게 몇 가지 작업을 추가하는 것은 사실입니다. 포함 목록(inclusion list)을 제안해야 할 때나, 증명자(attester)가 포함 목록에 따라 블록이 유효한지 확인하기 위해 조건을 하나 더 검사해야 할 때 그렇습니다. 또한 제안자에게도 작은 작업이 추가되는데, 이제 페이로드에 IL의 트랜잭션이 실제로 포함되어 있는지 확인해야 하기 때문입니다. 제게는 그것이 유일한 트레이드오프이며, 이러한 작업들은 무겁거나 복잡하지 않습니다. IL 위원회 구성원은 그저 공개 멤풀을 모니터링하고 전송할 목록에 트랜잭션을 포함시키기만 하면 됩니다. 어떤 종류의 기술이나 정교함도 필요하지 않다는 점이 좋다고 생각합니다. 반면에 앞서 말씀드렸듯이, 이는 큰 확장성 개선과 프로토콜 내 참여자 및 역할 간의 더 나은 분리를 가능하게 할 수 있습니다.

제가 편견을 가지고 있을 수도 있지만, 큰 트레이드오프는 없다고 봅니다. 검열 저항성 측면에서는 모든 것을 완전히 뒤바꿔 놓는다고 생각합니다. 이제 빌더가 검열할 수 있는 트랜잭션을 포함하여 모든 트랜잭션이 다음 블록에 포함되려면 기본적으로 네트워크의 15%만 정직하게 행동하면 되는데, 이는 매우 큰 개선입니다. 솔직히 이 부분에서 많은 것을 희생한다고 생각하지 않습니다.

푸자 란잔: 알게 되어 다행이네요. 대부분의 제안에서 보안 고려 사항 섹션에 정보가 없거나 아주 적은 것을 보게 되는데, 이 부분에 대한 연구가 이루어졌고 발생 가능한 보안 고려 사항을 인지하고 있다는 점이 좋습니다. 이것이 향후 구현 및 채택에 있어 장애물이나 잠재적인 과제가 아니라는 것을 알게 되어 기쁩니다.

인클루전 리스트를 위한 트랜잭션 수수료 메커니즘 (39:50)

Pooja Ranjan: 웹사이트에서 발견한 트랜잭션 수수료 메커니즘에 관한 몇 가지 미해결 질문에 대해 여쭤보고 싶습니다. 업데이트된 내용이 있는지, 아니면 인클루전 리스트에 포함하기 위해 수수료를 부과하고 분배하는 가장 좋은 방법에 대해 더 공유해 주실 수 있는지 궁금합니다.

Thomas Thiery: 저희는 이 문제와 IL 위원회 구성원에게 보상하기 위한 인센티브 메커니즘을 구체적으로 살펴보는 보조금(grant) 프로그램을 진행 중입니다. 쉽지 않은 일입니다. 까다롭고, 어떻게 접근하든 이는 매우 큰 변화입니다. 이더리움에서 수수료를 변경하는 것은, 수수료를 변경하든, 추가하든, 새로운 발행을 추가하든, 모두 많은 고려와 주의가 필요한 큰 변화입니다. 하지만 현재 탐색 중이며, 예를 들어 트랜잭션을 포함하는 위원회 구성원들에게 수수료를 분배하는 아이디어는 꽤 괜찮아 보입니다. 다른 사람들이 포함하고 싶어 하지 않을 수 있는 트랜잭션을 포함하는 사람들에게 보상하기를 원하기 때문에, 우리가 원하는 특성을 어느 정도 갖추고 있습니다. 그래서 저희는 이에 대해 꽤 깊이 생각하고 있으며, 진행 중인 보조금 프로그램도 있습니다.

또한 IL 위원회 구성원에게 수수료를 지급할지 여부에 대한 의문도 있습니다. 전 세계에 분산되어 있는 소규모 참여자에게 보상하는 것은 특히 어렵기 때문입니다. 시빌(Sybil) 공격을 원하지 않을 것이고, 많은 스테이크를 가진 대규모 참여자가 IL 위원회 세트를 밀어내는 것도 원하지 않을 것입니다. 이를 어떻게 방지할 수 있을까요? 매우 어려운 문제입니다. 따라서 고려해야 할 설계 요소가 많습니다.

최근 제가 가진 생각 중 하나는 이렇습니다. 프라이버시와 같은 멋진 기능을 FOCIL에 추가하여, 주어진 트랜잭션 리스트를 누가 제안했는지 알 수 없게 만들면 어떨까요? IL 위원회 구성원으로 실제로 선택된 누군가라는 것은 알지만, 정확히 누가 어떤 리스트를 제안했는지는 모르기 때문에 IL 위원회 구성원을 그들의 IL에 있는 트랜잭션 세트와 연결할 수 없습니다. 만약 우리가 그렇게 할 수 있고 IL 위원회 역할을 일종의 선택 사항(opt-in)으로 만들 수 있다면, 이타적인 행동에 의존하는 정직한 프로토콜 참여자를 확보할 수 있을 것이고, 어쩌면 수수료 메커니즘을 전혀 설정할 필요가 없을지도 모릅니다. 이는 매우 최근의 주관적인 의견이며, 현재 활발히 탐색되고 있습니다. 이 모든 것은 "FOCIL의 미래"에 대한 논의이며, 현재 EIP에 포함될 예정은 아닙니다.

Julian Ma: 덧붙이자면, 마지막 부분도 매우 중요합니다. EIP-7805는 구현을 더 간단하게 만들기 위해 어떠한 트랜잭션 수수료 메커니즘도 포함하지 않습니다. 이는 기본적으로 검열 저항성 속성을 제공할 수 있는 가장 작은 형태의 방법이지만, 확장성이 매우 뛰어납니다. 저희는 이를 조사하고 있습니다. Thomas는 포함자(includer)와 제안자를 위한 별도의 트랜잭션 수수료를 살펴보는 작업을 꽤 많이 수행했습니다. 그리고 Thomas가 언급했듯이, 저희는 FOCIL을 위한 트랜잭션 수수료 메커니즘을 만드는 것을 연구하고 있는 네더마인드의 훌륭한 연구원과 함께 보조금 프로그램을 진행 중이며, 이는 매우 유망합니다. 마지막으로, 인클루전 리스트 위원회 구성원에게 인센티브를 제공하는 방법을 모색하는, 여러 FOCIL 작성자와 함께 Sarisht Wadhwa, Fan Zhang, Kartik Nayak이 제안한 경매 기반 인클루전 리스트 설계인 AUCIL이라는 FOCIL 변형에 대한 트랜잭션 수수료 메커니즘 연구도 있었습니다.

앞서 Luis가 지적했듯이, 인센티브를 제공하는 것은 인클루전 리스트가 어떻게 생성되는지와 매우 밀접한 관련이 있습니다. 이는 프로토콜이 인클루전 리스트 위원회 구성원이 어떻게 행동해야 하는지에 대한 특정한 관점을 제시하고자 함을 의미합니다. 일반적으로 이는 특정 참여자가 다른 행동을 하기를 원한다는 것으로 귀결됩니다. 예를 들어, 위원회 구성원 간에 여전히 다른 행동을 유도하기 위해 상관 균형(correlated equilibrium)을 통해 위원회 구성원을 정렬하고 특정 트랜잭션을 할당할 수 있습니다. 따라서 이는 현재 제안의 일부는 아니지만, 저희는 확실히 이를 조사하고 있으며 FOCIL의 확장성 방향과도 잘 맞습니다.

Pooja Ranjan: 오, 흥미롭네요. 그렇다면 현재의 FOCIL 기능을 향상시키기 위해 향후 몇 가지 보완적인 제안을 기대해 볼 수 있겠군요.

포함 목록 크기 (44:16)

Pooja Ranjan: 질문이 하나 더 있습니다. 현재 제안에 포함되어야 하는 내용인지는 모르겠지만, IL(포함 목록) 크기에 대한 업데이트가 있는지 궁금합니다. 과도한 대역폭 사용을 방지하려면 포함 목록의 크기를 제한해야 할 것입니다. 포함 목록의 최적 크기를 결정하는 방법에 대한 추가 연구나 업데이트가 있나요?

Thomas Thiery: 현재 사양(spec)에는 고정된 크기가 있으며, 8킬로바이트로 정해진 지 꽤 되었습니다. FOCIL과 IL이 실제로 소비하는 것은 대역폭이 거의 전부이기 때문에 킬로바이트 단위로 설정했습니다. 중간값의 트랜잭션 크기를 기준으로 하면 IL당 약 40개의 트랜잭션이 들어가며, 모든 트랜잭션이 고유하다고 가정할 때 16명의 위원회 멤버 전체에 걸쳐 약 640개의 트랜잭션을 결합할 수 있습니다.

정확한 최적의 크기에 대해 더 많은 연구가 필요한지는 모르겠습니다. 우리가 선택한 방식은 이렇습니다. 16 곱하기 8킬로바이트는 기본적으로 블롭 하나의 크기와 같으므로, 합치더라도 대역폭이 엄청나게 크지는 않습니다. 그리고 여러 IL에 걸친 트랜잭션의 조합이 하나의 블록보다 크기 때문에, 그 부분에서 문제가 발생하지는 않을 것이라고 생각합니다.

향후에는 IL 크기를 늘릴 수도 있지만, IL 위원회 멤버 수를 늘리는 것도 고려할 수 있습니다. 그렇게 하면 네트워크의 대부분이 검열을 시작하기로 결정하더라도, 정직한 IL 위원회 멤버를 최소 한 명이라도 확보할 가능성이 훨씬 더 커집니다. 따라서 이 역시 우리가 취할 수 있는 조치입니다. 현재로서는 16명으로도 충분히 괜찮아 보이지만, 향후 검열이 매우 심해지거나 추가적인 조치가 필요해진다면 이러한 매개변수를 확실히 조정해 볼 수 있습니다.

도입을 추적하기 위한 지표 (46:39)

Pooja Ranjan: 여기서 후속 질문이 있습니다. 이 제안의 도입이나 성공을 이해하기 위해 우리가 추적할 수 있는 염두에 둔 지표가 있나요?

Julian Ma: 좋은 질문입니다. 제가 짧게 대답하고 Thomas에게 마이크를 넘기겠습니다. 몇 가지 간단한 지표로는 비어 있지 않은 포함 목록이 얼마나 많이 제안되었는지가 있습니다. 그리고 Toni Wahrstätter의 ".pics" 시리즈와 같은 대시보드를 생각해 볼 수 있는데, 여기에는 이러한 포함 목록에 어떤 품질 척도를 할당하는 등 더 많은 특징이 있을 수 있습니다. 하지만 원칙적으로는 검열 저항성을 제공하기 위해 슬롯당 단 한 명만 제대로 된 포함 목록을 작성하면 됩니다.

이것은 FOCIL을 조속히 구현하는 것이 중요하다는 점에서 매우 중요한 포인트라고 생각합니다. 왜냐하면 지금 우리는 블록 빌더들이 검열을 많이 하지 않고 검증자들도 검열을 많이 하지 않는 마법 같은 체제에 있기 때문입니다. 저는 이것이 매우 깨지기 쉬운 상태라고 말하고 싶습니다. 지금까지 블록 빌더들은 오랫동안 검열을 해왔고, 만약 우리가 지금 FOCIL을 도입한다면, 이 모든 검증자들이 이를 채택하고 의미 있는 포함 목록을 생성하는 것을 기본값으로 만들 가능성이 있습니다. 블록 빌더들이 검열을 하지 않기 때문에, 여기서 발생하는 시장 불안정성은 없습니다. 만약 빌더들 사이에서 검열이 일어날 때까지 기다린다면 FOCIL을 도입하기가 훨씬 더 어려워질 것이고, 도입을 측정하는 데 사용될 모든 지표들이 훨씬 더 나빠질 것이라고 생각합니다.

Thomas Thiery: 살펴봐야 할 또 다른 핵심 지표는 말 그대로 퍼블릭 멤풀 트랜잭션의 포함 지연 시간입니다. 퍼블릭 멤풀에서 대기 중인 모든 트랜잭션을 가져와서 얼마나 빨리 포함되는지 확인하는 것입니다. FOCIL이 작동한다면, 이 트랜잭션들은 모두 다음 블록에 포함될 것입니다. 그렇지 않다면, 이는 상당한 비율의 검증자가 검열을 하고 있다는 것을 의미합니다. 따라서 우리가 살펴볼 수 있는 다른 지표는 누가 검열을 하고 있는지, 그리고 네트워크의 어느 정도 비율이 검열을 하고 있는지입니다. 우리는 이를 추적하기 위한 대시보드와 매우 투명한 지표를 갖게 될 것입니다. 왜냐하면 이것이 기본적으로 FOCIL이 해야 할 일이기 때문입니다. 퍼블릭 트랜잭션이 다음 블록에 포함되지 않는다면, 이는 네트워크의 매우 큰 부분이 실제로 이러한 트랜잭션을 검열하고 있다는 것을 의미합니다.

Pooja Ranjan: 매우 흥미롭네요. 그렇다면 연구자들을 위한 업그레이드 희망 목록이 될 수도 있겠습니다. 제안이 네트워크 업그레이드에 포함될 때마다 개발자들이 대시보드와 지표 추적기를 공유해야 한다는 것 말이죠.

클라이언트 구현 상태 (49:11)

Pooja Ranjan: Julian이 언급했듯이, 이 제안은 가능한 한 빨리 구현되어야 할 수도 있습니다. 클라이언트 구현이 어느 정도 진행되었는지 궁금합니다. 지난 테스트넷 콜에서 Paritosh가 데브넷 지원을 추가하는 것에 대해 언급했던 기억이 나거든요. 현재 진행 상황은 어떤가요?

Thomas Thiery: 꽤 잘 진행되고 있습니다. 우선, 사람들이 FOCIL의 구현 부분을 어떻게 맡아 진행하는지 보는 것이 정말 좋았습니다. 저는 개발자가 아니라 연구원이기 때문입니다. 처음부터 개발자들과 함께 일해왔지만, 제가 클라이언트에 직접 무언가를 구현하는 사람은 아닙니다.

이 작업을 주도한 세 분이 있습니다. 프리즘의 Terence, 그리고 프리즘에서 Terence를 많이 도왔을 뿐만 아니라 Geth에서도 작업한 Jihoon입니다. 덕분에 현재 프리즘과 Geth를 위한 데브넷이 잘 작동하고 있으며, 많은 테스트가 진행 중입니다. 또한 Dora 익스플로러에 FOCIL이 표시되도록 노력하고 있습니다. 그리고 라이트하우스와 레스에서 작업한 Jacob이 있는데, 그곳에서도 여전히 작업이 진행 중인 것으로 알고 있습니다. 로드스타는 최근 매우 활발하게 움직이고 있으며, 데브넷 작동에 매우 근접했다고 생각합니다. 오늘 네더마인드에서 프로토타입을 완성했다는 소식을 들었는데, 정말 멋진 일입니다. 제가 누군가를 잊고 있는 것 같은데... Jihoon에 따르면 님버스도 합류한다고 합니다. 정말 좋은 소식입니다.

전반적으로 점점 더 많은 데브넷과 로컬 데브넷이 준비되어 가동되고 있으며, 실행 레이어와 합의 레이어 클라이언트 간의 조합도 점점 더 많아지고 있습니다. 정말 좋은 진전이 있었고, 이를 지켜보는 것은 즐겁습니다. 우리 모두 알다시피 개발자들은 펙트라 출시를 앞두고 매우 바쁘며, 이미 PeerDAS와 다른 작업들도 진행하고 있기 때문입니다. 이더리움 커뮤니티 전반의 사람들이 검열 저항성에 대해 얼마나 많은 관심을 가지고 있는지 보는 것은 정말 멋진 일이었습니다. 제가 특별히 연락하지 않았던 대부분의 팀들도 이 노력에 동참하여 현재 데브넷과 테스트를 향해 작업하고 있습니다.

Pooja Ranjan: 공유해 주셔서 감사합니다. 데브넷에 대한 업데이트를 계속 지켜보겠습니다. 이 데브넷이 몇 번의 반복(iteration)을 거치게 될지는 모르겠지만, 앞으로의 진행 상황이 기대됩니다. Justin이 질문이 있는 것 같네요. Justin, 말씀해 주세요.

푸사카 또는 글램스테르담에서의 FOCIL? (52:07)

저스틴: 자, 마음의 준비를 단단히 하세요. 검열 문제를 해결하기 가장 좋은 시기는 검열이 발생하기 전이라는 아주 좋은 지적을 해주셨죠? 그렇다면 FOCIL은 푸사카에 포함되어야 할까요, 아니면 글램스테르담까지 기다려도 될까요? 그리고 개발자로서 저는 어느 쪽을 지지해야 할까요?

토마스 티에리: 저희는 PR을 열었고 병합되었으며, FOCIL은 푸사카에 제안되었습니다. 저희는 푸사카에 포함되어야 한다고 생각합니다. 그 이유 중 하나는 일부 클라이언트가 이미 작업을 시작했고 큰 장애물에 부딪히지 않았기 때문입니다. 구현하기 훨씬 어렵고 훨씬 더 많은 작업이 필요한 다른 제안들과는 다릅니다. 그리고 논란의 여지도 별로 없습니다. 검열 저항성에 반대하는 사람은 아무도 없을 것이며, 모두가 가능한 한 빨리 포함되어야 한다는 데 어느 정도 동의하고 있습니다. 그래서 저는 푸사카를 선택하겠습니다.

기다릴 수 있을지 없을지는 모르겠습니다. 제안과 업그레이드는 항상 기다릴 수 있습니다. 저는 단지 이러한 변경 사항을 구현하기가 쉽지 않은 상황을 피하고 싶을 뿐입니다. 상황은 아주 빨리 뒤바뀔 수 있습니다. 우리가 보았듯이, 반대의 경우도 있었습니다. 몇 달 전, 주요 빌더 중 한 곳이 갑자기 검열을 중단했습니다. 이유를 물었더니 "네, 그냥 안 하기로 결정했어요"라고 하더군요. 그 경우는 좋은 쪽이었기 때문에 다행이었지만, 상황이 완전히 뒤집혀서 두 빌더가 일부 트랜잭션을 검열하게 된다면 우리는 다시 아주 나쁜 상황에 처하게 될 것입니다.

제가 중요하다고 생각해서 언급하고 싶은 또 다른 점이 있습니다. 우리가 작업한 일부 설계를 통해 증명자와 제안자를 실제로 분리할 수 있는 APS와 같이 우리가 이야기했던 방향으로 나아간다면, 그 전에 FOCIL이 도입되어야 하고 FOCIL이 제대로 작동하는지 확인해야 합니다. 이더리움의 검열 저항성 속성을 유지하고 개선한다는 목적을 제대로 달성하고 있는지 확인하려면 메인넷에서 6개월, 1년 동안 FOCIL을 실행해 보아야 합니다. 따라서 적어도 저에게 또 다른 시급한 문제는, 타이밍 게임이나 APS를 통해 해결하고자 하는 다른 우려 사항으로부터 증명자를 보호하려면 가능한 한 빨리 FOCIL을 도입해야 한다는 것입니다.

푸자 란잔: 제안이 다음이나 가장 가까운 업그레이드에 채택되지 않는 것을 보면 가끔 안타깝지만, 한 번의 업그레이드에 포함될 수 있는 제안의 수는 한정되어 있습니다. 제안을 발의하고, 준비하고, 테스트하는 과정에 들어간 모든 노고에 진심으로 감사드립니다. 이더리움 생태계를 위해 해주시는 모든 일에 정말 감사드립니다.

래피드 파이어 (55:18)

푸자 란잔: 마무리하기 전에 간단한 래피드 파이어(단답형 질문) 시간을 갖겠습니다. 유일한 조건은 대답을 한 단어나 한 문장으로 해야 한다는 것이며, 타이머를 맞춰서 각각 30초 정도로 진행해 보겠습니다. 준비되셨다면 줄리안부터 시작하겠습니다. 현재 블록체인 연구에서 가장 어려운 문제는 무엇인가요?

줄리안 마: 너무 장난스럽게(meme-y) 하지 않고 진지하게 대답하겠습니다. 가장 어려운 문제는 스테이킹의 미래라고 생각합니다. 스테이킹의 미래가 무엇을 의미하는지, 어떤 서비스 제공자가 어떤 역할을 하는지, 그에 대한 보상은 어떻게 받는지, 그리고 그들이 서로 어떻게 연관되어 있는지 말입니다.

푸자 란잔: 아직 충분히 탐구되지 않은 블록체인 사용 사례 하나를 꼽는다면 무엇인가요?

줄리안 마: FOCIL이라고 생각합니다.

푸자 란잔: 오늘날 이더리움의 가장 큰 보안 위험은 무엇인가요?

줄리안 마: 솔직히 말해서 여기서는 검열 저항성이 매우 중요하다고 생각합니다. 예를 들어 L2에 엄청난 보안 위험을 초래할 수 있는 다중 블록 MEV 같은 것들 때문입니다.

푸자 란잔: MEV는 최소화해야 할까요, 수용해야 할까요, 아니면 그 중간쯤이어야 할까요?

줄리안 마: 저는 이 부분에서 Flashbots의 의견에 대체로 동의합니다. 즉, 민주화되어야 한다는 뜻인데, 필요한 곳에서는 극대화하고 애플리케이션 레이어에서는 최소화해야 한다는 의미입니다.

푸자 란잔: 탈중앙화는 항상 그에 따른 트레이드오프(상충 관계)를 감수할 가치가 있나요?

줄리안 마: 대개는 감수할 가치가 있습니다.

푸자 란잔: 이더리움이 세상에 가져온 가장 큰 혁신은 무엇인가요?

줄리안 마: 여기서 저는 디지털 재산권에 대한 마이크 노이더(Mike Neuder)의 데브콘(Devcon) 강연을 인용하고 싶습니다. 세상을 진정으로 바꾸고 있는 것은 검열 저항성을 갖춘 디지털 재산권이라고 생각합니다.

푸자 란잔: 정말 감사합니다. 답변을 아주 잘해주셨네요. 다음 질문은 토마스에게 드리겠습니다. 만약 이더리움이 존재하지 않았다면, 어떤 블록체인에서 일하고 계셨을까요?

토마스 티에리: 저는 아주 장난스럽게 대답할 것 같은데, 줄리안도 똑같이 할 줄 알았기 때문에 그가 제 선수를 좀 쳤네요. 그 블록체인은 FOCIL일 것입니다.

푸자 란잔: 블록체인 사용 사례 중 가장 과대평가된 것은 무엇인가요?

토마스 티에리: FOCIL이 없다면 어떤 사용 사례도 과대평가할 가치가 없습니다.

푸자 란잔: 이더리움이 가능한 한 빨리 개선해야 할 한 가지는 무엇인가요?

토마스 티에리: FOCIL을 통한 검열 저항성입니다.

푸자 란잔: 탈중앙화를 한 단어로 표현한다면요?

토마스 티에리: FOCIL입니다.

푸자 란잔: 이더리움이 확장성 문제를 완전히 해결할 것이라고 생각하시나요?

토마스 티에리: FOCIL이 적용된 이더리움이라면, 그렇습니다.

푸자 란잔: 레이어 1 (l1) 확장과 레이어 2 (l2) 확장 중 어느 쪽이 이길까요?

토마스 티에리: 무한한 레이어들, 그리고 그 모든 것에 FOCIL이 함께할 것입니다.

푸자 란잔: 아주 잘해주셨습니다. 정말 감사합니다, 토마스. 이 모든 질문에 답해주셔서 감사합니다. 이제 마무리를 하면서 두 분께 기회를 드리고 싶습니다. 이 제안에 대해 커뮤니티에 전하고 싶은 메시지나, 이더리움 커뮤니티 전반에 전하고 싶은 말씀이 있으신가요?

커뮤니티에 전하는 메시지 (58:08)

Thomas Thiery: 사실 그것은 매우 중요한 부분입니다. 왜냐하면 저희는 항상 활발하게 토론을 진행하고 있으며, 이 모든 과정이 디스코드에 공개되어 있기 때문입니다. 초기부터 모든 것을 공개하려는 노력이 있었고, 사람들이 실제로 그렇게 하고 있어서 매우 기쁩니다. 공개된 Eth R&D 디스코드의 inclusion-list 채널에서 토론과 진행 상황을 확인하실 수 있습니다. 현재 모든 작업이 기본적으로 그곳에서 이루어지고 있습니다. 또한 트위터, 텔레그램 등 어디서든 저희에게 연락하실 수 있습니다. 편하게 연락해 주세요.

더 많은 사람들과 대화하고 참여를 유도할수록, 설계와 구현은 더욱 개선될 것입니다. 따라서 어떤 방식으로든 도움을 주실 수 있다면 연락해 주시기 바랍니다. 연구 측면을 포함한 모든 부분에서 기꺼이 도움을 드리겠습니다. FOCIL의 미래를 위해 함께 일하고 싶은 분들과 협력하는 것이 저희에게는 더욱 적합할 것 같습니다. 앞서 프라이버시와 트랜잭션 수수료 메커니즘을 언급했는데, 저희는 블롭을 위한 FOCIL에도 많은 초점을 맞출 예정입니다. 이 모든 것에는 사람과 연구 노력이 필요합니다. 관심이 있으시다면 연락해 주세요. 초대해 주셔서 대단히 감사드리며, 이더리움을 위해 애써주시는 모든 노력에도 감사드립니다.

Julian Ma: 덧붙이자면, 저희를 통해 많은 분들이 FOCIL에 열정을 가지게 되셨기를 바랍니다. 관심이 생기셨다면 저희에게 알려주세요. 또한 아직 궁금한 점이 있으시다면 기꺼이 답변해 드리겠습니다. 이를 통해 FOCIL이 진정으로 나아가야 할 방향이라는 점을 확신시켜 드릴 수 있기를 바랍니다. 정말 감사합니다. 이 자리에 함께할 수 있어서 정말 즐거웠고, 세션을 주최해 주셔서 감사합니다. 물론 참석해 주신 모든 분들께도 감사드립니다.

마무리 (59:52)

푸자 란잔: 감사합니다. 이것으로 마치겠습니다. 오늘 함께해 주시고 EIP-7805에 대한 통찰력을 공유해 주신 토마스와 줄리안에게 큰 감사를 드립니다. 모든 참가자분들께도 감사드립니다. 여러분의 질문은 큰 힘이 되었고 유익했습니다. 시청해 주셔서 감사합니다. 오늘 대화가 즐거우셨다면 좋아요와 구독을 눌러주시고, 동료 이더리움 열성 팬들과 이 에피소드를 공유해 주세요. PEEPanEIP에서 더 많은 EIP와 연구 진행 상황을 전해드리겠습니다. 다음 시간까지 지식과 함께 가르랑거리며, Ethereum Cat Herders와 함께 이더리움 곳곳을 누비시길 바랍니다. 남은 하루도 즐겁게 보내세요.