OP_CHECKSHRINCS: Mã lệnh chữ ký băm được thiết kế để chống lại các cuộc tấn công lượng tử Bitcoin.

Tác giả: Jonas Nick

Nguồn: https://blog.blockstream.com/op_checkshrincs-a-hash-based-signature-opcode-for-post-quantum-bitcoin/

Hiện tại, chưa có giải pháp cụ thể nào để tích hợp chữ ký hậu lượng tử vào Bitcoin . Blockstream Research đã nghiên cứu vấn đề này trong suốt năm qua. Bài viết này chia sẻ những gì chúng tôi đã tìm hiểu được và lập luận rằng chữ ký dựa trên hàm băm được tối ưu hóa là một lựa chọn thực tế để tăng khả năng chống lại các cuộc tấn công lượng tử Bitcoin và có thể sớm được triển khai. Bài viết cũng giới thiệu "SHRINCS" và "SHRIMPS", các lược đồ chữ ký hậu lượng tử với kích thước chữ ký tối thiểu được xây dựng dựa trên các giả định mật mã đã được thiết lập; sau đó, bài viết phác thảo một đề xuất sơ bộ.

Loại đầu ra Bitcoin mới nhất khóa tiền vào khóa công khai Schnorr, và việc chi tiêu các đầu ra này yêu cầu chữ ký Schnorr hợp lệ. Tuy nhiên, chữ ký Schnorr dễ bị tấn công bởi máy tính lượng tử. Cách tự nhiên nhất để thêm xác minh chữ ký hậu lượng tử là sử dụng tùy chọn hậu lượng tử để mở rộng cây kịch bản Taproot. Sau khi nâng cấp soft fork , một đầu ra Bitcoin có thể đồng thời cam kết với khóa công khai Schnorr và khóa công khai được ký hậu lượng tử. Vì Taproot chỉ tiết lộ đường dẫn Merkle trees của kịch bản thực sự được chi tiêu, người dùng có thể tiếp tục sử dụng chữ ký Schnorr để chi tiêu (chúng nhỏ hơn, do đó phí giao dịch sẽ rẻ hơn), và chi phí giao dịch sẽ hầu như không thay đổi. Tùy chọn hậu lượng tử có thể chờ đợi một cách lặng lẽ trên cây kịch bản. Chỉ khi có đủ máy tính lượng tử mạnh mẽ, người dùng mới cần chuyển sang con đường thứ hai: sử dụng chữ ký hậu lượng tử để chi tiêu, tại thời điểm đó chi phí giao dịch cao hơn sẽ được trả giá.

Các kịch bản lỗi sau khi nâng cấp lượng tử

Nâng cấp lên khả năng chống chịu lượng tử có thể thất bại vì nhiều lý do khác nhau, và việc chủ động tránh những tình huống này sẽ định hình các lựa chọn thiết kế sẽ được thảo luận sau.

• Tốc độ xử lý giảm mạnh . Nếu kích thước chữ ký quá lớn, không gian khối có thể dễ dàng bị cạn kiệt, và nhiều người dùng sẽ không thể xác nhận giao dịch.
• Chi phí xác minh . Nếu yêu cầu tính toán để xác minh chữ ký quá cao, số lượng các nút có khả năng xác minh đầy đủ nút sẽ giảm, điều này sẽ ảnh hưởng đến tính tập trung của mạng.
• Chi phí chữ ký . Các thiết bị ký điện tử và các thiết bị có tài nguyên hạn chế cần phải có khả năng tạo chữ ký trong một khoảng thời gian hợp lý.
• Hệ thống mật mã đã bị phá vỡ . Nó dựa trên giả định bảo mật rằng giả định đó không thể đúng mãi mãi.
• Không ai chấp nhận đề xuất đó . Đề xuất nâng cấp quá phức tạp hoặc không thể tích hợp vào cơ sở hạ tầng hiện có. Chỉ riêng bạn chấp nhận đề xuất là không đủ: nếu tất cả những người khác trên mạng đều bị xâm phạm, thì tiền điện tử của bạn, dù hoàn toàn an toàn, cũng trở nên vô giá trị về mặt kinh tế.
• Độ phức tạp của việc triển khai . Phương án triển khai được đề xuất có thể chứa lỗi hoặc dễ bị tấn công, và do bản chất độc đáo của các quy tắc đồng thuận của Bitcoin , mọi người sẽ phải duy trì mã này vô thời hạn, mà không được vô tình gây ra dù chỉ là sự không tương thích nhỏ nhất.

Chỉ những đề xuất nào tránh được những cạm bẫy này mới có cơ hội đạt được sự đồng thuận tương đối.

Ứng viên tiêu chuẩn

Nhóm ứng viên đầu tiên bao gồm các lược đồ được tiêu chuẩn hóa bởi NIST (Viện Tiêu chuẩn và Công nghệ Quốc gia). Các lược đồ này đã tồn tại và có sẵn các triển khai, có thể được chuyển đổi thành Đề xuất Nâng cấp Bitcoin (BIP) với nỗ lực tối thiểu. Tiêu chuẩn để so sánh là lược đồ chữ ký Schnorr được sử dụng trong đầu ra của Taproot. Nếu mọi giao dịch đều sử dụng chữ ký Schnorr, mạng Bitcoin có thể xử lý (tương đương) 6,5 giao dịch mỗi giây, dựa trên kích thước giao dịch trung bình hiện tại. Tất cả TPS (giao dịch mỗi giây) được sử dụng trong bài báo này đều giả định trung bình 2,27 đầu vào và 2,64 đầu ra mỗi giao dịch (trung bình 90 ngày được đo vào ngày 30 tháng 3 năm 2026, theo transactionfee.info ), và giới hạn kích thước khối Bitcoin vẫn không đổi.

Chữ ký Schnorr hỗ trợ các tính năng mà cơ sở hạ tầng ví hiện tại dựa vào, đặc biệt là việc tạo khóa không được bảo mật theo tiêu chuẩn BIP 32. Nó cũng đã tạo điều kiện thuận lợi nâng cấp hiệu quả được triển khai trên toàn hệ sinh thái Bitcoin trong những năm gần đây (như MuSig2), cũng như các cải tiến về quyền riêng tư và hiệu quả đã được lên kế hoạch (như chữ ký ngưỡng, thanh toán im lặng và tổng hợp chữ ký trên nhiều đầu vào).

• ML-DSA , dựa trên giả định "mạng lưới", sẽ làm giảm thông lượng xuống còn một nửa giao dịch mỗi giây (theo tiêu chuẩn bảo mật NIST cấp 3); hơn nữa, tất cả các tính năng của chữ ký Schnorr sẽ bị mất, bao gồm cả việc tạo khóa không được bảo mật theo BIP 32.
• SLH-DSA dựa trên hàm băm. Hàm băm là một giả định thận trọng mà Bitcoin đã dựa vào, do đó cho phép nó nhắm đến mức độ bảo mật NIST cấp 1. Tuy nhiên, thông lượng sẽ giảm xuống còn 0,36 giao dịch mỗi giây; tương tự, các đặc tính của chữ ký Schnorr cũng sẽ bị mất.

Cả hai phương pháp này đều không phải là giải pháp nhanh chóng, và cả hai đều sẽ gây ra sự sụt giảm đáng kể về thông lượng mạng. Tăng giới hạn kích thước khối có thể giảm bớt vấn đề về thông lượng, nhưng việc gắn một nâng cấp hậu lượng tử thực tế, cần gấp rút về thời gian với một đề xuất tăng kích thước khối gây tranh cãi khó có thể thành công. Tốt nhất là nên thảo luận về giới hạn kích thước khối một cách riêng biệt.

Các ứng viên cần nghiên cứu thêm

Các giải pháp được NIST tiêu chuẩn hóa rất dễ triển khai, nhưng những đánh đổi mà chúng mang lại là không thể chấp nhận được. Các giải pháp khác hứa hẹn sự cân bằng tốt hơn, nhưng lại đòi hỏi nhiều nghiên cứu và thời gian hơn trước khi việc triển khai trở thành một lựa chọn đáng tin cậy.

• Falcon^WS là một hệ thống chữ ký điện tử dựa trên mạng lưới tương đối mới. Nó cung cấp kích thước chữ ký tốt hơn đáng kể (tốc độ xử lý đạt 1 giao dịch/giây ở cấp độ bảo mật NIST 5), nhưng vẫn còn quá non nớt để triển khai. Nó được đưa vào đây để minh họa những gì cuối cùng có thể đạt được dựa trên mạng lưới.
• Các chữ ký mạng lưới phù hợp với tập hợp tính năng chữ ký Schnorr , chẳng hạn như BIP 32 và chữ ký ngưỡng, là một hướng đi đầy hứa hẹn đáng được nghiên cứu thêm. Tuy nhiên, việc thêm các tính năng này làm tăng đáng kể kích thước chữ ký (so với các lược đồ mạng lưới bỏ qua các tính năng này), có khả năng làm giảm thông lượng xuống khoảng 1 TPS, thấp hơn cả Falcon^WS. Ví dụ, một lược đồ Raccoon-G được sửa đổi hỗ trợ việc tạo khóa xác định theo thứ bậc (bao gồm cả việc tạo khóa không được bảo mật), nhưng kích thước khóa công khai đạt tới 16 kB và kích thước chữ ký là 20 kB.
• SQIsign , dựa trên "tính đồng nhất", tự hào có kích thước chữ ký thanh lịch và thông lượng tăng khoảng 3,6 TPS (mức độ bảo mật 5), với khả năng hỗ trợ các đặc điểm của chữ ký Schnorr. Phần khó khăn nằm ở các giả định mật mã của nó, vốn chưa hoàn thiện bằng các giả định mạng lưới. Rủi ro bị xâm phạm là có thật và có thể không thể loại bỏ trong ngắn hạn. Việc xây dựng niềm tin vào các giả định mật mã mới sẽ mất nhiều năm.
• Việc tổng hợp chữ ký ở cấp khối sử dụng một bằng chứng ngắn gọn (SNARK) để tổng hợp tất cả các chữ ký trong một khối. Theo ước tính thận trọng, mỗi khối yêu cầu bằng chứng có dung lượng 500 kB, dẫn đến thông lượng khoảng 6,7 giao dịch mỗi giây (TPS). Các đề xuất gần đây theo hướng này bao gồm BitZip và LeanVM . Vẫn còn một số câu hỏi chưa được giải đáp, chẳng hạn như ai sẽ tính toán bằng chứng, làm thế nào để tránh sự tập trung hóa khai thác và độ phức tạp về mặt kỹ thuật là rất đáng kể.

Tối ưu hóa chữ ký dựa trên hàm băm và hạn mức chữ ký.

Tất cả các ứng cử viên này đều tồn tại trong cùng một không gian đánh đổi đa chiều: các giả định về bảo mật, hiệu quả, thuộc tính và độ phức tạp. Đối với chữ ký dựa trên hàm băm, hai hướng có vẻ đặc biệt hứa hẹn. Thứ nhất, chúng ta có thể thêm một chiều mới: trạng thái, từ đó mở ra một không gian thiết kế hoàn toàn mới. Thứ hai, chúng ta có thể chấp nhận sự gia tăng nhẹ về độ phức tạp của giao thức để đổi lấy những cải tiến đáng kể về hiệu suất. Kết hợp hai cách tiếp cận này, chữ ký dựa trên hàm băm trở thành một ứng cử viên hấp dẫn. Chúng mang lại hiệu quả cao hơn mà không cần kết hợp các giả định mật mã mới, và mật mã của chúng vẫn tương đối dễ hiểu và dễ triển khai.

Khái niệm "yêu cầu bộ nhớ" sử dụng một khái niệm được tích hợp sẵn trong mọi lược đồ chữ ký dựa trên hàm băm: " hạn mức chữ ký ". Tham số này cho biết số lần một khóa công khai duy nhất có thể ký an toàn một thông điệp mới. Trong SLH-DSA, hạn mức được đặt là 2^64, gần như vô hạn đối với bất kỳ ứng dụng thực tế nào. Cố ý giảm hạn mức có thể làm cho chữ ký cuối cùng nhỏ hơn; tuy nhiên, một khi hạn mức bị cạn kiệt, tính bảo mật của khóa công khai sẽ bị xâm phạm.

Với hạn mức chữ ký là 2^64, kích thước của một chữ ký SLH-DSA gần bằng 8 kB, dẫn đến thông lượng là 0,36 TPS. Giảm hạn mức xuống còn 2^40 (một lần chữ ký trên mỗi khóa công khai) vẫn đủ: với kích thước khối hiện tại, hạn mức này có thể kéo dài hàng trăm năm mà không bị cạn kiệt. Với tham số hạn mức nhỏ hơn này, kích thước chữ ký sẽ giảm còn 5,7 kB, tăng thông lượng lên 33%.

TỦY

Vậy thì hạn mức chữ ký có thể giảm xuống mức thấp nhất là bao nhiêu? Ở lớp nền tảng Bitcoin, các biện pháp bảo mật tốt nhất không khuyến khích việc tái sử dụng địa chỉ, vì vậy một khóa công khai điển hình sẽ chỉ được sử dụng để ký lần. Do đó, ngân sách chữ ký có thể rất thấp. Đối với những người dùng cần nhiều hơn mức này, một tùy chọn sao lưu có thể được cung cấp. Cấu trúc này cung cấp cho một khóa công khai hai đường dẫn ký: một đường dẫn nhỏ gọn, nằm trong hạn mức, tạo ra các chữ ký nhỏ; và một đường dẫn sao lưu luôn khả dụng, tạo ra các chữ ký mà không cần phải nhớ số lượng chữ ký.

Các đường dẫn ngắn gọn có cái giá của nó: người ký phải liên tục theo dõi số lượng chữ ký của mình để tránh vượt quá hạn mức. Bộ đếm này chính là trạng thái , và các hệ thống dựa vào nó được gọi là hệ thống có trạng thái . Trong hoàn cảnh như ví máy tính để bàn và ví di động, việc sao lưu và nhập lại là một thao tác thường xuyên, khiến việc hỗ trợ tính chất có trạng thái trở nên khó khăn. Việc nhập lại bản sao lưu cũ có thể vô tình đưa bộ đếm trở lại giá trị đã sử dụng trước đó. Các chữ ký tiếp theo sẽ sử dụng lại trạng thái, có khả năng gây rủi ro cho tiền của người dùng. Các nhà phát triển Bitcoin, bao gồm cả đội ngũ của chúng tôi tại Blockstream Research, đã và đang nỗ lực để đảm bảo các sản phẩm Bitcoin có khả năng chống lại việc lạm dụng. Các hệ thống có trạng thái vốn dĩ dễ bị tổn thương hơn (so với các hệ thống không có trạng thái). Ban đầu, khi khám phá hướng đi này, quan điểm của chúng tôi là mặc dù đó là một kỹ thuật thú vị, nhưng nó không thực sự thiết thực.

Tuy nhiên, có một cơ chế để ngăn người dùng vô tình làm hỏng trạng thái: một thiết bị ký chuyên dụng. Sau khi khởi tạo, thiết bị sẽ tạo ra một cụm từ hạt giống và thiết lập trạng thái ban đầu, trạng thái này sau đó chỉ nằm trong thiết bị đó và không bao giờ rời khỏi thiết bị. Thiết bị này tạo ra một chữ ký nhỏ gọn. Vì trạng thái này là công khai, ví phần mềm có thể thêm một bước kiểm tra bảo mật bổ sung để xác minh rằng chữ ký đã sẵn sàng không sử dụng lại trạng thái trước khi phát tán giao dịch. Nếu thiết bị ký này bị mất, hư hỏng hoặc được thay thế, người dùng có thể nhập cụm từ hạt giống vào một thiết bị mới, thiết bị này sẽ tự động chuyển sang chế độ không trạng thái, tạo ra một chữ ký lớn hơn, không trạng thái. Bằng cách bảo toàn hoàn toàn trạng thái trên thiết bị, khả năng người dùng làm hỏng trạng thái được loại bỏ.

Chúng ta sẽ đặt tên cho cấu trúc thu được là "SHRINCS". Nó dựa trên hai ý tưởng cốt lõi:

• Khóa công khai có thể được sử dụng với hai phương thức ký : một phương thức ngắn gọn, có trạng thái và một phương thức sao lưu không có trạng thái.
• Thiết kế này sử dụng một đường dẫn hiệu quả cao và nhỏ gọn : chi tiết trong đó nằm ngoài phạm vi bài báo này, nhưng cấu trúc này được xây dựng trực tiếp trên các lược đồ chữ ký dựa trên hàm băm hiện có.

So sánh thông lượng:

• SLH-DSA : 0,36 TPS
• Hạn mức chữ ký giảm còn 2^40 đối với SLH-DSA : 0,48 TPS
• Đường dẫn nén SHRINCS (kích thước chữ ký 580 byte): Tối đa 3 TPS (giả sử mỗi chữ ký sử dụng một đường dẫn nén)

Hồ sơ rủi ro của SHRINCS khác biệt đáng kể so với các ứng cử viên hậu lượng tử khác. Những phương án đó tiềm ẩn rủi ro hệ thống ảnh hưởng đến mọi người dùng trên mạng: thông lượng thấp, các giả định mật mã đáng ngờ và các giao thức đồng thuận dễ bị phá vỡ. Ngược lại, SHRINCS dựa trên rủi ro cục bộ: quản lý trạng thái trên từng thiết bị riêng lẻ. Với khả năng triển khai an toàn và các con số thông lượng này, SHRINCS không còn chỉ là một thủ thuật thú vị mà là một lựa chọn thực tiễn để chống lại các cuộc tấn công lượng tử.

TÔM

Trong lược đồ SHRINCS, việc nhập thuật ngữ hạt giống vào một thiết bị mới rất tốn kém vì nó kích hoạt một đường dẫn sao lưu không trạng thái, dẫn đến chữ ký lớn hơn. Tuy nhiên, điều này không xảy ra thường xuyên trong suốt vòng đời của khóa. SHRINCS tận dụng điều này bằng cách thêm một đường dẫn thứ hai, nhỏ gọn hơn, dành riêng cho các thiết bị sao lưu này. Sử dụng hạn mức 1000 chữ ký, đường dẫn này tạo ra một chữ ký có kích thước khoảng 3000 byte. Kích thước này gấp 5 lần chữ ký của thiết bị chính, nhưng vẫn nhỏ hơn 2,5 lần so với đường dẫn sao lưu (chữ ký SLH-DSA).

Tối ưu hóa đường dẫn sao lưu

Việc tích hợp trạng thái là một trong hai hướng đã đề cập trước đó. Hướng thứ hai là tối ưu hóa chính đường dẫn sao lưu không trạng thái.

Bắt đầu từ 7.872 byte (0,36 TPS) của chữ ký SLH-DSA, các tối ưu hóa sau có thể được thêm vào:

• Việc giảm hạn mức chữ ký xuống còn 2^40 sẽ thu nhỏ kích thước chữ ký xuống còn 5.792 byte (0,48 TPS), giảm khoảng 26%.
• WOTS+C (trong đó nhà mật mã học Mikhail Kudinov của Blockstream là đồng tác giả) và PORS+FP là những lựa chọn thay thế trực tiếp, dễ dàng có sẵn cho SPHINCS+, nhưng không được lược đồ SLH-DSA áp dụng. Điều này làm giảm kích thước chữ ký xuống còn 5.060 byte (0,54 TPS), giảm thêm khoảng 13%, mà không ảnh hưởng đến hiệu suất. Nhược điểm duy nhất là nó không tuân theo tiêu chuẩn NIST.
• Việc chấp nhận thời gian tạo chữ ký và khóa dài gấp năm lần có thể giúp giảm kích thước thêm khoảng 11%, xuống còn 4.496 byte (0,60 giao dịch mỗi giây).
• Nếu cho phép thời gian xác minh trên mỗi byte tăng khoảng 1,5 lần so với chữ ký Schnorr , thì có thể giảm thêm khoảng 13%, dẫn đến 3.896 byte (0,69 giao dịch mỗi giây).

Kết hợp tất cả các yếu tố này có thể giảm kích thước của chữ ký dựa trên hàm băm không trạng thái xuống còn một nửa so với chữ ký SLH-DSA. Thậm chí có thể áp dụng các biện pháp quyết liệt hơn nữa, với chi phí là thời gian ký hoặc xác minh lâu hơn, để giảm kích thước chữ ký hơn nữa.

Một Đề án ngây thơ

Đề án này dựa trên hai nguyên tắc thiết kế.

Thứ nhất, nó không làm tăng thời gian xác minh (so với lược đồ SLH-DSA). Điều này nhằm tránh làm cho việc tăng giới hạn kích thước khối trong tương lai trở nên khó khăn hơn. Nó cũng đơn giản hóa đáng kể việc tạo bằng chứng SNARK nếu có thể áp dụng tổng hợp chữ ký cấp khối.

Thứ hai, ý tưởng về "một chữ ký cho mọi mục đích" bị loại bỏ, và nhiều phương án chữ ký khác nhau được đưa ra cho các tình huống ứng dụng cụ thể.

• Ví điện tử lớp 1 trên máy tính để bàn và thiết bị di động không thể lưu trữ trạng thái một cách an toàn, nhưng chúng thường có CPU nhanh hơn. Chúng có thể sử dụng các lược đồ ký không trạng thái, hy sinh thời gian ký để đổi lấy sự nhỏ gọn: với hạn mức ký là 2^40, kích thước chữ ký xấp xỉ 4.496 byte. Hạn mức này vượt xa số lần có thể vô tình bị vượt quá.
• Các thiết bị ký chuyên dụng có thể được thiết kế để bảo toàn trạng thái, nhưng bộ xử lý của chúng thường yếu, vì vậy việc tăng chi phí ký không phải là một chiến lược khả thi. SHRINCS và SHRIMPS sử dụng ký có trạng thái để đảm bảo kích thước chữ ký nhỏ và tốc độ ký nhanh. Một đường dẫn thay thế không trạng thái sử dụng hạn ngạch chữ ký 2^32 (không ai lại nhấn một nút 4 tỷ lần trên thiết bị ký phần cứng); kích thước chữ ký của thiết bị chính xấp xỉ 580 byte; kích thước chữ ký (gọn) của thiết bị thay thế sẽ xấp xỉ 3.000 byte, và kích thước chữ ký của đường dẫn thay thế sẽ xấp xỉ 4.336 byte.
• Nút Lightning vốn dĩ có trạng thái và được hưởng lợi từ tốc độ ký nhanh hơn. Việc cập nhật kênh sử dụng cùng một lược đồ không trạng thái như đường dẫn dự phòng cho các thiết bị ký chuyên dụng: hạn mức chữ ký là 2^32, xấp xỉ 4.336 byte chữ ký. Nút đạt gần 4 tỷ lần có thể chuyển sang khóa công khai mới. Việc đóng kênh hợp tác có thể thực hiện được bằng cách sử dụng đường dẫn nhỏ gọn SHRINCS (khoảng 580 byte).

Kết quả là bốn biến thể chữ ký độc quyền được kết hợp. Thông lượng thực tế dao động từ 0,60 đến 3,04 TPS, vượt xa mức 0,36 TPS của lược đồ SLH-DSA tiêu chuẩn.

Những câu hỏi chưa được giải đáp và những thiếu sót

Đề án này chỉ là điểm khởi đầu chứ chưa phải là thiết kế hoàn chỉnh. Nó cũng có những hạn chế và một số vấn đề chưa được giải quyết:

• Thời gian xác minh được ưu tiên hơn kích thước : Đề án này có thể tối ưu hóa hơn nữa kích thước chữ ký, nhưng phải trả giá bằng thời gian xác minh. Hiện tại, chi phí xác minh trên mỗi byte thấp hơn 6 lần so với chữ ký Schnorr, vì vậy về mặt lý thuyết, kích thước khối có thể tăng lên 6 lần mà không làm tăng thời gian xác minh khối. Cần có bằng chứng xác thực chặt chẽ hơn để chứng minh điều này. (Ghi chú của người dịch: Các nút thắt cổ chai về băng thông mạng sẽ không cho phép chúng ta thực hiện một điều điên rồ như vậy.)
• Giảm tính đồng nhất và quyền riêng tư : Việc cho phép kết hợp nhiều phương thức ký điện tử thay vì chỉ sử dụng một phương thức sẽ đồng thời làm giảm quyền riêng tư của các phương thức này.
• Phạm vi phủ sóng và Layer 2 : Đề án này có bao gồm bất kỳ kịch bản ứng dụng nào không ? Đề án này sẽ tương tác với các giao thức Lớp 2 như thế nào?
• Cần thiết kế các lược đồ chữ ký như thế nào để chuẩn bị cho khả năng tập hợp chữ ký dựa trên SNARK có thể được giới thiệu thông qua soft forktrong tương lai ? Liệu đây có nên là một vấn đề cần xem xét ngay hôm nay?
• Thời gian ký : Thời gian ký bao lâu là chấp nhận được trên các nền tảng máy tính khác nhau? Các tiêu chuẩn thời gian ký tốt hơn sẽ cho phép chúng ta giảm đáng kể kích thước chữ ký.
• Triển khai tham khảo : Mã C++ hay đặc tả hình thức? Trong kỷ nguyên của LLM (Mô hình ngôn ngữ lớn), việc xác minh hình thức mã quan trọng cần sự đồng thuận trở nên khả thi hơn bao giờ hết.

Tiếp theo là gì?

Không gian thiết kế cho nâng cấp hậu lượng tử Bitcoin là rất rộng lớn, và không có một lược đồ chữ ký nào rõ ràng là lựa chọn đúng đắn. Tuy nhiên, các chữ ký dựa trên hàm băm có trạng thái được tối ưu hóa mang lại sự cân bằng tốt hơn so với các lược đồ tiêu chuẩn hiện nay. Chúng hứa hẹn sẽ giữ cho Bitcoin có thể sử dụng được mà không cần dựa vào soft fork trong tương lai. Trong khi đó, nghiên cứu về các cải tiến dài hạn hơn, chẳng hạn như các lược đồ dựa trên mạng lưới tốt hơn, tổng hợp chữ ký và mật mã dựa trên đồng nhất, nên được tiến hành song song.

May mắn thay, các vấn đề triển khai phần lớn không phụ thuộc vào lựa chọn lược đồ chữ ký: các mã lệnh dựa trên hàm băm mới có thể được phát hành thông qua Taproot, Taproot v2 hoặc BIP 360 "Pay to Merklegen".

Các tối ưu hóa do trạng thái mang lại trên các lược đồ chữ ký dựa trên hàm băm vẫn còn phần lớn chưa được khám phá. Liệu trạng thái có thể mang lại những tối ưu hóa tiềm năng nào khác? Liệu thiết kế kỹ thuật cẩn thận có thể đảm bảo an ninh cho các thiết bị có trạng thái? Liệu các giao thức lớp 2 khác nhau có thể trực tiếp sử dụng chữ ký có trạng thái?

Để tìm hiểu về chữ ký dựa trên hàm băm và các tham số của chúng, bạn có thể đọc bài báo của chúng tôi, " Xem xét chữ ký dựa trên hàm băm cho Bitcoin ". Đoạn mã ở đây có thể được sử dụng để tính toán các con số xuất hiện trong bài viết này. Một triển khai SHRINCS bằng C++ , một trình xác thực bằng ngôn ngữ Simplicity và một bản dự thảo đặc tả cũng có thể được tìm thấy trên hoàn cảnh. SHRINCS đã được triển khai trong môi trường sản xuất: chúng tôi đã trình diễn nó trên sidechain Liquid và mọi người đều có thể tự mình thử nghiệm.

(qua)