Modular Blockchains: Lý do và Cách hoạt động

Giới thiệu

Nếu tách lẻ các thành phần chính của một Layer 1 blockchain ra, ta có thể cải thiện các lớp riêng biệt này với sự tối ưu gấp cả trăm lần so với hiện tại. Từ đó ta có một hệ thống phi tập trung, tương thích kèm theo khả năng mở rộng tốt. Trước khi bàn thêm về modular blockchain, ta phải hiểu kiến trúc của blockchain hiện tại và những trở ngại nó gặp phải.

Blockchain là gì?

Ta nhắc lại rất nhanh về Blockchain 101 nhé. Block sẽ chứa 2 thành phần: Block Header, và dữ liệu giao dịch liên quan đến header đó. Full nodes sẽ đảm nhiệm việc xác thực blocks - phân tích và tính toán toàn bộ block data để chắc chắn các giao dịch là hợp lệ.

Hãy tóm lược ngắn gọn về các lớp chức năng cấu thành nên Blockchain:

Execution - Thực thi: Các giao dịch và quá trình chuyển tiếp của state sẽ được xử lý bước đầu tại đây. Người dùng cũng sẽ tương tác với blockchain qua lớp này như chuyển tài sản, kí giao dịch hay triển khai smart contracts.
Settlement - Dàn xếp: Đây là lớp sẽ lo kiểm chứng lại kết quả tính toán của rollups và giải quyết các tranh chấp nếu có. Lớp dàn xếp vốn không tồn tại trong Monolithic Blockchain (nguyên khối), và là một phần tùy chọn có thể thêm vào Modular Blockchain.
Consensus - Đồng thuận: Lớp đồng thuận sẽ cung cấp trình tự giao dịch và finality nhờ một loạt các full nodes tải xuống và xác minh nội dung bên trong blocks, qua đó đạt được sự đồng thuận từ quá trình chuyển giao hợp lệ của state.
Data Availability - Dữ liệu khả dụng: Phần dữ liệu cần thiết để xác minh state chuyển giao hợp lệ phải được đưa lên và trữ trên lớp này. Phải thật dễ dàng phát hiện ra trong trường hợp block producer gian lận cố tình giữ lại dữ liệu giao dịch.

Một ví dụ về Blockchain nguyên khối là Ethereum trước khi có các giải pháp rollups, tức lớp cơ sở của Ethereum sẽ đồng thời đảm nhiệm tất cả các chức năng nêu trên.

Blockchain Trilemma

Blockchains hiện tại gặp phải bài toán khó Blockchain Scalability Trilemma, tương tự như Brewer’s theorem áp dụng chung cho các hệ thống phân quyền. Kiến trúc blockchain thường thỏa hiệp, hy sinh giảm bớt một trong 3 yếu tố - phi tập trung, bảo mật hoặc khả năng mở rộng để đạt được 2 cái còn lại.

Security - Bảo mật tức nói tới khả năng hoạt động của mạng lưới khi bị tấn công, đây là yếu tố cốt lõi bậc nhất của mọi blockchains. Do đó sự đánh đổi thường sẽ đến từ tính phi tập trung hoặc khả năng mở rộng.
Để một blockchain được Decentralization - Phi tập trung, yêu cầu phần cứng không được trở thành rào cản khi tham gia mạng lưới, và tài nguyên phục vụ việc xác thực phải được đưa về mức thấp nhất.

Scalability - Khả năng mở rộng thể hiện qua throughput của blockchain đạt được chia cho phần chi phí xác minh. Có 2 cách để gia tăng throughput.
- Một là tăng trực tiếp kích thước block, cho phép block chứa nhiều giao dịch hơn, tuy nhiên cách này không thỏa đáng vì block size lớn hơn đồng nghĩa việc xác thực yêu cầu nhiều tài nguyên hơn.
- Cách thứ hai là đưa việc thực thi xuống off-chain, giảm nhẹ gánh năng tính toán các nodes trên chuỗi chính, đồng thời sử dụng các proofs hỗ trợ xác thực on-chain.

Với kiến trúc modular, blockchains có thể từng bước giải quyết Scalability Trilemma thông qua nguyên lý thiết kế Chia Để Trị hay Separation of Concerns. Với Execution Layer và Data Availability Layer được modularized (tách thành module), blockchain có thể gia tăng throughput mà vẫn giữ lại các đặc tính kiến tạo nên mạng lưới trustless và phi tập trung, mối tương quan giữa khả năng tính toán và chi phí xác minh nay được tháo gỡ. Ta sẽ hiểu điều này có thể được thực hiện thế nào nhờ vào Frault Proofs, Rollups và mối liên quan giữa chúng và Data Availability - Tính khả dụng / sẵn có của dữ liệu. ‍

Đọc thêm về cách hoạt động của rollups ở bài này của bọn mình nhé:

Data Availability, Fault Proofs và Optimistic Rollups

Sau khi đọc xong bài rollups. Chắc hẳn, mấy bạn cũng nắm được khá khá cách hoạt động của Optimistic Rollups rồi. Mục này ta sẽ đi vào tìm hiểu xem cách mà Ethereum sẽ tương tác với Optimistic Rollups thông qua Fault Proofs (bằng chứng chứng minh gian lận). Đồng thời tìm ra các vấn đề mà nếu áp dụng Modularization thì liệu có thể khắc phục được hay không?

Cách mà Fault Proofs được Ethereum xử lý

Vitalik cho rằng nên tập trung giao cho một đơn vị đảm nhiệm sản xuất block. Cùng lúc duy trì tính phi tập trung tối đa cho việc xác thực. Điều này được thực hiện bằng cách chia các blockchain nodes ra thành Full Nodes và Light Clients. Hai vấn đề chính cần phải giải quyết ở đây là Block Validation (xác nhận kết quả tính toán từ Optimistic Rollups là chính xác) và Block Availability (đảm bảo toàn bộ dữ liệu để xác thực kết quả tính toán đã được cung cấp đầy đủ).

Full nodes sẽ có nhiệm vụ là tải xuống, tính toán và xác thực tất cả giao dịch bên trong block. Light Clients thì chỉ thu thập block headers từ full-nodes và mặc định coi các giao dịch là đã hợp lệ cho đến khi tiếp nhận Fault Proofs.

Do đó Light Clients phải phụ thuộc vào Fault Proofs được dựng bởi full nodes mới có thể nhận ra đâu là giao dịch gian lận. Trong trường hợp xuất hiện sự bất đồng nhất giữa Fault Proof với State của node đang nắm giữ, Full nodes sẽ phải thực thi lại những giao dịch có liên quan, dẫn đến phần tài sản bonding của sequencers nào gửi giao dịch gian lận sẽ bị network thu lại và gửi cho verifiers (bên đưa ra Fraud Proofs).

Hình bên dưới mô tả một cách đơn giản nhất quá trình chuyển giao state.

Đối với Ethereum + Rollups thì phần block trong hình sẽ chứa các giao dịch từ Rollups (Layer 2). Ở đây State có thể hiểu là trạng thái của chain.

Mô hình Fault Proof và Light Clients hoạt động dựa trên Honest Minority Assumption (giả định một thiểu số trung thực). Tức chỉ cần duy nhất một full nodes trung thực trữ toàn bộ state của chuỗi cung cấp Fault Proof. Thiết kế này đặc biệt phù hợp với các Sharded Blockchains vì validators có thể chọn chạy full-node trên một shard và Light Clients cho phần còn lại, từ đó vẫn duy trì được tính bảo mật trên tất cả các shards.

Optimistic Rollups sử dụng mô hình này để đảm bảo tính trung thực của sequencers - những máy tính lo việc đóng gói và thực thi các batch (lô) giao dịch, sau đó đưa dữ liệu đã nén lên chuỗi chính. Nỗ lực tính toán được chuyển xuống off-chain cho phép thông lượng giao dịch tăng lên tới 10-100 lần.

Muốn trở thành sequencer yêu cầu nodes phải ký gửi tài sản - bonding. Đơn vị verifiers sẽ theo dõi sự đồng bộ giữa state của chuỗi chính và rollup để đưa ra Fault Proof và lấy phần tài sản bonded của sequencer không làm đúng trách nhiệm.

Optimistic rollups cũng chỉ cần duy nhất một verifier trung thực còn hoạt động trong mạng lưới cung cấp Fault Proof, trước đó mặc định là state sẽ được chuyển giao hợp lệ. Quá trình tranh chấp sẽ diễn ra trên lớp thực thi của chuỗi chính.

Đây là cách để tăng thông lượng giao dịch cùng lúc giảm thiểu sự tin cậy giữa các đơn vị trong hệ thống: Tập trung hóa việc tính toán và phi tập trung hóa trình xác thực.

The Data Availability Problem

Biết là Fault Proofs rất hữu dụng để giải quyết vấn đề xác thực block. Thế nhưng full-nodes vẫn phải phụ thuộc vào tính khả dụng của block (data của block đó) mới có thể dựng Frault Proofs. Trong trường hợp có một block producer (chạy full nodes cho Ethereum và đảm nhiệm luôn việc sequencers cho Optimistic Rollups) gian lận chỉ cung cấp block header và giữ lại một phần dữ liệu, cố tình ngăn cản các nodes khác (làm nhiệm vụ xác thực) phát hiện ra giao dịch không hợp lệ do thiếu dữ liệu của block để dựng Fault Proof. Hình thức tấn công này dù sao cũng không phải vấn đề quá lớn với full nodes khác nhờ việc các full nodes phải tải xuống toàn bộ block nên dễ dàng nhận ra sự mâu thuẫn ở các phần dữ liệu bị khuyết.

Tuy nhiên, đây lại là vấn đề đối với Light Clients vì Light Clients chỉ thu thập Block Header nên có thể bị đánh lừa do từ đầu đã mặc định chấp nhận những giao dịch từ rollups kia là hợp lệ. Vấn đề này liên quan tới tính khả dụng của dữ liệu mà mô hình Fault Proof gặp phải: phải có cách để Light Clients dù không tải toàn bộ lịch sử của chain vẫn có dữ liệu khi cần thì xác minh tìm ra được giao dịch không hợp lệ trả về từ rollups ⇒ full nodes và Light Clients sẽ dễ dàng đạt được đồng thuận và không bị bỏ sót giao dịch bẩn.

Solutions

Một cách để đạt được điều này là thông qua kỹ thuật phân tách dữ liệu Erasure Encoding (EC). Có thể đọc thêm về kĩ thuật này ở đây:

Để giúp Light Clients không phải chứa toàn bộ lịch sử giao dịch nhưng vẫn có data khi cần thiết để tạo Frault Proof thì giải pháp là với mỗi block dữ liệu trong block sẽ được copy thành 2 bản sao sau đó áp dụng kĩ thuật EC để phân tách dữ liệu từ 2 bản sao này thành các mảnh nhỏ.

Các nodes (bao gồm Light Clients) chỉ cần lưu một vài mảnh dữ liệu là có thể tái tạo lại toàn bộ block dù có những phần dữ liệu thiếu sót. Bằng cách sử dụng Data Availability Sampling (DAS). Một kỹ thuật thu gom dữ liệu, tái tạo lại bản gốc cho phép Light Clients lấy mẫu ngẫu nhiên một vài mảnh dữ liệu (chunks) đại diện để tái tạo lại block, sau đó thông qua xác suất thông kê để chắc chắn dữ liệu giao dịch đã được cung cấp đầy đủ.

Tuy nhiên, kĩ thuật này có một vài lưu ý: Thực hiện DAS có thể gây ra độ trễ cao và tương tự như mô hình giả định thiểu số đáng tin, sẽ chỉ đạt được hiệu quả khi có đủ số lượng Light Clients đồng thời lấy mẫu.

Data Availability đối với ZK-Rollups và Validity Proofs.

Một phương án giúp phi tập trung trình xác thực là loại bỏ việc cần dữ liệu giao dịch để chuyển giao state. Điều này dân tới phát kiến Zero Knowledge Rollups (ZKR). Các bạn có thể đọc kĩ hơn ở bài rollups (link ở trên).

ZKR là mô hình rollups sử dụng Validity Proof thay vì Fault Proof để xác thực chuyển giao state (cập nhật giao dịch từ L2 về L1). Trong hệ thống sẽ có 2 đơn vị, Sequencer lo tính toán còn Prover tạo ra các proof tương ứng. Dù ZK-Rollups đã giao lại việc thực thi off-chain cho Sequencers, nhưng proof thì vẫn phải được xác thực on-chain. Đây trở thành bottleneck cho cách làm này.

Nhờ vào các công nghệ mã hóa Zero Knowledge như SNARKs and STARKs, Validity Proofs được sinh ra với nhiệm vụ có thể dùng toán để xác thực lại proofs mà không cần có verifiers, với đặc tính của ZK sẽ đảm bảo tính chính xác và hợp lệ của quá trình chuyển giao state. Đánh đổi lại là mỗi lần như vậy cần dựng một proof mới. So với Fault Proof, Validity Proof đòi hỏi nhiều khả năng tính toán hơn từ sequencers do đó sẽ khó khăn hơn trong việc mở rộng (giảm chi phí, giảm độ trễ), chưa kể thiết kế Execution layer trên zk rollups sao cho giống với EVM cũng sẽ khó hơn.

Lưu ý rằng kỹ thuật cho phép Light Clients xác thực state chỉ áp dụng cho mô hình Fault Proof. Vì quá trình chuyển giao state đã được đảm bảo là hợp lệ với Validity Proof, các nodes chẳng còn cần tới dữ liệu giao dịch để xác thực block. Nhưng lại cần để thực hiện chuyển giao và cập nhật state cho phép người dùng kiểm tra số dư, tương tác với ZK-Rollups.. Do đó, mô hình Validity Proof vẫn sẽ bị ràng buộc bởi các vấn đề liên quan tới Data Availability. Nhiệm vụ của Ethereum bây giờ là làm sao đảm bảo dược Data Available nhưng nodes sẽ không phải lưu trữ quá nhiều data ⇒ Giảm chi phí tạo proofs ⇒ Giảm chi phí cho người dùng rollups.

Giai đoạn hiện nay

Dẫu rằng ta có thể tăng Throughput Rollup lên theo cấp số nhân nhờ vào việc Block Production sẽ Centralized ⇒ Có thể tăng block size và chứa nhiều giao dịch trong 1 block hơn do Block Producers (nodes đảm nhiệm tạo block) có thể thoái mái nâng cấp phần cứng mà vẫn giữ được Decentralization thông qua việc block validation được tách riêng ra khi áp dụng mô hình PBS.

Bạn có thể đọc về PBS ở đây:

Lưu ý: Mô hình PBS này chưa được Ethereum áp dụng, các thiết kế vẫn đang trong quá trình discuss.

Vấn đề scale băng thông vẫn phần nào phụ thuộc vào Data Avalability của block thay vì khả năng xác thực nó. Điều này dẫn tới một kết luận: Bất kể ta có Execution Layer mạnh mẽ đến mức nào, hay tích hợp bất kể loại proof gì đi nữa, Throughput đạt được cuối cùng vẫn bị giới hạn bởi tính khả dụng của data.

Hiện tại, cách để chắc chắn dữ liệu khả dụng là đưa dữ liệu lên on-chain. Rollups sẽ cung cấp định kì tất cả rollup block và tận dụng Ethereum Mainnet làm lớp Data Availability cho mình. Vấn đề của cách làm này là ở chỗ kiến trúc hiện tại của Ethereum buộc full nodes phải tải xuống toàn bộ block mới đảm bảo được dữ liệu khả dụng. Nếu ta tăng kích thước block, mặc định yêu cầu phần cứng để chạy full nodes sẽ tịnh tiến theo. Điều này lại vô tình khiến mạng lưới càng trở nên centralized hơn.

Trong tương lai, Ethereum sẽ triển khai sharding và trở thành một hệ thống sharded để tích hợp Data Availability Sampling, cho phép cả full nodes lẫn Light Clients cùng đóng góp bảo mật cho mạng lưới. Tuy nhiên, điều này cũng chỉ giải quyết một phần câu chuyện, vấn đề khác mà rollups phải đối mặt là chi phí lưu trữ rollup data trên Ethereum. Định dạng ‘calldata’ hiện tại rollups sử dụng rất đắt đỏ, mặc định ở 16 gas/byte bất kể kích thước lô giao dịch của rollup.

Công thức tính chi phí rollups sẽ như sau:

Total Gas Cost = Fixed Cost + (Batch Size * Call data gas)

Trong đó:

Total Gas Cost: Tổng chi phí gas mà rollups phải trả.
Fixed Cost: Chi phí gas cố định không thay đổi
Batch Size: Số lượng transaction trong 1 batch.
Call data gas: Giá gas cho lưu trữ calldata

Batch Size Total Cost — Batch Size vs Total Cost

Như các bạn thấy trong công thức này, tổng phí gas chỉ có thể giảm đi nếu ta giảm được lượng chi phí có call data gas. Khi mà hoạt động trên rollups tăng đột biến, 1 batch (lô) dữ liệu càng chứa nhiều giao dịch hơn thì gas sẽ tăng lên theo cấp số nhân từ đó ta quay về lại tình trạng ban đầu của Ethereum.

Chào mừng tới kỉ nguyên của Modular

Validium là một thiết kế khác được Starkware đề xuất để cải thiện throughput và khả năng scale của rollups nhưng vẫn đảm bảo được tính khả dụng cho dữ liệu. Với mô hình Validium, dữ liệu của các giao dịch sẽ được gửi xuống off-chain, tới một ủy ban phụ trách. Có thể là PoS Guardians hoặc một lớp Data Availability riêng biệt nào đó, miễn là không phải lưu trên blockchain. Bằng cách chuyển sang sử dụng các giải pháp off-chain thay vì calldata trên Ethereum, Validium giảm bớt được phần phí gas/byte cố định khi mức sử dụng của rollups tăng lên. (Arbitrum Nova cũng sử dụng giải pháp tương tự).

Kiến trúc rollup cũng cho thấy blockchains không nhất thiết phải cung cấp Execution Layer. Thay vào đó chỉ cần đóng vai trò tạo blocks và đảm bảo tính khả dụng cho dữ liệu bên trong. Đây cũng là triết lý thiết kế đằng sau Celestia, một project tiên phong phát triển Modular Blockchain.

Trước đây được biết tới với tên gọi LazyLedger. Lazy có thể hiểu là ‘dựa dẫm’, tức để các lớp modules khác lo việc tính toán và xác thực. Bản thân Celestia chỉ cung cấp lớp Data Availability phục vụ việc xác thực giao dịch và đảm bảo dữ liệu luôn có sẵn thông qua Data Availability Sampling. Tiền đề cốt lõi trong thiết kế của Celestia là quy trình sản xuất block sẽ centralized, và đẩy mạnh phi tập trung với block validation. Ngay cả chiếc smartphone của bạn cũng có thể trở thành Light Client và đóng góp bảo mật cho mạng lưới.

Nhờ vào Data Availability Sampling, Celestia đóng vai trò như lớp dữ liệu khả dụng cho phép rollups sau khi cắm vào có thể tăng kích thước block lên khi số lượng Light Nodes của mạng lưới tăng lên. Điều này đồng nghĩa throughput sẽ được cải thiện đáng kể. Có thể nhắc tới một vài giải pháp khác như StarkEx, zkPorter hay Polygon Avail, chỉ duy nhất StarkEx là Validium đã và đang vận hành. Tuy nhiên, hầu hết các Validiums đều kèm theo một giả định tin tưởng vào nguồn dữ liệu, dù đó là một ủy ban uy tín, guardians hay lớp data availability chung nào đó. Các ràng buộc lòng tin này cũng cho thấy rằng các bên lưu trữ data của rollups khi có ý đồ xấu có thể chặn việc rút tiền của người dùng dù không thể tạo được giao dịch xấu trên Rollups.

Celestia 101

Celestia như đã nói sẽ mang tới rất nhiều lựa chọn. Celestia có thể là Data Availability Layer có thể là Consensus Layer. Điều quan trọng là các module của Celestia có thể gắn với các mô hình rollups khác nhau đem lại tính linh hoạt cực cao. Ở Settlement Layer, Celestia không offer module này nên thường sẽ gắn với các chain khác chẳng hạn như Evmos hay Ethereum. Khi sử dụng Ethereum cho Consensus và Settlement, thì ta có Celestium, Ở Celestium thì Ethereum sẽ outsource data từ Celestia cho Data Availibility Layer của mình. Rollups như Optimism, StarkNet,.. sẽ là lớp Execution Layer. Nhìn hình bên dưới để hiểu rõ hơn.

Celestium có thể coi là chain đáng quan tâm nhất vì nó là sự kết hợp chính của Ethereum và Celestia. Modular Blockchain là chủ đề sôi nổi rất được quan tâm gần đây. Đã có những phản đối không đồng tình, thậm chí Dankrad, người sáng chế ra mô hình Danksharding cho Ethereum cũng phản đối mô hình của Celestium, quan ngại chủ yếu đến từ các rủi ro về bảo mật và ràng buộc lòng tin nếu ta phân tách Settlement layer khỏi Data Availability layer. Celesitum hiện vẫn đang trong quá trình nghiên cứu xem xét.

Bỏ qua tranh cãi về Celestium thì ở mảng Modular Blockchain đã có những tiến bộ đáng kể được đề xuất và thực hiện trên các khía cạnh xoay quanh Modular Blockchain:

Fuel Labs đang cố gắng thiết lập Execution Layer cho phép Parallel Execution giống như Solana nhưng cho Rollups.
Team Optimism thì chọn sẽ triển khai sharding, phi tập trung hóa đơn vị sequencer hay thúc đẩy các hình thức cổ động tham gia trình xác thực.
Mô hình hybrid kết hợp giữa Optimistic Rollups và ZK-Rollups cũng đang được phát triển.
Volitions, tiên phong bởi Starkware, mang tới một giải pháp mới cho câu chuyện về tính khả dụng của dữ liệu trên chuỗi/on-chain và ngoài chuỗi/off-chain. Người dùng và nhà phát triển có thể chọn giữa việc sử dụng các validium để gửi dữ liệu giao dịch ra ngoài chuỗi hoặc giữ dữ liệu giao dịch trên chuỗi, mỗi cách đều có những điểm mạnh và điểm yếu riêng. Bọn mình sẽ nói trong các bài tới.
Lộ trình phát triển của Ethereum sau The Merge bao gồm kế hoạch hợp nhất hai lớp, Data Availability và Settlement. Đặc biệt là Danksharding - thiết kế hứa hẹn giúp chuyển đổi và tối ưu các dữ liệu trên Ethereum Layer 1 và Blockspace thành một “công cụ cung cấp dữ liệu”, từ đó L2 rollups sẽ được hưởng lợi với chi phí rẻ, throughput cao.

Một số dự án nổi bật trong mảng Modular Blockchains

Kiến trúc của Celestia tuy còn phải tranh luận thêm, nhưng cũng đem tới những ưu điểm như việc có thể xây dựng các Execution Layers đa dạng hơn cho các Layer 1s với các môi trường tính toán khác với EVM như WASM, Starknet hay Fuel VM. Khả năng chia sẻ Data Availability Layer dùng chung này cho phép các projects có thể xây cầu giữa các chain sử dụng DA của Celestia một cách an toàn hơn, mở ra khả năng kết hợp mới hệ sinh thái cũng như cross-chain như điều mà Ethereumcũng có thể thực hiện với các rollups của mình.

Ngoài ra, sự phổ cập đi kèm nhu cầu sử dụng gia tăng của các giải pháp Layer 2 sẽ mở ra cánh cửa đến với Layer 3: Fractal Scaling. Bọn mình sẽ có bài viết về Fractal Scaling sau.

Một cách dễ hiểu hơn là các projects có thể triển khai xây dựng các ứng dụng trên rollups riêng của mình (application-specific rollups) hay còn gọi là RollApps với toàn quyền kiểm soát những đặc tính của hạ tầng nền, từ tính khả dụng của dữ liệu đến quyền riêng tư. Có thể coi các RollApps này là Layer 3. Sự xuất hiện của Layer 3 đi kèm là khả năng tương thích giữa các dApps trên L3 với L2 và L1, thay vì những lựa chọn tốn kém hơn như Cosmos (application-specific sovereign chains).

Rollups trên rollups!

Kết luận

Tương tự như cách nền tảng web nguyên thủy phát triển từ máy chủ lưu trữ tại chỗ tới máy chủ điện toán đám mây. Hạ tầng web phi tập trung cũng dần mô-đun hóa (modularization), chuyển dịch từ blockchain nguyên khối với các lớp hình thành đồng thuận rời rạc, sang thiết kế modular, các chain phục vụ ứng dụng cụ thể sẽ chia sẻ sự đồng thuận lẫn nhau. Nhưng dù sao, trong tương lai modular, bất kể giải pháp hay thiết kế nào được đề xuất đi chăng nữa, người hưởng lợi cuối cùng vẫn là người dùng.