BIP352: Hiện tại và tương lai của thanh toán thầm lặng

Tác giả: Anony

"Thanh toán im lặng" là giải pháp được đề xuất để đạt được mã định danh thanh toán tĩnh trong khi vẫn đáp ứng được các yêu cầu về quyền riêng tư. Để sử dụng, người nhận thanh toán chỉ cần tiết lộ một mã định danh ổn định và không thay đổi (có thể coi là một địa chỉ đặc biệt) và người gửi sẽ tạo một địa chỉ Bitcoin mới không trùng lặp cho người nhận trong quá trình thanh toán.

Bài viết này cố gắng giải thích các khái niệm cơ bản của nó, đề xuất cải tiến Bitcoin đầu tiên cho thanh toán im lặng, BIP352 ^[5] và mong muốn áp dụng thanh toán im lặng dựa trên các thông số kỹ thuật của BIP352.

Các khái niệm cơ bản về thanh toán thầm lặng

Để hiểu khái niệm thanh toán thầm lặng, trước tiên chúng ta hãy xem xét quy trình thanh toán của Bitcoin “trên Chuỗi ” (tức là sử dụng blockchain làm phương pháp xác nhận giao dịch):

1. Alice cố gắng trả tiền cho Bob, vì vậy cô ấy yêu cầu Bob cung cấp một tập lệnh Bitcoin mà Bob có thể sử dụng (địa chỉ là một biểu diễn nhỏ gọn, không có lỗi của một tập lệnh như vậy ^[1] );
2. Bob trả lời Alice bằng một địa chỉ;
3. Alice sao chép địa chỉ vào phần mềm ví Bitcoin của mình, thêm các chi tiết giao dịch khác và phát giao dịch để nhận xác nhận blockchain.
4. Khi phần mềm của Bob nhận được một khối mới, nó sẽ quét các giao dịch khớp nhau dựa trên thông tin được Bob lưu trữ (chẳng hạn như địa chỉ); nếu có sự trùng khớp, nó sẽ lưu trữ thông tin giao dịch và đánh dấu đầu ra của giao dịch liên quan là số tiền mà nó có thể sử dụng.

Quá trình này liên quan đến những điểm sau:

1. Sự riêng tư. Nếu Bob cung cấp một địa chỉ đã được sử dụng, điều này sẽ làm tăng rủi ro địa chỉ đó bị " nặc danh " - chủ sở hữu thực sự của địa chỉ đó bị bên thứ ba phát hiện. Thói quen gây tổn hại đến quyền riêng tư này được gọi là "tái sử dụng địa chỉ" và càng tái sử dụng nhiều thì rủi ro nặc danh càng cao.
2. Tính tương tác. Trong quá trình trên, Bob sẽ tương tác với Alice và cung cấp cho cô ấy địa chỉ. Có thể thấy rằng loại tương tác này gây ra một số phiền toái, nhưng xét về tính riêng tư thì giá trị của nó là rõ ràng: Bob có thể tận dụng cơ hội này để cung cấp địa chỉ mới và tránh việc sử dụng lại địa chỉ.
3. Sự tiện lợi khi sao lưu. Miễn là Bob không chi tiêu khoản thanh toán ngay sau khi nhận được thì Bitcoin sẽ vẫn nằm trong địa chỉ của anh ấy, điều này tạo ra nhu cầu sao lưu thông tin chính của địa chỉ. Vì lý do riêng tư, Bob nên tạo một địa chỉ mới cho mỗi khoản thanh toán mới, nhưng làm sao anh ấy có thể sao lưu một cách thuận tiện?

Trong chương trình lưu ký Bitcoin hiện tại, chương trình ví xác định phân cấp BIP-32 giải quyết mâu thuẫn nêu trên giữa quyền riêng tư và sự tiện lợi khi sao lưu ^[2] : tất cả các khóa mà Bob sử dụng đều bắt nguồn từ cùng một hạt giống thông qua các bước nhất định; vì các khóa này có cùng nguồn nên Bob chỉ cần sao lưu hạt giống (tối đa một lượng rất nhỏ thông tin bước suy luận cần được sao lưu bổ sung); và vì bước suy luận là một chiều nên bên thứ ba không thể suy đoán từ khóa công khai của các khóa này rằng chúng thuộc cùng một nguồn, điều này cũng đảm bảo tốt tính riêng tư.

Điều duy nhất không thỏa đáng là nhu cầu tương tác vẫn còn tồn tại. Mỗi người trả tiền trước tiên phải liên lạc với Bob và lấy địa chỉ mới trước khi bắt đầu thanh toán. Có cách nào để có được mã định danh thanh toán tĩnh (địa chỉ) mà không ảnh hưởng đến quyền riêng tư không?

Ruben Somsen, người khởi xướng khái niệm thanh toán im lặng, đã từng thảo luận về các giải pháp khả thi trong một bài phát biểu ^[3] . Thanh toán im lặng là một trong đó và cho thấy sự đánh đổi đặc biệt (có phần triệt để): loại bỏ nhu cầu tương tác bằng cách tăng gánh nặng quét cho người nhận Bob (tức là sự phức tạp của bước thứ tư trong quy trình thanh toán được đề cập ở trên).

Thanh toán im lặng sử dụng một khái niệm gọi là “trao đổi Key Diffie–Hellman” (cùng tuổi với khái niệm “mật mã khóa công khai”! ^[4] ): nếu Alice và Bob mỗi người có một cặp khóa công khai-riêng tư, thì họ chỉ cần biết khóa công khai của người kia để có được một bí mật chung mà chỉ họ biết bằng một thao tác đơn giản: nhân private key của họ với khóa công khai của người kia.

Do mối quan hệ toán học giữa khóa private key và khóa công khai, khi Alice nhân private key của mình với khóa công khai của Bob, giá trị thu được sẽ giống với giá trị thu được khi Bob nhân private key của mình với khóa công khai của Alice.

Hãy lấy khóa công khai và khóa riêng dựa trên đường cong elip làm ví dụ. Khóa công khai A của Alice được lấy bằng cách thực hiện phép nhân điểm trên private key a và điểm đường cong elip G; Cặp khóa của Bob cũng tương tự. Khi đó: aB = a*bG = b*aG = bA . Điều này được gọi là "ECDH (trao đổi khóa DH qua đường cong Elliptic)".

Theo định nghĩa, chỉ có người biết một trong đó private key có thể có được giá trị bí mật này, do đó không ai khác biết được, chỉ có họ và nhau biết.

Hãy tưởng tượng nếu Bob tiết lộ khóa công khai của mình trước, thì Alice có thể sử dụng private key của mình để suy ra một giá trị bí mật mới mà không cần tương tác với anh ta, sau đó suy ra một khóa công khai mới (và sau đó là địa chỉ tương ứng) từ giá trị bí mật này. Ví dụ, khóa công khai mới là điểm đường cong elip của giá trị băm của khóa công khai của Bob cộng với giá trị bí mật được chia sẻ: New PK = B + H(aB).G ; private key đằng sau khóa công khai này là: New sk = b + H(bA) . Rõ ràng, chỉ có Alice và Bob mới biết được khóa công khai này được xây dựng như thế nào, vì trong đó sử dụng một giá trị bí mật chung mà chỉ họ biết; hơn nữa, chỉ có Bob mới có thể chi tiêu số tiền trong địa chỉ này (vì private key b chỉ có Bob biết, còn Alice thì không).

Phương pháp này đáp ứng ba yêu cầu trên: (1) Miễn là Alice không sử dụng lại private key, cô ấy sẽ không nhận được cùng một địa chỉ; (2) Alice không còn cần phải tương tác với Bob nữa và có thể trực tiếp xây dựng một địa chỉ mà chỉ Bob mới có thể chi tiêu; (3) Bob không cần sao lưu tài liệu khóa cho mỗi địa chỉ mới vì theo một nghĩa nào đó, tất cả chúng đều bắt nguồn từ cùng một hạt giống (cặp khóa).

Tuy nhiên, câu hỏi đặt ra là làm sao Alice có thể cho Bob biết cô ấy đã sử dụng cặp khóa nào? Nếu Bob không biết khóa công khai của Alice, thì mẹo này có hiệu quả không?

Đây là nơi mà các khoản thanh toán im lặng mang tính cấp tiến hơn so với các khái niệm tương tự trước đây: nó yêu cầu Alice sử dụng khóa công khai được dùng trong các đầu vào giao dịch, mà không truyền đạt thông tin này thông qua các phương tiện khác (chẳng hạn như đầu ra giao dịch OP_RETURN bổ sung), do đó các giao dịch sử dụng các thủ thuật trao đổi khóa ở trên trông không khác gì các giao dịch không sử dụng các thủ thuật như vậy! Điều này tối đa hóa các yêu cầu về quyền riêng tư và nhiệm vụ khám phá thông tin bí mật hoàn toàn được giao cho Bob.

Trên đây là khái niệm cơ bản về thanh toán im lặng. Tiếp theo, chúng ta hãy xem BIP352 bổ sung thêm nội dung cho bộ khung của hình thức thanh toán im lặng ở trên và biến nó thành một công nghệ hữu ích như thế nào, đồng thời xem các thông số kỹ thuật khác nhau của nó ảnh hưởng đến gánh nặng quét của người nhận thanh toán Bob như thế nào.

BIP352: BIP thanh toán thầm lặng đầu tiên

BIP352 được viết tốt, theo quy trình từng bước trong phần tổng quan và khá chặt chẽ trong phần chi tiết. Để cân bằng giữa nhu cầu trình bày trong đó dung với mục đích của bài viết này, các mục tiêu thiết kế chính và lựa chọn của bài viết được nêu lại như sau:

• Khả năng tương thích sinh thái
  • BIP352 sử dụng mã hóa Bech32m ^[6] để mã hóa địa chỉ người nhận của các khoản thanh toán im lặng.
    • Thiết kế này có nghĩa là phần mềm Bitcoin hỗ trợ đầu ra P2TR không cần phải triển khai phương pháp mã hóa và giải mã mới mà chỉ cần tinh chỉnh để giải mã thông tin cần thiết từ địa chỉ thanh toán ẩn.
    • Thiết kế này cũng cho phép chúng tôi xác định nhiều phiên bản của giao thức thanh toán thầm lặng. BIP352 được định nghĩa là "giao thức thanh toán im lặng cho v0".
• Bảo mật lưu trữ
  • Địa chỉ thanh toán ẩn BIP352 không chứa một khóa công khai mà là hai khóa công khai, được gọi là "khóa công khai quét" và "khóa công khai chi tiêu". Để quét các khoản thanh toán liên quan đến bạn, bạn cần biết "private key quét", nhưng không cần biết "private key chi tiêu".
    • Do đó, người dùng có thể lưu trữ private key để chi tiêu trong các thiết bị an toàn hơn (chẳng hạn như trình ký được thiết kế tốt).
• Sự riêng tư
  • “Điểm đầu ra” của giao dịch đầu vào cũng được bao gồm trong quá trình suy ra giá trị bí mật được chia sẻ. Điểm đầu ra là mã định danh duy nhất cho UTXO, bao gồm id của giao dịch tạo ra UTXO và số thứ tự của UTXO trong số các đầu ra của giao dịch.
    • Thiết kế này tránh được tác động của việc Alice (người khởi tạo thanh toán) sử dụng lại địa chỉ/khóa công khai trên Bob (người nhận thanh toán). Miễn là ID giao dịch không chồng chéo ^[7] , các điểm đầu ra của mỗi UTXO là duy nhất. Ngay cả khi sử dụng cùng một khóa công khai, giá trị bí mật chung được chia sẻ sẽ khác nhau và cùng một địa chỉ sẽ không được tạo cho Bob.
  • Tất cả các đầu vào đều tham gia vào quá trình tạo ra giá trị bí mật chung. Lấy điểm đầu ra nhỏ nhất của tất cả các đầu vào giao dịch để rút ra giá trị bí mật chung. Hơn nữa, Alice sử dụng private key cho tất cả các đầu vào đủ điều kiện để rút ra giá trị bí mật chung.
    • Thiết kế này cũng giúp Bob không thể biết được thông tin nào đến từ Alice.
  • Tương thích với nhiều loại đầu vào nhất có thể. BIP352 định nghĩa "P2PKH", "P2WPKH", "P2SH-P2WPKH" và "P2TR" là các đầu vào đủ điều kiện, nghĩa là người trả tiền có thể sử dụng tiền trong các loại địa chỉ này để bắt đầu thanh toán ngầm.
    • Những độc giả quen thuộc với các kiểu dữ liệu đầu vào Bitcoin có thể thấy rằng điều này bao gồm hầu hết các tập lệnh chuẩn hóa được kiểm soát bởi một khóa công khai duy nhất. Càng ít loại thông tin đầu vào được yêu cầu thì nhóm người dùng có thể thực hiện thanh toán im lặng càng lớn. Điều này cũng có nghĩa là sự khác biệt giữa thanh toán ngầm và thanh toán thường xuyên là nhỏ hơn và ít có khả năng bị phát hiện.
    • Đồng thời, do yêu cầu của điểm trước, khi xây dựng giao dịch thanh toán ngầm, người trả tiền phải đảm bảo private key của mỗi đầu vào giao dịch đáp ứng yêu cầu có thể tham gia vào việc suy ra giá trị bí mật chung.
  • Việc sử dụng số thứ tự bổ sung trong quá trình tìm ra địa chỉ Bitcoin của người nhận cho phép người trả tiền phân bổ số tiền thanh toán thực tế vào nhiều địa chỉ khác nhau trong một giao dịch duy nhất.
    • Điều này có thể được sử dụng để chống lại tình trạng đầu cơ dựa trên số tiền.
• Tiện lợi quét/tiện lợi quản lý
  • Thiết kế “sử dụng tất cả các đầu vào” ở trên cũng giúp Bob quét và thanh toán dễ dàng hơn.
  • Chỉ cho phép lên lịch đầu ra P2TR cho Bob.
  • Cho phép Bob tạo nhiều địa chỉ thanh toán ẩn bằng cùng một bộ khóa quét và khóa chi tiêu bằng cách tạo nhiều khóa công khai chi tiêu thông qua các thẻ bổ sung.
    • Bob có thể tạo nhiều địa chỉ thanh toán ẩn và sắp xếp các địa chỉ khác nhau cho nhiều người nhận tiền/mục đích thanh toán khác nhau mà không cần sao lưu bổ sung.

Trên đây là nội dung chung của BIP352.

Dựa trên thiết kế trên, quy trình để người nhận thanh toán Bob quét các giao dịch thanh toán im lặng liên quan đến mình trên blockchain về cơ bản như sau:

1. Đầu tiên, Bob cần tìm ra các giao dịch thanh toán ẩn tiềm năng trong một khối (được gọi là “giao dịch đủ điều kiện” trong BIP352);
   • Có ba tiêu chí để đánh giá các giao dịch tiềm năng: (1) có đầu ra P2TR; (2) chứa ít nhất một đầu vào của loại sử dụng được phép nêu trên; và (3) không chứa các đầu vào có phiên bản cao hơn SegWit v1. Ở đây, chỉ việc áp dụng tiêu chuẩn đầu tiên mới yêu cầu thông tin về chính giao dịch đó; hai tiêu chuẩn sau yêu cầu chúng ta phải có khóa công khai của tập lệnh đầu ra trước đó của đầu vào để thực hiện phán đoán và thông tin này là ngầm định và sẽ không được phản ánh trong giao dịch.
2. Sau đó, Bob cần duyệt qua tất cả các đầu vào của một giao dịch tiềm năng, một mặt để tìm điểm đầu ra nhỏ nhất và mặt khác để rút khóa công khai từ các đầu vào có thể sử dụng ở trên và cộng chúng lại;
   • Quá trình này sẽ tạo ra hai thông tin chính cần thiết để có được giá trị bí mật chung. Một là giá trị băm chứa thông tin điểm đầu ra tối thiểu, được gọi là "input_hash" trong BIP352; giá trị còn lại là tổng các khóa công khai của tất cả các đầu vào đủ điều kiện, được ký hiệu là "A" trong BIP352.
3. Cuối cùng, Bob sử dụng input_hash, A và private key được quét của anh ấy để có được giá trị bí mật được chia sẻ, sau đó có được khóa công khai và tập lệnh P2TR tương ứng dựa trên khóa công khai chi tiêu của anh ấy; sau đó anh ta kiểm tra xem có đầu ra P2TR như vậy trong đầu ra của giao dịch hay không. Nếu vậy, anh ta sẽ lưu giao dịch và đầu ra đó và đánh dấu là khoản tiền mà anh ta có thể chi tiêu. Nếu không thì có nghĩa là giao dịch đó không liên quan đến anh ta.

Những độc giả tinh ý có thể thấy rằng hai bước 1 và 2 ở trên là hậu quả trực tiếp của hai thiết kế chính do BIP352 thực hiện dựa trên khái niệm cơ bản về "thanh toán im lặng": (1) sử dụng thông tin của tất cả các đầu vào giao dịch khi suy ra giá trị bí mật chung của người gửi và người nhận thanh toán; (2) hỗ trợ càng nhiều loại đầu vào càng tốt. Gánh nặng quét như vậy rõ ràng sẽ ảnh hưởng đến việc áp dụng thanh toán ngầm (hay nói cách khác, chi phí này sẽ hạn chế các trường hợp áp dụng).

Tiếp theo, chúng tôi thảo luận về chế độ hoạt động có thể có của ví thanh toán ẩn BIP352 và sử dụng phương pháp so sánh để hiểu gánh nặng quét của nó.

Hai chế độ làm việc và gánh nặng quét

Qua phân tích quá trình quét máy thu ở trên, ta thấy rằng bất kể máy quét là Bob hay Carol thì chúng đều phải chạy hai bước đầu tiên của quá trình quét và kết quả thu được ở cuối hai bước là như nhau. Nghĩa là, vì thanh toán im lặng BIP352 "sử dụng tất cả các đầu vào", cho dù một giao dịch có phải là giao dịch thanh toán im lặng tiềm năng hay không và (nếu vậy) input_hash và A của nó là thông tin hữu ích như nhau đối với tất cả người nhận thanh toán im lặng, thông tin có thể được sử dụng lại (trên thực tế, người nhận chỉ cần lấy tích của hai thông tin). Do đó, một chế độ làm việc khả thi là "chế độ máy chủ- máy trạm": máy chủ chạy hai bước đầu tiên của quá trình quét và cung cấp kết quả cho máy trạm; máy trạm chỉ chạy bước cuối cùng dựa trên thông tin khóa cục bộ. Chế độ này tương tự như chế độ "full nút- light node" trong các ví thông thường, có thể giảm đáng kể khối lượng công việc của khách hàng.

Ngược lại, "chế độ tích hợp" không phân tách khối lượng công việc và cả ba bước đều được thực hiện bởi cùng một máy tính.

Tuy nhiên, nếu bạn xem xét kỹ hơn các bước quét trên và kết nối chúng với chế độ làm việc của nút đầy đủ, bạn sẽ có thêm những khám phá:

Các bước quét 1 và 2 yêu cầu phải có khóa công khai của tất cả các đầu vào của giao dịch để xác định loại tập lệnh đầu vào và thực hiện các bước rút khóa công khai tương ứng dựa trên loại tập lệnh. Thông tin được tiết lộ trong giao dịch, bao gồm "chữ ký tập lệnh (ScriptSig)" và "chứng kiến ​​(txinwitness)", là không đủ. Tuy nhiên, nút đầy đủ cũng yêu cầu thông tin này khi xác minh các giao dịch trong các khối mới đến và việc thu thập thông tin này chỉ yêu cầu tìm kiếm trong tập UTXO, mà không cần truy cập vào các khối và giao dịch lịch sử lịch sử(mà không kích hoạt các lần đọc ổ cứng sâu hơn).

Nói cách khác, nếu các bước quét trên được thực hiện trong khi xác minh các giao dịch trong khối mới thì đó là ngẫu nhiên và chi phí bổ sung hoàn toàn đến từ việc tính toán (kiểm tra kiểu đầu vào và đầu ra, rút khóa công khai, suy ra giá trị bí mật chung, ECDH, v.v.) và xét một cách khách quan thì lượng tính toán này sẽ không quá lớn; tuy nhiên, nếu chúng ta sử dụng một quy trình riêng để chạy quét, chúng ta không chỉ phải trả giá thêm chi phí tính toán mà còn cần thêm các lần đọc ổ cứng sâu hơn, vì sau khi khối mới được xác minh, khóa công khai của tập lệnh đầu vào trong đó dịch không còn có thể được lấy từ bộ UTXO nữa mà chỉ có thể lấy được bằng cách truy cập các giao dịch lịch sử(và có thêm chi phí không gian lưu trữ ở đây: lập chỉ mục tất cả các giao dịch trên blockchain. Nếu không có chỉ mục như vậy, các giao dịch lịch sử thực sự không thể được đọc và chế độ quét xác minh đồng bộ không yêu cầu lập chỉ mục các giao dịch lịch sử).

Do sự khác biệt đáng kể này về chi phí chung ^[8] , chúng tôi thêm định nghĩa về “chế độ tích hợp”: bước quét là bước phụ của quá trình xác minh khối và được hoàn thành đồng bộ với quá trình xác minh khối.

Xin lưu ý rằng sau khi thêm định nghĩa, sự kết hợp giữa "chế độ tích hợp" và "chế độ máy chủ- máy trạm" không tạo thành một bộ hoàn chỉnh: có thể khối lượng công việc quét không được phân tách, nhưng công việc quét vẫn được hoàn thành trong một quy trình riêng biệt.

Định nghĩa của hai chế độ này chỉ được xây dựng nhằm giúp chúng ta hiểu rõ hơn gánh nặng quét của người nhận thanh toán ngầm BIP352 thông qua việc so sánh: do tính chính xác của các định nghĩa nên cả hai đều có đối tượng so sánh phù hợp. Chế độ tích hợp có thể được so sánh với ví thông thường dựa trên một nút đầy đủ; chế độ máy chủ- máy trạm có thể được so sánh với ví thông thường dựa trên light node của bộ lọc khối BIP158 ^[9] .

Để thực hiện điều này, chúng tôi đưa ra những giả định sau về số lượng và tỷ lệ giao dịch diễn ra trong mạng lưới, cũng như số lượng địa chỉ được ví kiểm soát:

• Trung bình, mỗi khối chứa n giao dịch, có tổng cộng m giao dịch đầu vào và o giao dịch đầu ra;
• Chiếm tỷ lệ các giao dịch chứa ít nhất một đầu ra P2TR là p và tỷ lệ phần trăm đầu ra P2TR so với tất cả các đầu ra trong một khối duy nhất là q ;
• Ví thanh toán im lặng chỉ tiết lộ 1 địa chỉ thanh toán im lặng;
• Ví thông thường chứa 20 địa chỉ P2TR;
• Chỉ xem xét trường hợp địa chỉ ví này xuất hiện trong kết quả giao dịch (trường hợp nhận thanh toán).

Theo các giả định trên, gánh nặng quét của ví thông thường dựa trên một nút đầy đủ là: 20 * o * q , tức là chạy Lần kiểm tra khớp địa chỉ cho mỗi đầu ra P2TR trong khối. Gánh nặng quét của ví thanh toán thầm lặng ở chế độ tích hợp là: n * p * I + o * q * 1 Mục đầu tiên là chi phí phát sinh do hai bước đầu tiên của quá trình quét thanh toán thầm lặng, dựa trên các giao dịch. Ở đây I là lượng tính toán cần thiết để thực hiện kiểm tra kiểu, rút khóa công khai, ECDH và các hoạt động khác trên một giao dịch, được coi là một hằng số tại đây; mục thứ hai là lượng tính toán cần thiết để thực hiện kiểm tra khớp địa chỉ trên mỗi đầu ra P2TR của các giao dịch tiềm năng này. Do chủ ví chỉ tiết lộ 1 địa chỉ thanh toán ẩn nên giao dịch chỉ cần lần thực hiện 1 .

Đối với ví thông thường dựa trên light node, chúng ta biết rằng chế độ hoạt động của chúng là xác minh bộ lọc khối trước; nếu bộ lọc cho thấy không có đầu vào và đầu ra nào đáng quan tâm trong khối, thì toàn bộ khối sẽ không được tải xuống nữa; nếu bộ lọc khối cho thấy có (có khả năng rất nhỏ là có sự đánh giá sai ở đây), hãy tải xuống và kiểm tra xem địa chỉ có khớp không. Chúng tôi coi gánh nặng xác minh bộ lọc khối là một hằng số (điều này không ảnh hưởng đến phép so sánh), khi đó gánh nặng quét của nó là: 1/x * 20 * o * q , trong đó 1/x là xác suất bộ lọc va vào bộ lọc, phải lớn hơn xác suất phán đoán sai của bộ lọc khối BIP158, nhưng kích thước thực tế phụ thuộc vào sự phân phối các giao dịch mà ví này nhận được giữa các khối.

Đối với ví thanh toán im lặng dựa trên mô hình máy chủ- máy trạm, gánh nặng quét là: n * p * I_1 + o * q * 1 . Lý do tại sao công thức này lại giống với chế độ tích hợp là vì máy chủ chỉ hoàn thành một phần công việc quét và đối với mỗi giao dịch có thể xảy ra, máy trạm vẫn cần thực hiện một phần công việc (cụ thể là ECDH) (nó chỉ là một phần của I , do đó được ghi là I_1 ), trong khi việc kiểm tra địa chỉ khớp của đầu ra P2TR không thể hưởng lợi từ công việc của máy chủ, do đó vẫn giữ nguyên như vậy.

Tóm tắt các phân tích trên:

1. Gánh nặng quét của ví thông thường phần lớn được xác định bởi số lượng đầu ra cùng loại, nhưng gánh nặng quét của ví thanh toán thầm lặng liên quan một phần (hoặc thậm chí chủ yếu) đến số lượng giao dịch đủ điều kiện. Hai điều này không dễ để so sánh trực tiếp; nhưng xét về độ phức tạp của tính toán, gánh nặng quét của các khoản thanh toán im lặng có thể lớn hơn. Cụ thể, gánh nặng này liên quan đến chiếm tỷ lệ các giao dịch có chứa đầu ra P2TR; chiếm tỷ lệ càng lớn thì gánh nặng quét trên các ví thanh toán im lặng càng lớn;
2. Cả ví thông thường và ví thanh toán ẩn đều có thể được hưởng lợi đáng kể khi chuyển sang mô hình light node/ máy trạm nhẹ;
3. Sự khác biệt về gánh nặng quét giữa ví thanh toán im lặng và ví thông thường sẽ lớn hơn ở chế độ máy trạm, nghĩa là người dùng dễ cảm nhận được sự khác biệt về hiệu suất hơn. Ví thanh toán im lặng có thể phù hợp hơn với máy tính để bàn ổn định hơn là thiết bị di động để sử dụng hàng ngày.

Hiện tại và tương lai của thanh toán thầm lặng

Hiệu suất/chi phí chắc chắn sẽ ảnh hưởng đến việc áp dụng công nghệ. Từ những phân tích trên, chúng ta có thể biết rằng dù ở chế độ hoạt động nào thì ví thanh toán im lặng cũng phải trả giá giá cao hơn ví thông thường. Có thể nói đây cũng nằm trong dự đoán của chúng tôi, vì đây là đặc điểm vốn có của “thanh toán thầm lặng”. Ít nhất là trong các trường hợp sử dụng mà mọi người hình dung (chấp nhận quyên góp, chấp nhận thanh toán như một tổ chức), lợi ích của các phương thức thanh toán tĩnh phải lớn hơn chi phí bổ sung của chúng. Hơn nữa, do khả năng máy chủ-máy khách, một phần khối lượng công việc có thể được tái sử dụng.

Hiện nay, nhiều dự án đang cố gắng triển khai ví thanh toán ẩn BIP352, chẳng hạn như:

• Triển khai BIP352 trong Bitcoin Core: https://github.com/bitcoin/bitcoin/issues/28536
• Ví thanh toán im lặng Dana Wallet Mobile: https://github.com/cygnet3/danawallet

Ngoài ra, các nhà phát triển đang nỗ lực bổ sung nhiều thông số kỹ thuật khác nhau để thanh toán im lặng tương thích với giao dịch coinjoin. Trong giao dịch coinjoin, nhiều người tham gia sẽ cung cấp thông tin đầu vào cho giao dịch và chỉ định thông tin đầu ra; theo BIP352, để giao dịch như vậy có thể thực hiện thanh toán ngầm, người trả tiền phải cho phép private key của mỗi đầu vào đủ điều kiện tham gia vào việc tạo ra giá trị bí mật được chia sẻ; đồng thời, điều này không thể gây ra rò rỉ private key thực sự; ngoài ra, cần có các công cụ có khả năng truyền tải thông tin về giao dịch được xây dựng giữa các bên (kịch bản của người nhận chỉ có thể được lấy sau khi mọi người tham gia tính toán). Các thông số kỹ thuật có liên quan là:

• Bằng chứng đẳng thức logarit rời rạc BIP374: https://github.com/bitcoin/bips/pull/1689
  • Bằng chứng đẳng thức logarit rời rạc cho phép người nắm giữ private key chứng minh rằng họ biết private key mà không tiết lộ private key đó là gì.
• BIP375 sử dụng PSBT để gửi thanh toán ẩn: https://github.com/bitcoin/bips/blob/master/bip-0375.mediawiki
  • Xác định định dạng dữ liệu "PSBT (Giao dịch Bitcoin đang chờ ký)" có thể được sử dụng để truyền tải thông tin trong các giao dịch thanh toán ngầm được bên long bên ký kết.

Không gian thiết kế giao thức liên quan đến thanh toán im lặng cũng đang được khám phá.

(qua)

chú thích

1. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/ ↩

2. https://www.btcstudy.org/2023/10/25/a-guide-for-recovering-your-bitcoin-wallets/ ↩

3. https://www.btcstudy.org/2022/10/19/on-various-non-interactive-payments/ ↩

4. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ↩

5. https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki ↩

6. https://www.btcstudy.org/2024/11/22/bitcoin-address-types-its-essentials-and-its-economics/#Bech32m ↩

7. https://www.btcstudy.org/2024/04/17/transaction-security-improvement-from-soft-forks/#BIP30%EF%BC%9A%E7%A6%81%E6%AD%A2%E5%87%BA%E7%8E%B0%E7%9B%B8%E5%90%8C%E7%9A%84%E4%BA%A4%E6%98%93-ID ↩

8. Sự khác biệt đáng kể về chi phí này có thể giải thích tại sao một số nhà phát triển quyết tâm triển khai BIP352 trong Bitcoin Core. Xem: https://github.com/bitcoin/bitcoin/issues/28536 ↩

9. https://www.btcstudy.org/2022/04/18/how-neutrino-works-by-Suredbits/ ↩