Tìm hiểu các nút thắt cổ chai và các phương pháp tối ưu hóa từ góc độ sự khác biệt về hiệu suất giữa opBNB và Ethereum Layer2

Trung cấp2/27/2024, 2:57:45 AM
Bài viết này nhằm mục đích cung cấp một bản tóm tắt ngắn gọn về các nguyên tắc hoạt động và ý nghĩa thương mại của opBNB, phác thảo một bước quan trọng được thực hiện bởi chuỗi công khai BSC trong kỷ nguyên chuỗi khối mô-đun.

Con đường đến với khối lớn của BNB Chain

Con đường của những khối lớn trên chuỗi BNB

Tương tự như Solana, Heco và các chuỗi công khai khác được các sàn giao dịch hỗ trợ, chuỗi công khai BNB Smart Chain (BSC) của BNB Chain từ lâu đã theo đuổi hiệu suất cao. Kể từ khi ra mắt vào năm 2020, BSC đã đặt giới hạn dung lượng gas cho mỗi khối là 30 triệu, với khoảng thời gian khối ổn định là 3 giây. Với thông số như vậy, BSC đạt TPS (TPS với nhiều giao dịch trộn lẫn với nhau) tối đa trên 100. Vào tháng 6 năm 2021, giới hạn block gas của BSC được tăng lên 60 triệu. Tuy nhiên, vào tháng 7 cùng năm, một chuỗi trò chơi mang tên CryptoBlades đã bùng nổ trên BSC, khiến khối lượng giao dịch hàng ngày vượt quá 8 triệu và dẫn đến phí tăng vọt. Hóa ra nút thắt về hiệu quả của BSC vẫn còn khá rõ ràng vào thời điểm đó.

(Nguồn: BscScan)

Để giải quyết các vấn đề về hiệu suất mạng, BSC một lần nữa nâng giới hạn gas cho mỗi khối, vốn vẫn ổn định ở mức khoảng 80-85 triệu trong một thời gian dài. Vào tháng 9 năm 2022, giới hạn gas trên mỗi khối của BSC Chain đã tăng lên 120 triệu và đến cuối năm, nó đã tăng lên 140 triệu, gần gấp 5 lần so với năm 2020. Trước đây, BSC đã lên kế hoạch tăng giới hạn công suất khối gas lên 300 triệu, nhưng có lẽ do cân nhắc gánh nặng lớn đối với các nút Validator nên đề xuất về các khối siêu lớn như vậy vẫn chưa được thực hiện.


nguồn: YCHARTS

Sau đó, Chuỗi BNB dường như tập trung nhiều hơn vào kênh mô-đun/Lớp 2 thay vì tiếp tục mở rộng Lớp 1. Ý định này ngày càng trở nên rõ ràng kể từ khi ra mắt zkBNB vào nửa cuối năm ngoái tại GreenField vào đầu năm nay. Vì mối quan tâm sâu sắc đến blockchain mô-đun/Layer2, tác giả của bài viết này sẽ sử dụng opBNB làm đối tượng nghiên cứu để phát hiện các điểm nghẽn về hiệu suất của Rollup bằng cách so sánh nó với Ethereum Layer2.

Tăng cường thông lượng cao của BSC lên lớp DA của opBNB

Như chúng ta đã biết, Celestia đã tóm tắt bốn thành phần chính theo quy trình làm việc của chuỗi khối mô-đun: Lớp thực thi: Thực thi mã hợp đồng và hoàn thành chuyển đổi trạng thái; Lớp giải quyết: Xử lý bằng chứng gian lận/bằng chứng hợp lệ và giải quyết các vấn đề bắc cầu giữa L2 và L1. Lớp đồng thuận: Đạt được sự đồng thuận về việc đặt hàng giao dịch. Lớp sẵn có dữ liệu (DA): Xuất bản dữ liệu liên quan đến sổ cái blockchain, cho phép người xác thực tải xuống dữ liệu này.


Trong số đó, lớp DA thường được kết hợp với lớp đồng thuận. Ví dụ: dữ liệu của DA của Optimistic Rollup chứa một loạt chuỗi giao dịch trong các khối L2. Khi các nút đầy đủ L2 có được dữ liệu DA, chúng biết thứ tự của từng giao dịch trong đợt này. (Vì lý do này, cộng đồng Ethereum tin rằng lớp DA và lớp đồng thuận có liên quan với nhau khi phân lớp Rollup.)

Tuy nhiên, đối với Ethereum Layer2, thông lượng dữ liệu của lớp DA (Ethereum) đã trở thành nút thắt cổ chai lớn nhất hạn chế hiệu suất Rollup. Điều này là do thông lượng dữ liệu hiện tại của Ethereum quá thấp, buộc Rollup phải ngăn chặn TPS của nó càng nhiều càng tốt để ngăn mạng chính Ethereum không thể chịu được dữ liệu do L2 tạo ra. Đồng thời, thông lượng dữ liệu thấp khiến một số lượng lớn hướng dẫn giao dịch trong mạng Ethereum ở trạng thái chờ xử lý, dẫn đến phí gas bị đẩy lên mức cực cao và làm tăng thêm chi phí xuất bản dữ liệu cho Layer2. Cuối cùng, nhiều mạng Layer2 phải áp dụng các lớp DA bên ngoài Ethereum, chẳng hạn như Celestia và opBNB, mạng gần mặt nước, đã chọn sử dụng trực tiếp thông lượng cao của BSC để triển khai DA nhằm giải quyết vấn đề tắc nghẽn trong xuất bản dữ liệu. Để dễ hiểu xin giới thiệu phương pháp xuất bản dữ liệu DA cho Rollup. Lấy Arbitrum làm ví dụ, chuỗi Ethereum được kiểm soát bởi địa chỉ EOA của trình sắp xếp thứ tự Lớp 2 sẽ định kỳ gửi Giao dịch đến hợp đồng được chỉ định. Trong tham số đầu vào calldata của lệnh này, dữ liệu giao dịch đóng gói được ghi và các sự kiện trên chuỗi tương ứng được kích hoạt, để lại một bản ghi vĩnh viễn trong nhật ký hợp đồng.


Bằng cách này, dữ liệu giao dịch của Layer2 được lưu trữ trong các khối Ethereum trong thời gian dài. Những người có khả năng chạy các nút L2 có thể tải xuống các bản ghi tương ứng và phân tích dữ liệu tương ứng, nhưng bản thân các nút Ethereum không thực hiện các giao dịch L2 này. Dễ dàng nhận thấy L2 chỉ lưu trữ dữ liệu giao dịch trong các khối Ethereum, phát sinh chi phí lưu trữ, trong khi chi phí tính toán để thực hiện giao dịch do chính các nút L2 chịu. Ở trên là phương pháp triển khai DA của Arbitrum, trong khi Optimism sử dụng địa chỉ EOA do trình sắp xếp chuỗi kiểm soát để chuyển sang một địa chỉ EOA được chỉ định khác, mang theo một loạt dữ liệu giao dịch Lớp 2 mới trong dữ liệu bổ sung. Đối với opBNB, sử dụng OP Stack, phương thức xuất bản dữ liệu DA của nó về cơ bản giống với phương thức của Optimism.


Rõ ràng thông lượng của lớp DA sẽ giới hạn kích thước dữ liệu mà Rollup có thể xuất bản trong một đơn vị thời gian, từ đó hạn chế TPS. Xét rằng sau EIP1559, công suất gas của mỗi khối ETH ổn định ở mức 30 triệu và thời gian tạo khối sau khi hợp nhất là khoảng 12 giây, Ethereum có thể xử lý tối đa chỉ 2,5 triệu gas mỗi giây. Trong hầu hết trường hợp, lượng gas tiêu thụ khi cung cấp dữ liệu giao dịch L2 trên mỗi byte trong calldata là 16, do đó Ethereum có thể xử lý kích thước dữ liệu cuộc gọi tối đa chỉ 150 KB mỗi giây. Ngược lại, kích thước dữ liệu cuộc gọi trung bình tối đa được xử lý mỗi giây của BSC là khoảng 2910 KB, gấp 18,6 lần so với Ethereum. Sự khác biệt giữa hai lớp DA là rõ ràng.

Tóm lại, Ethereum có thể mang khoảng 150 KB dữ liệu giao dịch L2 mỗi giây. Kể cả sau khi EIP 4844 ra mắt, con số này cũng không thay đổi nhiều mà chỉ giảm phí DA. Vậy có thể bao gồm bao nhiêu dữ liệu giao dịch trong khoảng 150KB mỗi giây? Ở đây chúng ta cần giải thích tốc độ nén dữ liệu của Rollup. Vitalik đã quá lạc quan vào năm 2021 khi ước tính rằng Optimistic Rollup có thể nén kích thước dữ liệu giao dịch xuống 11% so với kích thước ban đầu. Ví dụ: chuyển ETH cơ bản, ban đầu chiếm kích thước calldata là 112 byte, có thể được nén thành 12 byte bằng Optimistic Rollup, chuyển ERC-20 có thể được nén thành 16 byte và giao dịch Hoán đổi trên Uniswap có thể được nén thành 14 byte. Theo ước tính của ông, Ethereum có thể ghi lại khoảng 10.000 giao dịch L2 mỗi giây (với nhiều loại khác nhau được trộn lẫn với nhau). Tuy nhiên, theo dữ liệu được nhóm Optimism tiết lộ vào năm 2022, tốc độ nén dữ liệu thực tế có thể đạt tối đa chỉ khoảng 37%, thấp hơn 3,5 lần so với ước tính của Vitalik.


(Ước tính của Vitalik về hiệu ứng khả năng mở rộng Rollup sai lệch đáng kể so với điều kiện thực tế)

(Tốc độ nén thực tế đạt được bằng nhiều thuật toán nén khác nhau do Optimism tiết lộ)

Vì vậy, hãy đưa ra một con số hợp lý: ngay cả khi Ethereum đạt đến giới hạn thông lượng, TPS tối đa của tất cả các bản tổng hợp lạc quan cộng lại chỉ hơn 2000 một chút. Nói cách khác, nếu các khối Ethereum hoàn toàn được sử dụng để mang dữ liệu được xuất bản bởi Optimistic Rollups, chẳng hạn như các dữ liệu được phân phối giữa Arbitrum, Optimism, Base và Boba, thì TPS tổng hợp của các Optimistic Rollups này thậm chí sẽ không đạt tới 3000, ngay cả ở mức cao nhất. thuật toán nén hiệu quả. Ngoài ra, chúng ta phải xem xét rằng sau EIP1559, công suất gas trung bình của mỗi khối chỉ bằng 50% giá trị tối đa, do đó con số trên sẽ giảm đi một nửa. Sau khi ra mắt EIP4844, mặc dù phí giao dịch xuất bản dữ liệu sẽ giảm đáng kể nhưng kích thước khối tối đa của Ethereum sẽ không thay đổi nhiều (vì thay đổi quá nhiều sẽ ảnh hưởng đến tính bảo mật của chuỗi chính ETH), do đó giá trị ước tính ở trên sẽ không tiến triển nhiều.


Theo dữ liệu từ Arbiscan và Etherscan, một loạt giao dịch trên Arbitrum chứa 1115 giao dịch, tiêu thụ 1,81 triệu gas trên Ethereum. Bằng phép ngoại suy, nếu lớp DA được lấp đầy trong mọi khối, giới hạn TPS theo lý thuyết của Arbitrum là khoảng 1500. Tất nhiên, xét đến vấn đề tổ chức lại khối L1, Arbitrum không thể công bố các lô giao dịch trên mỗi khối Ethereum nên những con số trên hiện chỉ mang tính lý thuyết. Ngoài ra, với việc áp dụng rộng rãi ví thông minh liên quan đến EIP 4337, vấn đề DA sẽ càng trở nên nghiêm trọng hơn. Bởi vì với sự hỗ trợ cho EIP 4337, cách người dùng xác minh danh tính của họ có thể được tùy chỉnh, chẳng hạn như tải lên dữ liệu nhị phân của dấu vân tay hoặc mống mắt, điều này sẽ làm tăng thêm kích thước dữ liệu mà các giao dịch thông thường chiếm giữ. Do đó, thông lượng dữ liệu thấp của Ethereum là nút thắt cổ chai lớn nhất hạn chế hiệu quả của Rollup và vấn đề này có thể không được giải quyết thỏa đáng trong một thời gian dài. Mặt khác, trong Chuỗi BNB của chuỗi công khai BSC, kích thước dữ liệu cuộc gọi trung bình tối đa được xử lý mỗi giây là khoảng 2910 KB, gấp 18,6 lần so với Ethereum. Nói cách khác, miễn là lớp thực thi có thể theo kịp, giới hạn trên TPS theo lý thuyết của Lớp 2 trong hệ sinh thái Chuỗi BNB có thể đạt xấp xỉ 18 lần so với ARB hoặc OP. Con số này được tính toán dựa trên công suất block gas tối đa của BNB Chain hiện tại là 140 triệu, với thời gian tạo khối là 3 giây.

Nói cách khác, giới hạn TPS tổng hợp hiện tại của tất cả các Rollup trong hệ sinh thái Chuỗi BNB gấp 18,6 lần so với Ethereum (ngay cả khi xem xét ZKRollup). Từ góc độ này, thật dễ hiểu tại sao rất nhiều dự án Layer2 sử dụng lớp DA trong chuỗi Ethereum để xuất bản dữ liệu, vì sự khác biệt là khá rõ ràng. Tuy nhiên, vấn đề không đơn giản như vậy. Bên cạnh vấn đề về thông lượng dữ liệu, bản thân tính ổn định của Layer1 cũng có thể ảnh hưởng đến Layer2. Ví dụ: hầu hết các Rollups thường đợi vài phút trước khi xuất bản một loạt giao dịch lên Ethereum, xem xét khả năng tổ chức lại khối Layer1. Nếu khối Layer1 được tổ chức lại, nó sẽ ảnh hưởng đến sổ cái blockchain của Layer2. Do đó, trình sắp xếp chuỗi sẽ đợi một số khối Layer1 mới được xuất bản sau mỗi lần phát hành lô giao dịch L2, làm giảm đáng kể xác suất khôi phục khối trước khi xuất bản lô giao dịch L2 tiếp theo. Điều này thực sự làm trì hoãn thời gian cuối cùng các khối L2 được xác nhận, làm giảm tốc độ xác nhận của các giao dịch lớn (các giao dịch lớn yêu cầu kết quả không thể đảo ngược để đảm bảo an ninh). Tóm lại, các giao dịch xảy ra trong L2 chỉ trở nên không thể đảo ngược sau khi được xuất bản trong các khối lớp DA và sau khi lớp DA đã tạo ra một số khối mới nhất định. Đây là lý do quan trọng hạn chế hiệu suất tổng hợp. Tuy nhiên, Ethereum có tốc độ tạo khối chậm, mất 12 giây để tạo ra một khối. Giả sử Rollup xuất bản một lô giao dịch L2 cứ sau 15 khối thì sẽ có khoảng thời gian 3 phút giữa các lô khác nhau và sau khi mỗi lô được xuất bản, nó vẫn cần đợi nhiều khối Lớp 1 được tạo trước khi trở nên không thể đảo ngược (giả sử chúng là không bị thách thức). Rõ ràng, thời gian từ khi bắt đầu đến khi giao dịch không thể đảo ngược trên Layer2 của Ethereum là khá dài, dẫn đến tốc độ giải quyết chậm; trong khi đó, Chuỗi BNB chỉ mất 3 giây để tạo ra một khối và các khối này không thể đảo ngược chỉ sau 45 giây (thời gian cần thiết để tạo ra 15 khối mới). Dựa trên các tham số hiện tại, giả sử cùng số lượng giao dịch L2 và xem xét tính không thể đảo ngược của các khối L1, số lần opBNB có thể công bố dữ liệu giao dịch trong một đơn vị thời gian có thể lên tới 8,53 lần so với Arbitrum (cứ sau 45 giây một lần đối với cái trước và cứ sau 6,4 phút một lần cho cái sau). Rõ ràng, tốc độ giải quyết các giao dịch lớn trên opBNB nhanh hơn nhiều so với Layer2 của Ethereum. Ngoài ra, kích thước dữ liệu tối đa được opBNB công bố mỗi lần có thể đạt tới 4,66 lần so với Layer2 của Ethereum (giới hạn gas khối L1 của lớp trước là 140 triệu, trong khi của lớp sau là 30 triệu). 8,53 * 4,66 = 39,74. Điều này thể hiện sự khác biệt giữa opBNB và Arbitrum về giới hạn TPS trong triển khai thực tế (hiện tại, vì lý do bảo mật, ARB dường như chủ động giảm TPS, nhưng về mặt lý thuyết, nếu tăng TPS thì vẫn thấp hơn rất nhiều lần so với opBNB. ).


(Trình sắp xếp thứ tự của Arbitrum xuất bản một lô giao dịch cứ sau 6-7 phút)


(Trình sắp xếp thứ tự của opBNB xuất bản một lô giao dịch cứ sau 1-2 phút, nhanh nhất chỉ mất 45 giây). Tất nhiên, có một vấn đề quan trọng khác cần xem xét, đó là phí gas trong lớp DA. Mỗi lần L2 xuất bản một lô giao dịch, sẽ có một khoản chi phí cố định là 21.000 gas không liên quan đến kích thước dữ liệu cuộc gọi, đây là một khoản chi phí. Nếu phí gas cho lớp DA/L1 cao, khiến chi phí cố định của việc xuất bản một lô giao dịch trên L2 vẫn ở mức cao, thì trình sắp xếp chuỗi sẽ giảm tần suất xuất bản các lô giao dịch. Ngoài ra, khi xem xét các thành phần của phí L2, chi phí của lớp thực thi rất thấp và thường có thể bị bỏ qua, chỉ tập trung vào tác động của chi phí DA lên phí giao dịch. Tóm lại, trong khi xuất bản dữ liệu cuộc gọi có cùng kích thước sẽ tiêu thụ cùng một lượng gas trên Ethereum và Chuỗi BNB, giá gas do Ethereum tính cao hơn khoảng 10 đến hàng chục lần so với Chuỗi BNB. Được dịch sang phí giao dịch L2, phí giao dịch người dùng hiện tại trên Ethereum Layer2 cũng cao hơn khoảng 10 đến hàng chục lần so với opBNB. Nhìn chung, sự khác biệt giữa opBNB và Optimistic Rollup trên Ethereum là khá rõ ràng.

(Một giao dịch tiêu thụ 150.000 gas trên Optimism có giá 0,21 USD)


(Một giao dịch tiêu thụ 130.000 gas trên opBNB có giá 0,004 USD) Tuy nhiên, việc tăng thông lượng dữ liệu của lớp DA, mặc dù có thể nâng cao thông lượng tổng thể của hệ thống Lớp 2, nhưng vẫn có tác động hạn chế đến việc cải thiện hiệu suất của các Bản tổng hợp riêng lẻ. Điều này là do lớp thực thi thường không xử lý các giao dịch đủ nhanh. Ngay cả khi có thể bỏ qua các giới hạn của lớp DA thì lớp thực thi sẽ trở thành nút thắt cổ chai tiếp theo ảnh hưởng đến hiệu suất Tổng hợp. Nếu tốc độ thực thi của lớp thực thi Layer2 chậm, nhu cầu giao dịch tràn sẽ lan sang các Layer2 khác, cuối cùng gây ra sự phân mảnh thanh khoản. Do đó, việc cải thiện hiệu suất của lớp thực thi cũng rất quan trọng, đóng vai trò là một ngưỡng khác phía trên lớp DA.

Tăng cường của opBNB trong lớp thực thi: Tối ưu hóa bộ đệm

Khi hầu hết mọi người thảo luận về các nút thắt cổ chai về hiệu suất của các lớp thực thi blockchain, chắc chắn họ sẽ đề cập đến hai nút thắt cổ chai quan trọng: việc thực thi nối tiếp một luồng của EVM không sử dụng hết CPU và việc tra cứu dữ liệu không hiệu quả của Merkle Patricia Trie được Ethereum áp dụng. Về bản chất, các chiến lược mở rộng quy mô cho lớp thực thi xoay quanh việc sử dụng tài nguyên CPU hiệu quả hơn và đảm bảo rằng CPU có thể truy cập dữ liệu nhanh nhất có thể.

Các giải pháp tối ưu hóa để thực thi EVM nối tiếp và Merkle Patricia Trie thường phức tạp và khó triển khai, trong khi những nỗ lực tiết kiệm chi phí hơn có xu hướng tập trung vào tối ưu hóa bộ đệm. Trên thực tế, việc tối ưu hóa bộ đệm đưa chúng ta trở lại các điểm thường được thảo luận trong bối cảnh Web2 truyền thống và thậm chí cả sách giáo khoa.

Thông thường, tốc độ lấy dữ liệu từ bộ nhớ của CPU nhanh hơn hàng trăm lần so với lấy dữ liệu từ đĩa. Ví dụ: tìm nạp dữ liệu từ bộ nhớ có thể chỉ mất 0,1 giây, trong khi tìm nạp từ đĩa có thể mất 10 giây. Do đó, việc giảm chi phí phát sinh do đọc và ghi đĩa, tức là tối ưu hóa bộ đệm, trở thành một khía cạnh thiết yếu của việc tối ưu hóa lớp thực thi blockchain.

Trong Ethereum và hầu hết các chuỗi công khai khác, cơ sở dữ liệu ghi lại trạng thái địa chỉ trên chuỗi được lưu trữ hoàn toàn trên đĩa, trong khi cái gọi là trie Trạng thái Thế giới chỉ đơn thuần là một chỉ mục của cơ sở dữ liệu này hoặc một thư mục được sử dụng để tra cứu dữ liệu. Mỗi khi EVM thực hiện một hợp đồng, nó cần truy cập vào các trạng thái địa chỉ liên quan. Việc tìm nạp từng dữ liệu từ cơ sở dữ liệu trên đĩa sẽ làm chậm đáng kể việc thực hiện giao dịch. Vì vậy, thiết lập bộ đệm bên ngoài cơ sở dữ liệu/đĩa là một phương tiện cần thiết để tăng tốc.

opBNB trực tiếp áp dụng giải pháp tối ưu hóa bộ đệm được BNB Chain sử dụng. Theo thông tin được tiết lộ bởi đối tác của opBNB, NodeReal, chuỗi BSC sớm nhất đã thiết lập ba lớp bộ đệm giữa EVM và cơ sở dữ liệu LevelDB lưu trữ trạng thái. Ý tưởng thiết kế tương tự như ý tưởng của bộ nhớ đệm ba cấp truyền thống, trong đó dữ liệu có tần suất truy cập cao hơn được lưu trữ trong bộ nhớ đệm. Điều này cho phép CPU trước tiên tìm kiếm dữ liệu cần thiết trong bộ đệm. Nếu tốc độ truy cập bộ đệm đủ cao, CPU không cần phải phụ thuộc quá nhiều vào đĩa để tìm nạp dữ liệu, dẫn đến tốc độ thực thi tổng thể được cải thiện đáng kể.

Sau đó, NodeReal đã bổ sung thêm một tính năng, giúp tận dụng các lõi CPU không được sử dụng để đọc trước dữ liệu mà EVM sẽ cần xử lý trong tương lai từ cơ sở dữ liệu và lưu trữ vào bộ nhớ đệm. Tính năng này được gọi là “tải trước trạng thái”.

Nguyên tắc tải trước trạng thái rất đơn giản: CPU của các nút blockchain là đa lõi, trong khi EVM hoạt động ở chế độ thực thi nối tiếp một luồng, chỉ sử dụng một lõi CPU, khiến các lõi CPU khác không được sử dụng đúng mức. Để giải quyết vấn đề này, các lõi CPU không được EVM sử dụng có thể hỗ trợ thực hiện các tác vụ bằng cách dự đoán dữ liệu mà EVM sẽ cần từ chuỗi giao dịch chưa được xử lý. Sau đó, các lõi CPU bên ngoài EVM này sẽ truy xuất dữ liệu mà EVM cần từ cơ sở dữ liệu, giúp EVM giảm chi phí truy xuất dữ liệu và do đó tăng tốc độ thực thi.

Với việc tối ưu hóa bộ đệm và cấu hình phần cứng đầy đủ, opBNB đã đẩy hiệu suất của lớp thực thi nút của nó đến gần giới hạn của EVM một cách hiệu quả, xử lý lên tới 100 triệu khí mỗi giây. 100 triệu lượng khí đốt này về cơ bản là mức trần hiệu suất của EVM chưa sửa đổi, được chứng minh bằng dữ liệu thử nghiệm thử nghiệm từ một chuỗi công khai nổi bật.

Nói một cách ngắn gọn, opBNB có thể xử lý tới 4761 lần chuyển đơn giản mỗi giây, 15003000 lần chuyển mã thông báo ERC20 mỗi giây và khoảng 5001000 hoạt động SWAP mỗi giây dựa trên dữ liệu giao dịch được quan sát trên các trình khám phá blockchain. So sánh các thông số hiện tại, giới hạn TPS của opBNB gấp 40 lần so với Ethereum, gấp hơn 2 lần so với Chuỗi BNB và hơn 6 lần so với Optimism.

Tất nhiên, đối với các giải pháp Ethereum Layer2, do những hạn chế nghiêm trọng của chính lớp DA, hiệu suất bị giảm đáng kể dựa trên hiệu suất của lớp thực thi, khi xem xét các yếu tố như thời gian tạo khối lớp DA và độ ổn định.

Đối với Chuỗi BNB có lớp DA thông lượng cao như opBNB, hiệu ứng nhân đôi của việc mở rộng quy mô là rất có giá trị, đặc biệt khi xem xét rằng Chuỗi BNB có thể lưu trữ nhiều dự án mở rộng quy mô như vậy. Có thể thấy trước rằng BNB Chain đã kết hợp các giải pháp Layer2 do opBNB dẫn đầu vào các kế hoạch chiến lược của mình và sẽ tiếp tục triển khai nhiều dự án blockchain mô-đun hơn, bao gồm giới thiệu bằng chứng ZK vào opBNB và cung cấp các lớp DA có tính sẵn sàng cao với cơ sở hạ tầng bổ sung như GreenField, trong nỗ lực cạnh tranh hoặc hợp tác với hệ sinh thái Ethereum Layer2.

Trong thời đại mà việc mở rộng quy mô theo lớp đã trở thành xu hướng, liệu các chuỗi công khai khác cũng sẽ gấp rút hỗ trợ các dự án Layer2 của riêng họ hay không, nhưng chắc chắn rằng sự thay đổi mô hình sang cơ sở hạ tầng blockchain mô-đun đã xảy ra.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [极客 Web3], Mọi bản quyền thuộc về tác giả gốc [Faust, 极客web3]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.

Tìm hiểu các nút thắt cổ chai và các phương pháp tối ưu hóa từ góc độ sự khác biệt về hiệu suất giữa opBNB và Ethereum Layer2

Trung cấp2/27/2024, 2:57:45 AM
Bài viết này nhằm mục đích cung cấp một bản tóm tắt ngắn gọn về các nguyên tắc hoạt động và ý nghĩa thương mại của opBNB, phác thảo một bước quan trọng được thực hiện bởi chuỗi công khai BSC trong kỷ nguyên chuỗi khối mô-đun.

Con đường đến với khối lớn của BNB Chain

Con đường của những khối lớn trên chuỗi BNB

Tương tự như Solana, Heco và các chuỗi công khai khác được các sàn giao dịch hỗ trợ, chuỗi công khai BNB Smart Chain (BSC) của BNB Chain từ lâu đã theo đuổi hiệu suất cao. Kể từ khi ra mắt vào năm 2020, BSC đã đặt giới hạn dung lượng gas cho mỗi khối là 30 triệu, với khoảng thời gian khối ổn định là 3 giây. Với thông số như vậy, BSC đạt TPS (TPS với nhiều giao dịch trộn lẫn với nhau) tối đa trên 100. Vào tháng 6 năm 2021, giới hạn block gas của BSC được tăng lên 60 triệu. Tuy nhiên, vào tháng 7 cùng năm, một chuỗi trò chơi mang tên CryptoBlades đã bùng nổ trên BSC, khiến khối lượng giao dịch hàng ngày vượt quá 8 triệu và dẫn đến phí tăng vọt. Hóa ra nút thắt về hiệu quả của BSC vẫn còn khá rõ ràng vào thời điểm đó.

(Nguồn: BscScan)

Để giải quyết các vấn đề về hiệu suất mạng, BSC một lần nữa nâng giới hạn gas cho mỗi khối, vốn vẫn ổn định ở mức khoảng 80-85 triệu trong một thời gian dài. Vào tháng 9 năm 2022, giới hạn gas trên mỗi khối của BSC Chain đã tăng lên 120 triệu và đến cuối năm, nó đã tăng lên 140 triệu, gần gấp 5 lần so với năm 2020. Trước đây, BSC đã lên kế hoạch tăng giới hạn công suất khối gas lên 300 triệu, nhưng có lẽ do cân nhắc gánh nặng lớn đối với các nút Validator nên đề xuất về các khối siêu lớn như vậy vẫn chưa được thực hiện.


nguồn: YCHARTS

Sau đó, Chuỗi BNB dường như tập trung nhiều hơn vào kênh mô-đun/Lớp 2 thay vì tiếp tục mở rộng Lớp 1. Ý định này ngày càng trở nên rõ ràng kể từ khi ra mắt zkBNB vào nửa cuối năm ngoái tại GreenField vào đầu năm nay. Vì mối quan tâm sâu sắc đến blockchain mô-đun/Layer2, tác giả của bài viết này sẽ sử dụng opBNB làm đối tượng nghiên cứu để phát hiện các điểm nghẽn về hiệu suất của Rollup bằng cách so sánh nó với Ethereum Layer2.

Tăng cường thông lượng cao của BSC lên lớp DA của opBNB

Như chúng ta đã biết, Celestia đã tóm tắt bốn thành phần chính theo quy trình làm việc của chuỗi khối mô-đun: Lớp thực thi: Thực thi mã hợp đồng và hoàn thành chuyển đổi trạng thái; Lớp giải quyết: Xử lý bằng chứng gian lận/bằng chứng hợp lệ và giải quyết các vấn đề bắc cầu giữa L2 và L1. Lớp đồng thuận: Đạt được sự đồng thuận về việc đặt hàng giao dịch. Lớp sẵn có dữ liệu (DA): Xuất bản dữ liệu liên quan đến sổ cái blockchain, cho phép người xác thực tải xuống dữ liệu này.


Trong số đó, lớp DA thường được kết hợp với lớp đồng thuận. Ví dụ: dữ liệu của DA của Optimistic Rollup chứa một loạt chuỗi giao dịch trong các khối L2. Khi các nút đầy đủ L2 có được dữ liệu DA, chúng biết thứ tự của từng giao dịch trong đợt này. (Vì lý do này, cộng đồng Ethereum tin rằng lớp DA và lớp đồng thuận có liên quan với nhau khi phân lớp Rollup.)

Tuy nhiên, đối với Ethereum Layer2, thông lượng dữ liệu của lớp DA (Ethereum) đã trở thành nút thắt cổ chai lớn nhất hạn chế hiệu suất Rollup. Điều này là do thông lượng dữ liệu hiện tại của Ethereum quá thấp, buộc Rollup phải ngăn chặn TPS của nó càng nhiều càng tốt để ngăn mạng chính Ethereum không thể chịu được dữ liệu do L2 tạo ra. Đồng thời, thông lượng dữ liệu thấp khiến một số lượng lớn hướng dẫn giao dịch trong mạng Ethereum ở trạng thái chờ xử lý, dẫn đến phí gas bị đẩy lên mức cực cao và làm tăng thêm chi phí xuất bản dữ liệu cho Layer2. Cuối cùng, nhiều mạng Layer2 phải áp dụng các lớp DA bên ngoài Ethereum, chẳng hạn như Celestia và opBNB, mạng gần mặt nước, đã chọn sử dụng trực tiếp thông lượng cao của BSC để triển khai DA nhằm giải quyết vấn đề tắc nghẽn trong xuất bản dữ liệu. Để dễ hiểu xin giới thiệu phương pháp xuất bản dữ liệu DA cho Rollup. Lấy Arbitrum làm ví dụ, chuỗi Ethereum được kiểm soát bởi địa chỉ EOA của trình sắp xếp thứ tự Lớp 2 sẽ định kỳ gửi Giao dịch đến hợp đồng được chỉ định. Trong tham số đầu vào calldata của lệnh này, dữ liệu giao dịch đóng gói được ghi và các sự kiện trên chuỗi tương ứng được kích hoạt, để lại một bản ghi vĩnh viễn trong nhật ký hợp đồng.


Bằng cách này, dữ liệu giao dịch của Layer2 được lưu trữ trong các khối Ethereum trong thời gian dài. Những người có khả năng chạy các nút L2 có thể tải xuống các bản ghi tương ứng và phân tích dữ liệu tương ứng, nhưng bản thân các nút Ethereum không thực hiện các giao dịch L2 này. Dễ dàng nhận thấy L2 chỉ lưu trữ dữ liệu giao dịch trong các khối Ethereum, phát sinh chi phí lưu trữ, trong khi chi phí tính toán để thực hiện giao dịch do chính các nút L2 chịu. Ở trên là phương pháp triển khai DA của Arbitrum, trong khi Optimism sử dụng địa chỉ EOA do trình sắp xếp chuỗi kiểm soát để chuyển sang một địa chỉ EOA được chỉ định khác, mang theo một loạt dữ liệu giao dịch Lớp 2 mới trong dữ liệu bổ sung. Đối với opBNB, sử dụng OP Stack, phương thức xuất bản dữ liệu DA của nó về cơ bản giống với phương thức của Optimism.


Rõ ràng thông lượng của lớp DA sẽ giới hạn kích thước dữ liệu mà Rollup có thể xuất bản trong một đơn vị thời gian, từ đó hạn chế TPS. Xét rằng sau EIP1559, công suất gas của mỗi khối ETH ổn định ở mức 30 triệu và thời gian tạo khối sau khi hợp nhất là khoảng 12 giây, Ethereum có thể xử lý tối đa chỉ 2,5 triệu gas mỗi giây. Trong hầu hết trường hợp, lượng gas tiêu thụ khi cung cấp dữ liệu giao dịch L2 trên mỗi byte trong calldata là 16, do đó Ethereum có thể xử lý kích thước dữ liệu cuộc gọi tối đa chỉ 150 KB mỗi giây. Ngược lại, kích thước dữ liệu cuộc gọi trung bình tối đa được xử lý mỗi giây của BSC là khoảng 2910 KB, gấp 18,6 lần so với Ethereum. Sự khác biệt giữa hai lớp DA là rõ ràng.

Tóm lại, Ethereum có thể mang khoảng 150 KB dữ liệu giao dịch L2 mỗi giây. Kể cả sau khi EIP 4844 ra mắt, con số này cũng không thay đổi nhiều mà chỉ giảm phí DA. Vậy có thể bao gồm bao nhiêu dữ liệu giao dịch trong khoảng 150KB mỗi giây? Ở đây chúng ta cần giải thích tốc độ nén dữ liệu của Rollup. Vitalik đã quá lạc quan vào năm 2021 khi ước tính rằng Optimistic Rollup có thể nén kích thước dữ liệu giao dịch xuống 11% so với kích thước ban đầu. Ví dụ: chuyển ETH cơ bản, ban đầu chiếm kích thước calldata là 112 byte, có thể được nén thành 12 byte bằng Optimistic Rollup, chuyển ERC-20 có thể được nén thành 16 byte và giao dịch Hoán đổi trên Uniswap có thể được nén thành 14 byte. Theo ước tính của ông, Ethereum có thể ghi lại khoảng 10.000 giao dịch L2 mỗi giây (với nhiều loại khác nhau được trộn lẫn với nhau). Tuy nhiên, theo dữ liệu được nhóm Optimism tiết lộ vào năm 2022, tốc độ nén dữ liệu thực tế có thể đạt tối đa chỉ khoảng 37%, thấp hơn 3,5 lần so với ước tính của Vitalik.


(Ước tính của Vitalik về hiệu ứng khả năng mở rộng Rollup sai lệch đáng kể so với điều kiện thực tế)

(Tốc độ nén thực tế đạt được bằng nhiều thuật toán nén khác nhau do Optimism tiết lộ)

Vì vậy, hãy đưa ra một con số hợp lý: ngay cả khi Ethereum đạt đến giới hạn thông lượng, TPS tối đa của tất cả các bản tổng hợp lạc quan cộng lại chỉ hơn 2000 một chút. Nói cách khác, nếu các khối Ethereum hoàn toàn được sử dụng để mang dữ liệu được xuất bản bởi Optimistic Rollups, chẳng hạn như các dữ liệu được phân phối giữa Arbitrum, Optimism, Base và Boba, thì TPS tổng hợp của các Optimistic Rollups này thậm chí sẽ không đạt tới 3000, ngay cả ở mức cao nhất. thuật toán nén hiệu quả. Ngoài ra, chúng ta phải xem xét rằng sau EIP1559, công suất gas trung bình của mỗi khối chỉ bằng 50% giá trị tối đa, do đó con số trên sẽ giảm đi một nửa. Sau khi ra mắt EIP4844, mặc dù phí giao dịch xuất bản dữ liệu sẽ giảm đáng kể nhưng kích thước khối tối đa của Ethereum sẽ không thay đổi nhiều (vì thay đổi quá nhiều sẽ ảnh hưởng đến tính bảo mật của chuỗi chính ETH), do đó giá trị ước tính ở trên sẽ không tiến triển nhiều.


Theo dữ liệu từ Arbiscan và Etherscan, một loạt giao dịch trên Arbitrum chứa 1115 giao dịch, tiêu thụ 1,81 triệu gas trên Ethereum. Bằng phép ngoại suy, nếu lớp DA được lấp đầy trong mọi khối, giới hạn TPS theo lý thuyết của Arbitrum là khoảng 1500. Tất nhiên, xét đến vấn đề tổ chức lại khối L1, Arbitrum không thể công bố các lô giao dịch trên mỗi khối Ethereum nên những con số trên hiện chỉ mang tính lý thuyết. Ngoài ra, với việc áp dụng rộng rãi ví thông minh liên quan đến EIP 4337, vấn đề DA sẽ càng trở nên nghiêm trọng hơn. Bởi vì với sự hỗ trợ cho EIP 4337, cách người dùng xác minh danh tính của họ có thể được tùy chỉnh, chẳng hạn như tải lên dữ liệu nhị phân của dấu vân tay hoặc mống mắt, điều này sẽ làm tăng thêm kích thước dữ liệu mà các giao dịch thông thường chiếm giữ. Do đó, thông lượng dữ liệu thấp của Ethereum là nút thắt cổ chai lớn nhất hạn chế hiệu quả của Rollup và vấn đề này có thể không được giải quyết thỏa đáng trong một thời gian dài. Mặt khác, trong Chuỗi BNB của chuỗi công khai BSC, kích thước dữ liệu cuộc gọi trung bình tối đa được xử lý mỗi giây là khoảng 2910 KB, gấp 18,6 lần so với Ethereum. Nói cách khác, miễn là lớp thực thi có thể theo kịp, giới hạn trên TPS theo lý thuyết của Lớp 2 trong hệ sinh thái Chuỗi BNB có thể đạt xấp xỉ 18 lần so với ARB hoặc OP. Con số này được tính toán dựa trên công suất block gas tối đa của BNB Chain hiện tại là 140 triệu, với thời gian tạo khối là 3 giây.

Nói cách khác, giới hạn TPS tổng hợp hiện tại của tất cả các Rollup trong hệ sinh thái Chuỗi BNB gấp 18,6 lần so với Ethereum (ngay cả khi xem xét ZKRollup). Từ góc độ này, thật dễ hiểu tại sao rất nhiều dự án Layer2 sử dụng lớp DA trong chuỗi Ethereum để xuất bản dữ liệu, vì sự khác biệt là khá rõ ràng. Tuy nhiên, vấn đề không đơn giản như vậy. Bên cạnh vấn đề về thông lượng dữ liệu, bản thân tính ổn định của Layer1 cũng có thể ảnh hưởng đến Layer2. Ví dụ: hầu hết các Rollups thường đợi vài phút trước khi xuất bản một loạt giao dịch lên Ethereum, xem xét khả năng tổ chức lại khối Layer1. Nếu khối Layer1 được tổ chức lại, nó sẽ ảnh hưởng đến sổ cái blockchain của Layer2. Do đó, trình sắp xếp chuỗi sẽ đợi một số khối Layer1 mới được xuất bản sau mỗi lần phát hành lô giao dịch L2, làm giảm đáng kể xác suất khôi phục khối trước khi xuất bản lô giao dịch L2 tiếp theo. Điều này thực sự làm trì hoãn thời gian cuối cùng các khối L2 được xác nhận, làm giảm tốc độ xác nhận của các giao dịch lớn (các giao dịch lớn yêu cầu kết quả không thể đảo ngược để đảm bảo an ninh). Tóm lại, các giao dịch xảy ra trong L2 chỉ trở nên không thể đảo ngược sau khi được xuất bản trong các khối lớp DA và sau khi lớp DA đã tạo ra một số khối mới nhất định. Đây là lý do quan trọng hạn chế hiệu suất tổng hợp. Tuy nhiên, Ethereum có tốc độ tạo khối chậm, mất 12 giây để tạo ra một khối. Giả sử Rollup xuất bản một lô giao dịch L2 cứ sau 15 khối thì sẽ có khoảng thời gian 3 phút giữa các lô khác nhau và sau khi mỗi lô được xuất bản, nó vẫn cần đợi nhiều khối Lớp 1 được tạo trước khi trở nên không thể đảo ngược (giả sử chúng là không bị thách thức). Rõ ràng, thời gian từ khi bắt đầu đến khi giao dịch không thể đảo ngược trên Layer2 của Ethereum là khá dài, dẫn đến tốc độ giải quyết chậm; trong khi đó, Chuỗi BNB chỉ mất 3 giây để tạo ra một khối và các khối này không thể đảo ngược chỉ sau 45 giây (thời gian cần thiết để tạo ra 15 khối mới). Dựa trên các tham số hiện tại, giả sử cùng số lượng giao dịch L2 và xem xét tính không thể đảo ngược của các khối L1, số lần opBNB có thể công bố dữ liệu giao dịch trong một đơn vị thời gian có thể lên tới 8,53 lần so với Arbitrum (cứ sau 45 giây một lần đối với cái trước và cứ sau 6,4 phút một lần cho cái sau). Rõ ràng, tốc độ giải quyết các giao dịch lớn trên opBNB nhanh hơn nhiều so với Layer2 của Ethereum. Ngoài ra, kích thước dữ liệu tối đa được opBNB công bố mỗi lần có thể đạt tới 4,66 lần so với Layer2 của Ethereum (giới hạn gas khối L1 của lớp trước là 140 triệu, trong khi của lớp sau là 30 triệu). 8,53 * 4,66 = 39,74. Điều này thể hiện sự khác biệt giữa opBNB và Arbitrum về giới hạn TPS trong triển khai thực tế (hiện tại, vì lý do bảo mật, ARB dường như chủ động giảm TPS, nhưng về mặt lý thuyết, nếu tăng TPS thì vẫn thấp hơn rất nhiều lần so với opBNB. ).


(Trình sắp xếp thứ tự của Arbitrum xuất bản một lô giao dịch cứ sau 6-7 phút)


(Trình sắp xếp thứ tự của opBNB xuất bản một lô giao dịch cứ sau 1-2 phút, nhanh nhất chỉ mất 45 giây). Tất nhiên, có một vấn đề quan trọng khác cần xem xét, đó là phí gas trong lớp DA. Mỗi lần L2 xuất bản một lô giao dịch, sẽ có một khoản chi phí cố định là 21.000 gas không liên quan đến kích thước dữ liệu cuộc gọi, đây là một khoản chi phí. Nếu phí gas cho lớp DA/L1 cao, khiến chi phí cố định của việc xuất bản một lô giao dịch trên L2 vẫn ở mức cao, thì trình sắp xếp chuỗi sẽ giảm tần suất xuất bản các lô giao dịch. Ngoài ra, khi xem xét các thành phần của phí L2, chi phí của lớp thực thi rất thấp và thường có thể bị bỏ qua, chỉ tập trung vào tác động của chi phí DA lên phí giao dịch. Tóm lại, trong khi xuất bản dữ liệu cuộc gọi có cùng kích thước sẽ tiêu thụ cùng một lượng gas trên Ethereum và Chuỗi BNB, giá gas do Ethereum tính cao hơn khoảng 10 đến hàng chục lần so với Chuỗi BNB. Được dịch sang phí giao dịch L2, phí giao dịch người dùng hiện tại trên Ethereum Layer2 cũng cao hơn khoảng 10 đến hàng chục lần so với opBNB. Nhìn chung, sự khác biệt giữa opBNB và Optimistic Rollup trên Ethereum là khá rõ ràng.

(Một giao dịch tiêu thụ 150.000 gas trên Optimism có giá 0,21 USD)


(Một giao dịch tiêu thụ 130.000 gas trên opBNB có giá 0,004 USD) Tuy nhiên, việc tăng thông lượng dữ liệu của lớp DA, mặc dù có thể nâng cao thông lượng tổng thể của hệ thống Lớp 2, nhưng vẫn có tác động hạn chế đến việc cải thiện hiệu suất của các Bản tổng hợp riêng lẻ. Điều này là do lớp thực thi thường không xử lý các giao dịch đủ nhanh. Ngay cả khi có thể bỏ qua các giới hạn của lớp DA thì lớp thực thi sẽ trở thành nút thắt cổ chai tiếp theo ảnh hưởng đến hiệu suất Tổng hợp. Nếu tốc độ thực thi của lớp thực thi Layer2 chậm, nhu cầu giao dịch tràn sẽ lan sang các Layer2 khác, cuối cùng gây ra sự phân mảnh thanh khoản. Do đó, việc cải thiện hiệu suất của lớp thực thi cũng rất quan trọng, đóng vai trò là một ngưỡng khác phía trên lớp DA.

Tăng cường của opBNB trong lớp thực thi: Tối ưu hóa bộ đệm

Khi hầu hết mọi người thảo luận về các nút thắt cổ chai về hiệu suất của các lớp thực thi blockchain, chắc chắn họ sẽ đề cập đến hai nút thắt cổ chai quan trọng: việc thực thi nối tiếp một luồng của EVM không sử dụng hết CPU và việc tra cứu dữ liệu không hiệu quả của Merkle Patricia Trie được Ethereum áp dụng. Về bản chất, các chiến lược mở rộng quy mô cho lớp thực thi xoay quanh việc sử dụng tài nguyên CPU hiệu quả hơn và đảm bảo rằng CPU có thể truy cập dữ liệu nhanh nhất có thể.

Các giải pháp tối ưu hóa để thực thi EVM nối tiếp và Merkle Patricia Trie thường phức tạp và khó triển khai, trong khi những nỗ lực tiết kiệm chi phí hơn có xu hướng tập trung vào tối ưu hóa bộ đệm. Trên thực tế, việc tối ưu hóa bộ đệm đưa chúng ta trở lại các điểm thường được thảo luận trong bối cảnh Web2 truyền thống và thậm chí cả sách giáo khoa.

Thông thường, tốc độ lấy dữ liệu từ bộ nhớ của CPU nhanh hơn hàng trăm lần so với lấy dữ liệu từ đĩa. Ví dụ: tìm nạp dữ liệu từ bộ nhớ có thể chỉ mất 0,1 giây, trong khi tìm nạp từ đĩa có thể mất 10 giây. Do đó, việc giảm chi phí phát sinh do đọc và ghi đĩa, tức là tối ưu hóa bộ đệm, trở thành một khía cạnh thiết yếu của việc tối ưu hóa lớp thực thi blockchain.

Trong Ethereum và hầu hết các chuỗi công khai khác, cơ sở dữ liệu ghi lại trạng thái địa chỉ trên chuỗi được lưu trữ hoàn toàn trên đĩa, trong khi cái gọi là trie Trạng thái Thế giới chỉ đơn thuần là một chỉ mục của cơ sở dữ liệu này hoặc một thư mục được sử dụng để tra cứu dữ liệu. Mỗi khi EVM thực hiện một hợp đồng, nó cần truy cập vào các trạng thái địa chỉ liên quan. Việc tìm nạp từng dữ liệu từ cơ sở dữ liệu trên đĩa sẽ làm chậm đáng kể việc thực hiện giao dịch. Vì vậy, thiết lập bộ đệm bên ngoài cơ sở dữ liệu/đĩa là một phương tiện cần thiết để tăng tốc.

opBNB trực tiếp áp dụng giải pháp tối ưu hóa bộ đệm được BNB Chain sử dụng. Theo thông tin được tiết lộ bởi đối tác của opBNB, NodeReal, chuỗi BSC sớm nhất đã thiết lập ba lớp bộ đệm giữa EVM và cơ sở dữ liệu LevelDB lưu trữ trạng thái. Ý tưởng thiết kế tương tự như ý tưởng của bộ nhớ đệm ba cấp truyền thống, trong đó dữ liệu có tần suất truy cập cao hơn được lưu trữ trong bộ nhớ đệm. Điều này cho phép CPU trước tiên tìm kiếm dữ liệu cần thiết trong bộ đệm. Nếu tốc độ truy cập bộ đệm đủ cao, CPU không cần phải phụ thuộc quá nhiều vào đĩa để tìm nạp dữ liệu, dẫn đến tốc độ thực thi tổng thể được cải thiện đáng kể.

Sau đó, NodeReal đã bổ sung thêm một tính năng, giúp tận dụng các lõi CPU không được sử dụng để đọc trước dữ liệu mà EVM sẽ cần xử lý trong tương lai từ cơ sở dữ liệu và lưu trữ vào bộ nhớ đệm. Tính năng này được gọi là “tải trước trạng thái”.

Nguyên tắc tải trước trạng thái rất đơn giản: CPU của các nút blockchain là đa lõi, trong khi EVM hoạt động ở chế độ thực thi nối tiếp một luồng, chỉ sử dụng một lõi CPU, khiến các lõi CPU khác không được sử dụng đúng mức. Để giải quyết vấn đề này, các lõi CPU không được EVM sử dụng có thể hỗ trợ thực hiện các tác vụ bằng cách dự đoán dữ liệu mà EVM sẽ cần từ chuỗi giao dịch chưa được xử lý. Sau đó, các lõi CPU bên ngoài EVM này sẽ truy xuất dữ liệu mà EVM cần từ cơ sở dữ liệu, giúp EVM giảm chi phí truy xuất dữ liệu và do đó tăng tốc độ thực thi.

Với việc tối ưu hóa bộ đệm và cấu hình phần cứng đầy đủ, opBNB đã đẩy hiệu suất của lớp thực thi nút của nó đến gần giới hạn của EVM một cách hiệu quả, xử lý lên tới 100 triệu khí mỗi giây. 100 triệu lượng khí đốt này về cơ bản là mức trần hiệu suất của EVM chưa sửa đổi, được chứng minh bằng dữ liệu thử nghiệm thử nghiệm từ một chuỗi công khai nổi bật.

Nói một cách ngắn gọn, opBNB có thể xử lý tới 4761 lần chuyển đơn giản mỗi giây, 15003000 lần chuyển mã thông báo ERC20 mỗi giây và khoảng 5001000 hoạt động SWAP mỗi giây dựa trên dữ liệu giao dịch được quan sát trên các trình khám phá blockchain. So sánh các thông số hiện tại, giới hạn TPS của opBNB gấp 40 lần so với Ethereum, gấp hơn 2 lần so với Chuỗi BNB và hơn 6 lần so với Optimism.

Tất nhiên, đối với các giải pháp Ethereum Layer2, do những hạn chế nghiêm trọng của chính lớp DA, hiệu suất bị giảm đáng kể dựa trên hiệu suất của lớp thực thi, khi xem xét các yếu tố như thời gian tạo khối lớp DA và độ ổn định.

Đối với Chuỗi BNB có lớp DA thông lượng cao như opBNB, hiệu ứng nhân đôi của việc mở rộng quy mô là rất có giá trị, đặc biệt khi xem xét rằng Chuỗi BNB có thể lưu trữ nhiều dự án mở rộng quy mô như vậy. Có thể thấy trước rằng BNB Chain đã kết hợp các giải pháp Layer2 do opBNB dẫn đầu vào các kế hoạch chiến lược của mình và sẽ tiếp tục triển khai nhiều dự án blockchain mô-đun hơn, bao gồm giới thiệu bằng chứng ZK vào opBNB và cung cấp các lớp DA có tính sẵn sàng cao với cơ sở hạ tầng bổ sung như GreenField, trong nỗ lực cạnh tranh hoặc hợp tác với hệ sinh thái Ethereum Layer2.

Trong thời đại mà việc mở rộng quy mô theo lớp đã trở thành xu hướng, liệu các chuỗi công khai khác cũng sẽ gấp rút hỗ trợ các dự án Layer2 của riêng họ hay không, nhưng chắc chắn rằng sự thay đổi mô hình sang cơ sở hạ tầng blockchain mô-đun đã xảy ra.

Tuyên bố từ chối trách nhiệm:

  1. Bài viết này được in lại từ [极客 Web3], Mọi bản quyền thuộc về tác giả gốc [Faust, 极客web3]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
  2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
  3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.
Начните торговать сейчас
Зарегистрируйтесь сейчас и получите ваучер на
$100
!