
Avalanche의 P·C·X-Chain과 독립 L1 구조 이해하기
- whackur
- Blockchain
- 2026년 11월 10일
목차
Avalanche는 공용 Primary Network와 독립적으로 운영되는 Avalanche L1들이 연결된 블록체인 플랫폼입니다. Primary Network 안에서는 C-Chain이 스마트컨트랙트를, P-Chain이 스테이킹과 검증자 등록을, X-Chain이 네이티브 자산 발행·전송을 맡습니다. 별도로 만든 L1은 자체 검증자와 실행 규칙을 사용하며, 그 보안도 해당 L1이 책임집니다. 이 구분을 알아야 C-Chain의 DeFi와 게임·기관용 네트워크를 같은 기준으로 오해하지 않습니다. Primary Network, Avalanche L1s
세 체인과 검증자 집합
체인은 거래와 상태를 기록하는 개별 원장입니다. VM(가상 머신)은 어떤 거래가 유효하고 상태가 어떻게 바뀌는지 정하는 실행 규칙이며, EVM은 그중 하나입니다. 검증자는 이 규칙을 확인하고 블록 합의에 참여하는 노드입니다. Avalanche L1 하나의 검증자 집합은 하나 이상의 체인을 검증할 수 있습니다. Primary Network가 세 체인을 운영하는 경우가 그 예입니다. L1 구조
| 구분 | P-Chain | C-Chain | X-Chain |
|---|---|---|---|
| 정식 이름 | Platform Chain | Contract Chain | Exchange Chain |
| 맡는 일 | 스테이킹, 검증자·L1 등록과 변경 기록 | Solidity 계약, DeFi, ERC-20·NFT | Avalanche Native Token 발행·전송 |
| VM | PlatformVM | EVM 호환 실행 환경 | Avalanche VM(AVM) |
| 주로 만나는 사용자 | 스테이커·L1 운영자 | dApp 사용자·개발자 | 네이티브 자산 사용자·통합 사업자 |
| 기본 수수료 자산 | AVAX | AVAX | AVAX |
Primary Network 검증자는 P·C·X를 모두 검증합니다. 세 체인은 역할과 잔고가 구분되지만 같은 검증자 집합으로 보호됩니다. C-Chain이 P-Chain의 L2인 관계도 아닙니다. 세 체인의 역할
C-Chain은 일반 사용자가 가장 자주 접하는 체인입니다. Ethereum Virtual Machine과 Solidity 도구를 활용하며 메인넷 Chain ID는 43114입니다. 다만 Ethereum과 잔고·계약 배포·유동성을 공유하지는 않습니다. C-Chain에 ERC-20을 발행해도 가스는 AVAX로 냅니다. C-Chain과 L1 가스, Primary Network
P-Chain은 Primary Network 스테이킹과 L1 생성·검증자 등록·가중치 변경을 기록합니다. 독립 L1의 검증자 관리 계약인 ValidatorManager가 결정한 변경을 Warp 메시지로 받아 반영하는 흐름도 지원합니다. 여기서 등록은 검증자 정보를 관리하는 절차입니다. P-Chain이 각 L1의 거래를 대신 실행하거나 모든 체인 간 메시지를 중계하는 것은 아닙니다. ACP-77
X-Chain은 AVM 규칙에 따라 네이티브 자산을 발행하고 옮깁니다. 이 자산 규격은 C-Chain의 ERC-20과 다릅니다. 초기 X-Chain은 DAG(방향성 비순환 그래프) 구조였지만 Cortina 업그레이드에서 거래 순서가 정해지는 선형 체인으로 바뀌었습니다. 현재 X-Chain을 DAG로 그린 구조도는 낡은 설명입니다. Cortina의 X-Chain 선형화
Subnet에서 독립 L1으로 바뀐 비용과 권한
과거 Subnet 검증자는 Primary Network도 함께 검증해야 했습니다. Etna에서 활성화된 ACP-77은 이 의무를 분리했습니다. 새 L1 검증자는 Primary Network 전체를 검증하는 대신 P-Chain을 동기화해 검증자 정보를 추적합니다. L1은 자체 검증자 구성, 가스 토큰, 수수료 시장과 실행 환경을 정할 수 있습니다. 기존 Subnet이 모두 자동으로 이 방식으로 전환된 것은 아닙니다. ACP-77, L1 운영 구조
| 비용·요건 | Primary Network 검증자 | ACP-77 방식의 독립 L1 검증자 |
|---|---|---|
| Primary Network 검증 | P·C·X 모두 검증 | 의무 없음, P-Chain 동기화 |
| Primary Network 스테이크 | 최소 2,000 AVAX | L1 검증자 자격만을 위해서는 불필요 |
| L1 검증자 등록 유지 | 해당 L1 방식과 구분 | AVAX로 내는 동적 연속 수수료 |
| 추가 요건 | Primary Network 규칙 | L1 자체 스테이크·허용 기준 등 |
2,000 AVAX는 잠기는 스테이크이고 연속 수수료는 소모되는 비용입니다. 두 금액을 같은 종류의 지출로 비교하면 자본 잠금과 운영비를 혼동하게 됩니다. 연속 수수료도 고정 월정액이 아닙니다. 활성 L1 검증자 수에 따라 조정되는 프로토콜 비용이며 서버·RPC·업그레이드·검증자 인센티브는 별도로 부담합니다. ACP-77 비용 모델
합의 방식과 L1별 보안 경계
Snowman은 검증자가 작은 표본을 반복 조회해 선호하는 블록에 합의하는 프로토콜입니다. Primary Network에서는 AVAX 스테이크에 따라 표본으로 뽑히는 영향력이 달라집니다. 안전성은 매개변수와 정직한 검증자 비중에 의존하는 확률적 모델입니다. Snowman++는 그 위에 블록 제안자 선택을 더합니다. 빠른 확정을 목표로 하지만 모든 L1·부하에 적용되는 하나의 TPS나 확정 시간 보장으로 읽을 수는 없습니다. Snowman 합의, 현재 C-Chain 구조
C-Chain 앱은 Primary Network 검증자와 AVAX 스테이킹에 의존합니다. 독립 L1 앱은 해당 L1의 검증자 수와 가중치 분포, 관리자 권한, 자체 경제적 유인에 의존합니다. P-Chain에 등록해도 Primary Network 전체 검증자가 그 L1의 블록을 확인해 주지는 않습니다. Primary Network의 기본 제재는 스테이크 원금 삭감(slashing)보다 보상 미지급이며, 커스텀 L1에는 별도 규칙을 적용할 수 있습니다. L1의 자체 보안, Primary Network 검증자 유인
Ethereum 롤업과도 보안의 출발점이 다릅니다. 일반적인 롤업은 Ethereum에 데이터와 상태 검증을 연결해 보안을 얻는 구조입니다. 독립 Avalanche L1은 자체 검증과 데이터 가용성을 책임집니다. 네트워크별 부하와 수수료를 분리할 수 있는 대신 검증자와 운영 권한을 L1마다 따로 평가해야 합니다. 독립 네트워크 설계
Helicon 이후 C-Chain의 수락·실행·정산
Helicon은 공식 공지상 2026년 9월 22일 15:00 UTC에 메인넷에서 활성화됐습니다. C-Chain은 이전 Coreth 실행 엔진에서 Continuous Execution VM으로 바뀌었습니다. Helicon 공지, 실행 엔진 문서
Continuous Execution은 합의가 블록을 수락하는 단계와 거래 실행을 분리합니다. 합의가 수락한 블록은 큐에 들어가고 실행기가 처리하며, 실행 결과의 상태·영수증 root는 후속 블록에 정산됩니다. 합의와 실행이 병행되는 구조이므로 이를 EVM 거래 전체의 병렬 실행으로 이해하면 안 됩니다. 거래 수락 시 비용 지불 가능성을 확인해도 계약 호출의 성공이나 out-of-gas 방지를 보장하지 않습니다. 앱은 블록 수락과 스왑 성공을 구분해야 합니다. ACP-194
Helicon에는 스테이킹 변경도 포함됩니다. Primary Network 검증 최소 기간은 48시간이지만 위임 최소 기간은 2주입니다. 보상에 필요한 uptime 90%는 업그레이드 이후 시작한 검증 기간에 적용됩니다. 보상 곡선을 바꾸는 ACP-285는 활성화 후 90일에 걸쳐 적용되므로 2026년 11월 10일에는 전환 중입니다. Helicon, 스테이킹 상세 가이드
자산 이동과 메시지 전달의 차이
P·C·X 사이의 export/import
C-Chain의 AVAX를 P-Chain 스테이킹에 쓰려면 체인 간 export와 import를 거칩니다. 같은 지갑으로 관리해도 C 잔고와 P 잔고는 별개입니다. 이 기능은 공유 UTXO 메모리를 이용하는 Primary Network의 자산 이동 방식입니다. UTXO는 아직 소비하지 않은 거래 출력을 뜻합니다. 일반 ERC-20 transfer를 다른 체인으로 보내는 기능과는 구분해야 합니다. C-Chain의 atomic transaction 구조
L1 간 ICM과 Warp, Teleporter
ICM(Interchain Messaging)은 Avalanche 체인 사이의 메시지 통신 체계입니다. 기반인 Avalanche Warp Messaging은 원본 측 검증자의 서명을 BLS 방식으로 집계해 메시지를 인증합니다. relayer가 메시지와 서명을 목적지로 운반하고, 목적지는 P-Chain에 기록된 검증자 정보와 필요한 서명 가중치를 확인합니다. P-Chain이 메시지마다 목적지 계약을 실행하는 구조는 아닙니다. ICM 동작
이 경로의 신뢰는 원본 측 서명자의 정직성과 목적지의 검증 설정에 달려 있습니다. 전달에는 relayer의 가용성도 필요합니다. Primary Network에서 온 메시지는 설정에 따른 서명자 예외가 있어 모든 경로를 하나의 고정 정족수로 설명하기 어렵습니다. Warp 검증 규칙
EVM 앱은 ICM Contracts의 TeleporterMessenger로 전달·중복 방지·재시도·relayer 보상을 처리할 수 있습니다. 메시지가 전달돼도 목적지 계약 호출은 revert할 수 있습니다. Teleporter는 전달 완료와 실행 실패를 구분하고 실행 재시도를 지원합니다. 개발자는 메시지 인증과 목적지 앱의 성공 조건을 각각 설계해야 합니다. ICM Contracts와 실행 재시도
ICTT의 자산 담보와 발행 권한
ICTT(Interchain Token Transfer)는 ICM 위에 만든 자산 전송 애플리케이션입니다. 기본 Home/Remote 구조에서는 Home 계약에 원본 자산을 잠그고 Remote에서 표현 토큰을 발행합니다. 반환할 때는 표현 토큰을 소각하고 원본 자산을 해제합니다. ICTT 구조
서명이 유효한 메시지라는 사실만으로 담보와 토큰 발행 권한까지 안전해지지는 않습니다. 어떤 Home이 자산을 보관하고 어떤 Remote에 발행 권한을 주는지 확인해야 합니다. 외부 Ethereum 브리지나 발행사 기반 전송을 쓰면 그 경로의 별도 신뢰 모델도 추가됩니다. ICM 연결만으로 유동성이 합쳐지거나 여러 체인의 앱이 한 거래처럼 동시에 실행되는 것도 아닙니다. ICTT의 보안 고려사항
공용 DeFi와 목적별 네트워크의 활용
C-Chain에서는 대출·거래·유동 스테이킹이 연결됩니다. Aave는 대출·차입, BENQI는 대출과 sAVAX 유동 스테이킹, LFJ는 Liquidity Book 기반 거래 인프라를 제공합니다. sAVAX를 DeFi에 사용하면 스테이킹 포지션을 활용할 수 있지만 계약·청산·유동성 위험이 더해집니다. Aave 배포 주소, BENQI, LFJ
독립 L1은 앱별 가스 경제나 검증자 정책이 필요한 경우에 쓰입니다. 기관용 토큰화는 공용 체인에서도 가능하므로 유명 기업의 Avalanche 활용을 모두 독립 L1 사례로 묶으면 안 됩니다.
| 사례 | 공식 자료가 보여 주는 활용 | 해석 범위 |
|---|---|---|
| FIFA Blockchain·FIFA Collect | 2025년 5월 22일 Avalanche 기반 커스텀 L1 선정과 Collect 이전 발표 | 발표와 이전 FAQ는 최신 이전 완료·사용 규모의 증거와 구분 |
| GUNZ·Off The Grid | 게임 아이템의 소유·NFT 전환·거래를 지원하는 플랫폼 | 게임 전체 상태가 온체인이라는 뜻은 아님 |
| BlackRock BUIDL·Securitize | 2025년 3월 25일 공지에서 Avalanche를 펀드 토큰 지원 네트워크로 명시 | BlackRock이 자체 Avalanche L1을 운영한다는 증거는 아님 |
FIFA 자료에는 미래형 이전 일정이 남아 있어 현재 완료 여부를 그 문구만으로 확정하기 어렵습니다. GUNZ의 제품 안내도 모든 게임 로직의 온체인 실행을 입증하지 않습니다. BUIDL은 자격 투자자 조건과 오프체인 운용·수탁·법적 권리가 결합된 펀드입니다. 세 사례는 서로 다른 활용 방식을 보여 주며 사용자 수나 매출 비교로 확대할 근거는 아닙니다. FIFA 발표, FIFA Collect FAQ, GUNZ, Securitize의 BUIDL 공지
AVAX 비용과 생태계 성장의 연결
AVAX는 Primary Network의 가스와 스테이킹에 쓰이며 독립 L1 검증자의 연속 수수료도 AVAX로 냅니다. Primary Network 거래 수수료는 소각되지만 스테이킹 보상은 새로 발행됩니다. 소각이 있다는 사실만으로 공급이 항상 줄어든다고 결론낼 수는 없습니다. AVAX 토큰, L1 검증자 수수료
독립 L1은 자체 가스 토큰과 수수료 규칙을 선택합니다. 따라서 L1 거래 증가를 같은 양의 AVAX 가스 수요 증가로 환산할 수 없습니다. AVAX와의 연결은 Primary Network 이용, 스테이킹, L1 검증자 비용 등 경로별로 따져야 합니다. 이 경로를 구분해야 생태계 활동이 토큰에 어떤 수요를 만드는지 판단할 수 있습니다. L1의 토큰 경제
C-Chain과 자체 L1을 선택하는 기준
공용 유동성과 기존 지갑·도구가 필요한 앱은 C-Chain에서 시작하는 편이 단순합니다. 체인을 직접 운영하지 않고 스마트컨트랙트와 제품에 집중할 수 있습니다. 공식 L1 가이드도 초기 C-Chain 배포 후 제약이 생겼을 때 자체 L1을 검토하는 경로를 제안합니다. L1 선택 가이드
자체 가스 토큰, 검증자 참여 조건, 전용 처리 용량이나 업그레이드 권한이 제품의 필수 요건이면 독립 L1이 유용합니다. 그 선택에는 검증자 보안과 RPC·탐색기·키 관리·복구 운영, 체인 간 자산의 유동성 확보까지 포함됩니다. 허용 목록을 설정하는 것과 규제 준수·거래 기밀성을 확보하는 일도 별개입니다. 앱에 필요한 통제권이 이 운영 부담을 감수할 만큼 구체적인지가 선택 기준입니다. L1 구성과 운영 범위
함께 보면 좋을 자료
- Snowman Consensus: 반복 표본 투표와 안전성 모델 설명.
- ACP-77: 독립 L1의 검증자 관리·연속 수수료 설계.
- ICTT: 메시징 위에 자산 전송을 구현할 때 필요한 계약과 신뢰 조건.
참고 자료
모든 자료의 확인일은 2026년 11월 10일입니다.
- Avalanche Builder Hub: Primary Network, Avalanche L1s, AVAX Token.
- Avalanche Builder Hub: Cortina, Snowman Consensus, ACP-77.
- Avalanche Builder Hub: Helicon, C-Chain architecture, ACP-194, Staking for Professionals.
- Avalanche Builder Hub: ICM, ICM Contracts, ICTT.
- 제품 문서: Aave, BENQI, LFJ, GUNZ.
- 도입 발표: FIFA·Avalanche, FIFA Collect FAQ, Securitize·BUIDL.

