현재 나의 상태다. 최소한 내PC에서는 1개 혹은 2개의 블록차이가 영영 유지될 수 밖에 없다는 결론.
예전에 싱크 코드를 분석한적이 있었다. (https://steemit.com/ethereum/@sigmoid/3b6jkn). 간단하게 요약하자면 "pivot"포인트를 잡아서 pivot-fsMinFullBlocks까지는 fast mode로 외부에서 블록/영수증을 받고, 이후부터는 full 검증모드로 내가 직접 블록을 처리하여 영수증을 생성하도록 되어있으니 fsMinFullBlocks값을 바꿔보자 뭐 이런 내용인데, 이번에 개인 노드를 돌려보기로 하면서 동일한 현상이 발생되어서(100개 정도의 블록이 유지되면서 싱크가 끝나지 않는 상황) 해당 값을 바꿔가며 테스트 해볼수 있었다.
왜저렇게 하는지 조금 멋들어지게 표현해보면, 준비대충되었으면 홀로서기를 한번 해봐라..뭐 이런거지.
기본값은 64이기 때문에, 싱크를 시작한 시점의 highestBlock - 얼마까지는 fast sync를 하고, 그이후 블록에 대해서는 직접 full sync 처리를 시작한다. 문제는 직접 블록을 처리하는 시간이 느려서 결과적으로 처리된 영수증 결과가 DB에 쓰여지는게 늦어진다면 current값 갱신이 늦어지는데, 그동안 highestblock이 다시 높아지기 때문에 또다시 pivot포인트를 옮기는 상황이 생긴다.
이걸 증명하기 위해서 fsMinFullBlocks값을 0으로 만들었다.
이렇게 설정하면 나는 최종블록까지는 아무것도 처리하지 않고 싱크를 하겠다는 뜻이 되기때문에
이렇게되면 저렇게 -1~-2블록까지 싱크가 된다
.
이렇게 설정했을때의 문제점은 마지막 영수증 처리결과까지 상대방에게 받아야 current가 +1 이되는데,
그시점에는 이미 상대의 highest 값이 갱신된다거다
이상태에서 싱크를 끝내는 법을 쉽게 표현하자면, 마지막 블록의 헤더와 블록 바디를 받았을때
블록타임 안에 검증을 끝내고 DB에 저장해서 current값이 highest값과 동일해지는 시점을 만들어야 한다
한 100개의 트렌젝션이 있기 때문에 해당 트렌젝션을 처리하고 영수증을 생성하고 DB까지 쓰는 동작이 평균블록타임안에는 들어와야
다음부터 대등하게 다른 노드와 경쟁할수 있게 된다. 아니라면 pivot이 또 옮겨지고 또다시 따라가야하는 상황이 생긴다.
그래서 내 구린 PC에 외장하드가 달린 환경에서는 나는 영영 highest -1이 되어 싱크가 안끝나는 것이다. 참고로 해당값을 기존의 절반으로 낮추면 약 50블록정도가 유지되면서 싱크가 안되는 현상을 확인할 수 있었다.
어차피 마지막 블록처리시간만 줄이면 되는거라서 바로 DB에 쓰도록 설정해봤는데 별 영향이 없었다.
(가비지 콜렉션 모드를 archive로 하면 캐시를 안쓰게됨, 코드가 이렇게 되어있음)
결론적으로 말하면 최소
1block processing time < average blocktime 를 만족해야
기생에서 자생으로 가는 건널목을 무사히 건너 싱크의 종료를 기대할 수 있다.
문제가 있으신 분들은 fsMinFullBlocks값을 조절해보면 좋을것 같다.
결론은 좋은CPU/SSD쓰세용ㅠ.
