Tôi thường thảo luận với những người trong ngành về một chủ đề: những cái bẫy dễ mắc phải nhất trong các dự án lưu trữ phi tập trung không nằm ở việc tải lên ban đầu có phiền phức hay không. Thực sự gây chết người là điều này—— sau một hoặc hai năm vận hành, các nút mạng liên tục vào ra, ổ cứng hỏng hóc, dao động mạng, di chuyển trung tâm dữ liệu… Những "mài mòn" tưởng chừng như hàng ngày này dần dần xói mòn lợi nhuận, cuối cùng dự án buộc phải tăng giá hoặc chỉ còn cách giảm thiểu bảo mật. Vòng lặp chết này gần như trở thành một lời nguyền trong ngành.
Gần đây, khi xem cơ chế phục hồi của Walrus, tôi nhận ra nó đã đi theo một hướng khác. Thiết kế Red Stuff của nó có một đặc điểm then chốt: băng thông phục hồi dữ liệu bị mất, được tính theo tỷ lệ chính xác với lượng dữ liệu mất—nói cách khác, mất bao nhiêu khối dữ liệu thì bù đắp bấy nhiêu, không cần phải di chuyển toàn bộ dữ liệu để sửa chữa chỉ vài mảnh vỡ. Nghe có vẻ đơn giản, nhưng điều này có ý nghĩa gì?
Nó có nghĩa là chi phí sửa chữa giảm ngược lại khi số lượng nút tham gia tăng lên. Các chỉ số kỹ thuật rõ ràng: băng thông mỗi nút dành cho phục hồi có thể giảm xuống mức O(|blob|/n). Mạng lưới càng lớn, càng nhiều nút, chi phí đơn vị càng ngày càng mỏng đi. Điều này cực kỳ quan trọng đối với mạng mở—bởi vì việc nút vào ra là chuyện thường ngày, nếu chi phí sửa chữa không giảm theo quy mô, sớm muộn gì cũng sẽ xuất hiện tình trạng "hóa đơn sửa chữa còn đắt hơn phí lưu trữ".
Logic này khi áp dụng vào thực tế sẽ mang lại điều gì? Trước tiên là sự ổn định về giá. Việc sửa chữa không còn là lỗ hổng vận hành, dự án không còn lý do để liên tục tăng giá hoặc cắt giảm dư thừa để "duy trì". Thứ hai là nâng cao khả năng sử dụng. Quy trình sửa chữa nhẹ nhàng hơn, trở nên thường xuyên hơn, hệ thống có thể nhanh chóng khắc phục các lỗ hổng dữ liệu, giảm thiểu khả năng người dùng gặp phải tình trạng "không đọc được". Nói sâu hơn, đây mới đúng là hạ tầng phù hợp cho các ứng dụng dài hạn—dù bạn lưu trữ dữ liệu huấn luyện AI, tài nguyên game chuỗi, trang web frontend, hay lưu trữ nội dung dạng hồ sơ, điều cần không phải là thành công một lần mà là có thể vận hành ổn định trong 5, 10 năm.
Vì vậy, tôi xem Walrus không chỉ để biết "lưu trữ được bao lâu", mà còn để xem "khi hỏng có thể sửa chữa với chi phí thấp không, và càng chạy càng ổn định". Red Stuff thiết kế chi phí phục hồi giảm theo quy mô mạng thực chất là đang chuẩn bị nền móng cho khả năng tồn tại lâu dài của dự án này. Cách thiết kế này chính là lý do tại sao lưu trữ phi tập trung mới có thể sống sót và phát triển bền vững.
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Thôi bỏ đi, lại là một giải pháp vá víu, thật sự có thể dùng trong năm năm hay mười năm thì hãy nói sau
---
O(|blob|/n) Bộ môn toán này trông đẹp đấy, nhưng các nút mạng thật sự chạy được bao lâu nữa?
---
Chết rồi, cuối cùng cũng có người nói rõ về chi phí sửa chữa, các dự án khác đều tránh né vấn đề này
---
Nói đơn giản là tiết kiệm tiền, nghe có vẻ ổn nhưng tôi vẫn muốn xem báo cáo tài chính sau nửa năm hoạt động
---
Logic này dù sao cũng tốt hơn tình trạng chết tiệt của Filecoin hiện tại nhiều
---
Nút mạng càng nhiều thì chi phí càng thấp? Khoan đã, cơ chế khuyến khích được thiết lập như thế nào, liệu có phải chăng sẽ không ai muốn chạy nút mạng nữa không?
---
Tôi chỉ muốn biết khi nào Walrus có thể đi vào thực tế, đừng lại là lưu trữ PPT nữa
Xem bản gốcTrả lời0
LiquidityWizard
· 15giờ trước
卧槽,终于有人把这个点说透了。其他项目都在扯"去中心化"的皮,Walrus这套设计才是真正戳中要害
修复成本随节点数递减?这不就是越大越便宜吗,妙啊
之前那些存储项目就是这么崩的,修着修着钱烧没了
Red Stuff这个思路确实不一样,难怪要重点研究一下
终于看到有人深度复盘存储项目的运营困局了,绝了
这个O(|blob|/n)的逻辑一旦跑起来,整个网络的韧性就不一样了
就怕节点波动频繁还是会出幺蛾子,Walrus这套能顶住吗
长期来看,修复成本下降这个设计确实是基础设施级别的思考
Trả lời0
gaslight_gasfeez
· 15giờ trước
Vấn đề vòng lặp chết của lưu trữ phi tập trung thực sự rất đáng chú ý, ý tưởng thiết kế giảm chi phí sửa chữa theo chiều ngược lại tôi cần phải suy nghĩ kỹ hơn
Chi phí sửa chữa hóa đơn còn đắt hơn phí lưu trữ, câu chuyện này quá chân thực haha
Ý tưởng của Walrus về (|blob|/n) thực sự khác biệt, càng nhiều nút thì chi phí càng thấp, ngược lại đây chính là một hệ thống khuyến khích
Nói về kiểu thiết kế này có thể thực sự triển khai được không, cảm giác vẫn phải dựa vào dữ liệu sau khi thực hiện mới nói được
Độ tin cậy lâu dài > bùng nổ ngắn hạn, điều này mới là chân lý trong lĩnh vực lưu trữ
Tôi thường thảo luận với những người trong ngành về một chủ đề: những cái bẫy dễ mắc phải nhất trong các dự án lưu trữ phi tập trung không nằm ở việc tải lên ban đầu có phiền phức hay không. Thực sự gây chết người là điều này—— sau một hoặc hai năm vận hành, các nút mạng liên tục vào ra, ổ cứng hỏng hóc, dao động mạng, di chuyển trung tâm dữ liệu… Những "mài mòn" tưởng chừng như hàng ngày này dần dần xói mòn lợi nhuận, cuối cùng dự án buộc phải tăng giá hoặc chỉ còn cách giảm thiểu bảo mật. Vòng lặp chết này gần như trở thành một lời nguyền trong ngành.
Gần đây, khi xem cơ chế phục hồi của Walrus, tôi nhận ra nó đã đi theo một hướng khác. Thiết kế Red Stuff của nó có một đặc điểm then chốt: băng thông phục hồi dữ liệu bị mất, được tính theo tỷ lệ chính xác với lượng dữ liệu mất—nói cách khác, mất bao nhiêu khối dữ liệu thì bù đắp bấy nhiêu, không cần phải di chuyển toàn bộ dữ liệu để sửa chữa chỉ vài mảnh vỡ. Nghe có vẻ đơn giản, nhưng điều này có ý nghĩa gì?
Nó có nghĩa là chi phí sửa chữa giảm ngược lại khi số lượng nút tham gia tăng lên. Các chỉ số kỹ thuật rõ ràng: băng thông mỗi nút dành cho phục hồi có thể giảm xuống mức O(|blob|/n). Mạng lưới càng lớn, càng nhiều nút, chi phí đơn vị càng ngày càng mỏng đi. Điều này cực kỳ quan trọng đối với mạng mở—bởi vì việc nút vào ra là chuyện thường ngày, nếu chi phí sửa chữa không giảm theo quy mô, sớm muộn gì cũng sẽ xuất hiện tình trạng "hóa đơn sửa chữa còn đắt hơn phí lưu trữ".
Logic này khi áp dụng vào thực tế sẽ mang lại điều gì? Trước tiên là sự ổn định về giá. Việc sửa chữa không còn là lỗ hổng vận hành, dự án không còn lý do để liên tục tăng giá hoặc cắt giảm dư thừa để "duy trì". Thứ hai là nâng cao khả năng sử dụng. Quy trình sửa chữa nhẹ nhàng hơn, trở nên thường xuyên hơn, hệ thống có thể nhanh chóng khắc phục các lỗ hổng dữ liệu, giảm thiểu khả năng người dùng gặp phải tình trạng "không đọc được". Nói sâu hơn, đây mới đúng là hạ tầng phù hợp cho các ứng dụng dài hạn—dù bạn lưu trữ dữ liệu huấn luyện AI, tài nguyên game chuỗi, trang web frontend, hay lưu trữ nội dung dạng hồ sơ, điều cần không phải là thành công một lần mà là có thể vận hành ổn định trong 5, 10 năm.
Vì vậy, tôi xem Walrus không chỉ để biết "lưu trữ được bao lâu", mà còn để xem "khi hỏng có thể sửa chữa với chi phí thấp không, và càng chạy càng ổn định". Red Stuff thiết kế chi phí phục hồi giảm theo quy mô mạng thực chất là đang chuẩn bị nền móng cho khả năng tồn tại lâu dài của dự án này. Cách thiết kế này chính là lý do tại sao lưu trữ phi tập trung mới có thể sống sót và phát triển bền vững.