diff --git a/week-05/quiz/quiz-05-solution.md b/week-05/quiz/quiz-05-solution.md new file mode 100644 index 00000000..b6206868 --- /dev/null +++ b/week-05/quiz/quiz-05-solution.md @@ -0,0 +1,436 @@ +# Week 5 Quiz: PoS/Consensus + RainbowKit + +> **제출 방법:** 이 파일을 복사하여 답변을 작성한 후, PR로 제출하세요. +> **평가 기준:** 개념 이해도 중심 - 문법 오류보다 논리적 설명을 중시합니다. + +--- + +## 문제 1: PoS 개념 (객관식) + +이더리움이 PoW(작업 증명)에서 PoS(지분 증명)로 전환한 **가장 주요한 이유**는 무엇인가요? + +**보기:** +A) 트랜잭션 처리 속도를 10배 이상 높이기 위해 +B) 에너지 소비를 99.95% 이상 줄이고 환경 친화적으로 만들기 위해 +C) 블록 크기를 늘려서 더 많은 데이터를 저장하기 위해 +D) 채굴 장비 없이도 누구나 블록을 생성할 수 있게 하기 위해 + +**답변:** +B) PoW에서 이더리움은 소규모 국가 수준의 전력을 소비했습니다. 채굴자들이 해시 연산 경쟁을 하기 위해 GPU/ASIC을 24시간 가동해야 했기 때문입니다. 2022년 9월 The Merge를 통해 PoS로 전환한 후 에너지 소비가 99.95% 이상 감소했습니다. PoS에서는 채굴 대신 ETH를 스테이킹하여 검증자가 되므로, 대규모 연산 장비가 필요 없습니다. A는 부분적으로만 맞습니다 — PoS 자체가 직접적으로 처리 속도를 10배 높이지는 않으며, 이는 샤딩이나 L2 솔루션의 역할입니다. D도 부분적으로 맞지만 32 ETH가 필요하므로 "누구나"는 아닙니다. + + +--- + +## 문제 2: 검증자 역할 (객관식) + +이더리움 PoS에서 검증자(Validator)가 수행하는 **두 가지 주요 역할**은 무엇인가요? + +**보기:** +A) 블록 채굴(Mining)과 가스 가격 결정 +B) 블록 제안(Proposing)과 블록 증명(Attesting) +C) 트랜잭션 전송과 수수료 수집 +D) 스마트 컨트랙트 배포와 실행 + +**답변:** +B) PoS에서 검증자는 두 가지 핵심 역할을 합니다: +- **블록 제안(Proposing)**: 각 슬롯(12초)마다 랜덤하게 선정된 1명의 검증자가 새로운 블록을 생성하여 네트워크에 제안합니다. 블록에는 트랜잭션, 상태 루트, 이전 블록 참조 등이 포함됩니다. +- **블록 증명(Attesting)**: 나머지 검증자들이 제안된 블록이 유효한지 검증하고, 유효하다고 판단되면 "이 블록이 맞다"는 증명(attestation)에 서명합니다. 충분한 수의 attestation이 모이면 블록이 확정됩니다. + +A의 "채굴"은 PoW의 개념이고, PoS에서는 더 이상 사용되지 않습니다. + + +--- + +## 문제 3: 왜 PoW에서 PoS로? (단답형) + +PoW(작업 증명)와 PoS(지분 증명)의 **핵심 차이점**은 무엇인가요? +"자격 증명 방식"과 "보안 보장 방식" 두 관점에서 각각 비교하세요. + +**답변:** +자격 증명 방식: +- **PoW**: 연산 능력(해시파워)으로 자격을 증명합니다. 더 많은 연산 장비를 가진 채굴자가 블록을 생성할 확률이 높습니다. 진입 장벽은 하드웨어 투자입니다. +- **PoS**: 경제적 지분(스테이킹)으로 자격을 증명합니다. 32 ETH를 예치한 검증자가 블록을 제안하고 증명합니다. 진입 장벽은 자본 투자입니다. + +보안 보장 방식: +- **PoW**: 51% 공격을 하려면 전체 네트워크 해시파워의 과반을 장악해야 합니다. 이를 위한 하드웨어 비용이 공격을 억제합니다. 하지만 공격 후 하드웨어를 되팔 수 있어 "공격 비용 회수"가 가능합니다. +- **PoS**: 공격을 하려면 전체 스테이킹의 2/3를 장악해야 합니다. 악의적 행동이 감지되면 스테이킹된 ETH가 **슬래싱(소각)**되므로, 공격자는 자신의 자산을 영구적으로 잃습니다. "공격하면 돈을 잃는" 구조가 보안의 핵심입니다. + + +--- + +## 문제 4: 슬래싱의 목적 (단답형) + +슬래싱(Slashing)은 검증자의 스테이킹된 ETH를 **강제로 소각**하는 패널티입니다. + +1) 슬래싱이 발동되는 **두 가지 조건**은 무엇인가요? +2) **왜** 이런 처벌이 필요한가요? 없다면 어떤 문제가 생길 수 있나요? + +**답변:** +1) 슬래싱 조건 (2가지): + - **이중 제안(Double Proposing)**: 같은 슬롯에 두 개의 서로 다른 블록을 제안하는 것. 하나의 슬롯에는 하나의 블록만 있어야 하므로, 두 블록을 제안하는 것은 체인 분열을 의도하는 악의적 행위입니다. + - **서라운드 투표(Surround Voting)**: 이전 attestation과 모순되는 attestation을 하는 것. 예를 들어 "블록 A가 정규 체인"이라고 증명한 후 "블록 A를 포함하지 않는 블록 B가 정규 체인"이라고 증명하면, 이중 투표(double voting)에 해당합니다. + +2) 슬래싱이 필요한 이유: + 슬래싱이 없다면 검증자가 악의적 행동을 해도 아무런 경제적 손실이 없습니다. 공격자는 이중 제안으로 체인을 분열시키거나, 이중 투표로 잘못된 블록을 확정시키려 시도할 수 있습니다. 실패해도 손해가 없으므로 "무한히 시도"가 가능해집니다. 슬래싱은 악의적 행동에 직접적인 경제적 처벌(32 ETH의 일부 또는 전부 소각)을 부과하여, 공격의 기대 비용을 기대 이익보다 훨씬 높게 만듭니다. + + +--- + +## 문제 5: 체인 선택 규칙 (단답형) + +여러 유효한 블록이 동시에 제안되면 **포크(Fork)**가 발생합니다. +이더리움의 LMD-GHOST(Latest Message Driven GHOST) 규칙은 어떻게 "정규 체인"을 선택하나요? + +1) LMD-GHOST의 기본 원리는 무엇인가요? +2) **왜** "가장 최근 메시지"를 사용하나요? (오래된 메시지를 사용하면 어떤 문제가?) + +**답변:** +1) LMD-GHOST 원리: + 포크가 발생하면, 각 검증자의 **가장 최근(Latest) attestation**을 기준으로 어떤 포크가 더 많은 지지를 받는지 계산합니다. 루트에서 시작하여 각 분기점에서 더 많은 attestation 가중치를 가진 쪽을 선택하며 내려갑니다(Greedy Heaviest Observed Sub-Tree). 이렇게 하면 가장 많은 검증자가 지지하는 체인이 정규 체인으로 선택됩니다. + +2) 최근 메시지 사용 이유: + 오래된 메시지를 사용하면 검증자가 마음을 바꿔 다른 포크를 지지해도 반영되지 않습니다. 공격자가 초기에 많은 attestation을 확보하면 나중에 정직한 검증자가 아무리 많이 반대해도 공격 체인이 선택될 수 있습니다. "최신 메시지"를 사용하면 검증자가 더 많은 정보(네트워크 상태, 다른 attestation 등)를 바탕으로 판단을 업데이트할 수 있고, 네트워크가 빠르게 하나의 체인으로 수렴합니다. 이는 활성(liveness)과 안전성(safety)의 균형을 맞추는 핵심 메커니즘입니다. + + +--- + +## 문제 6: RainbowKit Provider 계층 (빈칸 채우기) + +다음 코드의 빈칸을 채워서 RainbowKit을 올바르게 설정하세요. +**Provider 순서가 중요합니다!** + +```typescript +'use client'; + +// TODO: 필요한 스타일 import +_________________________________________ + +import { RainbowKitProvider } from '@rainbow-me/rainbowkit'; +import { WagmiProvider } from 'wagmi'; +import { QueryClientProvider, QueryClient } from '@tanstack/react-query'; +import { config } from '@/config/wagmi'; + +const queryClient = new QueryClient(); + +export default function RootLayout({ children }) { + return ( + + + {/* TODO: Provider를 올바른 순서로 중첩하세요 */} + <_________________ config={config}> + <_________________ client={queryClient}> + <_________________> + {children} + + + + + + ); +} +``` + +**답변:** +```typescript +'use client'; + +import '@rainbow-me/rainbowkit/styles.css'; + +import { RainbowKitProvider } from '@rainbow-me/rainbowkit'; +import { WagmiProvider } from 'wagmi'; +import { QueryClientProvider, QueryClient } from '@tanstack/react-query'; +import { config } from '@/config/wagmi'; + +const queryClient = new QueryClient(); + +export default function RootLayout({ children }) { + return ( + + + + + + {children} + + + + + + ); +} +``` + +**왜 이 순서인가요:** +Provider 순서가 중요한 이유는 **의존성 방향** 때문입니다: +1. **WagmiProvider** (가장 바깥): 블록체인 연결 설정(config)을 제공합니다. 모든 wagmi hook과 RainbowKit이 이 컨텍스트에 의존합니다. +2. **QueryClientProvider** (중간): React Query의 캐싱/상태 관리를 제공합니다. wagmi의 데이터 페칭이 React Query를 사용하므로 WagmiProvider 안에 있어야 합니다. +3. **RainbowKitProvider** (가장 안쪽): 지갑 연결 UI를 제공합니다. wagmi의 연결 상태와 React Query의 캐싱을 모두 사용하므로 가장 안쪽에 위치합니다. + +순서가 잘못되면 "Cannot find WagmiContext" 같은 에러가 발생합니다. RainbowKit 스타일 CSS를 import하지 않으면 ConnectButton 등의 UI가 깨집니다. + + +--- + +## 문제 7: Provider 순서 버그 (취약점 찾기) + +다음 코드에서 **문제점**을 찾고 수정하세요: + +```typescript +// BAD CODE - 문제점 찾기 +'use client'; + +import '@rainbow-me/rainbowkit/styles.css'; +import { RainbowKitProvider } from '@rainbow-me/rainbowkit'; +import { WagmiProvider } from 'wagmi'; +import { QueryClientProvider, QueryClient } from '@tanstack/react-query'; +import { config } from '@/config/wagmi'; + +const queryClient = new QueryClient(); + +export default function Providers({ children }) { + return ( + // 문제가 있는 Provider 순서! + + + + {children} + + + + ); +} +``` + +**1) 발견한 문제점:** +Provider 순서가 잘못되었습니다. `WagmiProvider`가 가장 안쪽에 있고, `QueryClientProvider`가 가장 바깥에 있습니다. `RainbowKitProvider`는 `WagmiProvider` 바깥에 위치해 wagmi 컨텍스트에 접근할 수 없습니다. + + +**2) 왜 이것이 문제인가:** +`RainbowKitProvider`는 내부적으로 wagmi의 hook들(`useAccount`, `useConnect` 등)을 사용합니다. 이 hook들은 `WagmiProvider`가 제공하는 컨텍스트에 의존합니다. 현재 코드에서 `RainbowKitProvider`는 `WagmiProvider` 바깥에 있으므로, wagmi 컨텍스트를 찾을 수 없어 `"Cannot find WagmiContext"` 런타임 에러가 발생합니다. 또한 `children` 안의 컴포넌트에서 wagmi hook을 사용할 때도, `WagmiProvider`가 가장 안쪽이라 상위 Provider들이 wagmi 기능을 사용할 수 없습니다. + + +**3) 올바른 수정 방법:** +```typescript +'use client'; + +import '@rainbow-me/rainbowkit/styles.css'; +import { RainbowKitProvider } from '@rainbow-me/rainbowkit'; +import { WagmiProvider } from 'wagmi'; +import { QueryClientProvider, QueryClient } from '@tanstack/react-query'; +import { config } from '@/config/wagmi'; + +const queryClient = new QueryClient(); + +export default function Providers({ children }) { + return ( + + + + {children} + + + + ); +} +``` + +--- + +## 문제 8: 트랜잭션 상태 처리 (빈칸 채우기) + +다음 코드의 빈칸을 채워서 트랜잭션 전송 후 **확인 상태를 추적**하세요: + +```typescript +'use client'; + +import { useWriteContract, _________________ } from 'wagmi'; + +const abi = [ + { + name: 'increment', + type: 'function', + stateMutability: 'nonpayable', + inputs: [], + outputs: [], + }, +] as const; + +function IncrementButton() { + const { writeContract, data: hash, isPending } = useWriteContract(); + + // TODO: 트랜잭션 확인 상태를 추적하는 hook + const { isLoading: isConfirming, isSuccess } = _________________({ + _________________, + }); + + return ( +
+ + + {isSuccess &&

트랜잭션 성공!

} +
+ ); +} +``` + +**답변:** +```typescript +'use client'; + +import { useWriteContract, useWaitForTransactionReceipt } from 'wagmi'; + +const abi = [ + { + name: 'increment', + type: 'function', + stateMutability: 'nonpayable', + inputs: [], + outputs: [], + }, +] as const; + +function IncrementButton() { + const { writeContract, data: hash, isPending } = useWriteContract(); + + const { isLoading: isConfirming, isSuccess } = useWaitForTransactionReceipt({ + hash, + }); + + return ( +
+ + + {isSuccess &&

트랜잭션 성공!

} +
+ ); +} +``` + +**트랜잭션 상태 흐름을 설명하세요:** +1) **isPending 상태**: 사용자가 버튼을 클릭한 후, 지갑(MetaMask 등)에서 트랜잭션 서명을 대기하는 상태입니다. 사용자가 서명하기 전까지 이 상태가 유지됩니다. +2) **isConfirming 상태**: 사용자가 서명을 완료하여 트랜잭션이 네트워크에 제출된 후, 블록에 포함되어 확인(confirm)되기를 대기하는 상태입니다. `useWaitForTransactionReceipt`가 트랜잭션 해시(`hash`)를 이용해 영수증(receipt)을 폴링합니다. +3) **isSuccess 상태**: 트랜잭션이 블록에 포함되고 성공적으로 실행된 상태입니다. receipt를 받았고 status가 성공이면 true가 됩니다. + + +--- + +## 문제 9: 검증자 생애주기 (다이어그램 해석) + +다음 다이어그램은 이더리움 검증자의 생애주기를 보여줍니다: + +```mermaid +stateDiagram-v2 + [*] --> Pending: 32 ETH 입금 + Pending --> Active: 활성화 큐 대기 + Active --> Slashed: 규칙 위반 + Active --> Exiting: 자발적 종료 + Exiting --> Exited: 출금 대기 + Slashed --> Exited: 강제 퇴장 + Exited --> [*]: ETH 출금 +``` + +**질문:** + +1) **Active** 상태에서 검증자가 수행하는 주요 활동은 무엇인가요? + +**답변:** Active 상태의 검증자는 두 가지 주요 활동을 수행합니다. 첫째, 랜덤하게 선정되었을 때 **블록을 제안(propose)**합니다. 둘째, 다른 검증자가 제안한 블록의 유효성을 검증하고 **attestation(증명)**에 서명합니다. 또한 sync committee에 참여하여 Light Client가 체인을 따라갈 수 있도록 돕기도 합니다. 이러한 의무를 성실히 수행하면 보상(ETH)을 받고, 빠뜨리면 소량의 패널티를 받습니다. + + +2) Active에서 **Slashed**로 전이되는 조건은 무엇인가요? 이 경우 검증자에게 어떤 일이 발생하나요? + +**답변:** 이중 제안(같은 슬롯에 두 블록 제안) 또는 이중 투표/서라운드 투표(모순된 attestation) 같은 **합의 규칙 위반** 시 Slashed 상태로 전이됩니다. Slashed된 검증자에게는: (1) 즉시 스테이킹의 1/32(약 1 ETH)이 소각되고, (2) 이후 약 36일간 추가 소각이 진행되며(같은 시기에 슬래싱된 검증자가 많을수록 더 많이 소각), (3) 검증 의무에서 제외되어 보상을 받을 수 없고, (4) 강제로 Exited 상태로 퇴장 처리됩니다. + + +3) 검증자가 자발적으로 종료(**Exiting**)하려면 왜 바로 ETH를 출금할 수 없고 대기 기간이 필요한가요? + +**답변:** 대기 기간이 필요한 이유는 네트워크 안정성과 보안 때문입니다. 첫째, 검증자가 나가기 직전에 악의적 행동을 했을 가능성이 있으므로, 대기 기간 동안 해당 행위가 발견되면 슬래싱할 수 있어야 합니다(책임 추적 기간). 둘째, 많은 검증자가 동시에 빠져나가면 네트워크의 보안 수준이 급격히 떨어지므로, 출금 큐를 통해 이탈 속도를 제한하여 항상 충분한 수의 활성 검증자를 유지합니다. 셋째, 검증자의 마지막 attestation이 확정(finalized)될 때까지 기다려야 포크 선택 규칙에 영향을 주지 않습니다. + + +--- + +## 문제 10: Provider 계층 구조 (다이어그램 해석) + +다음 다이어그램은 RainbowKit/wagmi 앱의 Provider 구조를 보여줍니다: + +```mermaid +graph TD + subgraph App["React App"] + WP["WagmiProvider
config 제공"] + QP["QueryClientProvider
캐싱/상태관리"] + RP["RainbowKitProvider
지갑 UI"] + COMP["Components
useAccount, useWriteContract 등"] + end + + WP --> QP --> RP --> COMP + + subgraph Deps["의존성"] + CONFIG["wagmi config"] + QC["QueryClient"] + WALLET["지갑 연결 상태"] + end + + CONFIG -.-> WP + QC -.-> QP + WP -.-> RP + QP -.-> COMP +``` + +**질문:** + +1) **WagmiProvider**가 가장 바깥에 있어야 하는 이유는 무엇인가요? + +**답변:** WagmiProvider는 블록체인 연결 설정(config: 체인 정보, 트랜스포트, 커넥터 등)을 React Context로 제공합니다. QueryClientProvider와 RainbowKitProvider 모두 내부적으로 wagmi의 기능을 사용하므로, WagmiProvider가 이들 바깥에 있어야 wagmi 컨텍스트에 접근할 수 있습니다. React의 Context API는 트리 상위에서 하위로만 값을 전달할 수 있으므로, 의존성의 근원인 WagmiProvider가 최상위에 위치해야 합니다. + + +2) **QueryClientProvider**의 역할은 무엇인가요? 없다면 어떤 문제가 발생하나요? + +**답변:** QueryClientProvider는 React Query(TanStack Query)의 캐싱, 자동 재시도, 백그라운드 리페치 등의 서버 상태 관리 기능을 제공합니다. wagmi v2는 내부적으로 React Query를 사용하여 블록체인 데이터를 관리합니다. QueryClientProvider가 없으면 `useReadContract`, `useBalance` 같은 wagmi hook들이 "No QueryClient set" 에러를 발생시킵니다. 또한 캐싱이 없으면 같은 데이터를 매번 RPC로 요청하여 성능이 크게 저하되고, 불필요한 네트워크 비용이 발생합니다. + + +3) 아래 코드에서 `useAccount()` hook이 **"Cannot find WagmiContext"** 오류를 발생시키는 이유는 무엇인가요? + +```typescript +// 오류 발생 코드 + + + {/* WagmiProvider가 안쪽에 있음 */} + {/* useAccount() 호출 */} + + + +``` + +**답변:** 이 코드에서 `MyComponent`는 `WagmiProvider` 안에 있으므로 `useAccount()`가 정상 작동할 것처럼 보이지만, 실제 문제는 `RainbowKitProvider`에 있습니다. `RainbowKitProvider`는 `WagmiProvider`보다 바깥에 위치해 있는데, RainbowKit 내부에서 wagmi hook을 사용하려고 합니다. WagmiProvider가 RainbowKitProvider의 자식이므로, RainbowKit이 초기화될 때 WagmiContext를 찾을 수 없어 에러가 발생합니다. 올바른 순서는 WagmiProvider → QueryClientProvider → RainbowKitProvider입니다. React Context는 **부모에서 자식으로만** 흐르므로, 의존하는 Provider는 반드시 의존 대상보다 안쪽(자식)에 위치해야 합니다. + + +--- + +## 제출 전 체크리스트 + +- [x] 모든 문제에 답변을 작성했는가? +- [x] 객관식 문제: 정답 선택 **이유**를 설명했는가? +- [x] 단답형 문제: 2-3문장 이상으로 충분히 설명했는가? +- [x] 코드 문제: 완성된 코드와 **왜 그렇게 작성했는지** 설명했는가? +- [x] 다이어그램 문제: 각 질문에 논리적으로 답변했는가?