암호화폐 , 얼트코인 이야기

본 글을  Zdnet에 기고된 글 입니다.

최근 서점가에 가면 가장 많이 눈에 띠는 곳에 전시된 책들 중 하나가 블록체인과 비트코인 이런 가상화폐 , 암호화폐 등을 다루는 책들 입니다.  특히, 비트코인같은 암호화폐에 투자해서 단시일만에 몇 억을 벌었네 라는 내용의 책이 가장 인기가 많다고 합니다. 아마 많은 사람들이 이러한 암호 화폐에 대해 관심을 갖고 있고 아마 여러분도 한두번쯤은 호기심에 암호화폐를 거래 하는 거래소에 접속한 적도 있을 것입니다. 참고로 가상화폐는 암호화폐를 포함하는 좀 더 포괄적인 개념으로 현재 각종 서비스의 마일리지나 포인트 같은 것을 포함하고 있고 암호화폐는 비트코인 처럼 암호화 기술을 사용하여 위.변조가 불가능한 형태의 화폐를 말합니다. 

아마 많은 언론 등을 통해 비트코인이라는 암호화폐에 대해서는 들어본 적이 있을 것 입니다. 그런데 비트코인외에도 많은 암호화폐가 있습니다. 다음은 국내 거래소 중 한곳에서 거래되는 암호화폐들 입니다.

국내 거래소를 통해  유통중인 암호화폐들

현재 비트코인 외에 다른 암호화폐를 통털어 얼트코인(Alternative Coin)이라고 합니다.  이들 얼트코인은 비트코인을 수정하여 개발되었기 때문에 비트코인과는 호환되지 않습니다.  따라서 현재 알트코인은 비트코인을 제외한 암호화폐를 지칭하는 용어로 사용되고 있습니다.  대표적인 알트코인으로는 리플,  라이트코인, 대쉬, NEM, 이더리움 클래식, 비트코인 클래식, 모네로 , Zcash, 디크리드(Decred) 등이 있습니다.   

알트코인(Alternative Coin) 살펴보기.  

먼저 리플은 XRP코인으로  거래되는 데  글로벌 정산 네트워크에서 정산을 단순하게 처리하기 위해 개발되었습니다. 현재 글로벌 결제 서비스는 사용자, 국내 은행, 해외 은행 등 여러 기관을 거쳐 복잡하게 처리가 됩니다. 각 기관의 정산 과정을 거칠 때 서로 다른 통화와 시스템 등으로 인해 많은 시간과 비용이 들어가는데 이런 절차를 줄이기 위해 개발된 블록체인 기반 정산 시스템이 리플이며 , 리플 시스템을 운영하기 위해 발행한 암호화폐가  XRP코인입니다.

리플이 현실 세계의 글로벌 정산 문제를 해결하기 위해 개발 되었다면 라이트코인은 비트코인의 블록 생성 시간을 단축시키기 위해  향상 시키기 위해 개발 되었습니다. 현재 비트코인의 경우 블록 생성 시간이 10분이지만  문제 없는 지 확인 후 거래의 최종 완료를 위해서는  6개의 블록이 블록체인에 등록될 때 까지 대기한 후 7번째 등록이 되기 때문에 실제 블록의 생성 시간은 1시간 가량 소요됩니다. 라이트코인은 이 문제를 해결하기 위해 비트코인을 수정하면서 탄생했습니다.

이더리움 클래식과 비트코인 클래식은 블록체인 기반 암호화폐 시스템이 어떻게 운영되는지를 잘 알 수 사례입니다.  이더리움 클래식은 이더리움의 가상화폐인 이더(Ether)를 도난 당했을 때  기술적으로 이를 어떻게 해결할 것인가에 대한 이견으로 이더리움에서 분리되어 나왔습니다. 2016년  이더리움에 해킹 사건이 발생했습니다.  자동으로 암호화폐 기반의 분산 투자를 하기 위한 이더리움 기반 펀드 시스템인 다오(The DAO)가 DAO 토큰을 발행하고 이를 판매해 투자 자금을 모집중이었습니다. 이 과정에서 다오는 이더리움의 스마트 컨트랙트 기술을 이용해 Spilit 라는 컨트랙을 개발했습니다. 스마트 컨트랙트는 블록체인상에 특정 조건이 만족하면 암호화폐를 자동으로 해당 대상에게 전달하게 해주는 계약 내용을 실행하게 해주는 프로그램입니다. 

Spilit 컨트랙은 투자금을 반환 요청을 하면 DAO토큰을 암호화폐 이더로 반환해주는 역할을 합니다.  그런데  이 과정에서 즉시 반환 요청이 처리되어 금액이 감소하는 것이 아니라 일정시간이 지난 후에야  반환 요청이 처리되는 치명적인 결함을 갖고 있었습니다. 이 결함을 알아 챈 해커는 투자 반환 요청 후 자신의 잔고에서 반환 요청이 처리되기 전에 반복해서 반환 요청을 하는 “반복 공격(Recursive attack)” 을 하여 다오가 확보한 전체 자금중 3분의 1에 해당하는 5,300만 달러(한화 612억)를 훔쳤습니다. 대다수의 이더리움 사용자는 잃어버린 암호화폐 이더를 다시 찾고 이 문제를 해결하기 위해 이더리움의 코드 변경을 원했지만 다른 일부 사람들은 이더리움의 블록체인 자체의 문제가 아니라 스마트 컨트랙의 문제이기 때문에 코드 변경을 하지 말아야 한다고 생각했습니다. 이 때,  코드 변경을 원하지 않는 사람들이 코드 변경전의 이더리움을 갖고 나와 이더리움 클래식을 만들었고 , 코드 변경을 한 사람들이 현재 이더리움을 운영중에 있습니다. (

아래 내용도 참고하세요. 

참고로 DAO 해킹 사건을 설명하시면서 recursive attack이라는 표현을 쓰셨는데 이 표현은 기술적으로 모호성이 있습니다. DAO 해킹에 사용된 방법은 꼭 recursive하지 않아도 다른 external 함수를 통해 스마트 컨트랙트에 재진입만 할 수 있으면 같은 원리로 해킹이 가능하기 때문에 보통 reentrant 혹은 reentrancy attack(재진입) 공격이라는 용어를 씁니다.

이더리움 상의 또 다른 해킹 방법인 call depth attack도 주로 recursive call을 하는 방식으로 공격이 이루어지기 때문에 둘을 구분하기 위해서라도 recursive attack이라는 표현을 지양하고, reentrant attack과 call depth attack으로 용어를 구분해 주시면 좋습니다. From 서광열.

서광열님, 의견주셔서 김사합니다.

)

이더리움 클래식 처럼 비트코인 클래식도 기존 비트코인을 개선하는 과정에서 탄생했습니다. 기존의 블록체인에서 하나의 블록 크기는 1MB입니다. 이 블록 크기를 늘리면 트랜잭션을 확인(Confirm)해 주는 속도를 높이기 때문에 실질적인 처리량을 증가하는 효과를 얻을 수 있고 높은 트랜잭션 비용 문제를 해결할 수 있습니다. 이  때문에 비트코인 커뮤니티에서는 2MB로의 점진적인 확장과 8MB 이상 급진적인 확장을 하자는 그룹의 의견이 충돌했고 투표를 하여 블록 크기를 2MB로 증가시키기로 하였습니다. 이렇게 해서 기존 비트코인과는 다른 프로토콜을 갖는 비트코인 클래식이 만들어 졌습니다.  

이들 외에 모네로와 Zcash는 익명성을 강화한 암호화폐입니다. 모네로는 블록체인상의 트랜잭션을 숨김으로 써 거래의 익명성을 강화하고 , Zcash는 "zero-knowledge" 라는 증명 방식을 사용하여 거래 당사자들이 서로의 신원을 확인하지 않고도 돈을 교환할 수 있게 해줍니다. 거래 트랜잭션을 블록체인에서 숨기는 모네로와 달리 Zcash는 연관된 이용자들과 거래된 양처럼 트랜잭션 자체의 세부사항만 숨깁니다.

비트코인 , 알티코인 등 암호화폐의 가치는 어떻게 판단할까?

새로운 암호화폐는 현실세계의 다양한 문제 해결을 위한 블록체인 기반 시스템과 서비스를 개발하는 과정에서 계속해서 나타날 것입니다.

아직까지 암호화폐들은 현실 거래에서 널리 사용되지 못하고 있습니다. 현실세계에 널리 쓰기에는 여러 문제점들이 있기 때문입니다. 이중 많은 사람들이 걱정하는 것은 현실화폐와 암호화폐간의 가격 변동폭이 크다는 것 입니다. 아마 언론을 통해 비트코인 가격이 폭락을 했다 또는 폭증했다 라는 기사를 간혹 들었을 것 입니다. 이러다 보니 이렇게 등락폭이 크다 보니 안정적인 가치를 제공해야 하는 화폐로서 위험하다는 생각을 하는 것은 당연합니다.

그런데 왜 등락폭이 클까요? 그것은 해당 암호화폐가 성장하는 데 있어 문제점이 발생하면 가격 하락이, 새로운 기능이 추가되거나 참여자가 증가하는 등 유리한 점이 발생하면 가격 상승이 생깁니다. 아직 해당 암호화폐의 상태가 초기다 보니 작은 사실 하나라도 큰 영향을 받습니다. 

그렇다면 이러한 암호화폐의 가치는 어떻게 판단해야 할까요? 답은 해당 암호화 화폐를 만들고 운영하는 커뮤니티의 성공 여부에 대한 판단이 암호화폐의 가치라 판단하는 기준이라 할 수 있습니다. 비트코인의 궁극적인 가치는 비트코인 기술이 계속 발전하고 참여가 늘면서 비트코인의 궁극적인 목표인 중간에 은행 등을 거치지 않고 사람간에 직접 전자 화폐를 거래하는 것을 실현할 것인가에 대한 여부일 것 입니다.  마찬가지로 다른 알트코인들도 초기 목적한 바를 이룰 수 있는가가 중요한 가치 판단 기준이라 할 수 있습니다.   

블록체인 기반 플랫폼 비지니스를 이해하자.

zdnet link -  http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170904160310

최근 ICT 분야에서 가장 많이 언급되는 것들이 아마 가상화폐, 암호화폐, 블록체인 일 것이다.  특히, 일반 언론에서도 간혹 비트코인 가격 폭락과 폭등을 다루는 기사와 새로운 암호화폐 프로젝트가 코인을 미리 판매하여  수백억원의 종자돈을 모았다는 기사 등 시종일관 많은 사람들의 관심을 끌고 있다. 가상화폐는 암호화폐를 포함하는 좀 더 포괄적인 개념으로서 각종 서비스의 마일리지나 포인트 같은 것을 포함하고 있고 , 암호화폐는 비트코인 처럼 암호화 기술을 사용하여 위변조가 불가능한 형태의 실물이 없는 가상의 디지털 화폐를 말한다 (엄밀히 말하면 현재 흔히들 말하는 가상화폐는 모두 암호화폐이다).

그러나 암화화폐의 기반에는 이루고자 하는 놀라운 목표와 이 목표의 실현에 동의하는 다양한 사람들이 모여 있는 생태계가 존재한다. 비트코인을 고안한 사토시는 그의 논문에서 비트코인을 다음과 같이 정의하고 있다 -“은행같은 중앙의 금융 기관없이 서로 간에 직접 온라인으로 캐쉬를 보낼 수 있는 전자 캐쉬”.

비트코인은 단순한 암호화폐가 아니라 은행같은 중간의 기관의 간섭없이 사용자간에 직접 화폐를 주고 받을 수 있는 세상을 만드는 것이 목표이다. 이러한 세상을 만들기 위해서는 암호화폐 사용자와 거래소 , 그리고 비트코인 시스템의 안정적인 운영을 담당하는 채굴자 , 그리고 끊임없이 필요한 기능과 오류를 수정하기 위한 개발자 커뮤니티 등 다양한 참여자들의 노력이 비트코인을 구성하고 있고 성장시키고 있는 것이다.  서로 신뢰할 수 없는 사람들이 모여 거래에 대한 이상유무를 합의하고 이에 따라 신뢰할 수 있는 거래가 이뤄지는 시스템과 생태계가 바로 비트코인이다.

중앙 집중식 플랫폼 비지니스

우리가 현재 널리 애용하고 있는 모든 서비스는 중앙집중형 플랫폼 비지니스 모델에 따라 운용된다. 모든 서비스와 컨텐트는 중앙의 집중화된 클라우드를 통해 사용자에게 제공된다. 사용자는 사용한 만큼 일정한 대가를 지불(Pay as you go)하고 컨텐트와 서비스를 이용한다. 심지어 우리라 무료 서비스라고 알고 있는 서비스도 사용자에게 광고를 전달하며 엄청난 수익을 창출한다.  이렇게 만들어진 엄청난 수익은 모두 중앙의 플랫폼 소유자에게 집중된다.  플랫폼 소유자는 발생한 모든 수익을 독점한다. 물론, 컨텐트를 공급하거나 일정한 부가 서비스를 제공하는 파트너에게는 우월적 지위에 있는 플랫폼 소유자가 정한 기준에 따른 대가가 전달된다.  중앙집중형 플랫폼 비지니스에서 모든 규칙은 플랫폼 소유자의 수익을 극대화하기 위해 만들어 진다. 플랫폼이 작동되고 수익을 만드는 데 참여한 사람들 공헌에 따른 가치 공유는 고려되지 않거나 플랫폼 소유자의 규칙에 따라 결정된다.

구글과 네이버는 인터넷상에 공개된 데이타를 모아 이를 손쉽게 검색하게 해주고 대신 검색 창과 결과에 광고를 게재하면서 엄청난 수익을 만들어 낸다.  물론, 이렇게 발생한 수익으로 서버를 운영하고 회사를 운영한다 라고 플랫폼 소유자들은 말을 하겠지만 전체 수익 중 사용자와 파트너 등 해당 비지니스가 성장하는 데 기여한 구성원들에게 돌아가는 가치 공유는 없다.  모든 것이 수익을 극대화하기 위해 결정된다. 아마존 또한 마찬가지이다. 중앙에 커다란 컴퓨팅 인프라를 클라우드로 구축하고 사용한만큼 사용자들에게 대가를 받는다. 많이 사용하면 할 수록 아마존은 더큰 수익을 내면 중앙의 클라우드는 더욱 커진다. 아마존 클라우드가 성장하는 데 기여한 사용자 및 솔루션 제공 파트너들에게는 가치공유란 존재하지 않는다.

블록체인 기반 분산형 플랫폼 비지니스

블록체인 기반 분산형 플랫폼에서는 중앙에 집중화된 클라우드 서버도 데이터도 없다. 분산된 플랫폼에 참여한 개별 컴퓨터가 하나의 서버이고 이 서버들이 네트웍으로 연결되어 하나의 거대한 네트웍 기반 클라우드 서버가 된다. 데이타는 모두 동일하게 공유되고 이 데이타는 위.변조가 불가능하다. 비록 연결된 사람들은 서로를 알지 못하고 신뢰할 수 없지만 서로 거래에 대한 이상유무를 확인하고 이 결과를 합의하여 모든 거래가 신뢰할 수 있도록 만든다.

분산형 플랫폼에 참여하여 서비스를 이용하면 이에 대한 대가로 암호화폐를 지불한다(Pay 암호화폐 as you go). 지불된 암호화폐는 플랫폼에 참여한 구성원들의 역할과 제공된 노력만큼 자동으로 전달된다. 이 모든 거래는 투명하게 공개되고 각각의 역할과 이에 대한 보수 등 모든 비지니스 규칙은 공개되고 모든 참여자들의 합의나 투표에 의해 결정되고 자동으로 적용된다. 

블록체인 기반의 이더리움은 임의의 서버들이 네트웍으로 연결되어 하나의 컴퓨터 클라우드를 형성하고 스마트 컨트랙을 하나의 컴퓨터에서 수행하는 것 같은 것을 만드는 것을 목표로 한다. 스마트 컨트랙트는 블록체인상에 특정 조건이 만족하면 암호화폐를 자동으로 해당 대상에게 전달하게 해주는 계약 을 만들고 이를 자동으로 실행하게 해주는 프로그램이다. 

스마트 컨트랙을 만들고 이를 작동시키기 위해 이더리움은 이더(Ether)라는 가상화폐를 사용한다. 이더리움상에서 컨트랙을 만들고 작동시키려면 이더를 사용해야 한다. 컨트랙들이 작동될 때 제공된 이더는 거래의 이상유무를 검증해주는 채굴자들의 노력에 대한 대가로 자동으로 제공된다. 또한 컨트랙이 실행되면 해당 컨트랙에 명시된 거래 조건이 만족하면 자동으로 컨트랙 내용에 따라 이더가 다른 사용자에게 전달되기도 한다. 가령, 이더리움 상에서 음악이나 영상같은 디지탈 저작권을 보증해 주고 거래할 수 있는 컨트랙을 통해 음악을 암호화폐 이더를 통해 구매하여 들을 수 있다. 이 때 구매에 사용된 이더는 컨트랙을 통해 해당 음악을 제작하는 데 참여한 작곡가, 작사가 , 세션, 그리고 가수 들에게 미리 정해진 규칙에 의해 자동으로 전달된다. 거래에는 중간에는 저작권사나 기획사 등 어떠한 개인이나 단체도 개입할 수 없다. 이 모든 과정의 비지니스 규칙은 투명하며 어떤 부정 거래를 용납하지 않는다. 또한 이더리움 플랫폼이 성장할 수록 암호화폐 이더를 소유한 모든 참여자들은 그 성장 가치를 공유한다. 이더리움 외에도 리플,  라이트코인, 대쉬, NEM, 이더리움 클래식, 비트코인 클래식, 모네로 , Zcash, 디크리드 (Decred) 등 많은 암호화폐 있으며  이들 모두 분산형 플랫폼 비지니스 모델을 지향한다.

독립형 생태계를 꿈꾸는 블록체인 세상

경험상 블록체인 기반의 플랫폼들이 안정적으로 작동되고 운영되기 위해서는 많은 개별 서버들이 자발적으로 참여하고 안정적으로 운영되어야 한다. 네트웍에 접속과 중단이 자주 반복되면 불안정할 수 밖에 없다.  물론, 채굴(마이닝)이라는 인센티브기반 운영체계를 통해 일정 수준 이상의 안정적인 서버를 확보할 수 있지만 이를 위해서는 많은 시간과 노력이 든다. 기술 및 운영 측면에서 볼 때 반드시 중앙집중 방식의 플랫폼이 비효율적인 것은 아니다. 실제 암호화폐들의 채굴업체들의 운용비용을 볼 때 블록체인 기반 P2P 플랫폼도 생각보다 많은 운영 비용이 발생한다. 그러나 앞서 설명한 것처럼 두 방식은 비지니스 모델 측면에서 근본적인 차이가 존재한다. 이 차이를 정확히 이해하고 블록체인 기반 플랫폼을 활용하고 고려하는 것이 반드시 필요한 시점이다.

이더리움 프로그래밍 수업(3)

들어가며

지난 두 번의 글을 통해 우리는 이더리움의 코어 엔진인 geth 를 다루는 다양한 방법에 대해 살펴보았습니다. 앞으로는 2회에 걸쳐 솔리디티를 이용해 컨트랙을 프로그래밍하는 방법에 대해 살펴보겠습니다. 특히, 단순 개발 뿐만 아니라 실제 해당 컨트랙이 어떻게 geth의 EVM 을 통해 실행되고 이 때 어떤 과정들을 거치는 지도 함께 살펴 보겠습니다.

// 첫번째 아주 간단한 예제 : Greeter.sol        

다음 예제 프로그램은 Greeter.sol 이라는 아주 간단한 솔리디티 프로그램입니다. Solidity-baby-steps에서 제공되는 첫번째 예제입니다. ( https://github.com/fivedogit/solidity-baby-steps ) 단계별로 많은 예제들이 모여 있어 해당 예제를 분석하면서 솔리디티 매뉴얼을 함게 보시면 솔리디티 프로그래밍을 익히는 데 효과적입니다.

아래 예제는 greet()를 호출할 때 마다 입력받은  스트링을 반환해주는 단순한 프로그램 입니다. 이 프로그램을 통해 솔리디티로 작성한 스마트 컨트렉트 프로그램의 구조를 이해해 보겠습니다. 

이더리움 프로그래밍 수업(2)

들어가며 

지난 글에서는 이더리움 코어 엔진인 geth을 설치하고 다뤄보면서 이더리움 플랫폼과 프로그래밍의 개괄적인 내용에 대해 살펴 보았습니다. 사용자 계정을 만들고 이들 간에 가상화폐를 주고 받고 , 이 주고 받는 작업을 블록체인에 연결하기 위해 마이닝이라는 작업을 하였습니다. 이번에서 실제 이더리움이 제공하는 가장 유용한 기술이자 비트코인 플랫폼과 차별화되는 대표 기능인 스마트 컨트랙트를 솔리디티(Solodity) 개발 언어를 이용하여 프로그래밍하는 방법과 개발 환경 구축 등에 대해 살펴보겠습니다.   

// 솔리디티(Solidity) 프로그래밍에 앞 서 기억해야 할 것들.

go-ethereum 1.6.0 이후 버전부터 geth 상에서 RPC API 호출을 사용하여 솔리디티 검파일러인 solc를 호출하여 Solidity 소스를 컴파일수 없습니다.  따라서 geth 엔진상에서 solidity compiler를 RPC로 호출하여 컴파일할 수 있는 getCompilers() API 1.6.0 버전 이후에는 작동하지 않습니다.

 > web3.eth.getCompilers()

"Method does not exist/is not available" eth.getCompilers(), in geth console to eth_compilers, eth_compileSolidity are gone in go-ethereum 1.6.0

참고 : #3740에서 해당 기능 삭제되었고 #290에 그 이유가 설명이 되어 있습니다. web3에서 제공하는 객체중 eth 객체는 이더리움 노드의 코어 기능과 관련된 것들을 담당하는 데 solc 컴파일러 호출은 이 범위를 벗어나기 때문에 삭제했다고 합니다. 또한 이더리움은 저차원 EVM 바이트 코드를 처리해야 하는 데 고수준의 프로그래밍 언어와 관련된 API를 호출하는 것은 바람직하지 않다라는 입장입니다. 이해도 가는 만 이 기능은 아주 유용하고 편리한 기능한 기능이라 반드시 지원이 되었으면 합니다.

// 솔리디티 개발환경을 준비합니다.

솔리디티 프로그래밍을 위해서는 직접 로컬 컴퓨터상에 솔리디티 컴파일러를 설치하거나 Remix(aka.Brower-solidity) 같은 개발 도구를 사용하는 방법이 있습니다.  Remix 외에도 Ethreum Studio 처럼 여러 개발 툴들이 있으나 Remix가 가장 편리합니다. 왜냐하면 다른 복잡한 것을 설치할 필요없이 웹 브라우져를 통해 항상 최신 버전을 사용할 수 있기 때문입니다. 

Remix를 사용하기 위해 다음의 주소로 접속합니다.  참고로 OSX에서 사파리10.1.1.에서 작동이 원활치 않았고 , 크롬 59.0.3071.115 빌드에서는 사용하는 데 문제가 없었습니다. 여기서는 크롬을 기준으로 합니다.

https://remix.ethereum.org 

만약 온라인으로 접속하지 않고 로컬 컴퓨터 상에 Remix를 설치하여 사용하고 싶으면 Remix 소스 코드를 다운로드를 받은 후 사용하면 됩니다.  다음은  Brower-solidity 의 다운로드 링크입니다.

https://github.com/ethereum/browser-solidity/archive/master.zip

// Remix 를 사용법을 익혀 봅니다.

모든 제품을 사용하기 전에 매뉴얼은 한번 읽어 보는 게 낭패를 당하거나 시간을 낭비하지 않는 지름길이라 생각합니다. 적어도 어디에 뭐가 있는지는 알아야 제대로 활용할 수 있듯이 Remix로 솔리디티 개발을 위해서는 Remix 개발 환경에 대한 이해가 반드시 필요하다 생각합니다.  차근차근 살펴보면서 동시에 Solidity 프로그램도 함께 익숙해져 보겠습니다.

[그림 2-1 ] Remix 접속 후 첫화면. 총 3개의 영역(컬럼)으로 구성되어 있다.

Remix는 3개 영역으로 구성되어 있습니다 - 가장 왼쪽이 소스코드 브라우져 , 가운데가 소스코드 에디터 , 그리고 오픈쪽이 컨트랙의 컴파일 및 배포, 디버깅, 분석 등 다양한 관련 옵션 등을 처리하는 영역입니다.

// 소스파일 브라우져 영역 알아보기

[그림2-2] 소스 파일 영역

소스 파일 영역에서 <<+버튼 메뉴>>는 신규 파일 생성 , 그리고 <<폴더 버튼>>은 로컬 파일 열기 , 그리고 마지막 <<체인 버튼>>은 특정 로컬 폴더을 연결하여 사용하는 기능입니다. 실제 작업을 하다보면 체인 버튼이 아주 유용한데 이 부분은 나중에 뒤에서 별도로 설명하겠습니다. 최초 설치 후 소스 파일 영약에 제공되는 Ballot.sol은 Remix에서 제공하는 기본 예제 파일입니다.

[그림2-3] 소스 코드 에디터 영역

-소스 코드 편집 영역

중간은 소스코드 편집 영역으로 <<+버튼>>은 폰트 크기를 크게 ,  <<- 버튼>> 폰트 크기를 작게 해줍니다. 멀티 파일을 열어서 작업할 수 있습니다.

-컨트렉 조정 영역

마지막은 컴파일 및 배포 등 컨트롤 영역입니다.  이 영역을 잘 이해해야 솔리디티 개발을 고생하지 않고 할 수 있습니다. 

[그림2-4] 컨트랙 조정 영역

컨트랙 조정 영역중 Contract 탭에는 Environment 메뉴가 있는데 3개의 실행 환경 모드를 제공합니다 - Javescript VM , injected Web3 , Web3 provider.

다음은 각 실행 모드에 대한 설명입니다.

• Javescript VM - geth 노드 연결 없이 모든 개발이 로컬 컴퓨터의 Remix의 메모리상에서 이루어짐
• injected Web3 - Mist나 Metamask같이 Mist와 유사한 공급자에 의해 제공되는 실행 환경을 이용
• Web3 provider - 로컬 컴퓨터에서 작동되는 geth 노드에 연결하여 수행됩니다. 이 환경에서는 트렌젝션이 네트웍을 통해 전달될 수 있음.

위의 세가지 환경 중 가장 편리한 것이 Javascript VM입니다. 첫번째 수업해서 설명한 것처럼 보통 개발자가 컨트렉트를 만들고 이를 컴파일한 후 블록체인 상에 배포하고 작동시키기 위해서는 마이닝 작업을 통해 Ether와 Gas가 미리 준비되어 있어야 합니다. 또한 구동중인 Geth 노드에  RPC 로 연결하여 컴파일된 솔리디티 바이트코드를 EVM에 배포하고 이를 다시 이더리움 체인에 연결하기 위해 다시 마이닝하는 등 여러 작업들을 해야 만 트렌젝션의 실행 결과를 확인할 수 있습니다. 다행스럽게도 Remix의 Javascript VM 환경을 이용하면 이러한 모든 작업을 로컬 메모리상에서 Remix 에서 미리 준비해둔 자바스크립트 VM모듈을 통해 수행가능합니다. 따라서 본 수업에서는 Javascript VM 환경을 기본 환경으로 사용합니다. 실제  Javascript VM 환경으로 개발을 하고 이후 Web3 Provider 환경을 통해 실제 로컬에 설치된 geth 노드에 RPC로 연결하여 작업을 하면 편리합니다. 보통 개발자들이 개인 개발 환경에서 작업을 하고 이를 개발 이나 스테이징 환경에 올려서 테스트 하는 것과 동일한 하다고 생각하면 됩니다.

***************************************************

$$ 정확히 알고 가자. : Ether와 Gas

Remix 에서 <<Contract 메뉴>>를 보면 Gas Limit 이라는 항목이 있습니다. Gas는 한마디로 이더리움에서 트렌젝션을 실행시키기 위해 필요한 수수료입니다. 이더리움에서는 트렌젝션들이 모여 블럭이 되고 , 이 블럭을 체인에 연결하기 위해서는 마이닝 작업을 통해 해쉬 계산을 하고 합의 과정을 거쳐 가장 빨리 계산한 마이너가 해당 블록을 체인에 연결을 합니다. 이러한 블록 하나를 연결할 때 마이너는 현재 0.25 Ether를 받습니다. 또한  해당 블럭내에 있는 트렉젝션을 수행하기 위해 EVM 을 작동시키는 데 드는 대가를 Gas로 받습니다.  

트렌젝션 수수료를 Ether로 주지 않고 Gsd라는 단위를 사용하는 이유는 무엇일가요? 바로 Ether는 가상 화폐이기 때문에 변동성이 생길 수 있으나 Gas는 거의 변동이 되지 않습니다. 따라서 트렌젝션을 수행하는 EVM은 계산량에 따라 고정된 Gas 값을 받습니다. 이더리움의 가스 가격의 변동 차트를 보면 거의 변동이 없습니다.

https://etherscan.io/chart/gasprice , 이더리움 가스 가격의 변동 차트

Gas Limit은 트렌젝션 처리에 쓸 수 있는 Gas 최대 한도비용입니다. 이 비용이 높을 수록 트렌젝션이 우선 처리가 될 수 있습니다. 그러나 트렌젝션 처리시   Gas Limit을 초과하면 트렌젝션이 중단되고 Gas는 그냥 소비되게 됩니다.

*****************************************************

// 컨트랙트 배포(Create)

Remix는 원격지에 있는 solc 컴파일러를 사용하여 컴파일을 합니다. <<Setting메뉴>>에 들어가면 기본값으로 컴파일 옵션이 <<Auto Compile>>로 설정되어 있습니다. 반복해서 주기적으로 컴파일을 하기 때문에 불편하면 해제해 놓아도  됩니다.

Contract 탭에서  <<Create 버튼>>는 작성된 컨트랙을 geth 노드에 배포합니다. 물론 Web3 provider 환경에서 배포를 하기 위해서는 RPC설정이 된 상태로 geth가 미리 작동이 되고 있어야 합니다. 또한 컨트렉을 배포할 때 잠시 생각을 해 보면 이런 의문점이 생깁니다. 이더리움은 어카운트가 기본인데 계정은 어떻게 되나? 그리고 컨트랙을 배포할 때는 당연히 비용을 지불해야 하는 데 어떻게 되는 거지?   

잠시 생각해 보겠습니다. 먼저 Contract은 원래 Contrace Account 의 줄임말입니다. 따라서 컴파일 후 배포가 되면 자동으로 해당 컨트렉트 계정이 생기고 컨트랙트 주소가 만들어 집니다. 대신 일반 사용자 계정 ( EOAs , Externally Owned Accounts)과는 구별이 됩니다. 실제 컨트렉트 계정은 사용자 계정에 의해서만 작동되고, 작동되면 컴파일된 코드에 의해서만 컨트롤이 됩니다.  그리고 당연히 코드를 이더리움 상에 배포시 대가를 지불해야 합니다. 다행이도 Remix의 Javascript VM환경에서는 이 대가를 Remix 대신 처리를 해주니 별도의 마이닝 작업 등을 할 필요가 없습니다. 물론, Web3 provider 환경에서는 미리 Ether를 할당해 높거나 마이닝을 통해 직접 처리해야 합니다.

<<Create 버튼>>을 클릭하여 배포를 하면 아래 [그림2-5]처럼 ballot 컨트렉트를 컨트롤 할 수 있는 다양한 버튼들이 나타납니다. 분홍색으로 표시된 각 트렌젝션들은 실제 해당 값을 입력하여 실행하면 그 결과를 바로 확인할 수 있습니다.

[그림2-5] 컨트랙 배포 후 화면

// web3 provider 환경 사용하기

로컬 컴퓨터 상의 구동중인 geth 노드에 연결하여 사용하고 싶다면 web3 provider 환경 옵션을 선택해야 합니다.  <<web3 provider >>옵션을 선택하면 다음과 같이 로컬에 있는 이더리움 노드와 연결을 원하는 지 다시 한번 묻는 팝업 윈도우가 나타납니다.

[그림2-6] <<web3 provider >>옵션 선택 후 팝업 화면

<<확인>>버튼을 선택합니다. 다음과 같이 이더리움 노드의 IP 주소와 RPC 포트를 묻는 팝업 윈도우가 나타납니다.

[그림2-7] <<web3 provider >>옵션에서 서버의 Endpoting 입력  화면

로컬 컴퓨터의 IP 주소와 RPC 포트인 8080을 입력합니다. 수업1에서 우리는 이미 다음과 같이 로컬컴퓨터상에서 이더리움 노드를 작동시켜 놓았습니다.

MacBook-Pro:go-ethereum jhpark$  geth167 --identity "JayBlockChain" --rpc --rpcaddr "127.0.0.1" --rpcport "8080" --rpccorsdomain "*" --datadir "/Users/jhpark/go-ethereum/go-ethereum-1.6.7/build/bin/privatechain" --port "30303" --nodiscover --rpcapi  "db,eth,net,web3,personal" --networkid 1999 --mine console

// 개발시 로컬 폴더 연결하여 활용하기

Remix는 웹 기반이기 때문에 작업을 하다 보면 로컬상의 폴더를 연결해서 쓰면 편하겠다라는 생각이 듭니다. 앞서 살펴본 소스 파일 브라우져 영역에서 <<체인 버튼>>이 바로 로컬 파일을 연결하는 기능입니다.

해당 <<체인 버튼>>을 클릭하면 다음과 같이 로컬 파일을 연결하겠느냐라는 팝업 윈도우가 나타납니다.

[그림2-8] 로컬 폴더를 연결하겠느냐는 확인 팝업 윈도우

연결을 위해 <<Connect 버튼>>을 선택하면 다음과 같이 로컬 컴퓨터의 특정 폴더를 연결할 수 있습니다. 연결된 후에는 <<Connect 버튼>>이 녹색으로 변경됩니다.

 [그림2-9] 로컬 호스트 상의 특정 폴더를 연결한 후의 모습

 그런데 이렇게 특정한 로컬 폴더에 연결을 하기 위해서는 remixd라는 모듈을 설치하고 구동시켜야 만 합니다.

 //로컬 폴더를 연결하기 위해 remixd 설치하기

 remixd를 설치하기 위해서는 npm 이 필요합니다.  Npm(Node.js package echosystem)은 오픈소스 자바 스크립트 패키지 관리툴입니다. node.js 를 설치하면 자동으로 함께 설치됩니다. 

 먼저 , http://nodejs.org 에서 설치 파일을 다운로드 합니다. 제 경우 macOS용 V6.11.2 LTS버전을 다운로드 받아 설치했습니다. 설치 후 npm으로 다음과 같이 remixd 설치합니다.

    npm install -g remixd

  MacBook-Pro:~ jhpark$ npm install -g remixd

   remixd 설치 후 다음과 같이 Remix에서 연결하여 사용하고 싶은 공유 폴더를 -S옵션과 함께 지정하여 remixd 를 구동 시킵니다. 여기서는 /Users/jhpark/go-ethereum/contracts를 공유하였습니다. 

   remixd -S [로컬에서 공유할 폴더 위치]

 cBook-Pro:contracts jhpark$  remixd -S /Users/jhpark/go-ethereum/contracts

 [WARN] Any application that runs on your computer can potentially read from and write to all files in the directory.

 [WARN] Symbolinc links are not forwarded to Remix IDE

 Shared folder : /Users/jhpark/go-ethereum/contracts

 Fri Aug 04 2017 09:23:45 GMT+0900 (KST) Remixd is listening on 127.0.0.1:65520

 이제 Remix에서 공유한 폴더를 소스 파일 브라우져에서 연동하여 사용할 수 있습니다.

 // 첫번째 솔리디티 프로그램 작성 : SimpleStorage.sol 

 자 이제 어느 정도 준비가 되었으니 첫번째 아주 간단한 프로그램을 하나 작성하여 작동시켜 보겠습니다.

먼저 , Remix의 파일 브라우져 영역의 <<+ 메뉴>>를 선택하여 새로운 파일을 생성하고 다음의 내용을 입력합니다. 

이 경우 프로그램 파일은 로컬 브라우져 상에 저장이 됩니다. 가장 편리한 방법은 앞서 Remixd를 통해 공유한 

로컬 폴더내에 해당 파일을 원하는 에디터로 작성하는 것 입니다. 일단 파일을 작성하면 자동으로 Remix가 Remixd를

통해 해당 파일을 읽어 옵니다. 제 경우 /Users/jhpark/go-ethereum/contracts 폴더 밑에

SimpleStorage.sol를 vi를 사용하여 작성하였습니다.

pragma solidity ^0.4.0;

    contract SimpleStorage {

        uint storedData;

function set(uint x)

        {

            storedData = x;

        }

        function get() constant returns (uint)

        {

            return storedData;

        }

    }

위의 예제는 솔리디티 가이드 문서에서 첫번째로 나오는 예제 파일입니다. 보다 자세한 내용은 아래 링크를 참고하세요.

참고 : 솔리디티 개발 문서 : https://media.readthedocs.org/pdf/solidity/develop/solidity.pdf

작성 후 컴파일시 문법적 오류가 없다면  아래와 같은 화면이 나타납니다. 앞서 설명드린 것처럼 Remix는 auto compile을 합니다 ( <<settings 메뉴>> ).

 [그림2-10] SimpleStorage.sol 컴파일 후 화면

 이 프로그램은 무척 단순합니다. solidity ^0.4.0은 솔리디티 0.4.0으로 작성되었으니 업그레이드된 컴파일러가 나오더라도 이 파일은 0.4.0 방식으로 처리해 달라는 의미이며 , SimpleStorage  라는 이름의 contract는 내부의 상태가 256비트 크기의 unsigned integer 타입인 storedData와 이 상태에 값을 추가하는 set 이라는 이름의 function과 상태의 값을 알려주는 get function으로 구성되어 있습니다. 특별한 사용자 계정에 의해 조작되는 것이 없기 때문에 누구나 SimpleStorage를 이용해서 상태 값을 설정하거나 조회할 수 있습니다.

 작동을 시켜 보겠습니다!!.

 오른쪽에 <<Create>> 버튼을 눌러 컴파일된 솔리디티 바이트코드를 배포하겠습니다. 배포 후 [2-11] 처럼 화면 하단에 SimpleStorage 컨트렌트의 트렌젝션과 실행 비용에 대한 Gas 비용, 그리고 컨트렉트 주소 등이 나타납니다.

 [그림2-11] 배포 된 후 SimpleStorage 컨트렉트

 그리고 재미나게도 함수 set은 트렌젝션, get은 Call이라고 합니다. 왜 같은 함수를 구별할까요? 제 생각에 트렌젝션은 상태의 변화를 가져오는 것이고 , Call은 상태변화가 없어서 구별하는 것이 아닐까 싶습니다. 이후 계속 맞는 지 확인해 보겠습니다.

 set함수 실행 후 get 버튼을 클릭하여 수행하면 다음과 같이 내부의 상태 값이 1000으로 바뀐 것을 확인할 수 있습니다.

 [그림2-13] SimpleStorage 컨트렉트의 get 실행

마치는 말

지금까지 본격적인 스마크 컨트랙트 개발에 앞서  Remix를 사용하여 솔리디티 언어로 스마트 컨트랙트를 작성하고 이를 실행하는 등 기본 사항들을 살펴 보았습니다. 다음부터는 본격적으로 솔리디티를 통한 스마트 컨트렉트 프로그래밍에 대해 살펴 보겠습니다. 프로그래밍을 하면서 필요한 개념과 용어는 중간에 지속적으로 소개하도록 하겠습니다. 혹시, 잘못된 내용이나 추가할 내용있으면 지속적으로 알려주시면 수정하도록 하겠습니다.