최근 STEEM이 SVM 브릿지를 위해 HF를 준비하는 것 같다. AI작성
[AI로 작성된 포스팅으로 의미 전달이 완벽하지는 않으나 한번쯤 참고할만한 내용입니다.]
최근 blaze.apps가 STEEM 블록체인과 SVM 사이의 브릿지를 구현하기 위한 하드포크 제안을 공개했습니다.
제안의 핵심은 STEEM의 상위 21개 증인 가운데 17개 증인의 확인을 통해 SVM에서 STEEM 메인체인으로의 출금을 승인하는 증인 기반 브릿지를 만드는 것입니다.
기존의 외부 멀티시그 브릿지나 별도의 연합 운영 주체를 두는 대신, 현재 STEEM 블록체인의 합의를 담당하는 증인 구조를 브릿지 오라클로 활용하겠다는 것입니다.
기술적인 구조만 보면 17/21 증인 합의, 출금 성숙 대기 시간, 재전송 방지, 무효화된 브릿지 계정 키 등 여러 보안장치가 포함되어 있습니다.
그러나 저는 현재 논의가 가장 중요한 문제를 놓치고 있다고 생각합니다.
문제는 브릿지의 출금 로직이 얼마나 잘 설계되었느냐가 아닙니다.
아직 안정성과 실제 수요가 검증되지 않은 SVM을 위해 STEEM 메인체인이 왜 하드포크까지 진행하며 위험을 먼저 부담해야 하느냐가 핵심입니다.
브릿지는 단순한 자산 이동 기능이 아니다
멀티체인과 브릿지의 위험성을 충분히 이해하지 못한 상태에서 브릿지 하나를 연결하기 위해 STEEM 하드포크를 추진하는 것은 매우 위험한 결정입니다.
브릿지는 단순히 A 체인에서 B 체인으로 토큰을 옮기는 기능이 아닙니다.
두 체인의 자산, 보안, 경제 모델과 운영 리스크를 서로 연결하는 통로입니다.
한쪽 체인에서 오류가 발생하면 해당 문제는 그 체인 내부에서만 끝나지 않을 수 있습니다. 브릿지를 통해 다른 체인의 사용자와 자산에도 직접적인 피해가 전파될 수 있습니다.
따라서 브릿지를 평가할 때는 다음과 같은 기능만 봐서는 안 됩니다.
- 몇 명의 증인이 출금을 확인하는가
- 몇 블록을 기다린 뒤 출금되는가
- 동일 거래의 중복 출금을 어떻게 막는가
- 브릿지 진행 상황을 UI로 어떻게 표시하는가
이러한 기능은 중요하지만, 브릿지의 일부일 뿐입니다.
가장 먼저 검토해야 할 문제는 연결 대상인 SVM 자체가 충분히 안전하고 안정적인가입니다.
17명의 증인이 확인한다고 잘못된 자산이 정상 자산이 되는 것은 아니다
이번 제안은 21명의 상위 증인 가운데 17명이 동일한 출금 요청을 확인해야 STEEM 메인체인에서 자산이 해제되는 구조를 제시하고 있습니다.
그러나 17/21 합의가 모든 문제를 해결하는 것은 아닙니다.
이 구조는 동일 출금의 중복 처리나 일부 증인의 악의적인 행동을 방지하는 데에는 도움이 될 수 있습니다. 하지만 SVM 내부에서 이미 잘못 생성된 출금 요청을 증인들이 정상 요청으로 판단한다면 이야기가 달라집니다.
예를 들어 다음과 같은 문제가 발생할 수 있습니다.
- SVM의 패깅된 STEEM 발행 로직에 오류가 발생한 경우
- 소각 또는 출금 검증 과정에서 버그가 발생한 경우
- 실제 담보보다 많은 패깅 STEEM이 생성된 경우
- 해킹이나 컨트랙트 오류로 비정상적인 출금 요청이 생성된 경우
- 증인 오라클이 SVM의 잘못된 상태를 정상 상태로 인식한 경우
이때 17명의 증인이 동일한 잘못된 정보를 확인한다면, 합의는 잘못된 출금을 막는 것이 아니라 오히려 잘못된 결과를 확정하는 역할을 할 수 있습니다.
증인들이 정직하게 작동한다는 것과 증인들이 확인하는 데이터가 정확하다는 것은 서로 다른 문제입니다.
증인 합의는 오라클 제출자의 일부 악의적인 행동을 줄일 수는 있지만, SVM 코드와 경제 구조 자체의 안전성을 보장하지는 않습니다.
SVM에서 발생한 문제가 STEEM 메인체인으로 전파될 수 있다
SVM에는 단순히 STEEM을 패깅해서 사용하는 기능만 존재하는 것이 아닐 수 있습니다.
SVM 운영 과정에서 STEEM 인플레이션, SVM 노드 보상, 패깅 STEEM의 발행과 소각, 별도의 보상 및 유통 구조가 만들어질 가능성이 있습니다.
그렇다면 브릿지에 대한 논의는 단순 출금 기능을 넘어서 다음 문제까지 포함해야 합니다.
- SVM에서 발생하는 STEEM 인플레이션은 어떤 구조인가
- SVM 노드 보상으로 지급되는 STEEM은 어디에서 나오는가
- 패깅된 STEEM은 실제 STEEM과 완전한 1대1 담보를 유지하는가
- 발행량과 소각량은 누가 검증하는가
- 오류 발생 시 손실을 누가 부담하는가
- 비정상적으로 생성된 자산이 브릿지를 통과하지 못하도록 어떻게 막는가
- 브릿지 사고가 발생했을 때 중단하거나 복구할 권한은 누구에게 있는가
이러한 질문에 대한 충분한 검증 없이 브릿지만 먼저 연결한다면, SVM 내부에서 발생한 오류나 경제적 문제가 STEEM 메인체인으로 흘러들어올 수 있습니다.
특히 비정상적으로 생성된 패깅 STEEM이 브릿지를 통해 정상 STEEM으로 전환된다면 그 피해는 공격자나 SVM 운영팀에만 머물지 않습니다.
SVM에서 정상적으로 STEEM을 보유하고 사용하던 일반 이용자들의 자산 가치가 훼손될 수 있으며, STEEM 메인체인의 사용자와 거래소, 증인, 애플리케이션까지 문제에 노출될 수 있습니다.
결국 SVM에서 발생한 문제가 STEEM 전체의 문제로 확대되는 것입니다.
왜 미완성 단계의 SVM을 위해 STEEM이 먼저 변경되어야 하는가
현재 가장 이해하기 어려운 부분은 순서입니다.
일반적으로 새로운 체인이나 사이드체인을 개발한다면 다음과 같은 과정이 먼저 진행되어야 합니다.
- SVM을 독립적으로 운영합니다.
- 코드와 경제 모델을 충분히 테스트합니다.
- 실제 이용자를 확보합니다.
- 일정 기간 장애와 보안 사고 없이 운영합니다.
- 발행, 소각, 노드 보상 및 자산 정산 구조를 검증합니다.
- 문제가 발생했을 때 운영팀이 책임지고 해결할 수 있는 체계를 구축합니다.
- 실제 브릿지 수요가 확인되면 STEEM과의 연결을 논의합니다.
그러나 현재는 SVM의 안정성과 실제 수요가 충분히 입증되기 전에 STEEM 메인체인이 먼저 하드포크를 통해 브릿지 기능을 받아들여야 한다는 방향으로 논의가 진행되는 것처럼 보입니다.
이것은 순서가 반대입니다.
SVM이 먼저 안정성을 증명해야 합니다.
STEEM이 SVM의 가능성을 믿고 먼저 하드포크를 해주는 방식이 아니라, SVM이 실제 운영 결과를 통해 STEEM 커뮤니티를 설득해야 합니다.
현재 SVM의 실제 이용자는 몇 명인가
하드포크를 논의하기 전에 가장 기본적인 수요부터 확인해야 합니다.
현재 SVM을 실제로 사용하는 이용자는 몇 명입니까?
10명은 됩니까?
일일 활성 이용자는 몇 명입니까?
100명 이상의 사용자가 지속적으로 이용하고 있습니까?
하루 거래량과 트랜잭션 수는 어느 정도입니까?
현재 실제로 STEEM과 SVM 사이를 이동하려는 자산 수요는 얼마나 됩니까?
브릿지가 없어서 서비스를 이용하지 못하는 사용자는 몇 명입니까?
이러한 기본적인 자료도 공개되지 않은 상태에서 STEEM 전체가 하드포크를 진행해야 할 이유는 찾기 어렵습니다.
이용자가 거의 없는 실험 단계의 서비스를 위해 다음 참여자들이 모두 비용과 위험을 부담해야 할 수 있습니다.
- STEEM 증인
- 전체 노드 운영자
- 거래소
- 블록 익스플로러
- 지갑 개발자
- dApp 운영자
- STEEM 일반 사용자
하드포크는 특정 애플리케이션에 기능 하나를 추가하는 일반적인 업데이트가 아닙니다.
네트워크 참여자들이 동일한 새로운 규칙을 적용해야 하는 합의 변경입니다.
실제 사용자가 거의 없는 서비스를 위해 STEEM 전체의 합의 규칙을 변경하려 한다면, 먼저 그 필요성과 기대 효과를 명확하게 입증해야 합니다.
하드포크는 신중하게 결정해야 한다
하드포크는 한 번 적용하고 문제가 생기면 간단히 되돌릴 수 있는 업데이트가 아닙니다.
새로운 연산과 합의 규칙이 추가되면 증인과 노드 운영자는 소프트웨어를 업데이트해야 합니다. 거래소와 지갑, 익스플로러, dApp도 새로운 거래 및 가상 연산을 인식하도록 시스템을 수정해야 할 수 있습니다.
실제 제안에 대한 검토 과정에서도 bridge_release_operation이 기존 condenser_api에서 누락될 수 있다는 호환성 문제가 이미 언급되었습니다.
이는 브릿지 하나를 추가하는 작업이 기존 STEEM 인프라 전체에 영향을 줄 수 있다는 것을 보여줍니다.
현재 알려진 문제는 개발 과정에서 해결할 수 있을지도 모릅니다. 그러나 멀티체인 연결 이후 발생할 수 있는 모든 위험을 현재 우리가 알고 있다고 말하기는 어렵습니다.
멀티체인에서 발생할 수 있는 피해는 단순한 코드 버그에 한정되지 않습니다.
- 두 체인의 상태 불일치
- 오라클 오류
- 패깅 자산의 과잉 발행
- 소각 검증 실패
- 브릿지 중단
- 체인 재구성
- 운영자 키 탈취
- 거버넌스 충돌
- 경제 모델 붕괴
- 사고 발생 시 책임 주체 불분명
- 거래소와 dApp의 입출금 인식 오류
이러한 문제 가운데 일부는 17/21 증인 합의나 22블록 대기만으로 해결할 수 없습니다.
따라서 “브릿지 코드가 잘 설계되었다”는 평가와 “STEEM 메인체인이 지금 하드포크를 해야 한다”는 결론은 분리해서 생각해야 합니다.
SVM의 위험은 우선 SVM 운영팀이 부담해야 한다
SVM은 독립적인 프로젝트입니다.
그렇다면 초기 개발과 운영 과정에서 발생하는 위험도 우선 SVM 운영팀이 책임지고 감당해야 합니다.
SVM이 아직 완성되지 않았고 안정성이 검증되지 않았다면, 먼저 제한된 환경에서 운영하며 문제를 해결해야 합니다.
오류가 발생했을 때 STEEM 메인체인이나 STEEM 일반 사용자에게 피해가 전파되지 않는 구조에서 충분한 검증을 거쳐야 합니다.
운영팀은 다음 사항을 먼저 증명해야 합니다.
- SVM이 장기간 안정적으로 운영될 수 있다는 것
- 패깅 STEEM이 정확하게 발행되고 소각된다는 것
- SVM 노드 보상과 인플레이션 구조가 지속 가능하다는 것
- 공격이나 버그가 발생했을 때 대응할 수 있다는 것
- 사고가 발생하면 운영팀이 손실과 복구 책임을 부담한다는 것
- 실제로 브릿지를 필요로 하는 이용자와 거래 수요가 존재한다는 것
이후 안정성이 충분히 검증되고 실제 사용자가 늘어난다면 그때 STEEM 브릿지와 하드포크를 논의해도 늦지 않습니다.
브릿지를 영원히 반대하는 것이 아니다
저는 SVM과 STEEM 사이의 브릿지를 영구적으로 반대하는 것이 아닙니다.
SVM이 실제로 성장하고, 안정성을 입증하며, 충분한 이용자와 자산 이동 수요를 확보한다면 브릿지는 STEEM 생태계 확장에 도움이 될 수 있습니다.
그러나 현재 단계에서 필요한 것은 STEEM의 하드포크가 아닙니다.
우선 필요한 것은 다음과 같습니다.
- SVM의 독립적인 장기 테스트
- 실제 사용자와 거래량 공개
- 패깅 STEEM 발행 및 소각 감사
- SVM 노드 보상과 인플레이션 구조 공개
- 보안 감사 결과 공개
- 사고 발생 시 책임과 보상 기준 수립
- 충분한 기간 동안의 안정적인 메인넷 운영
- 브릿지를 필요로 하는 실제 수요 입증
이러한 과정이 끝난 뒤 STEEM 커뮤니티가 하드포크의 비용과 위험, 기대 효과를 함께 검토해야 합니다.
결론
현재 브릿지 제안에 대한 논의는 17/21 증인 합의, 22블록 대기, 스팸 방지, 출금 UI와 같은 기술적인 세부사항에 집중되어 있습니다.
그러나 그보다 먼저 답해야 할 질문이 있습니다.
SVM은 STEEM 메인체인이 하드포크까지 해주어야 할 만큼 충분히 안정적이고, 안전하며, 실제로 사용되고 있는 서비스입니까?
이 질문에 명확하게 답하지 못한다면 현재 브릿지 하드포크 논의는 지나치게 이릅니다.
멀티체인 구조가 STEEM에 어떤 피해를 가져올 수 있는지 우리는 아직 모두 알지 못합니다.
SVM 운영 과정에서 발생하는 초기 위험은 우선 SVM 운영팀과 SVM 생태계가 감당해야 합니다. 미완성 서비스의 가능성을 위해 STEEM 전체가 먼저 위험을 떠안아서는 안 됩니다.
SVM이 안정성과 수요를 충분히 증명한 뒤 브릿지를 개선하고 하드포크를 논의해도 늦지 않습니다.
지금 필요한 것은 STEEM의 하드포크가 아니라, SVM의 검증입니다.