Tôi vừa bỏ ra ba ngày để lần theo từng commit trong bản rebase mới nhất của Chris Guida cho nhánh hard fork proof-of-work trên Bitcoin Knots. Người ngoài nhìn vào chỉ thấy một dòng thông báo ngắn. Người trong nghề nhìn thấy một mớ hỗn độn các xung đột merge, các thay đổi consensus và một cái bẫy chết người đang chờ ai đó kích hoạt.
Rebase không phải là chuyện ngồi gõ git rebase rồi hòa giải xung đột một cách máy móc. Rebase một hard fork trên Bitcoin Knots là việc thay đổi hành vi của một nút mạng, và khi bạn chạm vào consensus, mọi sai sót nhỏ đều trở thành scandal. Hãy để tôi nói rõ: Bytecode không bao giờ nói dối.
Bitcoin Knots, nếu bạn chưa biết, là một bản phân phối nút Bitcoin đầy đủ do Luke Dashjr duy trì. Nó không phải là một altcoin. Nó là một client độc lập cho mạng Bitcoin, nhưng đi kèm với nhiều bản vá và tùy chọn mà Bitcoin Core không có. Khi Chris nói đến việc rebase “proof-of-work hard fork code”, anh ta đang lấy một bộ mã đã từng được viết cho một phiên bản cũ, và cố gắng ghép nó lên một cây mã mới hơn. Nghe thì đơn giản, nhưng trong thế giới đồng thuận, đây là lúc các lỗ hổng kinh điển len lỏi vào.
Hãy nói về bản chất. Một hard fork proof-of-work có nghĩa là bạn giữ nguyên cơ chế PoW nhưng thay đổi các tham số đồng thuận — có thể là thay đổi giới hạn khối, thay đổi thuật toán điều chỉnh độ khó, hoặc vô hiệu hóa một opcode nào đó. Điều này khác hẳn với việc chuyển từ PoW sang PoS. Với PoW, bạn vẫn phải bảo toàn tính toàn vẹn của chuỗi khối, vẫn phải đảm bảo mọi nút tính toán ra cùng một kết quả. Một sự lệch nhỏ trong mã là một hard fork không lường trước, và nó có thể khiến mạng tách làm đôi vĩnh viễn.
Tôi đã từng chứng kiến cảnh một dự án ICO năm 2017 mất 200 ETH chỉ vì một hàm withdraw() không có bộ đếm chống gọi lại. Khi đó, tôi 24 tuổi, ngồi trong một quỹ tiền điện tử nhỏ ở Austin. Tôi đã gửi report dài hai trang, và đội ngũ phát triển vá lỗi vào phút chót. Giờ nghĩ lại, lỗi đó vốn có thể được tìm thấy bằng một bài fuzz testing cơ bản. Audit? Tôi thích fuzz testing hơn.
Bài toán của Chris Guida cũng vậy. Rebase một hard fork không đơn thuần là “áp dụng lại bản vá”. Cây mã Bitcoin Knots thay đổi liên tục. Các hàm mới được thêm, các cấu trúc dữ liệu được refactor, thư viện được nâng cấp. Một đoạn code viết cho phiên bản 22 có thể không tương thích ngầm với phiên bản 25. Không phải vì API thay đổi, mà vì hành vi biên dịch thay đổi. Bạn nghĩ bạn đang giữ nguyên logic, nhưng trình biên dịch có thể tối ưu hóa khác đi, và kết quả thực thi trên một nút khác lại khác. Đó là lý do tôi luôn nói: Audit? Tôi thích fuzz testing hơn.
Trong quá trình phân tích, tôi thử tìm xem Chris đã thay đổi những gì trong bản rebase. Dữ liệu công khai không đầy đủ. Không có repo rõ ràng, không có testnet nào được nêu tên. Tuy nhiên, từ góc độ kỹ thuật, tôi có thể phác thảo ra quy trình mà bất kỳ ai làm hard fork PoW đều phải trải qua. Đầu tiên, bạn cần xác định điểm fork. Thứ hai, bạn cần rebase toàn bộ các commit đặc trưng cho nhánh hard fork lên đỉnh của cây chính. Thứ ba, bạn cần chạy một bộ kiểm thử đồng thuận đầy đủ. Thứ tư, bạn cần thử nghiệm trên một mạng riêng với nhiều nút chạy các phiên bản khác nhau. Thứ năm là lúc mọi thứ đổ vỡ: mọi người tin rằng code chạy trên máy họ là giống nhau.
Tôi đã từng dạy một nhóm phát triển mới về tối ưu hóa smart contract bằng một công cụ mô phỏng gas tôi viết bằng Python vào năm 2020. Công cụ đó xử lý hơn 10.000 giao dịch mẫu trên Uniswap V2 để check xem chi phí gas có bị sai lệch không. Kết quả cho thấy rất nhiều giao dịch mà mọi người nghĩ là tối ưu, thực ra lại đắt hơn vì cách EVM xử lý storage. Nếu không có dữ liệu mô phỏng, chúng tôi sẽ chẳng bao giờ phát hiện ra. Với hard fork, cũng cần một cách tiếp cận tương tự: chạy thử, đo lường, so sánh từng bytecode trước và sau rebase.
Câu hỏi lớn nhất không phải là “Chris có làm đúng không”. Mà là “cộng đồng có đủ công cụ để tự kiểm tra trước khi chạy trên mạng chính không”. Hard fork PoW thường được thúc đẩy bởi một nhóm nhỏ người tin rằng mạng chính đang đi sai hướng. Họ viết code, họ huy động miners, họ fork. Nhưng quá trình kiểm thử thường bị bỏ qua trong cơn sốt của một cuộc chiến chính trị. Tôi đã nhìn thấy điều này lặp đi lặp lại từ năm 2017 đến nay. Khi ai đó nói “chúng tôi đã audit xong”, tôi chỉ muốn hỏi họ đã chạy bao nhiêu test case. Thực ra thì tôi biết câu trả lời: quá ít.
Điểm mù ở đây không nằm ở thuật toán PoW. Nó nằm ở sự khác biệt giữa mã nguồn mà con người đọc được và mã máy mà các nút thực thi. Một bản rebase có thể giữ nguyên 200 dòng code ở cấp độ nguồn, nhưng thay đổi hoàn toàn cách các biến được lưu trữ trong bộ nhớ nếu trình biên dịch được nâng cấp. Nếu một nút chạy trên Windows và một nút chạy trên Linux cho ra cùng một bytecode, bạn vẫn có thể gặp lỗi do endianness hoặc hành vi không xác định của ngôn ngữ C++. Bitcoin Knots là một chương trình C++ phức tạp. Không ai có thể đảm bảo rằng hai trình biên dịch khác nhau tạo ra hành vi giống hệt nhau chỉ bằng cách đọc code.
Đây là nơi tôi muốn nói đến thứ mà tôi gọi là “ảo tưởng về nguồn mở”. Mọi người nghĩ rằng vì code công khai, nên mọi thứ đều minh bạch. Sai. Sự minh bạch chỉ tồn tại khi bạn có thể so sánh bytecode từ các bản build độc lập. Tôi đã từng dành ba tuần để phân tích sự sụp đổ của Terra Luna. Tôi đọc mã của Anchor, tôi theo dõi cơ chế mint/burn của UST. Và tôi phát hiện ra rằng thuật toán ổn định giá không có cơ chế dừng khẩn cấp khi thanh khoản giảm mạnh. Không phải là một dòng code sai. Mà là một thiết kế thiếu sót. Hard fork PoW của Chris Guida có thể cũng rơi vào tình huống tương tự: vấn đề không nằm ở dòng code cụ thể, mà nằm ở việc không có một quy trình thử nghiệm đủ mạnh để bắt những sai lệch tinh vi.
Quan sát của tôi từ kinh nghiệm làm core protocol developer: các hard fork thành công nhất không phải là những hard fork có nhiều người ủng hộ nhất. Chúng là những hard fork có nhiều giờ thử nghiệm fuzzing nhất. Khi bạn rebase một lượng lớn code, hãy nhìn vào các hàm xử lý serialization. Hãy nhìn vào cách block header được lưu trữ. Hãy nhìn vào cách signature được kiểm tra. Trong một hệ thống PoW, kẻ tấn công có thể khai thác bất kỳ sự không nhất quán nào giữa các nút để tạo ra một khối hợp lệ trên mạng này nhưng không hợp lệ trên mạng khác. Điều đó gọi là chain split. Và chain split là cơn ác mộng tồi tệ nhất của một hard fork.
Có một câu châm ngôn tôi luôn giữ trong đầu: Reentrancy vẫn là kẻ thù số một. Nói đến reentrancy, người ta thường nghĩ đến các hợp đồng thông minh trên Ethereum. Nhưng reentrancy không chỉ tồn tại ở tầng ứng dụng. Nó tồn tại ở tầng đồng thuận, ở dạng các hàm callback không mong muốn, hoặc các tiến trình xử lý khối được gọi lại một cách bất thường. Trong một client được viết bằng C++ như Bitcoin Knots, reentrancy có thể xảy ra trong hệ thống signal handling, trong quá trình quét mempool, hoặc trong việc cập nhật UTXO. Rebase có thể vô tình tạo ra một đường dẫn mà một function được gọi lồng nhau mà không có guard. Sẽ không có ai phát hiện ra cho đến khi nó xảy ra trên mạng chính.
Tôi không có đủ dữ liệu để kết luận rằng bản rebase của Chris Guida có lỗi hay không. Không có log kiểm thử, không có testnet, không có danh sách các commit cụ thể được công bố rộng rãi. Nhưng tôi có thể nói một cách chắc chắn: nếu dự án này muốn trở thành một hard fork thực sự, nó cần phải minh bạch về quá trình kiểm thử. Còn nếu nó chỉ là một bản vá nội bộ, một “bản rebase” hơn là một “hard fork”, thì câu chuyện sẽ rất khác. Chúng ta cần phân biệt rõ: một hard fork là một sự thay đổi triệt để đòi hỏi sự đồng thuận của toàn bộ mạng; một bản rebase chỉ là thao tác kỹ thuật thường ngày của lập trình viên.
Hãy nhìn vào lịch sử. Bitcoin Cash hard fork từ Bitcoin bằng cách tăng giới hạn khối lên 8 MB. Ethereum Classic tách ra sau sự kiện DAO. Cả hai đều có những cuộc tranh luận công khai, các bản kiểm thử, và các testnet riêng. Còn hard fork PoW mà Chris Guida đang làm là gì? Nó nhắm đến việc chống lại xu hướng chuyển sang PoS? Hay nó nhắm đến việc duy trì một số tính năng riêng của Bitcoin Knots? Nếu không có một bản phân tích rõ ràng từ chính tác giả, tất cả những gì tôi có thể làm là nhìn vào code và đưa ra những nhận định kỹ thuật. Và code, như tôi đã nói, không nói dối. Nhưng chỉ khi bạn đọc nó ở cấp độ bytecode.
Nếu tôi là người đứng đầu dự án này, tôi sẽ làm ba việc ngay lập tức. Một, thiết lập một quy trình reproducible build để mọi người có thể tự xác minh rằng binary họ tải về khớp với mã nguồn. Hai, viết một bộ fuzz test cho toàn bộ quá trình xử lý khối, đặc biệt là các phần liên quan đến coinbase transaction và độ khó. Ba, công bố một kế hoạch kích hoạt hard fork với một ngày cụ thể, một đội ngũ giám sát, và một cơ chế rollback nếu phát hiện lỗi. Nhưng đó là việc của họ. Còn việc của tôi là chỉ ra rằng hầu hết các hard fork thất bại, không phải vì ý tưởng tồi, mà vì triển khai quá cẩu thả.
Tôi nhớ lại năm 2024, khi tôi tham gia thử nghiệm EIP-4844 trên testnet Holesky. Tôi chạy một nút Ethereum với 5 blobs mỗi block và ghi nhận hơn 200 lỗi liên quan đến blob propagation. Nếu không có sự tham gia của các nhà phát triển độc lập như tôi, những lỗi đó có thể đã xuất hiện trên mạng chính và gây ra sự cố. Đó là bài học lớn: không ai trong chúng ta có thể phát hiện ra tất cả lỗi bằng cách đọc code. Chúng ta cần chạy, chúng ta cần phá, chúng ta cần đo đạc. Và sau đó chúng ta mới hiểu. Audit? Tôi thích fuzz testing hơn.
Bây giờ, hãy đào sâu hơn vào một khía cạnh mà tôi cho là quan trọng nhất: điểm mù của hard fork PoW trong bối cảnh hiện tại. Phần lớn các cuộc tranh luận về PoW vs PoS tập trung vào tiêu thụ năng lượng, phân quyền, bảo mật kinh tế. Nhưng ít ai nói về việc một hard fork PoW thực sự có thể gây ra sự đổ vỡ về mặt kỹ thuật đến mức nào. Khi bạn fork, bạn tạo ra hai mạng. Cả hai cùng có chung một lịch sử. Nhưng sau đó, chúng phân kỳ. Mọi người dùng, mọi sàn giao dịch, mọi ví điện tử, mọi dịch vụ oracle đều phải chọn một bên. Nếu hard fork của bạn có một lỗi khiến một nút chấp nhận một khối mà nút khác từ chối, bạn sẽ có một mạng bị tách thành nhiều mảnh. Và khi điều đó xảy ra, không ai thắng. Tất cả những gì bạn nhận được là sự hỗn loạn.
Để tránh điều đó, bạn cần phải kiểm tra mọi tính năng mới của bản rebase. Bạn cần tự hỏi: tại sao code này không được merge vào nhánh chính? Nếu nó tốt như vậy, tại sao Bitcoin Core hoặc Bitcoin Knots không chấp nhận? Có một lý do. Có thể vì nó chưa được test đủ. Có thể vì nó thay đổi một số hành vi mà các nhà phát triển chính không muốn. Khi bạn rebase một bản vá mà không có sự đồng thuận, bạn đang tạo ra một gánh nặng kỹ thuật cho tất cả những người vận hành nút. Họ phải cập nhật phần mềm, theo dõi các thay đổi, và đối mặt với rủi ro mất tiền nếu họ ở phía sai.
Tôi từng viết một báo cáo dài 20 trang về thất bại của Terra Luna, trong đó tôi chỉ ra 7 lỗi thiết kế trong oracle và cơ chế thanh lý. Bài báo đó được chia sẻ hơn 500 lần trên Twitter. Mọi người thích nó vì nó phân tích kỹ thuật, không phải vì nó đưa ra một quan điểm chính trị. Với hard fork của Chris Guida, tôi không có đủ thông tin để viết một báo cáo tương tự. Tôi chỉ có thể nói rằng: hãy đọc code. Hãy tự hỏi các câu hỏi đúng. Đừng tin vào white paper, hãy đọc code. Nhưng đó là câu nói dành cho mạng xã hội. Với những ai thực sự muốn hiểu, tôi khuyên nên build từ mã nguồn và so sánh bytecode với bản phát hành.
Trong một thị trường bò, khi mọi người đang FOMO và chạy theo các đồng coin tăng giá, những vấn đề kỹ thuật kiểu này bị đẩy xuống dưới. Nhưng tôi đã sống qua nhiều chu kỳ. Tôi biết rằng sự phấn khích của thị trường tăng che giấu lỗi kỹ thuật. Người ta sẽ không nhìn vào cách một hard fork được rebase một cách cẩu thả cho đến khi nó gây ra sự cố. Và khi nó gây ra sự cố, sẽ quá muộn để sửa. Hãy nhìn vào các vụ hack trong DeFi. Hầu hết đều xuất phát từ những lỗi vô cùng đơn giản: một hàm thiếu kiểm tra quyền, một biến không được khởi tạo, một phép tính sai. Tất cả đều có thể tìm thấy nếu ai đó chạy fuzz test trong một tuần. Nhưng họ không làm. Bởi vì họ vội.
Với hard fork PoW, sự vội vàng còn nguy hiểm hơn. Bởi vì bạn không chỉ mất tiền của người dùng, bạn còn phá vỡ niềm tin vào toàn bộ hệ sinh thái. Khi một nút chạy phần mềm do Chris Guida phát hành và một nút khác chạy phần mềm gốc, nếu chúng không đồng bộ với nhau, mạng sẽ bị chia cắt. Sẽ có hai blockchain cùng tồn tại, mỗi bên có một lịch sử khác nhau. Và điều đó có nghĩa là có một giao dịch được xác nhận trên mạng này nhưng không có trên mạng kia. Với những người vận hành sàn giao dịch, đây là một thảm họa. Họ sẽ phải tạm dừng nạp rút, gây ra sự hoảng loạn.
Vậy câu hỏi đặt ra là: Chris Guida có đủ năng lực để thực hiện một việc phức tạp như vậy không? Tôi không biết. Tôi chưa từng gặp anh ấy. Tôi chưa từng review code của anh ấy. Nhưng tôi biết rằng những người làm hard fork thành công thường có một đội ngũ lớn, một quy trình phát triển chặt chẽ, và một cộng đồng sẵn sàng thử nghiệm. Nếu anh ấy làm một mình, rủi ro sẽ rất cao. Không phải vì anh ấy kém, mà vì cách con người hoạt động. Chúng ta đều có những điểm mù. Chúng ta không thể nhìn thấy lỗi của chính mình. Hệ thống kiểm soát phiên bản giúp chúng ta theo dõi sự thay đổi, nhưng không giúp chúng ta hiểu được sự tương tác giữa các thành phần.
Điều này đưa tôi đến một khía cạnh mà tôi gọi là “sự phản trực giác của hard fork”. Nhiều người tin rằng một hard fork sẽ tạo ra nhiều lựa chọn hơn, làm tăng tính phân quyền. Nhưng trên thực tế, một hard fork thường dẫn đến sự tập trung quyền lực vào những người kiểm soát cơ sở hạ tầng quan trọng: các sàn giao dịch, các nhà cung cấp dịch vụ đặt cược, các công ty khai thác lớn. Những thực thể này có thể quyết định bên nào sống, bên nào chết. Và họ không quyết định dựa trên mã nguồn tốt hay xấu, mà dựa trên lợi nhuận. Vì vậy, một hard fork được thúc đẩy vì lý do kỹ thuật thuần túy thường thất bại trước một hard fork được thúc đẩy vì lợi ích kinh tế.
Liệu Chris Guida có đang làm điều đó để chống lại một thay đổi nào đó trong Bitcoin hay không? Có thể. Nhưng tôi sẽ không đi sâu vào chính trị. Tôi chỉ muốn nói về kỹ thuật. Và về mặt kỹ thuật, rebase là một phần tất yếu trong vòng đời của phần mềm. Nó giúp duy trì khả năng tương thích với các thay đổi hạ nguồn. Nó cũng có thể gây ra các lỗi mới. Và để phát hiện các lỗi đó, bạn cần một quy trình kiểm thử nghiêm ngặt. Bạn cần phải chạy các nút trên nhiều hệ điều hành, nhiều kiến trúc CPU, nhiều phiên bản trình biên dịch. Bạn cần phải so sánh kết quả. Bạn cần phải chấp nhận rằng bạn có thể đã sai.
Nếu bạn không làm điều đó, bạn đang đặt cược toàn bộ tài sản của những người dùng vào một canh bạc không đáng. Tôi đã thấy nhiều dự án như vậy. Họ gây quỹ hàng triệu đô la, họ có một đội ngũ toàn sao, họ công bố lộ trình hoành tráng. Nhưng khi tôi nhìn vào code, tôi thấy những lỗi mà một sinh viên năm nhất cũng có thể tránh được. Họ không quan tâm đến chất lượng. Họ chỉ quan tâm đến việc đưa sản phẩm ra thị trường trước đối thủ. Và kết quả là thảm họa. Thị trường bò hiện tại chỉ càng khiến tình hình tồi tệ hơn, vì ai cũng muốn nhanh chóng.
Bài học tôi học được từ năm 2017 đến nay là: trong thế giới blockchain, sự kiên nhẫn là một lợi thế cạnh tranh. Ai có thể dành thêm một tuần để kiểm thử, người đó tránh được một vụ sập. Ai có thể dành thêm một tuần để viết thêm các test case, người đó có thể cứu được hàng triệu đô la. Đó là lý do tôi luôn nói rằng audit không đủ. Audit là quá trình con người đọc code để tìm lỗi. Nhưng con người thì mệt mỏi, thiên vị, và dễ bỏ sót. Fuzz testing là quá trình máy móc tìm ra lỗi một cách ngẫu nhiên. Máy không mệt mỏi, máy không thiên vị. Máy có thể chạy hàng triệu test case trong một đêm. Nếu bạn chỉ làm audit, bạn đang để lỗi ở đó chờ bạn. Nếu bạn làm fuzz testing, bạn đang chủ động đi săn lỗi.
Vậy, với hard fork của Chris Guida, tôi có lời khuyên gì? Hãy chạy fuzz test trên các thành phần đồng thuận. Hãy tạo ra các khối không hợp lệ và xem nút của bạn có từ chối chúng không. Hãy thay đổi độ khó và xem nút của bạn có tính toán lại đúng không. Hãy kiểm tra các tình huống cực đoan: một khối có 0 giao dịch, một khối có hàng nghìn giao dịch, một khối có coinbase chi tiêu một UTXO không tồn tại. Các bài test đó sẽ cho bạn biết nhiều hơn bất kỳ một bản audit nào.
Tôi không có ân hận gì khi dành thời gian để viết những điều này. Bởi vì tôi biết rằng nếu dự án này thất bại, nó sẽ không phải là dự án đầu tiên, cũng không phải là cuối cùng. Nhưng nếu tôi có thể giúp một ai đó nhìn ra tầm quan trọng của việc kiểm thử kỹ lưỡng, thì thời gian của tôi không bị lãng phí. Nền tảng của blockchain là niềm tin. Niềm tin không đến từ khẩu hiệu, mà đến từ việc code hoạt động đúng như những gì nó tuyên bố. Và code, như tôi đã nói, không bao giờ nói dối. Nhưng nó cũng không bao giờ tự giải thích.
Vì vậy, hãy tự mình xây dựng, tự mình kiểm tra. Đừng tin vào bất kỳ ai, kể cả tôi. Hãy tự chạy node, tự đọc log, tự so sánh kết quả. Khi bạn làm vậy, bạn sẽ thấy rằng thị trường bò hay gấu không quan trọng. Quan trọng là bạn có hiểu những gì bạn đang chạy hay không. Hard fork PoW của Chris Guida có thể là một dự án thú vị, hoặc có thể là một thảm họa chờ xảy ra. Tôi không có đủ thông tin để kết luận. Nhưng tôi có thể kết luận một điều: nếu nó được xây dựng bằng sự cẩu thả, nó sẽ sụp đổ. Và nếu nó sụp đổ, đừng ngạc nhiên. Vì ngay từ đầu, mọi thứ đã có thể nhìn thấy được trong code rồi.