김인근 | ingeun92@naver.com | CURG
이더리움이 길고 긴 약 16개월의 업그레이드 침묵을 깨고 새로운 업그레이드로 돌아왔다.
이더리움의 이번 업그레이드의 네이밍은 “베를린"이다. 그런데 이더리움 측은 왜 업그레이드에 도시의 이름을 붙이는 것일까? 이전 업그레이드였던 이스탄불 업그레이드처럼 이더리움과 관련된 큰 행사가 열린 도시를 기리기 위해 붙인다고 한다. 이번 베를린 같은 경우 2019년 12월 ~ 2020년 1월에 “Devcon 0” 행사가 열린 곳으로 이것을 기념하기 위해 베를린 업그레이드로 명명했다. 이와 마찬가지로 다음 업그레이드 이름은 “Devcon 1” 행사가 열릴 런던이 될 것이라고 했다.
이번 업그레이드는 Istanbul 업그레이드와 Muir Glacier 업그레이드를 뒤잇는 업그레이드다. 먼저 진행되었던 업그레이드에 대해 한 번 간단하게 짚고 베를린 업그레이드를 설명하도록 하겠다.
Istanbul 업그레이드
이스탄불 업그레이드는 메인넷 기준 9,069,000 블록(2019. 12. 07)에서 진행되었으며 아래의 EIP 업그레이드를 진행했다.
EIP-1679: Istanbul Meta
EIP-152: Add Black2 compression function ‘F’ precompile
EIP-1108: Reduce alt bn128 precompile gas costs
EIP-1344: ChainID opcode
EIP-1884: Repricing for trie-size-dependent opcodes
EIP-2028: Transaction data gas cost reduction
EIP-2200: Net gas metering for SSTORE operations
많은 업그레이드 내용이 있지만 이번 글에서는 베를린 업그레이드가 주인공이므로 아 그런게 있었구나 정도로 넘어가주는 것이 주인공에 대한 배려가 아닐까 싶다.
Muir Glacier 업그레이드
Muir Glacier 업그레이드는 메인넷 기준 9,200,000 블록(2019.12.30)에서 진행되었으며 아래의 EIP 업그레이드를 진행했다. 이 업그레이드는 포함하는 내용이 적고 흥미로운 내용이 하나 있어 이것만 살펴보고자 한다.
EIP-2384: Muir Glacier Difficulty Bomb Delay
Difficulty Bomb은 이더리움의 채굴 난이도를 조절하기 위해 작업 증명 알고리즘에 내장된 채굴 난이도 매커니즘이다. 이 매커니즘이 새 블록을 채굴하는데 필요한 채굴 난이도를 조작하여 평균 블록 시간을 유지시킨다. 그런데 Difficulty Bomb으로 조정한 채굴 난이도가 너무 커지면 블록이 평균 시간 이상으로 계속 생기지 않는 일명 ‘빙하기'가 오게 된다. 이러한 ‘빙하기'는 이더리움 네트워크의 성능 저하를 유발하게 되므로 EIP-2384는 Difficulty Bomb을 400만 블록(약 611일) 동안 지연시킨다. 이 업그레이드를 통해 우선은 지연을 시키고 더 좋은 방법으로 이러한 ‘빙하기' 문제를 영구적으로 해결할 예정이라고 밝혔다.
Berlin 업그레이드
Berlin 업그레이드 개요
이더리움 베를린 업그레이드의 일정은 다음과 같다.
베를린 업그레이드는 메인넷에서 12,244,000번째 블록에서 진행될 예정이다. 시간 상으로는 2021년 4월 14일로 예상하고 있다. 하지만 블록 생성 시간의 불규칙함으로 인해 약간의 차이는 생길 수 있다.
또한, 메인넷 이전에 테스트넷들은 아래와 같은 일정으로 베를린 업그레이드가 진행됐거나 진행될 예정이다.
테스트넷 | 업그레이드 실행 블록 | 업그레이드 실행 날짜
Ropsten | 9,812,189 | 2021. 03. 10
Goerli | 4,460,644 | 2021. 03. 17
Rinkeby | 8,290,928 | 2021. 03. 24
이더리움 노드로 활동 중인 이용자들은 업그레이드 된 새로운 이더리움 네트워크에서 활동을 이어가려면 클라이언트를 업그레이드 해주어야 한다. 클라이언트의 업그레이드는 네트워크의 베를린 업그레이드가 이루어지기 최소한 몇일 전에 하는 것을 권장한다고 한다.
Berlin 업그레이드 세부 내용
이제 본론으로 들어가 이더리움 베를린 업그레이드가 어떠한 세부적인 내용을 가지고 있는지 살펴보도록 한다.
EIP-2565: ModExp Gas Cost
ModExp 전처리를 사용할 때 발생하는 비용의 합리적인 조정을 위해 가스 비용을 계산하는 알고리즘을 정의하는 업그레이드이다. ModExp는 signatures, VDFs, SNARKs, accumulators 등의 많은 암호화 함수에서 사용되는 기초적인 산술 연산이다.
EIP-198에서 정의한 ModExp 정의를 따르던 지금까지는 ModExp가 가스 가격이 너무 비싸서 이러한 함수를 사용하는 코드들은 운영이 비효율적이고 비용이 많이 드는 문제가 있었다. 이것을 EIP-198에서 EIP-2565으로 업그레이드를 통해 이 비용을 줄여서 이러한 암호화 기능을 좀 더 원활하게 사용할 수 있는 효과를 볼 수 있게 되었다.
현재 이더리움에서 계속해서 도입하려고 하는 zkRollup 같은 경우 위에서 나온 SNARKs 암호화 함수를 많이 사용하게 되는데 ModExp 정의를 새로 하여 추후에 적용하려는 기술에 대해서도 매끄럽게 적용이 가능할 것으로 보여 필자도 굉장히 유용한 업그레이드라고 생각한다.
EIP-2718: Typed Transaction Envelope
EIP-2718 업그레이드는 추후에 나올 새로운 트랜잭션 타입을 담을 그릇(영어적 설명으론 Envelope)을 정의하는 것이다. 이전까지는 이더리움에 새로운 트랜잭션 타입을 추가하고자 할 때 정해진 규칙 내에서 다른 모든 트랜잭션들과 호환이 잘 이루어지는지 확인하고 이 확인 작업에서 문제가 있는 경우 새로운 트랜잭션을 만들 수 없는 한계가 존재했다. 이러한 확인 작업은 EIP-155의 정의 내용에 의해 확인이 되었지만 EOA 계정이 직접 코드를 실행할 수 있도록 하는 제안이나 msg.sender 이외의 사람이 가스 비용을 지불할 수 있도록 하는 제안, layer 1에서의 mul-sig 트랜잭션과 관련된 제안 등 새로운 트랜잭션 타입을 정의하는 제안을 빠르게 도입하는데 큰 걸림돌이었다.
따라서, EIP-2718에서는 Envelope 트랜잭션 타입을 도입하여 기존 트랜잭션과의 호환만 확인하고 그 이후로는 트랜잭션 간의 번호 충돌만 일어나지 않게 하면 새로운 트랜잭션들을 사용할 수 있는 환경을 제공하게 되었다.
각 이더리움 클라이언트는 트랜잭션의 첫 번째 바이트 값을 확인하여 기존 트랜잭션과 새로운 트랜잭션을 구분할 수 있다. [0 ~ 0x7f] 범위의 값으로 시작하는 트랜잭션은 새로운 트랜잭션 타입이며, [0xc0 ~ 0xfe] 범위의 값으로 시작하면 기존의 트랜잭션 타입이다.
이 때문에 이더리움을 사용하는 사용자는 새로운 EIP-2718 타입의 트랜잭션을 설계할 때 첫 번째 바이트에 트랜잭션 타입을 구분하는 구분자를 되도록이면 포함시켜야 한다. 이를 따르지 않을 경우 트랜잭션이 사용자에게 보안적으로 취약한 다른 타입의 트랜잭션과 혼동될 수 있기 때문이다.
EIP-2929: Gas cost increases for state access opcodes
EIP-2929에서는 SLOAD, CALL, BALANCE, EXT, SELFDESTRUCT opcode를 트랜잭션에서 처음 사용할 때의 가스비를 증가시키는 내용을 담은 업그레이드이다. 물론 첫 사용에서 가스비를 증가시키지만 전처리 및 동일한 트랜잭션에서 중복사용으로 이어지는 경우 가스 비용을 절감시키고 SSTORE 및 SELFDESTRUCT opcode를 개선하여 실제 스토리지 로드에 쓰이는 가스비 가격이 올바르게 책정되도록 하는 내용도 담고 있다.
일반적으로 opcode에 책정되는 가스비는 opcode가 블록 처리 시간 내에 얼마나 비중을 차지하는지에 대한 것을 기준으로 산정되는데 스토리지 액세스 opcode는 계속해서 가격이 저렴했었다. 그래서 2016년 상하이 DoS 공격에서 공격자들은 단순히 많은 수의 계정에 액세스하거나 호출하는 트랜잭션을 보냈다. 이 공격은 클라이언트가 디스크에서 계약을 검색하도록 강요하여 IO가 큰 트랜잭션을 발생하게 했다.
그래서 EIP-2929에서는 이러한 opcode의 비용을 3배까지 증가시켜 worst case 기준 트랜잭션 처리 시간을 기존 20~80초에서 7~27초로 단축시킬 수 있을 것으로 본다. 이러한 트랜잭션 처리 시간 단축을 바탕으로 향후 SNARK/STARK 증명을 생성할 때도 기존에 44.64초 정도 걸리던 것을 12.5초 까지 단축시킬 수 있을 것으로 전망했다.
EIP-2930: Optional access lists
EIP-2930은 Access List와 addresses, storage keys들의 List를 포함하는 트랜잭션 타입을 지정한다. 여기서 Access_list는 addresses와 storage keys의 List를 나타내는데 해당 내용들에 접근할 때 List 외부에서 접근할 때보다 List 내부에서 접근할 때 더 저렴한 가스비용을 제공한다.
이번 글에서는 04/14로 예정된 이더리움 베를린 업그레이드에 대해 살펴보았다. EIP로 대표되는 여러 기술들의 업그레이드가 포함이 되어있었고 이것을 통해 계속해서 앞으로 나아가고 발전하는 이더리움의 모습을 확인할 수 있었다.
이번 베를린 업그레이드나 이전에 있었던 업그레이드에 대해 더 많은 정보가 알고 싶다면 이 github 링크를 통해 살펴보거나 업그레이드에 참여했던 분들이 Medium에 설명을 자세히 하였으니 이 곳을 살펴봐도 좋을 것 같다.
이더리움 베를린 업그레이드 같이 블록체인을 발전시키고 싶은 여러 개발자들에 의해 개별적인 블록체인 발전과 더불어 전세계적인 블록체인 기술 인프라도 같이 발전했으면 좋겠다는 생각을 끝으로 이 글을 마치도록 하겠다.
