안녕하세요. 어미새입니다.
이더리움 백서를 쉽게 이해할 수 있도록 풀어서 설명하는 연재물을 작성하고 있습니다. 오늘 포스팅 내용은 비트코인의 스크립팅과 관련된 내용이며, 이번편을 마지막으로 비트코인에 대한 설명이 끝나고, 다음편 부터는 본격적인 이더리움에 대한 설명으로 넘어가게됩니다. 혹시 지난 포스팅을 읽지 못하셨던분은 먼저 아래의 포스팅을 읽어보시는것을 추천드립니다.
Remind
머클 트리는 이진트리의 일종으로 하나의 루트 노드의 집합이며, 블록의 용량을 효율적으로 활용할 수 있는 데이터 구조를 가지고 있습니다. 블록체인 기술을 이용한 응용 사례로는 네임 코드, 컬러드 코인, 메타코인 등 다양한 응용 사례가 있었습니다.
일반적으로 합의 프로토콜을 개발하기 위해서는 독립적인 네트워크를 구현하는 방식, 기존의 시스템인 비트코인과 연동되는 새로운 프로토콜을 만드는 방식으로 나누어볼수 있으며, 전자는 네임 코인과 같은 응용사례에서 상당히 성공적이었지만, 상태 변환과 네트워킹 코드를 직접 개발하고, 독립적인 블록체인을 구동 시켜야 하는 기술적인 어려움이 있으며, 후자의 방식 메타 프로토콜 방식으로, 자체 프로토콜을 지원하지 못하기 때문에 SPV 특징을 사용하지 못한다는 단점이 있으며 비트코인을 기반한 메타-프로토콜의 라이이트(light) 클라이언트 구현은 믿을만한 서버에 의지하는 형편입니다. 우리가 암호화폐를 만든 가장 중요한 목적은 제 3자의 신용기구의 필요성을 없애는것이었다는걸 되새겨본다면, 이것은 아주 분명하게도, 차선의 결과가 될뿐입니다.
스크립팅
비트코인 프로토콜은 별도의 확장 없이도 낮은 수준의 "스마트 계약"을 구현할 수 있습니다. 비트코인의 UTXO는 공개키로 획득할 수 있지만, 추가적으로 단순 스택-기반 프로그래밍 언어로 표현되는 더 복잡한 스크립트로도 획득할 수 있습니다. 공개키 소유권 메커니즘도 스크립트를 통해 실행되며, 스크립트는 타원곡선서명을 '입력'으로 받아 그 거래와 UTXO를 가진 주소에 대한 검증을 하게되며, 검증에 성공했을 경우 1을, 실패했을 경우 0을 출력하게됩니다. 즉 다양한 사용 사례에 대해 좀 더 복잡한 스크립트들을 만들 수 있다는 의미입니다.
예를들어, 주어진 세개의 개인 키 가운데 두 개로부터 서명을 받아야만 승인이 되도록 스크립트를 구성할 수 있으며, 이런 스크립트는 회사 계정, 보안 저축 계정, 상업 공탁 상황등에 유용하게 쓰일 수 있습니다. 또한 스크립트를 통해 어떤 조건, 즉 특정 계산 문제의 답에 대한 포상금을 지불하는 방식으로 쓰일 수 있습니다.
만약 비트코인에 상응하는 도기 코인을 나에게 보냈다는 SPV 증명을 제공한다면, 해당 비트코인의 UTXO를 보낸 사람의것으로 만들 수 있는 스크립트를 구현할 수 있습니다. 즉 근본적인 탈중앙화된 상호-암호화폐 교환을 가능하게할 수 있다는 의미입니다.
비트코인의 스크립트 언어는 한계점이 있다.
비트코인 스크립트의 한계점
튜링불완전성
비트코인 스크립트 언어로 할 수 있는 작업은 많지만, 모든 경우의 프로그래밍을 지원할 수 없습니다. 특히나 while이나 for와 같은 순환(loop) 명령 카테고리를 사용할 수 없으며, 순환 명령어를 없앤 이유는 거래 증명시 무한 루프에 빠지는것을 방지하기 위함입니다.
이론적으로 튜링 불완전성은 프로그래머가 극복할 수 있는 장애물이기는합니다. 그 이유는 어떤 순환 명령이든 여러 차례 if 구문을 사용함으로써 구현이 가능하기 때문입니다. 하지만 이러한 방법은 공간 비효율적인 프로그램이 되며, 타원곡선 서명 알고리즘을 실행할 경우 코드 안에 있는 곱셈을 모두 개별적으로 256번 반복하는 작업이 필요함으로 아주 비효율적인 프로그램이됩니다.
Value-blindness
UTXO 스크립트만으로 인출 액수를 세밀하게 통제할 방법이 없습니다. 신탁 계약의 강력한 실용 사례라 할 수 있는 헷지 계약으로 예를 들어보겠습니다. 만약 A와 B가 $1000의 금액만큼의 BTC를 공동 계좌에 입금하고, 30일 후 BTC의 가격이 상승하게될 경우 자동으로 A에게는 원금인 $1000의 금액에 해당하는 BTC를 돌려 받고, B에게는 이익금인 공동계좌의 나머지 잔금을 입금 받을 수 있는 그런 계약을 맺고 싶다고 가정해보겠습니다.
이러한 계약에는 1 BTC가 미국 달러로 얼마인지 정해줄 제 3자가 필요합니다. 하지만 이런 계약이 실현 가능하다면 지금 현존 하는 중앙 집권적인 금융 시스템 아래에서도 고도로 발전된 계약 형태라고 볼 수 있을 것입니다. 현재 비트코인의 UTXO는 인출액 전부가 송금되거나, 말거나 밖에 선택할 수 없으며, 즉 세부 작은 단위로 나눠질 가능성을 포함할 수 없다는 의미입니다.
앞선 헷지 계약의 거래를 실행할 유일한 방법은 UTXO의 액면가 단위를 아주 다양하게 양산하고 (예를 들어 1부터 30까지의 모든 자연수 k에 대해 2의 k승의 1 UTXO를 만듦) A가 B에게 이중에서 필요한 금액에 맞는 것을 선택해서 보내게 하는 방식과 같이 매우 비효율적인 편법을 사용하는 길 뿐입니다.
상태 표현의 한계점(다양한 상태를 표현할 수 없음)
UTXO가 표현할 수 있는 상태는 사용되었거나, 안되었거나 두가지 방법만 존재합니다. 이 두가지 상태 이외으ㅔ 다른 어떤 내부적 상태를 가지는 다중 계약이나 스크립트를 생성할 수 없으며, 이러한 환경은 분산 환전 거래나 이중 암호 실행 프로토콜과 같은 다중 계약을 어렵게 만듭니다. 즉, UTXO는 단순하고 1회적인 계약에만 이용될 수 있으며, 분산조직과 같은 더 복잡한 "상태적(stateful)" 계약에는 활용될 수 없으며, 나아가 메타 프로토콜을 적용하기 어렵게 만듭니다.
블록체인을 해독할 방법이 없다(Blockchain-blindness)
UTXO는 논스(Nonce), 타임스탬프, 이전 블록해시 같은 블록체인 자료를 해독하지 못합니다. 이 단점으로 인해 스크립트 언어 속에 잠재적으로 가치있을 무작위성이 빠지게됩니다. 그래서 도박이나 여러 다른 분야의 어플리케이션을 만들기 어려운 한계점이 있습니다.
정리하자면, 발전된 어플리케이션을 만드는 방법은 3가지 접근 방법이 있습니다. 첫번째는 독립적인 블록체인을 만드는 것이고 두번째는 비트코인에 이미 내재된 스크립트를 이용하는 것이며 세번째는 비트코인상에서 작동되는 메타-규약을 건설하는 것입니다. 독립적인 블록체인을 만들 경우 무한히 자유로운 프로그램을 만들 수 있겠지만 개발 기간, 초기 셋업 자원, 보안 등의 비용이 발생하며, 비트코인에 내재된 스크립트를 이용하면 실행이 간단하고 표준화된 장점이 있지만, 이용범위가 제한적입니다. 또한, 메타 규약을 쓰는 것은 간단하긴 하지만, 확정성의 결함을 감수해야하는 문제점이 있습니다.
이더리움을 통해 우리는 개발하기 쉽고, 더 강력한 라이트 클라이언트 기능을 가지면서 경제적인 개발 환경과 블록체인 보안을 공유할 수 있는 어플리케이션을 만들 수 있도록 지원하는 alternative framework를 건설하고자 합니다.
마무리
본격적인 이더리움에 대한 설명의 시작부에서 이더리움의 목적은 분산 어플리케이션 제작을 위한 대체 프로토콜을 만드는것이라고 명시되어있습니다. 오늘 학습한 백서의 내용에서는 비트코인의 스크립트의 한계점인, 튜링 불완전성, UTXO의 상태표현의 한계점, 블록체인을 해독할 수 없는 문제점 등을 설명하면서 비트코인의 스마트 계약의 한계점에 대한 문제점을 지적하였습니다. 그리고 이더리움에서는 이제 이러한 문제점을 어떻게 해결하여, 분산 어플리케이션 제작을 위한 대체 프로토콜을 개발할것인지에 대한 내용이 나올것으로 예상됩니다.
백서의 내용중 부연설명이 더 필요해보이는 단어들은 따로 취합하고 있습니다(예를 들어, 네임 코인, 컬러드 코인, 메타 코인, 사이드 체인, 튜링 불완전성 등) 이런 부분은 이더리움 백서 포스팅이 끝나는 시점에서, 개별 포스팅으로 진행할 예정입니다.
드디어 비트코인, 그리고 비트코인 응용 사례를 통해 왜 이더리움 개발이 필요했는지에 대한 서술이 끝났으며, 다음 시간부터는 본격적인 이더리움에 관한 설명으로 이어지게됩니다. 앞서 작성한 이더리움 백서 1~3편을 보지 않으셨던 분들은 꼭 정독해보시는것을 추천드립니다. (오랜시간이 소요되지 않습니다!)
혹시나 이더리움 백서를 먼저 읽고 싶으신분은 아래의 링크를 통해 이더리움 백서를 먼저 확인해보시는것도 좋을것 같습니다.
이상 긴 글 읽어주셔서 감사합니다!(보팅, 리스팀, 팔로워는 제게 큰 힘이됩니다!)
[참고문헌]
https://github.com/ethereum/wiki/wiki/White-Paper
[다음편 보기]