ERC-7779 출시

이더리움 표준 개발은 좀처럼 속도를 늦추지 않습니다. ERC-7779가 현재 출시됨에 따라 사용자, 개발자 및 지갑 제공업체들은 같은 질문을 하고 있습니다. 새로운 ERC가 출시되면 일상적인 암호화폐 및 DeFi 경험에 실제로 어떤 변화가 있을까요? 이 글에서는 새로운 ERC가 왜 중요한지, 어떻게 프로덕션 단계에 도달하는지, 승인 및 트랜잭션 UX에 대한 실질적인 영향은 무엇인지, 그리고 원키(OneKey) 사용자는 생태계가 최신 인터페이스를 채택함에 따라 무엇을 기대할 수 있는지 자세히 설명합니다.

먼저, 간단히 복습: ERC란 무엇인가요?

ERC(Ethereum Request for Comments)는 커뮤니티 주도 애플리케이션 레벨 표준으로, 계약 및 앱이 신뢰할 수 있게 상호 운용되도록 동작 방식을 정의합니다 (ERC-20 또는 ERC-721 생각). ERC는 EIP 프로세스를 통해 초안부터 최종까지, 공개 토론 및 동료 검토를 거쳐 생성됩니다. 표준이 어떻게 만들어지는지 처음 접하신다면, EIP 프로세스는 공식 사양에 자세히 문서화되어 있습니다. 이더리움의 표준 문서에서 EIP 수명 주기 및 근거, 그리고 EIP 메타 프로세스를 확인하세요.

• 공식 개발자 포털에서 이더리움 표준이 작동하는 방식을 알아보세요 (이더리움 표준 참조).
• EIP 수명 주기 및 상태 정의를 자세히 살펴보세요 (EIP-1 참조).

지갑, 댑 및 레이어 2를 일관되게 유지하기 위해 ERC는 종종 다음과 같은 기본 EIP를 기반으로 구축됩니다.

• EIP-712: 사람이 읽을 수 있는 구조화된 데이터 서명 (EIP-712 참조)
• EIP-165: 인터페이스 감지 및 호환성 확인 (EIP-165 참조)
• EIP-2771: 신뢰할 수 있는 전달자를 통한 메타트랜잭션 (EIP-2771 참조)

ERC-7779가 개선하려는 점

각각의 새로운 ERC는 고유하지만, 최근 표준은 두 가지 목표를 향해 나아가고 있습니다.

• 더 안전하고 세분화된 승인 및 트랜잭션 권한. 사용자는 댑이 무엇을, 언제까지, 어떻게 할 수 있는지 명확한 기기 내 프롬프트로 정확하게 승인하고 싶어 합니다. 이러한 방향은 ERC-20의 approve/transferFrom 워크플로와 permit 스타일 서명으로의 진화에서 얻은 교훈을 따릅니다. approve의 문제점 및 더 안전한 패턴에 대한 배경을 확인하세요 (OpenZeppelin approve 참고 자료 참조).
• 풍부한 컨텍스트를 통한 향상된 지갑 UX. 표준은 점점 더 메타데이터를 인코딩하여 지갑이 불투명한 바이트코드가 아닌 이해하기 쉬운 프롬프트를 렌더링할 수 있도록 하여, 사람이 읽을 수 있는 서명 규칙과 일치시킵니다. 더 안전한 프롬프트를 위한 형식화된 구조화된 데이터에 대해 알아보세요 (EIP-712 참조).

실질적으로 ERC-7779가 "출시"되었다는 것은 초기 채택자(댑, SDK 및 지갑)가 기존 토큰 및 프로토콜과의 호환성을 깨뜨리지 않으면서 더 안전한 승인, 더 나은 디코딩 및 덜 혼란스러운 서명을 제공하도록 설계된 인터페이스를 통합하기 시작했다는 것을 의미합니다.

지금 이것이 중요한 이유

시기가 중요합니다. 이더리움의 최근 업그레이드는 L2 수수료를 낮추고 온체인 활동을 확대했으며, 계정 추상화 및 새로운 지갑 패턴이 성숙하고 있습니다.

• 메인넷의 Dencun은 롤업을 위한 저렴한 데이터 가용성을 해제하고 L2 채택을 증가시켰습니다 (Dencun 발표 참조).
• 계정 추상화는 이론에서 구현으로 이동하여 프로그래밍 가능한 지갑을 가능하게 합니다 (EIP-4337 참조).
• 제안된 트랜잭션 모델(EIP-7702)은 향상된 UX 및 보안 트레이드오프를 통해 작업을 승인하는 새로운 방법을 도입합니다 (EIP-7702 참조).
• 이더리움의 장기 로드맵은 확장성 및 보안을 계속 우선시하며, 이는 지갑 및 표준이 발전하는 방식에 영향을 미칩니다 (이더리움 로드맵 참조).

이러한 배경 속에서 승인 안전을 강화하고 프롬프트 명확성을 개선하는 모든 ERC는 실제 세계에 상당한 영향을 미칠 수 있습니다.

일반 사용자를 위한: 지갑에서 무엇이 달라지나요?

• 더 명확한 프롬프트, 덜 맹목적인 서명. ERC-7779 스타일 메타데이터를 구현하는 지갑은 가능한 경우 구조화된 데이터를 사용하여 계약이 무엇을 요구하는지, 그리고 왜 요구하는지를 보여줄 수 있습니다 (EIP-712 참조).
• 더 세분화된 권한. 생태계가 permit 유사 워크플로 및 모범 사례로 수렴함에 따라 함수별 또는 금액별 제어가 더 보편화될 것으로 예상됩니다 (ERC-20 permit 확장 EIP-2612 및 Permit2 패턴 참조).
• 더 쉬운 허용량 관리. 특히 새로운 표준으로 마이그레이션할 때 위험한 승인을 탐지하고 취소하기 위해 허용량 스캐너를 계속 사용하세요 (Etherscan Token Approval Checker 참조).
• L2 전반의 인지 부하 감소. 표준이 일관된 인터페이스를 채택함에 따라 네트워크 전반의 경험이 더욱 통일됩니다.

유용한 도구 및 참조 자료:

• 취소 및 모니터링을 위한 Etherscan Token Approval Checker
• 최신 DEX에서 채택된 Permit 스타일 워크플로 및 취소 패턴 (Permit2 개요 참조)
• ERC-20 승인 및 안전 주의 사항에 대한 OpenZeppelin의 지침 (OpenZeppelin approve 참고 자료 참조)

개발자를 위한: 통합 플레이북

• 먼저 하위 호환성을 유지하세요. ERC-20 호환성을 유지하면서 EIP-165 감지 뒤에 새로운 인터페이스를 계층화하여 이전 지갑이 작동하지 않도록 합니다 (EIP-165 참조).
• 원시 바이트보다 형식화된 데이터를 선호하세요. 가능한 경우 사용자 대면 서명을 EIP-712로 이동하여 하드웨어 지갑에서 명확한 서명을 가능하게 하고 더 나은 위험 프롬프트를 제공합니다 (EIP-712 참조).
• Permit 워크플로를 고려하세요. 사용 사례가 지출 권한을 부여하는 경우, Permit 스타일 패턴(EIP-2612) 또는 승인 공격 표면을 줄이는 검증된 라이브러리를 채택하세요 (EIP-2612 및 Permit2 개요 참조).
• 적절한 경우 메타-tx를 지원하세요. EIP-2771을 사용하여 재생 보호 및 도메인 분리를 유지하면서 가스 후원 워크플로를 허용합니다 (EIP-2771 참조).
• 감사된 라이브러리를 사용하세요. 직접 구축하는 대신 유지 관리되는 기본 구성 요소 및 인터페이스에 의존하세요 (OpenZeppelin Contracts 참조).
• 새 코드 경로의 위협 모델링. 모든 새 훅 또는 권한 표면은 잠재적인 재진입 및 승인 남용 위험을 도입합니다. 이를 알려진 SWC 범주에 매핑하고 철저히 테스트하세요 (SWC Registry 참조).

개발자 참조 자료:

• EIP-2612 (ERC-20용 Permit)
• Permit2 개요 및 승인 모범 사례
• 표준 정렬 구현을 위한 OpenZeppelin Contracts 5.x
• 취약점 클래스에 대한 SWC Registry

지갑 통합 및 하드웨어 고려 사항

새로운 ERC가 출시될 때 실제 사용자 안전은 지갑이 이를 어떻게 구현하는지에 달려 있습니다.

• 정확한 메서드 디코딩: 지갑은 가능한 경우 EIP-165를 통해 인터페이스를 디코딩하고 함수 선택기 대신 사람이 읽을 수 있는 의도를 표시해야 합니다.
• 기기에서의 명확한 서명: 구조화된 데이터를 사용할 수 있는 경우, 하드웨어 지갑은 사람이 읽을 수 있는 필드를 렌더링하여 사용자가 자신이 서명하는 내용을 확인할 수 있도록 해야 합니다 (EIP-712 참조).
• 시뮬레이션 및 위험 경고: 사전 서명 시뮬레이션, 허용량 차이 및 계약 출처 경고는 악의적인 승인이 온체인에 기록되기 전에 이를 포착하는 데 도움이 됩니다.

원키(OneKey) 사용자가 기대할 수 있는 점:

• 표준 우선 서명: 원키는 구조화된 데이터 서명을 포함한 주요 이더리움 표준을 지원하여 모호한 바이트코드 프롬프트를 피할 수 있도록 합니다 (EIP-712 참조).
• 투명한 트랜잭션 검토: 원키 앱은 기기에서 확인하기 전에 메서드, 자산 및 금액 세부 정보를 표시합니다.
• 오픈 소스 정신: 오픈 소스 코드를 통해 독립 검토자와 커뮤니티는 새로운 표준이 어떻게 통합되는지 면밀히 조사할 수 있습니다. 이는 ERC가 새로운 권한 경로를 도입할 때 중요합니다.

ERC-7779 채택이 확대됨에 따라 원키는 엄격한 보안 관행을 유지하면서 L1 및 L2 네트워크 전반에 걸쳐 명확한 서명 및 호환성을 계속 우선시할 것입니다.

보안 위생: 필수 사항은 변하지 않습니다

• 가능한 경우 앱별 최소 허용량을 사용하세요. 꼭 필요한 경우가 아니면 무제한 승인은 피하세요.
• 특히 새로운 댑을 시도하거나 새로운 표준으로 마이그레이션한 후에는 오래된 승인을 주기적으로 취소하세요 (Etherscan Token Approval Checker 사용).
• 새로운 워크플로를 새로운 공격 표면으로 취급하세요. 피싱 키트는 새로운 지갑 프롬프트를 모방하도록 발전합니다. 도메인, 계약 주소 및 체인 ID를 확인하세요.
• 감사되고 잘 유지 관리되는 계약 및 라이브러리를 선호하고 (OpenZeppelin Contracts 참조) 일반적인 스마트 계약 취약점 클래스를 이해하세요 (SWC Registry 참조).

향후 전망

ERC-7779는 계정 추상화(EIP-4337 참조), 제안된 트랜잭션 승인 모델(EIP-7702 참조) 및 이더리움 로드맵의 지속적인 네트워크 개선과 같은 광범위한 지갑 및 UX 업그레이드 주기의 일부입니다. 표준이 성숙하고 수렴함에 따라 사용자는 혼란스러운 프롬프트가 줄어들고, 기본적으로 더 안전한 승인이 이루어지며, L2 전반에 걸쳐 더 일관된 경험을 보게 될 것입니다.

상당한 온체인 가치를 관리하고 있다면, 선호하는 소프트웨어 지갑과 하드웨어 지갑을 함께 사용하는 것을 고려해 보세요. 원키는 EIP-712와 같은 표준을 위한 명확한 서명, 오픈 소스 투명성 및 멀티체인 호환성을 강조합니다. 이는 새로운 ERC가 출시되고 트랜잭션 표면이 발전함에 따라 실질적인 안전 장치입니다.

참고 자료 및 추가 자료:

• ethereum.org의 이더리움 표준 개요 (이더리움 표준 참조)
• EIP 프로세스 (EIP-1 참조)
• Dencun 메인넷 발표 및 L2에 대한 영향 (Dencun 발표 참조)
• EIP-712 (구조화된 데이터)
• EIP-165 (인터페이스 감지)
• EIP-2771 (메타트랜잭션)
• EIP-2612 (Permit)
• Permit2 개요
• EIP-4337 (계정 추상화)
• EIP-7702 (제안된 승인 모델)
• 이더리움 로드맵
• OpenZeppelin Contracts
• SWC Registry
• Etherscan Token Approval Checker

위의 모든 링크는 더 깊은 기술적 맥락을 위한 권위 있는 출처입니다.