Thảo luận về cấu trúc tài khoản: Tại sao hệ thống ba chìa khóa là giải pháp lý tưởng?
Tác giả gốc: Norswap
Biên soạn gốc: Deep Chao TechFlow
Tôi đã suy nghĩ rất nhiều về ví và quá trình giới thiệu người dùng cho 0x Fable. Dưới đây là một số ý kiến của tôi. Chúng ta sẽ thảo luận:
Cấu trúc tài khoản lý tưởng của tôi;
Cân nhắc về Bảo mật;
Tổng quan về các nhà cung cấp đăng nhập Web3 hiện có,
Rõ ràng, không nên yêu cầu người dùng cài đặt phần mềm ví và lưu các cụm từ ghi nhớ trong quá trình giới thiệu. Chúng ta cần một cách tiếp cận thân thiện, tương đối an toàn và có phần hướng tới tương lai.
Ngành kiến trúc
Mỗi người dùng có Tài khoản thông minh của riêng mình, trong đó có ba khóa:
Khóa thiết bị - Ban đầu có thể được lưu trữ cục bộ, nhưng hy vọng trong tương lai, mật khẩu/webauthn sẽ được sử dụng.
Các khóa bổ sung, chẳng hạn như các khóa do nhà cung cấp kiểm soát và được mở khóa thông qua đăng nhập mạng xã hội.
Sao lưu khóa, ví dụ: với bên thứ ba (có thể đơn giản là dưới dạng tệp đính kèm email hoặc trên Dropbox/Google Drive).
Nếu điều này nghe có vẻ công nghệ thấp hoặc không an toàn, tôi e rằng bạn đã bị lừa bởi lời nói ngọt ngào của nhà cung cấp, bởi vì thực tế họ không an toàn hơn thế (thậm chí còn ít hơn nhiều lần - ví dụ: chìa khóa (2) và (3) ) ) được kiểm soát bởi cùng một bên).
Trong thiết lập này, bạn có thể sử dụng phím thiết bị để hoạt động mà không cần sự tương tác của người dùng. Đối với chuyển khoản và giao dịch liên quan đến tài sản, bạn có thể yêu cầu sử dụng khóa bổ sung.
Mẫu đơn giản là yêu cầu người dùng đăng nhập bằng Google/Apple/Facebook, v.v. rồi thêm lời nhắc xác nhận. Điều này làm cho việc bắt đầu trở nên dễ dàng. Tuy nhiên, nếu người dùng yêu cầu bảo mật hơn, khóa này có thể được thay thế bằng EOA truyền thống. Ngoài ra, bất kỳ cặp khóa nào cũng có thể được sử dụng để thay thế khóa dự phòng, khóa này chỉ cần là một tệp được lưu trữ trên đám mây.
phân tích bảo mật
Điều này an toàn đến mức nào? Phần lớn, anh ấy an toàn. Hai thiết bị hoặc thực thể phải bị xâm phạm cùng một lúc thì việc mất tiền có thể xảy ra.
Vấn đề chính là có một số rủi ro về cấu hình có thể làm giảm tính bảo mật. Ví dụ: Lưu trữ các khóa dự phòng trên Google Drive trong khi gán các khóa bổ sung cho tài khoản Google của bạn. Hoặc sử dụng ví nóng làm khóa bổ sung, điều này tiềm ẩn những rủi ro tương tự như khóa thiết bị. Người dùng có thể mất bản sao lưu của mình. Tốt hơn hết bạn nên định kỳ nhắc người dùng xoay phím của thiết bị, buộc họ phải tìm khóa dự phòng.
Nếu key dự phòng được lưu trữ công khai cũng rất dễ bị đánh cắp. Điều này thậm chí còn tệ hơn ví nóng, vốn mã hóa khóa trên đĩa (và yêu cầu giải mã mật khẩu trong bộ nhớ). Bất chấp điều đó, việc bổ sung khóa mật mã (cho phép bạn đăng nhập vào ứng dụng bằng xác thực thiết bị) sẽ giải quyết được vấn đề này.
Hiểu rằng đăng nhập mạng xã hội có nghĩa là tin tưởng vào nhà cung cấp. Về cơ bản, nhà cung cấp có một khóa mà họ có thể sử dụng theo cách họ muốn, nhưng họ hứa với bạn rằng họ sẽ chỉ sử dụng nó theo yêu cầu của bạn sau khi bạn đăng nhập bằng tài khoản xã hội của mình. Cuối cùng, xin lưu ý rằng khi khóa bổ sung được cung cấp bởi người tạo dapp hoặc không có lời nhắc xác nhận thì người tạo dapp rất dễ lừa dối người dùng (vì họ đã viết giao diện người dùng sở hữu khóa thiết bị và sở hữu hoặc có quyền kiểm soát khóa bổ sung).
Tổng quan về các nhà cung cấp hiện có
Ai cung cấp điều này ngày hôm nay? Theo như tôi biết thì không. Vấn đề thường là không có khóa dự phòng hoặc nó được giữ bởi cùng một thực thể (ví dụ: ví Coinbase).
Thị trường chủ yếu được chia thành hai loại:
Các nhà cung cấp cung cấp giải pháp đa khóa tích hợp sử dụng tài khoản thông minh hoặc sử dụng MPC (tính toán nhiều bên, kỹ thuật mã hóa) để kết hợp nhiều khóa thành một EOA duy nhất.
Nhà cung cấp cấp thấp hơn giữ khóa người dùng cho bạn và cho phép họ đăng nhập sau khi đăng nhập.
Có rất nhiều nhà cung cấp full-stack: Particle Network, Privy, Alembic Tech, Magic, Web3 Auth, Turnkey, Dynamic, 0x Pass, Fireblocks, Portal, Capsule, ZeroDev, Keyp, Circle Developers.
Những người giám sát chính như: Lit Protocol, Amazon.
Vâng, có rất nhiều điều đó. Về cơ bản không có sự khác biệt giữa chúng. Khi mô hình kinh doanh minh bạch, các mô hình này thường tính phí từ 0,02 đến 0,05 USD cho mỗi người dùng mỗi năm. Đối với tôi, điều này có vẻ khá hợp lý.
Điều thú vị là tất cả những thứ này đều được định vị là công cụ phát triển. Dường như không có công ty nào đang cố gắng áp dụng những công nghệ này để trở thành ví chính cho người dùng.
Tất nhiên, để hoạt động với các dapp hiện có, bạn cần cài đặt phần mềm ví. Vì vậy, lợi ích của hệ thống bị giảm đi khi loại bỏ cụm từ ghi nhớ. Nhưng bạn cũng có thể để các dapp quảng bá bạn như một cách dễ dàng nhất để bắt đầu (thậm chí không cần cài đặt phần mềm ví nếu họ tích hợp với bạn). Bạn có được người dùng và dapp có thể dễ dàng bắt đầu miễn phí. Thắng-thắng.
Mối lo ngại về nhà cung cấp
Ngoài việc không triển khai kiến trúc lý tưởng của tôi, các giải pháp này thường đưa ra các yếu tố tập trung lớn, như API REST hoặc một số tính toán MPC mà bạn sẽ không thể tự thực hiện nếu chúng ngừng hoạt động (hoặc thậm chí được phát hành công khai? Đã xem xét chưa? ).
Không rõ điều gì sẽ xảy ra nếu bạn ngừng làm việc với nhà cung cấp. Họ có (một phần) khóa người dùng của bạn! Điều này rất giống với mối quan tâm của tôi về Rollups-as-a-service.
Sau đó, một người sáng lập RaaS đã nói với tôi rằng có sự đánh đổi giữa việc cho phép thoát dễ dàng và ngăn người sáng lập lừa dối người dùng của họ (điều này sẽ có tác động xấu đến RaaS).
Dưới đây là cách dễ dàng chuyển đổi nhà cung cấp bằng cách sử dụng kiến trúc trên: Người dùng gửi hàm băm của tài khoản xã hội của họ trên chuỗi (ví dụ: gavin@hooli.xyz). Mỗi nhà cung cấp dịch vụ đăng nhập xã hội đều có khóa riêng (không cần thiết phải có khóa riêng cho mỗi người dùng và thường không an toàn hơn). Tài khoản thông minh tham chiếu một hợp đồng đơn lẻ chứa tài khoản của nhà cung cấp hiện tại. Chuyển đổi nhà cung cấp cũng dễ dàng như thay đổi tài khoản này.
suy nghĩ cuối cùng
Rõ ràng là chúng tôi đang hướng tới mục tiêu Giới thiệu lý tưởng. Lý tưởng nhất là những ví dễ truy cập này có mối quan hệ trực tiếp với người dùng của chúng. Sau đó, Dapp có thể bỏ qua hoàn toàn vấn đề này và chỉ cần ký hợp tác với ví để xác định ví đăng nhập mặc định là ai.
Nếu không, giải pháp của tôi sẽ là triển khai hệ thống của riêng mình - sẽ không khó để tạo nhà cung cấp thông tin đăng nhập xã hội của riêng tôi trong kiến trúc trên. Tuy nhiên, tôi thà sử dụng nhà cung cấp bên ngoài. Như đã đề cập ở trên, nếu người tạo dapp kiểm soát các khóa miễn phí thì hệ thống sẽ không được phân quyền hoàn toàn.


