2025년이 끝나고 2026년 새해가 밝았습니다.  
매해 돌아보는 글을 써야겠다고 마음먹지만, 실제로 끝까지 쓰게 되는 경우는 많지 않았습니다. 되짚어보고 고민하는 일은 언제나 아프고 힘든 일이기도 하고, 그보다는 앞에 놓인 일들을 하기에도 바쁘다고 스스로를 합리화했기 때문입니다. 그렇게 정리정돈이 되지 않은 채로 한 해 한 해를 살아오다 보니, 작년은 유난히 정신없는 한 해가 되었던 것 같습니다. 미뤄둔 집청소를 하듯이, 보기 싫어서 밀어두었던 생각들을 한 번쯤은 꺼내놓아야 할 시점이 온 것 같았습니다. 2026년 새해에는 미루는 일 없이 살아보고자, 늦었지만 회고를 해 보았습니다.

연구자로서의 한 해

박사학위 졸업을 언제 해야 하는지에 대해 여러 교수님들께 여쭈어본 적이 있습니다. 어떤 교수님은 “지도교수가 꼴뵈기 싫어질 때”라고 하셨고, 또 어떤 교수님은 “지도교수의 판단을 믿어라”라고도 하셨던 것 같습니다. 저 개인적으로는 스스로 하나의 완결된 연구를 수행할 역량이 되었을 때, 그때 한 명의 독립된 연구자로 졸업해도 좋다고 생각합니다. 주제 선정부터 문제 정의, 해결 제안, 실험까지 모두 혼자 힘으로 감당할 수 있어야 한다고 믿습니다.

지도교수님의 우산 아래에서 비교적 따뜻한 나날을 보낸 지도 어느덧 7년 차가 되어갑니다. 언어모델의 태동기라는 운이 좋은 시기에, 좋은 지도교수님과 흥미로운 분야, 함께 공부할 좋은 동기들을 만난 것은 분명 큰 행운이었습니다. 다만 지도교수님의 첫 제자이다 보니, 주제 선정이나 문제 해결 과정에서 많은 도움을 받았던 것도 사실입니다. 주제 또한 교수님께서 제시해 주신 것들 중에서 선택하는 경우가 많았고, 그로 인해 “나는 어떤 연구를 하고 싶은가”라는 질문에 대해 충분히 고민하지 못했던 것 같습니다.

연구자에게 있어 “어떤 연구를 하고 싶은가”라는 질문은 결국 “어떤 삶을 살고 싶은가”라는 질문과 맞닿아 있다고 생각합니다. 저는 오랫동안 이 질문에 대해 “재미있다고 느끼는 것을 하는 삶”이라고 답해 왔습니다. 다만 2020년쯤 창업했던 회사의 매각을 진행하면서, 제가 스스로 정의한 삶의 기준을 제대로 지키지 못했다고 느꼈고, 그 이후로 해당 질문은 열린 채로 방황해 왔습니다. 최근에 와서야 여러 경로를 돌아 다시 “재미있다고 느끼는 것을 하는 삶”으로 회귀하고 있는 중입니다. 무엇이 재미있는지에 대한 정의는 여전히 열려 있고, 아직은 그때그때의 감각에 의존하고 있지만, 이를 조금씩 구체화하는 것 또한 장기적인 과제로 남겨두고 있습니다.

연구자로서의 2025년을 되돌아보면 “애매모호함에 대한 대가를 치른 해”였다고 생각합니다. 연구자는 본질적으로 자영업자에 가깝지만, 그 사실을 쉽게 망각하게 됩니다. 학생의 태도를 완전히 벗어나지 못하면, 연구의 방향에 대한 책임이 나에게 있다는 감각도 흐려집니다. 방향타를 쥐고 있다는 인식이 부족하다 보니, 자연스럽게 애매한 스탠스를 취하게 되었고, 원치 않는 방향으로 연구가 흘러가더라도 그저 함께 표류하게 되었습니다. 그 표류의 대가는 결국 연구의 주인인 제가 치렀다는 사실을 몸으로 배우는 한 해였습니다.

연구를 진행하면서 원인을 명확히 규정하지 않은 채 애매하게 넘어간 영역들에 대해서도 적지 않은 대가를 치렀습니다. 어떤 현상에 대해 “대체로 이런 이유일 것이다”라는 추측만 남겨둔 채 연구를 진행했다가, 이후 실제 원인이 밝혀지면서 연구 세팅을 처음부터 다시 해야 했던 적도 있었습니다. 그 과정에서 한 달 가까운 시간을 그대로 버려버린 경험도 있었습니다. 이러한 경험들을 통해, 연구를 함에 있어 저 자신의 스탠스와 연구 과정 모두에서 확실함을 가지고 임해야 한다는 사실을 뼈저리게 느꼈습니다.

엔지니어로서의 한 해

엔지니어로서의 역할 역시 단순히 한 사람의 개발자를 넘어서는 방향으로 변하고 있음을 느낀 한 해였습니다. 추상적인 설계뿐만 아니라, 사업적 관점에서의 일정 산정과 기대 효과, 전체 사업 구조에서 기술이 차지하는 위치까지 설명할 수 있어야 했고, 이상적인 설계와 현실적인 타협점 사이를 연결하는 역할도 요구받았습니다.

조직적인 측면에서도 이전과는 다른 역할을 맡게 되었습니다. 저는 본래 혼자 일하는 스타일에 가깝고, 소통에도 능숙한 편은 아닙니다. 일을 명확히 분리하고 각자가 맡은 일을 하는 방식을 가장 편하게 느껴왔습니다. 하지만 이제 대부분의 일은 혼자 감당하기에는 규모가 커졌고, 제가 설계한 일을 다른 사람들에게 나누고 관리하는 역량이 필요해졌습니다. “답답하면 내가 직접 한다”는 태도가 오히려 병목이 된다는 사실을 자주 마주하게 되었습니다.

소프트웨어 엔지니어로서의 2025년을 돌아보면, 목표 설정에 특히 고생했던 한 해였던 것 같습니다. 그 이유는 크게 두 가지였습니다. 하나는 저 스스로를 과대평가한 점이고, 다른 하나는 사업적인 맥락을 충분히 이해하려 하지 않았던 점입니다. 높은 집중력으로 밤낮없이 몰입하면 해낼 수 있을 것 같은 일정을 현실적인 일정이라고 착각하고 제안했던 경우가 많았고, 실제로는 목표를 완전히 달성하지 못하거나 아슬아슬하게 맞추는 경우가 반복되었습니다. 막상 일을 시작하고 나서야, 그 목표가 얼마나 큰 산이었는지를 깨닫고 전의를 상실하는 일도 잦았습니다.

사업적인 맥락을 충분히 이해하지 못한 점 역시 크게 작용했습니다. 제가 맡은 일이 사업 전체에서 얼마나 크리티컬한지 체감하기 어려운 부분도 있었고, 이를 이해하기 위해서는 사업을 운영하는 쪽과 긴밀하게 소통하며 시야를 맞추는 시간이 필요했습니다. 다만 회사가 물리적으로 멀어지면서 그러한 교감을 유지하는 것이 체력적으로 쉽지 않았던 것도 사실입니다. 이러한 경험을 통해, 추상적인 이상보다는 구체적인 산출물과 활용 방안을 기준으로 현실적인 목표를 설정하고 집중하는 것이 중요하다는 생각을 하게 되었습니다.

가족 구성원으로서의 한 해

2025년에는 누나의 결혼을 시작으로 아버지의 환갑, 어머니와의 여행, 저의 결혼, 아버지의 은퇴까지 가족과 관련된 굵직한 사건들이 연이어 발생했습니다. 이 과정을 통해 부모의 가족관과 저의 가족관이 꽤 다르다는 사실을 분명히 인식하게 되었습니다. 저는 가족이 법적·사회적으로 구성될 수 있고, 상황에 따라 해체될 수도 있는 관계라고 생각합니다. 특별한 관계이기는 하지만, 그렇다고 완전히 예외적인 인간관계라고 보지는 않습니다. 그렇기 때문에 기본적인 예의와 거리 조절이 중요하다고 느끼는 편입니다. 반면 부모에게 가족은 해체될 수 없는, 매우 천부적인 관계라는 믿음이 있는 듯했습니다.

결혼을 통해 새로운 가정을 꾸리는 과정은 생각보다 훨씬 복잡했습니다. 기존의 가족과 새로 형성된 가족 사이에서 부드러운 소통을 만들어가는 일은 쉽지 않았습니다. 부모는 저에 대한 기여에 대한 보상 심리를 가지고 있고, 그에 비해 제가 아내에게 더 많은 보상을 하려는 것에는 반발하는 감정을 보이기도 했습니다. 그로 인해 제가 아내에게 방어적으로 행동하게 되는 순간들이 있었고, 그러한 태도를 아내는 그대로 느끼며 상처를 받았습니다. 중간에서 이를 조율하는 역할은 생각보다 훨씬 어려웠습니다. 또한 부모는 제가 가정을 이루었으니 이제는 어른으로서 행동하기를 요구했고, 원하지 않던 어른들의 행사들에도 하나하나 대응해야 하는 상황이 늘어났습니다.

10년 가까이 떨어져 살면서, 서로에 대해 잘 알지 못하게 되었다는 사실도 새삼스럽게 느끼게 되었습니다. 나이를 먹어서 그런 것인지, 아니면 부모가 늙어서 그런 것인지는 분명하지 않지만, 예전처럼 순수하게 믿고 의지하기에는 인간적인 부족함들이 눈에 들어오기 시작했습니다. 다만 이는 부모가 갑자기 달라졌기보다는, 원래 그런 분들이었음을 제가 다시 인식하게 된 과정에 가까운 것 같기도 합니다. 부모, 형제, 그리고 그 배우자들과의 관계를 어떻게 재정립하고 대화를 이어갈지는 여전히 시간이 필요한 문제로 남아 있습니다. 감정적으로 완전히 의지할 수 있었던 부모가 더 이상 그 위치에 있지 않다는 사실은 개인적으로 꽤 불편한 감각으로 남아 있습니다.

마치며

돌아보면 2025년은 졸업과 결혼을 동시에 진행하며 전반적으로 체계적으로 살아가지 못했다는 아쉬움이 많이 남는 해였습니다. 일들을 미루고 쌓아두며 감정을 소모하다 보니, “올해는 무엇을 이뤘다”라고 단정하기보다는 파편적으로 수행한 일들의 조각들만 떠오릅니다. 그럼에도 불구하고, 앞으로 더 이상 미룰 수 없는 문제들이 무엇인지에 대해서는 어느 정도 감각을 얻게 된 한 해이기도 했습니다.

2026년은 1년이나 분기 단위의 중장기적인 방향을 염두에 두고, 하루하루를 조금 더 체계적으로 살아가고 싶습니다. 완전히 정해진 목적지는 없지만, 적어도 방향을 가진 채로 나아가는 한 해가 되었으면 하는 마음으로 이 회고를 마무리합니다.

What is EraLend?

EraLend is a decentralized lending protocol operating within the zkSync Era ecosystem. It is based on the well-known decentralized lending protocol, Compound V2, and functions similarly to Compound V2. In this incident analysis, we will briefly cover the Money Market, Comptroller, and Oracle, which are the main components of EraLend. Money Market is a form of bond created in the form of ERC20 tokens. When you deposit 1 ETH into the Money Market, you will receive a certain amount of tokens in return (referred to as cTokens in Compound and nTokens in EraLend). The exchange rate for these tokens fluctuates in real time based on various factors, including loan interest rates.

EraLend allows users to deposit a certain amount of nTokens as collateral and borrow nTokens based on the collateral ratio. For example, one could deposit 1 nETH as collateral and borrow 100 nUSDC. The Comptroller is responsible for assessing the eligibility for loans, and Oracle provides external price data to evaluate the values of different tokens. It's important to note that retrieving price information directly from decentralized exchanges is not recommended due to the risk of collateral price manipulation. In summary, EraLend is a decentralized lending protocol that issues debt tokens to create liquidity and connects lenders and borrowers through collateralized loans. You can refer to this article for a more detailed understanding of how EraLend and the Compound Protocol operate.

Incident Overview

On July 25th, 2023, at 9:27 AM (UTC), two suspicious transactions occurred (Tx1, Tx2), exploiting the vulnerability in EraLend's collateral valuation algorithm. Velocore, SpaceFi, and SyncSwap used flash loans to perform the attack, resulting in approximately 2.76 million USD in damage.

Incident in Detail

The attack involves repeating cycles to gain profit. Here, we provide a simplified numerical view of a single attack cycle.

The attacker initially secures significant ETH and USDC by utilizing flash loans from various decentralized exchanges within the zkSync Era ecosystem. and then the attacker supplies liquidity to SyncSwap's ETH/USDC pair and receives 0.3 LP Tokens as a reward (exact figures may vary).

Next, the attacker deposits a very small portion of the obtained LP Tokens (0.004 LP Tokens) into EraLend eSYNC_ETHUSDC (consider it as nToken for LP Tokens) and receives 0.222 nLP Tokens. The attacker then burns all of their remaining 0.296 LP Tokens, specifying their self-made contract for the callback function.

During the LP Token burning process, the callback is invoked. At this point, the update of reserve values, which represents the actual liquidity amount, has not updated yet. Taking advantage of this, the attacker executes a USDC loan by using their 0.222 nLP Tokens as collateral. EraLend calculates the LP Token's value using the Pyth Network's Price Feed and SyncSwap's Reserve Parameter.

As the maximum loan allowed is 60% of the collateral value, the attacker receives a loan of 344,076 USDC.

After the callback function ends and reserve values are updated, the LP Token's collateral value is recalculated to be 233,165 USDC, which becomes lower than the loan principal. In such a case, a liquidation process is triggered, where the liquidator can obtain the collateral by paying 92% of the current collateral value. Thus, the attacker pays 214,511 USDC to receive back their 0.004 LP Token as collateral. The attacker gains 129,565 USDC worth of profit in this single cycle, which is still a significant amount even after paying the flash loan interest. Moreover, the attacker can repeat this cycle until the balance of EraLend eSYNC_ETHUSDC is depleted.

Root Cause

The root cause of this unfortunate incident lies in the position of the SyncSwap's callback function. The callback function is placed before the _updateReserves function at line 210, which allowed the callback function to manipulate the collateral evaluation based on reserve values.

Read-Only Reentrancy

The vulnerability that caused the EraLend incident is classified as Read-Only Reentrancy, where a point that relies on the state of an external contract can be called after the state has changed in the external contract. In this case, after the total supply of SyncSwap LP Tokens changes, the callback could call EraLend's borrow function, leading to Read-Only Reentrancy. To prevent reentrancy, a Check-Effect-Interaction pattern is commonly used, where critical actions, such as calling an external contract for a challenging verification process, are performed after updating most of the state. However, in the case of SyncSwap, the callback invocation at that specific location was intended design.

For a more detailed understanding of Read-Only Reentrancy, you can refer to this video.

Aftermath

Damages and Response

After the incident, EraLend announced that they are actively collaborating with various individuals and companies to recover the funds and restore the service. (Twitter) They have suspended lending, USDC deposits, and LP Token deposits since the incident became known. EraLend has issued an open letter to the attacker, giving them until July 27th, 14:00 UTC, to return 90% of the funds; otherwise, EraLend will take all possible measures.

On the other hand, SyncSwap stated that they did not suffer any damages from the incident, and the callback implementation was intentional, so they bear no responsibility. (Twitter)

Impact on Other Protocols

Since the zkSync Era ecosystem is still in its early stages and there aren't many protocols heavily relying on SyncSwap's state values, the impact on other protocols appears to be minimal.

크립토체크라고 하는 텔레그램 채널에서 "매달 50만 클레이 입금하는 지갑" 이라는 게시글이 올라옵니다. 2월 22일부터 매일 50만 클레이씩 653만 클레이를 바이낸스로 송금하고 있는 지갑이었습니다.

이 지갑을 변창호 코인사관학교 라고 하는 텔레그램 채널에서 분석을 하기 시작합니다. 분석을 해본 결과, 해당 자금의 출처는 클레이튼의 사내 창업 벤처인 크래커랩스에서 만든 DApp인 Stake.ly와 연관된 Contract임을 알아내게 됩니다.

Stake.ly는 클레이튼의 Liquid Staking 서비스로, 사용자들에게 Klay를 받아서, Klay Staking이 가능한 지정된 General Council 노드들이 대신 Staking을 해주고, 그 보상을 사용자들에게 분배해주는 서비스입니다.

위의 구조도와 같이, Klay를 예치하면, 예치의 증표로 같은 양만큼의 stKlay 토큰을 지급하기 때문에, Klay가 Protocol 바깥으로 나오기 위해서는 비슷한 양의 stKlay가 소각되어야 만 합니다. (예치 증서 없이 은행 자금이 새어 나와서는 안되니까요.)

그런데, 의심 계좌들은 딱히 stake를 하지도, stKlay를 소각하지 않고도, Klay를 잔뜩 받아갑니다. 여기서 이 분석글은 Stake.ly 서비스에 숨겨진 Mixer 기능이 있다고 주장을 합니다.

Mixer란?

Mixer라고 하는 것은 가상자산 세탁 기법의 일종입니다. 해킹된 자금과 같이 불법적인 가상 자산을 막는 방법은 1) 불법 행위에 연루된 지갑을 차단하거나, 2) 불법 자산을 추적하는 것입니다. 그런데 여러 입금자의 자금을 한데 넣고 서로 다른 주소로 보내게 되면, 어느 전송이 불법 자산의 전송인지 추적하기 어렵게 됩니다. 이런 원리로, 여러 사람의 여러 자금을 한데 모아서 숨겨진 장부를 가지고 누가 누구에게 전송 하였는지 알 수 없게 만들어주는 소프트웨어를 믹서라고 합니다. 대표적으로는 최근에 미 재무부에 의해서 제재를 받은 토네이도 캐시가 있습니다.

분석 글은 0x9f25a3bd 함수가 믹싱 행위를 한다고 보았습니다. allocate와 같이 이름이 등록 되지도 않았고, 주로 자금을 받아낸 지갑들이 0x9f25a3bd 함수에 의해 자금을 받았기 때문닙니다.

Kracker Labs의 해명

Kracker Labs는 3월 9일 해명글  을 게시하였습니다. 자금난으로 인해서 Klay를 팔았고, 클레이튼 운영사인 크러스트와는 독립된 기관이니 내부자 거래는 없었다는 내용이 핵심입니다. 문제가 된 컨트랙트와 0x9f25a3bd 함수에 대한 이야기는 전혀 없습니다.

해치랩스 임종규 이사 ”클레이튼 온보딩 프로젝트 보안감사는 했다” ...크래커랩스의 ‘리퀴드 스테이킹’ 오딧팅 논란 | 블록미디어

클레이튼을 운영하는 크러스트의 사내 벤처(CIC) 회사가 대량의 클레이 코인 매물을 내놨다는 주장과 관련, 클레이튼 블록체인 보안 감사가 허술하게 진행된 것이 아니냐는 지적이 나온다. 문제의 사내 벤처인 크래커랩스는 스테이크닷리(stake.ly)라는 리퀴드 스테이킹

블록미디어정아인 기자

Stake.ly에 코드 감사를 담당한 해치랩스에서도 해당 컨트랙트에 대한 이야기는 크게 없는 것으로 보입니다.

현 시점에서 크래커랩스가 자금 확보를 위해서 Klay를 처분한 사실은 자명합니다. 내부자 거래 였는지 여부에 대해서는 사실 대부분의 자금 출처가 크러스트와 그 연관사 자금에 연관되어 있기 때문에 의심스럽기는 하나 기술적으로는 알 길이 없습니다.

그렇다면 여기서 분석글이 제시한 대로, 0x9f25a3bd 함수는 자금 세탁을 위해서 작성된, 믹싱 함수 인 것일까요? 만약 그렇다면, 이는 자금 세탁의 결정적인 증거가 될 것입니다.

지루한 기술적 이야기 - 코드를 분석해보자

문제가 되었던 0x857a054ed25820e707b051066073ac45896a7240 컨트랙트의 바이트 코드를 가져와서, (바이트 코드는 기계가 읽을 수 있는 형태의 숫자 코드로, 블록체인 상에는 모든 DApp의 바이트 코드가 공개되어 있다.) 디컴파일(바이트코드로부터 사람이 읽을 수 있는 코드를 유추하는 기술)을 했습니다.

function allocate(address varg0, address varg1, uint256 varg2) public nonPayable { 
    require(msg.data.length - 4 >= 96);
    require(varg0 == varg0);
    require(varg1 == varg1);
    require(_deposit != 2, Error('ReentrancyGuard: reentrant call'));
    _deposit = 2;
    0x3815(msg.sender);
    ...
    v2 = stor_4d_0_19.allocate(varg0, varg1, varg2).gas(msg.gas);
    ...
    _deposit = 1;
}

allocate 의 코드의 경우 위와 같습니다. 유추해 낸 것이므로, 완벽하지는 않습니다. 윗부분에 ReentrancyGuard는 재진입 공격을 막기 위한 코드이고, 0x3815는 해당 컨트랙트의 관리자인지 확인하는 함수입니다. 그냥 보기에 크게 하는 것 없이 stor_4d_0_19에 allocate를 호출해 주는 것으로 보입니다.

function 0x9f25a3bd(uint256 varg0) public nonPayable { 
    ...
    0x3890(varg0);
    require(stor_4d_0_19.code.size);
    v0 = stor_4d_0_19.call(0x13a3395200000000000000000000000000000000000000000000000000000000, address(varg0)).gas(msg.gas);
    require(v0); // checks call status, propagates error data on error
    v1 = _SafeSub(this.balance, this.balance);
    v2 = _SafeAdd(_allocate, v1);
    _allocate = v2;
    _deposit = 1;
}

그 다음에는 문제의 0x9f25a3bd 함수를 보겠습니다. 윗 부분은 거의 비슷하고, 0x3890 함수를 호출한 다음, stor_4d_0_19에  0x13a339520 함수를 호출해 줍니다. 하지만 allocate, 0x13a33 함수 중 어느 것도 자금을 직접적으로 보내지는 않으므로, 0x3890 함수에 무언가가 있을 것으로 보입니다.

function 0x3890(uint256 varg0) private { 
    v0 = address(varg0);
    require(stor_4d_0_19.code.size);
    v1, v2, v3 = stor_4d_0_19.harvest(v0, _feeRate).gas(msg.gas);
    ...
        v10 = _feeCollector.call().value(v2).gas(2300 * !v2);
        ...
            v11, v12 = _deleteAdmin.getUserDeposit(stor_54_0_19).gas(msg.gas);
            ...
            v13 = 0x3d49(this, stor_4a_0_19, stor_54_0_19); // ClaimReward
                v14 = _SafeMul(v3, stor_52); // feeRate로 추정
                require(100, Panic(18));
                v12 = v14 / 100;
            ...
            v13 = 0x3d49(this, stor_4a_0_19, stor_54_0_19); // ClaimReward
            ...
			v17 = _deleteAdmin.call(0x3a2bf94e00000000000000000000000000000000000000000000000000000000, stor_54_0_19, v12, _rewardRate).gas(msg.gas);
            ...
            v19 = stor_53_0_19.allocate(stor_4a_0_19, v18).value(v18).gas(msg.gas);
                   ...
}

0x3890 함수는 굉장히 긴데, 중요한 함수 호출 부분만 보면 다음과 같습니다. stor_4d_0_19를 통해 harvest 함수를 호출하는데, 이는 각 스테이킹 노드를 돌면서, Klay를 회수하는 함수로 보입니다. 회수된 이익금 중 일부를 _feeCollector에게 보내고, 0x3d49 함수를 이용해서 스테이킹 보상을 수령한 다음, Admin이 Protocol Fee 만큼의 출금요청을 하게 합니다. (0x3a2bf942 가 requestWithdraw로 추정) 그리고 나서 가장 중요하게 stor_53_0_19에게 allocate를 호출하는데, 이때, 회수한 Klay와 스테이킹 보상을 모두 모아 stor_53_0_19에게 보냅니다.

stor_53_0_19는 온체인 상에서 0xcacaab1e74b97ee7b189e2292f647d1fa95d5c29로 추정되는데, 이 컨트랙트의 allocate 코드를 분석해 보면, 합이 10000인 4개의 변수 만큼 각 자금을 분배한다는 점, 함수 명이 allocate인 점을 미루어 보아, 자금을 일정 비율로 지정된 주소로 분배해주는 함수로 보입니다. (다만 Stake.ly 문서의 리워드 구성 에 따르면, 비율 항목은 3개인데 왜 4개 항목으로 구성했는지 알기 어렵습니다.)

재미있는 사실은 stor_53_0_19의 allocate 함수와 stor_4d_0_19의 allocate 함수는 구현 모양새가 다른데, stor_4d의 경우에는 Vault 주소만 호출할 수 있으며, 지정된 분배 전략 컨트랙트가 자금을 분배하는 반면에, stor_53의 경우에는 Owner가 임의로 설정한 주소들로 임의로 분배되도록 설계되어 있습니다.

function allocate(address varg0, address varg1, uint256 varg2) public payable { 
    ...
    0x2569(varg0); // getStrategy
    require(varg2 > 0, Error('not a positive number'));
    require(varg0.code.size);
    v0 = varg0.allocate(varg1, varg2).value(msg.value).gas(msg.gas);
    require(v0); // checks call status, propagates error data on error
    emit Allocated(varg0, varg1, varg2);
    stor_65 = 1;
}

결론

공개된 바이트코드를 기반으로 Stake.ly 구현체를 분석해 본 바, 의심되는 0xf925a3bd 함수가 자금 세탁을 위해 설계된 함수로 보기는 어렵습니다. 많은 클레이튼 기반 DApp 들이 기능 오작동이나 업데이트 시 계산값 오류 등을 정정하기 위한 관리자 권한으로 자금 조정 가능을 가지고 있기 때문입니다.

하지만, 관리자의 권한으로 임의로 사용자 자금을 빼 낼 수 있도록 구현한 것은 사실입니다. 보안 감사에서 이러한 사실이 별도로 보고되지 않은 것은 아마도, 관리자는 신뢰받는 대상이므로, 악용하지 않을 것이라는 확신이 있었거나, 감사 당시에 해당 함수가 존재하지 않았을 가능성이 있습니다.

어느 쪽이든, Kracker Labs는 코드 원본을 공개하고, 해당 함수의 구현 목적이 무엇이며, 투자자 기망의 의도가 없었음을 명확히 해야 할 것 입니다.

그리고 마지막으로, 많은 클레이튼 기반 서비스들은 아직도 코드를 공개하지 않고 있습니다. 코드가 공개되어 있었다면, 사실 이러한 관리자에 의한 임의의 자금 이동은 존재할 수 없었을 것입니다. 이런 사건 사고들을 거울 삼아 클레이튼 체인에도 코드를 모두 공개하는 문화가 자리 잡았으면 하는 바램입니다.

2022년 4월 27일, 골드만삭스의 디지털 자산 부서장인 매튜 맥도멋이 파이낸셜 타임즈의 디지털 / 암호 자산 서밋에 참가해 다음과 같은 말을 했다.

저희는 NFT를 금융 상품의 맥락에서 알아보고 있고, 그 잠재력이 꽤 강력하다고 봅니다. 그래서 우리는 여러가지 시도를 해보는 중인데, ...

골드 만삭스와 같은 대형 은행이 갑자기 NFT를 금융을 시도한다는 이야기는 NFT에 대해서 미술품 이나 수집품 거래를 위해 사용되는 토큰이라고 알고 있던 사람들에게는 다소 당황스러운 이야기이다. 고작해야 그림 거래를 위해 쓰이던 ERC-721이 왜 갑자기 금융에 사용된 다는 것인가? 그것을 알기 위해서는 이더리움의 초기인 2018년 초로 돌아가서 NFT가 생겨난 이유를 되돌아볼 필요가 있다.

NFT가 태어난 이유: 집을 Ethereum으로 거래하고 싶다

Non-Fungible Token, 줄여서 NFT라고 불리는 ERC-721은 원래 "Deed" (부동산 등기) 를 스마트 컨트랙트로 표현하기 위해서 만들어진 물건이다. 그림, 미래의 매출, 심지어는 소까지 유동화하는 세상에 유동화하는 것이 불가능한 자산은 없다지만, 집이나 미술품 같은 수집품이나 사용 자산은 잘 유동화하지 않는 경향이 있다. 그리고 이들 자산은 각각이 개개의 것들이 다 달라서, ERC-20과 같은 토큰으로는 각각을 구분해 거래하는 것이 불가능했다. ERC-20 표준으로 개발된 A 토큰 한개가 어떨 때는 강남구 래미안 아파트의 보유권을 상징하기도 하고, 어떨 때는 수원시 권선구의 신동아 아파트의 보유권을 상징한다고 생각해 보자. 그 둘을 토큰만 보고 구분하는게 가능하겠는가? 절대 불가능하다.

그런 문제를 해결하기 위해서 나온 것이 ERC-721 표준인 것이다. 애시당초 NFT는 유동화 하지 않을 개개의 독자적인, 복수 존재 불가능한 (Non-fungible) 자산을 담기 위한 토큰에 대한 표준이다. 그런 맥락 하에서 보자면, 게임 아이템이나 그림보다는 실물자산의 토큰화 하는데 사용되고 이것이 금융 시스템과 연동되는 것은 필연적인 일이다.

근데 우리는 왜 OpenSea에서 집행검이나 사고 팔지?

그렇다면 이것이 대체 왜 그림과 게임 아이템, 소위 메타버스라 불리는 키워드와 묶여 나가고 있는 것인가? 그것은 크게 세가지 이유로 나누어 볼 수 있다.  첫 번째는 NFT의 최초 사용 사례들이 게임들이었기 때문이고, 두 번째는 아이템 금전 거래에 대한 수요 때문이고,  마지막으로는 대체 불가능성 (Non-fungiblity)에 대한 오해 때문이었다.

1. NFT로 돈을 번 프로젝트들이 전부 게임과 수집품이었다.

NFT가 도입된 이유가 사용 자산들의 소유권을 담은 토큰을 발행하기 위한 것이라고 하긴 했지만, ERC-721 문서에 언급되어 있는 초기 구현체들을 보면, 부동산 프롭테크 업체인 Propy를 제외하면 우리가 잘아는 크립토키티, 크립토펑크, 디센트럴랜드 등 게임과 수집물에 관련된 것들이 대부분이다. 애시당초 ERC-721의 표준화를 주도한 사람 중 하나가 크립토키티 개발사인 Dapperlabs의 CTO인 Dieter Shirley 였으니 더 말해 무엇할까. 초기의 성공적인 (다시 말해, 성공적으로 돈을 모금한) 프로젝트들이 주로 게임과 수집품에 몰려 있으니, 그 이후의 프로젝트들도 그러한 부분을 따라가는 것이다.

2. 게임 업계는 원래부터 돈으로 아이템을 팔고 싶었다.

그리고 이러한 게임에서의 NFT 적용 성공 사례는 게임 업계에서 그들의 오랜 꿈을 다시 꺼내오게 하는데, 그것은 바로 게임 아이템 금전 거래이다. 게임 아이템 금전 거래 같은 경우에는 물론 현행 법규 상으로도 충분히 가능하지만, 게임 회사들이 사행성 문제나 사기 문제를 두려워 해 공식적인 거래 채널을 열어두고 있지는 않았다. 그런데 게임 아이템을 NFT로 발행하면, 게임 아이템들이 Ethereum 네트워크에 올라가게 되고, USDT와 같은 달러 연동 토큰으로 거래가 가능해진다. NFT 거래를 통해 아이템 거래를 하면 사기 문제는 거의 해결되는 데다가, (중고나라에서 돈 받고 아이템 안주는 사례는 흔하지 않던가? OpenSea로 거래하면 '돈 먹고 튀기'는 사실상 불가능하다.) 게임 회사의 개입없이도 거래가 가능해 게임 회사는 여전히 법적인 책임에서 자유롭다. 게임 회사 입장에서 이점만 가득하고 단점은 거의 없으니 시도하지 않을 수 없는 것이다.

3. 누군가 NFT에 담으면 예술품 원본 추적이 된다는 헛소리를 퍼뜨렸다.

게임 아이템과 인터넷 밈을 담을 수집품을 다루다 보니, 수집품의 연장선 상에서 명화나 예술품들을 NFT가 담기 시작한다. 이러한 예술품 NFT 프로젝트들이 많이 생기면서 사람들은 "왜 굳이 예술품을 NFT에 담아야 하는가?" 하는 질문들을 던지는데, 이 질문에 대한 대답을 구하는 과정에서 대체 불가능성 (Non-fungiblity) 에 대한 오해가 시작된다. NFT의 대체 불가능성이란, NFT이 소유권을 표시해 주고자 하는 자산이 대체 불가능하다는 의미이다. 예를 들자면, 어느 NFT가 경기도 광주시의 어느 전원주택의 소유권을 표시하고 있다고 하자. 이 전원주택은 세상에 하나 밖에 없는 것이기 때문에, 당연히 대체가 불가능한 자산이다. 이러한 자산을 담고 있기 때문에 대체 불가능 토큰이라고 불리는 것이다.

간혹 혹자들은 그림이 담겨 있는 NFT 같은 경우는 그림 복사해서 붙여넣기 하면 나도 가질 수 있는데, 이게 어떻게 대체 불가능한 자산이란 말인가? 라고 묻는 경우가 있다. 요즘 시대에는 빈 센트 반 고흐와 같은 명화 화가의 그림 모작을 아주 저렴한 가격에 구매할 수 있다. 하지만 진품 만이 오직 가치를 지니지 않는가? NFT 그림 또한 누구나 복사 붙여넣기로 가품을 지닐 수는 있지만, 작가가 인정하는 진짜 그림은 대체 불가능 하다고 볼 수 있다.

요는 NFT의 대체 불가능성이란 자산 자체가 지니는 대체 불가능성을 이야기 하는 것이지, NFT에 자산을 담음으로써 해당하는 유형의 자산 혹은 데이터에게 대체 불가능성을 부여하지는 않는다. 그런데, 예술품 NFT에 관해 설명할 때 자주 나오는 것은 "원본임을 증명하기 어려움" 이라는 이야기이다.  NFT에 디지털 아트나 예술품을 담는다고 그것이 원본임을 증명해주지 않는다는 것은 수많은 작품 도용 NFT 발행 사례들로 부터 알 수 있지만, 이러한 대체 불가능성에 대한 오해는 오히려 미술품 NFT가 활성화 되도록 도왔다.

이러한 이유에서 게임 아이템과 예술품을 비롯한 수집품에 주로 사용이 되고 있었는데, 최근 점점 디지털 자산과 금융을 연동하기 위한 시도가 늘어나고 있고 그 중 하나가 위에서 언급한 골드 만삭스의 그것이다.

그래서 NFT가 어떻게 될 것 같아?

이미 NFT는 많은 가치를 지닌 디지털 자산의 일종이 되어 가고 있다. 수많은 거래품들이 NFT를 통하여 거래되고 있다. 글을 작성하는 2022년 5월 1일 시점으로 NFT의 일 거래액은 3100만 달러이고, 유명 수집품 경매소인 소더비스도 NFT 전용 거래소를 운영 중에 있다. 가치 평가가 가능한 자산이니, 거래소는 기본이고, 담보로 하는 대출도 만들어 질 수도 있고, NFT의 유동화나 각종 파생 상품도 나올 수 있다.

한편, NFT 투기가 과열되어 과평가 되어 있다는 평들이 있다. 그것 또한 사실인데, 나의 생각에는 향후 NFT는 현재의 단순히 디지털 아트만 찍어내는 방식에서 벗어나서, 세계관을 크게 넓히고, 하나의 콘텐츠 경제를 이루고, NFT를 보유하는 것이 콘텐츠 경제를 추종하는 어떤 포지션을 가지는 것과 같게 되도록 할 것 같다. 가지고 있는 캐릭터나 IP, 세계관으로 커뮤니티와 함께 더 많은 콘텐츠를 생산하고, 그를 통해 더 많은 팬을 모으며, 콘텐츠 파워를 강화해 나가는 식인 것이다. 그 때에 NFT는 곧 해당 IP의 콘텐츠 파워를 현물 가치로 반영한 자산이 될 것이라고 생각한다.

* 본 포스팅의 내용은 어떠한 투자상품의 안정성도 보장하지 않으며, 이 글을 참조하여 이루어진 투자와 그로 인해 발생하는 그 어떠한 피해에 대해서도 책임지지 않습니다.

좀 지난 이야기이긴 하지만, 2월 26일에 Klaytn 기반의 NFT인 실타래에서 데이터 Reveal 과정에서 해킹으로 인하여 희귀 카드인 이순신 카드가 탈취 되었다.

게임 관련 NFT들은 확률적인 부분을 넣기 위해서 난수를 사용하고는 한다. 컴퓨터가 정말 아무 것도 없이 임의의 수를 고르는 것은 불가능하기 때문에, (모든 소프트웨어는 입력이 주어져야 하기 때문에, 난수 프로그램도 예외는 없다.) 일반적인 소프트웨어 실행 환경에서 난수는 사용자의 마우스 움직임이라던가, CPU 온도라던가 하는 예측 하기 어려운 값들로부터 난수 값을 생성한다.

스마트 컨트랙트 실행 환경은 기본적으로 스마트 컨트랙트의 실행값을 네트워크 참여자들이 모두 상호 검증하는 방식으로 이루어 지기 때문에, 스마트 컨트랙트에서 사용할 수 있는 값은 모두가 계산 가능한 값 이어야 만 한다. 따라서 스마트 컨트랙트에 존재하는 값만으로 만들어진 난수는 모두 예측이 가능한 것이다.

이번 실타래의 경우도, Reveal에 사용하는 난수 생성 함수를 오직 스마트 컨트랙트에 존재하는 값 만으로 구현하였기 때문에 문제가 발생한 것이다.

var var3 = keccak256(block.timestamp);
var temp2 = keccak256(block.timestamp) % var2;

Reveal에 포함된 NFT ID 결정 코드의 일부이다. 블록 생성 시간을 keccak256이라는 해시 알고리즘으로 해시한 값을 특정 값으로 나눈 나머지를 가지고 NFT ID를 결정한다. 여기서 자세하게 결정식을 다루지는 않겠지만, 아주 간단한 연산으로 예측이 가능하다.

그럼 여기서 의문이 하나 생긴다. 블록 생성시간인 block.timestamp 는 블록 생성 시에 결정되는데, 이걸 어떻게 예측해서 난수를 맞춘단 말인가? 심지어 그냥 쓰는 것도 아니고 해시 알고리즘으로 연산한 결과값을 사용 않는가? 해시 알고리즘으로 연산하면 그 값이 1만 차이나도 엄청나게 결과값에 차이가 나는데, 어떻게 저 값을 정확히 예측해서 결과값이 이순신의 NFT ID인 1111이 나오게 할 수 있는가?

답은 간단하다. 스마트 컨트랙트를 만들어서 내가 예측한 블록 생성 시간과 맞지 않으면 실행을 멈추면 그만이다. Klaytn의 블록 생성 주기가 1~2초 사이인것은 누구나 알고 있는 사실이니, 내가 예측한 블록 생성 시간이 실제 블록 생성 시간과 같으면 reveal을 진행하고, 아니면 트랜젝션을 철회하는 컨트랙트를 만들어 실행시키면, 컨트랙트가 실행되는 시점에는 이미 블록 생성 시간이 결정되었으니 충분히 확인 할 수 있는 것이다.

실제로, 공격자인 0x435929e065fc6abc36c93ed0096ceb3c016ae09f는 공격용 스마트 컨트랙트를 만들어서 예측값이 정확히 맞는지 검증하는 과정을 거쳤다.

그럼, 막을 수 없는 사고였나?

블록체인에서 Bad Randomness 취약점은 아주 유구한 역사를 가진 취약점이다. 많은 보안 전문가들이 난수 생성 시에 block.timestamp, block.number 등의 값을 사용하지 않도록 권장하고 있다. 아마도 실타래가 보안 감사를 받았더라면, 분명 이에 대해서 고지 받았을 것이다.

나는 이 사건은 개발자의 부주의 혹은 무지에 의해 일어난 인재(人災)라고 본다. 많은 DeFi / NFT들이 난수 생성을 위해 Chainlink VRF와 같은 암호학적으로 어느정도 안전하다고 검증된 난수 생성기를 비용을 지불하며 사용한다. 물론, Klaytn에서는 아직 Chainlink VRF를 사용할 수 없지만, VRF를 사용할 수 없다면 별도의 블록체인 외부 데이터를 사용해서 Random을 생성하게 했어야 한다.

모범 사례로 Wanchain을 사용하는 Zookeeper.finance의 사례를 보자. Wanchain도 Ethereum 기반의 사이드체인으로 Chainlink VRF를 지원하지 않는다.

    function randomNFT(address user, bool golden) private view returns (uint tokenId, uint level, uint category, uint item, uint random) {
        uint totalSupply = IZooNFTMint(zooNFT).totalSupply();
        tokenId = totalSupply + 1;
        uint random1 = uint(keccak256(abi.encode(tokenId, user, blockhash(block.number - 30), getRandomSeed())));
        uint random2 = uint(keccak256(abi.encode(random1)));
        uint random3 = uint(keccak256(abi.encode(random2)));
        uint random4 = uint(keccak256(abi.encode(random3)));
        uint random5 = uint(keccak256(abi.encode(random4)));

이곳도 얼핏 보기에는 block.number라는 예측가능한 값 만으로 난수를 생성하는 것 같아 보인다. 하지만 그들은 한가지 값을 더 사용하는데, randomSeed라는 것을 난수 생성에 사용한다.

ZooKeeper.finance는 mint를 호출 했을 때, 바로 random으로 NFT의 값들을 결정하지 않고, mint 요청들을 저장해 두었다가, Oracle이라고 불리는 외부 데이터 소스가 임의의 숫자인 randomSeed를 제공하면 그 값에 기반하여 난수를 생성하여 NFT의 값들을 채워넣는 식으로 난수를 예측할 수 없도록 해두었다.

Klaytn은 가스비가 그리 비싸지 않기 때문에, 매 요청에 임의의 난수를 생성해 보내는 Oracle 봇을 만들어 돌리는 것이 그렇게 비용적으로 부담이 되지는 않을 것이다.

이런 측면에서 볼 때, 해킹 불가능한 랜덤을 만들 수 없다는 이두희 님의 말은 언어도단이다. 온체인 데이터 만으로 해킹 가능한 랜덤을 만드는 것이 불가능 하다는 것을 알고 있었다면, 이러한 시스템을 구현하지 말았어야 하며, 그 사실을 몰랐다면, 보안 위협에 대해서 감사를 맡겼어야 한다.

결론

지금까지 실타래 NFT Reveal 해킹 사고의 원인과 해결 방법에 대하여 간단하게 다루어 보았다. 실타래 NFT Reveal은 누구나 쉽게 예측 할 수 있는 값을 난수로 NFT ID를 생성하고 있었고, 악의적인 누군가가 그를 악용하여 희귀 NFT를 뽑은 사건이다.

그 사고 경위나 대응, 후속 조치에 있어 실타래 프로젝트는 다소 아쉬운 모습을 보여주고 있다. 조만간 다시 실타래의 Reveal이 있을 예정이라고 한다. 그 때에는 보안감사를 받거나, 난수 예측 공격에 대한 안전한 대응책을 가지고 진행하기를 기대해 본다.

* 본 포스팅의 내용은 어떠한 투자상품의 안정성도 보장하지 않으며, 이 글을 참조하여 이루어진 투자와 그로 인해 발생하는 그 어떠한 피해에 대해서도 책임지지 않습니다.

최근에 KlayCity Minting Issue나 KLEVA Protocol의 Vault Issue로 정신이 없던 날이었다. KLEVA Protocol의 Vault Issue를 살펴보던 중에, Qubit Finance의 해킹 소식이 날아왔다.

DeFi Protocol Qubit Finance Exploited for $80M

The attack is the seventh-largest DeFi exploit by the amount of funds stolen, data shows.

CoinDeskShaurya Malwa

KLEVA Protocol에 비해 피해규모가 크기도 하고, 이미 KLEVA 쪽 사고는 Theori에서 분석이 나와 있는 지라, KLEVA 보다 Qubit Finance 쪽을 다루기로 했다.

대체 무슨 일이 일어난거야?

위의 트위터에 따르면, 0xd01ae1a708614948b2b5e0b7ab5be6afa01325c7에 의해서 BSC에 있는 xETH를 무한히 발행할 수 있게 되었다고 한다.  xETH란, Qubit Finance에서 사용하는 Cross-chain Ethereum 토큰이다. xETH는 원래 Ethereum 네트워크에서  Ethereum을 Bridge Contract에 예치하고, 신뢰할 수 있는 인증자가 그걸 확인해서 BSC의 Bridge Contract에 입금을 처리해서 xETH를 발행해주는 방식이다. Qubit Finance에서는 이 xETH를 담보로 대출을 받을 수 있다.

해커는 모종의 방법으로 ETH 없이 xETH를 무한히 발행할 수 있게 되었고, 그 xETH를 담보로 BSC에 있는 Qubit Finance의 wETH, BTC-B 등 약 960억원 어치를 대출 받아 갔습니다. 0원 짜리 가짜 xETH로 960억원을 대출받아 간 것이다.

어떻게 이게 가능했던거야?

그러니까 정상적으로 xETH가 발행이 되려면 동일한 양의 ETH를 입금해야 하는 것이다. 그런데, 해커는 어떻게 ETH 없이 xETH를 발행할 수 있었을까?

공격자의 Ethereum 트랙젝션 기록을 보면 QBridge를 향한 토큰 입금 (Deposit) 호출을 14번이나 호출하고 있는 것을 볼 수 있다. 그런데 흥미로운 점은 토큰 입금을 호출 했지만 그 어떤 토큰도 이동하지 않고 있다.

function deposit(uint8 destinationDomainID, bytes32 resourceID, bytes calldata data) external payable notPaused {
    require(msg.value == fee, "QBridge: invalid fee");

    address handler = resourceIDToHandlerAddress[resourceID];
    require(handler != address(0), "QBridge: invalid resourceID");

    uint64 depositNonce = ++_depositCounts[destinationDomainID];

    IQBridgeHandler(handler).deposit(resourceID, msg.sender, data);
    emit Deposit(destinationDomainID, resourceID, depositNonce, msg.sender, data);
}

위의 코드는 그닥 특별할 것 없이 토큰 입출금을 관리하는 자원 ID를 받아서 토큰 브릿지 handler에게 입금을 처리하도록 하는 함수를 호출한다.

function deposit(bytes32 resourceID, address depositer, bytes calldata data) external override onlyBridge {
    uint option;
    uint amount;
    (option, amount) = abi.decode(data, (uint, uint));

    address tokenAddress = resourceIDToTokenContractAddress[resourceID];
    require(contractWhitelist[tokenAddress], "provided tokenAddress is not whitelisted");

    if (burnList[tokenAddress]) {
        require(amount >= withdrawalFees[resourceID], "less than withdrawal fee");
        QBridgeToken(tokenAddress).burnFrom(depositer, amount);
    } else {
        require(amount >= minAmounts[resourceID][option], "less than minimum amount");
        tokenAddress.safeTransferFrom(depositer, address(this), amount);
    }
}

문제는 QBridgeHandler에서 발생한다. 위의 ResourceID로 resourceIDToTokenContractAddress를 호출하면 0x0000.. 즉 Zero address가 나오게 된다. 0x0000이 Whitelist 되어 있고, (0x0000은 통상적으로 ETH에 관련된 값을 저장시킬 때 사용하기 때문에 Whitelist 해둔 것이다.) 따라서 모든 방어 로직을 뚫어 내고 0x0000 주소를 가진 토큰을 입금자에게 이동 시키게 된다.

만약 저기서 토큰 이동 하기 전, tokenAddress가 컨트랙트인지 확인했더라면 문제가 없었겠지만, 안타깝게도 토큰 이동에 safeTransferFrom을 사용했다. 0x0000..은 EOA, 즉 컨트랙트가 아니기 때문에, low-level call을 이용하는 safeTransferFrom은 무조건 성공했는 값을 반환하게 되어 있다. (메시지를 담은 트랜젝션을 그냥 지갑으로 보내는 게 실패할 리 없다.)

입금은 처리되었고 0x0000... 자산 (ETH)이 지정한 갯수만큼 입금 되었다는 Deposit 이벤트가 네트워크에 전파된다.  중앙화 서버인 QBridge 프로그램은 Ethereum 네트워크에 전파된 Deposit 이벤트를 확인하고, BSC에서 xETH를 발행할 수 있게 처리해 두게 된다. 만약 여기서 DepositETH 함수와 Deposit 함수의 이벤트를 다르게 설정해 두었다면, 봇이 이벤트를 보는 과정에서 "어? 토큰 입금인데 왜 ETH를 옮겼다고 나오지?" 하고 xETH를 발행하지 않았을 것이다.

요약하자면 QBridge의 다음과 같은 실수들로 대량의 무가치한 xETH가 발행된 것이다 :

• data를 제대로 검증하지 않았다 ( tokenAddress가 0x000..이 아닌지 확인하지 않았다)
• depositETH와 deposit 함수가 분리되어 있음에도, 이벤트를 분리하지 않아 Bridge가 의도치 않은 작동을 하게 했다.
• safeTransferFrom을 할 때, 대상이 ERC20을 따르는지 확인하지 않았다.
• Bridge가 이벤트만을 데이터 소스로 사용하고 발행이 올바르게 이루어지는 것인지 검증하는 과정을 구현해 두지 않았다.

정리하며

지금까지 Qubit Finance에서 일어난 Bridge 공격 사건에 대해서 간단하게 원인 분석을 해 보았다. Bridge 프로그램이 만약 더 신중하게 데이터를 검증했거나, 컨트랙트 코드가 조금 더 명확하게 작성되어 있었더라면, 사실 취약점이 존재해도 막을 수 있는 공격 이었다고 생각한다.  

Qubit Finance가 그래도 Bridge를 Ethereum-BSC만 지원해서 망정이지, KLAY-ETH를 지원했다면, 2022년 1월 27은 Klaytn 커뮤니티에게 악몽같은 하루가 되었을 수도 있다. Klaytn.. 참 바람잘날 없다.

2021년 중순 이후부터 MultiChain이나 ChainSwap 사건과 같이 Cross-chain bridge에 대한 공격이 늘어나고 있다. 각각의 공격들이 굉장히 큰 액수의 피해를 입게 되었다. 앞으로 새로운 Cross-chain bridge가 나올때 마다 철저한 검증을 거칠 필요가 있겠다.

참조자료

1. Qubit Finance Docs
2. Rekt - Qubit Finance
3. Qubit Bridge Collapse Exploited to the Tune of $80 Million
4. Theori Qubit Cross-Chain Security Audit Report
   

얼마전 아톰릭스랩 정우현 대표님이 체인파트너스에서 출시한 탈중앙화 대출 서비스인 Donkey에 대해서 스마트 컨트랙트 소스를 공개하라는 글을 쓰셨다.

정우현--표철민 충돌 ”디파이 소스 공개하라” vs ”추후 공개” ..클레이스왑으로도 불똥 | 블록미디어

체인파트너스(체파)가 런칭한 디파이 돈키에 대해 ”디파이 스마트콘트렉트 소스를 공개하라”는 주장이 나왔다. 체파의 표철민 대표는 ”더 많은 감사를 받은 후 소스를 공개하고, 스마트콘트렉트도 오픈하겠다”는 입장을 내놨다. 오픈소스 공개를 주장한 아톰릭스의 정우현 대표는 ”투자자

블록미디어James Jung 기자

DeFi는 코드에 기반하여 금융 거래를 진행하는 서비스이니 통상적으로 코드를 공개하는 것이 맞다. 더군다나 Donkey는 수호아이오의 보안감사까지 받았으니 사실 코드에 크게 이상이 없을 것이다. 그냥 공개해도 크게 문제 없을 터인데, 체인파트너스 표철민 대표님께서는 다른 업체에도 보안감사 끝내고 Verify하겠다고 말씀을 하신다.

자꾸 안보여주시니 왜 안보여주시는지 궁금하기도 하고 해서 궁금증을 참지 못하고 컨트랙트를 간단하게 까서 어떻게 되어있나 보기로 했다. 아마 모든 Staking Pool들이 구조는 비슷비슷할터이니, 예치된 자산이 가장 많아보이는 dETH Pool을 대상으로 보기로 하자. dETH Pool의 위치는 아래와 같다.

위의 위치로 가보면 Contract 탭에 초록색 체크 표시와 함께 Contract Source Verified라고 되어있다. 그렇다면 소스코드가 인증이 되어 있는 것인가? 굳이 힘겹게 코드를 알아보려는 시도를 하지 않아도 되는가?

그렇지 않다. Contract의 이름을 보면 TransparentUpgradableProxy 라고 되어 있다. DApp의 사용자가 Proxy Contract와 상호작용한다는 것은, Proxy Contract에는 Token의 잔고액과 같은 상태값만 저장되어 있고, 토큰을 전송하거나 Stake 관련 계산을 하는 구현체 Contract는 어딘가 다른 곳에 존재한다는 의미이다.

자, 그럼 구현체를 찾아 여행을 떠나보자. 어떻게 하면 구현체를 찾아 볼 수 있을까? 이때 활용하는 것이 우리가 Ethereum 상에 존재했지만 거의 신경쓰지 않았던 탭인 Event 탭이다. OpenZepplin에서 만든 TransparentUpgradableProxy 컨트랙트는 구현체를 변경할 때마다 Upgraded(address)라고 구현체 Contract의 주소를 실어서 Event를 발생시켜준다. 우리는 Upgraded(address) 이벤트가 발생하였는지, 발생하였다면 지금 구현체는 어디에 있는지만 Event 탭을 통해 알아내면 되는 것이다.

Ethereum Signature Database에 따르면, Upgraded(address)의 Hex Signature는 다음과 같으니 Etherscan에 해당 Signature를 가진 Event가 있었는지 질의해 보면...

흥미로운 결과가 나온다. 글이 작성된 9월 15일 새벽 기준으로 13일 20시간 전이면 Donkey의 서비스 출시일이니 컨트랙트가 배치되는 것은 당연한 일인데, 그 이후로 3번, 가장 최근에는 8시간 전인 9월 14일 오후 7시 경에 Contract의 구현 내용이 바뀌었다.

사실 DeFi Contract에서 Contract Upgrade는 굉장히 민감한 이슈이다. Meerkat Finance의 사례를 보면, Contract 개발자들이 투자자 몰래 코드를 수정하고 자산을 빼돌리는 "Rug Pull"이 일어날 수 있기 때문에, Contract Upgrade는 통상적으로 Timelock을 걸어 24-48시간 정도의 실행 유예를 두고 커뮤니티가 판단할 수 있게 하는 경우가 많다. Donkey는 국내에서 잘 알려진 분들이 책임을 지고 운영을 하고 있다고 하니 Rug Pull에 대해서는 조금 덜 걱정이 되긴 하지만, 그래도 DeFi라면 Contract Upgrade에 대해서 정확히 커뮤니티에 공시했으면 좋았을 것이다.

아무튼 코드를 보자!

가장 최근에 업데이트 된 구현체 Contract인 0x9883480e59081fE8772bF01196965b0Da0e770d1을 향해서 나아가 보자. Etherscan에서 조회해 보면,

코드가 Verify되어 있지 않아서 정확히 어떤 작동을 하는지 알 수 없다. 하지만 어떻게라도 그 구조를 들여다보고 싶기 때문에, 제공되어 있는 바이트코드를 사람이 읽을 수 있는 형태로 재구성해주는 decompiler 도구들을 이용해서 그 단편을 볼 수 있을 듯 하다. 평소에는 EtherVM을 사용하여 decompile을 하는데, 어째서인지 해당 Contract는 디컴파일을 제대로 하지 못한다. Panoramix라는 또다른 도구를 이용하여 구조를 확인할 수 있는데, 이 도구도 완벽하게 decompile을 하지는 않아서 일단 decompile이 되는 0xb82..0dd의 초기 구현체를 간략하게 확인하고, Panoramix로 어떤 업데이트가 이루어졌는지 간단하게 보려고 한다.

Decompile을 싹 돌려보니 코드 시그니쳐와 함수명이 굉장히 익숙하다. redeemUnerlying...repayBorrowBehalf...seize. Donkey와 같은 대출 프로토콜의 일종인 Compound의 함수명들과 일치한다. 그러면 Compound와 코드가 같을지 Decompile된 코드 중에 일부와 Compound의 CEther 코드를 비교해 보자.

function getCash() returns (var r0) {
	var var0 = 0x00;
	var var1 = var0;
	var var2 = var1;
	var var3 = 0x307d;
	var var4 = address(this).balance;
	var var5 = msg.value;
	var3, var4 = func_33C0(var4, var5);
	var temp0 = var3;
	var1 = temp0;
	var2 = var4;
	var3 = 0x00;
	var4 = var1;
    
	if (var4 > 0x03) { assert(); }
    
	if (var4 == var3) { return var2; }
	else { revert(memory[0x00:0x00]); }
}

function getCash() external view returns (uint) {
	return getCashPrior();
}
 
function getCashPrior() internal view returns (uint) { 
	(MathError err, uint startingBalance) = subUInt(address(this).balance, msg.value); 
	require(err == MathError.NO_ERROR); 
	return startingBalance; 
} 

위의 두 코드를 비교하면 당장에는 크게 비슷해 보이지 않을 것이다. 하지만 찬찬히 작동을 비교해 보면, 사실 두 코드가 완전히 같은 기능을 하는 코드임을 알 수 있다. CEther.sol의 getCash는 사실상 getCashPrior와 같은 함수이다. getCashPrior는 Contract가 가진 잔고액에서 현재 Transaction에서 받은 값을 빼고, 빼기 연산 과정에서 에러가 없을 경우, 뺄셈의 결과인 startingBalance를 내어놓는 함수이다. 위의 Decompile된 코드도 이 Contract의 잔고액(var4)와 현재 Transaction에서 받은 값을 (var5) 빼고 (func_33C0) 에러가 없으면, 연산결과를 내어놓는 함수이다.

그럼 getCashPrior는 어디갔냐고 하면, 아마 Compiler가 바이트코드로 바꾸는 과정 중에, 굳이 필요하지 않다고 판단해서 최적화되어 사라졌거나, 개발자가 임의로 제거했을 가능성이 있다.

다른 대부분의 코드들도 하나씩 비교해 보면, CEther.sol, CToken.sol의 구현들을 따라가고 있는 것을 확인할 수 있다. 이를 더욱 확실히 확인할 수 있는 곳은 Donkey 보안감사 보고서인데, 보안감사 보고서에 나와있는 코드의 단편들을 보면 Compound의 코드에서 Comp를 Donkey로 수정한 정도임을 알 수 있다.

Cream Finance가 Compound에서 파생된 것 처럼, Donkey 역시 Compound에서 시작하는 것으로 보인다.

간단하고 개략적인 분석을 통해 Donkey가 Compound의 Fork라는 것을 알아냈다. 그럼 이제, 최근에 일어난 Contract 업데이트들은 어떤 것들을 수정한 것인지 알아보자.

Panoramix를 이용해 초기의 구현 코드와 업데이트 된 코드를 각각 Decompile하고, 그 결과를 비교해 보았다.

감사 보고서에서 제안하는 대로, Event를 추가하는 것처럼 파악하기 쉬운 것들도 있었지만, Panoramix의 도구의 정확성 자체가 좀 떨어지는 편이라, 정확히 어떤 부분이 어떻게 수정 되었다고 알아보기는 어려웠다. 함수의 갯수가 줄어들고, call의 갯수가 줄어든 것으로 추측하건데, Optimization과 Audit에 따른 몇몇 마이너 패치가 적용된 것이 아닌가 한다.

정리하며

지금까지 코드 공개 이슈가 있었던 Donkey의 코드를 간단한 Decompile 기법을 이용해서 확인해 보았다. Donkey는 랜딩 프로토콜인 Compound의 Fork인 것으로 보이며, 현재 소스 코드를 Verify하지 못하는 이유는 Audit 결과에 따른 마이너 업데이트가 아직 진행 중이기 때문인 것으로 보인다. 한국에는 DeFi 생태계가 크게 자라나지 못하고 아는 사람들끼리만 하는 것이 많이 안타까웠는데, Donkey가 불편한 UI/UX 적인 문제로 접근을 해서 어느정도 사람들을 모으는 모습이 신기했다. 분석하면서 이래저래 아쉬운 부분도 보았지만, 건강한 비판과 성장을 통해 대한민국에 더욱 건실한 DeFi 생태계가 자라나길 기대해 본다.

다음에 시간이 난다면 Compound Fork의 운용의 핵심인 Comptroller나 PriceOracle이 어떻게 운영되고 있는지 한번 볼까 싶다.

* 본 포스팅의 내용은 어떠한 투자상품의 안정성도 보장하지 않으며, 이 글을 참조하여 이루어진 투자와 그로 인해 발생하는 그 어떠한 피해에 대해서도 책임지지 않습니다.

Front-running이란 주식이나 다른 금융 자산을 브로커를 통해서 매매 할 때, 매매 정보를 일괄 처리하게 될 브로커나 아직 처리되지 않은 매매 정보를 알고 있는 거래소 내부인이 먼저 유리한 방향으로 거래를 해서 이익을 보는 행위를 말합니다.

탈중앙화 거래소(DEX)에는 중개인이 없잖아?

하지만 Uniswap과 같은 탈중앙화 거래소에는 중개인이 없고 스마트 컨트랙트가 그 역할을 대신하기 때문에, 중개인이 먼저 거래를 하는 것은 불가능합니다. 여기서 우리는 Ethereum 트랜잭션이 바로 처리되지 않는 다는 사실에 주목해야 합니다. 우리가 Uniswap에 대한 거래 트랜잭션을 만들면, 그 트랜잭션은 대기 풀에 들어가 블록에 포함될 때까지 대기하게 됩니다.

Uniswap Front-running Bot은 그 타이밍을 노립니다. 처리되지 않은 트랜잭션들을 감시하고 있다가, Uniswap을 통한 매매 트랜잭션을 확인하면, 해당 트랜잭션보다 먼저 자신들의 공격 트랜잭션을 처리되도록 해서 유리한 매매를 한 다음, 공격 대상 트랜잭션이 처리 된 이후에, 매매분을 청산해서 이익금을 챙기는 방식인 것입니다.

위의 설명으로는 이해가 잘 되지 않을 수 있으니, 실제 예시를 하나 들어 공격이 어떤 방식으로 이루어지는 지를 보이고, 자세한 코드 분석으로 넘어가겠습니다.

우리의 피해자 0xd7680084e582ac04fb0243a489d2f709dbaeef06 (약칭 0xd768)은 Uniswap을 통해서 10 WETH와 동일한 가치를 지닌 FalconSwap Token (약칭 FSW)를 구매하고자 합니다. 따라서 구매 트랜잭션을 대기 풀에 올려놓습니다.

계속 대기 풀을 지켜보고 있던 Front-running bot은 위의 구매 트랜잭션보다 더 빨리 블록에 편입되도록 더 비싼 가스비를 지불하는 30 WETH 어치의 FSW를 구매하는 공격 트랜잭션을  대기 풀에 올려놓습니다. 이 때, 그냥 올리면 그 사이에 공격 대상 트랜잭션이 먼저 처리되거나 하는 등의 위험 상황을 없애기 위해 스마트 컨트랙트를 이용해 공격 트랜잭션을 만듭니다.

그와 동시에, Front-running bot은 공격 대상 트랜잭션과 같은 가스비를 지불하는 청산 트랜잭션을 만드는 데, 이 때 공격 대상 트랜잭션과 같은 가스비를 지불하는 이유는 공격 대상 트랜잭션이 처리되고 나서 청산 트랜잭션이 실행되도록 해야 이익을 얻을 수 있기 때문입니다. 만약, 공격 대상 트랜잭션보다 먼저 실행된다면, 구매했다가 다시 되파는 것으로 수수료만 지불한 꼴이 되기 때문입니다. 청산 트랜잭션은 구매한 모든 FSW를 다시 WETH로 바꾸는 것을 통해 이익을 실현합니다.

아, Front-running bot을 만드는 전략에는 다양한 방법이 있습니다. 제가 이번에 분석한 Front-running bot은 Mempool Hunter 전략을 구사하는 봇 중의 하나로, 꽤 오랫동안 유효하게 공격을 해왔으며, 지금도 공격을 하고 있는 봇입니다.

코드를 자세히 살펴보자!

개략적으로 Uniswap Front-running Bot이 어떻게 작동하는 지는 알았으니 본격적으로 코드를 살펴보며 어떻게 구현이 되어 있는지 알아봅시다. Front-running bot은  대기 풀을 지켜보고 스마트 컨트랙트에 공격 명령을 내리는 서버 사이드의 프로그램과, 공격을 수행하는 스마트 컨트랙트로 이루어집니다. 서버 사이드의 프로그램이 어떻게 작성되어 있는지는 알 길이 없으니, Ethereum 네트워크 상에 공개되어 있는 스마트 컨트랙트의 코드를 살펴보도록 합시다.

착하게 컨트랙트 코드를 Etherscan에 올려주었으면 좋았겠지만, 그럴 일은 없습니다. 따라서, 바이트 코드를 읽어 들여야 하는데, 그것은 사람에게는 꽤나 가혹한 일입니다. 고맙게도, 바이트 코드를 어느정도 사람이 읽을만한 코드로 바꾸어주는 Online Solidity Decompiler가 있습니다. 여기서 디컴파일한 코드와 예시로 든 트랜잭션을 기반으로 스마트 컨트랙트 코드가 어떻게 작성되어 있는지 살펴보도록 하겠습니다.

편의상 공격 대상 트랜잭션보다 먼저 수행되는 트랜잭션을 Opening 트랜잭션, 공격 이후 수행되는 청산 트랜잭션을 Closing 트랜잭션이라고 부르겠습니다.

Opening 트랜잭션

우선 Opening 트랜잭션에 실린 데이터는 다음과 같습니다.

0x0000000d000001b57100010000b973bf19253770ae139f7eda5f22c3538066eeac5db2100000000000000035291039930971a3b80000000000000001a055690d9db8000000000000000000310c19b9fe491977c000000000000000008ac7230489e80000

컨트랙트 호출 트랜잭션에서 데이터 앞의 8자리는 Method Signature입니다. 0x0000000d의 Method Signature를 가지는 Method는 func_01EC입니다. func_01EC가 어떤 일을 하는 Method인지를 살펴보면 나머지 값들이 어떻게 사용되는지 알 수 있을 것입니다.

일단 func_01EC로 가보니, msg.sender가 0xdd07249e403979bd79848c27aa5454c7e66bdee7이나 0xe73c1e4d7992a4a4f19f31531ae7b5dc352b74b0인지 확인하는 절차가 있습니다. 저 위의 두 주소가 우리가 분석하는 컨트랙트의 주인임을 알 수 있습니다.

if ((arg0 >> 0xdc) & 0xffff >= block.number % 0x2710) { goto label_0C8C; }

위의 코드로부터, 메소드 시그니처 이후의 0x00001b57값이 공격 대상 트랜잭션이 들어가게 될 블록 넘버 끝 네자리임을 알 수 있습니다. 만약 공격 트랜잭션이 공격 대상과 다른 블록에 들어가게 되면 모든 것이 소용 없기 때문에 포함된 코드입니다.

var var2 = (arg0 >> 0x08) ~ 0x5d6cce56246559ec8e60081c80e1300870d4ea42;
var var3 = 0x00;
var var4 = var3;
var var5 = var2 & 0xffffffffffffffffffffffffffffffffffffffff;

그 다음 부분에서 데이터의 일부를 가지고 xor 연산을 하는데, 이는 Uniswap의 페어 주소를 계산하는 부분입니다. 흥미로운 것은 그냥 Pair 주소를 제공할 수도 있었는데, 왜 저런 식의 연산을 수행하는지 이해하지 못하겠다는 점입니다.

어찌되었건 얻어낸 Pair 주소를 향해서 Method Signature 0x0902f1ac의 staticcall 을 합니다. 0x0902f1ac는 getReserves()의 메소드 시그니쳐입니다.

그렇게 얻어낸 WETH의 Reserve는 서버가 제공한 인자값 00000000000000310c19b9fe491977c0와 비교합니다. 이것을 10진수로 표현하면 904.7623921164402인데, 이는 Reserve값에서 딱 10 WETH, 공격 대상 트랜잭션에서 구매하고자 하는 양을 더한 값입니다. 코드에서는 이 값보다 WETH Reserve가 작아야만 실행되도록 한 것입니다. 이를 통해서 다른 트랜잭션의 난입으로 손해를 보는 상황을 막는 것입니다.

공격 가능성을 충분히 확인 한 이후에, func_26B5에게 구매에 사용할 WETH의 양, 현재 WETH Reserve, 현재 FSW Reserve를 인자로 주어 가격을 계산하게 합니다.

function func_26B5(var arg0, var arg1, var arg2) returns (var r0) {
    var var2 = arg0 * arg2 * 997;
    var var3 = arg0 * 997 + arg1 * 1000;
    return var2 / var3;
}

위의 함수를 보면 var2는 구매할 WETH에 수수료인 0.3%를 뺀 값과 FSW Reserve를 곱해 상수 K를 구하고, var3에서 거래 후 WETH Reserve 총량을 구해서 나누는 것을 통해 arg0만큼의 WETH로 얼마 만큼의 FSW를 구매할 수 있는지 계산합니다.

그리고 같은 함수를 이용해서, 공격 이후에 공격 대상 트랜잭션으로 구매하게 될 FSW의 양도 계산합니다.

공격 대상이 구매에 사용할 WETH의 양, 공격에 사용할 WETH의 양, 그리고 각각의 구매에 따른 FSW 구매 양을 모두 알게 되었으므로, 또 func_26B5를 이용하여 공격 대상 트랜잭션이 수행된 이후 Closing 과정에서 얻게 될 수익을 계산합니다.

여기서는 공격 트랜잭션이 30 WETH로 111879.58729439399 FSW를 구매하였고, 공격 대상 트랜잭션은 10 WETH로 35698.50508403116765319 FSW를 구매하였으므로, 그 이후에 팔게 된다면,

FSW Reserve = 3458775.179288110579731962 (Original Reserve) - 111879.58729439399 (Bought by Bot) - 35698.50508403116765319 (Bought by Victim) = 3311197.0869096853
WETH Reserve = 894.762392116440168384 (Original Reserve) + 30 (Sold by Bot) + 10 (Sold by Victim) = 934.7623921164

In func_26B5,
var2 = 111879.58729439399 * 934.7623921164 * 997
var3 = 111879.58729439399 * 997 + 3311197.0869096853 * 1000
var2/var3 = 30.46303739508232

이 됩니다. 따라서 약 30.46 WETH로 0.46 WETH의 이익을 보게 되는데, 이 때, 이는 투자 원금 30 WETH에 공격 비용인 0x0000b973 Wei를 합친 것보다 크기 때문에 공격을 하게 됩니다. 만약, 가스비도 못 건진다면, 공격을 하지 않는 것이지요.

공격이 이익이 될지에 대한 계산이 끝나면, func_26DE에서 공격을 수행합니다. 이 함수가 하는 일을 간단합니다. WETH를 Uniswap으로 보내고, Swap을 진행합니다. 다만 여기서 옵션을 주기에 따라서, 다른 주소로 Swap의 결과물을 보내는 분기를 만들어 두었는데, 어디에 사용하는 지는 잘 모르겠습니다.

Opening 트랜잭션에서 재미있게 볼 만한 부분은 공격을 진행하면서, 공격 이득이 낮거나, 가스비 상승으로 공격이 실패했을 때, 손해를 최대한 줄이기 위해서 func_0CB2를 호출하는 부분입니다. func_0CB2에서는 미리 CREATE2로 만든 컨트랙트를 호출하는데, 호출된 컨트랙트를 보면 SELFDESTRUCT를 호출하는 것이 다입니다. 이는, 반복적으로 SELFDESTRUCT 컨트랙트를 호출하는 것을 통해서, 실패한 공격에 낭비한 가스 비용을 최대한 많이 회복하는 것입니다. SELFDESTRUCT가 왜 가스비를 돌려주는 지에 대해서는 이쪽을 참조하시기 바랍니다.

Closing 트랜잭션

Closing 트랜잭션의 경우에는 메소드 시그니쳐 0xbea175cb로 func_0796에서 처리되는데, Opening처럼 조심스럽게 무언가를 계산하기 보다는, 이미 공격 대상 트랜잭션이 처리되어 WETH를 지불하였는지 정도를 확인 한 후 바로 func_29EE에서 Swap을 진행하며, 이 과정 중에 실패를 하거나 가스비가 초과되는 경우, 가스비를 최대한 줄이기 위해 Opening 트랜잭션에서와 같이 func_0CB2를 이용하여 SELFDESTRUCT를 호출합니다.

정리하며

지금까지 Uniswap Front-running Bot 중 Mempool Hunter 전략을 사용하는 봇의 스마트 컨트랙트를 일부 분석해 보았습니다. 관리를 위한 다른 메소드들도 많고, Closing의 경우에도 여러 옵션으로 관리 옵션을 만들어두긴 했는데, 분석을 시작하게 된 이유가 봇의 모든 작동을 이해하자는 것이라기 보다는 서버로부터 어떤 정보를 받아 어떻게 처리하여 공격을 결정하는 가하는 큰 로직을 이해하기 위함이라 큰 가닥에서만 분석을 했습니다. 제가 분석을 하는 흐름을 따라 그냥 글을 쓰다보니 전반적으로 횡설수설하고, 코드 참조도 매우 부실합니다.

분석을 진행하면서 한 가지 의문점이 있었는데, 공격을 진행할 시에, 일반적으로 공격 대상과 같은 액수의 금액을 투입해 이익을 보는 식으로 할 것이라고 생각했는데, 실제로 작동을 보니 서버에서 임의의 예산을 설정하여 공격을 합니다. 위의 경우에서는 10 WETH 어치를 사는 트랜잭션을 공격하기 위해 30 WETH를 사용했지요. 공격 예산을 어떻게 계산하는 지가 의문입니다.

꽤 오랜시간 동안 공격을 해왔던 봇이라 꽤 복잡할 것이라고 생각했는데, 생각했던 것보다 훨씬 단순한 구조라 놀랐습니다. 나중에 시간이 된다면, 직접 간단한 형태의 모방 컨트랙트와 서버 프로그램을 만들어 소액으로 PoC 해보는 것도 나쁘지 않겠다는 생각을 했습니다.

• 두서없는 글이라 이해가 안되거나 궁금하신 부분이 있으시다면 언제든지 페이스북 메시지를 주시거나, do_not_reply@ieee.org로 이메일 주시면 답변 드리겠습니다.

게임스탑은 뭐고, 게임스탑 사태는 뭔데?

게임스탑 사태에 대해서 논하기 전에 게임스탑이라는 것이 무엇인지부터 알아야겠지요. GameStop은 1984년 텍사스에서 시작된 미국의 최대의 오프라인 비디오 게임 전문 소매 체인입니다. 대부분의 오프라인 소매업체들이 그러하듯, 게임스탑도 온라인 게임 판매 플랫폼에 밀려 서서히 죽어가던 중이었습니다.

한편, 미국 커뮤니티 사이트인 Reddit의 주식 게시판인 WallStreetBets의 유저들은 2020년 4월 경에 게임스탑의 주식이 저평가되었고, 시장 유통 주식 물량의 84%가 이미 공매도 되었다는 사실을 깨닫고 매입하고 있었으나, 그 여파는 미미했습니다.

2020년 10월경에는 공매도 세력이 그들의 매수에 아랑곳하지 않고 공매도를 두 배로 늘린 사실을 알아내고, (이미 시장 유통 주식 물량의 120% 이상이 공매도 되고 있었습니다.) 공매도 세력을 공격하기로 결의합니다.

2020년 11월에는 반려동물 용품업체인 츄이의 대표인 라이언 코헨이 게임스탑의 지분을 13% 정도 대량 매입하면서 많은 개인 투자자들이 게임스탑에 관심을 가지고 투자를 하기 시작합니다. 이듬해 1월에는 라이언 코헨이 게임스탑의 이사회에 합류, 온라인 판매 주력으로 경영 노선을 전환하면서 게임스탑의 주식 가치가 더욱 상승하게 됩니다.

Tomorrow am at 11:30 EST Citron will livestream the 5 reasons GameStop $GME buyers at these levels are the suckers at this poker game. Stock back to $20 fast. We understand short interest better than you and will explain. Thank you to viewers for pos feedback on last live tweet

— Citron Research (@CitronResearch) January 19, 2021

이런 와중에, 시트론 리서치라고 하는 미국의 헤지 펀드가 1월 19일에 “게임스탑 주식을 지금 사는 사람들이 주식판에서 호구인 5가지 이유”라는 주제로 라이브 스트리밍을 진행하겠다는 트윗을 올리며 게임스탑 매수자들을 비난합니다.

WallStreetBets의 게임스톱 투자자들은 화가 났고, Melvin Capital과 Citron Research와 같이 게임스탑에 공매도를 한 헤지 펀드를 공격하기 위해서 간단한 전략을 사용합니다. “한번 사면, 절대로 팔지 않는다.”

이미 게임스탑에 걸려있는 공매도는 시장 유통 물량의 140% 이상이었기 때문에, 개인 투자자들이 게임스탑 주식을 대량 매수하게 되면, 공매도를 한 기관들은 빌린 주식을 갚기 위해서 상당히 높아진 가격에 주식을 매입(숏 스퀴즈)하기 때문에 엄청난 손실을 보게 되는 것입니다. 그뿐만 아니라 개인 투자자들은 게임 스탑의 콜 옵션 또한 대거 매입해서 금융사들이 콜 옵션을 헤지하기 위해 주식을 사들이는 감마 스퀴즈까지 일으키고자 했습니다.

그 결과 게임스탑의 주식은 하늘 높이 상승했고, 가격 상승률에 눈이 돌아간 더 많은 개인 투자자들이 진입하기 시작하면서, 게임스탑 주식은 한때 480달러까지 치솟습니다. 치솟은 가격에 몇몇 헤지 펀드들이 무너지기 시작했습니다. WallStreetBets의 공격 목표 중 하나였던 Melvin Capital은 공매도 포지션을 청산하였으며, Citron Research도 더이상 매도 보고서는 내지 않겠다는 발표를 했습니다.

헤지 펀드가 손실을 보는 이 절묘한 타이밍에, 미국의 주식 거래 중개 플랫폼인 로빈 후드가 게임스탑 주식을 포함한 몇몇 주식의 매수 금지 정책을 발표해서 로빈 후드와 헤지 펀드가 결탁하여 개인 투자자를 농락하고 있는 것이 아니냐는 이야기도 나왔지만, 이는 그냥 옵션과 주식 거래량 증가에 따른 증거금이 부족해서 발생한 문제였습니다.

앞으로는 어떻게 되는데? 게임스탑 주식 사라고?

제가 주식 전문가는 아니므로, 여러 다른 참고 자료에 있는 내용에서 추측을 해 보겠습니다. 일단 Ortex에 나와 있는 1월 27일 공개된 자료에 따르면, 시장 유통 물량 대비 공매도 비중은 약 130%로, 13% 감소한 수치이기는 하지만 생각보다 매도 포지션을 많이 청산한 것은 아닌 것으로 보입니다.

현재의 게임스탑 가격이 버블이라는 것은 자명하고, 마땅한 출구 전략 없이 달려나가고 있는 것으로 보이기 때문에, 헤지 펀드들은 투자자 집단이 와해하여 패닉 셀로 이어지기를 기다리고 있는 듯 보입니다. 게임스탑 사태가 더욱 이슈화 될수록 더 많은 사람이 게임스탑 주식을 사려고 할 것이고, 그렇게 되면 지금과 같은 가격 통제는 어려워질 것이기 때문입니다.

그래서 제 개인적인 생각으로는 헤지펀드들이 주식 대여나 블록딜을 통해서 버텨내고, 그 이후의 패닉 셀로 끝나는 정도가 되며, 이후에도 헤지 펀드에 대해서 숏 스퀴즈를 노린 몇 차례의 크고 작은 주식 매집 단체 행위가 일어나지 않을까 싶습니다.

또 다른 의견으로는, 헤지 펀드들이 결국 버티지 못하고, 큰 손실을 입어 손실의 연쇄로 헤지 펀드에서 보험사로, 보험사에서 투자은행으로 연쇄적인 금융 쇼크가 발생해 경제 위기가 오는 것이 아니냐는 시각도 있습니다.

그래서 이게 다 무슨 의미일까?

게임스탑 사태를 굳이 따로 글로 다룰 만큼 주목을 하게 된 이유는 크게 세 가지입니다. 첫 번째는 이 사태를 서브프라임 모기지 사태 이후의 월가에 대한 분노가 만들어낸 금융 현상으로 해석할 수 있다는 점입니다. 서브프라임 모기지 사태로 인해 많은 사람의 삶이 피폐해진 것은 자명한 사실입니다. 그에 반해 세금을 투입해 살린 월스트리트의 펀드 매니저들은 벌어진 사태에 대한 책임을 하나도 지지 않고 잘 살았습니다. 이러한 것에 대한 분노로 월가 점령 시위가 일어났지만, 곧 와해하고 잊혔습니다. 그런데 이것이 10년이 지난 지금에 와서 주식시장에서 표출되고 있다는 점이 굉장히 흥미로웠습니다.

두 번째는 특정한 기관이나 개인이 아닌 이익을 추구하는 일반 사람들의 집합이 기관을 상대로 어느 정도의 위협을 가했다는 점입니다. 제가 게임스탑 사태를 조사하면서 WallStreetBets의 많은 글을 읽었지만, 게임스탑의 주식이 저평가되어 있음을 알고, 공매도가 많음을 눈치채고, 주식을 매집하는 과정에서 어떠한 주도적인 개인이나 마일스톤이 되는 게시글이 있다기보다는 자연스러운 소통의 흐름 속에서 기관을 공격하기 위한 계획을 만들고 성공 시켰다는 것입니다. 이것이 만약 단발적이지 않고 기관에 대응하는 지속적인 움직임이 된다면, 현재 주식시장에서 거의 무소불위의 힘을 구사하는 기관을 견제하는 또 하나의 세력이 될 수 있지 않을까 싶습니다.

아직 사태는 진행 중이고, 어떤 결말이 날지는 아무도 모릅니다. 버티지 못하고 패닉 셀로 가며 또 다른 거대 자본 승리의 역사가 쓰이게 될지, SEC가 개입하게 될지, 아니면 정말로 완전히 숏 스퀴즈가 나며 개인 투자자들의 승리로 끝이 나게 될지 주시해볼 만 합니다.

* 주식은 비전문분야라 틀린 내용이 있을 수 있습니다. 틀린 내용은 do_not_reply@ieee.org로 메일 주시면 즉시 반영하여 수정하겠습니다. 본 글은 어떠한 주식의 매매나 금융 상품의 투자를 권유하지 않으며, 관련 주식의 투자로 인한 손실의 책임은 전적으로 독자에게 있습니다.

Just-In-Time 컴파일러 사용

Python은 인터프리터 언어입니다. 인터프리터 언어는 코드를 한 번에 한 줄씩 읽어 들여서 실행하는 식이지요. 그렇다 보니 매번 코드를 탑재하고 기계어로 바꾸는 과정을 거치다 보니 컴파일러를 사용하는 언어에 비해 그 실행 속도가 느릴 수밖에 없습니다. 하지만 미리 소스 코드를 바이트 코드 형태로 변환해서 저장해 놓는 Just-In-Time 컴파일러를 이용하면 어느 정도 이를 개선 할 수 있습니다.

코드 빨리 돌리고 싶으면, PyPy 돌리면 대충 될 겁니다.
귀도 반 로섬, Python의 창시자

Python의 JIT 컴파일러에는 Numba, PyPy, Psyco 등이 있는데, 개인적으로는 설치도 간편하고 코드를 수정해주지 않아도 되는 PyPy가 가장 사용하기 편리했던 것 같습니다.

대부분의 경우에서 PyPy는 Cython이나 Python에 비해 2-3배 정도의 성능 향상을 보여주지만, File 읽고 쓰기가 잦은 경우나, Unicode를 다룬다거나, Tuple을 정렬하는 등의 경우, C 확장 모듈을 호출하는 등의 경우에는 Python이나 Cython보다 느린 경우가 나온다고 합니다. 운 좋게도, 저의 경우에는 파일 읽고 쓰기가 잦은 편임에도 불구하고, PyPy를 적용하는 것을 통해 약 2.1배 정도의 성능향상을 보여 주었습니다.

여러 Python JIT나 실행 환경을 시도해보고 가장 좋은 성능을 내는 실행 환경을 이용하는 것이 가장 좋다는 것으로 결론을 낼 수 있겠습니다.

List Comprehension 사용

output = []
for element in large_list:
	if some_filter(element):
		output.append(element)

어떤 리스트에서 조건에 맞는 값을 추출한 새로운 출력을 만들어 내는 코드를 그냥 작성한다면 위와 같을 것입니다. 위의 코드는 조금 복잡해 보이니, filter를 써서 조금 더 단순하게 만들면 다음과 같습니다.

output = list(filter(lambda x: some_filter(x), large_list)

저는 위와 같이 많이 작성해 오고는 했는데요, 전자가 후자보다 아주 조금 빠릅니다. 하지만 위의 두 코드 모두 느린 편입니다. 아래와 같이 List Comprehension을 사용하면 약 2배 정도 더 빠르게 값을 추려낸 새로운 리스트를 얻을 수 있습니다.

output = [x for x in large_list if some_filter(x)]

String 합치기 속도 최적화

저는 Python에서 String을 합칠 때는 아무 생각 없이 다음과 같은 Naive Concatenation을 사용하곤 했습니다.

out_str = ''
  for num in xrange(loop_count):
    out_str += `num`

하지만 이런 방식은 여러 번 반복하게 되면, 매번 new_string을 메모리에 올리는 과정을 거쳐야 하므로 매우 느려집니다. 저의 경우에는 문자열 List를 만들어서 맨 마지막에 join을 하는 것을 통해서 속도를 상당히 개선할 수 있었습니다. 55만 개의 데이터를 합치는 데에 2400초 정도의 시간이 걸렸었는데, 이를 약 800초 정도로 줄일 수 있었습니다. (순수하게 문자열 합치기만 한 것이 아니라 튜플 탐색 등이 포함된 시간이긴 합니다.)

str_list = []
  for num in xrange(loop_count):
    str_list.append(`num`)
  return ''.join(str_list)

String 합치기 속도에 대해 알아보면서 알게 된 것 중에 놀라운 것은, 임시 파일을 만들어서 값을 써놓고 파일의 값을 한번에 불러오는 방식이 위의 리스트를 이용한 방식보다 약 30% 정도 빠르다는 사실입니다.

Multiprocessing 사용

컴퓨터들은 대부분이 여러 개의 코어를 가지고 있습니다만, Python은 하나의 코어만을 활용하여 연산을 수행합니다. 동시성을 충분히 고려하여 안전하게 작동시킬 수 있는 코드라면, Multi-processing을 통해서 연산에 사용하는 코어의 개수를 늘여 더 빠르게 연산 결과를 얻을 수 있습니다. 그 성능 향상은 코어의 개수에 비례한다고 합니다.

아직 제가 작성 중인 코드에는 적용을 해보지 못하였지만, 조만간에 적용해 보고 그 성능 향상 효과에 대해 글을 쓰도록 하겠습니다.

알고리즘 설계 최적화

위에서 설명했던 방식들은 대부분이 어떤 도구를 이용하여 설계의 변경 없이 속도를 개선하는 방법들입니다. 하지만 대부분의 경우에는, 설계된 프로그램의 시간 복잡도를 최적화하여 극적인 성능개선을 얻을 수 있는 경우가 많았습니다. 코드마다 설계와 최적화 방식이 다르기 때문에 정확히 예를 들기는 어렵습니다만, 설계의 시간 복잡도를 고려해 보고, 어떻게 하면 시간 복잡도를 낮출 수 있을지 고민하는 과정이 필수적으로 필요합니다.

참고할 만한 자료

Python Wiki - Performance Tips
Efficient String Concatenation in Python
When is PyPy slower than Python? - Codeforces
The Little Book of Python Anti-Patterns — Python Anti-Patterns  documentation
Sebastian Witowski - Writing faster Python
Python Interpreters Benchmarks

또 다시 새 블로그. 이번에는 잘할 거야.

제 블로깅의 역사는 중학교 때로 거슬러 올라갑니다. 친구들이랑 같이 네이버 블로그를 했었죠. 주로 게임이나 애니메이션 리뷰를 했었는데, 당시에 AAA급 게임 프랜차이즈가 쏟아져 나올 때여서 글 쓸 건 정말 많았고, 중학생이 딱히 할 게 뭐가 있었겠습니까. 그 때는 정말 하루종일 블로그 글감을 찾고, 블로그 스킨을 만들고, 댓글에 답글 달고 했던 것 같습니다. 작년에 잠시 네이버 블로그를 하면서 과거의 친구들 블로그를 가보았는데, 블로그를 지금까지 계속하는 친구는 한 명밖에 남지 않았더군요.

대부분의 제 친구들이 그러했듯, 저도 나이를 먹어가면서 다른 재미있는 취미들이 생기면서 블로그와 멀어져갔습니다. 떠오른 글감이나 생각은 트위터나 페이스북에 곧바로 토해내듯 쓸 수 있었기 때문이기도 합니다. 가끔씩 장문의 글을 읽고 쓰는 능력이 서서히 퇴보해가고 있다는 두려움이 오면, 블로그 플랫폼 중에 아직 써보지 않은 마음에 드는 플랫폼을 골라서, 블로그를 꾸며 글을 한편 쓰고는 다람쥐 마냥 잊어버리곤 했습니다.

안타깝게도, 도토리를 묻으면 도토리 나무가 자라 종국에는 자신에게 도움이 되게 하는 다람쥐와 달리, 제 블로그에서 글 나무는 자라지 않았습니다.

그럼에도 불구하고, 이번에도 또 블로그를 만들었습니다. 별 다른 이유는 아니고, 서버가 한 대 놀고 있는데, 그게 너무 억울해서 블로그를 얹어보았습니다. Jekyll이나 Hugo를 고민했지만, 너무 강력한 커스터마이징 기능을 가지고 있어서 블로그 꾸미는 데 모든 힘을 쏟다가 글을 못 쓰고 또 하루살이 블로그로 전락해 버릴 것 같기도 하고, 전에 Jekyll 기반 블로그를 했을 때 Markdown으로 써서 퍼블리싱을 하는 과정이 너무 번거로워 글을 쓰지 않게 되는 것 같기도 해서 온라인으로 바로 글을 쓸 수 있고, 적당히 테마를 가져다 쓰면 예쁜 Ghost를 설치했습니다. 매번 새 블로그를 만들 때마다 하는 다짐이지만, 이번에는 잘 할겁니다. 아마도.

2020년 리뷰 - 잃어버린 20년

2020년은 모두가 COVID-19로 고생한 한 해였습니다. 당연하게 여기던 것들의 가치는 그것이 더이상 당연해지지 않을 때 알게 된다는 말을 뼈져리게 느끼게 해 준 한 해 였습니다. 원래부터 대부분의 식사를 배달의 민족에 외주를 주고, 물건은 쿠팡으로만 구매하며, 대부분의 시간을 집에서 보내는 제가 이 정도로 영향을 받았다는 것은 직접적인 타격권에 있는 사람들의 생활에는 얼마나 큰 영향이 있었는지 상상도 하기 어렵습니다. 많은 전문가들이 더이상 COVID 이전의 생활로는 돌아갈 수 없다고는 하지만, 2021년 말에는 블로그에 여행 후기를 쓰면서 그래도 안전하게 사람을 만날 수 있는 정도로는 돌아갔으면 하는 바램입니다.

2020년은 제게 있어서 회사 운영을 어느정도 정리하고, 원래의 꿈인 대학원 진학으로 진로를 전환한 해입니다. 원래 회사 설립 당시부터 1년 정도만 대표를 맡아 하면서 제품화 단계까지만 관여를 하기로 약조가 되어 있기도 했고, 저 자신이 사업과 대표자라는 것에 대한 내적 정의가 끝나서, 제가 대표자의 자리에는 맞지 않는 사람이라는 것을 깨달았기 때문에 회사는 어느 정도 정리를 했습니다. 사업을 완전히 접었느냐고 하면, 그것은 또 아닌데, 이런 이야기는 하기 시작하면 너무 길어지기 때문에 나중에 별도의 글로 다루어볼까 합니다.

어린 시절부터 대학원에 진학해 박사가 되는 것을 꿈꿔왔습니다만, 막상 대학원에 진학하려고 하니 두려웠습니다. 학부 시절 인턴 활동을 하면서 많은 박사 과정생들이 자신의 자질을 의심하며 괴로워하고, 중도 하차하는 것을 보아왔기 때문입니다. 5년은 어찌 보면 짧은 시간이지만, 소중한 시간이니까요. 무엇보다 제게 있어서 대학원 진학을 망설이게 하는 가장 큰 질문은 이것이었습니다.

연구가 재밌다 정도의 동기부여로 박사과정을 마칠 수 있을까? 해결하고자 하는 큰 질문이 있어야 하는게 아닐까?

저는 대학원 면담에 가서 교수님께 질문을 드렸고, 교수님은 “그런거 있는 사람이 약간 특이한거다. 원래 그 정도의 동기부여로 다들 대학원에 입학하고, 하다보면 그런 것은 찾아진다.”라는 대답을 주셨고, 그래서 대학원에 입학을 결정 했습니다. 어찌되었건 논문 읽고 연구하는게 즐거운 것은 사실이니까요.

1년이 지난 지금도 탐구할 궁극적인 질문은 고사하고 연구 주제를 스스로 찾는 방법조차 모르겠습니다. 한 8월 정도까지는 그 사실이 저를 굉장히 초조하게 했습니다. 하지만, 고민해 본 결과 그냥 제 경험이 아직 부족한 것으로 생각하고 2년 정도 더 열심히 논문을 읽고 연구를 해 보기로 했습니다.

궁극적인 질문을 찾지는 못했지만, 그렇다고 대학원에 와서 아무 것도 건진 것이 없는 것은 아닙니다. 2020년에 가장 크게 배운 것은 글쓰기의 소중함이 아닐까 합니다. 대학원에 입학할 때 아무도 제게 글쓰기가 연구의 중요한 부분이라고 가르쳐 주지 않았습니다. 하지만 제가 논문 작업을 하면서 가장 어려웠던 부분은 연구 이론이나 그 구현 보다는 논문 쓰기 바로 그 자체였습니다.

일주일동안 급하게 쓴 짧은 에세이 수준이긴 했지만, 정말 많은 부분이 비어있거나 어색했고, 많은 피드백을 받았습니다. 대학원을 다니면서, 기술 발표나 연구 노트, 리포트 등으로 글을 쓸 일이 정말 많았습니다. 그 글들을 어떻게 구성하고, 어떤 방식으로 서술해 나가야 하는지 일일이 교수님께 여쭈어 볼 수 없어서 난감했습니다. 저는 주로 해외 대학에서 설강되는 기술 발표하는 법이라던가, 논문 쓰는 법에 관한 논문을 읽으면서 가까스로 할 수 있었습니다. 이제는 제 설계 선택에 대해서 어느정도 타당한 이유를 들어 설명할 수 있게 되었다고 생각하는데, 저는 이것이 2020년에 대학원에 와서 가장 크게 배운 점이라고 생각합니다.

개인적으로, 제가 다니는 대학원에는 기술 발표나 논문을 쓰는 방법에 대한 강의가 따로 개설되어 있지 않은데, 전공과 관련없는 학부 수업의 연장선같은 수업을 진행할 바에는 논문 쓰는 법을 가르치는 과목을 몇 개 정도 개설하는 것도 좋을 것 같다고 생각했습니다. 모든 수업이 재미있는 편이긴 하지만, 제 세부전공과 연관없이 졸업학점을 채우기위해 수업을 들으며 연구 활동에 지장이 가는 것이 불편할 때가 간혹 있습니다.

원래 매년 여름 시즌에 한번, 겨울 시즌에 한번 정도 이곳 저곳 여행을 가는 편인데, 2020년은 COVID 때문에 어디 여행을 가지도 못하고, 집에 박혀서 공부만 하면서 지낸 것 같습니다. COVID가 아니었다면, 교수님을 따라 PLDI에 따라가서 발표도 보고, 런던 구경도 하고 했을 텐데 참 안타깝습니다. 제가 이번에 모 학회에 논문을 준비 중인데 그 논문이 Accept 되어서 발표를 하러 가게 될 즈음에는 COVID가 좀 잠잠해지길 바라는 마음입니다.

첫 글이라고 너무 힘을 주어서 글을 적었네요. 2020년의 회고라고 했는데, 막상 2020년을 회고해보니 정말 집에 있었던 것과 연구를 했던 것 외에는 거의 기억에 남는 것이 없는 것을 보니 정말 2020년은 ‘잃어버린 20년’이라고 부를 만하다고 생각했습니다. 오늘 보니 일일 COVID 감염자수가 300명대로 떨어졌더군요. 전문가들도 3차 대유행이 정점을 지났다고 조심스레 이야기하고 있는 것을 보니 참 다행이라고 생각합니다. 아무쪼록 2021년에는 추가적인 대유행없이 이 역병을 잘 넘어가는 해가 되었을면 좋겠습니다.