Lý do tôi hiểu sâu sắc tầm quan trọng thực sự của việc hiện thực hóa tính toán hoàn toàn phi tập trung bắt nguồn từ một câu chuyện khá đặc biệt phía sau, và câu chuyện này xứng đáng để kể—mời bạn nghe tôi từ từ chia sẻ.
Ngay từ năm 2015, tôi đã gia nhập lĩnh vực tiền mã hóa từ giai đoạn đầu, nhưng đồng thời tôi vẫn tiếp tục điều hành chính tựa game “Fight My Monster” mà tôi từng sáng lập trước đó—một MMO (trò chơi nhập vai trực tuyến nhiều người chơi) kiêm nền tảng mạng xã hội, có 3 triệu người dùng và về mặt tài chính có thể tự trang trải, lại còn nhận được sự hậu thuẫn từ quỹ đầu tư mạo hiểm.
Mặc dù tôi đã tìm được bến đỗ sự nghiệp dài hạn trong lĩnh vực tính toán phi tập trung, nhưng tôi không thể phụ lòng những người chơi đã luôn ủng hộ trò chơi này.
“Fight My Monster” được phát triển trong giai đoạn 2010 đến 2012, dùng một kiến trúc cực kỳ đổi mới vào thời điểm đó. Kiến trúc này giúp nền tảng có thể mở rộng quy mô với chi phí thấp và ít công việc vận hành nhất (tức là có thể phục vụ lượng người dùng rất lớn).
Về bản chất, hệ thống này gồm ba thành phần backend cốt lõi. Thành phần đầu tiên là một dịch vụ web hosting đơn giản, chịu trách nhiệm phân phối mã trò chơi phần frontend và tài nguyên tới trình duyệt web của người dùng (lúc đó tôi dùng một CDN nội dung phổ biến, tức là mạng phân phối nội dung).
Giống như dịch vụ web hosting, hai thành phần backend còn lại cũng phải có khả năng “mở rộng ngang”. Điều đó có nghĩa là để hỗ trợ thêm người dùng và nhu cầu tính toán cũng như dữ liệu tương ứng, tôi chỉ cần tăng tài nguyên phần cứng, mà không cần viết lại mã phần mềm backend, cũng không cần thực hiện các công việc quản trị hệ thống rườm rà. Tính năng này giúp tôi từ rất sớm, chỉ với một lượng người và vốn đầu tư rất ít, đã có thể mở rộng quy mô nhanh chóng.
Thành phần thứ hai là một khung máy chủ trò chơi ngang mở rộng có tên “Starburst”, đây là thành quả mà tôi đã dành tâm huyết để tự tay xây dựng. Nó được xây dựng trên một máy chủ mã nguồn mở hỗ trợ giao thức RTMP - RTMP là một giao thức mạng do Adobe phát triển, cho phép các tài nguyên media Flash chạy trong trình duyệt web giao tiếp trực tiếp với máy chủ (còn nhớ Flash không?). Starburst đảm nhiệm phần xử lý logic của game và mạng xã hội, và gần như thời gian thực điều phối phân luồng lượng lớn các sự kiện được tạo ra trong trò chơi tới người dùng.
Thành phần thứ ba là một cơ sở dữ liệu NoSQL ngang mở rộng có tên Cassandra (nếu bạn theo dõi mảng cơ sở dữ liệu, hẳn bạn biết một phiên bản dẫn xuất hiện đại của nó là ScyllaDB - hiện đang thể hiện rất tốt trong việc đáp ứng các nhu cầu AI thời gian thực).
Cũng cần nhắc rằng trong đội của tôi, ngoài công ty gốc phát triển Cassandra, chỉ có một người nộp commit cốt lõi Cassandra duy nhất (core committer). Ngoài ra, tôi cũng là một trong những người sớm nhất đưa bản beta của Cassandra vào môi trường sản xuất cường độ cao. Khi lượng người dùng đạt 800.000, cơ sở dữ liệu đã bị hỏng. 24 giờ tiếp theo thật sự khiến thần kinh căng như dây đàn - tôi phải khẩn trương, chạy đua từng giây để khôi phục dữ liệu và đưa hệ thống hoạt động trở lại (lúc đó tôi cảm thấy như đang lao về phía điện toán đám mây, ngay khoảnh khắc sau lại nghĩ rằng mọi thứ đã không thể cứu vãn... nhưng may mắn là cuối cùng vẫn không sao, có kinh ngạc mà không mất).
Điều tuyệt vời nhất ở Cassandra là bạn có thể trực tiếp tăng số lượng nút (tức là các máy chủ trang bị ổ cứng dung lượng lớn) để thực hiện mở rộng theo chiều ngang cho dung lượng lưu trữ, throughput đọc và - quan trọng nhất - throughput ghi. Tính năng này khá hiếm, nhưng với ứng dụng của tôi nó lại vô cùng quan trọng vì “Fight My Monster” tạo ra một lượng dữ liệu khổng lồ.
Tất nhiên, một lợi thế quan trọng khác của Cassandra là khả năng chịu lỗi. Tôi cấu hình 5 bản sao (replication factor = 5), nghĩa là dữ liệu của mọi người đều rất an toàn (ít nhất là lúc đó tôi nghĩ vậy...). Với cấu hình 5 bản sao, đối với bất kỳ “quorum dữ liệu” cụ thể nào, chỉ cần có 3 nút đang trực tuyến thì hệ thống vẫn có thể ghi dữ liệu một cách bình thường.
Khác với blockchain, Cassandra không có khả năng chịu lỗi kiểu Byzantine. Điều đó có nghĩa là tôi phải quản lý chặt chẽ an ninh hạ tầng để ngăn hacker hoặc phần mềm độc hại xâm nhập. Tuy nhiên, vào thời điểm đó, các hacker lại không hứng thú với một MMO vừa có đối tượng người dùng chính là trẻ em, vừa kiêm mạng xã hội, và bản thân nó cũng không phải là một nền tảng chung để người khác xây dựng ứng dụng dựa trên đó.
Áp lực kỹ thuật chính mà tôi gặp phải là do lượng dữ liệu sinh ra cực kỳ lớn, các nút chịu trách nhiệm cho cơ sở dữ liệu đang gánh chịu tải vô cùng nặng nề, khiến chúng thường xuyên “sụp đổ”! Điều đó có nghĩa là tôi phải thỉnh thoảng đăng nhập vào hạ tầng, đưa các nút bị lỗi ra khỏi hệ thống và thêm các nút mới. May mắn là việc này không quá khó khăn: nhờ cơ chế chịu lỗi, công việc đó không cần phải làm gấp gáp ngay lập tức, và các máy chủ “bare metal” này cũng có thể được nhà cung cấp dịch vụ đám mây của tôi điều phối tập trung...
“Fight My Monster” dùng một bộ kiến trúc đi trước thời đại, giúp tôi dễ dàng đạt được khả năng mở rộng. Ngoài ra, năng lực chịu lỗi và kiến trúc backend gọn gàng chỉ gồm 3 thành phần hệ thống cốt lõi đồng nghĩa với việc khối lượng công việc và áp lực quản trị cần thiết để vận hành hệ thống đã được giảm xuống mức tối thiểu. Vậy rốt cuộc bài học nào quan trọng đến mức cho đến tận bây giờ vẫn ảnh hưởng sâu sắc đến cách tôi suy nghĩ và sự phát triển của ICP? Bạn chắc chắn cảm nhận rằng đã có một điều gì đó phi thường xảy ra lúc ấy - và hiện tại, lần đầu tiên tôi sẽ công khai chia sẻ câu chuyện này.
Lúc đó, tôi đang di chuyển khắp châu Á, là một thành viên trong “đội lưu diễn” cộng đồng lõi Ethereum thời kỳ đầu, tới thăm các bên liên quan (người ta thường bỏ qua - đặc biệt là Trung Quốc - vai trò hỗ trợ quan trọng mà châu Á đã đóng trong sự phát triển của lĩnh vực tiền mã hóa giai đoạn sơ khai) và tham gia đủ loại sự kiện liên quan đến Ethereum. Tại những dịp ấy, tôi chủ yếu thảo luận về một số kỹ thuật khoa học máy tính phức tạp mà tôi tự phát triển, với mục tiêu nâng cao khả năng mở rộng và hiệu năng của các mạng như Bitcoin và Ethereum.
Tôi không muốn lan man về “những ngày xưa” trong lĩnh vực tiền mã hóa, nhưng tôi phải nói rằng đó là khoảng thời gian đầy phép màu. Những người tham gia giai đoạn đầu đã để lại cho tôi rất nhiều kỷ niệm đẹp, và tôi thực sự biết ơn vì điều đó. Trải nghiệm ấy cuốn hút đến mức tôi thậm chí không còn thời gian để xem email.
Kết quả là trên hành trình của mình, tôi đã bỏ lỡ vô số email - những email đó đều cảnh báo tôi: thẻ tín dụng dùng để thanh toán chi phí cho các nút Cassandra của dự án Fight My Monster đã hết hạn...
Vậy khi tôi ở trong vài tuần (thời gian cụ thể tôi không nhớ, nhưng cũng không lâu) mà không phản hồi thì nhà cung cấp đám mây đã làm gì? Rất đơn giản: họ xóa sạch mọi nút!!!
Khó có thể diễn tả cảm giác của tôi khi quay về California, Palo Alto và phát hiện ra tất cả điều đó. Nó là sự pha trộn giữa sốc và hoảng sợ: cảm giác trống rỗng trong dạ dày, adrenaline tăng vọt, nỗi sợ lan tràn không ngừng. Tôi cuống cuồng tìm cách cứu vãn, nhưng cuối cùng xác nhận rằng mọi thứ đã không thể cứu được nữa. Những người từng gặp hacker trong lĩnh vực tiền mã hóa hẳn sẽ hiểu cảm giác này.
Mọi thứ cứ thế kết thúc. Fight My Monster đã hoàn toàn biến mất. Trong cộng đồng thậm chí có người đã khởi động một bản kiến nghị trên Change.org, tha thiết yêu cầu đưa nó trở lại.
Dù tôi đã đánh mất giá trị lẽ ra nó có thể tạo ra, tôi cũng cảm thấy có lỗi. Nhưng ở một mức độ nào đó, tôi lại thấy nhẹ nhõm: tôi không còn phải chịu trách nhiệm duy trì nó nữa (nếu không, tôi có thể đã phải tiếp tục bảo trì cho cộng đồng một cách không ngừng). Ngoài ra, nó trở thành những kỷ niệm đẹp đối với một thế hệ trẻ em (và cả một phần người lớn) đã từng chơi trò đó, và nó kết thúc trước khi trở nên cũ kỹ và nhàm chán. Điều này cũng giúp tôi tập trung vào mảng mà lúc đó tôi hoàn toàn say mê - mạng tính toán phi tập trung.
Tuy nhiên, tôi rút ra được một bài học vô cùng sâu sắc từ đó: bạn có thể xây dựng một hạ tầng tính toán phi tập trung có khả năng mở rộng và chịu lỗi, nhưng chỉ cần tại bất kỳ thời điểm nào và ở bất kỳ khâu nào tồn tại một điểm lỗi đơn (single point of failure), thì toàn bộ hệ thống có thể sụp đổ hoàn toàn.
Chính vì vậy, mỗi khi nghe nói rằng một số blockchain dựa vào khóa quản trị do các nhà phát triển lõi nắm giữ, hoặc nghe rằng một lượng lớn nút bị đưa lên tuyến dưới khi nhà cung cấp đám mây ngừng hỗ trợ hoặc gặp lỗi kỹ thuật (thậm chí đứng trước nguy cơ tê liệt), tôi luôn cảm thấy lo lắng. Vấn đề cực kỳ mong manh này phổ biến trong ngành của chúng ta hơn nhiều so với những gì bạn tưởng.
Bài học đau đớn từ lần trải nghiệm Fight My Monster đã ảnh hưởng sâu sắc đến triết lý thiết kế của Internet Computer. Điều quan trọng không chỉ là số lượng nút, mà còn là những yếu tố khác, quan trọng hơn nữa: nếu các nút là ẩn danh, thì số lượng thực thể độc lập thực sự vận hành phần lớn nút có thể ít hơn rất nhiều so với kỳ vọng của bạn. Ngoài ra, dù số lượng nút có thể rất lớn, chúng thường lại chạy trên nền tảng của chỉ một vài nhà cung cấp dịch vụ đám mây. Và ngay cả khi chúng thuộc quyền sở hữu và vận hành bởi các thực thể khác nhau, nhà cung cấp đám mây vẫn có thể đột ngột quyết định không hỗ trợ nữa và đóng chúng chỉ trong một đêm (như Hetzner từng làm với một dự án blockchain nổi tiếng nào đó).
Trong các ứng dụng thực tế, điều thực sự quan trọng là số lượng thực thể độc lập vận hành các nút, và mức độ độc lập của các nút về vị trí vật lý lẫn thẩm quyền pháp lý. Chỉ một nhận thức đơn giản này đã là nền tảng của triết lý “phi tập trung tất định” (deterministic decentralization), triết lý này sẽ được thể hiện dưới một hình thức hoàn toàn mới trong các tính năng mở rộng của “ICP cloud engines” mà Internet Computer sắp ra mắt.
ICP cloud engines cho phép doanh nghiệp (thường là như vậy) tạo ra các subnet Internet Computer thực sự thuộc quyền kiểm soát của chính họ và tự quản lý cấu hình. Doanh nghiệp có thể ghép các nút bằng cách chọn từ một pool nút đóng vai trò như “thị trường”. Hiện đã có hơn 1500 nút đang chờ sẵn, và con số đó vẫn tiếp tục tăng lên.
“Engine” cung cấp một nền tảng đám mây serverless (không cần server) với các đặc tính vượt trội. Đây là nơi lý tưởng để xây dựng các ứng dụng và dịch vụ AI, vì ngăn xếp công nghệ của nó được thiết kế đặc biệt để hỗ trợ việc tạo nhanh các phần mềm AIware tiên tiến. Các AIware đó vừa an toàn vừa có độ bền cực cao.
Những ứng dụng này có nhiều đặc tính như chống sửa đổi (miễn nhiễm với các cuộc tấn công kiểu hacker ở tầng hạ tầng), luôn trực tuyến 24/7 (vì vậy có độ bền rất cao), chạy tự chủ tùy chọn (tức là không có backdoor), hỗ trợ tự nhiên tài sản số, v.v. Engine cũng có thể chạy các ứng dụng AIware như bộ Open SaaS, hỗ trợ doanh nghiệp vận hành công việc kinh doanh end-to-end. Cloud engine giúp việc cài đặt và bảo trì các ứng dụng phức tạp như Open CRM hoặc Open Email trở nên dễ dàng như cài một ứng dụng trên điện thoại.
Các nút hỗ trợ thay nóng (hot plug), nghĩa là bạn có thể điều chỉnh hệ số nhân bản tính toán (compute replication factor) hoặc thay đổi nút mà không cần ngắt dịch vụ được cloud engines lưu trữ, nhờ đó bạn thoát khỏi sự phụ thuộc vào một nhà cung cấp dịch vụ tính toán cụ thể. Ngoài ra, bạn cũng có thể chọn dùng các nút mới được triển khai trên các nhà cung cấp đám mây siêu quy mô (hyperscalers) và cả các nút Internet Computer truyền thống, để biến nó thành một thị trường chung cho tài nguyên tính toán.
Khung cloud engine (Cloud Engine) hướng dẫn người dùng ghép các nút có tính độc lập, đồng thời cung cấp sự linh hoạt mà dịch vụ hosting chia sẻ Internet Computer không có. Ví dụ, một doanh nghiệp ở Đức có thể chọn chỉ dùng các nút đặt trong phạm vi Liên minh châu Âu để đáp ứng yêu cầu GDPR (Quy định chung về bảo vệ dữ liệu).
Tuy nhiên, console cloud engines tự trị - được mạng Internet Computer lưu trữ và NNS (Mạng Thần Kinh, tức DAO tiên tiến nhất toàn cầu) cập nhật - sẽ cung cấp hướng dẫn cho người dùng. Nếu người dùng ghép các nút từ cùng một nhà cung cấp, cùng một trung tâm dữ liệu hoặc cùng một nhà vận hành đám mây, console này sẽ đưa ra những cảnh báo rất mạnh.
Vì vậy, ngay cả trong bối cảnh của ICP cloud engines, những bài học và kinh nghiệm từ dự án “Fight My Monster” vẫn mang ý nghĩa thực tiễn.
Có thể bạn sẽ thắc mắc vì sao framework này lại nỗ lực kết hợp nhiều nút độc lập với nhau. Thực ra phía sau điều đó có những lý do đầy đủ - và lý do đó đối với cộng đồng blockchain rộng lớn ngày nay cũng quan trọng như vào năm 2015.
Kỳ vọng sớm được chia sẻ với mọi người về nội dung liên quan đến cloud engines.
Nội dung IC mà bạn quan tâm
Tiến bộ kỹ thuật | Thông tin dự án | Sự kiện toàn cầu
Theo dõi và sưu tập IC Kênh Binance
Nắm bắt những thông tin mới nhất