Abstract 에 대해 알아보다 쓴 글입니다. 뭔가 이상한 것 같으면 틀린 내용일겁니다.

AGW 가 뭔가?

Contract 형태의 지갑이다. Abstract portal 에 로그인하면 지갑 주소를 하나 주는데, 그것이 AGW 주소다. 이것의 전신은 Clave이다. Clave 를 포크하여 만든것이 AGW이다.

AGW 를 이해하기 위해서 일단 Clave 를 알아야한다.

Clave 살펴보기

Contract 형태의 지갑이다. Clave 는 모든 사람이 지갑을 쉽게 사용할 수 있도록 하는것이다.

은행 앱을 생각해보자. 핸드폰이 바뀔 때 마다 여러 인증수단을 통해 ‘나’임을 확인해야만 한다. 인증이 모두 완료된 후에는 긴 기간 ‘나’임을 다시 인증하지 않는다. 회사는 ‘이 기기’는 ‘김모씨’가 직접 사용하는 핸드폰 이라는 기기인증을 하고 싶은 것 이라고 상상할 수 있다.

이와 비슷한 경험을 제공하기 위해 만들어진것이 Clave 이다.

요즘의 기기들과 OS는 보안구역이 격리되어 있는 경우가 많다. Clave 의 문서에서 소개하는 iOS 의 Secure Enclave는 대충 말하자면 FaceID 로 인증하면 ECC 서명을 사용할 수 있다. ‘이 기기’를 인증하는것은 손쉽게 해결되었다.

Web3 는 은행이 따로 없다. ECC 로 Signature 를 알 수 있어도 이것을 보관, 검증, 관리해줄 주체가 없는것이다. 그래서 Contract 를 하나 만들고 그곳에서 Signatrue 를 검증하는 방법을 선택했다. Contract 에 서명자를 등록, 삭제 할 수 있는 인터페이스를 만들고, Contract 로부터 트랜잭션을 실행하여 Contract 를 마치 지갑처럼 사용할 수 있도록 하였다. 이제 Contract를 배포하여 지갑처럼 쓰고, Signature 를 검증하여 트랜잭션을 실행할 수 있게되었다.

은행은 ‘나’임을 확인하면 계좌의 제어권을 준다. 만약 Contract 지갑을 사용하다가 모든 기기를 분실하면 어떻게 될까? 전통적인 지갑이라면 그냥 잃는것이다. 그러나 Clave 는 이것을 해결하기 위해 Recovery Mechanism를 여러개 개발했다. 대표적인 방법이 Social Recovery 이다. 내가 지정한 사람의 Clave 유저로 하여금 Contract 내 owner 를 변경할 수 있다.

이로써 Clave 는 어려운 web3 지갑을 은행앱과 비슷한 사용성을 만들어냈다.

그럼 AGW 는 Clave 인가?

그냥 Clave 쓰면 안됨?

Clave 는 서비스다. Clave 앱이 따로 있으며, Clave 지갑을 배포하는 Deployer Contract 와 Clave Implement 를 배포해놓아야 사용 가능하다. AGW 는 그런걸 원하지 않은것으로 보인다.

Clave 에서 주로 사용하는 PassKey를 위한 R1 곡선의 인증방식, r1Owner와 r1Validator를 사용하는것이 아니다. AGW는 여러 EOA로 하나의 Contract Wallet 을 사용할 수 있도록 만들어진 K1 곡선의 인증방식, k1Owner, k1Validator 를 사용하고있다. Abstract 는 Clave의 Contract Wallet 은 똑같이 만들어 사용하되, 사용하는 지향점이 다른것이다.

나도 여기서 의문이 드는데 이 지향점이 뭔지 모르겟다. Privy에서 생성된 EOA를 ClaveWallet에 쓰기 위해서라는데 그냥 EOA 쓰면 안되나 라는 생각이 많이 든다.

Privy랑 한세트인 것 같던데?

아니다. Privy 와 AGW 는 전혀 다른것이다. Privy 는 지갑을 서비스 형태로 제공하는 업체이다. ‘포쿱’이라는 서비스를 만든다고 가정하자.

  1. Privy 에 ‘ForKup’ 프로젝트를 생성한다
  2. 웹에 ‘ForKup’ Privy 로 로그인 하는 인터페이스를 만든다
  3. 유저가 포쿱 서비스에 로그인/가입한다
  4. Privy의 ‘ForKup’ 프로젝트에 유저가 생성되며 EOA 가 부여된다
  5. 포쿱 사이트에서 유저는 Privy 를 통해 트랜잭션을 서명한다

대충 이런 서비스다. 여기서 주의할점은 A, B, C 서비스가 모두 Privy 프로젝트에서 이메일로 로그인 을 활성화 했다는 가정하에 qwe@naver.com 메일 주인이 A, B, C 모두 가입 했을 때 A, B, C 에 모두 각기 다른 EOA 가 생성된다는것이다.

즉 내가 Privy 로 로그인을 구현해도, 내 서비스에 로그인 하여 나오는 EOA 와 Abstract Portal 에 로그인하여 나오는 EOA 는 서로 다르다.

AGW 를 내가 만들어도 되나?

당연히 된다 Contract Wallet 은 1 컨트렉트 1 지갑 이다. 그래서 유저들이 컨트렉트를 배포하여 사용해야한다.

근데 그건 너무 어렵고 일관된 Contract Wallet 을 만들기 어렵지 않을까? 그래서 Clave, AGW 는 AccountFactory 가 있다. AccountFactory 는 누구나 호출할 수 있다.

AGW AccountFactory 의 deployAccount 를 호출할 때 EOA 주소를 keccak256 으로 해싱해서 salt 값으로 넣으면 된다. salt 는 create2 의 salt 값이다. 그럼 Contract Wallet Implement Contract 의 initializer 를 실행하며 새로운 Contrat Wallet 을 배포할 것 이다. create2 이므로 배포전에 AGW 의 주소를 미리 계산하는것도 가능하다.

deploy-account

Abstract Portal이 위에 모든것을 합쳐놓은 집합체이다

Abstract Privy 로 로그인 하면 EOA 가 자동적으로 생기고, Abstract 에서 AGW 를 만들어준다. abstract-portal-login

Discover 에 가면 여러 앱들을 볼 수 있다. 이게 Abstract가 밀고있는 것 인데, 여러 앱들의 마켓플레이스가 되는것이 Abstract Portal 의 역할이다. discover-apps

아무 앱이나 들어가 로그인을 눌러보면 Log in to Abstract가 뜬다. 이건 Abstarct Portal 에서 사용하는 유저의 계정으로 앱 의 Privy 로그인에 연결하는 과정이다. 앱 Privy 유저 <-> Abstract Privy 유저 의 연결이다. 앱에 로그인 한 적 없는데 뭘 연결하냐고? 이건 또 새로운 국면인데, 가입과 동시에 연결하는 형태이다. login-with-abstract

유저가 앱에서 어떤 활동을 하면 Abstract Portal 즉 유저의 AGW 에 XP와 뱃지를 부여한다. 이건 뭐 해볼라면 돈내라고 하길래 나도 안해봣다. xp

In a nutshell

  • AGW 는 Contarct로 만든 지갑이다
  • 여러 EOA 를 붙여 서명할 수 있다. (다른 EOA 로 1개의 지갑 컨트롤)
  • AGW 의 전신은 Clave 이다
  • Privy 와는 분리하여 생각하여야 한다
  • Privy에 로그인 하면 나오는 EOA 로 Clave 를 사용하기 위해 Clave 를 포크하여 AGW 를 만들고 커스터마이징 했다
  • AGW 는 내가 아무 EOA 나 사용하여 만들 수 있다
  • Abstract Portal은 생태계를 조성하는 역할을 하며 Privy 와 AGW 를 필요로 한다
  • Abstract Portal에 등록된 앱들은 앱 내의 활동으로 유저의 Abstract Portal 내 AGW 에 XP와 뱃지를 받을 수 있다