Chúng tôi bắt đầu xây dựng Reth vào năm 2022 để cung cấp sự chống chịu cho Ethereum L1, và giải quyết việc mở rộng lớp thực thi trên Layer 2.

Hôm nay, chúng tôi rất háo hức chia sẻ con đường của Reth để đạt 1 gigagas mỗi giây trong L2 vào năm 2024, và lộ trình dài hạn của chúng tôi để vượt qua điều đó.

Chúng tôi mời cộng đồng hệ sinh thái hợp tác với chúng tôi khi chúng tôi đẩy ranh giới về hiệu suất và đánh giá mạnh mẽ trong lĩnh vực tiền điện tử.

Chúng ta đã mở rộng chưa?

Có một con đường rất đơn giản để tiền điện tử đạt tỷ lệ quy mô toàn cầu và thoát khỏi việc đầu cơ như trường hợp sử dụng chủ yếu: Giao dịch cần phải rẻ và nhanh chóng.

Làm thế nào để đo lường hiệu suất? Ý nghĩa của gas mỗi giây là gì?

Hiệu suất thường được đo bằng chỉ số “Giao dịch trên Giây” (TPS). Đối với Ethereum và các blockchain EVM khác, một chỉ số có thể chính xác hơn là “gas trên giây.” Chỉ số 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 nỗ lực tính toán cần thiết để thực hiện các giao dịch hoặc hợp đồng thông minh.

Tiêu chuẩn hóa xung quanh khí mỗi giây như một chỉ số hiệu suất cho phép hiểu rõ hơn về khả năng và hiệu suất của một chuỗi khối. Nó cũng giúp đánh giá các hậu quả về chi phí trên hệ thống, bảo vệ chống lại các cuộc tấn công từ chối dịch vụ tiềm ẩn có thể lợi dụng các đo lường ít tinh vi hơn. Chỉ số này giúp so sánh hiệu suất trên các chuỗi tương thích với Máy ảo Ethereum (EVM) khác nhau.

Chúng tôi đề xuất cộng đồng EVM áp dụng gas mỗi giây như một chỉ số tiêu chuẩn, kèm theo việc tích hợp các chiều khác của giá gasđể tạo ra một tiêu chuẩn hiệu suất toàn diện.

Hôm nay chúng ta ở đâu?

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

Chúng tôi nhấn mạnh về gas mỗi giây để đánh giá kỹ lưỡng hiệu suất mạng EVM, bao gồm cả chi phí tính toán và lưu trữ. Các mạng như Solana, Sui hoặc Aptos không được bao gồm do mô hình chi phí riêng biệt của họ. Chúng tôi khuyến khích nỗ lực hòa hợp 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 làm việc trên một bộ công cụ đánh giá liên tục cho Reth sao chép công việc thực sự, nếu bạn muốn hợp tác vào điều này, vui lòng liên hệ. Chúng tôi cần một TPC Benchmarkcho các nút.

Làm sao Reth sẽ đạt được 1 gigagas mỗi giây? Vượt qua điều đó?

Chúng tôi đã được một phần động viên để xây dựng Reth vào năm 2022 bởi nhu cầu cấp bách phải có một ứng dụng được xây dựng một cách có mục đích cho web-scale rollups. Chúng tôi nghĩ rằng chúng tôi có một con đường tiến lên hứa hẹn.

Reth đã đạt 100-200mgas/s trong quá trình đồng bộ trực tiếp (bao gồm phục hồi của người gửi, thực hiện giao dịch và tính toán trie trên mỗi khối); 10 lần từ đây sẽ đưa chúng ta đến mục tiêu ngắn hạn của chúng ta là 1 gigagas/s.

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

• Tăng cường theo chiều dọc: Mục tiêu của chúng tôi ở đây là tối đa hóa việc sử dụng mỗi “ô” đến giới hạn của nó. Bằng cách tối ưu hóa cách mà mỗi hệ thống cá nhân xử lý giao dịch và dữ liệu, chúng ta có thể cải thiện đáng kể hiệu suất tổng thể, đồng thời làm cho việc vận hành của từng nút cá nhân hiệu quả hơn.
• Mở rộng theo chiều ngang: Mặc dù đã tối ưu hóa, số lượng giao dịch tại quy mô web vượt quá khả năng xử lý của bất kỳ máy chủ đơn lẻ nào. Để giải quyết vấn đề này, chúng tôi muốn triển khai một kiến trúc được mở rộng theo chiều ngang, tương tự như mô hình Kubernetes cho các nút blockchain. Điều này có nghĩa là phân phối công việc trên nhiều hệ thống để đảm bảo rằng không có một nút nào trở thành chướng ngại vật.

Các tối ưu hóa mà chúng tôi đang khám phá ở đây không liên quan đến việc giải quyết tăng trưởng của bang, mà chúng tôi đang nghiên cứu riêng.

Dưới đây là tóm tắt cách chúng tôi dự định đạt được mục tiêu đó:

Trên toàn bộ ngăn xếp, chúng tôi cũng đang tối ưu hóa cho IO và CPU bằng cách sử dụng mô hình actor, để cho phép mỗi phần của ngăn xếp được triển khai như một dịch vụ với kiểm soát tốt đẹp về sử dụng. 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 chưa quyết định về ứng cử viên nào.

Lộ trình tăng cường dọc của Reth

Mục tiêu của chúng tôi ở đây là tối đa hóa hiệu suất và hiệu quả của một máy chủ hoặc laptop chạy Reth.

EVM Just-In-Time & Ahead-of-Time

Trong các môi trường blockchain như Máy ảo Ethereum (EVM), việc thực thi bytecode xảy ra thông qua một trình thông dịch, xử lý tuần tự các lệnh. Phương pháp này giới thiệu chi phí vì nó không thực hiện các hướng dẫn lắp ráp gốc trực tiếp, thay vào đó hoạt động thông qua lớp VM.

Biên dịch Just-In-Time (JIT) giải quyết vấn đề này bằng cách chuyển đổi bytecode thành mã máy native ngay trước khi thực thi, từ đó cải thiện hiệu suất bằng cách tránh qua quá trình phiên dịch của VM. Kỹ thuật này, biên dịch hợp đồng thành mã máy tối ưu từ trước, đã được cố định trong các VM khác như Java và WebAssembly.

Tuy nhiên, JIT có thể dễ bị tổn thương bởi mã độc được thiết kế để lợi dụng quá trình JIT, hoặc có thể quá chậm để chạy trực tiếp trong quá trình thực thi. Reth sẽ Ahead-of-Time (AOT) biên dịch các hợp đồng có nhu cầu cao nhất và lưu trữ chúng trên đĩa, để tránh bytecode không đáng tin cậy cố gắng lạm dụng bước biên dịch mã nguồn của chúng ta trong quá trình thực thi trực tiếp.

Chúng tôi đã đang làm việc trên một trình biên dịch JIT/AOT cho Revm, hiện đang được tích hợp với Reth. Chúng tôi sẽ công khai mã nguồn cho điều này trong những tuần sắp tới sau khi hoàn thành việc đo lường hiệu suất của chúng tôi. Khoảng 50% thời gian thực thi trung bình được dành cho trình thông dịch EVM, vì vậy điều này sẽ cung cấp cải tiến thực thi EVM khoảng ~2 lần, mặc dù trong một số trường hợp tải nặng hơn về tính toán thì có thể sẽ có tác động lớn hơn. Chúng tôi sẽ chia sẻ các bảng đo và tích hợp của trình biên dịch JIT EVM của chúng tôi trong Reth trong những tuần sắp tới.

Parallel EVM

Khái niệm về Máy Ảo Ethereum Song Song (Parallel EVM) cho phép xử lý giao dịch đồng thời, khác biệt so với mô hình thực thi tuần tự truyền thống của EVM. Chúng tôi có 2 hướng tiếp cận ở đây:

1. Đồng bộ Lịch sử: Trong đồng bộ lịch sử, chúng ta có thể tính toán lịch trình song song tốt nhất có thể bằng cách phân tích các giao dịch trong quá khứ và xác định tất cả mâu thuẫn trạng thái lịch sử. Xem sự cố gắng sớm của chúng tôi trong một nhánh cũ trên Github.
2. Live Sync: Đối với đồng bộ hóa trực tiếp, chúng tôi có thể sử dụng Block STM-như các kỹ thuật thực thi theo cách thử nghiệm mà không cần bất kỳ thông tin bổ sung nào như danh sách truy cập. Thuật toán này có hiệu suất kém trong các giai đoạn có nhiều tranh chấp trạng thái, vì vậy chúng tôi muốn khám phá chuyển đổi giữa thực thi tuần tự và song song tùy thuộc vào hình dạng của công việc, cũng như dự đoán tĩnh điều nào khe lưu trữ sẽ được truy cập để cải thiện chất lượng của tính song song. Xem một PoC bởi một nhóm bên thứ baở đây.

Dựa vào phân tích lịch sử của chúng tôi, kho lưu trữ Ethereum khoảng ~80% được truy cập một cách độc lập, có nghĩa là song song có thể mang lại cải tiến lên đến 5 lần trong việc thực thi EVM.

Cải thiện cam kết của Nhà nước

Chúng tôi vừa viết vềtác động của state root đối với hiệu suất và sự khác biệt giữa mô hình cơ sở dữ liệu Reth từ các khách hàng khác, cũng như lý do tại sao nó quan trọng.

Trong mô hình Reth, việc tính toán gốc trạng thái là một quy trình riêng biệt so với việc thực thi giao dịchxem chúng tôi mã), cho phép sử dụng các cửa hàng KV tiêu chuẩn không cần biết gì về trie. Điều này hiện mất >75% thời gian từ đầu đến cuối để niêm phong một khối và là một khu vực rất thú vị để tối ưu hóa.

Chúng tôi xác định 2 "chiến thắng dễ dàng" sau đây có thể mang lại cho chúng tôi hiệu suất gốc trạng thái gấp 2-3 lần mà không cần bất kỳ thay đổi giao thức nào:

1. Gốc Trạng Thái Hoàn Toàn Song Song: Hiện tại, chúng tôi chỉ tính lại cây lưu trữ cho các tài khoản đã thay đổi một cách song song, nhưng chúng tôi có thể tiến xa hơn và cũng tính toán cây tài khoản một cách song song trong khi công việc gốc lưu trữ hoàn thành ở nền.
2. Gốc Trạng Thái Đường Ống: Tiền xử lý các nút trie trung gian từ đĩa trong quá trình thực thi 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 được chạm đến.

Vượt xa điều đó, chúng ta thấy một số con đường phía trước bằng cách phân nhánh khỏi hành vi gốc trạng thái Ethereum L1.

1. Gốc Trạng Thái ít thường xuyên: Thay vì tính toán gốc trạng thái trên mỗi khối, tính toán nó mỗi T khối. Điều này giảm tỷ lệ thời gian tổng cộng được dành cho gốc trạng thái trong toàn bộ hệ thống và có thể là giải pháp dễ dàng và hiệu quả nhất.
2. Gốc Trạng Thái Theo Dõi: Thay vì phải tính toán gốc trạng thái trong cùng một khối, hãy để nó đuối lại 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 bị chặn lại do việc tính toán gốc trạng thái.
3. Thay thế Bộ mã hóa RLP & Keccak256: Thay vì mã hóa bằng RLP, có thể rẻ hơn nếu chỉ cần nối các byte và sử dụng một hàm băm nhanh hơn như Blake3.
4. Trie Rộng Hơn: Tăng số lượng N của cây, để giảm sự khuếch đại IO do độ sâu logN của trie.

Có một vài câu hỏi ở đây:

1. Những tác động cấp hai của những thay đổi trên đối với các máy khách nhẹ, L2s, cầu nối, bộ xử lý phụ và các giao thức khác dựa vào chứng minh tài khoản & lưu trữ thường xuyên là gì?
2. Chúng ta có thể tối ưu cả cam kết trạng thái cho việc chứng minh SNARK và cho tốc độ thực thi bản địa không?
3. Cam kết của nhà nước rộng nhất mà chúng ta có thể đạt được với các công cụ mà chúng ta có sẵn là gì? Có những tác động cấp hai nào xung quanh kích thước chứng kiến?

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

Chúng tôi sẽ thực hiện trên nhiều điểm trên trong suốt năm 2024 và đạt được mục tiêu 1gigagas/giây.

Tuy nhiên, việc tăng cường theo chiều dọc cuối cùng sẽ đối mặt với các giới hạn vật lý và thực tế. Không có một máy duy nhất nào có thể xử lý nhu cầu tính toán của thế giới. Chúng tôi nghĩ rằng có 2 con đường phía trước ở đây, cho phép chúng tôi mở rộng bằng cách giới thiệu thêm hộp khi tải thêm tăng lên:

Multi-Rollup Reth

Các ngăn xếp L2 ngày nay đòi hỏi chạy nhiều dịch vụ để theo dõi chuỗi: L1 CL, L1 EL, chức năng phái sinh L1 -> L2 (có thể được đóng gói với L2 EL), và L2 EL. Mặc dù tuyệt vời cho tính linh hoạt, điều này trở nên phức tạp khi chạy nhiều ngăn xếp nút. Hãy tưởng tượng phải chạy 100 rollups!

Chúng tôi muốn cho phép triển khai rollups trong cùng quy trình như Reth và giảm chi phí vận hành của việc chạy hàng nghìn rollups gần như về 0.

Chúng tôi đã bắt đầu với điều này với chúng tôi Các dự án mở rộng thực hiện ([1], [2]) , nhiều hơn trong những tuần tới đây.

Reth native đám mây

Các bộ xử lý hiệu suất cao có thể có đủ cầu cần trên một chuỗi duy nhất đến mức cần mở rộng ra ngoài một máy duy nhất. Điều này không thể thực hiện trong các triển khai nút khối ngày nay.

Chúng tôi muốn cho phép chạy các nút Reth nguyên sinh trên đám mây, triển khai như một ngăn xếp dịch vụ có thể tự động mở rộng theo yêu cầu tính toán và sử dụng lưu trữ đối tượng trên đám mây hình như vô hạn. Đây là một kiến trúc phổ biến trong các dự án cơ sở dữ liệu không máy chủ như NeonDB, CockroachDB hoặc Amazon Aurora.

Xem sớm suy nghĩtừ nhóm của chúng tôi về một số cách chúng ta có thể giải quyết vấn đề này.

Outlook

Chúng tôi dự định triển khai bản đồ con này một cách tăng dần cho tất cả người dùng Reth. Sứ mệnh của chúng tôi là cung cấp cho mọi người quyền truy cập vào 1 gigagas/s và hơn nữa. Chúng tôi sẽ thử nghiệm việc tối ưu hóa trên Reth AlphaNet, và chúng tôi hy vọng mọi người sẽ xây dựng các nút hiệu suất cao được sửa đổi bằng cách sử dụng Reth như một SDK.

Còn một số câu hỏi mà chúng tôi vẫn chưa tìm ra câu trả lời.

• Làm thế nào Reth có thể giúp cải thiện hiệu suất trên toàn hệ sinh thái L2?
• Làm thế nào chúng ta đo lường một cách thích hợp những trường hợp xấu nhất khi một số tinh chỉnh của chúng ta có thể dành cho trường hợp trung bình?
• Làm thế nào để chúng ta quản lý sự căng thẳng giữa L1 và L2 có thể phân kỳ?

Chúng tôi không có câu trả lời cho nhiều câu hỏi này, nhưng chúng tôi có đủ dẫn đầu hứa hẹn ban đầu để giữ cho chúng tôi bận rộn trong một thời gian và hy vọng thấy những nỗ lực này mang lại kết quả trong những tháng tới.

Tuyên bố:

1. Bài viết này được sao chép từ [ mô hình], Tất cả bản quyền thuộc về tác giả gốc [Georgios Konstantopoulos]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ với Gate Họcđội ngũ và họ sẽ xử lý nhanh chóng.
2. Miễn Trừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của 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 nêu, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép.