계좌 추상화
Account Abstraction은 블록체인 계좌 관리를 어떻게 진행되어야 하는지를 새로운 패러다임으로 바꿉니다. 일반적으로 업비트와 같은 블록체인에서는 두 가지 주요 계좌 유형을 사용해왔습니다: 개인 키를 통제하는 외부로 배포된 계좌(EOA)와, 스마트 컨tracts인 콜백 계좌입니다. Account Abstraction은 이러한 계좌 유형을 일원화하여, 스마트컨tracts가 계좌를 동작하게 함으로써, 사용자 인증 기능, 복구 가능한 계정, 그리고 복잡한 권한 구조 등 추가적인 특징들을 지원합니다. 이 접근 방식은 디CENTRALIZED 애플리케이션(DApp)과의 상호 작용을 간결하게 만들고 보안성을 향상시킵니다. 이를 통해 여러 작업을 하나로 묶핑하는 기능, 유저 편의성 증진 및 다른 토큰으로 가스 비용 지불, 복잡한 권한 구조 등 추가적인 특징들을 지원합니다. 목표는 블록체인과의 상호 작용이 클래식 웹 앱처럼 자연스럽고 안전하다는 것입니다.
블록체인, 특히 이더리움 맥락에서의 계정 추상화(AA)는 외부 소유 계정(EOA)의 한계를 넘어 스마트 계약 기능을 발전시키는 것을 목표로 합니다. EOA는 개인 키로 제어되며 주로 트랜잭션 서명이라는 고정된 기능 세트를 가지고 있습니다. 계정 추상화는 스마트 계약 자체를 계정으로 취급하여 프로그래밍 가능한 로직과 향상된 기능을 부여할 것을 제안합니다. 이는 트랜잭션 검증 및 실행을 위한 "멤풀"을 도입하는 ERC-4337과 같은 표준과 오프체인에서 서명을 검증하기 위한 ERC-1271을 통해 달성됩니다. 주요 이점에는 소셜 복구(신뢰할 수 있는 연락처를 지정하여 시드 문구 없이 계정을 복구), 가스 후원(제3자가 트랜잭션 수수료를 지불하도록 허용) 및 일괄 트랜잭션(여러 작업을 단일 원자 트랜잭션으로 결합)과 같은 향상된 사용자 경험이 포함됩니다. 기술적인 관점에서 AA는 개인 키 암호화를 넘어선 유연한 인증 방법을 허용하여 다중 서명 지갑, 하드웨어 지갑 통합 또는 스마트 계약에서 관리하는 생체 인식 인증까지 가능하게 합니다. 또한 조건부 지출 또는 다단계 승인 프로세스와 같은 더 복잡한 트랜잭션 검증 규칙을 용이하게 합니다. 단점으로는 스마트 계약 개발 및 감사의 복잡성 증가, 더 정교한 계정 로직에 대한 잠재적인 가스 비용 영향, 스마트 계약 계정 자체 내의 취약점을 방지하기 위한 강력한 보안 조치의 필요성이 있습니다.
graph LR
Center["계좌 추상화"]:::main
Pre_blockchain["blockchain"]:::pre --> Center
click Pre_blockchain "/terms/blockchain"
Pre_smart_contracts["smart-contracts"]:::pre --> Center
click Pre_smart_contracts "/terms/smart-contracts"
Pre_ethereum["ethereum"]:::pre --> Center
click Pre_ethereum "/terms/ethereum"
Rel_wallet["wallet"]:::related -.-> Center
click Rel_wallet "/terms/wallet"
Rel_reflection_token["reflection-token"]:::related -.-> Center
click Rel_reflection_token "/terms/reflection-token"
Rel_distributed_ledger_technology_dlt["distributed-ledger-technology-dlt"]:::related -.-> Center
click Rel_distributed_ledger_technology_dlt "/terms/distributed-ledger-technology-dlt"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 지식 테스트
🧒 5살도 이해할 수 있게 설명
일반 온라인 계정을 앞으로만 가는 단순한 장난감 자동차라고 상상해 보세요. 계정 추상화는 친구들이 리모컨을 잃어버렸을 때 도와주거나 자체 가스비를 지불할 수 있는 것처럼 여러 가지 멋진 트릭을 할 수 있는 초강력 로봇 자동차로 만들어 줍니다!
🤓 Expert Deep Dive
주로 이더리움의 ERC-4337 및 관련 표준에 의해 주도되는 계정 추상화(AA)는 스마트 계약을 트랜잭션을 시작할 수 있는 1급 시민으로 취급하여 계정 관리에 혁명을 일으킵니다. 개인 키에 의해서만 제어되는 전통적인 외부 소유 계정(EOA)과 달리, '스마트 계정' 또는 '계약 계정'으로 알려진 AA 지원 계정은 특정 인터페이스(예: IAccountAbstraction)를 준수하는 배포된 스마트 계약입니다.
AA의 핵심은 '결제자(Paymaster)'와 '번들러(Bundler)'의 개념입니다. 번들러는 스마트 계정의 사용자 작업(서명된 트랜잭션)을 집계하여 네트워크에 단일 트랜잭션으로 제출하는 오프체인 엔티티입니다. 이 프로세스는 '사용자 작업 멤풀(UserOperation mempool)'이라는 새로운 멤풀을 통해 촉진됩니다. 또 다른 스마트 계약인 결제자는 사용자에게 가스 수수료를 후원하거나(ERC-20 토큰으로 가스 지불 또는 사용자에게 무료 트랜잭션 허용) 사용자 지정 검증 로직을 강제할 수 있습니다.
스마트 계정에 대한 검증 프로세스는 일반적으로 스마트 계정 계약 내에서 isValidSignature 함수 또는 사용자 지정 validateUserOp 함수를 호출하는 것을 포함합니다. 이 함수는 사용자 작업 해시와 사용자가 제공한 서명을 받습니다. 그런 다음 스마트 계정은 내부 로직을 실행하여 작업을 확인하며, 여기에는 다단계 인증(예: 하드웨어 지갑 서명 및 시간 잠금 백업 요구), 소셜 복구 메커니즘 또는 세션 키가 포함될 수 있습니다.
solidity
// 스마트 계정 검증 로직의 단순화된 예
interface ISmartAccount {
function validateUserOp(UserOperation calldata op, bytes calldata signature) external returns (uint256 validUntil, bytes32 validHash);
}
contract MySmartAccount is ISmartAccount {
address public owner;
address public guardian;
uint256 public recoveryTimeout;
function validateUserOp(UserOperation calldata op, bytes calldata signature) external view override returns (uint256, bytes32) {
// 여기에 서명 검증 로직, 예: ECDSA, 다중 서명 등
// 예: require(ecrecover(keccak256(hash(op)), sig) == owner);
// 수호자 서명을 기반으로 시간 잠금 복구 로직을 구현할 수도 있습니다.
return (block.timestamp + 3600, keccak256(abi.encode(op))); // 1시간 동안 유효
}
}
이 아키텍처 전환은 트랜잭션 서명을 키 관리에서 분리하여 기본 블록체인의 보안 원칙을 손상시키지 않으면서 더 풍부하고 안전하며 사용자 친화적인 상호 작용을 가능하게 합니다.