이더리움이 확장성 로드맵을 발표했습니다. 이번에는 어떤 점이 다른가요?
원문 작성자: @VitalikButerin
번역: Peggy, BlockBeats
에디터 주: 이더리움 생태계의 규모가 계속 확장되면서, 네트워크 확장을 이루는 동안 보안성과 탈중앙성을 희생하지 않고 어떻게 이루어질 수 있는지가 핵심 주제가 되었습니다. 이 문서에서 Vitalik Buterin은 이더리움의 확장 경로를 자세히 설명하고 있습니다: Gas 메커니즘 최적화 및 블록 검증 병렬화 등 기술적 개선을 통해 실행 효율성을 향상시키는 단기 전략, 그리고 ZK-EVM 및 blobs 데이터 아키텍처를 장기 전략으로 하여 네트워크 규모를 확대하는 방향입니다.
전반적으로, 이 경로는 몇 년 동안 이더리움의 네트워크 용량을 계속해서 확장하는 데 기초가 되는 단계별 확장 솔루션을 제공하려는 목적을 갖고 있습니다.
아래는 원문입니다:
이제 확장에 대해 이야기해보겠습니다. 여기서는 주로 단기 확장과 장기 확장으로 나뉩니다.
단기 확장
단기 확장에 대해선 제가 이미 다른 곳에서 일부를 썼습니다. 핵심 아이디어는 대략 다음과 같습니다:
· 블록 레벨 액세스 리스트(block-level access lists) (Glamsterdam 업그레이드에서 도입 예정)는 블록 검증을 병렬화할 수 있게 합니다.
· ePBS(또한 Glamsterdam에서 도입)에는 여러 기능이 있지만 그 중 하나는 각 slot에서 블록 검증에 더 많은 비중을 안전하게 두는 것입니다. 현재처럼 수백 밀리초만 사용하는 대신 더 많은 비중의 slot 시간을 사용할 수 있습니다.
· Gas 재가격(gas repricing)은 각 유형의 작업이 실제 실행 시간과(및 다른 비용)에 따라 gas 비용을 일관되게 유지하도록 합니다. 우리는 또한 다차원 gas(multidimensional gas) 메커니즘을 초기 단계에서 탐구하고 있으며, 서로 다른 자원에 대한 상한선을 개별적으로 설정할 수 있습니다. 이 두 가지를 조합하면, 극단적인 경우에 대해 걱정하지 않고도 더 많은 비중의 slot 시간을 사용하여 블록을 검증할 수 있습니다.
다차원 gas에 대해, 우리는 단계적인 로드맵을 수립했습니다. 첫 번째 단계는 Glamsterdam 업그레이드 중, "상태 생성 비용"과 "실행 및 calldata 비용"을 분리하는 것입니다.
예를 들어, 현재: SSTORE 작업은, 저장 슬롯을 0이 아닌 값 → 0이 아닌 값으로 변경하면 가스 비용은 5000 가스이고, 0 → 0이 아닌 값으로 변경하면 가스 비용은 20000 가스입니다.
Glamsterdam의 한 번의 가스 재조정에서이 추가 비용은 상당히 높아집니다(예 : 60000으로 증가). 이 작업의 목표는 가스 한도를 높이면서 실행 능력의 확장 속도가 상태 크기의 확장 속도보다 훨씬 빠르게 되도록 하는 것입니다.
그 원인에 대해 이전에 썼던 내용은 다음과 같습니다: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
따라서 Glamsterdam에서는이 SSTORE 작업이 5000의 "보통 가스"를 소비할 것이며, 예를 들어 55000의 "상태 생성 가스"를 소비할 것입니다.
즉, 지금보다 더 큰 스마트 계약을 생성하는 것이 가능해집니다.
EVM에서 다차원 가스는 어떻게 구현되나요?
여기서 한 가지 문제가 발생합니다: EVM의 설계는 기본적으로 가스에는 하나의 차원만 있으며 GAS, CALL 등의 opcode는이 가정에 따라 작동합니다.
우리의 해결책은 두 가지 불변을 유지하는 것입니다:
만약 X 가스로 호출을 시작하면 해당 호출은 X 가스를 소유하고 "일반 작업"이나 "상태 생성" 또는 향후 추가될 수있는 다른 차원에 사용할 수 있습니다.
만약 GAS opcode가 현재 Y 가스를 가지고 있다고 하면 X 가스를 소비하는 호출을 시작하면 호출이 반환된 후에도 여전히 최소 Y − X 가스를 보유하여 후속 작업에 사용할 수 있습니다.
구체적인 구현 방법은 다음과 같습니다: 우리는 N+1 개의 가스 차원을 도입합니다. 기본적으로 N = 1 (상태 생성)이고 추가 차원은 리저보이어(reservoir)라고합니다.
EVM의 실행 로직은 다음과 같습니다:
가능한 경우 전용 차원 가스를 우선적으로 소비합니다
부족한 경우, 리저보이어(rervoir)에서 추가로 사용하십시오.
예를 들어, 다음을 보유하고 있다고 가정하면: (100000 상태 생성 가스, 100000 리저보이어)
SSTORE를 사용하여 세 개의 새로운 상태를 생성하는 경우, 가스의 변화는 다음과 같습니다: (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
이 설계에서:
GAS 옵코드는 리저보이어를 반환합니다.
CALL은 리저보이어에서 지정된 양의 가스를 넘겨받으며 동시에 모든 리저보이어 이외의 가스를 넘겨받습니다.
다차원 가스 가격 책정
나중에 우리는 다차원 가격 책정(multi-dimensional pricing)을 소개하여 각종 자원 차원이 다른 부동의 가스 가격을 갖도록 할 것입니다.
이로써 다음이 이루어집니다:
더 나은 장기적인 경제적 지속가능성
자원 할당의 최적화
자세한 내용은: https://vitalik.eth.limo/general/2024/05/09/multidim.html
그리고 리저보이어(rervoir) 메커니즘은 글의 마지막에서 언급된 서브콜(sub-call) 문제를 해결하는 데 정확히 온전히 이상적입니다.
장기 확장
장기 확장은 주로 ZK-EVM 및 Blobs 두 가지 방향으로 이루어집니다.
Blobs
Blobs에 대해서는 계속해서 PeerDAS를 발전시키고, 최종적으로는 대략 8 MB/초의 데이터 처리량을 얻고자 합니다.
이 스케일은:
이더리움 자체 요구를 충분히 만족합니다
전 세계적인 데이터 계층이 되는 것을 의도하지 않습니다.
현재 blobs는 주로 L2에서 사용됩니다. 미래 계획은 이더리움 블록 데이터가 직접 blobs에 기록되도록 하는 것입니다.
이 작업의 목적은 사람들이 전체 체인을 다운로드하고 다시 실행하지 않고도 높은 확장성을 갖춘 이더리움 네트워크를 검증할 수 있도록 하는 것입니다:
ZK-SNARK는 다시 실행 요구 사항을 제거합니다.
PeerDAS + blobs는 모든 데이터를 다운로드하지 않고도 데이터 가용성을 검증할 수 있습니다.
ZK-EVM
ZK-EVM에 대해, 우리의 목표는 네트워크가 이에 대한 의존성을 점진적으로 높이는 것입니다.
2026 년: ZK-EVM을 지원하는 클라이언트가 나타날 것으로 예상되며, 노드가 ZK-EVM을 사용하여 attestation에 참여할 수 있게 될 것입니다. 그러나 이러한 클라이언트는 아직 충분히 안전하지 않아 전체 네트워크가 이에 의존하여 작동하는 것은 아닙니다. 그러나 전체 네트워크의 약 5%가 해당 클라이언트를 사용하는 경우는 수용할 수 있습니다. (ZK-EVM에 문제가 발생하면 스테이킹한 자산이 처벌되지는 않지만, 잘못된 블록 위에 구축될 수 있어 수익이 손실될 수 있습니다.)
2027 년: 우리는 더 많은 비율의 노드가 ZK-EVM을 실행하도록 권장하기 시작할 것이며, 형식적 검증 및 보안 강화에 중점을 둘 것입니다. 심지어 네트워크의 약 20%만이 ZK-EVM을 사용하더라도 gas limit를 크게 높일 수 있습니다. 왜냐하면 이는 솔로 스테이커에게 저비용의 검증 경로를 제공하기 때문이며, 솔로 스테이커의 비율 자체가 20% 미만입니다.
기술이 성숙해지면: 3중 5 강제 증명 메커니즘을 도입할 것입니다. 즉, 블록은 5가지 다른 증명 시스템 중 최소한 3개의 증명을 포함해야만 유효로 간주됩니다. 그 때에는 우리는 인덱싱이 필요한 노드 이외에 대부분의 노드가 ZK-EVM 증명에 의존할 것으로 예상합니다.
장기적으로: ZK-EVM을 계속 향상시켜 더욱 견고하게 만들고 보다 엄격한 형식 검증을 진행할 것입니다. 이 단계에서는 가상 머신 수준의 변경도 포함될 수 있으며, 예를 들어 RISC-V와 같은 방향으로 진화할 수 있습니다.
자세한 내용은 다음을 참조하십시오: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052
BlockBeats 공식 커뮤니티에 참여하세요:
Telegram 구독 그룹：https://t.me/theblockbeats
Telegram 토론 그룹：https://t.me/BlockBeats_App
Twitter 공식 계정：https://twitter.com/BlockBeatsAsia
