Vấn đề cốt lõi: Phía dưới của Nhị phân, xác minh sự tin cậy

Khi hầu hết mọi người tải Bitcoin Core về, việc tương tác của họ với hệ thống build chỉ diễn ra trong vài cú nhấp chuột. Họ lấy file thực thi (executable binary) của phần mềm, xác minh chữ ký (hy vọng là vậy!), và bắt đầu chạy một node Bitcoin. Thứ họ thấy ngay lập tức là phần mềm đang chạy. Thứ họ không thấy là hệ thống build và các quy trình rất phong phú đã tạo ra phần mềm đó. Một hệ thống build thể hiện các nguyên tắc của Bitcoin về phi tập trung, minh bạch và khả năng kiểm chứng.

Nằm sau lượt tải xuống đó là nhiều năm công sức kỹ thuật được thiết kế để trả lời một câu hỏi đơn giản: “Tại sao ai đó lại nên tin vào phần mềm này?” Câu trả lời là: bạn không nên phải tin. Bạn phải có thể tự xác minh.

Trong thời đại mà các cuộc tấn công chuỗi cung ứng phần mềm trở thành tin nóng toàn cầu, từ các gói npm bị xâm nhập, các thư viện bị cài cài mã độc (backdoor), đến các máy chủ CI bị chiếm quyền, quy trình build của Bitcoin Core là một dự án kỷ luật âm thầm. Các phương pháp của nó có thể có vẻ chậm và phức tạp hơn so với sự tiện lợi không ma sát của “push to deploy”, nhưng đó chính là vấn đề. Bảo mật không phải là thứ tiện lợi.

Để hiểu hệ thống build của Bitcoin Core, chúng ta cần hiểu:

• Triết lý hệ thống Build của Bitcoin Core
• Các bản build có thể tái tạo (Reproducible Builds)
• Giảm thiểu phụ thuộc
• Không tự cập nhật
• Tích hợp liên tục (Continuous Integration)
• Điều chỉnh liên tục

Triết lý hệ thống Build của Bitcoin Core

Khi nói về phi tập trung của Bitcoin, hầu hết mọi người tập trung vào thợ đào (miners), các node và nhà phát triển. Nhưng phi tập trung không dừng lại ở những người tham gia giao thức. Nó còn mở rộng đến cách phần mềm bản thân được xây dựng và phân phối.

Một nguyên tắc trong hệ sinh thái Bitcoin là “đừng tin, hãy xác minh”. Chạy node của riêng bạn là một hành động xác minh, đối chiếu mọi khối (block) và giao dịch (transaction) với các quy tắc đồng thuận (consensus). Nhưng chính hệ thống build lại cho bạn một cơ hội khác để xác minh, ở cấp độ phần mềm. Bitcoin là tiền mà không cần trung gian được tin cậy và Bitcoin Core hướng tới việc tạo ra phần mềm mà không cần người xây dựng được tin cậy. Hệ thống build đã nỗ lực rất lớn để đảm bảo rằng bất kỳ ai, ở bất cứ đâu, đều có thể tự mình tái tạo độc lập đúng y hệt các file nhị phân (binaries) xuất hiện trên trang bitcoincore.org.

Triết lý này bắt nguồn từ bài tiểu luận năm 1984 của Ken Thompson Reflections on Trusting Trust, trong đó cảnh báo rằng ngay cả mã nguồn trông có vẻ sạch sẽ cũng không thể được tin tưởng nếu trình biên dịch (compiler) đã tạo ra phần mềm đó cũng bị xâm phạm. Các nhà phát triển Bitcoin đã ghi nhớ bài học này. Theo lời của cộng tác viên Bitcoin Core Michael Ford (fanquake):

“Các bản build có thể tái tạo là rất quan trọng, vì không có người dùng nào của phần mềm chúng tôi phải tin rằng những gì nằm bên trong đúng là những gì chúng tôi nói. Điều này luôn phải có thể được kiểm chứng độc lập.”

Một tuyên bố vừa là mục tiêu kỹ thuật vừa là một phần của tinh thần Bitcoin.

Trong thế giới an ninh, người ta nói về “bề mặt tấn công” (attack surfaces). Hệ thống build của Bitcoin Core coi chính quy trình build là một bề mặt tấn công cần được tối thiểu hóa và bảo vệ.

Các bản build có thể tái tạo: Xác minh từ tận gốc

Quy trình tạo ra một bản phát hành (release) của Bitcoin Core bắt đầu từ cơ sở mã nguồn mở (open-source codebase) trên GitHub. Mọi thay đổi đều công khai. Mọi pull request đều được xem xét. Nhưng hành trình từ mã code mà con người đọc được đến phần mềm software nhị phân có thể chạy liên quan đến các trình biên dịch (compilers), các thư viện bên thứ ba (third-party libraries), và các hệ điều hành (operating-systems) — những thứ tự bản thân chúng cũng là các vectơ tiềm ẩn để bị can thiệp, cài cài mã độc (backdoor) hoặc gây ra lỗi.

“Các bên thứ ba được tin cậy là các lỗ hổng bảo mật” – Nick Szabo (2001)

Để giải quyết những lo ngại này, kiến trúc sư Bitcoin Core đã thiết kế một đường ống (pipeline) quy trình build sử dụng Guix, một trình quản lý gói (package manager) được tạo ra để tạo ra các môi trường phần mềm có thể tái tạo và mang tính xác định (reproducible, deterministic).

Khi một bản phát hành Bitcoin Core mới được gắn thẻ (tag), nhiều cộng tác viên độc lập sẽ build lại các file nhị phân từ đầu bằng Guix. Mỗi người build làm việc trong một môi trường được cô lập (isolated environment) đảm bảo bộ công cụ (toolchains), phiên bản compiler và các thư viện hệ thống là giống hệt nhau. Nếu tất cả người build tạo ra các đầu ra có cùng bit thì họ biết rằng quá trình build là mang tính quyết định (deterministic).

Sau đó, các cộng tác viên sẽ ký chữ ký mật mã (cryptographically sign) cho các file nhị phân kết quả và công bố các chữ ký đó trên một kho GitHub riêng “guix.sigs”, nơi liệt kê các xác nhận (attestations) cho từng bản phát hành của Bitcoin Core. Một số người build là nhà phát triển Bitcoin Core, nhưng đó không phải là yêu cầu; quy trình xác nhận mở cho bất kỳ ai từ phía công chúng. Trên thực tế, nhiều người đóng góp không phải người viết code thường xuyên đóng góp chữ ký.

Quy trình này được gọi là các bản build có thể tái tạo (reproducible builds), và nó là thuốc giải cho “niềm tin vào sự tin tưởng” (trusting trust) của Thompson. Nó có nghĩa là bất kỳ ai cũng có thể lấy mã nguồn mở, môi trường Guix tương tự, và tự mình xác nhận rằng file nhị phân chính thức khớp với thứ mà chính họ đã build. Mặc dù các bản build có thể tái tạo có thể xác minh rằng phần mềm là biểu diễn thực sự của mã nguồn phần mềm, tính đúng đắn của phần mềm lại được để lại cho các quy trình xung quanh việc kiểm thử kỹ lưỡng và xem xét mã nguồn (code review).

Hầu hết mọi người sẽ không bao giờ thực hiện biên dịch đầy đủ (full compilation) hoặc kiểm tra các manifest của Guix hay so sánh các hash của bản build. Họ không cần phải làm thế. Sự tồn tại của cơ sở hạ tầng đó, cùng với những người duy trì nó, tạo cho mỗi người dùng một nền tảng của sự tin cậy đã giành được (earned confidence).

Các file nhị phân chính thức trên bitcoincore.org không chỉ đơn thuần là “được tạo bởi những người duy trì Bitcoin Core”. Chúng là giao điểm của đầu ra từ hàng chục người build độc lập. Thứ cuối cùng bạn tải về chính là thứ mà tất cả mọi người khác đã build và đã xác minh là xác thực (authentic).

Đó là xác minh từ tận gốc.

Giảm thiểu phụ thuộc: Ít thứ để tin

Tính tái tạo (Reproducibility) là một phía của bài toán. Phía còn lại là giảm thiểu những gì cần phải được tái tạo. Mã của Bitcoin Core không phải là phần mã duy nhất được thực thi khi chạy Bitcoin Core. Bitcoin Core cũng dựa vào mã bên ngoài (external), các thư viện bên thứ ba để tăng tốc phát triển và tăng năng suất.

Trong thập kỷ vừa qua, các nhà phát triển Bitcoin Core đã liên tục loại bỏ các phụ thuộc bên thứ ba không cần thiết và đôi khi gây rắc rối, như OpenSSL và MiniUPnP. Dù đó là một thư viện hay một bộ công cụ (toolkit) bên ngoài, các phụ thuộc này đều làm tăng độ phức tạp hoặc đưa vào các giả định ẩn. Những dự án như Boost và Libevent, từng là những thành phần chủ lực trong cơ sở mã của Core, đang dần bị loại bỏ hoặc thay thế bằng các lựa chọn thay thế đơn giản hơn, tự chứa (self-contained) hơn.

Tại sao? Vì mọi phụ thuộc mà bạn kế thừa đều là một rủi ro tiềm ẩn đối với chuỗi cung ứng (supply-chain risk). Đó là nhiều đoạn mã mà bạn không tự viết, không thể kiểm toán (audit) đầy đủ, và không thể kiểm soát hoàn toàn. Giảm thiểu phụ thuộc giúp hệ thống build gọn hơn, an toàn hơn và dễ xác minh hơn.

Gần đây Brink đã nêu bật nỗ lực này trong bài blog “Minimizing Dependencies” [1], ghi nhận rằng đây không chỉ là vấn đề của sự đơn giản, mà còn là việc bảo toàn bảo mật và sự tự chủ của dự án. Mỗi phụ thuộc bị loại bỏ là một bên bên ngoài ít hơn mà dự án phải tin cậy và cũng là một khả năng ít hơn cho việc cài cài mã độc (backdoor).

Mục tiêu cuối cùng là tạo ra các file nhị phân hoàn toàn tĩnh (fully static binaries): các file thực thi chứa mọi thứ chúng cần để chạy, mà không có bất kỳ phụ thuộc động hay phụ thuộc trong thời gian chạy (no dynamic or runtime dependencies). Tính tự chứa này có nghĩa là không dựa vào các thư viện bên ngoài có thể khác nhau giữa các hệ điều hành.

Trong một thế giới mà phần lớn phần mềm ngày càng nặng hơn và phụ thuộc nhiều hơn vào các hệ sinh thái gói (package ecosystems) tập trung, Bitcoin Core đang đi theo hướng ngược lại: hướng tới sự tối giản (minimalism) và độc lập.

Không tự cập nhật

Trong hầu hết phần mềm hiện đại, người dùng được “che chắn” khỏi việc phải đưa ra quyết định cập nhật lên phiên bản phần mềm nào, hoặc thậm chí có cần cập nhật phần mềm hay không. Bạn cài một ứng dụng, và nó lặng lẽ tự động cập nhật lên các phiên bản mới nhất ở chế độ nền. Mặc dù điều này tiện lợi, nhưng nó lại trái ngược với triết lý của Bitcoin Core.

Bitcoin Core chưa bao giờ bao gồm các bản tự cập nhật, và các nhà phát triển đã nói rằng họ sẽ không bao giờ thêm. Tự động cập nhật dồn quyền lực vào một nơi. Chúng tạo ra một nhóm duy nhất có thể đẩy (có khả năng là độc hại) mã nguồn tới mọi node trên mạng. Đây chính là kiểu kiểm soát tập trung mà Bitcoin được xây dựng để tránh. Bằng cách yêu cầu người dùng tự tải xuống, xác minh và cài đặt các phiên bản mới một cách thủ công, Bitcoin Core củng cố trách nhiệm cá nhân và sự đồng thuận có thể kiểm chứng (verifiable consent).

Hệ thống build và sự vắng mặt của tự cập nhật là hai nửa của cùng một nguyên tắc. Chỉ có người chạy node (node runner) quyết định sẽ chạy gì và có thể xác minh rằng phần mềm được chạy là xác thực.

Tích hợp liên tục: Chậm lại và sửa mọi thứ

Ở Thung lũng Silicon, tích hợp liên tục và triển khai liên tục (CI/CD) là đặc trưng của phát triển phần mềm linh hoạt (agile). Giao hàng nhanh. Lặp nhanh hơn nữa. Để tự động hóa lo phần còn lại.

Bitcoin Core tiếp cận theo một hướng khác. Hệ thống CI của nó không tồn tại để tăng tốc triển khai, mà để bảo vệ tính toàn vẹn (integrity). Các bản build tự động kiểm tra tính nhất quán trên nhiều nền tảng (platforms). Hệ thống build của Bitcoin Core được thiết kế để càng bất khả tri (agnostic) với phần cứng và hệ điều hành càng tốt. Dự án có thể build các file nhị phân cho Linux, macOS và Windows, cũng như cho nhiều kiến trúc khác nhau bao gồm x86_64, aarch64 (ARM) và thậm chí cả riscv64. Hệ thống tích hợp liên tục bảo đảm cả tính tương thích lẫn tính toàn vẹn của phần mềm bằng cách thực hiện hàng trăm bài kiểm thử cho mỗi thay đổi được đề xuất.

Kết quả là một văn hóa trong đó “tích hợp liên tục” có nghĩa là tích hợp kiểm thử, xác minh và bảo mật — chứ không phải tích hợp đổi mới liên tục.

Chậm lại và sửa mọi thứ.

Điều chỉnh liên tục: Đến đây đã xong chưa?

Hệ thống build không phải là tĩnh (static). Các nhà phát triển tiếp tục tinh chỉnh nó bằng cách giảm phụ thuộc, cải thiện các bản build chéo kiến trúc (cross-architecture builds), và khám phá một tương lai build hoàn toàn tĩnh với không phụ thuộc trong thời gian chạy.

Trong khi hệ thống build của Bitcoin Core hướng tới tính quyết định (determinism), bản thân hệ thống build không thể đứng yên. Thế giới mà nó vận hành trong đó luôn thay đổi. Hệ điều hành, trình biên dịch, thư viện và kiến trúc phần cứng đều thay đổi. Mỗi bản phát hành mới của macOS hay glibc, mỗi lần ngừng dùng (deprecation) một cờ của trình biên dịch, hoặc mỗi kiến trúc CPU mới nổi lên đều tạo ra các bất tương thích tinh vi cần được xử lý. Một hệ thống build đứng im sẽ, theo thời gian, ngừng không còn build được nữa.

Nghịch lý của các bản build có thể tái tạo là chúng đòi hỏi tiến hóa liên tục để vẫn có thể tái tạo được. Các nhà phát triển phải liên tục “chốt” (pin), vá (patch), và đôi khi thay thế toolchain để duy trì tính quyết định trước bối cảnh thay đổi liên tục. Việc duy trì sự cân bằng giữa ổn định và khả năng thích nghi là một phần trong sức bền bền bỉ (resilience) liên tục của Bitcoin.

Nhận bản sao của The Core Issue ngay hôm nay!

Đừng bỏ lỡ cơ hội sở hữu The Core Issue — với các bài viết do nhiều Core Developer viết, giải thích về các dự án mà chính họ đang làm!

Đây là bài Letter from the Editor (Thư của Tổng Biên tập) được đăng trong ấn bản Print (in) mới nhất của Bitcoin Magazine, The Core Issue. Chúng tôi chia sẻ nó ở đây như một cái nhìn sớm về những ý tưởng được khám phá trong toàn bộ số.

[1]