현재 Code4rena에서 5일 정도 남은 프로젝트에 참가해보려 한다. 시간이 얼마나 걸릴지 모르지만 일단 도전해보는걸로!
1. 프로젝트 파악
코드를 보기 전에 공식 홈페이지와 독스를 보면서 프로젝트의 목적과 핵심 컨셉을 먼저 파악하면 코드를 읽을 때 좀 더 편하게 이해할 수 있을 것이다.
이더리움이 PoS로 전환하면서 Staking의 중요도가 상승하고 있다. 현재 Lido가 42%로 스테이킹에서 가장 많은 비중을 차지하지만 중앙화될 수 있는 우려가 존재한다. 코빗 리서치에 따르면 Merge 업그레이드 이후 이더리움 네트워크에서 생성되는 블록 중 65%가 미국 재무부 산하 규제기관인 OFAC(Office of Foreign Asset Control, 해외자산통제국)의 제재를 준수하는 블록인 것으로 확인되었다. 이 비율이 Merge 직전에는 10% 미만의 수준이었으며, 규제를 준수하는 노드를 선별하는 것이 아니냐는 지적이 나오고 있다.
이러한 상황 속에서 Stakehouse는 개인이 node 없이 ethereum validator가 되는 것을 도와줌으로써 진입장벽을 낮추고, 이더리움 스테이킹의 중앙화를 막고자 하는 목적이 있는 것으로 보인다. 32ETH를 스테이킹 하면 dETH와 SLOT 토큰으로 나뉘게 되며, 두 토큰을 통해 스테이킹 이자와 네트워크 수수료 및 MEV를 얻을 수 있도록 하는 것이 특징이다. 또한 아직 출시하지 않았지만 Lido처럼 32ETH 이하로도 리퀴드 스테이킹이 가능하도록 할 예정이다.
Fees & MEV Pool / Protected Staking Pool
Stakehouse는 여러 LSD Network로 구성되어 있다. 각 LSD Network는 두 가지 풀로 구성된다. 첫 번째는 Fees & MEV Pool로 각 validator는 풀에 참여하기 위해 4ETH가 필요하며 일반 유저는 금액에 상관없이 예치할 수 있다. 예치한 금액에 비례하여 LSD Network에서 발생하는 MEV 수익과 수수료의 50%를 가져갈 수 있다.
두 번째는 Protected Staking Pool로 각 validator는 풀에 참여하기 위해 24ETH가 필요하며 일반 유저는 금액에 상관없이 예치할 수 있다. 일반 유저는 예치한 ETH 수량 만큼 dETH를 받게 되고 이는 이더리움과 1:1 교환이 가능하다. 이 풀에 예치하면 자신이 예치한 만큼 이더리움 스테이킹 보상을 얻게 된다.
각 네트워크에 풀이 1개 씩 존재하며, 네트워크에 있는 풀은 각각 Giant 풀에 의해 관리된다.
WorkFlow
Node Runner가 두 개의 풀에 참여하기 위해 총 4ETH를 Smart wallet에 예치하면 Liquid staking manager를 통해 관리된다. 일반 유저들은 자신이 원하는 풀에 ETH를 제공하면 수량과 비례하여 LP 토큰을 받을 수 있다.이 때 LP 토큰은 LP Token Factory에서 생성되고 유저들의 자금 또한 Liquid staking manager가 관리한다. Smart wallet에 총 32ETH가 모이면(Node Runner 4ETH + MEV pool 4ETH + savETH pool 24ETH) Stakehouse protocol에 의해 이더리움 재단으로 이더가 전송되며 스테이킹이 시작된다. 네트워크 수수료와 MEV 수익은 Syndicate에서 관리된다. 총 수익은 Fees & MEV Pool과 Smart wallet에 각각 50% 씩 분배된다.
2. Scope
Files in scope
3. Gas Optimizations
컨테스트가 시작되면 Code4rena 측에서 간단한 이슈와 gas optimization 결과를 정리해서 리포트를 내준다. 이전까지 있었던 사례들을 바탕으로 gas 최적화를 할 수 있는 부분을 찾아주고 프로그램을 돌려서 나온 가벼운 이슈들을 알려준다. Code4rena 초기에는 Gas Optimization을 찾는 것으로도 쏠쏠(?)했기 때문에 이것만 찾는 사람이 있었다고 한다. 난이도가 낮기도 하고 프로그램의 도움을 받아서 금방 할 수 있기 때문이다. 하지만 현재는 여러 프로젝트들을 거치면서 프로그램이 대부분 찾아내서 이런 사람들은 줄어들고 오히려 중요한 결함을 찾는 것에 집중할 수 있도록 도와준다고 볼 수 있다. Gas Optimizations에 대해 아직 익숙치 않은 내 입장에서는 리포트를 읽으면서 가스 최적화 케이스를 알 수 있어서 좋았다.
기억에 남는 부분이 있는데, unsigned integer를 비교하기 위해 >0 대신 !=0 을 사용하는 것이 가스비를 더 줄일 수 있다는 것이다. 한 가지 의문은 !=0을 사용하면 마이너스 값이 들어갔을 때에도 통과가 돼서 오히려 위험한 건 아닌가 하는 부분이였다. 또 정확히 어떤 부분이 다르길래 가스비를 절약할 수 있는지, 절약하면 얼마나 절약할 수 있는지에 대해 궁금했고 이를 디스코드에 질문한 결과 간단한 테스트 결과를 올린 깃헙 페이지를 공유받을 수 있었다. 0.8.12 버전의 경우 6정도 가스를 절약할 수 있었고, 아래 사진에서 볼 수 있듯이 !=0 을 사용하면 DUP1(0X80)과 GT(0X11)를 사용하지 않기 때문에 가스를 절약할 수 있다.(매우 적은 수치이긴 하다.) 하지만 0.8.13으로 버전이 넘어가면 가스는 다시 동일해진다. 비중이 큰 부분이 아니라 그냥 그렇구나 하고 넘어가면 될 것 같다.
출처 및 참고자료
