Được viết bởi: Decentralized.Co
Biên soạn bởi: TechFlow TechFlow
Mở rộng giao dịch luôn là một chủ đề nóng. Trong vài tuần qua, chúng tôi đã khám phá cách đơn nguyên có thể giúp mở rộng TPS.
Dưới đây là lời giải thích chi tiết về cách thức hoạt động của Monads, được viết bởi Saurabh Deshpande .
TPS là một chỉ báo mà chúng tôi rất chú ý. Chúng tôi muốn Chuỗi của mình hỗ trợ TPS cao hơn vì chúng có thể hỗ trợ nhiều người dùng và ứng dụng hơn. Biểu đồ bên dưới hiển thị số TPS cho Ethereum và L2. Chưa có Chuỗi nào vượt qua mốc 100 TPS. Lưu ý rằng TPS là một thuật ngữ chung dùng để đo lường quy mô. TPS không chính xác vì không phải tất cả các giao dịch đều giống nhau, chúng có độ phức tạp khác nhau. Nhưng để đơn giản, chúng tôi sử dụng TPS làm chỉ báo đo quy mô.
Muốn tăng TPS thì phải làm gì?
Phương pháp đầu tiên là xây dựng một hệ thống hoàn toàn mới, giống như Solana đã làm. Nó hy sinh khả năng tương thích EVM so với tốc độ. Nó sử dụng thực thi đa luồng thay vì thực thi đơn luồng (hãy nghĩ đến CPU đa lõi so với CPU lõi đơn), song song hóa các giao dịch và sử dụng cơ chế đồng thuận khác.
Phương pháp thứ hai là sử dụng khả năng thực thi ngoài Chuỗi và mở rộng Ethereum bằng một sắp xếp tập trung.
Phương pháp thứ ba là phân tách EVM thành các thành phần riêng biệt và tối ưu hóa chúng để có mở rộng.
Monad, L1 tương thích EVM mới gần đây đã huy động được 225 triệu USD, đang xây dựng EVM từ đầu thay vì sử dụng trực tiếp. Nó đã chọn phương pháp thứ ba này để tăng mở rộng.
Chúng tôi đã thảo luận về một số thay đổi lớn do Monads mang lại.
Thực thi song song
Máy ảo Ethereum(EVM) thực hiện các giao dịch một cách tuần tự. Trước khi một giao dịch được thực hiện, giao dịch tiếp theo phải chờ. Nghĩ theo cách này. Hãy xem xét một nền tảng trong một cửa hàng lắp ráp xe máy. Nhiều xe tải cung cấp phụ tùng xe máy (mỗi xe tải có tất cả các bộ phận cần thiết để lắp ráp 50 xe máy). Xưởng lắp ráp thực hiện bốn chức năng khác nhau: dỡ hàng, phân loại, lắp ráp và bốc hàng.
Trong thiết lập EVM hiện tại, chỉ có một nền tảng và cùng một vị trí được sử dụng để tải và dỡ hàng. Vì vậy, trong khi xe tải đang đỗ, các bộ phận của xe máy được dỡ xuống, phân loại, lắp ráp và chất lên cùng một xe tải. Trong khi đội ngũ phân loại đang làm việc thì đội ngũ khác đang chờ đợi. Vì vậy, nếu bạn coi công việc của họ là các vị trí riêng biệt thì mỗi đội ngũ chỉ làm việc một lần trong bốn vị trí. Điều này dẫn đến sự thiếu hiệu quả đáng kể, làm nổi bật sự cần thiết phải có một phương pháp hợp lý hơn.
Bây giờ, hãy tưởng tượng một sân ga có bốn khu vực bốc dỡ khác nhau. Ngay cả khi đội ngũ dỡ hàng chỉ có thể làm việc với một xe tải cùng một lúc, họ cũng không cần phải đợi ba suất tiếp theo. Chúng có thể được chuyển trực tiếp sang xe tải tiếp theo.
Điều tương tự cũng xảy ra với đội ngũ phân loại, lắp ráp và bốc hàng. Sau khi dỡ hàng xong, xe tải di chuyển về bãi bốc hàng chờ đội ngũ bốc xếp xếp các xe máy đã lắp ráp. Do đó, kho chỉ có một sàn và các khu vực xếp/dỡ hàng sẽ thực hiện tất cả các hoạt động một cách tuần tự, trong khi kho có 4 sàn và các khu vực xếp/dỡ hàng khác nhau sẽ thực hiện song song.
Hãy coi Monads như cơ sở hạ tầng, tương đương với một nhà kho có nhiều sàn xe tải. Nhưng nó không đơn giản. Sự phức tạp tăng lên khi phụ thuộc vào xe tải. Ví dụ, điều gì sẽ xảy ra nếu một chiếc xe tải không có đủ các bộ phận để lắp ráp 50 chiếc xe máy? Các giao dịch có thể không phải lúc nào cũng độc lập. Do đó, Monad phải xử lý các giao dịch phụ thuộc lẫn nhau khi thực hiện chúng song song.
Làm thế nào để đối phó với nó? Nó thực hiện một phương pháp gọi là thực thi song song lạc quan. Giao thức chỉ có thể thực hiện các giao dịch độc lập song song. Ví dụ: hãy xem xét 4 giao dịch trong đó số dư của Joel là 1 ETH:
Joel gửi 0,2 ETH cho Saurabh
Sid đúc NFT
Joel gửi 0,1 ETH cho Sid
Shlok mua Pepe
Tất cả các giao dịch này được thực hiện song song và các kết quả đang chờ xử lý sẽ được gửi từng cái một. Nếu đầu ra của kết quả đang chờ xử lý xung đột với đầu vào ban đầu của bất kỳ giao dịch nào, giao dịch sẽ được thực hiện lại. Giao dịch 2 và 4 không có kết quả đang chờ xử lý xung đột với đầu vào từ các giao dịch khác vì chúng độc lập với nhau. Nhưng giao dịch 1 và 4 không độc lập.
Lưu ý rằng vì cả 4 giao dịch đều bắt đầu từ cùng một trạng thái nên trọng tâm là số dư 1 ETH của Joel. Sau khi Joel gửi 0,2 ETH, số dư là 0,8 ETH. Sau khi Joel gửi 0,1 ETH cho Sid, số dư của anh ấy là 0,9 ETH. Các kết quả được gửi lần lượt, đảm bảo đầu ra không xung đột với bất kỳ đầu vào nào. Sau khi gửi kết quả đang chờ xử lý là 1, số dư mới của Joel là 0,8 ETH.
Đầu ra này xung đột với đầu vào của giao dịch 3. Vì vậy, bây giờ 3 được thực hiện lại với đầu vào là 0,8 ETH. Sau khi thực hiện 3, số dư của Joel là 0,7 ETH.
MonadDB
Tại thời điểm này, một câu hỏi rõ ràng là làm thế nào để chúng ta biết rằng chúng ta không phải thực hiện lại hầu hết các giao dịch. Câu trả lời là việc thực hiện lại không phải là nút thắt cổ chai. Nút thắt cổ chai đang truy cập vào bộ nhớ của Ethereum. Hóa ra cách Ethereum lưu trữ trạng thái trong cơ sở dữ liệu khiến việc truy cập trạng thái trở nên khó khăn (tốn thời gian và do đó tốn kém). Đây là một cải tiến khác của Monad: MonadDb. Cách cơ sở dữ liệu cấu trúc Monads giảm chi phí liên quan đến hoạt động đọc.
Khi giao dịch phải được thực hiện lại, tất cả đầu vào đều đã có trong bộ nhớ đệm, điều này dễ truy cập hơn trạng thái tổng thể.
Solana có 50 nghìn TPS trên mạng thử nghiệm của mình, nhưng hiện chỉ có khoảng 1 nghìn TPS trên mạng chính. Monad tuyên bố đã đạt được 10 nghìn TPS thực tế trên mạng thử nghiệm nội bộ của mình. Mặc dù điều này không phải lúc nào cũng thể hiện hiệu suất trong thế giới thực, nhưng chúng ta rất nóng lòng muốn xem Monad hoạt động như thế nào trong các ứng dụng trong thế giới thực.
