Ví MPC so với multisig

Cả ví MPC lẫn ví multisig đều hứa hẹn cùng một tiêu đề: không có điểm xâm phạm đơn lẻ nào. Cả hai đều thực hiện được lời hứa ấy. Nhưng chúng đi tới đó bằng những con đường khác nhau, và các con đường ấy dẫn tới những hệ quả khác nhau khi mọi chuyện hỏng bét — đó cũng là lúc duy nhất mà một mô hình bảo mật thực sự có ý nghĩa.

Bài này là cuộc đối đầu kỹ thuật. Nếu bạn muốn bức tranh rộng hơn về các lựa chọn tự lưu ký trước đã, so sánh các lựa chọn tự lưu ký bao quát toàn bộ, kể cả ví cứng và cụm từ khôi phục thuần túy.

Hai câu trả lời khác nhau cho cùng một bài toán

Bài toán được phát biểu giống nhau trong cả hai trường hợp: một bí mật duy nhất kiểm soát tất cả là điều không chấp nhận được, vậy hãy phân tán quyền.

MPC chia nhỏ khóa. Về mặt khái niệm có một khóa riêng tư, nhưng nó không bao giờ được ráp lại ở đâu cả. Thay vào đó, các phần của nó nằm ở những nơi khác nhau, và một giao thức mật mã cho phép các phần ấy phối hợp tạo ra chữ ký mà không bên nào biết được toàn bộ khóa.

Multisig đòi hỏi nhiều khóa. Ở đây thực sự có vài khóa riêng tư độc lập. Địa chỉ mã hóa một quy tắc — chừng này trong số các khóa này phải ký — và blockchain cưỡng chế quy tắc ấy khi xác thực giao dịch.

Sự phân biệt nghe có vẻ hàn lâm. Không phải vậy. Một bên là sự thật về mật mã học; bên kia là sự thật về blockchain. Điều mà chuỗi biết sẽ quyết định chuyện gì xảy ra khi một mảnh của hệ thống gãy.

MPC thực sự hoạt động ra sao

MPC — tính toán đa bên, trong ngữ cảnh này thường là các lược đồ chữ ký ngưỡng — cho phép nhiều bên cùng tính ra một chữ ký trên một thông điệp trong khi mỗi bên chỉ giữ một phần của khóa ký. NIST duy trì một dự án mật mã ngưỡng nếu bạn muốn cách trình bày hình thức.

Đầu ra là một chữ ký đơn lẻ, hết sức bình thường. Trên chuỗi, giao dịch của một ví MPC không thể phân biệt với giao dịch do một người ký bằng một khóa. Điều đó có những ưu thế thật: nó chạy trên mọi chuỗi, tốn kém bằng một giao dịch chữ ký đơn, và không tiết lộ gì về bố trí bảo mật của bạn cho ai đang quan sát chuỗi.

Hệ quả của chính đặc tính ấy là nơi cần thận trọng. Vì chuỗi thấy một chữ ký bình thường, chuỗi cũng chẳng cưỡng chế gì về chính sách của bạn. Có bao nhiêu phần, ai giữ chúng, và bao nhiêu phần phải phối hợp — đó là những sự thật về phần mềm và máy chủ, không phải về sổ cái. Đổi phần mềm là đổi chính sách.

Điều thứ hai cần nhìn kỹ là việc giữ các phần. Nhiều ví MPC dành cho người dùng phổ thông giữ một phần trên hạ tầng của nhà cung cấp. Đó thường chính là thứ khiến trải nghiệm khôi phục trơn tru trở nên khả thi — và cũng có nghĩa là sự tồn tại và hợp tác liên tục của nhà cung cấp là bộ phận chịu lực trong thiết lập của bạn. Một số thiết kế giảm nhẹ điều này rất tốt, với các phần xuất được ra ngoài hoặc lối sao lưu độc lập. Câu hỏi không phải là MPC có thể làm tốt hay không; mà là sản phẩm cụ thể bạn đang cân nhắc đã làm theo cách bạn kiểm chứng được hay chưa.

Multisig thực sự hoạt động ra sao

Trong multisig, chính sách là một phần của địa chỉ. Trên Bitcoin và các chuỗi UTXO khác, địa chỉ được dẫn xuất từ một script nêu tên các khóa công khai và ngưỡng; một lệnh chi tiêu không mang đủ chữ ký hợp lệ đơn giản là vô hiệu, và mọi nút trên mạng đều từ chối nó. Trên các chuỗi có hợp đồng thông minh, tương đương là một tài khoản mà mã của nó sẽ không hành động nếu thiếu các phê duyệt bắt buộc.

Không ai cần được tin cậy để áp dụng quy tắc, bởi áp dụng quy tắc chính là việc mà mạng lưới làm. Nếu ngày mai mọi phần mềm ví liên quan biến mất, quy tắc vẫn đứng vững, và bất kỳ ai có các khóa cùng một công cụ tương thích vẫn chi tiêu được.

Cái giá cũng là thật. Bạn quản lý nhiều khóa thay vì một, việc sao lưu phức tạp hơn, và giao dịch cồng kềnh hơn — trên Bitcoin, nhiều chữ ký hơn nghĩa là nhiều byte hơn và phí cao hơn chút ít. Chính sách của bạn cũng lộ ra trên chuỗi, đó là một cân nhắc về quyền riêng tư: người quan sát có thể thấy một địa chỉ là 2-trên-3 dù không thấy ai giữ cái gì.

Multisig là gì và vì sao nó quan trọng bàn về mô hình sâu hơn.

SSP đứng chính xác ở đâu

SSP là multisig 2-trên-2, nhưng sự trung thực đòi hỏi một chi tiết ở đây, bởi cách triển khai không giống hệt nhau trên mọi chuỗi.

Trên Bitcoin và các chuỗi UTXO khác, đó là multisig nguyên bản ở mức script qua BIP-48. Hai khóa, một script, do đồng thuận cưỡng chế.

Trên Ethereum và các chuỗi EVM khác không có script nguyên bản tương đương, nên SSP dùng một tài khoản thông minh xác minh chữ ký Schnorr đã tổng hợp tạo ra từ cả hai khóa. Hai thiết bị của bạn chạy một giao thức kiểu MuSig2, và chuỗi thấy một chữ ký — về mặt cơ chế, hình dạng ấy gần với MPC hơn là với một script multisig của Bitcoin.

Sự phân biệt có ý nghĩa không phải là "tổng hợp hay không". Mà là hai sự thật sau, đúng trên mọi chuỗi mà SSP hỗ trợ:

• Cả hai khóa đều được sinh ra trên thiết bị của bạn và chỉ bạn giữ. SSP không giữ phần nào, khóa nào, hay bí mật cục bộ nào. Trên máy chủ của chúng tôi không có phần nào để mất, để bị trưng thu, hay để bị giữ làm con tin.
• Yêu cầu ấy nằm trên chuỗi. Trên EVM, mã của tài khoản thông minh sẽ không cấp phép cho giao dịch nếu thiếu chữ ký mà chỉ hai khóa của bạn mới tạo ra được. Mã đó đã triển khai, công khai và được kiểm toán — nó không phải chính sách mà phần mềm của chúng tôi chọn áp dụng.

Trên Solana, đó là chương trình on-chain không có người tạo và không có khóa quản trị, nơi địa chỉ kho tự nó là dấu vân tay của tập thành viên và ngưỡng. Cơ chế khác, bảo đảm như nhau.

Nếu bạn quan tâm tới mật mã học của việc tổng hợp, chữ ký Schnorr và tổng hợp multisig giải thích vì sao một chữ ký lại có thể đòi hai khóa.

Các kiểu hỏng đặt cạnh nhau

So sánh mô hình bảo mật tốt nhất là bằng cách hỏi cái gì gãy.

Một thiết bị bị xâm phạm. Cả hai mô hình đều trụ được. Kẻ tấn công có một phần hoặc một khóa và không thể tự ký.

Nhà cung cấp biến mất. Multisig trụ được — chỉ cần các khóa và quy tắc trên chuỗi. MPC chỉ trụ được nếu bạn có thể lấy và dùng các phần của mình mà không cần phần mềm của nhà cung cấp, và điều đó hoàn toàn phụ thuộc vào thiết kế.

Nhà cung cấp bị buộc phải hành động. Nếu nhà cung cấp giữ một phần, phần ấy về nguyên tắc có thể bị buộc phải giao nộp theo pháp luật, và tùy lược đồ, cộng thêm một phần khác là đủ để dịch chuyển tiền. Nếu nhà cung cấp không giữ gì — như ở SSP, nơi cả hai khóa đều của bạn — thì chẳng có gì để cưỡng ép.

Bạn mất một khóa hay một phần. Điều này phụ thuộc vào ngưỡng, không phải công nghệ. Một thiết lập 2-trên-3 thuộc bất kỳ loại nào cũng chịu được một mất mát; một thiết lập 2-trên-2 thuộc bất kỳ loại nào cũng không. Chuyện gì xảy ra nếu một khóa của bạn bị xâm phạm đi qua riêng trường hợp SSP.

Phần mềm ví nói dối bạn về thứ bạn đang ký. Ở đây không mô hình nào cứu được, và điều này đáng nói thẳng. Phân tán quyền bảo vệ trước một khóa bị đánh cắp; nó không bảo vệ trước việc phê duyệt nhầm giao dịch. Vì thế câu hỏi đáng quan tâm với cả hai mô hình là: thiết bị của bạn kiểm tra độc lập những gì trước khi ký — giải mã giao dịch thô thay vì tin vào mô tả của một máy chủ.

Mỗi bên thắng ở đâu

MPC thắng trên những chuỗi thiếu nguyên hàm multisig tốt, thắng ở kích thước giao dịch và phí, ở quyền riêng tư của bố trí, và thường thắng ở trải nghiệm người dùng — nhất là khâu khôi phục, nơi một sản phẩm MPC thiết kế tốt có thể thân thiện hơn hẳn so với việc xoay xở với nhiều bản sao lưu cụm từ.

Multisig thắng ở khả năng kiểm chứng. Quy tắc nằm trong sổ cái. Bạn không phải tin vào một lời mô tả mô hình bảo mật; bạn có thể đọc địa chỉ hoặc hợp đồng và thấy chính sách. Nó cũng thắng ở tính độc lập: một thiết lập multisig với các khóa do bạn giữ hoàn toàn không có công ty nào trong mô hình tin cậy của nó.

Chẳng có gì mâu thuẫn khi ưa những câu trả lời khác nhau cho những mục đích khác nhau. Một số dư nhỏ dùng hằng ngày trong một ví MPC được xây tử tế, cùng một khoản nắm giữ dài hạn trong multisig với các khóa cất riêng, là một bố trí hoàn toàn mạch lạc.

Cần hỏi gì trước khi cam kết

Dù bạn nghiêng về bên nào, bốn câu hỏi sau tách một triển khai vững khỏi một triển khai yếu.

1. Ai giữ từng khóa hay từng phần, và tôi có lấy được tất cả không? Nếu câu trả lời thành thật có chứa "nhà cung cấp, và không", bạn đã chọn một mô hình có đối tác.
2. Chuyện gì xảy ra nếu ngày mai nhà cung cấp biến mất? Phải có một lối đi được ghi chép rõ mà không cần đến họ. Hãy thử nó trước khi bạn cần đến.
3. Chính sách sống ở đâu? Trong một script hay hợp đồng trên chuỗi, hay trong phần mềm? Cả hai đều có thể ổn, nhưng chỉ một thứ sống sót qua việc phần mềm thay đổi.
4. Mỗi thiết bị kiểm tra gì trước khi ký? Một khóa thứ hai chẳng thêm được gì nếu cả hai thiết bị đều ký mù bất cứ thứ gì máy chủ gửi tới. Các kiểu hỏng của multisig và cách SSP giảm nhẹ chúng đi qua điều này cùng những cách khác mà một thiết lập nhiều khóa có thể bị phá hoại trong thực tế.

Nếu bạn muốn mô hình mà SSP dựng nên được giải thích từ đầu, hãy bắt đầu với multisig 2-trên-2 là gì. Và nếu nỗi lo đưa bạn tới đây là mất một khóa chứ không phải mất quyền kiểm soát một khóa, khôi phục xã hội so với multisig bàn về họ câu trả lời còn lại.