logo
    FP Research
    코멘트
    이슈
    아티클
    리포트
    FP Validated
    회사 소개
    X텔레그램뉴스레터데이터 대시보드 (Dune)
    로그인
    logo
    FP Research
    코멘트이슈아티클리포트
    Validator
    FP Validated
    소셜
    X (KR)X (EN)텔레그램 (KR)텔레그램 (EN)링크드인
    회사
    회사 소개
    문의
    Support@4pillars.io
    정책
    서비스 약관개인정보처리방침투명성 고지
    author
    Jay
    2026년 2월 11일

    ERC-8128 리뷰

    Comment thumbnail
    Infra
    linked-in-logox-logo

    크립토가 진짜로 확장된다는 것은 무엇을 의미할까? 필자는 단순히 더 많은 트랜잭션이 처리되는 것이 아니라, 이더리움 계정이 웹의 기본 신원 단위로 자연스럽게 작동하는 것을 의미한다고 생각한다.

    온체인 결제는 지갑으로 처리하면서, 오프체인 API 호출은 또 다른 로그인과 API 키로 처리하는 현재의 구조는 분절적이다. 레이어가 나뉘어 있고, 신원이 나뉘어 있으며, 권한과 정산이 서로 다른 체계에 속해 있다.

    만약 하나의 이더리움 계정이 웹 요청, 권한 검증, 결제까지 일관되게 연결할 수 있다면, 온체인과 오프체인을 망라하고 레이어 간 허가 없는 상호작용이 가능해진다. 이런 전환을 HTTP 수준에서 구현하려는 시도가 바로 ERC-8128이다.

    기존 HTTP 인증은 서버가 발급한 비밀 자격증명에 의존한다. JWT나 API 키는 탈취되면 재사용될 수 있고, 세션 기반 모델은 서버 상태를 필요로 한다. OAuth는 중앙화된 ID 공급자와 복잡한 핸드셰이크를 요구한다.

    그렇다면 결국 인증의 신뢰는 “비밀을 얼마나 잘 지키는가”에 달려 있다. ERC-8128은 이러한 모델을 전환한다. ERC-8128에서는 공유되는 비밀 자격증명(shared secret) 없이, 클라이언트가 매 요청을 이더리움 키로 직접 서명하고, 서버는 이를 검증만 한다. 인증은 발급 기반이 아니라, 암호학적 증명 기반이 된다.

    구조는 다음과 같이 단순하다.

    ┌─────────────┐    Signed Request     ┌─────────────┐
    │   Client    │ ───────────────────▶  │   Server    │
    │  (signer)   │  Signature-Input      │ (verifier)  │
    │             │  Signature            │             │
    │             │  Content-Digest       │             │
    └─────────────┘                       └─────────────┘
           │                                     │
           │ Signswith ETH key                   │ Verifies signature
           ▼                                     ▼
    ┌─────────────┐                       ┌─────────────┐
    │    EOA      │                       │  ecrecover  │
    │     or      │                       │     or      │
    │    SCA      │                       │  ERC-1271   │
    └─────────────┘                       └─────────────┘
    

    Source: erc8128.slice.so

    스마트 계약 계정의 경우에는 ERC-1271의 isValidSignature()를 호출해 검증한다. 필요하다면 nonce store를 붙여 replay attack을 차단할 수 있다. 핵심은 인증이 stateless하며, 서버가 비밀을 발급하거나 저장하지 않는다는 점이다.

    예를 들어, 여기에 ERC-8004가 더해지면 구조는 더욱 정교해진다.

    [Agent / Human / Backend]
       └─ (ERC-8128) Signed HTTP Request
            → Service-side verification layer
                 ├─ Cryptographic signature validation
                     (EOA via ERC-191, SCA via ERC-1271)
                 ├─ Replay protection (nonce tracking / TTL constraints)
                 └─ On-chain state resolution via ERC-8004
                     (reputation, roles, permissions)
                        → Policy evaluation and enforcement
                            (rate limits, pricing, access control, delegation)
                             → Service execution
                                  → Optional on-chain settlement
    

    ERC-8128이 “이 요청이 해당 주소에서 생성되었다”는 것을 증명한다면, ERC-8004는 “그 주소가 어떤 역할과 권한을 갖는가”를 온체인에서 정의한다. 즉, 인증과 권한이 하나의 주소 기반 흐름으로 연결되며 실행과 정산까지 이어지게 된다. 에이전트든, 사용자든, 백엔드 시스템이든 동일한 암호학적 ID 위에서 정책 적용과 실행이 이루어지는 셈이다.

    결국 ERC-8128의 의의는 단순한 로그인 UX 개선을 넘으며, 이더리움 계정을 웹의 기본 신원 단위로 끌어올리는 인프라적 전환에 가깝다. 온체인 결제에 사용하던 동일한 주소로 오프체인 API를 호출하고, 서버는 해당 주소를 기준으로 온체인 자격이나 상태를 조회할 수 있다. 로그인, 토큰 발급, 세션 유지라는 별도 계층 없이, 하나의 암호학적 ID가 레이어 간 상호작용을 연결한다.

    ERC-8128은 Web2 인프라 위에 암호학적 신원 레이어를 삽입함으로써, 온체인과 오프체인을 하나의 신뢰 체계로 연결하고 레이어 간 허가 없는 상호작용에 대한 가능성을 제시한다.

    최신 코멘트
    2026년 2월 11일

    ERC-8128 리뷰

    author
    Jay
    2026년 2월 11일

    클라우드플레어와 x402 : 에이전트 웹의 미래

    author
    Jun
    2026년 2월 11일

    GTE의 ZERO 사용, 무엇을 시사하나

    author
    Steve
    2026년 2월 10일

    폴리곤 x402: 실거래인가, 조작되었는가?

    author
    Jun
    2026년 2월 08일

    크립토의 채택은 금융에서만 끝나지는 않을 것이다

    author
    100y
    가입하고 무료 뉴스레터 구독
    최신 크립토 산업 동향을 확인해보세요.
    로그인