[이더리움][Ethereum] Node & Client

근상·2024년 12월 19일
Nodeclientethereum노드이더리움클라이언트

비트코인에서는 Bitcoin Daemon(Bitcoind)이 기본적인 공식 노드인데,
이더리움에선는 Geth가 공식 노드다.

Go-Ethereum

  • 공식 Full Node - Go-Ethereum(Geth)은 현재 계속 개발 중이고
    cppEthereum(aleth), pyEthereum은 현재 개발 중단된 상태다.
    openethereum(parity)또한 꽤 사용 됐다가 중단됐다.

  • 다양한 통신 방안 - socket통신만 지원하는 bitcoind와 달리
    IPC, HTTP, websocket등 다양하게 client와 통신한다.

  • 사용 방법에 따른 용량 관리 - Bitcoind purne(내가 특정 깊이까지 블록을 소유하겠다)
    와 달리 geth는 사용 방안에 따라 여러가지 방식을 제공한다.
    Snap(풀 노드 중에서 가벼운 노드만 소유), Full(모든 블록체인 데이터 소유),
    Light(월렛처럼 헤더 정보만 갖고 있는 노드)가 있다.
    -> 여기에 Archive모드를 on/off함에 따라 데이터가 변한다.

Geth 실행 주요 Option

geth를 운영을 하면 이 4개의 정보들을 필수로 설정 해야만
원하는 데이터들을 얻을 수 있다.

  1. --http.api
    JSON RPC API 중 client에 허락되는 API를 지정해 open이 가능

  2. --networkid
    테스트넷, 메인넷, Private Blockchain 중 선택 운영이 가능하게함.
    비트코인의 경우 따로 이런 선택이 없다.
    실제로 geth를 운영한다면, 지정된 숫자가 아니라 그 이외의 숫자를
    지정하도록 요구를 하는데 기본적으로 메인넷1, 테넷 2~5.
    비슷한게 chainId인데, 일반적으로 두개가 동일하지만
    특정한 상황에서는 분리돼서 관리된다.
    Tx id는 tx검증 단계에서 사용되고, networkId는 블록을 검증할 때 사용한다.

  3. --syncmode
    블록체인 데이터를 어느 정도 갖고 있을 지 정하는 것이다.
    snap모드는 약 400GB, FULL모드는 1TB정도 된다.

  4. --gcmode
    Full, Archive모드로 구성돼 지정을 선택을한다.
    아카이브를 선택하면 모든 기록이 노드에 담긴다.

Geth를 사용하게 될 때 어느 옵션들을 사용해야 할 지 고민이 많겠지만,
이 주요 4가지는 우선 꼭 사용해야된다.

Geth 설치 및 실행

  • git clone으로 go-ethereum

  • 들어가서

  • geth를 생성한다.

  • 그 후 앞에서 설명한 주요 option을 사용하며 geth를 실행한다.

  • 노드 접속에는 두 가지 방식이 있다. - geth console, geth attach
    전자는 노드를 실행과 콘솔 실행을 동시에 한다

    (자료처럼 명령어 없이 자동으로 default값으로 실행시키면서 콘솔이 뜬다). 후자는 실행된 노드에 내가 붙어서 접근하는 방식이다.

Geth API 예제

(위 자료 geth attach를 통해 go-ethereum에 붙었을 경우임)

우선 접속을 했다면 Block Sync를 해야 한다.
전체 Block Syncing이 완료돼야 Account's State를 정확하게 알 수 있고,
Tx를 실행시킬 수 있다.

eth.syncing값이 false가 나와야 Sync가 끝난 것이다.

eth.blockNumber은 Sync가 완료됐을 때 가장 최신 Block Num을 알려준다.

eth.coinbase은 채굴에 참여했을 때 제공되는 주소

eth.getBalnce(personal.listAccounts[0])를 하게되면
api를 통해 유저의 계정주소를 받아올 수 있는데, personal.listAccounts는
이 geth에 생성된 wallet address들의 리스트 중 첫번째 인덱스의 잔액이다.

eth.getBalance(eth.coinbase)는 coinbase주소에 담긴 잔액이다.

=> 앞의 Dapp에서 처럼 노드에 직접 붙어서 실제로 Tx전송 혹은 데이터 조회의 경우
geth attach를 통해 노드에 접속해 잔액정보나 Sync여부 등을 확인가능.

JSON-RPC API

  1. eth_getBlockByNumber - 이더리움 블록 정보를 조회한다.
    Block Num뿐 아니라 ByHash로 해당 블록 해시값으로도 조회 가능하다.

  2. eth_newfilter - Geth에서 제공 받을 Event정보 등록.
    특정 주소, 이벤트 형식(topics)에 따라 Dapp에서 조회가 가능하다.
    (event&log부분에서 어느 정도 필터해서 event를 받고싶은 경우가 있었는데, 그럴 때 등록하는 것이다.)

  3. eth_getTransactionCount - 유저가 현재 nonce정보를 조회한다.
    이 사람이 얼마나 Tx를 날렸는지 파악.
    왜 중요? nonce정보가 중복되면 이더리움에서 이중지불로 인식한다.

  4. eht_sendTransaction - 거래의 서명과 네트워크 배포를 동시에 진행하는 함수다.
    이미 Web3에서 서명이 완료된 Tx는 sendRawTransaction을 사용한다.

GraphQL

추가적인 지식으로 알면 좋다.

JSON-RPC이 아닌 방법으로 데이터 조회

앞에 Event & Log에서 The Graph 언급을 했는데
이 Dapp이 이 GraphQL방식을 사용한다고 보면 된다. QL(Query Language)

Client가 Server에 데이터 요청할 때, 대부분 REST API(여러개 url을 나눠 데이터를 요청)방식을 사용하는데 하나의 URL로 처리가 가능하다.

REST API같은 경우에 응답받을 데이터를 지정 하지 않지만,
이 경우에는 지정할 수 있다.

좌 - REST API의 경우 사용자의 이름을 함께 URL로 요청하면
응답으로 사용자의 모든 정보를 받는다.

우 - GraphQL의 경우 url을 나누지 않고 하나로 요청한다.
그 속에 받고 싶어하는 데이터를 지정해서 요청한다.
응답으로 query명이 나오고 그에 해당하는 값들을 포함해 응답한다.

->보다 자유로운 환경에서 Client-Server가 가능하다. 최근에 많이 쓰이는 방식이다.

Infura Node

Geth 노드를 운영하기 복잡하고, 24시간 서버 비용 발생으로 사용하고 싶지 않을 때
사용하는 서비스 들이 있다.
그 중 하나로 Infura Node가 있다.

  1. Full Node 운영을 기본적으로 대행해준다. 24시간 운영이 힘들어 이를 대행.

  2. 장점으로 유저가 24시간 서버를 준비할 필요가 없고, 많은 데이터 용량 관리나
    자주 있는 Geth의 업데이트를 신경쓰지 않아도 된다. (Hard Fork에 대비)

  3. 단점으로 중앙화 기관의 문제 발생, Infura Node의 데이터가 위변조 되거나
    잘못된 거래 생성. 또 이 노드가 중지되면 서비스가 중단될 수 있다.

간단한 테스트 정도의 작업을 할 때 유용하다.
snap mode로 Sync를 해도 대략 24시간이 걸린다.
그래서 Solidity로 공부를 한다면 Infura Node를 추천한다.

Metamask

계속 노드의 설명을 했고 이제 Client 차례다.

가장 대표적인 월렛 서비스로 이더리움 기반의 Metamask가 있다.

  • 크롬 익스텐션에서 바로 사용이 가능한 월렛으로
    크롬만 갖고 있으면 사용 가능하다.

  • 메인넷, 테스트넷, Private Blockchain으로 다양한 네트워크 접속이 가능

  • Remix IDE라는 Solidity Online Compiler가 있다. 개발시 편리한 환경 제공

  • Defi 서비스 따로 연동없이 사용가능

  • 안전한 키 관리

Etherscan

이더리움의 대표적인 Explorer이다.

  • Block, Tx 등 Blockchain 전체 정보 확인 가능

  • 테스트넷에 개발 시 확인 가능

  • 일반 서비스의 Contract 코드 검증

실제 이더리움 개발시 가장 많이 보는 사이트다.

Etherscan SourceCode 검증

Smart Contract를 배포할 때 소스코드 배포가 아니라 ByteCode만 네트워크에 배포된다.

ByteCode만 보고 악성코드 여부를 판달할 수 없다.

역으로 ByteCode를 Decompile은 거의 불가능하다.

Etherscan은 실제로 사이트에 코드를 등록하고 ByteCode로
등록된 네트워크와 비교를 통해 일치한 지 확인을 해준다.

이미 올라왔다는 것이 일치가 된 코드이기 때문에 이를 믿고 SC를 확인하면 된다.

최근에는 이 솔리디티 파일들의 취약점이나 보안성 등을 검증해주는 업체들도 있어
더욱 신뢰할 수 있다.

이런 서비스들이 없었다면 아무리 블록체인상에서 안전하게 운영된다 해도
코드상에서 악의정인 행동은 막을 수 없다.

출처)) 자료 및 내용: 패스트캠퍼스

profile
근상
이전 포스트

[이더리움][Ethereum] Dapp & Web3

다음 포스트

[이더리움][Ethereum] ERC-20

0개의 댓글