위키원
"브로드캐스팅"의 두 판 사이의 차이
tjdwhd2401 (토론 | 기여) |
tjdwhd2401 (토론 | 기여) |
||
| 23번째 줄: | 23번째 줄: | ||
==활용== | ==활용== | ||
===비트코인=== | ===비트코인=== | ||
| + | ====블록 브로드캐스팅==== | ||
| + | 광부가 새로운 블록을 발견하면 다음 방법 중 하나를 사용하여 새로운 블록을 피어에게 브로드 캐스팅합니다. | ||
| + | *요청하지 않은 블록 푸시 | ||
| + | 광부는 새로운 블록을 가진 전체 노드 피어들에게 block 메시지를 보냅니다. 광부는 표준 릴레이 방법을 합리적으로 우회 할 수 있습니다. 왜냐하면 피어가 이미 방금 발견 된 블록을 갖고 있지 않다는 것을 알고 있기 때문입니다. | ||
| + | *표준 블록 릴레이 | ||
| + | 표준 릴레이 노드로 작동하는 광부는 새로운 블록을 참조하는 인벤토리로 각 피어 (전체 노드 및 SPV 모두)에 inv 메시지를 전송합니다. 가장 일반적인 응답은 다음과 같습니다. | ||
| + | *블록을 원하는 각 블록 우선 (BF) 피어는 전체 블록을 요청하는 getdata 메시지로 응답합니다. | ||
| + | *블록을 원하는 각 헤더 우선 (first-first (HF)) 피어는 최상의 헤더 체인에서 가장 높은 헤더의 헤더 해시를 포함하는 getheaders 메시지로 응답하고 일부 헤더는 포크 감지를 허용하는 최상의 헤더 체인으로 되돌아갑니다. 이 메시지 바로 뒤에 전체 블록을 요청하는 getdata 메시지가옵니다. 먼저 헤더를 요청하면 헤더 우선 피어는 아래의 하위 섹션에서 설명한대로 고아 블록을 거부 할 수 있습니다. | ||
| + | *블록을 원하는 각 SPV (Simplified Payment Verification) 클라이언트는 일반적으로 머클 블록을 요청하는 getdata 메시지로 응답합니다. | ||
| + | *다이렉트 헤더 발표 (Direct Headers Announcement) : 중계 노드는 새로운 블록의 전체 헤더를 포함하는 header 메시지를 즉시 전송함으로써 invheader에 의해 따라오는 inv 메시지의 왕복 오버 헤드를 건너 뛸 수있다. 이 메시지를 수신 한 HF 피어는 헤더 첫 번째 IBD 동안 블록 헤더를 부분적으로 검증 한 다음 헤더가 유효하면 getdata 메시지로 전체 블록 내용을 요청합니다. 그런 다음 중계 노드는 블록 또는 merkleblock 메시지의 전체 또는 필터링 된 블록 데이터로 getdata 요청에 응답합니다. HF 노드는 접속 핸드 세이크 중에 특별한 sendheaders 메시지를 전송함으로써 inv 공지 대신에 header를 수신하는 것을 선호한다고 신호 할 수있다. | ||
| + | ====거래 브로드캐스팅==== | ||
| + | 피어 (peer)에게 트랜잭션을 보내려면 inv 메시지가 전송됩니다. getdata 응답 메시지가 수신되면 트랜잭션은 tx를 사용하여 전송됩니다. 이 트랜잭션을 수신하는 피어는 유효한 트랜잭션 인 경우 동일한 방식으로 트랜잭션을 전달합니다. | ||
{{각주}} | {{각주}} | ||
2019년 8월 1일 (목) 14:14 판
브로드캐스팅(broadcasting)은 일반적으로 데이터를 전송할 때, 복수의 단말 장치에 대해 동일한 정보나 메시지를 일제히 전송하는 통신 기술을 일컫는다. 한편 블록체인과 관련하여 전파라는 의미로 쓰이기도 한다.
그 예로 P2P 네트워크의 작동 원리를 살펴보면, P2P 네트워크로 거래 기록을 받은 모든 참가자들은 거래 기록을 승인하는 작업을 수행한다. 승인한 사람은 기존 블록체인에 새로운 블록을 추가하고, 이 블록을 P2P 네트워크를 통해 참가자 전원에게 브로드캐스팅(전파) 한다.
개요
브로드캐스트는 원래 '씨앗을 뿌리다'에서 '말을 퍼뜨리다'를 거쳐 '방송하다'는 뜻으로 쓰이게 되었다. 1912년 브로드캐스팅이란 단어가 미 해군에 의해 최초로 '명령을 무선으로 한꺼번에 여러 군함에 보낸다'는 의미로 사용되었으며, 바로 그해에 미 의회는 무선커뮤니케이션의 '교통정리'를 위해 라디오 사용을 원하는 사람은 누구나 통상, 노동장관의 허가를 얻어야 한다고 규정한 '1912년 라디오법'을 통과시켰다.
특징
브로드캐스팅(Broadcasting) 방식은 특정 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트에 전달된다는 특징이 있다. WAN 같은 원거리 통신망에서는 특정 호스트 사이를 직접 연결한 전송 매체가 있는지, 아니면 어떤 우회 경로로 몇 단계를 거쳐서 연결할 수 있는지에 대한 판단이 중요하다. 그러나 LAN에서는 연결의 존재 여부보다는 데이터를 목적지 호스트까지 얼마나 효율적으로 전달할 수 있는지가 중요한 잣대가 된다. 이를 지원하는 브로드캐스팅 방식은 네트워크의 모든 호스트를 하나의 전송 매체로 연결하므로, 중개 기능을 수행하는 교환 호스트가 필요 없다. 앞서 설명한 것처럼 브로드캐스팅 방식은 네트워크의 모든 호스트가 하나의 전송 매체를 공유하므로 임의의 송신 호스트에서 보낸 데이터가 네트워크의 모든 호스트에 전달된다. 따라서 데이터를 수신하도록 지정된 호스트는 해당 데이터를 수신하고 보관해야 하지만, 다른 호스트는 수신한 데이터를 버려야 한다.[1]
종류
버스형
버스(Bus)형 구조에서는 다수의 호스트가 하나의 전송 매체를 공유하므로 전송 데이터를 모든 호스트에서 수신할 수 있다. 그러나 둘 이상의 호스트에서 데이터를 동시에 전송하면 데이터 충돌(Collision)이 발생할 수 있으므로 충돌에 따른 오류 문제를 해결해야 한다. 충돌 문제는 크게 두 가지 방법으로 해결할 수 있다. 첫째, 호스트의 전송 권한을 제한함으로써 사전에 충돌을 예방할 수 있다. 이 방식에서 호스트가 데이터를 전송하려면 사전에 전송 권한을 확보해야 한다. 전송 권한을 확보하는 방법에는 전송 시간대를 분할하여 각 호스트별로 데이터를 전송할 수 있는 시간대(Time Slice)를 다르게 지정하는 방법과 토큰(Token)으로 전송 권한을 순환적으로 이용하는 방법이 있다. 충돌을 해결하는 두 번째 방식은 충돌 허용이다. 둘 이상의 호스트가 데이터를 동시에 전송할 수 있도록 허용하지만, 충돌이 발생했을 때 이를 감지하고 해결하는 과정이 필요하다. 대표적인 공유 버스 방식인 이더넷(Ethernet)에서 채택하는 방식이 충돌 허용의 예다.
링형
링(Ring)형에서는 전송 데이터가 링 주위를 특정 방향으로 순환하면서 전달된다. 자신이 수신 호스트가 아닌 호스트는 데이터를 수신하지 않고 그냥 통과시켜야 한다. 수신 호스트로 지정된 호스트는 전송 데이터를 자신의 내부 버퍼에 보관하고, 데이터는 계속해서 링으로 순환시켜야 한다. 링을 한 바퀴 순환한 데이터는 원래의 송신 호스트에 다시 되돌아온다. 송신 호스트는 자신이 전송한 데이터를 링에서 회수함으로써 전송 과정을 종료하고, 이전에 확보한 토큰을 링에 돌려주어 다른 호스트가 데이터를 전송할 수 있도록 한다. 링형에서는 여러 호스트가 데이터를 동시에 전송함으로써 발생할 수 있는 충돌 문제를 해결하려고 토큰 기능을 사용한다. 호스트들이 데이터를 전송하지 않을 때는 토큰이 링 주위를 순환하게 된다. 따라서 임의의 호스트가 데이터를 전송하고자 하면 이 토큰을 획득하여 데이터를 전송하고, 데이터 전송을 완료하면 다시 토큰을 네트워크에 돌려준다.[1]
활용
비트코인
블록 브로드캐스팅
광부가 새로운 블록을 발견하면 다음 방법 중 하나를 사용하여 새로운 블록을 피어에게 브로드 캐스팅합니다.
- 요청하지 않은 블록 푸시
광부는 새로운 블록을 가진 전체 노드 피어들에게 block 메시지를 보냅니다. 광부는 표준 릴레이 방법을 합리적으로 우회 할 수 있습니다. 왜냐하면 피어가 이미 방금 발견 된 블록을 갖고 있지 않다는 것을 알고 있기 때문입니다.
- 표준 블록 릴레이
표준 릴레이 노드로 작동하는 광부는 새로운 블록을 참조하는 인벤토리로 각 피어 (전체 노드 및 SPV 모두)에 inv 메시지를 전송합니다. 가장 일반적인 응답은 다음과 같습니다.
- 블록을 원하는 각 블록 우선 (BF) 피어는 전체 블록을 요청하는 getdata 메시지로 응답합니다.
- 블록을 원하는 각 헤더 우선 (first-first (HF)) 피어는 최상의 헤더 체인에서 가장 높은 헤더의 헤더 해시를 포함하는 getheaders 메시지로 응답하고 일부 헤더는 포크 감지를 허용하는 최상의 헤더 체인으로 되돌아갑니다. 이 메시지 바로 뒤에 전체 블록을 요청하는 getdata 메시지가옵니다. 먼저 헤더를 요청하면 헤더 우선 피어는 아래의 하위 섹션에서 설명한대로 고아 블록을 거부 할 수 있습니다.
- 블록을 원하는 각 SPV (Simplified Payment Verification) 클라이언트는 일반적으로 머클 블록을 요청하는 getdata 메시지로 응답합니다.
- 다이렉트 헤더 발표 (Direct Headers Announcement) : 중계 노드는 새로운 블록의 전체 헤더를 포함하는 header 메시지를 즉시 전송함으로써 invheader에 의해 따라오는 inv 메시지의 왕복 오버 헤드를 건너 뛸 수있다. 이 메시지를 수신 한 HF 피어는 헤더 첫 번째 IBD 동안 블록 헤더를 부분적으로 검증 한 다음 헤더가 유효하면 getdata 메시지로 전체 블록 내용을 요청합니다. 그런 다음 중계 노드는 블록 또는 merkleblock 메시지의 전체 또는 필터링 된 블록 데이터로 getdata 요청에 응답합니다. HF 노드는 접속 핸드 세이크 중에 특별한 sendheaders 메시지를 전송함으로써 inv 공지 대신에 header를 수신하는 것을 선호한다고 신호 할 수있다.
거래 브로드캐스팅
피어 (peer)에게 트랜잭션을 보내려면 inv 메시지가 전송됩니다. getdata 응답 메시지가 수신되면 트랜잭션은 tx를 사용하여 전송됩니다. 이 트랜잭션을 수신하는 피어는 유효한 트랜잭션 인 경우 동일한 방식으로 트랜잭션을 전달합니다.
각주
참고자료
- 〈브로드캐스팅 방식〉《네이버 지식백과》
- 〈비트코인 개발자 가이드〉《WikiDocs》
- FXTM 공식홈페이지, 〈비트코인 트랜잭션:원리 알아보기〉《FXTM》
- 심심재, 〈블록체인 처리 흐름〉《티스토리》, 2018-02-04
같이 보기
