6장 · 블록체인, 코드로 확인하기

챕터 1부터 5까지, 많은 개념을 배웠어요. 블록체인, 개인키, 트랜잭션, 합의, 스마트 컨트랙트, EVM. 지금 이 순간에도 이더리움 위에서는 수천 개의 트랜잭션이 처리되고 있고, 수조 원의 자산이 코드 한 줄로 이동하고 있어요.

실습: Etherscan에서 USDC 컨트랙트 직접 보기

지금까지 배운 개념들이 실제로 어떻게 구현되어 있는지, 세계에서 가장 많이 쓰이는 스테이블코인 USDC의 스마트 컨트랙트를 통해 살펴볼게요.

USDC는 Circle이 발행하는 달러 연동 스테이블코인이에요. 이더리움 위에서 ERC-20 스마트 컨트랙트로 운영되고 있고, 지금까지 8,100만 건 이상의 트랜잭션이 이 컨트랙트를 통해 처리됐어요.

챕터 1에서 배운 블록체인의 원리부터 챕터 4에서 배운 ERC-20 토큰 표준까지, 모든 개념이 이 컨트랙트 하나에 담겨 있어요.

이더리움의 공식 USDC 컨트랙트 주소는 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48이에요. Etherscan에서 직접 확인할 수 있어요.

→ Etherscan에서 USDC 컨트랙트 보기

1단계: 컨트랙트 기본 정보 확인

Etherscan에 접속하면 상단에 이런 정보가 보여요.

• Token Name: USD Coin (USDC)
• Contract Address: 0xA0b86991...
• Total Supply: 현재 유통 중인 USDC 총량
• Holders: 이 컨트랙트의 잔액을 갖고 있는 주소 수
• Transfers: 지금까지 발생한 전송 횟수

이게 챕터 4에서 배운 ERC-20 컨트랙트예요. 수조 원이 이 주소 하나로 관리돼요.

2단계: Contract 탭 → Read Contract

Contract 탭 → Read Contract를 클릭하면 함수가 두 개밖에 안 나와요.

• implementation: 실제 로직이 있는 컨트랙트 주소
• admin: 업그레이드 권한을 가진 주소

왜 두 개밖에 없을까요?

USDC는 프록시 패턴으로 구현되어 있어요. 챕터 4에서 "스마트 컨트랙트는 한 번 배포되면 수정할 수 없다"고 했는데, Circle은 이 한계를 프록시 패턴으로 우회해요.

구조는 이래요.

사용자 → Proxy 컨트랙트 (0xA0b86991...) → Implementation 컨트랙트 (0x43506849...)

사용자가 접근하는 주소(0xA0b86991...)는 영원히 바뀌지 않아요. 그런데 이 Proxy는 실제 로직을 Implementation 컨트랙트에 위임해요. 버그가 생기거나 기능을 추가해야 하면 Implementation만 새 버전으로 교체해요. Proxy 주소는 그대로 유지하면서요.

3단계: Read as Proxy 탭

Contract 탭 안의 Read as Proxy를 클릭하면 Implementation 컨트랙트의 실제 함수들이 나와요. 챕터 4에서 배운 ERC-20 함수들이 그대로 있어요.

totalSupply 조회

Query 버튼을 누르면 현재 유통 중인 USDC 전체 수량이 나와요. 단위는 6자리 소수점이라 1,000,000 = 1 USDC예요.

balanceOf 조회

입력창에 아무 이더리움 주소나 넣고 Query를 누르면 해당 주소의 USDC 잔액이 나와요. 내 MetaMask 주소를 넣어봐도 돼요. 챕터 4 ERC-20 코드에서 봤던 mapping(address => uint256) public balanceOf가 실제로 조회되는 거예요.

allowance 조회

owner 주소와 spender 주소를 넣으면 대리 전송 허용량이 나와요. 챕터 4의 approve 함수와 연결되는 결과값이에요.

name / symbol / decimals 조회

• name: USD Coin
• symbol: USDC
• decimals: 6 (소수점 6자리)

단순한 정보처럼 보이지만, 이 값들이 있어서 MetaMask, 거래소, DeFi 서비스 어디서든 "이 토큰이 USDC다"라고 자동으로 인식해요. ERC-20 표준의 힘이에요.

4단계: Transfers 탭

Transfers 탭에서 실시간으로 발생하는 USDC 전송 내역을 볼 수 있어요. 각 트랜잭션 해시를 클릭하면 챕터 3에서 배운 트랜잭션 구조가 그대로 나와요.

• From / To: 보내는 주소, 받는 주소
• Value: ETH 전송량 (0 ETH. USDC는 토큰이지 ETH가 아니니까요)
• Gas Used: 실제 소모된 Gas
• Input Data: Data 필드. transfer 함수 호출 데이터가 인코딩되어 있어요

Input Data → Decode Input Data를 클릭하면 "transfer 함수에 이 주소로 이 금액을 보냈다"가 해석돼요. 챕터 4의 ERC-20 transfer 함수가 실제로 호출된 거예요.

5단계: Past Implementations 탭

Contract 탭 안의 Past Implementations를 클릭하면 USDC 컨트랙트가 지금까지 몇 번 업그레이드됐는지 볼 수 있어요.

"배포 후 수정 불가"라는 스마트 컨트랙트의 원칙은 유지하면서, 프록시 패턴으로 실질적인 업그레이드를 가능하게 한 거예요. 각 Implementation은 한 번 배포되면 변경되지 않았어요. 단지 Proxy가 가리키는 주소가 바뀌었을 뿐이에요.

마무리

챕터 1부터 여기까지, 우리는 2008년 리먼 파산에서 시작해서 EVM 위에서 수조 원의 USDC가 코드 한 줄로 이동하는 세계까지 왔어요.

블록체인은 중앙 기관 없이 신뢰를 만들었어요. 개인키로 신원을 증명했어요. 트랜잭션으로 요청을 표준화했어요. 합의로 장부를 확정했어요. 스마트 컨트랙트로 조건부 계약을 자동화했어요. EVM으로 어디서나 같은 결과를 냈어요.

그리고 이 기술들이 현실 세계와 만나면서 새로운 질문들이 생겨났어요.

모든 거래가 공개되는데 금융기관이 쓸 수 있을까? 체인이 여러 개 생겼는데 서로 통신할 수 없다. 메인넷이 느리고 비싸다. 양자컴퓨터가 개인키를 뚫을 수 있다면? 블록체인 위에서 내 신원을 스스로 증명할 수 없을까?

이 질문들에 대한 답이 심화 챕터에서 이어져요.

핵심 요약