Tạp chí Bitcoin 
Vấn đề cốt lõi: libsecp256k1, trái tim mã hóa của Bitcoin
Những câu nói phổ biến trong cộng đồng Bitcoin bao gồm “đừng tin tưởng, hãy xác minh” hoặc “không phải khóa của bạn, không phải tiền của bạn”, đôi khi còn khẳng định rằng nó “được hỗ trợ bởi toán học”. Nhưng rốt cuộc những câu tục ngữ này có ý nghĩa gì, và toán học phức tạp này được áp dụng vào thực tế như thế nào? Hầu hết độc giả chắc hẳn đều biết rằng một thành phần cơ bản trong thiết kế của Bitcoin là Mật mã hóa khóa công khai và cụ thể hơn là chữ ký số , rất cần thiết để chứng minh quyền sở hữu mà không cần đến một thực thể trung tâm. Có lẽ ít người biết đến phần mềm nào nằm bên dưới để làm cho toán học đường cong elip đó hoạt động và những nỗ lực nào được thực hiện để đảm bảo điều này diễn ra một cách an toàn và hiệu quả nhất, với những cải tiến liên tục. Hãy cùng tìm hiểu lịch sử và sự phát triển thú vị của “libsecp256k1”, một thư viện bắt đầu như một dự án sở thích nhỏ và qua nhiều năm đã phát triển thành một phần thiết yếu của các quy tắc Consensus bảo vệ một tài sản trị giá hàng nghìn tỷ đô la.
Sự khởi nguyên
Vì những lý do mà chúng ta chưa biết chắc chắn, Satoshi (SATS) đã chọn một đường cong elip có tên “secp256k1” để tạo và xác minh chữ ký số trong Bitcoin. Phiên bản ban đầu của ứng dụng khách Bitcoin được phát hành bằng cách sử dụng thư viện OpenSSL phổ biến để ký và xác minh giao dịch. Việc dựa vào thư viện của bên thứ ba nghe có vẻ là một cách tiếp cận hợp lý từ góc độ kỹ thuật phần mềm (càng hợp lý hơn nếu đó là một thứ phức tạp và chuyên biệt như đường cong elip).
(mật mã học), nhưng lựa chọn này sau đó lại gây ra vấn đề do sự không nhất quán trong mã phân tích chữ ký. Trong trường hợp xấu nhất, điều này thậm chí có thể dẫn đến việc phân tách chuỗi ngoài ý muốn. Một bài học rút ra từ thời kỳ đó là OpenSSL không phải là thư viện phù hợp cho một hệ thống quan trọng về mặt đồng thuận như Bitcoin. Vấn đề này sau đó đã được khắc phục bởi BIP66, đảm bảo mã hóa nghiêm ngặt các chữ ký ECDSA. Sau đó, sự phụ thuộc vào OpenSSL đã được thay thế bằng libsecp256k1 trong Bitcoin Core v0.12, được phát hành vào đầu năm 2016. 1
Nhưng nhìn lại một chút, động lực ban đầu đằng sau việc bắt đầu dự án libsecp256k1 chủ yếu là sự tò mò về khả năng tăng tốc. Vào khoảng năm 2012, nhà phát triển Bitcoin Core Pieter Wuille, hay còn gọi là “sipa”, tình cờ bắt gặp một chủ đề Bitcointalk của Hal Finney (người nổi tiếng là người nhận giao dịch Bitcoin đầu tiên vào năm 2009 từ Satoshi (SATS)).
Trong chủ đề “Tăng tốc xác minh chữ ký”, bài đăng đã thảo luận về một phương pháp tối ưu hóa sử dụng cái gọi là “tự đồng cấu” (chính xác hơn là sử dụng phương pháp GLV, Gallant-Lambert-Vanstone), điều mà chỉ một số đường cong elliptic nhất định cho phép, secp256k1 là một trong số đó. Chính Hal Finney đã triển khai nó bằng cách sử dụng các hàm cơ bản của OpenSSL, và sau đó thậm chí còn gửi nó dưới dạng yêu cầu kéo (PR) cho Bitcoin Core. 2 Mặc dù nó cho thấy một sự cải tiến đáng kể
Tăng tốc khoảng 20%, nhưng cuối cùng không được tích hợp do lo ngại về việc tăng độ phức tạp của mã và thiếu sự đảm bảo rằng thuật toán mã hóa liên quan là an toàn.
Pieter Wuille đã quyết định bắt đầu xây dựng một thư viện mới từ đầu, với lần commit đầu tiên vào kho lưu trữ “secp256k1” vào ngày 5 tháng 3 năm 2013. Chỉ sau một tuần, thư viện đã có thể xác minh toàn bộ chuỗi khối (Block Height khoảng 225000 vào thời điểm đó), và trong vòng một tuần nữa, chức năng ký đã được triển khai. Phải mất thêm một thời gian và thử nghiệm nữa cho đến khi thư viện sẵn sàng được sử dụng trong Bitcoin Core để thay thế OpenSSL, trước tiên là để ký trong chuỗi khối.
ví điện tử (phiên bản v0.10, 2015), và cuối cùng là để xác minh chữ ký ECDSA trong Consensus (phiên bản v0.12, 2016). Những nỗ lực này hoàn toàn xứng đáng: theo mô tả PR trong Core, việc sử dụng libsecp256k1 để xác minh chữ ký nhanh hơn "từ 2,5 đến 5,5 lần". Trớ trêu thay, điều này vẫn chưa bao gồm tối ưu hóa nội hình đã đề cập trước đó, vì nó không được bật theo mặc định do lo ngại vi phạm bằng sáng chế. Nó chỉ được kích hoạt vào năm 2020, sau khi bằng sáng chế hết hạn (được bật trong phiên bản v0.20), dẫn đến một sự tăng tốc đáng kể khác khoảng 16%.
Theo thời gian, dự án đã thu hút thêm một số người đóng góp khác. Điều này đương nhiên bao gồm những người đã làm việc chặt chẽ với Pieter ngay từ đầu tại Blockstream, cụ thể là CTO lúc bấy giờ Gregory Maxwell và nhà nghiên cứu Andrew Poelstra. Năm 2015, Jonas Nick và vài năm sau đó là Tim Ruffing tham gia, cả hai đều là nhà nghiên cứu được Blockstream tuyển dụng và hiện đang giữ vai trò người bảo trì libsecp256k1 trong nhiều năm. Họ chịu trách nhiệm xác định các thuật toán mã hóa mới.
Việc nắm vững các giao thức (bao gồm cả các bằng chứng bảo mật chi tiết) và đưa chúng vào thực tiễn bằng cách triển khai và xem xét lại, hoàn toàn phù hợp khi gọi họ là "nhà mật mã học toàn diện", như Tim Ruffing thường tự mô tả về mình.
Thỉnh thoảng, ngay cả các nhà mật mã học ngoài lĩnh vực Bitcoin cũng đã đóng góp vào...
libsecp256k1. Một ví dụ đáng chú ý là Peter Dettman, được biết đến là một trong những người duy trì thư viện mật mã C#/Java BouncyCastle, người cho đến nay vẫn thường xuyên xuất hiện với nhiều đề xuất cải thiện hiệu suất khác nhau. Một trong những đóng góp chính của ông là triển khai phép đảo ngược mô-đun bằng thuật toán “safegcd” vào năm 2021 để cải thiện một cách an toàn, theo một bài báo của Daniel J. Bernstein và Bo-Yin Yang.
Tại sao phải phát minh lại cái bánh xe?
Mục tiêu của libsecp256k1 là cung cấp thư viện chất lượng cao nhất cho các hoạt động mã hóa trên đường cong secp256k1, với mục đích chính là hữu ích trong hệ sinh thái Bitcoin rộng lớn hơn – Bitcoin Core chỉ đơn giản là máy khách chính sử dụng nó. API của libsecp256k1 được thiết kế mạnh mẽ và khó bị lạm dụng, nhằm ngăn người dùng thực hiện các hoạt động không an toàn (ví dụ: bằng cách tự tạo ra các lược đồ mã hóa riêng) có thể dẫn đến mất tiền trong trường hợp xấu nhất. Bằng cách chỉ tập trung vào một đường cong elliptic và giới hạn chức năng của nó vào các hoạt động...
Liên quan đến Bitcoin (chủ yếu là ký và xác minh giao dịch), mã nguồn có thể được xem xét nhanh hơn và đơn giản hơn, dẫn đến gánh nặng bảo trì thấp hơn và chất lượng tổng thể cao hơn so với các triển khai khác. libsecp256k1 được viết bằng ngôn ngữ C và không phụ thuộc vào bất kỳ thư viện nào khác, vì vậy nó chỉ sử dụng mã nội bộ được viết riêng cho dự án. Do đó, nó được thiết kế để chạy trên các thiết bị có tài nguyên hạn chế như vi điều khiển, thường được sử dụng trong ví phần cứng.
Đo hai lần, cắt một lần
Ngay từ rất sớm, thư viện libsecp256k1 đã tập trung mạnh vào việc đảm bảo chất lượng, điều này được liên tục cải thiện và hoàn thiện qua nhiều năm. Hiện nay, độ phủ mã kiểm thử của nó đạt gần 100%, và các mô-đun mới chỉ có cơ hội được hợp nhất nếu tiêu chuẩn đó vẫn được đáp ứng. Ngoài ra, còn có một hình thức đảm bảo đặc biệt gọi là "kiểm thử toàn diện". Ý tưởng cơ bản là kiểm tra chức năng của thư viện trên toàn bộ không gian các giá trị có thể có trên đường cong. Vì điều này không khả thi trên đường cong secp256k1 thực tế, bao gồm khoảng 2^256 điểm, nên một đường cong đặc biệt, nhỏ hơn nhiều nhưng rất giống nhau được sử dụng, có bậc chỉ ở phạm vi hai hoặc ba chữ số, do đó nó có thể dễ dàng được thực thi trong một khoảng thời gian hợp lý. Một phần quan trọng khác của việc kiểm thử là đảm bảo hành vi thời gian không đổi, điều này đặc biệt liên quan đến việc ký điện tử, như chúng ta sẽ thấy bên dưới.
Schnorr: Một thế giới hoàn toàn mới
Chuyển trọng tâm từ kiểm thử phần mềm sang các tính năng mới, một trong những cột mốc quan trọng trong thập kỷ qua của libsecp256k1, và trong giao thức Bitcoin nói chung, là sự ra đời của chữ ký Schnorr. Là một phần thiết yếu của bản cập nhật mềm Schnorr/Taproot được kích hoạt vào cuối năm 2021, chúng mang lại nhiều lợi thế so với chữ ký ECDSA, bao gồm tính bảo mật được chứng minh theo các giả định tiêu chuẩn, nhỏ gọn hơn và cho phép nhiều cấu trúc khác như tổng hợp khóa và chữ ký để tạo ra các lược đồ Đa chữ ký hiệu quả hơn. Cả đặc tả trong BIP340 và việc triển khai đều được tạo ra bởi ba người bảo trì hiện tại của libsecp256k1, Pieter Wuille, Jonas Nick và Tim Ruffing.
libsecp256k1 tốt cho node của bạn và mạng.
Không cần phải nói, việc xác minh chữ ký số là một trong những (nếu không phải là ) đường dẫn mã quan trọng và có tính bảo mật cao nhất của cơ chế Consensus Bitcoin. Cho dù có bao gồm các đường dẫn kịch bản phức tạp và các điều kiện chi tiêu bổ sung trong một số Script khóa, cuối cùng vẫn có ít nhất một bước kiểm tra chữ ký liên quan đến giao dịch để đảm bảo rằng nó thực sự được tạo ra bởi chủ sở hữu của số tiền đang được chi tiêu. Đối với một hoạt động thiết yếu như vậy, chúng ta muốn mã phải mạnh mẽ, được kiểm thử kỹ lưỡng và có hiệu suất cao nhất có thể. Việc xác minh chữ ký nhanh cũng rất quan trọng đối với cả việc truyền tải giao dịch và Block nhanh chóng, cũng như để tăng tốc độ Tải xuống Block Ban đầu (IBD) cho những người tham gia mới vào mạng lưới. Chúng ta đã đề cập trước đó về việc tăng tốc độ khoảng 5 lần khi libsecp256k1 thay thế OpenSSL lần đầu tiên khoảng mười năm trước. Theo thời gian, các cải tiến hiệu suất hơn nữa đã được thực hiện, và một cuộc điều tra gần đây cho thấy libsecp256k1 hiện nhanh hơn khoảng 8 lần so với OpenSSL trong việc xác minh chữ ký ECDSA bằng cách sử dụng phiên bản mới nhất của mỗi thư viện. 3
Việc ký kết có thể nguy hiểm, vì vậy hãy làm đúng cách.
Cho đến nay, chúng ta đã tập trung vào chức năng xác minh của libsecp256k1, đây là chức năng quan trọng nhất đối với hiệu suất của các node runner và Thợ đào. Mặt khác (không có ý chơi chữ!) là việc ký điện tử , tức là quá trình tạo chữ ký số cho một giao dịch để chi tiêu tiền. Điều khiến quá trình này trở nên nhạy cảm là do nó liên quan đến khóa bí mật. Nếu khóa này bị rò rỉ bằng bất kỳ cách nào, trong trường hợp xấu nhất có thể dẫn đến mất mát tiền bạc nghiêm trọng, vì vậy cần phải hết sức cẩn thận ở cấp độ triển khai. libsecp256k1 cố gắng chống lại các cuộc tấn công "kênh phụ" bằng cách tránh các nhánh phụ thuộc dữ liệu, tức là các trường hợp mà các đoạn mã khác nhau được thực thi tùy thuộc vào dữ liệu được cung cấp. Đây là một nhiệm vụ không hề đơn giản và đòi hỏi một số nỗ lực bổ sung đối với các trình biên dịch hiện đại, đôi khi "quá thông minh" theo nghĩa là chúng cố gắng tối ưu hóa mã trong khi biên dịch thành phần mềm với các nhánh tiết kiệm tài nguyên mà chúng ta rõ ràng không muốn điều đó xảy ra. Đây không chỉ là vấn đề lý thuyết mà đã xảy ra nhiều lần, đòi hỏi phải phát hành các bản vá lỗi (ví dụ: các phiên bản 0.3.1 và 0.3.2). Thuộc tính thời gian không đổi quan trọng cũng được kiểm tra bằng một công cụ có tên “valgrind”, ban đầu được xây dựng để gỡ lỗi các vấn đề về bộ nhớ. Bằng cách sử dụng nó để tìm bất kỳ nhánh nào trong mã hoạt động trên dữ liệu bí mật, chúng ta có thể phát hiện xem có tồn tại rủi ro tấn công kênh phụ hay không.
Một cách khác mà tài liệu bí mật có thể bị rò rỉ là do vô tình để lại nó trong bộ nhớ. Việc ghi đè lên một vùng bộ nhớ để đảm bảo nó bị xóa nghe có vẻ đơn giản, nhưng điều này phải được thực hiện theo cách ngăn trình biên dịch can thiệp do tối ưu hóa mã trong quá trình biên dịch. Chúng tôi hết sức cẩn thận để đảm bảo điều đó không xảy ra.
Một vài sự cố bất ngờ may mắn
Trong quá trình phát triển thư viện, nhiều điều thú vị bất ngờ đã xuất hiện. Năm 2014, Pieter Wuille và Gregory Maxwell đã bắt đầu xây dựng bộ kiểm thử mở rộng cho thư viện. Một trong những chiến lược để đạt được mức độ đảm bảo cao hơn là xác minh hoạt động của các hàm nội bộ trong thư viện so với các triển khai khác bằng cách sử dụng các đầu vào ngẫu nhiên đặc biệt. Điều này đã phát hiện ra trường hợp OpenSSL đưa ra kết quả sai khi bình phương một số, một lỗi bảo mật nghiêm trọng được ghi nhận là CVE-2014-3570 (“Bình phương số lớn có thể tạo ra kết quả không chính xác.”).
Trong một trường hợp khác vài năm sau đó, Pieter Wuille đã đề xuất một phương pháp mới để tính toán giới hạn (hoặc cận) về số lần lặp cần thiết cho thuật toán “safegcd” đã đề cập trước đó để tính toán nghịch đảo modulo. Điều này cho phép thu hẹp giới hạn đó, dẫn đến tốc độ tính toán nhanh hơn. Nhưng mọi chuyện không dừng lại ở đó. Chủ yếu là do tình cờ, Gregory Maxwell đã phát hiện ra một biến thể khác của thuật toán Bernstein và Yang với giới hạn thậm chí còn thấp hơn, dẫn đến một sự tăng tốc đáng kể khác cả trong việc ký và xác minh.
Điều đáng chú ý là tính đúng đắn (và do đó, tính an toàn) của việc triển khai “safegcd” đã được xác minh chính thức bằng cách sử dụng phần mềm chứng minh định lý đặc biệt có tên là “Rocq” (trước đây có tên là “Coq”) và logic chương trình “Verifiable C”. 4 Công trình ấn tượng này được thực hiện bởi Russell O'Connor và Andrew Poelstra, những người khẳng định rằng toàn bộ libsecp256k1 có thể được xác minh theo cùng một cách.
Mật mã học vẫn đang phát triển.
Chúng tôi đã chứng minh rằng libsecp256k1 chủ yếu được sử dụng để tạo và xác minh chữ ký số trong các giao dịch Bitcoin, với sự cẩn thận tối đa để thực hiện theo cách an toàn và hiệu quả nhất có thể, nhưng điều đó không dừng lại ở đó. Bất cứ khi nào có các đề xuất khác được đưa ra liên quan đến các hoạt động mật mã trên đường cong secp256k1 (lý tưởng nhất là được chính thức hóa trong Đề xuất cải tiến Bitcoin (BIP)) và được coi là có lợi cho hệ sinh thái Bitcoin nói chung, thì khả năng cao là mã cần thiết sẽ được xem xét trong phạm vi của thư viện. Trong trường hợp đó, nếu có đủ thời gian của nhà phát triển để triển khai và xem xét, thì khả năng cao là nó sẽ được đưa vào bản phát hành của libsecp256k1. Điều này đã từng xảy ra trước đây với mô-đun ElligatorSwift, một phần thiết yếu để cho phép mã hóa cho giao tiếp P2P của các nút [xem BIP324; được thảo luận chi tiết tại đây ], và gần đây nhất là với MuSig2, một lược đồ tổng hợp khóa dựa trên chữ ký Schnorr cho phép tạo ra nhiều chữ ký n-trên-n một cách tiết kiệm không gian và bảo vệ quyền riêng tư. Hiện cũng đang có nỗ lực bổ sung một mô-đun mới cho Thanh toán im lặng, một đề xuất về địa chỉ tĩnh có thể tái sử dụng, bảo vệ quyền riêng tư, không cần tương tác giữa người gửi và người nhận trước khi thanh toán. Và còn rất nhiều điều nữa sắp tới: Xác thực hàng loạt cho Chữ ký Schnorr, bằng chứng DLEQ, FROST, ETC Hãy cùng chờ xem 10 năm phát triển tiếp theo của libsecp256k1 sẽ mang lại những gì!
Những độc giả quan tâm đến libsecp256k1 được khuyến khích xem xét và thử nghiệm secp256k1lab, một phiên bản Python của đường cong secp256k1 được thiết kế cho mục đích tạo mẫu và thử nghiệm. 5
Đừng bỏ lỡ cơ hội sở hữu ấn phẩm The Core Issue — với các bài viết được chấp bút bởi nhiều lập trình viên cốt lõi, giải thích chi tiết về các dự án mà họ đang thực hiện!
Bài viết này là Thư của Biên tập viên đăng trong ấn bản in mới nhất của Tạp chí Bitcoin, Số cốt lõi. Chúng tôi chia sẻ bài viết này ở đây như một cái nhìn sơ lược về những ý tưởng được khai thác xuyên suốt toàn bộ số báo.
[1] https://gnusha.org/pi/bitcoindev/55B79146.70309@gmail.com/
[2] (#2061, https://github.com/bitcoin/bitcoin/pull/2061 )
[3] https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087?u=thestack
[4] [ https://www.arxiv.org/abs/2507.17956 ]
[5] https://github.com/secp256k1lab/secp256k1lab/
Bài viết này, "Vấn đề cốt lõi: libsecp256k1, trái tim mật mã của Bitcoin", lần đầu tiên xuất hiện trên Bitcoin Magazine và được viết bởi Sebastian Falbesoner .
