스마트 컨트랙트 감사

스마트 컨트랙트는 특이한 소프트웨어입니다. 돈을 직접 보관하고, 누구나 들여다볼 수 있는 공개된 곳에서 실행되며, 한 번 배포하면 고치기 어렵거나 아예 고칠 수 없습니다. 놓친 코드 한 줄 때문에 공격자가 트랜잭션 하나로 프로토콜을 털어 갈 수도 있습니다. 감사는 출시 전의 핵심 방어선입니다. 공격자보다 먼저 전문가가 코드를 읽는 것입니다.

감사인이 살펴보는 것

• 로직 오류: 적힌 대로 작동하지만 의도한 대로는 작동하지 않는 코드입니다. 리워드를 두 번 지급하는 계산식이 그런 예입니다.
• 접근 제어: 관리자만 호출해야 하는데 누구나 호출할 수 있는 함수입니다.
• 재진입(reentrancy): 첫 호출이 끝나기 전에 외부 호출을 통해 공격자가 함수에 다시 들어올 수 있게 되는 문제로, 2016년 The DAO 해킹의 원인이었습니다.
• 가격 조작: 한 트랜잭션 안에서 움직일 수 있는 가격을 그대로 믿는 로직이며, 취약한 오라클을 통해 일어나는 경우가 많습니다.
• 경제적 설계: 모든 코드가 적힌 대로 작동하더라도 자금력이 큰 참여자가 악용할 수 있는 인센티브 구조입니다.

감사인은 수동 검토와 자동화 도구를 함께 쓰고, 최근에는 정형 검증(formal verification)도 점점 더 많이 활용합니다. 정형 검증은 코드가 문서로 정한 명세를 충족한다는 것을 수학적으로 증명하는 방법입니다.

두 가지 감사 방식

전통적인 감사 회사 방식에서는 소수의 보안 엔지니어 팀이 정해진 기간 동안 코드베이스를 분석하고 보고서를 냅니다. 경쟁형 감사에서는 많은 독립 연구자가 같은 코드를 동시에 검토하고, 찾아낸 이슈에 따라 보상을 받습니다. 두 방식은 서로 다른 것을 잡아내는 경향이 있어서, 프로토콜은 둘을 함께 쓰는 경우가 많습니다.

감사 보고서 읽는 법

범위부터 보십시오. 어떤 컨트랙트, 어떤 버전의 코드, 어떤 기간을 다뤘는지입니다. 1버전에 대한 감사는 2버전에 대해 거의 아무것도 말해 주지 않습니다. 그다음 심각도별로 발견 사항을 읽습니다. 치명(critical)과 높음(high) 등급은 자금 손실로 이어질 수 있고, 중간(medium) 등급은 대개 특정 조건이 갖춰져야 문제가 되며, 낮음(low)과 정보(informational) 등급은 코드 위생에 관한 것입니다. 발견 사항마다 수정됨, 인지됨, 이의 제기 중 어느 상태인지, 그리고 수정 사항을 다시 검토했는지 확인하십시오.

간단한 예시

어떤 보고서에 높음 등급 발견 사항이 하나 있습니다. 반올림 오류 때문에 사용자가 넣은 것보다 조금 더 많이 출금할 수 있고, 이를 수천 번의 트랜잭션에 걸쳐 반복하면 볼트를 비울 수 있다는 내용입니다. 팀은 출시 전에 이를 고치고, 감사인이 수정을 확인합니다. 바깥에서는 아무도 그 버그에 대해 듣지 못합니다. 이것이 제 역할을 한 감사이며, 표지의 로고보다 발견 사항 항목이 더 중요한 이유입니다.

위험과 한계

감사는 스냅숏입니다. 검토가 끝난 뒤에도 코드는 바뀌고, 새 컨트랙트가 그 코드와 상호작용하며, 공격 기법은 발전합니다. 큰 피해를 낸 디파이 공격 가운데 일부는 감사를 받은 프로토콜에서 일어났으며, 범위 밖의 코드나 여러 프로토콜이 서로 맞물리는 방식이 통로가 된 경우가 많았습니다. 감사는 키를 어떻게 관리하는지, 준비금이 무엇으로 이뤄져 있는지 같은 시스템의 오프체인 부분도 판단할 수 없습니다. 그래서 감사는 여러 층 가운데 하나일 때 가장 쓸모가 있습니다. 출시 뒤에도 연구자에게 계속 보상하는 버그 바운티, 실시간 트랜잭션을 지켜보는 런타임 모니터링, 그리고 자산 자체에 대한 준비금 증명이 함께할 때입니다.

Tori Finance의 스마트 컨트랙트는 Sherlock과 Nethermind의 감사를 받았습니다. 감사는 Hypernative의 런타임 모니터링, Accountable의 준비금 증명과 함께 Tori Finance 보안을 이루는 한 층입니다.