← 최신 논문
💻 computer science

Secure AltDA Integration for Ethereum L2s: An End-to-End Validation Framework

본 논문은 이더리움 L2에서 보안이 강화된 대체 데이터 가용성(AltDA) 통합을 위한 정형화된 검증 프레임워크를 제시하며, Celestia-Blobstream 및 EigenDA와 같은 다양한 아키텍처 전반에 걸쳐 모든 적대적 입력이 고유하고 잘 정의된 결과를 생성하도록 보장함으로써 합의 실패와 브릿지 공격을 방지하는 결정론적 변환 모델을 정의한다.

원저자: Bowen Xue, Samuel Laferriere

게시일 2026-06-03
📖 3 분 읽기☕ 가벼운 읽기

원저자: Bowen Xue, Samuel Laferriere

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

이더리움을 도로 위의 규칙에 모두가 동의하는 거대하고 분주한 도시라고 상상해 보십시오. 이 도시를 더 빠르게 만들기 위해 사람들은 "레이어 2(Layer 2)"라는 동네들을 건설했습니다. 이 동네들은 자신들만의 교통량(트랜잭션)을 처리하지만, 분쟁을 해결하고 공식 기록을 유지하기 위해 본체 도시인 이더리움에 의존합니다.

보통 이 동네들은 본체 도시의 게시판에 직접 교통 기록을 게시합니다. 하지만 게시판에는 크기 제한이 있습니다. 너무 많은 동네가 동시에 게시하려고 하면 게시판이 막히고 교통 흐름이 느려집니다.

솔루션: "AltDA" 택배 서비스
이 문제를 해결하기 위해 일부 동네는 대체 데이터 가용성(Alternative Data Availability, AltDA) 시스템을 사용하기 시작했습니다. 전체 로그를 본체 도시에 게시하는 대신, 아주 작은 "영수증"(약속/commitment)만을 도시에 게시하고, 실제 무거운 로그는 전문화된 고속 택배 서비스(Celestia, EigenDA, Avail 등)에 보관하는 방식입니다.

문제점: "영수증"의 함정
이 논문은 단순히 영수증을 가지고 있는 것만으로는 충분하지 않다고 주장합니다. 이는 마치 식당에서 주문하지도 않은 음식에 대한 영수증을 주거나, 영수증에는 "피자"라고 적혀 있지만 실제 주방에서는 "독성 슬러지"를 내놓는 것과 같습니다.

만약 동네가 이 영수증을 확인하기 위한 엄격한 엔드 투 엔드(end-to-end) 규칙을 갖추지 않는다면, 악의적인 행위자들이 시스템을 속일 수 있습니다. 그들은 다음과 같은 일을 할 수 있습니다:

  1. 존재하지 않는 로그(택배사가 이미 버린 로그)에 대해 유효한 영수증을 게시합니다.
  2. 영수증은 로그와 일치하지만, 그 로그 안에 동네의 규칙을 위반하는 지시 사항이 포함되어 있습니다.
  3. 영수증은 유효해 보이지만, 누가 읽느냐에 따라 두 가지 서로 다른 결과를 초래합니다.

만로 동네의 결제 시스템(판사)이 전체 관리 체인(chain of custody)을 확인하지 않고 이러한 잘못된 영수증을 수락한다면, 동네가 멈춰버리거나 동네와 연결된 브릿지를 통해 사람들이 돈을 훔쳐갈 수 있습니다.

논문의 솔루션: "전체 검증(Total Validation)" 프레임워크
저자들은 모든 동네가 안전을 보장하기 위해 반드시 따라야 하는 엄격한 단계별 체크리스트("정형 검증 프레임워크")를 제안합니다. 그들은 이 과정을 4단계 보안 터널에 비유합니다:

  1. 수신함 (우편함): 본체 도시가 동네의 우편함에 종이 한 장(바이트)을 떨어뜨립니다. 그것은 유효한 영수증일 수도 있고, 낙서나 빈 페이지일 수도 있습니다.
  2. 영수증 확인 (택배의 인장): 동네는 해당 종이가 택배 서비스로부터 온 유효한 영수증인지 확인합니다. 서명이 진짜인가? 영수증이 최신 상태인가(만료되지 않았는가)?
  3. 패키지 일치 (결합): 동네는 실제 로그(블롭, blob)를 가져오기 위해 택배사로 갑니다. 그들은 자신이 가진 영수증과 자신이 집어 든 로그가 정확히 일치한다는 것을 증명해야 합니다. 바꿔치기는 허용되지 않습니다.
  4. 번역 (페이로드): 마지막으로, 그들은 로그를 동네의 명확한 지시 사항으로 번역해야 합니다. 만약 로그가 횡설수설하거나, 두 명의 사람이 서로 다르게 해석할 여지가 있다면, 시스템은 즉시 이를 거부해야 합니다.

황금률: "모든 것에는 답이 있어야 한다"
이 논문의 가장 중요한 아이디어는 **전체 검증(Total Validation)**입니다.

  • 입력값이 올바르면, 시스템은 "여기에 유효한 지시 사항이 있습니다"라고 말합니다.
  • 입력값이 잘못되었다면(가짜 영수증, 만료됨, 잘못된 패키지), 시스템은 반드시 "거부함"이라고 말해야 합니다.
  • 입력값이 일시적으로 불가능한 상태라면(택배사가 휴식 중인 경우), 시스템은 "기다리되, 멈추지는 마라"고 말해야 합니다.

시스템은 "무엇을 해야 할지 모르겠다"라고 말하며 멈추거나 패닉에 빠져서는 안 됩니다. 시스템은 항상 결정론적인 답을 내놓아야 합니다.

저자들이 발견한 점
저자들은 Celestia, EigenDA, Avail을 사용하는 실제 사례들을 조사하고 이 체크리스트를 적용했습니다. 그 결과 다음을 발견했습니다:

  • 일부 시스템은 영수증을 확인하는 데(DA Verifier)는 뛰어났습니다.
  • 하지만 많은 시스템이 중간 단계, 즉 영수증이 너무 오래되었는지 확인하는 과정(최신성, Recency)이나 로그가 영수증과 완벽히 일치하는지 확인하는 과정(결합, Binding)을 놓치고 있었습니다.
  • 저자들은 만약 이 단계 중 하나라도 건너뛴다면, 악의적인 행위자들이 시스템이 실제 데이터를 뒷받받하지 않음에도 불구하고 시스템이 수락하게 만드는 "제약 부족(Under-constrained)" 상황을 만들어낼 수 있음을 보여주었습니다. 이는 브릿지가 해킹되거나 네트워크 전체가 멈추는 결과로 이어질 수 있습니다.

핵심 요약
보안은 단순히 택배사가 정직한지의 문제가 아닙니다. 그것은 동네 내부의 전체 프로세스에 관한 것입니다. 세계 최고의 택배사를 보유하고 있더라도, 영수증을 확인하는 동네 내부의 규칙이 허술하다면 전체 시스템은 안전하지 않습니다. 이 논문은 모든 데이터가 공식적인 역사의 일부가 되기 전에 정확하게 확인되고, 검증되고, 번역될 수 있도록 하는 내부 규칙을 구축하기 위한 청사진을 제공합니다.

연구 분야의 논문에 파묻히고 계신가요?

연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.

Digest 사용해 보기 →