Báo cáo vừa tung ra từ Fireblocks khiến cõi mạng xôn xao. Châu Âu và Anh thích giải pháp full-stack cho hạ tầng tiền mã hóa. An toàn hơn. Rõ ràng hơn. Và họ đòi hỏi giám sát chặt chẽ.
Tôi đọc đi đọc lại bản tin. Chẳng có một dòng code. Chẳng có một số liệu vận hành. Không TPS, không độ trễ, không kiến trúc. Chỉ có một thông điệp: 'Tổ chức tài chính muốn mua trọn gói'.
Với một người đã audit smart contract từ thời ICO 2017, tôi có một thói quen: trước khi phán xét, phải xác minh. Và bản tin này không cho tôi thứ gì để xác minh cả.
Bối cảnh: 'Full-stack' nghĩa là gì trong thế giới tiền mã hóa?
Trong kỹ thuật phần mềm, full-stack nghĩa là bạn có frontend, backend, database, và tất cả chạy trong cùng một hệ thống. Trong hạ tầng tiền mã hóa cho tổ chức, full-stack nghĩa là một công ty bán cho bạn mọi thứ: ví, lưu ký, thanh toán, tuân thủ, báo cáo, token hóa.
Fireblocks đứng ở vị trí này. Họ đi từ công cụ lưu ký dùng MPC - multi-party computation, hay tính toán đa bên - cho tới mạng lưới chuyển tiền giữa các tổ chức.
Vấn đề nằm ở chỗ: khi bạn mua full-stack từ một nhà cung cấp duy nhất, bạn giao phó toàn bộ tài sản kỹ thuật số của mình cho một hệ thống khép kín. Ví dụ, nếu Fireblocks gặp sự cố ở lớp thanh toán, toàn bộ chuỗi cung ứng dịch vụ của bạn đứng yên.
Năm 2021, Fireblocks từng tiết lộ một lỗ hổng cơ sở dữ liệu. Đó là chuyện công khai, mọi người trong nghề đều biết. Không phải để bới móc, nhưng một hệ thống full-stack lại càng cần được kiểm tra độc lập thường xuyên hơn.
Đi vào chi tiết: Tại sao tôi không thể đánh giá báo cáo này?
Một bài viết kỹ thuật tốt cần tối thiểu ba thứ: kiến trúc, số liệu, và kịch bản thử nghiệm.
Báo cáo Fireblocks nói về 'nhu cầu bảo mật tăng cao'. Nói về 'mong muốn giám sát rõ ràng'. Nhưng không hề công bố một sơ đồ kiến trúc nào.
Nếu tôi là một kiến trúc sư hạ tầng tại ngân hàng, tôi sẽ đặt câu hỏi: lớp nào dùng MPC? Khóa nào do khách hàng nắm giữ, khóa nào do Fireblocks nắm? Khi chuyển tiền giữa hai ngân hàng qua Fireblocks Network, bản chất có phải là một sổ cái nội bộ không?
Đó là câu hỏi sống còn.
Nếu Fireblocks chỉ là một lớp trung gian ghi nhận 'A chuyển cho B 100 USDC' trong hệ thống riêng của họ, rồi định kỳ thanh toán ròng trên chuỗi, thì rủi ro đối tác cực kỳ lớn. Còn nếu mỗi giao dịch đều được settle ngay lập tức trên blockchain công khai, rủi ro thấp hơn nhiều.
Báo cáo không trả lời. Nhà báo cũng không hỏi.
Điểm mù bảo mật mà mọi người thường bỏ qua
Điều tôi thấy đáng lo nhất không nằm ở công nghệ. Nó nằm ở câu chuyện 'full-stack' đang được dùng để đánh vào nỗi sợ của ngân hàng.
Nỗi sợ đó là: phải tự ráp nối nhiều nhà cung cấp, nhiều contract, nhiều chuẩn bảo mật khác nhau. Rối. Đau đầu. Sợ sai sót.
Fireblocks nói: Cứ để chúng tôi lo.
Nghe có vẻ hợp lý. Nhưng hãy nhìn vào lịch sử ngành ngân hàng. Năm 2008, khủng hoảng tài chính bắt nguồn từ việc quá nhiều rủi ro dồn vào những 'cỗ máy full-stack' được cho là quá lớn để sụp đổ.
Trong thế giới tiền mã hóa, nguyên tắc cốt lõi là không cần tin tưởng. Bạn không cần tin ngân hàng, không cần tin sàn giao dịch. Bạn tự kiểm soát khóa của mình.
Bây giờ, nếu các tổ chức lớn dồn toàn bộ tài sản vào một Fireblocks - một công ty tư nhân, một cơ sở dữ liệu tập trung - thì chúng ta đang tái tạo lại chính hệ thống mà chúng ta muốn thay thế.
Đó là điểm mù trong báo cáo.
Toàn bộ lập luận 'full-stack' dựa trên giả định rằng một nhà cung cấp lớn sẽ an toàn hơn nhiều nhà cung cấp nhỏ. Giả định đó chưa từng được kiểm chứng trong lĩnh vực hạ tầng tiền mã hóa.
Câu chuyện thực tế từ góc nhìn của tôi
Năm 2020, khi tôi tự viết công cụ phân tích tĩnh bằng Python và Slither để kiểm tra contract DeFi, tôi phát hiện một vấn đề về tính toán phí trong pool thanh khoản thấp trên Uniswap V2.
Tôi gửi issue lên GitHub. Đội ngũ Uniswap phản hồi tích cực.
Điều tôi học được: lỗi không nằm ở đâu xa. Nó nằm trong những chi tiết tưởng chừng như nhỏ nhặt. Một phép nhân bị đảo thứ tự. Một phép so sánh thiếu điều kiện biên.
Báo cáo của Fireblocks không hề đụng tới những chi tiết như vậy. Nó chỉ nói về 'xu hướng'.
Tôi không phản đối full-stack. Tôi phản đối việc chúng ta tin vào một báo cáo marketing mà không có mã nguồn để kiểm tra.
Trong 26 năm quan sát ngành công nghiệp blockchain, tôi nhận ra một quy luật: những thứ thực sự hoạt động đều có thể được kiểm chứng. Nếu bạn không thể kiểm chứng, hãy coi đó là một quảng cáo, không phải một báo cáo kỹ thuật.
Kịch bản: Nếu full-stack là tương lai, ai sẽ chịu rủi ro?
Giả sử mọi ngân hàng châu Âu đều dùng Fireblocks. Giả sử Fireblocks xử lý hàng trăm tỷ đô la tài sản.
Một ngày đẹp trời, có một lỗi logic trong module tính phí. Hoặc một lỗi trong MPI - giao diện lập trình thanh toán. Hoặc đơn giản là một quản trị viên nội bộ bị lừa chuyển tiền.
Hậu quả không chỉ dừng ở một ngân hàng. Nó lan truyền qua hệ thống full-stack dùng chung.
Đó là lý do vì sao các tổ chức tài chính lớn thường có yêu cầu rất kỹ về kiểm toán độc lập, về ủy quyền đa chữ ký, về việc chia tách nhiệm vụ.
Nhưng cái giá của sự an toàn là sự phức tạp. Và báo cáo Fireblocks đang hứa hẹn một thứ nghe như 'an toàn mà không cần phức tạp'.
Tôi chưa thấy điều kỳ diệu nào như vậy trong đời làm kỹ thuật.
Điều gì thực sự quan trọng đối với một nhà phát triển giao thức
Nếu bạn là một nhà phát triển đang cân nhắc tích hợp Fireblocks hoặc một nền tảng full-stack tương tự, hãy đặt những câu hỏi sau:
Một, địa chỉ hợp đồng thông minh mà nền tảng dùng là gì? Nếu không có địa chỉ contract công khai, làm sao tôi tự kiểm tra?
Hai, nhà cung cấp có hỗ trợ mô hình không cần tin tưởng - trustless - không? Nếu tôi không giữ khóa riêng, tôi không kiểm soát được tài sản.
Ba, khi tôi rút tiền khỏi nền tảng, thời gian trung bình là bao lâu? Có giới hạn rút tiền không? Điều gì xảy ra nếu nền tảng ngừng hoạt động?
Bốn, liệu có thể tự vận hành một phiên bản mã nguồn mở của hạ tầng này không? Nếu không, đó là khóa chặt độc quyền.
Tôi đã từng chứng kiến nhiều dự án xây dựng hạ tầng 'full-stack' và rồi thất bại vì một lý do cực kỳ trần tục: họ không thể chi trả chi phí vận hành.
Giống như ZK Rollup. Tôi viết một phiên bản zk-rollup mini bằng Rust trong bear market 2022. Chi phí chứng minh rất cao. Trừ khi gas quay lại mức bull market, các operator đang chảy máu tiền.
Full-stack cũng vậy. Duy trì một đội ngũ bảo mật, một hạ tầng tuân thủ ở nhiều quốc gia, một hệ thống hỗ trợ 24/7 - rất tốn kém.
Những startup nhỏ không thể theo nổi. Và khi một công ty độc quyền nắm giữ hạ tầng critical, họ có thể tăng giá bất cứ lúc nào.
Góc nhìn phản trực giác
Điều phản trực giác ở đây là: 'full-stack' nghe có vẻ an toàn hơn, nhưng thực tế nó tạo ra một điểm thất bại duy nhất - single point of failure.
Một hệ thống phi tập trung với nhiều nhà cung cấp, mỗi nhà cung cấp chuyên về một lớp, có thể chịu được một nhà cung cấp sụp đổ. Hệ thống full-stack thì không.
Báo cáo Fireblocks nói rằng 'các tổ chức châu Âu và Anh ưa thích giải pháp full-stack'.
Tôi tin rằng các tổ chức thực sự ưa thích điều đó - nhưng vì lý do ngân sách và nhân sự, không phải vì lý do kỹ thuật. Dễ dàng để đổ trách nhiệm lên một nhà cung cấp. Dễ dàng để nói với hội đồng quản trị rằng 'chúng tôi đã thuê một công ty lớn, uy tín'.
Nhưng rủi ro kỹ thuật thực sự không biến mất chỉ vì bạn ký hợp đồng với một công ty lớn.
Điều tôi muốn thấy trong các báo cáo tiếp theo
Nếu Fireblocks thực sự muốn thuyết phục cộng đồng kỹ thuật, họ nên công bố các thông tin sau:
Một, kiến trúc tổng thể: các thành phần, mô-đun, giao diện giữa các lớp.
Hai, mô hình chia khóa: ai giữ phần nào, quy trình khôi phục khóa ra sao.
Ba, cách xử lý khi có sự cố: làm sao người dùng rút tài sản trong trường hợp khẩn cấp.
Bốn, kết quả kiểm toán độc lập gần nhất.
Năm, số liệu vận hành thực tế: thời gian hoạt động, thời gian phản hồi, tỷ lệ giao dịch thất bại.
Không có những thứ đó, 'full-stack' chỉ là một từ khóa marketing.
Vậy chúng ta nên đọc báo cáo này như thế nào?
Tôi nghĩ nó có giá trị như một tín hiệu về định hướng thị trường. Các tổ chức tài chính đang muốn giảm độ phức tạp khi tham gia tiền mã hóa. Điều đó rất thực.
Nhưng giá trị của tín hiệu này chỉ dừng ở mức đó.
Nếu tôi là một quỹ đầu tư, tôi sẽ không thay đổi quyết định đầu tư chỉ vì một báo cáo từ một công ty có động cơ thúc đẩy sản phẩm của chính họ.
Tôi sẽ tìm kiếm dữ liệu độc lập. Tôi sẽ nói chuyện với các ngân hàng đã sử dụng Fireblocks và các ngân hàng đã từng dùng rồi bỏ. Tôi sẽ kiểm tra xem có bao nhiêu khách hàng thực sự triển khai full-stack end-to-end, chứ không phải chỉ dùng một phần.
Bởi vì trong kỹ thuật, hành vi thực tế luôn khác xa những gì mọi người nói trong bảng khảo sát.
Kết luận mở
Có một câu hỏi tôi luôn tự hỏi mỗi khi đọc bất kỳ báo cáo nào của một công ty về chính họ: Nếu sản phẩm thực sự tốt như vậy, tại sao họ không cho tôi nhìn vào mã nguồn?
Câu trả lời thường là: vì họ muốn giữ bí mật kinh doanh. Điều đó có thể hợp lý.
Nhưng trong một hệ sinh thái xây dựng trên nguyên tắc minh bạch, các tổ chức lớn đòi hỏi 'sự rõ ràng về quy định' - còn các kỹ sư như tôi đòi hỏi sự rõ ràng về kỹ thuật.
Nếu không có sự rõ ràng đó, thì thứ duy nhất tôi tin tưởng được là chính sự nghi ngờ của tôi.
Và như lịch sử 26 năm của tôi trong ngành đã chứng minh: nghi ngờ không bao giờ gây ra sự sụp đổ. Chính sự thiếu nghi ngờ mới khiến mọi thứ sụp đổ.