Monad Lianchuang: Sau Cancun, điểm nghẽn về hiệu suất của Rollup là gì?
Tác giả gốc: Keone Hon, đồng sáng lập Monad
Biên soạn bởi: Odaily Azuma
Ghi chú của biên tập viên: Sáng ngày 26 tháng 3, giờ Bắc Kinh, Keone Hon, người đồng sáng lập Monad đã xuất bản một bài viết chuyên sâu về tình trạng hiệu suất của Rollup trên Personal X. Trong bài viết, Keone đã trình bày chi tiết cách tính giới hạn TPS lý thuyết của Rollup sau khi nâng cấp Cancun và giải thích lý do tại sao phí giao dịch duy nhất của một số Lớp 2 (Cơ sở) vẫn cao tới vài đô la sau khi nâng cấp. vạch ra những thách thức mà Rollup gặp phải. Một số hạn chế về nút thắt cổ chai và những cải tiến tiềm năng.
Sau đây là nội dung gốc của Keone, do Odaily biên soạn, để thuận tiện cho độc giả, người dịch đã có những bổ sung nhất định vào nguyên văn.
Gần đây trên thị trường đã có một số cuộc thảo luận về các tắc nghẽn thực thi Rollup và các giới hạn Gas, không chỉ liên quan đến Lớp 1 mà còn liên quan đến Lớp 2. Tôi thảo luận về những tắc nghẽn này dưới đây.
Tính sẵn có của dữ liệu (DA)
Với việc giới thiệu cấu trúc dữ liệu Blob (EIP-4844) trong bản nâng cấp Cancun, tính khả dụng của dữ liệu (DA) của Ethereum đã được cải thiện rất nhiều. Các giao dịch đồng bộ hóa dữ liệu Lớp 2 không còn cần phải tính phí như các giao dịch Lớp 1 thông thường. Đấu thầu trên thị trường.
Hiện tại, dung lượng của Blobs là khoảng ba Blobs 125 kb mỗi khối (12 giây), tức là 31,25 kb mỗi giây. Do kích thước của một giao dịch là khoảng 100 byte, điều này có nghĩa là tất cả các Rollups chia sẻ TPS là khoảng 300.
Tất nhiên, có một số thông tin ở đây cần có những nhận xét đặc biệt.
Đầu tiên, nếu Rollup áp dụng công nghệ nén dữ liệu giao dịch tốt hơn để giảm quy mô của một giao dịch, TPS có thể phát triển.
Thứ hai, về mặt lý thuyết, ngoài việc sử dụng Blob để đồng bộ dữ liệu, Rollup còn có thể tiếp tục sử dụng calldata để đồng bộ dữ liệu (tức là giải pháp cũ trước khi nâng cấp Cancun), mặc dù làm như vậy sẽ mang lại thêm độ phức tạp.
Thứ ba, có sự khác biệt trong cách xuất bản trạng thái của các bản tổng hợp ZK khác nhau (đặc biệt là zkSync Era và Starknet), vì vậy đối với các bản tổng hợp này, phương pháp tính toán và kết quả cũng sẽ khác nhau.
Giới hạn khí cuộn
Gần đây, Base đã thu hút rất nhiều sự chú ý do sự bùng nổ phí gas, tăng lên vài đô la cho một giao dịch thông thường trên mạng.
Tại sao mạng Base chỉ xuống cấp một thời gian sau khi nâng cấp Cancun mà bây giờ nó đã quay trở lại hoặc thậm chí vượt mức trước khi nâng cấp? Điều này là do các khối trên Base có tổng giới hạn gas được thực thi thông qua một tham số trong mã của chúng.
Các thông số gas hiện được Base sử dụng giống như Optimism, nghĩa là có tổng giới hạn 5 triệu gas cho mỗi khối Lớp 2 (2 giây), khi nhu cầu (tổng số giao dịch) trên mạng vượt quá nguồn cung ( không gian khối) , việc thanh toán giá sẽ áp dụng cơ chế thực hiện theo yêu cầu, dẫn đến lượng gas trên mạng tăng đột biến.
Tại sao Base không tăng tổng giới hạn gas này? Hay nói cách khác, tại sao Rollup cần đặt tổng giới hạn gas?
Ngoài giới hạn trên của TPS về tính sẵn có của dữ liệu được đề cập ở trên, thực tế còn có hai lý do chính khác, đó là sự tắc nghẽn về thông lượng thực thi và mối nguy tiềm ẩn đối với sự phát triển của nhà nước.
Vấn đề 1: Tắc nghẽn thông lượng thực thi
Nói chung, EVM Rollup chạy EVM được phân nhánh từ Geth, có nghĩa là chúng có đặc điểm hiệu suất tương tự như ứng dụng khách Geth.
Máy khách của Geth là ứng dụng đơn luồng (nghĩa là nó chỉ có thể xử lý một tác vụ tại một thời điểm), sử dụng mã hóa LevelDB/PebbleDB và lưu trữ trạng thái của nó trong merkle patricia trie (MPT). Đây là cơ sở dữ liệu có mục đích chung sử dụng cấu trúc cây khác (cây LSM) làm lớp bên dưới để lưu trữ dữ liệu trên ổ đĩa thể rắn (SSD).
Đối với Rollup, quyền truy cập trạng thái (đọc các giá trị từ merkle trie) và cập nhật trạng thái (cập nhật merkle trie ở cuối mỗi khối) là những liên kết tốn kém nhất trong quá trình thực thi. Điều này là do chi phí cho một lần đọc từ SSD là 40-100 micro giây và do cấu trúc dữ liệu merkle trie được nhúng trong một cấu trúc dữ liệu khác (cây LSM), nên nó yêu cầu nhiều Tìm kiếm bổ sung không cần thiết.
Liên kết này có thể được hình dung như quá trình tìm kiếm một tệp cụ thể trong một hệ thống tệp phức tạp. Bạn cần phải đi từ thư mục gốc (nút gốc trie) đến tệp đích (nút lá). Khi tìm kiếm từng file, bạn cần tìm một key cụ thể trong cơ sở dữ liệu LevelDB, bên trong LevelDB bạn phải thực hiện thao tác lưu trữ dữ liệu thực tế thông qua một cấu trúc dữ liệu khác gọi là cây LSM, quá trình này gây ra nhiều bước tìm kiếm bổ sung. Các bước bổ sung này làm cho toàn bộ việc đọc và cập nhật dữ liệu khá chậm và không hiệu quả.
Trong thiết kế Monad, chúng tôi đã giải quyết vấn đề này thông qua MonadDb. MonadDb là cơ sở dữ liệu tùy chỉnh hỗ trợ lưu trữ merkle trie trực tiếp trên đĩa, tránh chi phí hoạt động của LevelDb; hỗ trợ IO không đồng bộ, cho phép xử lý song song nhiều lần đọc; bỏ qua hệ thống tệp.
Ngoài ra, cơ chế thực thi song song tối ưu được Monad áp dụng cho phép nhiều giao dịch tiến hành song song và trạng thái của chúng được trích xuất song song từ MonadDb.
Tuy nhiên, Rollup không có những tối ưu hóa này và do đó gặp trở ngại về thông lượng thực thi.
Cần lưu ý rằng ứng dụng khách Eragon/Reth có một số tối ưu hóa nhất định để đạt hiệu quả cơ sở dữ liệu và một số ứng dụng khách Rollup cũng được xây dựng dựa trên các ứng dụng khách này (chẳng hạn như OP-Reth). Erigon/Reth sử dụng cấu trúc dữ liệu phẳng, giúp giảm chi phí truy vấn khi đọc ở một mức độ nhất định; tuy nhiên, chúng không hỗ trợ đọc không đồng bộ hoặc xử lý đa luồng. Ngoài ra, gốc merkle cần được tính toán lại sau mỗi khối, đây cũng là một quá trình khá chậm.
Câu hỏi 2: Những nguy cơ tiềm ẩn của sự phát triển nhà nước
Giống như các blockchain khác, Rollup giới hạn thông lượng của chúng để ngăn trạng thái hoạt động của chúng phát triển quá nhanh.
Một lập luận phổ biến trên thị trường là lý do khiến tốc độ tăng trưởng của trạng thái đáng lo ngại là vì nếu dữ liệu trạng thái tăng lên đáng kể, nhu cầu thiết bị về ổ đĩa thể rắn (SSD) cũng sẽ phải tăng lên. Tuy nhiên, tôi nghĩ điều này hơi không chính xác, SSD tương đối rẻ (SSD 2 TB chất lượng cao có giá khoảng 200 USD) và trạng thái đầy đủ của Ethereum “chỉ” ở mức khoảng 200 GB trong lịch sử gần 10 năm của nó. Từ góc độ lưu trữ thuần túy, vẫn còn rất nhiều cơ hội để phát triển.
Mối nguy hiểm tiềm ẩn lớn hơn là khi trạng thái tiếp tục tăng lên, thời gian truy vấn đoạn trạng thái được chỉ định sẽ dài hơn. Điều này là do merkle patricia trie hiện tại sẽ sử dụng phím tắt khi đáp ứng điều kiện nút chỉ có một nút con, điều này có thể làm giảm độ sâu hiệu quả của trie và do đó tăng tốc quá trình truy vấn. Tuy nhiên, nếu trạng thái của merkle trie ngày càng trở nên đầy đủ hơn, sẽ ngày càng có ít phím tắt hơn.
Tóm lại, mối nguy tiềm ẩn của tăng trưởng nhà nước cuối cùng là vấn đề hiệu quả tiếp cận của nhà nước.Do đó, tăng cường tiếp cận nhà nước là chìa khóa để làm cho tăng trưởng nhà nước bền vững hơn.
Tại sao chỉ tối ưu hóa phần cứng lại không hiệu quả?
Lớp 2 vẫn tương đối tập trung, nghĩa là mạng vẫn dựa vào một trình sắp xếp chuỗi duy nhất để duy trì trạng thái và tạo khối. Người ta có thể hỏi, tại sao không chạy bộ sắp xếp trên phần cứng có RAM (bộ nhớ truy cập ngẫu nhiên) rất cao để tất cả trạng thái có thể được lưu trữ trong bộ nhớ?
Có hai lý do cho việc này.
Đầu tiên, điều này sẽ không giải quyết được vấn đề thắt cổ chai về tính sẵn có của dữ liệu của mạng chính Ethereum. Mặc dù dựa trên tình hình hiện tại của Base, sự gia tăng gas trong mạng không phải do mạng chính không đủ khả năng sẵn có dữ liệu, mà về lâu dài Điều này cuối cùng sẽ trở thành một nút thắt cổ chai lớn hạn chế Rollup.
Thứ hai là vấn đề phân quyền, mặc dù trình sắp xếp chuỗi vẫn mang tính tập trung cao độ nhưng các vai trò khác liên quan đến vận hành mạng cũng rất quan trọng, chúng cũng cần có khả năng chạy các nút độc lập, phát lại cùng một lịch sử giao dịch và duy trì trạng thái tương tự. .
Dữ liệu giao dịch thô và các cam kết trạng thái trên Lớp 1 không đủ để mở khóa trạng thái hoàn chỉnh. Bất kỳ vai trò nào cần quyền truy cập vào trạng thái hoàn chỉnh (chẳng hạn như người bán, sàn giao dịch hoặc nhà giao dịch tự động) phải chạy nút Lớp 2 đầy đủ để xử lý các giao dịch và có bản sao cập nhật của trạng thái.
Rollup vẫn là các chuỗi khối và chuỗi khối rất thú vị vì khả năng đạt được sự phối hợp toàn cầu thông qua trạng thái toàn cầu được chia sẻ. Đối với tất cả các blockchain, phần mềm mạnh mẽ là cần thiết và chỉ tối ưu hóa phần cứng là không đủ để giải quyết vấn đề.
tương tác cộng đồng
Sau khi Keone đăng bài viết này, các nhân sự chủ chốt của nhiều dự án Lớp 2 đã tương tác bên dưới bài đăng.
Alex Gluchowski, người đồng sáng lập zkSync, đã hỏi Monad về vấn đề này có sự khác biệt như thế nào đối với nội dung trong bài viết rằng gốc merkle cần được tính toán lại sau mỗi khối.
Câu trả lời của Keone là sẽ có một thuật toán tối ưu hóa để tính toán căn bậc merkle sau mỗi khối.
Jesse Pollak, người phụ trách Base, cũng dùng điều này để giải thích tại sao chi phí gas của Base lại tăng thay vì giảm sau khi nâng cấp ở Cancun, ông cho rằng EIP-4844 đã giảm đáng kể chi phí DA ở cấp Lớp 1. chi phí gas lẽ ra đã giảm, nhưng do các giao dịch mạng, Nhu cầu đã tăng hơn năm lần và các khối trên mạng Cơ sở có giới hạn 250 gas/s. Nhu cầu lớn hơn nguồn cung, khiến phí gas tăng.
