Một cái nhìn sâu sắc về Midgard so với Ethereum Rollups

Ngày 10 tháng 04 năm 2025

Layer 2 (Layer 2) Rollup đã nổi lên như một giải pháp chính để mở rộng quy mô nền tảng hợp đồng thông minh. Ethereum Rollup như Optimism và Arbitrum đã dẫn đầu sự đổi mới này. Tuy nhiên, các mô hình mới hơn như Midgard — một optimistic rollup được xây dựng cho Cardano — giới thiệu các kiến ​​trúc thay thế thách thức các giả định về phi tập trung, không cần phải được cho phép và tính hoàn tất.

Bài viết này so sánh Ethereum Rollups và Midgard trên các chiều kiến ​​trúc cốt lõi, bao gồm phi tập trung, sắp xếp, giải quyết xung đột, tính hoàn tất và mô hình trạng thái. Chúng tôi khám phá cách Midgard cung cấp một khuôn khổ xác định và phi tập trung hơn và nêu bật sự đánh đổi của các thiết kế dựa trên Ethereum hiện tại.

Để hiểu rõ hơn về chủ đề này, hãy đọc bài viết giới thiệu của chúng tôi về Midgard.

Layer 2 ưu tiên khả năng mở rộng và xác nhận trước nhanh chóng

Các Blockchain như Ethereum và Cardano ưu tiên tính phi tập trung, bảo mật, tính cởi mở và không cần phải được cho phép. Ngược lại, Layer 2 rollup tập trung vào thông lượng cao và khả năng phản hồi nhanh. Một lợi ích chính đối với người dùng là xác nhận trước nhanh chóng — một tín hiệu lạc quan, nhanh chóng từ Rollup cho biết giao dịch đã được chấp nhận và có thể được hoàn tất.

Để thực hiện được điều này, các hệ thống Layer 2 thường bỏ qua tính hoàn tất ngay lập tức để ưu tiên tốc độ xử lý. Việc phối hợp cơ chế đồng thuận phi tập trung, như được thực hiện trong các mạng Layer 1, quá chậm so với nhu cầu bao gồm giao dịch theo thời gian thực. Thay vào đó, hầu hết các Ethereum Rollup sử dụng trình sắp xếp tập trung hoặc bán tập trung để sắp xếp các giao dịch.

Optimistic Rollup cho rằng hầu hết các giao dịch đều hợp lệ và đăng dữ liệu giao dịch và trạng thái gốc của chúng lên Layer 1. Mỗi khối Layer 2 sẽ nhập vào một "cửa sổ thử thách" — một khoảng thời gian xác định mà bất kỳ ai cũng có thể gửi một bằng chứng gian lận nếu phát hiện vi phạm giao thức (ví dụ: chi tiêu gấp đôi).

Nếu không phát hiện gian lận, khối sẽ trở thành khối hoàn tất. Nhưng nếu chứng minh gian lận được gửi và xác minh, khối và bất kỳ khối kế nhiệm nào của nó sẽ bị vô hiệu hóa, kích hoạt quá trình khôi phục.

Giai đoạn thử thách có thể kéo dài hàng giờ hoặc thậm chí hàng ngày (ví dụ: 7 ngày trong một số đợt tổng hợp Ethereum), do đó tính hoàn tất thực sự bị trì hoãn. Tuy nhiên, các đợt tổng hợp vẫn tiếp tục tạo ra các khối với tần suất cao để đáp ứng kỳ vọng về thông lượng, nghĩa là trạng thái mới nhất thường tiến triển trước trạng thái đã xác nhận.

Trong hình, các khối màu xanh lá cây biểu thị trạng thái đã xác nhận. Các khối màu trắng đang trong giai đoạn thử thách. Giao dịch của Sender 1 đã được chèn vào khối Rollup 2 và sau đó vào khối Ethereum 15. Khối 2 đã vượt qua giai đoạn thử thách, khiến nó không thể thay đổi theo quan điểm của Rollup.

Giao dịch của Sender 2 đã được chèn vào khối Rollup 8 và khối Ethereum 18. Khối 8 vẫn đang trong giai đoạn thử thách. Mặc dù khối 8 được lưu trữ trong blockchain Ethereum, nhưng nó có thể được khôi phục. Dữ liệu (đầu vào giao dịch) vẫn được lưu trữ trên Ethereum mãi mãi, nhưng kết quả được yêu cầu (gốc trạng thái) có thể bị thách thức và từ chối.

Cả Người gửi 1 và Người gửi 2 đều nhận được xác nhận trước từ Rollup gần như ngay lập tức sau khi gửi giao dịch. Tuy nhiên, chỉ có Người gửi 1 mới có thể chắc chắn rằng giao dịch của mình đã được hoàn tất. Tôi sẽ đi sâu vào chi tiết sau.

Trạng thái hiện tại của Rollup được thể hiện bằng khối 12.

Trong khi Rollup được cho là kế thừa tính phi tập trung và bảo mật từ Layer 1 của chúng, điều này chỉ mạnh mẽ như cơ chế tích hợp và thực thi của chúng. Phát hiện gian lận, giải quyết tranh chấp và tính khả dụng của dữ liệu phải được kết hợp chặt chẽ với logic Layer 1 và yêu cầu sự tham gia tích cực từ các tác nhân bên ngoài như Watchers.

UTxO so với Mô hình dựa trên Tài khoản

Cốt lõi của kiến ​​trúc Rollup nằm ở một điểm khác biệt chính: mô hình trạng thái. Ethereum Rollup kế thừa mô hình dựa trên tài khoản của Ethereum, mô hình này duy trì một trạng thái tổng thể duy nhất. Mỗi giao dịch đều cập nhật ngữ cảnh toàn cầu này — số dư tài khoản, lưu trữ hợp đồng và nonce — và phải được sắp xếp theo thứ tự nghiêm ngặt. Trạng thái tổng thể này phải có thể phát lại tuần tự bởi mọi node.

Vì tất cả các giao dịch đều tương tác với cùng một trạng thái được chia sẻ, ngay cả một thay đổi nhỏ cũng có thể ảnh hưởng đến những giao dịch khác ở hạ nguồn. Tính hợp lệ phụ thuộc vào các quá trình chuyển đổi trạng thái trước đó, khiến việc xác thực các giao dịch độc lập hoặc song song trở nên bất khả thi.

Hình ảnh cho thấy quá trình xây dựng một khối mới. Khối mới phụ thuộc vào trạng thái tổng thể được chia sẻ, cụ thể là giao dịch hoàn thành (giao dịch màu đỏ). Việc xác thực giao dịch tiếp theo trong khối (giao dịch màu vàng) phụ thuộc vào giao dịch trước đó (giao dịch màu xanh lá cây).

Midgard, giống như Cardano, sử dụng mô hình UTxO mở rộng (EUTxO). Ở đây, mỗi giao dịch sử dụng các UTxO cụ thể và tạo ra các UTxO mới. Các giao dịch là cục bộ — chúng chỉ ảnh hưởng đến các UTxO mà chúng chạm vào. Không cần phải phối hợp lệnh giao dịch toàn cầu. Các xung đột như chi tiêu gấp đôi được giải quyết một cách xác định và không cần phối hợp.

Mô hình thực thi cục bộ này cho phép tính song song cao và xử lý xung đột đơn giản. Nếu hai giao dịch cố gắng sử dụng cùng một UTxO, một giao dịch sẽ bị loại bỏ. Không cần phải xác thực lại các giao dịch không liên quan.

Hình minh họa xác thực khối N. Mỗi giao dịch sử dụng UTxO từ tập hợp UTxO. Tập hợp UTxO biểu diễn ngữ cảnh (trạng thái tổng thể) để xác thực các giao dịch mới (khối). UTxO là các đối tượng độc lập phải được sử dụng toàn bộ để tạo và thêm UTxO mới vào tập hợp UTxO. Và mỗi khối mới sẽ cập nhật tập hợp UTxO. Lưu ý rằng trình tự giao dịch không quan trọng.

Trình tự và phối hợp

Ethereum Rollups phụ thuộc vào các trình sắp xếp tập trung do thiếu một mem-pool chung và các yêu cầu sắp xếp của mô hình tài khoản. Trong các hệ thống dựa trên tài khoản, tính hợp lệ của giao dịch phụ thuộc vào thứ tự. Để Phi tập trung trình tự, nhiều bên sẽ cần có chế độ xem nhất quán về các giao dịch đang chờ xử lý.

Trong hình, bạn thấy 2 trình tự xuất bản khối Rollup của họ lên blockchain Ethereum mà không có sự phối hợp. Trình tự 2 có thể đã chèn các giao dịch tương tự vào khối 9 của mình như trình tự 1 vào khối 8 của mình. Bob có thể đã cố gắng tấn công chi tiêu gấp đôi. Sự phi tập trung của trình tự đòi hỏi sự phối hợp.

Việc phối hợp các trình tự sẽ yêu cầu một mem-pool chung, cùng với những thứ khác.

Rất khó để xây dựng một mem-pool thống nhất toàn cầu. Nó sẽ yêu cầu:

• Logic loại bỏ trùng lặp
• Ngăn chặn việc sắp xếp lại giao dịch
• Cơ chế kháng thuốc MEV
• Đồng bộ hóa để tránh tình trạng fork hoặc tình trạng chạy đua

Nếu không có điều này, các trình sắp xếp khác nhau có thể thấy các tập giao dịch xung đột và tạo ra các trạng thái khác nhau. Do đó, các trình sắp xếp tập trung thống trị các đợt tổng hợp Ethereum — chúng đơn giản hóa việc phối hợp bằng cách thực thi một lệnh toàn cầu.

Trong hình, bạn có thể thấy một mem-pool được chia sẻ cho các trình sắp xếp. Điều này cho phép Rollup đảm bảo tính duy nhất của các giao dịch trong trình tự trên các khối Rollup. Các khối 8 và 9 không xung đột với nhau.

Midgard tránh được những vấn đề này. Nhờ mô hình UTxO của nó, xung đột là nhị phân và cục bộ. Các giao dịch có thể hợp lệ (UTxO chưa chi) hoặc không hợp lệ (đã chi). Không có trạng thái chung nào để phối hợp. Các toán tử Midgard tạo ra các khối theo trình tự trong các khoảng thời gian đã lên lịch (chuyển đổi) được thực thi bởi hợp đồng thông minh Scheduler dựa trên Cardano.

Người vận hành coi khối chưa xác nhận mới nhất trong danh sách chờ trạng thái là trạng thái đang hoạt động. Họ có thể xác thực khối này trước khi xây dựng khối của riêng họ. Nếu các khối trước đó hợp lệ, khối của riêng họ cũng có thể được hoàn thiện. Điều này mang lại sự an toàn với chi phí tối thiểu.

Khối Midgard chứa tập hợp UTxO hiện tại. Việc thêm khối mới yêu cầu sử dụng tập hợp UTxO từ khối trước đó và xác thực các giao dịch mới dựa trên khối đó.

Trong hình, bạn có thể thấy toán tử Midgard 1 đang thêm khối 6. Bộ UTxO hiện tại từ khối 5 được sử dụng cho quá trình chuyển đổi trạng thái. Các giao dịch màu xanh lam chi tiêu các UTxO màu xanh lam. Toán tử Midgard 2 đã thêm khối 7. Các giao dịch màu đỏ chi tiêu các UTxO màu đỏ. Nó đã sử dụng bộ UTxO hiện tại từ khối 6 trước đó để xác thực các giao dịch. Các UTxO màu xanh lá cây là các UTxO mới được tạo sau khi thêm khối 6. Lưu ý rằng các UTxO màu xanh lam không có trong bộ UTxO sau khi thêm khối 7 (chúng đã được chi tiêu).

Hình ảnh cho thấy cùng một kịch bản từ góc nhìn chuyển đổi trạng thái. Chuyển đổi trạng thái diễn ra thông qua việc cập nhật một tập hợp UTxO. Các giao dịch và UTxO đã sử dụng có tương quan về màu sắc. Các UTxO màu xanh lá cây và tím được tạo mới sau khi các giao dịch được xử lý (các UTxO đã sử dụng được xóa khỏi tập hợp UTxO trong khi các UTxO mới được thêm vào). Tập hợp UTxO từ khối 5 là đầu vào cho quá trình chuyển đổi trạng thái cũng như tất cả các giao dịch (sự kiện) từ khối 6. Nói cách khác, tập hợp UTxO từ khối trước là ngữ cảnh xác thực cho khối tiếp theo. Để đơn giản, chúng tôi chỉ xem xét các giao dịch Midgard.

Ví dụ về xung đột trình tự

Giả sử Alice gửi hai giao dịch:

• TX1: 5 ETH cho Bob
• TX2: 5 ETH cho Charlie

Cô ấy chỉ có 5 ETH. Nếu Sequencer A nhìn thấy TX1 trước, TX2 không hợp lệ. Nếu Sequencer B nhìn thấy TX2 trước, TX1 không hợp lệ. Cả hai giao dịch đều hợp lệ riêng lẻ, nhưng không hợp lệ khi kết hợp. Một hệ thống phi tập trung phải hoàn tất giao dịch nào đến trước. Nếu không có thứ tự chuẩn mực đã thỏa thuận, thì việc fork và tranh chấp là điều không thể tránh khỏi.

Lưu ý rằng ngay cả khi việc sắp xếp không phải là vấn đề (và cả hai khối 8 đều có thể được thêm vào theo thứ tự đã thỏa thuận), Rollup vẫn cần phải bảo vệ chống lại các cuộc tấn công chi tiêu gấp đôi. Ethereum Rollups có thể ứng dụng sắp xếp theo kiểu Midgard dựa trên sự thay đổi bằng cách sử dụng Scheduler, nhưng điều này sẽ không giải quyết được vấn đề phối hợp. Nó vẫn yêu cầu:

• Một mem-pool giao dịch được chia sẻ
• cơ chế đồng thuận về các quy tắc bao gồm
• Chiến lược giải quyết Fork

Trên thực tế, điều này sẽ tạo lại độ phức tạp đồng thuận Layer 1 chỉ dành cho trình tự Layer 2.

Hãy cùng xem cách giải quyết xung đột tương tự trong trường hợp mô hình UTxO dễ dàng như thế nào. Chúng ta sẽ quay lại chủ đề này sau.

Mô hình UTxO cung cấp giải pháp giải quyết xung đột đơn giản hơn

Ngược lại, các mô hình UTxO làm cho việc giải quyết xung đột trở nên tầm thường. Nếu hai giao dịch cố gắng sử dụng cùng một UTxO, một giao dịch sẽ bị loại bỏ. Không cần ngữ cảnh trạng thái trước đó hoặc thực hiện lại. Ví dụ:

• Khối N: TX_A chi tiêu UTxO_X
• Khối N+1: TX_B cũng cố gắng sử dụng UTxO_X → không hợp lệ

Hệ thống có thể phát hiện và loại bỏ TX_B một cách xác định. Nếu cả hai đều nằm trong cùng một khối, khối đó không hợp lệ. Trong quá trình xây dựng khối mới, toán tử sẽ bao gồm khối đầu tiên và loại bỏ khối thứ hai (ví dụ, dựa trên thời gian gửi giao dịch). Không có sự mơ hồ.

Xác thực Midgard và Bối cảnh UTxO

Xác thực một giao dịch trong Midgard chỉ yêu cầu biết tập UTxO hiện tại. Nếu các UTxO mà nó muốn sử dụng có sẵn và chưa được chi tiêu, thì nó hợp lệ. Không cần phải xem xét thứ tự của các giao dịch khác trong cùng một khối. Xung đột được ngăn chặn và việc xác thực lại các giao dịch không liên quan là không cần thiết.

Điều này làm cho hệ thống có thể song song hóa cao, có tính tất định và chống lại các vấn đề phối hợp. Các giao dịch được xử lý độc lập và mỗi khối hoàn toàn độc lập.

Trong hình, bạn có thể thấy rằng Midgard Operator 2 đã loại bỏ giao dịch mà nó muốn đưa vào khối như giao dịch thứ ba (nhưng thứ tự không quan trọng, tôi sử dụng thứ tự chỉ vì lý do giải thích) vì giao dịch đang cố gắng sử dụng UTxO đã được chi tiêu trong khối trước đó. Điều này không ảnh hưởng đến các giao dịch khác trong khối 6.

Tại sao Ethereum Rollups không thể chỉ sử dụng Midgard Scheduler cho trình tự phi tập trung

Một câu hỏi thường gặp nảy sinh khi so sánh Midgard với Ethereum rollups: "Tại sao Ethereum rollups không thể sử dụng Scheduler như Midgard để chỉ định lượt tuần tự và tránh xung đột?"

Thoạt đầu, có vẻ khả thi. Midgard sử dụng Hợp đồng Lập lịch để chỉ định các ca cố định cho người vận hành, mỗi ca tạo ra một khối. Người vận hành chỉ cần bộ UTxO hiện tại để tiếp tục. Liệu các đợt tổng hợp Ethereum không thể làm như vậy sao — Sequencer 1 xây dựng trên trạng thái đã biết, tiếp theo là Sequencer 2?

Câu trả lời là không, do có sự khác biệt cơ bản giữa mô hình eUTxO của Midgard và mô hình dựa trên tài khoản của Ethereum.

Mô hình eUTxO của Midgard cập nhật tập UTxO một cách xác định và cục bộ. Mỗi UTxO chỉ có thể được chi tiêu bởi một giao dịch, do đó các xung đột như chi tiêu gấp đôi bị cô lập và nhị phân (chúng có thể xảy ra hoặc không xảy ra). Các giao dịch không dựa vào trạng thái tổng thể hoặc can thiệp vào các phần không liên quan của hệ thống.

Điều này cho phép các nhà điều hành xác thực các giao dịch một cách độc lập, loại bỏ các giao dịch xung đột mà không làm gián đoạn khối. Các nhà điều hành không cần phải phối hợp hoặc chia sẻ một mem-pool — họ chỉ cần theo dõi các ca được xác định của Scheduler, xây dựng trên trạng thái hợp lệ mới nhất. Sự kết hợp giữa logic theo lượt và logic xác định này làm cho Midgard có thể chống xung đột và song song hóa.

Mô hình dựa trên tài khoản của Ethereum làm mọi thứ trở nên phức tạp. Tính khả dụng của dữ liệu không chỉ là lưu trữ dữ liệu giao dịch; nó còn đòi hỏi phải tái tạo trạng thái hiện tại từ các giao dịch trước đó. Mỗi khối phụ thuộc vào thứ tự và nội dung chính xác của các giao dịch trước đó, điều này có thể gián tiếp ảnh hưởng đến các khu vực không liên quan như logic hợp đồng.

Sequencer 2 trong Ethereum rollups không chỉ có thể dựa vào gốc trạng thái mới nhất; nó cần lịch sử giao dịch đầy đủ và thứ tự được Sequencer 1 xử lý để tính toán trạng thái hiện tại chính xác. Nếu không có dấu vết này, Sequencer 2 không thể xác thực các giao dịch mới. Một mem-pool được chia sẻ là điều cần thiết để phối hợp — nếu không có nó, các sequencer khác nhau có thể xây dựng trên các nhóm giao dịch xung đột, dẫn đến các trạng thái khác nhau.

Nếu Sequencer 1 giữ lại hoặc trì hoãn việc đăng danh sách giao dịch của mình, Sequencer 2 sẽ bị kẹt và không thể tiếp tục. Trong trường hợp xảy ra xung đột, tất cả các giao dịch trước đó phải được phát lại để xác định sự khác biệt, khiến tính nhất quán và khả năng truy xuất trở nên quan trọng đối với các đợt tổng hợp Ethereum.

Trong Midgard, chỉ cần truyền tập UTxO giữa các toán tử. Mỗi khối cục bộ và xác định biến đổi tập UTxO, đảm bảo xác thực nhanh chóng và đơn giản. Toán tử lấy tập UTxO từ Lớp khả dụng dữ liệu (Lớp DA) và xác minh các giao dịch mới bằng cách đảm bảo đầu vào không được chi tiêu. Điều này tránh việc phát lại toàn bộ dấu vết giao dịch và làm cho Midgard hiệu quả và nhỏ gọn.

Trong Ethereum rollups, trình tự phải tải xuống dữ liệu giao dịch và phát lại toàn bộ trạng thái để tiếp tục, điều này làm chậm quá trình. Cả hai hệ thống đều phụ thuộc vào DA Layers, nhưng Midgard chỉ yêu cầu kiểm tra UTxO, trong khi Ethereum phải xử lý việc tái tạo trạng thái đầy đủ.

Trong khi Trình lập lịch của Midgard cho phép hoạt động trơn tru và không xung đột nhờ mô hình UTxO xác định, thì mô hình dựa trên tài khoản của Ethereum và sự phụ thuộc vào trạng thái tổng thể khiến cách tiếp cận như vậy trở nên không thực tế nếu không gây ra sự phức tạp đáng kể.

Phi tập trung và tính cởi mở

Hầu hết các bản tổng hợp Ethereum đều được vận hành bởi cùng một nhóm đã xây dựng chúng. Các nhóm này kiểm soát trình sắp xếp, trình chứng minh và cơ sở hạ tầng chống gian lận hoặc chống hợp lệ. Mặc dù Ethereum thực thi tính bất biến sau khi dữ liệu được đăng, nhóm quyết định:

• Những gì được đăng
• Theo thứ tự nào
• Khi nó được đăng (hoặc không được đăng)
• Bằng chứng gian lận có thể được nộp bởi ai
• Có chấp nhận chứng minh gian lận không

Một số rollup hỗ trợ việc bao gồm bắt buộc (ví dụ: Optimism), nhưng điều này thường liên quan đến sự chậm trễ, giao dịch đặc biệt hoặc danh sách cho phép. Trong thực tế, nếu trình sắp xếp bỏ qua giao dịch của bạn, giao dịch đó có thể không bao giờ được bao gồm.

Phi tập trung chỉ có hiệu quả khi có nhiều thực thể độc lập với nhiều sở thích, hệ tư tưởng hoặc mô hình kinh doanh khác nhau tham gia. Trong một hệ thống được kiểm soát tập trung, không có giải pháp thay thế nào để thách thức hoặc sửa chữa các quyết định do một cơ quan duy nhất đưa ra. Ví dụ, nếu một cơ quan trung ương quyết định chặn các giao dịch của Bob, không có nhóm nào khác (hoặc trình tự) có thể can thiệp để đưa chúng vào một khối.

Layer 2, giống như Blockchain, phải luôn mở cửa cho mọi người tham gia. Nếu tính mở này không được đảm bảo, người dùng buộc phải dựa tin tưởng một cơ quan kiểm soát duy nhất, phá vỡ mục đích của phi tập trung.

Hãy cùng giải thích trong những trường hợp nào một nhóm có thể khởi tạo lệnh khôi phục.

Mỗi khối Rollup mới chứa một lô giao dịch Layer 2 được trình sắp xếp xử lý. Khi trình sắp xếp gửi một khối (dưới dạng nén) đến Ethereum, nó sẽ bao gồm dữ liệu giao dịch (dưới dạng calldata hoặc blob). Sau khi xử lý các giao dịch này, một gốc trạng thái mới được tạo, đại diện cho trạng thái được cập nhật. Mỗi khối tạo ra một gốc trạng thái được đề xuất mới, ngay cả khi các khối trước đó vẫn chưa được hoàn thiện.

Gốc trạng thái được lưu trữ như một lịch sử nội bộ trong hợp đồng thông minh của rollup hoặc cơ sở hạ tầng off-chain. Tuy nhiên, chỉ có gốc trạng thái đang chờ xử lý hoặc đã hoàn tất mới nhất mới được coi là trạng thái "hiện tại". Mỗi gốc trạng thái tóm tắt toàn bộ trạng thái của rollup bằng cách sử dụng gốc Merkle, là bản tóm tắt mật mã (hoặc dấu vân tay) của dữ liệu, không phải là dữ liệu đó.

Trong thời gian thử thách, bất kỳ ai cũng có thể gửi bằng chứng chống gian lận nếu họ tìm thấy gốc trạng thái không chính xác. Cho đến khi thời gian này kết thúc, gốc trạng thái vẫn đang chờ xử lý. Mặc dù vậy, rollup vẫn tiếp tục xây dựng các khối mới một cách lạc quan trên gốc đang chờ xử lý, tạo ra một chuỗi các gốc trạng thái chưa hoàn thiện, mỗi gốc phụ thuộc vào gốc trước đó.

Hợp đồng thông minh của rollup ứng dụng các quy tắc nghiêm ngặt. Gốc trạng thái chỉ có thể bị vô hiệu hóa trong thời gian thử thách và chỉ khi bằng chứng gian lận hợp lệ được gửi và xác minh. Khi thời gian thử thách kết thúc, gốc trạng thái trở thành cuối cùng và không thể thay đổi tùy ý.

Tuy nhiên, trong nhiều bản tổng hợp ngày nay, nhóm vẫn có thể viết lại lịch sử. Điều này là do một số bản tổng hợp sử dụng hợp đồng có thể nâng cấp hoặc giữ lại khóa quản trị. Nếu quản trị viên có quyền kiểm soát, họ có thể thay đổi logic hoặc lưu trữ ngay cả sau thời gian thử thách, xác định lại những gì được coi là chuẩn. Cho đến khi các khóa quản trị này bị xóa và hợp đồng thông minh trở nên bất biến, người dùng phải tin tưởng rằng nhóm không hành động ác ý.

Trong hình, bạn có thể thấy giao dịch của Alice đã được đưa vào khối Rollup. Sau đó, nhóm quyết định thay đổi lịch sử và không đưa giao dịch của Alice vào.

Tại Midgard, người dùng có thể gửi giao dịch thông qua hợp đồng thông minh Cardano Layer 1. Bất kỳ ai cũng có thể gửi bằng chứng gian lận. Không có danh sách cho phép hoặc quyền đặc biệt. Bất kỳ ai cũng có thể đăng ký làm nhà điều hành hoặc hoạt động như Người giám sát.

Ngay cả khi tất cả các nhà điều hành ngoại tuyến, người dùng Midgard vẫn có thể buộc thực hiện giao thức thông qua Cardano. Tất cả các logic sản xuất khối và giải quyết gian lận đều được thực thi bằng hợp đồng thông minh. Điều này làm cho Midgard cởi mở hơn và không cần phải được cho phép so với hầu hết các bản tổng hợp Ethereum.

Trong hình, bạn có thể thấy rằng tất cả các quy trình Midgard đều được kiểm soát bởi các hợp đồng thông minh xác định mà mọi người đều có thể truy cập. Không có khóa quản trị nào được sử dụng. Người dùng không phải tin tưởng nhóm. Midgard sẽ hoàn toàn không cần tin tưởng.

Đừng Làm Ác vs. Không Thể Làm Ác

Ethereum rollups dựa vào các nhóm để hành xử đúng đắn. Nếu backend kiểm duyệt, trì hoãn hoặc hành xử sai, người dùng thường bất lực. Mô hình này được xây dựng trên cơ sở "đừng làm điều xấu".

Midgard được xây dựng dựa trên "không thể là điều xấu". Không có tác nhân tập trung nào kiểm soát quá trình chuyển đổi trạng thái. Hợp đồng thông minh thực thi tất cả các quy tắc giao thức và bất kỳ ai cũng có thể giám sát hoặc can thiệp. Quyền lực được phân bổ cho nhiều tác nhân với các động cơ khác nhau, giúp hệ thống mạnh mẽ và bền bỉ hơn.

Bằng chứng về tính hoàn tất và gian lận

Trong Ethereum rollup, tính hoàn tất được xác định bởi những gì trình sắp xếp chọn để xuất bản lên Layer 1. Nhóm kiểm soát việc tạo lô và gửi bằng chứng. Mặc dù Layer 1 đảm bảo tính bất biến, cơ sở hạ tầng rollup kiểm soát những gì trở thành cuối cùng.

Đây là "vấn đề công bố đáng tin cậy": người dùng phải tin tưởng rằng trình sắp xếp sẽ công bố giao dịch của họ, ngay cả khi hợp đồng thông minh Layer 1 cho phép đưa vào.

Midgard loại bỏ vấn đề này. Khi một khối được gửi đến State Queue, nó có thể được xác thực độc lập. Nếu hợp lệ và không bị thách thức, nó sẽ được hợp nhất vào trạng thái đã xác nhận. Tính hoàn tất là xác định và được điều chỉnh bởi hợp đồng thông minh Cardano.

Bất kỳ ai cũng có thể gửi bằng chứng gian lận. Bất kỳ ai cũng có thể đóng vai trò là Người giám sát. Không có sự phụ thuộc vào backend. Scheduler xác định các ca làm việc của toán tử nhưng không ảnh hưởng đến tính hoàn tất. Khi một khối vượt qua cửa sổ thử thách, nó sẽ trở thành cuối cùng.

Người dùng Midgard có thể tin tưởng ngay vào tính hoàn tất của giao dịch. Điều này được gọi là "tính hoàn tất lạc quan an toàn".

Nếu người dùng (hoặc ví của họ) hoạt động như Người giám sát, họ có thể xác thực rằng một khối là chính xác. Nếu không thể gửi bằng chứng gian lận (tất cả các quy tắc đã được tuân thủ.), khối sẽ được hoàn tất. Điều này cho phép người dùng hành động trên trạng thái chưa được xác nhận với sự tự tin cao, biết rằng bất kỳ khối không hợp lệ nào sẽ bị từ chối một cách có thể chứng minh được.

Lời kết

Ethereum Rollups mang lại khả năng mở rộng nhưng thừa hưởng sự đánh đổi tập trung. Chúng dựa vào cơ sở hạ tầng do trình tự kiểm soát và gặp khó khăn với trình tự phi tập trung do tính phức tạp của trạng thái chia sẻ. Phi tập trung rollups có nghĩa là giới thiệu lại cơ chế đồng thuận, chỉ dưới một tên gọi khác.

Midgard, được xây dựng trên mô hình UTxO của Cardano, bao gồm chủ nghĩa quyết định, không cần phải được cho phép và phi tập trung. Với việc thực thi chuỗi trình tự, xác thực và tính hoàn tất, Midgard cung cấp một kiến ​​trúc sạch hơn và mạnh mẽ hơn.

Ethereum Rollups ngày nay đánh đổi sự phi tập trung lấy tốc độ. Midgard đánh đổi tốc độ lấy sự phi tập trung — và kết quả là xây dựng một hệ thống bền bỉ hơn, không cần tin cậy. Mặc dù Midgard có thể không đạt được tốc độ thô hoặc UX của một số Ethereum rollups, nhưng nó phi tập trung hơn và giảm thiểu sự tin cậy, phù hợp hơn với các giá trị ban đầu của Blockchain.

Nguồn bài viết tại đây

Chia sẻ bài viết này trên Twitter | Facebook | Telegram

---

Đọc thêm các bài viết liên quan tại thẻ Tags bên dưới