이더넷, 솔라나, 코스모스 계정 추상화 솔루션의 유사점과 차이점에 대한 연구

저자: Zeqing Guo & Jinming Neo, HashKey Capital; Golden Finance 번역 xiaozou

1, 계정 추상화(AA)가 필요한 이유는 무엇인가요?

오늘날 블록체인 업계에는 해결되지 않은 많은 문제들이 있습니다. 그중에서도 블록체인 사용의 어려움, 즉 블록체인과 상호작용하는 사용자 경험(UX)은 대중의 불만이 가장 많은 분야입니다.

예를 들어, 많은 사람들은 키를 사용하는 것이 이메일을 사용하여 계정을 관리하는 것보다 더 복잡하고, 키 관리가 어렵고 안전하지 않으며, 송금할 때마다 여전히 네이티브 토큰(예: 이더, 솔)이 필요하다는 점을 직관적이지 않다고 생각합니다(예: USDC).

이러한 맥락에서 온체인 상호작용의 사용자 경험을 개선하고 대량 채택을 촉진하기 위해 계정 추상화 분야에 점점 더 많은 관심이 쏠리고 있습니다.

탐색 과정에서 이더리움은 ERC-4337, EIP-3074, EIP-7702와 같은 계정 추상화 솔루션을 제안했습니다. 다른 L1(예: Solana)에는 프로토콜 수준의 계정 추상화를 지원하는 기능(예: 프로그램 파생 주소 PDA)이 있으며, Cosmos에도 유사한 설계(예: x/authz 및 수수료 추상화 모듈)가 있습니다. 이 백서에서는 위의 솔루션을 소개 및 비교하고, 다양한 솔루션 설계의 미묘한 차이를 이해하며, 각 솔루션의 장단점과 주의 사항을 설명합니다.

2, 배경

(1)EOA 및 컨트랙트 계정

이더 백서에 정의된 두 가지 계정 유형은 외부 계정(EOS)과 컨트랙트 계정입니다.EOA 계정은 개인 키로 제어되며, 사용자는 다양한 거래에 서명하고 계정의 자산을 제어할 수 있습니다. 컨트랙트 계정은 컨트랙트 계정 자체의 코드로 제어되며, 다른 계정은 컨트랙트 계정의 코드를 호출하여 컨트랙트 계정이 특정 로직을 수행하도록 허용할 수 있습니다.

(2) 계정 추상화

추상 계정 개념은 2016년으로 거슬러 올라갑니다. 계정 추상화는 현재 이더리움의 두 가지 계정 유형인 EOA 계정과 컨트랙트 계정을 기반으로 구축되었습니다. 이는 다음과 같은 방식으로 이더리움 사용자의 대화형 경험을 개선합니다.

- 사용자가 슈노르, BLS, 포스트퀀텀 서명 등과 같은 여러 서명을 사용할 수 있도록 허용하고,

- 사용자가 다음과 같이 가스 요금을 지불할 수 있도록 허용합니다. 사용자가 ERC20 토큰 또는 사용자 지정 결제 로직을 사용하여 가스 요금을 지불할 수 있도록 허용

- 사용자가 이메일, 소셜 미디어 등을 사용하여 자신의 계정을 검색할 수 있도록 허용

- 사용자가 다음을 수행할 수 있도록 허용합니다. 일일 출금 한도 설정과 같은 세분화된 권한으로 계정의 자금을 관리할 수 있습니다.

- 단일 아토믹 트랜잭션에서 여러 온체인 작업을 수행할 수 있도록 허용합니다. 예를 들어, 사용자는 단일 서명을 사용하여 DEX 트랜잭션에서 승인과 교환 작업을 완료할 수 있습니다.

(3) 이더 로드맵

이더 로드맵은 이더의 향후 업그레이드 경로를 강조합니다. 현재 이더리움 커뮤니티의 대부분의 연구는 이더리움 로드맵을 중심으로 이루어지고 있습니다. 계정 추상화는 이 중 필수적인 부분입니다.

이더넷 커뮤니티는 ERC-4337을 기반으로 프로토콜 내에서 계정 추상화 솔루션을 구현하고, EIP-3074 또는 EIP-7702와 같은 제안을 통해 최종적으로 엔드게임 계정 추상화를 구현하기를 희망하고 있습니다.

향상된 사용자 경험에도 불구하고 계정 추상화 엔드게임은 양자 컴퓨팅 시대에 EOA 계정에 사용되는 현재 ECDSA 알고리즘이 안전하지 않기 때문에 이더리움의 양자 컴퓨팅 방지를 위해서도 매우 중요합니다. 양자 이후 서명을 지원하기 위해 계정 추상화를 채택하면 양자 컴퓨팅으로 인한 진화하는 위협으로부터 사용자 계정을 보호할 수 있습니다.

3, EIP-3074, ERC-4337

계정 추상화 계정을 이해하려면 EOA가 어떻게 작동하는지 이해해야 합니다. 다음 다이어그램은 체인에서 가장 일반적인 토큰 구매 및 판매 과정을 보여줍니다:

일반적으로 사용자는 토큰을 구매하거나 판매할 때 두 가지 트랜잭션을 보내야 합니다: 먼저 유니스왑에 거래소를 위해 USDC를 전송하도록 승인한 다음, 유니스왑에 작업을 수행하도록 요청하는 다른 트랜잭션을 보냅니다. 유니스왑은 사용자 계정에서 USDC를 전송하고 현재 가격을 기준으로 적절한 양의 이더를 사용자에게 보냅니다.

ERC-4337은 위의 두 트랜잭션을 하나로 결합합니다.

위 다이어그램에서 볼 수 있듯이, 번들러가 사용자의 EOA 계정과 다른 계정 4337에서 사용자의 자산을 조작할 수 있도록 승인하려면 두 개의 서명이 필요합니다. 번들러는 승인을 받은 후 승인을 트랜잭션 패키지에 병합하고 해당 패키지를 게시하여 트랜잭션을 완료합니다. 또한 사용자에게 가스비 지불에 사용되는 이더 토큰이 없는 경우, 페이마스터 역할을 도입하여 페이마스터가 가스비를 지불하고 사용자로부터 동등한 ERC20 토큰을 받을 수 있도록 할 수 있습니다.

EIP-3074와 ERC-4337은 몇 가지 유사점이 있지만, EIP-3074의 구현은 이더 프로토콜 내에 있습니다:

ERC-4337에서는 서명을 통해 번들러가 온체인 스마트 컨트랙트 지갑의 자산을 처리하도록 승인합니다. EIP-3074에서는 번들러가 서명을 통해 EOA 지갑의 자산을 직접 처리할 수 있는 권한이 부여됩니다. 이를 위해 이더리움 커뮤니티는 이더리움 프로토콜에 두 가지 새로운 옵코드인 AUTH와 AUTHCALL을 추가해야 합니다.

AUTH는 번들러가 사용자의 EOA 계정에서 자산을 취급하는 것이 승인되었는지 확인하는 데 사용되며, AUTHCALL은 다음을 수행하는 데 사용됩니다. 사용자 상호작용 스마트 컨트랙트(예시에서는 USDC와 유니스왑)를 사용자의 EOA 계정에서 거래가 발생한 것처럼 "스푸핑"합니다. 이는 유니스왑과 USDC 관리자가 배포된 스마트 콘트랙트를 업그레이드할 필요가 없고, EOA 계정은 계정 추상화 기능을 계속 사용할 수 있다는 장점이 있습니다.

(1) EIP-3074와 ERC-4337

이더넷 커뮤니티에서 EIP는 일반적으로 이더넷 업그레이드가 필요한 제안을 가리키며, ERC는 이더넷 업그레이드가 필요하지 않은 사양을 가리킵니다.

따라서 두 계정 추상화 체계의 이름에서 알 수 있듯이 ERC-4337은 이더넷 네트워크의 하드 포크가 필요하지 않으므로 EIP-3074보다 구현하기가 더 쉽습니다. 이것이 ERC-4337이 출시되어 폴리곤과 베이스에서 점점 더 많이 사용되는 이유 중 하나이지만, EIP-3074는 제183차 이더넷 올코어 개발자 임원 회의(ACDE)에서 막 승인된 상태입니다.

또한, ERC-. 4337은 사용자가 현재 계정을 새 컨트랙트 계정으로 마이그레이션해야 하며, 디앱이 EIP-1271의 기능을 지원하도록 요구합니다.EIP-3074는 이러한 추가 지원이 필요하지 않습니다. 이것이 ERC-4337의 채택률이 낮은 주된 이유입니다. 또한 ERC-4337은 중간 다중 호출 컨트랙트를 도입하지 않고는 여러 온체인 작업을 승인하는 단일 서명을 지원할 수 없는 반면, EIP-3074는 가능하다는 점도 ERC-4337의 한계에 영향을 미칩니다.

그러나 EIP-3074에는 자체적인 문제도 있습니다. 가장 중요한 문제는 연산 코드 AUTH에 너무 많은 권한이 부여되어 공격자가 사용자의 EOA 계정을 완전히 제어할 수 있다는 것입니다. 결국, 해커가 사용자를 속여 AUTH 서명을 수행하기만 하면 사용자의 EOA 지갑에 있는 자산을 처분할 수 있습니다. 요즘 피싱 공격이 기승을 부리고 있고, 대부분 사용자 서명을 스푸핑하여 이루어지고 있다는 점을 고려할 때, EIP-3074가 구현되면 이는 더욱 심각한 문제가 될 것입니다.

이에 대응하여 EIP-3074의 작성자 중 하나인 lightclient는 지갑 수준에서 악성 서명을 가로채는 완화 방법을 제안했습니다. erc-4337에는 이 문제가 없지만 해커는 여전히 사용자를 속여 악성 UserOps에 서명할 수 있습니다. 왜냐하면 UserOp 은 사용자 계정의 모든 자산을 처분할 수 있는 권한을 얻기가 어렵기 때문입니다. 이 글을 쓰는 시점에 ACDE 개발자들은 펙트라 데브넷 0에서 EIP-3704를 제거하고 다음 펙트라 데브넷 1에 EIP-7702를 포함하기로 합의했습니다.

(2)< strong>EIP-7702에서 변경된 사항은 무엇인가요?

EIP-7702는 EIP-3074와 ERC-4337의 장점을 통합하려고 시도하며 중간 경로를 취합니다. 사용자는 서명된 작업을 번들러에게 전송합니다. 번들러가 트랜잭션을 체인에 전송하면 사용자의 EOA 계정은 일시적으로 4337 계정과 같은 스마트 컨트랙트 계정이 됩니다. 다음으로, EIP-3074의 AUTH 프로세스와 유사하게 스마트 컨트랙트 계정은 사용자가 승인한 번들러 작업의 유효성을 검사합니다. 그런 다음 AUTHCALL과 마찬가지로 사용자가 승인한 작업이 실행됩니다. 트랜잭션이 실행된 후 사용자 계정은 일반 EOA 계정으로 롤백됩니다.

EIP-7702의 장점은 다음과 같습니다:

- EIP-3074의 모든 장점 상속: 사용자가 새로운 주소를 가진 스마트 컨트랙트 계정으로 전환할 필요가 없으며, 다음을 수행할 수 있습니다. 단일 아토믹 트랜잭션에서 여러 작업을 수행할 수 있습니다.

- ERC-4337의 스마트 컨트랙트 계정 코드와 인프라를 재사용할 수 있습니다.

- ERC-4337이 나타내는 스마트 컨트랙트 계정 추상화와 ERC-4337이 나타내는 스마트 컨트랙트 계정 추상화는 다시 사용할 수 있습니다. ERC-4337로 대표되는 스마트 컨트랙트 계정 추상화와 EIP-3074로 대표되는 EOA 계정 추상화 솔루션을 병합하여 이더리움이 두 개의 다른 계정 추상화 시스템으로 분리되는 것을 방지하고 이더리움 로드맵에서 추상 계정 종말을 위한 길을 열 수 있습니다.

- AUTH 및 AUTHCALL 옵코드는 이더넷의 EVM에 추가되지 않습니다. 이더넷 로드맵에 따라 향후 EOA 계정은 계정 추상화 계정으로 전환될 것이며, 이 시점에서 이 두 개의 옵코드는 중복될 것입니다.

또한 EIP-7702는 EIP-3074의 모든 보안 위험을 상속합니다.

커뮤니티는 2025년 펙트라 업그레이드에 EIP-7702를 포함시키기로 결정했으며, 실현될 경우 이더리움 생태계를 극적으로 변화시키고 현재 ERC-4337 버전의 계정 추상화 인프라를 점진적으로 개선할 것으로 기대됩니다.

4, 솔라나의 절차적 파생 주소(PDA)

(1)솔라나의 계정 추상화

솔라나의 계정 추상화는 이더의 ERC-4337과 유사하며, 원래 계정에서 파생된 계정입니다(유사 계정인 EOA 계정)에서 파생된 계정으로, 4337 컨트랙트 계정과 유사합니다. 솔라나의 계정 추상화를 이해하기 전에 솔라나에서 사용하는 계정 모델을 이해할 필요가 있습니다.

대략적으로 계정은 코드를 실행할 수 있는 실행 가능 계정과 코드를 실행할 수 없는 비실행 가능 계정으로 분류할 수 있습니다. 좀 더 자세히 살펴보면, 솔라나에는 네이티브 프로그램, 프로그램 계정, 데이터 계정의 세 가지 유형의 계정이 있습니다.

네이티브 프로그램은 검증자 구현의 일부이며, 새로운 데이터 계정과 사용자 지정 프로그램을 생성하는 등 솔라나 네트워크의 핵심 기능을 제공합니다. 프로그램 계정은 실행 코드가 포함된 사용자 지정 프로그램입니다. 데이터 계정은 소유자 프로그램 계정에서 정의한 대로 데이터를 저장하고 프로그램 상태를 관리할 수 있습니다.

이 계정 모델을 사용하면 프로그램 계정으로 특정 계정을 만들고 관리할 수 있으므로 개발자는 사용자 지정 규칙과 로직을 정의하여 계정을 관리할 수 있습니다. 이 계정 모델의 지원으로 데이터 계정의 일종인 PDA(프로그램 파생 주소)는 다중 서명 지갑과 2단계 인증을 통한 사용자 보안 강화부터 소셜 복구 메커니즘 활성화에 이르기까지 Solana에서 계정 추상화의 가능성을 확장합니다.

(2 ) 프로시저 파생 주소

맥락상, 모든 계정은 Ed25519 곡선 위에 있고 공개-개인 키 쌍을 가지며, PDA는 Ed25519 곡선 밖에 있고 결정론적으로 파생된 32바이트 문자열로 공개 키처럼 보이지만 해당 개인 키가 없습니다. PDA를 통해 개발자는 PDA의 프로그램 계정 소유자가 PDA를 대신하여 거래를 자율적으로 실행할 수 있는 사용자 지정 규칙과 거래 서명 메커니즘을 만들 수 있으며, 이는 솔라나 네트워크에서 완전히 승인하고 지원합니다.

(3 )PDA와 계정 추상화

PDA가 어떻게 파생되는지 이해했으니 이제 이 개념이 계정 추상화와 어떤 관련이 있는지 궁금할 것입니다. 계정 추상화는 교차 프로시저 호출(CPI)이라는 함수의 성능을 통해 맨 아래에서 구현됩니다.

CPI는 한 프로그램이 다른 프로그램에서 명령을 호출할 수 있게 함으로써 Solana 프로그램의 구성성을 가능하게 하는 기능입니다. 프로그램이 invoke_signed를 통해 CPI를 시작하면, 프로그램은 파생된 PDA를 대신하여 서명할 수 있습니다.

PDA 관련 거래의 적법성을 확인하기 위해 트랜잭션이 합법적인지 확인하기 위해 Solana 런타임은 내부적으로 호출자의 signers_seeds 및 program_id를 사용하여 create_program_address를 호출합니다. 유효한 PDA가 발견되면 런타임은 PDA를 호출자의 프로그램과 연결하고 해당 프로그램을 승인된 서명자로 식별합니다. 서명자로 식별합니다.

현재 Squads는 Solana 계정 추상화를 위한 PDA 기반 솔루션을 개발 중입니다. 그러나 Squads의 솔루션은 현재 노시스 세이프의 스마트 컨트랙트 계정 솔루션과 더 유사하며 아직 계정 추상화 기능을 완전히 개발하지 못했습니다.

(4)PDA의 이점

-스마트 컨트랙트의 자동화된 실행: PDA는 보다 복잡한 프로그램 간 호출을 통해 사용자를 대신하여 여러 작업을 자율적으로 수행할 수 있는 스마트 컨트랙트 설계를 지원합니다.

- 향상된 사용자 경험: 사용자는 여러 거래를 관리하거나 기술적 복잡성을 처리할 필요가 없습니다.

-보안 및 유연성 강화: 개인 키가 없으므로 키 유출 위험이 감소하며, PDA는 다중 서명 지갑이나 기타 유연한 거버넌스 모델에 사용할 수 있어 단일 위험 지점을 완화하고 대규모 공유 리소스를 관리하는 조직에 특히 효과적입니다.

(5)PDA의 한계

PDA는 계정 추상화 기능의 토대를 마련하는 데 도움이 되지만 키보다 구현하기 어려울 수 있습니다. 쌍 계정은 키 계정에 비해 구현하기가 복잡할 수 있습니다.

ERC-4337과 마찬가지로 사용자가 새 계정으로 계정 마이그레이션을 수행해야 하므로 솔라나 계정 추상화 도입을 저해할 수 있습니다.

5, Cosmos에서의 계정 추상화(Authz 및 Fee Grant)

(1)Cosmos x/authz

계정 추상화가 점점 더 많은 개발자들의 관심을 끌면서 개발자들의 관심을 끌면서, 한 계정이 인증을 통해 다른 계정을 대신하여 특정 작업을 수행할 수 있도록 하기 위해 EIP-3074 및 EIP-7702와 유사하게 authz(핵심 Cosmos SDK의 일부)가 도입되었습니다.

Authz에는 서약과 같은 특정 작업의 수행을 권한 있는 사람에게 위임하여 사용자 경험을 향상시키는 몇 가지 사전 정의된 권한 부여 유형이 있습니다.

오츠에는 3가지 유형의 권한 부여가 가능합니다.

- 일반 권한: 이 권한은 은 권한을 부여받은 사람에게 권한 부여자를 대신하여 메시지를 실행할 수 있는 무제한 권한을 부여합니다.

- SendAuthorization: ERC20의 승인과 마찬가지로 이 권한은 승인된 사람에게 양수 지출 한도를 제공하기 위한 것으로, 승인된 사람을 대신하여 지출할 수 있는 최대 금액을 정의합니다.

- StakeAuthorization: 이 권한은 허가자를 대신하여 위임, 위임 취소 또는 재위임과 같은 위임 작업을 관리할 수 있게 해줍니다.

권한은 권한 부여자의 주소 바이트, 권한 부여 대상자의 주소 바이트 및 권한 부여 유형으로 구성됩니다. 기간을 정의하여 특정 기간 동안 승인을 제한할 수도 있습니다. 각 블록이 끝날 때마다 네트워크는 가지치기라는 프로세스를 통해 만료된 인증을 제거합니다.

운영 프레임워크 이해

Authz는 다양한 작업에 대한 인증을 제공하는 데 사용할 수 있지만, 간단하게 설명하기 위해 범용 일반 폴링 트랜잭션을 가능하게 하는 Authz의 작동 방식을 살펴보기로 하겠습니다.

- 인증을 수행하기 전에 인증 인터페이스를 구현합니다. 이 단계에서는 메시지 유형도 정의합니다. 여기에서는 거버넌스 투표 작업에 대해 Alice가 부여한 권한을 볼 수 있습니다.

- Bob은 서명되지 않은 투표 트랜잭션을 생성합니다.

- Bob은 수증자로부터 서명되고 실행된 투표 트랜잭션을 생성합니다. 트랜잭션이 완료되고 만료된 트랜잭션은 삭제됩니다.

자동 인증의 장점은 무엇인가요?

- 운영 보안: 검증자와 다른 사용자가 거버넌스 제안에 투표하거나 특정 작업을 수행할 수 있도록 별도의 계정을 승인하여 계정 보안을 강화하고 보안 부담을 줄일 수 있습니다.

-운영 간소화: 검증자의 키에 액세스할 필요 없이 거래를 실행할 수 있으며, 단일 거래를 사용하여 인증된 계정에 대한 Authz 인증을 수행함으로써 다중 서명 지갑 거래를 간소화할 수 있습니다.

- 마이그레이션 필요 없음: EIP-3074 및 EIP-7702와 마찬가지로 인증 작업은 사용자의 원래 계정에서 이루어집니다. 사용자는 계정 추상화를 활성화하기 위해 기존 계정에서 새 계정으로 자산을 이전할 필요가 없습니다.

- DAO 운영 효율성 및 유연성: 특정 작업을 수행하기 위해 각 DAO 멤버에게 실행 권한의 일부를 부여할 수 있습니다.

- 서약 보상 합성: Authz는 리플렛지 및 이와 동등한 서비스를 사용하여 서약 보상을 자동으로 합성할 수 있도록 지원합니다.

오츠의 한계와 위험성:

오츠를 통해 승인되는 거래 유형에 유의해야 합니다. 악의적인 인증은 사용자에게 해로울 수 있는 다양한 유형의 인증을 수행할 수 있습니다.

- 일반인증: 인증자를 대신하여 모든 다중 서명을 수행할 수 있는 무제한 권한을 부여합니다. 서명할 내용을 완전히 이해하지 못한다면 이러한 유형의 승인에 서명하지 않는 것이 좋습니다. 일부 지갑은 Authz 트랜잭션에 서명할 때 경고를 제공하지 않을 수도 있습니다.

- SendAuthorization: 승인자가 특정 금액을 지정하지 않은 경우 승인자가 사용할 수 있는 최대 토큰 수를 전송할 수 있도록 허용합니다. 또한 승인된 사람이 보낸 토큰을 받을 수 있는 특정 주소를 지정하는 허용 목록을 확인하는 것도 중요합니다.

(2) 수수료 부여 모듈

또 다른 사용자 경험의 장애물은 블록체인 사용자가 토큰을 지불해야 한다는 사실을 인지해야 한다는 점입니다. 또 다른 장애물은 블록체인 사용자가 다양한 생태계와 상호작용하기 위해 다양한 네이티브 토큰을 보유해야 한다는 점입니다. 이는 전반적인 사용자 경험, 특히 코스모스 생태계에 존재하는 무수히 많은 체인을 처음 접하는 비암호화 네이티브 사용자의 경험을 저해합니다.

그러나 수수료 보조금 모듈의 통합으로 이 문제에 대한 돌파구가 마련되었습니다. 이더에서 계정 추상화를 구현하는 페이마스터 계약과 유사하게, 코스모스의 수수료 보조금 모듈은 승인자가 거래 수수료의 일부 또는 전부를 지불하도록 승인된 사람에게 수수료 수당을 부여할 수 있게 해줍니다. 자금은 승인자의 통제 하에 있으며 승인 수당은 언제든지 취소할 수 있습니다.

비용 승인 분류

비용 승인은 기본 승인(기본 수당)과 정기 수당.

기본수당은 승인된 사람이 지출 한도 또는 만료 시간에 도달할 때까지 승인자의 계정에서 비용을 사용할 수 있도록 허용한 다음 승인 상태가 종료됩니다. 기본 수당은 일회성 경비 승인을 구현한다는 점에 유의하세요. 지출 한도 및 시간을 null로 설정하면 경비 승인에는 만료일이나 지출 한도가 없습니다.

기간별 허용은 지정된 기간마다 비용 허용을 주기적으로 업데이트할 수 있도록 합니다. period_spend_limit은 주어진 기간에 사용할 수 있는 최대 토큰 수를 지정합니다. period_reset은 다음 기간을 추적하고 를 추적하고, period_can_spend는 새 기간이 시작되기 전까지 남은 토큰 수를 추적합니다.

운영 프레임워크 이해하기

지정된 메시지 유형에 대한 허용량 허용량을 생성하려면 AllowedMsgAllowance를 사용합니다. 허용량은 BasicAllowance 기본 허용량 또는 PeriodicAllowance 주기적 허용량일 수 있습니다. 만료 만료 시간이 설정된 경우 FeeAllowance는 만료 접두사가 붙은 상태로 대기열에 추가되며, 엔드블로커는 FeeAllowanceQueue 상태를 확인하여 만료되는 허용을 확인하고 만료되는 허용이 발견되면 제거합니다. MsgGrantAllowance 외에도 MsgRevokeAllowance를 사용하여 비용 수당을 취소할 수 있습니다.

요약하자면, Authz와 Fee Grant 모듈은 궁극적으로 코스모스 생태계에서 더 나은 사용자 경험을 구축할 수 있는 다양하고 혁신적인 사용 사례를 열어줍니다.

6, 결론

2024년 5월 27일 기준 계정 추상화 추정치는 다음과 같습니다:

현물 BTC ETF 및 ETH ETF의 승인으로 기관 및 소매 수요가 크게 증가했으며, 암호화폐 산업에 노출되기를 원하는 새로운 사용자들이 유입될 것으로 예상됩니다. 프로토콜과 디앱이 커뮤니티 확장을 위해 원활한 경험을 제공하고자 하는 가운데 계정 추상화는 올해 핵심 화두가 될 것입니다.