계정 추상화를 플랫폼에 구현한 EVM 체인이 있다?

12 min readMar 11, 2024

> DISCLAIMER: 이 글은 투자를 권유하기 위한 용도의 글이 아니며, 개인적으로 발행하는 블로그입니다. 클레이튼 재단의 공식 내용이 아니며, 개인적인 의견이 섞여 있을 수 있음을 말씀드립니다.

TL;DR

클레이튼은 단순히 이더리움을 포크한 게 아니라, 계정에 대한 사용성을 향상시켰음.
현재 많이 회자되고 있는 계정 추상화의 일부 기능이 클레이튼 메인넷 런칭 당시 구현되어 있었음
클레이튼의 계정 모델을 사용하면, 멀티시그 계정, N-screen 계정, 대납만 가능한 계정을 컨트랙트 없이도 쉽게 이용할 수 있음
이더리움의 계정 추상화와 클레이튼의 계정 모델을 결합하여 시너지를 내는 것도 가능함

안녕하세요, 클레이튼 재단에서 일하고 있는 콜린입니다. 이 글에서는 계정 추상화를 플랫폼에 구현한 클레이튼의 구현에 대해서 설명해보고자 합니다.

2023년 3월 ETH Denver에서 계정 추상화(AA, Account Abstraction, ERC-4337)을 발표한 이래로 AA에 대해 많은 관심들이 쏟아지고 다양한 개발활동들이 이뤄지고 있습니다. 계정 추상화에 대한 자세한 내용은 인터넷 검색을 통해 충분히 얻으실 수 있을테니, 이 글에서는 계정 추상화 자체에 대해서는 자세히 다루지 않겠습니다. 이더리움 계정 추상화에 대한 정보를 얻고 싶으시다면 글 하단의 참고자료를 확인해주시기 바랍니다.

현재 이더리움의 계정 추상화의 최근 트렌드는 코어 프로토콜은 수정하지 않고, 스마트 컨트랙트 기반으로 모든 것을 구현하는 방법입니다. 하지만 지난 9월 비탈릭의 글에서 볼 수 있듯이, 여전히 컨트랙트로 하는 것이 옳은지, 코어로 구현하는 것이 옳은지 판단하기는 어렵다고 생각합니다.

계정 추상화를 플랫폼에 구현한 EVM 체인이 있나요?

네, 있습니다! 현재의 이더리움 계정 추상화와 완벽히 일치하는 스펙은 아니지만, 계정 추상화가 풀려고 했던 문제 일부를 코어 프로토콜에서 해결하고자 했으며, 이를 설계/구현하고 6년째 운영하고 있는 EVM 체인이 있습니다. 이미 예상하시고 계시겠지만, 클레이튼입니다. :)

클레이튼의 계정 사용성 개선

클레이튼은 2018년 개발을 시작하면서 대중이 사용할만한 블록체인 서비스가 구현될 수 있는 플랫폼을 빠르게 구현하고자 했습니다. 그 당시에는 20초에 한 번씩 블록을 생성하는 이더리움이 대세였고, 이더리움 위에서 서비스를 개발한다고 했을 때, 대중이 사용할만한 사용성을 제공할 수 없다고 생각했습니다. 그래서 매 초 블록을 생성하고 바로 확정을 할 수 있도록 Istanbul BFT를 도입하고 블록을 1초에 한 개씩 생성하도록 구현하였습니다.

이러한 짧은 트랜잭션 실행시간 뿐만 아니라, 계정에 대한 사용성도 고민하였습니다. 블록체인의 근간은 가치를 교환하는 금융 시스템이니, 은행 계좌와 이더리움 계좌를 비교해 볼 수 있겠습니다. 은행 계좌의 주소는 이더리움 계좌의 주소, 은행 계좌의 비밀번호는 이더리움 계좌의 개인키로 비유할 수 있습니다. 우리가 보통 은행 계좌의 비밀번호를 실수로 노출하게 되었을 때, 은행 계좌의 주소는 유지하되, 비밀번호만 변경하게 됩니다. 대부분의 경우, 계좌 주소가 다른 서비스와 연결되어 있고, 계좌 주소를 변경한다는 것은 또 다른 불편함을 불러올 수 있습니다.

하지만 이더리움의 경우, 개인키와 주소가 강하게 연결되어 있어, 개인키를 변경한다는 것은 곧 주소를 변경한다는 것이 됩니다. 이 부분은 기존의 사용경험과 다르기 때문에, 대중의 입장에서는 받아들이기 쉽지 않을 것이라고 생각했습니다.

그래서 클레이튼은 계정 주소를 바꾸지 않고 개인 키만 변경할 수 있는 기술을 설계하고 구현하였습니다. 단순히 하나의 개인키를 바꾸는 것에서 그치지 않고, 더 확장가능할 수 있게, 여러개의 키를 할당하거나 역할 기반 접근 제어 (RBAC, Role-based Access Control)이 가능한 구조로 확장성을 고려하여 설계하였습니다. 기술에 대한 자세한 설명은 Klaytn Docs를 참고하시면 됩니다. 또한 해당 내용을 바탕으로 2019년 Devcon 5에서 Extending Ethereum’s Account and Transaction Models in Klaytn이라는 제목으로 발표도 했습니다. 아래부터는 클레이튼의 계정을 이용하여 어떤 사례들이 구현이 가능한지 살펴보도록 하겠습니다.

클레이튼의 계정 사용 사례

먼저, 현재의 클레이튼의 계정 사용성을 가지고 생각해 볼 수 있는 사용사례를 몇 가지 이야기해보고자 합니다. 사실 현재 클레이튼의 대표 지갑인 카이카스도 클레이튼의 계정 사용성을 완벽하게 지원하고 있지 않아 아쉬움이 좀 있습니다만, 이 글을 통해 어떤 사례들이 가능한 지 설명드리고자 합니다.

사용 사례1: Native Multisig Account

클레이튼 계정에는 여러 개의 개인 키를 하나의 계정에 할당할 수 있기 때문에, 별도의 컨트랙트가 없더라도 아주 쉽게 멀티시그 계정을 구현할 수 있습니다. 이더리움에서는 보안을 높이기 위해 멀티시그 계정을 만들고 싶으면 컨트랙트를 구현해야 합니다. 하지만 컨트랙트에 취약성이 발견되게 되면 해킹을 당해 자산이 탈취될 수도 있습니다. 플랫폼에 구현된 멀티시그는 코어 프로토콜에 의해 관리되기 때문에, 컨트랙트에 구현되는 경우보다는 보안 위협을 더 잘 관리할 수 있으며, 최악의 경우 hard-fork를 통해 전체 시스템의 복원이 가능합니다. 멀티시그는 이미 널리 알려진 개념이니, 더 자세한 설명은 필요하지 않을 것이라고 생각합니다.

사용 사례 2: N-screen Account (Multi-Device, Single Account)

멀티시그 기능을 활용하면 새로운 사용 사례를 생각해 볼 수 있습니다. 예를 들어, 노트북에서 생성한 개인키 한 개와, 핸드폰에서 생성한 개인 키 한개를 모두 A라는 계정에 할당하게 되면, 컴퓨터와 핸드폰 사이에 개인키를 주고 받지 않아도, 하나의 계정을 공유할 수 있습니다. 아래의 그림으로 사용 사례를 좀 더 쉽게 이해하실 수 있기를 바랍니다.

사용 사례 3: 역할 분리를 통한 계정 보안 강화

클레이튼의 계정 모델은 멀티시그를 넘어서, 역할 기반 접근 제어 (RBAC, Role-based Access Control)가 가능합니다. 현재 정의된 역할은 아래와 같이 세 가지 입니다.

- 토큰 전송 및 컨트랙트 실행

- 계정 키 변경

- 수수료 대납만 가능

세 역할에 대해 서로 다른 키를 할당할 수 있으며, 각 역할별로도 멀티시그로 관리할 수 있습니다. 보통은 토큰 전송 및 컨트랙트 실행에 대한 역할이 가장 많이 쓰이기 때문에, 이 역할에 할당된 키는 핸드폰이나 노트북에서 랜덤으로 생성된 키를 사용하여 원할 때 편하게 토큰을 전송하도록 할 수 있습니다.

계정 키를 변경하는 경우는 토큰 전송에 비해서는 현저히 낮은 빈도로 사용이 될 것을 쉽게 유추할 수 있습니다. 키를 따로 잘 보관하거나 하드웨어 월렛을 사용한다면 보다 높은 보안성을 확보할 수 있습니다.

이렇게 두 개의 역할만 분리한다고 하더라도, 핸드폰이나 노트북을 잃어버리거나 해킹 당했을 경우에도 계정을 다시 복구할 수 있는 장치를 마련할 수 있습니다.

사용 사례 4: 자금 관리와 대납 운영을 분리

위의 사례에서 수수료 대납만 가능한 역할에 대해 설명드리지 않았는데, 이 사용 사례에서 설명을 드리도록 하겠습니다. 수수료 대납만 가능한 역할은 말 그대로 토큰 전송은 불가능하고, 대납만 가능한 역할입니다. 클레이튼은 메인넷을 만들 당시부터 대납에 대한 부분을 많이 고려하였습니다. 아직까지도 블록체인 업계에서는 사용자들이 트랜잭션 수수료를 부담하지만, 기존의 많은 서비스들을 생각해 봤을 때, 대부분의 사용자는 비용을 지불하지 않으면서 서비스를 사용하고 있습니다. 이러한 부분이 실현되기 위해서는 대납기능이 플랫폼 수준에서 제공되어야 한다고 생각했고, 이 기능을 메인넷 개발단계에서 포함하여 설계하고 구현하였습니다.

이더리움에서는 이후에 메타 트랜잭션과 가스 스테이션을 통해 대납기능이 구현되었지만, 이 경우에는 스마트 컨트랙트 단에서 특별한 처리가 필요합니다. 클레이튼의 대납기능은 트랜잭션에 대납자의 서명이 추가되는 형태로 구현되어, 스마트 컨트랙트단에서는 특별한 처리가 필요없다는 것이 장점입니다.

서비스 개발사가 사용자 대신 트랜잭션 수수료를 대납하는 경우를 가정해보면, 개발사의 대납 운영팀에서 키를 관리하고 서명을 해야합니다. 하지만 대납 운영팀에서 한 사람이 자금을 전송시키고 도망가게 되면 자산을 다시 복구하기가 어렵습니다. 혹은 이런 마음이 없더라도 키 관리를 잘 하지 못해 자산이 탈취될 수 있습니다. 이것을 방지하기 위해 대납 운영팀에게는 대납만 가능한 키를 제공할 수 있습니다. 이 키는 수수료 대납만 가능하며, 자산을 전송하는 기능은 허용하지 않습니다. 이렇게 자금 관리 역할과 대납 운영의 역할을 분리하여 계정의 보안을 강화할 수 있습니다.

계정 추상화와 클레이튼의 계정 모델 통합을 통한 시너지 효과 확보

계정 추상화에서 가장 많이 다뤄지고 있는 주제가, 계정의 검증 권한 다양화입니다. 단순히 키만을 사용하지 않고 대부분 사람들이 친숙한 SNS를 통한 로그인이 많이 다뤄지고 있습니다. 이 부분을 클레이튼의 계정 모델과 접목한다면 더 좋은 사용성을 만들어 볼 수 있지 않을까 생각합니다.

현재 계정 추상화에서 많이 다뤄지지 않고 있지만 스펙에 대한 논의가 되었으면 하는 부분이 크게 아래 두 가지입니다.

- 검증 로직을 변경하는 방법에 대한 스펙

- 검증 로직을 여러 개 설정하는 방법에 대한 스펙

이런 부분들을 각 지갑사나 서비스에서 스스로 결정하여 구현할 수 있지만, 스펙이 정의가 되지 않는다면 서로간의 상호 운용성을 확보하기 어려울 것이라 생각합니다. 이러한 스펙이 정의된다면 지갑 사이의 상호운용성을 확보하여 A라는 지갑을 사용하던 유저가 B라는 지갑으로 쉽게 계정 이전을 할 수 있으리라고 기대합니다.

현 시점에서는 위 두 부분은 클레이튼의 계정 모델에서 제공하고 있는 기능이기 때문에, 현재의 계정 추상화 스펙과 클레이튼 계정 모델의 스펙을 활용하면 시너지 효과를 확보할 수 있습니다.

현재 클레이튼 코어 프로토콜에서는 키만 계정에 할당할 수 있도록 되어있습니다. 이것이 동작하기 위해서는, ERC-4337의 IAccount 인터페이스가 구현된 컨트랙트도 할당할 수 있게하는 수정이 클레이튼 코어 프로토콜에 필요합니다.

시너지 효과가 발생하는 사용사례: Account Abstraction + Klaytn’s Account Model

이 두 기능을 잘 이용하면 최고의 사용성과 보안성을 가지는 Web3 지갑을 구현할 수 있습니다. 또한 이 구현은 플랫폼 레벨에서 지원하고 표준이 모두 정의되어 있는 상태이기 때문에, 상호 운용성을 확보되어있다고 말할 수 있습니다. 또한, 컨트랙트 수준에서는 변화를 요구하지 않으며, 트랜잭션을 서명하는 방식에 대해서만 약간 변경이 필요합니다.

아래는 사용자 관점에서 작성해 본 사용 사례입니다.

1. 핸드폰에서 랜덤 생성한 private key로 계정 주소 A를 확보합니다.

2. 계정 주소 A의 Key Update역할을 구글 로그인과 카카오톡 로그인으로 설정하고, 2-of-2 로 설정하여 두 로그인 권한이 모두 확보되어야 키를 업데이트 할 수 있게 구성합니다. 핸드폰에서 랜덤 생성한 private key는 그대로 컨트랙트 실행 역할로 사용합니다.

3. 노트북에서 계정 주소 A를 입력하고, 구글 로그인과 카카오톡 로그인에 성공합니다. 노트북에서 생성한 랜덤 private key를 컨트랙트 실행 역할에 추가 할당하고,1-of-2로 설정합니다.

4. 핸드폰과 노트북이 서로 키를 교환하지 않았음에도 각자 디바이스에서 생성한 키로 계정 A를 같이 사용할 수 있습니다.

5. 핸드폰과 노트북을 모두 잃어버리더라도, 계정주소 A만 알고 있으면 구글 로그인과 카카오톡 로그인을 통해 계정을 다시 복구할 수 있습니다.

여기서, 추가적으로 사용성을 개선한다면, 계정 주소 A를 외우는 것이 어렵기 때문에, KNS와 같은 domain service를 사용하면 사용자가 쉽게 계정 주소를 외울 수 있습니다. 또한, 이 설계 자체가 지갑에 종속적이지 않기 때문에, 카이카스에서 해당 기능을 구현하였다 하더라도, 다른 지갑에서 쉽게 사용자의 마이그레이션을 지원할 수 있습니다. 여기서 한 발 더 나아가면, 서비스에서 생성한 새로운 랜덤 키를 컨트랙트 실행 역할에 부여한다면, 서비스에서 카이카스를 띄우지 않고도 카이카스와 하나의 계정을 공유할 수 있습니다.