[KOR] Layerzero DVN이 보는 것, Cosmos IBC가 보는 것

KelpDAO 2.9억 달러 탈취 사건이 드러낸 cross-chain 검증의 구조적 차이

Eng:

2026년 4월 18일, KelpDAO의 rsETH 116,500개가 사라졌다. 피해액 약 2.9억 달러로 올해 DeFi 최대 규모의 해킹이다.

LayerZero가 사건 직후 공개한 post-mortem은 기술적으로는 명확하다. 프로토콜 코드는 뚫리지 않았다. DVN 컨트랙트도, 개인키 관리도, OApp의 Solidity 코드도 뚫리지 않았다. 뚫린 것은 LayerZero Labs가 운영하는 DVN이 조회하던 op-geth RPC 노드 2대와, 정상 트래픽을 고립시키기 위한 외부 RPC 대상의 DDoS였다.

체인 위의 어떤 코드도 뚫리지 않았는데 “검증된” cross-chain 메시지가 위조됐다. 이게 어떻게 가능한지를 이해하려면 DVN이 구조적으로 무엇을 검증하는지부터 봐야 한다. 그리고 그 구조는 Cosmos IBC가 설계된 방식과 대조했을 때 가장 선명하게 드러난다.

1. DVN은 서명을 보고, light client는 상태를 본다

LayerZero에서 Ethereum이 “Unichain에서 이 메시지가 발생했다”고 받아들일 때, Ethereum 쪽 endpoint가 실제로 검증하는 것은 하나다. OApp이 설정한 DVN set이 이 메시지의 payloadHash에 대해 attestation을 올렸는가.

DVN set의 attestation이 들어오면 메시지는 실행된다. Ethereum은 Unichain의 블록 헤더를 보관하지 않는다. Unichain의 state transition이 실제로 일어났는지 스스로 재계산하지 않는다. DVN의 “나는 봤다”는 선언을 신뢰할 뿐이다. DVN이 그 선언을 만들어내는 방식은 자신이 설정된 RPC 엔드포인트에 source chain의 이벤트를 물어보는 것이고, 답이 오면 그 답을 서명해서 destination에 올린다. 끝이다.

destination chain이 궁극적으로 신뢰하는 것은 DVN signer의 서명이지 source chain의 상태가 아니다.

IBC는 다르게 설계됐다. Destination chain 위에 source chain의 light client가 올라가 있다. 이 light client는 source chain의 validator set을 알고 있고, 새 block header가 올라올 때 해당 헤더에 validator set의 2/3 이상 서명이 있는지 직접 검증한다. Validator set 자체가 교체되면 그 교체까지 UpdateClient 경로로 추적한다. Packet이 도착하면 destination chain은 light client가 보관 중인 AppHash를 루트로 Merkle proof를 돌려 “이 메시지가 source chain의 state에 실제로 포함됐는가”를 ICS-23 규약에 따라 스스로 계산한다.

Relayer라는 외부 주체가 헤더와 proof를 운반하긴 하지만, relayer는 신뢰되지 않는다. Destination chain이 스스로 재계산하기 때문에 relayer가 거짓말을 하면 proof가 검증에 실패한다. 신뢰의 단위는 “누가 운반했는가”나 “누가 서명했는가”가 아니라 “source chain의 합의 자체”다.

이 모델도 완전히 무신뢰는 아니다. ibc-go 공식 문서는 IBC를 “trustless”가 아니라 “trust-minimized“로 규정한다. Source chain의 validator 2/3 이상이 악의적으로 합의를 장악하면 그 체인이 내는 AppHash 자체가 거짓이 될 수 있고, 그러면 light client도 속는다. 다만 이 경우의 공격 비용은 “source chain 합의 장악”이라는 on-chain 경제 보안 수준이 된다. off-chain 노드 몇 대 침투와는 경제적 단위가 다르다.

두 모델 모두 명확한 trade-off가 있다. Light client 방식은 chain 쌍마다 feasibility가 달라진다. Consensus 타입이 맞아야 하고, light client 구현체가 destination chain 위에 올라가 있어야 하며, update 빈도와 gas 비용도 부담이다. 임의의 체인을 빠르게 연결하기 어렵다. Attestation 방식은 임의의 체인 쌍을 연결할 수 있고 경제성도 좋지만, verifier가 “체인 상태를 어떻게 아는가”의 책임을 각자 져야 한다.

이번 사건은 그 책임이 깨지는 경로를 보여준 사례다. DVN은 체인 상태를 독립적으로 재구성하지 않는다. RPC 노드에 물어보고 답을 받는다. 그 RPC 노드들을 오염시키고 건강한 나머지를 DDoS로 가리면 DVN의 ‘체인 상태에 대한 인식’ 자체가 조작된다. 조작된 인식 위에서 DVN은 정직하게 서명했고 destination chain은 그 서명을 정직하게 검증했다. 어떤 단계에서도 “속였다”고 말할 수 있는 코드가 없었다.

2. Multi-DVN은 필요조건이지 충분조건이 아니다

LayerZero 공식 입장은 단순하다. KelpDAO가 1-of-1 DVN 설정을 썼기 때문에 뚫렸다. Multi-DVN이었다면 막혔다. 공식 post-mortem은 multi-DVN redundancy가 자사가 모든 integrator에게 지속적으로 권고해온 구성이라고 단언했다.

KelpDAO는 이 서술에 공개적으로 반박했다. 2024년 1월부터 LayerZero 인프라 위에서 운영해왔고, 2024년 7월부터 직접 커뮤니케이션 채널이 열려 있었으며, L2 확장 시점에 default 설정이 적절하다는 확인까지 받았다는 것이다. rsETH의 DVN 설정을 바꾸라는 구체적 권고를 받은 적 없다고 Kelp는 주장한다.

Dune Analytics가 사건 직후 공개한 숫자를 보자. LayerZero 활성 OApp 2,665개 중 47%가 1-of-1 DVN 설정이다. 이게 절반에 가까운 디폴트가 된 이유는 분명하다. LayerZero V2 OApp Quickstart의 샘플 layerzero.config.ts가 required DVN 1개, optional DVN 0개로 와이어링되어 있다. Yearn Finance의 banteg는 별도 분석에서 LayerZero의 공개 deployment 코드가 Ethereum, BSC, Polygon, Arbitrum, Optimism 모두에서 single-source verification을 reference로 배포하고 있음을 확인했다. LayerZero의 공식 주장과 디폴트가 1/1이라는 사실이 동시에 참이다.

디폴트 문제를 제쳐놓고 구조적인 질문을 하자. N개의 DVN이 있으면 정말 N배 안전한가?

5개의 “독립된” DVN이 같은 3개의 RPC 프로바이더에서 체인 상태를 읽고 있다면, 공격자가 그 3개를 오염시키는 순간 5개의 DVN이 모두 같은 위조된 상태를 보고 같은 유효 서명을 올린다. M-of-N은 각 N이 서로 독립된 failure domain일 때만 의미가 있다.

이번 사건이 이 명제에 그대로 들어맞는다. KelpDAO의 rsETH 브릿지는 OApp 레이어에서 required DVN 1개로 설정됐다. 이게 1-of-1 DVN이라고 불리는 구성이다. 그 한 개의 DVN이 내부적으로 서명을 어떻게 형성하는지, 단일 서명인지 multi-signer 구조인지는 LayerZero가 공개적으로 밝히지 않았다. 다만 DVN이 어떤 내부 서명 정책을 쓰든, 그 서명의 입력이 되는 “source chain에 대한 관찰”이 모두 같은 RPC에서 나온다면 결과는 같다. 여러 signer가 거짓을 보고 여러 서명이 형성될 뿐, 독립된 관찰이 교차 검증된 게 아니다.

다수결의 안전성은 “몇 개의 서명이 붙었는가”가 아니라 “몇 개의 서로 다른 관찰이 있었는가”에서 나온다. 이번 공격은 이 구분이 서류상으로만 존재하고 운영상으로는 존재하지 않았던 경우다.

OApp 레이어에서 DVN 개수를 1에서 3으로 늘렸다고 가정해보자. 만약 그 3개 DVN이 모두 LayerZero Labs가 배포한 같은 바이너리 이미지를 돌리고, 같은 종류의 퍼블릭 RPC 프로바이더에 의존한다면, 공격 표면은 실질적으로 그대로다. 카운트는 올랐는데 상관관계는 그대로다.

점검해야 할 correlation 축을 꼽으면 다음과 같다.

1. DVN 바이너리 구현:

   1. 같은 이미지 혹은 같은 구현체를 공유하는가. LayerZero는 파트너 DVN 운영자에게 LayerZero가 작성한 바이너리 이미지를 배포해서 돌리는 구조가 일반적이다.

2. RPC 프로바이더 의존성:

   1. 같은 퍼블릭 endpoint (예: Infura, Alchemy) 에 의존하는가, 각자 full node를 돌리는가. IP whitelisting이 걸린 private RPC인가, 공개 endpoint인가.

3. 클라이언트 구현:

   1. 모두 op-geth인가, Reth인가. 같은 클라이언트 제로데이에 동시 노출되는가.

4. 호스팅 인프라:

   1. 모두 AWS us-east-1인가. 리전, 클라우드, ISP가 분산되어 있는가.

5. 운영 entity:

   1. legally 서로 다른 회사인가, 같은 모회사 산하인가. 계약적으로 독립인가.

SEAL(Security Alliance)이 사건 이틀 뒤 공개한 권고문이 이 지점을 정확히 잡았다. 팀은 supply chain 전체를 exhaustively 매핑해야 한다. “3-of-5 multisig인데 4명이 같은 custodian을 쓴다”는 종류의 hidden correlation이 진짜 리스크다. 카운트를 올리는 건 쉽고, 독립성을 확보하는 건 각 축마다 의도적 작업이 필요하다.

light client 모델과 비교하면 이 점이 더 선명해진다. 3개의 서로 다른 light client 인스턴스를 돌린다고 했을 때, 각 인스턴스가 보는 것은 전부 source chain의 validator 서명과 AppHash다. 그 서명을 위조하려면 source chain의 validator 2/3를 실제로 뚫어야 한다. 3개의 light client 인스턴스가 같은 RPC에서 데이터를 받아오더라도 서명 검증 자체는 각 인스턴스가 각자 한다. RPC가 거짓 블록을 주면 서명 검증이 실패할 뿐, 위조된 상태가 통과되지 않는다. Light client가 보는 것은 “데이터를 운반한 경로”가 아니라 “데이터에 붙은 validator 서명”이기 때문이다.

DVN의 경우 “보는 것”은 RPC 응답 자체다. 서명이 데이터에 붙어 오지 않는다. 그래서 RPC를 오염시키면 전체가 넘어간다.

3. 4월 18일, 그 차이가 어떻게 드러났는가

2026년 18일 간격으로 두 건의 대형 사건이 터졌다. Drift Protocol 2.85억 달러(4월 1일), KelpDAO 2.9억 달러(4월 18일). 합계 5.75억 달러. 둘 다 북한 Lazarus Group의 소행으로 추정되고, 구체적으로는 Lazarus 내부의 TraderTraitor 서브유닛이 실행 주체로 지목됐다.

두 사건 다 스마트 컨트랙트가 뚫리지 않았다. Drift은 거버넌스 서명자 대상 social engineering이었고, KelpDAO는 DVN이 의존하는 RPC에 대한 infrastructure 침투였다. Blockaid 분석에서 지적됐듯이, 두 사건 모두 스마트 컨트랙트 audit이 잡아낼 수 있는 범위 바깥에서 터졌다.

이번 공격의 설계를 단계별로 뜯어보면 다음과 같다.

1. 정찰, RPC 리스트 획득.

   1. 공격자가 LayerZero Labs DVN이 조회하는 RPC 노드 목록을 사전에 확보했다. LayerZero 공식 성명은 “the attacker was able to gain access to the list of RPCs our DVN uses”라고만 기술했고, 어떤 경로로 그 리스트가 유출됐는지는 공개되지 않았다. 초기 침투 벡터는 현재 공개된 정보 기준으로는 미해명 상태다.

2. RPC 노드 침투, 바이너리 교체.

   1. 서로 다른 클러스터에서 돌던 op-geth 노드 2대의 바이너리를 악성 버전으로 교체했다. DVN 인스턴스 자체는 least-privilege 원칙 때문에 뚫지 못했다.

3. 선택적 위조, monitoring 회피.

   1. 악성 바이너리는 DVN의 IP에만 위조 데이터를 반환하고, 다른 IP (예: LayerZero Scan, 외부 옵저버) 에는 정상 데이터를 반환하도록 설계됐다.

   2. LayerZero는 “The message was only shown to the DVN while the node explicitly told the truth to any other IP addresses... This was carefully designed to prevent any security monitoring from noticing anomalies”라고 직접 서술했다. 이 선택적 위조로 인해 LayerZero 자체 모니터링 시스템의 anomaly detection이 사건 중 정상 작동하지 않았다.

4. DDoS로 fail-over 강제.

   1. DVN은 내부/외부 RPC 중복 구성이라 2대 침투만으로는 부족했다. 건강한 외부 RPC에 DDoS를 날려 DVN이 오염된 노드로 fail-over하도록 강제했다. 공격 window는 미국 태평양 시간(PT) 기준 10:20 a.m.부터 11:40 a.m.이며, LayerZero는 이 시간대 외부 RPC 트래픽 그래프에서 DDoS 피크를 직접 공개했다.

5. 메시지 위조.

   1. fail-over가 트리거되자 오염된 노드가 "발생하지 않은 Unichain 트랜잭션"을 DVN에 보고했다. DVN이 내부적으로 어떤 서명 정책을 쓰든 그 정책의 입력이 모두 같은 오염된 RPC에서 왔기 때문에 정상적인 attestation이 형성됐고, OApp 레이어에서 Kelp가 요구한 "1 DVN의 attestation"이 충족됐다. 결과적으로 Ethereum 측 OFTAdapter가 lzReceive를 통해 116,500 rsETH를 공격자 주소로 release했다.

6. 증거 인멸 (anti-forensics).

   1. 공격 종료 후 악성 바이너리는 자기 제거 루틴을 실행했다. LayerZero 성명에 따르면 “It was designed to self-destruct once the attack could no longer be performed, disabling the RPCs, deleting the malicious binary and corresponding local logs and configs.”

   2. 즉, RPC 데몬 disable, 악성 바이너리 삭제, 로컬 로그 삭제, 설정 파일 삭제 순으로 자기 흔적을 제거하도록 설계된 말웨어였다. 이 패턴은 APT 계열에서 표준적인 anti-forensics 기법이다.

여기서 중요한 것은 공격자가 스마트 컨트랙트 공격자의 사고방식이 아니라 네트워크 공격자의 사고방식으로 움직였다는 점이다. Reconnaissance, pivot, selective deception, availability-to-integrity downgrade, anti-forensics. 이것들은 웹2 보안 팀이 익숙한 어휘이지 Solidity audit의 어휘가 아니다.

그리고 이 공격이 성립한 근본 이유는 destination chain이 “DVN이 뭐라고 말했는가”만 검증하기 때문이다. destination chain이 “source chain의 validator가 뭐라고 서명했는가”를 직접 검증했다면, RPC 오염과 DDoS는 failure를 유발해도 forged message를 통과시킬 수 없다. 공격의 6단계 중 어느 한 단계도 source chain의 validator 서명을 위조하지 못한다.

다시 말해, DVN 모델에서는 off-chain 노드의 compromise가 destination chain의 승인까지 전달된다. Light client 모델에서는 off-chain 노드의 compromise는 “서명 검증 실패”에서 멈춘다. 이 차이가 구조적이다.

닫으며

LayerZero 개별 비판이 이 글의 목적은 아니다. Attestation 기반 verifier 모델은 light client 모델이 닿을 수 없는 체인 쌍을 연결해주는 유효한 선택지이고, 그 선택이 이번 사건으로 부정되지 않는다. Ethereum과 Unichain 같이 서로 다른 consensus family에 속한 체인을 light client로 연결하려면 별도의 zk proof 시스템이나 새로운 client 구현이 필요하다. DVN 같은 attestation 레이어는 이 한계를 실용적으로 우회하는 방법이다.

다만 설계 결정을 할 때 “verifier가 궁극적으로 무엇을 보고 있는가”가 명시적으로 질문되어야 한다. DVN이 보는 것은 RPC 응답이다. Light client가 보는 것은 validator 서명과 Merkle proof다. 전자는 “chain 상태에 대한 타인의 보고”를 받아들이는 모델이고, 후자는 “chain 상태 자체”를 받아들이는 모델이다. 4월 18일에 뚫린 것은 DVN 모델의 이 전제였다.

Cross-chain 인프라를 평가할 때 “DVN set이 몇 개인가”는 두 번째 질문이다. 첫 번째 질문은 “그 verifier들이 궁극적으로 무엇을 보고 있는가”다. 그 답에 따라 공격자가 뚫어야 하는 것이 “off-chain 노드 몇 대”인지 “source chain 합의”인지가 갈린다.

---

References

1. The Block, “LayerZero says North Korea’s Lazarus likely behind Kelp DAO exploit; blames single-point setup”, Apr 20, 2026.

2. LayerZero, “KelpDAO Incident Statement”, Apr 19, 2026. (공격 체인 기술 서술, multi-DVN 권고, selective deception, DDoS window, self-destruct 루틴의 1차 출처)

3. CoinDesk, “Kelp DAO hits back at LayerZero for trying to shift the blame after a massive exploit”, Apr 20, 2026. (Kelp 반박 statement, banteg 분석, V2 OApp Quickstart 디폴트)

4. The Defiant, “Dune Analytics Reveals 47% of LayerZero OApps Use Minimal DVN Security Following KelpDAO Hack”, Apr 20, 2026.

5. Harry Donnelly, “Inside the Kelp/LayerZero Hack: How Lazarus Forged $292M Into Existence”, Apr 20, 2026.

6. Security Alliance (samczsun et al.), “Initial Takeaways on LayerZero DVN Security Incident”, Apr 20, 2026.

7. CoinDesk, “LayerZero blames Kelp’s setup for $290 million exploit, attributes it to North Korea’s Lazarus”, Apr 20, 2026.

8. Blockaid, “How a Single LayerZero DVN Compromise Drained $292M from KelpDAO”, Apr 20, 2026.