: : 이더리움 요청 사항(ERC)-8128 검토
암호화폐의 확장성이란 진정으로 무엇을 의미하는가?
저는 이것이 단순히 더 많은 거래를 처리하는 것을 의미하는 것이 아니라, 암호화폐 계정이 웹상에서 기본적인 신원 확인 단위로 자연스럽게 기능하기 시작한다는 것을 의미한다고 생각합니다.
오늘날의 아키텍처는 여전히 파편화되어 있습니다. 온체인 결제는 지갑을 통해 처리하지만, 오프체인 API 호출 인증은 별도의 로그인과 API 키를 사용합니다. 계층이 분리되어 있고, 신원이 파편화되어 있으며, 권한과 결제는 완전히 다른 시스템에 존재합니다. 그 결과, 통합된 신뢰 모델이 아니라 느슨하게 연결된 메커니즘들의 집합체가 형성됩니다.
만약 단일 이더리움 계정이 웹 요청, 권한 확인, 결제를 일관되게 연결할 수 있다면, 온체인과 오프체인 환경을 아우르는 계층 간 비허가형(Permissionless) 상호 작용이 가능해질 것입니다.
이더리움 요청 사항(ERC)-8128은 바로 이러한 시도를 나타냅니다.
"HTTP 계층에서 해당 전환을 구현하기 위해"
반면 기존 HTTP 인증은 서버에서 발급한 비밀 자격 증명(JWT 및 API 키)에 의존하며, 이러한 자격 증명은 손상될 경우 재사용될 수 있습니다. 세션 기반 모델은 서버 측 상태를 필요로 하며, OAuth는 중앙 집중식 ID 공급자와 복잡한 핸드셰이크에 의존합니다.
궁극적으로 신뢰 모델은 그러한 비밀 정보가 얼마나 안전하게 저장되고 관리되는지에 달려 있습니다.
이더리움 요청 사항(ERC)-8128은 이러한 패러다임 뒤집습니다. 서버에서 발급하는 공유 비밀 키에 의존하는 대신, 클라이언트는 각 HTTP 요청에 이더리움 키를 사용하여 직접 서명하고, 서버는 단순히 서명을 검증합니다. 인증 방식은 자격 증명 발급 모델에서 요청 기반, 명시적, 그리고 독립적으로 검증 가능한 암호학적 증명 모델로 전환됩니다.
구조는 의도적으로 단순하게 설계되었습니다.
출처: http:/erc8128.slice.so
스마트 계약 계정의 경우, 이더리움 요청 사항(ERC)-1271의 isValidSignature() 인터페이스를 통해 검증이 수행됩니다. EOA의 경우, 서명 복구(예: ecrecover)로 충분합니다. 논스 추적 또는 TTL 적용을 통해 리플레이 공격을 완화할 수 있습니다.
무엇보다 중요한 것은 인증이 사실상 상태 비저장 방식이 되므로 서버는 더 이상 비밀 키를 발급, 변경 또는 저장할 필요가 없다는 점입니다.
이더리움 요청 사항(ERC)-8004와 결합하면 아키텍처가 더욱 표현력이 풍부해집니다.
이더리움 요청 사항(ERC)-8128이 "이 요청은 이 주소에서 시작되었다"는 것을 증명하면, 이더리움 요청 사항(ERC)-8004는 "해당 주소가 수행할 수 있는 작업"을 정의합니다. 따라서 인증과 권한 부여는 단일 주소 기반 흐름으로 통합되어 실행 및 필요한 경우 결제까지 자연스럽게 확장됩니다.
행위자가 에이전트, 인간 사용자 또는 백엔드 시스템이든 관계없이 정책 시행 및 서비스 상호 작용은 동일한 암호화 ID를 기반으로 이루어집니다.
이러한 관점에서 이더리움 요청 사항(ERC)-8128의 중요성은 로그인 사용자 경험(UX) 개선을 훨씬 뛰어넘습니다. 이는 이더리움 계정을 웹 기반의 핵심 신원 확인 요소로 격상시키는 인프라적 전환을 의미합니다. 온체인 결제에 사용되는 동일한 주소로 오프체인 API 호출을 인증할 수 있으며, 서버는 온체인 상태를 해석하여 자격 및 권한을 판단할 수 있습니다. 별도의 로그인 계층, 토큰 발행, 세션 관리 없이 단일 암호화 신원이 계층 간 상호 작용을 연결합니다.
이더리움 요청 사항(ERC)-8128은 암호화된 신원 확인 계층을 Web2 인프라에 직접 삽입함으로써 온체인 및 오프체인 시스템이 더 이상 고립된 영역이 아니라 통합된 신뢰 구조의 구성 요소가 되는 모델을 제안합니다. 이 모델은 적어도 원칙적으로는 계층 간 비허가형(Permissionless) 상호 작용을 가능하게 합니다.
#ERC8004 #ERC8128
twitter.com/JayLovesPotato/sta...
