Block Sync about it-chain

[hea9549]

받아오는 도중에 합의에 참여할 수 없게하는 방법을 쓰면,
1버퍼에서 새로운 블록들을 받아온다. (합의에 참여할 수 없다.)
2버퍼를 또 확인해보니 새로 만들어진 블록들이 있다.
3버퍼에서 새로운 블록들을 받아온다. (합의에 참여할 수 없다.)
4반복...
과 같은 문제가 있을 거 같습니다.

에 대해서 블록을 받는 도중에 버퍼에 새로 만들어진 블록들을 받아 놓는다는 말이였습니다.
따라서 블록을 다받은 후에 버퍼에있는 블록들을 연결만 시키면되니
이때 연결시 발생하는 시간은 매우 빠르므로( 네트워크 통신이아닌 로직을 이용해서 연결하므로)
연결 사이에 발생하는 버퍼에 쌓이는 블록은 없거나 한번정도 더 반복후에는 없을 것으로 생각됩니다.
(즉 무한루프에 빠지지 않는다. 언젠간 탈출한다. 블록생성시간<블록연결시간 )

버퍼에 있는 블록 연결 / 완료 중에 합의 진행은 존재 할 수있는데
블록 연결 후 다음 합의부터 참가한다는 메세지를 리더에게 전달후 해당합의에 의한
블록까지 연결하면 문제가 해결될듯합니다.

아무쪼록 지금 답변들은 제 의견인데 잇체인의 생각이 어떻게되는지
@junbeomlee 빨리듣고싶어요! 읽어주세요!

[junbeomlee]

@zeroFruit

• 길이가 다르고 새 피어의 블록이 기존 피어 블록 모양에 일부분이 아닌 경우

는 없습니다!! 왜냐하면 block이 각각 height와 previous hash로 블록의 순서를 결정하기 때문에 맞지 않을 경우에는 처음부터 붙일 수가 없습니다.

@zeroFruit @hea9549
worldstatedb만 받아오는 경우는 없고, 기존 네트워크 참가자로부터 모든 block를 받아와서 진행할 계획입니다. 우선 public chain일 경우에는 퍼포먼스를 위해 worldstatedb만을 받을 수 있겠지만 마치 light node처럼 아직 그런 노드들에 대한 고려는 없습니다!!

@zeroFruit @hea9549
합의와 블록 sync및 추가는 independent 합니다. 합의는 내 블록체인의 상태랑은 상관없이 모든 피어가 동일한 블록을 받았는지를 검사하는 과정이고, 그 후에 블록추가를 수행하지만 블록을 붙일수 없는경우에는 합의와 별도로 블록을 붙일 수 있도록 sync를 맞추기만 하면 되기 때문에 서로 영향을 끼치지 않는다고 볼 수 있을 것 같습니다. (합의 한 블록만 블록체인에 추가한다는 점만 제외)

@zeroFruit @hea9549
블록을 leader 혹은 peer 누구에게서 가져올 지는 아직 생각해보지않아서.. 이제 우리가 생각하면됩니당!

[hea9549]

@junbeomlee 새노드 추가시의 문서 / 코드를 찾을수 없어 질문 & 답변을 동시에 남깁니다.
관련 문서 or 코드 있으면 답글로 파일명 또는 링크달아주시면 감사하겠습니다!
새 피어가 참가할 경우 두가지 방법이 있을수 있다고 생각합니다.

• 첫번째 방법
  기존 네트워크 참가자로부터 결과(world state)만 받아와서 진행

기존피어 : Gensis -> A -> B -> C
새 노드 : Genesis ( 기존피어와 World State는 동일함 )

의 진행이 완료된 World State DB 를 복사 + 새 노드는 Gensis Block 부터 시작
이렇게하면 기존피어의 Gensis -> A -> B -> C 까지 진행한 결과(world state)와
새 노드의 Gensis 의 결과(world state)가 동일하게되고 이후 블럭 생성에 대해서도 동일하게 될 듯합니다.
단, 이전 블럭의 진행과정을 알수없기에 적절한 방법이 아닌듯합니다. 정책적인 내용이 될 듯 합니다.

• 두번째 방법
  기존 네트워크 참가자로부터 모든 block를 받아와서 진행

기존피어 : Gensis -> A -> B -> C
새 노드 : Gensis -> A -> B -> C ( 피어로 부터 복사 )

이 경우 새 노드가 피어로부터 블록을 받아올때 사이에 생기는 새로운 블록생성들에 대해
버퍼에 잘저장 한 뒤 블록 받아오기 완료 후 잘 진행되도록 sync 조절이 중요할 것 같습니다.
받아오는 도중엔 합의에 참여할 수 없는등 여러 설정이 필요할 것 같은데
만약 아직 정의된 바가 없다면 논의가 필요한것같습니다. (@junbeomlee 체크해주세요 이미 있는지)

두번째 방법에서는 두가지로 또 나뉠수 있는데

• Block을 받는 방법
  • 리더노드로 부터 block를 받기
  • 네트워크 참여자 아무로부터 block 받기

먼저 리더노드로부터 Block을 받기의 경우
boot node 로부터 leader 정보를 받고 leader에게 블록을 요청하여 받아야하는데
이때 모든 새로운 노드가 leader에게 요청을 하니 leader에게 부담이 가지 않을까 생각하는데
private chain 특성상 적은 node라 부담이 안될수도 있을것같아 상관없는지 궁금합니다(@junbeomlee )

leader노드로부터만 받는다면 여러 sync 문제가 어느정도 편하게 해결 될 것 같습니다

네트워크 참여자 아무로부터 Block을 받기의 경우
네트워크 참여자 노드로부터 block 정보를 받고, 해당 노드가 leader로부터 받은 message들을 이용해
그 후 처리도 하는방법인데 여러 sync 문제가 발생 할 것 같습니다.

결론

따라서 결론은 Block이나 World State같은경우 기존 참여자로부터 정보를 받아오기때문에
복사해온다면 질문과 같이 어긋나는 경우는 발생하지 않을 것 같습니다.

틀린부분이 있거나 it-chain이 새 노드에 관한 정책이 이미 존재한다면
답글남겨주시면 감사하겠습니다!

[zeroFruit]

@hea9549 @junbeomlee

답변주셔서 감사합니다.
저도 두번째 방법에서 리더노드로부터 block을 받는 방식을 생각했습니다.

이 경우 새 노드가 피어로부터 블록을 받아올때 사이에 생기는 새로운 블록생성들에 대해
버퍼에 잘저장 한 뒤 블록 받아오기 완료 후 잘 진행되도록 sync 조절이 중요할 것 같습니다.
받아오는 도중엔 합의에 참여할 수 없는등 여러 설정이 필요할 것 같은데

받아오는 도중에 합의에 참여할 수 없게하는 방법을 쓰면,

1. 버퍼에서 새로운 블록들을 받아온다. (합의에 참여할 수 없다.)
2. 버퍼를 또 확인해보니 새로 만들어진 블록들이 있다.
3. 버퍼에서 새로운 블록들을 받아온다. (합의에 참여할 수 없다.)
4. 반복...

과 같은 문제가 있을 거 같습니다.

그래서 혹시 합의를 시작하기전에 새로 네트워크에 들어온 노드들은 리더 노드 block 기준으로 sync를 맞추고 시작하는 방법은 문제가 있을까요?
아예 sync맞추는 부분과 합의하는 부분을 병렬적으로 진행하지않고 블럭의 sync를 맞추는 부분과 합의하는 부분을 동기화시키는 것입니다.

새로 네트워크에 참여한 피어들은 참여하고 난 뒤 최초로 합의하기 이전에는 다른 피어들과는 sync가 맞지 않다가 합의에 참여하고나서야 sync가 맞춰지는 것입니다. 대신 합의하는 시간은 훨씬 길어질 것 같습니다.(leader로부터 블록을 받아오는 시간이 얼마나 걸릴진 잘 가늠이 안되네요)

[hea9549]

합의시 마다 sync를 맞추는것은 무리가 있을것 같습니다.
매번 맞추려면 cost가 클것같아서요..!

Sync가 맞춰진 node끼리만 합의를 하고 새 노드들은 sync맞춰진곳까지
block을 받아온 후 진행될 것 같은데

정확히 이쪽은 알지못해서 @junbeomlee 의 코맨트가 필요할 것 같습니다.

leader로부터 블록을 받아오는 시간은 아마 엄청 빠를텐데
네트워크 상황이나 chain의 크기에 따라 다르므로 시간을 단정지을수는 없을것 같습니다.

[hea9549]

boot node로부터 받는게 나을까요 아니면
boot node로부터 leader 정보를 얻어와
leader에게 요청을 보내는게 나을까요?

리더에게 보내는경우 여러노드가 동시에 참여시
네트워크에 무리가 가지않을까 생각해봤지만
private 특성상 그러지는 않을것 같아서

딱히 문제가없으면 leader에게 block정보를 받아오는게
여러문제를 해결하기 편할것같습니다!

[junbeomlee]

일단 모든 피어간 네트워크 연결이되면, leader나 그냥 peer나 상관없을 것 같습니다.

[zeroFruit]

@hea9549 @junbeomlee
#172 에서 가져왔습니다. 아무래도 여기에서 얘기하는 것이 좀 더 좋을 거 같습니다! 👍

새로 네트워크에 참여한경우
Peer(새 노드 A) 서비스 에서 받아올 피어(B) 에게 블록 요청 이벤트를 보내고
해당 이벤트를 받은 B 의 blockChain 서비스가 블록을 모아 이벤트를보내고
A의 blockChain이 그 이벤트를받아 블록들을 저장한다.
라는 순서로 이해하는게 맞을까요?

A가 그렇게해서 블록들을 저장한다음에 버퍼를 한번더 확인해야하겠죠?
그리고 추가하는 동안은 합의 요청을 받지않는 것이 좋을 거 같습니다