"Account Abstraction" 태그로 연결된 5 개 게시물 개의 게시물이 있습니다.

AllScale.io는 신흥 시장의 프리랜서와 소규모 기업을 대상으로 하는 합법적인 벤처 지원 스테이블코인 결제 플랫폼이며, 토큰 프로젝트가 아닙니다. 2025년 2월에 설립되었으며 YZi Labs, Draper Dragon, KuCoin Ventures를 포함한 유명 암호화폐 벤처 캐피탈로부터 650만 달러를 지원받았습니다. 이 회사는 Kraken, Capital One, Block에서 검증 가능한 경험을 가진 신원 공개된 팀과 홍콩 사이버포트 인큐베이터의 기관 지원을 통해 긍정적인 신호를 보여줍니다. 그러나 공개 보안 감사의 부재와 플랫폼의 극도로 짧은 역사(1년 미만)는 중요한 참여 전에 신중한 실사를 요구합니다.

AllScale의 역할과 해결하는 문제​

AllScale은 전통적인 해외 결제로 어려움을 겪는 전 세계 6억 개 이상의 소규모 기업 (프리랜서, 콘텐츠 제작자, 중소기업, 원격 계약자)을 위해 특별히 설계된 "세계 최초의 자체 수탁 스테이블코인 네오뱅크"로 자리매김하고 있습니다. 핵심 문제는 국제 프리랜서들이 은행 계좌 장벽, 높은 송금 수수료, 환전 손실, 그리고 종종 5영업일을 초과하는 정산 지연에 직면한다는 것입니다.

이 플랫폼은 기업이 인보이스를 생성하고, 고객이 신용카드, 송금 또는 암호화폐 등 어떤 방식으로 결제하든 USDT 또는 USDC로 결제를 받을 수 있으며, 비수탁형 지갑을 통해 즉시 자금에 접근할 수 있도록 합니다. 주요 제품으로는 AllScale Invoice (2025년 9월부터 서비스 중), AllScale Pay (텔레그램, 왓츠앱, 라인을 통한 소셜 커머스), AllScale Payroll (해외 계약자 결제)이 있습니다. 이 회사는 "보이지 않는 암호화폐"를 강조합니다. 즉, 고객은 블록체인 레일을 사용하고 있다는 것을 모를 수 있지만, 판매자는 스테이블코인을 받습니다.

현재 개발 단계: 이 플랫폼은 BNB 체인 메인넷에서 작동하는 제품과 함께 공개 베타 상태입니다. 사용자는 dashboard.allscale.io에서 대시보드에 접근할 수 있지만, 대기 목록이 적용될 수 있습니다.

BNB 체인과 계정 추상화에 의존하는 기술 아키텍처​

AllScale은 자체 체인을 운영하는 대신 기존 블록체인 인프라를 기반으로 구축됩니다. 주요 기술 스택은 다음과 같습니다.

패스키 기반 접근 방식은 악명 높은 시드 문구 관리의 UX 마찰을 제거하여 주류 채택의 장벽을 낮춥니다. 멀티체인 페이마스터 스폰서십 아키텍처는 백그라운드에서 거래 비용을 처리합니다.

누락된 부분: AllScale은 공개 GitHub 저장소를 보유하고 있지 않습니다. 인프라는 독점적이고 비공개 소스입니다. 스마트 계약 주소는 게시되지 않았으며, 공개 API나 SDK도 제공되지 않으며, docs.allscale.io의 기술 문서는 아키텍처 사양보다는 사용자 가이드에 중점을 둡니다. 이러한 불투명성은 그들의 주장에 대한 독립적인 기술 검증을 방해합니다.

자체 토큰 없음—플랫폼은 USDT와 USDC를 사용합니다​

AllScale은 자체 암호화폐 토큰을 가지고 있지 않습니다. 이는 많은 웹3 프로젝트와 중요한 차이점입니다. ICO, IDO, 토큰 판매 또는 투기 자산이 관련되어 있지 않습니다. 이 회사는 지분 투자를 유치하는 전통적인 델라웨어 C-법인으로 운영됩니다.

이 플랫폼은 주로 USDT와 USDC와 같은 제3자 스테이블코인을 결제 수단으로 사용합니다. 사용자는 스테이블코인으로 결제를 받으며, 법정화폐 또는 카드 결제로부터 자동 변환됩니다. BNB 체인과의 통합은 USD1 (바이낸스 계열 스테이블코인)에 대한 접근도 제공합니다.

수익 모델 (추정치, 공개되지 않음):

• 인보이스/결제 처리 수수료
• 법정화폐-스테이블코인 환전 스프레드
• B2B 급여 관리 서비스
• 온/오프 램프 통합 수수료

토큰의 부재는 특정 위험(투기적 변동성, 토크노믹스 조작, 규제 증권 문제)을 제거하지만, 지분 참여 외에는 투자자를 위한 토큰 기반 노출이 없다는 것을 의미하기도 합니다.

검증 가능한 배경을 가진 4명의 신원 공개된 창립자​

AllScale 팀은 강력한 투명성을 보여줍니다. 모든 창립자는 검증 가능한 전문 경력을 가진 공개적으로 신원이 확인된 인물입니다.

Shawn Pang (CEO & 공동 창립자): 웨스턴 대학교 컴퓨터 과학 및 비즈니스 전공. Capital One의 결제 사기 제품 관리자 역임; 틱톡 캐나다 최초 PM; AI 제품을 위한 성장 마케팅 에이전시인 HashMatrix 공동 창립.

Ruoyang "Leo" Wang (COO & 공동 창립자): 토론토 대학교 컴퓨터 공학 전공. PingCAP (분산 데이터베이스), IBM, AMD, Scotiabank 경력. CP Clickme에서 이전 스타트업 경험.

Jun Li & Khalil Lin (공동 창립자): OKX 배경을 포함한 법률/규정 준수 전문성을 갖춘 추가 공동 창립자. LinkedIn 프로필 확인 가능.

Avrilyn Li (창립 제품 관리자): Ivey Business School 출신의 AI-웹3 기업가로, 급여 제품을 이끌고 있습니다.

이 팀은 바이낸스, OKX, Kraken, Block (Square), 아마존, 델, HP에서 집단적인 경험을 가지고 있다고 주장합니다. 총 팀 규모는 약 7~11명입니다.

자금 조달 및 투자자​

주목할 만한 참여 투자자로는 KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures, V3V Ventures가 있습니다. 엔젤 투자자로는 Gracy Chen과 Jedi Lu가 있습니다. 이 회사는 정부 지원 기술 액셀러레이터인 홍콩 사이버포트 인큐베이션 프로그램의 회원입니다.

주요 보안 문제: 공개 감사 또는 버그 바운티 프로그램 없음​

이는 연구에서 가장 중요한 위험 신호입니다. 스마트 계약 지갑을 통해 사용자 자금을 처리함에도 불구하고:

• 공인된 회사(CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)의 공개 스마트 계약 감사 없음
• CertiK Skynet 또는 유사한 보안 데이터베이스에 목록에 없음
• Immunefi, HackerOne 또는 Bugcrowd에 버그 바운티 프로그램 없음
• 보험 또는 보장 메커니즘 미공개
• 보안 공개 정책이 공개적으로 보이지 않음

AllScale은 자체 수탁 아키텍처, 자동화된 KYC/KYB/KYT 규정 준수, 패스키를 위한 하드웨어 보안 모듈(HSM) 통합, 2단계 인증 지원을 포함한 보안 기능을 주장합니다. 자체 수탁 모델은 플랫폼 거래 상대방 위험을 줄여줍니다. AllScale이 침해되더라도 사용자 자신의 지갑에 있는 자금은 이론적으로 수탁 서비스보다 안전할 것입니다.

긍정적인 측면: AllScale에 대한 보안 사고, 해킹 또는 익스플로잇은 보고된 바 없습니다. 그러나 플랫폼의 짧은 역사를 고려할 때, 이러한 사고의 부재는 강력한 보안보다는 제한된 노출을 반영할 수 있습니다.

경쟁 환경 및 시장 포지셔닝​

AllScale은 빠르게 진화하는 스테이블코인 결제 시장에서 경쟁합니다.

AllScale의 차별화 요소:

• 자체 수탁 모델 (사용자가 자금 통제)
• 시드 문구 UX를 제거하는 패스키 인증
• 계정 추상화를 통한 제로 가스 수수료
• 신흥 시장 집중 (아프리카, 라틴 아메리카, 동남아시아)
• 기업 집중 대비 "라스트 마일" SMB 타겟팅

단점: 극도로 짧은 역사, 소규모 팀, 제한된 실적, 확립된 유통 채널을 가진 자금력이 풍부한 기존 기업과의 경쟁.

커뮤니티 존재는 초기 단계이며 B2B에 집중되어 있습니다​

AllScale은 표준 웹3 소셜 채널을 유지합니다.

• X (트위터): @allscaleio (2025년 4월부터 활동)
• 텔레그램: AllScaleHQ 커뮤니티 그룹
• 디스코드: 커뮤니티 ID가 보이는 활성 서버
• 링크드인: AllScale Inc 회사 페이지
• 뉴스레터: Substack의 "The Stablecoin Scoop"

커뮤니티는 초기 단계이며, 주로 AMA 세션, X 스페이스, 파트너십 발표를 통해 참여가 이루어집니다. AllScale은 HashKey Group 및 Amber Group과 함께 홍콩에서 스케일 스테이블코인 서밋 (2025년 6월)을 개최했습니다.

전통적인 DeFi 지표는 적용되지 않습니다: AllScale은 결제 플랫폼이지 DeFi 프로토콜이 아니므로 TVL (총 예치 자산) 지표는 적용되지 않습니다. 이 플랫폼은 DeFiLlama 또는 Dune Analytics에 등재되어 있지 않습니다. 사용자 수 및 유지율 지표는 투자자들에 의해 언급되지만 공개적으로 공개되지는 않습니다.

주목할 만한 파트너십으로는 BNB 체인 (공식 생태계 파트너), Skill Afrika (아프리카 프리랜서 커뮤니티), Ethscriptions (L1 영속성), Asseto (수익 상품을 위한 RWA 토큰화)가 있습니다.

위험 평가 결과: 중간 위험 초기 단계 벤처​

긍정적인 합법성 신호​

• 검증 가능한 전문 경력을 가진 신원 공개된 팀
• 평판 좋은 암호화폐 벤처 캐피탈 (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• 홍콩 사이버포트 기관 지원
• 델라웨어 C-법인 법적 구조
• BNB 체인 메인넷에서 작동하는 제품 라이브
• 사기 의혹, BBB 불만 또는 커뮤니티 경고 없음
• 익명 팀 우려 없음
• 비현실적인 수익 약속 또는 토큰 투기 없음
• 규정 준수 지향적 포지셔닝 (GENIUS 법, 홍콩 스테이블코인 조례)

주의가 필요한 영역​

• 극도로 짧은 역사: 2025년 2월 설립, 1년 미만
• 자금 처리에도 불구하고 공개 보안 감사 없음
• 버그 바운티 프로그램 없음
• 독립적인 사용자 리뷰 또는 커뮤니티 피드백 없음
• 비공개 소스 인프라—주장 독립적으로 검증 불가
• 언론 보도는 주로 보도 자료 배포, 독립 저널리즘 아님
• 중앙화 위험: 회사 운영 플랫폼, BNB 체인 의존성
• 소규모 팀 (약 7~11명)이 야심찬 글로벌 범위 실행

발견되지 않음 (부재로 인한 잠재적 위험 신호)​

• 공개적으로 공개된 사용자 지표 없음
• 수익 수치 없음
• 공식 자문 위원회 없음
• 특정 규제 라이선스 없음 (홍콩 프레임워크 아직 미발효)

최근 개발 및 로드맵​

최근 주요 성과 (2025년):

• 12월 8일: 500만 달러 시드 라운드 발표 (YZi Labs 주도)
• 11월: BNB 체인에서 AllScale Pay 라이브; Skill Afrika 파트너십
• 10월: L1 영속성을 위한 Ethscriptions 파트너십
• 9월: AllScale Invoice 제품 출시
• 8월: USD1 지원을 통한 BNB 체인 통합
• 6월: 홍콩 스케일 스테이블코인 서밋; 150만 달러 프리 시드 펀딩

향후 계획:

• 2026년 1분기: 라틴 아메리카 시장 확장
• 향후: DeFi 수익 옵션, 크로스체인 기능 확장, B2B 기업 솔루션

결론​

AllScale.io는 사기 우려보다는 합법적인 초기 단계 스타트업으로 부상하고 있으며, 신뢰할 수 있는 투자자와 투명하고 검증 가능한 팀의 지원을 받습니다. 이 프로젝트는 계정 추상화와 스테이블코인을 활용한 사려 깊은 기술적 접근 방식을 통해 신흥 시장 프리랜서의 해외 결제 마찰이라는 실제 시장 문제를 해결합니다.

그러나 의미 있는 참여 전에 두 가지 중요한 격차에 주의를 기울여야 합니다. 공개 보안 감사의 완전한 부재와 독립적인 검증을 방해하는 비공개 소스 인프라입니다. 사용자 자금을 처리하는 플랫폼의 경우, 팀의 자격에 관계없이 이러한 누락은 중대한 우려 사항입니다.

전반적인 위험 등급: 중간. 이 벤처는 강력한 합법성 신호를 보여주지만, 내재된 초기 단계 위험을 수반합니다. 잠재적 사용자는 보안 감사가 게시될 때까지 소액으로 시작해야 합니다. 잠재적 파트너는 기술 사양 및 감사 보고서에 대한 직접적인 접근을 요청해야 합니다. 이 프로젝트는 특히 2026년 1분기 보안 감사 발표에 대해 성숙해짐에 따라 주시할 가치가 있습니다.

사용자가 네이티브 토큰(SUI)을 전혀 보유하지 않아도 dApp과 원활하게 상호작용할 수 있는 세상을 상상해 보세요. 이제 이는 먼 꿈이 아닙니다. Sui의 Gas Station(또는 Paymaster) 덕분에 개발자는 사용자를 대신해 가스 비용을 부담할 수 있어, Web3에 처음 진입하는 사용자들의 가장 큰 장벽을 완전히 제거하고 진정한 무마찰 온체인 경험을 제공할 수 있습니다.

이 글에서는 dApp을 가스 없는 형태로 업그레이드하는 전체 가이드를 제공합니다. Sui Paymaster의 핵심 개념, 아키텍처, 구현 패턴 및 모범 사례를 깊이 있게 살펴보겠습니다.

1. 배경 및 핵심 개념: 스폰서드 트랜잭션이란?​

블록체인에서는 모든 트랜잭션에 네트워크 수수료, 즉 “가스”가 필요합니다. Web2의 매끄러운 경험에 익숙한 사용자에게 이는 큰 인지적·운영상의 장벽이 됩니다. Sui는 프로토콜 수준에서 스폰서드 트랜잭션이라는 개념으로 이 문제를 해결합니다.

핵심 아이디어는 간단합니다: 한 당사자(스폰서)가 다른 당사자(사용자)의 트랜잭션에 대한 SUI 가스 비용을 대신 지불하도록 허용합니다. 이렇게 하면 사용자가 지갑에 SUI가 전혀 없어도 온체인 행동을 성공적으로 시작할 수 있습니다.

Paymaster ≈ Gas Station​

Sui 생태계에서 트랜잭션을 스폰서하는 로직은 일반적으로 Gas Station 또는 Paymaster라 불리는 오프체인·온체인 서비스가 담당합니다. 주요 역할은 다음과 같습니다.

1. 트랜잭션 평가: 사용자의 가스 없는 트랜잭션 데이터(GasLessTransactionData)를 받습니다.
2. 가스 제공: 트랜잭션에 필요한 가스 비용을 잠그고 할당합니다. 이는 보통 다수의 SUI Coin 객체로 구성된 가스 풀을 통해 관리됩니다.
3. 스폰서 서명 생성: 스폰서를 승인한 뒤, Gas Station은 자신의 개인키(SponsorSig)로 트랜잭션에 서명하여 비용을 지불하겠다는 의사를 인증합니다.
4. 서명된 트랜잭션 반환: 이제 가스 데이터와 스폰서 서명이 포함된 TransactionData를 반환해 사용자의 최종 서명을 기다립니다.

요컨대, Gas Station은 dApp 사용자의 “차량”(트랜잭션)이 Sui 네트워크 위를 부드럽게 달릴 수 있도록 연료를 공급하는 역할을 합니다.

2. 고수준 아키텍처 및 상호작용 흐름​

가스 없는 트랜잭션은 사용자, dApp 프론트엔드, Gas Station, Sui Full Node 간의 협업으로 이루어집니다. 흐름은 다음과 같습니다:

흐름 세부 설명

1. 사용자가 dApp UI에서 행동을 수행하면 가스 정보가 없는 트랜잭션 데이터 패키지가 생성됩니다.
2. dApp은 이 데이터를 지정된 Gas Station에 보내 스폰서십을 요청합니다.
3. Gas Station은 요청의 유효성을 검증(예: 사용자가 스폰서 대상인지 확인)하고, 가스 코인을 채워 서명한 뒤 반쯤 완성된 트랜잭션을 dApp에 반환합니다.
4. 사용자는 지갑에서 전체 트랜잭션 상세(예: “NFT 하나 구매”)를 확인하고 최종 서명을 제공합니다. 이는 사용자가 자신의 행동에 대한 동의를 유지하도록 하는 중요한 단계입니다.
5. dApp은 사용자와 스폰서의 서명이 모두 포함된 완전한 트랜잭션을 Sui Full Node에 전송합니다.
6. 트랜잭션이 체인에 최종 확정되면 Gas Station은 온체인 이벤트나 영수증을 청취해 이를 확인하고, 필요 시 웹훅을 통해 dApp 백엔드에 성공을 알릴 수 있습니다.

3. 세 가지 핵심 상호작용 모델​

비즈니스 요구에 맞게 아래 세 모델을 개별적으로 혹은 조합하여 사용할 수 있습니다.

모델 1: 사용자‑주도 → 스폰서‑승인 (가장 일반적)​

대부분의 dApp 상호작용에 적합한 표준 모델입니다.

1. 사용자가 GasLessTransactionData를 생성: dApp 내에서 행동을 수행합니다.
2. 스폰서가 GasData를 추가하고 서명: dApp 백엔드가 트랜잭션을 Gas Station에 보내면, 스폰서는 가스 코인을 첨부하고 서명합니다.
3. 사용자가 최종 서명: 사용자는 지갑에서 전체 트랜잭션을 확인하고 서명합니다. 이후 dApp이 네트워크에 전송합니다.

보안과 사용자 경험 사이의 균형이 뛰어납니다.

모델 2: 스폰서‑주도 에어드롭/인센티브​

에어드롭, 사용자 인센티브, 배치 자산 배포에 최적화된 모델입니다.

1. 스폰서가 TransactionData를 미리 채우고 서명: 프로젝트 팀이 대부분의 트랜잭션을 사전에 구성(예: 특정 주소에 NFT 에어드롭)하고 스폰서 서명을 붙입니다.
2. 사용자의 두 번째 서명만으로 실행: 사용자는 “미리 승인된” 트랜잭션에 한 번만 서명하면 됩니다.

클릭 한 번으로 보상을 청구하거나 작업을 완료할 수 있어 전환율이 크게 상승합니다.

모델 3: 와일드카드 GasData (신용 한도 모델)​

보다 유연하고 권한 기반의 모델입니다.

1. 스폰서가 GasData 객체를 전송: 스폰서는 예산이 정해진 가스 코인 객체를 생성해 직접 사용자에게 소유권을 이전합니다.
2. 사용자는 예산 한도 내에서 자유롭게 사용: 사용자는 해당 가스 코인을 이용해 예산과 유효 기간 내에서 원하는 트랜잭션을 자유롭게 실행할 수 있습니다.
3. 가스 코인 반환: 소진되거나 만료되면 가스 코인 객체는 자동 파괴되거나 스폰서에게 반환되도록 설계할 수 있습니다.

한정된 시간·예산의 “가스 신용카드”를 제공하는 형태로, 게임 시즌 동안 무료 플레이 경험을 제공하는 등 높은 자율성이 요구되는 시나리오에 적합합니다.

4. 전형적인 적용 시나리오​

Sui Paymaster는 가스 비용 문제를 해결할 뿐 아니라 비즈니스 로직과 깊게 결합해 새로운 가능성을 열어줍니다.

시나리오 1: 페이월​

콘텐츠 플랫폼이나 dApp 서비스가 특정 조건(예: VIP NFT 보유, 멤버십 레벨) 충족 시에만 기능을 제공하도록 할 때 활용합니다.

• 흐름: 사용자가 행동을 요청 → dApp 백엔드가 사용자의 자격(NFT 보유 등) 검증 → 자격이 있으면 Paymaster에 가스 스폰서를 요청, 없으면 서명 요청을 거부.
• 장점: 봇 및 남용에 강합니다. 스폰서십 결정이 백엔드에서 이루어지므로 악의적인 사용자가 가스 풀을 고갈시키기 어렵습니다.

시나리오 2: 원클릭 체크아웃​

이커머스나 인게임 구매 시 결제 과정을 최소화하고 싶을 때 유용합니다.

• 흐름: 사용자가 “지금 구매” 버튼을 클릭 → dApp이 비즈니스 로직(transfer_nft_to_user)을 포함한 트랜잭션을 구성 → 사용자는 비즈니스 트랜잭션만 서명하고, 가스는 스폰서가 부담합니다.
• 장점: order_id와 같은 비즈니스 파라미터를 ProgrammableTransactionBlock에 직접 인코딩해 온체인에서 정확히 주문을 추적할 수 있습니다.

시나리오 3: 데이터 어트리뷰션​

정확한 데이터 추적은 비즈니스 최적화에 필수적입니다.

• 흐름: 트랜잭션을 구성할 때 고유 식별자(order_hash)를 파라미터나 실행 시 발생하는 이벤트에 기록합니다.
• 장점: Gas Station이 성공 영수증을 받으면 이벤트 또는 트랜잭션 데이터를 파싱해 order_hash를 추출할 수 있어 온체인 상태 변화와 백엔드 주문·사용자 행동을 정확히 매핑할 수 있습니다.

5. 코드 스켈레톤 (Rust SDK 기반)​

아래는 핵심 상호작용 흐름을 보여주는 간단한 Rust 코드 예시입니다.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

전체 구현은 공식 Sui 문서의 **Gas Station 튜토리얼**을 참고하세요. 여기에는 바로 사용할 수 있는 코드 예제가 포함되어 있습니다.

6. 위험 요소 및 보호 방안​

강력하지만 프로덕션 환경에 Gas Station을 배포할 때는 다음 위험 요소를 신중히 고려해야 합니다.

• 이중 서명(Equivocation) 위험: 악의적인 사용자가 동일한 가스 코인을 병렬로 여러 트랜잭션에 사용하려 할 수 있습니다. 이를 방지하려면 사용자·트랜잭션당 고유 가스 코인을 할당하고, 블랙리스트와 요청 속도 제한(rate‑limiting)을 적용합니다.
• 가스 풀 관리: 동시성이 높은 상황에서 하나의 대형 가스 코인은 성능 병목이 될 수 있습니다. 서비스는 대형 SUI 코인을 자동으로 다수의 소액 가스 코인으로 분할하고, 사용 후 효율적으로 회수할 수 있어야 합니다. Shinami와 같은 전문 Gas Station 제공업체는 이러한 기능을 관리형으로 제공합니다.
• 인증 및 속도 제한: 엄격한 인증·속도 제한 정책을 수립해야 합니다. 예를 들어, 사용자 IP, 지갑 주소, API 토큰 기반으로 스폰서십 한도·빈도를 관리해 악의적인 대량 소모를 방지합니다.

7. 생태계 도구​

Sui 생태계에는 Paymaster 개발·배포를 간소화하는 다양한 도구가 이미 준비되어 있습니다.

• 공식 SDK (Rust / TypeScript): sponsor_transaction_block() 같은 고수준 API를 제공해 통합 복잡도를 크게 낮춥니다.
• Shinami Gas Station: 가스 코인 자동 분할·회수, 상세 메트릭 모니터링, 웹훅 알림 등을 포함한 올인원 관리형 서비스를 제공해 개발자는 비즈니스 로직에 집중할 수 있습니다.
• Enoki / Mysten Demo: 커뮤니티와 Mysten Labs가 제공하는 오픈소스 Paymaster 구현체는 자체 서비스를 구축할 때 좋은 참고 자료가 됩니다.

8. 구현 체크리스트​

dApp을 가스 없는 시대에 맞게 업그레이드할 준비가 되셨나요? 시작하기 전에 아래 체크리스트를 확인하세요.

• 펀딩 흐름 설계: 스폰서의 자금 출처, 예산, 보충 전략을 정의하고 가스 풀 잔액·소모율 등 핵심 지표에 대한 모니터링 및 알림을 설정합니다.
• 어트리뷰션 필드 예약: 트랜잭션 파라미터 설계 시 order_id, user_id 등 비즈니스 식별자를 위한 필드를 미리 확보합니다.
• 남용 방지 정책 적용: 실서비스 이전에 반드시 인증, 속도 제한, 로깅 메커니즘을 구현합니다.
• 테스트넷에서 리허설: 자체 서비스를 구축하든 서드파티 Gas Station을 연동하든, 반드시 테스트넷·데브넷에서 동시성·스트레스 테스트를 충분히 수행합니다.
• 지속적인 최적화: 출시 후에도 트랜잭션 성공률, 실패 원인, 가스 비용 등을 지속적으로 추적·분석해 예산·전략을 조정합니다.

결론​

Sui Paymaster(또는 Gas Station)는 단순히 사용자의 가스 비용을 대신 부담하는 도구를 넘어, “SUI 없이 온체인” 사용자 경험과 “주문 수준 온체인 어트리뷰션”을 하나의 원자적 트랜잭션 안에서 결합하는 강력한 패러다임을 제공합니다. 이는 Web2 사용자가 Web3에 진입하도록 돕고, 개발자에게는 비즈니스 맞춤형 로직을 구현할 전례 없는 유연성을 부여합니다.

Sui 네트워크의 현재 낮은 가스 비용과 점점 성숙해지는 툴 체인 덕분에, 이제 dApp의 결제·상호작용 흐름을 가스 없는 시대로 전환하기에 최적의 시점입니다.

지갑 마찰을 없애고, 사용자를 지속시키며, 성장 가능성을 예측하는 방법

Web3 앱이 최신 Web2 서비스와 같은 원활한 회원가입 흐름을 제공한다면 어떨까요? 이것이 바로 zkLogin이 Sui 블록체인에서 제공하는 핵심 약속입니다. zkLogin은 Sui용 OAuth와 같은 역할을 하며, 사용자가 Google, Apple, X 등 익숙한 계정으로 로그인할 수 있게 해줍니다. 이후 영지식 증명이 해당 Web2 신원을 온체인 Sui 주소와 안전하게 연결합니다 — 지갑 팝업도, 시드 구문도, 사용자 이탈도 없습니다.

그 효과는 실질적이고 즉각적입니다. 이미 수십만 개의 zkLogin 계정이 활성화된 상황에서, 사례 연구에 따르면 전통적인 지갑 장벽을 제거한 후 사용자 전환율이 **17%에서 42%**로 크게 상승했습니다. 이제 작동 원리와 프로젝트에 가져다줄 수 있는 혜택을 살펴보겠습니다.

왜 지갑이 첫 번째 전환을 방해하는가​

혁신적인 dApp을 만들었지만 사용자 확보 퍼널이 새는 경우가 많습니다. 그 원인은 거의 항상 “Connect Wallet” 버튼입니다. 표준 Web3 온보딩은 확장 프로그램 설치, 시드 구문 경고, 암호화 용어 퀴즈 등 복잡한 미로와 같습니다.

신규 사용자는 큰 장벽에 직면합니다. UX 연구자들은 지갑 프롬프트가 나타나는 순간 **87%**가 이탈한다는 충격적인 수치를 발견했습니다. 한 실험에서는 해당 프롬프트를 결제 과정의 후반부로 옮기기만 해도 완료율이 **94%**로 급상승했습니다. 암호화에 호기심이 있는 사용자조차도 “잘못된 버튼을 누르면 자금이 사라질까 봐”라는 두려움을 가지고 있습니다. 이 단일하고 위협적인 단계를 제거하는 것이 기하급수적 성장을 여는 열쇠입니다.

zkLogin 작동 방식 (쉽게 설명)​

zkLogin은 모든 인터넷 사용자가 이미 신뢰하는 기술을 활용해 지갑 문제를 우아하게 회피합니다. 몇 가지 간단한 단계로 마법이 이루어집니다:

1. 임시 키 페어: 사용자가 로그인하려면 브라우저에서 일시적인 단일 세션 키 페어가 로컬에서 생성됩니다. 이는 이번 세션에만 유효한 임시 패스키와 같습니다.
2. OAuth 흐름: 사용자는 Google, Apple 등 소셜 계정으로 로그인합니다. 앱은 이 로그인 요청에 고유값(nonce)을 삽입합니다.
3. ZKP 서비스: 로그인 성공 후, ZKP(Zero‑Knowledge Proof) 서비스가 암호학적 증명을 생성합니다. 이 증명은 “이 OAuth 토큰이 임시 패스키 소유자를 인증한다”는 것을 온체인에 공개하지 않고 확인합니다.
4. 주소 파생: OAuth 제공자의 JWT(JSON Web Token)와 고유 salt를 결합해 영구적인 Sui 주소를 결정적으로 생성합니다. salt는 클라이언트 측이나 안전한 백엔드에 비공개로 보관됩니다.
5. 트랜잭션 제출: 앱은 임시 키로 트랜잭션에 서명하고 ZK 증명을 첨부합니다. Sui 검증자는 온체인에서 증명을 검증해 전통적인 지갑 없이도 트랜잭션의 정당성을 확인합니다.

단계별 통합 가이드​

구현 준비가 되셨나요? TypeScript SDK를 활용한 빠른 가이드를 소개합니다. Rust나 Python에서도 원리는 동일합니다.

1. SDK 설치​

@mysten/sui 패키지에 필요한 모든 zklogin 헬퍼가 포함되어 있습니다.

pnpm add @mysten/sui

2. 키와 Nonce 생성​

먼저 임시 키페어와 현재 Sui 네트워크 epoch에 연결된 nonce를 생성합니다.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. OAuth 리다이렉트​

사용 중인 제공자(예: Google, Facebook, Apple)에 맞는 OAuth 로그인 URL을 구성하고 사용자를 리다이렉트합니다.

4. JWT 디코드 및 사용자 Salt 조회​

사용자가 로그인하고 돌아오면 URL에서 id_token을 가져옵니다. 이를 이용해 백엔드에서 사용자 전용 salt를 조회한 뒤 Sui 주소를 파생합니다.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. ZK 증명 요청​

JWT를 증명 서비스에 보내 ZK 증명을 받습니다. 개발 단계에서는 Mysten의 퍼블릭 prover를 사용할 수 있습니다. 프로덕션에서는 자체 호스팅하거나 Enoki와 같은 서비스를 이용하세요.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. 서명 및 전송​

이제 트랜잭션을 구성하고, 발신자를 사용자의 zkLogin 주소로 설정한 뒤 실행합니다. SDK가 zkLoginInputs(증명)를 자동으로 첨부합니다. ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // 任意的 Move 调用
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // 여기서 마법이 일어납니다
});

7. 세션 유지​

보다 부드러운 사용자 경험을 위해 키페어와 salt를 IndexedDB 또는 로컬 스토리지에 암호화하여 저장합니다. 보안을 강화하려면 몇 epoch마다 회전시키는 것을 잊지 마세요.

KPI 예측 템플릿​

zkLogin이 가져오는 차이는 정성적인 것이 아니라 정량적인 것입니다. 일반 온보딩 퍼널과 zkLogin 적용 퍼널을 비교해 보세요:

👉 의미: 10,000명의 고유 방문자를 유도하는 캠페인이라면, 첫날 온체인 행동이 300건에서 2,500건 이상으로 증가합니다.

모범 사례 & 주의점​

보다 매끄러운 경험을 위해 다음 팁을 기억하세요:

• 스폰서드 트랜잭션 사용: 사용자의 첫 몇 번 트랜잭션 수수료를 여러분이 부담하세요. 모든 마찰이 사라지고 강력한 “아하” 순간을 제공할 수 있습니다.
• Salt 관리에 신중: 사용자의 salt를 변경하면 새로운 주소가 생성됩니다. 복구 경로를 확실히 제어할 수 있을 때만 수행하세요.
• Sui 주소 노출: 가입 후 사용자의 온체인 주소를 보여 주세요. 이는 고급 사용자가 원한다면 전통적인 지갑으로 가져갈 수 있게 합니다.
• 리프레시 루프 방지: JWT와 임시 키페어를 만료될 때까지 캐시해 두어 반복 로그인 요청을 피하세요.
• Prover 지연 모니터링: 증명 생성 라운드 트립 시간이 2초를 초과하면 지역 프로버를 호스팅해 응답성을 유지하세요.

BlockEden.xyz가 제공하는 가치​

zkLogin이 사용자 경험을 완성한다면, 이를 확장하는 과정에서 새로운 백엔드 과제가 등장합니다. 여기서 BlockEden.xyz가 역할을 합니다.

• API 레이어: 고처리량, 지리적 라우팅이 적용된 RPC 노드가 사용자 위치와 무관하게 zkLogin 트랜잭션을 최소 지연으로 처리합니다.
• 관찰 가능성: 증명 지연, 성공/실패 비율, 전환 퍼널 건강 지표 등을 한눈에 볼 수 있는 대시보드를 제공합니다.
• 컴플라이언스: fiat 연동 앱을 위해 선택 가능한 KYC 모듈이 있어, 검증된 사용자 신원에서 직접 온‑램프를 구현할 수 있습니다.

바로 배포할 준비가 되셨나요?​

거추장스럽고 위협적인 지갑 흐름은 이제 끝났습니다. zkLogin 샌드박스를 띄우고 BlockEden의 풀노드 엔드포인트를 연결하면, 사용자는 “지갑”이라는 단어조차 듣지 못한 채 가입 그래프가 상승하는 모습을 확인할 수 있습니다. 😉

수년간 암호화폐 세계는 지갑이라는 중대한 사용성 문제에 갇혀 있었습니다. 기존 지갑, 즉 외부 소유 계정(EOA)은 관대하지 않습니다. 하나의 시드 구문을 잃어버리면 자금은 영원히 사라집니다. 모든 행동은 서명이 필요하고, 가스 비용은 체인의 네이티브 토큰으로 지불해야 합니다. 이처럼 투박하고 위험 부담이 큰 경험은 대중 채택의 큰 장벽이었습니다.

여기에 계정 추상화 (AA) 가 등장합니다. AA는 사용자의 계정을 프로그래머블 스마트 계약으로 변환하여, 소셜 복구, 원클릭 거래, 유연한 가스 결제와 같은 기능을 열어줍니다.

이 더 똑똑한 미래로 가는 여정은 세 가지 뚜렷한 경로로 전개됩니다: 검증된 ERC‑4337, 효율적인 네이티브 AA, 그리고 기대를 모으는 EIP‑7702. 각각이 개발자와 사용자에게 의미하는 바를 살펴보겠습니다.

💡 경로 1: 선구자 — ERC‑4337​

ERC‑4337 은 프로토콜 자체를 변경하지 않고도 이더리움 및 EVM 체인에 계정 추상화를 도입한 돌파구였습니다. 기존 시스템 위에 스마트 레이어를 추가한 셈이죠.

새로운 트랜잭션 흐름을 도입합니다:

• UserOperations: 사용자의 의도를 나타내는 객체 (예: “100 USDC를 ETH로 교환”)
• Bundlers: 오프체인 행위자로 UserOperations 를 모아 네트워크에 제출
• EntryPoint: 번들된 작업을 검증·실행하는 전역 스마트 계약

장점

• 범용 호환성: 모든 EVM 체인에 배포 가능
• 유연성: 게임용 세션 키, 다중 서명 보안, Paymaster 를 통한 가스 스폰서십 등 풍부한 기능 지원

트레이드오프

• 복잡성·비용: Bundler 운영 등 인프라 부담이 크고, EntryPoint 로 인한 가스 비용이 가장 높음. 따라서 가스 비용이 저렴한 L2(예: Base, Polygon)에서 주로 채택됨.

ERC‑4337 은 다른 AA 솔루션이 달릴 수 있는 토대를 마련했습니다. 수요를 입증하고 보다 직관적인 Web3 경험을 위한 기반을 닦았습니다.

🚀 경로 2: 이상적인 통합 — 네이티브 계정 추상화​

ERC‑4337 이 부가 기능이라면, 네이티브 AA 는 스마트 기능을 블록체인 자체에 내장합니다. zkSync Era, Starknet 와 같은 체인은 설계 단계부터 AA 를 핵심 원칙으로 삼았습니다. 이 네트워크에서는 모든 계정이 스마트 계약입니다.

장점

• 효율성: 프로토콜에 AA 로직이 통합돼 불필요한 레이어가 사라져 ERC‑4337 대비 가스 비용이 크게 낮음
• 개발자 친화성: Bundler 나 별도 메모풀을 관리할 필요 없이 표준 트랜잭션 흐름과 유사하게 동작

트레이드오프

• 생태계 단편화: 네이티브 AA 는 체인마다 다릅니다. zkSync 의 계정은 Starknet 의 계정과 다르고, 이 둘 모두 이더리움 메인넷에 네이티브하지 않음. 여러 체인을 오가는 사용자·개발자에게 경험이 파편화됩니다.

네이티브 AA 는 효율성의 “엔드게임”을 보여주지만, 채택은 해당 체인의 성장에 좌우됩니다.

🌉 경로 3: 실용적인 다리 — EIP‑7702​

이더리움 2025년 “Pectra” 업그레이드에 포함될 예정인 EIP‑7702 는 기존 EOA 사용자에게 AA 기능을 대규모로 제공하도록 설계된 게임 체인저입니다. 하이브리드 접근 방식으로, EOA 가 단일 트랜잭션 동안 스마트 계약에 권한을 일시 위임하도록 합니다.

EOA 에 일시적인 슈퍼파워를 부여하는 셈이죠. 자금을 옮기거나 주소를 바꿀 필요 없이, 트랜잭션에 권한 부여를 추가해 한 번의 클릭으로 배치 작업(예: 승인 + 스와프)이나 가스 스폰서십을 수행할 수 있습니다.

장점

• 역호환성: 기존 EOA 로 보호된 수십억 달러와 호환. 마이그레이션 불필요
• 낮은 복잡성: 기존 트랜잭션 풀 사용으로 Bundler 필요 없으며 인프라가 크게 단순화
• 대규모 채택 촉진제: 모든 이더리움 사용자가 즉시 스마트 기능을 활용하게 되면 UX 개선이 급속히 확산될 가능성

트레이드오프

• 완전한 AA 가 아님: EIP‑7702 는 EOA 자체의 키 관리 문제를 해결하지 않음. 키를 잃어버리면 여전히 자금 손실. 트랜잭션 기능 강화에 초점

정면 비교: 명확한 차이점​

미래는 수렴하고 사용자 중심이다​

세 경로는 서로 배타적이지 않으며, 지갑이 더 이상 마찰점이 되지 않는 미래를 향해 수렴하고 있습니다.

1. 소셜 복구가 표준이 된다 🛡️: “키를 잃어버리면 자금도 사라진다”는 시대는 끝납니다. AA 는 가디언 기반 복구를 가능하게 하여, 자체 보관이 전통 은행 계좌만큼 안전하고 관대해집니다.
2. 게임 UX 재구상 🎮: 세션 키 덕분에 “거래 승인” 팝업이 사라지고, Web3 게임이 Web2 게임처럼 매끄럽게 진행됩니다.
3. 지갑이 프로그래머블 플랫폼이 된다: 지갑에 “DeFi 모듈”, “보안 모듈(2FA)” 등을 추가해 사용자가 필요에 따라 기능을 조합할 수 있습니다.

BlockEden.xyz 와 같은 인프라 제공자에게 이 진화는 엄청난 기회입니다. Bundler, Paymaster, 다양한 AA 표준을 지원하는 복잡한 인프라를 추상화함으로써, 개발자는 손쉽게 AA 기능을 통합하고, 지갑은 체인별 지원 상황에 따라 ERC‑4337, 네이티브 AA, 혹은 EIP‑7702 를 자동으로 활용할 수 있게 됩니다.

지갑은 마침내 업그레이드를 맞이했습니다. 정적 EOAs 에서 동적이고 프로그래머블한 스마트 계정으로의 전환은 단순한 개선이 아니라, 다음 억 명 사용자를 위한 Web3 접근성과 안전성을 보장하는 혁명입니다.

안녕하세요, 블록체인 블로그에 다시 오신 것을 환영합니다! 오늘은 ERC-4337이라는 흥미로운 새로운 제안에 대해 살펴보겠습니다. 이 제안은 합의 계층 프로토콜 변경 없이 이더리움에 계정 추상화를 도입합니다. 대신, 상위 레이어 인프라를 활용해 목표를 달성합니다. ERC-4337이 제공하는 내용과 현재 이더리움 생태계의 한계를 어떻게 해결하는지 알아보겠습니다.

ERC-4337이란?​

ERC-4337은 별도의 mempool과 UserOperation이라는 새로운 유형의 의사‑트랜잭션 객체를 사용하여 이더리움에 계정 추상화를 도입하는 제안입니다. 사용자는 UserOperation 객체를 대체 mempool에 전송하고, 번들러(bundler)라 불리는 특수한 행위자가 이를 트랜잭션으로 패키징하여 전용 계약에 handleOps 호출을 수행합니다. 이러한 트랜잭션은 블록에 포함됩니다.

이 제안은 다음과 같은 목표를 가지고 있습니다:

1. 사용자가 임의의 검증 로직을 가진 스마트 계약 월렛을 기본 계정으로 사용할 수 있도록 합니다.
2. 외부 소유 계정(EOA)이 필요 없도록 완전히 제거합니다.
3. 어떤 번들러든 계정 추상화된 사용자 작업을 포함하는 과정에 참여할 수 있게 하여 탈중앙화를 보장합니다.
4. 모든 활동이 공개 mempool을 통해 이루어지도록 하여 사용자가 특정 행위자의 직접 통신 주소를 알 필요가 없게 합니다.
5. 번들러에 대한 신뢰 가정을 피합니다.
6. 더 빠른 채택을 위해 이더리움 합의 변경을 요구하지 않습니다.
7. 프라이버시 보호 애플리케이션, 원자성 다중 작업, ERC-20 토큰으로 거래 수수료 지불, 개발자 지원 거래 등 다양한 사용 사례를 지원합니다.

하위 호환성​

ERC-4337은 합의 계층을 변경하지 않기 때문에 이더리움에 직접적인 하위 호환성 문제가 없습니다. 그러나 ERC-4337 이전에 존재하던 계정은 필요한 validateUserOp 함수가 없기 때문에 새로운 시스템과 바로 호환되지 않습니다. 이를 해결하려면 검증 로직을 래퍼 형태로 재구현하고 원래 계정의 신뢰할 수 있는 op 제출자로 설정하는 ERC-4337 호환 계정을 생성하면 됩니다.

레퍼런스 구현​

ERC-4337의 기술적 세부 사항을 더 깊이 탐구하고 싶은 분들을 위해 레퍼런스 구현이 https://github.com/eth-infinitism/account-abstraction/tree/main/contracts 에 제공됩니다.

보안 고려 사항​

ERC-4337의 엔트리 포인트 계약은 시스템 전체의 중앙 신뢰 지점 역할을 하므로 철저한 감사와 형식 검증이 필요합니다. 이 접근 방식은 개별 계정에 대한 감사와 검증 부담을 줄여주지만, 엔트리 포인트 계약에 보안 위험이 집중되므로 강력한 검증이 필수적입니다.

검증은 두 가지 주요 주장에 초점을 맞춰야 합니다:

1. 임의의 탈취에 대한 안전성: 엔트리 포인트는 해당 계정에 대한 validateUserOp 검증이 통과된 경우에만 일반적으로 계정을 호출합니다.
2. 수수료 고갈에 대한 안전성: 엔트리 포인트가 validateUserOp를 호출하고 통과하면, op.calldata와 동일한 calldata로 일반 호출도 수행해야 합니다.

결론​

ERC-4337은 합의 계층 프로토콜 변경 없이 이더리움에 계정 추상화를 도입하려는 흥미로운 제안입니다. 상위 레이어 인프라를 활용함으로써 탈중앙화, 유연성 및 다양한 사용 사례에 대한 새로운 가능성을 열어줍니다. 보안 고려 사항을 해결해야 하지만, 이 제안은 이더리움 생태계와 사용자 경험을 크게 향상시킬 잠재력을 가지고 있습니다.