Nhắc đến phát triển ứng dụng on-chain, nhiều người bỏ qua một vấn đề lâu dài: dữ liệu và ứng dụng cùng lão hóa.
Tài sản trò chơi, siêu dữ liệu NFT, kết quả suy luận AI — những thứ này tích lũy mỗi ngày. Sau một năm, chỉ dữ liệu trạng thái cốt lõi đã có thể chất tới 20—40GB. Còn rắc rối hơn, chúng cần phải được truy cập thường xuyên, được sửa đổi, được xác minh. Đến giai đoạn sau, nhà phát triển thường bị buộc phải chọn cách cũ: sao lưu, di chuyển, xây dựng lại chỉ mục. Quy trình này vừa tốn kém vừa kém hiệu quả, điều tệ nhất là tính toàn vẹn của dữ liệu lịch sử không thể được đảm bảo.
Gần đây có một ý tưởng mới xuất hiện, thay đổi tình trạng này.
Sự khác biệt chính là không đơn giản là nhồi dữ liệu vào rồi xong. Mà là để dữ liệu và khả năng xác minh gắn kết với nhau. Mỗi đối tượng khi được tạo ra đã nhận được một danh tính ổn định, những thay đổi trạng thái tiếp theo xảy ra bên trong đối tượng này, không cần phá hủy cấu trúc ban đầu.
Kết quả là gì? Dù dữ liệu có lớn bao nhiêu, tần suất cập nhật có mạnh bao nhiêu, hệ thống vẫn có thể đảm bảo những điểm này: địa chỉ đối tượng luôn không thay đổi, trạng thái lịch sử hoàn toàn có thể theo dõi được, dự phòng đa nút dưới kiến trúc có tính khả dụng vượt quá 99%, độ trễ đọc song song duy trì ở mức độ giây.
Tác động lên nhà phát triển thực sự khá lớn. Khi dữ liệu của bạn được đặt trong hệ thống lưu trữ như vậy, bạn có thể yên tâm hơn khi thiết kế logic lặp lại, không phải lúc nào cũng lo lắng rằng một sửa đổi sẽ phá hủy toàn bộ trạng thái on-chain.
Lợi ích thực tế có một vài cái:
**Chi phí thấp hơn** Dữ liệu một khi được lưu vào đã có tính khả xác minh dài hạn, tiết kiệm rất nhiều rắc rối về di chuyển, sao lưu và quản lý phiên bản.
**Tần suất truy cập không phải là nút cổ chai** Đọc ghi tần suất cao được hỗ trợ natively trong kiến trúc này, sẽ không tạo ra đối tượng mới hoặc kích hoạt các hoạt động on-chain bổ sung vì cập nhật.
**Truy cập lịch sử không còn là vấn đề khó** Chuỗi tiến hóa trạng thái hoàn chỉnh được giữ lại, truy vấn dữ liệu lịch sử không cần bảo trì chỉ mục bổ sung.
Đưa ra một góc nhìn khác, điều này thay đổi tâm lý của nhà phát triển về quản lý dữ liệu. Trước đây luôn ở thế phòng thủ — phòng chống dữ liệu bị hỏng, phòng chống chi phí bảo trì tăng vọt. Bây giờ có thể chuyển sang thiết kế chủ động, vì logic lưu trữ cấp độ dưới đã giúp bạn giải quyết những điểm đau này.
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.
15 thích
Phần thưởng
15
6
Đăng lại
Retweed
Bình luận
0/400
CoffeeNFTs
· 01-08 03:38
Không thể phủ nhận, giải pháp này thực sự chạm đúng vào điểm đau của chúng ta
Vấn đề dữ liệu lỗi thời thật sự làm đau đầu các nhà phát triển, bộ quy trình trước đó quá phức tạp đến mức chết đi được
Điều cốt lõi là ý tưởng cố định danh tính đối tượng này, cuối cùng đã có người nghĩ thấu đáo vấn đề này
Lịch sử hoàn toàn có thể truy xuất và chi phí giảm xuống, đó mới là giá trị thực sự
Trước đây chỉ nghĩ làm sao để dữ liệu không bị sập, giờ có thể tập trung vào việc phát triển sản phẩm, cảm giác như được giải phóng
Xem bản gốcTrả lời0
JustHereForAirdrops
· 01-07 20:50
Cuối cùng có người nói ra điều này, tôi ngày nào cũng bị cái chuyện vớ vẩn này hành hạ.
Xem bản gốcTrả lời0
SigmaBrain
· 01-07 20:50
卧槽这才是真正的痛点啊,以前天天为了数据迁移掉头发。
等等,这套逻辑是不是就是immutable object那一套,把状态变化内化了?感觉有点东西。
开发者终于不用活在恐惧里了,牛逼。
这要是真的能做到99%可用性...我有点信了。
Dữ liệu một khi đã vào thì có thể xác thực, không cần phải lặp lại việc chỉnh sửa chỉ mục? Theo kinh nghiệm của tôi, nghe có vẻ hơi quá đẹp để là sự thật.
Nói thật, so với những khái niệm mới rực rỡ, những thứ giải quyết điểm đau thực tế này càng hiếm hơn.
Chìa khóa là tiết kiệm chi phí, điều này thực sự là cứu tinh cho các nhóm nhỏ.
Nói vậy là dự án nào đang làm, cảm giác phải thử xem sao.
等等高频读写秒级延迟...会不会又是营销噱头,现实中卡的一批?
不过从防守心态转到主动设计,这个转变确实改变游戏规则了。
Dữ liệu hỏng hóc đã sớm có người giải quyết rồi, sao đến giờ mới xuất hiện.
Xem bản gốcTrả lời0
MEV_Whisperer
· 01-07 20:42
Điều này chính là giải quyết điểm đau vĩnh viễn của dữ liệu trên chuỗi, đã đến lúc có người làm điều này rồi
Nghe có vẻ thực sự tiết kiệm nhiều công sức, đặc biệt là đối với những dự án có lượng dữ liệu lớn, không cần phải xây dựng lại một nửa hệ thống cho mỗi lần cập nhật
Số liệu 99% khả dụng nghe có vẻ thoải mái, chỉ là không biết thực tế khi vận hành có giảm sút hay không
Xem bản gốcTrả lời0
StableNomad
· 01-07 20:33
thật sự điều này giống như UST copium một lần nữa... trạng thái quản lý "có lý thuyết ổn định" cho đến khi nó không còn nữa lmao
Xem bản gốcTrả lời0
Rugman_Walking
· 01-07 20:32
Haha, cuối cùng cũng có người nói về vấn đề này rồi, thật sự rất phiền chết đi được
Ý tưởng mới nghe có vẻ dễ chịu hơn nhiều, không cần phải mày mò theo quy trình sao lưu cũ kỹ nữa
Đối với nhà phát triển, thực sự là một sự giải thoát
Nhắc đến phát triển ứng dụng on-chain, nhiều người bỏ qua một vấn đề lâu dài: dữ liệu và ứng dụng cùng lão hóa.
Tài sản trò chơi, siêu dữ liệu NFT, kết quả suy luận AI — những thứ này tích lũy mỗi ngày. Sau một năm, chỉ dữ liệu trạng thái cốt lõi đã có thể chất tới 20—40GB. Còn rắc rối hơn, chúng cần phải được truy cập thường xuyên, được sửa đổi, được xác minh. Đến giai đoạn sau, nhà phát triển thường bị buộc phải chọn cách cũ: sao lưu, di chuyển, xây dựng lại chỉ mục. Quy trình này vừa tốn kém vừa kém hiệu quả, điều tệ nhất là tính toàn vẹn của dữ liệu lịch sử không thể được đảm bảo.
Gần đây có một ý tưởng mới xuất hiện, thay đổi tình trạng này.
Sự khác biệt chính là không đơn giản là nhồi dữ liệu vào rồi xong. Mà là để dữ liệu và khả năng xác minh gắn kết với nhau. Mỗi đối tượng khi được tạo ra đã nhận được một danh tính ổn định, những thay đổi trạng thái tiếp theo xảy ra bên trong đối tượng này, không cần phá hủy cấu trúc ban đầu.
Kết quả là gì? Dù dữ liệu có lớn bao nhiêu, tần suất cập nhật có mạnh bao nhiêu, hệ thống vẫn có thể đảm bảo những điểm này: địa chỉ đối tượng luôn không thay đổi, trạng thái lịch sử hoàn toàn có thể theo dõi được, dự phòng đa nút dưới kiến trúc có tính khả dụng vượt quá 99%, độ trễ đọc song song duy trì ở mức độ giây.
Tác động lên nhà phát triển thực sự khá lớn. Khi dữ liệu của bạn được đặt trong hệ thống lưu trữ như vậy, bạn có thể yên tâm hơn khi thiết kế logic lặp lại, không phải lúc nào cũng lo lắng rằng một sửa đổi sẽ phá hủy toàn bộ trạng thái on-chain.
Lợi ích thực tế có một vài cái:
**Chi phí thấp hơn** Dữ liệu một khi được lưu vào đã có tính khả xác minh dài hạn, tiết kiệm rất nhiều rắc rối về di chuyển, sao lưu và quản lý phiên bản.
**Tần suất truy cập không phải là nút cổ chai** Đọc ghi tần suất cao được hỗ trợ natively trong kiến trúc này, sẽ không tạo ra đối tượng mới hoặc kích hoạt các hoạt động on-chain bổ sung vì cập nhật.
**Truy cập lịch sử không còn là vấn đề khó** Chuỗi tiến hóa trạng thái hoàn chỉnh được giữ lại, truy vấn dữ liệu lịch sử không cần bảo trì chỉ mục bổ sung.
Đưa ra một góc nhìn khác, điều này thay đổi tâm lý của nhà phát triển về quản lý dữ liệu. Trước đây luôn ở thế phòng thủ — phòng chống dữ liệu bị hỏng, phòng chống chi phí bảo trì tăng vọt. Bây giờ có thể chuyển sang thiết kế chủ động, vì logic lưu trữ cấp độ dưới đã giúp bạn giải quyết những điểm đau này.