ERC20 토큰의 관리 권한을 바로잡을 수는 없을까? (with 취약점)

“zk Capital에서 보내주는 주간 메일(This Week in Blockchain Research Issue #119)에서 하나를 골라 읽어보았다.”

이 글은 2021년 7월 17일 arXiv에 올라온 ‘Rectifying Administrated ERC20 Tokens [1]’ 논문에 관한 내용을 다룬다.

현재 수백만개의 이더리움 스마트 컨트랙트를 통해 수천억 달러에 달하는 자산이 운용되고 있다. 그 중에서도 ERC20 토큰은 이더리움에서 가장 많이 쓰이고 있는 스마트 컨트랙트 유형이다.

이더리움에는 Externally Owned Accounts (EOAs)와 Contract Accounts (CAs), 이 두 가지 유형의 계정이 존재한다.

1. EOA의 경우 연결된 private key로 제어하며, 다른 EOA나 CA에게 메시지를 보낼 수 있다. 하지만 사용자가 지정한 코드를 실행할 수는 없다.
2. CA의 경우 사용자가 지정한 코드를 실행할 수는 있지만 owner를 결정하기 위한 private key를 가지진 않는다.

EOA 컨트랙트는 개발자에 의해 배포가 되는데, 이 안에 소유권, 역할 기반의 접근 제어 및 기타 특수 권한에 대한 내용을 수동으로 정의한다. 논문에서는 수많은 스마트 컨트랙트가 OpenZeppelin Contracts 라이브러리의 여러 루틴을 이용하여 위와 같은 내용들을 정의하고 있다고 한다.

최근 연구 자료[2]에 따르면 약 580만 개의 스마트 컨트랙트 중 적어도 210만 개 이상이 OpenZeppelin Contracts 라이브러리의 onlyOwner 함수 변경자(modifier)를 사용하고 있으며, 이는 특정한 유저(ex. owner)만이 함수 변경자로 구현된 스마트 컨트랙트 함수를 호출할 수 있도록 한다.

그림 1. 이더리움 스마트 컨트랙트 유형에 대한 벤 다이어그램

논문에서는 이더리움 스마트 컨트랙트의 서로 다른 부분 집합 관계를 [그림 1]과 같이 표현하고 있으며, 쉽게 두 가지 분류로 구분하고 있다.

1. Administrated Contracts: Contract owner가 마음만 먹으면 문제를 일으킬만한 가능성이 있는 코드를 포함하고 있는 경우
2. Effectively Ungoverned Contracts: 1번과 반대의 경우

Existing Problems

문제는 이 administrated contracts 상에 있는 ERC20 토큰의 코드 중 중앙화 이슈를 만들 수 있는 패턴이 존재한다는 것이다. 논문에서 정의한 5가지 중앙화 패턴에 대한 내용은 다음과 같다.

1. Self-destruction (스마트 컨트랙트 파괴)
2. Deprecation (사라지게 될 컨트랙트로 정의)
3. Change of Address (특정 주소 변경)
4. Change of Parameters (특정 동작에 대한 매개변수 값 변경)
5. Minting and Burning (특정 주소에 대한 토큰 추가 발행 및 소각)

이 중 대표적으로 굵은 글씨로 되어 있는 두 가지를 보고자 한다. 그 중 첫 번째로 self-destruction 패턴을 보자.

그림 2. Self-destruction 코드

EVM의 SELFDESTRUCT opcode는 블록체인 상에서 해당 스마트 컨트랙트를 지울 수 있도록 한다. 이를 통해 개발자가 구현한 스마트 컨트랙트 상에 치명적인 문제가 있는 경우 해당 컨트랙트를 지우고 컨트랙트 상에 있는 이더리움 잔액을 전부 회수할 수 있다. 하지만 이를 contract owner 또는 공격자가 악용하여 실행하는 경우 해당 컨트랙트와 연결된 모든 사용자들의 자산을 한순간에 날려버릴 수 있기 때문에 이는 심각한 문제를 초래할 수 있다.

그림 3. Deprecation 코드

두 번째로 Deprecation의 경우를 보자.

스마트 컨트랙트의 경우 한 번 배포되면 수정할 수 없다는 특성으로 인해 결국 새로운 컨트랙트를 배포한 다음 사용자들이 해당 컨트랙트를 이용할 수 있도록 안내해야 한다. 그래서 이러한 경우 contract owner에 의해 기존의 코드는 더이상 사용하지 않을 것이라는 의미에서 ‘deprecated’를 선언하게 되는데, 문제는 대체할 함수 내용을 또 다른 것으로 우회하도록 하면 문제가 발생할 가능성이 있다는 것이다.

그 외, 각 Administrated ERC20이 가지는 중앙화 패턴에 대한 자세한 설명 및 여러가지 사례에 대한 내용이 궁금한 경우 논문을 참고하면 좋을 것 같다.

Solution

결국 위와 같은 문제들은 contract owner가 컨트랙트의 내용을 임의로 바꾸거나 악용할 가능성이 있다는 것을 나타내는 것 뿐만아니라 악용의 목적이 없더라도 private key를 취득하여 owner의 권한을 얻은 누군가에 의해 발생 가능함을 내포하고 있다. 이는 스마트 컨트랙트의 취약점과도 연결될 수 있음을 보여주고 있기 때문에 논문에서는 하나의 방법을 제시하여 이 문제를 최소화하고자 했다.

가장 먼저, 이더리움 메인넷에 있는 administrated ERC20 토큰들을 찾기 위해 패턴 인식 방식을 사용했다. 스마트 컨트랙트는 JSON(JavaScript Object Notation) 배열로 표현되는 몇 개의 파일로 구성되어 있는데, 모든 입력에 대해 필요 없는 부분(comments)은 지우고, 소스코드를 추출하는 전처리 작업을 진행하게 된다.

이더스캔(Etherscan)으로부터 약 110만 여개의 오픈된 스마트 컨트랙트 코드를 모아 이를 입력으로 하였고, 그 중 중복되는 형태의 코드를 삭제하여 총 8만여개의 고유한 소스코드를 얻었다.

그림 4. Administrated ERC20 토큰 분석 과정에 대한 흐름

[그림 4]는 이 흐름에 대한 내용을 담고 있는데, 이유는 모르지만 8만여개의 코드 중 385개만 랜덤으로 선택하여 직접 레이블링 작업을 한 후 각 코드와 일치하는 9-dimensional 특성 벡터를 추출하도록 하였다. 그런 다음 딥러닝 모델의 K-fold 방식을 이용해 서로 다른 9가지의 분류자(classifier) 모델을 평가하고 그 중에 정확도가 가장 높은 SVC(Support Vector Classifier)를 선택하였다.

K-fold 방식은 하나의 training set을 K개의 fold(겹)로 나누어 training할 데이터와 test할 데이터를 교차 검증하는 방법이다. 자세한 내용은 [3]을 참고해보면 좋을 것 같다.

표 1. Classifiers 테스트 정확도

그 다음 385개의 레이블링된 표본을 가지고 SVC classifier를 트레이닝 시키고, 여기에 추출한 8만여개에 대한 특성 벡터를 대입해 어떤 컨트랙트가 administrated ERC20 형태를 가지는지 확인하였다.

논문에서는 9가지 syntactic signatures로 구분하여 administrated ERC20 토큰 가능성을 판단하였다. 이에 포함될 내용은 다음과 같다.

1. ERC20 Interface Implementation
2. Administrated Self-destruction Signature
3. Pausable Functionality Signature
4. Contract Deprecation Signature
5. Minting and Burning Signatures
6. Role-restricted Transfers and Withdrawals
7. Function-disabling Modifier
8. Direct Checks of Sender Address
9. Freezing, Halting or Killing Methods

일부 관련 내용에 대해서는 위에서도 설명했지만 전체적으로 쉽게 보자면 ERC20 토큰 안에 포함되는 코드 내용 중 스마트 컨트랙트 취약점을 일으킬 가능성이 있거나 contract owner가 특정 함수를 악용하여 사용하거나 변경하는 경우 문제를 일으킬 수 있기 때문에 이러한 내용들이 포함된 코드들을 분류한 것으로 볼 수 있다.

위에서 정의한 9가지 syntactic signatures에 대한 자세한 설명이 궁금한 경우 논문을 참고하면 좋을 것 같다.

그림 5. 8만여개의 스마트 컨트랙트 소스코드를 SVC classifier와 9가지 syntactic 특성을 이용해 처리한 결과

실제로 8만여개에 대한 스마트 컨트랙트를 분석해본 결과 administrated ERC20 토큰으로 분류되는 것들은 ERC20 토큰들 중 약 90%를 차지했고, 이는 잠재적인 중앙화 및 취약 문제 가능성을 나타내고 있다.

그래서 논문에서는 이러한 문제를 가진 토큰들이 Safely Administrated ERC20 코드가 될 수 있도록 contract owner가 ‘SafelyAdministrated’ 라이브러리를 통해 3가지 컨셉을 중점으로 보완할 필요성을 제기하고 있다.

표 2. SafelyAdministrated 라이브러리 상속 인자

SafelyAdministrated 라이브러리는 추상 클래스로 표현되어 있으며, 위에서 말한 3가지 컨셉은 다음과 같다.

1. Deferred Maintenance: 컨트랙트가 보완될 필요가 있을 때 유저에게 이를 알리고 점검하는 작업을 특정 시간이 지난 이후에 수행할 수 있도록 한다. 만일 유저가 이에 반대한다면 유저는 자신의 토큰을 파는 등의 방법을 통해 안전하게 나갈 수 있는 기회를 제공한다.
2. Contract Board of Trustees: 특정 유저(ex. administrator)가 관리 권한을 단독으로 누리고 있기 때문에 하나의 private key가 한 사람에게만 속해있는 것은 악의적인 목적이 없더라도 누군가에게 공격을 당한다면 문제가 발생할 가능성이 있다. 그렇기 때문에 이러한 토큰 관리 권한을 서로 다른 집단에서 여러 개의 private key로 관리할 수 있도록 하여 특정 함수 실행을 위해서는 합의하는 과정이 있어야 한다. 이를 통해 관리 권한을 여러 명에게 나눈다.
3. Safe Pause: 컨트랙트 상에서 취약점이 발견되었을 때 관리자는 관련된 트랜잭션 실행을 pause 하여 부당한 이용을 막을 수 있다. 하지만 무한한 시간동안 컨트랙트를 pause 시키는 행위를 방지하기 위해 특정 기한이 지나면 자동으로 pause를 중단하도록 하고, 한 번 이 과정을 마친 이후에는 일정 시간동안 다시 pause를 할 수 없도록 한다.

Conclusion

결과적으로 기존에 contract owner가 가지는 관리 권한을 추가적으로 분산하여 컨트랙트를 사용하는 일반 유저들이 피해를 보지 않는 방향으로 개선할 필요성이 있다는 것을 어필하고 있다. ERC20 토큰을 가지고 서비스를 진행하고 있는 개인 혹은 기업의 자체 거버넌스가 있더라도 스마트 컨트랙트 상에서 처리될 필요성을 제기하고 있는 것이다.

하지만 논문에서 제시한 90%의 ERC20 토큰 코드를 모두 이 라이브러리를 통해 개선하는 것은 비용적인 문제도 있을뿐더러 관리자들이 반드시 참여할 것이라는 보장도 없다.

하나의 개선 방안이 될 수는 있겠지만 완전한 탈중앙성을 보장할 수 없는 현재의 사회로 볼 때 효과가 있을지는 미지수라는 생각이 든다.

Reference

[1] ‘Rectifying Administrated ERC20 Tokens’, Nikolay I., et al., arXiv (2021). (https://arxiv.org/pdf/2107.10979.pdf)

[2] ‘An ever-evolving game: Evaluation of real-world attacks and defenses in ethereum ecosystem’, Zhou S., et al., 29th USENIX Security Symposium (USENIX Security 20). pp. 2793–2810 (2020).

[3] K-Fold Cross Validation(교차검증) 정의 및 설명, https://nonmeyet.tistory.com/entry/KFold-Cross-Validation%EA%B5%90%EC%B0%A8%EA%B2%80%EC%A6%9D-%EC%A0%95%EC%9D%98-%EB%B0%8F-%EC%84%A4%EB%AA%85