EVM vs SVM

사용자가 지갑에서 트랜잭션에 서명해 RPC 노드로 보내면 Ethereum의 트랜잭션 처리가 시작됩니다. RPC 노드는 받은 트랜잭션을 자기 멤풀에 넣고 연결된 다른 노드에도 곧바로 전달합니다. 아직 합의에 들어가기 전이지만 이때부터 그 트랜잭션은 네트워크의 누구나 볼 수 있는 공개 상태가 됩니다.

공개되어 있으니 MEV 서처도 그 트랜잭션을 볼 수 있습니다. 서처는 사용자보다 먼저 끼어들거나(프론트런) 바로 뒤에 붙거나(백런) 앞뒤를 함께 감싸는(샌드위치) 방식으로 차익을 챙깁니다. 수수료를 충분히 냈더라도 내 트랜잭션 옆에서 어떤 트랜잭션이 함께 실행될지는 사용자가 정할 수 없습니다. 공개 멤풀을 거치지 않는 Flashbots Protect 같은 사설 경로는 그래서 생겼습니다.

블록을 만드는 쪽과 블록에 서명하는 쪽도 나뉘어 있습니다. 빌더는 모은 트랜잭션으로 블록 후보를 조립합니다. 그런 다음 MEV-Boost를 거쳐 블록 헤더와 입찰가만 그 슬롯의 제안자에게 보냅니다. 제안자는 본문을 확인하지 않고 가장 높은 입찰에 서명합니다. 현재 Ethereum 메인넷 블록 대부분은 이렇게 외부 빌더가 만들고 제안자는 서명만 합니다.

서명된 블록은 다시 네트워크 전체로 퍼집니다. Ethereum은 12초마다 슬롯을 하나씩 열고 슬롯 32개가 모이면 에포크 하나가 끝납니다. 슬롯마다 배정된 위원회 밸리데이터가 블록에 어테스테이션(투표)을 남기고 이 투표가 쌓여 어느 분기를 본 체인으로 볼지 정해집니다. 다만 투표만으로 확정되지는 않습니다. 연속된 두 에포크가 전체 지분의 2/3 이상에게 지지를 받아야 확정에 이르고 여기까지 약 13분이 걸립니다. 그 전에는 짧은 재구성(reorg)이 일어날 수 있습니다.

Ethereum은 이 구조를 일부러 나눠 두었습니다. 주문 흐름은 공개하고 블록 구성은 외부에 맡기며 확정은 느리지만 분명하게 긋습니다. 트랜잭션이 노출되는 시간과 긴 확정 시간은 감수합니다. 그 대신 여러 클라이언트 구현체가 함께 돌아가는 다양성과 부정행위에 지분을 깎는 슬래싱과 한 번 확정되면 되돌릴 수 없는 경계를 얻습니다.

Solana에는 공개 대기열이 없습니다. 지갑은 트랜잭션에 서명할 때 최근 블록해시를 함께 넣습니다. 이 해시는 약 60초 동안만 유효하고 그 시간이 지난 트랜잭션은 그대로 버려집니다. 유효 시간이 짧으니 같은 트랜잭션을 나중에 다시 보내 두 번 실행시키는 시도도 막힙니다. 멤풀이 없어도 이 보호는 작동합니다.

RPC 노드는 트랜잭션을 받으면 먼저 프리플라이트를 돌리고 그 결과를 사용자에게 바로 돌려줍니다. 통과한 트랜잭션은 Gulf Stream을 따라 지금의 리더와 곧 리더가 될 밸리데이터에게 직접 전달됩니다. 노드 사이를 거쳐 퍼지거나 공개 버퍼에 머무는 단계 없이 실제로 처리할 노드에 곧바로 도착합니다.

리더는 받은 트랜잭션을 TPU에 넣습니다. 패킷을 모아 서명을 묶음으로 검증하고 쓰기 계정이 겹치지 않는 트랜잭션끼리 여러 스레드에 나눠 동시에 실행합니다. 실행한 트랜잭션은 PoH 체인에 기록되고 이때 순서가 정해집니다. Solana에서는 합의보다 순서가 먼저 정해집니다.

블록은 다 만든 뒤 한 번에 보내지 않습니다. 리더는 트랜잭션을 처리하는 동안 결과를 shred라는 조각으로 나누어 계속 내보냅니다. 이 조각은 Turbine을 따라 네트워크로 퍼집니다. 다른 밸리데이터는 블록이 완성되기를 기다리지 않고 도착한 shred부터 다시 실행해 결과를 검증합니다. 전파와 실행과 검증이 같은 시간에 겹쳐 진행됩니다.

검증을 마친 밸리데이터는 그 결과에 Tower BFT 투표를 보냅니다. Solana는 확정 상태를 세 단계로 나눕니다. 리더가 처리한 직후는 processed입니다. 전체 지분의 2/3 이상이 같은 블록에 투표하면 confirmed가 되고 보통 400ms~2초가 걸립니다. 그 위로 블록이 31개 이상 더 쌓여 투표 잠금이 최대 깊이에 이르면 finalized가 되고 여기까지 약 12~13초가 걸립니다. Solana에는 Ethereum 같은 슬래싱이 없습니다. 대신 투표를 쌓을수록 되돌리는 비용이 빠르게 커지기 때문에 finalized 상태는 사실상 뒤집히지 않습니다.

Ethereum 밸리데이터는 같은 머신에서 함께 돌아가는 두 프로그램으로 이루어져 있습니다. 2022년 머지 이전에는 클라이언트 하나가 모든 일을 처리했지만 지금은 일부러 둘로 나눠 두었습니다. 이 분리 때문에 네트워크가 장애를 겪고 회복하는 방식도 달라집니다.

실행 클라이언트는 EVM을 돌리고 상태를 보관합니다. 사용자가 보낸 트랜잭션을 실제로 실행하는 쪽입니다. 합의 클라이언트는 비컨 체인을 돌리며 어느 블록을 인정할지 결정합니다. 두 클라이언트는 Engine API라는 정해진 규격으로만 통신합니다.

장애를 한 구현체 안에 가두려고 둘로 나눴습니다. 양쪽 모두 서로 독립된 구현체가 여러 개 있으니 한 클라이언트에 합의를 깨는 버그가 생겨도 그 클라이언트를 쓰는 밸리데이터만 멈추고 체인 전체는 계속 돌아갑니다. 네트워크 전체가 기대는 단일 코드베이스가 없습니다.

대신 운영 부담이 늘어납니다. 운영자는 프로그램 두 개와 데이터베이스 두 개를 유지하고 업데이트도 각각 해야 합니다. 두 프로그램 사이의 API도 하나로 통합된 프로세스라면 필요 없는 계층입니다. 이 구조는 빠른 실시간 처리보다 자기 버그를 견디는 쪽에 맞춰져 있습니다.

Ethereum은 하나로 묶어 빠르게 움직이기보다 장애 격리와 구현체 분산을 먼저 챙깁니다. 밸리데이터는 잘 멈추지 않지만 운영이 무겁고 전체가 한 몸처럼 빠르게 움직이기는 어렵습니다.

Solana는 반대 방향을 택했습니다. 밸리데이터라는 프로그램 하나 안에 모든 하위 시스템이 함께 들어 있습니다. Ethereum이 경계를 긋는 자리에 Solana는 경계를 두지 않습니다.

이 프로세스 안에는 트랜잭션을 받아 처리하는 TPU와 다른 노드가 만든 블록을 검증하는 TVU가 있습니다. 순서를 기록하는 PoH와 계정 상태를 담는 AccountsDB도 같은 프로세스에 있습니다. 블록을 저장하는 Blockstore와 밸리데이터끼리 정보를 주고받는 Gossip도 마찬가지입니다. 이 모듈들은 메모리를 공유하고 내부 채널로 작업을 넘깁니다. 프로세스 경계를 넘을 때 생기는 지연이 없습니다.

400ms 슬롯 주기 때문에 이렇게 묶었습니다. 네트워크와 실행과 저장과 합의가 이 시간 안에 함께 맞물려 돌아가야 합니다. Ethereum처럼 하위 시스템 사이에 경계와 API를 두면 이 주기 안에서 감당할 수 없는 지연이 생깁니다.

이 속도를 유지하려면 하드웨어 요구가 높아집니다. 성능 좋은 CPU와 넉넉한 RAM과 빠른 NVMe와 큰 대역폭이 필요합니다. 단일 구현체 위험도 오랫동안 이어졌습니다. 네트워크 대부분이 Agave라는 구현체 하나로 돌아갔기 때문에 그 안의 버그 하나가 체인 전체를 멈출 수 있었습니다. Ethereum은 운영 부담을 감수하면서 바로 이런 실패를 피하려 합니다.

Firedancer가 중요한 이유도 여기에 있습니다. 독립된 두 번째 클라이언트가 자리를 잡으면 Solana도 다양성을 얻고 처리량도 함께 올라갑니다. Ethereum은 이 다양성을 설계 단계부터 갖췄습니다. 지금까지 Solana는 하나로 묶인 빠른 시스템을 위해 무거운 하드웨어 요구와 얇은 클라이언트 다양성을 감수해 왔습니다.

Ethereum에서 지갑과 프로그램은 서로 다른 종류의 계정이고 둘 사이의 구분이 분명합니다. 사용자 지갑은 보통 EOA입니다. 잔액이 있고 개인키를 가진 사람이 움직입니다. 애플리케이션 로직은 별도의 컨트랙트 계정에 들어 있고 이 계정은 자기 코드대로 움직입니다.

이 분리 덕분에 경계가 깔끔합니다. 사람은 서명하고 컨트랙트는 규칙을 실행합니다. 대신 지갑 자체에는 기능이 거의 없습니다. 서명해서 보내는 것 이상은 모두 그 위에 따로 만들어야 합니다. EOA는 키 한 쌍일 뿐이라서 스마트 월렛이나 다른 사람의 가스비를 대신 내주는 기능이나 여러 동작을 한 번의 승인으로 묶는 기능이 원래 기본으로 들어 있지 않았습니다.

개발자가 겪는 문제도 하나 더 있습니다. 컨트랙트 계정에서는 코드와 그 코드가 다루는 상태가 같은 주소에 묶여 있습니다. 상태를 그대로 둔 채 코드만 바꿀 수 없으니 업그레이드할 때는 보통 프록시 패턴을 씁니다. 고정된 앞단 주소가 교체 가능한 로직 컨트랙트로 호출을 넘기는 방식입니다. 동작은 하지만 저장소 배치 충돌이나 권한 설정 실수나 잘못된 초기화 같은 버그가 자주 생깁니다. 모두 상태와 코드가 얽혀 있어서 생기는 문제입니다.

최근에는 이 분리를 유지하면서 지갑에 프로그래밍 기능을 더하는 방향으로 가고 있습니다. ERC-4337은 컨트랙트 계층에서 스마트 월렛을 구현합니다. EIP-7702는 일반 EOA가 컨트랙트 코드를 지정해 스마트 월렛처럼 동작할 수 있게 합니다.

Ethereum은 유연함보다 명확함을 택했습니다. 사용자와 코드 사이의 경계를 단단하게 지키는 대신 지갑 기능은 기본으로 넣지 않고 위에 덧붙여 왔습니다.

Solana에서는 거의 모든 것이 계정입니다. 지갑과 프로그램 코드와 토큰 잔액과 메타데이터가 모두 계정입니다. 계정 유형이 둘인 Ethereum보다 단순해 보이지만 실제로 다뤄 보면 그렇지 않습니다. 개발자는 계정마다 소유자와 서명 권한과 쓰기 가능 여부를 따져야 합니다. 계정을 언제 만들고 닫을지도 정해야 하고 렌트도 챙겨야 합니다.

Solana에서 중요한 구분은 사용자와 코드가 아니라 코드와 데이터입니다. 프로그램 코드는 실행 가능한 프로그램 계정에 들어 있고 프로그램이 이 계정을 스스로 고칠 수는 없습니다. 그 코드가 다루는 데이터는 프로그램이 소유한 별도의 계정에 저장됩니다. 프로그램 하나가 데이터 계정을 여러 개 소유할 수 있기 때문에 SPL Token이나 프로토콜 금고 같은 구조가 자연스럽게 나옵니다. 코드 하나가 상태 계정 수천 개를 관리합니다.

이 구조는 PDA가 있어서 가능합니다. PDA는 개인키가 없는 주소입니다. 대신 주소를 만들 때 정한 규칙에 따라 프로그램이 서명할 수 있습니다. 금고와 에스크로와 프로그램이 가진 권한은 모두 프로그램이 PDA로 서명해서 움직입니다.

업그레이드 권한이 있는 사람은 데이터 계정은 그대로 둔 채 프로그램 코드만 교체할 수 있습니다. 처음부터 코드와 상태가 서로 다른 계정에 있었으니 업그레이드에 Ethereum식 프록시 패턴이 필요 없습니다.

대신 설계 부담은 개발자가 집니다. 어떤 계정이 있어야 하는지와 누가 만들고 소유하는지와 어떤 명령이 어떤 계정을 읽고 쓰는지를 처음부터 정해야 합니다. Solana는 계정 구조를 유연하게 만든 만큼 상태 설계의 많은 부분을 개발자에게 맡깁니다.

EVM은 표현력을 가장 먼저 고려해 설계했습니다. 컨트랙트는 실행 도중에 어떤 상태를 읽고 쓸지와 어떤 컨트랙트를 호출할지를 그때그때 정할 수 있습니다. 이 자유 덕분에 EVM 위에서 다양한 애플리케이션이 만들어졌습니다.

이 자유에는 구조적인 비용이 따릅니다. EVM은 256비트 스택 머신입니다. 값을 스택에 넣고 꺼내며 계산하고 한 번에 다루는 단위가 256비트로 매우 큽니다. 이 크기는 암호 연산과 큰 정수 계산에는 편하지만 64비트로 동작하는 실제 CPU와는 거리가 멉니다. 그 탓에 연산은 하드웨어에서 바로 실행되지 못하고 인터프리터를 거쳐 실행됩니다.

실행 비용은 스택 연산과 스토리지 읽기·쓰기와 다른 컨트랙트 호출에서 나오고 이 모두에 가스가 매겨집니다. 특히 스토리지가 비쌉니다. 덧셈 한 번은 3가스지만 빈 슬롯에 값을 쓰는 SSTORE 한 번은 2만 가스가 넘습니다. 비용 구조가 곧 프로그래밍 방식의 일부입니다.

EVM 개발자는 컨트랙트 로직만 작성하지 않습니다. 저장소 배치를 설계하고 비싼 호출을 줄이고 업그레이드 경로를 계획하고 각 호출이 온체인에서 얼마나 들지 미리 계산해야 합니다.

EVM은 가장 넓은 설계 공간을 주고 실행 비용과 복잡함은 개발자에게 넘깁니다. 거의 무엇이든 표현할 수 있지만 그것을 싸고 안전하게 만드는 일은 개발자의 몫입니다.

SVM은 범용성보다 처리량과 스케줄링을 먼저 고려해 설계했습니다. 목표는 고성능 런타임 하나에서 많은 트랜잭션을 빠르고 안전하게 실행하는 것이고 VM 구조도 그 목표에 맞췄습니다.

구조로 보면 SVM은 eBPF를 바탕으로 한 레지스터 머신입니다. 값을 스택에 쌓지 않고 정해진 레지스터에 둡니다. 실제 CPU가 코드를 실행하는 방식과 가깝기 때문에 기계어로 바로 번역(JIT 컴파일)해 빠르게 실행할 수 있습니다. 실행 비용은 컴퓨트 유닛으로 매깁니다. 트랜잭션마다 상한이 미리 정해져 있어 스케줄러가 한 블록에 무엇을 얼마나 넣을지 계산하기 쉽습니다.

병렬 실행은 레지스터 구조에서 나오지 않습니다. 레지스터 구조는 프로그램 하나를 빠르게 돌리고 컴퓨트 예산은 스케줄링을 돕습니다. 여러 프로그램을 나란히 돌리는 데 필요한 나머지 조건은 계정 선언에서 나오고 이 내용은 병렬 처리 부분에서 다룹니다.

대신 프로그램은 런타임의 제약에 맞춰야 합니다. 실행 전에 자기가 접근할 계정 목록을 밝혀야 하고 컴퓨트와 자원 사용도 정해진 한도 안에 두어야 합니다. EVM처럼 실행하면서 필요한 상태를 찾아갈 자유가 SVM에는 없습니다.

SVM의 목표는 VM 하나를 빠르게 만드는 것이 아닙니다. 실행 중의 자유를 내주고 병렬 시스템 안에서 스케줄링하기 쉬운 제약을 얻는 데 있습니다. EVM과는 정반대의 선택입니다.

Ethereum의 합의는 확정을 확률에 맡기지 않고 어기면 처벌받는 분명한 선으로 만듭니다. 합의 방식은 Gasper입니다. 지금 어느 체인이 최신인지 정하는 포크 선택 규칙과 어느 블록을 되돌릴 수 없는지 정하는 확정 규칙을 함께 씁니다. 두 역할은 일부러 나눠 두었습니다.

확정은 단계를 거쳐 이루어집니다. 밸리데이터 위원회가 슬롯마다 블록에 어테스테이션을 남기고 연속된 두 에포크에서 전체 지분의 2/3가 한 체크포인트를 지지하면 그 체크포인트가 확정됩니다. 실제 시간으로 약 13분이 걸립니다. 전체 밸리데이터가 에포크마다 한 번씩 돌아가며 투표하니 이만큼 시간이 듭니다.

이 확정은 슬래싱이 지탱합니다. 이중 서명을 하거나 모순된 투표를 한 밸리데이터는 지분 일부를 잃습니다. 확정된 블록을 되돌리려면 전체 지분의 1/3 이상이 함께 부정행위를 하고 함께 슬래싱을 당해야 합니다. 확정을 되돌리는 공격은 어려울 뿐 아니라 공격자에게 감당하기 힘든 손실을 남깁니다.

완전한 확정이 필요한 사용자는 몇 분을 기다려야 합니다. 더 빠른 확인이 필요한 애플리케이션은 확정 전의 약한 상태를 따로 고려해야 합니다.

Ethereum은 더 오래 기다리는 대신 공격 비용이 크고 한 번 확정되면 되돌릴 수 없는 분명한 확정 지점을 얻습니다.

Solana의 합의는 투표 때문에 블록 생성을 멈추지 않고 블록 흐름과 함께 진행되도록 설계했습니다. 합의 방식은 Tower BFT입니다. PoH가 만든 시간 위에서 동작하고 투표를 별도 단계로 두지 않습니다. 밸리데이터의 투표는 트랜잭션으로 블록에 함께 기록됩니다.

투표가 데이터와 함께 흐르기 때문에 확인도 짧은 주기로 일어나고 Solana는 그 단계를 이름으로 구분합니다. 블록은 먼저 processed 상태가 됩니다. 전체 지분의 2/3 이상이 같은 블록에 투표하면 보통 1~2초 안에 confirmed가 됩니다. 같은 분기에 투표가 계속 쌓이면 약 12~13초 뒤 finalized에 이릅니다.

이 단계는 잠금(lockout)으로 단단해집니다. 밸리데이터는 투표할 때마다 그 분기에 묶이고 같은 분기에 투표를 더할 때마다 묶이는 시간이 두 배로 늘어납니다. 여러 번 투표한 분기를 버리려면 그만큼 오래 기다려야 합니다. 확정된 분기는 이렇게 쌓인 잠금 때문에 사실상 되돌릴 수 없게 됩니다.

Ethereum과는 이를 강제하는 장치가 다릅니다. Solana에는 부정행위에 지분을 없애는 슬래싱이 아직 구현되어 있지 않습니다. 되돌리기 어려운 이유는 자기 투표를 뒤집는 비용이 계속 커지기 때문입니다.

Solana는 Ethereum과 반대의 선택을 했습니다. 확인은 훨씬 빠르게 얻고 확정은 슬래싱으로 보장된 체크포인트 대신 쌓여 가는 잠금으로 만듭니다.

EVM은 트랜잭션을 한 번에 하나씩 실행합니다. 최적화가 덜 되어서가 아니라 트랜잭션이 무엇을 건드릴지 실행하기 전에는 알 수 없기 때문입니다. 컨트랙트는 실행 도중에 접근할 대상을 계산합니다. 방금 계산한 키로 매핑을 읽고 그 값으로 다른 컨트랙트를 호출하고 호출된 컨트랙트가 다시 자기 상태를 읽습니다. 트랜잭션의 상태 접근 범위는 실행이 끝나야 알 수 있습니다.

병렬 실행에는 반대 조건이 필요합니다. 두 트랜잭션을 동시에 안전하게 실행하려면 둘이 같은 슬롯을 건드리지 않는다는 것을 미리 알아야 합니다. 겹칠 수 있는 두 트랜잭션을 함께 실행하면 쓰기 순서가 뒤바뀌어 상태가 깨질 수 있습니다. 미리 알 방법이 없으니 한 줄로 실행하는 것이 가장 안전합니다.

Ethereum도 접근 범위를 미리 알리는 장치를 넣었습니다. 접근 목록을 쓰면 트랜잭션이 접근할 슬롯을 미리 적을 수 있습니다. 하지만 이 목록은 선택 사항이고 강제되지도 않습니다. 적은 것보다 더 많은 슬롯을 건드려도 막지 않습니다. 스케줄러는 이 목록을 믿고 병렬로 실행할 수 없습니다. 가스 계산에는 도움이 되지만 병렬 실행의 근거는 되지 못합니다.

다음 업그레이드인 Glamsterdam에 들어가는 블록 단위 접근 목록은 이 빈틈을 다른 쪽에서 메웁니다. 블록을 만든 쪽이 실행을 마친 뒤 접근 범위를 블록에 함께 기록하고 검증하는 노드는 이 목록을 보고 트랜잭션을 병렬로 다시 실행할 수 있습니다. 다만 목록은 실행이 끝난 뒤에 만들어지므로 블록을 만드는 단계는 여전히 순차 실행입니다.

Ethereum은 기본 계층에서는 순차 실행을 받아들이고 처리량의 대부분을 그 위의 롤업에서 얻습니다. 실행은 나란히 돌아가는 여러 롤업에서 이루어지고 L1은 정산과 데이터 가용성을 맡습니다. L1은 한 줄로 실행하지만 그 위에서 여러 롤업이 동시에 실행됩니다.

순차 실행은 단순하고 기본적으로 안전합니다. 개발자가 접근할 상태를 미리 선언할 필요도 없습니다. 대신 L1 자체의 처리량에는 분명한 한계가 있고 확장의 복잡함은 롤업 계층으로 넘어갑니다.

Solana는 Ethereum이 얻지 못하는 한 가지를 요구합니다. 모든 트랜잭션은 실행 전에 자기가 읽고 쓸 계정을 모두 선언해야 합니다. 상태 접근 범위가 실행 중에 드러나지 않고 처음부터 밝혀집니다. 이 요구 하나로 병렬 실행이 가능해집니다.

접근 범위를 미리 알면 Sealevel은 트랜잭션 묶음을 접근하는 계정 기준으로 나눌 수 있습니다. 이어서 Banking Stage가 충돌하지 않는 트랜잭션을 서로 다른 코어에 배정해 동시에 실행합니다. 서로 다른 여덟 명 사이의 송금 네 건은 서로 관련이 없어 한 번에 처리됩니다.

비용은 개발자가 부담합니다. 모든 명령어는 사용할 계정을 나열하고 각 계정이 읽기용인지 쓰기용인지 표시해야 합니다. 필요한 계정을 빠뜨린 트랜잭션은 실패합니다. Solana는 실행 중에 상태를 찾아가는 자유를 내주고 미리 스케줄링될 수 있는 구조를 얻었습니다.

실제 한계는 핫 계정입니다. 인기 있는 거래 풀 하나에 같은 블록의 트랜잭션 수천 건이 쓰기를 시도하면 모두 그 계정에서 충돌하고 다시 한 줄로 실행됩니다. 이 모델은 수요가 가장 몰리는 곳에서 병렬성을 잃습니다.

Solana는 이 문제를 로컬 수수료 시장으로 완화합니다. 핫 계정에 경쟁이 붙어도 그 계정을 쓰는 트랜잭션의 수수료만 오르고 다른 사용자는 영향을 받지 않습니다. 스케줄링 장치가 복잡해지고 계정 선언 부담도 생깁니다. 그래도 접근 범위가 겹치지만 않으면 병렬 처리량을 실제로 얻습니다.

앞에서 본 차이는 모두 로드맵의 방향과 이어집니다. Ethereum은 몇 년째 같은 방향으로 갑니다. L1의 실행 부담은 줄이고 가장 믿을 수 있는 정산 계층이 되는 데 집중합니다.

가까운 과제는 롤업이 쓸 공간을 늘리는 일입니다. blob은 롤업이 데이터를 싸게 올릴 자리를 만들었습니다. PeerDAS는 2025년 Fusaka 업그레이드로 들어왔습니다. 각 노드가 blob 전체를 내려받지 않아도 되니 blob 공간을 크게 늘릴 길이 열렸습니다. 이 방향의 끝에는 Danksharding이 있습니다. L1은 직접 많이 실행하기보다 여러 실행 환경의 데이터를 싸게 받아 주는 쪽으로 바뀌고 있습니다.

더 먼 과제는 체인을 검증하기 쉽게 만드는 일입니다. 상태 증명의 크기를 줄여 상태 전체를 저장하지 않은 가벼운 클라이언트도 체인을 검증할 수 있게 하려고 합니다. 처음에는 Verkle tree가 유력한 후보였고 지금은 영지식 증명과 잘 맞는 이진 트리 방식도 함께 검토하고 있습니다. 13분 걸리는 확정을 슬롯 하나 안으로 줄이려는 연구도 이어지고 있습니다. 목표는 더 가볍고 검증하기 쉬운 기본 계층입니다.

2025년부터는 L1 자체를 키우는 작업에도 무게가 실렸습니다. 블록 가스 한도를 꾸준히 올리고 있습니다. Glamsterdam에 들어가는 블록 단위 접근 목록도 L1 실행을 빠르게 하려는 작업입니다. 같은 업그레이드에 들어가는 ePBS는 앞에서 본 MEV-Boost 경매를 프로토콜 안으로 들여옵니다. Glamsterdam은 2026년 10월 Sepolia 테스트넷에 적용되었고 메인넷 적용은 2026년 4분기로 잡혀 있습니다. 그래도 큰 방향은 그대로입니다. 처리량의 대부분은 롤업에서 얻고 L1은 데이터 가용성과 정산에 집중합니다.

Ethereum은 모든 실행을 스스로 맡기보다 다른 실행 계층이 올라서는 기반이 되려 합니다. 모듈형 구조도 그래서 의도적으로 택했습니다.

Solana의 로드맵은 반대 방향입니다. 실행은 밖으로 내보내지 않습니다. 더 높은 처리량과 더 나은 소프트웨어와 하드웨어 효율을 L1 안에서 직접 얻습니다.

Solana는 일을 바깥으로 나누지 않고 밸리데이터 자체를 다시 작성해 더 빠르게 만듭니다. Firedancer가 그렇게 다시 작성한 클라이언트이고 독립된 두 번째 클라이언트라서 장애 위험도 줄여 줍니다. Solana는 기계 하나를 충분히 빠르게 만들면 두 번째 계층이 필요 없다고 봅니다.

합의도 다시 설계하고 있습니다. Alpenglow는 2025년 밸리데이터 투표로 통과했고 Tower BFT와 Turbine을 대체합니다. 투표를 트랜잭션으로 블록에 싣지 않고 밸리데이터끼리 직접 주고받습니다. 지금 12~13초 걸리는 확정을 150ms 안팎까지 줄이려 합니다. 2026년 10월 현재 Alpenglow는 테스트넷에서 시험 중이고 메인넷 적용 날짜는 아직 정해지지 않았습니다. 사전 작업인 투표 계정의 BLS 키 등록은 2026년 7월 메인넷에 먼저 들어갔습니다.

로드맵의 나머지는 상태를 L1에 두면서 보관 비용을 낮추는 일입니다. 상태 압축을 쓰면 NFT나 기록을 기존 비용의 일부만으로 대량 발행할 수 있습니다. 밸리데이터가 빠른 메모리에 올려 둬야 하는 데이터의 양을 줄이는 작업도 이어지고 있습니다. 바깥으로 옮기지 않고 같은 자리에 더 많이 담는 것이 목표입니다.

L1에 더 많이 담을수록 밸리데이터는 더 무거워집니다. 앞에서 말한 하드웨어 부담이 이 방향의 대가입니다. 클라이언트 다양성과 효율 개선을 로드맵의 중심에 둔 것도 그 때문입니다.

두 로드맵은 정반대입니다. Ethereum은 L1을 가볍게 만들고 실행을 롤업으로 내보냅니다. Solana는 L1을 더 무겁게 만들고 모든 것을 빠른 기본 계층 하나에 모읍니다. 두 체인을 비교할 때 가장 먼저 기억할 차이입니다.