[NEAR] Meta Transaction (2) NEP-366을 통한 표준 구현
NEAR의 UX 향상을 위한 매스어돕션 솔루션 Meta Transaction에 대한 시리즈 아티클을 연재합니다. 본 글은 시리즈의 2편으로 NEAR 프로토콜의 메타 트랜잭션 표준인 NEP-366과 타 프로토콜과의 구현 방식 비교에 대해 다룹니다. 다른 편을 읽고 싶으시다면 아래의 리스트를 확인해 주십시오.
- 1편: [NEAR] Meta Transaction (1) UX 향상을 통한 매스어돕션 솔루션
- 2편: [NEAR] Meta Transaction (2) NEP-366을 통한 표준 구현
- 3편: [NEAR] Meta Transaction (3) 활용 사례와 로드맵
본 글은 저자가 속하고 연계된 어떠한 단체나 개인의 의사와 연관되지 않았으며, 투자 권유, 자문 등의 다른 목적 없이 단순한 정보 전달을 위해 작성되었음을 밝힙니다. 모든 판단과 결정들은 스스로 충분한 근거를 가진 후 결정하시길 바랍니다. DYOR!
NEAR 프로토콜과 NEP
NEAR는 개발자 친화적인 플랫폼으로 알려져 있으며, 다양한 개발 레퍼런스와 교육 자료, 툴셋 등을 통해 간편하고 빠른 온보딩 프로세스를 제공한다. NEAR는 NEAR Collective라는 세계적인 연구원, 개발자 및 전문가들의 커뮤니티에 의해 구축되고 있으며, NEAR의 코드는 오픈 소스로 공개되어 있어 누구나 이 커뮤니티에 참여하고 개발에 기여할 수 있다.
NEP (NEAR Enhancement Proposal)은 NEAR 프로토콜 사양과 표준에 대한 변경사항들을 의미하는 라벨이다. NEAR의 사용자들은 Github Repository를 통해 제안을 올리고 프로세스에 따라 구현을 주도할 수 있다. 특히 표준의 경우 NEAR Protocol 위에서 스마트 계약 개발자들이 사용하는 다양한 공통 인터페이스와 API를 다루고 있다. 이에는 이번 아티클에서 다루는 메타 트랜잭션에 대한 논의도 포함된다.
NEP-366, NEAR 메타 트랜잭션 표준 제안
NEAR의 메타 트랜잭션에 대한 표준 제안은 NEP-366으로 나타난다. NEP-366은 NEAR 프로토콜의 메타 트랜잭션 기능에 대한 제안으로, 제3자 계정이 사용자를 대신하여 트랜잭션 수수료를 시작하고 지불할 수 있도록 허용하는 내용을 담고 있다.
앞서 말했듯, NEAR는 사용자 온보딩을 간소화하기 위해 설계된 블록체인이다. 하지만 현재 사용자가 NEAR 기반의 DApp 및 스마트 컨트랙트와 상호 작용하기 위해 필요한 가스비를 지불할 수 있는 NEAR 토큰이 없는 경우도 있을 것이다. 이러한 상황에서 사용자는 계정이 있어도 그대로 앱에서 제공하는 작업에 대한 보상을 받거나 무료 플레이 게임을 하는 등 DApp을 사용하기 어려울 것이다.
NEAR는 Aurora Plus 를 통한 free transaction 서비스를 통해 사용자의 입장에서 가스비에 대한 진입 장벽을 낮춘 프로덕트가 유저 온보딩을 Seamless하게 진행할 수 있다는 점을 확인한 바 있다. 많은 NEAR 개발자들 또한 NEP-366을 통한 메타 트랜잭션 구현에 동의하고 있다.
NEP-366은 사용자가 메타 트랜잭션을 통해 트랜잭션에 대한 비용을 지불하는 가장 쉬운 방법을 제공한다. 사용자 계정에 대한 요구사항이 없으며, 암시적 계정을 사용할 뿐만 아니라 심지어 체인 상에 사용자의 계정이 존재하지 않아도 된다.
NEP-366과 ERC-2771 비교
NEP과 같이 이더리움에서 EIP 및 ERC는 이더리움의 표준에 대한 내용을 정리하는 것에 쓰인다. 그중 ERC-2771은 메타 트랜잭션에 대해 정의하고 있다. 이는 1편의 메타 트랜잭션 작동 방식을 이더리움에 적용시킨 것이다. 용어나 세부 사항이 약간 다르지 원리는 비슷하니 이를 통해 NEP-366을 이해해 보자.
먼저 메타 트랜잭션에 관여하는 주체들을 정리해 보자.
- 트랜잭션 서명자 (Transaction Signer): 엔드유저. 트랜잭션 서명 및 가스 릴레이로 전송
- 가스 릴레이 (Gas Relay): 거래 서명자로부터 오프체인으로 서명된 요청을 수신하고 가스를 지불하여 신뢰할 수 있는 포워더를 통과하는 유효한 거래로 전환
- 신뢰할 수 있는 전달자 (Trusted Forwarder): 트랜잭션 서명자의 요청을 전달하기 전에 수신자가 서명과 논스(Nonce)를 올바르게 확인하도록 신뢰하는 스마트 컨트랙트
- 받는 사람 (Recepient): 신뢰할 수 있는 Forwarder를 통해 메타 트랜잭션을 수락하는 스마트 컨트랙트
트랜잭션 서명자는 오프체인 방식으로 트랜잭션에 서명하고 이를 가스비를 대신 납부할 주체인 가스 릴레이에게 전달한다. 가스 릴레이는 이 트랜잭션을 받아 가스비를 지불하고 포워더에게 전달한다. 포워더는 트랜잭션 서명자의 서명 등을 검증하고 메타 트랜잭션의 대상이 되는 Recepient 혹은 Receiver 스마트 컨트렉트에게 트랜잭션을 보내 실행시키게 한다.
NEP-366 핵심 내용과 의미
NEP-366 또한 위의 ERC-2771과 비슷한 원리로 작동되나 아래와 같이 Action, Receipt 등 NEAR 프로토콜의 트랜잭션 스키마가 달라 세부 사항이 다르다는 점을 기억하면 된다. NEP-366에서 제시된 프로토콜 관련 변경 사항은 크게 세 가지로 정리할 수 있다.
(1) Delegate Action(receiver_id, Action, signer_pk, signature)이라는 새로운 액션 생성
NEAR의 Action은 스마트 컨트랙트에서 수행되는 특정 작업을 나타낸다. NEAR에서 각 트랜잭션은 receiver_id 측에서 수행할 액션 목록으로 구성된다. 액션은 NEAR 토큰을 전송하거나 스마트 컨트랙트를 호출하는 등의 역할을 할 수 있다.
즉 1번을 통해 Delegate Action이라는 새로운 타입의 액션을 생성한 것은, 자신의 트랜잭션을 다른 사람이 실행할 수 있게 위임 (Delegate)을 해주는 작업을 의미하여 NEAR에서 네이티브한 메타 트랜잭션 서비스를 가능하게 하는 것을 알 수 있다.
(2) Receipt으로 변환하면 이러한 Action이 DelegateAction으로 receiver_id로 전송된다.
(3) Receipt 처리 시 지정된 계정과 signer_pk를 통해 서명을 확인하고, 주어진 receiver_id와 Action으로 새 Receipt의 receiver_id: AccountId, action: Action으로 랩을 해제한다.
NEAR의 영수증 (Receipt)은 계정 간 통신의 핵심 요소이다. Receipt은 이전 계정(predecessor_id)과 현재 계정(receiver_id)을 내용으로 가지고 있다. predecessor_id는 Receipt를 보낸 계정을 나타내고, receiver_id는 Receipt를 수신하는 계정을 나타낸다. Receipt에는 Action Receipt과 Data Receipt라는 두 가지 종류가 있다.
액션 Receipt는 트랜잭션 결과로 생성되며 액션 정보를 포함하고, 데이터 Receipt는 특정 데이터를 전송하고 대기하는 역할을 한다. 액션은 동일한 계약에 대해 동작하는 경우에는 함께 배치되며 배치된 액션은 하나의 단위로 작동한다. 거래가 처리될 때 액션들은 Action Receipt으로 배치되어 전환되므로 여러 액션을 하나의 트랜잭션으로 그룹화하여 실행된다는 것을 뜻한다.
2, 3번을 통해 기존 ERC-2771 메타 트랜잭션의 처리 방식처럼 NEAR에도 작업에 필요한 정보와 서명이 Receipt의 형태로 담기고, 중개자는 확인 과정을 거친 후 실제 트랜잭션으로 래핑해서 처리하는 것을 확인할 수 있다. 컨트렉트는 언래핑을 통해 사용자가 의도했던 작업을 트랜잭션으로 실행하는 메커니즘까지 잘 구현되어 있다.
NEP-366을 통한 NEAR 체인 위 메타 트랜잭션 구현은 NEAR의 트랜잭션 모델의 복잡성이 증가한다는 단점을 가지고 있지만, 더 많은 사용자들을 NEAR에 온보딩 시켜 에코시스템을 크게 확장할 수 있다는 엄청난 장점을 가지고 있다. 또한 유저의 서명뿐만이 아니라 영지식 증명 (ZK proof)을 지원하여 익명 트랜잭션을 도입하여 익명 방식으로 중개인에게 수수료를 지불할 수 있다는 보안적인 혁신도 기대할 수 있다.
이번 2편에서는 NEAR 프로토콜과 NEP-366 표준 제안을 통한 NEAR 프로토콜에서의 메타 트랜잭션 구현 방식에 대해 알아보았다. 다음 3편에서는 NEAR 메타 트랜잭션 구현 사례와 앞으로의 로드맵에 대해 살펴보겠다.
