기술 해설: 오픈 웹의 엑세스 레이어를 구축하는 Particle Network
글: 안개달, 극객 Web3
서론: AA 지갑은 사용자 진입 장벽을 크게 낮추고, 가스 대납 및 Web2 계정 로그인 기능을 초보적으로 구현했지만, 여전히 프라이버시 로그인-프라이버시 거래, 전 체인 통합 AA 계정, 인텐트(의도) 전용 아키텍처 등 대중적 채택(mass adoption)과 관련된 설계는 AA 기반 위에 추가적인 구조적 보완이 필요하다.
ZenGo 같은 MPC 지갑이나 Argent 같은 스마트 계약형 월렛과 같은 다양한 UX 최적화 방안들이 존재하며, 이들은 사용자 진입 장벽을 효과적으로 낮췄다. 그러나 이러한 솔루션들은 앞서 언급한 문제들 중 일부만 해결할 뿐이며, 제품의 전반적인 사용 편의성 문제를 포괄적으로 다루지는 못한다.
분명히 현재 대부분의 AA 지갑 또는 유사 제품들은 Web3의 대규모 채택을 지원하기에는 부족하다.또한 생태계 측면에서 개발자층은 매우 중요한 요소인데, 일반 사용자에게 매력적인 제품일지라도 개발자 커뮤니티에서 영향력이 없다면 규모를 형성하기 어렵다.최근 점점 더 많은 개발자 경험 최적화 방안들이 등장하고 있는 것은, 개발자 측면에서의 영향력이 제품 생태계에 얼마나 중요한지를 보여준다.
본문에서는 Particle Network를 사례로 들어, 현재 Web3 제품들의 사용자 경험상 문제점을 분석하고, 이를 해결하기 위한 종합적인 기술 솔루션 설계 방식을 자세히 살펴볼 것이다. 이러한 종합적 솔루션이야말로 mass adoption을 실현하는 필수 조건일 수 있다.아울러 Particle의 BtoBtoC 비즈니스 전략은 많은 프로젝트들이 참고해야 할 모범 사례이기도 하다.
Particle 제품 구조 완전 해부
Particle Network는 사용 진입 장벽 해결을 핵심 과제로 삼고, B2B2C 제품 구성 및 생태계 발전 전략을 통해 Web3 대규모 채택을 위한 종합적 솔루션을 제시한다. 그 핵심 모듈은 다음과 세 가지이다:
zkWaaS(Zero-Knowledge Wallet-as-a-Service): 제로지식 증명 기반의 WaaS(지갑 서비스). 개발자는 Particle이 제공하는 SDK를 활용해 스마트 월렛 모듈을 자신의 dApp에 신속하게 통합할 수 있다. 이 지갑은 계정 추상화(Account Abstraction) 기반의 키리스(keyless) 스마트 계약형 지갑으로, 가스 대납 등의 기본 AA 기능을 구현할 뿐 아니라, Web2 방식의 OAuth 프라이버시 로그인 및 프라이버시 거래 기능도 제공한다.
Particle Chain —— Particle 전용의 전 체인 계정 추상화(Omnichain Account Abstraction) 솔루션. 스마트 계약 지갑의 크로스체인 배포, 관리 및 호출 문제를 해결하기 위해 설계되었다. 함께 제공되는 유니파이드 가스 토큰(Unified Gas Token)은 다수의 체인에서 각기 다른 가스 코인을 사용해야 하는 번거로움을 해소한다.
Intent Fusion Protocol: 간결한 DSL(Domain Specific Language), 인텐트 프레임워크, 인텐트 솔버 네트워크 등을 포함하여, 인텐트 기반의 Web3 상호작용 프레임워크를 구축한다. 사용자는 개별 작업을 일일이 수행하지 않고 자신의 거래 의도만 선언하면 되며, 이로써 복잡한 경로 선택에서 벗어나고底层 인프라에 대한 이해 부담을 줄일 수 있다.
zkWaaS —— 제로지식 증명과 결합된 스마트 지갑 서비스
지갑 측면에서 Particle은 주로 WaaS(Smart Contract Wallet as a Service) 형태로 dApp 개발자들에게 SDK를 제공함으로써, 전체 Web3 mass adoption 프레임워크를 통합하도록 유도한다. 이러한 BtoBtoC 전략은 비즈니스 및 생태계 측면에서 다음과 같은 장점이 있다:
C 단말 지갑 시장은 이미 치열한 경쟁 상태이며 기능 또한 유사해졌으므로, C 단말 지갑은 더 이상 좋은 진입점이 아니다. 반면 dApp 개발자들은 점점 더 내장형 지갑을 선호하고 있으며, 이는 사용자가 외부 지갑을 연결하거나 거래 시 지갑 전환을 해야 하는 UX 손실을 피하기 위함이며, 동시에 더 많은 맞춤형 기능을 제공할 수 있기 때문이다.
C 단말 고객 확보 비용은 매우 높지만, B 단말은 그렇지 않다. WaaS의 사용자 성장은 주로 SDK를 통합한 dApp을 통해 이루어진다. 따라서 BD와 개발자 관계를 잘 관리한다면 '도시가 농촌을 포위하는' 방식으로 생태계를 확장할 수 있다.
현재 C 단말 지갑들은 주로 금융 및 자산 관리에 집중하고 있지만, 이것이 반드시 Web3의 주요 시나리오라고 단정할 수는 없다. Web3의 대규모 채택을 이루기 위해서는 사용자 정체성(계정)과 사용자 동작(트랜잭션 전송)과 같은 더 기초적인 요소들을 추상화하여 하위 인프라 서비스로 제공하고, 상위 계층에서는 dApp이 더욱 풍부한 시나리오를 구현할 수 있도록 해야 한다.
기존 dApp 접속 방식을 보면, 지갑과 dApp 사이에는 비교적 밀접한 바인딩 관계가 형성된다.dApp 측에서 가능한 한 높은 지갑 점유율을 확보하는 것이 매우 중요하다. 이 점에서 B2B2C 모델은 지리적 이점을 갖는다.
사용자의 요구를 충족시키고, 사용 장벽을 낮추며, 개발자가 쉽게 통합할 수 있는 WaaS를 구축하는 것은 성공의 또 하나의 기둥이다. Particle의 zkWaaS는 세 가지 핵심 요소를 가진다:
1. 프라이버시 로그인. 계약 기반 지갑에서 트위터, 구글, 위챗 등 기존 Web2 로그인 방식(OAuth 인증)을 활용하여 사용자가 개인키 관리의 고통에서 벗어나 가장 익숙하고 쉬운 방법으로 Web3에 진입할 수 있게 한다. 동시에 제로지식 증명을 이용해 사용자 정체성을 숨긴다.
2. 프라이버시 거래. 스마트 스틸스 주소(Smart Stealth Address) 메커니즘을 통해 P2P 방식의 일반적 프라이버시 송금을 실현하고, ERC4337의 Paymaster를 사용해 스틸스 주소가 가스 없이 자산을 사용할 수 있도록 한다(가스 스폰서).
3. 완전한 AA 지갑 기능. Particle의 지갑 모듈은 ERC-4337의 기본 요구사항을 완전히 준수하며, Bundler, EntryPoint, Paymaster, Smart Wallet Account 등 ERC-4337 워크플로우의 주요 구성 요소를 포함하여, DApp이나 사용자의 스마트 지갑 기능 요구를 원스톱으로 만족시킨다.
Web2 계정 기반의 체인상 지갑 프라이버시 로그인
Particle의 프라이버시 로그인 방식은 JWT(Json Web Token)를 활용하여, 스마트 계약 내에서 Web2 정체성 인증 및 지갑 조작을 가능하게 한다.
JWT는 전통 인터넷에서 널리 사용되는, 서버가 클라이언트에게 발급하는 정체성 증명이다. 클라이언트는 서버와 상호작용할 때마다 이 증명을 제시하여 본인 인증을 수행한다.
（출처: FlutterFlow Docs）
JWT에는 계약이 정체성을 검증하는 데 기반이 되는 몇 가지 핵심 필드가 있다:
-
「iss」 (Issuer): JWT 발급자를 나타내며, 즉 Google, Twitter 등의 서버를 의미한다.
-
「aud」 (Audience): 해당 JWT가 사용되는 서비스 또는 애플리케이션을 나타낸다. 예를 들어 Medium에 Twitter로 로그인할 경우, Twitter가 발급한 JWT의 이 필드에는 Medium이 명시된다.
-
「sub」 (Subject): JWT를 수령하는 사용자 정체성을 의미하며, 일반적으로 UID로 표시된다.
실제 운영에서 iss와 sub는 대부분 변하지 않으며, 변경될 경우 내외부 시스템에서 큰 혼란을 초래할 수 있다. 따라서 이러한 파라미터들은 계약에서 사용자 정체성을 확인하는 데 활용되며,사용자는 개인키 생성 및 보관이 전혀 필요 없다.
JWT와 대응되는 개념은 JWK(JSON Web Key)이며, 이는 서버의 공개 키 쌍이다. 서버는 JWT를 발급할 때 JWK의 비밀키로 서명하며, 대응하는 공개키는 공개되어 타 서비스가 서명을 검증할 수 있다.
예를 들어 Medium이 Twitter로 로그인할 경우, Medium은 Google이 공개한 JWK 공개키를 사용해 JWT의 유효성을 검증함으로써, 해당 JWT가 실제로 Google이 발급한 것임을 확인한다. 스마트 계약 역시 JWK를 사용해 JWT를 검증한다.
Particle의 프라이버시 로그인 방식의 절차는 아래 그림과 같다:
구체적인 ZK 회로(circuit)는 여기서 생략하고, 프로세스의 핵심 사항만 나열하면 다음과 같다:
-
로그인 정보를 검증하는 Verifier 계약은 사용자 정체성-JWT와 관련된 ZK Proof와 무해한 eph_pk만 인지하며, 지갑 공개키나 JWT 정보를 직접 알 수 없으므로 사용자 프라이버시가 보호되며, 체인상 데이터로부터 로그인자의 정체를 외부에서 파악할 수 없다.
-
eph_pk(임시 키 쌍)은 단일 세션에서만 사용되는 키 쌍으로, 지갑의 공개/비밀키가 아니며 사용자가 신경 쓸 필요 없다.
-
이 시스템은 오프체인에서도 검증이 가능하며, MPC 등의 논리를 사용하는 계약형 지갑에도 적용 가능하다.
이는 전통적인 로그인 방식을 기반으로 한 계약 검증 방식이므로, 사용자는 Web2 계정 폐쇄 등의 극단적 상황을 대비해 다른 소셜 연락처를 후견인(Guardian)으로 지정할 수도 있다.
DH 키 교환 기반의 프라이버시 거래
Particle의 프라이버시 거래 방식을 설명하기 전에, 기존 EVM 시스템 내에서 수신자의 프라이버시를 보호하는, 즉 수신자 주소를 숨기는 방법을 먼저 살펴보자.
Alice가 송신자, Bob이 수신자라고 하고, 양측이 공유하는 정보는 다음과 같다고 가정하자:
1. Bob은 루트 소비 비밀키(root spending key) m과 스틸스 메타 주소(stealth meta-address) M을 생성한다. M은 m으로부터 도출되며, 두 값의 관계는 M = G * m으로, 이는 암호학적 연산상의 수학적 관계를 나타낸다.
2. Alice는 임의의 방법으로 Bob의 스틸스 메타 주소M을 획득한다.
3. Alice는 임시 비밀키r을 생성하고, 알고리즘 generate_address(r,M)을 사용해 스틸스 주소A를 생성한다.이 주소는 Bob 전용의 특별한 스틸스 주소이며, Bob은 자산을 수령한 후 이 주소를 완전히 제어할 수 있다.
4. Alice는 임시 비밀키r을 기반으로 임시 공개키R을 생성하고, 이를 임시 공개키 기록 계약(또는 양측이 인정하는 위치, 어떤 경로든 Bob이 접근 가능하면 됨)에 전송한다.
5. Bob은 주기적으로 임시 공개키 기록 계약을 스캔하여 새로 업데이트된 모든 임시 공개키를 기록해야 한다. 임시 공개키 계약은 공개적이므로 타인이 보낸 프라이버시 거래 관련 키들도 포함되어 있으며, Bob은 어느 키가 Alice가 자신에게 보낸 것인지 아직 모른다.
6. Bob은 업데이트된 각 기록을 스캔하며 generate_address(R,m)을 실행해 스틸스 주소를 계산한다. 만약 해당 주소에 자산이 있다면, 그것은 Alice가 생성하여 Bob이 제어하도록 승인한 것이며, 그렇지 않으면 Bob과 무관하다.
7. Bob은 generate_spending_key(R,m)을 실행하여 해당 스틸스 주소의 소비 비밀키를 생성한다. 즉 p = m + hash(A), 이후 Alice가 생성한 주소A를 제어할 수 있다.
위 프로세스는 복잡한 수학적 연산을 상당히 단순화한 설명이며,정보 교환 과정은 마치 두 첩보원이 공용 게시판에 오직 서로만 해독 가능한 암호를 적는 것과 같다. 암호 생성 및 해독 방법은 공개되어 있지만, 중간에 필요한 핵심 데이터는 오직 두 첩보원만 알고 있으므로, 외부에서는 방법을 알아도 해독이 불가능하다.
이 교환 방식은 유명한 Diffie–Hellman 키 교환 방식과 거의 동일하며, 각자의 비밀(Bob의 루트 소비 비밀키 m과 Alice의 임시 비밀키 r)을 노출하지 않은 채 양측 모두 공유 비밀(shared secret)—즉 위의 스틸스 주소 A를 계산할 수 있다. DH 교환에 대해 잘 모르겠다면 아래 색상 혼합 그림을 통해 비유적으로 이해할 수 있다.
DH 방식과 비교해 추가되는 단계는, 공유 비밀—스틸스 주소 A를 계산한 후 이를 바로 비밀키로 사용할 수 없다는 점이다. 왜냐하면 Alice도 A를 알고 있기 때문이다. 따라서 소비 비밀키 p = m + hash(A)를 구성하고, A를 공개키로 사용해야 한다. 앞서 언급했듯이 루트 소비 비밀키m은 오직 Bob만 알고 있으므로,Bob이 유일한 제어자가 된다.
이러한 방식의 프라이버시 송금에서는, 수신자가 새 거래를 받을 때마다 자금이 항상 새로운 EOA 주소로 들어간다. 수신자는 자신의 루트 소비 비밀키를 사용해 각 주소의 소비 비밀키를 계산해 어떤 주소가 자신과 관련 있는지 확인해야 한다.
하지만 여전히 문제가 하나 있다. 새롭게 생성된 스틸스 주소는 초기에 EOA 계정이며, ETH 등의 가스 토큰이 없을 수 있어 Bob은 직접 거래를 시작할 수 없다.스마트 계약 지갑의 Paymaster 기능을 통해 가스 대납을 해야 프라이버시 거래가 가능하다. 따라서 수신 주소를 다음과 같이 수정해야 한다:
계약 배포 시 CREATE2 메서드의 주소 계산 방식을 사용해 특정 파라미터(스틸스 주소 A를 해당 계약의 소유자로 설정 등)를 포함하여 Counterfactual 주소를 계산한다. 이는 계산된 계약 주소이지만 아직 계약이 배포되지 않았으며, 일시적으로는 EOA 상태이다.
Alice는 이 Counterfactual 주소로 직접 송금한다. Bob이 사용할 때는 해당 주소에 스마트 지갑을 생성하면 되며, 이때 가스 대납 서비스를 호출할 수 있다(이 단계는 Alice나 Particle 네트워크가 미리 대행할 수도 있음).
위 Counterfactual 주소를 우리는 스마트 스틸스 주소라고 부를 수 있다.Bob은 다음 절차를 통해 이 스마트 스틸스 주소 내 자산을 익명으로 사용한다:
임의의 자신의 주소를 통해 Paymaster에 입금하면, Paymaster는 자금 증명(ZK화)을 반환한다.
AA 메커니즘을 통해 잔액이 없는 임의의 주소로 Bundler 노드에 UserOperation을 전송하여, 위 스틸스 주소 내 자산을 호출한다. Bob은 새로운 주소를 통해 Paymaster에 자금 증명을 제공하면, Paymaster가 Bundler의 트랜잭션 패키징 수수료를 지불한다.
이는Tornado Cash와 유사한 작동 원리로, 자금 증명(ZK화)을 통해 메르클 트리의 리프 노드 집합 중 한 번 입금된 사실을 증명할 수 있지만, 소비 시에는 어떤 리프 노드의 자금을 사용했는지 알 수 없으므로 소비자와 입금자 사이의 연결을 차단한다.
종합하면, Particle은 AA와 스틸스 주소를 결합하여 스마트 스틸스 지갑 형태로 프라이버시 송금을 교묘하게 실현했다.
Particle Chain & 전 체인 계정 추상화
Particle Chain은 전 체인 계정 추상화(Omnichain Account Abstraction)를 위해 설계된 PoS 체인이다. 현재 및 미래를 고려할 때 단일 체인만의 세상은 불가능하며, 멀티체인 환경에서의 사용자 경험 향상은 매우 중요하다.
현재 ERC4337 계정 추상화 시스템은 멀티체인 환경에서 다음과 같은 문제를 겪고 있다:
-
동일한 사용자의 주소가 체인마다 달라질 수 있으며, 이는 계약 설계에 따라 달라진다.
-
사용자는 여러 체인의 계약 지갑을 수동으로 반복 관리해야 하며, 예를 들어 관리자 변경 등이 필요하다. 더 심각한 경우, 한 체인에서 관리자 권한을 갱신하고 이전 인증 방식을 폐기하면, 다른 체인에서는 변경도, 사용도 불가능해진다.
-
다양한 체인을 사용하려면 각 체인의 가스 코인이 필요하거나, 각 체인의 Paymaster에 미리 자금을 예치해야 한다. 개발자 입장에서도 불편한데, 특정 조건에서 사용자에게 무료 이용을 제공하거나 기타 기능을 구현하려면 각 체인에 자체 Paymaster를 배포하고 자금을 예치해야 하기 때문이다.
Particle Chain의 전 체인 계정 추상화는 위 문제점들을 해결한다:
-
Particle Chain 상에서 AA 지갑을 생성한다.
-
LayerZero 등의 AMB(Arbitrary Message Bridge) 크로스체인 프로토콜을 통해 신규 생성, 업그레이드, 권한 변경 등의 작업을 다른 체인으로 동기화한다. 다른 체인의 지갑은 모두 이 체인 지갑의 참조이며, 주체만 수정하면 모든 지갑에 자동 반영된다.
-
일관된 파라미터의 Deployer Contract를 통해 모든 체인의 지갑 주소를 동일하게 유지한다.
-
각 체인의 지갑은 AMB를 통해 서로 호출 가능하며, 반드시 Particle Chain에서 시작할 필요는 없다.
-
유니파이드 가스 토큰(Unified Gas Token)을 발행하여 전 체인 가스 코인으로 사용한다. Paymaster 메커니즘을 통해 ERC20 토큰을 가스료로 사용할 수 있도록 한다. 특정 체인에 가스나 Paymaster 예치금이 없더라도, 조건을 충족하는 체인에서 크로스체인 거래를 통해 유니파이드 가스 토큰을 소비할 수 있다.
위 목적 외에도 Particle Chain은 향후 다음과 같이 활용될 수 있다:
-
zkWaaS의 Proof 및 Salt 생성을 위한 탈중앙화 네트워크.
-
각 체인의 Bundler에 대한 인센티브 계층으로, Bundler의 탈중앙화를 촉진한다.
-
Intent Fusion Protocol의 Solver 네트워크 역할.
Particle Chain의 스토리텔링에서 유니파이드 가스 토큰은 생태계 전반의 핵심 가치 플랫폼이다:
-
가스 요금 지불 기능은 암호화폐에서 반복적으로 검증된 강력한 수요 및 가치 포획 로직이다.
-
유니파이드 가스 토큰은 기존 공용 체인 생태계에서 다시 가스 계층을 추상화한 개념이며, 이 추상화는 Particle Chain과 지갑 없이는 실현 불가능하므로, 유니파이드 가스 토큰은 Particle 생태계 전체의 가치 표현이다. 가스 계층이 생기면 각 체인의 사용자 상호작용 및 성장, 그리고 자체 토큰 가치와 유니파이드 가스 토큰은 상호보완적 관계가 된다.
-
통합 가스는Chainless 실현을 위한 추진 요소 중 하나다. 사용자 입장에서 단일 코인으로 지불하는 것은 사용 절차와 이해 비용을 크게 단순화한다. 향후 멀티체인 환경에서도 사용자는 무감각하게 사용할 수 있으며, underlying 인프라의 동작 방식을 신경 쓰지 않아도 된다. 현재 Web2에서 우리가 서버와 상호작용할 때 데이터센터의 위치, 사양, 사용 언어 및 데이터베이스 등에 관심 없는 것과 같다.
-
dApp이 유입하는 사용자는 유니파이드 가스 토큰에 직접 가치를 부여하며, 사용 사례가 매우 풍부하다.
Intent Fusion Protocol
보통 우리는 다양한 dApp을 사용할 때마다 경로를 계속 생각해야 한다:
-
DEX에서 유동성이 없으면 다른 DEX를 확인해야 한다.
-
동일 카테고리의 dApp 중 어느 것이 거래를 더 잘 수행할지 모른다.
-
많은 기능을 사용하려면 Approve를 해야 하는데, Approve란 무엇인가?
-
월렛 먼지 청소(mini token 정리), 소액 토큰 여러 개를 한 종류의 코인으로 전환하는 과정이 번거롭다.
-
최종 목표를 달성하기 위해 여러 앱을 거쳐야 한다. 예: 고레버리지 차입: 먼저 swap, 담보 제공, 차입, 얻은 토큰으로 다시 swap, 담보 제공, 차입...
위 내용은 현재 DeFi 세계의 일부에 불과하며, dApp이 더욱 다양해지는 Web3 대중화 시대에는 상호작용 복잡도가 훨씬 더 심각해질 수 있다.
따라서 구체적인 작업 단계 대신 인텐트(Intent)를 사용하는 것은 사용자 경험 측면에서 하늘과 땅 차이다.인텐트는 작업보다, 선언형 프로그래밍이 함수형 프로그래밍보다 더 우월한 것과 같다. 선언형 문장은 간단명료한 느낌을 주며, 내가 무엇을 원하는지만 선언하면 되고, 그 뒤의 세부 사항은 신경 쓰지 않아도 된다. 하지만 이를 위해선底层에 다양한 함수형 프로그래밍 문장들이 층층이 캡슐화되어 있어야 한다.
인텐트 사용도 마찬가지로 일련의 인프라 지원이 필요하다. 전체 프로세스를 살펴보자:
1. 사용자는 자연어 등을 통해 자신의 인텐트를 묘사하고, RFS(Request For Solver) 형태로 Solver 네트워크에 제출한다. Solver는 인텐트 해석기 역할을 하며, 현재 일반적인 Solver로는 1inch 같은 어그리게이터가 있는데, 이들은 사용자에게 최적의 DEX를 찾아주지만, 우리의 비전에 비하면 충분히 범용적이거나 강력하지 않다.
2. 여러 Solver가 응답하며, 이들은 경쟁 관계이다. 이 응답들은 Intent DSL 언어로 작성되며, 클라이언트에서 사용자가 이해하기 쉬운 형태로 파싱된다. 응답은 Input Constraints와 Output Constraints를 포함하여 입력과 출력의 범위를 정의한다. 사용자는 직접 제약 조건을 지정할 수도 있다. 간단한 예: Swap 사용 시 Swap 후 최소 수령량을 알려주는 것은 일종의 제약이다. 사용자는 여러 Solver의 응답 중에서 선택한다.
3. 인텐트에 서명한다.
4. Solver는 특정 실행 계약(Executor)을 지정하고, 인텐트를 응답 계약(Reactor)에 제출한다.
5. Reactor는 사용자 계정에서 필요한 입력(특정 자산 등)을 수집하고, Executor에 인텐트를 전달한다. Executor는 관련 로직 계약을 호출한 후 거래 결과를 Reactor에 반환한다. Reactor는 제약 조건을 검사한 후, 이상 없으면 결과를 사용자에게 돌려준다.
이 과정을 당신이 ChatGPT에게 요구사항을 말해주면, 아무리 복잡한 요구라도 최종 결과를 생성해 주는 것으로 상상할 수 있다. 결과에 만족하면 바로 사용할 수 있고, 그 과정은 신경 쓸 필요 없다.
결론
Particle Network는 종합적인 솔루션을 제시한다: zkWaaS, Particle Chain, Intent Fusion Protocol이라는 삼위일체 구조를 통해 Web2 OAuth 프라이버시 로그인, 프라이버시 거래, 전 체인 계정 추상화, 인텐트 거래 패러다임을 실현했다. 각 기능은 Web3 사용의 일부痛点을 해결하며, 이러한 진보와 최적화는 향후 Web3 대규모 채택을 위한 제품 및 기술적 기반이 될 것이다. 생태계 및 비즈니스 모델 측면에서는 B2B2C 패러다임을 채택하여, WaaS를 입구로 삼아 전체 제품 체인의 규모화 및 표준화를 유도하고, dApp 개발자들과 함께 생태계를 구축함으로써 사용자에게 낮은 장벽과 높은 경험을 제공하는 Web3 세계를 만들어 간다.
물론 다양한 프로젝트들은 Web3 mass adoption을 실현하는 경로에 대해 서로 다른 이해를 가지고 있다. 특정 프로젝트를 검토하는 것을 넘어, 다양한 솔루션을 통해 Web3가 현재 직면한 온보딩 장애(onboard friction)에 대한 이해를 높이고, 사용자 요구 및 문제점에 대한 사고를 깊이 있게 하며, 전체 생태계가 공동으로 연결되고 발전하는 것을 고려하고자 한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
