원래 제목: "Time, slots, and the ordering of events in Ethereum Proof-of-Stake》

원래 제목: "

저자: Georgios Konstantopoulos, Mike Neuder, Paradigm

원문 편집: wesely

4월 2일, 악의적인 이더리움 네트워크 행위자가 mev-boost-relay의 취약점을 악용하여 MEV 검색자로부터 2,000만 달러를 훔쳤습니다(Flashbots 사후 분석 참조). 다음 며칠 동안 개발자들은 기존 네트워크 대기 시간 및 유효성 검사기 정책과 결합하여 4월 6일 이더리움 네트워크에 짧은 기간 불안정을 초래한 5개의 패치를 릴리스하여 버그를 해결했습니다. 재구성은 블록 생산 속도를 줄이고 결제 보장을 줄이므로 네트워크 건강에 좋지 않습니다.

이 기사는 mev-boost와 합의 사이의 상호 작용을 탐구하고 Ethereum의 지분 증명 메커니즘의 미묘함을 밝히고 가능한 몇 가지 방법을 설명하는 것을 목표로 합니다. 우리는 검색자에 대한 공격과 네트워크 불안정의 순간에서 영감을 받았습니다.

mev 부스트란? 왜 중요 함?

mev-boost는 이더리움 네트워크에 부정적인 영향을 미치는 최대 추출 가능 가치(MEV)를 완화하기 위해 Flashbots와 커뮤니티에서 설계한 프로토콜입니다.

• mev-boost에는 세 가지 역할이 있습니다.

• 릴레이 - 제안자와 블록 빌더를 연결하는 상호 신뢰 경매인.

• 제안자 - 이더리움의 지분 증명 유효성 검사기.

각 블록에 대한 대략적인 이벤트 순서는 다음과 같습니다.

• 각 블록에 대한 대략적인 이벤트 순서는 다음과 같습니다.

• 빌더는 사용자, 검색자 또는 기타(개인 또는 공개) 주문 스트림으로부터 트랜잭션을 수신하여 블록을 생성합니다.

• 빌더는 블록을 Relay에 제출합니다.

• 릴레이는 블록이 유효한지 확인하고 제안자에게 지불하는 금액을 계산합니다.

• 릴레이는 "blinded" 헤더와 지불 값을 현재 슬롯의 제안자에게 보냅니다.

제안자는 받은 모든 입찰을 평가하고 가장 높은 금액과 관련된 블라인드 헤더에 서명합니다.

제안자는 이 서명된 헤더를 릴레이 사이트로 다시 보냅니다.

블록은 로컬 비콘 노드를 사용하여 릴레이어에 의해 게시되고 제안자에게 반환됩니다. 해당 블록 및 블록 보상 내에서 트랜잭션을 수행하여 빌더와 제안자에게 보상이 분배됩니다.

Relay는 제안자로부터 블록 공간의 공정한 교환과 빌더로부터 MEV 추출을 위한 트랜잭션 시퀀싱을 용이하게 하는 상호 신뢰할 수 있는 제3자입니다. Relay는 제안자가 MEV를 발견한 검색자/빌더에게 할당하는 대신 빌더 트랜잭션을 복제하여 MEV를 얻는 MEV 도난으로부터 빌더를 보호합니다. 릴레이는 빌더 블록을 검증하고, 제안자를 대신하여 슬롯당 수백 개의 블록을 처리하고, 제안자 지불의 정확성을 보장함으로써 제안자를 보호합니다.

mev-boost는 모든 제안자가 빌더 또는 검색자와의 신뢰 관계를 요구하지 않고 MEV에 대한 민주적 액세스를 가능하게 하므로 이더리움의 장기적인 분산화에 기여하는 핵심 프로토콜 인프라입니다.

Ethereum의 포크 선택 규칙 및 mev-boost

공격과 대응에 대해 알아보기 전에 이더리움의 지분 증명(PoS) 메커니즘과 관련 포크 선택 규칙을 살펴보겠습니다. 포크 선택 규칙을 통해 네트워크는 체인 헤드에 대한 합의에 도달할 수 있습니다. The Post-Merge Ethereum Restructuring에 따르면:

포크 선택 규칙은 클라이언트가 평가한 기능으로, 본 블록과 기타 정보를 입력으로 받아 "공식 체인"이 무엇인지 클라이언트에게 출력합니다. 선택할 수 있는 유효한 체인이 여러 개 있을 수 있기 때문에 포크 선택 규칙이 필요합니다(예: 동일한 부모를 가진 두 개의 경쟁 블록이 동시에 게시되는 경우).

포크 선택 규칙에 대해 잘 알려지지 않은 한 가지 측면은 블록 생성에 상당한 영향을 미치는 시간과의 관계입니다.

슬롯 및 서브슬롯 주기

Ethereum PoS에서 시간은 슬롯이라고 하는 12초 단위로 나뉩니다. PoS 알고리즘은 블록을 제안할 슬롯을 얻기 위해 검증자를 무작위로 할당하며, 이 검증자를 제안자라고 합니다. 동일한 슬롯에서 다른 유효성 검사기는 분기 선택 규칙을 적용하여 로컬 보기에서 체인 헤드 위치에 있는 블록의 최신 버전에 투표하는 작업을 할당받습니다. 12초 간격은 세 단계로 나뉘며 각 단계에는 4초가 걸립니다.

슬롯에서 발생하는 이벤트는 다음과 같으며, 여기서 t=0은 슬롯의 시작을 나타냅니다.

슬롯에서 가장 중요한 순간은 t=4의 인증 기한입니다. 증명하는 검증인이 증명 기한까지 블록을 보지 못하면 이전에 수락된 체인의 헤드에 투표합니다(브랜치 선택 규칙에 따라). 블록이 일찍 제안될수록 전파하는 데 더 많은 시간이 걸리므로 더 많은 증인이 축적됩니다(더 많은 검증자가 인증 마감일 전에 블록을 보았기 때문입니다).

네트워크 상태 관점에서 블록 릴리스를 위한 최적의 시간은 t=0(사양에 지정된 대로)입니다. 그러나 블록 값은 시간이 지남에 따라 단조롭게 증가하기 때문에 제안자는 더 많은 MEV가 누적될 수 있도록 블록 게시를 지연할 인센티브가 있습니다. 자세한 내용은 Proof of Stake의 Timed Games 및 이 토론을 참조하십시오.

역사적으로 제안자는 다음 유효성 검사기가 후속 슬롯 블록을 구축하기 전에 블록을 관찰하는 한 유효성 검사 기간 이후 또는 슬롯이 거의 끝날 때까지 여전히 블록을 게시할 수 있습니다. 이것은 상위 블록이 가중치를 상속하고 분기 선택 규칙이 리프 노드에서 종료되어 지연 게시 블록의 부정적인 영향이 없는 곳입니다. 합리적인 행동(블록 릴리스 지연)을 정직한 행동(정시 게시)으로 유도하기 위해 "정직한 재구성"이 구현되었습니다.

제안자 승천과 정직한 개편

• 증명 기한에 대한 주요 의미와 함께 합의 클라이언트에 두 가지 새로운 개념이 도입되었습니다.

• 제안자 부스트(PR) - 전체 증명 가중치의 40%에 해당하는 포크 ​​선택 "부스트"를 제안자에게 부여하여 재조정 공격을 최소화하려고 시도합니다. 중요한 것은 이 개선 사항이 하나의 슬롯에만 지속된다는 것입니다.

정직한 재구성(PR) - 제안자 확대를 채택하고 정직한 제안자가 이를 사용하여 인증 가중치가 20% 미만인 블록의 재구성을 강제할 수 있습니다. 이는 Lighthouse 및 Prysm(v ​​4.0-Capella 릴리스 이후)에서 구현됩니다. 이 변경은 제안자가 내린 로컬 결정이므로 유효성 검사기 동작에 영향을 미치지 않으므로 선택 사항입니다. 따라서 모든 클라이언트에게 동시에 롤아웃하기 위한 조정된 노력이 없었고 특정 하드 포크에 연결되지도 않았습니다.

• 일부 특수한 경우에는 정직 재정렬을 피할 수 있습니다.

• 에포크 경계 블록 동안

• 체인이 완료되지 않은 경우

재정렬된 블록 이전의 슬롯에서 체인 헤드를 가져오지 않은 경우

조건 3은 정직성 재정렬이 체인에서 단일 블록만 제거하도록 보장합니다. 이는 회로 차단기 역할을 하여 네트워크 대기 시간이 극도로 긴 기간 동안 체인이 블록을 계속 생성할 수 있도록 합니다. 이것은 또한 제안자 향상 블록이 규범적인 것으로 간주될 것이라고 더 이상 확신할 수 없기 때문에 네트워크에 대한 제안자의 신뢰도 감소를 반영합니다.

아래 다이어그램은 재구성 전략을 구현하기 위해 정직한 행동이 어떻게 변화하는지 보여줍니다.

이 경우 b 1은 늦게 도착하는 블록을 나타냅니다. 지연으로 인해 b1은 n번째 슬롯의 검증 가중치의 19%만 가집니다. 증명 가중치의 나머지 81%는 상위 블록 HEAD에 할당됩니다. 많은 검증자가 인증 마감일 이전에 b1을 보지 못했기 때문입니다.

정직한 재구성이 없는 경우 슬롯 n+1에서 제안자는 b 1 을 체인의 헤드로 간주하고 하위 블록 b 2 를 구성합니다. 증명 가중치가 19%에 불과함에도 불구하고 제안자는 b1을 재구성하려는 노력을 하지 않습니다. 슬롯 n+1 동안 b 2는 제안자 부스트를 가지며 제시간에 전달된다고 가정하면 해당 슬롯에 대한 대부분의 인증을 축적하여 표준이 됩니다.

솔직히 개편하면 상황이 많이 달라집니다. 이제 epoch n+1의 제안자는 b 1에 대한 19% 인증 가중치가 재구성 임계값보다 낮다는 것을 발견하여 HEAD를 b 2의 부모로 사용하여 새 블록을 만들고 b 1의 재구성을 강제합니다. n+1 epoch에 대한 인증 기한, 정직한 검증자는 b 2(제안자 증가에서 40%)와 b 1(19%)의 상대적 가중치를 비교할 것입니다. 모든 클라이언트는 Proposer Augmentation을 수행하므로 b2는 체인의 헤드로 간주되고 슬롯 n+1에 대한 인증을 축적합니다.

번들 해제 공격에 대한 릴레이 및 비콘 노드 수정

4월 2일 언번들링 공격에서 제안자는 잘못된 서명 헤더를 릴레이에 전송하여 릴레이 취약점을 악용했습니다. 다음 며칠 동안 릴레이 및 핵심 개발 팀은 반복되는 공격의 위험을 완화하기 위해 수많은 소프트웨어 패치를 릴리스했습니다. 다섯 가지 주요 변경 사항은 다음과 같습니다.

• 1. 릴레이 변경 사항:

• 알려진 악의적인 제안자에 대한 데이터베이스를 확인하십시오(초음파 릴레이에 의한 생산에만 사용되며 제거됨).

• 해당 시간 내에 전체 블록이 P2P 네트워크에 전달되었는지 확인합니다.

블록을 게시하기 전에 0-500ms(모든 릴레이에서 제거됨) 범위의 균일한 임의 지연을 도입합니다.

• 2. 비콘 체인 노드 변경(릴레이 비콘 체인 노드에만 적용 가능):

• 브로드캐스팅하기 전에 비콘 블록의 유효성을 확인하십시오.

블록을 게시하기 전에 네트워크에서 동등한 항목을 확인하십시오.

이러한 변화의 조합은 합의 불안정으로 이어지며, 이는 위에서 설명한 정직한 재구성 전략을 사용하는 대다수의 검증자에 의해 더욱 악화됩니다.

의도하지 않은 결과

위의 5가지 변경 사항은 각각 릴레이 블록 해제 핫 경로의 지연 시간을 증가시켜 릴레이 블록이 증명 기한을 초과하고 방송될 가능성을 높입니다. 아래 다이어그램은 이러한 5가지 검사의 순서와 지연 도입으로 인해 블록 게시가 증명 기한을 초과하는 원인이 되는 방법을 보여줍니다.

이러한 검사가 구현될 때까지 t=0(예: t=3)보다 상당히 늦게 도착하는 서명 헤더는 일반적으로 문제가 되지 않습니다. 릴레이 오버헤드는 매우 낮으므로 블록은 t=4 이전에 게시됩니다.

그러나 이 5개의 패치로 인해 대기 시간이 증가함에 따라 이제 릴레이가 브로드캐스트 지연에 부분적으로 책임이 있을 수 있습니다. 다음 가상 시나리오에서 블록 게시를 살펴보겠습니다.

릴레이는 t=3에서 제안자로부터 서명된 헤더를 수신합니다. t=4까지 릴레이는 여전히 확인을 수행하므로 증명 마감일 이후에 브로드캐스트가 발생합니다. 이 경우 서명된 헤더를 늦게 보내는 제안자와 약간의 추가 지연을 도입하는 릴레이의 조합으로 인해 증명 기한을 놓쳤습니다. 정직한 재구성이 없다면 이러한 블록은 온체인으로 갈 가능성이 높습니다. 그림 2에서 볼 수 있듯이 후속 슬롯의 정직한 제안자는 너무 늦어서 거부된 블록을 의도적으로 재구성하지 않습니다. 그러나 정직한 개편의 경우 증명 기한을 놓치면 다음 제안자가 블록을 개편하게 됩니다.

결과적으로 분기된 블록의 수는 공격 이후 며칠 동안 급격히 증가했습니다.

Metrika의 2주 데이터에 따르면 최악의 경우 1시간 이내에 13개 블록(4.3%)이 재구성되었으며 이는 평소보다 약 5배 더 많습니다. 릴레이가 다양한 변경 사항을 출시함에 따라 분기된 블록 수의 극적인 증가가 분명해졌습니다. 릴레이 운영자와 핵심 개발자의 엄청난 커뮤니티 노력 덕분에 영향을 이해하고 네트워크가 정상 상태로 돌아간 후 많은 변경 사항이 취소되었습니다.

현재 가장 유용한 변경 사항은 방송 전 비콘 노드 블록 유효성 검사 및 동등성 확인입니다. 악의적인 제안자는 유효하지 않은 헤더를 릴레이에 보내고 릴레이 비콘 노드가 게시하기 전에 동등한 블록을 보지 못하도록 하여 더 이상 공격을 수행할 수 없습니다. 그럼에도 불구하고 릴레이는 Mev-boost 및 ePBS 중간 공격에 의해 제시된 보다 일반적인 동등성 공격에 여전히 취약합니다.

그래서 우리는 무엇을 해야 합니까?

이를 감안할 때 연구 커뮤니티는 "허용 가능한" 재구성의 양을 평가하고 일반적으로 동등성 공격으로 인한 위험을 고려하여 완화 조치를 구현해야 하는지 여부를 결정해야 합니다.

또한 현재 몇 가지 향후 방향을 적극적으로 모색하고 있습니다.

• 또한 현재 몇 가지 향후 방향을 적극적으로 모색하고 있습니다.

• 동등성 공격으로부터 mev-boost를 보호하기 위해 "headlock"을 구현합니다. 이것은 또한 합의된 클라이언트 소프트웨어에 대한 변경과 증명 기한을 연장하기 위한 사양 변경이 필요합니다.

• mev-boost 소프트웨어에 대한 버그 바운티 프로그램의 수와 가시성을 높입니다.

• 시뮬레이션 소프트웨어를 확장하여 서브슬롯 타이밍이 네트워크 안정성에 미치는 영향을 살펴보십시오. 이는 증명 마감일을 조정하여 재구성을 줄일 수 있는 방법을 평가하는 데 사용할 수 있습니다.

• 불필요한 지연을 줄이기 위해 릴레이에서 블록 게시 경로를 최적화합니다. 이것은 이미 연구 중입니다.

• 핵심 프로토콜 기능으로 mev-boost를 인식하고 합의 클라이언트인 ePBS(enshrined-PBS)에 흡수합니다. 2슬롯 ePBS는 동등성 공격에 취약하므로 "헤드락"을 구현하는 것은 여전히 ​​옵션입니다.

• 대기 시간 및 증명 기한 문제를 기반으로 더 많은 하이브 및/또는 사양 테스트를 추가합니다.

• 릴레이 사양의 추가 구현을 구축하여 릴레이 클라이언트 다양성을 장려합니다.

등가 페널티를 조정하는 것을 고려하되, 극단적인 MEV 기회가 존재하는 경우 32 ETH를 완전히 삭감해도 악의적인 행동을 억제하지 못할 수 있음을 명심하십시오.

전반적으로 우리는 MEV 및 mev-boost 생태계 주변의 새로운 에너지에 대해 기쁘게 생각합니다. 공격과 완화를 분리함으로써 대기 시간, mev-boost 및 합의 메커니즘 간의 중요한 관계를 배웠으며 프로토콜이 계속 강화되기를 바랍니다.