암호화 지갑의 혁신: 계정 추상화가 모든 것을 변화시키는 방법

간단히 말해서, 계정 추상화는 사용자가 스마트 계약을 계정으로 사용할 수 있게 하여, 암호화 지갑을 프로그래머블하게 만듭니다. 이 기술은 사용자가 블록체인 애플리케이션과 상호작용하는 방식에 획기적인 변화를 가져오며, 많은 사람은 이것이 암호화를 더 사용자 친화적이고 안전하게 만들어 대중 채택에 준비를 갖추는 주요 단계라고 믿습니다.

이더리움의 공동 창립자 비탈릭 부테린은 계정 추상화를 채택하지 않으면 이더리움이 목표를 달성하지 못할 수도 있다고까지 언급했으며, 이는 이 기술이 Web3의 미래에 얼마나 중요한지를 강조합니다.

그렇다면 계정 추상화란 정확히 무엇이며, 그것은 어떻게 작동할까요? 그 중요성을 이해하기 위해서는 먼저 전통적으로 블록체인 계정이 어떻게 작동하는지와 그 구 모델이 왜 한계를 가지고 있는지를 이해해야 합니다. 그 후 계정 추상화가 어떻게 게임을 변화시키는지를 알아보고, 더 나은 보안과 더 쉬운 사용자 경험과 같은 이점들을 탐색하며, 실제 적용 사례를 살펴보고 남아있는 과제를 검토할 것입니다.

끝으로, 왜 계정 추상화가 암호화 지갑에 대규모 업그레이드로 자주 언급되는지, 그리고 현대 금융 앱처럼 암호자산 관리가 얼마나 매끄럽고 쉬워질 수 있는지를 알게 될 것입니다.

전통적 계정 모델: EOA와 스마트 계약 계정

오늘날 이더리움과 같은 블록체인은 자산 관리 및 거래 실행을 위해 계정 모델을 사용합니다. 이더리움에는 두 가지 주요 계정 유형이 있습니다:

• Externally Owned Accounts (EOAs) – 개인 키를 통해 개인이 제어하는 "일반" 사용자 계정입니다. 이더리움 지갑(메타마스크나 하드웨어 지갑과 같은)을 생성했다면, 당신은 EOA를 가지고 있습니다. EOA로, 공개키에서 파생된 공개 주소와 거래 서명에 사용되는 비공개키를 가지고 있습니다. EOA를 사용하여 코인이나 토큰을 보유하고, 자금을 이체하거나 스마트 계약을 호출하는 거래를 보낼 수 있습니다. 중요한 점은, EOA는 자체적으로 거래를 시작할 수 있지만(비공개 키의 서명으로), 사용자 지정 코드를 실행할 수 없습니다 – 기본적인 전송 기능을 넘어서는 프로그래머블하지 않습니다. EOAs는 다른 계정으로 ETH나 토큰을 보내거나 스마트 계약의 함수를 호출하는 두 가지 주된 작업으로 제한됩니다.

• 계약 계정(스마트 계약) – 비공개 키보다는 코드(스마트 계약 코드)에 의해 관리되는 계정입니다. 계약 계정은 자산을 소유하고 거래가 이루어졌을 때 실행되는 규칙이나 로직(코드)을 정의할 수 있습니다. 예를 들어, 탈중앙화 애플리케이션이나 토큰 계약은 계약 계정에 존재합니다. 그러나 계약 계정은 스스로 거래를 시작할 수 없습니다. EOA나 다른 계약으로부터의 거래에 의해 촉발될 때만 코드를 실행합니다. 달리 말해서, 계약이 무엇인가를 하도록 하려면 누군가(또는 어떤 외부 계정)가 호출해야 합니다. 계약 계정은 매우 프로그래머블하고 복잡한 규칙을 적용할 수 있지만, 자동으로 행동할 능력이 없습니다 – 새로운 거래를 보내도록 직접 제어하는 비공개 키가 없습니다.

*이더리움 계정 유형의 비교: Externally Owned Account (EOA)와 Smart Contract Account (SCA). EOAs는 비공개 키로 제어되며 거래를 시작할 수 있지만 임의의 코드를 실행할 수 없습니다. SCAs는 코드를 실행할 수 있지만 스스로 거래를 시작할 수 없습니다. 계정 추상화는 이 분리를 제거하려 합니다.

현재 패러다임에서는, 이 두 계정 유형이 분리되어 있으며 각각의 단점이 있습니다. EOAs는 단일 비공개 키와 연결되어 있어 큰 한계와 취약성을 가집니다: 비공개 키(또는 백업 구문 키)를 잃는다면, 계정과 모든 자산에 접근할 수 없습니다 – 블록체인에는 "비밀번호를 잊어버렸습니다" 옵션이 없습니다. 반대로, 누군가가 악의적으로 비공개 키를 얻게 된다면 전액을 도난 당할 수 있는 통제권을 얻게 됩니다. EOA에 지출 한도를 설정하거나, 다중 서명(멀티시그) 승인이 필요하게 하거나, 신뢰받는 자를 통해 접근을 회복하기 위한 내장된 방법이 없습니다; 계정의 보안은 단지 그 하나의 비밀 키만큼 강력합니다. 이는 전통적인 은행이 사기 방지 관리, 고객 지원, 이중 인증을 통해 실수나 도난을 완화할 수 있는 것과 극명한 대조를 이룹니다. 이와 더불어, EOAs를 사용하면 모든 거래에 수동으로 서명해야 하고(이는 번거로울 수 있습니다), 거래 수수료로 가스를 지불하기 위해 계정에 일정량의 블록체인 원산지 암호화폐(예: ETH)를 유지해야 합니다. 이러한 요구사항은 EOAs를 사용하는 것 자체가 위험하고 일상 사용자가 다루기에 부담스러운 요소가 되게 만듭니다. Rumble Fish 개발 팀이 간단히 정리하듯, EOA는 "소셜 회복 메커니즘이 없고, 지출 한도 설정 옵션이 없으며, 추가할 수 있는 2FA가 없고, 수수료를 충당하기 위한 ETH가 항상 필요하다"며 "불만족스러운 사용자 경험을 제공하며, 신입들에게 크게 환영받지 못한다"고 요약합니다.

반면 스마트 계약 계정은 코드를 통해 유연성을 제공합니다. 예를 들어, 스마트 계약 지갑은 여러 사람이 거래에 대한 승인 필요성을 설정할 수 있으며(다중 서명 지갑), 일일 인출 한도를 설정하거나, 소셜 회복을 허용할 수 있습니다(친구들이 키를 잃을 경우 접근을 회복하는 것을 도울 수 있음). 이는 훌륭한 해결책처럼 보입니다. 실제로 Gnosis Safe와 같은 제품(인기 있는 멀티시그 지갑)이나 Argent(소셜 회복 기능이 있는 지갑)는 단순한 EOA로는 불가능했던 추가 보안 기능을 사용자에게 제공하며 계약 계정을 활용하고 있습니다. 하지만, 역사적으로 스마트 계약 계정은 자체적으로 거래를 시작할 수 없기 때문에 여전히 EOA에 의존하여 어떤 행동이라도 시작해야 했습니다. 예를 들어, 스마트 계약 지갑을 사용한다면, 일반적으로 중계 서비스(외부 EOA)가 의도를 받아 EOA 거래로 캡슐화한 후 네트워크로 밀어주는 방식으로 동작합니다. 이 중계 서비스에 비용을 지불해야 할 수도 있고, 아니면 최소한 동일한 번거로움(다른 계정에 가스를 위해 ETH를 유지하는 것)을 처리해야 할 수도 있습니다. 결과적으로 계약 기반 지갑을 사용하는 것이 잘 설계되지 않을 경우 일반 지갑보다도 복잡해질 수 있습니다. 최근의 혁신 이전에는 스마트 계약 계정을 사용하려면 효과적으로는 계약을 구동하기 위해 ETH로 "충전"된 보조 EOA(또는 도우미 서비스)가 필요했습니다 – 사용자에게 마찰을 더 수반시킵니다.

요약하면, 현 모델 하에서:

• EOA = 당신의 지갑 (단일 키에 의해 제어됨) – 간단하지만 유연성이 없고 용서가 없는 구조.
• 계약 계정 = 프로그래머블한 금고 (고급 기능을 갖춘) – 강력하지만 스스로 동작할 수 없습니다.

이 분리는 계정 추상화가 제거하려는 것입니다. 비전은 별도의 EOA에 의존하지 않고 스마트 계약의 유연성을 가진 사용자 계정을 허용하는 것입니다. 다시 말해, 모든 계정을 스마트하게 만드는 것입니다. 이를 통해 사용자는 원하는 대로 계정의 보안 및 동작을 사용자 정의할 수 있게 되며 – 행동을 시작할 수 있는 능력을 희생하지 않고도 가능합니다. 계정 추상화가 이를 어떻게 실현하며 블록체인 사용자 경험을 어떻게 크게 개선시킬 준비가 되었는지 알아봅시다.

계정 추상화란 무엇입니까?

근본적으로, 계정 추상화는 사용자의 계정이 스마트 계약처럼 행동할 수 있도록 두 계정 유형을 통합하는 개념입니다. 프로토콜의 내장된 규칙만 따르는 경직된 "외부 소유" 지갑 대신 계정 추상화는 사용자가 완전히 제어하는 스마트 계약에 계정의 지출 로직을 인코딩할 수 있게 합니다. 실질적으로, 이는 당신의 지갑이 블록체인 상의 스마트 계약이 될 수 있으며, 그 지갑의 유효한 거래를 구성하는 규칙을 프로그래머블하게 설정할 수 있음을 의미합니다. 소유자로서, 그 규칙들을 직접 설정하거나 사용자 친화적인 방법을 제공하는 지갑을 사용하여 구성할 수 있습니다.

계정 추상화를 정의하는 또 다른 방법은: 사용자 계정을 더 유연하게 만들기 위해 표준 거래 검증 규칙을 "추상화"하여 사용자 정의 검증 로직을 허용하는 것입니다. 오늘날, 모든 이더리움 거래는 승인되기 위해 몇 가지 하드코딩된 기준을 충족해야 합니다: 올바른 제출자의 주소에 해당하는 ECDSA 비공개 키로 서명해야 하며, 유효한 거래 논스를 포함해야 하며, 제출자가 가스 비용을 충당할 만큼의 ETH를 보유해야 합니다. 이러한 규칙은 모든 거래 및 모든 EOAs에 균일하게 적용됩니다. 계정 추상화는 이 일괄적인 모델을 완화할 것을 제안합니다. 모든 계정이 동일한 서명 체계를 사용하고(단일 키로 ECDSA) 항상 ETH로 가스를 지불하는 대신, 거래의 유효성 조건을 계정 기반으로 프로그래머블하게 할 수 있습니다. 본질적으로, 거래의 검증은 자체적으로 스마트 계약이 될 수 있습니다: 계정의 계약 코드에 정의된 조건을 만족하는 거래(또는 작업)는 유효한 것으로 간주됩니다.

이는 무한한 가능성을 열어줍니다. 예를 들어, 계정 추상화를 사용하면:

• 다중 소유자 계정 – 다중 서명(멀티시그) 또는 거래 허가에 대한 기타 기준 필요.
• 포스트-양자 보안 계정 – 양자 컴퓨터에 대한 내성을 가질 수 있는 대체 암호 서명 사용.
• 아예 서명이 없는 계정 (특정 특수 사례에서 필요할 경우), 또는 신뢰할 수 있는 모듈을 통한 생체 인증을 사용하는 계정.
• 다른 자산으로 가스 비용을 지불하거나 제3자가 수수료를 지불하는 계정, 항상 ETH를 손에 쥐고 있을 필요는 없습니다.
• 공개 계정 또는 타이머 잠금 계정, 특정 액션이 일정 시간 후에만 유효하거나 조건을 만족하면 누구든지 트리거할 수 있는 계정(기준이 만족되면 온체인으로 실행할 수 있는 유언장 생각해보세요).

요컨대, 계정 추상화는 사용자가 자신의 지갑이 작동하는 방식에 대한 규칙을 정의할 수 있도록 하여 블록체인의 기본 규칙에 의해 제한받지 않도록 합니다. 이는 사실상 "사용자 계정"과 "스마트 계약"을 하나로 결합합니다. 이더리움 연구원 Ansgar Dietrichs은 이를 "프로그래머블 지갑"을 실현하는 것이라고 묘사하며 – 지갑 자체가 보안, 회복, 트랜잭션 배치, 그 외 다양한 기능의 로직을 포함할 수 있게 하고 대신 외부 소프트웨어에만 의존해오던 기능들을 통합하는 것입니다. 중요한 이유** 많은 암호화폐 채택을 방해해 온 문제들은 EOA의 한계에서 비롯되었습니다. 새로운 사용자는 개인 키와 시드 구문을 안전하게 관리하는 데 어려움을 겪고 있으며, 실수가 발생할 경우 안전망이 없습니다. 숙련된 사용자들은 단일 실패 지점 문제에 대해 걱정합니다. 해킹된 키 하나가 치명적일 수 있기 때문입니다. 개발자들은 블록체인이 본질적으로 지원하지 않는 기능들을 제공하기 위해 무거운 해결책(예: 릴레이어 네트워크 또는 중앙화된 서비스)을 만들어야 했습니다. 계정 추상화를 통해 계정 모델 자체를 보다 강력하고 사용자 중심으로 만들어 이러한 문제들을 정면으로 해결합니다. 그 결과, 이는 Web3의 다음 진화에 필수적인 인프라로 간주됩니다. 사실, 계정 추상화는 Vitalik Buterin과 다른 사람들이 여러 차례 Ethereum의 사용성과 보안을 크게 향상시킬 수 있는 경로로 옹호해온 Ethereum의 핵심 개발자들의 오랜 꿈이었습니다. 이는 이제 추상적인 이론에 불과한 것이 아니라 최근 표준을 통해 Ethereum에서 현실화되고 있으며, 새로운 블록체인들은 처음부터 계정 추상화를 고려하여 설계하고 있습니다.

이론에서 실천으로의 전환을 더 잘 이해하기 위해, Ethereum이 계정 추상화를 ERC-4337이라는 업그레이드를 통해 어떻게 구현하는지, 이게 실제로 어떻게 작동하는지 살펴보겠습니다.

Ethereum에서의 계정 추상화 작동 방식 (ERC-4337)

Ethereum의 계정 추상화를 향한 여정은 최근 ERC-4337(EIP-4337이라고도 함)이라는 제안으로 절정을 이루었습니다. 2021년에 발표되어 2023년에 배포된 ERC-4337은 Ethereum의 핵심 프로토콜을 근본적으로 변경할 필요 없이 계정 추상화를 도입했습니다. 이는 중요한데, 핵심 프로토콜(L1)을 변경하는 것은 느리고 광범위한 합의가 필요하기 때문입니다. 대신 4337은 Ethereum 위에 스마트 계약과 오프체인 인프라를 사용하여 계정 추상화를 달성하므로, 오늘날의 이점을 하드 포크 없이 누릴 수 있는 독창적인 해결책이 됩니다.

그럼 어떻게 작동할까요? ERC-4337은 "User Operation" 객체(종종 UserOp라고 줄여 부름)의 개념을 중심으로 새로운 거래 흐름을 정의합니다. User Operation은 사용자의 스마트 계약 지갑이 수행하고자 하는 패키지화된 거래와 같습니다. 사용자의 지갑이 직접 일반 Ethereum 거래를 생성하는 대신, 지갑은 해당 행동의 모든 세부 정보를 포함한 User Operation을 생성합니다: 누구인지(발신자), 작업 대상(예: 계약 호출 또는 토큰 전송), 호출에 대한 데이터나 매개 변수, 그리고 관련 검증 서명 또는 증명 등이 포함됩니다.

ERC-4337의 새로운 구성 요소와 함께한 고급 흐름은 다음과 같습니다:

• User Operations & Mempool: ERC-4337 지원 지갑(스마트 계약 지갑)을 사용할 때, 지갑은 일반 거래를 방송하지 않습니다. 대신 필요한 정보와 서명을 포함한 UserOperation 객체를 생성합니다(단, 이 서명은 꼭 단일 EOA 키일 필요는 없으며, 계약의 논리가 기대하는 무엇이든 될 수 있습니다). 이 UserOps는 일반 Ethereum 거래 mempool과는 별도로 특수한 UserOperation mempool로 방출됩니다. 이것은 스마트 계약 지갑에서의 의도된 행동이 선택되기를 기다리는 대기 영역과 같습니다.

• Bundlers: 여기에 bundlers가 등장합니다. 이는 사용자의 작업 수준에서 약간의 비유를 들어 광부나 블록 생산자에 해당합니다. 번들러는 이 UserOp mempool을 관찰하고 여러 사용자로부터 여러 UserOps를 수집하여 하나의 "번들"로 모으고, 그 번들을 단일 Ethereum L1 거래로 감쌉니다. 간단히 말해, 번들러는 많은 사용자를 대신하여 그들의 작업을 블록체인으로 운반합니다. 번들러는 EOA입니다(현재 프로토콜에서는 EOAs만이 L1 거래를 시작할 수 있으므로, 번들러는 그래야 합니다). - 하지만 최종 사용자들 자신은 더 이상 EOA 거래를 실행할 필요가 없습니다. 번들러는 큰 거래에 대한 가스를 지불하고, 그 대가로 각각의 UserOp에서 수수료를 받습니다.

• EntryPoint Contract: 번들된 거래는 Ethereum에 배포된 특별한 EntryPoint 스마트 계약으로 전송됩니다. 이 계약은 ERC-4337의 설계 중심에 위치합니다. EntryPoint 계약은 번들 내 User Operations를 검증하고 실행하는 역할을 맡습니다. 번들을 해체하고, 각 UserOp에 대해서, EntryPoint는 대상 스마트 계약 지갑(사용자의 계정 계약)을 호출하여 그 작업을 검증하고, 원하는 행동을 실행합니다. 각 스마트 계약 지갑은 EntryPoint가 호출할 표준 인터페이스를 구현해야 하며, 일반적으로 validateUserOp(해당 계정의 규칙을 위한 서명, 논스 등을 확인)와 execute 함수(검증이 통과하면 요청된 작업을 수행)를 포함합니다. 모든 UserOp가 검증에 실패하면(예: 잘못된 서명 또는 자금 부족), EntryPoint는 이를 거부하여 불법 거래가 실행되지 않도록 합니다.

• Paymasters (Optional): ERC-4337은 또한 Paymasters 개념을 도입합니다. 이는 가스 비용을 후원하거나 누가 어떻게 가스를 지불할지를 지정할 수 있는 보조 스마트 계약입니다. 존재할 때, Paymaster는 UserOp에 첨부될 수 있으며, 검증 중에 EntryPoint가 사용자를 대신하여 가스 비용을 Paymaster에게 요청하게 됩니다(종종 일부 기준 확인 후). 이를 통해 사용자가 가스를 지불하기 위한 ETH를 보유하지 않고도 거래를 할 수 있습니다 - 예를 들어, dApp 개발자는 Paymaster를 운영하여 새로운 사용자들이 온보딩될 때 가스를 지불하도록 하거나, 사용자가 보유한 ERC-20 토큰으로 가스를 지불하도록 허용할 수 있습니다. Paymaster가 사용되지 않으면, 가스는 사용자의 스마트 지갑 자금에서 지불됩니다(이 경우 지갑이 스왑을 하거나 이에 대한 논리를 가지고 있다면 ERC-20 토큰의 형태로 여전히 가능합니다).

• Bundler Incentive: 작업을 실행한 후, EntryPoint 계약은 번들러에게 적법한 수수료를 지불합니다(사용자의 계정 또는 Paymaster에서 제공한 자금을 사용하여). 이는 번들러들이 계속 운영되도록 장려합니다. 본질적으로, 번들러들은 광부나 검증자가 가스 비용을 벌어들이는 방식과 유사하게 수수료를 얻게 됩니다. 이제 그들은 하나의 사용자 작업 뭉치에서 수익을 낼 수 있습니다.

이 아키텍처는 모든 사용자가 EOA를 직접 가질 필요성을 효과적으로 제거합니다. 번들러들만이 거래를 게시하기 위해 EOAs를 사용해야 하며, 다른 모든 사람들의 "거래"는 계약에서 처리하는 UserOps에 캡슐화됩니다. Rumble Fish 팀의 농담처럼, 4337 모델에서 번들러는 "이 계정 추상화 생태계 내에서 EOAs가 필요한 유일한 참여자"입니다. 최종 사용자에게 있어, 그들의 계정은 순전히 스마트 계약 지갑입니다 - 그들은 EOA로 직접 L1 거래를 수동으로 보내지 않으면서도, EntryPoint의 중개를 통해 그들의 의지가 온체인에서 실행됩니다.

이것을 더욱 확립하기 위해 빠른 예제를 살펴보겠습니다: 가령 Alice가 "내 친구 Bob이 하루에 최대 0.1 ETH만 내 지갑에서 보낼 수 있도록 허락"이라는 규칙이 있는 계정 추상화 지갑을 가지고 있다고 가정해 보겠습니다. 이는 보통 EOA로는 불가능한 것입니다 - 내장 도구를 통해 제한적 지출 권한을 온체인에서 위임할 수 없습니다. 하지만 AA로, Alice의 지갑은 그 규칙을 시행하는 스마트 계약입니다. 이제 Bob이 Alice가 오프라인일 때 그녀를 돕기 위해 거래를 실행하고 싶어 합니다. Bob은 Alice의 지갑 계약을 호출하는 UserOperation을 작성합니다: "Alice에서 일부 DEX로 0.05 ETH를 전송합니다". Bob은 이 UserOp에 서명합니다(아마도 Alice의 계약 코드에서 인가된 자신의 키로). 이 UserOp은 mempool로 갑니다. 번들러가 그것을 주워 모아 EntryPoint에 보냅니다. EntryPoint는 Alice의 지갑 계약의 검증 함수를 호출합니다; 코드는 "Bob이 허용된 대표인가? 이 금액이 0.1 ETH의 일일 한도 내에 있는가?"를 확인합니다. 그렇다면 검증이 통과됩니다. 그런 다음 EntryPoint는 Alice의 지갑의 실행 함수를 호출하여 0.05 ETH 전송을 DEX 계약으로 개시합니다. 작업이 성공하면, EntryPoint는 Alice의 지갑 자금에서 소정의 가스 비용을 번들러에게 지불합니다(또는 Bob의 예치금이나 설정에 따라 Paymaster에서 지불할 수도 있습니다). Alice는 그 순간 아무것도 할 필요가 없었습니다 - 그녀의 지갑의 사전 설정된 규칙 덕분에 Bob의 행동이 안전하게 허용되었습니다. Bob이 한도를 초과하려 했거나 권한이 없는 경우, 지갑은 검증 중에 이를 거부했을 것입니다.

위와 같이, 계정 추상화는 UserOps, 번들러, EntryPoint, Paymasters 등 많은 새로운 구성 요소를 도입합니다. 하지만 사용자 관점에서 이러한 모든 것은 그저 새로운 기능처럼 보일 수 있습니다. 특정 개발자는 이렇게 설명했습니다. "최종 사용자는 그들이 계정 추상화를 사용하고 있다는 걸 의식하지 못합니다 - 그저 이전에는 불가능했던 기능을 볼 뿐입니다". 그렇긴 하나, 이를 안전하게 구현하는 것은 복잡합니다. 예를 들어 EntryPoint 계약은 버그 없이 믿을 수 있어야 하며, 중요성이 있기 때문에 감사와 형식적으로 검증된 상태입니다. 각 스마트 지갑의 코드 또한 서명, 논스, 보안 검사를 적절히 처리하도록 신중하게 작성되어야 합니다. 따라서 계정 추상화를 안전하고 매끄럽게 만드는 데는 많은 엔지니어링이 필요합니다.

주의해야 할 점: Ethereum만이 계정 추상화를 연구한 네트워크가 아닙니다. 일부 최신 블록체인과 Layer-2 네트워크는 계정 추상화를 자연스럽게 통합하는 데 있어 더 용이했습니다. 예를 들어, StarkNet(Ethereum 위의 Layer-2 zk-rollup)은 기본적으로 모든 계정이 스마트 계약 계정인 형태로 설계되었습니다. StarkNet에는 EOA라는 개념이 없습니다 - 심지어 사용자 계정도 코드(일반적으로 사용자의 필요에 따라 업그레이드되거나 구성될 수 있는 표준 계정 계약)를 가지고 있습니다. 이로 인해 StarkNet은 초기부터 4337과 같은 외부 번들러 시스템이 필요 없이, 사회적 회복 등의 계정 추상화 기능을 제공할 수 있었습니다; 시퀀서 자체가 스마트 계정을 본질적으로 처리하기 때문입니다. 마찬가지로, zkSync v2(또 다른 Layer-2)도 프로토콜 수준에서 계정 추상화를 자연스럽게 지원합니다 - EOAs의 행동을 모방하는 각 사용자에게 기본 계정 스마트 계약을 배포하여 호환성을 유지하면서도 확장성을 여전히 제공합니다. 이러한 접근 방식들은...## Content Translations

AA의 힘: 프로토콜 레벨에서 EOA/계약 분리를 제거함으로써, 훨씬 더 풍부한 지갑 기능을 설계할 수 있습니다. 이더리움의 ERC-4337 접근 방식은 조금 더 정교하지만 (레이어드 방식이기 때문에), 궁극적으로 Layer-1 이더리움에서 동일한 최종 결과를 제공합니다.

이제 계정 추상화가 무엇인지, 그리고 어떻게 기능하는지 (적어도 이더리움 구현에서) 알게 되었으니, 그 이점에 대해 알아보도록 합시다. 왜 이렇게 많은 화제가 되는 걸까요? 무엇이 이전에 불가능하거나 매우 어려웠던 사용자의 기능을 가능하게 할까요? 계정 추상화의 장점은 보안, 사용성 등을 포함한 여러 측면에 걸쳐 있습니다.

계정 추상화의 장점

계정 추상화는 암호화폐 사용 경험과 보안의 혁신으로 자주 언급됩니다. 지갑을 스마트 계약으로 전환함으로써, 암호화폐 관리를 원시 암호화 키를 다루는 대신 현대적인 은행 계좌나 온라인 프로필을 관리하는 것에 더 가깝게 만듭니다. 주요 이점을 분해해 봅시다:

보안 향상 및 복구 옵션

계정 추상화의 가장 강력한 매력 중 하나는 암호화폐 계정의 보안을 극적으로 개선할 수 있는 잠재력입니다. 오늘날, EOA 지갑의 시드 구문이나 개인 키를 잃으면 단순히 접근 불가능해지는 반면, 복구 수단도 없습니다. 또한, 키가 도난당하면 도둑이 모든 것을 가져갈 수 있으며, 계정을 동결시키거나 피해를 복구할 수 있는 사람도 없습니다. 이러한 냉혹한 현실은 수많은 잃어버린 재산 이야기로 이어졌고, 새로운 사용자들에게는 주요 두려움으로 남아 있습니다.

계정 추상화는 해결책을 제공합니다: 당신의 계정이 프로그래밍 가능한 계약이기 때문에, 자신만의 보안 메커니즘을 구축할 수 있습니다. 예를 들어, 개발자는 소셜 복구 또는 멀티시그 승인을 포함한 스마트 지갑을 구현할 수 있습니다. 소셜 복구 지갑에서는 여전히 매일 사용할 수 있는 기본 서명 키가 있지만, 이를 잃어버리면 "보호자" 그룹(친구, 가족, 또는 당신의 다른 장치들)이 당신의 지갑에 대한 대체 키를 집단적으로 승인할 수 있습니다. 이는 단일 실패 지점을 제거하며, 키 하나를 잃어도 영원히 접근이 차단되지 않고, 단일 도난 키가 (모든 보호자가 손상되지 않는 한) 공격자를 접근할 수 없도록 합니다. Vitalik Buterin은 소셜 복구를 지갑을 보호하는 그의 선호하는 방법으로 추진했고, 계정 추상화로 인해 이 모델은 널리 배포하기 더 쉬워졌습니다 (실제로, Argent와 같은 프로젝트는 스마트 계약을 통해 이 형태를 사용했습니다).

마찬가지로, 계정 추상화는 개인 뿐만 아니라 단체의 멀티시그 지갑 사용을 주류로 만들 수 있습니다. 예를 들어, 모든 거래가 휴대폰과 노트북(두 개의 키)에서 서명되어야 한다고 요구할 수 있습니다 – 이는 단일 장치 손상의 위험을 크게 줄입니다. 과거에는 Gnosis Safe와 같은 멀티시그 지갑이 존재했지만, 설치가 복잡하여 주로 팀이나 전문가들에 의해 사용되었습니다. AA 지갑으로, 사용자 친화적인 인터페이스는 누구나 2-of-3 멀티시그를 자신에게 활성화하거나, 초과되면 추가 확인을 요구하는 일일 지출 한도를 추가할 수 있게 합니다. 이러한 종류의 맞춤형 규칙은 일반 EOA로는 불가능했습니다.

결정적으로, 계정 추상화는 개발자들이 "계정 인증 및 복구를 위한 모든 종류의 옵션을 창의적으로 프로그래밍"할 수 있다는 것을 의미합니다. 거래에 모바일 장치가 공동 서명해야 하는 이중 인증(2FA)을 추가하고 싶나요? 가능합니다. 해킹이 의심되면 지갑을 동결할 수 있는 "동결" 기능을 추가하고 싶나요 (신용카드 동결과 유사하게)? 코딩이 가능합니다. 안전한 주소를 허용 목록에 추가하여 다른 이들에게 송금할 때 추가 확인이 필요하도록 하고 당신의 콜드 스토리지를 무제한으로 받을 수 있게 하고 싶나요? 계약 로직으로 가능합니다. 요컨대, 계정 추상화는 이제까지 아무 것도 아닌 키 모델에 갇혀 있던 암호화폐 지갑에 현대 보안 설계의 유연성을 가져옵니다. 이는 EOA 지갑을 괴롭히는 많은 취약성과 실패 지점을 크게 줄입니다. 사용자들은 이제 안전망 없이 줄타기를 하지 않아도 됩니다 – 키 하나를 잃어도 다른 방식으로 복구할 수 있으며, 의심스러운 시도가 있을 때 회로 차단기를 프로그램할 수 있습니다.

새로운 사용자에 대한 진입 장벽 낮추기

보안 외에도 계정 추상화는 일상 사용자들에게 암호화폐 사용을 훨씬 더 접근 가능하게 만듭니다. 솔직히 말해, 가스 요금과 시드 구문을 가진 EOA를 관리하는 것은 신입들에게 경계감을 줍니다. UI/UX는 종종 인터넷 초기와 비교됩니다 – 사용자들에게 비밀 키(긴 비밀번호와 같은)를 완벽하게 관리하고, 첫날부터 가스와 논지같은 개념을 이해시키려 합니다. 이는 채택에 장벽입니다.

계정 추상화는 보다 친숙하고 사용자 친화적인 경험을 가능하게 하여 이 장벽을 낮춥니다. 예를 들어, 페이마스터가 가스 요금을 대납하거나 스테이블코인을 통한 가스를 허용하면, 새로운 사용자는 탈중앙화 거래를 위해 필요한 ETH 없이 첫 번째 블록체인 거래를 실행할 수 있습니다. dApp이나 지갑이 가스 요금을 후원할 수 있습니다(아마도 온보딩 프로모션이나 프리미엄 모델을 사용해서) – 사용자는 자신의 행동이 진행되는 것을 보고, 마치 금융 테크 앱이 첫 거래의 수수료를 면제하는 것처럼. 이는 매우 중요합니다: 새로운 사용자에게 dApp을 사용하기 위해 먼저 ETH를 획득하도록 요구하는 것은 온보딩 악몽이었습니다. 계정 추상화는 가스 요금 추상을 가능하게 하여 이 장애물을 제거합니다 – 사용자는 가지고 있는 어떤 토큰으로도 지불할 수 있고, 제3자가 개입할 경우 전혀 지불하지 않을 수 있습니다.

또한 사용자 경험 개선은 “서명 없는” 또는 원클릭 거래의 아이디어입니다. 사실상 서명 없는 것은 아니지만(기술적으로는 암호화가 백엔드에서 실행됩니다), 사용자 관점에서는 dApp에 "로그인"되어 세션 동안 수동 승인이 필요하지 않을 수 있습니다. 계정 추상화를 통해 지갑은 세션 키를 구현할 수 있습니다 – 제한된 권한을 가진 임시 키 (예: 특정 행동만 수행할 수 있는 제한 시간 동안). 예를 들어, 게임 dApp에 로그인하여 세션 키에 대해 승인하고, 특정 시간 동안 특정 행동을 대신 수행하도록 허용할 수 있습니다. 그 시간 동안, 추가 거래 팝업 없이 마치 일반 온라인 게임을 즐기는 것 같은 매끄러운 경험을 즐길 수 있습니다. 지갑의 스마트 계약은 세션 키가 주어진 권한을 벗어난 일을 하지 못하게 보장합니다. 이러한 흐름은 web2 앱이 세션을 유지하는 방식과 비슷하며, 계정 추상화의 유연성 덕분에 가능합니다. 초기 세션 키 및 "이더리움을 통한 로그인" 경험의 구현은 이제 AA 지갑을 통해 탐구되고 있습니다.

게다가, 계정 추상화는 자동 결제나 구독 기능도 사용할 수 있게 합니다. 앞서 언급한 것처럼, Visa의 암호화 연구팀은 스마트 계약 지갑이 자체 일정에 따라 정기적으로 결제를 실행할 수 있는 개념 증명을 시연했습니다 (자동 이체). 이 시나리오에서는 사용자 자기 관리 지갑에서 매월 계정 이체를 예약할 수 있으며, 이는 현재는 수탁 서비스나 중앙 은행만이 할 수 있는 것입니다 – 스마트 계약이 자금을 인출할 때 사전 승인을 받음으로써. 이는 AA가 내재된 StarkNet의 Layer-2에서 수행되었지만, 개념은 광범위하게 적용됩니다. 예를 들어, 조건부로 미리 거래, 요금 납부, 또는 송금을 예약할 수 있습니다 (“날짜 Y에 잔액이 X 이상이면 이 거래를 실행하시오”). 사용자는 매번 온라인으로 "확인"을 클릭할 필요가 없으며, 자신의 지갑 계약은 자신이 설정한 규칙에 따라 작동합니다.

이러한 개선 사항들은 더 친근한 온보딩과 사용 경험으로 이어집니다. 한 블로그에서는 계정 추상화와 함께 dApp이 전통적인 테크 앱만큼 매끄러워질 것이라고 적절히 언급했습니다. 사용자가 복구 경로를 사용할 수 있고 (보호자와 연락하거나 백업 장치를 사용하는 것처럼 “비밀번호 재설정”), 가스에 대해 걱정할 필요가 없어집니다 (복잡성은 기본적으로 앱에 의해 처리됨). 비암호화폐 네이티브 사용자에게 이는 큰 의미를 가집니다 – 누군가에게 인터넷을 명령줄을 통해 구성하도록 요구하는 것과 단순히 앱 아이콘을 탭하고 서비스를 사용하는 것의 차이입니다.

거래의 맞춤화 및 자동화

계정 추상화로, 사용자는 자신이 가진 계정으로 무엇을 할 수 있는지를 더 많이 통제할 수 있으며, 이전에는 수작업이나 외부 서비스에 대한 신뢰가 필요했던 복잡한 작업을 자동화할 수 있습니다. 몇 가지 예를 다뤘지만, 몇 가지 주요 기능을 강조해 봅시다:

• 거래 묶음 및 복잡한 행동: 전통적인 EOA는 각 거래마다 별도의 확인으로 하나씩 제출해야 합니다. 스마트 계약 지갑은 여러 행동을 하나의 메타 거래로 묶어 수행할 수 있도록 설계될 수 있습니다. 예를 들어, 당신의 스마트 지갑에서 일련의 단계 (DEX에서 거래, 그 후 수익을 대출 플랫폼에 대출, 후에 얻은 토큰 전송)를 원자적으로 실행할 수 있습니다. 이는 시간과 클릭을 절약할 뿐만 아니라, 단계들을 결합하여 가스를 절약할 수도 있습니다. 참으로, 계정 추상화의 한 가지 이점으로 “여러 거래를 함께 묶어”, 오버헤드를 줄이고 아마 수수료도 절약할 수 있는 능력이 강조됩니다. 사용자에게 이는 여러 거래를 다루는 대신 원클릭 전략을 의미합니다.

• 사전 승인된 거래 및 자동화: 추가 승인이 없이 특정 조건 하에서 발생할 거래를 허가할 수 있습니다. 이는 DeFi의 손절매 주문 (가격이 특정 임계값에 도달하면 자동으로 거래를 실행)이나 특정 매개 변수 내에서 자동으로 실행되는 블록체인 게임의 이동 등을 가능하게 합니다. 계정이 코드로서 당신의 의지를 실행하기 때문에, 마치 블록체인에 등록된 개인 비서 같은 역할을 합니다. 실 세계에서의 구체적인 사용 예: “1년 동안 내 계정에 상호작용하지 않으면, 자동으로 내 백업 지갑으로 자금을 이체하시오.”와 같은 죽은 자 스위치를 프로그래밍할 수 있어, 상속 메커니즘을 제공합니다. AA 없이, 이는 신뢰할 수 있는 제3자가 필요합니다.서비스 또는 누군가가 특별한 계약을 호출하기를 바라지 않아도 됩니다. AA를 통해 귀하의 계정 자체가 이를 강제할 수 있습니다.

• 쉬운 자산 관리: 계정 추상화는 “한 번의 함수 호출로 모든 토큰 전송”과 같은 기능을 허용합니다. 일반적으로 새로운 지갑으로 마이그레이션하려면 각 토큰을 하나씩 전송해야 했습니다. 그러나 스마트 지갑은 자산(ETH 및 모든 토큰, NFT 등)을 다른 주소로 한 번에 모을 수 있는 방법을 제공함으로써 지갑 마이그레이션이나 자산 통합을 간소화할 수 있습니다. 지갑 자체의 소유권을 변경하게 할 수도 있습니다: 예를 들어, 지갑을 판매하거나 제3자에게 이전하는 것 (EOA에서는 일반적으로 불가능하며, EOA는 공유되어서는 안 되는 고정된 키에 묶여 있음).

• 프로그래머블 제한: 계정 사용에 임의의 정책을 부과할 수 있습니다. 예를 들어, 일일 지출 한도를 설정할 수 있습니다. 거래가 해당 금액을 초과할 경우, 지갑은 다음날까지 추가 전송을 일시 중지하거나 사용자로부터 추가 확인을 요구할 수 있습니다. 이러한 종류의 속도 제한은 키가 몰래 절충된 경우에도 모든 자금 손실을 방지할 수 있습니다 - 도둑은 예를 들어 하루에 1%의 자금만을 가져갈 수 있으므로, 사용자가 이를 알아차리고 대응할 시간을 제공합니다. 계정은 특정 거래 유형(예: “추가 키 서명이 없는 경우 위험한 DeFi 계약 X 호출 불가”)을 제한할 수 있습니다. 이것은 신용 카드가 특정 금액 이상의 거래에 대한 제한이나 경보를 설정할 수 있는 방식과 유사합니다.

간단히 말해, 계정 추상화는 전례 없는 유연성을 제공합니다. 블록체인 개발자들의 논평에 따르면, EOAs을 사용하는 사용자는 “맞춤화하거나 자동화할 수 없는 거래에 묶여 있으며, 각 거래는 개별적으로 서명해야 합니다.” 그러나 계정 추상화와 함께 “게임이 변했다”며 사용자는 “정기 결제를 설정하고 다른 형태의 자동화로 들어갈 수 있으며,” 여러 작업을 한 번에 승인할 수 있습니다. 이는 수동 조작의 자동차에서 경로와 규칙으로 프로그래밍할 수 있는 지능형 자율주행 자동차로 전환하는 것과 같습니다 - 사용자가 직접 모든 작은 작업을 수행하는 것이 아니라 원하는 것을 정의하고 시스템이 메커니즘을 처리하게 합니다.

가스비 유연성과 후원

계정 추상화가 제공하는 또 다른 주요 이점은 가스비에 대한 유연성입니다. 현재 이더리움에서는 거래마다 자신의 계정에서 ETH로 가스비를 지불해야 합니다. 이는 많은 사용자 친화적인 경험에게는 쉽게 시작할 수 없는 경우입니다 – 신용카드를 사용할 때마다 수수료를 지불하기 위해 두 번째 통화를 휴대해야 한다고 상상해보십시오, 만약 그것이 없다면 결제가 실패합니다. 이것이 EOA 및 가스에 대한 ETH의 사실입니다.

계정 추상화는 가스 추상을 가능하게 하여 이 제약을 깨뜨립니다:

• 귀하의 계정(스마트 지갑)은 보유하고 있는 모든 토큰으로 가스를 지불하도록 설정될 수 있습니다. 예를 들어, USDC 안정 코인만 보유한 경우, 지갑의 로직(결제 관리자 또는 dex 통합과 연계하여)이 자동으로 일부 USDC를 변환하거나 이를 채굴자/검증자에게 지불하는 데 사용할 수 있어 아예 ETH가 필요하지 않습니다.
• **후원자(결제 관리자)**가 귀하의 가스를 덮어줄 수 있습니다. 이는 사용자들을 위한 가스없는 거래의 문을 엽니다. dApp은 사용자 채택을 높이기 위해 사용자의 거래 수수료를 지불하기로 결정할 수 있습니다 – 고객 유치를 위해 업체가 배송비를 부담하는 것과 유사합니다. 이는 과거에 메타트랜잭션을 통해 제한적인 방식으로 가능했지만, 계정 추상화는 이를 표준화하고 더 안전하게 만듭니다. 사용자는 가스가 존재한다는 사실조차 인식하지 않고 블록체인 애플리케이션과 상호작용할 수 있습니다; 경험은 모든 작업이 “그냥 작동하는” 무료 웹2 앱과 같을 수 있습니다. 예를 들어, 새로운 사용자가 가입하면 앱에서 몇 개의 무료 거래를 후원하여 처음 경험을 원활하게 할 수 있습니다.
• 유연한 수수료 로직: 현재 보유하고 있는 가장 저렴한 자산을 자동으로 사용하여 수수료를 지불하거나 시장 가격에 따라 ETH와 다른 토큰 중 하나를 선택하여 지불하도록 설정할 수 있습니다 – 이 모든 로직은 귀하의 지갑 계약이나 결제 관리자 정책에 내장될 수 있습니다.

ERC-4337 규격은 이를 핵심 기능으로 명시적으로 고려합니다: 결제 관리자 덕분에 사용자는 “네트워크와 상호작용하기 위해 네이티브 ETH 토큰을 보유할 필요가 없다. 이는 웹3에 새로 들어오는 사용자들에게 중요한 개선 사항입니다.” 그리고 럼블 피쉬의 분석은 AA를 통해 dApp이나 다른 사람들도 사람의 가스를 선물이나 프로모션으로 지불할 수 있음을 강조하며, 온보딩을 훨씬 원활하게 만듭니다. 우리는 이미 비자와 같은 조직이 계정 추상을 사용하여 사용자들이 신용 카드나 제3자를 통해 가스를 지불할 수 있게 함으로써 암호화 거래를 일반 온라인 구매처럼 느끼게 하는 실험을 보고 있습니다. 이러한 UX는 블록체인 애플리케이션을 대중화하는 데 있어 큰 도약이 될 것입니다.

미래 대비 및 새로운 가능성

마지막으로, 계정 추상화는 오늘날 무엇을 가능하게 하는지뿐만 아니라 새로운 기술에 블록체인 계정을 미래 대비하며 전혀 새로운 종류의 애플리케이션을 열어준다는 점에서 중요합니다:

• 포스트-양자 암호화: 오늘날의 이더리움 서명(ECDSA)은 미래에 양자 컴퓨터에 의해 해킹될 수 있습니다. 계정 추상화로 각 계정별로 양자 저항 서명 체계로 점진적으로 전환할 수 있으며, 모든 서명 방법을 바꾸는 하드포크를 필요로 하지 않습니다. 실제로 AA는 여러 서명 체계가 공존할 수 있도록 허용합니다 – 일부 계정은 전통적인 키를 사용할 수 있으며, 다른 계정은 램포트(Lamport) 또는 BLISS와 같은 양자 안전 서명을 요구할 수 있습니다. 이더리움의 4337은 “양자 컴퓨터에 저항하는 거래를 생성하는 첫 번째 단계 중 하나”로 간주됩니다. 왜냐하면 이는 계정 검증을 고정된 알고리즘에서 분리하기 때문입니다.
• 역할 기반 접근 및 모듈성: 계정은 역할 기반 접근 제어를 위해 프로그래밍할 수 있습니다. 예를 들어, 거래만 할 수 있고 인출은 할 수 없는 “거래 키”를 지정하거나, 계약을 배포할 수는 있지만 자금을 이동할 수 없는 “배포자 키” 등을 계정 계약 내에서 지정할 수 있습니다. 이는 세부적인 제어를 원하는 조직이나 파워 유저들에게 유용합니다.
• 일류 멀티시그 및 공유 계정: 계정 추상화는 멀티 소유자 계정을 생태계 전반에 걸쳐 일류 시민으로 만들 수 있습니다. 이는 dApp과 프로토콜이 멀티시그 계정과의 상호작용을 보다 쉽게 지원할 수 있게 합니다. 또한 팀이나 가족 지갑이 더 쉬워집니다. 한 계정 계약이 여러 사람에 의해 소유될 수 있으며, 각자가 특정 권리를 가질 수 있습니다 – 이는 EOA와는 단순하지 않은 일입니다. 실제로 참조 문서는 계정 추상이 “팀 지갑”을 활성화하는 용례로 언급하며, 이는 여러 사람이 관리하는 프로그래밍된 거버넌스 규칙으로 관리되는 지갑을 의미합니다(기업 재무, DAO 자금 등에 이상적임).
• 온체인 신원 및 평판: 계정 계약은 논리를 포함할 수 있기 때문에, 평판 점수 또는 DeFi에 대한 화이트리스트를 통합할 수 있습니다(예: 사용자가 설정을 변경할 때까지 안전을 위해 화이트리스트 된 프로토콜과의 상호작용만 허용하는 계정). 또한 인증 시스템과 통합되어, 특정 자격 증명이나 NFT가 일부 기능을 잠금 해제하는 데 필요할 수도 있습니다. 이는 스마트 계정이 지갑과 신원 허브 역할을 동시에 하는 영역으로 확장됩니다.

종합적으로, 계정 추상의 이점은 보안, 사용성, 유연성 및 미래 대비성을 아우릅니다. 이는 암호화 계정을 현대 소프트웨어가 허락하는 만큼 강력하고 편리하게 만드는 것이며, 보관자 및 탈중앙화 원칙을 희생하지 않습니다. 이더리움 커뮤니티의 많은 사람들이 이를 대규모 사용자 채택을 촉진할 중요한 단계로 보고 있습니다. 한 소식통에 따르면 계정 추상화는 이더리움이 대규모 사용자 채택으로 나아가는 중요한 발판으로 널리 인식되고 있습니다.

AA가 무엇을 가능하게 하는지에 대해 설명했으니, 실제 세계의 구현 사례와 계정 추상의 실질적인 예시를 살펴보며 이 논의를 구체화해보겠습니다.

실제 사례 및 예시

계정 추상화는 이론적으로 들릴 수 있으나, 이미 현실에서 구현되고 테스트되고 있습니다. 다음은 그 영향을 보여주는 몇 가지 주목할 만한 사례 및 시나리오입니다:

• 스마트 계약 지갑(소셜 복구 및 멀티시그): 아르젠트(Argent) 지갑과 같은 프로젝트는 소셜 복구 및 신뢰할 수 있는 연락처를 제공하는 스마트 계약 지갑의 초기 선구자였습니다. 아르젠트의 지갑(ERC-4337 이전에도)은 사용자가 키를 잃어버렸을 때 접근을 복원할 수 있는 “가디언”을 지명할 수 있도록 했습니다 – 이는 사용자마다 맞춤형 계약을 통해 이루어졌습니다. 이제 ERC-4337이 활성화됨에 따라, 이러한 지갑은 표준화된 인프라에 플러그인할 수 있으며, 산업 전반에 걸쳐 더욱 일반화될 가능성이 있습니다. 유사하게, Gnosis Safe(현재 Safe로 불림)는 주로 팀/DAO에 사용되는 널리 사용되는 멀티-사인 지갑이었습니다. Safe 자체가 계정 추상화의 사례입니다(다수 소유자가 하나의 계약 계정을 제어함). Safe 팀은 적극적으로 AA를 수용하고 있으며, 심지어 ERC-4337을 활용한 프로토타입을 개발하고 있으며, EIP-7702와 같은 다가오는 프로토콜 변경 사항이 기존 Safe 계정을 일류 스마트 계정으로 마이그레이션하는 것을 어떻게 지원할지 검토하고 있습니다. 이러한 예들은 개인 및 조직에 대한 보안 강화 지갑이 AA의 명확한 즉각적 이점임을 보여줍니다.

• DApps에 의한 가스 후원: 우리는 탈중앙화 애플리케이션이 UX 개선을 위해 사용자 가스 비용을 지원하는 실험을 보고 있습니다. 예를 들어, 블록체인 게임이나 탈중앙화 거래소는 ERC-4337 기준에 따라 결제 관리자(Paymaster)를 사용하여 사용자가 가스를 위한 ETH를 보유하지 않고 거래할 수 있도록 할 수 있습니다 – dApp은 가스를 후원하며, 아마도 약간의 더 높은 프로토콜 수수료를 통해 비용을 회수하거나 마케팅 비용으로 회수할 수 있습다음 콘텐츠를 영어에서 한국어로 번역합니다.
  형식은 다음과 같습니다:

Markdown 링크는 번역을 생략합니다.

콘텐츠: 우리가 언급한 연구는 지갑의 로직과 페이마스터에 의해 중재되어, 지갑이 Visa 카드로 요금을 청구하면서 가스를 지불할 수 있게 했습니다. 아직 신용 카드로 가스를 청구하는 것이 일반적이지는 않지만, 이러한 가능성이 있다는 사실은 우리가 얼마나 멀리 블록체인 메커니즘을 사용자로부터 추상화할 수 있는지를 강조합니다.

• 정기 결제 및 구독: 셀프 커스토디얼 지갑에서 자동화된 정기 결제의 개념은 이전에는 거의 들어본 적이 없습니다. 왜냐하면 EOA는 미래 날짜에 자체적으로 결제를 시작할 수 없기 때문입니다. 그러나 계정 추상을 통해 자동 결제가 가능해집니다. StarkNet의 Visa 개념 증명은 완벽한 예입니다: 그들은 계정 추상을 사용하여 풀 기반 결제를 구현했습니다(청구자가 사용자의 지갑으로부터 결제 날짜에 결제를 시작할 수 있었습니다. 왜냐하면 지갑이 사전 승인했기 때문입니다). 또 다른 가상의 예: 스트리밍 서비스는 매달 구독료를 청구하기 위해 지갑 계약을 핑하는 스마트 계약을 배포할 수 있습니다; 당신의 지갑 코드는 그것이 정당한 서비스임을 확인하고 예를 들어, 스테이블코인으로 자동 결제를 할 수 있습니다 - 매달 로그인하지 않고도 말이죠. 이러한 편리함은 일반적으로 Web3에서 누락되어 있었으며, 사용자가 이러한 기능을 원할 경우 커스토디얼 솔루션을 선택하도록 강요할 수 있었습니다. 계정 추상화는 이를 셀프-커스토디로 제공합니다.

• "원클릭" 경험 및 조합 가능성: NFT 마켓플레이스를 생각해 보세요. NFT를 구매하는 데 여러 단계가 필요할 수 있습니다(토큰 승인, 그다음 거래 등), 또는 DAO 참여가 토큰 잠금 후 투표를 요구할 수 있습니다. AA 지갑을 사용하면 프로젝트는 사용자가 원클릭 "구매" 또는 "참여"를 진행하고 뒤에서는 지갑 계약이 필요한 단계를 번들링하도록 설계할 수 있습니다. 우리는 이미 메타 트랜잭션을 수행하는 일부 DeFi 집계기에서 이것을 보고 있지만, 네이티브 AA를 통해 더 일반적이고 통합하기 쉬울 수 있습니다. 이는 dApp의 조합 가능성을 높입니다 - 스마트 계정은 한 번에 여러 프로토콜과 상호작용할 수 있어, 개발자가 첫번째 거래 이후 사용자가 이탈할 염려 없이 더 풍부한 기능을 만들도록 장려합니다.

• 레이어-2 채택 및 크로스체인 UX: StarkNet 및 zkSync와 같은 이더리움 레이어-2 네트워크(네이티브 AA가 있는)에서는 사용자들이 첫날부터 이러한 이점을 맛볼 수 있습니다. 예를 들어, StarkNet의 사용자는 계약을 배포하여 계정을 생성하고 이후에는 요금 지불을 위한 토큰 선택과 같은 기능을 즐길 수 있습니다. 이러한 L2가 사용자를 확보할수록, 이러한 편리함에 대한 기대감이 커지며 다른 체인들이 유사한 아이디어를 도입해야 하는 압박을 받게 됩니다. 또한, 계정 추상화는 크로스체인 경험을 도울 수 있습니다. 커뮤니티 일부에서는 계정 추상화와 손잡고 "체인 추상화"에 대해 이야기합니다. 예를 들어, 스마트 지갑은 연산이 이루어지는 체인을 추상화할 수 있습니다 - 당신은 작업을 시작하고 지갑은(릴레이 또는 브리지를 통해) 적절한 체인에서 실행을 처리하고, 당신에게 결과를 반환합니다. 이것은 아직 초기 단계이지만, 설계에 따라 멀티체인에서 자원을 관리할 수 있는 스마트 계정이 통합된 UX를 제공할 수 있습니다.

• 개발자 도구 및 새로운 서비스: 계정 추상을 지원하기 위한 새로운 서비스들이 등장하고 있습니다. 예를 들어, 사용자에게 스마트 지갑 배포를 처리하고 사용자 친화적인 방법으로 키를 관리하는 지갑-서비스(WaaS)를 제공하는 공급자들입니다(어떤 것은 전화기나 클라우드 백업의 보안 인클레이브와 통합됩니다). 특정 회사를 홍보할 수는 없지만, 많은 스타트업과 프로젝트가 적극적으로 AA 도구를 구축하고 있다는 점이 주목할 만합니다. 이는 dApp이 사용자에게 AA 지갑을 간편하게 생성할 수 있는 SDK에서부터, 가스 전환을 처리하는 전문 페이마스터까지 다양합니다. 이로 인해 생태계는 빠르게 AA를 매끄럽게 하고자 하고 있습니다. 이러한 도구들이 성숙해짐에 따라 더 많은 앱이 AA를 채택할 수 있으며, 사용자는 이를 모르는 상태에서도 사용할 수 있을 것입니다(예를 들어, 게임이 사용자의 이메일 로그인에 연결된 계약 지갑을 자동으로 각 사용자에게 제공할 수 있으며, 사용자는 그저 그들이 게임 계정을 가지고 있다는 것을 알 뿐입니다. 그 밑에는 이메일 인증된 키와 연결된 스마트 계약 지갑이 있습니다).

이러한 예들은 계정 추상이 단순한 이론적 업그레이드가 아니라는 것을 강화하며, 다양한 분야에 걸쳐 구체적인 개선을 가져오고 있음을 보여줍니다. 그러나 아직 모든 것이 순조로운 것은 아닙니다. 새로운 기술에는 항상 인지해야 할 과제와 트레이드오프가 있습니다. 균형 있는 관점을 얻기 위해 이러한 문제들을 주의 깊게 살펴보는 것이 중요합니다.

계정 추상의 과제와 한계

계정 추상이 흥미로운 가능성을 열어주는 한편, 새로운 복잡성과 고려 사항을 도입하기도 합니다. 여기 중요하게 살펴볼 도전과 한계들입니다:

• 스마트 계약 위험: 사용자 지갑을 스마트 계약으로 전환함으로써, 우리는 개인 계정에 스마트 계약 위험을 본질적으로 도입합니다. 지갑 코드의 버그는 치명적일 수 있습니다 - 예를 들어, 결함이 공격자가 보안을 우회하거나 자금을 빼갈 수 있도록 할 수 있습니다. EOAs의 경우, 계정에 포함된 "코드"는 본질적으로 잘 테스트된 암호학적 기본 요소인 ECDSA 서명 검증이라 할 수 있습니다. 스마트 지갑은 훨씬 더 복잡합니다. 주요 AA 프레임워크(예: ERC-4337의 EntryPoint 계약)는 감사를 받았지만, 각 지갑 구현의 보안은 다양할 수 있습니다. 한 개발자 가이드는 AA 지갑을 사용할 때, "불변의 계약을 배포"하는 것이라고 명시한 바 있습니다. 버그가 발견되면 해당 계약 코드는 쉽게 변경할 수 없기 때문에 패치하기 어려울 수 있습니다. 일부 지갑 계약은 이를 완화하기 위해 업그레이드 가능성 또는 마이그레이션 기능을 포함할 수 있지만, 이는 곧 신뢰 문제를 도입하게 됩니다(이를 누가 업그레이드할 수 있는가?). 지갑 계약의 감사를 철저히 하는 것이 중요합니다.

• 복잡성과 새로운 실패 모드: AA 아키텍처(번들러, 페이마스터, 개별 메모리풀 포함)는 현재 상태보다 더 복잡합니다. 이는 더 많은 오류나 공격 가능성 있는 요소를 의미합니다. 예를 들어, 초기 단계에서 번들러 네트워크가 충분히 분산되지 않았다면 어떻게 될까요? 번들러가 특정 UserOps를 검열하거나 높은 수수료를 요구할 수 있을까요? 소수의 행위자가 주요 번들러로 자리 잡을 경우, 중앙집중화의 위험이 있습니다. 시간이 지남에 따라, 많은 이더리움 노드 또는 채굴자/검증자가 번들러 소프트웨어를 구동할 수 있는(특히 경제적 인센티브가 있는 경우) 것으로 기대되지만, 초기 단계에서는 사용자들이 UserOps의 메모리풀과 번들러가 정직하게 작동한다고 신뢰해야 합니다. EntryPoint 계약도 또 다른 중앙 신뢰점입니다 - 만약 여기서 취약성이 발견된다면, 모든 AA 사용자들에게 영향을 미칠 수 있습니다. 이더리움 커뮤니티는 이에 대한 예방 조치를 취해 왔습니다(견출자 다중 서명을 통한 업데이트 메커니즘을 통해 버그 발견 시 EntryPoint를 교체할 수 있음) 하지만 여전히 주시해야 할 핵심 부분입니다.

• 자원 비용(가스 및 배포): 스마트 계약 지갑을 사용하는 것은 오버헤드가 있습니다. 계정을 생성하는 데 일회성 배포 비용이 있으며(각 사용자 지갑에 대해 새로운 계약을 블록체인에 게시해야 하는데, Counterfactual 배포 패턴을 사용하지 않는 한) 이더리움 메인넷에서 가스비로 몇 달러가 들 수 있으며, 이는 일부 사용자를 저어하거나 지갑이 이러한 비용을 후원해야 할 수도 있습니다. 또한, 스마트 지갑을 통한 각 운영은 간단한 EOA 거래보다 가스를 더 많이 소모할 수 있습니다. EntryPoint 호출, 추가 코드 실행 등이 필요하기 때문입니다. 그러나 일부는 배치 실행 효율성을 통해 상쇄될 수 있습니다. 그렇지만 온체인 활동이 많을 경우, 이러한 비용이 증가합니다. 초기 단계에서 계정 추상화는 레이어-2(가스가 저렴한)에서 더 일반적이거나 레이어-1의 고가치 사례에 한정될 수 있습니다. 좋은 소식은 이더리움 개발자들이 이 문제를 인식하고 있으며 AA를 더 가스 효율적으로 만들기 위해 프로토콜 변경을 작업 중이라는 것입니다. 예를 들어, "InitCode 압축"과 같은 제안이나 다른 EIP는 스마트 계정의 배포 및 사용 비용을 줄이는 것을 목표로 하며, AA가 기본 형태가 된다면 장기적으로 프로토콜이 이를 최적화할 수 있습니다.

• 키 관리가 여전히 중요함(말 그대로): 계정 추상이 프라이빗 키를 제거하지는 않습니다 - 키를 사용하는 방식에 층을 추가할 뿐입니다. 귀하는 여전히 계정의 소유자임을 인증하기 위해 프라이빗 키 또는 비밀을 필요로 합니다(키가 여러 당사자 간에 분할되거나 하드웨어에 저장되더라도). 사용자가 키에 대한 보안이 불량하면 여전히 해킹당할 수 있습니다. AA는 소셜 복구 등의 도구를 제공합니다. 그러나 사용자가 실제로 이를 사용하고 적절하게 설정해야 합니다. 일부 비평가는 많은 사용자가 기본 설정(계정을 제어하는 단일 키)을 고수할 것으로 지적합니다(EOA를 다시 도입하되 복잡성 증가). 이 경우, 수호자 또는 2FA를 결코 구성하지 않으면, 많은 보안을 얻지 못할 것이며, 새로운 지갑 모델을 이해하지 못하면 더 많은 위험에 처할 수 있습니다. 요약하자면, 계정 추상화는 잠재적 보안을 크게 개선하지만, 이를 보증하지는 않습니다. 사용자에게 더 안전한 설정으로 안내할 수 있는 좋은 UX가 필요합니다 (지갑 온보딩 동안 수호자나 백업 키를 추가하라는 프롬프트 등).

• 아직 보편화되지 않음: 2025년 기준으로, ERC-4337을 통한 계정 추상화가 이더리움에서 가능하지만, 지갑 제공자가 이를 지원해야 합니다. 현재 사용하는 지갑(메타마스크 또는 하드웨어 지갑 등)이 4337 스마트 계정 생성 및 관리를 지원하지 않으면, AA를 사용하려면 교체해야 혜택을 받을 수 없습니다. 우리는 EOA와 AA 계정이 공존하는 전환기에 있습니다. 이는 사용자 혼란 및 마찰을 초래할 수 있습니다. 예를 들어, AA 계정은 자체 주소를 가지고 있습니다(어느 이더리움 주소처럼 보이지만 실제로는 계약입니다). 누군가가 ETH를 당신의 AA 지갑 주소로 보낸다면, 괜찮습니다 - 주소니까요 - 하지만 ETH를 보내려면 간단한 EOA 트랜잭션 대신 AA 플로우를 따라야 합니다. 고급 사용자들은 호환성에 대해 우려할 수 있습니다: "이 dApp이 내Here's the translation formatted according to your specifications:

Content: 스마트 지갑?” 일반적으로, AA 지갑이 잘 설계되었다면, 모든 dApp과 호환되어야 합니다 (dApp 측에서는 단지 계약 호출을 하는 주소이기 때문입니다). 하지만 일부 저수준의 도구 (예: 몇몇 블록체인 탐색기나 구형 지갑)에서는 이러한 트랜잭션을 완전히 인식하지 못할 수 있습니다. 시간이 지나면서 ERC-4337과 같은 표준이 문제가 없어야 하지만, 생태계가 뒤따라야 합니다 — 체인 탐색기, 하드웨어 지갑 펌웨어 등의 업데이트가 필요할 수 있습니다.

• 상호운용성 및 다중체인: 여러 체인(L1, L2, 사이드체인)에서 스마트 계정을 사용하는 경우, 각 체인에 계약을 배포해야 할 수도 있습니다. 현재, 계정 배포를 체인 간 "복제 가능"하게 만드는 작업이 진행 중입니다. 그러나 이것이 완전히 해결될 때까지, 하나의 네트워크에서 AA를 사용한다고 해서 다른 네트워크에서 자동적으로 제공되는 것은 아닙니다 – 각 체인에 대한 설정이 필요할 수 있습니다.

• 기존 사용자에 대한 전환 문제: 이미 귀중한 자산을 보유한 EOA들이 많이 있습니다 (예: 영혼 결합형 NFT 등). 이러한 사용자들이 계정 추상화를 원할 경우, 어떻게 전환할 수 있을까요? 한 가지 접근 방식은 EIP-7702와 같은 프로토콜 업그레이드입니다. 이는 주소를 변경하지 않고도 스마트 계약 기능을 채택할 수 있도록 제안되었습니다. 하지만 이러한 업그레이드가 이루어지기 전에는, AA 기능을 얻기 위해 새 계정을 만들어야 할 수도 있으며, 이는 번거로울 수 있습니다. 사용자는 스마트 지갑으로 이동하는 것이 왜 유리한지 이해해야 하며, EOAs와의 "고장나지 않으면 고치지 마세요"라는 불활성에서 벗어나야 합니다.

전반적으로, 이더리움 커뮤니티는 계정 추상화의 장점이 단점을 훨씬 능가하고 있으며, 이러한 제약 사항들이 적극적으로 해결되고 있습니다. 새로운 기술은 종종 높은 복잡성으로 시작되지만 시간이 지나면서 부드러워지는 경우가 많습니다. 최초의 스마트폰은 사용하기 어렵고 배터리 수명이 짧았지만, 지금은 필수적이고 사용자 친화적입니다. 마찬가지로, AA 지갑도 몇 년 후 사회적 회수나 가스 없는 거래와 같은 기능 없이는 살 수 없다고 느낄 수 있습니다.

완전한 계정 추상화를 향하여

이더리움에서의 계정 추상화, 특히 ERC-4337을 통해, 중요한 이정표가 되는 것은 분명하지만, 종종 여정의 한 걸음으로 간주됩니다. 많은 이더리움 핵심 개발자들이 표현한 궁극적인 비전은 프로토콜 수준에서 "완전한 계정 추상화"를 달성하는 것입니다. 모든 계정이 스마트 계정이 되고, EOA의 기존 개념은 사라지게 됩니다. 이를 달성하기 위해 향후 몇 년간 추가적인 업그레이드와 신중한 전환 전략이 필요할 것입니다.

1. 프로토콜 수준 통합: 현재 ERC-4337은 EntryPoint 계약을 통해 이더리움의 기존 트랜잭션 메커니즘을 이용하여 응용 프로그램 계층에서 운영됩니다. 장기적으로 이더리움은 프로토콜(Layer 1)에 계정 추상화를 직접 통합하여 프로세스를 간소화할 수 있습니다. 이는 새로운 트랜잭션 유형을 도입하거나 스마트 계약 지갑이 트랜잭션을 번들과의 간접 접근 없이 시작할 수 있도록 합의 규칙을 변경하는 것을 의미할 수 있습니다. 사실, 4337 접근 방식이 첫 선택이었지만 깊이 있는 변화가 배제되지는 않았습니다.

2. EOAs를 스마트 계정으로 전환: 완전한 계정 추상화를 위해 새로운 EOAs는 더 이상 생성되지 않아야 합니다. 새로운 계정은 기본적으로 스마트 계정이어야 합니다. 이는 사용자가 탑승할 때 메타마스크 같은 지갑 소프트웨어가 순수 키 계정 대신 4337 스마트 지갑을 생성하기 시작한다면 가능합니다.

The rest of the translation should follow the same style and formatting, maintaining markdown links and not translating them. Let me know if you need any more assistance with translating or formatting!모든 사용자를 하룻밤 사이에 강제로 전환하게 만들 순 없지만, 그 추세는 있습니다. 이더리움 개발자들은 궁극적으로 대다수의 사용자가 스마트 계정으로 전환하여 보안성과 사용 편의성의 이점을 누리고, 그 가정에 따라 프로토콜을 최적화할 수 있는 로드맵을 구상했습니다(예를 들어, 언젠가 모든 사용자가 페이마스터와 같은 것을 사용한다면 이더리움은 ETH로 지불하는 가스의 개념을 없앨 수도 있습니다. 하지만 이는 매우 추측적인 이야기입니다).

Final thoughts

계정 추상화는 블록체인 계정 관리의 패러다임 전환을 나타냅니다. 사용자가 스마트 계약을 계정으로 활용할 수 있게 함으로써 과거의 엄격한 제한을 깨고 사용자가 보안에 대한 더 많은 통제를 가진 채 전통적인 은행 앱을 사용하는 것만큼 - 또는 그보다 더 쉽게 - 암호화를 사용할 수 있는 미래를 열어줍니다. 더 이상 하나의 키 분실이 돌이킬 수 없는 비극이 아니며, 더 이상 매번 수동으로 모든 작업에 서명하거나 dApp을 사용하기 위해 여분의 ETH를 가져야 할 필요가 없습니다. 계정 추상화를 통해 사회적 복구, 다중 서명 보안, 자동 결제, 일괄 거래, 가스 무료 사용과 같은 기능이 해킹이나 꿈이 아니라 점점 표준 도구가 되고 있습니다.

실질적으로, 계정 추상화는 더 넓은 암호화 채택의 두 가지 가장 큰 장벽인 사용자 경험과 안전을 직접 해결하기 때문에 중요합니다. 사용자 경험을 개선(맞춤형 지갑 규칙, 원하는 인증 방법 등)하고 포용성(다른 사람이 수수료를 지불하며, 간단한 로그인 방법 사용, 실수에서 회복)까지 제공합니다. 이 기술은 Web3를 사용자 친화적으로 만드는 기본 요소입니다. 이더리움의 리더십과 많은 커뮤니티 구성원이 생태계의 성공에 필수적이라고 여길 정도로 중요한 요소입니다. 계정 추상화는 솔루션의 큰 부분을 차지하고 있습니다.

현재 이더리움의 ERC-4337 및 다양한 레이어-2 네트워크의 네이티브 구현에서 이를 초기 단계로 볼 수 있습니다. 오는 몇 년간 더 매끄러운 통합이 이루어질 가능성이 높습니다. 당신은 탈중앙화 앱을 사용하면서도 실제로는 백그라운드에서 당신의 "계정"이 모든 것을 매끄럽게 준비하는 스마트 계약임을 깨닫지 못할 수 있습니다. 지갑 제공자, dApp 개발자, 사용자 모두 마찰을 줄이고 더 많은 가능성을 얻을 수 있습니다.

물론, 이 새로운 모델을 채택할 때 경각심이 필요합니다 - 스마트 계약 지갑은 신중하게 구축되고 감사되어야 하며, 사용자도 사회적 복구와 같은 새로운 기능에 대해 교육을 받아야 합니다. 하지만 그러한 도전은 오늘날의 지갑이 가진 UX 악몽과 보안 문제에 비하면 관리 가능한 수준입니다.

결론적으로, 계정 추상화는 블록체인 기술의 성숙을 향한 한 걸음으로 볼 수 있습니다. 인터넷이 명령줄 인터페이스에서 오늘날의 사용자 친화적인 웹으로 발전한 것처럼, 블록체인은 원시 키 관리의 시대에서 스마트 계정의 시대로 발전하고 있습니다. 이는 인프라 내에서 조용한 혁명이지만, 그 효과는 사용자에게 직접적으로 느껴질 것입니다: 더욱 안전한 자금, 더 쉬운 로그인, 디지털 자산과 상호작용하는 더욱 강력한 방법. 기술이 계속 발전함에 따라 "비밀번호를 잊어버렸다"거나 "이 앱을 24시간 허용한다"는 기능이 암호화된 용어의 일부가 되었을 때 놀라지 마십시오. 이는 계정 추상화가 작동하여 암호화를 다른 디지털 서비스만큼이나 자연스럽게 만들어주는 동시에, 우리를 블록체인으로 이끌어준 자유와 주권을 여전히 제공하는 것입니다.