Vitalik의 새로운 EIP-7702 제안을 하나의 기사로 읽어보세요: 계정 추상화를 위한 궁극적인 처방?

원작자: Jarrod Watts

원본 편집: Frank, Foresight News

Vitalik Buterin은 최근 이더리움 역사상 가장 영향력 있는 변화 중 하나일 수 있는 EIP-7702 제안을 제안했습니다. 이 기사에서는 새로운 제안의 작동 방식과 이를 구현하기 위해 알아야 할 모든 것을 소개합니다.

첫째, 새로운 EIP-7702 제안은 놀라울 정도로 짧아 일부 사람들이 실제로 어떻게 작동하는지 혼란스럽게 합니다. 7702를 이해하려면 먼저 여기에 언급된 다른 세 가지 제안을 이해해야 합니다.

• EIP-4337

• EIP-3074

• EIP-5003

이 모든 제안의 공통 목표인 "계정 추상화"부터 시작하겠습니다. 이더리움의 EOA("일반" 계정)는 끔찍하고 위험하며 기능이 매우 제한적인 반면, 계정 추상화를 통해 사용자는 스마트 계약을 계정으로 사용하여 추가할 수 있습니다. 이 문제를 해결하기 위해 더 많은 기능과 보안이 필요합니다.

EIP-4337

2023년 3월 메인넷에 출시된 EIP-4337은 스마트 계약을 계정처럼 작성하여 거래를 확인하고 실행할 수 있도록 하여 많은 사용자 경험(UX)을 향상시킵니다.

EIP-4337은 출시 이후 주로 Polygon을 중심으로 널리 채택되었으며, Base는 지난 몇 달 동안 활동이 증가했습니다.

EIP-4337과 관련된 최신 혁신은 생체인식 기술을 기반으로 하고 뛰어난 사용자 경험을 제공하는 Coinbase 생태계와 지난 주말 ETH Global Sydney에서 이를 시연하기 위해 또 다른 작은 데모를 만들었습니다.

그렇다면 EIP-4337에는 어떤 문제가 있는 걸까요? 왜 오늘 또 다른 계정 요약 제안을 하게 되었나요? EOA는 여전히 가장 널리 사용되는 계정 유형이기 때문입니다.

또한 EIP-4337의 스마트 계약 계정 대부분은 단일 EOA 서명자에 의해 제어됩니다. 샘플 코드는 다음과 같습니다.

사용자의 EOA를 스마트 계약 계정으로 "변환"할 수 있는 방법이 없기 때문에 이상한 중간 단계 솔루션이 있습니다. 주로 Web3 애플리케이션에서 스마트 계약 계정 연결에 대한 기본 지원이 부족하기 때문에 오늘날 대부분의 사람들은 여전히 플러그를 사용합니다. -MetaMask와 같은 지갑에서는 EOA를 사용합니다.

EIP-3074

이는 우리의 다음 제안인 EIP-3074로 이어집니다.

실제로 이 제안은 EIP-4337 이전에 제안되었지만 아직 메인 네트워크에 병합되지 않았습니다. EIP-3074는 EOA에 더 많은 권한을 부여하여 EOA 제어를 스마트 계약에 위임할 수 있도록 시도합니다.

제안에서는 두 개의 새로운 opcode를 추가하여 다음 내용을 간략하게 설명합니다.

• AUTH: EOA는 AUTH를 호출하여 특정 스마트 계약이 EOA를 대신하여 작업을 수행하도록 승인할 수 있습니다.

• AUTHCALL: 승인된 스마트 계약은 AUTHCALL을 사용하여 EOA에 대한 트랜잭션을 실행할 수 있습니다.

이를 통해 각 사용자가 새로운 스마트 계약을 배포하지 않고도 EIP-4337과 동일한 사용 사례를 많이 사용할 수 있습니다. 가장 큰 차이점은 사용자의 계정 기록, ETH, NFT, 토큰 등이 없는 새로운 계약이 아닌 사용자의 EOA에서 거래가 이루어진다는 점입니다.

EIP-3074에 대한 일반적인 응답은 "누군가 악의적인 계약을 맺고 사용자가 그에게 위임하면 어떻게 되나요?"입니다. 결국 악의적인 계약을 위임하면 사용자 지갑에 있는 모든 암호화폐 자산이 유출될 수 있습니다.

이 문제에 대한 해결책은 지갑 서비스 제공자가 사용자가 어떤 계약도 승인하는 것을 허용하지 않고 사용자가 승인을 위임할 수 있는 스마트 계약의 화이트리스트 목록을 유지할 수 있으며 이 목록 밖의 모든 계약은 사용자에게 표시되지 않는다는 것입니다.

EIP-3074 위임의 핵심은 위임이 영구적이지 않다는 것입니다. "EOA의 단일 거래로 인해 nonce가 증가하여 완료되지 않은 승인이 무효화됩니다."

기본적으로 사용자가 새로운 거래를 한 후에는 해당 주문이 더 이상 유효하지 않습니다.

EIP-5003

우리는 EOA에 더 많은 권한을 부여하고 싶지 않습니다. 결국, 이러한 제안의 목표는 사용자를 EOA에서 스마트 계약 계정으로 이동시키는 것입니다. 그렇다면 EOA에 기능을 추가하는 이유는 무엇입니까?

이는 우리의 다음 제안인 EIP-5003으로 이어집니다. EIP-5003은 EIP-3074 인증 주소에 코드를 배포하는 또 다른 opcode "AUTHUSURP"를 추가합니다.

EIP-3074와 EIP-5003의 차이점은 다음과 같습니다.

• EIP-3074는 스마트 계약에 대한 임시 위임이며 취소될 수 있습니다.

• EIP-5003은 EOA에서 영구적인 마이그레이션과 EOA에서 스마트 계약 계정으로의 "변환"입니다.

EIP-3074 + EIP-5003의 큰 문제점은 EIP-4337을 통한 현재 계정 추상화 체계와 잘 호환되지 않는다는 점입니다. 따라서 이더리움 커뮤니티의 일부에서는 "두 개의 별도 코드 생태계를 만들 것"을 우려하고 있습니다.

EIP-7702

오늘 Vitalik Buterin의 제안은 다음과 같습니다. EIP-7702 - 그는 EIP-3074를 수정하여 EIP-4337과 더욱 간소화되고 호환되도록 하여 두 개의 개별 계정 추상화 생태계로 끝나지 않도록 할 것을 제안합니다. EIP-5003은 영구 마이그레이션의 다음 단계입니다.

EIP-7702는 contract_code와 서명 필드를 모두 허용하는 새로운 트랜잭션 유형을 제안하고, 트랜잭션 실행 시작 시 서명자 계정의 계약 코드를 contract_code로 설정합니다. 거래가 끝나면 티커가 비어 있도록 재설정됩니다.

이는 스마트 계약에 대한 EOA의 임시 위임 기능을 구현하는 EIP-3074와 동일합니다. 그러나 EIP-7702는 새로운 opcode(하드 포크가 필요함)를 도입하지 않고 대신 호출할 함수를 정의합니다.

• AUTH -> "확인" 호출(확인)

• AUTHCALL -> "실행" 호출

구체적으로는 다음과 같습니다.

• 계정 계약 코드가 비어 있는지 확인하세요.

• 비어 있으면 제공된 계약 코드로 설정됩니다.

• 제공된 스마트 계약이 거래를 처리하는 방식에 따라 거래를 실행합니다.

• 계정 계약 코드 설정을 빈 상태로 복원합니다.

"계약 코드"는 말 그대로 "계약 코드"에 스마트 계약의 코드가 저장되어 있음을 의미합니다. EOA 자체는 계약이 아니므로 이 필드는 일반적으로 비어 있습니다. 그러나 EIP-7702의 영리한 점은 트랜잭션 실행 중에 일부 스마트 계약 코드를 이 필드에 일시적으로 채운다는 것입니다.

이는 특정 거래를 실행하기 위해 EOA에 새로운 동작(티커 형태)을 제공하는 방법입니다. 다음 단계는 이를 영구적인 동작 변경으로 만드는 것입니다. "거래 종료 후 티커를 설정하지 않음"을 선택하면 됩니다. null ".

이 제안의 가장 좋은 점 중 하나는 현재까지 EIP-4337을 위해 구축된 모든 계정 추상화 작업과 호환성이 높다는 것입니다. "사용자가 서명해야 하는 계약 코드는 실제로 기존 EIP-4337 지갑 코드일 수 있습니다."

이 변경 사항이 적용되면 사용자의 기존 EOA는 모든 스마트 계약 코드를 실행할 수 있습니다. 추가 EIP를 사용하면 EOA를 영구적으로 업그레이드하여 특정 코드를 실행할 수도 있습니다.

시간이 지남에 따라 이는 우리 모두가 Web3 애플리케이션과 상호 작용하는 방식에 혁명을 일으킬 수 있습니다.