Cửa hàng DApp | Trung tâm Web3 với các sự kiện và trò chơi

Chủ đề thịnh hành

Đây là một số kết quả thú vị. Thật tuyệt khi thấy MegaETH đứng đầu : ) Để đặt dữ liệu vào một số bối cảnh, độ trễ end-to-end của một yêu cầu RPC bao gồm ba thành phần: (1) độ trễ truyền ánh sáng từ/người quan sát đến/máy chủ, (2) thời gian mà máy chủ cần để lấy và xử lý dữ liệu được yêu cầu, (3) thời gian mà người quan sát cần để tải xuống phản hồi. Như bạn đã đề cập, các phương pháp RPC đang được thử nghiệm là nhẹ nhàng, cả về chi phí tính toán và kích thước dữ liệu. Điều này có nghĩa là các thí nghiệm chủ yếu kiểm tra (1), tức là độ trễ truyền giữa các người quan sát và các máy chủ RPC. Đừng hiểu sai ý tôi - các RPC của MegaETH cũng rất mạnh về (2) và (3) và sẽ thật thú vị khi thấy các thí nghiệm căng thẳng chúng! Vậy, làm thế nào để chúng ta tinh chỉnh độ trễ truyền? Thực ra, không có quá nhiều điều chỉnh. Đầu tiên, chúng ta có thể triển khai các máy chủ RPC ở nhiều khu vực địa lý khác nhau, và tự động định tuyến yêu cầu đến máy chủ gần nhất. Điều này giống như các chuỗi thức ăn nhanh mở cửa hàng khắp nơi - luôn có một chi nhánh gần bên! Cụ thể hơn, việc có các máy chủ phân bố theo địa lý giúp giảm khoảng cách vật lý giữa người dùng và máy chủ. Thứ hai, chúng ta có thể tối ưu hóa cấu trúc mạng. Ngay cả khi nó giữa cùng một cặp người gửi và người nhận, độ trễ truyền thay đổi dựa trên đường đi thực tế của mạng. Ví dụ, giữa Bờ Đông Hoa Kỳ và Châu Á, độ trễ có thể thay đổi gấp 2 lần tùy thuộc vào việc các gói dữ liệu đi qua Thái Bình Dương hay qua Châu Âu. Đôi khi, thậm chí có nhiều đường đi mạng theo cùng một lộ trình địa lý; một số đường bị tắc nghẽn hơn những đường khác, dẫn đến độ trễ cao hơn. Điều này giống như có nhiều xa lộ để chọn từ điểm A đến điểm B. Những lợi thế về độ trễ mà bạn quan sát được có lẽ đến từ việc chúng tôi tối ưu hóa lộ trình.

MegaETH RPC chính thức so với Thirdweb RPC – Độ trễ Testnet Tôi muốn lấy dữ liệu trực tiếp từ MegaEth mà không cần phải chạy bất kỳ cơ sở hạ tầng nào và đang tìm cách nhanh nhất để làm điều này. Tôi đã sử dụng "" để chạy một bài kiểm tra đơn giản nhằm xem RPC chính thức của MegaETH so với RPC bên thứ ba (Thirdweb) như thế nào. Mục tiêu là kiểm tra cái nào sẽ lấy dữ liệu mới từ trình khám phá nhanh hơn từ các khu vực khác nhau trên thế giới. Bài kiểm tra đã sử dụng lệnh RPC `eth_blockNumber` và `eth_getBalance` trên testnet MegaETH. Nó đã kiểm tra 27 vùng AWS trên 6 châu lục, gửi yêu cầu lần lượt với khoảng cách một giây. Nó theo dõi độ trễ trung bình, tỷ lệ thất bại, lỗi 429, yêu cầu thành công và tổng thời gian yêu cầu. Dưới đây là kết quả Tất cả các kết quả cho thấy RPC chính thức của MegaETH nhanh hơn ở cả sáu châu lục và tất cả 27 vùng. Độ trễ của MegaETH dao động từ khoảng 126 ms đến 238 ms theo bài kiểm tra này. Đối với Thirdweb, độ trễ dao động từ khoảng 170 ms đến 381 ms. Cả hai đều có tỷ lệ thất bại thấp nhưng MegaETH có ít hơn một chút, và tổng thời gian yêu cầu luôn thấp hơn cho MegaETH. Để có bối cảnh, thường thì các mạng có ít nhất một vài vùng mà RPC bên thứ ba nhanh hơn. Avalanche, Optimism và Ethereum đều có ví dụ về điều này trong các bài kiểm tra công khai. Xem - Kết quả Avalanche C-Chain - Kết quả Optimism - Kết quả Ethereum Việc MegaETH vượt qua Thirdweb ở mọi nơi là điều không bình thường. Luận điểm của tôi về việc tại sao RPC chính thức của MegaETH lại đứng đầu là mạng lưới được điều chỉnh tốt về mặt kiến trúc, và sử dụng một bộ sắp xếp duy nhất tại một thời điểm. Tôi mời @NamikMuduroglu @yangl1996 @0xSami_M chia sẻ suy nghĩ của họ Đây là testnet nên các con số có thể thay đổi trên mainnet khi lưu lượng truy cập cao hơn. Tuy nhiên, hiện tại, nếu bạn cần cách nhanh nhất và đáng tin cậy nhất để lấy dữ liệu từ trình khám phá MegaETH, RPC chính thức là lựa chọn rõ ràng. NB: Tôi không phải là chuyên gia, đây chỉ là lý thuyết và có thể không chính xác 100% vì dữ liệu được kiểm tra là các cuộc gọi nhẹ, cũng như các kết quả này được chụp lại, kết quả có thể thay đổi nếu dữ liệu lớn hơn được liên quan vào những thời điểm khác nhau, cuối cùng tôi đã sử dụng một RPC bên thứ ba công khai, có thể có những cái nhanh hơn.

12,8K

Hàng đầu

Thứ hạng

Yêu thích