기존 웹2 서비스들은 복잡한 과정들의 간소화를 통해 유저의 경험을 개선시켰고, 유저들은 이미 그러한 편의성에 익숙해져있지만, 블록체인은 여전히 복잡한 기술로 남아있다.
블록체인이 대중의 선택을 받지 못하는 이유는, 블록체인 지갑 자체가 사용하기 굉장히 어려운데다. 트랜잭션 수수료를 매번 지불해야한다는 것도 큰 장애물로 여겨져왔다.
해서 수이는 zkLogin을 통해 유저들이 자신의 데이터를 보호하면서도 기존 웹2 와 유사한 로그인 경험을 제안하고, Sponsored Transactions을 통해 유저들이 트랜잭션 수수료를 지불하지 않아도 온 체인 활동을 할 수 있도록 인프라를 구성하고 있다.
“단순함은 복잡한 것보다 어려울 수 있습니다. 단순해지려면 당신은 생각을 명쾌하게 하기 위해 열심히 노력해야 합니다. 하지만 결국 그럴 가치가 있지요. 일단 당신이 그 단순함에 도달하면 당신은 산을 옮길 수 있기 때문입니다.”
스티브 잡스(Steve Jobs, Co-founder of Apple)
오늘날 유저경험(User Experience)하면 가장 먼저 떠오르는 회사인 애플(Apple)의 창립자인 스티브 잡스(Steve Jobs)는 제품을 만들 때 “심플함”을 강조했다. 물론 잡스는 회사의 전반적인 부분(회사의 의사결정 구조부터, 제품의 라인업까지)에 심플함을 강조했던, 엄청난 미니멀리스트였지만, 우리가 가장 익숙한 잡스의 심플 철학은 바로 애플 제품의 디자인과 소프트웨어에서 드러난다. 수많은 버튼을 줄이고, 단순한 동작 몇 번으로 스마트폰을 조작할 수 있게 만들었던 애플의 ‘심플함’은 결국 대중들에게 큰 사랑을 받았고, 이는 지금도 현재 진행형이다.
애플 대학 수업에서 소개한다는 피카소의 ‘황소(The Bull).’
Source: Drawpaintacademy
애플이 성공한 이후에, 수많은 IT 회사들은 애플의 철학을 동경하며 따랐고, 그 결과로 이제 사람들은 ‘심플함’에 익숙해져있다. 다르게 말하면 UI적 복잡성은 더 이상 시장에서 용인되지 않는다는 말이기도 하다. 이제는 단순하고 명료한 것이 살아남는 시대, 하지만 유난히 이 트렌드를 거스르는 기술이 하나 있는데, 블록체인이 바로 그것이다.
체인 위에서 트랜잭션을 발생시키기 위해서는 수수료를 내야하고, 그 수수료도 법정화폐가 아니라 해당 네트워크의 네이티브 토큰인데다, 다른 블록체인마다 다른 계정과 지갑을 가지고 있어야 하고, 시드구문(Seed Phrase)과 프라이빗 키(Private Key)를 컴퓨터 어디엔가, 더 나아가서는 아무도 볼 수 없는 나만의 금고에 넣어둬야 내 계정을 지킬 수 있다. 지문인식, 얼굴 인식(FaceID 같은)으로 쉽게 로그인이 가능한 시대에 이러한 복잡성이라니. 블록체인이 아무리 재미있고 흥미로운 제품을 내놓더라도 사람들은 블록체인에 온보딩하는 과정에서 좌절하고 말 것이다.
심플함은 이제 인간의 관성이 되었다. 더 이상 심플하거나 직관적이지 않다면, 널리 사용될 수 없다. 그렇다면 블록체인은 무엇을 바꿔야할까? 본 글에선 블록체인 사용성 문제와 수이(Sui)가 이 문제를 어떤 방식으로 해결하는지에 대해서 알아보고자 한다.
실생활에서 지갑이 모든 경제 활동의 시작이듯, 블록체인에서 지갑은 블록체인으로 접속하는 그 시작점이다. 지갑이 없이는 블록체인을 사용할 수 없다. 다시 말해서, 블록체인 지갑이 사용하기 번거롭다면 애초에 유저들은 우리가 말하는 ‘블록체인 세상’에 들어올 수 없다는 이야기다.
그런데 안타깝게도, 블록체인 지갑은 굉장히 사용하기 어렵다. 블록체인 업계에서 오랜 시간 활동해온 나 조차도 가끔 지갑을 만들고 시드구문(Seed Phrase)과 프라이빗 키, 퍼블릭 키를 생성하고, 이것들을 구분한 다음에 저장해두는 것이 매우 번거롭고 불편하다. 정말로 필요한 일이 아니라면, 새로운 지갑을 만드는 행동 자체가 꺼려진다. 어찌보면 당연하다. 요즘 웬만한 로그인 서비스들은 SSO(Single Sign On의 약자로 1회 사용자 인증으로 다수의 애플리케이션 및 웹사이트에 대한 로그인을 가능하게 만드는 기술)를 사용해서 기존에 복잡했던 회원가입이나 로그인 과정을 간소화 하였기 때문이다.
SSO에 익숙한 유저들이 시드구문과 다양한 키들을 어딘가에 보관해두고, 메인넷이 바뀔 때마다 같은 과정을 반복하는 행동을 할리 만무하다. 이미 심플한 UI에 익숙한 유저들에겐 관성이 생겼을거고, 그 관성을 극복하기란 정말로 쉽지 않은 일이다. 블록체인 지갑이 과연 사용성(usability)적인 측면에서만 문제가 있을까? 그랬다면 얼마나 좋을까. 블록체인 지갑이 가진 문제점들을 하나 하나 나열해보자.
블록체인 지갑은 기본적으로 자가 수탁형(Self-Custodial) 방식을 채택한다. 즉, 기존 웹2에서처럼 비밀번호를 잃어버리거나 프라이빗 키를 잃어버렸을 때 그것을 복구해줄 수 있는 존재가 없다. 비트코인의 가격이 엄청 상승하고 나서 뉴스에 많이 나왔던 이야기가, “수많은 비트코인을 지갑에 넣어놨는데 지갑을 잃어버렸거나 프라이빗키를 분실해서 찾을 수가 없다.”라는 이야기였다. 실제로 Origin Stamp에 의하면, 2022년까지 잃어버린 비트코인의 개수만 무려 400만 비트코인이라고 한다. 신용카드는 잃어버리면 분실신고를 하고 재발급을 받으면 되고, 나의 온라인 계정은 잃어버리면 해당 서비스를 운영하고 있는 회사에 문의를 하면 된다. 하지만 블록체인 월렛은 어떤가? 답이없다. 과연 얼마나 많은 사람들이 이러한 리스크를 감수하고 자신의 자산을 보관할 수 있을까. 블록체인 지갑이 해킹당해서 자산을 잃어버렸다는 기사를 접하면 더더욱 블록체인 지갑을 사용할 수 없는 것도 문제다.
이 문제는 어쩌면 필자가 위에서 언급한 사용성 문제와 비슷한 맥락이라고 볼 수 있는데. 처음 블록체인 월렛을 사용하는 유저들의 입장에선 시드 구문을 포함해 프라이빗 키와 퍼블릭 키의 차이점조차 모른다. 그들이 왜 그렇게 길고 복잡한 조합으로 구성이 되어있는지도 모른다. 트랜잭션을 보내는 방법도 모를거고, 수수료를 왜 내야하는지도 의문일 것이다. 이렇게 교육이 안되어있는 상태에서 블록체인 지갑을 사용한다는 것은 어쩌면 걸음마도 떼지 않은 아기한테 운전을 하라고 이야기 하는 것과 같다.
AML, KYC와 같은 규제와 가이드 라인 문제들도 있다. 함부로 내 현실 자산을 암호자산으로 바꿀 수 없고, 그 반대 역시나 어렵다. 자금세탁이나 암호자산을 범죄로 악용할 수도 있다는 부분이 사람들로 하여금 직접적으로 블록체인 지갑을 쓰지 못하게 만든다. 또한, 지갑 서비스를 제공해주는 제공자에 대한 신뢰 이슈도 있을 것이다. 정말로 수많은 지갑들이 있는데, 그 지갑 제공자가 해커나 악의적인 참여자일수도 있다는 문제가 발생한다. 이 외에도 블록체인 지갑을 쓰지 않는 이유는 정말로 많을 것이다.
결론은, 지갑이 단순하고 안전하지 않다면, 앞으로도 많은 유저들이 블록체인을 직접적으로 사용할 일은 없을지도 모른다는 것이다. 어쩌면 우리 모두가 꿈꾸는 블록체인이 대중화되는 세상은, 지갑의 단순화 없이는 불가능한게 아닐까. 하지만 지갑의 문제가 해결된다고 하더라도 또 다른 문제가 있다. 트랜잭션 수수료가 바로 그것이다.
지갑의 UI가 단순해져서 시드구문이나 프라이빗 키를 저장하지 않아도 쉽게 블록체인 계정을 생성할 수 있다고 해보자. 그러면 블록체인이 널리 사용될 수 있을까? 아마, 어려울 것이다. 지갑을 누구나 가질 수 있다고 하더라도, 트랜잭션 수수료라는 기존 웹2에선 전혀 경험해보지 못한 또 하나의 장벽이 존재하기 때문이다. 생각해보자, 페이스북에 글 한 번 쓰는데 돈을 줘야한다고 한다면 페이스북은 지금과 같이 성장하기 어려웠을 것이다. 수많은 게임들을 즐기면서 매번 돈을 지불해야 한다고 한다면 게임은 오늘과 같이 대중화되기 어려웠을지도 모른다. 그런데 블록체인은 어떤가? 블록체인 위에서 행동하는 모든 것들은 다 유료다. 모든 것이 유료인 것 말고도 또 어떠한 문제들이 있을까?
모든 트랜잭션이 유료인 것도 불편하고 번거로운데, 트랜잭션 수수료가 실시간으로 변동된다면 유저들 입장에선 블록체인을 사용하기가 매우 어려울 것이다. 그리고 인간은 본질적으로 “예측 불가능성”을 싫어한다. 페이스북에 글을 쓰는데 오늘 500원이 들었는데, 내일은 1000원이라고 한다면, 페이스북이 유료인 것을 감안하고 사용하던 유저들마저도 떠나갈 것이다. 심지어 블록체인 수수료는 토큰으로 표기되기 때문에 유저 입장에선 두 번 계산해얀다는 점(바뀐 수수료에 대한 계산과 수수료를 법정화폐로 변환했을 때 얼마인지를 알아야 한다는 점)에서 유저에게 굉장히 불친절한 구조이다.
거의 모든 블록체인들은 벨리데이터나 노드들이 트랜잭션들이 어떤 순서로 블록에 담길지 순서를 정하는 과정을 거친다. 이 과정에서 당연히 더 많은 트랜잭션 비용을 소모한 유저들의 트랜잭션이 먼저 처리된다. 유저들은 자신의 트랜잭션이 언제 처리될지를 고민해야 하는 것이다. 더 많은 비용을 지불한 유저의 트랜잭션이 먼저 처리되는 것은 어찌보면 당연한 논리이긴 하지만, 유저의 입장에선 자신의 트랜잭션이 늦게 처리돼서 손해보는 상황을 감수해야 한다는 점에서 불편함을 야기한다고 볼 수 있다.
결국 기존 웹2 서비스에 익숙해진 사람들은 1) 온보딩이 굉장히 쉬워야 하고 2) 블록체인을 사용함에 있어서 그 과정을 최소화 해야지만 블록체인도 이질감 없이 사용할 수 있다고 볼 수 있다. 그리고 수이(Sui)는 이 두 가지를 잡기 위해서 새로운 기능을 소개했다: zkLogin 과 Sponsored Transaction이 바로 그것들이다. 이 둘에 대해서 한 번 알아보자.
Source: Binance Feed
우선 블록체인에 쉽게 온보딩 할 수 없다는 문제를 해결하기 위해서 나온 온보딩 프레임워크인 zkLogin에 대해서 알아보자. zkLogin은 간단하게 말해서 사람들이 웹2 서비스에 로그인을 하거나 가입을 하는 프로세스와 거의 동일한 수준의 UI를 제공해주는 온보딩 프레임워크이다. 다만, 기존 웹2에선 데이터를 써드파티가 맡아주는 형태였다면, zkLogin은 데이터를 유저가 온전히 소유하는 형태라는 부분이 다르다. 수이는 어떻게 편의성과 데이터 자가수탁(Self Custodial)을 가능하게 했을까? 우선 zkLogin의 방법에 대해 이해하기 위해서는 OAuth 2.0과 Zero Knowledge Proofs에 대한 이해가 선제적으로 필요하기 때문에 이 둘에 대해 간단하게 알아보자.
많은 분들은 생소한 단어겠지만, 이 글을 보시는 분들이라면 포필러스 웹사이트에 로그인을 하실 때도 OAuth 2.0 방식을 사용하셨을 것이다. OAuth 2.0은 Open Authorization 2.0의 약자로 신원 인증을 위한 개방형 표준 프로토콜이다. 간단하게 말해서 리소스를 소유한 사람들(유저들)을 대신해서 리소스에 대한 접근 권한을 써드파티에 위임할 수 있도록 해주는 프로토콜이라고 볼 수 있다. 우리가 현재 이용하는 간편 로그인 기능들은 거의 대부분 OAuth 2.0 프로토콜을 기반으로 만들어졌다고 해도 과언이 아니다. OAuth에 참여하는 참여자는 아래와 같다:
Resource Server: 리소스를 보유하고 있는 서버라고 볼 수 있다. Facebook, Google, Twitter와 같이 우리가 간편 로그인을 할 때 이용하는 업체들이 주로 Resource Server에 속한다.
Resource Owner: 자원의 소유자로서, 실제로 서비스를 이용하는 유저라고 볼 수 있다.
Authorization Server: 리소스에 대한 접근 권한 등을 관리하는 서버이다. Access Token을 만들어주는 서버이기도 하다.
Business Client: Resource Server에 접속해서 정보를 가져오고자 하는 주체이다. 포필러스도 Client라고 볼 수 있다.
위의 그림을 좀 더 설명하자면. 클라이언트는 약 세 번의 과정을 거쳐서 리소스를 받아간다: 우선 Resource Owner(유저)에게 인증 승인을 받아야 하고, 해당 승인을 Authorization Server에 주면 해당 서버는 Access Token을 준다. 그리고 그 Access Token을 Resource Server에 주어야 서버로부터 리소스를 얻어가는 방식이다.
수이의 zkLogin 역시 ‘간편 로그인’이 핵심 기능중에 하나이므로 OAuth 2.0 을 이용한다. 즉, OAuth 2.0 호환이 가능한 Resource Server는 전부 zkLogin 지원이 가능하다.
하지만 zkLogin이 단순히 OAuth 2.0만 사용했다면 앞에 zk라는 글자를 붙히지 않았을 것이다. 수이의 zkLogin이 기존 간편 로그인 기능들과 다른 점이 바로 영지식 증명(Zero Knowledge Proofs)을 이용했다는 부분일 것이다. 영지식 증명(ZKP)은 증명자가 정보 자체를 공개하지 않고도 검증자에게 특정 정보에 대한 지식이 있다는 것을 증명할 수 있는 암호화 프로토콜이다. 즉, ZKP를 사용하면 자신이 알고 있는 정보를 실제로 공개하지 않고도 자신이 무언가를 알고 있음을 증명할 수 있다.
ZKP는 정보 자체를 공개하지 않고도 증명자가 검증자에게 특정 정보에 대한 지식이 있음을 증명할 수 있도록 하는 방식으로 작동하기 때문에 인증, 신원 확인, 개인정보 보호등 다양한 애플리케이션에서 사용될 수 있고, 수이의 zkLogin은 ZKP를 활용한 애플리케이션 사례로 매우 적합하다고 볼 수 있다. 왜냐하면 zkLogin이 ZKP를 사용하여 써드 파티들이 수이 주소와 해당 OAuth 식별자에 연결되는 것을 방지하여 매우 간편한 로그인 방식을 제공하면서도 데이터를 온전히 유저들의 소유(영지식 증명 기술을 통해서 구글 페이스북과 같은 정보 제공자들도 자신들이 제공하는 정보와 특정 수이 주소가 연결되어있다는 것을 알 수 없다)로 만들어주기 때문이다.
우선 zkLogin 을 이해하기 위해서 알아야 하는 단어들이 몇 개 있다:
JWT Token: JWT Token은 JSON Web Token의 약자로 헤더(header), 페이로드(payload), 서명(signature) 로 구분되어 있고 클라이언트와 서버 사이에서 통신할 때 권한을 주기 위해 사용하는 토큰이라고 볼 수 있다.
Salt(솔트): 솔트값은 데이터, 비밀번호, 통과암호를 해시 처리하는 단방향 함수에 임의의 문자열을 덧붙이는 것을 말한다. 누군가 같은 비밀번호를 사용하더라도 솔트값이 적용된 문자열이 다르기 때문에 보통 스토리지에서 비밀번호를 보호하기 위해 사용된다.
OpenID Provider(OP): 이들은 OAuth 2.0에서 Resource Server의 역할을 맡는 주체들이라고 볼 수 있다. 현재까지 zkLogin을 지원하는 제공자들은 페이스북, 구글, 트위치, 슬랙, 애플이 있다.
Application Frontend: zkLogin을 지원하는 애플리케이션이나, 지갑과 같은 서비스를 이야기 한다.
Salt Backup Serivce: 백엔드 서비스로, 솔트값을 유저들에게 돌려주는 역할을 한다.
ZK Proving Service: JWT 토큰과, JWT 랜덤값, 유저 솔트값, max-epoch를 기반으로 ZKP를 만드는 역할을 한다. ZK Proof를 생성하는 것은 굉장히 많은 리소스가 드는 작업이기 때문에 직접 ZK Proof를 생성할 수도 있지만, 미스텐 랩스가 ZK Proof를 대신 만들어주기도 한다.
eph_sk. eph_pk: 이들은 임시적으로 서명을 생성하기 위해 필요한 KeyPair(Private Key와 Public Key의 쌍)를 의미한다. 서명 매커니즘은 통상적인 트랜잭션 서명 매커니즘과 동일하지만, OAuth 의 세션이 끝나면 만료되기 때문에 일시적이다.
zkLogin이 이러한 임시 KeyPair를 만든 이유는, 유저들이 키를 잃어버려도 언제든지 새로운 임시 키를 만들 수 있게해서 자산을 지킬 수 있도록 하기 위함이다.
iss(issuer): 발급자라는 의미로 JWT 토큰을 발행한 주체를 식별하는 문자열이다.
aud(audience): JWT 토큰을 전달받는 주체를 식별하는 문자열이다.
sub(subject): JWT 의 대상인 유저를 식별하는 문자열이다.
핵심 단어들에 대한 이해가 끝났다면, 다음은 zkLogin의 과정에 대해서 알아보자. 어떻게 유저들은 zkLogin을 통해 수이 블록체인에 접근이 가능할까?
우선 사용자들은 OP(OpenID Provider)에 로그인 함으로써 논스값이 담긴 JWT 토큰을 얻는다. 특히 사용자는 여기서 일시적인 KeyPair(eph_sk. eph_pk)를 생성한 다음 KeyPair에서 퍼블릭 키를 만료 시간(expiray times) 및 Jwt_randomness와 함께 논스에 입력한다. 사용자가 OAuth 로그인을 끝내면 애플리케이션의 리디랙션 링크에 JWT토큰을 찾을 수 있게 된다.
그 다음은 Application Frontend에서 JWT 토큰을 Salt Backup Service로 보낸다. 그러면 Salt Service는 JWT 토큰의 유효성을 검사한 뒤, iss(JWT발행 주체를 나타내는 문자), aud (애플리케이션을 나타내는 문자), sub(유저를 나타내는 문자)를 기반으로 유저의 고유한 솔트값과 JWT 토큰을 다시 Application Frontend 로 보낸다.
유저는 JWT 토큰, 솔트값, 임시 퍼블릭 키, jwt randomness, 문자열들(iss, aud, sub)을 ZK Proving Service로 보내면, ZK Proving Service는 해당 정보를 바탕으로 ZKP를 생성하게 된다.
애플리케이션은 문자열들을 바탕으로 유저의 주소를 연산한다(JWT 토큰만 유효하다면 이 작업은 독립적으로 이루어질 수 있다).
임시 프라이빗 키를 사용해서 임시 서명(emphemeral)을 하는 것으로 트랜잭션이 서명된다.
마침내 유저는 임시 서명과, ZKP, 그리고 다른 인풋값을 수이에 제출한다.
여기서 반드시 짚고 넘어가야하는 부분이 있는데, 바로 zkLogin은 각각의 애플리케이션, 그리고 zkLogin 호환 월렛마다 별도의 OAuth credential을 만든다는 부분이다. 쉽게 말하면, 여러분이 zkLogin으로 수이 블록체인에 온보딩하여 특정 애플리케이션을 사용한다고 했을 때, 애플리케이션마다 별도의 주소와 어카운트가 부여된다(여기서 애플리케이션은 단지 DeFi, Game등에만 국한된 것이 아니라 월렛들도 포함이다. 즉 같은 구글 계정으로 다른 지갑에 로그인 하더라도 다른 어카운트가 배정이 된다). 이렇게 하는 이유는 각각의 앱별로 독립적인 UX를 제공해주기 위해서라고 볼 수 있다. 이해를 돕기위해서 예시를 들어보자:
steve@4pillars.io + Sui Wallet = account 1
steve@4pillars.io + different sui wallet but zkLogin compatible = account 2
steve@4pillars.io + game or DeFi app = account 3
그렇다면 만약 steve@4pillars.io 라는 구글 계정을 활용해서 zkLogin을 하고 수이 월렛을 이용해서 게임이나 디파이를 사용하는 경우엔 사용하는 게임과 디파이마다 어카운트가 다르게 배정될까? 정답은 “아니다”이다. 필자가 방금 설명했던 것처럼 이 맥락에서는 월렛도 애플리케이션의 일종이기 때문에 여러분이 zkLogin으로 수이 월렛에 로그인 해서 다양한 수이의 애플리케이션들을 사용하신다면, 이미 수이 월렛 자체가 애플리케이션이기 때문에 이에 할당된 하나의 OAuth credential에 해당되는 것이다. 만약 다른 월렛을 거치지 않고 게임이나 디파이에 바로 접근했다면, 그 경우엔 애플리케이션마다 별도의 어카운트가 배정되는 것은 맞다.
지금 이 글을 읽고계신 분들은 zkLogin이 너무 복잡한 기능이라고 생각하실 수 있지만, 당연히 필자가 위에서 명시한 과정들은 유저딴에선 전부 생략되고 애플리케이션들이 감당하기 때문에 걱정하지 않아도 된다. 필자가 zkLogin의 과정을 설명한 이유는, zkLogin이 얼마나 안전하게 유저들의 데이터를 보호하고 어떻게 비수탁형으로 쉽게 수이 네트워크에 온보딩 될 수 있는지를 설명하고 싶어서였다. 블록체인에서 가장 중요한 기능인 월렛에 대한 이야기이니 만큼 자세한 설명이 있어야 사람들도 안심하고 쓸 수 있기 때문이다.
우선 다른 소셜 로그인들(웹2의 인증 정보들을 웹3로 가져오는 것)도 얼핏 보면 zkLogin과 비슷한 기능을 하고 있는 거 같지만 이들은 1)써드 파티에 의존한다는 점(웹2 신원 인증을 할 때나, 프라이빗 키를 운영할 때) 2) JWT 토큰을 증명할 때 스마트 컨트랙트에 의존해서 개인정보를 공개해야 하거나, 굉장히 비싼 온체인 ZKP 검증을 해야한다는 부분에서 zkLogin과 다르다고 볼 수 있다.
zkLogin은, Sui 네티이브 하기 때문에 zkLogin으로 만들어진 트랜잭션들은 수이 블록체인의 다른 트랜잭션들(뒤에서 후술한 Sponsored Transaction과 같은)과 쉽게 호환이 된다.
또한 임시 퍼블릭 키(ephemeral key)를 사용하기 때문에 써드 파티가 지속적으로 프라이빗 키를 관리하지 않아도 된다(해당 키는 만료 기간이 지날 때 까지만 사용되고, 해당 ZKP도 키가 만료되면 같이 만료된다). 마지막으로 ZKP와 임시 서명(ephemeral signature)만 온 체인에 제출하면 되기 때문에 다른 정보들을 공개하지 않아도 된다는 점에서 기존 소셜 로그인과는 확실한 차이점을 보인다.
여태까지 우리는 수이의 zkLogin에 대해서 알아보았다. zkLogin으로 블록체인 지갑이 주는 불편함은 해소할 수 있을 거 같은데, 필자가 언급했던 불편함은 지갑에만 있는 것이 아니었다. 오히려 어쩌면 지갑보다 더 불편한 것이 트랜잭션 수수료일 것이다. 수이는 트랜잭션 수수료의 복잡성 문제를 어떻게 해결하려고 할까?
Source: Sui Blog
사실 어떠한 것이 문제라면, 그 문제의 원인을 없애는 것이 가장 현명한 문제 해결 방법이다. 블록체인에서 트랜잭션 수수료를 지급하는 것이 UI적으로 문제라면, 트랜잭션 수수료를 지불하지 않고도 트랜잭션을 발생시킬 수 있으면 되지 않을까? 그래서 등장한 것이 바로 Sponsored Transactions이다. Sui의 프로그래밍 언어인 Sui Move에는 애플리케이션 빌더들이, 애플리케이션에서 발생하는 트랜잭션의 수수료 일부 또는 전부에 대해 대납할 수 있는 기능이 있다. Sponsored Transaction은 아래와 같은 경우에 사용할 수 있다:
유저가 실행한 트랜잭션에 대한 대납을 할 때.
유저가 GasLessTransactionData Object를 만들면 빌더에게 승인을 받기 위해서 보내진다. 그러면 빌더는 TransactionData Object를 트랜잭션 수수료와 함께 만들고 서명하면, 유저도 해당 Object에 서명하고 트랜잭션은 처리된다.
빌더가 직접 유저에게 트랜잭션 수수료를 전달할 때.
이 경우는 빌더가 TransactionData Object(이미 트랜잭션이 미리 허용(Pre-authorized)된 경우고, 트랜잭션 비용도 지불이 된다)를 만들어서 이메일이나 다른 메시징 프로토콜로 유저들에게 직접 전달해서 유저들이 해당 트랜잭션을 발생시킬 수 있도록 한다.
보통 이런 형태의 트랜잭션은 광고나, 새로운 유저들을 온보딩 시킬 때 매우 유용하게 쓰일 수 있다.
이러한 유형의 트랜잭션이 재미있는 것은, 수이 토큰이 없는 유저나 아예 블록체인을 사용해보지 않은 유저도 zkLogin과 함께 트랜잭션을 발생시키게 해서 웹3에 대한 경험을 시킬 수 있다는 부분에 있다.
빌더가 GasData 를 만들어서 유저에게 전달할 때
GasData는 일종에 백지수표와 같다. GasData(트랜잭션 비용 예산을 정의해둔다)를 전달받은 유저는 트랜잭션 비용이 얼마인지 알 필요 없이 트랜잭션을 실행하기만 하면, 빌더가 서명하고 트랜잭션이 처리된다.
이런식으로 수이는 유저의 입장에서 트랜잭션 비용을 알지 않아도 블록체인에서 트랜잭션을 발생시킬 수 있는 구조를 만들어놨다. 이러한 피처들이 좀 더 상용화 된다면 많은 유저들이 블록체인을 활용하는지도 모른채 웹3 서비스를 이용할 수 있는 순간도 찾아올 것이다.
수이의 코파운더이자 CPO인 Adeniyi는 웹3 서비스가 성공하기 위해서는 웹2의 성공 사례들을 살펴볼 필요가 있다고 하였다. 만약 레이어1 블록체인이, 웹3의 핵심 인프라가 되려면 AWS나 다른 서비스들이 어떻게 성공했는지를 다시 한 번 복습할 필요가 있다. 우리는 AWS위에 올라온 서비스를 쓰지만 AWS에 수수료를 지급하지 않는다. AWS에 서비스를 구현한 사람들이 AWS에 비용을 지불한다. 어찌보면 당연한 말이지만 블록체인에선 그렇지 않다.
어쩌면 블록체인이 대중에게 쓰이지 않는 가장 큰 이유는, 본질적으로 블록체인이 인간의 관성에 도전하고 있기 때문일지도 모른다.
그런 점에서 수이가 시도하고 있는 zkLogin과 Sponsored Transaction은 앞으로 블록체인 인프라 서비스가 나아가야하는 방향성을 제시한다고 느낀다. 어쩌면, 조만간 블록체인 서비스인지도 모르고 애플리케이션 서비스를 사용하는 날이 올지도 모르겠다.
이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.
Sui
Optimism
