[이번 KelpDAO rsETH 해킹을 막을 수 있었을까?]
이번 rsETH 해킹에 대한 레이어제로와 KelpDAO의 공식 입장(
https://x.com/LayerZero_Core/status/2046081551574983137?s=20, https://x.com/KelpDAO/status/2046332070277091807?s=20)이 공개되었습니다. 결과론적인 이야기지만, 더 나은 보안 세팅이었다면 이 공격을 막을 수 있었을까요?
가장 이상적인 방향이라면 1/1 DVN 세팅 (레이어제로 랩스가 운영하는 밸리데이터) 를 쓰지 않고, N-of-M 형태의 밸리데이터 셋을 구축하는게 가장 이상적이었겠지만, 현실적인 상황에서 레이어제로 랩스가 추가 가드레일로 이 공격을 막을 수 있을지에 집중해서 분석해봅시다.
<공격의 형태>
레이어제로 랩스가 운영하는 DVN 노드는, 일반적으로 내부 RPC 노드를 포함한 다양한 RPC에서 트랜잭션 결과를 교차 검증해, 단일 RPC로 인한 실패나 해킹을 방지하는 시스템을 구축하고 있었습니다. 공격자는 레이어제로 랩스의 DVN 노드가 의존하는 RPC 노드 두 대를 해킹해 악의적인 프로그램으로 바꾸었고, 사용하던 다른 외부 RPC에는 DoS 공격을 날려, 해킹당한 내부 RPC에 의존할 수밖에 없도록 만들었죠.
그리고, 공격자는 악의적인 RPC 노드에 가짜 트랜잭션을 집어넣은 것으로 보입니다. rsETH가 거의 없는 유니체인에서, 대량의 rsETH를 이더리움으로 보내는 브릿지 트랜잭션을 DVN 노드에게 전달한 것이죠. 자세한 로직은 알 수 없으나 DVN 노드는 아마 트랜잭션 receipt 정도를 통해 해당 트랜잭션은 유효한 것으로 확인했을 것이고, 정당한 양의 rsETH가 유니체인에서 입금되었다고 판단 후 이더리움에서 동일한 양의 rsETH를 민팅한 것으로 생각됩니다.
<어떻게 막을 수 있었을까?>
세팅이 어떻게 되었든, DVN 노드가 RPC의 악의적인 응답을 제대로 검증했더라면 일어나지 않았을 수 있는 공격이었을 것입니다. 다만, 일반적인 RPC에서 체크할 수 있는 것으로 막기엔 꽤 어려우며, 별도의 세팅이 필요했을 거라고 생각됩니다.
<방법 1: eth_getProof 사용>
이더리움 RPC에는 eth_getProof라는 엔드포인트가 있습니다. 이 엔드포인트를 호출하면 계정 및 스토리지의 머클 증명을 받을 수 있는데, 이 머클 증명과 블록 헤더 내 상태 루트값을 비교해서, 이 계정이 실제로 체인에 존재하는지, 스토리지값 역시 진짜 맞는지 확인할 수 있죠.
그러나 이번 공격 케이스는 아예 RPC 자체가 공격당한 케이스이기 때문에, eth_getProof만 가지고는 응답 조작을 막을 수 없었으리라 생각됩니다. RPC가 블록 헤더까지 조작된 값으로 응답해버릴 수 있기 때문입니다.
<방법 2: L1을 통한 교차 검증>
이번 공격의 소스 체인이었던 유니체인은 OP 스택 롤업이며, OP 스택은 L1에 데이터를 블롭 형태로 제출합니다. 즉, 만약 레이어제로가 별도의 L1 노드를 운영 중이었고, 이 노드가 받는 유니체인 시퀀서의 블롭 데이터를 가지고 요청과 교차 검증을 수행했다면 바로 해당 요청이 조작된 것임을 알 수 있었겠죠.
그러나, 이는 요청 처리에 ‘유니체인의 블롭 제출’을 기다려야 한다는 것을 의미하며, 이는 최대 10분 이상 걸리는 일입니다. 실시간 브릿지의 특성 상, 레이어제로는 이러한 구조를 택하지 않은 것으로 보이네요.
여담이지만, 이번 사건에 ‘ZK를 통한 크로스 롤업 상호운용이 짱이다’라고 말하는 폴리곤 애그레이어 혹은 리니아 측 의견들도 보였는데, 이 역시 비슷한 이유로 보안과 레이턴시의 트레이드오프가 존재합니다. L1에 데이터와 ZK 증명이 제출될 때까지 요청 처리의 레이턴시가 길어지기 때문이죠. 진짜 ZK 기반의 강한 보안을 유지하며 빠른 상호운용이 가능하려면, L2 블록도 실시간 증명이 이뤄져야 합니다.
<방법 3: L2 라이트 클라이언트 활용>
이번 공격에서 가장 효과적이었을 것이라고 생각되는 방안은, L2 라이트 클라이언트의 활용입니다. 라이트 클라이언트는 전체 블록체인 데이터를 저장하지 않고 블록 헤더와 암호학적 증명만으로 체인의 상태를 검증하는 노드입니다. 이더리움에서는 밸리데이터들이 블록에 서명한 것을 확인해서 그 블록이 진짜라는 걸 검증하는 방식으로 구현되어 있죠.
그런데 L2는 밸리데이터들이 따로 없고, 시퀀서만이 단독으로 블록을 생성합니다. 시퀀서는 매 블록마다 서명을 포함해 블록을 전파하죠. L2 라이트 클라이언트는 이 서명을 검증하는 것을 목표로 합니다. 물론 시퀀서에 의해 조작될 수 있다는 점에서 이더리움 L1의 라이트 클라이언트가 보장하는 것만큼 높은 보안이 있지는 않으나, 시퀀서가 정직하다는 가정 하에서는, RPC의 악의적인 응답을 원천 차단할 수 있죠.
즉 만약 이번 케이스에서 레이어제로가 Helios와 같은 L2 라이트 클라이언트를 운영해, 블록에 대한 시퀀서의 서명을 확인했다면, 이러한 일은 발생하지 않았을 가능성이 큽니다. 라자루스가 레이어제로 랩스의 RPC + 유니체인의 시퀀서를 동시에 해킹하지 않는 가정 하이긴 하지만요.
장기적으로는 L2들이 ZK를 도입해 출금 시간을 줄여 레이어제로와 같이 보안이 취약할 수 있는 브릿지에 대한 공식 브릿지의 경쟁력을 높여야 할 것으로 보이며, 장기적으로는 슈퍼체인 상호운용이나 ZK를 활용한 실시간 증명 등 체인 네이티브의 신뢰 최소화된 상호운용성 솔루션들이 사용되는게 가장 이상적이지 않을까 싶습니다.
