블록체인 기초 개념 퀴즈
이 퀴즈는 합의, 머클 트리, 파이널리티, 운영 특성에 대한 이해도를 테스트합니다.
객관식 문제
- Fault model은 어떻게 비교해야 합니까?
- A) 블록체인은 분산 시스템이고 etcd는 단일 노드다
- B) 선택한 consensus를 비교한다. etcd/Raft는 CFT이고 일부 blockchain은 BFT이며 permissioned Fabric도 CFT Raft를 사용할 수 있다
- C) 블록체인은 강한 일관성을 제공하고 etcd는 최종 일관성을 제공한다
- D) etcd는 암호화를 쓰지 않는다
정답 보기
정답: B) 선택한 consensus를 비교한다. etcd/Raft는 CFT이고 일부 blockchain은 BFT이며 permissioned Fabric도 CFT Raft를 사용할 수 있다
설명: Fabric 3.x는 SmartBFT도 제공합니다. Permissioned membership이나 blockchain이라는 명칭 자체가 Byzantine fault tolerance를 뜻하지는 않습니다.
- Full-node replica 추가가 base-chain 쓰기 용량을 자동으로 늘리지 않는 이유는 무엇입니까?
- A) 암호 연산이 느리기 때문
- B) 복제 full-node 검증은 base-chain 쓰기 용량을 자동 증가시키지 않지만 RPC read는 확장할 수 있다
- C) P2P 네트워크의 대역폭 한계 때문
- D) 블록 크기 제한 때문
정답 보기
정답: B) 복제 full-node 검증은 base-chain 쓰기 용량을 자동 증가시키지 않지만 RPC read는 확장할 수 있다
설명: Full node·light client·permissioned 데이터 배포 모델은 다릅니다. 모든 node가 항상 모든 transaction을 검증하거나 replica 수가 어떤 처리량에도 영향을 줄 수 없다고 단정하지 않습니다.
- 머클 트리가 제공하는 핵심 이점은?
- A) 블록 크기를 압축한다
- B) 거래 포함 여부 증명(머클 증명)의 크기가 거래 수 N에 대해 log N으로 자라므로, 전체 체인 없이 검증 가능 — 경량 클라이언트의 근거
- C) 거래 순서를 보장한다
- D) 합의 속도를 높인다
정답 보기
정답: B) 거래 포함 여부 증명(머클 증명)의 크기가 거래 수 N에 대해 log N으로 자라므로, 전체 체인 없이 검증 가능 — 경량 클라이언트의 근거
설명: 거래들을 쌍쌍이 해시해 올라가는 이진 트리 구조 덕분에, 특정 거래가 블록에 있음을 증명하려면 형제 해시들만 있으면 됩니다. 거래 100만 개 블록에서도 증명은 20개 해시 정도입니다. 이것이 경량 클라이언트를 가능하게 하며, 블록체인과 기존 시스템을 연동할 때 "전체 노드를 운영할 것인가, 경량 검증으로 충분한가"라는 선택지가 생기는 근거입니다.
- 합의에 비용(PoW의 전기, PoS의 예치금)이 필요한 근본 이유는?
- A) 검증자에게 보상을 주기 위해
- B) Sybil 공격 방어 — 비용이 없으면 한 주체가 무한히 많은 신원·블록 후보를 만들어 네트워크를 마비시킬 수 있다
- C) 블록 생성 속도를 조절하기 위해
- D) 네트워크 대역폭을 절약하기 위해
정답 보기
정답: B) Sybil 공격 방어 — 비용이 없으면 한 주체가 무한히 많은 신원·블록 후보를 만들어 네트워크를 마비시킬 수 있다
설명: 익명 참여가 가능한 환경에서 정체성만으로는 한 주체가 수많은 신원을 만드는 것(Sybil 공격)을 막을 수 없습니다. PoW는 계산으로, PoS는 자본과 몰수 위험으로 비용을 만듭니다. BFT 계열은 애초에 참여자를 제한해서 이 문제를 회피하므로 PoW의 전기나 PoS의 예치금 없이 투표로 합의할 수 있습니다. 이것이 금융권 컨소시엄 체인 선택의 기술적 근거입니다.
- 파이널리티가 인프라 운영에서 가장 중요한 개념인 이유는?
- A) 합의 속도를 결정하기 때문
- B) 노드가 응답하는 최신 데이터가 아직 확정되지 않은 것일 수 있어, reorg 시 답이 달라지기 때문
- C) 블록 크기를 결정하기 때문
- D) 노드 스토리지 용량을 결정하기 때문
정답 보기
정답: B) 노드가 응답하는 최신 데이터가 아직 확정되지 않은 것일 수 있어, reorg 시 답이 달라지기 때문
설명: 노드는 자기가 아는 최신 체인 기준으로 답하는데, 그 블록이 나중에 재조직(reorg)되면 답이 달라집니다. 이것이 실제 사고로 이어집니다 — 최신 블록 기준으로 입금을 확인해 처리했는데 reorg로 입금이 사라지거나, 여러 노드에 분산하는 로드밸런서에서 노드별 체인 높이가 달라 같은 질문에 다른 답이 나옵니다. 그래서 애플리케이션에 confirmation depth가 필수이고, 인프라 쪽에서는 동기화 상태를 readiness에 넣고 노드 간 체인 높이 편차를 모니터링해야 합니다.
- 블록체인 노드에 영구 볼륨이 필수인 이유는?
- A) 체인 데이터는 네트워크에서 복구할 수 없기 때문
- B) 상태는 히스토리에서 재생 가능하지만 그 재생에 오랜 시간이 걸려, 그 동안 해당 노드가 서비스할 수 없기 때문
- C) Kubernetes가 StatefulSet에 영구 볼륨을 강제하기 때문
- D) 키가 데이터 디렉터리에 저장되기 때문
정답 보기
정답: B) 상태는 히스토리에서 재생 가능하지만 그 재생에 오랜 시간이 걸려, 그 동안 해당 노드가 서비스할 수 없기 때문
설명: 블록체인 노드의 상태(잔액, 컨트랙트 저장소)는 블록 히스토리를 재생해 도출할 수 있으므로 이론적으로는 재구축 가능합니다. 그러나 제네시스부터 전부 검증·재생하는 full sync는 체인 나이에 비례해 시간이 들고, 수백 GB~수 TB 규모에서는 며칠이 걸릴 수 있습니다. Pod를 교체할 때 상태를 잃으면 그 동안 서비스할 수 없으므로 영구 볼륨이 선택이 아니라 필수입니다.
- Hard-fork client 업그레이드는 어떻게 관리해야 합니까?
- A) 컨테이너 이미지 크기가 커진다
- B) 활성화 전에 fork-compatible client를 canary/rolling 적용하고 이후 비호환 rollback은 별도 평가한다
- C) Pod 재시작 시간이 길어진다
- D) 네트워크 정책을 다시 작성해야 한다
정답 보기
정답: B) 활성화 전에 fork-compatible client를 canary/rolling 적용하고 이후 비호환 rollback은 별도 평가한다
설명: 프로토콜은 정해진 시점에 활성화되지만 호환 client를 미리 설치한다고 현재 chain을 이탈하는 것은 아닙니다. 외부 기한 전에 fleet 준비를 완료합니다.
- 블록체인에서 키 관리가 기존 시스템의 비밀번호 관리와 결정적으로 다른 점은?
- A) 키 길이가 더 길다
- B) 사용 전에 custody·복구를 설계한다. 개인 signing key 손실은 되돌릴 수 없을 수 있으며 KMS 개인 키는 export할 수 없다
- C) 키를 정기적으로 교체해야 한다
- D) 키가 평문으로 전송된다
정답 보기
정답: B) 사용 전에 custody·복구를 설계한다. 개인 signing key 손실은 되돌릴 수 없을 수 있으며 KMS 개인 키는 export할 수 없다
설명: 복구는 키 생성 출처·contract/account 제어·backup 설계에 달려 있습니다. Validator slashing 이력을 보호하고 관리형 HSM이 이전용 개인 키를 제공한다고 가정하지 않습니다.