M1 백서
M1 백서 (한국어)
이 문서는 M1 백서(영문)의 한국어 번역본입니다. 원문 제목: M1 Whitepaper · 번역일: 2026-06-11
초록
M1(Movement L1)은 Move 프로그래밍 언어의 잠재력을 온전히 실현하기 위해 구축된 블록체인 인프라입니다. M1은 탈중앙화 애플리케이션, 온체인 금융, 디지털 네이티브 조직을 위한 안전하고 리소스 지향적인 기반을 제공합니다.
성능과 안전성을 넘어, M1은 단순한 전제 위에 설계되었습니다. 기술은 사용자의 역량을 확장해야 합니다. M1은 글로벌 모바일 우선 경제에 열린 참여, 공동 소유권, 검증 가능한 신뢰라는 가치를 회복하기 위해 존재합니다.
이 문서는 Move의 효율성과 접근성 및 커뮤니티 소유권에 기반한 설계 철학을 결합한 사람 중심의 레이어 1 네트워크인 M1의 동기, 원칙, 상위 수준 아키텍처를 설명합니다.
1. 소개
1.1 배경
블록체인 생태계는 확장성, 보안, 탈중앙화 사이의 긴장을 해결하려는 반복적인 시도를 거치며 발전해 왔습니다. 각 세대의 네트워크는 진전을 이루었지만, 성능과 개방성 사이의 트레이드오프는 계속 남아 있었습니다. 그 결과 오늘날의 환경은 혁신만큼이나 분절성으로 정의됩니다. 이는 종종 사용자가 아니라 자본에 최적화된 특화 시스템들의 집합입니다.
Diem 프로젝트를 위해 처음 개발된 Move 프로그래밍 언어는 이러한 흐름에서 분명한 전환점을 제시합니다. 리소스 지향 설계, 타입 안전성, 형식 검증은 Move를 검증 가능한 금융 시스템 구축에 특히 적합하게 만듭니다. M1은 이 비전을 프로토콜 계층 자체로 확장하여, 기술적으로 견고하면서도 그 네트워크에 의존하는 커뮤니티와 사회적으로 정렬된 네트워크를 만듭니다.
1.2 비전과 동기
Movement는 접근성, 커뮤니티 참여, 지속 가능한 온체인 경제에 새롭게 초점을 맞추며 Move 기반 블록체인 인프라의 진화를 이어갑니다. 목표는 기존 기반을 더 포용적이고 목적 지향적인 네트워크로 정교하게 발전시키는 것입니다.
현대 블록체인은 성공을 TVL이나 수수료 같은 시장 지표로 주로 측정하는 경우가 많습니다. Movement는 그 초점을 사용자 영향으로 되돌립니다. 즉, 네트워크가 사람들이 만들고, 벌고, 조율하도록 얼마나 효과적으로 힘을 부여하는지에 집중합니다. Movement는 성숙한 기술을 실제 커뮤니티를 위한 열린 인프라로 전환합니다.
주권적 레이어 1은 이러한 방향을 가능하게 합니다. Movement는 자체 L1을 운영함으로써 경제 모델, 거버넌스, 조율 메커니즘을 포용성과 회복탄력성에 맞춰 설계할 수 있습니다. 예를 들어 검증자를 통해 지역 허브로 가치를 흘러가게 할 수 있습니다. 그 결과 커뮤니티 규모의 애플리케이션, 의미 있는 커뮤니티 참여, 실물자산, 모바일 네이티브 금융에 최적화된 네트워크가 됩니다. 이는 투기보다 사용성과 공동의 이익을 우선하는 시스템입니다.
1.3 지침 원칙
Movement의 개발은 시스템의 모든 계층에 영향을 주는 몇 가지 타협 불가능한 원칙에 의해 추진됩니다.
- 사람 우선: 기술은 사용자의 능력을 확장해야 하며, 가두어서는 안 됩니다.
- 인프라로서의 커뮤니티: 탈중앙화는 기술적일 뿐 아니라 사회적입니다.
- 엣지에서의 접근성: 다음 10억 명의 사용자는 모바일, 개발도상 환경, 제한된 대역폭 환경에서 올 것입니다.
- 목적 있는 조합성: 프로토콜과 애플리케이션은 고립된 사일로가 아니라 일관된 경제적 메시로 상호 연결되어야 합니다.
- 투기보다 지속 가능성: 가치는 빌더, 검증자, 커뮤니티 사이를 순환하며 장기 성장을 위한 안정적 기반을 형성해야 합니다.
1.4 애플리케이션과 생태계
M1은 온체인 금융부터 디지털 신원 및 조율 시스템까지 폭넓은 탈중앙화 애플리케이션을 지원하는 범용 레이어 1로 설계되었습니다. M1의 아키텍처는 조합성, 검증 가능성, 예측 가능한 성능을 강조하여 개발자가 안전성이나 접근성을 희생하지 않고 구축할 수 있게 합니다.
네트워크의 초점은 투기적 활동이 아니라 실제 효용에 있습니다. Movement의 설계에서 가장 큰 이점을 얻는 애플리케이션은 다음과 같습니다.
- 탈중앙화 금융 및 자산 발행: 투명성과 검증 가능한 실행이 필수적인 시장, 결제 레일, 신용 시스템.
- 실물자산 통합: Movement 네트워크에서 운영되는 인가 금융기관은 유형 자산의 표현을 토큰화하여, 소유권과 수익을 수탁 기관에 집중시키는 대신 규정을 준수하고 투명한 방식으로 커뮤니티에 분배할 수 있습니다.
- 모바일 네이티브 경험: 사용자가 어떤 기기에서든 직접 거래하고 상호작용할 수 있게 하는 경량 클라이언트와 지갑.
- 신원 및 평판 프레임워크: 신뢰, 기여 이력, 거버넌스 참여를 온체인에서 확립하기 위한 시스템.
- 커뮤니티 주도 거버넌스와 조율: 이해관계자가 제안하고, 투표하고, 집단적 결정을 안전하게 실행할 수 있게 하는 메커니즘.
이러한 범주는 Movement 생태계가 지향하는 형태를 정의합니다. 즉, 애플리케이션이 경제적 가치를 인간의 기여와 정렬시키는 실용적이고 검증 가능한 네트워크입니다.
1.5 M1 설계 철학
M1은 사회-기술 시스템입니다. M1의 목적은 또 하나의 토큰 시장을 만드는 것이 아니라, 조율과 소유권을 위한 지속 가능한 프레임워크를 구축하는 것입니다. 네트워크는 검증, 거버넌스, 개발, 교육에 이르는 모든 기여를 가치의 구성 요소로 봅니다.
이런 의미에서 Movement는 제품이라기보다 공공 유틸리티에 가깝습니다. 노력은 가치로, 기여는 소유권으로, 참여는 집단적 힘으로 전환되는 시스템입니다.
1.6 M1 핵심 기능
M1은 다음 핵심 기능을 구현합니다.
- Move 런타임: 블록체인 실행을 위한 MoveVM 구현.
- 고처리량 합의: 부하 상황에서 확장하기 위한 Jolteon 계열 및 Quorum Store와 유사한 전파 계층.
- 병렬 실행: 처리량 증가를 위한 트랜잭션 병렬화.
- 상태 관리: 상태 저장 및 관리 솔루션.
- 개발자 도구: 개발 환경 및 디버깅 도구.
2. 기술 아키텍처
2.1 시스템 개요
M1은 블록체인 운영의 여러 측면을 처리하는 별도 계층을 가진 모듈형 아키텍처를 사용합니다.
애플리케이션 계층 │ DApps, DeFi, NFTs, 엔터프라이즈 애플리케이션
API 계층 │ REST, WebSocket, Indexer GraphQL 인터페이스
실행 계층 │ MoveVM 런타임, 트랜잭션 처리
스토리지 계층 │ 상태 저장소, 트랜잭션 이력, 이벤트
합의 계층 │ BFT 합의, 검증자 네트워크
네트워크 계층 │ P2P 통신, 멤풀 관리, 메시지 라우팅2.2 합의 프로토콜
2.2.1 Jolteon
M1은 Jolteon 스타일의 BFT 프로토콜을 채택합니다. Jolteon은 지연 시간을 줄이고 빠른 복구를 보장하기 위해 2-chain 커밋 규칙과 이차적 뷰 변경(pacemaker)을 도입합니다. 정상 경로에서는 한 라운드 확인으로 선형 메시지 복잡도를 달성하며, 스트레스 상황에서도 견고성을 유지합니다.
프로토콜은 최대 1/3의 비잔틴 검증자까지 일관성을 통해 _안전성_을 보장하고, 네트워크 비동기성 하에서도 진행을 통해 _활성성_을 보장하며, 빠른 확인을 위한 2-chain 커밋으로 _최종성_을 제공하고, 최적화된 메시지 복잡도와 라운드 지속 시간으로 _효율성_을 유지합니다.
2.2.2 검증자 선택
네트워크는 지분에 비례하여 검증자 선택 확률이 결정되는 가중 선택 방식의 Proof-of-Stake(PoS)를 사용합니다. 검증자는 지분과 성과에 따라 참여하거나 이탈할 수 있는 _동적 집합_을 구성하며, 정직한 검증과 블록 생산에 대해 스테이킹 _보상_을 받습니다. (참고: 슬래싱은 프로토콜에 정의되어 있으나 현재 활성화되어 있지 않습니다.)
2.2.3 블록 생산
블록 생산은 결정론적 리더 선택 알고리즘을 따릅니다.
// Note: This is a simplified pseudocode representation.
// Deterministic, stake/reputation-weighted round-robin (illustrative)
fn select_leader(set: &ValidatorSet, round: u64) -> ValidatorId {
let order = set.weighted_order_by_stake_and_rep(); // fixed per epoch
order[(round as usize) % order.len()]
}2.2.4 데이터 전파
Quorum Store 스타일의 전파를 사용합니다. 이는 트랜잭션 전파와 순서 지정을 분리하여 버스트성 부하에서 처리량을 안정화합니다. 낮은 부하에서는 최소 지연 시간을 위해 우회할 수 있습니다.
2.3 Move 가상 머신
2.3.1 런타임 최적화
M1의 MoveVM 구현에는 검증된 바이트코드를 사용하는 최적화된 인터프리터, 반복 실행을 위해 컴파일된 바이트코드를 캐싱하는 명령 캐싱, 정밀한 가스 계량과 최소 오버헤드를 갖춘 가스 최적화, 효율적인 메모리 할당과 가비지 컬렉션을 갖춘 _메모리 관리_가 포함됩니다.
2.3.2 보안 기능
MoveVM은 이중 지출과 리소스 누수를 방지하는 리소스 안전성, 컴파일 시점 및 런타임 타입 검사를 통한 타입 안전성, 세밀한 권한 관리를 통한 접근 제어, 컨트랙트 정확성의 수학적 증명을 위한 형식 검증 지원 등 내장 보안 보장을 제공합니다.
2.3.3 병렬 실행
의존성이 허용하는 경우 트랜잭션 실행은 병렬화될 수 있습니다(Block-STM 접근 방식).
// Note: This is a simplified pseudocode representation.
struct ParallelExecutor {
worker_pool: ThreadPool,
dependency_graph: DependencyAnalyzer,
conflict_detector: ConflictDetector,
}
impl ParallelExecutor {
fn execute_batch(&self, transactions: Vec<Transaction>) -> Vec<ExecutionResult> {
let dependency_groups = self.dependency_graph.analyze(&transactions);
let results = dependency_groups.par_iter()
.map(|group| self.execute_group(group))
.collect();
self.resolve_conflicts(results)
}
}2.4 상태 관리
2.4.1 글로벌 상태 모델
M1은 계정 주소별로 구성된 글로벌 상태를 유지합니다. 각 주소가 여러 리소스와 모듈을 보유할 수 있는 계정 모델, Move 리소스 및 타입 정보의 네이티브 저장을 위한 리소스 스토리지, 메타데이터가 포함된 컴파일된 Move 모듈을 위한 모듈 스토리지, 원장 버전별로 인덱싱되는 _버전 관리 상태_를 사용하며, Jellyfish Merkle Tree를 통해 인증된 증명을 제공합니다.
2.4.2 Jellyfish Merkle Tree(JMT)
M1은 상태 커밋을 위해 Jellyfish Merkle Tree를 사용합니다. 이 구조는 효율적인 상태 증명을 가능하게 하고, 라이트 클라이언트와 풀 노드를 위한 확장 가능한 검증을 지원합니다.
State Root (Jellyfish Merkle Tree)
├── Account Subtree
│ ├── Address_1 → {Resources, Modules}
│ ├── Address_2 → {Resources, Modules}
│ └── ...
├── Events Subtree
│ ├── Event_Stream_1 → [Event_1, Event_2, ...]
│ └── ...
└── Metadata Subtree
├── Validator Set
├── Network Configuration
└── ...2.4.3 스토리지 최적화
여러 최적화가 스토리지 효율성을 개선합니다. 여기에는 오래된 상태 버전 제거를 위한 상태 프루닝(설정 가능), 데이터 저장 및 전송을 위한 RocksDB 수준 압축, 일반적인 쿼리 패턴을 위한 효율적 인덱싱, 자주 접근되는 데이터를 위한 다단계 _캐싱_이 포함됩니다.
2.5 네트워크 프로토콜
2.5.1 P2P 통신
네트워크 통신은 가십 기반 프로토콜을 사용합니다. 여기에는 네트워크 피어의 자동 발견 및 연결을 위한 피어 디스커버리, 메시지 유형과 우선순위에 따른 효율적 라우팅을 위한 메시지 라우팅, 네트워크 메시지의 압축 및 배칭을 통한 대역폭 최적화, 암호학적 인증과 메시지 무결성을 통한 _보안_이 포함됩니다.
2.5.2 트랜잭션 전파
트랜잭션 전파는 낮은 지연 시간에 맞춰 최적화됩니다.
- 클라이언트 제출: 트랜잭션이 네트워크의 어느 노드로든 제출됩니다.
- 초기 검증: 기본 검증이 수행됩니다(서명, 형식, 잔액).
- 멤풀 삽입: 유효한 경우 로컬 멤풀에 추가됩니다.
- 가십 프로토콜: 연결된 피어로 전파됩니다.
- 합의 포함: 다음 블록에 포함되도록 선택됩니다.
3. 경제 모델
3.1 토크노믹스
3.1.1 MOVE 토큰
네이티브 MOVE 토큰은 여러 목적을 수행합니다. 여기에는 트랜잭션 실행 및 저장소 비용 지불을 위한 트랜잭션 수수료, 검증자 스테이킹과 네트워크 보안을 위한 스테이킹, 프로토콜 업그레이드와 매개변수에 대한 투표를 위한 거버넌스, 검증자와 네트워크 참여자에게 지급되는 _보상 인센티브_가 포함됩니다.
3.1.2 토큰 분배
시간에 따른 누적 유통 공급량: TGE(2024년 11월)부터 전체 베스팅(2029년 11월)까지 카테고리별 누적 유통 공급량을 보여주는 누적 보기입니다. 실제 언락 일정은 표시된 예측과 다를 수 있습니다.
3.1.3 수수료 구조
트랜잭션 수수료는 리소스 소비를 기준으로 계산됩니다.
// Note: This is a simplified pseudocode representation.
// Fee model: gas unit price × gas used, minus storage refund
struct GasSchedule {
instruction_costs: HashMap<Opcode, Gas>,
storage_costs: StorageGasSchedule,
}
fn calculate_fee(gas_used: Gas, gas_unit_price: Octa, storage_refund: Octa) -> Fee {
gas_used * gas_unit_price - storage_refund
}3.1.4 스테이킹 메커니즘
검증자 스테이킹은 다음 원칙을 따릅니다. 검증자 참여를 위한 최소 지분 요건, 토큰 보유자가 검증자에게 지분을 위임할 수 있는 위임, 지분과 성과에 비례한 보상, 그리고 프로토콜에는 정의되어 있으나 2025년 기준 메인넷에서는 활성화되지 않은 _슬래싱_이 포함됩니다.
3.1.5 수수료 및 스테이킹 보상 흐름
스테이커와 위임 스테이커는 Reward-and-Gas-Pool에서 보상을 받습니다.
이 풀에는 두 가지 유입 흐름이 있습니다. 첫째, 수수료가 직접 풀로 수집되어 지속 가능한 보상 모델을 위한 자연스러운 경로를 만듭니다. 둘째, 풀은 정기적으로 보충되는 스테이킹 보상 트레저리로부터 자금을 공급받습니다.
네트워크 보안을 강화하기 위해 스테이킹 보상 트레저리는 지분을 위임합니다. 보상은 트레저리로 반환되기 때문에 유통 공급량에 기여하지 않으며, 런웨이를 줄이지도 않습니다. 트레저리로 반환된 보상은 풀의 수명도 늘려 장기적으로 더 지속 가능한 모델을 추진합니다. 스테이킹 보상 트레저리가 Reward-and-Gas-Pool로의 지급을 통해 시간이 지나며 감소하기 때문에, 거버넌스와 운영에 대한 트레저리의 영향력도 시간이 지나며 감소합니다.
이 설계에는 두 가지 장점이 있습니다. 첫째, 부트스트래핑 기간 동안 트레저리는 네트워크에 중요한 보안을 제공합니다. 둘째, 네트워크와 토큰 분배가 성숙해짐에 따라 이러한 부트스트래핑 풀의 필요성은 낮아지고, 지속적인 감소는 커뮤니티의 완전한 소유권으로 가는 길을 점진적으로 엽니다.
3.2 거버넌스 모델
3.2.1 온체인 거버넌스
거버넌스 결정은 온체인 투표를 통해 이루어집니다. 여기에는 이해관계자가 거버넌스 제안을 제출할 수 있는 제안 제출, 활성 제안에 대한 시간 제한 투표를 위한 투표 기간, 승인된 제안의 자동 _실행_이 포함됩니다.
3.2.2 매개변수 관리
핵심 네트워크 매개변수는 거버넌스를 통해 조정될 수 있습니다. 여기에는 기본 가스 가격과 수수료 구조를 위한 가스 가격, 블록 크기와 시간 및 트랜잭션 한도를 위한 블록 매개변수, 최소 지분과 보상률 및 슬래싱 조건을 위한 스테이킹 매개변수, 검증자 집합 크기와 합의 타임아웃을 위한 _네트워크 구성_이 포함됩니다.
4. 보안 분석
4.1 위협 모델
4.1.1 네트워크 공격
다양한 네트워크 수준 공격에 대한 보호가 포함됩니다. 여기에는 속도 제한과 트래픽 분석을 통한 DDoS 공격 대응, 피어 다양성과 연결 관리를 통한 이클립스 공격 대응, Proof-of-Stake와 신원 검증을 통한 시빌 공격 대응, 체크포인팅과 약한 주관성을 이용한 장거리 공격 대응이 포함됩니다.
4.1.2 합의 공격
합의 수준 공격에 대한 보호 장치에는 이중 투표에 대한 경제적 페널티를 통한 nothing-at-stake 방지, 높은 경제적 비용과 증명 가능한 악의적 행위 페널티를 통한 슈퍼메이저리티(투표권 2/3 이상 장악) 억제, 결정론적 지분 가중 리더 스케줄을 통한 그라인딩 및 리더 조작 감소, 투표 책임성과 악의적 행위 증명을 통한 뇌물 공격 방지가 포함됩니다.
4.1.3 스마트 컨트랙트 보안
Move 언어 기능은 스마트 컨트랙트 보안을 강화합니다. 여기에는 이중 지출과 자산 복제를 방지하는 리소스 모델, 일반적인 취약점을 컴파일 시점에 방지하는 타입 안전성, 세밀한 권한 및 capability 시스템을 통한 접근 제어, 컨트랙트 정확성의 수학적 증명을 위한 형식 검증 지원이 포함됩니다.
4.2 암호학적 프리미티브
4.2.1 디지털 서명
M1은 트랜잭션 인증을 위해 Ed25519 서명을 사용합니다. 이는 트랜잭션 승인 증명을 위한 트랜잭션 인증, 합의 투표 인증을 위한 검증자 서명, P2P 메시지 인증을 위한 메시지 무결성, Multi-Ed25519 임계값 방식을 통한 _다중 서명_을 제공합니다.
4.2.2 해시 함수
SHA-3(Keccak)는 시스템 전반에서 사용됩니다. _블록 해싱_에서는 고유한 블록 식별을 위해 사용되고, _Jellyfish Merkle Tree_에서는 인증된 상태 및 트랜잭션 커밋을 위해 사용됩니다. 합의는 결정론적 리더 선택을 사용하며, 작업증명이나 랜덤 비콘은 없습니다.
4.3 감사 및 검증
4.3.1 코드 감사
정기적인 독립 보안 감사는 시스템 무결성을 보장합니다. 감사 범위에는 합의 및 네트워킹 컴포넌트를 포함한 핵심 프로토콜, 가상 머신 및 실행 엔진을 위한 MoveVM 구현, 모든 암호학 구현을 위한 암호학 라이브러리, 시스템 컨트랙트와 모듈을 포함한 _스마트 컨트랙트_가 포함됩니다.
4.3.2 형식 검증
중요 컴포넌트의 수학적 검증에는 기반 Jolteon 프로토콜의 일관성에 대한 형식 증명을 통한 합의 안전성, Move Prover를 통한 언어 안전 속성의 자동 검증을 포함한 _Move 의미론_이 포함됩니다. 인센티브 경제와 거버넌스 기반 업그레이드는 동일한 수준의 형식 증명 대상이 아닙니다.
5. 개발 생태계
5.1 개발자 도구
5.1.1 Movement CLI
종합적인 명령줄 인터페이스입니다.
# Note: This is a simplified pseudocode representation.
# Create new Move project
movement init my-project
# Compile Move modules
movement build
# Deploy to testnet
movement deploy --network testnet
# Run local testnet
movement node run-local
# Interact with deployed contracts
movement call --function transfer --args 0x123 1005.1.2 IDE 통합
널리 쓰이는 개발 환경을 지원합니다.
- VS Code 확장: 구문 강조, 디버깅, IntelliSense.
- IntelliJ 플러그인: 고급 기능을 포함한 완전한 IDE 지원.
- Language Server: 편집기 통합을 위한 Language Server Protocol.
- Web IDE: 브라우저 기반 개발 환경.
5.1.3 테스트 프레임워크
종합적인 테스트 인프라입니다.
// Note: This is a simplified pseudocode representation.
#[test]
public fun test_transfer() {
let sender = @0x1;
let receiver = @0x2;
let amount = 100;
// Setup test environment
let state = create_test_state();
// Execute transfer
let result = transfer(sender, receiver, amount);
// Verify results
assert!(result.success, 1);
assert!(balance_of(receiver) == amount, 2);
}이 프로토콜 명세는 살아 있는 문서이며, M1이 계속 발전하고 성숙함에 따라 업데이트될 예정입니다.