안녕하세요, 저는 마르코 로페즈입니다 (말라가 대학교 / NICS 연구실 + 분산 보안).
저희 논문이 secp256k1/ECDSA 에 대한 미래의 암호학적으로 관련된 양자 컴퓨터(CRQC) 위협 하에서 이더리움 EOA의 마이그레이션 전략 에 관한 논문으로 채택되었습니다.
본 논문은 의도적으로 실행 계층 (EOA 인증, 트랜잭션/서명 흐름 등)에 초점을 맞추었습니다. 합의 계층의 PQ 마이그레이션(검증자 서명, BLS/KZG 이더리움 클래식(ETC))은 다루지 않습니다.
간략한 배경 설명: 저희는 기존 ethresearch의 훌륭한 연구 결과를 기반으로 새로운 연구를 진행하고 있습니다.
게시글을 올리기 전에, PQ 트랜잭션 서명과 실제 엔지니어링상의 장단점을 다룬 여러 훌륭한 게시글들을 살펴보았습니다. 이러한 논의를 이끌어주신 분들, 특히 asanso님과 seresistvanandras님께 진심으로 감사드립니다.
asanso (1부): "양자 후 이더리움 거래 서명을 원하시나요?"
asanso (2부): “이더리움 거래 서명으로서의 Falcon: 장점, 단점, 그리고 까다로운 점”
asanso (3부): “이더리움 포스트 양자 컴퓨팅 거래로 가는 길은 계정 추상화(AA)로 포장되어 있습니다.”
seresistvanandras: “poqeth: 이더리움에서 효율적인 양자 후 서명 검증” (+ 벤치마크 + 반대 의견 모드)
본 논문은 마이그레이션 경로에 대한 간단한 초기 조사이지만, 전환 과정에서 발생하는 호환성 문제와 공격 표면에 더 중점을 두고 있습니다.
제가 여기에 글을 올리는 이유 (커뮤니티에 대한 호소)
이 작업은 첫 번째 (그리고 의도적으로 단순화된) 시도 입니다. 우리는 CRQC 위협에 대응하여 EOA의 복원력을 높이기 위해 논의되는 주요 마이그레이션 경로를 파악하고, 실제 적용 과정에서 발생할 수 있는 문제점을 강조하고자 했습니다.
이 게시글의 목표는 커뮤니티의 의견을 수렴하고 이 문제의 실행 계층 측면에 대한 노력을 결집하는 것 입니다.
우리가 적절한 완화 방안이나 마이그레이션 경로를 놓치고 있는 것은 아닐까요?
그 외에 어떤 호환성 문제 (온체인 및 오프체인)에 주의해야 할까요?
우리가 과소평가하고 있는 적대적 행위/MEV/운영 위험은 무엇입니까?
어떤 선행 논문/저장소/게시글을 참고하거나 배워야 할까요?
이 프로젝트에 적극적으로 참여하고 있는 다른 사람은 누구이며, 어떤 부분에서 협업이 효과적일 수 있을까요?
지갑, 보안 강화(AA), 인프라, 프로토콜 연구, 감사 또는 L2 생태계 분야에서 일하고 계시다면, 여러분의 관점은 매우 귀중할 것입니다.
이 논문은 다음 내용을 다룹니다 (노선 조사 + 장단점 비교).
본 연구에서는 양자 컴퓨팅 이후 보안을 향한 EOA 마이그레이션과 관련하여 논의되는 주요 접근 방식을 분석하고, 특히 이러한 접근 방식이 현재의 인프라 및 계약 패턴과 교차하는 지점에서 발생하는 장단점을 명확히 밝히고자 했습니다.
네이티브 PQ 서명(프로토콜/ 이더리움 가상 머신(EVM) 경로): ECDSA를 PQ 체계로 대체합니다.
개념적으로는 간단하지만, 검증 비용과 서명/키 크기는 방식에 따라 크게 달라지므로 거래 크기, 가스/성능, 그리고 경우에 따라 주소 생성 방식에도 영향을 미칩니다. 또한 프로토콜 수준에서 도입하는 데 시간이 더 오래 걸립니다.
해시 기반 서명에 대한 참고 사항(미니멀리즘 관점) : 이더리움은 이미 핵심 기본 요소로 해시 함수에 크게 의존하고 있기 때문에 해시 기반 서명 에 대해 자세히 논의할 예정입니다. 해시 기반 서명은 "암호학적으로 최소한의" 방식으로 구현될 수 있습니다(격자/동형성 이더리움 클래식(ETC) 처럼 완전히 새로운 난이도 가정을 도입하는 것이 아니기 때문입니다). 또한, 많은 해시 기반 구조는 온체인에 매우 작은 "공개 키"를 생성할 수 있습니다(종종 해시 /루트 커밋먼트만 사용). 이는 poqeth에서 강조된 "이더리움 환경에서 큰 공개 키는 바람직하지 않다"는 주제와 일맥상통합니다. 물론, 서명 크기, 상태 유지, 사용자 경험/멤풀 마찰과 같은 다른 부분에서 장단점이 발생하며, 바로 이 부분에 대한 커뮤니티의 더 많은 의견을 기다리고 있습니다.
한 가지 작은 차이점을 언급하자면, 상태를 저장하는 해시 기반 서명 (예: XMSS/LMS )은 상태 관리가 필요하기 때문에 일반적인 시스템에서 사용하기에 불편할 수 있지만, 블록체인은 온체인에서 해당 상태를 관리할 수 있는 잠재력을 가지고 있습니다(인덱스/논스 방식과 유사). 다른 생태계에서도 이러한 선례가 있습니다(예: XMSS를 사용하는 QRL ).
이더리움 요청 사항(ERC)-4337 계정 추상화: 현재 사용 가능하며, 검증은 계정 계약 내부에서 이루어지므로 지갑은 PQ 서명을 요구하여 작업을 승인하고 ECDSA 기반 양자 공격에 대한 사용자의 직접적인 노출을 줄일 수 있습니다.
문제는 (아산소 시리즈에서도 논의되었듯이) 번들러가 여전히 ECDSA 서명 트랜잭션을 게시한다는 점입니다. 따라서 전체 흐름이 PQ에 완전히 안전하지 않습니다. 또한 멤풀과 유사한 인프라, 수수료, 운영 복잡성 등 추가적인 요소가 발생합니다.
네이티브 AA 제안(RIP-7560 / 이더리움 개선 제안(EIP)-7701 방향): 깔끔한 암호화 유연성 최종 목표: 계정은 첨부된 검증 로직(PQ 검증, 멀티시그, 패스키 이더리움 클래식(ETC))으로 정의되어 계정 모델 수준에서 고정된 ECDSA 가정을 제거합니다.
심층적인 프로토콜 변경이 필요하며, 일정 및 최종 설계는 불확실합니다.
이더리움 개선 제안(EIP)-7702 위임: 새로운 계정 모델로 마이그레이션하지 않고 기존 EOA/주소에 새로운 유효성 검사 로직을 연결할 수 있는 실용적인 연결 고리입니다. 이를 통해 주소 및 기존 관계를 유지하면서 PQ 인식 유효성 검사 및 계정 정책을 실험할 수 있습니다.
주요 제한 사항: 프로토콜이 EOA의 ECDSA 키를 계속 허용하는 한, EOA는 여전히 "루트 권한"으로 남아 있습니다(CRQC 환경에서 이러한 잔존 권한은 특히 문제가 됩니다).
이더리움 개선 제안(EIP)-7702 + 키 비활성화 변형: 해당 문제를 해결하기 위한 아이디어 논의: 위임 후 원래 ECDSA 키를 비활성화(이상적으로는 영구적으로)하여 주소 및 관련 자산/관계를 유지하면서 위임된 로직을 통해서만 제어 경로를 설정할 수 있습니다.
보다 유연한 검증 메커니즘이 마련되면 이러한 사항들을 "루트 ECDSA 권한"을 제거하기 위한 더 넓은 설계 공간의 일부로 간주합니다.
모든 경로에서 우리는 실용적인 관점을 유지하려고 노력합니다. 즉, ECDSA가 여전히 남아 있는 부분은 어디인지 , 어떤 새로운 인프라 가정이 나타나는지, 그리고 전환 과정에서 생태계에 어떤 문제가 발생하는지를 파악합니다.
호환성/파손 위험 지역("문제 영역")
어려움이 가장 많이 발생할 것으로 예상되는 부분:
배포된 계약에서
ecrecover기반 인증 (서명을 통한 신원 확인)을 사용합니다.온체인 인증의 상당 부분은
ecrecover통한 "서명 기반 신원 확인" 방식으로 이루어집니다. PQ 마이그레이션에서는 트랜잭션 계층에서 ECDSA 사용을 중단하는 것만으로는 충분하지 않습니다.ecrecoverECDSA에 대한 유효한 사전 컴파일로 남아 있는 한, 기존 계약은 ECDSA 오프체인 서명을 계속해서 권위 있는 것으로 취급할 수 있습니다. 따라서 진정한 전환을 위해서는 ECDSAecrecover방식 검증을 어떻게 처리할지(그리고 제한할지, 대체할지, 아니면 새로운 검증 경로로 보완할지)에 대한 명확한 설명이 필요합니다. 그렇지 않으면 EOA가 트랜잭션에 ECDSA 사용을 중단한 후에도 기존 오프체인 서명이 계약 내에서 여전히 효력을 유지할 수 있습니다.(관련 내용: asanso의 AA/Falcon 스레드에서 제기된 것처럼, 많은 PQ(Public Key) 체계는 "키 복구"를 지원하지 않습니다. 예를 들어, "일반" Falcon은 서명에서 공개 키 복구를 지원하지 않으므로
ecrecover스타일의 패턴은 사용할 수 없습니다. Falcon 기반 지갑은 일반적으로 저장/등록된 공개 키를 사용하여 검증해야 합니다. Falcon 문서(Renaud Dubois가 지적한 3.12절)에는 키 복구를 가능하게 하는 "복구 가능한" 모델도 있지만, 이 모델은 서명 크기를 거의 두 배로 늘려 온체인/대역폭에 상당한 영향을 미칩니다.)이더리움 요청 사항(ERC)-2612
permit+ 더욱 폭넓은 오프체인 서명 흐름(유형화된 데이터, 앱별 인증, 메타 트랜잭션 패턴)tx.origin가정 (EOA 대 계약 ID, 취약한 권한 부여 로직)L2s + 크로스체인 드리프트 (동일성 의미론, 리플레이 도메인, 브리징 가정)
마이그레이션 기간 중 MEV (위임, 취소, "마지막 유효 서명" 시점 주변의 순서/경쟁)
우리가 커뮤니티에 바라는 가장 중요한 점은 이 목록에 무엇을 더 추가해야 하는지, 그리고 실제로 가장 해로운 것은 무엇인지에 대한 것입니다.
양자 비상 하드 포크(Fork) (병렬 방식으로) 대체 수단으로 사용됩니다.
"원활한 마이그레이션" 경로와는 별개로, 양자 컴퓨팅 비상 하드 포크 개념은 복원력 측면에서 중요한 요소입니다.
비탈릭 부테린은 2024년 3월 게시물( "양자 비상사태 발생 시 대부분 사용자의 자금을 보호하기 위한 하드포크 방법" )에서 실질적인 양자 기술이 갑자기 등장하여 대규모 데이터 도난이 발생할 경우 최후의 수단으로 고려할 만한 신뢰할 수 있는 대응책을 제시했습니다. 그 방안은 도난 이전 상태로 되돌리고, 기존 EOA 거래를 비활성화하며, 양자 보안 스마트 계약 검증으로 제어권을 이전하는 복구 경로를 제공하는 것입니다.
이 이야기를 꺼내는 이유는 선제적으로 대응하자는 계획이 아니라(비용이 많이 들고 사회적/운영적 부담이 크기 때문입니다), 비상 계획의 중요성을 상기시키고, 동시에 생태계가 "비상 탈출" 모드에 돌입하지 않도록 보다 점진적인 암호화폐 유연성 확보 방안을 마련해야 한다는 점을 강조하기 위함입니다.
우리가 명시적으로 요구하는 것은
답변하실 때 관련 스레드/논문/저장소/팀 링크를 함께 알려주시면 매우 도움이 됩니다.
실행 단계에서 누락된 마이그레이션 경로/완화 조치가 있거나, 포함해야 할 중요한 변형 사항이 있습니까?
온체인 및 오프체인 호환성 문제 중 어떤 것이 가장 시급하거나 실제 사용자에게 가장 큰 피해를 줄 가능성이 높다고 생각하시나요? 구체적인 사례를 제시해 주시면 감사하겠습니다.
마이그레이션 과정에서 고려해야 할 적대적 행위/MEV/운영 위험(선행 공격/경쟁, 악의적인 행위, "마지막 유효 서명" 문제, 인프라 침해, 일회성/상태 저장 방식의 트랜잭션 정체 현상 이더리움 클래식(ETC))은 무엇입니까?
ecrecover,permit또는tx.origin가정으로 인해 마이그레이션이 특히 어려워지는 것으로 알려진 계약 유형이나 지갑 패턴이 있습니까?이러한 패턴의 발생 빈도를 정량화하는 데 도움이 되는 측정/데이터 세트/도구 (예:
ecrecover스캔, 야생에서의 허가 사용 등)를 알고 계십니까?현재 EOA를 위한 CRQC/암호화 민첩성 개발에 적극적으로 참여하고 계신 분이 있나요? 참여하고 계시거나 참여하고 계신 분을 알고 계시다면, 저희와 연결해 주시면 감사하겠습니다.
저희는 이 프로젝트를 공익을 위한 노력(우마(UMA)/NICS 연구소 + 분산형 보안)으로 접근하고 있습니다. 검토, 수정 및 필요한 경우 협업에 매우 열려 있습니다.
폐막/행사
저희는 3월 중순 스페인 테네리페에 있는 라 라구나 대학교에서 열리는 학술대회에서 해당 논문을 발표할 예정입니다. 또한 2026년 5월 9일 로마에서 열리는 유로크립트(Eurocrypt) 관련 블록체인 암호화 도구 워크숍 ( CTB-26 )에서 후속 연구 결과를 발표할 계획입니다.
이 분야에 종사하시는 분이라면 두 행사 중 어느 곳에서든 만나 뵙기를 기대합니다.
참고로 CBT26 제출 마감일은 2월 말이니 아직 시간이 있습니다.
감사합니다!! 피드백 기다리겠습니다.
