1. EVM은 튜링 완전하지 않다​

인터넷에는 "EVM이 튜링 완전하다"는 흔한 오해가 있지만, 실제로는 그렇지 않습니다.

튜링 머신은 앨런 튜링이 1936년에 제안한 수학 모델로, 무한 길이의 테이프, 유한 알파벳, 읽기/쓰기 헤드, 상태 레지스터, 그리고 유한 명령어 집합으로 구성됩니다. 초기 구성에서 시작해 헤드는 명령어 집합을 따라 한 단계씩 움직이고 기록하다 상태가 "정지"가 될 때 계산이 끝납니다. 컴퓨팅 분야에서 우리가 다루는 모든 문제는 계산 문제이며, 튜링 완전이란 임의의 계산 가능 문제를 풀 수 있다는 의미입니다. 프로그래밍 언어나 가상 머신은 본질적으로 튜링 머신이며, 튜링 완전이라는 말은 곧 튜링 머신이 할 수 있는 모든 일을 할 수 있다 — 즉, 모든 계산 가능 문제를 풀 수 있다 — 는 뜻입니다.

그러나 EVM의 설계에서는 모든 명령 실행이 가스에 의해 제한되어 수행 가능한 계산 횟수가 제한됩니다. 이는 튜링 불완전의 흔한 원인 중 하나로, 반복, 재귀, 계산이 모두 유한해 프로그램의 종료가 보장됩니다. 따라서 EVM에서 실행 가능한 프로그램은 많은 제약을 받게 되며, EVM은 튜링 완전이 아닙니다.

2. EVM의 비합리적인 설계​

EVM은 최초의 준 튜링 완전 가상 머신으로서 스마트 컨트랙트 기반 DApp 개발의 길을 열었습니다. 그러나 블록체인 응용이 확산되면서 EVM 초기의 비합리적인 설계가 점차 드러났고, 일부는 심각한 보안 사고로까지 이어졌습니다. 가상 머신 계층만 보아도 설계 측면과 보안 측면에 다음과 같은 문제가 있습니다:

2.1 스마트 컨트랙트 설계 측면​

• 표준 라이브러리 부족: EVM은 충분한 표준 라이브러리 지원을 제공하지 않으며, 가장 기본적인 string 타입조차 다루기 불편해 문자열 연결, 분할, 검색 등을 모두 개발자가 직접 구현해야 합니다. 결과적으로 개발자는 본업과 무관한 자질구레한 디테일에 시간을 빼앗기고 비즈니스 로직에 집중하기 어려워집니다. 직접 구현한 라이브러리는 시간/공간 복잡도가 과해 불필요한 가스를 낭비하기 쉽고, 오픈 소스에서 가져온 코드는 보안 리스크와 감사 부담을 더할 수 있어 어느 쪽도 이득이 적습니다.
• 디버깅과 테스트가 어려움: EVM은 OutOfGas 예외를 던지는 것 외에 개발자에게 정보를 돌려주지 않습니다. 로그 출력이 없고 브레이크포인트나 단계별 디버깅도 불가능합니다. event 메커니즘이 부분적으로 이를 보완하지만, 본래 디버깅 도구로 설계된 것이 아니어서 우아하거나 사용하기 좋다고 보기 어렵습니다.
• 부동소수 미지원: EVM은 부동소수를 지원하지 않으며 이더리움은 Wei를 최소 단위로 정수만 다룹니다. 이를 통해 부동소수의 정밀도 문제는 피했지만, 실무에서는 eth 값을 표현하기 위해 변수 뒤에 많은 0을 붙여야 해서 코드 유지보수가 매우 까다로워집니다. 부동소수가 특정 상황에서는 여전히 유용한 만큼 일률적으로 배제할 일은 아닙니다.
• 컨트랙트 업그레이드 불가: EVM은 컨트랙트 업그레이드를 지원하지 않으며, 업그레이드 가능성은 스마트 컨트랙트 개발의 강한 요구 사항 중 하나입니다. 보안 패치, 기능 확장 등에 필수적이지만 EVM은 전혀 지원하지 않으므로 개발자는 새 컨트랙트를 다시 배포할 수밖에 없으며, 그만큼 시간과 노력이 더 듭니다.

2.2 스마트 컨트랙트 보안 측면​

• 오버플로 공격: EVM의 safeMath 라이브러리는 기본값으로 사용되지 않습니다. Solidity에서 uint256 연산 결과가 uint256 최댓값을 넘어가면 매우 작은 수로 오버플로되며 취약점이 발생합니다. BEC, SMT 같은 토큰들이 모두 오버플로 공격을 겪고 큰 피해를 입었습니다. BEC의 오버플로 취약점은 다음과 같았습니다:

function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
    uint cnt = _receivers.length;
    uint256 amount = uint256(cnt) * _value; // 여기서 오버플로 발생
    require(cnt > 0 && cnt <= 20);
    require(_value > 0 && balances[msg.sender] >= amount); // 오버플로 후 require가 항상 참이 되어 취약점이 성립

    balances[msg.sender] = balances[msg.sender].sub(amount);
    for (uint i = 0; i < cnt; i++) {
        balances[_receivers[i]] = balances[_receivers[i]].add(_value);
        Transfer(msg.sender, _receivers[i], _value);
    }
    return true;
}

• 재진입 공격: Solidity의 큰 특징 중 하나는 외부 컨트랙트를 호출할 수 있다는 점입니다. 그러나 ETH를 외부 주소로 보내거나 외부 컨트랙트를 호출하려면 외부 호출이 필요한데, 만약 대상이 악의적인 컨트랙트라면 fallback 함수에 악성 코드를 심을 수 있습니다. 송금이 일어날 때 fallback이 호출되며 악성 코드가 호출자의 취약한 함수를 다시 호출해 송금이 반복됩니다. 가장 유명한 재진입 공격은 이더리움 초기의 DAO 사건입니다. 아래 스니펫이 그 구조를 보여줍니다:

contract weakContract {
    mapping (address => uint) public balances;
    ...... // 기타 컨트랙트 코드
    function withdraw() {
        // 호출자의 잔액을 송금하고 그 다음 balance map을 0으로 만든다.
        // !!! 0으로 만들기 전까지는 msg.sender를 계속 호출해 송금을 일으킬 수 있어 여기서 재진입이 발생한다.
        if (!msg.sender.call.value(balances[msg.sender])()) {
            throw;
        }
        balances[msg.sender] = 0;
    }
    ..... // 기타 컨트랙트 코드
}

contract attack{
    weakContract public weak;
    ...... // 기타 코드
    // 아래 함수는 fallback. 외부 송금 시 호출되어 weakContract.withdraw를 반복 호출하며 재진입 공격을 수행한다.
    function () payable {
        if (weak.balance >= msg.value) {
            weak.withdraw();
        }
    }
    ...... // 기타 코드
}

• 예상치 못한 함수 실행: EVM은 함수 호출을 엄격하게 검사하지 않습니다. 컨트랙트 주소가 호출자가 조작 가능한 형태로 인자로 전달되면 의도치 않은 동작이 발생할 수 있습니다:

contract A {
     function withdraw(uint) returns (uint);
}

// B를 실행할 때 A 컨트랙트에 withdraw 메서드가 있는지만 확인하고, 있으면 정상적으로 호출한다.
// 전달된 a에 withdraw가 없다면 a의 fallback 함수가 호출되어 의도치 않은 동작이 일어난다.

contract B {
    function put(A a){ a.withdraw(42);
}

3. 또 다른 주목 체인 EOS의 두드러진 문제​

EOS는 이더리움에 이어 또 한 번 주목받은 퍼블릭 체인으로, WebAssembly 기반의 독자적인 스마트 컨트랙트 엔진을 갖추고 있습니다. 하지만 EOS의 컨트랙트 개발에는 다음과 같은 분명한 문제가 있습니다:

• 계정 시스템이 친화적이지 않다: 계정 생성 난이도가 높고, 계정이 있어야 컨트랙트를 배포할 수 있습니다. EOS에서는 기존 계정으로 새 계정을 만들어야 하므로, EOS 계정을 이미 보유한 친구나 제3자를 찾기가 쉽지 않습니다. 계정을 만들려면 RAM을 사야 하므로 실제 비용이 들고, 제3자를 통하면 자금 리스크도 생깁니다. 계정을 만든 뒤에도 EOS를 스테이킹해 CPU 시간과 네트워크 대역폭을 확보해야 EOS 네트워크에서 동작이 가능합니다. 개발자에게는 절차가 너무 번거롭습니다.
• RAM 가격: RAM이 비쌉니다. 컨트랙트 실행에는 RAM이 필요하며, EOS는 RAM 거래 시장을 열어 두었지만 투기적 거래로 인해 가격이 매우 높습니다.
• 개발 난이도가 높다: 컨트랙트 언어로 C++를 사용해 개발 진입 장벽을 크게 올렸습니다. C++ 자체도 매우 복잡한데 그 위에서 EOS.IO C++ API까지 다뤄야 하므로 개발자 개개인에게 요구되는 역량이 매우 큽니다.

이러한 이유들로 인해 EOS 스마트 컨트랙트 개발은 개발자에게 매력이 떨어지며, 오히려 EOS를 떠나는 이유가 될 수도 있습니다.

4. IOST 가상 머신의 탄생​

좋은 가상 머신은 우아한 설계와 함께 사용성과 안전성을 모두 만족해야 한다고 봅니다. EVM, EOS, C Lua, V8 등 여러 VM의 장단점을 비교한 뒤, EVM과 EOS의 비합리적인 설계를 근본부터 다시 짚었고, Node.js와 Chrome에서의 V8의 뛰어난 성능을 바탕으로 V8 기반의 IOST 가상 머신을 만들었습니다.

4.1 IOST V8VM 아키텍처와 설계​

V8VM 아키텍처의 핵심은 VMManager이며 주로 다음 세 가지 역할을 합니다:

• VM 진입점: 다른 모듈로부터 들어오는 요청(RPC 요청, 블록 검증, Tx 검증 등)을 받아 전처리/포맷팅한 뒤 VMWorker에게 실행을 위임합니다.
• VMWorker 라이프사이클 관리: 현재 시스템 부하에 맞춰 워커 수를 유연하게 조정하고 워커를 재사용합니다. 워커 내부에서는 JavaScript 코드의 핫 스타트와 핫 Sandbox 스냅샷 영속화를 구현해 VM을 반복 생성하거나 같은 코드를 반복 로드하면서 발생하는 고부하/메모리 폭주를 막아, 시스템 자원 사용을 줄이면서 처리량을 크게 끌어올렸습니다. 결과적으로 Fomo3D처럼 단일 컨트랙트에 대규모 사용자가 몰리는 워크로드도 IOST V8VM이 무리 없이 처리합니다.
• State 데이터베이스와의 상호작용: 모든 IOST 트랜잭션의 원자성을 보장합니다. 컨트랙트 실행 실패나 가스 부족 시 트랜잭션 전체를 롤백합니다. State 데이터베이스에서는 두 단계의 메모리 캐시를 적용한 뒤 최종적으로 RocksDB로 flush합니다.

4.2 Sandbox 핵심 설계​

Sandbox는 JavaScript 스마트 컨트랙트를 실제로 실행하는 곳입니다. 위로는 V8VM을 받고 아래로는 Chrome V8을 래핑해 호출하며, Compile 단계와 Execute 단계로 나뉩니다:

Compile 단계

주로 컨트랙트 개발과 온체인 배포를 위한 단계로, 두 가지 주요 기능이 있습니다:

• Contract Pack: 스마트 컨트랙트의 번들링. webpack을 기반으로 현재 프로젝트의 모든 JavaScript 코드를 번들링하고, 의존성 설치까지 자동으로 수행해 IOST V8VM에서 대형 컨트랙트 프로젝트를 구축할 수 있게 합니다. IOST V8VM은 Node.js의 모듈 시스템과 완전 호환이라 require, module.exports, exports를 그대로 사용할 수 있어 네이티브 JavaScript 개발 경험을 제공합니다.
• Contract Snapshot: V8의 스냅샷 기능을 사용해 JavaScript 코드를 사전에 컴파일합니다. 컴파일된 코드는 Chrome V8의 isolate와 context 생성 효율을 크게 높이며, 실제 실행 시에는 스냅샷을 deserialize하기만 하면 되어 로드 속도와 실행 속도를 모두 크게 끌어올립니다.

Execute 단계

실제 온체인 컨트랙트 실행을 위한 단계로, 두 가지 주요 기능이 있습니다:

• LoadVM: VM 초기화를 수행합니다. Chrome V8 객체 생성, 시스템 실행 파라미터 설정, 관련 JavaScript 라이브러리 import 등 컨트랙트 실행에 필요한 모든 준비를 마칩니다. 주요 JavaScript 라이브러리:

• Execute: 최종 실행 단계. IOST V8VM은 컨트랙트를 별도 스레드에서 실행하고 실행 상태를 모니터링합니다. 예외, 리소스 한도 초과, 실행 시간 초과 중 하나라도 발생하면 Terminate를 호출해 실행을 중단하고 오류 결과를 반환합니다.

4.3 IOST V8VM 성능​

가상 머신은 퍼블릭 체인의 가장 핵심적인 인프라이므로 성능이 충분히 뛰어나야 합니다. IOST는 설계 단계와 VM 선정 단계부터 성능을 최우선 지표 중 하나로 삼아왔습니다.

Chrome V8은 JIT, 인라인 캐싱, 지연 로딩 등으로 JavaScript의 해석 실행을 가속합니다. Chrome V8의 높은 성능 덕분에 IOST V8VM의 JavaScript 실행 속도도 크게 향상되었습니다. 재귀 fibonacci, 메모리 복사, 복잡한 CPU 연산 세 가지 측면에서 EVM, EOS, C Lua, V8VM의 성능을 비교한 결과는 다음과 같습니다:

• 테스트 환경

• 결과

실측 결과 IOST V8VM은 주요 VM 구현 중에서도 우수한 성능을 보였습니다. 위 수치에는 VM 시작과 설정 로드 시간이 포함되어 있어 콜드 스타트 단계에서도 이미 유리한 모습입니다. 앞으로 VM 객체 풀, LRU 캐시 등을 추가해 CPU/메모리 사용률을 더 끌어올리고 IOST의 스마트 컨트랙트 처리 능력을 한층 더 향상시킬 예정입니다.

4.4 마무리​

현재 IOST V8VM 1차 버전을 완성했으며, 계획한 모든 기능을 구현했습니다. 이후의 반복 개발에서는 안전성과 사용성을 최우선으로 다음 세 방향에서 지속적으로 개선해 나갈 예정입니다:

• 높은 성능 — 컨트랙트가 더 빠르게 실행되도록.
• 더 친화적인 개발 경험 — 표준 라이브러리를 더 늘리고 다듬기.
• 대형 프로젝트의 빌드/디버그를 지원하는 완성도 높은 툴체인.

1차 버전의 IOST V8VM 개발에서는 투표, 컨트랙트 이름, 토큰 등 많은 아이디어를 초기 검증할 수 있었으며, 더 많은 새 기능은 다가오는 테스트넷 업데이트에서 단계적으로 제공될 예정입니다.

부록: VM 벤치마크 프로그램​

• 1. EVM 코드

package evm

import (
   "math/big"
   "testing"

   "github.com/ethereum/go-ethereum/accounts/abi/bind"
   "github.com/ethereum/go-ethereum/accounts/abi/bind/backends"
   "github.com/ethereum/go-ethereum/common"
   "github.com/ethereum/go-ethereum/core"
   "github.com/ethereum/go-ethereum/crypto"
)

var bm *Benchmark

func init() {
   key, err := crypto.GenerateKey()

   auth := bind.NewKeyedTransactor(key)
   gAlloc := map[common.Address]core.GenesisAccount{
      auth.From: {Balance: big.NewInt(1000000)},
   }
   sim := backends.NewSimulatedBackend(gAlloc)

   _, _, bm, err = DeployBenchmark(auth, sim)

   if err != nil {
      panic(err)
   }
   sim.Commit()
}

func BenchmarkFibonacci(b *testing.B) {
   for i := 0; i < b.N; i++ {
      _, err := bm.Fibonacci(nil, big.NewInt(32))
      if err != nil {
         b.Fatalf("fibonacci run error: %v\n", err)
      }
   }
}

func BenchmarkStrConcat(b *testing.B) {
   for i := 0; i < b.N; i++ {
      _, err := bm.StrConcat(nil, "This is vm benchmark, tell me who is slower", big.NewInt(10000))
      if err != nil {
         b.Fatal(err)
      }
   }
}

func BenchmarkCalculate(b *testing.B) {
   for i := 0; i < b.N; i++ {
      _, err := bm.Calculate(nil, big.NewInt(5000))
      if err != nil {
         b.Fatal(err)
      }
   }
}

• 2. Lua 코드

function fibonacci(number)
    if number == 0
    then
        return 0
    end

    if number == 1
    then
        return 1
    end

    return fibonacci(number - 1) + fibonacci(number - 2)
end

function strConcat(str, cycles)
    local result = ""
    for i = 1, cycles do
        result = result .. str
    end

    return result
end

function calculate(cycles)
    local rs = 0
    for i = 0, cycles-1 do
        rs = rs + math.pow(i, 5)
    end

    return rs
end

• 3. EOS 코드

class fibonacci : public eosio::contract {
public:
    using contract::contract;

    /// @abi action
 void calcn(int64_t n) {
      int64_t r = calc(n);
      print(r);
   }
    int calc( int64_t n ) {
      if (n < 0)
      {
          return -1;
      }
      if (n == 0 || n == 1)
      {
          return n;
      }
      return calc(n - 1) + calc(n - 2);
    }
};

EOSIO_ABI( fibonacci, (calcn) )


class stringadd : public eosio::contract {
public:
    using contract::contract;

    /// @abi action
 void calcn(std::string s, int64_t cycles) {
      std::string ss(s.size() * cycles, '\0');
      int32_t k = 0;
      for (int i = 0; i < cycles; ++i)
      {
         for (int j = 0; j < s.size(); ++j)
         {
            ss[k++] = s[j];
         }
      }
      print(ss);
   }
};

EOSIO_ABI( stringadd, (calcn) )


class calculate : public eosio::contract {
public:
    using contract::contract;

    /// @abi action
 void calcn(uint64_t cycles) {
      uint64_t rs = 0;
      for (uint64_t i = 0; i < cycles; ++i)
      {
         rs = rs + i * i * i * i * i;
      }
      print(rs);
   }
};

EOSIO_ABI( calculate, (calcn) )