Mastering Ethereum 3

개발새발·2021년 10월 16일
mastering ethereum
1

Mastering Ethereum

목록 보기
3/7
post-thumbnail

Chapter 3. 이더리움 클라이언트

본 글은 『Mastering Ethereum』을 읽고 정리한 내용입니다.

1. 이더리움 클라이언트

이더리움 클라이언트는 이더리움 사양을 구현하고 다른 이더리움 클라이언트와 피어투피어 네트워크를 통해 통신하는 소프트웨어 애플리케이션이다. 기준 사양과 표준 통신 프로토콜을 준수한다면, 서로 다른 이더리움 클라이언트들끼지 상호운용(interoperate)이 가능하다. 이러한 서로 다른 클라이언트가 다른 팀과 다른 프로그래밍 언어로 구현되는 동안 이들은 모두 동일한 프로토콜로 소통(speak)하고 동일한 규칙을 따른다. 따라서 이들은 모두 동일한 이더리움 네트워크에서 운영 및 상호작용하는데 사용될 수 있다.

이더리움은 오픈 소스 프로젝트이며, 모든 주요 클라이언트의 소스 코드는 오픈 소스 라이선스(예: LGPL v3.0)하에서 사용할 수 있으므로 무료로 다운로드하여 다른 용도로 자유롭게 사용할 수 있다. 오픈 소스란 단순히 자유롭게 사용할 수 있는 것 이상을 의미한다. 또한 이더리움은 공개 기여자 커뮤니티에 의해 개발되어 누구든지 수정할 수 있다. 참여자가 많을수록 신뢰할 수 있는 코드가 된다.

이더리움은 황서라는 공식 사양에 의해 정의된다.

하지만 비트코인은 이와 달리 공식적인 방식으로 정의되지 않는다. 비트코인의 사양이 비트코인 코어(Core) 기준 구현체인 반면, 이더리움은 영어와 수학(공식) 사양이 결합되어 문서화되어 있다. 이 공식 사양은 다양한 이더리움 개선 제안과 함께 이더리움 클라이언트의 표준 작동 방식을 정의한다. 황서는 이더리움에 주요 변경사항이 적용됨에 따라 주기적으로 업데이트 된다.

이더리움은 각 클라이언트가 구현해야 될 사양에 대해 명확한 기준을 제시하고 있기 때문에, 독립적으로 개발된 클라이언트들도 대부분 상호운용이 가능하다. 이더리움은 다른 블록체인보다 네트워크에서 실행되는 구현의 다양성이 더 크며, 이는 일반적으로 좋은 점으로 평가된다. 실제로 이더리움은 네트워크 공격을 방어하기 위한 훌륭한 방법으로 입증되었다. 왜냐하면 특정 클라이언트의 구현 전략을 악용하는 것은 개발자가 공격을 패치하는 동안 개발자를 괴롭히지만 다른 클라이언트는 네트워크에 거의 영향을 주지 않기 때문이다.

2. 이더리움 네트워크

이더리움 기반 네트워크 중에는 이더리움 황서에서 정의된 공식 사양에 부합하지만, 서로 간에 상호운용될 수도 있고 그렇지 않을 수도 있는 것들이 많이 있다.

이더리움 기반 네트워크는 이더리움, 이더리움 클래식(Classic), 엘라(Ella), 익스팬스(Expanse), 유비크(Ubiq), 뮤지코인(Musicoin) 및 기타 여러 네트워크가 있다. 대부분 프로토콜 수준에서 호환되는 반면, 이더리움 클라이언트 소프트웨어의 관리자가 각 네트워크를 지원하기 위해 작은 변경을 요구하는 기능 또는 속성을 갖고 있는 경우가 많다. 이 때문에 이더리움 클라이언트 소프트웨어의 모든 버전이 모든 이더리움 기반 블록체인을 실행하는 것은 아니다.

현재 여섯 가지 언어로 작성된 이더리움 프로토콜의 여섯 가지 기본 구현이 있다.

  • 러스트(Rust)로 작성된 패리티(Parity)
  • 고(Go)로 작성된 게스(Geth)
  • C++로 작성된 cpp-ethereum
  • 파이썬(Python)으로 작성된 pyethereum
  • 스칼라(Scala)로 작성된 맨티스(Mantis)
  • 자바(Java)로 작성된 하모니(Harmony)

이번 장에서는 가장 일반적인 2개의 클라이언트인 패리티와 게스에 대해 살펴볼 것이다. 각 클라이언트를 사용하여 노드를 설정하고 커맨드 라인(command-line) 및 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API) 중 일부를 탐색하는 방법을 학습한다.

2-1. 풀 노드를 실행해야 하는가?

블록체인의 건전성(health), 복원력(resilience), 검열 저장(censorship resistance) 특성은 독립적으로 운용되고 지리적으로 분산된 풀 노드(full node)가 얼마나 많은지에 달려있다. 각각의 풀 노드는 다른 새 노드가 블록 데이터를 얻어 작업을 부트스트랩(bootstrap)하고, 운영자에게 모든 트랜잭션 및 컨트랙트에 대해 신뢰할 수 있고 독립적인 검증을 제공할 수 있도록 도와준다.

그러나 풀 노드를 실행하면 하드웨어 자원 및 대역폭 비용이 발생한다. 풀 노드는 80 ~ 100GB 정도의 데이터를 다운로드해야 하며(2018년 9월 기준이며 클라이언트에 따라 다르다), 로컬 하드 디스크에 저장해야 한다. 새로운 트랜잭션 및 블록이 추가되면서 매일 이러한 데이터 부담이 상당히 빠르게 증가한다.

이더리움 개발에는 메인넷(mainnet) 네트워크에서 실행 중인 풀 노드가 필요하지 않다. 테스트넷(testnet) 노드(작은 공개 테스트 블록체인 중 하나에 연결), 가나슈(Ganache) 같은 로컬 사설 블록체인 또는 인퓨라(Infura) 같은 서비스 공급자가 제공하는 클라우드 기반 이더리움 클라이언트로 원하는 대부분의 작업을 수행할 수 있다.

블록체인의 로컬 사본을 저장하지 않거나 블록 및 트랜잭션의 유효성을 확인하지 않는 원격 클라이언트를 실행할 수도 있다. 이 클라이언트는 지갑의 기능을 제공하며 트랜잭션을 생성하고 전파할 수 있다. 원격 클라이언트를 사용하여 자신의 풀 노드, 공개 블록체인, 공개 또는 허가된(권위증명(Proof-of-Authority)) 테스트넷 또는 개인 로컬 블록체인 같은 기존 네트워크에 연결할 수 있다. 실제로 다른 모든 노드 옵션 간에 전환하기 위한 편리한 방법으로 메타마스크(MetaMask), 에메랄드 지갑(Emerald Wallet), 마이이더월렛(MyEtherWallet), 마이크립토(MyCrypto) 같은 원격 클라이언트를 사용할 것이다.

원격 클라이언트 및 지갑이라는 용어는 혼용되어 사용되기도 하지만 서로 다른 점이 있다. 일반적으로 원격 클라이언트는 지갑의 트랜잭션 기능 외에도 API(예: web3.js API)를 제공한다.

이더리움의 원격 지갑 개념을 라이트 클라이언트(light client, 비트코인의 간이 결제 확인(Simplified Payment Verification) 클라이언트와 유사함)의 개념과 혼동하면 안 된다. 라이트 클라이언트는 블록 헤더의 유효성을 검사하고, 머클(Merkle) 증명을 사용하여 블록체인에서의 트랜잭션 포함 여부를 확인하고 그 영향도를 결정하여 풀 노드에 대해 비슷한 수준의 보안을 제공한다. 반대로, 이더리움 원격 클라이언트는 블록 헤어 또는 트랜잭션의 유효성을 검사하지 않는다. 그들은 풀 클라이언트(full client)를 신뢰하여 블록체인에 대한 접근 권한을 부여하므로 보안 및 익명성 보장 수준이 상당히 떨어진다. 여러분 스스로 실행하는 풀 클라이언트를 사용하여 이러한 문제를 완화할 수 있다.

2-2. 풀 노드의 장단점

풀 노드를 실행하기로 선택하면 네트워크를 연결하는 데 도움이 되지만, 일정 수준의 비용이 발생한다. 몇 가지 장단점을 살펴보자.

장점

  • 이더리움 기반 네트워크의 복원력과 검열 저항을 지원한다.
  • 모든 트랜잭션을 정식으로 검증한다.
  • 중개자 없이 공개 블록체인의 모든 컨트랙트와 상호작용할 수 있다.
  • 중개자 없이 컨트랙트를 공개 블록체인에 직접 배포할 수 있다.
  • 블록체인 상태(계정, 스마트 컨트랙트 등)를 오프라인에서 조회할 수 있다(읽기 전용).
  • 여러분이 읽은 정보를 제3자에게 노출하지 않고 가져올 수 있다.

단점

  • 하드웨어와 대역폭 자원의 확대가 필요하다.
  • 처음 시작할 때 전체 동기화를 위해 여러 날이 소요된다.
  • 동기화를 유지하기 위해 관리하고, 업그레이드하고, 온라인 상태로 유지해야 한다.

2-3. 공개 테스트넷의 장단점

풀 노드를 선택하든 아니든, 여러분은 아마도 공개 테스트넷 노드를 실행하기를 원할 것이다. 공개 테스트넷을 사용할 때의 장단점을 알아보자.

장점

  • 테스트넷 노드는 훨씬 적은 데이터(네트워크에 따라서 약 10GB)와 동기화를 필요로 한다(2018년 4월 기준).
  • 테스트넷 노드는 몇 시간 내에 전체 동기화를 할 수 있다.
  • 컨트랙트 배포 및 트랜잭션 생성을 위한 테스트용 이더를 몇몇 Faucet으로부터 무료로 얻을 수 있다.
  • 테스트넷은 다른 많은 스마트 컨트랙트가 동작(live) 실행 중인 공개 블록체인이다.

단점

  • 테스트넷에서는 실제(real) 돈을 사용할 수 없다. 테스트 이더로 실행한다. 따라서 위험에 처할 만한 일이 없으므로 악의적 사용자들에 대응하는 실전 보안성 테스트를 할 수 없다.
  • 테스트넷에서는 퍼블릭 블록체인에서만큼 실전 테스트를 할 수 없는 측면이 있다. 예를 들면, 테스트넷에서는 실제 트랜잭션 시 필수적으로 발생하는 비용인 가스 수수료를 고려하지 않는다. 더구나 테스트넷은 공개 메인넷에서 때때로 발생하는 네트워크 혼잡이 없다.

2-4. 로컬 블록체인 시뮬레이션 장단점

많은 테스트 목적에 가장 좋은 선택은 단일 인스턴스 사설 블록체인을 실행하는 것이다. 가나슈(Ganache, 이전 이름은 testrpc)는 다른 어떤 참여자들 없이 상호작용할 수 있는 가장 인기 있는 로컬 블록체인 시뮬레이션 중 하나다. 가나슈는 공개 테스트넷의 많은 장단점을 공유하지만 약간의 차이가 있다.

장점

  • 동기화가 없고 디스크에 데이터가 거의 없다. 직접 첫 번째 블록을 채굴한다.
  • 테스트 이더를 얻을 필요가 없다. 테스트를 위해 사용할 수 있는 채굴 보상을 자신에게 수여(award)한다.
  • 다른 사용자는 없고 단지 자신만 있다.
  • 다른 컨트랙트는 없고 단지 자신이 시작하고 배포한 컨트랙트만 있다.

단점

  • 다른 사용자가 없다는 건, 공개 블록체인과 동일하게 동작하지 않는다는 뜻이다. 트랜잭션 순서나 트랜잭션 공간을 두고 경쟁이 없다.
  • 자신 외에 채굴자가 없다는 건, 채굴이 더욱 예측 가능하다는 뜻이다. 그러므로 공개 블록체인에서 발생하는 일부 시나리오를 테스트할 수 없다.
  • 다른 컨트랙트가 없다는 건, 테스트를 위해 의존성을 갖는 것들과 컨트랙트 라이브러리를 포함하여 원하는 모든 것을 자신이 배포해야 한다는 뜻이다.
  • 어떤 시나리오를 테스트하기 위한 공개 컨트랙트와 주소를 다시 만들지 못할 수도 있다(예: DAO 컨트랙트).

3. 이더리움 클라이언트 실행

만약 여러분에게 시간과 자원이 있다면, 절차에 대해 좀 더 배우기 위해서라도 풀 노드의 실행을 시도해 봐야 한다. 다음 절에서는 이더리움 클라이언트인 패리티(Parity)와 게스(Geth)를 다운로드, 컴파일, 실행할 것이다. 이를 위해 운영체제에서 커맨드 라인 인터페이스를 사용하는 데 익숙해져야 한다. 테스트넷 노드로 풀 노드를 실행하는 것을 선택하든지 아니면 로컬 사설 블록체인을 위한 클라이언트를 선택하든지 간에, 이러한 클라이언트를 설치해 보는 것은 도움이 될 만한 일이다.

3-1. 풀 노드를 위한 하드웨어 요구사항

시작에 앞서 이더리움 풀 노드를 실행하기 위해 컴퓨터가 충분한 자원을 갖고 있는지 확인해야 한다. 이더리움 블록체인의 전체 사본을 저장하기 위해서는 적어도 80GB의 디스크 공간이 필요하다. 만약 이더리움 테스트넷에서 풀 노드를 실행하기를 원한다면 적어도 15GB가 더 필요하다. 80GB 블록체인 데이터를 다운로드하는 데는 오랜 시간이 걸린다. 그래서 고속 인터넷에 접속하기를 권한다.

이더리움 블록체인을 동기화하는 것은 매우 많은 입출력(I/O)을 필요로 한다. 가장 좋은 방법은 솔리드 스테이트 드라이브(Solid-State Drive, SSD)를 준비하는 것이다. 만약 기계식 하드 디스크 드라이브(Hard Disk Drive, HDD)를 갖고 있다면 캐시(cache)를 사용하기 위해 적어도 8GB RAM이 필요할 것이다. 그렇지 않으면 너무 느려서 완전히 동기화되지 않을 수도 있다.

최소 요구사항

  • 2코어 이상의 CPU
  • 적어도 80GB의 여유 스토리지 공간
  • 최소 4GB RAM SSD (HDD의 경우 8GB 이상)
  • 다운로드 속도가 초당 8MBit인 인터넷 서비스

이것은 이더리움 기반 블록체인의 전체(하지만 정리된) 사본을 동기화하기 위한 최소 요구사항이다.

2018년 4월 시점에 패리티 코드베이스(codebase)가 리소스를 좀 더 적게 사용하기 때문에 만약 제한된 하드웨어에 실행한다면 패리티를 사용하는 것이 더 낫다.

만약 좀 더 빠른 시간 내에 동기화하고 모든 개발 도구, 라이브러리, 클라이언트 및 이 책에서 논의한 블록체인을 저장하고 싶다면, 더 고성능의 컴퓨터를 사용하는 것이 좋다.

추천 사양

  • 4코어 이상의 빠른 CPU
  • 16GB 이상의 RAM
  • 메모리 여유 공간이 적어도 500GB인 빠른 SSD
  • 다운로드 속도가 초당 25MBit 이상인 인터넷 서비스

블록체인의 크기가 얼마나 빨리 증가할지, 디스크 공간이 더 필요할지 예측하기가 어렵기 때문에 동기화를 시작하기 전에 블록체인의 가장 최근 데이터 용량을 확인하는 것이 좋다.

위에서 언급한 디스크 크기 요구사항은 오래된 상태 데이터에 대해 분기된(pruned) 블록체인에서 기본 설정으로 노드를 실행한다고 가정했다. 모든 상태가 디스크에 보관되는 전체 기록(archival) 노드를 실행한다면 1TB 이상의 디스크 공간이 필요할 수 있다.

다음 링크는 블록체인 크기에 대한 최신 추정치를 제공한다.

3-2. 클라이언트(노드)를 빌드하고 실행하기 위한 소프트웨어 요구사항

이번 절에서는 패리티와 게스 클라이언트 소프트웨어에 대해 다룬다. 유닉스 같은 커맨드 라인 환경을 사용한다고 가정한다. 예제에서는 bash shell을 실행하는 우분투 GNU/리눅스 운영체제에서 나타나는 명령과 출력을 보여준다.

일반적으로 모든 블록체인에는 자체 버전의 게스가 있다. 패리티는 동일한 클라이언트 다운로드를 통해 여러 이더리움 기반 블록체인(이더리움, 이더리움 클래색, 엘라이즘, 익스팬스, 뮤지코인)을 지원한다.

패리티는 OpenSSL과 libudev같은 소프트웨어 라이브러리가 필요하다. 우분투 혹은 데비안 GNU/리눅스 호환 시스템에 소프트웨어 라이브러리를 설치하기 위해 다음 명령을 사용하라.

$ sudo apt-get install openssl libssl-dev libudev-dev cmake

3-3. 패리티

패리티(Parity)는 풀 노드 이더리움 클라이언트 및 댑 브라우저를 구현한 것이다. 패리티는 모듈식의 안전하고 확장 가능한 이더리움 클라이언트를 구축하기 위해 시스템 프로그래밍 언어인 러스트를 기반으로 작성되었다. 패리티는 영국 회사인 패리티 테그(Parity Tech)에서 개발했으며, GPLv3 무료 소프트웨어 라이선스하에 출시되었다.

이 책의 저자 중 한 명인 개빈 우드는 패리티 테크의 설립자이며, 패리티 클라이언트의 대부분을 개발했다. 패리티는 설치된 이더리움 클라이언트들 중에서 25%를 차지한다.

패리티를 설치하려면 러스트 패키지 관리자인 cargo를 사용하거나 깃허브에서 소스 코드를 다운로드할 수 있다. 패키지 관리자는 소스 코드를 다운로드할 수 있어서 두 가지 선택 간에 별 차이점은 없다.

패리티 설치

rustup을 사용하여 이미 러스트를 설치했다고 가정한다.

먼저 깃허브에서 소스 코드를 받는다.

$ git clone https://github.com/paritytech/parity

parity 디렉토리로 변경하고 cargo를 사용하여 실행 파일을 작성한다.

$ cd parity
$ cargo install

--version 옵션으로 패리티가 잘 설치되어있는지 확인해본다.

$ parity --version

패리티가 설치되었다면 블록체인을 동기화하고 기본 커민드 라인 옵션을 시작할 수 있다.

3-4. 게스

게스(Go-Ethereum, Geth)는 이더리움 재산에서 고(Go) 언어로 개발하였으며, 이더리움의 공식 클라이언트다. 일반적으로 모든 이더리움 기반 블록체인은 자체 게스 구현을 갖고 있다. 만약 게스를 실행하고 있다면, 다음 저장소 링크 중 하나를 사용하여 블록체인에 적합한 버전을 찾아야 한다.

이러한 설명을 무시하고, 선택한 플랫폼에 맞는 바이너리(binary)를 설치할 수도 있다. 사전 컴파일된 배포본이 설치하기가 훨씬 쉽고 위에 나열된 저장소의 배포(releases) 섹션에서 찾을 수 있다. 그러나 소프트웨어를 직접 다운로드하고 컴파일함으로써 더 많을 것을 배울 수 있다.

저장소 클론

첫 번째 단계는 깃 저장소를 클론(clone)하여 소스 코드 사본을 얻는 것이다.

$ git clone <저장소 링크>

소스 코드로 게스 빌드

$ cd go-ethereum
$ make geth

게스를 실행하지 않고 구동 가능한 상태인지 확인

$ ./build/bin/geth version

아직 geth를 실행하지 마라. geth를 그냥 실행하게 되면 블록체인을 느린 방법을 동기화하기 시작할 것이고 아주 오래 걸릴 것이다.

4. 이더리움 기반 블록체인의 첫 번째 동기화

일반적으로 이더리움 블록체인을 동기화할 때 클라이언트는 처음부터, 즉 제네시스 블록(genesis block) 이후 모든 블록 및 트랜잭션을 다운로드하고 유효성을 검사한다.

블록체인을 이런 식으로 완전히 동기화하는 것은 가능하지만, 동기화는 매우 오래 걸리고 많은 자원을 필요로한다(RAM이 훨씬 더 필요하며, 빠른 스토리지가 없으면 실제로는 오랜 시간이 걸릴 것이다).

많은 이더리움 기반 블록체인이 2016년 말 서비스 거부 공격(Denial-of-Service, Dos)을 받았다. 공격을 받은 블록체인은 전체 동기화를 수행할 때 천천히 동기화되는 경향이 있다.

예를 들어, 이더리움에서 새로운 클라이언트는 블록 2,283,397에 도달할 때까지 빠르게 진행된다. 이 블록은 2016년 9월 18일에 채굴되었고, 공격의 시작을 표시한다. 이 블록에서 블록 2,700,031(2016년 11월 26일)까지 트랜잭션의 유효성 검사는 매우 느리고 많은 메모리와 입출력(I/O)이 필요하다. 이로 인해 블록당 1분을 초과하는 유효성 검사 시간이 요구된다. 이더리움은 하드 포크를 사용하여 서비스 거부 공격에서 악용된 근본 취약점을 해결하기 위해 업그레이드했다. 이러한 업그레이드를 통해, 스팸(spam) 트랜잭션으로 만들어진 2천만 개의 빈 계정을 삭제하여 블록체인을 정리했다.

만약 전체 유효성 검사로 동기화한다면, 클라이언트 속도가 느려지고 DoS 공격의 영향을 받는 블록을 확인하는 데만 며칠 혹은 더 오래 걸릴 수도 있다.

다행히 대부분의 이더리움 클라이언트는 트랜잭션의 전체 유효성 검사를 건너뛰고 블록체인의 일부에 동기화될 때까지 빠른 동기화를 수행하는 옵션을 포함한다. 그런 다음 유효성 검사를 다시 재개한다.

게스의 경우 빠른 동기화를 활성화하는 옵션으로 --fast가 있지만 이더리움 체인의 특정 지침을 참고해야 할 수도 있다.

패리티는 기본적으로 빠른 동기화를 수행한다.

게스는 빈 블록 데이터베이스로 시작할 때만 빠른 동기화를 수행할 수 있다. 빠른 모드 없이 이미 동기화를 시작한 경우 게스는 변경할 수 없다. 블록체인 데이터 디렉토리를 삭제하고 처음부터 빠른 동기화를 시작하는 것이 전체 유효성 검사로 동기화를 계속하는 것보다 빠르다. 블록체인 데이터를 삭제할 때 지갑을 삭제하지 않도록 주의해야 한다.

4-1. 게스 또는 패리티 실행

이제 첫 번째 동기화의 문제점을 이해했고 이더리움 클라이언트를 시작하고 블록체인을 동기화할 준비가 되었다. 게스와 패리티 둘 다 --help 옵션을 사용하여 모든 구성 파라미터를 볼 수 있다. 앞 절에서 설명한 게스의 --fast 를 사용하는 것 외에는 대부분의 경우 기본 설정이 일반적으로 적절하다. 필요에 따라서는 선택적 파라미터를 구성하는 방법을 선택한 다음 체인을 동기화하기 위해 게스 또는 패리티를 시작하고 기다리자.

이더리움 블록체인을 동기화하면 RAM이 많은 매우 빠른 시스템에서는 반나절, 느린 시스템에서는 며칠까지 소요된다.

4-2. JSON-RPC 인터페이스

이더리움 클라이언트는 애플리케이션 인터페이스와 JSON(JavaScript Object Notation)으로 인코딩된 RPC(Remote Procedure Call) 명령을 제공한다. JSON-RPC API를 참고하면 이 명령을 볼 수 있을 것이다. 기본적으로 JSON-RPC API는 이더리움 클라이언트를 이더리움 네트워크 및 블록체인 게이트웨이(gateway)로 사용하는 프로그램을 작성할 수 있게 해주는 인터페이스다.

일반적으로 RPC 인터페이스는 포트 8545에서 HTTP 서비스로 제공된다. 기본적으로 보안상의 이유로 로컬 호스트(사용자 컴퓨터의 IP 주소 127.0.0.1)의 연결만 허용하도록 제한된다.

JSON-RPC API에 접근하려면 사용 가능한 각 RPC 명령에 해당하는 스텁(stub) 함수 호출을 제공하는 특수 라이브러리(원하는 프로그래밍 언어로 작성됨)를 사용하거나, HTTP 요청과 JSON으로 인코딩된 보내기/받기 요청을 수동으로 생성할 수 있다. curl 같은 일반적인 커맨드 라인 HTTP 클라이언트를 사용하여 RPC 인터페이스를 호출할 수도 있다. 먼저 게스가 구성되어 실행 중인지 확인한 다음, 새 터미널 창으로 전환하여 시도해 보자. (예: 기존 터미널 창에서 Ctrl+Shift+N 혹은 Ctrl+Shift+T 사용)

$ curl -X POST -H "Content-Type: application/json" --data \ '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' \ http://localhost::8545


{"jsonrpc":"2.0","id":1,"result":"Geth/v1.8.0-unstable-02aeb3d7/linux-amd64/gol.8.3}

이 예제에서는 http://localhost8545 주소로의 연결을 만들기 위해 curl 명령문을 사용한다. 우리는 이미 8545포트에서 HTTP 서비스로서 JSON-RPC API를 제공하는 게스를 실행하고 있다. HTTP POST 명령을 사용하고 Content-Type: application/json 유형의 콘텐츠를 식별하기 위해 curl을 지시한다. 마지막으로, HTTP 요청의 데이터 요소로서 JSON으로 인코딩된 요청을 전달한다. 대부분의 커맨드 라인은 올바른 HTTP 연결을 만들기 위해 curl을 설정하는 것이다. 흥미로운 부분은 우리가 발행한 실제 JSON-RPC 명령이다.

{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}

JSON-RPC 요청은 JSON-RPC 2.0 사양에 따라 형식이 지정된다. 각 요청에는 네 가지 요소가 포함된다.

jsonrpc

  • JSON-RPC 프로토콜의 버전. 이것은 정확히 "2.0"이어야 한다.

method

  • 호출할 메서드의 이름

params

  • 메서드를 호출하는 동안 사용할 파라미터 값을 보유하는 구조화된 값. params는 생략될 수 있다.

id

  • 클라이언트가 설정한 식별자로 String, Number 혹은 (NULL 값이 포함된 경우) NULL도 포함된다. 이 멤버는 두 객체 간의 컨텍스트를 연결하는 데 사용한다.

id 파라미터는 주로 단일 JSON-RPC 호출에서 여러 요청을 할 때 사용하고, 이러한 실행을 배치(batch)라고 한다. 배치는 매번 요청에 대해 새로운 HTTP 및 TCP 연결의 오버헤드를 피하기 위해 사용된다. 예를 들어, 이더리움 컨텍스트에서 하나의 HTTP 연결에 수천 개의 트랜잭션을 검색하려면 배치를 사용한다. 배치가 실행되ㅗㄹ 때 각 요청마다 마른 id가 설정된다. 그러면 각 요청의 id와 JSON-RPC 서버의 응답 id를 맞춘다. 이를 구현하는 가장 쉬운 방법은 카운터(counter)를 유지하고 각 요청의 값을 증가시키는 것이다.

응답 값은 다음과 같다.

{"jsonrpc":"2.0","id":1,"result":"Geth/v1.8.0-unstable-02aeb3d7/linux-amd64/gol.8.3}

이것은 JSON-RPC API가 게스 클라이언트 버전 1.8.0에서 서비스되고 있음을 알려준다.

좀 더 흥미로운 것들을 시도해보자. 다음 예제에서는 JSON-RPC API에 현재 가스 가격(웨이 단위)을 묻는다.

$ curl -X POST -H "Content-Type: application/json" --data \ '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":4213}' \ http://localhost::8545


{"jsonrpc":"2.0","id":4213,"result":"0x430e23400"}

응답 0x430e23400은 현재 가스 가격이 18Gwei(기가웨이 또는 10억 웨이)임을 알려준다. 만약 16진수로 생각하지 않으면, bash-fu 커맨트 라인을 이용하여 십진수로 변환할 수 있다.

$ echo $((0x430e23400))

18000000000

전체 JSON-RPC API는 이더리움 위키에서 살펴볼 수 있다.

패리티 게스 호한 모드

패리티는 특별한 게스 호환 모드를 갖고 있으며, 게스에서 제공하는 것과 같은 JSON-RPC API를 제공한다. 게스 호환 모드로 패리티를 실행하려면 --geth를 변경하여 사용하라.

$ parity --geth

5. 원격 이더리움 클라이언트

원격 클라이언트는 풀 클라이언트의 일부 기능을 제공한다. 원격 클라이언트는 더 빠르며 데이터 용량도 훨씬 더 적게 요구한다.

이러한 클라이언트는 일반저긍로 다음 기능 중 하나 이상을 제공한다.

  • 개인키와 이더리움 주소를 지갑에서 관리
  • 트랜잭션 생성, 서명 및 브로드캐스트
  • 데이터 페이로드(payload)를 사용하여 스마트 컨트랙트와 상호연동
  • 브라우저와 댑(DApp) 간 상호 연동
  • 블록 탐색기 같은 이부 서비스 링크
  • 이더 단위를 변환하고 외부 소스에서 환율을 검색
  • 자바스크립트 객체로서 web3 인스턴스(instance)를 웹 브라우저에 삽입
  • 다른 클라이언트가 브라우저에 제공/삽입한 web3 인스턴스를 사용
  • 로컬 또는 원격 이더리움 노드에서 RPC 서비스로 접근

모바일(스마트폰) 지갑 같은 원격 클라이언트는 기본적인 지갑 기능만 제공한다. 다른 원격 클라이언트는 모든 기능을 갖춘 댑 브라우저다. 원격 클라이언트는 일반적으로 다른 고ㅗㅅ에서 실행되고 있는 풀 노드에 연결하여 이더리움 블록체인의 로컬 사본으로 동기화하지 않고 풀 노드 이더리움 클라이언트의 기능 중 일부만 제공한다. 예를 들면, 로컬에서 여러분의 PC 혹은 웹 서버에서 또는 이더리움 서버에서 서드파티 제품을 통해 제공한다.

가장 인기 있는 원격 클라이언트와 제공되는 기능을 살펴보자.

5-1. 모바일(스마트폰) 지갑

스마트폰에서는 전체 이더리움 클라이언트를 실행하는 데 필요한 자원이 충분하지 않기 때문에 모든 모바일 지갑은 원격 클라이언트다. 라이트 클라이언트는 개발 중이고 아직은 이더리움을 위해 범용적으로 사용되고 있지는 않다. 패리티의 경우 '실험 중(experimental)'으로 표시되어 있고 --light 옵션을 실행하여 사용할 수 있다.

인기 있는 모바일 지갑은 다음과 같다.

잭스(Jaxx)

비트코인, 라이트코인, 이더리움, 이더리움 클래식, 제트캐시, 다양한 ERC20 토큰 및 기타 여러 화폐를 지원하는 BIP39 니모닉 시드(mnemonic seed) 기반의 다중 화폐 모바일 지갑이다. 잭스는 브라우저 플러그인 지갑으로 안드로이드, iOS와 다양한 운영체제의 데스크톱에서도 동작한다.

스태터스(Status)

다양한 토큰과 인기 있는 댑(DApp)을 지원하는 모바일 지갑 및 댑 브라우저이다. 안드로이드와 iOS에서 사용할 수 있다.

트러스트월렛(Trust Wallet)

ERC20 및 ERC223 토큰을 지원하는 모바일 이더리움 및 이더리움 클래식 지갑이다. 트러스트 지갑은 iOS와 안드로이드에서 사용할 수 있다.

사이퍼 브라우저(Cipher Browser)

모든 기능을 갖춘 이더리움 지원 모바일 댑 브라우저와 지갑이다. 이더리움 앱과 토큰 통합을 허용한다. 안드로이드와 iOS에서 사용할 수 있다.

5-2. 브라우저 지갑

다양한 지갑과 댑 브라우저는 크롬 및 파이어폭스 같은 웹 브라우저의 확장 혹은 플러그인 형태로 사용이 가능하다. 이들은 브라우저 내부에서 실행되는 원격 클라이언트다.

인기 있는 브라우저 지갑은 다음과 같다.

메타마스크(MetaMask)

다재다능한 브라우저 기반 지갑이며, RPC 클라이언트 및 컨트랙트 탐색기 기능도 지원한다. 크롬, 파이어폭스, 오페라, 브레이브 브라우저에서 사용할 수 있다.

여타 브라우저 지갑과 달리 메타마스크는 다양한 이더리움 블록체인(메인넷, 롭스텐 테스트넷, 코반 테스트넷, 로컬 RPC 노드 등)에 연결되는 RPC 클라이언트 역할을 하는 브라우저 자바스크립트 컨텍스트에 web3 인스턴스를 넣는다. web3 인스턴스 삽입 및 외부 RPC 서비스의 게이트웨이로서의 기능은 메타마스크를 개발자와 사용자를 위한 매우 강력한 도구로 만든다. 예를 들어, 마이이더월렛이나 마이크립토와 결합하여 해당 도구들을 위한 web3 공급자와 RPC 게이트웨이로서의 기능을 수행할 수 있다.

잭스(Jaxx)

모바일 지갑으로도 소개된 잭스는 크롬, 파이어폭스 확장판과 데스크톱 지갑으로도 이용할 수 있다.

마이이더월렛(MyEtherWallet)

브라우저 기반 자바스크립트 원격 클라이언트로 다음과 같은 기능을 한다.

  • 자바스크립트로 실행되는 소프트웨어 지갑
  • 트레저(Trezor)와 레저(Ledger) 같은 인기 있는 하드웨어 지갑을 연결
  • 다른 클라이언트에 의해 주입된 web3 인스턴스에 연결할 수 있는 web3 인터페이스 (예: 메타마스크)
  • 이더리움 풀 클라이언트에게 연결할 수 있는 RPC 클라이언트
  • 컨트랙트의 주소와 애플리케이션 바이너리 인터페이스(Application Binary Interface, ABI)가 있는 스마트 컨트랙트와 상호작용할 수 있는 기본적인 인터페이스

마이이더월렛은 테스트와 하드웨어 지갑을 위한 인터페이스로서 매우 유용하다. 마이이더월렛은 브라우저를 통한 공격에 노출되어 있고 안전한 키 저장 시스템이 아니기 때문에 주 소프트웨어 지갑으로 사용해서는 안 된다.

마이이더월렛과 기타 브라우저 기반의 자바스크립트 지갑에 접근할 때는 피싱(phishing)의 대상이 되기 때문에 매우 조심해야 한다. 검색 엔진이나 링크가 아닌 즐겨찾기를 사용하여 올바른 웹 URL에 접근하라.

마이크립토(MyCrypto)

이 책의 초판이 출간되기 직전에 마이이더월렛 프로젝트는 2개의 독립적인 개발팀이 주도하는 2개의 경쟁 구도로 나뉘었다(오픈 소스 개발에서는 포크(fork)라고 얘기한다). 이 2개의 프로젝트가 바로 마이이더월렛과 마이크립토다. 분할 당시 마이크립토는 마이이더월렛과 동일한 기능을 제공했다. 두 개발팀이 각기 다른 목표와 우선순위를 채택함에 따라 두 프로젝트가 갈라설 가능성이 높았다.

미스트(Mist)

이더리움 재단이 만든 최초의 이더리움 지원 브라우저였다. 또한 ERC20 토큰 표준의 첫 번째 구현인 브라우저 기반 지갑도 포함되어 있다(ERC20의 저자인 파비안 보겔스텔라(Fabian Vogelsteller)도 미스트의 주요 개발자였다). 미스트는 또한 카멜케이스 체크섬(camelCase checksum)을 소개한 최초의 지갑이었다(EIP-55). 미스트는 풀 노드를 실행하며 스웜 기반 스토리지 및 ENS 주소를 지원하는 전체 댑 프라우저를 제공한다.

6. 결론

이 장에서는 이더리움 클라이언트를 살펴보았다. 여러분은 클라이언트를 다운로드하고 설치하고 동기화했으며, 이더리움 네트워크의 참여자가 되었다. 그리고 자신의 컴퓨터에 블록체인을 복제하여 시스템의 건전성과 안정성에 기여했다.

profile
개발새발
블록체인 개발 어때요
이전 포스트

Mastering Ethereum 2

다음 포스트

Mastering Ethereum 4

0개의 댓글