블록체인의 향후 보안이슈와 대응

1. 블록체인의 양자 컴퓨팅 대비

참고 논문: 

Towards Post-Quantum Blockchain: A Review on Blockchain Cryptography Resistant to Quantum Computing Attacks

(1) 핵심 요약 

양자 알고리즘(Shor, Grover)이 오늘날 블록체인 암호의 근간(공개키·해시)에 구조적 위협을 주므로, 포스트-양자(PQ) 암호 전환 전략이 필수다.

(2) 양자 컴퓨팅의 위협적인 알고리즘 

• Shor는 RSA/ECDSA 같은 공개키 체계를 다항시간에 붕괴시킬 수 있다.
• Grover는 해시 보안강도를 제곱근 수준으로 깎아내린다(예: 256비트 해시는 128비트 안전도).
• 블록체인 주소·서명·블록 링크 모두가 보안적으로 취약해 질 수 있다. 

(3) 해결 방법

 

• 격자 기반 : 빠르고 범용적이다.
• 해시 기반 : 아주 튼튼하지만 서명 크기 크다.
• 코드 기반 : KEM에 강함(복호화 빠름), 공개키 매우 큼
• 단점: 키/서명 크기 커짐, 검증 속도↓, 수수료↑ 이되어 체인 성능 저하 되거나 UX적으로 불편해질수 있다.

 

(4) 실제 적용

• 위험 표면 파악: 체인/지갑/스마트컨트랙트에서 공개키·해시 의존 경로 인벤토리 작성.
• 하이브리드 서명으로 PoC 하기 : 메시지/트랜잭션에 서명 2개를 붙여 보안성을 더 강화 한다.
• 벤치마크로 체감 영향 보기 : 서명/키가 커지거나, 검증이 느려지면 수수료(가스), 속도(TPS) 등이 어떻게 변화 하는지 테스트 해봐야 합니다.
• 표준 따라가기 : 분기마다 1번(3개월에 1번) 체크하여, 호환성과 보안성을 강화 해야 합니다.

---

2. Zero-Knowledge Proof(ZKP)와 프라이버시 보호

참고 논문:  A Survey on the Applications of Zero-Knowledge Proofs

(1) 핵심 요약

• ZKP는 “증명은 하지만, 내용은 숨기는” 기술로서 프라이버시·확장성·상호운용성을 동시에 노리는 웹3 핵심 인프라가 되었다.
• ZK-Rollup은 대규모 연산을 L2로 넘기고 L1은 짧은 증명만 검증해 처리량↑, 수수료↓ 효과를 제공한다. 이로써 프라이버시뿐 아니라 확장성까지 해결 축이 됐다.

(2) 주요 내용

• ZK-Rollup 핵심: L2에서 계산·증명 생성 → L1은 검증만 수행. 이더리움의 상태변경 검증 비용을 크게 줄인다.

1. L2(롤업)에서 거래들을 한꺼번에 계산하고,
2. 그 계산이 맞다는 **짧은 증명(ZK-proof)**만 L1(이더리움 본체)에 올려요.
3. L1은 “증명만” 확인하므로 검증 비용이 크게 줄고 처리량이 올라갑니다.

• STARK vs SNARK 

 

1. SNARK: 증명이 아주 짧고 검증이 빠름 → 수수료/검증비용에 유리. 다만 신뢰 설정 이슈를 고려해야 함.
2. STARK: 신뢰 설정이 필요 없고 일반적으로 양자에도 강한 성향. 다만 증명 크기/검증이 무거워질 수 있음. StarkNet이 채택, 전용 언어 Cairo로 회로화.

 

• 저장·상호운용:
  • Storage Proofs/Herodotus로 과거 온체인 데이터를 ZK로 안전 검증.
  • Filecoin은 대규모 저장 증명을 192바이트 수준으로 압축해 검증비용을 대폭 절감.
  • zkBridge/Telepathy: 체인 간 헤더·최종성 증명을 ZK로 전달해 신뢰 최소화 브리지를 구현.
• 응용 스펙트럼:
  • 트랜잭션 프라이버시(Tornado Cash류 믹싱), 익명 신원·투표(Semaphore), 프라이빗 컨트랙트(Hawk), Mina zkApps 등으로 확장 할수 있습니다.

(3) 실무 적용

• (1) 문제 정의: 프라이버시(누구의 어떤 데이터?) vs 확장성(TPS/가스) 우선순위 결정.
• (2) 증명 체계 선택: 신뢰설정/양자내성/증명·검증 시간/프루버 비용을 표로 비교(SNARK↔STARK).
• (3) 개발 스택 선택: Circom/gnark/Noir/Cairo 등 DSL·라이브러리를 PoC로 테스트.
• (4) 규제 고려: 믹서류는 제재 리스크 존재 → 기업용 프라이버시는 허가형 접근·감사용 백도어 논의 필요.

(4) 한계

• 프루버 비용과 지연, 회로 설계 난이도, 개발자 도구 성숙도, 프라이버시와 규제의 긴장이 상존.

---

3. MEV와 거래 순서 조작 문제

참고 논문: Maximal extractable value: Current understanding, categorization, and open research questions

(1) 핵심 요약

MEV는 블록 제안/정렬 권한을 이용해 사용자 비용을 착취하는 모든 가치 추출 행위를 포괄하는 개념으로, 기술·시장설계·규제 이슈가 얽힌 난제다. 

(2) 대표 악용 패턴

• 프런트러닝: 사용자가 100 토큰 매수(슬리피지 허용 1%) 전송 → 봇이 먼저 같은 방향으로 소량 매수 → 가격 살짝 ↑ → 사용자는 더 비싸게 체결.
• 샌드위치: 앞에서 사고, 뒤에서 파는 두 거래로 사용자를 가격 사이에 끼움 → 사용자는 불리한 가격으로 체결, 봇은 차익.
• 백러닝/차익거래: 큰 스왑 뒤 가격이 흔들리면 즉시 반대 체결로 차익 회수.
• 청산 MEV: 담보대출 포지션이 청산가 도달 시, 먼저 청산을 실행해 수수료/보너스 선점.

(3) 해결이 어려운 이유

• 정량 정의 난감: “얼마가 MEV였나?”를 공통 공식으로 재기 어려움.
• 법·시장 영향: 전통금융의 불공정거래와 닮았지만, 온체인에선 정의/책임 주체가 복잡.
• 크로스도메인: L1↔L2↔다른 체인/오프체인까지 연쇄 효과.
• 순서 복잡도 N!: 거래 100개면 가능한 순서가 100!… 전수 탐색은 사실상 불가 → 측정·검증이 본질적으로 어려움.

(4) 실무 적용 

A. 사용자/트레이더/지갑 관점 

• 슬리피지(허용 가격 변동폭) 좁히기: 샌드위치 피해 감소.
• 비공개 제출/MEV 보호 라우팅 지원 RPC·라우터 쓰기(공개 메모풀 노출 최소화).
• 대량 주문 쪼개기·시간 분산(TWAP): 한 번에 큰 흔들림 방지.
• 고정가(리밋) 위주 사용: 시장가보다 MEV 표적이 되기 어려움.

B. 프로토콜/앱 팀 관점

• 순서 의존성 줄이기: 빈번한 가격 민감 연산은 배치 경매나 시간 동시 결제 고려.
• 온체인 검증 로직 단순화: “순서만 바뀌면 이익” 구조를 줄이는 방향(예: LVR 완화 AMM 설계, 오라클 업데이트 타이밍 개선).
• 비공개 제출 옵션 제공: 사용자에게 “공개/비공개 경로” 선택권.

C. 인프라/검증자·빌더 관점

• PBS 채택: 제안자와 빌더 역할 분리로 권한 집중 완화.
• 투명성 지표: 포함/제외 정책, 릴레이 사용 현황 공개.
• 경매/릴레이 선택: “수익 최대”만이 아니라 검열·공정성 기준 포함한 정책 수립.

(4) 한계

• 수학적·실무적 공통 지표 부재로 계량이 어렵고, 완화책은 인센티브 재배치로 부작용을 낳을 수 있음(탈중앙성·검열 저항성 저하 등).