WebAssembly (WASM)와 Ethereum 2.0: EVM - WASM 인스트럭션셋 전환 논란, 간단하게 톺아보기

이 글은 필자의 블로그 (https://unifiedh.com/wasm-and-ethereum-20)에도 함께 게시되었습니다.

Ethereum 창시자 비탈릭 부테린이 Ethereum 2.0인 Serenity 체인에서 현 EVM 체제를 폐기하고, 점진적으로 Ethereum 플랫폼을 위해 일부 개조된 WebAssembly 규격인 eWASM (Ethereum flavored WebAssembly)로 전환할 계획을 본격적으로 밝히며 (...) 기존에 Ethereum 플랫폼에서 토큰과 DApp을 개발하던 일부 개발자들이 반발하고 나섰습니다. 그도 그럴 것이, 2014년 Ethereum이 런칭될 때부터 현재까지 약 5년 동안 유지해 왔던 EVM 인스트럭션셋 생태계로부터의 단절적 이행은, 사실상 기존 Ethereum 개발자와 DApp 생태계 베이스에 대한 지원을 (점진적이든 급진적이든) 언젠가는 끊겠다는 선언과 다름없기 때문입니다.

이러한 반발에도 불구하고 Ethereum 재단이 이러한 급진적인 선택을 내린 것에는 이유가 있습니다. 현 상황에서 WASM이 웹과 웹앱, 더 나아가 크로스-플랫폼 앱의 미래인 것은 분명하며, "Web 3.0" 플랫폼을 표방하는 Ethereum이 현재의 좁은 "블록체인, DApp 개발자" 풀에서 벗어나 훨씬 더 넓은 "앱 개발자" 풀까지 포용하기 위해서는 WASM으로의 전환을 제외하고는 다른 선택지가 없기에 그렇습니다.

대체 인스트럭션셋 전환이란 무엇이길래 기존 DApp 개발자들이 반발하고 나서는 것일까요? WebAssembly는 왜 웹앱의 미래라고 불리며, Ethereum이 이를 포용하려고 나서는 이유는 무엇일까요? 과연 간단하게 끝날지는 모르겠지만(...) 한 번 전체적으로 간단하게 살펴봅시다.

* 이미 Insturction Set Architecture와 VM 구조에 관한 기본적인 이해가 있으신 분들께서는 아래 대부분의 내용은 건너뛰셔도 무방할 듯 싶습니다.

# 인스트럭션셋과 레거시: 현대의 고성능 PC가 아직도 1980년대의 MS-DOS를 구동할 수 있는 이유

엔지니어가 아닌 대부분의 사람들이 잘 알지 못하는 사실이 하나 있습니다. 마우스 포인터와 키보드로 조작하는 대부분의 현대 PC는, 40년도 넘은 1970년대 후반에 출시된 최초의 IBM PC와 구조적으로는 크게 다르지 않다는 것. 현재 우리는 여러 개의 코어와 멀티쓰레딩 (SMT) 기술, 거기다 내장 GPU까지 탑재된 64비트 CPU를 사용하고 있지만, 이 CPU의 "인스트럭션셋"은 1979년에 출시된 인텔 8086 칩에 기반을 두고 있습니다.

실제로, 인텔과 AMD의 x86 CPU를 탑재한 모든 PC는 부팅 시 이 8086 마이크로프로세서와 동일한 16비트 real mode에서 시작합니다. 이 상태에서는 역시 오리지널 8086과 동일하게, 최대 1MB의 메모리밖에 액세스할 수 없습니다. 부팅 이후 과정에서 소프트웨어를 통해 반드시 32비트 protected mode, 64비트 프로세서/소프트웨어의 경우에는 64비트 long mode로 진입해야만 1MB보다 많은 메모리에 접근할 수 있습니다. (보다 정확하게는 레지스터의 크기와 그 커진 레지스터를 처리할 수 있는 인스트럭션, 그리고 메모리를 매핑하는 virtual address space에 더 넓게 접근할 수 있다는 등의 차이점이 있고, protected mode의 경우 80286에서 코드에 대한 권한 링을 도입해 보안과 runtime memory corruption을 막기 위해 도입되었지만, 본 글은 x86 아키텍처의 구조에 대한 글이 아니므로 상세한 설명은 생략하도록 하겠습니다 (...))

쉽게 설명하자면, 현대 x86 프로세서의 모든 성능을 활용하기 위해서는 우선 그 옛날의 인텔 8086과 정확히 동일한 16비트 real mode에서 시작해 한 단계씩 (32bit protected mode - 64bit long mode) 거쳐 더 많은 성능을 발휘하게 해 주는 단계로 올라가야만 한다고 보시면 되겠습니다. 이런 구조 덕분에, 지금까지 인텔 8086 및 그 호환 프로세서를 위해 쓰인 모든 소프트웨어는 아직도 현대 PC에서도 큰 문제 없이 구동할 수 있습니다. 1980년대의 유물인 MS-DOS를 현대 PC에서도 아무런 에뮬레이션 없이 네이티브로 구동할 수 있는 이유가 바로 이 때문입니다.

왜 현대 PC에 사용되는 x86 프로세서는 이렇게 설계되었을까요? 1970년대 발표되어 현재는 거의 쓰이지 않는 인텔 8086과의 호환성을 아직까지 유지하고 있는 이유가 무엇일까요?

사실 8086을 처음 만든 인텔 자신도 90년대 초부터 어떻게든 이 8086의 망령(?)에서 벗어나고자 발버둥을 쳤습니다. 다만 인텔이 이를 위해 야심차게 준비한 "포스트-x86 시대"의 결과물인 IA-64와 아이태니엄 (Itanium) 프로세서 제품군은, x86과의 하위 호환성을 그대로 끌고 가는 방식을 선택한 AMD의 AMD64(x86-64)와 애슬론64 프로세서 제품군에 완패해 그야말로 폭망(...)하고 맙니다.

이렇듯, IA-64를 비롯한 인텔의 모든 노력이 실패한 까닭은 다름 아닌 "레거시" 때문이었습니다. 레거시란, 지금까지 존재해왔던 모든 소프트웨어 설계와 코드, 바이너리, 그리고 그에 의존하는 개발자 등등을 모두 통칭하는 일종의 기존 생태계를 통칭하는 표현입니다. 보다 더 나은 신기술이 등장했다 하더라도, 기존의 소프트웨어와 개발자 생태계가 이전 기술에 맞추어져 있고 그 신기술에 맞추는 데에 많은 시간과 비용이 든다면, 사람들은 쉽게 신기술로 옮겨가지 않을 것입니다. 예를 들어, 새로운 Windows 버전에서 이 새로운 Windows 버전에 맞게 다시 짠 프로그램을 제외한 기존의 모든 Windows 프로그램들이 갑자기 모두 구동되지 않거나 성능이 크게 저하된다면, 사람들은 이 새로운 버전을 구입하려고 하지 않겠죠. 아무리 훌륭한 신기술이라도 이 "레거시"를 제대로 고려하지 않는다면 결코 시장에 성공적으로 안착할 수 없을 것입니다.

앞서 서술한 x86 아키텍처는 현존하는 레거시 중 가장 강력하고 오래된 레거시 중 하나입니다. 보다 정확히는, 인텔 8086과 현대의 x86 CPU들은 모두 같은 "인스트럭션셋"을 공유하기 때문에 MS-DOS를 비롯한 8086 (보다 정확하는 16-bit real mode) 이래로의 소프트웨어와 하위 호환성이 현재까지 유지될 수 있는 것이죠.

# 인스트럭션셋 하위 호환과 레거시의 관계

그렇다면, 인스트럭션셋이란 무엇일까요? 컴퓨터 프로그램은 사람이 바로 이해하기 어려운 "기계어"로 쓰여져 있다는 사실은 요즘 유치원생들도 알고 있는 사실입니다만, 사실 이 "기계어"도 프로세서에 내리는 일종의 "명령"이기 때문에... 이 "명령"들에 대한 구조와 방식 등에 대한 정의를 우선 내려야만 프로그램을 작성할 수 있을 것입니다. 이러한 공통된 명령어의 정의들에 관한 집합을 Instruction Set Architecture (인스트럭션셋 아키텍처, ISA)라고 합니다.

물론 무언가를 새로 "정의"한다는 건 처음부터 정해진 부분이 없다는 뜻이기 때문에, 만들고자 하는 설계 목표상의 범위를 만족하기만 한다면 (튜링완전한 고성능, 튜링완전한 저전력, 병렬연산, 채굴, 암호화/복호화 등등) 매우 다양한 설계 접근과 정의들이 존재할 수 있겠죠. 이 때문에 ISA에도 그 목적과 설계 접근에 따라 매우 다양한 종류가 존재하며, 그 중 하나가 x86입니다. 즉, ISA란 프로세서의 언어이며, 사람의 언어가 다양하듯 기계의 언어도 다양하게 존재할 수 있는 것입니다.

문제는 서로 다른 ISA를 가진 프로세서나 VM은 서로 호환되지 않는다는 점입니다. 예를 들어, ARMv8 ISA 타깃으로 빌드된 프로그램은 x86 프로세서에서 바로 구동할 수 없으며, 그 반대도 마찬가지입니다. 서로의 언어를 알지 못하니 당연한 일이겠죠. 따라서, 이 경우에는 별도의 에뮬레이션 또는 호환 레이어를 거쳐야만 해당 프로그램을 구동할 수 있습니다.

이렇게 에뮬레이션을 거쳐야만 하는 프로그램은, 당연하게도 해당 프로세서가 바로 구동할 수 있는 것보다 속도가 느립니다. 서로 언어가 다르니 당연히 통역을 한 번 거쳐야 하므로, 작업 속도가 느리겠죠. Dynamic Recompile이나 JIT 등의 기법을 사용하면 어느 정도 성능 영향을 줄일 수는 있겠으나, 처음부터 ISA-Independent하게 설계된 VM의 그것보다는 훨씬 더 성능에 미치는 영향이 클 수밖에 없습니다. 이러한 기법을 구현해내는 것도 당연히 많은 시간과 노력이 드는 일이고요.

인텔이 x86 레거시를 버리기 위해 안간힘을 썼지만, 결국 포기할 수밖에 없었던 이유가 바로 이것 때문입니다. 인텔은 x86을 폐기하고 단절적으로 64비트 아키텍처로 이행하기 위해 HP와 공동으로 IA-64라는 새로운 ISA를 개발했는데, ISA가 달라졌으므로 너무나 당연하게도 기존의 수많은 x86 프로그램은 상기와 같이 에뮬레이션을 거쳐야만 했습니다. 이들 애플리케이션의 성능 하락은 불 보듯 뻔했죠.

반면, 경쟁자인 AMD는 x86 아키텍처를 또다시 64비트로 확장해 기존 x86 ISA와의 하위호환을 (또다시) 가져가는 전략을 택했습니다. 따라서 AMD의 프로세서에서는 기존 x86 타깃의 32비트 프로그램들에서 체감상 아무런 성능하락도 없었고, 당연히 소비자들은 기존 자신들이 사용하던 애플리케이션에서 성능이 더 잘 나오는 AMD의 손을 들어준 것입니다. (물론 여기에는 IA-64에서 네이티브 VLIW (Very Long Instruction Word) 설계를 택해 실행의 병렬화를 통한 성능 향상을 꾀하다가, opcode instruction 간 dependency bit 설정 등의 일들을 compile-time에 맡겨버리는 등의 구조로 컴파일러가 지나치게 비대해지는 바람에 (...) IA-64 타깃 빌드가 당시의 프로세서에서 다소 버겁게 만들었던 인텔의 실책도 큽니다만, 역시 이 문제에 대해서는 아직까지 논란이 많으므로... 자세한 설명은 생략합니다.)

마찬가지 이유로 인해 현재는 MS가 모바일에서 사용되기에는 지나치게 비대하고 전력 소모가 큰 x86을 버리고 퀄컴의 스냅드래곤 프로세서를 탑재한 ARM 기반 Windows 10 PC를 밀어주고 있지만, ARM 프로세서 상의 x86 에뮬레이터 성능 문제와 각종 호환성 문제로 아직까지 인기를 얻지 못하고 있습니다. 애플의 경우 맥 플랫폼에서 ISA 이전을 두 번이나 (Motorola - PowerPC - x86) 성공적으로 이룬 상당히 드문 성공사례를 가지고 있지만, 이는 애플이 이전부터 내부적으로 Mac OS 플랫폼을 "혹시나를 대비해" 거의 모든 ISA 타깃으로 빌드해놓고 있었고, 맥 플랫폼을 독점하고 있었으므로 사용자들이 이에 따를 수밖에 없었기에 가능한 일이었습니다.

# EVM 아키텍처와 몇 가지 불만사항들

이게 다 Ethereum하고 무슨 상관이냐고요? 그건 지금부터 설명드리겠습니다 (...)

Ethereum이 혁명적인 이유는, 블록체인에 "튜링 완전한 실행환경"을 최초로 접목했기 때문입니다. 물론 앞서 논했던 프로세서들과는 달리, Ethereum은 플랫폼에 구애받지 않고 다른 소프트웨어 (컨트랙트)를 구동할 수 있는 소프트웨어이므로 하드웨어가 아닌 "가상의" 실행환경을 가지고 있습니다. 이렇게 자체적인 인스트럭션셋을 가진 소프트웨어 실행환경을 프로세스 가상머신 (VM)이라 하며, 가장 대표적인 것이 자바 바이트코드를 실행하는 자바 가상머신 (JVM)입니다.

Ethereum 역시 Java처럼 플랫폼에 구애받지 않고 컨트랙트를 구동하기 위해, Ethereum 가상머신 (EVM)을 새롭게 정의하고 구현했습니다. 이는 다른 블록체인이나 플랫폼과는 호환되지 않는 자체적인 인스트럭션셋으로, Ethereum은 EVM 옵코드와 그 코드의 길이를 기준으로 컨트랙트 실행 시 실행비용, 즉 가스를 부과하기 때문에 기존 프로세스 VM들과는 성격이 꽤나 다릅니다. 예를 들어, EVM에서의 컨트랙트 코드의 실행 순서는 순전히 해당 코드가 담긴 블록의 채굴 속도에 기반하므로 JVM과는 달리 process scheduler 등의 로직을 포함하고 있지 않으며, JavaScript처럼 single-threaded 구조를 가정합니다. 또한, runtime에서의 state transition 자체 역시 각 블록의 처리에 의존할 뿐만 아니라 블록체인의 특성상 변경도 힘들기 때문에, state와 같이 (CS/Compiler Construction의 관점에서) low-level에서 처리되는 것들을 거의 신경쓰지 않아도 되는 (것이 목적 그 자체인) 타 VM들과는 다르게 Finite-State Machine (FSM) 등의 기법을 사용해 컨트랙트 코드의 작성에 상당히 주의를 기울일 필요가 있습니다.

(참조: Mavridou & Laszka 2017, Designing Secure Ethereum Smart Contracts: A Finite State Machine Based Approach [https://arxiv.org/pdf/1711.09327.pdf]; Sanchez & Williams 2018, The Ethereum Virtual Machine (EVM) Architecture and Execution Context [https://fullstacks.org/materials/ethereumbook/14_evm.html#evm_architecture]. EVM의 구조와 언급된 FSM Approach 기반의 Smart Contract 설계와 관련해 좀 더 자세하게 알아보고 싶으시다면 읽어보시길 추천드립니다).

이 EVM은 ISA 그 자체만 놓고 보아도 문제가 한 두 가지가 아닙니다. 대표적으로, (다수의 EIP를 통해 개선되고는 있으나) 옵코드당 가스 계산 로직이 상당히 비효율적이어서 제공되는 성능 대비 지나치게 높은 실행비용을 부과하고 있으며 (특히 Storage 처리 쪽에서 그런 경향이 커서, 이를 해결하기 위해 여러 EIP들이 제안되었으나 정작 Constantinople에 포함될 예정이었던 EIP-1283(http://eips.ethereum.org/EIPS/eip-1283)은 reentrancy attack 취약점을 포함하고 있다는 사실이 밝혀져 최종 하드포크에서는 철회되었음), 앞서 지적된 바와 같은 적절한 프로세스 스케쥴링 미비, 앞의 두 문제가 결합되어 네트워크의 process overloading과 과도한 비용부과를 막기 위한 옵코드의 기능 제한 같은 문제를 들 수 있겠습니다.

또다른 문제점은 바로 EVM이 Ethereum에서만 동작하는 독자 규격이라는 점입니다. Ethereum이 처음 등장했을 당시 "블록체인 기반의 튜링완전한 실행환경"이라는 개념은 완전히 새로운 것이었고, 따라서 튜링완전한 General-Purpose 실행환경을 만들기 위해서는 블록체인 상에 스테이트 개념을 도입하는 것부터 실행비용 (Gas) 정의, 그리고 블록체인의 제한된 처리성능과 실행환경에 맞는 제한된 옵코드들을 정의해야만 했습니다. 블록체인이라고는 비트코인과 그 포크밖에 없었던 시절에는 상당히 제한되어 있는 Bitcoin Script 말고는 선행 사례가 전혀 없었으므로, 그 당시로서는 이런 식의 접근이 가장 합리적이었을 겁니다.

Ethereum이 점차 성능을 향상해 나가면서 온체인 성능이 어느 정도 받쳐주게 되면, 더 이상 성능이 아닌 바로 이 EVM 인스트럭션셋이 발목을 잡게 될 것은 자명합니다. 아기가 자라 정신적으로 성숙했는데도 언제까지나 옹알이 언어만 확장해서 사용할 수는 없겠죠. 이는 향상된 온체인 성능에 걸맞는 DApp의 개발에 큰 걸림돌이 될 것이 확실해 보입니다.

더 큰 문제는 이제부터입니다. Ethereum은 탈중앙화된 컴퓨팅 인프라, 즉 "The World Computer"를 내세우면서 "Web 3.0"을 가장 중요한 모토 중 하나로 잡았는데, 웹이라는 건 모든 당사자가 합의해 플랫폼에 상관없이 어디에서든 사용할 수 있는 표준이 생명인 세계입니다. 이쪽은 MS가 웹 브라우저 시장을 독점하자마자 IE6를 통해 사실상 단독으로 웹표준을 정하던, 그래서 5년 넘게 웹 기술에 아무런 발전이 없었던 "암흑기"를 경험한 적이 있기 때문에 (...) 어느 한쪽에서만 동작하는 독점 기술을 선호하지 않는 편입니다. (물론 구글 크롬이 웹 브라우저 시장을 다시 독점하게 되자 크롬 말고는 테스트를 전혀 안 하는 등 (...) 다시 예전으로 돌아갈 분위기이긴 하지만...)

아무리 이더리움 재단이 사용자들이 참여하는 비영리 재단이고 오픈 소스 커뮤니티를 중심으로 개발이 진행된다고 할지라도, 하나의 단체가 단독으로 정하는 "표준" 기술을 나머지 주류 업계가 받아들일 리 없습니다. 진정으로 "Web 3.0"을 내세운다면 블록체인뿐만이 아닌, 다른 모든 플랫폼에서도 범용적으로 사용할 수 있는 표준을 받아들이는 것이 급선무일 겁니다.

...그리고 그런 표준은 이미 존재합니다. 바로 WebAssembly, 즉 WASM입니다.

# WASM: 모두가 동등한 미래

WebAssembly의 아이디어는 단순합니다. 기존 브라우저들에 존재하는 JavaScript 엔진을 어셈블리 레벨의 저수준 코드까지 실행할 수 있도록 만들어, 웹 브라우저에서 실행되는 웹앱이라도 네이티브에 가까운 실행 성능을 낼 수 있도록 하겠다는 것입니다.

별 것 아닌 것 같지만, 이는 컴퓨팅의 역사에서 매우 중대한 변화입니다. HTML, CSS, JavaScript를 비롯한 웹 기술은 사용자가 어떤 플랫폼을 사용하든 상관없이, 모두 동등한 환경에서 사용할 수 있는 유일한 애플리케이션 플랫폼이기 때문입니다. 기존의 앱과 프로그램은 각 플랫폼별로 별도의 버전을 만들어야 했으나, 웹 기술은 브라우저별 호환성만 잘 맞춰 주면 모두가 같은 환경에서 같은 사용자 경험을 제공받을 수 있습니다. 개발자 입장에서는 플랫폼별로 별도로 앱을 개발할 필요가 없으니 사용자에게 더 나은 경험을 제공하는 데에 집중할 수 있고, 그 혜택은 그대로 사용자에게 돌아옵니다.

문제는 성능입니다. 웹 기술이 발전하면서 아무리 요즘 PC의 성능이 좋아졌다고는 하나, JavaScript는 여전히 (이름에서도 드러나듯) "스크립트" 언어입니다. 다시 말해, 사전에 컴파일되지 않고 실행할 때마다 JavaScript 엔진을 통해 인터프리팅을 거치거나, (최신 브라우저의 경우) JIT 컴파일러를 동원해야 한다는 뜻입니다.

이 문제는 Electron 기반의 웹앱과 하이브리드 앱, 그리고 Progressive Web App (PWA)이 새로운 유행이 된 현재에 와서 더욱 더 두드러졌습니다. 이러한 솔루션들은 예전과는 달리 (플랫폼 추상화를 통해) 각 플랫폼별로 앱을 각각 개발해야 하는 수고를 덜어주어, 사용자들이 더욱 더 고품질의 앱을 사용할 수 있도록 했으나 그 대가로 시스템 리소스를 지불해야만 했습니다. 특히나 Electron 앱의 경우 각 앱별로 (가뜩이나 그 자체로도 무거운) 별도의 Chromium 인스턴스가 내장되어 있기 때문에... 슬랙 하나 돌리는 데 램을 1.5GB씩 먹는 것이 농담이 아닌 시대가 되었죠. (...)

또한, 스크립트 언어의 한계상 사용하고 있는 장치의 네이티브 성능에 직접 접근하는 것도 어느 정도 제한이 있을 수밖에 없습니다. 예를 들어, 이제는 WebGL을 사용해 웹 브라우저 내에서 직접 3D 게임을 실행하는 것도 가능한 시대가 되었으나, 아직까지 게임 마니아들이 즐기는 수준의 그래픽은 웹 브라우저에서 구현할 수 없습니다.

WebAssembly를 사용하면 JavaScript의 이러한 성능 문제를 해결할 수 있습니다. 완전한 네이티브 바이트코드는 아니지만, 저수준 어셈블리 언어이기 때문에 JavaScript보다는 훨씬 overhead가 적으며, 하드웨어에 보다 직접적으로 접근이 가능하기 때문입니다. 또한, C/C++로 작성한 코드를 WASM 타깃으로 빌드할 수도 있기 때문에, 기존의 저수준/고성능 코드를 그대로 재사용해 기존에는 네이티브 코드로만 구현이 가능했던 고성능 웹 애플리케이션을 만드는 것도 가능해질 것입니다. 실제로도 Emscripten (https://emscripten.org) 등의 LLVM - Web (JS/WASM) 컴파일러 백엔드를 사용해, Windows 95를 Electron 웹앱으로 포팅한 사례도 있습니다. 각 플랫폼의 API 제약에 구애받지 않는, 모두가 동등한 미래 그 자체인 것이죠.*

(주: clang/LLVM의 완전한 WASM 네이티브 백엔드 지원은 현재 작업이 진행 중입니다. 다만, Emscripten 등 3rd party backend를 사용하면 동일하게 사용이 가능합니다.)

물론 블록체인 세계에서도 이러한 WebAssembly의 잠재력을 일찍부터 깨달은 이가 있었으니, 바로 EOS의 창시자 댄 라리머입니다. 물론 과연 EOS가 블록체인의 정신인 "탈중앙화"를 제대로 구현하는지에 대해서는 아직까지도 논란이 많고, 개인적으로 DPoS를 그리 좋아하는 편은 아닙니다만 (...) WebAssembly의 잠재력을 일찍부터 블록체인 플랫폼에 포용한 것은 충분히 높게 평가할 만합니다. EOS가 WebAssembly를 차용해온 덕분에 새로운 언어 베이스를 구축해야만 했던 Ethereum과는 달리, 기존의 C/C++ 개발자 베이스를 그대로 포용해올 수도 있었고요.

# 그래, WASM 좋은데, 그래서 뭐가 문제라는 거야?

이로만 놓고 보면 WASM으로의 이행은 Ethereum으로서 당연히 밟아야 할 수순으로만 보이는데, 사실 문제는 그 이행이 생각보다 간단하지 않다는 것입니다. 그 이유는, 앞서 서술했던 레거시 문제 때문입니다.

블록체인 세계에서는 지금까지 레거시라는 것이 존재하지 않았습니다. 생각해 보면 그럴 이유도 없었고요. 레거시라는 건 이전 기술을 사용하는 사용자 베이스가 새로운 기술으로의 전환을 방해할 때 생기는 건데, 지금까지 블록체인 업계에서는 대체될 "이전 기술"도, 대체할 "새로운 기술"도, 그걸 사용할 "사용자 베이스"도 모두 충분히 존재하지 않았기 때문입니다.

...Ethereum이 크립토 붐과 함께 급부상하기 이전까지는 말이죠.

2017년 말에 유례를 찾아보기 힘든 크립토 붐이 찾아오면서, 암호화폐공개 (ICO)를 진행하기 위해 Ethereum을 사용해 토큰을 발행하는 사람들의 수가 급증하기 시작했습니다. 이 수많은 토큰 컨트랙트들은 모두 Solidity 코드로 작성되어 ERC-20 표준을 사용해 EVM 타깃으로 빌드되었고, 토큰 발행을 통해 스마트 컨트랙트의 가능성에 눈을 뜬 사람들이 EVM과 Solidity 위에서 DApp을 개발하기 시작했습니다. 하나의 생태계가 형성된 것이죠.

앞서 인텔의 IA-64/Itanium의 실패 사례에서도 살펴보았듯, 이러한 기성 생태계의 형성은 강력한 레거시로서 작용해 신기술로의 손쉬운 전환을 방해합니다. 마찬가지로, Ethereum이 기존 EVM에서 eWASM으로 실제로 전환할 때, 한 때 Ethereum의 성장에 크나큰 공헌을 했던 EVM 기반 개발 커뮤니티가 반대로 "전환의 적", "적폐"로 돌변할 가능성이 농후합니다. 특히나, 블록체인의 특성상 일반 컴퓨팅 인프라처럼 기존의 컨트랙트와 코드를 eWASM 기반으로 전환할 수 없으므로 더욱 더 신중히 진행해야 합니다.

이뿐만이 아닙니다. 이 EVM 전환 과정에서는 Ethereum이 인기를 얻으면서 완전히 EVM과 호환되도록 개발된 다른 블록체인 플랫폼들과 TRON과 같은 Ethereum 포크 체인들, 그리고 그 위에서 구동되는 토큰들과 스마트 컨트랙트의 존재까지 고려해야 합니다. Ethereum이 세레니티에서 공식적으로 EVM을 폐기하더라도, 이러한 EVM 호환 생태계가 이 변화에 적응하기까지는 상당히 오랜 시일이 걸릴 겁니다. "주류" Ethereum 개발 커뮤니티는 이들 EVM 호환 체인과 포크 체인들을 "짝퉁" 또는 "스캠"이라며 깔보는 경향성이 있으나, 오픈 소스 프로젝트로서 포크를 무시하는 모습은 매우 우려스럽지 않을 수 없습니다. IBM "짝퉁"인 IBM 호환 PC가 없었더라면 Windows는 현재의 자리에 오르지 못했을 것이며, Android가 제조사 포크를 허용하지 않았더라면 현재 모바일 시장의 절대 강자에 오를 수 없었을 것처럼요. 마찬가지로, 월드와이드웹이 특허가 걸려 있었더라면 전 세계에서 동시다발적으로 동일한 규격의 네트워크가 구축되어 서로 연결되는, 현대의 "인터넷" 아키텍처는 완성되지 못했을 것입니다. "탈중앙화"를 지향한다면서, 수많은 이해관계자의 밥줄이 걸려있는 생태계와 런타임의 존폐와 관련한 사항을 하나의 단체가 독단적으로 결정하는 것은 있을 수 없는 일입니다.

물론 Ethereum 개발진들은 이에 관한 솔루션을 가지고 있기는 합니다. 기존 컨트랙트의 EVM1 바이트코드를 eWASM 코드로 전환하는 트랜스파일러를 만들어, 그 트랜스파일러 자체를 eWASM 컨트랙트로서 Ethereum 상에서 구동하겠다는 것입니다. (https://github.com/ewasm/design/blob/master/backwards_compatibility.md) 다만, 여기서도 역시나 의문이 드는 부분은 한두 가지가 아닙니다.

1. 우선 Ethereum 2.0이 아무리 성능이 뛰어나다고 해도, 바이트코드 트랜스파일러 같은 꽤나 복잡하고 높은 성능이 요구되는 코드를 "온체인 컨트랙트"로 구동할 수 있을까요? 앞서 인텔의 사례에서도, 무려 "고성능 데스크탑 프로세서"의 ISA를 전환하는 것이었음에도 불구하고 에뮬레이터의 성능 overhead로 인해 AMD에 패배할 수밖에 없었다고 언급했었습니다. 고성능 네이티브 프로세서의 경우에도 이러한데, 과연 온체인으로 이러한 에뮬레이션을 구동하는 것이 가능할까요? 실행 시마다 에뮬레이팅하는 방식이 아닌 최초 1회만 실행해 eWASM으로 트랜스파일링을 실행하는 방식이라 할지라도, 최소한 현재의 연구 성과들만 놓고 보았을 때 아주 획기적인 솔루션이 등장하지 않는 한 이를 온체인으로 처리한다는 발상은 다소 이해가 가지 않는 부분입니다.
2. 1의 overhead를 줄이기 위해서는 eWASM을 디자인적으로 WASM보다 EVM에 조금 더 가깝게 만드는 수밖에 없는데, 이렇게 되면 WASM의 바이트코드 레벨 및 언어 단 호환성을 잃게 되므로 앞서 언급한 WASM의 대중성과 그에 따른 도입 당위성은 상당히 와해될 수밖에 없습니다.
3. Design Docs에서 언급된 트랜스파일러 솔루션은 작년 12월 이후로 개발이 중단된 상태이며 (https://github.com/ewasm/evm2wasm), 이를 대체할 RuneVM (https://github.com/axic/runevm)의 경우 Parity의 EVM-eWASM 솔루션에 사실상 대부분을 의존, 개발이 그리 활발한 상태가 아닙니다. 현 Ethereum 2.0 로드맵에 맞추어 개발이 진행될 수 있을 것이라고 보이지 않습니다.

결국 가장 현실적으로 보이는 그림은... 하드포크가 진행될 때마다 EVM 상에서 depreciate된 옵코드들을 무기한으로 지원할 수밖에 없는 것처럼, EVM 전체를 depreciate하되 실행 자체는 무기한 지원하고, 신규 프로젝트에 한해 최대한 eWASM으로의 전환을 독려하는 것 말고는 없어 보입니다. 코드 자체를 대체할 수 있는 Upgradable Smart Contracts 솔루션이 등장하기는 했으나 여전히 production에 바로 사용하기에는 위험한 "hack"에 가까운 수준이고, 그렇다고 해서 이미 EVM 기반으로 실행되고 있는 수많은 "레거시" 토큰과 DApp 컨트랙트들을 중지할 수는 없는 노릇이니까요. 문제는 이러한 "권고"에는 강제력이 있을 수 없으므로... 계속해서 EVM 기반으로 컨트랙트를 배포하는 개발자들에 대해서는 별도로 제지할 방법이 마땅치 않습니다. 점진적으로 신규 EVM 바이트코드의 배포를 막는다고 하더라도, 기존 EVM 생태계의 반발을 살 가능성이 농후합니다.

결론적으로, 이 전환 과정은 Ethereum 역사상 가장 험난한 여정이 될 것으로 보입니다. 이미 인텔과 MS를 비롯한 세계 유수의 기업들도 딱히 해결책을 찾아내지 못한 레거시 문제에 더해, 블록체인 특유의 "변경 불가능성"과 성능 문제까지 겹쳐 매우 풀어내기 어려운 난제가 등장했습니다. (...)

"가야만 하는 방향"과 "Ethereum이라는 플랫폼으로서의 생태계와 정체성" 사이에서 과연 제대로 방향을 잡을 수 있을지, 계속해서 지켜보아야 할 듯합니다. 만약 기존 EVM 생태계를 성공적으로 eWASM으로 유도해내지 못한다면, 업계 내의 심각한 분열과 혼란은 불가피하지 않을까 싶습니다. 이 혼란을 틈타 이미 WASM에 안정적으로 정착한 EOS만 더 잘 나가는 상황이 될 수도 있고, WASM 코드를 온체인에서 구동하는 성능을 기준으로 한 플랫폼 체인의 춘추전국시대가 다시 올 수도 있겠고요. (...) 현행 EVM 체제를 유지하려는 쪽이 체인을 하드포크해 분열할 가능성도 충분히 있을 듯 합니다.

Ethereum의 비전과 그 비전을 실현해나가는 사람들을 조용히 응원하는 한 사람으로서, Ethereum 개발팀이 Ethereum 2.0을 통해 탈중앙화된 "Web 3.0"의 실현에 더욱 더 가까이 다가갈 수 있었으면 하는 바람입니다. 🙂