오늘은 Light Etherium Services에 대해 분석시작.

기본적 정의는 다음과 같다.
블록헤더를 다운받고 아주 작은 부분을 검증하기 위해 하드 디스크에 저장된 trie노드 형태의 분산된 해시 테이블을 DB로 이용한다.

In Ethereum, a light client can be viewed as a client that downloads block headers by default, and verifies only a small portion of what needs to be verified, using a distributed hash table as a database for trie nodes in place of its local hard drive.

IoT같은 디바이스에서 compact하게 ethereum을 실행하기 위해 디자인 된 서비스이다.

우선 한글 주석은 여기..
https://github.com/NAKsir-melody/go-ethereum/commit/50133d56fc95640630c427fc79909a38bdb53da5

geth 바이너리가 실행되면서 노드를 생성후 초기화 하는데,
노드객체는 기본적으로 서비스들이 등록되는 컨테이너 객체이기 때문에
ethereum 프로토콜도 역시 서비스로 추가 된다.
초기화가 완료된 노드가 start하면서 본인에게 등록된 모든 서비스를 시작하게 되므로
그때 라이트 이더리움 프로토콜이 실행될 것이다.

우선 node가 어떤 프로토콜을 사용할 것인지는 이더리움 프로토콜을 노드에 등록하는 시점에
config파일의 sync 모드에 따라 Light Sync인지 아닌지(Full sync)를 구별한다.

RegisterEthServcie내에서 les 객체의 New function으로 부터 시작
New함수에서 체인 DB(level DB)를 설정하고(생성 혹은 연결 /eth/db/cahindata) 3초마다 모니터링할 meter를 달아둔다
db를 읽어서 캐노니컬 hash가 있는지 확인하고 없다면 제네시스 블록을 생성하고
있다면 해당 블럭의 해시를 체크한 후에 net의 config를 읽어서
main-net인지 test net인지 결정한다.

그 후에 서비스 참여자를 관리하기 위해 피어셋을 생성하고
서버풀을 가동하여 새로 생성되거나 발견된 라이트 서버 노드를 저장한다.
효율적인 검색을 위한 bloom인덱서와, 합의 엔진(ethash), 요청 분배자를 설정한다.
요청 분배자가 사용할(?) 릴레이 채널과 검색매니저를 설정하는데
검색 매니저는 request id에 대응하여 응답/재전송/타임아웃을 관리한다.

그후에 라이트 체인의 최신 state 정보를 받아 오는 과정에서
트랜젝션 풀을 생성함과 동시에 서브 프로토콜 매니저를 생성하여 이더리움 네트워크와 호환 가능한 피어들을 관리한다.

이제 start가 불리우면
LES를 시작하는데, 이때 DiscV5프로토콜을 이용해 RLPx 노드를 검색하고
내부적으로 프로토콜 매니저가 돌면서 블럭과 해시 정보를 동기화 한다.

위키를 찾아보니
이더리움은 RLPx스펙으로 kademlia프로토콜의 일부를 사용하여 노드를 찾고 관리한다고 한다(p2p 관련 부분, node discovery protocol)
http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

코드에서 본 프로토콜 매니져의 역할은 아래. (Ethereum Wire Protocol)
이더리움 네트워크중 불록체인 데이터를 교환하는 프로토콜이다. = 프로토콜 매니져
두개의 피어가 서로 handshake를 하고 각자의 status message를 보낸다.
status는 TD와 best block의 해시값이 저장되어 있다.
베스트 블록 = RecentBlock이란 마이닝된 마지막 블록이다.
total difficulty는 누적된 체인의 difficulty이다. 이값이 크면 longest chain이 된다.
그러므로 해당 크라이언트가 방금 해시된블럭의 풀체인 피어로서 동작하게 된다
해쉬체인은 work풀을 통해 연결되 모든 피어에게 공유된다.
https://github.com/NAKsir-melody/wiki/blob/master/Ethereum-Wire-Protocol.md
(위키도 한글화 해야겠네..왜 이렇게 동작하는지 알려면..)

일단 라이트 노드로 설정되면 라이트 이더리움 서비스로 부터 블록과 해시를 받아오고
라이트 서버 노드들을 따로 저장해서 관리한다는건 알겠다.
또한 풀체인을 싱크하지 않고 최신 state만 받아오는 것을 확인했다.

아직 눈가리 코끼리 다리만지기 형태의 소스 분석이지만,
어느정도 분석하고 공부하다보면 큰 그림이 나올것이라 생각한다.

다음엔 합의 엔진인 ethash쪽을 분석해보고자 한다..