BTC

$96,000

5.73%

ETH

$3,521.91

3.97%

HTX

$0.{5}2273

5.23%

SOL

$198.17

3.05%

BNB

$710

3.05%

简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

Monad Lianchuang: Sau Cancun, điểm nghẽn về hiệu suất của Rollup là gì?

Đọc bài viết này mất 19 phút

Trong bài viết này, Keone Hon, người đồng sáng lập Monad, thảo luận về các vấn đề thị trường gần đây liên quan đến tắc nghẽn thực thi Rollup và giới hạn gas.

Tác giả gốc: Keone Hon, Monad Lianchuang

Tác giả gốc: Azuma, Odaily Planet Daily

Ghi chú của biên tập viên: Giờ Bắc Kinh ngày 3 Sáng ngày 26/3, Keone Hon, người đồng sáng lập Monad đã đăng một bài viết chuyên sâu về tình trạng hoạt động của Rollup trên chứng chỉ X cá nhân của mình. 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 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. phác thảo Một số điểm nghẽn mà Rollup gặp phải và những cải tiến tiềm năng.

Sau đây là nội dung gốc của Keone, do Odaily Planet Daily biên soạn, để thuận tiện cho độc giả, người dịch có một số bổ sung nhất định so với nguyên văn.

Gần đây đã có một số cuộc thảo luận trên thị trường 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 khả dụng của dữ liệu (DA)

Với cấu trúc dữ liệu Blob (EIP-4844) được giới thiệu 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 giá thầu trong cùng thị trường phí như các giao dịch Lớp 1 thông thường.

Hiện tại, dung lượng của Blobs là khoảng ba Blobs 125kb trên mỗi khối (12 giây), tức là cứ mỗi giây 31,25 kb, với điều kiện là kích thước của một giao dịch là khoảng 100 byte, điều này có nghĩa là TPS dùng chung của tất cả các Bản tổng hợp 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ề 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 có Nâng cấp Cancun). Mặc dù làm như vậy sẽ gây ra sự phức tạp hơn.

Thứ ba, có sự khác biệt về cách thức phát hành ZK-rollup khác nhau (đặc biệt zkSync Era và Starknet), do đó, đối với Rollup , các phương pháp và kết quả tính toán này sẽ cũng khác nhau.

Giới hạn gas rollup

Gần đây, Base đã có sự gia tăng về số lượng giao dịch đã gây ra mối quan tâm lớn, với chi phí của một giao dịch thông thường trên mạng tăng lên vài đô la.

Tại sao mạng Base chỉ suy giảm một thời gian sau khi nâng cấp Cancun mà giờ đã 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ố khí hiện được Base sử dụng giống như Optimism , tức là có 5 triệu khí trong mỗi khối Lớp 2 (2 giây ) Tổng số lượng có hạn. 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 vọt.

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 khả dụng 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à sự phát triển của trạng thái. Ẩn nguy hiểm.

Vấn đề 1: Sự tắc nghẽn trong thông lượng thực thi

Nói chung, chạy EVM Rollup Cả hai đều là một EVM được phân nhánh từ Geth, có nghĩa là chúng có các đặc tính hiệu suất tương tự như ứng dụng khách Geth.

Ứng dụng 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), nó sử dụng mã hóa LevelDB/PebbleDB và được triển khai trong merkle patricia trie (MPT) lưu trữ trạng thái của nó trong đó. Đâ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ừ bộ ba merkle) và "cập nhật trạng thái" (cập nhật bộ ba merkle ở cuối mỗi khối ) là liên kết tốn kém nhất trong quá trình thực hiện. Đ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 được tiến hành song song và trạng thái của nó có thể đượ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. (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.

Vấn đề 2: Những nguy cơ tiềm ẩn đối với sự tăng trưởng của nhà nước

Giống như các blockchain khác, Rollup cũng là thông lượng của chúng bị hạn chế để ngăn chặn hoạt động của chúng phát triển quá nhanh.

Lý luận phổ biến trên thị trường là sở dĩ tốc độ tăng trưởng của bang đáng lo ngại là vì nếu dữ liệu của bang tăng trưởng đáng kể sẽ ảnh hưởng đến ổ đĩa thể rắn (SSD) Nhu cầu thiết bị cũng sẽ phải được điều chỉnh 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 2TB chất lượng cao có giá khoảng 200 USD) và trạng thái đầy đủ của Ethereum “chỉ” 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 đầy đủ, sẽ ngày càng có ít "phím tắt".

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 đó, việc 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 ở trạng thái 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 bộ sắp xếp không chạy 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ù xét theo tình hình hiện tại của Base, gas mạng đã tăng vọt. không phải do dữ liệu mạng chính không đủ sẵn có, nhưng về lâu dài, điều này cuối cùng sẽ trở thành nút thắt cổ chai lớn hạn chế Rollup.

Vấn đề thứ hai là sự 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ì cùng một trạng thái.

Dữ liệu giao dịch thô và 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ỳ tác nhân nào có nhu cầu 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) đều phải chạy nút Layer2 đầy đủ để xử lý các giao dịch và có bản sao cập nhật của trạng thái.

Rollups 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 Keone đăng bài viết này, nhiều người đứng đầu Nhân sự chủ chốt của Layer ;2 dự án đều được tương tác bên dưới bản cập nhật.

Người đồng sáng lập zkSync Alex Gluchowski đã chỉ ra trong bài viết rằng "sau mỗi khối "Cần tính toán lại gốc merkle" hỏi Monad khác nhau như thế nào về mặt này? ”

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 gố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 biết EIP -4844 đã giảm đáng kể chi phí DA ở cấp Lớp 1. Phí gas đáng lẽ phải giảm. Tuy nhiên, do nhu cầu giao dịch mạng tăng hơn 5 lần và khối trên Base mạng có giới hạn 250 gas/s, nhu cầu lớn hơn nguồn cung, điều này khiến chi phí gas tăng cao.