[요약]

0. 상하이 업그레이드는 23년 3월 예정되어 있다

1. 머지 이전 업그레이드와 다르게 Execution 클라이언트와 Consensus 클라이언트 업그레이드가 동시에 이루어진다
2. 상하이 업그레이드에서 중요한 변경 두 가지는 EVM Object Format(EOF)과 비콘 체인 출금이다.
3. EOF는 EVM에 대한 변경으로 새로운 스마트 컨트랙트 포맷을 정의한다.
4. 비콘 체인 출금은 execution payload의 별도 타입으로 정의가 되었다. 컨센서스 레이어에서도 검증을 쉽게 하기 위함이다.
5. EIP-4844는 비콘 체인 출금을 앞당기기 위해 상하이 업그레이드에서 제외되었다.

[목차]

1. 두 클라이언트의 업그레이드
2. 상하이 업그레이드에서 무엇이 바뀌나요?
3. EOF
4. 비콘 체인 출금
5. EIP-4844의 상하이 업그레이드 제외

두 클라이언트의 업그레이드

이전 업그레이드(머지 이전)들과 다르게 두 클라이언트의 업데이트가 모두 필요하다!

현재 이더리움은 두 종류의 클라이언트 소프트웨어를 사용한다. Exeuction 클라이언트와 Consensus 클라이언트이다.

Execution 클라이언트는 이더리움 등장부터 사용한 클라이언트다. 대표적으로 Go로 구현된 Geth가 있다. Execution 클라이언트는 머지 이전에 블록을 생성하는 역할과 트랜잭션을 실행하는 역할 둘 다 담당했다.

Consensus 클라이언트는 비콘체인을 지원하기 위해 탄생하였다. 대표적으로 Go로 구현된 Prysm이 있다. 비콘 체인이 등장한 2020년 12월 1일부터 머지 이전까지 이더리움은 비콘 체인과 기존 체인(Execution Chain) 두 개의 체인이 공존했다. 2022년 9월 15일 The Merge 업그레이드가 성공적으로 마무리되며 두 체인은 연결이 되었고 이더리움은 PoS로 전환이 되었다.

PoS 전환 이후 Execution 클라이언트가 쓰이지 않는 것이 아니다. 두 클라이언트는 서로 통신하며 역할을 분담하고 있다. Execution 클라이언트는 EVM, state tree, mempool 등의 구현체를 가지고 있어 트랜잭션을 실행하고 이더리움 상태를 업데이트하는 역할을 한다. Consensus 클라이언트는 블록을 생성하는 비콘 체인의 핵심 구현체이기에 블록 전파, 합의 등을 담당한다.  

두 클라이언트가 네트워크를 구성하고 있어 하드 포크 업그레이드를 할 때 두 클라이언트 전부 업데이트해야 한다. The merge도 Consensus 레이어의 업그레이드(Bellatrix upgrade)와 Execution 레이어의 업그레이드(Paris upgrade)가 동시에 수행되었다.

2023년 3월 예정된 상하이 업그레이드 역시 Consensus 레이어 업그레이드(Capella upgrade)와 Execution 레이어 업그레이드(Shanghai upgrade)가 동시에 수행될 것이다.

상하이 업그레이드에서 무엇이 바뀌나요?

Consensus 클라이언트와 Execution 클라이언트가 전부 업그레이드가 되니 추가되는 기능도 나눠볼 수 있을 것이다.

이번 업그레이드에서는 Execution 클라이언트 위주로 기능이 추가된다. Consensus 클라이언트는 비콘 체인 출금 지원이 추가되는데, Execution 클라이언트도 관련 변경이 이루어져 Execution 클라이언트 변경만 살펴봐도 상관이 없다. 그러면 Execution 클라이언트 업그레이드 스펙을 살펴보자.

• EVM Object Format(EOF): EIP-3540, EIP-3670, EIP-4200, EIP-4750, EIP-5450
• 비콘 체인 출금: EIP-4895
• 기타: EIP-3651(Warm COINBASE), EIP-3855(PUSH0), EIP-3860(Limit and meter initcode)

이번 상하이 업그레이드에서 중요한 변경 사항 두 가지는 EOF와 비콘 체인 출금이다. EOF는 EVM에 대한 변경이다. EVM은 지금까지 큰 변화가 없었기에 이번 EOF는 의미가 있다. 비콘 체인 출금은 밸리데이터가 되기 위해 입금한 이더를 EVM으로 출금할 수 있게 하는 업데이트이다.

상하이 업그레이드는 23년 3월 예정되어 있지만 아직 대다수의 EIP가 구현이 완료되지 않아(Not merged) 충분히 미뤄질 수 있다. 특히 Geth는 EOF와 비콘체인 출금 어느 것도 완료가 되지 않은 상황이다.

EOF

EOF는 새로운 컨트랙트 포맷을 제시하는 업데이트이다. 현재 EVM은 모든 컨트랙트에 대해 동일한 번역(interpretation) 및 검증 규칙을 적용하고 있다. 이번 상하이 업그레이드에서 새로운 컨트랙트 도입과 동시에 클라이언트/EVM 번역기가 업데이트된다.

EOF가 도입되면 기존 컨트랙트와 EOF 컨트랙트가 공존한다. 하지만 점차 기존 컨트랙트를 EOF 컨트랙트로 옮겨지면서 기존 컨트랙트의 수는 줄어들 것이다.

EOF는 총 5개의 EIP 구현으로 적용될 것이다.

1) EIP-3540: EVM Object Format v1

container := header, body
header := magic, version, kind_types, types_size, kind_code, num_code_sections, code_size+, kind_data, data_size, terminator
body := types_section, code_section+, data_section
types_section := (inputs, outputs, max_stack_height)+

EIP-3540은 컨테이너 개념을 도입해 바이트 코드가 구조를 갖췄다. 컨테이너는 헤더와 바디로 나누어지고, 바디는 또 다른 섹션들로 나눠진다.

그동안 EVM 바이트 코드는 instruction의 나열이었다. 이는 클라이언트에서 코드를 검증할 때 부담이 있었을 뿐 아니라(뒤에 어떤 instruction이 나올지 예상 불가) 새로운 기능을 추가하기도 힘들게 만들었다. EOF가 적용이 되면 코드를 검증하기 한결 쉬워질 것이다.

클라이언트뿐만 아니라 온체인 코드 밸리데이터도 이득을 볼 수 있다. 이는 EOF가 코드와 데이터를 분리했기 때문이다. 옵티미즘과 같은 롤업에게 도움이 될 수 있는 부분이다.

버전을 도입한 것도 의미가 있다. 버전을 통해 특정 기능을 지원해주지 않거나 추가하기 쉬워졌다. 예를 들어 Account Abstraction 등을 도입하기 수월해질 것이다.

2) EIP-3670: Code Validation

EOF 포맷 컨트랙트가 생성될 때 코드 검증을 바로 진행한다. 여기서 검증이란 컨트랙트가 잘려진 PUSH-data를 가지고 있거나 정의되지 않은 명령어를 가진지 확인하는 작업을 말한다. 현재 존재하는 컨트랙트는 이런 검증 과정이 필수가 아니고, EVM에서 이런 컨트랙트를 어떻게 처리할지 결정한다.

코드 검증이 즉시 진행되면 EOF 포맷 컨트랙트에 대해 EVM이 할 일이 줄어들 것이다.

3) EIP-4200: Static relative jumps

새로운 EVM jump 명령을 도입한다(RJUMP, RJUMPI, RJUMPV). 현재 EVM은 2개의 jump 명령만 가지고 있었고, 동적 jump만 처리할 수 있었다. 한정된 명령으로 모든 로직을 처리하다 보니 코드 분석이 복잡해지는 등 여러 문제가 있었다.

정적 jump(static jump)를 도입함으로써 컴파일러가 최적화할 방법을 열어주어 최종적으로 가스비 감소까지 노려볼 수 있게 되었다.

4) EIP-4750: Functions

EIP-4200의 연장선이다.

EIP-4750은 CALLF와 RETF라는 새로운 opcode를 도입한다. EIP-4200에서 말했듯이 현재 EVM은 동적 jump만 지원한다. EIP-4750은 함수(서브 루틴)를 호출하고 리턴받을 때 CALLF와 RETF를 사용하게 해 해당 케이스에서 동적 jump의 사용을 불허한다.

5) EIP-5450: Stack Validation

검증된 컨트랙트 실행 중 스택의 underflow 및 overflow가 일어나지 않음을 보장한다. 즉 추가적인 검증 규칙을 도입해 안정성을 확보하겠다는 EIP이다.

EOF는 여전히 개선할 점이 많기 때문에 앞으로도 관련 EIP들이 제안되고 적용될 것으로 예상된다.

비콘 체인 출금

비콘 체인 출금은 22년 3월 EIP-4895로 제안되었다. 출금 operation이 Execution 레이어에서 처리되면 Consensus 레이어에서 스테이킹한 이더가 출금되는 방식이다.

출금은 아예 블록의 execution payload의 한 타입으로 새로 정의가 될 예정이다. 이 말은 유저 레벨 트랜잭션과 별개의 기능으로 분리된다는 것이다. 실제로 코드를 확인해보면 블록 타입에 트랜잭션과 별개로 withdraw가 구현된 것을 확인할 수 있다.

별도의 payload 오브젝트로 구현된 이유는 컨센서스 레이어에서도 검증이 되야하기 때문이다. 위에서 언급했듯이 트랜잭션 처리는 Execution 클라이언트에서만 처리가 된다. 만약 트랜잭션 타입으로 구현되었다면 Consensus 클라이언트가 볼 수 없어 컨센서스 레이어에서 출금하기 까다로웠을 것이다. 구체적으로 말하자면 출금 관련 트랜잭션만 예외적으로 처리하는 로직을 넣어야 할 것이고, 이는 버그 발생 확률을 높인다.

출금이 처리되면 주소가 가지고 있는 이더가 증가하지만 가스비가 따로 청구되지 않는다.  Consensus 레이어가 주어진 시간에 최대 출금 횟수를 제한하기 때문에 전체 payload 실행 비용 대비 출금이 소모하는 비용은 무시할 수 있어(1% 미만) 이런 결정을 했다고 한다.

EIP-4844의 상하이 업그레이드 제외

프로토 댕크샤딩으로 더 잘 알려진 EIP-4844는 롤업의 가스비를 크게 낮출 수 있을 것으로 기대돼 많은 사람이 주목하는 프로포절이다. EIP-4844가 적용되면 저장공간(blob)을 가진 트랜잭션 형태가 따로 생기게 된다. 현재 롤업은 트랜잭션 데이터를 블록의 calldata에 저장하는데 blob에 저장하게 되면 가스 비용을 크게 낮출 수 있다.

EIP-4844는 구현 대부분이 거의 끝났다. 그런데도 상하이 업그레이드에서 제외된 이유는 비콘 체인 출금을 최대한 빨리 구현하기 위해서이다.

Ethereum Core Dev 미팅 (22.12.08)에서 최대한 출금을 빠르게 구현하고 그 후에 EOF+EIP-4844를 구현하자는 의견이 많은 동의를 얻었다. 결론적으로 EOF는 비콘 체인 출금과 함께 상하이 업그레이드에 포함이 되었지만 EIP-4844는 상하이 업그레이드 이후 다음 업그레이드에 포함되는 것으로 합의가 되었다. 이미 Geth의 EIP-4844 구현은 비콘 체인 출금이 구현된 브랜치에서 이어 구현이 되고 있다.

Dankrad Feist는 비콘 체인 출금 시점을 몇 달 앞당기기 위하여 커뮤니티가 가장 원하는 EIP-4844를 미룬 것을 비난하기도 했다.

개인적인 의견으로도 비콘 체인 출금을 이렇게 서두를 이유가 있는지 의문이다. 하락장을 맞아 이더리움의 가격은 크게 하락하였고 트랜잭션 양도 줄어들었다. 아무래도 EIP-4844보다는 당장 이더가 공급되는 비콘 체인 출금이 유동성 증가에 도움이 될 것이다. 커뮤니티의 반대가 있을 것을 알면서도 개발 방향을 수정한 이유가 혹시 이러한 이유 때문인지 개인적으로 궁금하다.

Reference

Current Ethereum

Networking layer

EIP-4895

EIP-4844 시리즈