메인 콘텐츠로 건너뛰기
일부 내용은 OP Stack P2P Specs에서 가져왔습니다. 최신 OP Stack 요구 사항은 사양을 참조하십시오.
OP Stack은 합의 계층에서 P2P 네트워킹을 사용하여 sequencer가 보는 L2 체인 상태를 네트워크의 다른 노드와 공유합니다. P2P를 통해 공유되는 L2 블록은 “unsafe”로 간주되며, L1을 우선하여 정규(canonical) 체인과 일치하도록 재구성(reorg)됩니다. 즉, P2P 계층의 동작은 rollup 보안에 영향을 주지 않습니다. 따라서 P2P gossip을 기반으로 피어를 차단하고 점수를 매기는 규칙은 정책의 문제이며, 최종적으로 자신에게 가장 적합한 구성을 선택하는 것은 사용자의 몫입니다. P2P가 kona-node에 어떻게 연결되는지 알아보려면 아래의 P2P Actor 섹션으로 이동하십시오. 그렇지 않으면 계속 읽으면서 P2P 스택의 세부 사항을 알아보십시오.

토폴로지

P2P 스택 토폴로지는 다음으로 구성됩니다.
  • discv5를 통한 피어 탐색
  • libp2p를 통한 gossip 및 피어 연결 관리
  • 노드에 의한 gossip 게시 및 검증
kona-node에서 이러한 계층은 모듈 또는 별도의 crate 형태의 모듈식 구성 요소로 나뉘어 있습니다.

탐색(Discovery)

Kona의 탐색 계층은 Discv5Driver라는 “driver”에 캡슐화되어 있습니다. driver가 시작되면 새 스레드를 생성하여 이벤트 스트림에서 오는 discv5::Discv5 이벤트와 kona-node의 메트릭 요청을 처리합니다. 소비된 Discv5Driver는 “handler”를 반환하며, 이를 통해 kona-node의 다른 구성 요소가 채널을 이용해 생성된 discv5::Discv5 서비스와 통신할 수 있습니다. kona의 탐색 서비스가 피어를 발견하면, 해당 피어가 올바른 네트워크 gossip에 참여하고 있는지 확인하기 위해 피어의 “ENR”을 검증해야 합니다. Ethereum Node Record(ENR)와 그 검증 방법은 이후 섹션에서 다룹니다. ENR이 검증되면 소비자(kona의 경우 libp2p)에게 전달되며, 소비자가 해당 노드와의 연결을 수립하고 관리합니다. Kona의 탐색 driver에는 몇 가지 주목할 만한 기능이 더 있습니다.
  • X초마다 무작위 ENR을 탐색합니다. 이는 Discv5Builder::with_interval로 구성할 수 있습니다.
  • 피어 탐색을 새롭게 유지하기 위해 Y초마다 탐색 테이블에서 무작위 ENR 하나를 제거합니다. 이는 Discv5Builder::with_discovery_randomize로 구성할 수 있습니다.
  • Z초마다 구성 가능한 위치에 ENR 테이블을 저장하므로, 서비스가 재시작되어도 피어를 다시 탐색할 필요 없이 저장된 피어를 사용할 수 있습니다. 이 간격은 Discv5Builder::with_store_interval로 구성할 수 있습니다.

Gossip

L1에서 derive되지 않은 OP Stack의 L2 블록은 노드들의 P2P 네트워크에서 TCP를 통해 공유됩니다. 이렇게 공유되는 unsafe L2 블록은 sequencer에서 생성됩니다. kona-node에서 L2 블록 gossip은 libp2p Swarm을 통해 처리됩니다. GossipDriver는 kona-node에서 libp2p swarm을 관리하는 구성 요소이며, 피어 연결 시도, payload(L2 블록) 게시, swarm 이벤트 처리 등 swarm과의 모든 상호작용을 담당합니다.
libp2p swarm이 진행되려면 Swarm을 Stream으로 사용하여 폴링해야 합니다. kona의 GossipDriver에서는 GossipDriver::next에서 이벤트를 반복적으로 소비하여 이를 수행할 수 있습니다.
GossipDriver는 libp2p Swarm의 이벤트를 처리하는 메서드를 제공합니다. GossipDriver의 피어 저장소, 연결 시도 기록, 연결 상태를 swarm과 일치시키려면 이벤트를 이 방식으로 소비해야 합니다. 피어, 주소, 서브넷 차단과 점수 기반 차단(ban)은 swarm 내부에서 gate behaviour에 의해 적용됩니다. swarm은 다른 behaviour보다 먼저 각 연결에 대해 이 gate behaviour에 확인을 요청합니다. gate는 차단된 주소에서 오는 인바운드 연결을 핸드셰이크 전에 거부하고, 차단되거나 ban된 피어의 연결은 피어 ID가 확인되는 즉시 거부합니다. 피어, 주소 또는 서브넷을 차단하면 이미 열려 있는 해당 연결도 닫힙니다. libp2p Swarm은 지정된 Multiaddr에서 수신 대기합니다.

L2 블록 게시

이전 섹션에서 언급했듯이, L2 블록은 GossipDriver를 사용해 libp2p Swarm을 통해 payload로 게시됩니다. GossipDriver는 OpExecutionPayloadEnvelope와 그 서명을 받아, OP Stack P2P Specs에 문서화된 wire 형식으로 내부에서 인코딩합니다. GossipDriver를 통해 게시되는 L2 블록은 “토픽(topic)“에 게시됩니다. gossipsub 프로토콜은 토픽을 사용해 해당 토픽에 메시지를 게시하며, 피어는 구독할 토픽을 선택할 수 있습니다.

L2 블록 검증

kona에서 L2 블록은 trait으로 추상화된 “block handler”를 통해 검증됩니다. libp2p 메시 네트워크의 메시지는 snappy로 압축되어 있으므로, 압축을 해제한 다음 해당 메시지가 게시된 올바른 블록 토픽에 맞게 디코딩해야 합니다. 압축 해제 후 kona는 서명을 정확한 인코딩된 envelope 바이트와 분리합니다. 해당 블록 토픽에 따라 envelope를 디코딩하고 블록 내용을 검증하기 전에 먼저 이 바이트를 인증합니다.
kona의 블록 유효성은 OP Stack 블록 검증 사양을 따릅니다.
이 문서 작성 시점에서 블록 검증은 다음 몇 가지 규칙을 따릅니다.
  • 타임스탬프는 과거 60초부터 미래 최대 5초 사이여야 합니다.
  • 블록 서명은 정확한 인코딩된 envelope 바이트를 인증합니다.
  • 블록 해시가 유효해야 합니다. 이는 인코딩된 트랜잭션 바이트에서 직접 트랜잭션 trie root를 계산하고 재구성한 헤더를 해싱하여 확인합니다. 트랜잭션 디코딩과 실행은 여전히 실행 계층의 책임입니다.
  • payload envelope의 내용이 해당 버전에 맞게 올바라야 합니다. 서로 다른 버전은 하드포크에 따라 payload에 새로운 내용을 도입하므로, 상위 호환되는 payload envelope는 이전 버전에 존재하지 않는 필드에 내용을 가질 수 없습니다.

노드 식별

TODO

P2P Actor

TODO