Các blockchain nhanh giới thiệu những thách thức mới cho việc quản lý băng thông và sự công bằng trong RPC. Hôm nay, chúng tôi giới thiệu một cơ chế để định hình quyền truy cập RPC bằng cách sử dụng cam kết staking lỏng. Hệ thống đã hoạt động thông qua RPC ShMonad của FastLane. Chủ đề này khám phá kiến trúc và lý do phía sau. 🧵

Các mạng lưới có khả năng xử lý cao như Monad (~0.5 giây thời gian khối, ~1 giây hoàn tất) để lại rất ít không gian cho việc điều chỉnh phản ứng. Khi một điểm cuối RPC phát hiện rằng nó đang bị tấn công spam, thiệt hại đã xảy ra. Việc giảm thiểu phải được thực hiện một cách chủ động và phù hợp với động lực.

Ràng buộc chính là băng thông. Các nút gần gũi với validator bị hạn chế về tài nguyên và nhạy cảm với độ trễ. Nếu quyền truy cập không cần sự cho phép được cấp một cách bừa bãi, các khách hàng thù địch có thể làm cho những người tham gia trung thực bị đẩy ra—dẫn đến trải nghiệm người dùng kém và chi phí cho validator mà không có biện pháp khắc phục. /3

Giải pháp của chúng tôi tận dụng ShMonad, một token staking lỏng có thể lập trình (LST) với khả năng cam kết trên chuỗi. Người dùng nhận được một URL RPC riêng tư để đổi lấy việc cam kết ShMON vào một "Chính sách RPC" trên chuỗi. Cam kết này quản lý giới hạn tỷ lệ truy cập. /4

Băng thông được phân bổ theo tỷ lệ: RPS của người dùng = (ShMON cam kết của người dùng / tổng ShMON cam kết) × RPS_max-global Điều này tạo ra một mô hình băng thông có thể chia sẻ động, được trọng số theo cổ phần mà không cần giới hạn tỷ lệ ngoài chuỗi tập trung.

Stake được cam kết trong một khoảng thời gian (hiện tại là 20 khối), điều này cho phép lưu trữ tạm thời. Relay định kỳ kiểm tra và chụp lại trạng thái cam kết trên chuỗi. Điều này ngăn chặn các cuộc gọi EVM trong đường dẫn quan trọng và hỗ trợ việc sử dụng tần suất cao mà không có độ trễ bổ sung. 6/

Thực nghiệm cho thấy, hệ thống này mang lại độ trễ thấp hơn một cách nhất quán. Qua nhiều phiên kiểm tra độc lập, RPC ShMonad của FastLane cho thấy thời gian phản hồi trung bình/trung vị thấp hơn khoảng 20ms so với nhà cung cấp nhanh thứ hai, với khoảng cách lớn hơn so với các RPC công cộng. 7/

ShMON cam kết với chính sách RPC được đặt cọc với các validator tham gia vào mạng relay FastLane (hiện tại >90% các validator của Monad). Điều này tạo ra sự đồng nhất: những người tiêu thụ băng thông hỗ trợ cùng một validator phục vụ lưu lượng của họ, và các validator có khả năng được bồi thường trực tiếp thông qua các khoản phạt vượt mức. 8/

Nhưng để thực thi giới hạn băng thông một cách đáng tin cậy và không cần tin tưởng, chúng ta cần nhiều hơn là giới hạn tốc độ... chúng ta cần sự thực thi có thể chứng minh. Hiện tại, người dùng bị hạn chế tại điểm chuyển tiếp. Nhưng lộ trình bao gồm các hệ thống chứng minh trên chuỗi dựa trên delta nonce và biên nhận sử dụng đã ký. 9/

Một thiết kế tối giản có thể so sánh các nonce tài khoản giữa các độ cao khối n và m, và phạt (tức là 'áp dụng phụ phí' và giao cho người xác thực) việc sử dụng vượt quá RPS tối đa. Nhưng có một vấn đề: điều này dễ bị tấn công phát hành theo lô bởi một relay khiến các giao dịch xuất hiện đột biến.

Để giảm thiểu điều này, chúng tôi giới thiệu một kênh thứ hai: biên nhận sử dụng có dấu thời gian không đồng bộ. Khi một giao dịch được gửi, nó sẽ được phát sóng đến cả người xác thực và một "nhà phát hành biên nhận" riêng biệt. Nhà phát hành trả lại một đối tượng đã ký cho người gửi, có dấu thời gian và bao gồm siêu dữ liệu nonce trước khi thực thi. Điều này loại bỏ chi phí theo dõi và xác minh khỏi đường dẫn nóng giữa người dùng và người xác thực. 11/

Những biên nhận này (sẽ được ký) phục vụ hai mục đích: 1. Phản hồi từ người dùng: Nếu biên nhận ngừng đến, khách hàng có thể tự nguyện ngừng lưu lượng để tránh phí vượt mức. 2. Bằng chứng trên chuỗi: Biên nhận xác nhận hoạt động tạm thời, phân biệt spam thực sự với việc gộp lại do relay gây ra. 12/

Mô hình này hỗ trợ cả EOAs và 4337 userOps (giả sử không có gói chia sẻ hoặc tích hợp dọc với paymaster của riêng chúng tôi). Trong các phiên bản tương lai, chúng tôi có thể yêu cầu rằng người ký giao dịch phải khớp với người nắm giữ chính sách hoặc đã được đưa vào danh sách trắng trong quá trình cam kết chính sách. TBD. 13/

Mục tiêu của chúng tôi là chuyển giao việc thực thi lên chuỗi mà không làm giảm hiệu suất. Nhờ vào không gian khối phong phú của Monad và tốc độ hoàn tất nhanh chóng, việc gửi chứng cứ trạng thái, xác minh biên lai và tính phí vượt mức là khả thi trên chuỗi... điều này không khả thi trên các mạng có chi phí cao hơn. 14/

Các khoản phạt vượt mức (tương tự như giá cả tắc nghẽn) vẫn đang trong quá trình thiết kế. Chúng tôi đang chờ cấu trúc thị trường phí đã được hoàn thiện của Monad trước khi hoàn thiện lịch trình phụ phí - sẽ không hợp lý nếu chúng tôi thiết kế phí vượt mức mà không biết phí cơ bản là gì. 15/

Thông lượng RPC hiện đang được đo lường tổng hợp (txs + eth_call), nhưng các bản nâng cấp trong tương lai sẽ phân tách các lớp băng thông. Các yêu cầu đọc sẽ được định tuyến qua các nút tối ưu hóa theo vùng, loại bỏ chúng khỏi nút thắt cổ chai do các hạn chế băng thông của validator tạo ra. 16/

Đối với các ứng dụng nhạy cảm với độ trễ (ví dụ: nút đầy đủ, nhà tạo lập thị trường), chúng tôi hỗ trợ kết nối và truyền tải khối trực tiếp qua p2p. Đối với các khối đầy đủ, ưu tiên truyền tải sẽ được cân nhắc theo trọng số cổ phần (LSWQoS): người dùng có ShMON cam kết cao hơn sẽ nhận được khối sớm hơn một chút, tùy thuộc vào ngưỡng bao gồm. 17/

Điều này đại diện cho một sự khác biệt so với RPC "nỗ lực tốt nhất" truyền thống. Với các yêu cầu đọc đến một RPC, số lượng cổ phần đã cam kết xác định số lượng yêu cầu. Đối với các khối được gửi từ các nút của chúng tôi, số lượng cổ phần đã cam kết xác định thứ tự gửi.

Kiểm soát truy cập không cần tin cậy là khả thi trên các chuỗi có thông lượng cao nếu các động lực, việc thực thi và khả năng quan sát được thiết kế từ các nguyên tắc cơ bản. RPC ShMonad là một triển khai tham chiếu của luận điểm đó. Chúng tôi mong chờ sự lặp lại và sự xem xét từ bên ngoài. 19/