Một trong những người từng đặt nền móng cho XRP Ledger lại gọi kế hoạch mở rộng mới nhất của nó là 'ý tưởng tồi tệ nhất có thể'. Matt Hamilton, cựu kỹ sư trưởng của Ripple, vừa công khai chỉ trích một đề xuất sửa đổi giao thức mà theo ông sẽ phá hủy điều khiến XRPL trở nên đặc biệt. Điều gì đã chạm đến giới hạn của một người đã dành cả thập kỷ để xây dựng hệ thống này?
Trước khi đi vào chi tiết, cần hiểu XRPL là gì. XRP Ledger là một blockchain L1 tập trung vào thanh toán, nổi tiếng với tốc độ giao dịch nhanh (3-5 giây) và phí cực thấp (dưới 0,001 USD). Không giống như Ethereum hay Solana, XRPL không sử dụng cơ chế đào hay staking. Thay vào đó, nó dùng một mạng lưới các nút xác thực (validator) được vận hành bởi các tổ chức độc lập trên toàn cầu. Điểm mấu chốt: bất kỳ ai cũng có thể chạy một nút XRPL trên một máy tính thông thường. Đây là yếu tố cốt lõi tạo nên tính phi tập trung của nó.
Cơ chế sửa đổi (Amendment) của XRPL yêu cầu 80% validator bỏ phiếu thuận trong hai tuần liên tiếp để kích hoạt thay đổi. Đây là một trong những cơ chế quản trị khắt khe nhất trong ngành. Và chính cơ chế này đang được thử thách bởi một đề xuất gây tranh cãi: buộc tất cả các nút phải lưu trữ vĩnh viễn các tệp phương tiện lớn — như hình ảnh, video, tài liệu — ngay trên lớp đồng thuận.
Hãy tưởng tượng bạn đang vận hành một nút XRPL trên một chiếc máy tính để bàn với ổ cứng 2TB. Hiện tại, toàn bộ lịch sử sổ cái chỉ chiếm vài trăm GB. Đề xuất này có thể đẩy yêu cầu lên hàng chục TB chỉ sau vài tháng, nếu có nhiều giao dịch media được thực hiện.
Tôi đã từng chứng kiến những kịch bản tương tự trong quá trình audit các dự án ICO năm 2017. Khi một giao thức cố gắng nhồi nhét quá nhiều chức năng vào lớp cơ sở mà không có kế hoạch kinh tế rõ ràng, hậu quả thường là sự tập trung hóa. Một dự án lưu trữ từng hứa hẹn 'dữ liệu bất biến trên blockchain' nhưng sau một năm, chỉ còn ba nút vận hành vì chi phí quá cao. Đề xuất của XRPL có nguy cơ đi vào vết xe đổ đó.
Có khi nào bạn tự hỏi tại sao cùng một thuật toán nhưng trong môi trường này lại chết yểu? Vì các nhà thiết kế giao thức thường bỏ qua chi phí vận hành thực tế. Một tệp 100MB được lưu trữ trên 1.000 nút đồng nghĩa với 100TB dung lượng bị chiếm dụng. Với mức giá ổ cứng trung bình 20 USD/TB, đó là 2.000 USD chi phí một lần — nhưng hóa đơn điện và băng thông cho việc đồng bộ hóa các tệp này mỗi khi có nút mới tham gia mới là vấn đề thực sự. Không có cơ chế khuyến khích nào được đề cập để bù đắp chi phí này.
Sự khác biệt giữa lý thuyết và thực hành nằm ở chỗ bạn không thể ép buộc các nút nhỏ phải gánh vác trách nhiệm mà không có phần thưởng tương xứng. Trong XRPL, validator không nhận phí giao dịch (phí được đốt). Vậy ai sẽ trả tiền cho việc lưu trữ hàng TB dữ liệu? Nếu không có câu trả lời, đề xuất này chỉ có thể tồn tại nếu các nút trở nên đủ lớn — và đủ giàu — để chịu đựng chi phí. Điều đó đồng nghĩa với việc các nút nhỏ sẽ bị loại khỏi cuộc chơi.
Matt Hamilton đã nói thẳng: 'Đây là một ý tưởng thực sự tồi tệ.' Và ông ấy có lý do chính đáng. Điều này giống như việc yêu cầu mọi thư viện công cộng phải lưu trữ một bản sao của mọi bộ phim Hollywood — không chỉ là bất khả thi về mặt chi phí, mà còn đi ngược lại mục đích của thư viện. XRPL được thiết kế để xử lý thanh toán nhanh, rẻ, phi tập trung. Nó không phải Arweave, không phải Filecoin, cũng không phải một nền tảng lưu trữ phi tập trung.
Góc nhìn phản trực giác: Tuy nhiên, tôi cho rằng cộng đồng XRPL đang bỏ qua một điểm mù quan trọng. Đề xuất này có thể mang lại lợi ích cho các ứng dụng NFT và GameFi trên XRPL — lĩnh vực đang phát triển nhanh. Việc lưu trữ media trực tiếp trên L1 giúp xác thực nguồn gốc và tính bất biến một cách dễ dàng. Nhưng chi phí ẩn của việc này là sự xói mòn niềm tin vào tính phi tập trung. Nếu chỉ có các tổ chức lớn mới có thể chạy nút, thì XRPL sẽ mất đi một trong những lợi thế cạnh tranh lớn nhất của nó so với các blockchain khác: khả năng chống kiểm duyệt từ một mạng lưới rộng khắp các nút độc lập.
Tôi từng tham gia một cuộc thảo luận kỹ thuật về thiết kế sequencer cho một layer2. Một thành viên trong nhóm đề xuất lưu trữ dữ liệu giao dịch trực tiếp trên Ethereum L1 để 'tăng tính bảo mật'. Phân tích của tôi cho thấy chi phí gas sẽ tăng gấp 10 lần và thời gian xác nhận kéo dài. Cuối cùng, chúng tôi chọn giải pháp lưu trữ ngoài chuỗi với bằng chứng mật mã. Bài học: không phải lúc nào 'lưu trữ trên L1' cũng là giải pháp tốt nhất, đặc biệt khi nó phá vỡ các giả định thiết kế ban đầu.
Quay lại đề xuất XRPL, tôi tin rằng 80% những người ủng hộ nó chưa từng vận hành một nút XRPL nào. Họ nhìn thấy cơ hội từ góc độ ứng dụng, nhưng bỏ qua thực tế vận hành. Một validator chạy trên máy chủ AWS với ổ SSD 1TB có thể đối mặt với hóa đơn tăng gấp đôi hoặc gấp ba nếu phải lưu trữ media. Nếu không có kế hoạch bồi thường, những validator này sẽ rời bỏ mạng, và sự tập trung hóa bắt đầu.
Contrarian angle: Liệu có cách nào dung hòa? Một số người đề xuất lưu trữ media trên IPFS hoặc Arweave, chỉ giữ hash trên XRPL. Đây là giải pháp thông minh hơn nhiều. Nhưng nếu vậy, tại sao lại cần một amendment phức tạp đến vậy? Có lẽ động lực thực sự đến từ một nhóm dự án trong hệ sinh thái muốn 'giữ chân người dùng' bằng cách không phụ thuộc vào dịch vụ bên ngoài. Tuy nhiên, điểm mù của họ là đánh giá thấp sự phản kháng từ cộng đồng validator và các nhân vật kỳ cựu như Matt Hamilton.
Takeaway: Nếu một blockchain sẵn sàng hy sinh khả năng chống kiểm duyệt để có thêm tính năng, liệu nó còn xứng đáng được gọi là blockchain? XRPL đang đứng trước một ngã rẽ. Đề xuất này khó có thể vượt qua ngưỡng 80% validator, nhưng nếu nó thành công, XRPL sẽ mất đi bản sắc cốt lõi. Tôi sẽ theo dõi chặt chẽ cuộc bỏ phiếu — nó sẽ là một bài kiểm tra về mức độ trưởng thành của quản trị phi tập trung.
