Trong lần thực thi cuối cùng ACD, một mục tiêu blob cũng như một số người đề xuất phụ trợ khác đã được chuyển sang trạng thái CFI.
Những đề xuất đó là:
- EIP 7623 (Tăng chi phí dữ liệu gọi)
- EIP này tăng chi phí gas của dữ liệu gọi để số lượng dữ liệu gọi tối đa có thể trong một block thấp hơn, giảm kích thước block tối đa. Trước 4844, dữ liệu gọi là cách mà các rollup đăng dữ liệu của họ lên blockchain, vì vậy tăng giá của dữ liệu gọi không khả thi, nhưng bây giờ các rollup đang đăng blob thay vì thế, chúng ta có thể tăng giá của dữ liệu gọi để kiểm soát kích thước block tối đa mà không gây ra vấn đề cho các rollup.
- EIP 7762 (Tăng min_base_fee_per_blob_gas)
- EIP này đặt một giá dự trữ nhỏ cho các blob (~1c) được thiết kế để tăng tốc độ khám phá giá. Mỗi lần tăng gấp đôi giá của các blob mất gần 6 block đầy để đạt được do cách thực hiện bộ điều khiển, vì vậy đặt tham số này thành 2^25 wei thay vì 1 wei sẽ tiết kiệm rất nhiều thời gian cho bộ điều khiển để tăng lên.
- EIP 7742 (Tách blob count giữa CL và EL)
- Đây chủ yếu là một thay đổi về quản lý, đặt các biến blob count ở đúng vị trí phù hợp với sự phân tách thích hợp giữa EL và CL.
- EIP 7691 (tăng blob target từ 3 lên 4, blob limit vẫn ở 6)
- Bộ điều khiển phí EIP 4844 là một bộ điều khiển tích phân sẽ hoạt động tốt với mục tiêu 4, giới hạn 6 như với mục tiêu 3, giới hạn 6.
Sự phản đối
Đã có một số phản đối trong cuộc gọi và từ các nhà đặt cược solo chống lại những đề xuất này. Đặc biệt, các nhà đặt cược solo lo lắng về băng thông bổ sung cần thiết để đề xuất một block một mình. Nhưng nếu bạn xem xét các đề xuất trên, những lo ngại đó có thể không đúng. Thực tế, nếu tất cả các đề xuất được bao gồm cùng nhau, nó sẽ làm giảm kích thước block tối đa. Tăng blob target không có nghĩa là tăng blob limit và việc bổ sung 7623 sẽ làm giảm kích thước tối đa của phần không phải blob của tải trọng block.
Ngoài ra, một số nhà đặt cược solo đã đăng về tốc độ tải lên kém của họ, điều này đã khơi ra một cuộc thảo luận về các yêu cầu tối thiểu đối với người đặt cược solo, đặc biệt nếu họ đề xuất block một mình. Chỉ có một phần nhỏ các nút đề xuất block một mình và việc này có chi phí cơ hội cao. Tuy nhiên, hãy coi những mối quan ngại này là có cơ sở.
Phản hồi với sự phản đối
Trước tiên, cần bao nhiêu băng thông để đề xuất một block kích thước x một cách đáng tin cậy? Người đề xuất cần block của họ đạt được ít nhất 40% mạng lưới trước 4 giây vào khe thời gian. Block được truyền qua mạng P2P nhưng trước khi điều này xảy ra, người đề xuất cần gieo nó. Nó gửi toàn bộ block cho một tập con N của các ngang hàng của mình. Gửi cho nhiều ngang hàng và chất lượng cao hơn cải thiện khả năng block sẽ đạt được một phần đủ lớn của mạng lưới trước khi hết thời gian.
Nhưng theo như tôi hiểu, các triển khai client mặc định có tối ưu hóa rất sơ sài về độ trễ và độ tin cậy với các ngang hàng. Nói cách khác, có thể có những cách mà các nút có thể tối ưu hóa tốc độ truyền block của họ mà không sử dụng thêm băng thông.
Tuy nhiên, các kết nối cực kỳ kém từ các nhà đặt cược ở vùng nông thôn có khả năng sẽ trở thành một điểm nghẽn trong tương lai, vì vậy rất quan trọng phải đặt các yêu cầu về kết nối internet giống như chúng ta đặt các yêu cầu về phần cứng. Tôi đề xuất tốc độ tải lên 50MB/s làm điểm khởi đầu cho những cuộc thảo luận này. Mặc dù chúng ta không cần nhiều băng thông như vậy ngày nay, mục tiêu của lộ trình rollup là đạt 64 blob mỗi block, vì vậy, ngay cả với các tối ưu hóa đến từ PeerDAS, chúng ta sẽ có không gian để mở rộng đáng kể trong tương lai. Hơn nữa, tốc độ tải lên 50MB trên internet dành cho người tiêu dùng rất phổ biến ở Bắc và Nam Mỹ, châu Á và châu Âu. Châu Phi cũng có khả năng truy cập đáng kể (mặc dù ít toàn diện hơn) ở phạm vi tốc độ này. Do đó, phạm vi tốc độ này sẽ cung cấp cho mạng lưới không gian đáng kể để phát triển, đồng thời vẫn cho phép các mức độ phân cấp địa lý mong muốn.
Các đề xuất giảm mức stake tối thiểu
Trên Twitter, Vitalik đề xuất giảm stake yêu cầu để chạy một nút. Tôi nghĩ rằng đây sẽ là một ý tưởng tồi. Có hai lý do chúng ta có stake, thứ nhất là trách nhiệm giải trình (slashing cho hành vi xấu), và thứ hai là sybil proofness (bạn cần stake để tham gia). Giảm yêu cầu stake tối thiểu sẽ xấu ở mức độ biên vì chúng ta đã có quá nhiều chữ ký để tổng hợp cho tính chất cuối cùng. Mỗi chữ ký bổ sung gây ra một chi phí cho mạng lưới bằng cách giới thiệu thêm một chữ ký phải được tổng hợp mỗi epoch. Mức stake tối thiểu hiện tại dường như phù hợp với tôi và hy vọng chúng ta sẽ thấy một sự giảm lớn trong số lượng nút sau MAXEB trong lần hard fork tiếp theo. Hơn nữa, các giải pháp ngoài giao thức đã cho phép các nhà đặt cược solo stake với số dư thấp hơn đáng kể.
