가변 페이로드 마감 시간이 약 6%밖에 도움이 되지 않는 이유는 무엇일까요?

요약: 가변 페이로드 마감 시간은 이론적으로 가스 제한 여유 공간을 약 6% 늘려주지만, 이는 압축된 블록 크기를 기준으로 하며, 블록 크기 분포가 오른쪽으로 심하게 치우쳐 있는 점을 고려하면 선형 보간법으로는 전파 시간을 효과적으로 확장할 수 없습니다. 오히려 현재보다 전파 시간이 더 짧아질 수도 있습니다.

이더리움 개선 제안(EIP)-7732 에 따라 빌더는 페이로드를 제출하고, 페이로드는 네트워크를 통해 전파되며, PTC는 가용성에 대해 투표하고, 검증자는 다음 슬롯 전에 이를 실행합니다.

가변 페이로드 마감 시한은 큰 블록에는 더 많은 전파 시간을 부여하고, 작은 블록에는 더 빨리 도착하여 더 많은 실행 시간을 제공하는 방식입니다. 이론적으로는 타당해 보이지만, 실제로는 얻는 이점이 미미하며 근본적인 문제점을 안고 있습니다.

배경: 이더리움 개선 제안(EIP)-7976 및 통화 데이터 가격 책정

이더리움 개선 제안(EIP)-7976 에 따르면, 콜데이터 최저 요금은 바이트당 64 가스입니다. 표준 요금은 0바이트당 4 가스, 0이 아닌 바이트당 16 가스만 부과합니다. 이 차액(바이트당 최대 60 가스)은 트랜잭션 실행에 필요한 가스로, 트랜잭션이 "무료"로 제공되는 것입니다.

이더리움 개선 제안(EIP)-7976은 Pectra에 포함된 이더리움 개선 제안(EIP)-7623을 개선한 것으로, 0바이트와 0바이트가 아닌 바이트에 대해 통화 데이터 비용을 10/40으로 설정했습니다. 이더리움 개선 제안(EIP)-7976은 최악의 블록 크기를 처리할 때는 0바이트와 0바이트가 아닌 바이트의 구분이 중요하지 않으므로 두 바이트의 비용을 통합 함으로써 한 단계 더 나아갔습니다.

최악의 경우 블록 2개

데이터 크기에 대해 이야기할 때, 우리는 보통 Snappy로 압축된 크기에 초점을 맞춥니다. 하지만 이 프로토콜은 특정 압축 알고리즘을 명시적으로 정의하지 않기 때문에 압축되지 않은 크기도 고려해야 합니다. 이는 문제를 상당히 복잡하게 만들기 때문에 중요한 부분입니다.

가스 제한을 설정할 때, 가능한 모든 블록 하나의 슬롯 안에 들어가야 합니다. 두 가지 극단적인 경우가 있습니다.

• 순수 연산 블록 : 호출 데이터가 없고, 모든 가스는 실행에 사용됩니다. 전파 시간은 전혀 필요하지 않지만 실행 시간은 최대화됩니다.
• 최대 호출 데이터 블록 : 호출 데이터로 가득 차면 플로트(floor)가 발생합니다. 최대 전파 시간이 필요하지만, 가스의 93.75%를 "예약된" 실행으로 확보할 수 있습니다.

핵심 관찰 사항은 다음과 같습니다. 최대 호출 데이터 블록 순수 연산 블록 만큼이나 실행량이 많습니다 . 최저 비용으로 부과되는 64 가스 중 실제 호출 데이터 비용에 사용되는 가스는 4에 불과합니다. 나머지 60은 "예약된" 실행입니다. 따라서 데이터 블록 연산 블록 에 비해 93.75%의 실행량을 사용합니다. 자세한 내용은 이더리움 개선 제안(EIP)-7623 분석을 참조하십시오.

이더리움 개선 제안(EIP)-7623 방식은 최악의 경우 블록 크기를 제한하면서 대부분의 트랜잭션에 대해 하위 호환성을 효과적으로 유지합니다 . 또한 최악의 경우 블록의 경우에도 페이로드 관찰 마감 시간(PTC) 이후에 실행 시간을 "예약"하기 때문에 ePBS와도 잘 작동합니다. 그러나 이러한 "예약된 실행"이 바로 가변 마감 시간의 유용성을 제한하는 요인입니다.

현재 최악의 경우 압축 블록 크기와 EIP-7976 이후의 블록 크기를 비교하려면 이 페이지를 참조하십시오 . 60M 가스 제한에서 현재 블록 크기는 2.24MB이고, EIP-7976 이후에는 938KB입니다. 최악의 경우 블록 크기는 가스 제한에 비례하여 증가합니다.

고정 마감일 vs. 가변 마감일

고정 마감 시한에서는 단일 마감 시한으로 모든 블록을 처리해야 합니다. 이는 가장 큰 블록 에 필요한 전파 시간과 가장 연산량이 많은 블록 에 필요한 실행 시간을 모두 확보하기 위함입니다. 이 두 블록은 서로 다르지만, 고정 마감 시한으로는 이를 구분할 수 없습니다. 결국 어떤 단일 블록 도 두 가지 측면에서 모두 최악의 경우는 아님에도 불구하고, 두 가지 최악의 경우를 모두 고려하게 됩니다.

가변적인 마감 시한으로 인해 각 블록 개별적으로 평가됩니다. 가장 큰 블록 전파 시간이 더 길어지고, 연산량이 가장 많은 블록 실행 시간이 더 길어집니다. 이것이 이론입니다.

그래서 얻는 이득은 뭐죠?

이득은 두 최악의 시나리오 블록의 차이에 비례 합니다. 두 시나리오가 매우 다르다면, 고정된 마감일은 관련 없는 최악의 시나리오를 합산하는 데 많은 낭비를 초래할 것입니다. 반대로 두 시나리오가 거의 동일하다면, 절약할 수 있는 것은 거의 없습니다.

이더리움 개선 제안(EIP)-7976 포함:

두 블록의 실행 필요량은 6.25% 밖에 차이가 나지 않습니다. 이는 고정 마감일로 인한 초과 예약량이며, 가변 마감일은 정확히 이만큼을 회수합니다.

6.25%는 어디서 나온 걸까요? \frac{C}{4F} = \frac{4}{64} C 4 F 에서 나온 겁니다. = 4 64 : 실제 호출 데이터 비용을 나타내는 바닥 비용의 비율이며, "예약된" 실행 비용이 아닙니다. 즉 , 최대 호출 데이터 블록 에서 실제로 호출 데이터 비용을 지불하는 가스의 비율 입니다.

가변 마감 시한을 도입하면 가스 제한 여유 공간을 약 6% 더 확보할 수 있으므로 여전히 고려해 볼 만합니다. 하지만 이는 압축된 블록 크기를 기준으로 한다는 가정에 기반합니다. 실제로는 그렇지 않습니다.

실질적인 이득이 훨씬 적은 이유는 무엇일까요?

약 6%라는 수치는 이론적인 최대치일 뿐입니다. 실제로 이 제안은 압축되지 않은 블록 크기를 기준으로 하고 있으며, 이는 전체적인 접근 방식의 근간을 무너뜨립니다.

데이터 전송에 중요한 것은 전송 중 블록의 크기, 즉 블록이 압축되는 방식입니다. 두 블록 모두 압축 전 크기가 1MB일 수 있지만, 하나는 100KB로 압축되는 반면 다른 하나는 전혀 압축되지 않을 수 있습니다. 전송 방식은 매우 다르지만, 두 블록 모두 동일한 마감 시간을 갖습니다.

이미지 1000×800 90.2KB

더욱 심각한 것은 블록 크기 분포가 오른쪽으로 심하게 치우쳐 있다는 점입니다.

이미지 1100×700 28.8KB

이 분포에서 3.6초와 9초 사이를 선형적으로 보간하면 대부분의 블록은 최소값보다 약간 높은 마감 시간을 갖게 됩니다. 이렇게 되면 전파 시간은 사실상 전혀 확장되지 않으며, 오히려 현재보다 전파 시간이 더 짧아질 수도 있습니다.

PR을 있는 그대로 사용하면 페이로드 관측 마감일이 인증 마감일 근처에 집중되어 ePBS가 원래 제공하는 전파 시간을 상당 부분 잃게 됩니다.

이미지 1100×700 29.3KB

PR이 가스 한도와 이더리움 개선 제안(EIP) -7976 가격을 기반으로 동적 최대 블록 크기를 사용하도록 업데이트된다고 가정하더라도 상황은 크게 개선되지 않습니다.

이미지 1100×700 33.4KB

명확히 하자면, 이는 블롭 마감일과 페이로드 마감일이 같아야 한다는 의미는 아닙니다. 이 둘은 분리되어 있어도 되지만, 가변 페이로드 마감일이 의미를 가지려면 압축 크기에 기반해야 합니다.

이론적인 이득을 개선할 수 있을까요?

더 큰 이론적 이득을 얻으려면 두 최악의 경우 블록 간의 차이가 더 커야 합니다. 즉, "예약된" 실행 비율 a = 1 - \frac{C}{4F} a = 1 − C 4 F를 줄여야 합니다. 여기서 C 는 표준 토큰 비용이고 4F 는 바이트 당 최저 비용입니다.

분명히 두 가지 수단이 있지만, 둘 다 심각한 단점을 가지고 있습니다.

최저 비용을 낮춥니다(예: 64/64 → 32/32). 이렇게 하면 비율이 87.5%로 줄어들고, 가변 마감 시 이득이 12.5%로 두 배가 됩니다. 표준 가격은 4/16으로 유지되어 하위 호환성이 유지됩니다. 하지만 최저 비용이 낮아지면 최악의 경우 블록 크기가 커집니다. 가스 비용이 1억 5천만일 경우 최대 블록 크기가 약 2.25MiB에서 약 4.5MiB로 두 배가 됩니다. 가스 한도를 높이려는 경우 이는 역효과를 초래할 수 있습니다.

표준 비용을 인상합니다(예: 4/16 → 8/32). 이렇게 하면 비율이 87.5%로 직접적으로 줄어들고 이득은 12.5%로 두 배가 됩니다. 하지만 이는 하위 호환성을 깨뜨립니다. 데이터 사용량이 많은 거래뿐만 아니라 모든 거래에 대해 통화 데이터 비용이 더 많이 부과됩니다. 이더리움 개선 제안(EIP)-7976의 설계 목표는 약 98%의 거래가 현재의 4/16 가격을 유지하는 것입니다. 표준 비용을 인상하면 이러한 목표가 저해됩니다.

두 가지 상충 관계가 있습니다. 높은 최저 비용은 블록 크기를 제한하지만(이더리움 개선 제안(EIP)-7623의 주요 목표) "자유로운" 실행을 극대화합니다. 낮은 표준 비용은 하위 호환성을 유지하면서 "자유로운" 실행을 극대화합니다. 이 두 가지 목표 모두 예약 실행 비율을 100%에 가깝게 만들어 가변 마감 시간이 회수될 수 있는 여유 공간을 거의 남기지 않습니다.

여전히 고려해 볼 만한 가치가 있을까요?

이러한 모든 점에도 불구하고, 가변적인 탑재량 마감 시한에는 몇 가지 장점이 있습니다.

• 구현 복잡성이 낮습니다. 이는 PTC에만 영향을 미치는 정직한 검증자 사양에 대한 비교적 간단한 변경 사항입니다. 적어도 이론상으로는 하드포크가 필요하지 않습니다.
• 평균적인 경우의 효율성 향상은 미미합니다. 평균적인 블록 크기는 최악의 경우와는 거리가 멀기 때문에 동적 마감 시한은 일반적인 조건에서 약간의 효율성 향상을 가져올 수 있지만, 압축되지 않은 크기 고정 방식을 고려할 때 프로토콜이 실제로 이러한 향상을 활용할 수 있을지는 의문입니다.
• 건설업체의 정보 우위가 줄어듭니다. 현재는 입찰이 선정된 건설업체만이 최종 확정 후 상황을 가장 먼저 완벽하게 파악할 수 있습니다. 마감일을 가변적으로 설정하면 이러한 정보 비대칭성이 다소 완화됩니다.

이러한 이점은 분명하지만 미미합니다. 이 접근 방식이 잘못된 측정 기준(압축되지 않은 크기)에 기반하고 있다는 점, 실질적인 이점이 이미 작은 6%의 극히 일부에 불과하다는 점, 그리고 현재보다 전파 시간이 악화될 위험이 있다는 점을 고려하면, 이 방식을 도입하는 것은 타당성이 떨어집니다.

진정한 해결책

최선의 해결책은 훨씬 더 복잡하지만, 데이터를 별도의 비용 차원으로 분류하는 것입니다. 이더리움 개선 제안(EIP)-7999는 다차원 수수료 시장을 제안합니다. 이는 하위 호환성을 깨뜨리겠지만, 허용 가능한 최악의 경우 블록을 정확하게 정의할 수 있게 해 줄 것이며, 동적 마감일로 데이터와 컴퓨팅의 얽힘을 덮어씌우려는 시도 대신 데이터와 컴퓨팅을 완전히 분리할 수 있게 해 줄 것입니다.