Giải thích mô hình CTO: Cách Reth đạt được 1GB gas mỗi giây

Tác giả: Georgios Konstantopoulos, Đối tác nghiên cứu mô hình &CTO; Dịch: Golden Finance xiaozou

Chúng tôi bắt đầu xây dựng Reth vào năm 2022 để cung cấp tính linh hoạt cho Ethereum L1 đồng thời giải quyết lớp thực thi cho câu hỏi Tiện ích mở rộng L2.

Hôm nay, chúng tôi rất vui được chia sẻ với bạn cách Reth lên kế hoạch đạt được thông lượng L2 1GB gas/giây vào năm 2024 và lộ trình dài hạn của chúng tôi về cách vượt qua mục tiêu này.

Chúng tôi mời toàn bộ hệ sinh thái tham gia cùng chúng tôi để thúc đẩy ranh giới hiệu suất và tiêu chuẩn nghiêm ngặt trong tiền điện tử.

1. Chúng ta đã đạt được sự mở rộng quy mô lớn chưa?

Để tiền điện tử có thể đạt được quy mô toàn cầu và tránh tình trạng đầu cơ (trở thành trường hợp sử dụng chính), có một cách rất đơn giản: giao dịch phải rẻ và nhanh chóng.

1.1 Làm thế nào để đo lường hiệu suất? Khí mỗi giây đề cập đến điều gì?

Hiệu suất thường được đo bằng số giao dịch mỗi giây (TPS). Đặc biệt đối với Ethereum và các chuỗi khối EVM khác, một số liệu tinh tế hơn và có lẽ chính xác hơn là “gas mỗi giây”. Số liệu này phản ánh lượng công việc tính toán mà mạng có thể xử lý mỗi giây, trong đó “gas” là đơn vị đo lượng công việc tính toán cần thiết để thực hiện các hoạt động như giao dịch hoặc hợp đồng thông minh.

Việc chuẩn hóa lượng khí mỗi giây làm thước đo hiệu suất có thể mang lại sự hiểu biết rõ ràng hơn về công suất và hiệu quả của chuỗi khối. Nó cũng giúp đánh giá tác động chi phí của hệ thống và bảo vệ khỏi các cuộc tấn công từ chối dịch vụ (DOS) tiềm ẩn có thể khai thác các phương pháp đo lường ít chi tiết hơn. Số liệu này giúp so sánh hiệu suất của các chuỗi tương thích với Máy ảo Ethereum (EVM) khác nhau.

Chúng tôi khuyên cộng đồng EVM nên sử dụng lượng khí đốt mỗi giây làm chỉ số tiêu chuẩn và kết hợp nó với các tham số định giá khí đốt khác để tạo ra một tiêu chuẩn hiệu suất toàn diện.

1.2 Giai đoạn phát triển hiện tại của chúng tôi

Lượng gas mỗi giây được xác định bằng cách chia mức sử dụng gas mục tiêu của mỗi khối cho thời gian của khối. Trong bảng sau, chúng tôi hiển thị thông lượng khí hiện tại và độ trễ mỗi giây của các chuỗi EVM khác nhau L1 và L2 (chưa đầy đủ):

Chúng tôi nhấn mạnh đến lượng gas mỗi giây và sử dụng nó để đánh giá toàn diện hiệu suất mạng EVM đồng thời nắm bắt chi phí điện toán và lưu trữ. Các mạng như Solana, Sui hoặc Aptos không được đưa vào do mô hình chi phí riêng của chúng. Chúng tôi khuyến khích nỗ lực hài hòa các mô hình chi phí trên tất cả các mạng blockchain để cho phép so sánh toàn diện và công bằng.

Chúng tôi đang phát triển một bộ công cụ đo điểm chuẩn không ngừng nghỉ dành cho Reth để tái tạo khối lượng công việc thực tế. Yêu cầu của chúng tôi đối với các nút là tuân thủ tiêu chuẩn TPC.

2. Làm thế nào Reth đạt được 1GB gas mỗi giây? Hoặc thậm chí cao hơn?

Một phần động lực tạo ra Reth vào năm 2022 là nhu cầu cấp thiết của chúng tôi về một ứng dụng khách được xây dựng dành riêng cho việc tổng hợp web. Chúng tôi tin rằng con đường phía trước của chúng tôi đầy hứa hẹn.

Reth đã đạt tới 100-200MB gas mỗi giây trong quá trình đồng bộ hóa thời gian thực (bao gồm khôi phục người gửi, thực hiện giao dịch và tính toán số lần thử cho mỗi khối), để đạt được mục tiêu ngắn hạn của chúng tôi là 1GB gas mỗi giây); , Cần mở rộng gấp 10 lần.

Khi Reth phát triển, các kế hoạch mở rộng của chúng tôi phải tìm ra sự cân bằng giữa khả năng mở rộng và hiệu quả:

• Mở rộng theo chiều dọc: Mục tiêu của chúng tôi là tối đa hóa việc sử dụng từng "hộp" và phát huy hết tiềm năng của nó. Bằng cách tối ưu hóa cách mỗi hệ thống riêng lẻ xử lý giao dịch và dữ liệu, chúng tôi có thể cải thiện đáng kể hiệu suất tổng thể đồng thời giúp các nhà khai thác nút riêng lẻ hiệu quả hơn.

• Mở rộng theo chiều ngang: Mặc dù đã được tối ưu hóa nhưng khối lượng giao dịch tuyệt đối ở quy mô web vẫn vượt quá khả năng xử lý của bất kỳ máy chủ nào. Để giải quyết tình huống này, chúng tôi đã xem xét triển khai kiến ​​trúc mở rộng theo chiều ngang tương tự như mô hình Kubernetes của các nút blockchain. Điều này có nghĩa là phân bổ khối lượng công việc trên nhiều hệ thống để đảm bảo rằng không một nút nào có thể trở thành nút cổ chai.

Những tối ưu hóa mà chúng ta thảo luận ở đây sẽ không liên quan đến các giải pháp tăng trưởng nhà nước mà chúng ta sẽ thảo luận riêng trong các bài viết khác. Dưới đây là thông tin tổng quan về kế hoạch của chúng tôi nhằm đạt được mục tiêu này:

Trong toàn bộ nhóm công nghệ, chúng tôi cũng sử dụng mô hình tác nhân để tối ưu hóa IO và CPU, cho phép mỗi phần của nhóm được triển khai dưới dạng dịch vụ và có quyền kiểm soát chi tiết đối với việc sử dụng nó. Cuối cùng, chúng tôi đang tích cực đánh giá các cơ sở dữ liệu thay thế nhưng vẫn chưa hoàn thiện.

2.1 Lộ trình mở rộng theo chiều dọc của Reth

Mục tiêu mở rộng theo chiều dọc của chúng tôi là tối đa hóa hiệu suất và hiệu quả của máy chủ hoặc máy tính xách tay chạy Reth.

(1) EVM đồng đều (đúng lúc) và EVM đi trước thời gian (đi trước thời gian)

Trong các dự án như Máy ảo Ethereum (Trong môi trường blockchain như EVM), việc thực thi mã byte được thực hiện thông qua trình thông dịch, xử lý các hướng dẫn một cách tuần tự. Phương pháp này sẽ mang lại một số chi phí vì các lệnh hợp ngữ gốc không được thực thi trực tiếp mà thao tác được thực hiện thông qua lớp VM.

Tính năng biên dịch đúng lúc (JIT) giải quyết vấn đề này bằng cách chuyển đổi mã byte thành mã máy gốc trước khi thực thi, từ đó cải thiện hiệu suất bằng cách bỏ qua quá trình diễn giải của VM. Công nghệ này có thể biên dịch trước các hợp đồng thành mã máy được tối ưu hóa và đã được sử dụng tốt trong các máy ảo khác như Java và WebAssugging.

Tuy nhiên, JIT có thể dễ bị tấn công bởi mã độc được thiết kế để khai thác các lỗ hổng trong quy trình JIT hoặc quá chậm để chạy trong thời gian thực trong quá trình thực thi. Reth sẽ biên dịch trước các hợp đồng đòi hỏi khắt khe nhất (AOT) và lưu trữ chúng trên đĩa, ngăn chặn mã byte không đáng tin cậy cố gắng lạm dụng quy trình biên dịch mã gốc của chúng tôi trong quá trình thực thi trực tiếp.

Chúng tôi đã phát triển trình biên dịch JIT/AOT cho Revm và hiện đang tích hợp nó với Reth. Chúng tôi sẽ mở nguồn nó ngay khi chúng tôi hoàn thành các tiêu chuẩn trong những tuần tới. Trung bình, khoảng 50% thời gian thực thi được dành cho trình thông dịch EVM, do đó, cần phải cải thiện gấp đôi khả năng thực thi EVM, nhưng trong một số trường hợp có nhu cầu tính toán lớn hơn, tác động có thể lớn hơn. Trong vài tuần tới, chúng tôi sẽ chia sẻ điểm chuẩn của mình và tích hợp JIT EVM của riêng chúng tôi vào Reth.

( 2) EVM song song

Khái niệm Máy ảo Ethereum song song (Parallel EVM) hỗ trợ xử lý nhiều giao dịch cùng lúc, khác với mô hình thực thi nối tiếp EVM truyền thống. Chúng tôi có hai đường dẫn sau:

• Đồng bộ hóa lịch sử: Đồng bộ hóa lịch sử cho phép chúng tôi vượt qua Phân tích các giao dịch lịch sử và xác định tất cả các xung đột trạng thái lịch sử để tính toán lịch trình song song tốt nhất có thể.

• Đồng bộ hóa thời gian thực: Để đồng bộ hóa thời gian thực, chúng ta có thể sử dụng công nghệ tương tự như Block STM để thực hiện thực thi suy đoán mà không cần bất kỳ thông tin bổ sung nào (chẳng hạn như danh sách truy cập). Thuật toán hoạt động kém trong thời gian tranh chấp trạng thái nghiêm trọng, vì vậy, chúng tôi muốn khám phá việc chuyển đổi giữa thực thi nối tiếp và song song dựa trên điều kiện khối lượng công việc, cũng như dự đoán tĩnh những khe lưu trữ nào sẽ được truy cập để cải thiện chất lượng song song.

Theo phân tích lịch sử của chúng tôi, khoảng 80% khe lưu trữ Ethereum có thể truy cập độc lập, điều đó có nghĩa là tính song song có thể tăng hiệu quả thực thi EVM lên gấp 5 lần.

（ 3) Tối ưu hóa cam kết trạng thái

Trong mô hình Reth, tính toán gốc trạng thái là một quá trình độc lập với việc thực hiện giao dịch, cho phép sử dụng bộ lưu trữ KV tiêu chuẩn mà không cần lấy thông tin trie. Việc này hiện chiếm >75% thời gian từ đầu đến cuối để niêm phong một khối, đây là một lĩnh vực tối ưu hóa rất thú vị.

Chúng tôi đã xác định được hai “chiến thắng dễ dàng” sau đây có thể cải thiện hiệu suất của trạng thái gốc lên 2-3 lần mà không cần bất kỳ thay đổi giao thức nào:

• Song song hoàn toàn gốc trạng thái: hiện tại chúng tôi chỉ tính toán lại song song cây lưu trữ của các tài khoản đã thay đổi, nhưng chúng tôi có thể tiến xa hơn, khi Cây tài khoản được tính toán song song trong khi công việc lưu trữ gốc hoàn thành trong nền.

• Gốc trạng thái theo đường dẫn: Trong quá trình thực thi, các nút trie trung gian được tìm nạp trước từ đĩa bằng cách thông báo cho dịch vụ gốc trạng thái về các khe lưu trữ và tài khoản liên quan.

Ngoài ra, chúng ta cũng có thể khám phá một số con đường phía trước bằng cách đi chệch khỏi hoạt động gốc trạng thái Ethereum L1:

• Tính toán gốc trạng thái thường xuyên hơn: gốc trạng thái không được tính trên mỗi khối mà được tính một lần cho mỗi khối T. Điều này làm giảm tổng thời gian dành cho việc đầu tư vào state root của toàn bộ hệ thống, đây có lẽ là giải pháp đơn giản và hiệu quả nhất.

• Theo dõi gốc trạng thái: Thay vì tính toán gốc trạng thái trên cùng một khối, hãy để nó tụt lại phía sau một vài khối. Điều này cho phép việc thực thi tiến triển mà không chặn việc tính toán gốc trạng thái.

• Thay thế bộ mã hóa RLP & Keccak256: Hợp nhất các byte trực tiếp và sử dụng hàm băm nhanh hơn (chẳng hạn như Blake3) có thể rẻ hơn so với sử dụng mã hóa RLP.

• Wider Trie: Tăng các nút con N-arity của cây để giảm mức tăng IO do độ sâu logN của trie gây ra.

Có một số câu hỏi ở đây:

< li>

Tác động thứ cấp của những thay đổi trên đối với máy khách hạng nhẹ, L2, cầu nối, bộ đồng xử lý và các giao thức khác dựa vào tài khoản thường xuyên và bằng chứng lưu trữ là gì?

• Chúng ta có thể tối ưu hóa các cam kết trạng thái cho bằng chứng SNARK và tốc độ thực thi gốc cùng một lúc không?

• Cam kết cấp tiểu bang rộng rãi nhất mà chúng tôi có thể đạt được với các công cụ hiện có của mình là gì? Những tác động phụ lên quy mô nhân chứng là gì?

2.2 Lộ trình mở rộng theo chiều ngang của Reth

Chúng tôi sẽ triển khai nhiều nội dung trên trong suốt năm 2024 để đạt được mục tiêu 1GB gas mỗi giây.

Tuy nhiên, việc chia tỷ lệ theo chiều dọc cuối cùng cũng gặp phải những hạn chế về mặt vật lý và thực tế. Không một chiếc máy nào có thể đáp ứng được nhu cầu tính toán của thế giới. Chúng tôi tin rằng ở đây có hai con đường có thể hỗ trợ việc mở rộng của chúng tôi bằng cách giới thiệu nhiều hộp hơn sau khi tải tăng lên:

(1) Multiple Rollup Reth

Hôm nay Ngăn xếp L2 cần chạy nhiều dịch vụ để theo dõi chuỗi: các hàm dẫn xuất L1 CL, L1 EL, L1 -> L2 (có thể đi kèm với L2 EL) và L2 EL. Mặc dù điều này rất tốt cho tính mô-đun, nhưng mọi thứ trở nên phức tạp hơn khi chạy nhiều ngăn xếp nút. Hãy tưởng tượng bạn phải chạy 100 lần cuộn!

Chúng tôi muốn cho phép các bản tổng hợp được phát hành đồng thời khi Reth phát triển và giảm chi phí hoạt động khi chạy hàng nghìn bản tổng hợp xuống gần như bằng không.

Chúng tôi đang nghiên cứu vấn đề này trong dự án Mở rộng quy mô thực thi và sẽ có thêm nhiều dự án khác trong những tuần tới.

(2) Reth gốc trên nền tảng đám mây

Máy phân loại hiệu suất cao có thể có nhiều yêu cầu trên một dây chuyền, chúng cần được mở rộng và một máy không thể đáp ứng nhu cầu của họ. Điều này là không thể với việc triển khai một nút ngày nay.

Chúng tôi hy vọng có thể hỗ trợ việc chạy các nút Reth gốc trên đám mây, triển khai chúng dưới dạng ngăn xếp dịch vụ có thể tự động mở rộng quy mô dựa trên nhu cầu điện toán và sử dụng bộ lưu trữ đối tượng đám mây dường như không giới hạn để lưu trữ liên tục. Đây là kiến ​​trúc phổ biến trong các dự án cơ sở dữ liệu không có máy chủ như NeonDB, CockroachDB hoặc Amazon Aurora.

3. Triển vọng trong tương lai

Chúng tôi hy vọng sẽ dần dần triển khai lộ trình này cho tất cả người dùng Reth. Nhiệm vụ của chúng tôi là làm cho mọi người có thể tiếp cận được 1GB gas mỗi giây và cao hơn. Chúng tôi sẽ thử nghiệm tính năng tối ưu hóa trên Reth AlphaNet và chúng tôi hy vọng mọi người sẽ sử dụng Reth làm SDK để xây dựng các nút hiệu suất cao được tối ưu hóa.

Có một số câu hỏi mà chúng tôi chưa có câu trả lời.

• Reth giúp cải thiện hiệu suất của toàn bộ hệ sinh thái L2 như thế nào?

• Làm cách nào để đo lường chính xác các tình huống xấu nhất có thể xảy ra với một số hoạt động tối ưu hóa của chúng tôi nói chung?

• Chúng ta giải quyết những bất đồng tiềm ẩn giữa L1 ​​và L2 như thế nào?

Chúng tôi chưa có câu trả lời cho nhiều câu hỏi này, nhưng chúng tôi có rất nhiều ý tưởng ban đầu đầy hứa hẹn sẽ khiến chúng tôi bận rộn trong một thời gian và chúng tôi hy vọng sẽ làm được điều đó. xem họ Nỗ lực để có kết quả trong những tháng tới.