Stack Exploder: Modularism Đã Đến Saga Như Thế Nào

Blockchain Modularity Là Điều Tất Yếu, Đúng Không?

Trong suốt năm qua, tôi đã cố gắng hiểu về khả năng mở rộng của blockchain và cách Saga hòa nhập vào một bối cảnh đang không ngừng phát triển. Để đảm bảo Saga đi đúng hướng, tôi cần hiểu rõ cách các kiến trúc scalability khác nhau hoạt động, những con đường này sẽ dẫn đến đâu, và đảm bảo chúng tôi đang theo đuổi con đường tối ưu nhất.

Khi tôi phân tích những khác biệt về sản phẩm và sự đánh đổi giữa các appchain và rollup hiện có, tôi nhận ra mình đang bị cuốn vào những lập luận vòng vo và càng ngày càng rối. Với bất kỳ ai cũng từng lao vào mê cung này và chạm mặt một bức tường dày đặc sự mơ hồ, tôi hoàn toàn thấu hiểu.

Mọi người luôn hỏi tôi: Saga phù hợp với câu chuyện modular như thế nào? Tôi nhận thấy rất khó để trả lời câu hỏi này. Và lý do là: Saga không hoàn toàn phù hợp với câu chuyện modular hiện tại. Điều này xuất phát từ thực tế rằng hệ sinh thái modular hiện tại và các thiết kế của nó vẫn đang trong giai đoạn sơ khai và chưa hoàn thiện.

Tuy nhiên, bằng cách phân tích hệ sinh thái modular đã hình thành như thế nào và hiểu những hạn chế của kiến trúc modular hiện tại, chúng ta có thể dự đoán hướng đi tiếp theo của hệ sinh thái modular.

Hóa ra, tương lai của modularism trông rất giống với Saga.

Bắt đầu từ cơ bản: Chuỗi Monolithic

Một blockchain đơn giản chỉ là một danh sách dài các trạng thái (states) và giao dịch (transactions), được đảm bảo bởi một mức độ bảo mật nhất định.

• State: Đại diện cho dữ liệu của sổ cái tại một thời điểm cụ thể (snapshot).
• Transactions: Kích hoạt chuyển đổi trạng thái (state transitions).
  

Trong một blockchain proof-of-stake (PoS) kiểu monolithic, một ủy ban các nhà sản xuất khối (block producers), tức các validator, sẽ cập nhật sổ cái bằng cách đồng thuận về:

1. Danh sách giao dịch sẽ được đưa vào khối tiếp theo.
2. Trạng thái tương ứng (state) được tạo ra từ các giao dịch đó.

Cơ chế sản xuất khối (block production) có thể được chia thành ba phần chính:

1. Data Availability (DA)

• Đây là một cách nói hoa mỹ cho “lưu trữ giao dịch”.
• DA lưu giữ danh sách các giao dịch sẽ được đưa vào khối.

2. Execution

• Đây là một cách nói hoa mỹ cho “tính toán”.
• Execution tính toán trạng thái (state) được cập nhật dựa trên các giao dịch đó.

3. Settlement

• Đây là một cách nói hoa mỹ cho “lưu trữ trạng thái”.
• Settlement lưu giữ trạng thái (state) kết quả sau quá trình thực thi (execution).
  Trong mỗi khối, một validator đề xuất sẽ chuẩn bị danh sách giao dịch (DA), thực thi các giao dịch đó (execution), và đăng trạng thái kết quả (settlement). Sau bước đồng thuận, khi tất cả các validator khác đồng ý với khối được sản xuất, trạng thái được chỉ định trong giai đoạn settlement sẽ trở thành trạng thái toàn cầu mới nhất.

Hạn chế tiềm năng của chuỗi monolithic

Vấn đề với chuỗi monolithic là nó có một giới hạn lý thuyết về số lượng giao dịch mà chuỗi có thể xử lý. Mặc dù việc thực thi (execution) có thể được thực hiện song song ở một mức độ nhất định, bất kỳ giao dịch nào cập nhật cùng một trạng thái đều cần được xử lý tuần tự.

Điều này tương tự như giới hạn lý thuyết của CPU hyperthreading so với tính toán đa lõi (multicore computation). Giống như cách CPU cuối cùng đã chuyển sang thiết kế đa lõi để tối ưu hóa khả năng tính toán, chuỗi monolithic cũng cần chuyển sang thiết kế modular để đạt được khả năng mở rộng thực sự.

Bước 1: Modular hóa quá trình thực thi

Trong cơ chế sản xuất khối, thành phần tiêu tốn nhiều tài nguyên tính toán nhất là giai đoạn thực thi (execution). Do đó, một chiến lược mở rộng là chuyển việc thực thi khỏi chuỗi chính (base chain).

Trong thiết kế này, mainnet chỉ đóng vai trò là nơi lưu trữ giao dịch và trạng thái mới nhất từ môi trường thực thi ngoài chuỗi (off-chain execution environment).

Làm thế nào để đảm bảo môi trường thực thi ngoài chuỗi gửi trạng thái hợp lệ lên chuỗi chính?

Chúng ta cần đưa một mức độ bảo mật vào môi trường thực thi. Có hai phương pháp chính để thực hiện điều này:

1. Đảm bảo tính chính xác bằng tính toán

Khi môi trường thực thi gửi trạng thái lên mainnet, nó cũng cần phải gửi kèm một bằng chứng hợp lệ (validity proof), chứng minh toán học rằng trạng thái đó là hợp lệ. Phương pháp này thường được gọi là “zero knowledge” (ZK).

2. Đảm bảo thông qua ủy ban

Một ủy ban (ví dụ như một nhóm validator hoặc các node operator) xác nhận tính chính xác của quá trình thực thi. Cách này có thể được thực hiện qua:

• Triển khai một cơ chế đồng thuận proof-of-stake đầy đủ trên môi trường thực thi (decentralized sequencers).
• Hoặc tạm thời tin tưởng một nhóm kiểm toán viên (auditors) và thiết lập một giai đoạn thử thách (challenge period) để đảm bảo tính minh bạch.

Mở rộng quy mô bằng cách nhân bản môi trường thực thi

Khi môi trường thực thi được bảo mật đúng cách, bạn có thể lặp lại quy trình này để mở rộng quy mô mainnet bằng cách khởi chạy nhiều môi trường thực thi song song. Đây chính là cách hoạt động của các L2, chẳng hạn như Optimism, Arbitrum, v.v.

Hạn chế cuối cùng: Vấn đề khả năng mở rộng

Tuy nhiên, phương pháp này cũng gặp giới hạn về khả năng mở rộng. Tải tính toán của mainnet vẫn bị giới hạn, và việc chỉ lưu trữ giao dịch, trạng thái, và xác minh tính hợp lệ của trạng thái cuối cùng cũng có thể tiêu tốn toàn bộ tài nguyên tính toán của mainnet.

Bước 2: Modular hóa Data Availability

Để giải quyết vấn đề này, thành phần tiếp theo được modular hóa trong hệ sinh thái là Data Availability (DA). Bằng cách chuyển tác vụ lưu trữ giao dịch ra khỏi mainnet, chúng ta có thể tối ưu hóa mainnet để chỉ tập trung vào lưu trữ trạng thái (state storage) và xác minh trạng thái (state verification).

Điều này cho phép chúng ta triển khai lượng lớn hơn nữa các môi trường thực thi song song, thúc đẩy khả năng mở rộng ở một cấp độ mới.

Các nhà cung cấp Data Availability ngoài chuỗi

Các nhà cung cấp DA ngoài chuỗi hiện nay bao gồm các dự án như Celestia, EigenDA, và Avail. Tuy nhiên, giống như môi trường thực thi, DA cũng cần có cơ chế bảo mật để đảm bảo việc lưu trữ giao dịch là đáng tin cậy.

• Với Celestia, cơ chế bảo mật được đảm bảo bởi hệ thống proof-of-stake của họ.
• Với EigenDA, bảo mật được bảo đảm từ Ethereum tái staking (restaked Ethereum).

Thực trạng kiến trúc modular hiện nay

Dù kiến trúc modular hiện tại đã cải thiện khả năng mở rộng, nhưng nó chưa đủ để hỗ trợ các trường hợp sử dụng phổ biến. Để hỗ trợ cơ sở hạ tầng giá trị toàn cầu, sẽ cần hàng nghìn môi trường thực thi (execution environments). Tuy nhiên:

1. Thiết lập bảo mật cho một môi trường thực thi đã rất phức tạp và tốn kém, nói gì đến việc triển khai hàng nghìn môi trường như vậy.
2. Để hỗ trợ lượng giao dịch khổng lồ từ hàng nghìn chuỗi thực thi, một lớp DA và settlement duy nhất là không đủ. Cần có nhiều lớp DA và settlement song song, nhưng việc triển khai và đảm bảo bảo mật cho mỗi chuỗi mới đòi hỏi khối lượng công việc và tài nguyên rất lớn.

Để tạo ra một kiến trúc thực sự có khả năng mở rộng, chúng ta cần tự động hóa quy trình này.

Bước tiếp theo: Modular hóa bảo mật

Phần khó khăn nhất của bất kỳ cơ sở hạ tầng phi tập trung nào là cung cấp bảo mật. Một kiến trúc thực sự có khả năng mở rộng và linh hoạt chỉ khả thi nếu chúng ta có thể tách rời bảo mật khỏi các module sản xuất khối và giao nhiệm vụ đó cho một chuỗi chuyên biệt riêng biệt (có thể gọi đây là mainnet).

Làm thế nào để modular hóa bảo mật?

Thông thường, trong một blockchain, bất kỳ hoạt động xấu nào cũng sẽ bị trừng phạt (slash) validator chịu trách nhiệm ngay trên chính chuỗi đó. Điều thú vị của proof-of-stake là bảo mật của chuỗi mang tính tham chiếu nội tại (self-referential).

• Sản xuất khối chính xác xảy ra nhờ vào bảo mật nền tảng (giá trị staking). Validator tiếp tục sản xuất các khối chính xác vì họ lo sợ mất tài sản.
• Tuy nhiên, bảo mật nền tảng này được thực thi bởi sản xuất khối chính xác, vì danh mục tài sản của các validator được lưu trữ ngay trong sổ cái.

Cross Chain Validation (CCV): Modular hóa bảo mật ra khỏi chuỗi

Chúng ta có thể sử dụng Cross Chain Validation (CCV) để modular hóa bảo mật. Đây là một đổi mới của Cosmos tương tự như re-staking của Eigenlayer, cho phép các chuỗi vay mượn bảo mật từ chuỗi khác.

Với CCV:

• Bất kỳ hoạt động xấu nào trên DA và chuỗi thực thi sẽ được báo cáo lại cho mainnet, nơi cơ chế slashing được thực thi.
• Theo cách này, các module tự động kế thừa toàn bộ bảo mật của mainnet.
  

  Mô hình bảo mật tập trung qua mainnet

Trong mô hình này, trách nhiệm duy nhất của mainnet là cung cấp bảo mật và chia sẻ bảo mật cho các module sản xuất khối ngoài mainnet. Ngoài việc cải thiện khả năng mở rộng, việc hợp nhất bảo mật cho toàn bộ chu trình sản xuất khối theo cách này tạo ra một kiến trúc an toàn hơn.

Trong thế giới modular hiện tại, mức độ bảo mật cho một giao dịch cụ thể mang tính xác suất, phụ thuộc vào vị trí của giao dịch trong chu trình sản xuất khối. Bảo mật mang tính xác suất gây ra nhiều vấn đề về cầu nối (bridging) và trải nghiệm người dùng (UX).

Sự tất yếu của tích hợp

Khái niệm modularity không phải là phát minh của Web3. Thực tế, chu kỳ chuyên biệt hóa và tích hợp đã thúc đẩy nhiều chu kỳ đổi mới trong quá khứ.

• Trong thời kỳ đầu của PC, CPU là một giải pháp tổng quát cho tất cả các tác vụ tính toán.
• Cuối cùng, các trường hợp sử dụng mới đã yêu cầu các module chuyên biệt bên ngoài CPU.
  • Đồ họa được chuyển sang GPU,
  • Âm thanh sang sound card,
  • Và mạng sang network card.

Mỗi module chuyên biệt này dần dần trải qua nhiều vòng cải tiến, trở nên tiêu chuẩn hóa và được thương mại hóa.

Khi các giải pháp modular hóa này được tối ưu hóa và tiêu chuẩn hóa đủ tốt, việc tích hợp chúng trở lại thành một gói duy nhất trở nên hiệu quả hơn.

Hiện nay, hầu hết các bộ vi xử lý và SoC (System on Chip) là các sản phẩm tích hợp, xử lý tính toán tổng quát, đồ họa, âm thanh, và mạng trong một hệ thống duy nhất.

Tương tự, nhiều phần của kiến trúc blockchain modular cũng sẽ được tích hợp lại để tăng hiệu quả.

Bước tiếp theo: Tích hợp sản xuất khối và tự động hóa khả năng mở rộng

Có một điều thú vị xảy ra khi bạn di chuyển tất cả các thành phần sản xuất khối ra khỏi mainnet. Giống như cách mà các bộ xử lý hiện đại đã tích hợp các module tính toán khác nhau vào một SoC duy nhất để cải thiện hiệu quả, kiến trúc blockchain trong tương lai sẽ tích hợp các module sản xuất khối thành một module duy nhất.

Lý do duy nhất mà các module sản xuất khối này từng bị tách ra ngay từ đầu là để chuyển tác vụ thực thi ra khỏi mainnet. Tuy nhiên, với một kiến trúc bảo mật tích hợp, việc giữ chúng tách biệt không còn hợp lý nữa.

Chúng tôi dự đoán rằng DA, execution, và settlement ngoài mainnet sẽ được tích hợp lại thành một thành phần duy nhất để tăng hiệu quả và khả năng mở rộng.

Thay vì chỉ để mainnet duy trì và chia sẻ bảo mật, chúng ta có thể thêm một chức năng mới vào mainnet: tự động hóa việc khởi chạy các thành phần ngoài mainnet. Bằng cách modular hóa toàn bộ các module sản xuất khối ra khỏi mainnet và tích hợp khả năng tự động khởi chạy các module ngoài mainnet, chúng ta có thể xây dựng một kiến trúc mở rộng vô hạn.

Thực tế, đây chính là kiến trúc của Saga.

• Chúng tôi gọi mainnet là Saga Platform Chain.
• Và thành phần sản xuất khối ngoài mainnet được gọi là Chainlet.

Kết luận

Liệu modularity trong blockchain có phải là điều tất yếu? Chắc chắn là vậy. Trong bài viết này, chúng ta đã tìm hiểu những động lực và con đường trong hệ sinh thái blockchain đã dẫn chúng ta đến kiến trúc modular hiện tại. Sau đó, chúng ta đã phác thảo những hạn chế của kiến trúc modular ở thời điểm hiện tại.

Cuối cùng, chúng ta đã khám phá bước tiếp theo của modularism. Với bảo mật được modular hóa và tích hợp lại chu trình sản xuất khối, chúng ta có thể thấy rõ sự đổi mới tiên tiến nhất đang dần hội tụ về thiết kế của Saga.

Hãy chứng kiến trạng thái tất yếu của modularism đang diễn ra ngày hôm nay tại Saga.