리졸브 해킹 사건과 그로부터 얻지 못한 교훈 이번 피해는 100% 자초한 것이며 충분히 예방할 수 있었던 것입니다. Resolv의 5천만 달러 + 3천만 달러 민트(Mint) "승인되지 않음"으로 이루어졌습니다. 즉, 개인 키가 유출되었다는 뜻입니다. 마치 북한식 수법처럼 말이죠. 이런 식의 잘못된 김치 프리미엄은 쉽게 막을 수 있었습니다. 시장 상황이 나빠지거나 가격이 하락하거나 담보가 무용지물이 된 것이 아닙니다. 단순히 무능함, 마치 발에 총을 쏘는 것과 같은 어리석은 실수 때문에 발생한 것입니다. 이제 2013년 비트코인에 멀티시그 기능이 추가된 이후 13년 동안, 우리는 무단 개인 키 사용을 방지하는 방법을 알고 있습니다. - 애초에 개인 키를 사용하지 않고, 다중 서명 지갑을 사용하는 것이 좋습니다. - 서명 프로세스에 추가적인 보호 기능을 제공하는 하드웨어 보안 모듈(HSM)을 사용하십시오. 그런데 Resolv는 왜 이런 일을 했을까요? 그리 복잡한 문제는 아닌데요. 무단 사용의 원인은 무엇입니까? "SERVICE_ROLE은 Resolv의 USR 프로토콜 계약(2단계 요청/완료된 민트(Mint)/스왑 흐름의 일부)에서 특권 역할입니다. Resolv는 이 역할의 목적, 보안 모델, 할당 프로세스 또는 위험에 대해 자세히 설명하는 공식 문서를 제공하지 않습니다. 공개된 라이트페이퍼, 사용자 문서(http:/docs.resolv.xyz) 또는 GitHub README 어디에도 언급되어 있지 않습니다." (그록의 명언) 18회 감사 완료 Resolv는 여러 차례 감사를 진행했음에도 불구하고 왜 이 문제를 발견하지 못했을까요? @sherlockdefi와 같은 극히 드문 경우를 제외하고, 감사 기관들은 프로젝트가 해킹당하든 말든 신경 쓰지 않기 때문입니다. 그들은 배포된 시스템에 대해 어떠한 책임도 지지 않습니다. 아무런 이해관계도 없죠. 그저 현금 보상과 "코드가 괜찮아 보인다"는 것만으로 만족할 뿐입니다. 그런데도 이 모든 감사 담당자들이 이 명백한 사실을 지적하지 못했습니다. 우리에게는 스테이블코인을 무제한으로 민트(Mint) 할 수 있는 SERVICE_ROLE이 있는데, 이 사실은 어디에도 문서화되어 있지 않습니다. 이봐! "시스템에 있는 이 막강한 개인 키" 말이지. 하지만 우리한테 약간의 수수료만 내면 소프트웨어는 문제없어. 그 후에 무슨 일이 일어나든 우린 신경 안 써. 그냥 잘못 다루지만 않으면 돼, 알겠지? 코인베이스 투자 유치, 스테이크하우스의 찬사 브라이언의 승인 도장도 별 도움이 되지 않았다. 불과 6일 전, 스테이크하우스는 자사의 스테이크하우스 재무 분석 보고서에서 다음과 같이 썼습니다. "운영 측면에서 Resolv는 제3자 수탁, 다중 오라클 이중화 및 프로그램적 안전장치를 통해 제도적 엄격성을 입증했습니다. Resolv는 현재까지 사고 없이 운영되었으며 불리한 상황에서도 자체적으로 오류를 수정하는 능력을 보여주었습니다." kitchen.steakhouse.financial/p... 이 보고서는 너무 모호해서 실제 시스템, 프로세스 및 그 속성을 명시하지 않아 ISO 9001 품질 심사 보고서와 다를 바 없습니다. "그들과 점심을 먹고 프랑스산 레드 와인 한 잔을 마신 후, 시스템이 괜찮을 거라고 확신했습니다." 제3자 보관이라고요? 그럼 파이어블록을 사용해서 개인 키를 보호했다는 뜻인가요? 전 모사드 요원이 만든 개인 키 지갑이라도 여전히 개인 키 지갑일 뿐이고, 오히려 더 위험할 수 있습니다. 왜냐하면 소프트웨어 내부가 얼마나 취약한지 알 수 없기 때문에, 폐쇄형 소스 소프트웨어 서비스 제공업체가 직접 키를 훔쳐갈 가능성이 높기 때문입니다. 향후 이러한 상황을 피하는 방법 그렇게 어렵지 않습니다. 특히 1천만 달러의 초기 자금과 최대 5억 달러의 예치(stake) 있다면, 충분히 더 잘할 수 있습니다. 1. 권한이 낮은 개인 키 2. 이해관계가 얽힌 감사인을 활용하십시오. 3. 투명성을 유지하고 분산형 금융의 방식을 따르십시오. 탈중앙화 금융(DeFi) 사용자로서 이러한 사고를 피하려면 어떻게 해야 할까요? 이건 좀 까다로운 문제네요. 문제는 기본 스마트 계약이 여러 요소가 혼합된 자작 언어로 작성된 솔리디티(Solidity)라는 점입니다. 솔리디티 스마트 계약의 보안 특성을 파악하기는 매우 어렵습니다. 더 나은 언어들이 있지만, 우리는 어쩔 수 없이 레거시 언어인 솔리디티 사용해야 하는 상황입니다. 솔리디티의 잘 알려진 결함에도 불구하고, 단순히 사고 사례에만 머무르지 않고 언어 수준에서 이러한 허점을 찾아 해결할 방법을 연구할 인력을 고용하는 등 실질적인 보안 개선 노력이 거의 이루어지지 않고 있습니다. 인공지능은 많은 도움이 될 것입니다. 보안 감사관들의 평판이 해킹 사건과 직접적인 상관관계가 없어 책임을 묻기 어려웠던 만큼, 앞으로는 보안 감사관 자체를 없애는 것이 해결책이 될 수 있습니다. 머지않아 누구나 복잡하게 구축된 스마트 계약 시스템에 인공지능 에이전트를 연결하여 적합 또는 부적합 보고서를 받을 수 있게 될 것입니다. 이 주제에 대해 이미 작은 시범 프로젝트를 진행한 적이 있습니다(github.com/tradingstrategy-ai/...…). Claude Code는 파트너사 시스템 중 하나에 배포된 스마트 계약에서 절대 있어서는 안 될 특권 개인 키를 찾아낼 수 있었습니다. 추신: HSM 관련: 중요한 개인 키를 보호하기 위해 시중에 나와 있는 불투명한 상용 솔루션은 더 이상 사용하지 마세요. 오프체인 고신뢰 개인 키가 필요한 보안이 중요한 스마트 계약 시스템을 구축하는 경우 Google Cloud를 활용할 수 있습니다. 다음은 Google Cloud용 무료 오픈 소스 이더리움 서명 모듈입니다: web3-ethereum-defi.tradingstra...… - 조직 정책을 적절히 설정하는 것을 잊지 마세요. @zacodil 님과 @omeragoldberg 님의 연구에 찬사를 보냅니다.