Cổng triển khai Polkadot: Tại sao các dự án nên chọn triển khai trên Polkadot thay vì trở thành một L2?

Trước đây, việc triển khai một Rollup trên Polkadot chưa bao giờ là điều dễ dàng. Bởi vì hệ thống càng linh hoạt thì quy trình triển khai thường càng phức tạp: từ việc cập nhật SDK, đến đấu giá slot, rồi đến quản trị và nâng cấp runtime, mỗi khâu đều có thể trở thành thách thức đối với các đội ngũ phát triển.

Để thay đổi hiện trạng này, Parity đã ra mắt Polkadot Deployment Portal (PDP) trong năm nay — một “cổng thông tin một cửa” từ xây dựng, triển khai đến tích hợp. Mục tiêu của nó rất rõ ràng: hạ thấp rào cản, đơn giản hóa quy trình, giúp bất kỳ đội ngũ nào cũng có thể nhanh chóng và ổn định khởi chạy cũng như vận hành Rollup của riêng mình trên Polkadot.

Trong bài viết này, Santi Balaguer — trưởng bộ phận phát triển sản phẩm của Parity — sẽ cùng chúng ta nhìn lại quá trình thay đổi trải nghiệm triển khai trên Polkadot trong những năm qua, phân tích triết lý thiết kế phía sau PDP, và chia sẻ cách công cụ này từng bước thay đổi cách khởi động Rollup.

Trải nghiệm triển khai trên Polkadot: Hệ thống càng linh hoạt, càng phức tạp

Jay: Chào mừng đến với Space Monkeys, hôm nay chúng tôi mời đến Santi Balaguer — người phụ trách phát triển sản phẩm tại Parity. Hôm nay chúng ta sẽ nói về PDP, PDP là viết tắt của gì nhỉ?

Santi: Đó là Polkadot Deployment Portal — Cổng triển khai Polkadot.

Jay: Trước khi bắt đầu làm PDP, bốn năm năm qua ở Parity bạn chủ yếu phụ trách những gì?

Santi: Trước đây tôi luôn làm việc sát với cộng đồng nhà phát triển, chủ yếu là giúp họ khởi chạy parachain và Rollups trên Polkadot. Như bạn nói, tôi đã ở Parity từ khi parachain còn chưa ra mắt.

Jay: Trong số các dự án bạn thường xuyên tiếp xúc, có những dự án nào mà chúng tôi khá quen thuộc không?

Santi: Trước đây tôi phụ trách dự án Substrate Builders, trong đó có rất nhiều dự án nổi tiếng. Ấn tượng nhất là đội Hydration. Tôi vẫn nhớ khi Jakub trình bày, anh ấy giới thiệu ý tưởng Omnipool và vấn đề mà Hydration muốn giải quyết. Anh ấy còn chiếu một meme kinh điển “money printer goes brrrr” để giải thích tại sao họ cần đề xuất giải pháp mới. Đến giờ tôi vẫn thường đùa với Jakub về chuyện này.

Jay: Haha, tuyệt vời quá. Chắc chắn bạn đã chứng kiến nhiều dự án thành công trên Polkadot, cũng nghe không ít về những khó khăn của họ. Bạn có thể chia sẻ về những điểm đau đầu nhất khi triển khai dự án trên Polkadot trong vài năm qua không?

Santi: Tất nhiên rồi. Bản thân Polkadot là một hệ thống rất phức tạp, bạn phải thực sự hiểu nó thì dự án mới vận hành suôn sẻ. Sự phức tạp này thực ra đến từ tính linh hoạt của nó — hệ thống càng linh hoạt thì càng phức tạp.

Thời gian đầu, muốn chạy một parachain trên Polkadot, trước tiên bạn phải đối mặt với đủ loại “cập nhật phá vỡ” của SDK. Khi đó chưa có Polkadot SDK, chỉ có Substrate, khác bây giờ rất nhiều. Sau khi xử lý xong môi trường phát triển, bạn còn phải vận động cộng đồng bỏ phiếu, tham gia đấu giá slot. Bản thân đấu giá cũng rất thách thức, bạn cần đủ nhiều người ủng hộ, mà kết quả đấu giá chỉ biết ở phút cuối. Dù thắng, bạn cũng phải đợi ba tháng parachain mới thực sự lên mạng. Hơn nữa slot chỉ cho thuê hai năm. Vì vậy, lúc đó bạn phải dốc toàn lực cả về kỹ thuật lẫn vận động cộng đồng mới có thể có chỗ đứng trên Polkadot.

Jay: Đúng vậy. Sau này vài năm, trải nghiệm đã cải thiện nhiều. Bạn có thể chia sẻ về quá trình thay đổi này không?

Santi: Tất nhiên. Tôi nghĩ Parity đã nỗ lực rất nhiều, đặc biệt là trong việc giảm bớt các cập nhật phá vỡ của Polkadot SDK.

Dù bây giờ vẫn có cập nhật, nhưng so với trước thì ổn định hơn nhiều, khả năng tương thích giữa các phiên bản cũng tốt hơn. Giờ đây các nhà phát triển có thể yên tâm dựa vào phiên bản SDK mà mình dùng. Thậm chí có những parachain vẫn dùng Substrate cũ nhưng vẫn chạy tốt trên Polkadot.

Thêm nữa là việc đưa vào Cortime (dù bản thân nó cũng có độ phức tạp nhất định), nhưng thực sự đã giảm đáng kể rào cản cho nhà phát triển. Nó giúp mọi người dễ thử nghiệm hơn, hạ thấp rất nhiều rào cản gia nhập Polkadot, tôi nghĩ chúng ta nên tận dụng tối đa điều này.

Tại sao bây giờ các dự án lại chọn triển khai trên Polkadot thay vì làm L2 của Ethereum?

Jay: Dù khi đó có nhiều thách thức, nhưng giờ đã giải quyết được khá nhiều. Vậy bạn nghĩ tại sao ngày nay một dự án lại chọn triển khai trên Polkadot? Tại sao không làm L2 trên Ethereum, hoặc phát hành một L1 riêng luôn? Lý do là gì?

Santi: Đây là một câu hỏi rất thú vị. Trước tiên tôi nghĩ, với tư cách cộng đồng, chúng ta nên truyền thông và quảng bá nhiều hơn về điều này. Theo hiểu biết và quan điểm cá nhân tôi, Polkadot hiện là blockchain duy nhất được thiết kế ngay từ đầu để hỗ trợ Rollup một cách nguyên bản. Nó cung cấp cho nhà phát triển nhiều hạ tầng mà nơi khác không có.

• Ví dụ, Polkadot cung cấp lớp khả dụng dữ liệu (data availability) rất lớn cho Rollup, còn nếu bạn làm L2 trên Ethereum thì phải dựa vào một số hệ thống bên ngoài hoặc “blob” để giải quyết.

• Thêm nữa là truyền thông tin gốc giữa các parachain (liên lạc cross-chain), điều này các Rollup khác không có. Thiếu tính năng này sẽ làm giảm tính an toàn của hệ thống.

• Về hiệu năng, Spamming đã xác thực, TPS của Rollup trên Polkadot thuộc hàng xuất sắc trong ngành.

• Và còn khả năng mở rộng linh hoạt, Polkadot hiện là hệ thống duy nhất có thể mở rộng hoặc thu nhỏ hạ tầng theo nhu cầu bất cứ lúc nào. Ví dụ, nếu Mythical đột ngột ra mắt game mới, dự kiến tuần đầu người dùng tăng gấp 10 lần, họ gần như không cần thay đổi gì mà vẫn có thể hỗ trợ lưu lượng này ngay lập tức.

Tôi nghĩ trong các cuộc thảo luận trước đây về “parachain và Rollup”, chúng ta chưa làm nổi bật Polkadot, bỏ lỡ một chút cơ hội. Nhưng bây giờ vẫn còn kịp, chúng ta vẫn có cơ hội đưa nó trở lại trung tâm sân khấu.

Jay: Đúng vậy, bạn từng nói với tôi rằng, Polkadot ngay từ khi thiết kế kiến trúc nền tảng đã chuẩn bị cho Rollup. Chỉ là ban đầu chúng ta không gọi nó là Rollup.

Santi: Đúng rồi, còn một điểm nữa mà chúng ta thường bỏ qua, đó là bảo mật chia sẻ. Nhìn lại lịch sử phát triển blockchain: đầu tiên là bitcoin, sau đó có Ethereum. Sau này mọi người bắt đầu phát hành đủ loại “Ethereum mới”, quảng bá rằng “chuỗi của tôi tốt hơn vì có đặc tính A, B, C”. Nhưng vấn đề là, đảm bảo an toàn cho một chuỗi mới rất khó. Bạn phải có một tập hợp validator đủ lớn, đủ mạnh, điều này không dễ chút nào.

Khi đó Gavin nghĩ: tại sao tôi không cung cấp bảo mật như một dịch vụ, tích hợp vào tầng cơ sở luôn? Đó chính là điểm độc đáo của Polkadot. Nó không chỉ cung cấp bảo mật chia sẻ, mà còn có thể thực hiện truyền thông hiệu quả giữa các Rollup, đây là điểm mạnh đặc biệt của Polkadot.

Ý tưởng về PDP ra đời như thế nào?

Jay: Tuyệt vời. Nếu một Rollup muốn có khả dụng dữ liệu tích hợp (và ở quy mô lớn), thay vì phải ghép nối các dự án khác, lại còn muốn TPS và thông lượng mạnh, đồng thời có thể giao tiếp liền mạch với các Rollup khác, thì Polkadot thực sự rất hấp dẫn. Nhưng trước khi có PDP, việc triển khai một parachain vẫn rất phức tạp, tốn thời gian. Vậy tại sao ban đầu lại có ý tưởng làm công cụ PDP này?

Santi: Thực ra ý tưởng này đã được ấp ủ một thời gian, dù chúng tôi thực sự bắt tay vào làm là từ tháng 11 năm ngoái.

Sau đó đội ngũ của chúng tôi bắt đầu tập trung toàn thời gian vào dự án này từ khoảng tháng 3, tháng 4 năm nay, hiện tại tiến độ rất nhanh, mọi người đang từng bước biến ý tưởng thành hiện thực. Việc này đã được ấp ủ từ lâu, và trong ngành cũng đã có một số giải pháp tương tự. Ví dụ trong hệ sinh thái Ethereum có Conduit, Gelato; phía Polkadot trước đây cũng có Tanssi, nhưng sau này họ cũng chuyển sang Ethereum là chính, ý tưởng cũng tương tự.

Chúng tôi thấy phía Polkadot mãi chưa có giải pháp thực tế, nên quyết định tự mình làm, đảm bảo việc này thành công. Dù sao chúng tôi cũng hiểu Polkadot sâu hơn, cũng biết rõ hơn làm sao để giúp nhà phát triển triển khai dự án dễ dàng hơn, đó chính là mục tiêu mà PDP muốn giải quyết.

Chúng tôi không quyết định thay nhà phát triển, mà cung cấp hướng dẫn và lựa chọn

Jay: Vậy PDP thực sự hướng tới những ai? Tôi nhớ thời kỳ đầu Polkadot có một vấn đề là một số dự án ngay từ đầu đã làm Rollup, nhưng thực ra chỉ cần làm smart contract là đủ. Bạn nghĩ dự án như thế nào mới thực sự phù hợp để có một Rollup riêng?

Santi: Đây là một câu hỏi hay, nhưng tôi nghĩ không có câu trả lời cố định. Đến bây giờ chúng tôi vẫn thấy một số dự án, thực ra làm contract cũng hợp lý. Nhưng đôi khi phía dự án cần sự độc lập, họ không muốn phụ thuộc vào hạ tầng của chuỗi khác; đôi khi họ dự đoán thông lượng tương lai sẽ rất lớn, nên thà chọn làm Rollup ngay từ đầu, những lý do như vậy khiến họ cần một chuỗi riêng, hoặc cần sự độc lập cao hơn về hạ tầng.

Ví dụ như Omnipool của Hydration, chúng ta cũng có thể tranh luận liệu nó chỉ nên là một contract, nhưng tôi nghĩ không, làm thành một chuỗi riêng là hợp lý. Nhìn sang Uniswap trên Ethereum, ban đầu chỉ là contract, sau này mới làm chuỗi riêng, nhưng giờ họ thực sự cần một chuỗi không? Có thể chưa chắc, nhưng họ có cân nhắc kinh doanh riêng.

Vì vậy thực ra không có tuyệt đối, phần lớn là kết quả của sự kết hợp giữa kỹ thuật và kinh doanh. Với tôi, điều quan trọng nhất là: chúng tôi không quyết định thay nhà phát triển, mà cung cấp hướng dẫn để họ tự lựa chọn. Dù họ muốn làm Rollup hay contract, đều nên dễ dàng thử nghiệm và trải nghiệm.

Khám phá trải nghiệm toàn trình PDP: Từ xây dựng, triển khai đến truy cập, khởi động Rollup dễ dàng như thế nào

Jay: Được rồi, giả sử một đội ngũ đã quyết định, dù là tự quyết hay được Magenta Labs hoặc đội BD hướng dẫn. Cuối cùng họ quyết định triển khai rollup trên Polkadot. Vậy khi vào PDP, họ sẽ có trải nghiệm gì? Quy trình triển khai hiện nay ra sao?

Santi: Trong thiết kế của PDP, chúng tôi chia quy trình thành ba giai đoạn chính: Build (xây dựng) — Deploy (triển khai) — Access (truy cập), ba phần này liên kết với nhau.

Ở giai đoạn “xây dựng”, vấn đề cốt lõi là “tôi nên bắt đầu như thế nào”. Ý tưởng của chúng tôi là: cách tốt nhất là thông qua các mẫu runtime (runtime templates). Hiện tại OpenZeppelin đang phát triển các mẫu liên quan, đội Pop CLI và đội ROG cũng đang làm việc này. Pop CLI về bản chất là một công cụ bạn có thể dùng trên máy tính để viết Rollup. Chúng tôi hợp tác với họ, kết nối nó với hai khâu còn lại của PDP (triển khai và truy cập).

Ví dụ, bạn xây dựng xong một Rollup trên Pop CLI, có thể kết nối trực tiếp với PDP để triển khai Rollup, chúng tôi thiết kế và thực hiện đúng như vậy. Như vậy, nhà phát triển có thể dùng CLI để đi hết quy trình, giống như Heroku hoặc Vercel trong Web2, họ đều có CLI riêng. Nếu bạn quen cách này, có thể dùng CLI; tất nhiên bạn cũng có thể dùng giao diện đồ họa hoàn toàn. Cả hai đều được.

Jay: Tức là ngoài xây dựng bằng template, còn có thể dùng Pop CLI để xây dựng rồi triển khai. Vậy bản thân PDP có giúp nhà phát triển đưa ra một số lựa chọn không? Hay nó chỉ là công cụ, chủ yếu do đội ngũ tự thao tác?

Santi: Cả hai. Chúng tôi muốn PDP là công cụ tự phục vụ, để nhà phát triển tự sử dụng. Nhưng nếu gặp vấn đề quan trọng, chúng tôi sẽ hỗ trợ bên cạnh, đảm bảo họ nhận được sự giúp đỡ cần thiết. Tất nhiên, nếu ai đó muốn tự thử nghiệm cũng hoàn toàn được haha.

Jay: Nghe thú vị đấy. Bạn có thể lấy ví dụ về một số template cụ thể không? Có mẫu nào bạn thích không?

Santi: Ví dụ, đội ROG có một template Pilot Revive sẵn, bạn có thể dùng để khởi động ngay. OpenZeppelin có template Frontier, nếu bạn muốn chạy một chain có chức năng EVM thì dùng nó luôn.

Jay: Nghe hay đấy, tức là có vài lựa chọn liên quan đến smart contract.

Santi: Đúng vậy. Còn có template không có smart contract. Ví dụ ai đó chỉ muốn làm một chain lưu ký tài sản, nhất là các dự án liên quan đến tài sản thế giới thực (RWA), cũng có template tương ứng. Nói chung giai đoạn đầu sẽ có nhiều lựa chọn, sau đó bạn có thể mở rộng thêm.

Jay: Vậy template có thể thêm Pallet mới theo nhu cầu không?

Santi: Ban đầu thì không. Ý tưởng thiết kế là bạn khởi động từ template, sau đó chúng tôi sẽ hướng dẫn bạn từng bước nâng cấp runtime. Chúng tôi muốn qua cách này giúp đội ngũ dần tìm được điểm phù hợp với thị trường. Thiết kế này rất thú vị, cũng là tính năng chúng tôi tập trung phát triển hiện nay, hiện chúng tôi đang dùng một công cụ rất hay của đội Puppet, nó có thể so sánh runtime bạn sắp nâng cấp với runtime đang triển khai, tạo ra một báo cáo cho bạn biết những gì đã thay đổi, những gì có thể ảnh hưởng đến nhà phát triển, và cần chú ý điều gì.

Jay: Đúng đúng, tôi thấy các bạn vừa tích hợp cái này, tuyệt quá.

Santi: Đúng, vừa hoàn thành tuần này. Như vậy bạn sẽ nhận được báo cáo nâng cấp runtime, đảm bảo nội dung bạn muốn đẩy lên phù hợp với kỳ vọng. Sắp tới chúng tôi còn muốn thêm chức năng: giúp bạn mô phỏng chạy vài block ở backend, kiểm tra runtime mới. Nếu mọi thứ ổn, chúng tôi sẽ báo “có thể lên mạng”; nếu có vấn đề, sẽ báo “chúng tôi test không qua, bạn nên kiểm tra lại”. Như vậy có thể tránh lỗi khi nâng cấp. Chúng tôi cho rằng một trong những lợi thế của Polkadot là hỗ trợ nâng cấp runtime linh hoạt, đội ngũ hoàn toàn có thể tận dụng để thử nghiệm nhanh, tìm ra điểm phù hợp với thị trường.

Jay: Khoan đã, vậy phần này đã tính là giai đoạn “triển khai” chưa? Những gì chúng ta vừa nói từ xây dựng đến runtime, có tính là triển khai không?

Santi: Đúng, ở đây có chút giao thoa. Có thể hiểu thế này: xây dựng chủ yếu bắt đầu từ template; triển khai thì liên quan đến hạ tầng cơ bản. Trước đây bạn cần có đội DevOps riêng để dựng node collator, làm vận hành, giờ mới bắt đầu thì không cần lo. Nếu dự án phát triển tốt, có vốn và nguồn lực, bạn hoàn toàn có thể xây dựng đội vận hành riêng, lúc đó chúng tôi cũng sẽ hỗ trợ chuyển giao. Nhưng lúc mới bắt đầu, những việc này chúng tôi sẽ lo cho bạn.

Jay: Vậy hiện tại ai làm những việc này?

Santi: Hiện tại là Parity cung cấp. Nhưng tương lai chúng tôi sẽ để nhà phát triển tự chọn triển khai trên nền tảng đám mây nào, thậm chí có thể là IBP (nhà cung cấp hạ tầng), chỉ là trừu tượng hóa lớp này cần thời gian, nên hiện tại để đảm bảo trải nghiệm, chúng tôi dùng hạ tầng của Parity, nhưng cuối cùng sẽ mở rộng nhiều lựa chọn hơn.

Chúng tôi còn đưa ra một khái niệm gọi là BDU (Basic Deployment Unit — đơn vị triển khai cơ bản), chỉ cần bạn muốn triển khai Rollup trên mạng sản xuất, chúng tôi sẽ triển khai cho bạn một bộ hạ tầng tiêu chuẩn, gồm ba node collator, một node làm RPC endpoint cho bạn sử dụng, đồng thời còn có một indexer.

Hiện chúng tôi đang hợp tác với Subscan, họ có một giải pháp mã nguồn mở, chúng tôi dự định tích hợp vào PDP. Như vậy bạn không chỉ có indexer mà còn có block explorer, trước đây các đội phải mất rất nhiều thời gian để dựng, giờ chúng tôi giúp bạn lo hết, thiết kế này rất ổn.

Jay: Wow, nghe tuyệt thật. Phần này tính là xây dựng à?

Santi: Đây là triển khai.

Jay: Hiểu rồi, vậy đến bước này Rollup đã chạy rồi? Bắt đầu tạo block rồi? Đội ngũ cũng có thể nâng cấp runtime để thử nghiệm, lặp lại và tìm điểm phù hợp với thị trường rồi? Vậy tiếp theo là bước cuối cùng “truy cập (Access)”, đúng không? Đó là gì vậy?

Santi: Đúng! Access chính là điểm nổi bật của Polkadot, tôi nghĩ đây là nơi Polkadot có thể mang lại giá trị độc đáo cho đội Rollup. Xây dựng và triển khai liên quan đến runtime và hạ tầng, mọi người có thể tự tìm hiểu khá nhanh, nhưng tận dụng được đặc tính của Polkadot thì mới khác biệt. Ví dụ Coretime, nó là một phần của Access, PDP sẽ mua trước Coretime, như vậy khi nhà phát triển muốn triển khai Rollup là có thể dùng ngay, không phải đợi 28 ngày mới bắt đầu tạo block, điều này cải thiện trải nghiệm người dùng rất lớn.

Jay: Nếu tôi muốn triển khai, có phải tự vào PDP mua Coretime không?

Santi: Chúng tôi sẽ mua giúp bạn, sau đó thu phí lại. Thực tế, chúng tôi cung cấp nhiều lựa chọn cho Coretime. Ví dụ bạn muốn dốc toàn lực ngay từ đầu, có thể dùng một core đầy đủ. Nhưng chúng tôi cũng có “core chia nhỏ”, tức là một phần của core, ví dụ bạn chỉ muốn thử nghiệm, không muốn tốn nhiều tiền, muốn xem hiệu quả thế nào thì chỉ dùng một phần nhỏ core.

Jay: Chức năng này giờ đã dùng được chưa?

Santi: Trên PDP đã dùng được rồi. Hiện đã chạy trên mạng Westend và Paseo. Paseo vừa mới ra mắt core chia nhỏ, còn ở Westend bạn có thể giao dịch một phần core, nhược điểm là thời gian tạo block sẽ lâu hơn, nhưng ưu điểm là hạ thấp rào cản rất nhiều, bạn gần như có thể thử nghiệm với chi phí rất thấp. Nếu hiệu quả tốt, bạn có thể nâng cấp lên core đầy đủ, tận hưởng tốc độ tạo block 6 giây, và tất cả đều có thể thực hiện trên PDP. Tuy nhiên, cơ chế tích hợp vẫn cần giải quyết cách tận dụng hiệu quả Polkadot. Hiện tại Polkadot Hub là một module chức năng quan trọng sắp ra mắt, chúng tôi rất kỳ vọng vào điều này.