BLUEPRINT

제12장: 기술 아키텍처

12.1 아키텍처 개요

┌─────────────────────────────────────────────┐
│  애플리케이션 계층 (DApp, Fay 인터페이스,      │
│  거버넌스 UI)                                │
├─────────────────────────────────────────────┤
│  Layer 2: ZK Rollup (고빈도                  │
│  트랜잭션 처리)                               │
│  - 기여 기록, 친밀도 업데이트,                  │
│    일상 상호작용                              │
├─────────────────────────────────────────────┤
│  Layer 1: Substrate 전용 체인                 │
│  (정산 & 합의)                               │
│  - 상태 루트 앵커링, 신원 관리,                 │
│    거버넌스 투표                              │
├─────────────────────────────────────────────┤
│  신원 계층: DID + PKI + ZKP                   │
└─────────────────────────────────────────────┘

12.2 기술 선택 비교

논의 과정에서 여러 접근법이 평가되었습니다:

접근법장점단점결론
이더리움 메인넷성숙한 생태계, 높은 보안높은 가스비, 낮은 TPS (15–30)인구 규모의 고빈도 기록에 부적합
이더리움 L2수수료 절감여전히 이더리움 생태계에 제약대안
DAG (IOTA/Nano)높은 처리량, 수수료 없음약한 합의 보안보안 불충분
Substrate 커스텀 체인완전 커스터마이징 가능, 가스비 없음자체 생태계 구축 필요권장

가스비 문제

가스비는 이더리움과 같은 퍼블릭 체인에서 트랜잭션당 계산 비용입니다. 전체 인구가 매일 대량의 소규모 기여 기록을 생성하는 상황에서, 각각을 온체인에 기록하면 비용이 감당할 수 없을 정도로 높아집니다. GMC는 무료 또는 극히 저렴한 기록 방식이 필요합니다.

처리량 문제

이더리움 메인넷은 약 15–30 TPS를 처리합니다. 전 세계 수십억 사용자의 기여 기록에는 이 처리량이 턱없이 부족합니다.

12.3 Substrate 전용 체인

왜 Substrate인가

  1. 완전 커스터마이징 가능한 합의: 기여 기록에 특화된 합의 알고리즘을 설계할 수 있습니다
  2. 가스비 없음: 수수료 없는 트랜잭션으로 설계할 수 있습니다
  3. 커스터마이징 가능한 거버넌스 모듈: 커뮤니티 합의에 자연스럽게 적합합니다
  4. Polkadot 상호운용성: 릴레이 체인을 통해 다른 체인과 상호운용할 수 있습니다
  5. 모듈식: 필요에 따라 Runtime 모듈을 조합합니다

근거

GMC의 고유한 요구사항은 범용 퍼블릭 체인을 부적합하게 만듭니다:

  • 전 인구 참여 = 극도로 높은 트랜잭션 볼륨
  • 소규모 기여 기록 = 고빈도, 저가치 트랜잭션
  • 수수료를 부과할 수 없음 = 기여 기록이 재정적 부담이 되어서는 안 됩니다
  • 커스텀 감쇠 계산과 친밀도 알고리즘이 필요합니다

12.4 ZK Rollup

핵심 개념

오프체인 실행, 온체인 검증:

  • 일상 기여 기록은 L2에서 고속으로 처리되며, 수수료 없이 높은 처리량을 달성합니다
  • 배치 기록의 영지식 증명이 주기적으로 L1에 제출됩니다
  • L1은 압축된 상태 루트만 저장합니다

ZK Rollup vs. Optimistic Rollup

특성ZK RollupOptimistic Rollup
검증 방식영지식 증명 (수학적 보장)사기 증명 (이의 제기 기간)
확인 시간빠름느림 (일반적으로 7일)
보안수학적 보장정직한 검증자에 의존
계산 비용높음낮음

선택: ZK Rollup — 평판 시스템은 빠른 확인과 수학적으로 보장된 보안이 필요합니다.

책임 분담

  • L2 처리: 기여 기록 생성, 실시간 MeriToken 계산, 친밀도 업데이트
  • L1 앵커링: 상태 루트, 신원 등록/변경, 거버넌스 투표 결과, 처벌 기록

12.5 데이터 저장

온체인 (L1): 신원 레지스트리, 상태 루트, 거버넌스 기록, 처벌 기록
Rollup (L2): MeriToken 잔액 및 배치, 친밀도, 기여 기록
오프체인 (IPFS 등): 상호작용 세부 내용, 기여 증거, 대용량 파일

12.6 합의 메커니즘

  • 검증자 진입: 일정량의 MeriToken이 필요합니다 (평판 담보)
  • 검증 인센티브: 검증 작업 자체가 기여이며 Merit을 획득할 수 있습니다
  • L1 합의: GRANDPA/BABE (Substrate 기본값)
  • L2 합의: 경량 BFT

12.7 성능 추정

10억 사용자가 각각 하루 5건의 기록을 생성한다고 가정:

  • 일일 트랜잭션 볼륨: 50억 건
  • TPS 요구사항: ~58,000
  • 필요: 다수의 병렬 Rollup 인스턴스 (샤딩), 효율적인 증명 생성, 분산 L2 노드

12.8 논의 메모

기술 아키텍처의 핵심 결정:

  • 범용 퍼블릭 체인이 아닌 전용 체인: GMC의 요구사항이 너무 특수합니다
  • Optimistic이 아닌 ZK Rollup: 빠른 확인과 수학적 보장이 필요합니다
  • 계층적 저장: 보안과 확장성 사이의 균형
  • 성능이 가장 큰 과제입니다: 전 인구 참여의 규모는 전례가 없습니다

이것은 논의 초안 단계의 아키텍처 개념이며; 실제 구현은 기술 발전에 따라 조정이 필요합니다.