ERC-8128: 당신의 Ethereum 지갑이 곧 유일한 로그인 수단이 될 수도 있습니다.

Source: Dev.to

번역을 진행하려면 번역이 필요한 전체 텍스트를 제공해 주시겠어요? 텍스트를 주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

Introduction

몇 년 동안 저를 괴롭혀 온 문제부터 시작하겠습니다.

저는 API를 지속적으로 다룹니다. 그리고 Web3 기능과 관련된 새로운 프로젝트를 시작할 때마다 어색한 춤을 추게 됩니다 — 사용자는 지갑으로 온체인 인증을 하고, 저는 또한 오프체인 작업을 처리하기 위해 JWT나 API 키를 발급해야 합니다. 두 개의 별도 신원 시스템. 두 개의 별도 신뢰 모델. 그리고 두 개의 별도 고장 지점.

뭔가 잘못된 느낌입니다. 그리고 분명히 저만 이런 생각을 하는 것이 아닌 것 같습니다.

ERC‑8128 소개

2026년 1월, 이더리움 ERCs 저장소에 조용히 올라온 제안이 있습니다. 이 제안이 주목받게 된다면 Web3 앱에서 인증을 생각하는 방식을 근본적으로 바꿀 수 있습니다.

ERC‑8128은 이더리움 계정을 사용해 HTTP 요청에 서명하는 표준을 제안합니다. 로그인 메시지를 한 번만 서명하는 것이 아니라(그것이 Sign‑In with Ethereum이 하는 일입니다). 지갑 소유권을 증명하는 것만이 아니라. 모든. 단 하나의. HTTP 요청—이더리움 키로 서명하고 서버가 검증하며, 저장된 자격 증명은 전혀 사용되지 않습니다.

이 사양은 RFC 9421 위에 구축되었습니다. RFC 9421은 HTTP Message Signatures에 대한 IETF 표준입니다. 따라서 완전히 새로운 방식을 처음부터 만들지는 않습니다. 잘 확립된 웹 표준에 이더리움 계정이 제공하는 암호학적 기반을 입힌 것입니다.

실제로 오늘날 인증 방식이 부러진 이유

메커니즘에 들어가기 전에, 왜 이것이 중요한지 생각해 볼 가치가 있다.

전통적인 HTTP 인증에는 설계 단계부터 자격 증명 기반이라는 근본적인 결함이 내재되어 있다. API 키, JWT, 세션, OAuth를 사용하든, 기본 모델은 동일하다 — 서버가 비밀을 발급하고, 당신은 이후 요청에 그 비밀을 제시하며, 서버는 당신이 그 비밀을 가지고 있기 때문에 신뢰한다.

문제는 입으로 말해 보면 명확해진다: 비밀은 도난당하고 재사용될 수 있다.

• JWT는 전송 중에 가로채질 수 있다.
• API 키는 GitHub에 커밋될 수 있다.
• OAuth 토큰은 브라우저 저장소에서 유출될 수 있다.

이런 상황이 발생하면, 공격자는 당신이 될 필요는 없다 — 단지 당신의 자격 증명을 가지면 된다. 서버는 차이를 구별할 수 없다.

세션 기반 인증은 서버‑사이드 상태를 유지해야 한다는 추가 문제를 가진다. 이제 인증 시스템은 활성 세션 데이터베이스를 관리해야 하며, 이는 단일 장애 지점이자 확장성의 골칫거리가 된다.

OAuth는 이 접근 방식들 중 가장 정교하다고 할 수 있지만, 중앙 집중식 신원 제공자에 대한 의존성을 도입하고, 매번 구현할 때마다 처음부터 다시 배워야 하는 꽤 복잡한 인가 흐름을 제공한다.

ERC‑8128이 모델을 뒤바꾸는 방식

서버가 나중에 클라이언트가 제시할 자격 증명을 발급하는 대신, ERC‑8128은 클라이언트가 각 요청을 자신의 개인 키로 직접 서명하도록 합니다. 서버는 그 서명만 검증하면 됩니다.

이 표준에 따라 요청을 보낼 때 클라이언트는 세 개의 추가 HTTP 헤더를 첨부합니다:

• Signature-Input – 서명에 포함되는 요청의 어떤 부분(메서드, 경로, 헤더, 본문 해시, 타임스탬프 등)을 설명합니다.
• Signature – 해당 구성 요소들에 대한 실제 암호학적 서명입니다.
• Content-Digest – 요청 본문의 해시로, 전송 중에 변조될 수 없도록 합니다.

서버는 이 헤더들을 받아 Signature-Input에 있는 keyid(형식은 erc8128::)를 통해 이더리움 주소를 추출하고, 그 주소와 서명을 검증합니다.

• 일반 외부 소유 계정(EOA)의 경우, 이는 온‑체인에서 트랜잭션을 보낼 때와 동일한 ECDSA 서명 복구 과정입니다.
• 스마트 계약 계정(SCA)의 경우, 검증은 ERC‑1271의 isValidSignature() 인터페이스를 통해 이루어지며, 따라서 계정 추상화 지갑, 멀티시그 및 기타 복잡한 계정 유형도 네이티브하게 작동합니다.

제가 계속 강조하고 싶은 점은 서버가 여러분에 대해 아무것도 저장하지 않는다는 것입니다. 자격 증명 데이터베이스도, 세션 테이블도, 취소할 토큰도 없습니다. 서명된 요청을 보내지 않으면 단순히 인증되지 않은 상태가 됩니다. 인증은 어느 곳에 저장된 상태ful 세션이 아니라 요청 자체의 속성이 됩니다.

재생 공격 및 논스

명백한 질문은: 누군가 서명된 요청을 가로채서 재생하는 것을 무엇이 막는가?

ERC‑8128은 이를 몇 가지 방법으로 해결한다:

1. 타임스탬프 / TTL을 서명된 구성 요소에 포함시킬 수 있어, 오래된 요청은 자동으로 만료된다.
2. 논스를 포함시켜 각 요청을 일회성 권한으로 만들 수 있다 — 검증자가 본 논스를 추적하면, 캡처된 요청을 재생하는 것은 실패한다.

실제로 제안서에는 흥미로운 미해결 질문이 있다. 엄격한 논스 기반 재생 방지는 서버가 상태(본 논스 집합)를 유지해야 하며, 이는 이 인증 모델의 무상태 특성과 충돌한다. 제안서는 이 긴장을 인정한다: 강력한 재생 방지 또는 쉬운 수평 확장을 가질 수 있으며, 트레이드오프가 숨겨진 것이 아니라 명시적이다.

저자들이 이를 솔직히 밝히는 점을 높이 평가한다. 이는 이더리움 매지션스 토론 스레드에 나열된 미해결 질문 중 하나이며, 실제 구현 피드백을 통해 해결될 가능성이 높은 사안이다.

The Bigger Picture: ERC‑8128 + ERC‑8004

Web3 애플리케이션을 구축하는 사람들에게 진정으로 흥미로운 부분이 여기입니다.

ERC‑8128은 한 가지 질문에 답합니다: “이 요청이 이 이더리움 주소에서 온 것인가?”
하지만 ERC‑8004와 결합하면 두 번째 질문에도 답할 수 있습니다: “이 주소가 무엇을 할 수 있나요?”

ERC‑8004는 온체인 상태 해결을 위한 제안으로, 주소와 연관된 평판, 역할, 권한과 같은 것을 다룹니다. 두 가지를 결합하면 단일 암호학적 정체성에 기반한 완전한 인증 및 인가 흐름을 얻을 수 있으며, 인가 규칙은 온체인에 존재해 투명하고 감사 가능하게 됩니다.

ERC‑8128이 가능하게 하는 애플리케이션

• 요청당 API 청구 – API가 서명을 검증하고 온‑체인에서 결제를 정산할 수 있어 청구 계정을 별도로 관리할 필요가 없습니다.
• DAO 툴링 – 온‑체인 거버넌스 상태를 읽어 권한을 강제할 수 있습니다.
• AI 에이전트 – 자율 에이전트가 모든 API 호출에 사용자의 이더리움 아이덴티티를 담아 전송할 수 있습니다; 서버는 온‑체인에서 권한을 확인하므로 에이전트가 어떤 자격 증명도 보유하지 않습니다.

마지막 시나리오는 자율 AI 에이전트가 점점 보편화됨에 따라 특히 매력적입니다. 현재, 여러분을 대신해 API를 호출하는 AI 에이전트는 API 키를 저장해야 하거나(위험) 직접 위임 시스템을 구축해야 합니다(불편). ERC‑8128을 사용하면 에이전트가 위임된 키로 요청에 서명하고, 서비스는 온‑체인에서 해당 위임이 승인되었는지 확인할 수 있습니다.

SIWE가 부족한 점 (그리고 ERC‑8128이 다른 이유)

이더리움 분야에 오래 계셨다면, 처음 떠오르는 생각은 아마도: “이게 이미 Sign‑In with Ethereum (SIWE)이 하는 일이 아닌가?”

SIWE는 훌륭합니다—실제 문제를 해결했죠: 사용자가 비밀번호 대신 지갑으로 웹 앱에 인증할 수 있게 해줍니다. 하지만 SIWE는 근본적으로 로그인 메커니즘입니다. 메시지를 한 번 서명하고 세션을 얻은 뒤, 그때부터는 전통적인 자격 증명 기반 모델로 돌아갑니다. 세션은 일반 세션처럼 만료되거나 도난당할 수 있습니다.

ERC‑8128은 SIWE를 대체하지 않습니다—두 기술은 서로 다른 문제를 해결합니다.

아직 해결 중인 사항

이것을 완성된, 바로 배포 가능한 표준으로 제시하는 것은 부정직한 행동입니다. 아직 여러 질문이 남아 있는 초안 제안입니다.

keyid 형식

현재 제안에서는 다음과 같이 사용합니다:

erc8128::

기존 eip155: 네임스페이스를 재사용할지, 아니면 다음과 같은 보다 명시적인 복합 형식을 채택할지에 대한 논쟁이 있습니다:

erc8128;eip155::

네임스페이스는 검증 의미를 나타내며, 이를 잘못 지정하면 모호성 및 보안 문제가 발생할 수 있습니다.

서명 알고리즘 다양성

이더리움 계정은 결국 ECDSA 외의 알고리즘(예: P‑256)도 지원할 수 있습니다. 표준은 이러한 경우를 혼란을 일으키는 알고리즘 혼동 취약점 없이 부드럽게 처리해야 합니다.

재생 방지 트레이드오프

엄격한 논스(nonce) 적용을 준수 필수 조건으로 해야 할지, 아니면 TTL‑only 접근 방식을 유효하지만 다소 약한 구현으로 인정할 수 있을지에 대해 논의 중입니다.

이러한 사항들은 결정적인 장애 요소는 아니며, ERC 과정에서 다듬어지는 세부 사항에 해당합니다. 오늘 이 기반 위에 구축하고 있다면, 사양이 아직 변경될 수 있음을 염두에 두세요.

내 생각

저는 ERC‑8128이 실제 문제를 깔끔하게 해결한다고 생각합니다. HTTP Message Signatures(기존 IETF 표준)가 이더리움 인증을 붙이기에 적절한 레이어라는 통찰은 매우 스마트합니다—즉, 웹이 완전히 새로운 개념을 받아들이도록 요구하는 것이 아니라 이미 존재하는 것을 확장하는 것이죠.

인증 방식을 자격증명 기반에서 서명 기반으로 전환하는 것은 보안 개선뿐 아니라 개념적인 측면에서도 의미가 큽니다:

• 자격증명 기반: 신원은 서버에 의해 부여됩니다.
• 서명 기반: 신원은 이미 가지고 있는—당신의 개인 키—것이며, 서버는 이를 검증할 뿐입니다.

이는 이더리움이 온‑체인에서 작동하는 방식과 철학적으로 일치하며, 이를 HTTP 레이어에 도입하는 것은 별도의 부가 기능이라기보다 자연스러운 진화처럼 느껴집니다.

광범위하게 채택될지는 지갑 지원, 개발자 도구, 클라이언트 라이브러리 구현, 그리고 생태계가 이 표준을 다른 대안보다 선호하느냐 등에 달려 있습니다. 제안은 사려 깊고, 사용 사례도 실질적이며, AI 에이전트와 자율 시스템이 부상하고 있는 시점에 시기적절해 보입니다.

주목할 가치가 있습니다.

ERC‑8128 초안은 GitHub에서 확인할 수 있으며, 논의는 Ethereum Magicians 포럼에서 진행 중입니다. 의견이나 구현 피드백이 있다면 지금이 참여할 시점입니다—이 단계에서 커뮤니티의 의견이 실제로 사양을 형성합니다.