Ethereum의 종료 대기열에 유연성 추가
본 기사는 최근 제안된 이더리움 개선 제안(EIP)-7922에 대한 내용을 담고 있습니다.
^출처: https://www.youtube.com/watch?v=bl91wk5fB4g
작성자: mike neuder , mallesh pai , mikhail kalinin (mik-mal-mik) – 2025년 4월 1일
\uparrow ↑ 하지만 만우절 농담은 아니야
내용물
1. Introduction
2. Revisiting the current exit queue
3. Improving the exit queue
4. Connection to past work
tl;dr; 이더리움 개선 제안(EIP)-7922 에서 제안된 대로 Ethereum 종료 대기열에 대한 잠재적인 변경 사항을 설명합니다. ELI5 게시물에서는 Ethereum이 오늘날 검증자 종료를 관리하는 방법과 Prague/Electra 업그레이드에서 발생하는 변경 사항에 대해 설명했습니다. 이 게시물은 프로토콜의 보안 모델을 변경하지 않고도 대기열의 효율성을 개선하기 위해 대기열에 대한 추가 변경 사항을 동기를 부여합니다.
1. 서론
이더리움의 지분 증명 메커니즘은 확정된 거래의 책임 있는 안전성을 보존하기 위해 종료 대기열을 구현합니다(자세한 내용은 "종료 대기열이 있는 이유는 무엇입니까?"를 참조하세요). 검증자 종료율(때때로 검증자 이탈 이라고 함)을 제한하는 것은 필요하지만, 지나치게 제한하면 인출해야 할 경우 오랜 지연 위험에 직면하는 정직한 검증자에게 영향을 미칩니다. 이는 또한 프로토콜에 비용이 많이 듭니다. 표준 금융 이론에 따르면 비교적 유동성이 낮은 자산은 동일한 양의 자본 유치하기 위해 더 높은 수익률을 제공해야 합니다. 이는 스테이 킹 에도 준용됩니다. 따라서 종료 대기열은 프로토콜 보안 제약 조건을 고려하여 최대한 효율적으로 만들어야 합니다.
이 글에서는 종료 대기열 설계에 대한 연구를 바탕으로 동적 이탈 한도를 추가하는 것을 제안하는 이더리움 개선 제안(EIP)-7922를 소개합니다. 이 변경은 이더리움의 보안을 손상시키지 않으면서 검증자의 삶의 질을 극적으로 향상시킵니다.
2. 현재 종료 대기열 다시 방문
" 종료 프로세스 "에서 설명한 대로 자발적 종료의 첫 번째 단계는 종료 대기열 입니다. "churn" 제한은 주어진 에포크에서 종료할 수 있는 검증자 수를 결정하며 현재 다음과 같이 계산됩니다. \max(8, \lfloor \# \text{ validators} / 2^{16} \rfloor) max ( 8 , ⌊ # validators / 2 16 ⌋ ) ( get_validator_activation_churn_limit 참조 ) 2025년 4월 1일 기준으로 이는 \lfloor 1,065,882/2^{16} \rfloor=16 ⌊ 1 , 065 , 882 / 2 16 ⌋ = 에포크당 16번의 종료에 해당합니다(예: 대기열에 160개의 검증자가 있는 경우 새로 대기열에 추가된 검증자는 약 1시간 후에 10개의 에포크에서 종료됩니다).
거래의 경제적 보안이 너무 빨리 감소하지 않도록 하기 위해 속도 제한을 한다는 점을 기억하세요. 에포크당 16개의 종료 보안 모델을 이해하는 또 다른 방법은 검증자 종료 주변에 다음과 같은 "제약 조건"을 인코딩한다는 것입니다.
- 다음 에포크에서 최대 16명의 검증자가 종료되고
- 다음 두 에포크에서 최대 32명의 검증자가 종료되고
- 다음 3개 에포크에서 최대 48명의 검증자가 종료되고
… - 최대 16 \cdot ⋅ n 검증자가 다음 n 에포크에서 종료됩니다.
…
동등하게, 1,065,882명의 검증자를 통해, 우리는 이러한 제약을 최종화된 거래의 경제적 보안 감소율 로 설명할 수 있습니다. 거래의 경제적 보안은 다음보다 더 이상 감소하지 않습니다.
- 16/1,065,882 = 0.0015\% 16 / 1,065,882 = 0.0015 % 한 에포크 에서 ,
- 32/1,065,882 = 0.0030\% 32 / 1 , 065 , 882 = 0.0030 % 두 에포크에서,
… - 3600/1,065,882 = 0.34\% 3600 / 1 , 065 , 882 = 0.34 % 225 에포크(1일)
… - 50,400/1,065,882 = 4.7\% 50,400 / 1,065,882 = 4.7 % 3,150 에포크 ( 2 주 )
… - 108,000/1,065,882 = 10.1\% 108,000 / 1,065,882 = 10.1 % 6,750 에포크 ( 30 일 )
… - 324,000/1,065,882 = 30.4\% 324,000 / 1,065,882 = 30.4 % 20,250 에포크 ( 90 일 )
이러한 제약은 해석하기 쉽습니다. 예를 들어, (5)를 "완료된 거래는 향후 30일 동안 책임 있는 안전성의 10% 이하를 상실합니다."라고 읽을 수 있습니다. 거래의 경제적 안정성이 시간이 지남에 따라 감소하는 반면, 장기 재편/안전 결함의 가능성도 감소한다는 점을 기억하세요. 따라서 거래의 결제 보증은 시간이 지날수록 매우 높게 유지됩니다.
주요 관찰 사항: 위에서 언급한 제약 조건 중 일부는 프로토콜에 매우 중요하기 때문에 과거 출금 내역에 관계 없이 에포크당 16개의 종료만 허용하는 것은 지나치게 제한적입니다.
예를 들어 설명하겠습니다. 검증자가 100만 명인 경우 현재 프로토콜은 에포크당 16명의 검증자가 종료할 수 있도록 지정합니다. 2주 동안 이는 50,400회의 종료에 해당합니다. 이는 "검증자의 5.04% 이하( 예치(stake) 와 동일)만이 2주 이내에 종료할 수 있음"으로 직접 해석됩니다. 이것이 프로토콜이 신경 쓰는 유일한 제약 조건이라고 가정해 보겠습니다. 이제 지난 13일 동안 프로토콜에서 종료한 검증자가 없고, 따라서 2주간 이탈 한도가 전혀 사용되지 않았다고 가정해 보겠습니다. 검증자 세트의 3%(검증자 30,000명)을 보유한 대규모 스테이킹 운영자가 즉시 인출하려고 하면 즉시 인출할 수 있어야 합니다. 이는 5.04%의 2주 한도를 위반하지 않습니다. 그러나 앞으로 에포크당 16회의 종료만 처리할 수 있으므로 1875개 에포크(8.33일과 동일)를 기다려야 합니다.
주요 관찰 사항: 프로토콜이 종료 기록을 과거로 되돌릴 수 있게 되면 앞으로는 더 이상 하드한 에포크당 제한이 필요 없게 됩니다.
예를 들어, 현재 제안된 이더리움 개선 제안(EIP)-7922 에서는 다음과 같은 제약 조건을 명시적으로 선택했습니다.
제안된 약한 주관성 제약: 2주 동안의 연속적인 기간 동안 검증자가 50,400명을 넘지 않도록 합니다.
그런 다음, 우리는 모든 에포크 동안 종료에 하드 캡을 설정하지 않고도 모든 롤링 2주 기간 동안 제약 조건이 존중되도록 보장하기만 하면 됩니다. 과거 검증자 종료 데이터를 기반으로 동적으로 조정된 이탈 한도를 통해 이더리움은 모든 2주 기간 동안 동일한 보안을 유지하면서 종료 수요의 급증을 유연하게 수용할 수 있습니다.
3. 종료 대기열 개선
이더리움 개선 제안(EIP) -7922는 이 변경 사항을 구현합니다. 이더리움 개선 제안(EIP) -7251 에서 검증자의 잔액이 다를 수 있으므로, 우리는 먼저 "검증자 수" 대신 " 이더리움(ETH) 양"을 기준으로 종료를 재분류합니다. 다시 말하지만, 오늘날의 값을 사용하면 약 34mm의 이더리움(ETH) 스테이킹되어 있습니다. 이는 에포크당 16 \cdot ⋅ 32 = 512 이더리움(ETH) 이탈할 수 있는 자격이 있음을 의미합니다. 이더리움 개선 제안(EIP)-7251의 복잡성으로 인해 종료에 대한 에포크당 이탈 한도는 256 이더리움(ETH) 로 제한됩니다(자세한 내용은 "2.2 - 종료 대기열 이탈 한도 변경" 참조). 3584(= 256 \cdot ⋅ 14)개 이상의 에포크(약 17일, 아래에서 대략적인 약한 주관성 기간으로 사용)를 통해 256 \cdot ⋅ 3584 = 917504 이더리움(ETH) (총 34mm 이더리움(ETH) 지분의 2.7%)가 종료될 수 있습니다.
제안된 이더리움 개선 제안(EIP) 이러한 값을 종료 대기열이 보장하는 단일 제약 조건으로 인코딩합니다.
이더리움 개선 제안(EIP)-7922 제약 조건(오늘의 예치(stake) 숫자 사용) - 17일 동안 최대 917504(=256 \cdot ⋅ 256 \cdot ⋅ 14) 이더리움(ETH) 변동할 수 있음(전체 34mm 이더리움(ETH) 지분의 2.7%).
중요한 점은, 이 단일 제약 조건이 여전히 프로토콜의 약한 주관성이 그대로 유지되도록 하는 열쇠라는 것입니다. 이 메커니즘은 더 짧은 시간 범위에서 종료 대기열에 더 많은 유연성을 제공함으로써 보안을 손상시키지 않고 더 반응성이 좋을 수 있습니다. 아래 그림은 제안된 변경 사항을 보여줍니다.
그림 1. 두 대기열 모두 동일한 제약 조건을 구현하여 M+1 M + 1 에포크 시간 범위에 걸쳐 최대 16 \cdot (M+1) 16 ⋅ ( M + 1 ) 개의 종료가 발생하지 않도록 합니다. 현재 대기열은 허용되는 종료 수에 대한 에포크당 제약 조건을 설정하여 이를 적용합니다. 우리는 지난 M+ 1 M + 1 에포크에 대해 단일 제약 조건을 명시적으로 확인하는 단순화된 대기열을 제안합니다.
메커니즘이 구현되는 방법에 대한 자세한 내용은 이더리움 개선 제안(EIP)-7922를 참조하세요. 1. Introduction 에서 언급했듯이 현재 종료 대기열의 제한은 자산 이더리움(ETH) 에 재정적 영향을 미칩니다. 이 업그레이드가 Ethereum의 스테이킹 생태계에 광범위한 영향을 미칠 것으로 생각합니다.
- 스테이킹 프리미엄 감소 : 지연과 관련된 유동성 위험을 줄임으로써 이러한 메커니즘은 자본 유치하는 데 필요한 필수 스테이킹 보상을 낮출 수 있습니다.
- 향상된 자본 효율성 : 더욱 반응성 있는 종료 메커니즘을 통해 더 광범위한 이더리움 생태계에서 보다 역동적인 자본 배분이 가능해졌습니다.
- 향상된 프로토콜 견고성 : 더 나은 종료 메커니즘은 시장 변동성 이벤트 중에 검증자가 "갇히는" 위험을 줄여줍니다.
처리할 수 있는 출금 금액에는 여전히 엄격한 제한이 있으며 , 이 제안은 종료 속도를 보장하지 않는다는 점에 유의해야 합니다. 대신, 이는 출금 수요의 갑작스러운 급증을 처리하는 데 있어 종료 대기열에 더 많은 유연성을 제공하는 것을 목표로 합니다. 향후 네트워크 업그레이드에 포함될 가능성을 향해 노력하면서 커뮤니티 피드백을 환영합니다.
4. 과거 작업과의 연결
이 이더리움 개선 제안(EIP) Max Resnick 과 함께 작성한 최적 종료 대기열에 대한 이전 논문을 직접 확장한 것입니다. 해당 작업에서 동적 대기열 시스템인 MINSLACK을 소개했습니다. 이 이더리움 개선 제안(EIP) 와 마찬가지로 MINSLACK은 각 에포크에서 일정한 최대 검증자 수를 처리하는 대신 과거 데이터와 주어진 보안 제약 조건 모음을 기반으로 얼마나 많은 검증자가 안전하게 종료할 수 있는지 계산합니다. 구체적으로, 최근 에포크에서 사용되지 않은 인출 용량인 "슬랙"을 확인하여 허용되는 종료를 결정합니다. MINSLACK은 이전 에포크에서 허용되는 최대값보다 적은 검증자가 종료된 경우 프로토콜이 현재 에포크에서 더 많은 종료를 안전하게 처리하면서도 전체 시간 창에 걸쳐 동일한 전반적인 책임 있는 안전 보장을 유지할 수 있다는 것을 인식하여 이 슬랙을 활용합니다.
이 이더리움 개선 제안(EIP) 3. Improving the exit queue 에서 설명한 단일 제약 조건만 구현하는 MINSLACK의 간소화된 버전입니다. 저희의 분석에 따르면 모든 검증자가 종료에 대해 비슷한 긴급성(균질한 값)을 가질 때 MINSLACK이 최적입니다. 간단히 말해서, MINSLACK은 Ethereum의 보안을 고려할 때 가능한 가장 빠른 종료율을 달성합니다. 이 이론적 프레임워크를 기반으로, 약한 주관성 기간을 인코딩하는 단일 제약 조건이 있는 MINSLACK 알고리즘이 현 상태를 개선한다고 확신합니다. 커뮤니티가 다른 시간적 지평에 걸쳐 더 많은 제약 조건이 필요하다고 느낀다면, 이 이더리움 개선 제안(EIP) 전체 MINSLACK 알고리즘을 구현하도록 쉽게 확장될 수 있습니다. 또한 저희 논문은 종료가 우선 순위를 입찰할 수 있는 능력도 조사합니다. 입찰 크기에 따라 대기열을 정렬하는 수정된 버전의 MINSLACK(우선순위 대기열 구현)이 이기종 값 설정에서 거의 최적임을 보여줍니다. 이는 종료 대기열 프로세스에 대한 추가적인 후속 개선으로 사용될 수 있으며, 커뮤니티에서 관심이 있는지 논의하고 싶습니다.
–
로 만든 
그리고 mik-mal-mik의 마크다운
