zkLogin이란?

zkLogin은 두 항목을 공개적으로 연결하지 않고 OAuth credential을 사용하여 Sui address에서 transaction을 전송할 수 있게 해주는 Sui primitive 기능이다.

zkLogin은 다음과 같은 목표로 설계되었다:

• Streamlined onboarding: zkLogin은 익숙한 OAuth login flow를 사용해 Sui에서 transaction할 수 있게 하여 cryptographic key를 다루거나 mnemonic을 기억할 필요를 없앤다.
• Self-custody: zkLogin transaction은 표준 OAuth login process를 통한 사용자 승인을 요구한다. OAuth provider는 사용자를 대신해 transaction할 수 없다.
• Security: zkLogin은 two-factor authentication scheme이다. transaction을 전송하려면 최근 OAuth login의 credential과 OAuth provider가 관리하지 않는 salt가 모두 필요하다. OAuth account를 탈취한 공격자라도 salt까지 탈취하지 않는 한 사용자의 Sui address에서 transaction할 수 없다.
• Privacy: zero-knowledge proof는 제3자가 Sui address를 그에 대응하는 OAuth identifier와 연결하는 것을 방지한다.
• Optional verified identity: 특정 Sui address를 도출하는 데 사용된 OAuth identifier를 검증하도록 선택할 수 있다. 이는 검증 가능한 온체인 identity layer의 기반을 만든다.
• Accessibility: zkLogin은 sponsored transaction과 다중 서명(multisig) 같은 다른 Sui primitive와 통합된다.
• Rigor: zkLogin의 코드는 zero-knowledge를 전문으로 하는 두 회사가 독립적으로 audited했다. common reference string 생성을 위한 공개 zkLogin ceremony에는 100명이 넘는 참여자의 기여가 포함되었다.

zkLogin이 Sui에 가져오는 핵심 차별점은 다음과 같다:

1. Native support in Sui: blockchain agnostic한 다른 솔루션과 달리, zkLogin은 Sui 전용으로 배포된다. 이는 zkLogin transaction이 다중 서명 및 sponsored transaction과 매끄럽게 결합될 수 있음을 뜻한다.

2. Self-custodial without additional trust: Sui는 JWT의 nonce field를 활용해 ephemeral public key를 commit하므로, 어떤 trusted party와도 persistent private key management가 필요 없다. JWK 자체도 어떤 source of authority를 신뢰하지 않고 validator의 stake 정족수가 합의한 oracle이다.

3. Full privacy: 온체인에 제출할 것은 zero-knowledge proof와 ephemeral signature 외에는 없다.

4. Compatible with existing identity providers: zkLogin은 OpenID Connect를 채택한 provider와 호환되므로 OAuth provider 자체 외의 중간 identity issuer나 verifier를 신뢰할 필요가 없다.

애플리케이션이나 wallet에 zkLogin을 통합하려는 builder라면 zkLogin 통합을 참고한다.

OpenID providers

The following table lists the OpenID providers that can support zkLogin or are currently being reviewed to determine whether they can support zkLogin.

Provider	Can support?	Devnet	Testnet	Mainnet
Facebook	Yes	Yes	Yes	Yes
Google	Yes	Yes	Yes	Yes
Twitch	Yes	Yes	Yes	Yes
Apple	Yes	Yes	Yes	Yes
Slack	Yes	Yes	No	No
Kakao	Yes	Yes	No	No
Microsoft	Yes	Yes	No	No
AWS (Tenant)*	Yes	Yes	Yes	Yes
Karrier One	Yes	Yes	Yes	Yes
Credenza3	Yes	Yes	Yes	Yes
RedBull	Under review	No	No	No
Amazon	Under review	No	No	No
WeChat	Under review	No	No	No
Auth0	Under review	No	No	No
Okta	Under review	No	No	No

• Sui supports AWS (Tenant) but the provider is enabled per tenant. Contact us for more information.

Terminology and notations

이 섹션은 the OpenID specification에 정의된 관련 OpenID 용어와 zkLogin에서의 사용 방식을 설명하고, 프로토콜 세부사항에 대한 정의를 함께 제공한다.

OpenID provider (OP)

OpenID provider는 최종 사용자를 인증하고 인증 이벤트와 최종 사용자에 대한 claim을 relying party에 제공할 수 있는 OAuth 2.0 authorization server이다. 이는 JSON web token payload의 iss field에서 식별된다. zkLogin이 현재 지원하는 엔티티는 table of available OPs를 확인한다.

Relying party (RP) or client

relying party는 OpenID provider로부터 최종 사용자 인증과 claim이 필요한 OAuth 2.0 client application이다. 이는 애플리케이션을 생성할 때 OP가 할당한다. 이는 JWT payload의 aud field에서 식별되며 zkLogin enabled wallet 또는 application을 의미한다.

Subject identifier (sub)

subject identifier는 issuer 내에서 최종 사용자에 대해 로컬하게 유일한 식별자이며 RP가 소비하도록 의도된 값이다. Sui는 이를 사용자 address를 도출하는 key claim으로 사용한다.

JSON Web Key (JWK)

JSON Web Key는 OP에 대한 public key 집합을 나타내는 JSON data structure이다. 공개 endpoint(예: https://www.googleapis.com/oauth2/v3/certs)를 질의하면 provider의 kid에 대응하는 유효한 public key를 검색할 수 있다. JWT header의 kid와 일치하면 JWT는 payload와 대응 JWK에 대해 검증될 수 있다. Sui에서는 모든 authority가 JWK endpoint를 독립적으로 호출하고, 지원되는 모든 provider에 대한 최신 JWK view는 protocol upgrade 중에 업데이트된다. JWK의 정확성은 validator stake의 정족수(2f+1)에 의해 보장된다.

JSON Web Token (JWT)

JSON Web Token은 OAuth login flow를 완료한 뒤 RP로 가는 redirect URI 안에 있다(https://redirect.com?id_token=$JWT_TOKEN처럼). JWT는 header, payload, signature를 포함한다. signature는 jwt_message = header + . + payload와 kid로 식별되는 그 JWK에 대해 검증되는 RSA signature이다. payload는 여러 claim으로 구성된 name-value pair 형태의 JSON을 담는다.

Header

Name	Example Value	Usage
alg	RS256	zkLogin은 RS256(RSA + SHA-256)만 지원한다.
kid	c3afe7a9bda46bae6ef97e46c95cda48912e5979	JWT를 검증하는 데 사용해야 하는 JWK를 식별한다.
typ	JWT	zkLogin은 JWT만 지원한다.

Payload

Name	Example Value	Usage
iss	https://accounts.google.com	OAuth provider에 할당된 고유 식별자이다.
aud	575519200000-msop9ep45u2uo98hapqmngv8d8000000.apps.googleusercontent.com	OAuth provider가 relying party에 할당한 고유 식별자이다.
nonce	hTPpgF7XAKbW37rEUS6pEVZqmoI	relying party가 설정하는 값이다. zkLogin enabled wallet는 이를 ephemeral public key, expiry time, randomness의 해시로 설정해야 한다.
sub	110463452167303000000	사용자에게 할당된 고유 식별자이다.

zkLogin transaction의 경우 iat와 exp claim(timestamp)은 사용되지 않는다. 대신 nonce가 expiry time을 지정한다.

Key claim

sub 또는 email처럼 address를 도출하는 데 사용되는 claim이 key claim이다. 당연히 한 번 설정된 후 다시 변경되지 않는 claim을 사용하는 것이 이상적이다. zkLogin은 현재 OpenID specification이 provider가 이 identifier를 변경하지 못하게 요구하기 때문에 sub를 key claim으로 지원한다.

Notations

1. (eph_sk, eph_pk): ephemeral signature를 생성하는 데 사용되는 private/public key pair이다. 서명 메커니즘은 전통적인 transaction 서명과 같지만, 짧은 session 동안만 저장되고 새 OAuth session에서 갱신될 수 있기 때문에 ephemeral하다. ephemeral public key는 nonce 계산에 사용된다.

2. nonce: JWT payload에 포함된 application-defined field이며, ephemeral public key, JWT randomness, maximum epoch(Sui가 정의한 expiry epoch)의 해시로 계산된다. 구체적으로 zkLogin 호환 nonce는 nonce = ToBase64URL(Poseidon_BN254([ext_eph_pk_bigint / 2^128, ext_eph_pk_bigint % 2^128, max_epoch, jwt_randomness]).to_bytes()[len - 20..])로 전달되어야 하며 여기서 ext_eph_pk_bigint는 ext_eph_pk의 BigInt 표현이다.

3. ext_eph_pk: ephemeral public key(flag || eph_pk)의 byte 표현이다. 크기는 signature scheme 선택에 따라 달라진다(flag로 표시되며 서명에 정의된다).

4. user_salt: OAuth identifier를 온체인 address와 분리하기 위해 도입된 값이다.

5. max_epoch: JWT가 만료되는 epoch이다. 이는 Sui에서 사용하는 u64이다.

6. kc_name: key claim 이름이며, 예를 들면 sub이다.

7. kc_value: key claim 값이며, 예를 들면 110463452167303000000이다.

8. hashBytesToField(str, maxLen): Poseidon hash를 사용해 ASCII string을 field element로 해싱한다.

Entities

1. Application frontend: zkLogin을 지원하는 wallet 또는 frontend application을 말한다. frontend는 ephemeral private key 저장, OAuth login flow 유도, zkLogin transaction 생성 및 서명을 담당한다.

2. Salt backup service: 고유 사용자별 salt를 반환하는 backend service이다. salt를 유지하는 다른 전략은 zkLogin 통합을 참조한다.

3. Zero-knowledge proving service: JWT, JWT randomness, user salt, max epoch에 기반한 zero-knowledge proof를 생성하는 backend service이다. 이 proof는 zkLogin transaction을 위한 ephemeral signature와 함께 온체인에 제출된다.

How zkLogin works

high level에서 zkLogin protocol은 다음과 같이 동작한다:

1. JWT는 nonce라는 사용자 정의 field를 포함하는 OAuth provider의 signed payload이다. zkLogin은 nonce를 public key와 expiry epoch로 정의하여 the OpenID Connect OAuth flow를 사용한다.

2. wallet는 nonce에 정의되는 ephemeral key pair를 저장한다. ephemeral private key는 짧은 session 동안 transaction에 서명한다. Groth16 zero-knowledge proof는 JWT에서 생성되며 민감한 field를 숨긴다.

3. transaction은 ephemeral signature와 zero-knowledge proof와 함께 온체인에 제출된다. Sui authority는 ephemeral signature와 proof를 검증한 뒤 transaction을 실행한다.

4. public key에 기반해 Sui address를 도출하는 대신, zkLogin address는 sub(user identifier), iss(provider), aud(application), user_salt(OAuth identifier를 온체인 address와 분리하는 값)로부터 도출된다.

Step 0: zkLogin uses Groth16 for zkSNARK instantiation, which requires a common reference string (CRS) linked to the circuit.

ceremony는 proving service의 proving key와 Sui authority의 verifying key를 생성하는 데 사용되는 CRS를 생성한다.

Steps 1-3: Login to an OpenID provider (OP) to obtain a JWT containing a nonce.

ephemeral key pair (eph_sk, eph_pk)를 생성하고 eph_pk, expiry time(max_epoch), randomness(jwt_randomness)를 nonce에 포함한다. login 후 JWT는 application의 redirect URL에 나타난다.

Steps 4-5: The application frontend sends the JWT to a salt service. The service returns the unique user_salt based on iss, aud, and sub.

Steps 6-7: Send the JWT, user salt, ephemeral public key, JWT randomness, and key claim name (for example, sub) to the proving service.

proving service는 다음을 증명하는 zero-knowledge proof를 생성한다:

• nonce가 올바르게 도출되었음을 확인한다.
• key claim 값이 대응되는 JWT field와 일치함을 확인한다.
• provider의 JWT에 대한 RSA signature를 검증한다.
• address가 key claim과 user salt와 일관됨을 확인한다.

Step 8: The application computes your address based on iss, aud, and sub.

Steps 9-10: Sign the transaction with the ephemeral private key and submit it with the ephemeral signature, ZK proof, and other inputs to Sui.

Step 10 이후 Sui authority는 provider의 JWK(합의에 의해 저장됨)와 ephemeral signature를 대조해 ZK proof를 검증한다.

Address definition

address는 다음 입력으로 계산된다:

1. The address flag: zkLogin address에 대한 zk_login_flag = 0x05이다. 이는 domain separator 역할을 한다.

2. kc_name_F = hashBytesToField(kc_name, maxKCNameLen): key claim의 이름이며, 예를 들어 sub이다. byte sequence는 hashBytesToField(아래 정의)를 사용해 BN254의 field element로 매핑된다.

3. kc_value_F = hashBytesToField(kc_value, maxKCValueLen): hashBytesToField로 매핑된 key claim의 값이다.

4. aud_F = hashBytesToField(aud, maxAudValueLen): relying party(RP) identifier이다.

5. iss: OpenID Provider(OP) identifier이다.

6. user_salt: OAuth identifier를 온체인 address와 분리하기 위해 도입된 값이다.

마지막으로 Sui는 addr_seed = Poseidon_BN254(kc_name_F, kc_value_F, aud_F, Poseidon_BN254(user_salt))일 때 zk_login_address = Blake2b_256(zk_login_flag, iss_L, iss, addr_seed)를 도출한다.

Ceremony

OAuth artifact의 프라이버시를 보존하기 위해 소유에 대한 zero-knowledge proof가 제공된다. zkLogin은 proof 크기와 검증 효율성 측면에서 가장 효율적인 범용 zkSNARK이기 때문에 zero-knowledge proof를 인스턴스화하기 위해 Groth16 zkSNARK를 사용한다.

그러나 Groth16은 trusted party가 설정해야 하는 계산별 common reference string(CRS)을 필요로 한다. zkLogin은 고가치 transaction의 안전한 보관과 중요한 smart contract의 무결성을 보장할 것으로 기대되므로, 시스템 보안을 단일 엔티티의 정직성에 기반할 수 없다. 따라서 zkLogin 회로용 CRS를 생성하려면 많은 참여자 중 소수의 정직성을 가정하는 protocol을 실행하는 것이 중요하다.

Sui zkLogin ceremony는 다양한 참여자 그룹이 CRS를 생성하기 위해 수행하는 cryptographic multi-party computation(MPC)이다. ceremony는 Bowe, Gabizon, Miers가 설명한 MMORPG MPC protocol을 따른다. protocol은 2단계로 진행된다. 첫 번째 단계는 타원 곡선 원소의 지수에서 비밀 값 tau의 거듭제곱 수열을 만든다. 이 단계는 회로와 무관하므로 ceremony는 기존 커뮤니티 기여 perpetual powers of tau의 결과를 채택한다. 현재 ceremony는 zkLogin 회로에 특화된 두 번째 단계이다.

MMORPG protocol은 순차적 protocol이므로 사전 동기화나 순서 지정 없이도 무제한의 참여자가 순차적으로 참여할 수 있다. 각 참여자는 이전 참여자의 출력을 다운로드하고, 자신의 entropy를 생성한 뒤 받은 결과 위에 덧씌워 자신의 기여를 만들고, 이를 다음 참여자에게 전달해야 한다. 이 protocol은 최소 1명의 참여자가 protocol을 성실히 따르고 강한 entropy를 생성해 신뢰성 있게 폐기하면 보안을 보장한다.

How was the ceremony performed?

Sui validator, 암호학자, Web3 전문가, 세계적으로 저명한 학자, 비즈니스 리더 등 다양한 배경과 소속을 가진 100명이 넘는 사람에게 초대장이 발송되었다. ceremony는 2023년 9월 12일부터 18일까지 진행되도록 계획되었지만, 고정된 슬롯 없이 원하는 시점에 참여할 수 있게 했다.

MPC는 순차적이므로 각 기여자는 이전 기여자가 끝날 때까지 기다렸다가 그 기여물을 받아 MPC 단계를 수행하고 자신의 기여물을 만들어야 했다. 이 구조 때문에 먼저 합류한 사람들이 끝나는 동안 후속 참여자가 기다릴 수 있는 queue를 마련했다. 참여자 인증을 위해 각 참여자에게 고유 activation code를 보냈다. activation code는 signing key pair의 secret key였고, 두 가지 목적을 가졌다: coordination server가 참여자의 이메일을 기여와 연결할 수 있게 하고, 대응 public key로 기여를 검증할 수 있게 한다.

참여자는 브라우저 또는 Docker를 통해 기여할 수 있었다. 브라우저 option은 모든 것이 브라우저에서 일어나므로 참여자에게 더 user-friendly했다. Docker option은 Docker setup이 필요하지만 Dockerfile과 기여자 source code가 open source이고 전체 과정이 검증 가능하므로 더 투명했다. 또한 브라우저 option은 snarkjs를 사용하고 Docker option은 Kobi's implementation을 사용한다. 이는 소프트웨어 다양성을 제공했고, 참여자는 자신이 신뢰하는 방법으로 기여할 수 있었다. 추가로 참여자는 임의 text를 입력하거나 cursor를 무작위로 움직여 entropy를 생성할 수 있었다.

zkLogin 회로와 ceremony client code는 open source로 공개되었고, 참여자가 ceremony 전에 검토할 수 있도록 링크가 제공되었다. 추가로 개발자 문서와 zkSecurity의 회로 audit report도 게시되었다. ceremony는 1단계에서 회로와 무관한 perpetual powers of tau의 challenge #0081(커뮤니티 기여 80건으로 생성됨)을 채택했다. Drand random beacon의 epoch #3298000 출력은 편향을 제거하기 위해 적용되었다. 2단계 ceremony에서는 총 111건의 기여가 있었고, 브라우저 82건과 docker 29건이었다. 마지막으로 epoch #3320606의 Drand random beacon 출력을 적용해 기여의 편향을 제거했다. 모든 중간 file은 phase 1과 phase 2에 대한 지침을 따라 재현할 수 있다.

최종 CRS와 각 참여자의 기여 transcript는 공개 repository에서 확인할 수 있다. 기여자는 자신이 작업 중이던 이전 기여의 hash와 자신의 기여 이후 결과 hash를 화면과 이메일로 받았다. 그들은 이 hash를 ceremony site에 공개된 transcript와 비교할 수 있다. 또한 누구나 hash가 올바르게 계산되었고 각 기여가 최종 parameter에 적절히 반영되었는지 확인할 수 있다.

결국 최종 CRS는 proving key와 verifying key를 생성하는 데 사용되었다. proving key는 zkLogin용 zero-knowledge proof를 생성하는 데 사용되며 zero-knowledge proving service와 함께 저장된다. verifying key는 Sui에서 zkLogin transaction을 검증하는 데 사용되는 validator software(release 1.10.1의 protocol version 25)의 일부로 deployed되었다.

Security and privacy

다음 섹션은 모든 zkLogin artifact, 그들의 보안 가정, 그리고 유실이나 노출의 결과를 설명한다.

JWT

JWT의 유효성은 피싱 공격을 방지하기 위해 client ID(aud) 범위로 제한된다. proof에 대한 same origin policy는 악성 application을 위해 획득한 JWT가 zkLogin에 사용되는 것을 방지한다. client ID용 JWT는 redirect URL을 통해 application frontend로 직접 전송된다. 특정 client ID용 JWT가 유출되면, 이러한 token은 사용자 이름과 이메일 같은 민감한 정보를 자주 포함하므로 사용자 프라이버시가 손상될 수 있다. 추가로 backend salt server가 user salt management를 담당하는 경우 JWT가 salt를 가져오는 데 악용될 수 있어 추가 위험이 생긴다.

그러나 대응 ephemeral private key가 안전한 이상 JWT 유출이 fund 손실을 의미하지는 않는다.

User salt

user salt는 zkLogin wallet에 접근하는 데 필요하다. 이 값은 ZK proof 생성과 zkLogin address 도출 모두에 필수적이다.

user salt가 유출되어도 fund 손실을 의미하지는 않지만, 공격자가 subject identifier(예: sub)를 Sui address와 연결할 수 있게 된다. 이는 pairwise 또는 public subject identifier 사용 여부에 따라 문제가 될 수 있다. 특히 pairwise ID를 사용하는 경우(예: Facebook)에는 subject identifier가 각 RP에 대해 고유하므로 문제가 없다. 그러나 public reusable ID를 사용하는 경우(예: Google, Twitch)에는 전역적으로 고유한 sub 값이 사용자를 식별하는 데 쓰일 수 있다.

Ephemeral private key

ephemeral private key의 수명은 유효한 zero-knowledge proof를 생성하기 위해 nonce에 지정된 maximum epoch에 묶여 있다. 이를 잃어버려도 transaction 서명을 위해 새 ephemeral private key를 생성할 수 있으며, 새로운 nonce를 사용해 새로 생성한 zero-knowledge proof가 함께 제공된다. 하지만 ephemeral private key가 탈취되면 fund를 이동하려면 user salt와 유효한 zero-knowledge proof를 함께 획득해야 한다.

Proof

proof 자체를 획득하는 것만으로는 유효한 zkLogin transaction을 만들 수 없는데, transaction에 대한 ephemeral signature도 필요하기 때문이다.

Privacy

기본적으로 OAuth subject identifier(예: sub)와 Sui address 사이에는 연결이 없다. 이것이 user salt의 목적이다.

JWT는 기본적으로 온체인에 게시되지 않는다. 공개되는 값에는 iss, aud, kid가 포함되어 public input hash를 계산할 수 있고, sub 같은 민감한 field는 proof 생성 시 private input으로 사용된다.

ZK proving service와 salt service(운영되는 경우)는 user salt와 JWT를 알고 있으므로 사용자 identity를 연결할 수 있지만, 두 서비스는 설계상 stateless하다.

FAQ

What providers is zkLogin compatible with?

• zkLogin은 OAuth 2.0 framework 위에 구축된 OpenID Connect와 함께 동작하는 provider를 지원할 수 있다. 이는 OAuth 2.0 호환 provider의 일부이다. 활성화된 모든 provider는 latest table를 참조한다. 다른 호환 provider도 향후 protocol upgrade를 통해 활성화될 예정이다.

How is a zkLogin Wallet different from a traditional private key wallet?

• 전통적인 private key wallet은 mnemonic과 passphrase를 지속적으로 기억해야 하며 private key 탈취를 방지하기 위해 안전한 저장소가 필요하다. 반면 zkLogin wallet은 session expiry가 있는 ephemeral private key 저장소와 expiry가 있는 OAuth login flow만 필요하다. ephemeral key를 잊어도 fund 손실이 발생하지 않는데, 언제든 다시 sign in하여 새 ephemeral key와 새 ZK proof를 생성할 수 있기 때문이다.

How is zkLogin different from MPC or multisig wallets?

• Multi-Party Computation(MPC)와 다중 서명(multisig) wallet은 여러 key 또는 여러 key share를 분산 저장하고, signature를 수락하기 위한 threshold 값을 정의하는 방식에 의존한다. zkLogin은 어떤 개별 private key도 분할하지 않지만, OAuth provider로 인증할 때 fresh nonce를 사용해 ephemeral private key를 등록한다. zkLogin의 주된 장점은 MPC나 다중 서명 같은 private key management 기법으로도 persistent private key를 어디에서도 관리할 필요가 없다는 점이다. zkLogin은 첫 번째 요소가 OAuth account이고 두 번째 요소가 salt인 address용 2FA scheme으로 생각할 수 있다. 또한 Sui는 다중 서명 wallet을 네이티브로 지원하므로, k-of-N 설정에서 zkLogin 부분을 2FA로 사용하는 등 추가 보안을 위해 다중 서명 wallet 안에 하나 이상의 zkLogin signer를 포함할 수 있다.

If a OAuth account is compromised, what happens to the zkLogin address?

• zkLogin은 2FA 시스템이므로 OAuth account가 탈취되더라도 salt까지 별도로 탈취하지 않는 한 zkLogin address에 접근할 수 없다.

If you lose access to my OAuth account, do you lose access to the zkLogin address?

• 그렇다. zkLogin을 사용하려면 OAuth account에 login하고 현재의 JWT를 생성할 수 있어야 한다.

Does losing an OAuth credential mean the loss of funds in the zkLogin wallet?

• 잊어버린 OAuth credential은 일반적으로 해당 provider에서 비밀번호를 재설정해 복구할 수 있다. 불행히도 OAuth credential이 탈취된 경우 공격자는 user_salt가 여전히 필요하며, 어느 wallet이 사용되는지도 알아야 그 account를 탈취할 수 있다. 최신 user_salt provider는 유효하고 만료되지 않은 JWT를 제시하는 주체에게조차 user salt 제공을 막기 위한 추가 2FA 보안 조치를 둘 수도 있다. 또한 zkLogin address는 사용자 identity나 사용된 wallet에 대한 어떤 정보도 드러내지 않으므로, 블록체인만 모니터링해서 수행하는 표적 공격은 더 어렵다는 점도 중요하다. OAuth account에 대한 접근을 영구적으로 잃으면 해당 wallet에 대한 접근도 잃는다. 잃어버린 OAuth account 복구가 필요하다면, wallet provider는 네이티브 Sui 다중 서명 기능을 지원하고 backup method를 추가하는 것이 좋다. 예를 들어 첫 번째 요소는 Google이고 두 번째 요소는 Facebook OAuth인 1-of-2 다중 서명 zkLogin wallet처럼, 모든 signer가 zkLogin을 사용하는 다중 서명 wallet도 가능하다.

Canyou convert or merge a traditional private key wallet into a zkLogin one, or the reverse?

• 아니다. zkLogin wallet address는 private key address와 다르게 도출된다.

Does my zkLogin address ever change?

• zkLogin address는 sub, iss, aud, user_salt로부터 도출된다. 같은 OAuth provider로 같은 wallet에 login하면 JWT 자체는 매번 달라 보일 수 있어도 JWT의 sub, iss, aud, user_salt는 변하지 않으므로 address는 변하지 않는다. 그러나 다른 OAuth provider로 login하면 iss와 aud가 provider마다 다르게 정의되므로 address가 바뀐다. 추가로 각 wallet 또는 application은 자체 user_salt를 유지하므로, 같은 provider로 다른 wallet에 login해도 다른 address가 생길 수 있다.

Can you have multiple addresses with the same OAuth provider?

• 그렇다. 각 account에 대해 다른 wallet provider 또는 다른 user_salt를 사용하면 가능하다. 이는 서로 다른 account 간 fund를 분리하는 데 유용하다.