위키원
"스마트 계약"의 두 판 사이의 차이
잔글 (→참고자료) |
잔글 |
||
| 47번째 줄: | 47번째 줄: | ||
제품의 유통 추적이 필요한 분야인 전 세계 식품 유통에 관여하는 생산자, 공급자, 운영자, 배급업체, 유통업체, 규제당국, 소비자 등이 모두 블록체인 상에서 식품 오염 이력을 확인하고 이에 따라 대금을 지불 가능하다. IBM은 블록체인 기반 식품 산지조회 서비스 푸드트러스트를 운영 중이다. 식품 산지조회 서비스를 운영하게 되면서 오염된 식품이 발견될 경우, 어떤 농장에서 생산됐는지 확인하는 데 6일 이상 걸려 모든 식품을 폐기해야 했는데 블록체인 기술을 적용해 2.2초로 단축됐다고 설명했다. 삼성SDS의 경우, 2017년 36개 민·관·연과 함께 해운물류 블록체인 컨소시엄을 구성해 7개월간 기술 검증을 진행했었다. 배를 이용해 물건 하나를 다른 나라로 보내는 일이 생각보다 복잡해서 상대방을 속이는 부당행위가 일어나도 이를 걸러내기 쉽지 않은 구조이기 때문에 해운물류 분야 기업들은 '신뢰'의 기술이라는 블록체인에 관심이 가질 수 밖에 없었던 것이다. 기존에는 200개 이상 문서가 수작업으로 오가야 했는데 이제 문서를 한 번에 동시 공유할 수 있도록 했다. 5~6일 걸리던 작업이 실시간으로 해결돼 많은 낭비가 사라졌다고 한다. | 제품의 유통 추적이 필요한 분야인 전 세계 식품 유통에 관여하는 생산자, 공급자, 운영자, 배급업체, 유통업체, 규제당국, 소비자 등이 모두 블록체인 상에서 식품 오염 이력을 확인하고 이에 따라 대금을 지불 가능하다. IBM은 블록체인 기반 식품 산지조회 서비스 푸드트러스트를 운영 중이다. 식품 산지조회 서비스를 운영하게 되면서 오염된 식품이 발견될 경우, 어떤 농장에서 생산됐는지 확인하는 데 6일 이상 걸려 모든 식품을 폐기해야 했는데 블록체인 기술을 적용해 2.2초로 단축됐다고 설명했다. 삼성SDS의 경우, 2017년 36개 민·관·연과 함께 해운물류 블록체인 컨소시엄을 구성해 7개월간 기술 검증을 진행했었다. 배를 이용해 물건 하나를 다른 나라로 보내는 일이 생각보다 복잡해서 상대방을 속이는 부당행위가 일어나도 이를 걸러내기 쉽지 않은 구조이기 때문에 해운물류 분야 기업들은 '신뢰'의 기술이라는 블록체인에 관심이 가질 수 밖에 없었던 것이다. 기존에는 200개 이상 문서가 수작업으로 오가야 했는데 이제 문서를 한 번에 동시 공유할 수 있도록 했다. 5~6일 걸리던 작업이 실시간으로 해결돼 많은 낭비가 사라졌다고 한다. | ||
| − | ===이더리움 | + | ===이더리움 스마트 계약의 한계점=== |
* 특정 기능, 특히 상태값을 변경하는 작업에 수수료<ref>gas라고 부른다.</ref>를 필요로 한다. 결과적으로 무료로 사용할 수 있는 서비스를 구현하기가 힘들다. [[루니버스]] 같은 이더리움을 기반으로 하는 일부 2차 플랫폼은 운영업체에서 참여 서비스 업체들의 수수료를 정책적으로 대납해준다고 한다. | * 특정 기능, 특히 상태값을 변경하는 작업에 수수료<ref>gas라고 부른다.</ref>를 필요로 한다. 결과적으로 무료로 사용할 수 있는 서비스를 구현하기가 힘들다. [[루니버스]] 같은 이더리움을 기반으로 하는 일부 2차 플랫폼은 운영업체에서 참여 서비스 업체들의 수수료를 정책적으로 대납해준다고 한다. | ||
* 다른 언어로 작성된 프로그램과 달리 스마트 계약 코드는 타이머나 이벤트 등을 통해서 실행되지 못한다. 예를 들어서 특정 시간에 특정 주소로 자동으로 송금하거나 하는 프로세스 등은 구현할 수 없다. 이유는 스마트 계약은 자기 자신의 개인키(Private Key)가 없기 때문에 스스로 어떤 트랜잭션을 발생시킬 수가 없기 때문이다. | * 다른 언어로 작성된 프로그램과 달리 스마트 계약 코드는 타이머나 이벤트 등을 통해서 실행되지 못한다. 예를 들어서 특정 시간에 특정 주소로 자동으로 송금하거나 하는 프로세스 등은 구현할 수 없다. 이유는 스마트 계약은 자기 자신의 개인키(Private Key)가 없기 때문에 스스로 어떤 트랜잭션을 발생시킬 수가 없기 때문이다. | ||
| 59번째 줄: | 59번째 줄: | ||
* 현재 이더리움 공식 인터페이스 라이브러리에서 지원하는 기존 언어는 자바(Java), 자바스크립트(Javascript), PHP, 파이썬(Python) 등이다. | * 현재 이더리움 공식 인터페이스 라이브러리에서 지원하는 기존 언어는 자바(Java), 자바스크립트(Javascript), PHP, 파이썬(Python) 등이다. | ||
* 스마트 계약과 이더리움 공식 인터페이스 라이브러리<ref>통칭 web3라고 부르지만 지원하는 언어별로 약간씩 명칭이 다르다. 예를 들어 자바는 Web3J, 자바스크립트는 Web3.js, 파이썬은 Web3py라고 되어있다.</ref> 사이에도 아직 제약 사항이 남아 있다. 예를 들어 solidity 언어의 struct 타입의 데이터는 인터페이스 라이브러리를 통해서 주고 받을 수 없다. 아예 solidity 언어의 컴파일러에서 에러 처리<ref>experimental ABI encoder라고 하는 실험적인 컴파일 지시자를 사용하면 가능하지만 권장되지는 않는다.</ref>되고 있다. | * 스마트 계약과 이더리움 공식 인터페이스 라이브러리<ref>통칭 web3라고 부르지만 지원하는 언어별로 약간씩 명칭이 다르다. 예를 들어 자바는 Web3J, 자바스크립트는 Web3.js, 파이썬은 Web3py라고 되어있다.</ref> 사이에도 아직 제약 사항이 남아 있다. 예를 들어 solidity 언어의 struct 타입의 데이터는 인터페이스 라이브러리를 통해서 주고 받을 수 없다. 아예 solidity 언어의 컴파일러에서 에러 처리<ref>experimental ABI encoder라고 하는 실험적인 컴파일 지시자를 사용하면 가능하지만 권장되지는 않는다.</ref>되고 있다. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==비트코인캐시 스크립트 연산 부호== | ==비트코인캐시 스크립트 연산 부호== | ||
2019년 3월 10일 (일) 16:05 판
스마트 계약 또는 스마트 컨트랙트(smart contract)는 디지털로 작성된 계약서이다. 계약 당사자가 사전에 협의한 내용을 미리 프로그래밍하여 전자 계약서 문서 안에 넣어두고, 이 계약 조건이 모두 충족되면 자동으로 계약 내용이 실행되도록 하는 시스템이다. 스마트 계약은 중간에 제3의 보증기관을 끼우지 않고도 개인간(P2P)에 원하는 계약을 체결할 수 있도록 해주는 전자계약 기능이기도 하다. 2013년 당시 19세의 천재 프로그래머였던 비탈릭 부테린(Vitalik Buterin)은 스마트 계약 플랫폼인 이더리움(ethereum)을 개발할 것을 제안[1]하고, 2015년 7월 30일 이더리움 개발에 성공하여 실제 서비스를 시작했다. 솔리디티(solidity)라는 프로그래밍 언어를 사용하여, 계약 기간, 금액, 조건 등을 미리 코딩해 두면, 부동산 거래, 중고 자동차 거래, 무역 거래 등 어떠한 종류의 계약도 자동 실행되도록 만들 수 있다. [2] 기존의 비트코인이 블록체인 기술을 활용하여 가치의 저장과 전달이 가능한 암호화폐를 만들었다면, 이더리움은 한 단계 더 나아가 블록체인 기술을 활용하여 인간이 상상할 수 있는 모든 종류의 계약을 자동으로 실행할 수 있는 스마트 계약 플랫폼을 개발했다. 비탈릭 부테린이 이더리움을 통해 스마트 계약 기능을 구현함으로써, 블록체인 기술을 비트코인과 같은 암호화폐에만 사용하는 것이 아니라, 위변조 방지가 필요한 각종 계약서 작성 등에 활용할 수 있게 되었다. 이런 점에서 기존의 비트코인을 '블록체인 1.0'이라고 부르고, 스마트 계약 기능을 구현한 이더리움을 '블록체인 2.0'이라고 부른다.
목차
닉 재보의 비트골드
스마트 계약은 1994년 닉 재보(Nick Szabo)[3]가 처음 고안한 개념이다. 닉 재보는 스마트 계약을 "계약에 필요한 요소를 코드를 통해 스스로 실행되게 하는 전산화된 거래 약속"이라고 정의했다. 그는 스마트 계약이 자동판매기와 비슷하다[4]고 말했다. 자동판매기에 미리 정해진 액수 이상의 돈을 투입하면, 자동으로 원하는 상품을 구매할 수 있듯이, 스마트 계약을 통해 일정한 조건이 충족되면 자동으로 계약이 실행되도록 한다는 것이다.
1996년 닉 재보는 스마트 계약 설계의 기본 원칙으로 관측 가능성, 검증 가능성, 사생활 보호, 강제 가능성 등 4가지를 제시했다.
- 관측 가능성(observability) : 스마트 계약은 서로의 계약 이행 가능성을 관찰하거나 성과를 입증할 수 있어야 한다.
- 검증 가능성(verifiability) : 계약을 이행 또는 위반했을 때 이를 알 수 있어야 한다.
- 사생활 보호(privacy) : 계약 내용은 계약에 관련된 당사자들에게만 알려져야 한다.
- 강제 가능성(enforceability) : 계약을 강제로 이행할 수 있는 구속력이 있어야 한다. 단, 강제 가능성은 최소화해야 한다.
닉 재보는 스마트 계약을 위해 비트골드(bit gold)라는 디지털 화폐를 고안했지만, 당시의 기술적 한계로 인해 실제로 개발되거나 사용되지는 못하였다.[5]
비트코인 스크립트
2009년 비트코인이 개발되고 비트코인의 신뢰 보장 기술인 블록체인이 등장하자 스마트 컨트렉트가 다시 부상하기 시작했다. 기존 디지털 프로토콜의 낮은 신뢰성과 복제 및 위변조의 문제로 실제 구현되기 어려웠던 스마트 계약은 블록체인 기술를 통해 무결성을 보장하고 조작방지가 가능한 블록체인 기반 스마트 컨트랙트로 개발될 수 있게 되었다. 비트코인 프로토콜도 낮은 수준의 '스마트 계약' 기능을 가지고 있다. 기술적인 관점에서 봤을 때, 비트코인의 장부는 하나의 상태변환시스템(state transition system)으로 생각해볼 수 있다. 이 시스템은 현재 모든 비트코인의 소유권 현황으로 이루어진 하나의 “상태(state)” 와 이 현재 상태와 트랜잭션을 받아서 그 결과로써 새로운 상태를 출력해주는 “상태변환함수(state transition function)”로 구성되어 있다. 이러한 비트코인의 결제 시스템인 UTXO(소비되지 않은 트랜잭션 출력)은 간단한 스택-기반 프로그래밍 언어로 표현된 복잡한 스크립트에 의해서도 작동한다.[1] 즉, 최초의 블록체인 기반 스마트 컨트랙트는 바로 비트코인 스크립트이다. 비트코인 트랜잭션에 원시 언어인 OPCODE로 스크립트를 작성해서 보내면 조건에 따라 자동으로 거래를 수행할 수 있다. 하지만 비트코인 스크립트는 튜링불완전언어를 사용하고, 반복문은 사용할 수 없고, 다양한 상태를 표현할 수 없으며 비트코인 잔고 외의 다른 정보를 관리 할 수 없다는 한계가 있다. 이는 비트코인 스크립트에서 반복문을 허용할 경우, 스크립트 조건 때문에 코드 실행을 0부터 시작하는 프로그램 카운터를 하나씩 증가시키면서 반복적으로 연산을 수행하도록 구성된 무한 루프가 발생하여 네트워크 전체가 멈출 수 있기 때문이다.[6]
이더리움 스마트 컨트랙트
이더리움(Ethereum)은 이러한 비트코인 스크립트 시스템의 한계를 극복하고자 나온 스마트 컨트랙트에 특화된 블록체인 플랫폼이다. 이더리움 블록체인의 경우, 블록에 데이터뿐만 아니라 비트코인 스크립트 시스템의 한계인 조건, 반복 구문 등의 실행코드를 포함시켜 로직의 실행을 자동화할 수 있다. 스마트 컨트랙트를 구현하기 위한 컨트랙트 코드(contract code)는 EVM(Ethereum Virtual Machine)이라는 독립된 실행 환경에서 실행된다. 여기에 스마트 컨트랙트를 실행할 때마다 수수료를 발생시키고 네트워크상에 수수료의 한계를 설정하여 무한루프를 막았다. 무한히 반복되는 조건을 만들어 스마트 컨트랙트를 실행시키면 중간에 수수료 한계점에 도달하게 되는데, 이때 중단된다. 이더리움에서 스마트 컨트랙트는 솔리디티 언어로 프로그래밍된다. 솔리디티 언어로 프로그래밍된 스마트 컨트랙트는 컴파일러(solc)에 의해 바이트 코드로 컴파일되고, 컴파일된 바이트코드는 블록에 포함되어, EVM(Ethereum Virtual Machine)에 의해 실행된다. EVM(Ethereum Virtual Machine)은 이더리움 스마트 컨트랙트의 바이트 코드를 실행하는 32바이트 스택 기반의 실행환경이다.
이더리움이 제공하려는 것은 튜링 완전(turing-complete) 프로그래밍 언어가 심어진 블록체인이다. 이 프로그래밍 언어는 코딩된 규칙에 따라 '어떤 상태'를 다르게 변환시키는 기능(arbitrary state transition functions)이 포함된 "계약(contracts)"을 사용자들이 작성할 수 있게 함으로써 인간이 상상할 수 있는 모든 종류의 계약을 자동으로 실행할 수 있게 만들고, 다른 많은 애플리케이션도 쉽게 만들 수 있도록 돕는다.[1]누구든지 이 언어를 사용해 스마트 컨트랙트, 디앱을 작성하고 소유권에 대한 임의의 규칙, 트랜잭션 형식(transaction format), 상태변환함수(state transition function) 등을 생성 할 수 있다. 초창기 스마트 컨트랙트에서 가장 이슈가 되었던 예는 DAO(Decentralized Autonomous Organization)라고 불리는 탈중앙화된 자율 조직이다. 다오(DAO)는 스마트 컨트랙트 기술로 구현된 조직으로 중앙 운영의 주체 없이 개인들이 자율적으로 제안 및 투표를 하여 다수결로 의결하여 운영되는 조직이다. 회사의 의결권을 다오 토큰(DAO Token)으로 행사할 수 있도록 크라우드 펀딩을 통해 이더리움으로 다오 토큰을 살 수 있게 판매하였고, 그 과정에서 모인 약 2000억원 가량의 이더리움을 어떻게 사용할지 다오 토큰을 기반으로 투표할 수 있도록 했다.
작동 방법
블록체인 기반 스마트 컨트랙트는 기본적으로 모든 트랜잭션 로그가 저장된 블록체인 데이터베이스와 스마트 컨트랙트의 상태를 저장하는 데이터베이스 두 가지가 존재한다. 여기서의 스마트 컨트랙트는 상태를 변경할 수 있는 애플리케이션이라고 할 수 있고, 스마트 컨트랙트의 상태는 해당 애플리케이션에서 사용하는 변수라고 할 수 있으며 이를 변경하기 위한 입력값은 트랜잭션에 포함되어 있다. 또, 스마트 컨트랙트는 두 가지 인터페이스를 공개하고 있는데, 하나는 트랜잭션(Transaction)이고, 하나는 쿼리(Query)이다. 트랜잭션을 통한 인터페이스는 트랜잭션 데이터베이스에 저장되고, 스마트 컨트랙트의 상태를 변경시키는 접근방법이다. 쿼리는 트랜잭션 데이터베이스에 기록이 남지 않으면서 스마트 컨트랙트의 상태를 읽는 작업이다. 트랜잭션은 쓰기, 삭제, 수정을 실행하고 쿼리는 읽기 및 조회만을 실행한다. 예로, '상품 거래' 가 어떻게 작동하는지를 알아보도록 하자.
- 기록 저장: 판매자가 상품을 올리겠다는 내용을 코딩하여 트랜잭션을 만든 후 블록체인에 전송한다. 상품 등록 트랜잭션 발생 시, 네트워크의 모든 노드는 상품 등록 트랜잭션을 공유하고 블록을 생성한 후 블록을 브로드캐시팅한다. 블록을 전달받은 각 노드는 블록을 자신이 블록체인에 추가하고, 해당 블록에 저장돼 있는 트랜잭션을 적용시켜 자신의 스마트 컨트랙트 데이터베이스를 동기화한다. 이러한 과정을 통해 모든 블록체인의 노드들이 스마트 컨트랙트 상태 데이터베이스를 공유하게 된다.
- 상품 조회: 구매자는 블록체인 네트워크에서 상품를 조회한다. 스마트 컨트랙트에 쓰는 것는 것은 트랜잭션을 발생시키지만, 값을 읽어 오는 것은 트랙잭션을 발생시키지 않는다. 블록체인의 어떤 데이터도 변경시킬 필요 없이 스마트 컨트랙트 데이터베이스 내 저장된 상태 값만 조회하면 되기 때문에 쿼리 정보는 블록체인에 동기화할 필요 없고, 블록 동기화 타이밍에 상관없이 바로 응답할 수 있다.
- 계약 이행: 구매자가 상품 구매 트랜잭션을 보내면 트랜잭션을 공유하고 블록체인 네트워크에 동기화한다. 모든 노드의 스마트 컨트랙트 데이터베이스에 상품 구매자를 등록하고 돈을 판매자에게 전송한다. 그러면 등록된 콘텐츠의 소유권이 구매자에게로 이동한다.
이렇듯 스마트 컨트랙트는 모든 데이터를 공유하기 때문에 특정한 사람이 스마트 컨트랙트의 실행 결과를 조작하려해도 조작할 수 없으며 블록체인이 모든 트랜잭션의 무결성을 보장해 주는 방식으로 스마트 컨트랙트의 무결성도 보장할 수 있다. 또, 조건 성취 시 계약을 자동으로 이행함으로써 계약의 집행 비용 및 분쟁 가능성을 줄일 수 있으나, 일상 언어를 프로그래밍하는 계약 작성 단계의 비용 및 작성 오류 문제가 존재한다.
사용 사례
스마트계약은 오랜 기간 동안 비즈니스 관행으로 고착화된 여러 제약을 넘어설 수 있는 사고의 파괴를 유도하고 나아가 새로운 가치를 창출할 수 있는 원천이다. 왜냐하면 보안 비용이 절감되고, 해킹 위험이 사라지며 중개자가 없으므로 수수료도 절감되고 데이터 정합성 혹은 무결성 검증 시간이 단축되기 때문이다. 또, 투명성으로 인해 규제 비용이 절감되고, 이중 지불 위험도 사라지며 IT 구축 비용이 절감되고 신사업 서비스로의 확장성도 가질 수 있다. 특히, 상호 약속된 규칙에 따른 절차로 작동하며 서로 간의 신뢰가 필요한 서비스 업무 영역에서 가장 큰 적용 효과를 발휘할 것으로 예상되고 있다. 또, 기존 비트코인(Bitcoin) 블록체인에서부터 시작된 통화 및 지급 결제 수단으로서의 본원적 업무 영역은 물론, 유∙무형 자산을 포괄한 모든 재화에 대한 평가, 가치 관련 모든 거래 등에 빠르게 침투하고 있다. 우선적으로, 일정한 형식의 반복적인 계약이 많은 분야, 원격자 간 계약 체결이 필요한 분야, 제품의 유통 추적이 필요한 분야에서 스마트 컨트랙트를 도입하고 있다.
금융
비트코인 블록체인에서는 지불 수단을 중심으로 한 중개기관 없이 순수 자금의 이동·전환·처리에 중점을 두었다면, 블록체인 2.0에서는 거래 관련 이해관계자들 간 자금이동을 포함하여 관련된 계약의 내용을 포괄하는 사전·사후 업무처리 범위로 관련 서비스 영역이 확산되어 거래 당사자 간 스마트 계약에 따른 자동 실행을 기반으로 하는 P2P 중심 계약 시스템으로 확산될 전망이다. 특히, 일정한 형식의 반복적인 계약이 많은 분야, 즉 보험업에서 특정 조건을 만족시키면 계약 보상금이 지급되도록 스마트 컨트랙트를 작성함으로써, 조건 성취 시 보험금을 지불한다.
- 보험
보험업의 특성상 손해보험 보상 업무 하나만을 놓고 보더라도 가입자, 보험사, 손해사정, 정비업체, 병원, 사법기관 등 다양한 이해관계자들간 확인 및 검증 처리 절차를 위하여 각기 상이한 대외 업무 처리를 통한 복잡한 인터페이스 프로세스에 의존할 수 밖에 없어 전체 업무 처리에 소요되는 시간과 비용은 상대적으로 높을 수 밖에 없었다. 보상 프로세스 진행과 관련 관련자간 동일한 증빙문서에 대하여 블록체인을 통하여 상호 합의한 처리내용에 대하여 위∙변조가 불가하면서도 처리 절차를 스마트 계약으로 자동 진행하여 블록체인 기반 연계업무를 누수 없이 신속 정확하게 처리할 수 있다. 이렇게 보험회사, 병원, 환자 간 블록체인 거래가 가능하면, 공동의 블록체인 시스템 생태계가 조성되어 네트워크 보완과 환자 의료 기록을 보호하면서 의료비 산출 및 청구 과정에서 투명성과 효율성을 높일 수 있다. 최근 해외에서는 알리안츠 보험, 존핸콕과 같은 대형 보험사를 중심으로 블록체인의 잠재성을 높이 평가하여 스타트업과의 제휴를 통해 새로운 보험 사업 모델을 개발 중이다.
- 은행
삼성SDS는 2017년 기업형 블록체인 플랫폼 넥스레저(Nexledger)를 선보인 후, 은행 공동 블록체인이자 은행연합회의 블록체인 공동 인증 서비스인 뱅크사인(BankSign)을 출시했다. 2018년 8월 27일에 개발 완료된 뱅크사인은 18개 은행이 모두 서버를 두고 블록체인 네트워크를 운용하는 프로젝트로, 고객이 한 은행에서 공동인증서를 발급 받으면 다른 은행에서도 간단한 인증만으로 거래 은행의 모바일 뱅킹 서비스를 편리하게 이용할 수 있다. 매년 갱신하고 은행마다 등록과 인증이 필요했던 번거로운 절차도 필요 없어졌고, 유효기간도 3년 이상으로 늘어난다. 증권업계도 증권 거래에 스마트 계약을 도입해 자동화를 이뤄가고 있다. 나스닥의 경우 전문 투자자용 장외시장 거래에 이를 적용했다.
지적재산권
블록체인을 통해 소유권을 관리하고 음원 구입관련 거래 정보를 투명하게 공유하여, 저작권과 같은 지적재산권을 보호하고 불법 복제를 근본적으로 근절하는 데에 기여할 수 있다. 또한 지적재산권에 대한 권리를 스마트계약(Smart Contracts)으로 등록하여 사용자 대금 지급에 따라 실시간 대금 수령이 이루어지도록 구현하면, 불필요한 중개자가 제거되고 프로세스는 단축되어 보다 효율적인 거래가 가능해진다.
공유경제
블록체인 기반의 스마트계약(Smart Contracts)은 공유경제의 한계점인 보완과 신뢰의 문제를 해결하는 열쇠가 될 수 있다. 원격자 간 계약 체결이 필요한 분야이기도 한 공유경제의 경우, 집 또는 자동차를 공유하는 경우 계약 조건을 정하고 이에 따라 금전 지급 및 서비스 제공이 이루어지도록 스마트계약(Smart Contracts)을 실행하면, 중개 기업을 거치지 않는 사용자 간 직접 거래가 실현된다. GM과 승차공유기업 리프트는 사물인터넷(IoT) 기반으로 차량을 등록하고 유치권, 이전, 압류 담보관리 등의 추적을 스마트 계약을 통해 자동화하는 작업을 진행하고 있다.
물류 유통
제품의 유통 추적이 필요한 분야인 전 세계 식품 유통에 관여하는 생산자, 공급자, 운영자, 배급업체, 유통업체, 규제당국, 소비자 등이 모두 블록체인 상에서 식품 오염 이력을 확인하고 이에 따라 대금을 지불 가능하다. IBM은 블록체인 기반 식품 산지조회 서비스 푸드트러스트를 운영 중이다. 식품 산지조회 서비스를 운영하게 되면서 오염된 식품이 발견될 경우, 어떤 농장에서 생산됐는지 확인하는 데 6일 이상 걸려 모든 식품을 폐기해야 했는데 블록체인 기술을 적용해 2.2초로 단축됐다고 설명했다. 삼성SDS의 경우, 2017년 36개 민·관·연과 함께 해운물류 블록체인 컨소시엄을 구성해 7개월간 기술 검증을 진행했었다. 배를 이용해 물건 하나를 다른 나라로 보내는 일이 생각보다 복잡해서 상대방을 속이는 부당행위가 일어나도 이를 걸러내기 쉽지 않은 구조이기 때문에 해운물류 분야 기업들은 '신뢰'의 기술이라는 블록체인에 관심이 가질 수 밖에 없었던 것이다. 기존에는 200개 이상 문서가 수작업으로 오가야 했는데 이제 문서를 한 번에 동시 공유할 수 있도록 했다. 5~6일 걸리던 작업이 실시간으로 해결돼 많은 낭비가 사라졌다고 한다.
이더리움 스마트 계약의 한계점
- 특정 기능, 특히 상태값을 변경하는 작업에 수수료[7]를 필요로 한다. 결과적으로 무료로 사용할 수 있는 서비스를 구현하기가 힘들다. 루니버스 같은 이더리움을 기반으로 하는 일부 2차 플랫폼은 운영업체에서 참여 서비스 업체들의 수수료를 정책적으로 대납해준다고 한다.
- 다른 언어로 작성된 프로그램과 달리 스마트 계약 코드는 타이머나 이벤트 등을 통해서 실행되지 못한다. 예를 들어서 특정 시간에 특정 주소로 자동으로 송금하거나 하는 프로세스 등은 구현할 수 없다. 이유는 스마트 계약은 자기 자신의 개인키(Private Key)가 없기 때문에 스스로 어떤 트랜잭션을 발생시킬 수가 없기 때문이다.
- 랜덤 함수를 원칙적[8]으로 사용할 수 없다.
- 한번 배포되어 블록으로 생성된 스마트 계약은 수정이 불가능하기 때문에 업그레이드나 버그 패치, 보안 취약점 수정 등이 어렵다. 최근들어 업그레이드 가능한 스마트 계약(Upgradable Smart Contract) 작성 방법이 활발히 연구되고 있으나 delegatecall 기능을 이용하여 복수의 스마트 계약을 구성하고 새로 배포한 스마트 계약을 delegatecall하는 방식이기 때문에 플랫폼 차원에서 해결된 문제라고 보기는 힘들 것이다.
- Solidity 언어가 비교적 최근에 개발된 언어이고 그렇게 빠르게 업그레이드되고 있지는 못하고 있어서 타 개발 언어에서 기본적으로 지원되는 타입이나 연산자나 명령어가 부족하다. 예를 들어 소수점 연산을 아직 지원하지 않고[9] 있고 예외 상황이나 에러처리를 위한 제어문[10]이나 클래스가 거의 없다시피하다.
- Solidity 언어 관련 라이브러리도 상당히 부족하다. 심지어는 이더리움 공식 solidity built-In 라이브러리도 거의 없어서 기본적인 문자열 연산(문자열 결합,분할,내부검색 등)도 지원되지 않는다[11].
기존 시스템과의 인터페이스
- 스마트 계약도 이더리움의 다른 기능들과 마찬가지로 웹서버,모바일,일반 PC 어플리케이션과 같은 기존 시스템과 인터페이스하면서 계약 내용의 등록, 집행, 결과 조회 등의 동작을 수행할 수 있다.
- 현재 이더리움 공식 인터페이스 라이브러리에서 지원하는 기존 언어는 자바(Java), 자바스크립트(Javascript), PHP, 파이썬(Python) 등이다.
- 스마트 계약과 이더리움 공식 인터페이스 라이브러리[12] 사이에도 아직 제약 사항이 남아 있다. 예를 들어 solidity 언어의 struct 타입의 데이터는 인터페이스 라이브러리를 통해서 주고 받을 수 없다. 아예 solidity 언어의 컴파일러에서 에러 처리[13]되고 있다.
비트코인캐시 스크립트 연산 부호
2018년 한국에서 열린 후오비 카니발에서 비트메인 대표이자 비트코인캐시의 아버지라 불리는 우지한은 비트코인캐시(BCH)는 의사결정 방식인 합의 알고리즘 변화 없이 다양한 프로젝트를 시도할 수 있는 방안을 도출했다며 BCH에 내재된 ‘스크립트 연산 부호(OP_RETURN)’을 활용하면 스마트 계약 등 다양한 기능을 자유롭게 구현할 수 있다고 했다. BCH는 최근 업데이트를 통해 40바이트였던 스크립트 연산 부호 용량을 220바이트로 늘려 새로운 프로토콜을 개발하기에 훨씬 쉬운 환경이 됐다고 한다. 스크립트 연산 부호는 블록체인 거래(transaction) 과정에 아무런 영향을 주지 않고, 블록에서 제거할 수 있기 때문에 스마트 계약 등 다양한 기능을 자유롭게 개발 및 구현할 수 있다거 한다. 이어 비트코인의 스크립트 연산 부호 용량이 컸다면 이더리움 창시자인 비탈릭 부테린도 이더리움을 만드는 대신 이 부호를 활용하여 스마트 계약을 만들었을 것이란 언급도 덧붙였다.
심버스의 심트랜스 : 범용거래 처리기
이더리움 블록체인의 주요 기능인 스마트 계약은 당사자 간 특정 조건이 충족되어야만 거래가 발생하므로, 예약거래는 불가능하다. 반면 심버스는 범용거래 처리기로 예약거래와 일반거래를 구분 없이 거래 가능하도록 했다. 심버스 블록체인의 사용자들은 일반거래와 예약거래는 분 단위로 처리시점을 정할 수 있으며, 예약거래의 최장 예약시점은 1년이며, 그 이상 되는 예약거래의 경우 애플리케이션이 연 단위로 갱신하여 처리하거나 스마트 계약을 이용하여야 한다. 예약거래의 네트워크 수수료는 거래의 컴퓨팅 크기를 기준으로 하며 저장비용을 감안하여 기간할인 방식을 적용한다. 이러한 범용거래 처리기 사용으로 그동안 블록체인 접근이 힘들었던 개인과 소상공인 및 인터넷 애플리케이션에 새로운 블록체인을 활용 기회가 제공된다.
심트랜스 범용거래 처리기의 주요 기능은 다음과 같다.
- 즉시거래와 예약거래 : 범용거래 처리기는 다중블록체인을 이용하여 일반거래와 스마트 계약을 구분하여 처리하고, 일반거래는 거래 처리 시점에 따라 즉시거래와 예약거래로 구분하며 서로 다른 블록체인을 사용한다. 일상생활에서 송금이나 단순지불 거래는 즉시 처리가 요구되지만, 일부 인터넷 쇼핑 등에서는 물건의 배달이 확인되는 시점까지 대금지불을 늦출 수 있다. 또한 매달 월정액을 지불하는 상품과 서비스 구매도 예약거래에 해당한다. 계약서에 따른 대금지불이나 조건이 붙은 거래도 예약 거래를 이용하여 손쉽게 처리할 수 있다.
- 일대다 거래 : 다수의 수신자에게 즉시 거래하거나 예약거래를 할 수 있다. 다수의 수신인에게 송금을 할 수 있기 때문에 다수의 중개인이 존재하는 거래나 동일한 유형의 다수 거래를 한 번에 처리할 수 있다. 이를 통하여 거래 처리시간 단축, 거래시점 동시화 등을 간단하게 처리한다.
- 일반거래와 스마트 계약의 병용 : 하나의 함수로 모든 일반거래와 스마트 계약을 동시에 처리할 수 있다. 예를 들어 예약거래와 스마트 계약의 호출은 하나의 함수로 처리할 수 있기 때문에, 선물거래나 옵션거래를 간단하게 처리할 수 있다.
보안 문제
스마트 컨트랙트는 블록체인 기술을 기반으로 계약 조건을 코딩하고, 조건에 부합하면 계약 내용이 자동으로 실행되는 프로토콜이다. 이더리움 스마트 컨트랙트는 솔리디티(Solidity)라는 프로그래밍 언어로 작성된 ‘소스 코드’로, 소스 코드 상의 작은 실수나 오류로 인해 버그가 발생할 수 있다. 이더리움 기반 토큰들은 스마트 컨트랙트를 이용하여 만들어지기 때문에, 스마트 컨트랙트를 안전하게 관리하지 못하면 해킹 등 큰 경제적 피해가 초래될 수 있다. 그렇기 때문에 사용자 및 투자자들을 위험에 빠뜨리지 않기 위해서라도 스마트 컨트랙트에 대한 검증은 매우 중요하다. 하지만 이더리움의 스마트 계약이 보안 취약성을 가지고 있다는 문제가 계속 제기되고 있다. 2018년 싱가포르국립대학교(National University of Singapore)와 런던대학교(University College London)의 연구를 통해 이더리움 네트워크에서 3만 4,000개 이상의 취약한 스마트 컨트랙트가 발견됐다. 또, 버그 바운티에는 발견된 여러 취약점들이 올라오는데, IBM 리서치 연구원들이 ZEUS라는 이름으로 발표한 논문에 따르면, 현재 배포된 스마트 컨트랙트 중에서 그들의 분석기로 분석한 결과, 95%에 달하는 스마트 계약이 하나 이상의 취약점을 가지고 있다고 한다. 문제는 이러한 취약점이 취약점으로 끝나는 게 아니라 실제 해킹 사건으로 이어지고 있다는 데 있다. 그렇다면 이러한 취약점은 왜 발생할까?
코드 재사용
취약점 전파의 주요 이유 중 하나가 ‘코드 재사용’ 때문이다. 흔히 2가지 형태로 코드를 재사용하는데, 첫째는 개발 단계와 컨트랙트 실행 단계에서의 완전 재사용, 둘째는 포킹와 특정한 압축된 코드 파일로부터 시작하거나 ‘복사 및 붙여넣기’ 등의 부분적 재사용도 취약점의 원인이 될 수 있다고 한다. 보통 완전 재사용에 위해서는 솔리디티 프로젝트를 MPM 모듈을 통해 개발하는 게 보편화되어 있다고 한다. 혹은 컨트랙트 초기 배포 단계에서 외부 컨트랙트의 주소를 가지고 와서 객체(object)에서 활용하기도 한다. 중요한 것은, 하나의 컨트랙트 코드가 취약하다는 전제에서, 하나라도 잘못된다면 그것을 가져다가 사용하는 모든 사람들은 익스플로잇에 노출된다는 점이다. 취약점(vulnerability)과 익스플로잇(exploit)은 다르다. 취약점은 임의의 공격자가 허락받지 않은 기능을 수행할 수 있게 하는 프로그램 상의 약점이다. 반면 익스플로잇은 임의의 공격자가 취약점을 통해 허락박지 않은 기능을 수행하는(발현되는) 것이다. 부분 재사용도 마찬가지이다. 부분적 코드가 취약하다면, 사용자 모두가 그 위협으로부터 벗어날 수 없다고 한다. 포크의 경우, 새로운 프로젝트를 특정 시점의 소스 코드로 개발을 시작하고, 이러한 자식 프로젝트는 부모 프로젝트의 상당 수 코드를 포함하고 있기 때문에 취약점이 남아있을 확률이 높다는 것이다. 코드 재사용이 나쁜 것만은 아니다. 전략적인 블록체인 개발을 위해 가져다 쓸 수밖에 없으며 또 유지보수 전략차원에서도 많이 사용하는 패턴을 사용하면 수월해지기 때문에 재사용할 수밖에 없다. 하지만 문제는 원본 소스가 취약점이 발현하여 패치가 되더라도 안드로이드, 타이젠 등에 취약점이 전파되고, 최종적으로 여러 기기에까지 취약점이 전파된다는 것이다. 또, 취약점이 제품 반영까지 평균 8개월 정도로 오랜 시간이 걸린다. 취약점 전파는 주의하면 어느 정도 해결이 되지만 구조적 해결은 쉽지 않다고 한다.
스마트 컨트랙트 환경 자체
스마트 컨트랙크는 일반적으로 패치가 불가능하고, 모두가 같은 실행 환경을 가지고 있으며 모든 거래를 추적할 수 있다. 또, 컨트랙트가 현금화 가능한 이더리움라는 재화를 가지고 있다. 문제는 이 모든 특징이 해커에게 유리한 환경을 제공한다는 것이다. 패치가 불가능하기 때문에 취약점이 남아있다면 계속해서 해킹할 수 있는 단서를 제공하는 것이고, 모두가 같은 실행 환경을 가지고 있다는 것은 해커의 접근성이 올라간다는 것이다. 무엇보다 컨트랙트가 현금화 가능한 이더라는 재화를 가지고 있다는 것은 해커의 강력한 동기 부여가 된다. 실제 이더스캔에 등록되어 있는 검증된 컨트랙트를 다운받아 컨트랙트 수준의 재사용 현황을 살펴 본 결과, 완전히 동일한 컨트랙트가 많이 존재했으며 토큰위자드 등의 편리한 서비스를 활용해서 각자만의 토큰을 만들고 있는 상황이라고 전했다. 함수 수준의 재사용을 살펴본 결과, safemath라는 함수를 가장 많이 사용하고 있고, 취약한 함수에서 일부 수정을 했던 코드상에서도 취약점이 발견되고, 이로 인해 익스플로잇 가능한 코드들이 있다고 한다.
리엔트란시(Re-entrancy)
해커가 특정 기능을 악용해 반복적으로 진입하고 코드의 특정 시점 이전에 원하는 바를 실행할 수 있다. 잔고가 확인되기 전에 계정을 비울 때까지 암호화폐를 반복적으로 송금해 프로세스 실패를 유발하는 것이 그 예다. 이 방법이 DAO 해킹에서 사용되었지만 적절한 코드 작성을 통해 방지할 수 있다.[14]
정수 오버플로 및 언더플로
정수 오버플로 및 언더플로(Integer overflow and underflows)는 스마트 컨트랙트에서 보편적으로 발견되는 문제다. 이 결함은 최근 특정 프로토콜을 사용하는 여러 이더리움 스마트 컨트랙트에서 보고됐다. 이런 것은 오픈제플린(OpenZeppelin)의 세이프매스(SafeMath) 라이브러리 같은 라이브러리로 수정할 수 있는 경우가 많다.
짧은 주소 공격
짧은 주소 공격(Short address attacks)은 트랜잭션 내의 표적 주소가 짧을 때 발생할 수 있다. 이더리움 플랫폼은 트랜잭션을 무효화하는 대신에 해당 주소에 0을 추가한다. 이 지식을 이용해 해커는 정상보다 훨씬 큰 금액에 대해 완벽하게 정당한 송금을 실행해 토큰 지갑을 비울 수 있다.
DoS(Denial of Service)
DoS 공격을 통해 컨트랙트를 무력화시킬 수 있는 방법은 다양하다. 여기에는 트랜잭션 비용 부풀리기, 트랜잭션 승인을 위해 특정 권한 요구하기, 컨트랙트를 무한 루프(Loop)에 가두기 등이 포함된다.
이러한 문제를 해결하기 위해서는 지속적 보안이 필요한데, 일반적으로 소프트웨어를 개발하는 형식은, 디자인을 하고 코드를 짜고 동료들과 커밋과 코드 리뷰를 주고받으면서 지속적인 업데이트를 하고, QA와 Intergration과 같은 테스트를 하다가 Deploy 직전에 보안 검수를 받게 되는데, 이러한 형식의 개발은 유지보수 비용이 많이 든다. 취약점을 빨리 발견할수록 더 적은 비용이 소모되기 때문에 디자인 단계에서부터 어떤 새로운 취약점이 있는지를 살펴봐야 한다. 안전하지 못한 컨트랙트의 보안은 어렵기 때문에 배치 전 가능한 보안을 확보하기 위해 포괄적인 단위 테스트 선택이 필요하다. 그리고 개발자는 코드를 작성하기 전에 언어, 컴파일러, 알려진 보안 위험을 심도 있게 검토해야 한다. 또, 컨트랙트가 복잡할수록 오류가 포함될 가능성이 높아진다. 따라서 스마트 컨트랙트에 포함된 로직은 항상 최소화하고 컨트랙트의 거동에 대한 명확한 사양이 있어야 한다.
보안 업체
- 수호: 수호는 스마트 컨트랙트 전문 보안 회사로서, 자동화된 코드 보안 검수 서비스, 매뉴얼 서비스를 제공하고 있다. 각 회사가 개발한 스마트 컨트랙트를 검증받고자 하는 수요가 늘어나면서, 이더리움 스마트 컨트랙트에 대한 보안 검증을 관련 업체들이 하나씩 생겨나기 시작했다.
- 퀀트스탬프: 퀀트스탬프는 이더리움 스마트 컨트랙트를 검증하는 자동화된 프로토콜이다. 퀀트스탬프는 크게 두 부분으로 구성돼 있는데, 하나는 스마트 컨트랙트를 감사하는 웹 기반 자동 검증 시스템이고, 다른 하나는 스마트 컨트랙트에 있는 오류를 찾는 사람들에게 보상을 주는 자동 보상 시스템이다. 한편, 퀀트스탬프는 현재 베타 버전을 출시한 상태다. 퀀트스탬프 홈페이지에서 회원가입 후, 검토 받고자 하는 이더리움 기반 토큰의 컨트랙트 주소를 입력하면 5분 이내로 결과를 확인할 수 있다. 퀀트스탬프 메인넷은 오는 8월에 출시될 예정이다.
- 해치랩스 : 스마트 컨트랙트 검증 기업 해치랩스 역시 스마트 컨트랙트를 검증해 보안성을 높이는 전문 업체다. 스마트 컨트랙트에 보안 취약성이 존재하는지 점검하고, 백서에서 서술한 내용대로 구현되었는지 살피는 서비스를 제공한다. 특히 해치랩스는 스마트 컨트랙트를 적용한 디앱들이 서비스 발표 이후에도 꾸준히 업데이트할 수 있도록 하는 툴(Tool)을 제공하는데 관심을 두고 있다.
향후 전망
블록체인을 이용한 스마트계약은 계약 이행 및 검증의 과정이 네트워크로 자동화되고, 중재해주는 사람이나 기관이 없다보니 돈이나 부동산, 주식, 그밖에 가치있는 그 무엇이라도 교환하면서도 투명하고, 계약 쌍방간에 충돌 없이 거래를 완료할 수 있다. 기존 계약서는 서면으로 돼 있어 계약 조건을 이행하려면 실제 사람이 계약서대로 수행을 해야 하지만 디지털 명령어로 계약서를 작성하게 되면 명확성과 함께 애초에 합의한 조건에 따라 계약 내용을 자동 수행이 가능하다. 그리고 추가 비용 없이 직접 처리하게 만든 것으로 복잡한 사업상의 계약을 적은 비용과 합의에 따른 신뢰를 바탕으로 안전하게 계약을 실행할 수 있다. 무엇보다 스마트 계약은 그 실행 내용의 무결성과 조작되지 않음을 보장한다. 그렇기 때문에 스마트 컨트랙트 비즈니스는 계속 성장할 것으로 예상된다. 시장조사업체 가트너는(Gartner)는 2022년에는 글로벌 기관 중 25% 이상이 스마트 컨트랙트를 사용할 것으로 예상하고 있다. 캡제미니(Capgemini)는 2020년 초 스마트 컨트랙트가 도입될 것이며 특히 금융업계가 비용 절감과 수요 창출의 효과를 얻을 것라고 예측하고 있다. 즉, 투자은행의 경우, 결제 주기가 20일에서 6~12일로 단축되어 5~6% 추가 수요를 발생시킴으로써 매년 20~70억 달러의 추가 수입 발생을 예상하고 있고, 소비자 금융의 경우, 주택 담보 대출의 처리 비용을 낮춰 매년 30~110억 달러 비용 절감되고, 보험의 경우, 개인용 자동차 보험에서만 연간 210억 달러 비용 절감이 예상되고 있다. 한국에서도 지난해부터 스마트 콘트랙트를 활용한 각종 정부사업이 추진되고 있다. 중앙선거관리위원회는 블록체인을 접목한 온라인 전자투표 시스템을, 농림축산식품부는 블록체인 기반의 축산물 이력관리시스템을 준비 중이다. 국토교통부는 공인중개사 등과 연계해 부동산 거래를 원스톱으로 제공하는 플랫폼을 시범적으로 구축하고 있다.
각주
- ↑ 1.0 1.1 1.2 Vitalik Buterin, "A Next-Generation Smart Contract and Decentralized Application Platform", 2013.
- ↑ Peter Sayer, 〈블록체인에 대한 기본 상식 5가지〉, 《CIO Korea》, 2016-04-12
- ↑ 닉 재보(Nick Szabo)는 로스쿨을 졸업한 컴퓨터 과학자이다. '닉 자보'라고도 한다.
- ↑ 김인경 기자, 〈(IT열쇳말) 스마트 계약〉, 《블로터》, 2018-02-05
- ↑ 이정훈 기자, 〈(이정훈의 암호화폐 읽기)<2>`빅 브라더` 가라…혁신 넘어선 혁명〉, 《이데일리》, 2018-01-10
- ↑ 더루프, 〈스마트 컨트랙트 개요(Smart Contract)-2〉, 《더루프 블로그》, 2017-04-04
- ↑ gas라고 부른다.
- ↑ 블록의 생성 시간으로 랜덤값을 만드는 방법 등이 있기는 하지만 원칙적인 랜덤값이라고 보기는 힘들다
- ↑ Solidity 공식 매뉴얼에서 사용하지 말 것을 추천하고 있다.
- ↑ assert문이나 require문이 있기는 하나 주어진 검사 조건이 참(true)이 아니면 실행중인 코드를 중지시키는 역할만 하고 코드 흐름을 제어하지는 못한다.
- ↑ 3rd party 비공식 라이브러리는 있지만 그렇게 활발히 사용되고 있지는 않고 있다.
- ↑ 통칭 web3라고 부르지만 지원하는 언어별로 약간씩 명칭이 다르다. 예를 들어 자바는 Web3J, 자바스크립트는 Web3.js, 파이썬은 Web3py라고 되어있다.
- ↑ experimental ABI encoder라고 하는 실험적인 컴파일 지시자를 사용하면 가능하지만 권장되지는 않는다.
- ↑ Dan Swinhoe, 〈블록체인의 스마트 컨트랙트란 무엇인가, 그리고 보안〉, 《IT WORLD》, 2018-10-17
참고자료
- Vitalik Buterin, "A Next-Generation Smart Contract and Decentralized Application Platform", 2013.
- 김인경 기자, 〈(IT열쇳말) 스마트 계약〉, 《블로터》, 2018-02-05
- 이정훈 기자, 〈(이정훈의 암호화폐 읽기)<2>`빅 브라더` 가라…혁신 넘어선 혁명〉, 《이데일리》, 2018-01-10
- 더루프, 〈스마트 컨트랙트 개요(Smart Contract)-2〉, 《더루프 블로그》, 2017-04-04
- Dan Swinhoe, 〈블록체인의 스마트 컨트랙트란 무엇인가, 그리고 보안〉, 《IT WORLD》, 2018-10-17
- 박소영, 〈생활 속에 스며드는 스마트 컨트랙트 현황 및 준비과제〉, 《한국과학기술기획평가원》, 2018-40(통권 제258호)
- 김종협, 〈블록체인 기반 스마트 컨트랙트 활용 사례 연구〉, 《전자금융과 금융보안》, 2017-07(제9호)
- 야옹메롱, 〈스마트 컨트랙트에 대한 개요 및 설명〉, 《네이버 블로그》, 2018-08-08
같이 보기
