이더리움과 튜링 완전(비트코인과 이더리움의 차이)

GDSC Hongik Devtalk #2 - 이더리움과 튜링 완전

본 글은 GDSC Hongik Devtalk 2회차 이더리움과 튜링 완전 발표 내용을 다시 정리한 글입니다.

22년 10월 31일, 그러니깐 이 글을 쓰는 시점을 기준으로 9개월 전에 발표한 내용을 다시 정리하고 있는 것인데요, 이전에 발표한 내용이라도 블로그에 한 번이라도 남기는 것도 좋고, 추억이기도 하고, 오랜만에 1학년 때 생각나서 적습니다.

이렇게 쓰고 보니 벌써 1년 가까이 되어 가네요 저 발표를 한 지가. 시간이 참 빠르다는 생각이 듭니다.

발표를 다시 들어보니 새내기 시절이여서 그런지 정말 긴장한 티가 팍팍 나네요.

발표의 주제는 이더리움과 튜링 완전입니다. 그리고 ‘비트코인과 이더리움의 비교를 중심으로’ 라는 부제가 달려 있네요. 이더리움과 비트코인이 어떻게 다른지를 비교하는 내용입니다.

이 당시는 한창 블록체인 동아리 하이블(HIBL)을 운영하고 있을 시기였습니다. Solidity를 가르치는 교육 담당을 맡기도 했었고, Smart Contract를 연구하는 팀을 이끌던 시기였습니다. 그래서 이와 관련된 발표 주제를 선정했습니다.

튜링 완전이란?

영화 이미테이션 게임을 보신 분들은 엘런 튜링이라는 인물을 아실 겁니다. 영국의 수학자이자 컴퓨터 공학자로, 세계 2차 대전 당시 독일의 암호 체계 애니그마를 해독하기 위해 최초의 컴퓨터 격으로 여겨지는 ‘봄브’ 기계를 만들었습니다. 봄브, 콜로서스, ABC(Atanasoff–Berry Computer) 머신 등 최초의 컴퓨터라는 타이틀을 누가 가질 것인가에 대한 논쟁은 계속되고 있지만, 엘런 튜링의 봄브가 컴퓨터 역사의 결정적인 시발점 중 하나라는 것은 부정하기 어렵습니다.

튜링의 이름을 기려서, 컴퓨터 과학계에서 혁혁한 공을 세운 사람들에게 수여되는 ‘튜링상’도 존재합니다.

튜링 완전은 엘런 튜링이 고안한 개념으로, 어떤 프로그래밍 언어나 추상 기계가 튜링 머신과 동일한 계산 능력을 지닐 때 이를 튜링 완전하다고 합니다.

말로만 들어서는 복잡합니다. 일단 튜링 머신이 뭔지부터 알아야 하는데, 튜링 머신은 1936년 튜링이 제시한 계산하는 기계(Computing Machine, 즉 Computer)를 일반화하기 위한 개념입니다. 일종의 오토마타입니다.

튜링 머신은 다음 네 가지 구성 요소로 이루어집니다.

요소	설명
테이프	일정한 크기의 셀(Cell)로 나뉘어 있는 종이 테이프. 각 셀에는 기호가 기록되어 있으며, 길이는 무한히 늘어날 수 있다.
헤드	종이 테이프의 특정한 한 셀을 읽을 수 있는 헤드. 이동이 가능하다.
상태 기록기	현재 튜링 머신의 상태를 기록하고 있는 장치 개시 상태: 상태 기록기가 초기화된 상태 종료 상태: 수행이 종료된 상태
행동표	특정 상태에서 특정 기호를 읽었을 때 해야 할 행동을 지시한다. 기호를 지우거나 쓴다. 헤드를 오른쪽, 왼쪽으로 한 칸 움직이거나 그 자리에서 머문다. 상태를 변경하거나 유지한다. 이때 단, 튜링 머신에서 종이 테이프에 기록할 수 있는 기호 및 상태, 행동표의 개수는 모두 유한하고 각각 구분된다.

오늘날의 컴퓨터 속 CPU, 메모리 등의 초기 개념이 보이는 듯 합니다.

튜링 완전은 튜링 머신과 동일한 계산 능력을 지닐 때 튜링 완전하다고 했습니다. 이 말은 즉 위 튜링 머신이 계산 가능한 것들을 어떤 기계가 똑같이 계산할 수 있는 능력을 가질 때 이를 튜링 완전하다고 합니다.

정확히는 ‘튜링 동치’일 때 튜링 완전하다고 합니다. 개념적으로 A와 튜링 머신이 동치이면 둘을 구분할 필요 없이 동치로 취급해도 된다는 뜻입니다.

보편 튜링 머신, 폰 노이만 컴퓨터, 다중 테이프 튜링 머신 등이 튜링 동치라고 합니다. 이때 우리가 현재 사용하고 있는 컴퓨터 아키텍처의 근간이 바로 폰 노이만 컴퓨터입니다.

튜링 동치에 대한 정확한 정의는 두 컴퓨터 P와 Q가 서로를 흉내낼 수 있으면 튜링 동치라고 합니다.

발표 자료 수정

발표 자료를 다시 보면서, 문제가 될 수 있는 오류를 정정하고자 합니다. 발표 자료에 튜링 머신에 대한 정의를 아래와 같이 정의했습니다.

for $\omega$ as out of $L$, let std TM $P$ and non-std TM $Q$ s.t. $\forall \omega \in L(P) \Longleftrightarrow \forall \omega \in L(Q)$, then $P$ and $Q$ are turing equivalent.

Also for $\forall \omega$, let $T_1$, $T_2$ s.t. $T_{1}(\omega)=T_{2}(\omega)$, then $T_1$ and $T_2$ are turing equivalent.

위 정의는 어딘가에서 인용한 것이 아닌, 제가 임의로 작성한 정의입니다. 그래서 오류의 소지가 있을 수 있겠다 싶었는데, 역시 문제가 있습니다.

위 수식은 다음 의미를 갖습니다:

언어 L의 모든 출력 ω에 대해 표준 튜링 머신 P와 비표준 튜링 머신 Q가 있다고 가정합니다. 이때 P와 Q에 대해 P와 Q가 실행한 L의 출력이 동치라면 ,P와 Q는 동치입니다.
또한 모든 ω에 대해 $T_1(ω) = T_2(ω)$인 튜링 머신 $T_1$과 $T_2$가 있다고 가정하면, $T_1$과 $T_2$는 튜링 동등성입니다.

그러나 여기에 해석적인 오해의 소지 및 오류가 있습니다.

위에서는 표준 튜링 머신 $P$와 비표준 튜링 머신 $Q$가 언어 $L$의 같은 입력에 대해 같은 출력을 생성할 경우 동치라고 가정합니다. 그러나 실제로 튜링 동등성은 동일한 출력을 생성하는 것이 아니라 한 기계가 다른 기계를 시뮬레이션할 수 있는 능력에 관한 것입니다.

동치라는 말은 한 기계가 다른 기계를 시뮬레이션한다는 말에 가깝기는 하나 정확하지는 않습니다. 때문에 위 정의는 오해의 소지가 있는 것 같습니다(화살표가 문제입니다).

아래 정의가 조금 더 정확합니다.

Two Turing machines $M_1$ and $M_2$ are said to be Turing equivalent if each one can simulate the other. Formally we say:

$\forall \omega$, let there be Turing machines $T_1$ and $T_2$ such that $T_1$ can simulate $M_1$ and $T_2$ can simulate $M_2$. If for any input $\omega$, $T_{1}(\omega)=M_{1}(\omega)$ and $T_{2}(\omega) =M_{2}(\omega)$, then $M_1$ and $M_2$ are Turing equivalent.

튜링 완전과 프로그래밍 언어

어떤 언어가 튜링 완전임을 보이려면, 다른 튜링 머신과 동치인 시스템과 동치 임을 보이면 됩니다.

즉 A라는 언어가 튜링 동치이면, B가 튜링 완전임을 보이기 위해서는 A와 튜링 동치인 것만 보이면 B가 튜링 완전임을 보일 수 있습니다. 똑같이 C가 B와 튜링 동치임을 보이면 C 역시 튜링 완전입니다.

대표적인 튜링 완전한 언어는 다음 두 가지입니다.

절차적 프로그래밍 언어

다음 두 조건을 만족한다면 튜링 완전함이 증명된다고 합니다.

조건 분기문이 있을 것.
1. 즉 if(…)else(…), then goto(…) 형태의 조건 분기문이 있을 것
2. for, while 문의 loop 문도 조건 분기문으로 바꿀 수 있음
임의 위치의 메모리 값을 바꿀 수 있다.

거의 대부분의 프로그래밍 언어들은 전부 이 성질을 만족합니다(조건문이 없는 프로그래밍 언어는 없으니깐요). C, C++, Python, Rust, Solidity(이후에 나올, Smart Contract 작성을 위한 EVM 기반 OOP 언어입니다) 등이 이 여기에 속합니다.

람다 대수(Lambda calculus)

한편 람다 모델 역시 튜링 동치입니다. 람다 대수는 알론조 처치가 제안한 계산 모델로, 람다 대수로 할 수 있는 모든 계산은 튜링 머신으로도 가능하고, 그 역도 성립함이 증명되었습니다(Church, 1936 & Church, 1940).

HTML과 CSS는 프로그래밍 언어일까?

여기서 재밌는 질문 하나가 나오는데, 과연 HTML과 CSS는 프로그래밍 언어일까라는 질문입니다.

답은 무엇일까요? 유명한 답이지만 HTML은 프로그래밍 언어가 아닙니다.

“HTML은 프로그래밍 언어가 아니다”라는 말이 여기서 나왔습니다. HTML은 조건 분기가 없고, 또한 메모리를 임의로 바꾸는 것도 불가능합니다. 두 조건을 모두 충족하지 못하기에 튜링 불안전합니다. 그렇기에 이런 말이 나오게 된 것입니다.

사실 자료 조사를 하다가, 더 재밌는 사실 하나를 발견했는데요, 바로 HTML과 CSS 각각은 튜링 불안전하지만, HTML5와 CSS3의 조합은 과연 어떨 것인가에 대한 질문입니다.

HTML5 + CSS3의 조합은 프로그래밍 언어일까요?

굉장히 놀랍게도, 답은 O입니다. 여기서 프로그래밍 언어란 튜링 동치인 언어라고 표현한다면, 답은 O입니다.

HTML5와 CSS3의 조합은 초등 셀룰러 오토마타인 110 세포 오토마타(110 Cellular Automata)를 흉내낼 수 있다고 합니다. 이때 110 Cellular Automata가 튜링 완전하기 때문에, 이와 동치인 HTML5+CSS3 역시 튜링 완전하다고 합니다.

사실 아직도 의심이 가는 대목이긴 한데, 저도 맞는 지는 모르겠습니다. 레퍼런스를 링크할 테니 한 번 보시고 진위 여부를 직접 파악하는 것도 좋을 것 같습니다.

Brian Krent. “Eli Fox-Epstein’s Rule 110 HTML & CSS3 Machine.” Youtube, 14 Feb. 2012, youtu.be/Ak_sWZyHi3E.
Lara Schenck. “Is CSS Turing Complete?” Lara Schenck, 25 May 2019, notlaura.com/is-css-turing-complete/.

이더리움과 튜링 완전

이더리움(Ethereum)

사실 튜링 완전은 배경 지식일 뿐, 본 발표의 핵심은 이더리움과 비트코인의 비교입니다.

이더리움은 무엇일까요? 이더리움은 블록체인 기술을 바탕으로 한 분산 컴퓨팅 플랫폼입니다. 분산 원장 기술을 기반으로 한다는 것은 비트코인과 동일합니다. 그러나 이더리움은 분산 원장 기술에 한 발 더 나아가 분산 컴퓨팅 기술을 도입합니다.

분산 원장과 분산 컴퓨팅 기술을 이용해서, 스마트 컨트랙트(Smart Contract, SC)의 개념이 도입되게 됩니다.

또한 비트코인과 마찬가지로, 이더리움은 플랫폼 내 자체 통화인 ‘이더(Ether)’를 갖고 암호화폐로의 역할을 수행할 수도 있습니다.

스마트 컨트랙트(Smart Contract)

스마트 컨트랙트는 이더리움의 핵심이 되는 기능으로써, 상호 계약자간 거래(Transaction, TX)를 제 3의 중개자 혹은 신용 기관 없이 진행할 수 있도록 하는 기술을 의미합니다.

블록체인 네트워크의 강력한 무결성, 신뢰성에 ‘프로그래밍 가능한 계약 작성’이라는 무기를 더해 스마트 컨트랙트를 완성시킵니다.

예를 들어 구매자와 판매자가 있을 때, 구매자는 암호화폐 이더를 스마트 컨트랙트에 지불하고, 판매자는 제품 혹은 서비스를 스마트 컨트랙트에 제공하고 나면, 중개자가 개입할 필요 없이 스마트 컨트랙트 내에서 거래를 완수할 수 있는 개념입니다.

겉보기에는 대단한 기술인가 싶지만, 사실 많은 잠재력을 갖고 있습니다. 현재 이루어지고 있는 대부분의 거래들은 제 3의 중개인을 필요로 합니다. 자동화된 프로그램에 의해 제어된다고 하더라도, 이 프로그램을 제어하는 제 3의 기관은 어쨌든 존재합니다. 관리자가 데이터베이스 서버에서 실수로 drop table 같은 명령어를 실행했다고 해봅시다. (안전 장치가 없다는 가정 하에)곧바로 심각한 문제가 발생할 것입니다. 또한 의도적으로 데이터베이스를 조작할 수도 있겠죠.

블록체인은 기본적으로 불변성을 갖고 있기 때문에, 그리고 SC는 사람의 힘으로 개입되어 움직이지 않기 때문에 이러한 걱정에서 어느 정도 자유로울 수 있습니다.

솔리디티(Solidity)

이렇게 강력한 스마트 컨트랙트는 솔리디티라는, 스마트 컨트랙트 작성을 위해 태어난 고수준 객체 지향 언어로 작성됩니다.

사실 Rust, Go 등 스마트 컨트랙트를 작성할 수 있는 언어는 무수히 많습니다. 원한다면 C++ 등으로도 작성할 수 있습니다. 실제로 Rust, Go 언어로도 스마트 컨트랙트가 많이 작성됩니다.

다만 이더리움 플랫폼 위에서 스마트 컨트랙트를 실행하기 위해선, EVM(Ethereum Virtual Machine)이라는 가상 머신 위에서 컨트랙트가 실행되어야 하는데, EVM이 공식적으로 지원하는 언어는 솔리디티입니다.

// SPDX-License-Identifier: MIT
pragma solidity >= 0.7.0 < 0.9.0;

/// Solidity로 작성한 Hello World 프로그램
/// string “Hello World!”를 블록에 기록하고, 문자열을 반환. 
/// 블록에 기록된 문자열은 영원하다.
contract HelloWorld {
	event saveData(string indexed data);
	function sayHelloWorld() public returns(string memory) {
		emit saveData("Hello World!");
		return "Hello World";
	}
}

이더리움 VS 비트코인

이더리움과 비트코인은 무엇이 다를까요?

비트코인은 제한적으로만 프로그래밍이 가능합니다(사토시 나카모토, 2008). 그러나 for, while 문 등의 loop문, 그리고 일부 조건 분기문을 구현하지 못해서, 튜링 불완전합니다.

비트코인은 Dumb Network입니다(안드레아스 안토노폴로스, 2018).

그러나 이더리움은 Solidity, 혹은 Go나 Rust 등의 프로그래밍 언어로 튜링 완전한 프로그래밍이 가능합니다. 이에 따라 블록체인 네트워크 상에서 연산 자원을 공유할 수 있는 혁명이 가능해집니다. 일종의 탈중앙화된 클라우드 컴퓨팅 시스템입니다.

이더리움은 Smart Network라고 표현할 수 있겠습니다.

이더리움의 한계

그런데, 이더리움이 튜링 완전하다고 하는 것에 대해, 약간의 조건이 붙어있기는 합니다. 엄밀하게 따졌을 때 튜링 완전하지 않을 수도 있습니다.

이더리움의 튜링 불완전성

이더리움은 분산 컴퓨팅 시스템으로, 이더리움 노드 생태계에 기여하는 전세계 수많은 기계들이 연산 자원을 제공하여 운영됩니다.

그런데 이더리움은 튜링 완전하기에, 무한 루프에 걸릴 수도 있다는 위험이 존재합니다. 실수로 생긴 무한 루프도 위험하지만, 일부러 네트워크 전체의 연산을 과부하시키려는 목적으로 적대적인 무한 루프 공격을 수행할 수도 있습니다.

이더리움은 악의적인 공격자가 이더리움 네트워크를 마비시킬 목적으로, 특정한 무한 루프를 형성하는 스마트 컨트랙트를 작성하는 것을 방지하기 위해 가스비를 도입했습니다.

그래서 만약에 무한 루프가 생성되더라도, 가스비가 모두 소모된다면 더이상 의미없는 무한 루프 연산에 네트워크의 자원을 소비하지 않을 수 있습니다.

이것이 왜 중요하냐면, 일반 컴퓨터의 경우는 무한 루프가 생성되었을 경우 그냥 프로그램을 종료하거나 컴퓨터를 끄면 되지만, 블록체인 네트워크는 그게 안 되기 때문입니다. 전세계 노드로 퍼져있는 블록체인 네트워크를 한 번에 끌 수 없고, 한 번 실행이 완료된 트랜잭션을 되돌리는 것 역시 불가능합니다.

무한 루프를 사전에 탐지할 수 있는 방법은 존재하지 않습니다. 괴델의 불완전성 정리와 튜링 정리에 의하면, 사전에 무한 루프를 방지할 수 있는 일반화된 방법따윈 존재하지 않는다는 것이 증명되어 있습니다. 결국 이를 방지하기 위해서는 다른 방법을 사용해야 합니다. 그것이 가스비이죠.

이더리움 네트워크 등 블록체인 네트워크에서는 모든 행동에 가격이 붙습니다. 일종의 수수료입니다. 모든 거래에 가스비를 수수료로 제공해야 합니다.

어떤 코드가 어떤 동작과 함수를 실행하는 지에 따라서 가스비가 달라집니다. 모든 계산에는 가격표가 붙어있습니다. 예를 들어 어떤 문자열을 해시화하는 keccak256 함수의 경우, 문자열의 byte 당 25 gwei가 소모된다(gwei는 가스비의 기본 단위이고, 숫자는 그냥 임의의 값입니다!) 이런 식이죠.

실제로 만약에 어떤 트랜잭션을 수행하려고 하는데, 트랜잭션을 수행하기 위해서 필요한 가스의 양보다 자신이 갖고 있는 잔존 이더의 양이 적다면 해당 트랜잭션은 실패하고 맙니다. 물론 이때 트랜잭션은 원자성을 갖고 있어서, 실패한 그 지점으로 거래의 내용은 되돌아간다는 특징은 있습니다. (물론 어떤 긴 트랜잭션 과정에서 중간중간 블록체인에 상태가 저장되는 구조로 프로그램을 설계했다면, 트랜잭션 실패 시 저장된 상태를 바꾸진 못 하므로, 그에 따른 손해는 감수해야 합니다. 그러니 최대한 어떤 행동이 원자성을 갖게끔 스마트 컨트랙트를 설계하는 것이 중요합니다)

그렇기 때문에 이더리움이 완벽한 튜링 완전이라고 말하기는 어렵습니다. 그렇기 때문에, 이더리움을 ‘반튜링완전’이라고 부르기도 합니다. 거의 튜링 완전에 근접해 있으나 실제 완벽한 튜링 완전이라 보기에는 무리가 있다는 뜻이죠.

정지 문제

이 외에도 튜링 머신이 갖고 있는 한계 역시 그대로 갖고 있습니다. 대표적으로 ‘정지 문제’인데, 튜링 머신은 모든 문제를 해결해주지 않습니다. 튜링 정리에 의하면, 튜링 머신이 어떤 문제를 풀기 위해 소요되어야 할 시간을 미리 알 수 있는 일반화된 방법은 없습니다. 때문에 이 문제가 적절한 유한 시간 내에 풀리게 될 지, 혹은 거의 무한에 가까운 시간이 걸리는 지를 미리 알 수 있는 일반화된 방법이 존재하지 않습니다.

같은 이유로 어떤 문제를 풀기 위해 이더리움 네트워크의 자원을 얼마나 사용해야 하는지를 알 수 없습니다. 그래서 이더리움은 자원의 가용량을 유지하기 위해 가스비를 도입했습니다.

이 외에도 여러 문제들은 튜링 머신으로 해결이 불가능하다는 것이 수학적으로 증명되어 있으며, 현대에도 이더리움을 포함한 모든 튜링 머신들(일반적인 디지털 컴퓨터부터 양자 컴퓨터에 이르기까지)의 한계로 남아 있습니다.

해킹 가능성

블록체인 네트워크 자체는 해킹이 거의 불가능합니다. 전세계 모든 노드들의 과반수를 해킹하는 51% 공격이 성공하지 않는 한, 블록체인 네트워크의 해킹이 성공할 일은 거의 없거나, 성공한다 해도 그로 인해 얻는 이익보다 비용이 더 클 것입니다.

그러나 스마트 컨트랙트는 해킹이 가능합니다. 이 역시 인간이 작성하는(코딩하는) 계약(프로그램)이므로, 계약 자체에 허점이 존재한다면 이를 노리는 공격도 가능합니다.

특히, 튜링 불완전한 비트코인과 다르게 이더리움은 for-loop 등이 있어 튜링 완전하기에, 재진입 공격(Re-entry attack)과 같은 다양한 공격 기법들에 더 취약합니다.

특히 스마트 컨트랙트를 작성할 때 가장 흔하게 일어나는 실수가 오버플로우/언더플로우로 인한 실수입니다.

contract LevelRestriction is ERC721Connector {
	mapping(address => uint8) private userLevels;

	function increaseUserLevel(
      address user,
      uint8 addLevel
  	) public onlyOwner validAddress(user) {
      userLevels[user] += addLevel;
  	}

	function decreaseUserLevel(
	    address user,
	    uint8 subLevel
	) public onlyOwner {
	    userLevels[user] -= subLevel;
	}
}

위 함수는 치명적인 문제점을 갖고 있습니다. 무엇인지 보이시나요?

Solidity를 배우셨다면, 눈치챘을 수도 있습니다(눈치 채셔야 합니다..!). 문제가 되는 부분은 아래 부분입니다.

userLevels[user] += addLevel;
userLevels[user] -= subLevel;

일반적으로 문제가 없어보이는 이 부분이 왜 문제가 될까요?

만약에 uint256 타입의 userLevels[user]의 현재값이 0이라고 가정해봅시다. 그런데 여기서 1 이상의 subLevel을 빼면 어떻게 될까요? 언더플로우 문제로, userLevels에는 원래 의도했던 바와 전혀 다른 결과를 저장하게 될 것입니다.

반대로 현재 값이 uint8의 최대값인 255라고 가정해봅시다. 여기서 1 이상의 값을 더하는 순간 오버플로우가 일어나서 전혀 다른 값이 저장되고 말 것입니다. 이처럼 솔리디티에서 오버플로우, 언더플로우 문제는 보안적 허점을 발생시키는, 정말 자주 일어나는 실수입니다.

참고로 하나 더 있는데요, user account가 유효한 지도 체크해야 합니다. 이처럼 솔리디티 프로그래밍 시 조심해야 할, 자주 발생하는 실수들이 많다고 강조하기 위해 이 부분도 일부러 제외했습니다.

그래서 코드를 리팩토링하면 아래와 같이 됩니다.

using SafeMath for uint256;

function increaseUserLevel(
    address user,
    uint256 addLevel
) public onlyOwner validAddress(user) {
    userLevels[user] = userLevels[user].add(addLevel);
}

function decreaseUserLevel(
    address user,
    uint256 subLevel
) public onlyOwner validAddress(user) { 
		// validAddress는 주소 유효성을 검사하는 modifier
    userLevels[user] = userLevels[user].sub(subLevel);
}

SafeMath는 Solidity에서 안전한 연산을 돕기 위해 만들어진 라이브러리입니다. 이 함수의 내부적으로 add, sub 함수는 모두 오버플로우/언더플로우 등을 검출하고 에러를 던질 수 있도록 설계가 되어 있습니다.

다행인 점은, 솔리디티 0.8.0 버전부터는 이러한 실수를 방지하기 위해 언어 자체적으로 오버플로우/언더플로우가 발생할 시 에러를 던집니다. 따라서 굳이 SafeMath 라이브러리를 사용하지 않아도 됩니다.

스마트 컨트랙트로 가능한 것들

스마트 컨트랙트로 가능한 것들은 정말 많습니다.

9개월 전 발표에서는 부동산, 보험 등에서 제 3의 신용 기관 없이도 신뢰성 있는 거래를 체결할 수 있는 서비스를 예시로 들었습니다(김승래, 2018 및 오서영, 이창훈, 2017). 그 외에도 이더리움의 창시자 비탈릭 뷰테린은 그의 백서에서 스마트 멀티시그 공탁 계좌, 탈중앙화된 데이터 피드, 클라우드 컴퓨팅, 예금융 전자 지갑, 금융 파생 상품, 분산형 파일 저장소, 신원 조회 및 평판 시스템, 토큰 시스템 등을 예시로 들었습니다.

과거이나 지금이나, 블록체인은 엔드 유저로 하여금, 블록체인 서비스를 이용하고 있구나라는 티가 안 나는 게 가장 좋다는 생각이 듭니다. 블록체인은 결국 백엔드 단에서 서비스의 신뢰성을 확보하고 개선하는 것이지, 엔드 유저한테 블록체인 서비스를 이용하기에 추가적인 단계를 거쳐야 하는 불편한 UX를 제공해서는 안 된다고 생각합니다.

이것이 가능하다면 점차 블록체인이 IT 세계에서 차지하는 비율은 늘어갈 것이라고 생각을 합니다. 반대로, 사실 NFT 등 블록체인을 전면에 내세운, 블록체인에 내재적 가치를 담는 서비스가 과연 성공할 수 있을까 의문이 드는 것도 사실입니다.

제가 주목하고 있는 것은 Web3.0입니다. 현재의 웹은 Web2.0 시대라고 불립니다. 정적인 웹페이지만을 제공했던 Web1.0과 다르게, Web2.0 시대가 열리면서 클라이언트와 서버가 동적으로 연결되고, 엔드 유저들이 더 다양하고 다이나믹한 웹 사용 경험을 갖게 되는 시대가 열렸습니다.

웹3에서는 블록체인 기술과 결합되어, 정보라는 자산이 중앙화된 클라우드 서버에 저장되지 않고, 분산되어 있고 매우 높은 가용성을 갖는, 상호 운용이 가능한 네트워크에 저장될 것을 기대할 수 있습니다.

글을 마치며

번외로, 사실 최근에 재밌는 일도 하나 있었습니다. 올해 2월 즈음에, 블록체인 네트워크를 기반으로 한 스마트 모빌리티(자동차) 네트워크 시스템에 대한 논문 몇 개를 간단히 읽고 리뷰한 적이 있습니다. 그런데 올해 6월에 알고 보니깐, 그 주제가 바로 우리 학교의 한 연구실의 연구 과제였습니다. 연구실 모집 공고가 떠서 가서 봤는데, Web3.0을 주제로 한 연구실이었고, 과거 연구 과제 중에 똑같은 주제의 연구 과제가 있었습니다.

재밌는 점은 해당 연구실의 교수님은 과거 수업에서 ‘블록체인은 사기다’라는 말을 하신 적이 있습니다. 그런데 더 이전에 블록체인 관련된 연구 과제를 진행하셨고, 또 그 말을 하고서 금학기에 Web3.0을 주제로 또 학부 연구생을 모집하시니깐, 흥미롭기는 합니다. 어떤 뜻을 갖고 계실까요?

매우 궁금하기는 했는데, 저는 군대를 가기까지 한 학기만 남은 상태이기에 결국 연구실 지원은 안 했습니다.

그래서 오랜만에 옛날 생각이 나서 과거 발표한 내용을 다시 리뷰했습니다.

블록체인은 사기일까요? 아니면 혁명적인 기술일까요?

사실, 개인적으로는 둘 다 아니라고 생각합니다. 저는 예나 지금이나 블록체인이 단 한 번도 미래 산업을 이끌어갈 산업 혁명의 주역이라고 생각해본 적이 없습니다. 그러나 블록체인이라는 기술이 가진 잠재적 가치를 저평가하지도 않습니다.

블록체인 기술은 그냥 하나의 기술일 뿐입니다. 저는 블록체인 기술이 유망한 기술이라고 생각합니다. 그러나 IT 역사 속에서 블록체인보다 더 유망하고 좋은 기술들은 많습니다. 차라리 http 통신 기술이 세상을 바꾸는데 더 일조했다는 생각도 듭니다. 그러나 우리가 http가 위대한 기술이고 매우 높은 잠재적 가치를 지녔다고, 열광을 하지는 않습니다.

블록체인 역시 그냥 하나의 유용한 기술일 뿐입니다. 블록체인 기술이 사람들에게 좋은 가치를 가져다주면 사용하면 되는 것이고, 이것을 사용하는데 있어 손익보다 비용이 더 크다면, 블록체인이 주는 유용함을 불편함이 앞지른다면 사용하지 않으면 될 뿐입니다.

사기도 아니고, 열광을 할 기술도 아니라고 생각합니다. 미래에는 어떻게 될 지는 모르겠습니다. 그저 현재의 저의 생각은 그렇습니다. 지금 당장 집중되고 있는, 돈의 흐름이 집중되고 있고, 정보가 모이며, 지식이 가장 활발히 성장하고 있는 분야는 인공지능과 클라우드 기술인 건 확실합니다.

블록체인이 이들만큼 영향력을 펼친 적은 지금껏 한 번도 없고, 앞으로도 인공지능과 클라우드만큼의 영향력을 갖기란 쉽지 않을 것입니다. 그래도 현재도 활발히 블록체인 기술은 발전하고 있고, 여전히 돈의 흐름이 모이고 있으며, 지식과 정보의 교류는 활발히 일어나고 있습니다. 여전히 매력적인 기술이고, 시선을 돌릴 이유는 없습니다. 꾸준히 주목하면서, 산업과 기술의 변화에 귀를 열어둘 이유는 충분합니다.

저도 지금 당장은 블록체인 동아리 운영을 내려놓았고, 다음 기수의 사람들에게 역할을 물려주었지만, 여전히 시선 한 쪽 끝은 걸쳐두고 있습니다. 이 기술이 앞으로 어떻게 될 지는 모르겠습니다. 그러나 가능성은 열어둘 뿐입니다.

Reference

Church (1936). An unsolvable problem in elementary number theory. American Journal of Mathematics 58:345—363.
Church (1940). A formulation of the simple theory of types. Journal of Symbolic Logic 5(2):56—68.
Brian Krent. “Eli Fox-Epstein’s Rule 110 HTML & CSS3 Machine.” Youtube, 14 Feb. 2012, youtu.be/Ak_sWZyHi3E.
Lara Schenck. “Is CSS Turing Complete?” Lara Schenck, 25 May 2019, notlaura.com/is-css-turing-complete/.
Nakamoto, Satoshi. "Bitcoin: A peer-to-peer electronic cash system." Decentralized Business Review (2008): 21260.
안드레아스 안토노풀로스. 비트코인, 그 시작과 미래. 범어디자인연구소 옮김, 제 1판., 프로제, (2018): 120-126
김승래 "부동산거래의 블록체인에 의한 스마트계약 체계" 부동산법학 22.3 pp.93-124 (2018) : 93.
오서영, and 이창훈. "부동산 시장의 신뢰성 향상을 위한 블록체인 응용 기술." 한국전자거래학회지 22.1 (2017): 51-64.
Buterin, Vitalik. "A next-generation smart contract and decentralized application platform." white paper 3.37 (2014): 2-1.

이더리움과 튜링 완전(비트코인과 이더리움의 차이) - GDSC Devtalk 발표 셀프 리뷰