USPD는 은밀 하거나 조용한 공격 기법으로 해킹 당했습니다. 해킹팀은 이더스캔에서 해킹 흔적을 찾을 수 없었고 공격자가 숨겨진 접근 권한을 가졌다고 주장했습니다. 하지만 이는 모두 잘못된 해석이며, 어쩌면 거짓말일 수도 있습니다. 이제부터 그 진실을 밝혀보겠습니다. 아니면 어쩌면 이 모든 상황을 지나치게 단순화해서 보는 것일지도 모릅니다.

유능하고 태만하지 않은 팀이었다면 프로토콜이 손상된 9월에 즉시 문제를 발견했을 것입니다. 이 문제가 "숨겨져 있었다"고 주장하는 보안 "연구원"은 마찬가지로 무능하고 태만하며 신뢰할 수 없습니다.
이더스캔과 같은 공개적으로 사용 가능한 무료 도구만 사용해도 팀은 배포 시점에 문제를 파악할 수 있었습니다. 유능하고 꼼꼼한 팀이라면 당연히 이를 발견했을 것입니다. 특별한 도구는 필요하지 않았습니다. 물론 이더스캔이 관련 정보를 숨기는 경우가 있는 것은 사실입니다. 이더스캔을 무조건 신뢰하고 상황을 파악하는 것은 좋지 않다는 점을 이미 여러 차례 강조해 왔습니다. 또한, 일부 팀들이 이더스캔의 한계를 이용해 자신들의 제품에 대한 통제력을 과소평가하는 경향이 있다고 지적해 왔습니다. 어쩌면 우리의 평가는 더욱 낮아져야 할지도 모릅니다. 이더스캔에 통제력이 나타나지 않는다는 이유로 팀들이 스스로 통제력을 갖고 있다는 사실조차 인지하지 못한다면 어떻게 될까요? 이는 매우 혼란스럽고 어리석 으며 안타까운 일이 될 것입니다.

하지만 USPD는 그렇게 복잡한 시스템이 아닙니다. 관련 정보가 은폐되지 않았다는 점에서 이는 명백히 과실과 무능력이 복합적으로 작용한 결과입니다. 물론 개발자들이 시스템을 제대로 배포하기 위해 필요한 모든 도구를 사용하는 것은 당연한 일입니다. 하지만 특수 소프트웨어를 사용하지 않거나 복잡한 감시 도구를 직접 개발하는 것과 이번 사건은 완전히 다릅니다. 이 팀은 표준적이고 무료로 제공되는 소프트웨어를 사용하지 않았고, 그런 소프트웨어로는 문제가 발견되지 않았다고 거짓말을 했습니다.
이제 우리는 이것이 복잡한 은밀한 공격이 아니라, 합리적인 팀이라면 놓쳤을 수도 있는 단순한 무지와 오류의 결과임을 증명할 것입니다. 네, 팀이 이 문제를 놓쳤습니다. 우리는 그 점을 부인하지 않습니다. 우리의 목적은 오히려 팀의 무능과 과실을 명확히 드러내는 것입니다. 이를 위해 우리는 문제가 발생했을 당시 실시간으로 분명히 드러났지만 팀이 간과했던 위험 신호들을 지적할 것입니다.
세부
프로젝트의 GitHub 저장소를 살펴보면, 그들이 배포한 계약 중 하나가 0x1346B4d6867a382B02b19A8D131D9b96b18585f2 주소에 있는 "안정화(stabilizer)" 계약임을 알 수 있습니다. 이더스캔(etherscan)에서 표준 도구를 사용하여 해당 배포 트랜잭션을 확인할 수 있습니다. 이더스캔에 따르면 해당 트랜잭션은 2025년 9월 16일 오후 1시 1분 59초(UTC)에 실행되었습니다.
그리고 바로 다음 블록 인 2025년 9월 16일 오후 1시 2분 11초(UTC)에 동일한 0x1346 주소에서 6개의 로그가 기록된 것을 확인할 수 있습니다. 로그는 다양한 표준 무료 도구를 사용하여 쉽게 볼 수 있습니다. 해당 6개의 로그는 다음과 같습니다.
- 공격자가 0xc2a0aD4Bd62676692F9dcA88b750BeC98E526c42 주소에서 비공개 소스 계약에 RoleGranted를 부여한 것으로 추정됩니다.
- 동일한 비공개 소스 계약에 또 다른 역할이 부여되었습니다 .
- InsuranceEscrowUpdated는 보험 에스크로 계약을 동일한 비공개 소스 계약으로 업데이트합니다.
- "Initialized" 는 프로토콜이 초기화되었음을 나타냅니다.
- 업그레이드되었다는 것은 0xAC075b9bf166e5154Cc98F62EE7b94E5345Cc090이라는 또 다른 비공개 소스 계약에 대한 일종의 프록시 업그레이드를 나타냅니다.
- 이번에는 실제 USPD 시행 계약으로 업그레이드되었습니다 .
팀에서 배포 후 계약 관련 이벤트를 확인했더라면 이러한 이벤트를 확인할 수 있었을 것입니다. 에더스캔(Etherscan)이나 그 외 다양한 유료 및 무료 도구를 이용하면 쉽게 확인할 수 있습니다.
언급된 두 개의 비공개 소스 계약은 의심스러우며, 팀에게 무언가 잘못되었다는 것을 즉시 알려주었을 것입니다. 유능한 팀이라면 예기치 않은 계약이 발견되면 무슨 일이 있었는지 문의했을 것입니다.
팀이 의도했던 계약이 아니라는 것을 어떻게 알 수 있을까요? 해당 이벤트에서 노출된 주소들이 공격자의 주소로 표시되었기 때문입니다. 자세한 내용은 나중에 설명드리겠지만, 팀이 예상치 못한 주소들이 관리자 권한을 획득하고 프록시와 연결된 것을 발견했을 때, 이는 매우 심각한 위험 신호였습니다. 팀은 해당 두 주소가 나타날 것이라고 예상하지 못했으므로, a) 로그를 보고도 무시했거나 b) 로그를 아예 보지 못했을 가능성이 있습니다. 두 경우 모두 팀의 과실입니다.
RoleGranted 로그는 프로토콜 내의 권한과 관련이 있으며 , 임의의 외부 계약에 권한이 부여되었다는 점은 다시 한번 심각한 문제점을 보여줍니다.

앞서 언급했듯이 보안 연구원들은 현재 위 두 주소를 악성 주소로 분류하고 있습니다 . 외부에서는 이러한 주소들이 해킹의 일부인지 확실히 알 수 없었습니다. 단순한 오류였을 가능성도 있습니다. 팀에서 실수로 해당 연락처를 배포했지만, 실제 운영 환경에서 사용될 일이 없었기 때문에 출처를 공개하지 않았을 수도 있습니다. 오픈소스 프로토콜에서 임의의 비공개 소스 계약이 일시적으로 업그레이드되는 사례를 종종 발견합니다. 이러한 일시적인 오류 배포를 검증하는 사람은 거의 없습니다. 때로는 프로토콜 자체가 오픈소스인지 여부 를 거짓 으로 밝히는 경우도 있습니다. 이는 분명 문제이지만, 앞서 언급한 문제와는 다른 맥락입니다.
하지만 USPD 팀은 이것이 보안 문제라는 것을 알고 있었을 것입니다. 그들은 자신들이 어떤 계약을 체결했는지 알고 있었고, 이 주소들이 자신들의 통제하에 있지 않다는 것도 알고 있었습니다. 외부인이 당시에는 무엇이 잘못되었는지 알아차리기 어려웠을 것입니다. 하지만 유능한 팀이라면 간단하고 무료이며 표준적인 도구만으로도 100% 알아낼 수 있었습니다. 외부인이라면 이상 징후를 발견하고 질문을 할 수 있었을 것입니다. 그리고 가장 재미있는 결과는 당시 어떤 보안 연구원이 USPD에 문의했다가 거절당하거나 무시당하는 것이었을 겁니다. 하지만 안타깝게도 그런 일은 일어나지 않은 것 같습니다. 만약 이런 일이 실제로 일어났다는 것을 알고 계신다면 연락 주시기 바랍니다.
팀이 한 일
위 사건 발생 후 몇 시간 뒤, 해당 팀이 GitHub에 0x1346 배포 주소를 기록한 것을 확인할 수 있습니다. 개발자 한 명이 이 작업에 몇 시간을 투자했고, 모든 것을 완전히 업데이트 하기 위해 여러 번의 커밋을 거쳤습니다. 흥미롭게도, 그 개발자는 당시 테스트 작업도 진행하고 있었습니다. 심지어 9월 18일에는 "새로운 구현 및 권한으로 USPDToken을 재배포"하는 스크립트를 커밋하기도 했습니다. 따라서 tomw1808이 문제가 있다는 것을 알고 있었던 것은 아닌지 의심해 볼 필요가 있습니다. 해당 개발자가 온체인 배포 검증을 담당했는지는 알 수 없지만, 그 부분을 먼저 의심해 보는 것이 좋을 것 같습니다. 어쩌면 이 사건 속에 숨겨진 재미있는 이야깃거리가 있을지도 모릅니다.
마지막으로, 두 프로젝트 감사 모두 배포 이전에 실시되었으므로 배포가 아직 이루어지지 않았기 때문에 배포 과정에서 발생할 수 있는 문제를 발견할 수 없었다는 점에 유의하십시오. 또한 배포에 대한 감사가 실시된 것 같지도 않습니다. 만약 실시되었다 하더라도, 제대로 된 감사가 아니었거나, 아니면 제대로 받아들여지지 않았을 가능성이 있습니다.
어쨌든, 문제는 코드 자체가 아니라 배포 방식에 있었습니다. 하지만 그렇다고 코드가 특별히 좋았다는 뜻은 아닙니다! 다음은 감사 보고서 목차의 일부입니다.

전문 프로그래머가 아니더라도 "이건 형편없고, 아마추어 같고, 시대에 뒤떨어진 코드다"라고 말할 수 있습니다. 두 감사 모두 초기화 과정에서 문제를 발견했고, 어느 정도는 배포 과정도 검토했다고 주장했습니다. 따라서 감사 담당자들이 잘못된 배포 및 초기화 과정을 더 명확하게 파악하지 못한 점에 대해서는 부분적인 책임이 있습니다. 하지만 가장 큰 책임은 팀에 있습니다. 다시 한번 말씀드리지만, 감사 과정에 참여했던 분들 중 이와 관련된 다른 황당한 사실을 알고 계신 분이 있다면 알려주시기 바랍니다. 이 문제가 논의되었지만 묵살되고 협상을 통해 해결되었을 가능성도 충분히 고려하고 있습니다.
원한다면 배포 자체가 범위에서 벗어났다고 주장할 수도 있습니다. 하지만 코드 업그레이드가 불가능한 시스템에서 "프로토콜 전체에 걸쳐 중복 코드가 있다"거나, 설계 단계부터 의도된 "cUSPD의 중앙 집중화 위험" 같은 문제는 심각한 문제가 아닙니다. 이러한 감사는 기껏해야 가치가 낮은 불필요한 내용으로 채워 넣은 것에 불과합니다. 이것 또한 협상의 결과였을 가능성이 있으며, 어쩌면 다른 흥미로운 내용이 숨겨져 있었을지도 모릅니다.
이거 해킹인가요?
이 경우 "공격자"는 배포 프로세스의 일부를 선점하여 자신의 코드를 실행함으로써 팀의 트랜잭션보다 먼저 이득을 취했습니다. 여기서 "선점"이라는 용어는 기계적인 의미로 사용되었으며, 합법성이나 도덕성에 대한 의견을 표명하려는 의도는 아닙니다.
그리고 이는 소위 "해커"들이 이더리움의 핵심인 경쟁적인 블록 생성 과정을 악용하여 돈을 갈취했다는 페레르-부에노 사건 과 매우 유사합니다. USDP 사건과 페레르-부에노 사건 모두에서, 누구도 다른 사람의 개인 키를 해킹하지 않았습니다. 누구도 다른 사람의 집이나 사무실에 침입하지 않았습니다. 누구도 피싱 공격을 하거나 거짓말을 하지 않았습니다. 모든 것은 이더리움 프로토콜의 범위 내에서 이루어졌습니다.
두 경우 모두 일종의 선행매매가 존재합니다. USDP의 경우, 마치 누군가 현관문을 열어놓고 차 키를 테이블 위에 올려놓은 것과 비슷합니다. 다만 이더리움에서의 거래는 그 차를 가져가는 행위가 절도로 간주되지 않는 환경에서 이루어집니다.
복잡한 릴레이어-블록 빌더-멤풀-합의 메커니즘을 이용해 탈중앙화 거래소 (탈중앙화 거래소(DEX) 거래를 선점하는 것과 이와 같은 배포를 선점하는 것에는 아무런 차이가 없습니다. 둘 다 이더리움 커뮤니티가 구축하고 사용하고자 했던 동일한 프로토콜 기능을 "악용"하는 것입니다.
코인 센터가 페레리-부에노 형제를 지지하는 의견서 에서, 그들이 이더리움 시장에서 행한 선행매매는 완전히 공정하고 합리적이며 합법적이었다고 주장합니다.
이더리움은 글로벌 기술이자 생태계입니다. 새롭고 빠르게 변화하며, 비규제 아니지만, 내부적인 경제적 인센티브, 암호화 제어, 그리고 피고인과 피해자들을 포함한 검증자들 간의 치열한 경쟁으로 인해 (아래에서 설명하는 바와 같이) 규제가 존재합니다. 이더리움의 오픈 소스 소프트웨어는 수천 명의 뛰어난 개발자들이 투명하고 협력적으로 자발적으로 기여한 덕분에 이러한 경쟁에 대한 규칙과 통제 장치를 마련합니다. 소수의 검사의 판단이 해당 기술에 대한 합법적인 참여 자격을 규정하는 특정한 대안적 기술 표준을 강요하고, 그 표준이 오픈 소스 소프트웨어의 확립된 규칙들과 명백히 모순된다는 것은, 한마디로 급진적인 발상입니다.
그러니까 이 모든 것은 "명확한" "확립된 규칙" 안에서의 "치열한 경쟁"을 중심으로 구축된 것입니다. 그리고 그 규칙 안에서 활동하는 사람은 누구든 법을 위반하는 것이 아닙니다. 왜냐하면 모든 참가자가 자발적으로 이러한 방식에 참여했기 때문입니다. 적어도 그런 주장이 있습니다. 코인 센터는 다음과 같이 덧붙입니다.
피해자로 지목된 사람들은 실제로 업계 참여자들이 예상하고 기대하는 바와 같이, 프로토콜의 한계까지 최대한의 추출 가치를 얻기 위한 치열한 경쟁에 참여하고자 했던 매우 성공적인 소프트웨어 봇의 사용자들이었습니다. 주장된 피해는 단순히 피고인들이 프로토콜의 엄격한 합의 규칙에 따라 "정직한" 참여에 대한 한도까지 블록 보상을 극대화하기 위해 다양한 상업적 및 기술적 방법을 모색하면서 그들의 경쟁에서 밀려났다는 것입니다.
그들은 단순하고 명확한 규칙만이 최적의 결과를 얻는 유일한 방법이며, 관련된 모든 사람들이 이러한 조건에 동의하고 참여하기로 했기 때문에 이 모든 것이 옳다고 계속 주장합니다.
암호화폐 분야의 사상가들 사이에서 채굴자 검증자들이 최소한의 명확한 제약 조건 하에서 경쟁하고, 규정 미준수 시 자동적인 제재를 받도록 하는 목표는 시장이나 탐욕이 미덕이라는 고든 게코식 사고방식에 내재된 편견에서 비롯된 것이 아닙니다. 오히려 이는 자기 이익 추구는 언제나 존재하며, 검증 불가능한 외부 정보나 압력(블록체인의 수학적 검증 외의 요소)에 좌우되지 않는 단순한 경쟁 규칙이 자기 이익 추구를 단순하고 정치적으로 중립적인 목적, 즉 단순한 수학적 거래 검증에만 국한시킬 수 있다는 인식에서 비롯된 것입니다.
USPD의 "공격"은 이더리움 합의 규칙을 위반하지 않았습니다. 아무도 아무것도 훔치지 않았습니다. 단지 영리한 업계 참여자가 역량이 부족한 팀을 "경쟁에서 이긴" 사례일 뿐입니다. 만약 그 팀이 이더리움 경쟁 환경에 참여할 자격이 없었다고 주장하고 싶다면, 참여 승인 절차가 어떻게 작동하는지 설명해야 합니다. 약하고 무지한 사람들을 보호하는 것은 고귀한 목표일 수 있습니다. 하지만 누가 약하고 무지한 사람으로 간주되고 누가 성인들의 경쟁에 참여할 자격이 있는지를 결정하는 절차가 필요합니다. 이것을 해킹이라고 부르는 것은 이더리움 합의 과정에 참여하려면 단순히 소프트웨어를 실행할 수 있는 능력 이상의 역량 테스트를 통과해야 한다는 주장과 같습니다. 글쎄요.
이로써 우리는 흥미로운 입장에 놓이게 되었습니다. 웹3 업계의 상당 부분이 페라이르-부에노 사건에 대해 코인 센터와 같은 입장을 취하고 있습니다. 만약 그것이 진정성 있는 입장이라면, 업계 관계자들 또한 이번 사건이 해킹이 아니었다는 점에 동의해야 할 것입니다. 더 나아가, 업계는 해당 팀과 프로세스에 심각한 결함이 있었다는 사실을 인정해야 합니다.

이러한 "꼼수"가 완전히 용인될 수 있는 행위였다는 사실을 인정하지 않는다면, 업계의 입장이 자기 이익만을 추구할 때를 제외하고는 일관성이 없다는 것이 명백해질 것입니다. 우리는 웹3 로비 단체에서 지적인 일관성을 기대하지 않으며, 그들의 위선을 드러내는 이러한 사례에 대해 논의를 거부하더라도 놀라지 않을 것입니다. 하지만 질문해 볼 가치는 있습니다.
결론적으로, 이러한 무능한 개발자들에게 최소한 사회적 제재라도 가하지 않는다면, 앞으로 이런 일이 더욱 빈번하게 발생할 뿐입니다. 왜냐하면 이는 커뮤니티가 사용하고 싶어하고 제거하고 싶어하지 않는 이더리움 기능에만 의존하기 때문입니다. 개발팀은 문제를 실시간으로 발견하고 출시 전에 배포 프로세스를 수정했어야 했습니다. 현재의 이더리움 생태계를 받아들인다면, USPD는 기술적인 문제가 아니라 사회적인 문제를 안고 있었던 것입니다. 따라서 "해결책" 또한 사회적인 차원에서 이루어져야 합니다.

USPD 해킹: 세부 정보 및 질문'은 원래 미디엄(Medium) 의 ChainArgos 에 게시되었으며, 사람들이 이 기사를 강조 표시하고 댓글을 달면서 대화를 이어가고 있습니다.




