Hiểu về thanh toán im lặng (Phần 2)

Tác giả: benma & Sebastian

Nguồn: https://blog.bitbox.swiss/en/understanding-silent-payments-part-two/

Xem phần trước tại đây

Trong bài viết trước, chúng tôi đã học về các nền tảng kỹ thuật của thanh toán âm thầm. Giờ đây, hãy đến gần hơn để xem thanh toán âm thầm hoạt động như thế nào trong các thiết bị ký (như BitBox).

Chúng tôi rất khuyến khích đọc bài viết trước trong loạt bài này, bởi vì bài viết này được xây dựng dựa trên kiến thức đã được trình bày trong bài viết trước, cụ thể là về tính chất của private key và public key cũng như cách thức hoạt động của thanh toán âm thầm. Giống như bài viết trước, trong bài viết này, chúng tôi cũng sử dụng chữ thường để đại diện cho private key và chữ hoa để đại diện cho public key. Ví dụ:A = a × G .

Để ôn lại, khi Alice muốn gửi một khoản thanh toán âm thầm cho Bob, đầu ra giao dịch được chỉ định cho Bob được phát sinh động từ địa chỉ thanh toán âm thầm của Bob và private key của Alice:

P = B_spend + hash(input_hash × S) × G

Trong đó S là giá trị bí mật được chia sẻ giữa Alice và Bob. Thiết bị ký của Alice có thể tính toán nó bằng private key của mình a và public key của Bob B_scan:

S = a x B_scan

Ở đây, B_spend và B_scan mà Alice sử dụng đều được lấy từ địa chỉ thanh toán âm thầm của Bob, và a là tổng của các private key của tất cả các đầu vào của giao dịch này.

Tạo và ký giao dịch

Điều đầu tiên chúng ta cần hiểu là, thanh toán âm thầm đã thay đổi rất lớn vai trò của thiết bị ký trong việc xử lý giao dịch Bitcoin.

Trong các hình thức thanh toán trước đây, ví chủ (phần mềm trên máy tính hoặc điện thoại của bạn, như BitBoxApp) tạo giao dịch, còn thiết bị ký (như BitBox02 của bạn) chỉ xác minh và ký nó (cấp phép).

Nhưng với thanh toán âm thầm, mọi thứ khác đi. Thiết bị ký không chỉ chịu trách nhiệm ký, mà còn phải tạo một phần của giao dịch, cụ thể là đầu ra giao dịch cho Bob. Điều này là do việc tạo đầu ra giao dịch cho Bob yêu cầu private key của Alice, và chỉ có thiết bị ký của cô ấy mới biết những private key này.

Sự chuyển đổi mẫu này mang lại một số rủi ro mới:

• Hỏng bộ nhớ: Nếu thiết bị ký có lỗi hoặc sự cố bộ nhớ, nó có thể tạo ra đầu ra không chính xác, do đó gửi tiền đến địa chỉ không thể chi tiêu, về cơ bản là mất tiền.
• Hành vi độc hại: Nếu thiết bị ký bị xâm phạm, nó có thể tạo ra một đầu ra trực tiếp gửi đến kẻ tấn công (thay vì Bob) mà ví chủ không để ý.

Vấn đề này có thể được giải quyết một cách tinh tế bằng cách để ví chủ xác minh tính chính xác của đầu ra thanh toán âm thầm do thiết bị ký tạo ra. Về mặt khái niệm, điều này tương tự như "anti-klepto" - một trường hợp khác yêu cầu ví chủ xác minh rằng thiết bị ký không có hành vi xấu.

Bằng chứng bằng chứng số rời rạc

Vậy, làm thế nào để ví chủ xác minh rằng đầu ra thanh toán âm thầm do thiết bị ký tạo ra là chính xác?

Ví chủ không thể trực tiếp xác minh nó, vì ví chủ không thể tự tạo lại đầu ra thanh toán âm thầm. Điều này đòi hỏi hoặc private key của Alice a, hoặc private key của Bob b_scan, để tính toán giá trị bí mật được chia sẻ S, nhưng ví chủ không thể có được bất kỳ cái nào.

Ngược lại, chúng ta sử dụng một công cụ mật mã để cho phép ví chủ xác minh đầu ra thanh toán âm thầm do thiết bị ký tạo ra, được gọi là "bằng chứng bằng chứng số rời rạc (DLEQ)".

Một bằng chứng bằng chứng số rời rạc cho phép bạn chứng minh rằng cùng một private key a được sử dụng để tạo ra hai public key khác nhau, mặc dù hai public key này được tạo thông qua các "điểm bắt đầu" (còn được gọi là "điểm cơ sở") khác nhau.

Public key đầu tiên là A1 = a x G, trong đó G là điểm cơ sở (sinh) thông thường. Public key thứ hai là A2 = a x P2, trong đó P2 là một điểm cơ sở khác. Bằng chứng đảm bảo rằng cả hai public key này đều xuất phát từ cùng một private key a, mà không cần tiết lộ chính private key đó cho người xác minh.

Nói một cách dễ hiểu, bạn chứng minh rằng mặc dù hai public key này được tạo thông qua các điểm cơ sở khác nhau (G và P2), nhưng chúng đều sử dụng cùng một giá trị bí mật (private key a).

Về mặt kỹ thuật, bằng chứng này cho thấy logarit rời rạc của public key A1 đối với cơ sở G và logarit rời rạc của public key A2 đối với cơ sở P2 là như nhau.

Xác minh tính chính xác

Giao thức cho phép ví chủ xác minh tính chính xác của đầu ra thanh toán âm thầm như sau:

Thiết bị ký tạo đầu ra thanh toán âm thầm, cùng với một bằng chứng DLEQ, chứng minh rằng cùng một giá trị bí mật (private key a) được sử dụng trong public key A = a x G và giá trị bí mật được chia sẻ S = a x B_scan.

• Bởi vì A và S đều được phát sinh từ cùng một private key a, nên bằng chứng DLEQ đảm bảo rằng giá trị bí mật của public key S cũng được tạo bằng private key của Alice.

Thiết bị ký gửi đầu ra thanh toán P do chính nó tạo ra, cùng với giá trị bí mật được chia sẻ S và bằng chứng DLEQ cho ví chủ.

Ví chủ sử dụng ba thứ sau để xác minh bằng chứng DLEQ:

1. Public key A, là tổng của các public key của tất cả các đầu vào giao dịch mà Alice sẽ gửi;
2. B_scan từ địa chỉ thanh toán âm thầm, và
3. S, được cung cấp bởi thiết bị ký

• Nếu bằng chứng vượt qua kiểm tra, ví chủ có thể tin chắc rằng S được tính toán chính xác từ a x B_scan, ngay cả khi ví chủ không biết private key a.

Bây giờ, ví chủ có thể xác minh đầu ra thanh toán âm thầm thông qua việc tính toán lại độc lập:

P = B_spend + hash(input_hash × S) × G

Để làm điều này, ví chủ cần lấy B_spend từ địa chỉ thanh toán âm thầm của Bob, tính toán độc lập input_hash từ các đầu vào giao dịch, và nhận S từ thiết bị ký (đã được xác minh trong bước trước).

• Nếu các đầu ra thanh toán im lặng được tính toán lại khớp với các đầu ra do trình ký số cứng trả về, thì ví chính có thể an toàn kết thúc và phát sóng giao dịch, vì nó biết các đầu ra thanh toán im lặng là chính xác và không bị thay đổi.

Tóm tắt quy trình

• Trình ký số cứng của Alice tạo các đầu ra thanh toán im lặng và sử dụng bằng chứng DLEQ để chứng minh mình đang sử dụng private key chính xác.
• Ví chính xác minh bằng chứng để đảm bảo giá trị bí mật được chia sẻ được tính toán chính xác.
• Ví chính sử dụng giá trị bí mật được chia sẻ và các đầu ra đã biết từ giao dịch, tính toán lại và xác minh các đầu ra thanh toán im lặng; nếu tất cả các kiểm tra đều thông qua, giao dịch sẽ được hoàn tất.

Phương pháp này thể hiện rằng trình ký số cứng không thể thực hiện các hành động xấu, cho dù là do hư hỏng phần cứng hay hoạt động độc hại.

Ra mắt

Các tính năng đảm bảo tính an toàn của thanh toán im lặng, bao gồm việc triển khai các kiểm tra tính chính xác được mô tả trong bài viết này trong BitBoxApp, sẽ được phát hành trong phiên bản 4.45 của BitBoxApp và phiên bản firmware BitBox 9.21.

BitBox02 là trình ký số cứng đầu tiên hỗ trợ gửi thanh toán im lặng. Nếu toàn bộ hệ sinh thái không hỗ trợ gửi thanh toán im lặng, việc thuyết phục các ví, sàn giao dịch, dịch vụ khác hỗ trợ thanh toán im lặng sẽ rất khó. Đây là vấn đề về việc gà sinh trứng, trứng sinh gà. Chúng tôi hy vọng có thể giúp thanh toán im lặng được áp dụng bằng cách này.

Cảm ơn sự hợp tác mã nguồn mở

Chúng tôi lần đầu tiên nghe về thanh toán im lặng tại hội nghị BTC Azores vào năm 2023, từ các bài thuyết trình của tác giả BIP josibake và Ruben Somsen. BIP này đã nhận được rất nhiều đánh giá chất lượng cao.

Khi bắt đầu soạn thảo việc triển khai trong BitBox02, tôi bắt đầu suy nghĩ về các rủi ro đã đề cập ở trên và đã đăng một tweet liệt kê những lo ngại của mình. Josie, Ruben và Andrew Toth đã chỉ ra rằng bằng chứng DLEQ là một giải pháp khả thi và cung cấp cho tôi một số tài liệu đọc rất hữu ích về chủ đề này. Mảnh ghép duy nhất còn thiếu là một triển khai DLEQ chất lượng cao và đã được đánh giá.

Khi Andrew Toth bắt đầu viết một dự thảo BIP chi tiết về DLEQ, nhà mật mã học Tim Ruffing nhớ rằng đã có một triển khai trong thư viện mã secp256k1-zkp mà BitBox02 đã phụ thuộc. Đó là do jesseposner cung cấp cho một trường hợp sử dụng khác, nhưng may mắn thay, triển khai này cũng rất phù hợp cho thanh toán im lặng.

Với sự trợ giúp từ giao diện thử nghiệm của BIP, triển khai DLEQ nêu trên và một triển khai tham khảo hữu ích (mặc dù chúng tôi không thể sử dụng trực tiếp vì các yêu cầu của trình ký số cứng khác nhau), chúng tôi đã có thể tích hợp hỗ trợ thanh toán im lặng vào BitBox một cách suôn sẻ.

Khi nhiều người tự nguyện đóng góp thời gian và nỗ lực của mình để xây dựng một cái gì đó trong môi trường mở và cuối cùng có thể tích lũy thành công, điều đó luôn khiến người ta phấn khích.

Chân thành cảm ơn Josie, Ruben, Andrew và nhiều người khác đã giúp chúng tôi hoàn thành tính năng này.