Browse Category: 개발

개발 관련 카테고리

[블록체인]스마트계약 2(geth 설치)

ether 개발 환경을 설정하는 과정에 대해 설명하는 글이다.

Geth를 사용하기 위해서는 “Go”가 먼저 설치 되어야 한다.

Go를 설치하는 과정은 편한 방법으로…

우선 우분투 환경(AWS 우분투 사용)에서

Go version 을 확인했으면 Go 설치완료

geth version 확인 했으면 geth 설치완료

 

이후 ether를 사설 테스트넷에서 사용해보기 위해서는 최초 블럭 정보가 필요하다. 최초 블록 정보가 포함된 파일을 ether에서는 genesis 파일이라고 부른다.

원하는 위치에 genesis.json 을 만들고 geth 에 genesis 파일의 위치를 알려주면 된다.

genesis.json 파일

이후 geth에 genesis.json 의 위치를 등록시켜 주자

그리고 geth을 console에서 실행시켜 주면 ether 개발 환경 준비 끝

 

 

출처 : 블록체인 애플리케이션 개발실전 입문@위키북스

[블록체인]스마트계약(1)

 

스마트계약 이라는 용어는 비트코인 이전에 나온 개념이다.

스마트 컨트랙트는 Nick Szabo가 1994년 최초 제안한 개념입니다. 기존 계약서(Contract)는 서면으로 되어있어 계약 조건을 이행하려면 실제 사람이 계약서 대로 수행을 해야 하지만 디지털 명령어로 계약을 작성하면 조건에 따라 계약 내용을 자동으로 실행할 수 있는 것입니다.

94년도에 나온 스마트계약이라는 개념이 블록체인과 결합되며 새로운 기술로 등장했다고 보면될거 같다.

일단 스마트계약은 블록체인 네트워크 상에서 블록이 생성될때 블록과 함께 작동하는 특정 프로그램을 같이 넣어두는 것을 말한다. 좀더 정확히 말하면 스마트 계약은 블록체인에서 동작하는 응용프로그램의 단위이다.

사실 스마트계약의 개발 흐름은 서버/클라이언트 구조와 유사하다. 결국 지갑과 같은 노드(클라이언트)가 이더리움 네트워크(서버)에 연결되어 서버의 프로그램을 실행하며 특정 로직이 수행되는 구조다.

기존으 서버/클라이언트 구조와 비슷하다면 왜 스마트계약이 많은 관심을 받고 있는지 생각해보면 결국 블록체인의 장점 때문이다. P2P 네트워크상에서 배포되는 프로그램은 믿을수 없다.(누가 악성 프로그램을 배포할지 알 수 없음) 하지만, 블록체인은 합의 알고리즘을 통해 블록이 생성 되기 때문에 생성된 블록에 포함된 프로그램은 믿을 수 있을만하다고 생각하는 것이다. (이더리움은 캐스퍼라는 지분증명 방식의 합의알고리즘을 사용한다.)

또한, 스마트 계약의 함수들은 입력값과 그 소스들이 공개되어 있고 ABI라는 계약 객체를 통해 함수 내용을 누구나 확인 할 수 있다. 이런 배경을 바탕으로 결국 이더리움 네트워크에는 믿을 수 있는 스마트계약(프로그램)이 돌아 다니고 그 프로그램을 사용하는 노드들은 의심 없이 스마트계약을 실행하면 되는것이다.

스마트 계약을 예시로 이해해보겠다.

가령 A라는 소비자가 마트에서 물건을 구매했을 때(이더리움으로 전송) 트랜잭션이 발생한다. 이 때 ,블록에 포함되어 있던 스마트계약에 의해 A가 지불한 구매대금의 0.3%는 적립금으로 다시 A의 지갑으로 돌아간다. 그리고 해당 내용(구매 대금이 A->마트로 이동, 0.3%의 적립금 마트 -> A로 이동, 스마트계약 이행 Gas fee)이 포함된 블록이 생성된다.

다음글에서 좀 더 디테일한 스마트 계약을 살펴 보겠지만 스마트 계약에 대해 성급한 결론을 내리자면,

중앙의 기관(정부 or 은행)이 없는 상태에서 Node와 Node간에 트랜잭션이 일어날때 미리 준비된 스마트계약 이라는 프로그램이 강제로 실행되고 이렇게 해서 계약을 공증하는 기관이 없더라도 계약은 이행 된다는 것이 스마트 계약이다.

출처 : 블록체인 애플리케이션 개발실전 입문@위키북스 , https://blog.theloop.co.kr/2017/03/28/스마트-컨트랙트smart-contract-개요-1/

Continue Reading

비트코인 네트워크(비트코인 P2P 프로토콜)

블록체인에 대해서 공부하면서 항상 블록체인 네트워크가 어떻게 구성되는지 궁금했다.

해답은 안드레아스 안토노폴러스의 Mastering Bitcoin(비트코인, 블록체인과 금융의 혁신) 이라는 책에서 찾을 수 있었다.(블록체인 책중 가장 구체적이고 잘 정리된 책)

기본적으로 비트코인 네트워크를 구성하는 클라이언트는 세가지로 나뉜다.

  • Full Client : 비트코인 거래정보(Full BlockChain)을 가진 클라이언트
  • LightWeight Client: 사용자의 지갑과 라우트 노드만 가진 클라이언트(거래정보는 가지지 않음)
  • Web Client : 웹 클라이언트를 통해 접속하며 제3자의 서버에 지갑을 저장

하지만, 실제 비트코인 네트워크를 구성하는 노드는 ‘라우팅’, ‘블록체인 DB’ , ‘채굴’ , ‘지갑’ 같은 기능에 따라 다양하게 나눠지는데 크게

  • Reference Client : 사토시 클라이언트라고도 불리는 클라이언트로 모든 서비스(지갑,채굴, BlockChain DB , 라우터 )를 가진 노드
  • Full Block Chain Node : Full Client의 노드로 전체 거래내역을 가진 Full Node (지갑은 없음)
  • Mining Node : 채굴 기능을 가진 노드
  • Lightweight Wallet :  거래내역을 저장하지 않고 지갑 서비스와 라우팅 서비스를 가진 노드

로 나눠볼수 있다.(이외에도 기능에 따라 다양한 노드가 존재)

이렇게 기능에 따라 구성된 노드들은 비트코인 네트워크에 참여하며 서로 연결되어 있는데 비트코인 네트워크에 연결되기 위해서는 최소 하나 이상의 이웃 노드와 연결되어야 한다. 이때 이웃 노드와 연결하기 위해서는 TCP 통신을 하는데 8333 port(일반적으로 비트코인 포트로 알려짐)를 사용해서 서로 연결된다. 최초 연결시에는 오랜기간 안정적으로 동작되고 있는 seed node 를 기본으로 연결하거나 IP를 사용해서 연결될 노드를 선택할 수 있다.

그리고, 최초 클라이언트 내에는 기본적으로 최초블록만 가지고 있는데 연결된 이후에는 Full Client 일 경우 이웃 노드와 블록의 Height를 비교해서 최신 블록을 받아오는 일련의 프로세스를 따르게 된다.

“거래 풀(Transaction Pool) / UTXO( Unspent Transaction Output ) 데이터베이스”

이렇게 비트코인 네트워크에서는 각 노드들이 연결되어 거래가 성사될 경우(Wallet A -> Wallet B 로 이동) 해당 거래 내역은 거래 풀로 들어가게 된다. 이 거래 풀에 들어간 거래는 미승인 거래로 아직 블록체인에 포함되지 않은 거래들이다. 마이닝 노드는 거래 풀에서 미승인 거래들을 모아 블록을 생성하게 되고 보통 생성된 블록 이후 6개의 블록이 생성되면(6개 블록이 생성된 이후에는 변조가 불가능한 것으로 판단) 거래 취소가 불가능한 상태가 된다.

비잔틴 장군문제

비잔틴 장군 문제(The Byzantine Generals Problem)란 고대 동 로마 제국(비잔틴 제국)을 비유한 시스템 문제이다.

상호 간에 통신을 통해 어떤 합의를 해야 하는 경우 통신에 문제가 발생하거나 고의로 정보를 변경해 가짜 정보를 전달할 가능성이 있을 때 전체가 올바른 합의를 형성할 수 있는지는 묻는 문제이다.

해당 논문의 요약에는 상황을 아래와 같이 설명하고 있다.

This situation can be expressed abstractly in terms of a group of generals of the Byzantine army camped with their troops around an enemy city. Communicating only by messenger, the generals must agree upon a common battle plan. However, one or more of them may be traitors who will try to confuse the others. The problem is to find an algorithm to ensure that the loyal generals will reach agreement.

비잔틴 장군의 입장에서 상황을 살펴보자.

비잔틴 장군들은 예루살렘성(가정)을 공격하려고 한다. 각 장군들이 한마음으로 한시 한때에 공격하면 성을 함락하고 승리 할 수 있지만 합의된 계획을 세우지 못할경우 패배한다. 이 때 장군들 사이에는 배신자(합의된 메세지를 변조할 수 있는)가 있을 수 있을 때 어떻게 하면 하나의 계획으로 승리 할 수 있을까 라는 문제이다.(논문에 따르면 2/3 이상의 장군이 믿을 만할때 배신자의 방해에도 불구하고 승리 할 수 있다)

비잔틴 장군의 문제를 해결하기 위해 어느정도의 fault를 가정하는 비잔티움 장애 허용 시스템도 존재한다.

이제 블록체인의 입장에서 비잔틴 장군 문제를 바라보자. 블록체인은 비트코인에 사용된 분산원장의 기술에 기초한다. P2P 기반의 가상화폐에서는 악의적인 노드의 행동을 제한하는것이 굉장히 중요하다. 그래서 비트코인은 PoW라는 작업증명 알고리즘을 통해 비잔틴 장군 문제를 해결한다.

먼저, 각 노드에 풀기 어려운 문제를 제공하여 답을 찾아 올것을 주문한다. 이때 문제는 충분한 인원이 충분한 시간을 들여야 풀수 있는 문제이다. 확률적으로 찾을 수 있는 문제기 때문에 특정시간(10분)에 한번씩 답을 나온다면 해당 네트워크에는 충분한 노드가 답을 찾기 위해 노력하고 있다고 믿을 수 있다. 믿을 만한 수의 노드가 참여한 네트워트에서 선출된 하나의 노드가 블록을 생성함으로 신뢰할 만한 노드를 선정한다. 그리고 새롭게 생성된 블록은 이전에 존재하던 블록에 연결된다. 새롭게 생성된 블록을 받은 노드는 블록해쉬를 확인해서 확인된 블록은 새롭게 블록체인에 연결(새롭게 생성될 블록을 악의적으로 수정하기 위해서는 이전 모든 블록의 값을 수정해야해서 이론적으로 불가능)

 

PoW를 비잔틴 장군의 상황에 넣어서 이해해보자.

5명(A,B,C,D,E)의 장군이 있다.

  1. A장군이 B장군에게 10시에 공격하는 계획을 전달한다(최초의 블록)
  2. B장군은 A장군의 서명을 포함한 메세지를 10분정도 걸리는 암호화 작업을 진행한다. 이후 암호화 된 메세지를 C장군에게 전달한다.
  3. C장군은 B장군에게서 받은 메세지를 해석해서 A장군의 서명을 확인하고 B장군의 10분간의 암화화 작업 기록을 확인한다.
    배신자인 C장군은 이 작전이 실패하기를 바란다. 그래서 작전시간을 9시로 위조하고 10분간 암호화 작업을 진행한다. 그리고 D장군에게 전달한다.
  4. D장군은 메세지를 해석하고 A장군이 B장군에게 10시 공격계획을 전달한것과 B장군이 C장군에게 10시 계획을 전달한 것을 확인한다. 하지만 C장군의 암호화 작업을 확인한 결과 계획이 9시로 변경된것을 확인한다.
  5. D장군은 C장군의 메세지가 악의적으로 편집된 것을 확인하고 10시 공격 계획을 E장군에게 전달한다.

PoW과 비잔틴 장군의 예시가 정확히 맞지 않아 이해하는데 방해가 될 수도 있다. 그럼에도 예시를 넣어둔 것은 큰 틀에서 블록체인이 어떻게 비잔틴 장군 문제를 해결하는가를 설명하기 위해 작성하였음을 참고하시기 바란다.

 

* 참고 : http://goodjoon.tistory.com/256https://ko.wikipedia.org/wiki/비잔티움_장애_허용 , https://steemit.com/kr/@twinbraid/1npff , 블록체인 구조와 이론@위키북스, http://bnrg.cs.berkeley.edu/~adj/cs16x/hand-outs/Original_Byzantine.pdf(논문원본)

블록체인 Intro

이글은 블록체인 구조와 이론을 읽으며 블록체인에 대해 공부한 내용을 요약한 것입니다.

Intro

  • 블록체인
    블록체인의 기술에 대해 공부하려면 4가지 기술에 대한 복합적인 이해가 있어야한다.
    1) ‘블록체인’ 그 자체에 대한 아키텍쳐
    2) 블록체인이 공유 되는 P2P 네트워크
    3) 어떤 블록을 accept 할지를 결정하는 합의 알고리즘
    4) Nonce 값을 찾아서 블록해쉬를 생성하는 해쉬

블록체인이 시작된 역사를 보면 블록체인은 비트코인의 분산원장을 구현하기 위해 사용된 기술이다. 그래서 위 4개의 기술들은 블록체인의 구현보다는 가상화폐의 구현 기술에 가까워 보인다. 그래서 혹자는 가상화폐 구현을 위한 4가지 기술이라고 이야기 할 수도 있다. 그러나 책을 읽으면서 느끼는점은 가상화폐(비지니스)에서 블록체인(기술)을 분리하는 방향으로 기술이 발전해 가고 있다는 것이다. 가상화폐는 블록체인을 이용한 비지니스라는 것을 인지하면서 4가지 기술에 대한 이해를 바탕으로 블록체인에 대해 이해해보려고 한다.

먼저 블록체인에 대해 알아보자. 네이밍만 따라서 이해한다면 블록을 체인으로 연결해놓은 그림을 그릴 수 있다.

하지만, 어떤 블록을 생성해서 어떻게 연결한다는 말인가?

답을 찾아보자면, 블록의 생성을 위해서는 합의 알고리즘이 그리고 블록을 연결하기 위해서는 전자서명과 해쉬를 이용해야 한다는 것이다.

잠깐 가상화폐 중 비트코인에 사용된 합의 알고리즘을 이용해 블록을 연결하는 과정을 살펴보자.

 

블록의 생성

비트코인은 Proof of Work(계산량에 따른 증명 , PoW)이라는 합의 알고리즘을 사용한다.

PoW를 극단적으로 설명하면 10분에 당첨자가 한명씩 나오는 로또가 있다고 가정하자. 이 로또는 특이하게 이미 당첨번호가 선정되어 있다. 그리고 로또 게임에 참여하는 사람은 모든 경우의 수를 고려해서 6자리 숫자를 만들어 나가며 당첨번호를 찾아간다. 그 과정에서 경우의 수를 빠르게 계산한 사람이 당첨번호를 찾으면 당첨금을 받아가고 그 사실이 전세계에 공표된다.

위의 로또 게임에서는 두가지 가정이 있다. 1)당첨자는 10분에 한명씩만 나온다. 2)당첨 번호를 가장 빠르게 찾는 사람은 당첨금을 가지고 갈 권리가 있다.

무슨 로또냐고 반문하겠지만, PoW는 CPU 파워를 이용해 10분(예시)에 한번씩 답을 찾을 수 있는 확률을 가진 해쉬 값을 찾는 사람이 블록을 생성하고 보상으로 비트코인을 가지고 가는 알고리즘이다. 이 알고리즘은 P2P 네트워크에서 비잔틴장군의 문제를 해결하는 대표적인 알고리즘으로 알려져 있다.(Intro에서 다 설명할수 없다 천천히…)

P2P 네트워크에서는 중앙집권식의 서버에서 작업에 대한 신뢰를 보장하지 않기 때문에 PoW에서는 CPU파워가 가장 높은 사람을 믿겠다 라고 이야기하는 것이다. 그리고 그 사람이 블록을 생성할 권리를 가지게 되는 것이다.

이렇게 블록은 생성 되었고 이전 블록과는 어떻게 연결하는지 알아보자

 

블록의 연결

생성된 블록에는 크게 앞블록의 정보 및 현재 블록의 정보(고정된 정보) 와 Nonce 라 불리는 해쉬 계산에 필요한 정답으로 구성되어 있다. 고정된 정보를 바탕으로 모든 경우의 Nonce 값을 계산해서 블록해쉬 값을 찾아야 한다.(SHA256 해쉬 함수를 적용해서 계산되는 값)

Nonce 값을 찾은 유저는 해당 블록을 블록체인 네트워크에 전파하고 각 노드는 새롭게 생성된 블록을 검증해서 로컬 블록체인에 추가한다. 결국 블록해쉬는 이전 블록의 블록해쉬값을 가지고 있고 이는 링크드 리스트처럼 블록을 연결하는 역활을 한다.

블록의 생성시 서로 다른 노드간 충돌에 대해서는 어떻게 관리할까? 간단히, 생성 후 많은 블록이 연결된 노드가 더 신뢰할 만하다고 판단한다.(충돌 트렌트 차트 – https://blockchain.info/charts/n-orphaned-blocks)

 

일단 마무리

글쓴이처럼 블록체인에 대해 이제 공부해보려는 사람이 많을 것이다. 하지만 정보도 많이 없고 정의도 제각각이고 개념은 어렵고.. 산넘어 산일수도 있다.(혹은 천재여서 다 이해할지도) 이 글에 담은 내용이 맞는지도 확신할 수 없다. 하지만 여러 reference를 바탕으로 스터디 한 내용을 공유한다. 그리고 잘못된 내용이 있다면 자유롭게 토론할 수 있었으면 좋겠다.

일단, 블록을 어떻게 생성하고 연결하는지에 대해 알아봤다. 다음에는 각 기술 요소에 대해 더 자세하게 스터디하는 글을 준비하겠다.

 

*출처 : 블록체인 구조와 이론, 예제로 배우는 핀테크 핵심 기술@위키북스,

https://homoefficio.github.io/2017/11/19/블록체인-한-번에-이해하기/

[알고리즘]알고리즘 설계의 다섯가지 접근법

코딩인터뷰 완전분석 (게일 라크만 맥도웰 지음 ) 을 공부하면서 작성하는 글입니다.

알고리즘 문제를 풀기위한 설계는 5가지의 접근법이 있다.

  1.  예증
    일반적 규칙을 유도해내서 문제를 해결한다.
    ex) 거리, 시간 그리고 속도에 관한 문제 해결
  2. 패턴매칭
    기존의 문제와 유사한 문제를 떠올리고 그 문제의 해답(가령 알고리즘)을 수정해서 적용한다.
  3. 단순화와 일반화
    자료형이나 데이터 양과 같은 제약조건을 변경해서 문제를 단순화 해본다.
    단순화 된 버전의 문제를 해결한다면 최종적으로 일반화해서 찾은 알고리즘을 복잡한 형태로 다듬어 간다.
  4. 초기사례로부터의 확장
    초기사례(n=1)에 대해 문제를 푼다. 후에 n=2에 대한 문제를 풀어보고 n=3를 풀어본다.
    이후 N-1을 안다면 N을 어떻게 찾을 수 있을지 고민해보고 규칙을 찾아 문제를 해결한다.
  5. 자료구조 브레인스토밍
    일련의 자료구조를 차례대로 적용해보고 적절한 알고리즘을 찾아나가는 방법이다.
    연결리스트? 이진트리? 힙? 처럼 여러 자료구조를 이해하고 적응시킬 수 있는 능력이 중요하다.

이렇게 5가지 접근법으로 문제를 풀어나가 보자. 물론 기본적인 자료구조에 대한 이해는 반드시 필요하다.

출처 : 코딩인터뷰완전분석

2급수표

코딩인터뷰 완전 분석이라는 책을 보면 2급수표를 먼저 외우라고 요구한다.

2의 10승 까지야 보통은 외우고 있을 테지만..

그 후에 2의 16이 64K이고 2의 20승이 1MB 이며 2의 30승이 1GB 이라는 점은 외워두자

x 2^x 근사값 메모리 요구량(Bytes)
7 128
8 256
10 1,024 1,000(천) 1K
16 65,536 64K
20 1,048,576 1,000,000(백만) 1MB
30 1,073,741,824 1,000,000,000(십억) 1GB
32 4,294,967,296 4GB
40 1,099,511,627,776 1,000,000,000,000(조) 1TB

 

 

*출처 : https://github.com/loustler/data-structure-algorithm/wiki/2%EA%B8%89%EC%88%98%ED%91%9C(Power-of-2)

[Java]Java 8

Java 8은 2014년 발표된 Java의 Version 8 이다.

Java 5 이후로 Version  6, 7 도 있었지만 Version 8이 중요한 이유는 언어 자체에 변화가 있었던 버전업이기 때문이다. 그래서 Java에 대한 지식을 누군가가 물어본다면 Java 8에 대한 점은 기존의 자바 언어와 별개의 언어처럼 물어보는 경우도 있다. 그만큼 Java 8은 새로운 세상이다.

가장 큰 특징은 Lambda, Map , Filter 같은 함수형 언어의 여러 개념이 도입한 것이다.

함수형 언어에 대한 이야기는 http://kwangshin.pe.kr/blog/2013/01/21/번역-함수형-프로그래밍functional-programming-기초 에서 확인할 수 있다.

함수형 언어의 특징을 이해하면 왜 Java 8이 함수형 언어의 개념을 도입했는지 이해할 수 있다. 프로세서의 성능이 높아짐에 따라 소프트웨어는 그것을 활용할 수 있는 방향으로 발전해나가야 하기 때문이다.

publish/subscribe model

구글의 GCM(이전엔 FCM으로 불렸음)을 사용면서 GCM이 가진 많은 기능 중 Topic 메세지를 사용할 케이스가 있었다.  Topic 메세지는 publish/subscribe model에 기반을 둔 push service인데, 그 과정은 아래와 같다.

서버 혹은 메세지를 보내는 주체가 메세지를 publish 하면 메세지의 발송 성공 여부는 확인하지 않는다. 그냥 publish 할 뿐이다. 한편, 해당 토픽에 대해 subscribe를 한 subscriber들은 메세지가 publish 되면 해당 메세지를 수신 할 수 있게 된다. 결국 publish/subscribe 모델에서는 publisher와 subscriber들은 서로를 알필요가 없다. 각자의 역활(메세지를 publish/메세지를 수신)만을 수행하면 되는 모델인 것이다.

publish/subscribe 모델이 작동하기 위해서는 publish 된 메세지가 해당 토픽을 선택한 subscriber에게 메세지가 발송 되도록 중간에서 브로커 역활을 하는 모듈이 존재한다.

이렇게 publish/subscribe 모델 기반의 시스템의 경우 publisher와 subscriber 간에 낮은 결합도를 가진 시스템을 구축 할 수 있으며 이를 통해 시스템 확장성에 있어 큰 장점을 가질 수 있게 된다.

그러나, 메세지 전송에 대한 정확한 피드백을 받기가 어렵고 악의적인 메세지가 publish 되었을때 브로커가 그것을 필터링하는데 어려움이 존재한다.

 

참고: http://blog.naver.com/PostView.nhn?blogId=hisukdory&logNo=50109265674 , https://developers.google.com/cloud-messaging/topic-messaging