Trạng thái nhận thức: khám phá sớm
Gần đây, đã có những thảo luận về các phương pháp tích cực hơn để giảm thời gian chờ của Ethereum. Điều này có thể được thực hiện theo hai cách:
- Giảm tham số \delta δ (giả định của chúng tôi về độ trễ mạng tối đa dự kiến). Điều này chỉ có thể được thực hiện một cách an toàn nếu chúng tôi có những cải tiến ở lớp ngang hàng (p2p) giúp giảm độ trễ.
- Thiết kế lại cấu trúc khe cắm để giảm số vòng trễ mạng trong một khe cắm.
Có nhiều công việc củng cố và tối ưu hóa p2p đang được tiến hành để cho phép (1); ứng cử viên hàng đầu cho việc tăng tốc đáng kể là mã hóa xóa. Công việc nghiên cứu đang tập trung vào (2).
Bài đăng này sẽ lập luận rằng cách tiếp cận tối ưu đối với (2) có thể là tránh xa sự kết hợp chặt chẽ giữa các khe cắm và Tính chất cuối cùng được giới thiệu trong 3SF và thay vào đó là có một quy tắc lựa chọn Fork LMD GHOST riêng biệt hơn và tiện ích tính Tính chất cuối cùng , với số lượng người tham gia khác nhau.
Đầu tiên, chúng ta hãy xem cấu trúc khe cắm hiện tại ( nguồn ):
\delta δ ở đây là 4 giây. Phần đầu tiên (lan truyền Block ) là không thể tránh khỏi. Giờ hãy lưu ý rằng có hai giai đoạn liên quan đến chứng thực: tổng hợp và lan truyền. Điều này xảy ra vì có quá nhiều chứng thực (khoảng 30.000 mỗi khe) để có thể truyền tải trực tiếp. Thay vào đó, trước tiên chúng ta phát một tập hợp con bên trong một mạng con, sau đó phát các tập hợp con bên trong một mạng ngang hàng (p2p) toàn cầu.
Nếu chúng ta muốn tăng số lượng trình xác thực nhiều hơn nữa (ví dụ: lên 1 triệu cho mỗi khe), chúng ta có thể phải thực hiện tới ba giai đoạn để duy trì quy mô của mỗi giai đoạn ở mức có thể quản lý được (thực tế, bài viết trước đây đã đề xuất chính xác điều này).
Nhìn chung, chúng ta có thể ước lượng như sau:
tổng hợp \ _thời gian = log_C ( số lượng \ _trình xác thực ) tổng hợp thời gian = log C ( số lượng trình xác thực )
Trong đó C C là dung lượng: nhiều chữ ký có thể được phát sóng đồng thời một cách an toàn trong một mạng con duy nhất . Có vẻ như giá trị thực tế của C C nằm ở hàng trăm hoặc hàng nghìn. Nếu muốn chống lượng tử, chúng ta nên giả định các con số thận trọng hơn (ví dụ: nếu một chữ ký chống lượng tử chiếm 3 KB và có 256 chữ ký trên mỗi khe, thì mỗi khe sẽ là 768 kB, gần tương đương với kích thước Block thực thi trong trường hợp xấu nhất).
Tính chất cuối cùng phụ thuộc vào "bộ xác thực đầy đủ" tham gia; có lẽ là 8192 nếu chúng ta (i) chấp nhận tập trung Staking nhiều hơn hoặc ủy quyền bắt buộc, hoặc (ii) thực hiện Orbit , và nhiều hơn nữa (có thể là 10^5 10 5 đến 10^6 10 6 ), nếu không. Nghĩa là, C^2 C2 hoặc C^3 C3 tùy thuộc vào giả định của chúng ta.
Trong khi đó, một phiên bản LMD GHOST ổn định chỉ yêu cầu số lượng thành viên tham gia được chọn ngẫu nhiên; ở đây, kích thước 256 (tức là nhỏ hơn C C ) là chấp nhận được để đạt được tỷ lệ lỗi rất thấp .
Điều này ngụ ý rằng bất kỳ phương pháp nào cố gắng thực hiện một bước để hoàn tất Consensus cho mỗi ô sẽ về cơ bản mất 3C 3 C hoặc 4C 4 C (thêm một C C cho người đề xuất). Trong khi đó, nếu chúng ta không làm như vậy, một bước sẽ chỉ mất 2C 2 C.
Điều này đưa tôi đến đề xuất chính của tôi:
- Có một chuỗi LMD GHOST trong đó ~256 trình xác thực được chọn ngẫu nhiên cho mỗi khe . Sử dụng chuỗi này làm "nhịp tim" chính.
- Có một cơ chế Consensus cuối cùng theo sát phía sau (thực tế, có lẽ là hoàn tất trong 12C 12C ) , sử dụng tất cả các trình xác thực đang hoạt động. Đừng cố gắng kết hợp các phiếu bầu GHOST của LMD và các phiếu bầu Consensus cuối cùng; hãy coi chúng hoàn toàn tách biệt.
Điều này mang lại cho chúng ta những lợi ích sau:
- Thời gian khe cắm rất nhanh đủ tốt cho trường hợp bình thường, mà không thay đổi bất kỳ giả định bảo mật nào (vì bước "tổng hợp" không còn là một phần của thời gian khe cắm nữa)
- Chúng tôi có toàn quyền tự do lựa chọn cơ chế Consensus cuối cùng, bao gồm cả việc sử dụng các cơ chế truyền thống có sẵn (ví dụ: Tendermint)
- Chúng ta có được câu trả lời tự nhiên cho câu hỏi "cách xử lý rò rỉ không hoạt động": trong quá trình rò rỉ không hoạt động, chuỗi LMD GHOST vẫn tiếp tục, Consensus cuối cùng dừng lại. Sau đó, chính chuỗi LMD GHOST sẽ xác định tiến trình của rò rỉ không hoạt động, từ đó xác định thời điểm có thể khôi phục quá trình hoàn thiện.
- Chúng tôi có nhiều tự do hơn để đưa ra những lựa chọn tham vọng hơn cho bước Consensus (ví dụ: yêu cầu 1 REQ xác thực ETH và 1 triệu trình xác thực)
- Đơn giản hơn vì có ít hiệu ứng tương tác hơn và vì chúng ta có thể có số lượng người xác thực cao hơn mà không cần đến các kỹ thuật giống như Orbit.
