26-8-2 @blaze.apps 의 하드포크 24제안에 대한 질의와 답변

steem-agora (86)in AVLE 일상 • 2 days ago

@blaze.apps가 스팀 블록체인의 사이드 체인을 위한 HF 24 안을 제시했습니다.
https://steemit.com/svm-evm-on-steem/@blaze.apps/how-steem-witnesses-can-help-the-svm-dream-bridging-svm-to-steem-a-witness-based-bridge-oracle

이에 대해 Gemini에게 평가를 요구했더니 아래와 같은 답을 제시했습니다.
Gemini의 문제제기에 대한 @blaze.apps의 답도 게시합니다.
한번씩 읽어 보시기 바랍니다.

🌟 1. 총평 및 핵심 강점 (Positive Aspects)

HF24 명세서는 기존 블록체인의 고질적인 브릿지 보안 문제를 매우 명쾌하게 해결한 우수한 설계입니다.

신뢰 경계(Trust Boundary)의 최소화

중앙화된 브릿지 멀티시그(Multisig)나 별도의 연합(Federation) 위원회를 두지 않고, 이미 체인을 담보하고 있는 top 21 증인 세트(17/21 멀티시그 합의)를 그대로 재사용했습니다. 이는 브릿지 해킹의 대표 원인인 "외부 오라클/서명자 탈취" 위험을 완벽히 차단합니다.

완벽한 통화량 중립성 (1:1 Peg & Balance)

svm.bank 계정의 키를 영구 무효화(Nullify)하여 개인키에 의한 출금을 불가능하게 만들고, 온체인 로직으로만 이체가 가능하도록 고안했습니다.

Double Spend & Reorg 방지 대책 (22-Block Delay & Permanence)

합의(Block $C$) 후 즉시 지급하지 않고 22블록(~66초) 성숙 대기 시간을 거쳐 가상 연산(bridge_release_operation)으로 지급하도록 설계했습니다. 이는 체인 리오르가니제이션(Reorg) 발생 시 발생할 수 있는 이중 지급(Double Payout)을 완벽히 방지합니다.

⚠️ 2. 보완 및 개선이 필요한 항목 (Areas for Improvement)

아키텍처 자체는 훌륭하지만, 실제 메인넷 가동 시 발생할 수 있는 엣지 케이스(Edge Cases) 및 운영 편의성 측면에서 아래 항목들이 보완되어야 합니다.

🛠️ A. 기술 및 아키텍처 보완점

1. 증인 오라클의 Liveness 및 DoS 대책 (가장 중요)

문제점: 21명 중 17명의 증인이 3.5일 이내에 동일한 트랜잭션을 증명(bridge_submit)해야 출금이 승인됩니다. 만약 상위 증인 중 5명 이상이 오라클 노드를 다운시키거나 업데이트를 제때 안 할 경우, 브릿지가 완전히 먹통(Liveness Failure)이 됩니다.
보완 제안:
증인의 브릿지 참여 여부 및 응답 속도를 모니터링할 수 있는 증인 오라클 가동률(Uptime) 메트릭 API 제공.
증인이 정당한 사유 없이 지속적으로 오라클 제출을 누락할 경우 Missed Block처럼 페널티를 부여하거나 거버넌스 차원에서 시각화하는 기능 필요.

2. 가상 연산(Virtual Op) 하위 호환성 문제

문제점: 명세서에도 적혀 있듯, 가상 연산인 bridge_release_operation은 기존 레거시 condenser_api에서 누락되며 최신 account_history_api에서만 잡힙니다.
보완 제안:
기존 스팀 거래소, dApp, 블록 익스플로러, 서드파티 인프라 다수가 여전히 condenser_api 기반으로 작성되어 있어 유저들의 "입금 누락" 문의가 폭주할 수 있습니다.
익스플로러 및 dApp 개발자용 SDK/라이브러리 업데이트 가이드를 하드포크 전에 필수적으로 배포해야 합니다.

3. 트랜잭션 수수료(Gas/Steem Fee) 및 스팸(Spam) 방지

문제점: 사용자가 SVM에서 의미 없는 소액 소각을 수천 건 연속으로 실행할 경우, 21명의 증인이 매번 스팀 메인넷에 bridge_submit_operation을 쏴야 하므로 스팀 메인넷에 불필요한 트랜잭션 과부하(Spam Attack)가 발생할 수 있습니다.
보완 제안:
브릿지 최소 출금 수량 제한(e.g., 최소 10 STEEM 이상) 적용.
브릿지 출금 요청 시 일정 비율의 수수료(Bridge Fee)를 차감하여 증인 오라클 운영 비용 및 스팸 방지용으로 충당하는 메커니즘 검토.

💡 B. 운영 및 사용자 경험(UX) 개선점

1. 3.5일 만료(Expiration) 시 자금 처리 로직 명확화

명세 내용: "3.5일 동안 17/21 합의에 도달하지 못하면 만료되며 나중에 재제출(Resubmitted)할 수 있다."
보완 필요:
만료되었을 때 SVM 측에서 소각된 토큰은 어떻게 되는지(자동 환불되는지, 아니면 사용자가 직접 쿼리해서 재시도 버튼을 눌러야 하는지) UX 흐름이 명확해야 합니다.
유저 자금이 붕 뜨는 현상(Stuck)을 막기 위한 SVM 측 Auto-Refund 또는 Retry UI 필요.

2. 사용자 트래킹 전용 대시보드/조회 도구 (Bridge Explorer)

상태: 현재는 find_bridge_oracle, find_bridge_processed 등 RAW API로만 상태 추적이 가능합니다.
보완 제안: 일반 유저가 "내 출금이 지금 21명 중 몇 명의 증인 서명을 받았는지(e.g., 14/17)", "22블록 대기 중인지"를 메타마스크나 웹 UI에서 직관적인 진행률 바(Progress Bar)로 볼 수 있는 전용 브릿지 스캐너 페이지 제공이 필수적입니다.

🎯 3. 최종 결론 및 권장사항

구분	평가 결과	비고
보안성 (Security)	A+	중앙화 브릿지 위험 요소를 완전히 제거함
자산 안전성 (Supply)	A+	1:1 Peg 유지 및 22-Block Delay로 Reorg 완벽 방어
운영 가동성 (Liveness)	B+	증인 5명 이상 미응답 시 락업 위험 (오라클 모니터링 필요)
사용자 경험 (UX)	B	브릿지 진행 상태 시각화 및 레거시 API 호환 대책 필요

핵심 요약:
HF24는 스팀 생태계의 독립성과 보안을 극대화한 매우 완성도 높은 하드포크 제안입니다. 메인넷 적용 전 1) 증인 노드의 오라클 모니터링 도구 구축, 2) 소액 스팸 방지 수수료/최소 수량 설정, 3) 유저용 브릿지 진행 상황 추적 UI 개발의 3가지만 보완된다면 완벽한 신뢰 비필요 브릿지가 될 것입니다.

리뷰에 대한 상세한 피드백 감사드립니다. 매우 명쾌한 설명입니다. 보내주신 답변 내용의 한글 번역입니다.

@blaze.apps의 답변

상세한 리뷰에 진심으로 감사드립니다. 아주 훌륭한 분석이었습니다. 지적해주신 부분들에 대한 명확한 답변을 드립니다:

가동성(Liveness, 5명 이상 오프라인 시 우려 건)에 관하여:
생각하시는 것보다 훨씬 덜 취약합니다. 증인들이 동일한 순간에 동시에 증명할 필요는 없습니다. 대기 중인 각 출금 요청은 약 3.5일 동안 열려 있으며, 증인이 제출하는 시점마다 확인 건수로 집계됩니다. 즉, 17명이 동시에 온라인 상태일 필요 없이 해당 시간(3.5일) 내에 21명 중 17명이 각자 한 번씩만 증명하면 됩니다. 특정 라운드를 놓친 증인은 다음 라운드에서 따라잡으면 됩니다.
또한 여기에 슬래싱(Slashing)을 추가할 수는 없습니다. 스팀 DPoS는 슬래싱 제도가 없으며, 증인들은 투표수와 블록 누락(Missed-block) 통계를 통해 책임을 집니다. 따라서 오라클 상태 대시보드(증인별 최근 증명 블록 표시)가 가장 적절한 도구이며, 충분히 구축할 가치가 있다는 점에 동의합니다.
condenser_api / 가상 연산(Virtual Op) 공백에 관하여:
지적해주신 부분 중 가장 중요한 포인트이며, 아주 잘 짚어주셨습니다. 출금 해제는 단순 이체(Transfer)가 아닌 가상 연산이므로, 이체 내역을 감시하거나 레거시 API를 사용하는 거래소/dApp은 브릿지-인(Bridge-in)을 자동으로 감지하지 못합니다.
이에 대한 해결책으로 하드포크 이전에 통합 안내서(account_history_api를 통해 bridge_release_operation 읽기)를 배포할 예정이며, 레거시 API에서도 브릿지 연산이 표시될 수 있도록 레거시 API 쪽에 브릿지 연산을 추가하는 방안도 검토 중입니다.
스팸 및 수수료(Spam/Fees)에 관하여:
이미 여러 장치가 스팸을 방어하고 있습니다. 공격자는 SVM 측에서 소각할 때마다 가스비를 지불해야 하고, 증인은 증명 제출 시 리소스 크레딧(RC)을 소모하며, 대기 기록은 트랜잭션당 제한되어 있고 해제 시 자동 삭제됩니다. 영구적으로 남는 데이터는 성공한 브릿지 건당 저장되는 아주 작은 재시도 방지(Replay-guard) 기록뿐입니다.
최소 출금 수량 제한은 SVM 측에서 강제하는 것이 가장 좋으며, 소액의 브릿지 수수료 도입도 합리적인 추가안입니다. 두 방안 모두 고려 대상에 올려두었습니다.
만료 및 환불(Expiry/Refunds)에 관하여:
스팀 측에서는 이미 안전하게 처리되어 있습니다. 만료된 출금 요청은 자금을 이동시키지 않고 나중에 재제출할 수 있으므로, 자금이 묶이는 일은 없습니다. 증인들이 뒤늦게 참여하더라도 나중에 정상 완료됩니다. 환불 및 재시도 UX는 SVM dApp 단에서 처리될 것이며, 클릭 한 번으로 가능하게 구현할 예정입니다.
브릿지 추적 UI(Bridge Tracker UI)에 관하여:
동의합니다. 다행히 관련 데이터는 이미 노출되어 있습니다. find_bridge_oracle API가 확인 건수와 성숙 블록 정보를 반환하므로, "14/17 확인됨, N개 블록 후 해제"와 같은 추적기 화면은 기존 API 위에 프론트엔드만 입히면 됩니다. 작업 목록에 올려두었습니다.