Tài liệu này được truyền cảm hứng bởi công việc của chúng tôi trên FOCIL consensus spec 23thấy rằng giao thức yêu cầu xem xét thận trọng hơn về hạn chế tài nguyên do một số chi tiết không được chỉ định rõ trongNghiên cứu Ethereum FOCIL bài 14.

Tiên quyết

Trước khi chúng ta bắt đầu, chúng ta giả sử cài đặt sau đây để thiết lập một cơ sở sạch sẽ cho các xem xét của chúng ta:

• Bố trí dựa trên phân nhánh cứng Electra. Cũng hợp lý khi xem xét lại điều này trên nền tảng của EIP-7732 (ePBS) để so sánh
• Chúng tôi giả định xây dựng và phát hành khối đơn lẻ, trong đó người đề xuất không chạy MEV-Boost. Đây là thành phần chính đầu tiên cần đúng, trong khi Builder API là một yếu tố cân nhắc thứ cấp
• Chúng tôi đang giả định một cài đặt độc lập với yêu cầu tính toán, bộ nhớ và băng thông điển hình mà bạn có thể dễ dàng theo dõi trên chuỗi Ethereum ngày nay

Diễn viên

Trước khi chúng ta tiếp tục, chúng tôi giả định các thành viên sau đây là một phần của giao thức và phân tích trách nhiệm của họ:

• Các thành viên trong ủy ban Danh sách Bao gồm (IL), người có trách nhiệm hạn chế người đề xuất khe tiếp theo bằng tập hợp các giao dịch danh sách bao gồm của nó
• Người đề xuất, người chịu trách nhiệm đề xuất khe tiếp theo
• Những người chứng thực, người đang chứng thực cho khe tiếp theo cho đầu chuỗi
• Các nút, chúng đang xác minh và theo dõi chuỗi. Người đề xuất và người chứng nhận là một phần của các nút mà đã đặt cược Ether.

Dòng thời gian

Chúng tôi giả định tiến độ sau đây trong đó ủy ban IL, người đề xuất và người chứng thực thực hiện một số hành động trung thực:

• Khe n-1, t=6: Hội đồng IL công bố Danh sách Bao gồm địa phương của họ (ILs) trên một chủ đề toàn cầu sau khi tìm hiểu nội dung của khối n-1
• Khe cắm n-1, t=9: Điểm chứng và các nút xác minh trung thực khóa chặt quan điểm của họ về các IL cục bộ
• Khe n, t=0: Người đề xuất khối cho khe n phát hành khối B, bao gồm dữ liệu được yêu cầu thỏa mãn yêu cầu IL
• Khe n, t=4: Người chứng thực cho khe n bầu chọn cho khối B, xác minh việc tổng hợp IL bằng cách so sánh với quan điểm IL cục bộ của họ và xác nhận xem khối B có “hợp lệ” hay không
  • Chúng tôi quá tải từ “hợp lệ” khi nói về một khối, nhưng nó có thể có nghĩa là “có thể nhập”, “có tính chất chuẩn”, hoặc điều gì khác. Xem câu hỏi mở để làm rõ hơn.

Khoảng thời gian 1: Ủy ban IL phát hành IL địa phương

Diễn viên: Ủy ban Danh sách Bao gồm

Các thành viên trong ủy ban IL lấy danh sách giao dịch IL từ khách hàng EL theo yêu cầu (cuộc gọi từ CL → EL), sau đó họ ký IL cục bộ (giao dịch + tóm tắt) và phát hành nó lên mạng lời đồn.

Xem xét tài nguyên

• Đang nhận các giao dịch IL từ EL mempool → CPU/MEM
• Ký danh sách bao gồm → CPU
• Đang tải danh sách bao gồm lên mạng lăng mạn → Băng thông (Tải lên)

Diễn viên: Các nút (bao gồm cả Attesters)

Các nút theo chuỗi sẽ tải xuống IL, xác minh nó để chống lại anti-DOS (chưa nhập nó vào EL), và chuyển tiếp nó cho các đồng nghiệp khác. Các nút cũng nhập IL vào lựa chọn nhánh và theo dõi IL đã được nhìn thấy bằng cách sử dụng bộ nhớ cache AggreGate. Những người chứng thực và các nút theo chuỗi nên có cùng quan điểm về chuỗi.

Xem xét tài nguyên

• Tải IL → Băng thông (Tải xuống)
• Chuyển tiếp IL → Băng thông (Tải lên)
• Xác minh IL cho anti-DOS → CPU/MEM
• Caching nhìn thấy và tổng hợp ILs → MEM

Diễn viên: Người đề xuất

Người đề xuất cho vị trí tiếp theo tích cực theo dõi mạng lưới tin đồn IL và, thu thập và tổng hợp các IL cục bộ, sau đó tại giới hạn tổng hợp IL (khoảng # 2) người đề xuất cập nhật quy trình xây dựng khối với danh sách các giao dịch IL sẽ được đưa vào khối của nó. Điều này đòi hỏi một cuộc gọi CL đến EL.

Xem xét tài nguyên

• Kế thừa cùng chi phí như các nút theo chuỗi

Trường Hợp Cạnh Bên Người Đề Xuất

Nếu người đề xuất khe tiếp theo quan sát đủ số lượng danh sách bao gồm dựa trên một hash cha mà nó chưa thấy, người đề xuất sẽ cần yêu cầu một cách thủ công khối beacon thiếu, nhập khẩu khối và xây dựng trên đó.

Kết luận

Dựa trên những điều trên, chúng ta có thể xác định các khu vực tiêu tốn tài nguyên tiềm năng và thu hẹp phạm vi của chúng:

• Ảnh hưởng CPU của Ủy ban IL: Truy xuất giao dịch IL từ EL & ký: mặc dù có yêu cầu tài nguyên ở đây, nhưng được cho là tương đối rẻ và không phải là một mối quan tâm lớn.
• Ảnh hưởng về băng thông của các nút: Các nút tải và tải lên IL có thể sử dụng rất nhiều băng thông, đặc biệt là nghiên cứu gần đây cho biết kích thước của danh sách inclusion là linh hoạt/vô hạn. Điều này tạo ra một rủi ro DOS tiềm ẩn, vì một thành viên ủy ban IL độc hại có thể làm ngập mạng bằng một số lượng lớn giao dịch, ngay cả khi chúng không hợp lệ. Các nút vẫn sẽ lan truyền về IL trước khi nhập IL. Các biện pháp chống DoS cần được xem xét cẩn thận.

Khoảng thời gian 2: Các nút khóa quan điểm của họ, người đề xuất nhập giao dịch IL

Diễn viên: Người đề xuất

Người đề xuất cập nhật quy trình xây dựng khối với danh sách giao dịch danh sách bao gồm. Đây là một cuộc gọi CL → EL.

Xem xét nguồn lực

• Cập nhật quá trình xây dựng khối với danh sách giao dịch danh sách bao gồm → CPU/MEM

Diễn viên: Các nút (bao gồm cả Attesters)

Xem danh sách bao gồm khóa. Dừng chấp nhận danh sách bao gồm cục bộ từ điểm này trở đi.

Xem xét tài nguyên

• Khóa xem danh sách bao gồm cục bộ → Không

Kết luận

• Tác động CPU của Người đề xuất: Việc nhập các giao dịch IL vào quá trình xây dựng khối có thể làm gián đoạn quá trình xây dựng khối, gây căng thẳng cho CPU của khách hàng lớp thực thi trong quá trình mô phỏng giao dịch. Điều này có thể trở nên phức tạp trong trường hợp trừu tượng hóa tài khoản khi các giao dịch có thể vô hiệu lẫn nhau. Việc này nên được phân tích kỹ hơn.

Khoảng thời gian 3: Người đề xuất phát hành khối

Diễn viên: Người đề xuất

Người đề xuất truy xuất tải trọng thực thi từ máy khách EL (gọi CL → EL), và phát hành nó vào mạng lưới đồn đại khối của đèn hiệu. Sau đó, mọi người khác xác minh khối.

Xem xét tài nguyên

• Truy xuất dữ liệu từ khách hàng EL → CPU/MEM

Diễn viên: Nodes

Các nút nhận khối phản xạ và xác minh nó. Các bước xác minh mới bao gồm kiểm tra danh sách bao gồm xây dựng và xác nhận xem danh sách bao gồm có đáp ứng hàm đánh giá hay không, điều này sẽ được hoàn thành trên CL. Việc kiểm tra các điều kiện IL (xem liệu chúng có thể bị bỏ qua do xung đột hay không) sẽ được thực hiện trên EL.

Resource Considerations

• Xác minh rằng danh sách bao gồm được đáp ứng trên CL → CPU
• Xác minh điều kiện danh sách bao gồm trên EL → CPU

Kết luận

Các nhiệm vụ bổ sung đối với người đề xuất có vẻ không phải là một mối quan tâm đáng kể. Các bước xác minh mới cho các node - kiểm tra xác minh rằng danh sách bao gồm đáp ứng điều kiện đáng chấp nhận - có thể đưa vào một số lượng CPU bổ sung, nhưng có vẻ không phải là một vấn đề lớn.

Khoảng thời gian 4: Ban Thẩm tra

Diễn viên: Người chứng thực

Người chứng thực bỏ phiếu cho khối beacon bằng cách sử dụng quy tắc lựa chọn nhánh LMD GHOST. Người chứng thực chỉ sẽ bỏ phiếu cho một khối beacon thỏa mãn hàm đánh giá danh sách bao gồm, dựa trên các quan sát từ Khoảng thời gian 1.

Xem xét tài nguyên

• Attesters bỏ phiếu cho một khối thỏa mãn hàm đánh giá danh sách bao gồm → Không tốn thêm chi phí

Kết luận

Không có sự khác biệt so với hôm nay.

Tổng kết Xem xét Tài nguyên

Như đã thấy ở trên, những vấn đề tài nguyên quan trọng nhất xoay quanh việc tải lên, tải xuống danh sách bao gồm và tiềm năng bị spam từ quan điểm của một nút. Một vấn đề quan trọng khác là áp lực lên các nút để xác minh và nhập danh sách bao gồm, cũng như nhu cầu của người đề xuất cập nhật quy trình xây dựng khối của mình để đáp ứng danh sách bao gồm. Những khía cạnh này đòi hỏi sự cân nhắc cẩn thận và thiết kế để đảm bảo hiệu quả và an ninh.

Câu hỏi mở

Dựa trên những điều trên, chúng tôi chỉ ra một số câu hỏi mở sẽ ảnh hưởng đến cách viết thông số kỹ thuật:

1. Khối không đáp ứng chức năng đánh giá: Làm thế nào để xử lý một khối không vượt qua chức năng đánh giá danh sách bao gồm, và những yếu tố thiết kế nào cần được xem xét trong các trường hợp như vậy?
   • Nó có nên được xử lý tương tự như các đối tượng blobs và không thể được nhập khẩu?
   • Không nên lọc bằng lựa chọn cái nĩa?
   • Nó không nên hợp lệ trong hàm chuyển trạng thái của tiểu bang?
2. Danh sách Bao gồm Sự đa nghĩa: Nếu một thành viên trong ủy ban danh sách bao gồm gửi các phiên bản khác nhau của danh sách bao gồm đến các nút khác nhau, và tất cả chúng đều được lan truyền trên mạng, hậu quả của hành động này là gì? Làm thế nào hành vi như vậy có thể ảnh hưởng tiêu cực đến người đề xuất xây dựng khối tiếp theo?
3. Người đề xuất đã xây dựng trên một Head khác: Nếu người đề xuất xây dựng trên một Head khác so với Head được gửi bởi ủy ban danh sách bao gồm, và do đó cần thay đổi quan điểm Head của mình, hành động này có tác động gì đến tính hợp lệ của khối và hành vi của người đề xuất?
4. Các giao dịch trên Danh sách Bao gồm không hợp lệ: Các giao dịch trên Danh sách Bao gồm địa phương có thể bị vô hiệu hóa theo một số cách khác nhau. Ngay cả khi các giao dịch này bị vô hiệu hóa, khối vẫn nên đáp ứng được chức năng đánh giá. Các giao dịch có thể bị vô hiệu hóa khi nhiều danh sách bao gồm hợp nhất với nhau hoặc với các giao dịch trong khối. Ngoài kiểm tra nonce điển hình, trừ tài khoản giới thiệu các cách mới để các giao dịch bị vô hiệu hóa, vì số dư có thể bị rút hết với nonce tĩnh. Việc xây dựng khối cần bao nhiêu mô phỏng bổ sung do giao dịch bị vô hiệu hóa và việc này ảnh hưởng đến tính toán CPU của nó còn chưa được xem xét cho cả các diễn viên MEV-Boost và các nhà xây dựng địa phương.
5. Quan sát của người đề xuất về Mạng lưới IL: Người đề xuất theo dõi mạng lưới danh sách bao gồm để biết khi nào nó sẵn sàng xây dựng aggreGate. Có hai phương pháp thiết kế ở đây, và đáng xem xét kỹ hơn. Phương pháp đầu tiên là một người đề xuất tham lam, nơi người đề xuất chờ đến t=9, thu thập nhiều IL nhất có thể, gửi chúng đến EL, và EL cập nhật khối của mình. Phương pháp thứ hai là một người đề xuất lựa chọn, nơi người đề xuất chờ đến khi có một danh sách bao gồm đủ để thỏa mãn hàm đánh giá, gửi chúng đến EL, và có thể làm điều này trong thời gian ít hơn t=9s hoặc thậm chí sớm hơn. Câu hỏi là liệu phương pháp thứ hai có chứng minh rằng việc tối ưu hóa để cho phép người đề xuất phát hành danh sách bao gồm aggreGate sớm hơn. Phương pháp thứ hai có thể chỉ phù hợp cho một IL với giới hạn gas riêng.

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

1. Bài viết này được sao chép từ [Gateethresear]. Tất cả bản quyền thuộc về tác giả gốc [Terence]. Nếu có bất kỳ ý kiến ​​phản đối nào về việc tái in này, vui lòng liên hệ với Cổng 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 tạo 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 đã được dịch là không được phép.