빌더를 위한 zkLogin 모범 사례 및 비즈니스 고려 사항

소금 관리를 포함한 주요 이슈를 앱에 통합하기 전에 검토해야 할 사항

빌더를 위한 zkLogin 모범 사례 및 비즈니스 고려 사항

이번 주 메인넷( Sui )에서 zkLogin이 출시되면 빌더는 사용자에게 앱에 대한 간편한 계정 생성을 제공할 수 있습니다. 새로운 기술을 통합할 때와 마찬가지로, 빌더는 위험을 완화하고 성공을 최적화하기 위해 고려해야 할 중요한 주제가 많이 있습니다.  

이 블로그에서는 이러한 고려 사항 중 몇 가지를 간략하게 설명하고 zkLogin 문서에서 제공되는 명시적인 지침을 강조합니다.

zkLogin은 셀프 커스터디 주소만 제공합니다.

사용자 친화적인 온보딩 기능을 갖춘 대부분의 Web3 솔루션은 관리 제공업체에서 제공합니다. 이러한 공급업체는 사용자의 개인 키를 관리하고 사용자가 비밀번호를 잊어버린 경우 익숙한 복구 경로를 제공합니다. 이러한 솔루션은 자산 커스터디에 필요한 규제 의무를 충족하고자 하는 기업에게는 적합하지만, 많은 빌더는 이러한 프로세스를 수행할 시간과 예산이 없습니다.

이것이 바로 zkLogin이 필요한 이유입니다. 프리미티브의 셀프 커스터디 경로는 규제 부담을 줄이고 간단한 로그온을 위한 시장 출시 시간을 단축합니다. 하지만 각 빌더는 사용자가 셀프 커스터디를 얼마나 편안하게 생각하는지, 그리고 zkLogin이 모든 사용자, 일부 사용자 또는 전혀 사용자에게 적합한지 고려해야 한다는 과제를 안고 있습니다. 이러한 이해는 빌더가 zkLogin과 함께 통합할 수 있는 다른 계정 생성 및 키 관리 시스템(있는 경우)을 결정하는 데 도움이 됩니다.

웹 자격 증명을 오프체인에 보관해야 합니다.

zkLogin은 현재 사용 가능한 최고의 암호화 방식을 사용하여 온체인 주소가 자격증명 공급자를 포함하여 웹 자격증명으로 직접 연결될 수 없도록 합니다. 예를 들어, Google 계정을 사용하여 Sui 주소를 생성하는 경우 Google은 이 사실을 전혀 알 수 없으며 해당 주소를 회원님과 연결할 수 없습니다. 이러한 설계는 의도적이며 매우 중요한데, 특히 자격증명 제공업체가 준수해야 하는 글로벌 개인정보 보호법(예: 유럽의 GDPR 및 미국의 CCA)이 있기 때문입니다. 앱 빌더는 무엇보다도 어떤 사용자 정보를 누구와 공유할 수 있는지, 사용자 데이터를 저장, 보호 및 삭제할 의무를 규정하는 여러 개인정보 보호법을 숙지해야 합니다.

zkLogin을 구현할 때 빌더는 종종 사용자의 온체인 주소를 생성하기 위해 서브(사용자의 고유 영숫자 식별자) 또는 실제 웹 자격증명(예: 이메일 주소)을 사용하도록 선택할 수 있습니다. 온체인 계정 파생 문제를 신원 또는 검색 문제(예: 사용자가 서로 상호작용할 수 있는 더 접근하기 쉬운 방법)와 분리하는 것이 좋습니다. 사용자는 자신의 정보가 온체인 주소에 비가역적으로 저장되는 것을 원하지 않을 수도, 기대하지도, 이득을 얻지 못할 수도 있습니다. 이러한 위험을 완화하는 데 도움이 되는 한 가지 옵션은 이름 서비스(도메인 URL과 같은)를 사용자의 신원 계층으로 사용하는 것입니다.

프로버 및 소금 관리는 개인 정보 보호에 민감합니다.

Sui 문서에는 zkLogin이 주소를 생성하는 방법에 대한 자세한 개요가 나와 있습니다. 요약하자면, 사용자는 OAuth 웹 계정으로 로그인하여 JSON 웹 토큰(JWT)을 생성합니다. 그런 다음 애플리케이션은 JWT와 솔트 (무작위 데이터에 대한 일반적인 암호화 용어)를 영지식(zk) 증명 생성기에 제공하고, 이 증명은 Sui 에서 트랜잭션의 일부로 포함됩니다. 이 흐름은 웹 계정 정보가 온체인에서 절대 보이지 않도록 합니다.

빌더는 자체 증명자 및 소금 관리 솔루션을 실행하거나 타사 솔루션을 사용할 수 있습니다. Zk에 능숙한 빌더는 공개적으로 사용 가능한 공통 참조 문자열을 사용하여 처음부터 자체 증명자를 구축할 수도 있습니다.

증명자를 운영하고 솔트를 관리하는 것은 개인정보 보호에 민감한 작업입니다. 이러한 서비스를 수행하는 모든 주체는 원칙적으로 이 정보가 온체인에 표시되지 않더라도 웹 자격 증명을 Sui 주소에 연결할 수 있습니다. 개인정보 보호에 민감한 애플리케이션(예: 사용자가 고가의 자산이나 금액을 저장할 가능성이 높은 애플리케이션)을 구축하는 경우, 제3자에 의존하기보다는 자체 증명자를 운영하고 자체적으로 솔트를 관리하는 것을 고려하는 것이 좋습니다.

타사 서비스를 사용할 때는 제품, 타사 서비스 사용에 대한 적절한 거버넌스(자체 비즈니스 정책에 따라)를 운영하고 사용자에게 공개하는 것과 관련된 관련 법률을 준수해야 합니다.

소금 관리 트레이드 오프

염분 관리 체계를 선택하는 것은 zkLogin 빌더가 내려야 하는 가장 중요한 결정 중 하나입니다. zkLogin 문서에는 소금 관리를 위한 몇 가지 옵션이 설명되어 있으며, 각 옵션은 편의성, 보안 및 복구 가능성 측면에서 장단점이 있습니다. 크게 두 가지 접근 방식이 있습니다: SSO 스타일과 비밀번호 스타일.

접근 방식

작동 방식

장점

단점

완화

SSO

앱이 사용자의 소금을 관리합니다.

Web3 비원주민을 위한 익숙한 경험

웹 인증정보가 유출되면 자산 손실로 이어질 수 있습니다.

사용자에게 웹 자격 증명을 위해 2단계 또는 다중 인증(2FA 또는 MFA)을 사용하도록 권장합니다.

및/또는

애플리케이션 내부에서 2단계 인증 활성화

비밀번호

사용자가 처음 로그인할 때 솔트를 입력합니다.

웹 인증정보가 유출되더라도 소금도 유출되지 않는 한 자산이 위험에 노출되지는 않습니다.

온보딩 프로세스에 소량의 마찰을 다시 추가합니다.


사용자가 유출에 취약한 간단한 솔트를 만들 수 있습니다.


소금을 잊어버리면 사용자가 자산에 접근할 수 없습니다.

잠금 방지를 위해 사용자 백업을 강력히 권장합니다.

빌더는 사용자를 허용하는 것과 악의적인 사용자가 자산에 액세스하는 것을 방지하는 것 사이에 상당한 긴장이 존재합니다. 모든 빌더는 편의성과 보안 사이의 스펙트럼에서 앱에 적합한 위치를 찾아야 합니다. 어떤 경로를 채택하든, zkLogin을 사용하는 빌더는 항상 사용자에게 모든 해당 정보를 공개해야 합니다.

모두를 위한 더 나은 인터넷을 구축합시다

블록체인이 모든 사람에게 획기적인 경험을 제공할 때가 되었으며, Sui 의 빌더들은 광범위한 사용자에게 서비스를 제공할 준비가 되어 있습니다. 약 1억 개의 블록체인 주소와 40억 개 이상의 웹 계정이 존재합니다. zkLogin은 블록체인을 주류 사용자에게 제공하는 데 있어 중요한 단계입니다. 이 기능을 잘 고려한 방식으로 구현하면 Sui 이 다음 10억 명의 사용자에게 최고의 경험을 제공할 수 있을 것입니다.