Ethereum의 활성 데이터 동기화에 대한 간략한 분석

I. 소개

요컨대 이더리움 데이터 동기화는 노드(피어)를 데이터 캐리어로 사용하여 데이터 주체를 저장하고 전송하며 주로 Header, Body, Reciept로 구성됩니다. 데이터 동기화 트랜잭션은 Ethereum p2p 통신 프로토콜을 통해 관리되며 최종적으로 최종 데이터 다운로드 작업을 수행하기 위해 실행기(활성 동기화는 다운로더로 전달되고 수동 동기화는 Fetcher로 전달됨).

그런 다음 데이터 주체에게 동기화를 위해 동기화해야 하는 데이터가 무엇인지 묻습니다. 서로 다른 데이터를 분류하고 동기화해야 합니까?

Chuangyu Blockchain Security Lab이 포괄적이고 상세한 분석을 수행했음을 알고 있습니다.

2. 데이터 주체:

데이터 동기화를 수행하려면 먼저 동기화하는 데이터 주체가 무엇인지 명확히 해야 합니다.일반적으로 두 가지 유형이 있습니다.하나는 노드가 활성 동기화 요청을 보낼 필요가 없으며 노드가 스스로 네트워크에 브로드캐스트합니다. 데이터가 패키징될 때 이 유형에는 세 가지 유형의 데이터가 있습니다: 유형 - 전체 블록, 블록 해시 및 트랜잭션 트랜잭션. 오늘 우리는 데이터의 다음 범주에 초점을 맞춥니다.

두 번째 유형의 데이터는 노드가 능동적으로 동기화 요청을 보내고 다른 노드가 동기화할 데이터에 응답해야 하는 데이터로, 첫 번째 유형의 데이터를 제외하고 동기화가 필요한 다른 데이터는 두 번째 유형에 속합니다. , 따라서 유형이 더 복잡하고 가장 중요하다고 할 수 있습니다. 또한 블록 헤더, 블록 본문, 트랜잭션 영수증 Receipt(특정 코드 ⬇⬇⬇)의 세 가지 유형이 있으며 첫 번째 유형과 달리 이 세 가지가 될 수 있습니다. 능동적으로 동기화하기 위해서는 노드 간 데이터 동기화의 범위를 자유롭게 제어할 수 있고, 필요한 데이터가 먼저 동기화되고 일시적인 비필수적일 수 있음을 나타내는 완전한 블록의 특정 부분이라고 합니다. 데이터를 포기할 수 있습니다.

⬆Header는 블록 헤더를 의미하며 블록에서 매우 중요한 역할을 합니다.ParentHash는 이전 블록의 블록 해시를 기록하고, uncleHash는 삼촌 블록 해시를 기록하고, coinbase는 채굴자의 주소를 식별합니다. Root, Txhash 및 ReceiptHash는 각각 state trie, tx trie 및 Receipt.trie의 세 가지 접두사 트리의 루트 노드입니다.하나의 RLP 코드 해시는 세계의 상태를 설명하는 데 사용되고 하나는 트랜잭션을 설명하는 데 사용됩니다. 다른 하나는 거래 영수증을 설명하는 데 사용됩니다. Bloom은 대상 해시가 특정 세트에 있는지 빠르게 판단하기 위한 블록 헤더의 Bloom 필터입니다. 헤더에 있는 위의 데이터는 블록 헤더에서 해시를 사용하여 블록과 블록의 중요한 데이터 모듈을 식별하는 데 사용됩니다. 나머지 데이터에는 고유한 요구 사항이 있습니다. 블록 헤더는 기본적으로 블록 프레임을 기술하고 있음을 알 수 있으며, 이는 후술할 데이터 동기화 전략을 위한 길을 열어주기도 합니다.

⬆본문은 트랜잭션 개체 집합과 삼촌 블록의 블록 헤더 배열을 포함하는 비교적 간결합니다.

⬆Receipt는 블록 내 모든 트랜잭션 객체가 실행된 후 생성되는 배열로, 트랜잭션 처리 정보를 기록하는 데 사용됩니다. 생성된 후 Receipt trie에 하나씩 삽입되며 블록 헤더의 ReceiptHash도 생성됩니다. 트랜잭션 영수증은 트랜잭션 관리 및 식별을 위한 정보의 세 부분을 기록합니다.첫 번째 부분은 합의 부분인 PostState, Status, CumulativeGasUsed, Bloom 및 Logs입니다.이 다섯 가지 데이터만 ReceiptRLP에 인코딩되어 영수증 해시를 형성합니다. 영수증 해시는 합의에 참여할 것입니다. 데이터의 두 번째 부분은 거래 부분이고, TxHash는 거래 영수증에 해당하는 거래 해시를 말하며, ContractAddress는 거래가 배포될 때 새 계약의 주소이고, GasUsed는 Gas를 나타냅니다. 트랜잭션 사용의 세 번째 부분은 BlockHash 블록 해시, BlockNumber 현재 블록 번호 및 TransactionIndex 트랜잭션의 일련 번호를 블록에 기록하는 블록 부분입니다. Receipt는 데이터 동기화 전략에서 직관적인 차이가 있는데, 아래에서 언급하는 fullSync와 fastSync의 가장 직관적인 차이점은 Peer의 Receipt를 동기화 시킬 것인지 로컬에서 Receipt를 생성할 것인지 입니다.

3. 데이터 캐리어

데이터 전송 캐리어는 피어 노드입니다.이 데이터 캐리어 피어, 소스 코드에서 자세히 검색하면 일부 구석에서 peer.go를 찾을 수 있습니다.먼저 데이터 동기화 모듈에 대해 찾은 피어 구조를 나열합니다. . p2p/peer.go, eth/peer.go, les/peer.go, eth/downloader/peer.go가 있습니다. Ethereum의 네트워크에는 전송 계층, 세션 계층, 프레젠테이션 계층 및 프로토콜 계층도 있습니다.

p2p 패키지의 피어는 기본 노드 모델 역할을 하며 전송 계층은 UDP 프로토콜을 기반으로 인접 피어를 검색하고 피어 연결을 유지하며 TCP 프로토콜을 기반으로 피어 간에 정보 교환 채널을 설정합니다. 세션 레이어의 피어 관리는 주로 노드와 상위 레이어 하위 프로토콜 간의 상호 작용을 관리하는 반면, NodeTable 관리는 주로 UDP 프로토콜을 기반으로 구축된 기본 노드 연결 테이블을 관리합니다. 따라서 p2p 계층의 피어 노드는 하위 프로토콜을 얻고 열 수 있어야 하며 다른 노드에 핑할 수 있어야 하고 물론 다른 노드에서 메시지를 받을 수 있어야 합니다. 이것은 p2p/peer.go, pingLoop, readLoop 및 startProtocols의 세 가지 중요한 기능 모듈에 반영되어 있으며 이는 peer.run() 메서드의 세 가지 기능이기도 합니다.

위는 기본 피어 구조이고 아래 그림은 하위 프로토콜 계층의 피어 구조임을 알 수 있습니다.다른 하위 프로토콜 계층은 서로 다른 피어 구조를 가지므로 eth/peer.go 및 les/peer.go 모든 다른 하위 프로토콜이 다른 데이터 시나리오에 적용됩니다.

우리는 데이터 캐리어가 하위 계층 피어와 하위 프로토콜 계층 피어를 가지고 있으며 데이터 동기화는 통신 프로토콜을 사용하여 두 계층의 피어를 관리하고 연결해야 함을 알 수 있습니다.하위 계층은 피어의 메시지 배포, 메시지 모니터링을 실현합니다. , 하위 프로토콜 계층 피어는 데이터 다운로드 및 동기화를 수행하며 이 두 계층 간의 관리 및 통신을 위해 매우 중요한 protocolManger가 필요합니다.

4. 데이터 동기화 프로세스

그렇다면 protocolManager를 시작하는 방법은 무엇입니까? 위에서 피어 구조를 소개했습니다. 주로 다른 원격 노드를 나타냅니다. 이더리움에는 노드를 나타내는 또 다른 유형의 구조 노드가 있습니다. 주로 로컬 노드 자체를 나타내며 약간 다릅니다. 노드는 p2p를 시작하려고 합니다. 두 가지 작업을 시작하기 위해 Node.Start() 함수를 사용하는 로컬 노드 모듈에 의존해야 합니다. 하나는 Ethereum 서비스를 시작하고 Ethereum.start는 프로토콜 관리자를 시작하고 다른 하나는 p2p를 시작합니다. 서버, K 버킷 생성 및 새로 고침, UDP 포트 모니터링 및 TCP 포트 모니터링을 동시에 활성화하고 원격 노드에서 보낸 메시지를 처리합니다.

protocolManager가 시작되면 기본 논리 계층 피어(p2p)와 최상위 계층 프로토콜 계층 피어(eth)를 연결해야 합니다.

protocolManager가 시작되면 노드는 먼저 NewProtocolManager를 초기화하고 호출하며 초기화 과정에서 SubProtocol 함수를 호출하여 던전 p2p.peer에서 메시지 읽기 및 쓰기 채널을 얻은 다음 메시지 프로세서 Handle, Handle을 빌드합니다. , 동기화를 요청하는 메시지를 수락할 뿐만 아니라 노드 응답 메시지도 수락합니다. protocolManger의 시작 메서드에서 정기적인 동기화 코루틴 syncer를 시작하여 메시지에 따라 데이터 동기화를 수행하기 위해 fecher 또는 다운로더 실행기를 호출합니다. 공고.

• 데이터 동기화 모드

• 활성 데이터 동기화는 로컬 노드가 인접 노드에서 자발적으로 블록 데이터를 요청하고 데이터 항목이 eth/downloader/downloader 및 eth/handler에 있음을 의미합니다.

• 패시브 데이터 동기화는 로컬 노드가 다른 노드로부터 데이터 동기화 메시지(Message)를 수신한 다음 블록 데이터를 요청하는 것을 의미합니다. 데이터 항목은 eth/fetcher/fetcher.go에 있습니다.

• 활성 동기화 프로세스 활성 동기화를 예로 들어 다운로더 실행기가 호출되면 먼저 findAncestor를 호출하여 로컬 체인과 원격 체인의 공통 조상을 찾고 공통 조상에서 동기화를 시작하며 4개의 가져오기를 구성합니다. 즉, fetcherHeader 및 fetcherBodies, fetcherReceipts, ProcessHeaders는 동기화 모드에 따라 최종적으로 processFullSyncContent 및 processFastSyncContent를 호출하고 마지막으로 spawnSync를 호출하여 동기화를 수행합니다.

위는 동기화 과정의 소스 코드인데, 소스 코드에서 주요 다운로드 작업이 그가 구성한 확장 가능한 가져오기에 집중되어 있는 것을 알 수 있는데, 이것이 바로 가져오기 작업 대기열입니다. 서로 다른 데이터 동기화 전략에 따라 페처 태스크 큐의 구조가 다를 뿐만 아니라 페처 간의 협업 프로세스도 다릅니다.

5. 데이터 동기화 전략

가져오기 작업 대기열의 역할은 진행 중, 데이터 채우기, 데이터 조립 및 최종 데이터 삽입으로 요약됩니다. 어떤 종류의 데이터를 채우고, 어떤 데이터를 조합해야 하고, 언제 데이터를 삽입해야 하는지는 모두 데이터 동기화 전략을 나타내는 중요한 데이터 구조 모드로 식별되며 주로 세 가지 유형으로 나뉩니다.

• lightSync: 라이트 노드 동기화, 데이터를 채울 때 블록 헤더 데이터만 채워지고 데이터 어셈블리가 필요하지 않습니다. insertHeaderchain을 호출하여 블록 헤더를 직접 삽입합니다.

• fullSync: 전체 노드 동기화 데이터를 채울 때 블록 헤더와 블록 본문을 채워야 하지만 트랜잭션 영수증은 채우지 않고 데이터를 결과 집합 Result에 조합한 다음 importBlockResults를 호출하여 데이터를 삽입합니다. 결과를 메인 체인에 설정하고, lightSync의 차이점은 빛 동기화를 위한 블록 바디가 없기 때문에 트랜잭션을 실행 및 검증하지 않는 반면, fullSync 풀 노드 동기화는 데이터를 삽입하면서 트랜잭션을 실행하고 검증한다는 점입니다. 동기화 속도가 느리고 자체적으로 트랜잭션 영수증을 생성하므로 Receipt가 작성 및 조립에 참여할 필요가 없습니다.

• 6. 결론

6. 결론

Ethereum 데이터 동기화는 매우 복잡하며 네트워크 아키텍처, 통신 프로토콜 관리, 데이터 전송 채널의 협력, 데이터 동기화 전략 배열 및 데이터 동기화 속도를 높이는 알고리즘을 다룹니다. 많은 세부 사항과 논리적 관계가 있습니다. 그리고 데이터 동기화는 블록체인 노드와 외부 세계 간의 통신의 초석이며 놀라운 건축 이스터 에그가 더 많이 있습니다. 여러분과 공유할 다음 기사를 기대합니다.