목차

1. 스마트 컨트랙트 톺아보기

     1-1. 스마트 컨트랙트의 정의

     1-2. 스마트 컨트랙트 도입 배경과 기대 효과

     1-3. 스마트 컨트랙트 구조

     1-4. 스마트 컨트랙트 밸류체인 정리

     1-5. 스마트 컨트랙트의 한계점

2. 취약점을 활용한 다양한 해킹 사례 

     2-1. 스마트 컨트랙트 관련 해킹 사례

     2-2. 스마트 컨트랙트 이외 해킹 및 탈취 사례

     2-3. 디파이 관련 해킹이 많은 이유

3. 스마트 컨트랙트 관련 해킹 방지 방안

     3-1. 사전 방지 방안

     3-2. 사후 방지 방안

     3-3. 주체별 유의할 점

4. 마무리하며

1. 스마트컨트랙트 톺아보기

1-1. 스마트컨트랙트의 정의

스마트컨트랙트란? 한국어로 직역해보면 똑똑한 계약이라는 의미로, 서면이 아닌 특정 코드에 의해 이뤄지는 계약으로 이해가 가능하다. 결국, 코드에 의해 특정 조건이 부합되었을 때, 계약을 이행시키는 Script 구조이며 컴퓨터 프로그램으로, 법적으로 의미를 지닌 계약은 아니다.
‘Code As Law’로 코드로 중개자 없이 계약 실행을 시켜주는 ‘Trustless’ 구조인 것이다.

1-2. 도입 배경과 기대효과

도입 배경

스마트컨트랙트는 언제, 어떻게 등장하였을까?

스마트컨트랙트는 블록체인 2.0 이더리움의 등장과 함께 부각되기 시작하였다. 사실 최초의 스마트 컨트랙트 개념은 1994년 컴퓨터 공학과 법학을 전공한 Nick Szabo이 제안하였다.

다만, 향후 비탈릭 부테린(Vitalik Buterin)이라는 인물이 이를 블록체인 기술과 함께 이더리움이라는 플랫폼으로 구현한 것이다. 이더리움 등장 이후, 본격적으로 스마트 컨트랙트 사용처가 확대되기 시작하였다.

그럼 이더리움의 등장 배경은 어떠하였을까?

비탈릭 부테린은 과거 비트코인의 소스 코드 일부 수정하여서 스마트 컨트랙트 기능을 구현하려고 하였으나, 비트코인 커뮤니티에서 해당 프로포절이 받아들여지지 않았다.

이더리움은 2013년 Thiel Fellow인 비탈릭 부테린이 제안하였으며 2015년 첫 공개가 된 이후 단기간에 시가총액 2위 규모의 크립토 자산으로 자리매김하였다. 타 크립토 자산군 대비 ‘스마트 컨트랙트’라는 개념을 도입시킨 것이 차별 포인트였다.

스마트 컨트랙트 도입으로 인한 기대효과는 어떤 것이 있을까?

이더리움의 등장 이후, 이더리움은 스마트 컨트랙트 플랫폼으로써 다양한 유틸리티 창출의 가능성을 기대하게 만들어 주었다.

 스마트 컨트랙트의 특징을 살펴보면 조금 더 기대효과에 대해 직관적으로 살펴볼 수 있다.

• 누구나 배포 가능
• 컨트랙트 소유자가 아니더라도 누구든지 검증 가능
• 코드 실행 자동화 가능
• 위변조가 어려움

따라서, 스마트컨트랙트는 1)투명하게 거래내역 공개가 필요하며 위변조를 어렵게 할 필요성이 있는 곳 (소유권 보장 가능), 
2)중개인이 많이 필요하거나 비용이 커서 중개인 관련 비용 절감의 Benefit이 큰 곳, 3)거래 수수료 자체가 너무 비싸서 해당 비용에 대한 감소에 대한 니즈가 클 경우 사용되는 것이 적합하다.

현재 등장한 대부분의 어플리케이션이 이러한 니즈에 부합한다. 

금융서비스가 중개자가 가장 많은 부문 중 하나로, 스마트 컨트랙트를 활용한 DeFi(Decentralized Finance) 부문이 빠르게 발전하였으며, 
‘소유권’ 이라는 측면에서 투명성과 위변조 불가능성을 바탕으로 NFT나 P2E 등이 발전하였다. (중앙 서버가 관리하는 것이 아닌 분산된 다양한 노드에서 관리되어 유저들이 소유권 확립 가능)
DAO 또한 탈중앙화조직에 따라 스마트 컨트랙트에 따라 본인이 기여한 만큼 받아갈 수 있고, 글로벌 인력이나 유휴지적자산 활용을 극대화 할 수 있다는 측면에서 주목할 만하다. (높은 환금성이 장점)

결국, 이더리움의 등장이 스마트컨트랙트 시대의 도래와 다양한 DApp의 등장을 이끌었다고 볼 수 있다.

이는 ICO, DeFi, NFT, P2E, DAO 등 다양한 서비스 및 유틸리티를 창출해 냈으며, 블록체인을 활용한 다양한 어플리케이션 및 활용 가능성을 기대하게 만들어준 것이다.

1-3. 스마트컨트랙트 구조

1세대 블록체인 비트코인에서는 스마트 컨트랙트 배포가 불가능한가?

사실 스마트컨트랙트가 1세대 블록체인인 비트코인에서 배포 및 이행이 불가능한 것이 아니다. 단지 이더리움에 비해 낮은 수준의 스마트 컨트랙트 기능 구현이 가능할 뿐이다.

그렇다면 왜 이더리움이 스마트 컨트랙트를 구현하기에 더 용이한 환경일까? 이를 살펴보기 위해서는 UTXO와 계좌잔고 모델에 대한 이해가 필요하다고 생각된다.

간단하게 비교해보는 UTXO vs 계좌잔고 모델

비트코인에서 사용하고 있는 거래의 기본단위는 UTXO(Unspent Transaction Outputs)이다. 영어에서 알 수 있듯이 Unspent(아직 사용되지 않은)한 거래 결과값들을 잔고로 기록한 구조이다. 즉, 하나의 잔고값으로 기록되는 것이 아닌 여러개의 UTXO가 모여서 기록되어 있는 구조이다.

UTXO의 가장 중요한 특징 중 하나는 일회성이다. 한 번 사용되고 나면 사라지기 때문에 익명성과 보안성이 강하다는 점이 장점이다. 다만, UTXO가 매번 형성될 때마다, 수수료가 부과되기 때문에 수수료 측면에서는 불리하다.

또한, 비트코인도 스마트 Script가 존재하여 스마트 컨트랙트 배포가 가능하며, Virtual Machine을 통해 스마트 컨트랙트 수행 및 상태값 변화가 나타난다. 다만, 비트코인에 구현된 Script(스택 베이스의 코드이며 튜링 완전하지 않음)와 UTXO 모델 등은 보안성을 고려하여 송금과 기록 기능에 최적화 되어 있는 환경이며, 여러 한계점으로 인해 그 이상 고도의 기능을 수행하기에는 부족한 환경이다.

이유는 이더리움 백서에 따르면, 1)튜링 불완전성, 2)가치 무지, 3)상태표현 제한, 4)블록체인 무지 등으로 한계점을 설명한다.

각각 대략적으로 풀어 설명해보면, 1)반복문 사용의 불가, 2)UTXO 스크립트만으로 인출 액수 정밀하게 통제 불가, 3)다중계약이나 다중 스크립트 만드는 과정이 어려우며, 4)UTXO가 Nonce, 타임스탬프, 이전 블록해쉬 등의 온체인에 기록된 자료를 읽어오지 못한다는 점으로 해석 가능하다.

계좌잔고 모델: EOA와 CA로 구성된 이더리움 계좌 모델

그렇다면 계좌잔고 모델은 어떨까? 이더리움의 EOA(Externally Owned Account)와 CA(Contract Account) 구조를 살펴보면 이해가 용이하다.

EOA(Externally Owned Account)는 외부 소유 계좌로 개인 키에 의해 통제되는 계정 정보로 사용자 지갑으로 이해하시면 용이하다.
일반적인 계정 유형, 계정의 주소 통제할 수 있는 개인키가 존재하는 점이 특징이며, EOA는 트랜잭션을 발생시키고, 이를 다른 EOA나 CA에 전송할 수 있다.

CA(Contract Account)는 외부 소유 계정과는 다르게 개인키가 없다.
CA는 스마트 컨트랙트 블록체인에 배포할 때 생성되며, 스마트 컨트랙트 코드를 Bytecode 형태로 담고 있다. EOA와 마찬가지로 이더 송수신 가능하며 다른 컨트랙트나 EOA의 호출 통해 트랜잭션 발생시킬 수 있다. CA에는 개인키가 없으므로 직접 트랜잭션 발생시킬 수 없다. 따라서 EOA가 발생시킨 트랜잭션을 전송받고, 해당 트랜잭션의 메시지가 조건 충족한다면 컨트랙트 코드가 실행되어 특정 Action이 발생되게 된다.

이더리움의 EOA는 비트코인의 UTXO와 달리, 잔액만 보여진다. EOA 자체는 현실 세계의 은행 계좌와 비슷한 구조로 이해 가능하다. 차별점은 CA 구조가 추가로 존재하여, 다양한 제약 조건을 설정한 스마트컨트랙트를 바이트코드형태로 배포 가능하다. (조금 더 자세한 내용이 궁금하시다면, 쟁글 기존 레포트를 참고)

그렇다면 스마트컨트랙트의 작동 방식은 어떻게 이루어질까?

EOA를 통해 나타날 수 있는 케이스는 아래 3가지이며, EOA로부터 모든 상태 변화가 시작된다.

• EOA→EOA
• EOA→CA
• EOA→CA→CA

간단한 작동방식을 살펴보면, (Tujac.com 참고) 아래와 같다.

• 1/ 스마트 컨트랙트로 구현하고자 하는 내용을 Solidity 등의 언어로 프로그래밍
• 2/ 코드를 컴파일하여 네트워크에 배포할 수 있는 Bytecode(컴퓨터 언어)형태를 생성함
• 3/ Transaction에 Bytecode를 담고, 마이너가 해당 Transaction이 담긴 블록을 채굴 →이와 동시에 transaction은 블록체인 네트워크에 기록됨
• 4/ 유저는 ABI(Application Binary Interface)를 통해 배포된 스마트컨트랙트 코드에 정의된 함수를 호출하는 Bytecode를 생성하고, Transaction에 담아 블록체인 네트워크에 전달
• 5/ 채굴자는 유저로부터 받은 Bytecode를 배포된 스마트컨트랙트 코드에 따라 EVM 위에서 실행함. 이 때, Gas Fee가 계산되면서 블록에 추가되고, 실행결과가 유효한 경우 실행 결과가 state에 반영됨

스마트컨트랙트 언어

스마트 컨트랙트 언어에도 다양한 존재가 있다. 블록체인에는 바이트코드 형태로 보이지만, VM이 읽기 위해 변환시킨 형태로, 그 이전단의 언어들은 블록체인별로 상이하다.

대표적인 언어로 Solidity, Vyper, Rust, Ride, Cairo 등이 존재한다. 최근에는 Aptos와 Sui 등이 등장하며 Move라는 언어도 새롭게 내세우고 있다. 스마트 컨트랙트의 원조인 이더리움의 경우 현재 Solidity와 Vyper 언어를 사용하고 있다.

대표적인 2가지 언어인 Solidity와 Rust를 살펴보면, 활용처는 아래와 같다.

Solidity: Ethereum, Tendermint, BSC, Ethereum Classic, Tron, AVAX, Counterparty, Hedera
Rust: 솔라나, 폴카닷, 니어

체인의 성공 조건 중 하나로 EVM 호환성(EVM Compatibility)이 중요하다는 이야기를 많이 들어 보았을 것이라 생각한다. 실제로 많은 체인들이 ‘EVM 호환성’을 강점으로 내세우고 있다.

EVM(Ethreum Virtual Machine)은 말 그대로 이더리움에서 사용하는 스마트컨트랙트 언어인 Solidity와 Vyper로 작성이 된 스마트 컨트랙트를 확인할 수 있다는 점이다.

EVM 호환성은 이더리움의 강력한 개발자, 생태계 환경을 활용 가능하기 때문에 장점이 분명하다.

• 1/ 이더리움 코드 및 인프라 접근 용이 (이더리움 생태계가 이미 구축한 코드와 인프라 활용 가능)
• 2/ DApp 마이그레이션의 용이

결국 개발자단에서 상당한 시간과 비용이 절약된 채, 코드를 처음부터 작성하지 않고도 체인에 프로토콜을 쉽고 빠르게 배포 가능할 수 있게 되는 것이다.

다만, 단점으로는 비EVM 호환 체인 대비 혁신이 상대적으로 부족하다는 점이다. 특히 이더리움에 쓰이는 스마트컨트랙트 언어의 경우 상대적으로 초창기에 나온 언어인 만큼, 유연성이 좋은 대신 취약점이 자주 등장한다는 단점 등도 지속 제기되고 있다.

1-4. 스마트컨트랙트 관련 밸류체인 정리

스마트컨트랙트 관련 밸류체인을 정리해보면, 아래와 같다

스마트컨트랙트 Audit
대표적으로 Certik, Slowmist, SmartDec, Zeppelin 등이 존재하며, 스마트 컨트랙트 관련 취약점을 사전에 Audit하는 역할을 수행한다.

보험(Insurance)
대표적으로 Nexus Mutual, Insrace, Unslashed가 존재하며, 사후적으로 스마트 컨트랙트 해킹에 대한 보상을 제공해주는 보험 프로토콜이다.

버그 바운티 플랫폼
대표적으로 ImmuneFi, Code4rena, PatchDay가 존재하며, 화이트햇 해커 모집부터 보고서 관리, 보상 지급까지 복잡한 버그바운티 운영 등을 가능하게 해준다.

DApps (Decentralized Applications)
디앱으로, 스마트 컨트랙트를 활용한 다양한 어플리케이션이다. 대표적으로 NFT, P2E, DeFi, DAO 등이 활용이 많이 되고 있다.

오라클 (Oralce)
블록체인(온체인)과 외부(오프체인) 사이를 연결하는 별도의 미들웨어 인프라로써 기능한다.
대표적으로 Chainlink, API3, Band Protocol 등이 존재한다.

1-5. 스마트 컨트랙트의 한계점

스마트 컨트랙트의 한계점 또한 존재한다.

• 1/ 스마트 컨트랙트는 배포된 이후에 내용을 수정할 수 없다는 점이다.
• 2/ 현실세계의 이벤트나 가격 등 오프체인 데이터를 가져와야할 경우, 오라클 등 제 3자에 의존이 필요하다.

이러한 한계점으로 인해서 스마트 컨트랙트 내 취약점이 존재하고 이러한 취약점을 파고들어, 해킹이나 탈취 사태 등이 발생하곤 한다.

2. 취약점을 활용한 다양한 해킹 사례

스마트 컨트랙트에는 위에서 언급한 한계점으로 인해 취약점을 파고든 해킹사례를 살펴볼 필요가 있다. 대부분이 사실 DeFi 관련 해킹이며, 스마트 컨트랙트 외 다양한 해킹 사례들도 존재한다.

Certik에 따르면, 22년 1Q와 2Q를 합쳐서 이미 $2B을 초과하는 해킹과 탈취 사태가 존재하였다고 한다. 21년의 경우에는 약 44개의 DeFi 관련 해킹 사례가 있었으며 피해 금액은 $1.3B 수준이었다. 이미 22년 상반기 내 작년 피해금액을 초과할 만큼 피해규모는 지속 커지고 있다.

2Q22에는 약 $745M 수준의 피해가 있었다 (해킹, 스캠, 탈취 등 포함). 대부분의 피해가 소셜 미디어를 활용하였으며, 프로젝트의 Discord 서버, 텔레그램이 대표적으로 활용되었다고 한다.

우선, 스마트컨트랙트 취약점을 활용한 대표적인 사례는 1)플래시론, 2)크로스체인 브릿지 해킹 사례 등이 존재하며, 스마트 컨트랙트 외로도 러그풀이나 Multi-Sig 구조에서 Privtate Key 탈취 등을 통한 피해 사례들이 존재한다.

그럼, 간단하게 정의와 대표적인 사례 및 현황을 살펴보기로 하겠다.

2-1. 스마트 컨트랙트 관련 해킹 사례

플래시론

플래시론이란 블록체인의 블록 1개가 만들어지는 매우 짧은 시간 안에 무담보로 대출을 받고 상환하는 거래를 의미한다. 한 블록 안에서 대출하고 상환 동시에 하는 행위인 것이다.

보통 플래시론을 지원하는 프로토콜을 활용해서 취약점이 존재하는 동일 또는 타 프로토콜 내 공격을 일으키는 것을 의미한다. 플래시론 구조의 허점을 파고든 사례가 많다. 대부분 오라클이나 거버넌스를 이용한 공격이 많다.

플래시론이 일어나는 구조를 간단히 살펴보면, 암호화폐를 빌릴 때 보통 담보를 설정하게 되는데, 일시적으로 담보의 가치를 조작하여 실제 담보의 가치보다 더 많은 대출을 받고→대출을 바로 상환하여 그 차익만큼의 이익을 공격자가 탈취해 가는 구조이다.

대표적인 사례는 Beanstalk Farms, Fei Protocol, DEUS Finance2 등이 있으며,  최근에는 솔라나 기반 DeFi Nirvana Finance에서 또한 발생하였다 (약 $3.5M)

대표적으로 Cream Finance 사례를 살펴보자 (21년 10월, $130M 규모 피해)

담보물 가격을 조작하여 실제 담보금 가치 1.5배 수준 부풀려서, 부풀려진 담보금 바탕으로 Cream Finance 모든 자산을 대출한 구조이다. 해커가 MakerDAO에서 DAI를 대출받아, 많은 양의 yUSD 토큰을 발행하는 동시에 멀티 자산 유동성풀(yDAI, yUSDC, yUSDm 및 yTUSD) 포함)을 조작하여 yUSD 가격에 대간 오라클 활용을 악용한 사례이다.
(자세한 내용은 Xangle에서 발행한 공시내역 및 Cream Finance Medium을 참고)

Certik에 따르면 2Q22에 발생한 Top10 사례는 아래와 같다. 플래시론으로 인한 피해금액은 2Q22에만 $308M 수준이며 약 27개의 플래시론 공격이 존재하였다고 한다.

크로스체인 브릿지 해킹 사례

보통 크로스체인 브릿지 해킹사례는 스마트컨트랙트 취약점을 파고든 사례가 대부분이며, 로닌 브릿지나 Harmony Bridge와 같이 스마트컨트랙트 허점으로 인한 해킹이 아닌, Private Key를 탈취하여 해킹이 발생한 사례도 존재한다.

크로스체인 브릿지 자체는 DA레이어가 다른 블록체인끼리 연결되어 있는 구조이기 때문에, 담보자산이 브릿지에 묶여있을 경우 구조적으로 자금 갈취의 리스크가 상당히 높다. 크로스체인 브릿지 해킹 사례는 1)웜홀 브릿지, 2)Multichain, 3)Q 브릿지 사례가 대표적이다.

대표적으로 웜홀 브릿지 사례를 살펴보자. (해킹규모 $320k ETH/$325M)

웜홀 매커니즘에는 크로스체인 트랜잭션을 Guardian이라는 존재들이 검증(Verifiable Action Approval)하여 실행하는 구조이다. 약 12만개의 SOL-wETH가 담보 없이 발행되는 사고가 터졌으며, 웜홀 팀의 발 빠른 수습으로 인해 다행히 모든 자금 회수하였었다.

자세한 내용은 쟁글에서 작성한 ‘웜홀 해킹 사례를 통해 바라본 크로스체인 구조의 문제점’을 살펴보기를 바란다.

해당 부분 대부분이 사실 Certik에서 이야기하는 ‘Major Exploits’에 포함된다. 다만 여기에는 코드의 취약점 활용한 해킹사례를 비롯하여 오라클 및 Multi-sig 구조 내 private key 탈취 등의 사례가 포함되어 있다는 점은 감안할 필요가 있다.

2-2. 스마트 컨트랙트 외 해킹 및 탈취 사례

Multi-Sig 구조 하 Private Key 탈취 통한 해킹, 러그풀(Rug-Pull) 등

사실 스마트컨트랙트에 의한 해킹 사례 외에도 다양한 크립토 생태계 내 해킹 등이 많이 발생하고 있다. 러그풀, 또는 로닌 브릿지 해킹 사태와 같은 사례가 대표적이다. 엄밀히 말하면 스마트컨트랙트와 관련성이 있지만 매우 높지는 않다고 판단하여, 필자는 '스마트 컨트랙트 이외 해킹 및 탈취 사례'로 정리하였다.

Multi-Sig 구조 하 Private Key 탈취 통한 해킹

대표적으로 로닌 브릿지 사례를 살펴보자. (해킹규모 $568m in ETH & USDC)

로닌 네트워크는 이더리움 사이드체인으로, 독립적인 합의 알고리즘을 확보하고 있었다.

9개의 노드가 존재하며 이 중 5개 노드가 합의 성공하면 트랜잭션이 승인되는 구조였는데, 9개 중 4개는 Sky Mavis측의 소유였다 (나머지 4개는 Axie DAO 구성원들에게 분배)

21년 11월경, 과도한 트래픽 이슈로 인해서 속도를 높이기 위해, Sky Mavis측이 Axie DAO로부터 노드 1개를 위임받아 자신의 시스템에 등록하였었다.

결국, 5개 노드를 차지하여 중앙화된 Sky Mavis 노드에 의해서 대부분 트랜잭션 검증되는 상황이었다. 이후 다시 분산화된 구조로 되돌렸지만, 이슈는 백도어 통해 통신하던 노드가 Sky Mavis측에서 삭제되지 않은 상태였던 점이다.

이후, 해커가 Sky Mavis측 서버 침투하여 관리키 4개 확보한 이후, 백도어 통해서 추가로 한 개의 노드 합의 이끌어내기 위한 노드를 확보해서 총 5개의 검증 노드를 확보하였다.

이미 과반을 확보한 해커는 트랜잭션들을 컨펌시켜 엑시 인피니티 자산들을 빼낸 것이다.

러그풀

러그풀의 경우도 피해금액의 상당 부분 차지하는 Scam 사례이다.

러그풀(Rug pull)이란 양탄자를 잡아당겨 사람들을 넘어뜨린다는 비유적 표현으로, Crypto 시장에서 개발자가 프로젝트를 중단하고 투자금을 가로채는 등의 ‘투자 회수 사기’를 주로 의미한다.

대표적으로 오징어 게임을 모티브로 한 오징어 코인 (Squid) 사기가 존재한다. 
21/10/26 패케이크 스왑에 상장하였으며, 개발자들은 오징어 게임 온라인 대회를 열 것이며 참가비에 사용 가능하다며 적극 홍보를 시작하였다. 넷플릭스의 오징어 게임과 마찬가지로, 6가지 놀이를 정한 뒤 진행해 최종 우승자에게 코인 참가비의 90%를 상금으로 지급하겠다고 이야기하다.
출시 직후 코인은 0.01달러에서 출발해, 2,860달러까지 오르는 등의 기염을 토했다.
그러나 약 1주일 뒤, 코인은 0원으로 폭락했다. 개발자들이 일시에 보유물량 매각하며 가격이 급락하게 된 것이다. 개발자들은 적어도 20억원 이상의 코인을 현금화 해 달아났을 것으로 추정된다.

러그풀은 직접적인 코드와 연결되어 있지는 않지만, 스마트 컨트랙트 검수가 완벽히 되지 않은 상태에서 보통 많은 개발자들이 코드에 대한 감사 없이 프로젝트를 배포한다는 점이 특징이다.

아래 테이블은 Certik에서 발표한 2Q22 Top 10 러그풀 사례이다. 약 $37.7M 수준의 피해금액이 나왔으며 89개의 러그풀 사례가 2Q22에 존재하였다고 한다.

2-3. 디파이 해킹이 많은 이유 

디파이에 해킹이 많은 이유는 아래와 같이 정리 가능하다.

• DeFi 시장 규모 자체가 상당히 크며, Cost 대비 Return이 좋은 구조
• 오프체인 데이터 의존이 많다 (오라클)
• 코드변경이 활발하게 이루어지기 때문에, 취약점이 존재할 경우가 많음
• 익명성으로 인해, 해킹 사태 이후 조사가 어려움
• 현금화가 매우 용이하며 각종 규제로부터 상대적으로 자유로움

3. 스마트 컨트랙트 관련 해킹 방지방안

3-1 신뢰도와 직결된 만큼, 프로토콜 차원에서 해킹 방지를 위한 방안 마련 필요

일단 프로토콜 내 취약점으로 큰 해킹이 나타나게 되면, 프로토콜 신뢰도를 잃게 된다.
DeFi 프로젝트의 경우에는 고객 자산이 탈취되는 현상 등으로 문제가 더 심각하다.
블록체인의 특성 상, Roll-back (되돌리기) 현상은 불가능에 가까우며, 이더리움 클래식/이더리움처럼 규모 자체가 너무 클 경우에는 누군가 나와서 구제해야 하는 케이스도 존재한다.

대표적으로 웜홀 브릿지의 경우 해킹 이후에 백커가 보상해주었지만, 신뢰도는 많이 무너진 상황이다. 또한 이번에 Harmony에서도 브릿지 (Harmony측이 만듦) 해킹이 또 일어났으며 구제 방식으로 Proposal (신규 ONE 토큰 발행 통한 피해자 구제) 등이 제안 되었지만, 이미 많은 투자자 신뢰를 잃은 상황이라고 생각된다. 파운더가 직접 나와 새로운 Proposal을 암시하였지만, 커뮤니티 반응이 어떻게 나올지는 지켜봐야 할 것이다.

그렇다면 이러한 사태를 방지할 수 있는 방법은 어떤 것이 있을까?

물론 100% 방지는 어렵지만, 아래와 같은 방식으로 피해 규모나 다양한 취약점들을 사전적으로 모니터링 및 발견, 또는 사후적으로 피해 보상을 일부 받는 구조 등으로 피해 규모를 최소화 시킬 수 있다고 생각한다.

필자는 사전 방지 방안과 사후 방지 방안을 간단하게 설명해보고자 한다.

3-2 사전 방지 방안

대표적으로 사전 방지 방안으로는 크게 3가지가 존재한다.

• 1/ 버그 바운티
• 2/ 스마트 컨트랙트 Audit
• 3/ 온체인 모니터링

1/ 버그바운티

버그바운티란 기업의 서비스나 제품 등을 해킹해 취약점을 발견한 화이트 해커에게 포상금을 지급하는 제도이다. 다양한 빅테크 기업에서도 진행 중이며, 최근 다양한 Web3 프로젝트에서도 진행하며 실제로 사전적으로 취약점들을 모니터링 및 예방한 사례들도 지속 등장하고 있다.

다만, 불분명한 신원에게 프로젝트 공개해야 하는 위험성이 존재하기에, 보통 Security Audit(보안 검수)가 선행되어야 하는 경우가 많다. 대표적인 플랫폼으로는 Immunefi, Code4rena, PatchDay 등이 존재한다.

2/ 스마트 컨트랙트 Audit

스마트 컨트랙트 보안감사(Audit)란 스마트컨트랙트 코드상에 존재하는 보안 취약점을 검출하고, 코드가 의도대로 잘 수행되며 작성되었는지를 분석하는 것이다.

스마트 컨트랙트 특성상, 한 번 배포되면 수정이 불가능하다. 따라서 배포 이후 큰 취약점이 발견될 경우, 새롭게 다른 스마트 컨트랙트 재배포해야 하는 경우가 생기게 된다. 이 경우에는 적은 Audit 비용을 아끼려다가 더 큰 비용이 초래되곤 한다.

결국, 정상적이고 중장기적인 프로젝트 운영 계획이 있다면, 대부분의 프로젝트들은 스마트컨트랙트 Audit을 받는 경우가 많다.

대표적인 스마트 컨트랙트 Audit 업체로는 Certik, Slowmist, SmartDec, Zeppline, 해치랩스, Solidfied 등이 존재한다.

3/온체인 모니터링

지속적인 온체인 모니터링을 통해 공격 시도를 탐지하는 방법이다.

보통 공격자들의 공격 패턴은 상대적으로 비슷한 양상을 보인다. 이를 통해 공격자들의 공격 패턴을 학습하여 사전에 공격 시도 탐지를 하는 방식이다.

공격자들의 공격 패턴은 1)실제 공격 진행하기 이전, 공격 수행하는 스마트컨트랙트를 메인넷에 배포한다, 2)배포된 Version을 Fork한 로컬 노드에서 테스트를 진행한다→3)실제 공격을 수행한다.

2번과 3번 과정에서 Time-Delay가 발생하는데, 이 때 배포된 컨트랙트 Static Anaylsis를 수행하여 빠르게 탐지하는 방법이다. 탐지 이후에는, 프르토콜 자체를 일시정지 시켜 수정해서 배포하는 방식 등이 적용 가능하다.

대표적인 플랫폼으로 블록섹(BlockSec) 등이 존재한다.

3-3. 사후 방지 방안: 보험 프로토콜

사후적으로는 보험 프로토콜을 활용하는 방안이 존재한다.

보험 프로토콜의 경우 대표적으로 Nexus Mutual, Insurace, Unslashed 등을 들 수 있다.

대표적으로 Nexus Mutual에 대해 간단히 살펴보겠다.

Nexus Mutual의 경우에는 KYC를 통해 구성원이 되어야 해당 프로토콜에 참여가 가능하다. (한국인은 참여 불가)

크게 3가지 역할이 존재하며; 보험 구매자(Cover Buyer), 리스크 심사자(Risk Assessor), 그리고 청구 심사자(Claim asseosrs)이다.

보험 구매자: 프로토콜을 통하여 특정 프로젝트에서 발생하는 여러 Risk에 대한 보험을 구매하는 주체. 해당 프로젝트에서 손실이 발생했을 경우, 청구 심사를 통해 보장 금액 내에서 환급 가능한 구조이다.

리스크 심사자: 주로 코드 검수 전문가나 관련 인물들로, ‘해당 프로젝트에 리스크가 제한된다’라고 생각하고 금액을 넣는 주체이다. 리스크 심사자들은 해당 프로젝트 보험 상품에 일정량의 NXM을 스테이킹하고, 해당 프로토콜의 안정성을 보증하는 주체인 것이다. 실제 손실이 발생하여, 청구 심사가 일어나게 되면, 청구 금액에 따라 스테이킹한 NXM이 소각되는 구조이다. 반면, 보험 상품의 구매가 이뤄질 경우에 보험 프리미엄의 50%를 보상으로 받는다.

청구 심사자: 보험 구매자들이 환급 청구 (손실 이벤트가 발생)할 경우 심사하는 역할을 수행한다. 보험 구매자들이 제출한 정보에 따라 해당 청구가 기준에 만족하는지 여부를 판단한 이후, 환급에 찬성여부를 투표한다. 청구 심사자가 되기 위해서는 일정량의 NXM 토큰을 스테이킹 해야하고, 합의된 결과와 동일하게 투표하였을 때 일정량의 보상을 받고, 소수의 위치로 투표 시에는 스테이킹된 NXM이 소각되는 구조이다.

이 경우에도, 리스크나 한계점은 명확하게 존재한다.

1/ 모든 프로토콜 관련된 리스크를 구매할 수 있는 옵션이 존재하지 않는다. 결국 참가자들이 충분한 커버리지 Capacity가 갖춰진 옵션에서만 구매나 Claim이 가능하다

2/ 손실이 발생한 이후, 보험 청구 시에 청구 심사자들의 투표를 통해 지급 여부를 결정한다. 다만, 리스크 심사자들의 스테이킹된 NXM 소각을 막기 위해 다수의 위치에 이해관계가 존재하며, 언제나 Claim을 하지 않는 편이 프로토콜의 수익 측면에서는 유리(보상을 안해주는 구조)하다고 판단할 우려가 존재한다. (물론, 장기적으로는 신뢰도를 잃게 되는 구조이다).

결론적으로, 사전 또는 사후적 방안으로 대안들은 존재하나 여전히 완벽하게 예방이 가능하지는 않다. 다만, 확률적으로 프로토콜을 좀 더 안전하고 장기적으로 운영 및 성장시키기 위한 방안으로써 늘 고려해야 할 수단이라는 판단이다.

마지막으로, 투자자와 개발자 입장에서 어떻게 스마트 컨트랙트 관련된 해킹이나 탈취 사례에서 좀 더 안전하게 본인들을 지켜 나갈 수 있을 지에 대한 필자의 의견을 이야기 해보겠다.

3-4. 생태계 참여 주체별 유의할 점 

투자자 입장

투자자 입장에서는 프로젝트의 버그 바운티 및 Audit 관련해서 지속 확인해 나갈 필요가 있다.
정상적으로 Audit 진행했는지 (많은 개발자들이 코드에 대한 감사 없이 배포, 감사에는 적지 않은 비용 들어가지만 장기간 프로젝트 이어갈 팀은 이를 필수 비용으로 간주), 다양한 버그 바운티 프로그램을 운영하고 있는지 등을 통해 간접적으로 프로젝트의 신뢰도나 프로토콜 안정성에 대한 추구 정도를 어느정도 확인 할 수 있다고 생각한다.
특히나 DeFi 관련 프로젝트 토큰의 경우에는, 유동성이 충분하지 않다고 생각되는 토큰에 대해서 높은 비율의 담보 대출은 위험하다는 점을 인지할 필요가 있다. 신뢰도 높은 오라클이 관련 토큰 지원을 하지 않을 가능성이 크며, 그 경우 오프체인 데이터와의 차이를 이용한 취약점에 노출되기 용이하기 때문이다.
추가로, 러그풀이나 다른 탈취 사례 등 방지를 위해서도, 창립자와 프로젝트 팀 이력을 꼼꼼하게 조사할 필요가 있다.
정상적인 팀이라면 보유물량 의무보유하도록 강제하는 락업 조치 등이 존재할 것이다.
또한 소셜미디어에서도 규모에 비해 소통 활성화 정도 파악, 참여 계정이 비정상적 활동 하고 있는지 등의 여부 확인을 통해서 프로젝트의 건전성도 유추해볼 수 있다.

개발자 및 서비스 운영자 입장

개발자 및 서비스 운영자 입장에서는 사전적 예방 방지를 위한 대안들을 최대한 많이 도입하는 것이 바람직할 것이라 생각한다.
사전에 비용을 절약하기 위해 Audit이나 버그 바운티 등을 최소화하는 전략보다는, 중장기적 방향성을 가지고 다양한 버그 바운티 및 Audit 과정을 거치는 것이 투자자 신뢰 확보와 중장기적 성장을 위해 바람직할 것이라 판단한다. 특히나, DeFi 프로젝트의 경우 많은 투자자의 돈이 관련되기 때문에, 신뢰도 이슈가 중요한 만큼, ‘소 잃고 외양간 고치기’ 전략보다는 사전에 조금 더 투자해서 신뢰도를 확보해 나가는 전략이 바람직할 것이다.
스마트 컨트랙트의 경우에도 반드시 깃허브에도 올린 뒤, Explorer상의 Bytecode 조회 외에도 검증 과정을 거친 Solidity 소스 코드 등을 조회할 수 있도록 하는 방향을 추구해야 할 것이다. 참여자 입장에서도 Github와 익스플로러상 Bytecode를 비교해가며 일치 여부를 판단하는 수고를 덜고, 좀 더 신뢰도 있게 검증할 수 있을 것이라고 판단한다.

4.마무리 하며…

지속 성장하는 크립토 시장 속 건전한 프로토콜 등장을 기대

결론적으로, 크립토 시장이 지속 성장하면서, 스마트 컨트랙트나 프로토콜 내 취약점들을 찾아 공격 자체는 꾸준히 계속 증가해 나갈 것이다. 실제 Certik에 따르면, 22년 크립토 내 해킹 및 탈취 사례는 21년 대비 약 214% 수준 y-y 증가 가능성을 시사하고 있다.

투자자들과 개발자 및 서비스 운영자 등 많은 참여자들이 크립토 생태계의 건전한 성장을 위해 단기적인 시야보다는, 좀 더 장기적인 방향성을 추구해 나가며, 다양한 사전적 대응 방안 등을 적극 적용해 나가야한다고 생각한다.

또한 사후적인 대책 또한 조금 더 적극적으로 마련될 필요가 있다. 현재 크립토 생태계는 코드만으로 완전하고 완벽하게 통제되기에는 부족한 점이 존재한다. 늘 취약점이 존재할 수 있다는 점을 인지해야 할 것이다. 탈중앙성을 빌미로 익명성에 기댄 해킹과 탈취에 집중하지 않고, 애초에 중개자를 없애는 확실한 Benefit을 위해 등장했던 ‘스마트 컨트랙트’ 취지에 맞춰 다양한 보상 방안과 거버넌스가 개선되어 나간다면, 조금 더 건전하고 안정적인 크립토 생태계가 형성되어 나갈 것이라고 감히 기대해 본다.