Đặc biệt cảm ơn Justin Drake, Hsiao-wei Wang, @antanttc và Francesco vì những phản hồi và đánh giá của họ.
Ban đầu, "hợp nhất" đề cập đến sự kiện quan trọng nhất trong lịch sử giao thức Ethereum kể từ khi ra mắt: quá trình chuyển đổi được chờ đợi từ lâu và khó giành được từ Bằng chứng công việc sang Bằng chứng cổ phần. Ngày nay, Ethereum đã là một hệ thống Bằng chứng cổ phần ổn định và hoạt động trong gần hai năm, Bằng chứng cổ phần đã hoạt động rất tốt về tính ổn định, hiệu suất và tránh rủi ro tập trung. Tuy nhiên, vẫn còn một số lĩnh vực quan trọng mà Bằng chứng cổ phần cần được cải thiện.
Lộ trình của tôi cho năm 2023 chia nó thành nhiều phần: cải tiến các tính năng kỹ thuật như độ ổn định, hiệu suất và khả năng tiếp cận các trình xác thực nhỏ hơn cũng như những thay đổi về mặt kinh tế để giải quyết rủi ro tập trung hóa. Cái trước đảm nhận danh hiệu "Hợp nhất", trong khi cái sau trở thành một phần của "The Scourge".
Bài viết này sẽ tập trung vào phần "sáp nhập": Những gì khác có thể được cải thiện trong thiết kế kỹ thuật của Bằng chứng cổ phần, và những cách để đạt được những cải tiến này là gì?
Đây không phải là danh sách đầy đủ các cải tiến có thể được thực hiện đối với Bằng chứng cổ phần; đúng hơn, đây là danh sách các ý tưởng đang được tích cực xem xét.
Tính cuối cùng của một khe và dân chủ hóa đặt cược
Chúng ta đang giải quyết vấn đề gì?
Ngày nay, phải mất 2-3 kỷ nguyên (~15 phút) để hoàn thành một khối và cần 32 ETH để trở thành người đặt cọc. Đây ban đầu là một sự thỏa hiệp nhằm đạt được sự cân bằng giữa ba mục tiêu:
· Tối đa hóa số lượng người xác thực có thể tham gia đặt cược (điều này trực tiếp có nghĩa là giảm thiểu số ETH tối thiểu cần thiết để đặt cược)
· Giảm thiểu thời gian hoàn thành
· Giảm thiểu chi phí của nút đang chạy
Ba mục tiêu này xung đột với nhau: để đạt được mục đích kinh tế cuối cùng (tức là kẻ tấn công cần phải đốt lượng lớn ETH để khôi phục khối cuối cùng), mỗi người xác thực cần ký hai tin nhắn lần khi hoàn tất. Vì vậy, nếu bạn có nhiều trình xác thực, sẽ mất nhiều thời gian để xử lý tất cả chữ ký hoặc bạn sẽ cần nút rất mạnh để xử lý tất cả chữ ký cùng một lúc.
Lưu ý rằng tất cả điều này đều xoay quanh một mục tiêu chính của Ethereum: đảm bảo rằng ngay cả một cuộc tấn công thành công cũng phải trả giá đắt cho kẻ tấn công. Đây chính là ý nghĩa của thuật ngữ “mục đích kinh tế”. Nếu chúng ta không có mục tiêu này thì chúng ta có thể giải quyết vấn đề này bằng cách chọn ngẫu nhiên một ủy ban (chẳng hạn như Algorand ) để hoàn thiện từng vị trí. Nhưng vấn đề với phương pháp này là nếu kẻ tấn công kiểm soát 51% số người xác thực, chúng có thể tấn công với chi phí rất thấp (khôi phục các khối đã hoàn thiện, kiểm duyệt hoặc trì hoãn việc hoàn thiện): chỉ một phần của ủy ban có thể được phát hiện nút tham gia trong các cuộc tấn công và bị trừng phạt, bằng cách chém hoặc một số soft fork . Điều này có nghĩa là kẻ tấn công có thể liên tục tấn công Chuỗi lần . Vì vậy, nếu chúng ta muốn đạt được mục tiêu cuối cùng về mặt kinh tế, phương pháp đơn giản dựa trên ủy ban sẽ không hiệu quả và thoạt nhìn, chúng ta cần một bộ đầy đủ những người xác nhận để tham gia.
Lý tưởng nhất là chúng ta muốn duy trì mục tiêu kinh tế trong khi cải thiện hiện trạng theo hai cách:
· Chấm dứt các khối trong một khoảng thời gian (lý tưởng nhất là duy trì hoặc thậm chí giảm thời lượng hiện tại là 12 giây) thay vì 15 phút
· Cho phép người xác thực đặt cược 1 ETH (giảm từ 32 ETH xuống 1 ETH)
Mục tiêu đầu tiên được chứng minh bằng hai mục tiêu, cả hai đều có thể được coi là “điều chỉnh các thuộc tính của Ethereum với các thuộc tính của Chuỗi L1 tập trung vào hiệu suất (tập trung hơn)”.
Đầu tiên, nó đảm bảo rằng tất cả người dùng Ethereum đều được hưởng lợi từ mức độ bảo mật cao hơn đạt được thông qua cơ chế quyết toán. Ngày nay, hầu hết người dùng không được hưởng sự đảm bảo này vì họ không muốn đợi 15 phút; với cơ chế quyết toán một khe, người dùng có thể thấy giao dịch được hoàn tất gần như ngay lập tức sau khi giao dịch được xác nhận. Thứ hai, nó đơn giản hóa giao thức và cơ sở hạ tầng xung quanh nếu người dùng và ứng dụng không phải lo lắng về khả năng khôi phục Chuỗi(ngăn chặn trường hợp rò rỉ không hoạt động tương đối hiếm gặp).
Mục tiêu thứ hai được thúc đẩy bởi mong muốn hỗ trợ các cá nhân đóng góp. Cuộc thăm dò này đến cuộc thăm dò khác đã nhiều lần chỉ ra rằng yếu tố chính ngăn cản nhiều người đặt cọc hơn là mức tối thiểu 32 ETH. Việc giảm mức tối thiểu xuống 1 ETH sẽ giải quyết vấn đề này đến mức các vấn đề khác trở thành yếu tố chính hạn chế việc đặt cược của từng cá nhân.
Có một thách thức: các mục tiêu về tính cuối cùng nhanh hơn và đặt cược dân chủ hơn đều xung đột với mục tiêu giảm thiểu chi phí. Trên thực tế, đây chính là toàn bộ lý do tại sao chúng ta không áp dụng thuyết tất định vị trí đơn ngay từ đầu. Tuy nhiên, nghiên cứu gần đây cho thấy một số phương pháp khả thi cho vấn đề này.
Nó là gì và nó hoạt động như thế nào?
Tính hữu hạn của một vị trí liên quan đến việc sử dụng thuật toán đồng thuận để hoàn thiện các khối trong một vị trí. Bản thân đây không phải là một mục tiêu không thể đạt được: nhiều thuật toán (chẳng hạn như sự đồng thuận của Tendermint) đã đạt được mục tiêu này với các đặc tính tối ưu. Một đặc tính mong muốn duy nhất của Ethereum là rò rỉ không hoạt động không được Tendermint hỗ trợ, cho phép Chuỗi tiếp tục hoạt động và cuối cùng phục hồi ngay cả khi hơn 1/3 số trình xác thực ngoại tuyến. May mắn thay, mong muốn này đã được thực hiện: đã có Đề án sửa đổi cơ chế đồng thuận kiểu Tendermint để giải quyết các rò rỉ không hoạt động.
Phần khó nhất của vấn đề là tìm ra cách làm cho tính hữu hạn của một vị trí hoạt động với số lượng trình xác thực rất cao mà không phải chịu chi phí vận hành nút cực cao. Có một số giải pháp hàng đầu cho việc này:
Tùy chọn 1: Brute Force - Hướng tới giao thức tổng hợp chữ ký tốt hơn, có thể sử dụng ZK-SNARK, về cơ bản sẽ cho phép chúng tôi xử lý chữ ký từ hàng triệu trình xác thực trên mỗi vị trí.
Horn, một trong những thiết kế được đề xuất cho các giao thức tổng hợp tốt hơn.
Tùy chọn 2: Ủy ban quỹ đạo - Một cơ chế mới cho phép một ủy ban cỡ trung bình được chọn ngẫu nhiên chịu trách nhiệm hoàn thiện Chuỗi, nhưng theo cách duy trì các thuộc tính chi phí tấn công mà chúng tôi đang tìm kiếm.
Một phương pháp để nghĩ về Orbit SSF là nó mở ra một không gian có nhiều lựa chọn thỏa hiệp, từ x=0 ( ủy ban kiểu Algorand , không có quyết định cuối cùng về kinh tế) đến x=1 ( hiện trạng Ethereum), mở ra một điểm ở giữa , Ethereum Vẫn còn đủ khả năng kinh tế cuối cùng để đạt được mức độ bảo mật cao nhất, nhưng đồng thời chúng tôi đạt được lợi thế về hiệu quả khi chỉ yêu cầu một mẫu trình xác thực ngẫu nhiên có quy mô vừa phải để tham gia vào mỗi kỷ nguyên.
Orbit tận dụng tính không đồng nhất tồn tại từ trước về quy mô tiền gửi của trình xác nhận để đạt được mục đích kinh tế tối đa nhất có thể, trong khi vẫn trao cho các trình xác nhận nhỏ một nhân vật phù hợp. Ngoài ra, Orbit sử dụng sự luân chuyển chậm của ủy ban để đảm bảo mức độ trùng lặp cao giữa các nhóm túc số liền kề, đảm bảo rằng tính hữu hạn về mặt kinh tế của nó vẫn áp dụng cho ranh giới luân chuyển của ủy ban.
Tùy chọn 3: Đặt cược hai cấp - Một cơ chế trong đó người đặt cược được chia thành hai loại, một loại có yêu cầu tiền gửi cao hơn và loại còn lại có yêu cầu tiền gửi thấp hơn. Chỉ những cấp độ có yêu cầu tiền gửi cao hơn mới tham gia trực tiếp vào việc cung cấp mục đích kinh tế cuối cùng. Có nhiều Đề án khác nhau về quyền và trách nhiệm chính xác của các cấp độ có yêu cầu tiền gửi thấp hơn sẽ là gì (ví dụ: xem bài đăng đặt cược Rainbow). Những ý tưởng phổ biến bao gồm:
· Quyền ủy quyền cho người nắm giữ cấp cao hơn
· Người nắm giữ cổ phần cấp thấp hơn được lựa chọn ngẫu nhiên được chứng thực và yêu cầu hoàn thành từng khối
· Quyền tạo danh sách bao gồm
Các kết nối với nghiên cứu hiện tại là gì?
· Con đường dẫn đến tính hữu hạn của một khe cắm (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality
· Đề án cụ thể cho giao thức cuối cùng một khe Ethereum (2023): https://eprint.iacr.org/2023/280
· Quỹ đạo SSF: Staking
· Phân tích sâu hơn về cơ chế kiểu quỹ đạo: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF
· Horn, Giao thức tổng hợp chữ ký (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219
· Hợp nhất chữ ký để đồng thuận quy mô lớn (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn
· Giao thức tổng hợp chữ ký do Khovratovich và cộng sự đề xuất: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/
· Tổng hợp chữ ký dựa trên STARK (2022): https://hackmd.io/@vbuterin/stark_aggregationRainbow
· Staking : Staking
Còn lại gì để làm? Sự đánh đổi là gì?
Có bốn đường dẫn chính có thể (chúng ta cũng có thể sử dụng các đường dẫn kết hợp):
· Giữ nguyên hiện trạng
·Quỹ đạo SSF
· SSF mạnh mẽ
· SSF với hai cấp độ đặt cược
(1) có nghĩa là không làm việc gì và tiếp tục đặt cược như hiện tại, nhưng điều này sẽ làm cho trải nghiệm bảo mật và các thuộc tính tập trung đặt cược của Ethereum trở nên tồi tệ hơn so với bình thường.
(2) Tránh "công nghệ cao" và giải quyết vấn đề bằng cách khéo léo suy nghĩ lại các giả định về giao thức: chúng tôi nới lỏng yêu cầu về "tính cuối cùng về kinh tế" để yêu cầu chi phí tấn công cao, nhưng chấp nhận rằng chi phí tấn công có thể thấp hơn 10 lần hơn hiện tại (Ví dụ: chi phí của cuộc tấn công là 2,5 tỷ USD chứ không phải 25 tỷ USD). Người ta cho rằng rằng Ethereum ngày nay có tính hữu hạn về kinh tế cao hơn nhiều so với mức cần thiết và rủi ro bảo mật chính của nó nằm ở chỗ khác, vì vậy đây được cho là một sự hy sinh có thể chấp nhận được.
Công việc chính là xác minh rằng cơ chế Orbit an toàn và có các thuộc tính mà chúng ta mong muốn, sau đó chính thức hóa và triển khai nó một cách đầy đủ. Ngoài ra, EIP-7251 (Tăng số dư hợp lệ tối đa) cho phép hợp nhất số dư của người xác thực tự nguyện, giúp giảm ngay chi phí xác minh Chuỗi và đóng vai trò là giai đoạn ban đầu hiệu quả cho việc triển khai Orbit.
(3) Tránh suy nghĩ lại một khéo léo và thay vào đó là những vấn đề mang tính vũ phu với công nghệ cao. Làm điều này đòi hỏi phải thu thập lượng lớn chữ ký (1 triệu+) trong thời gian rất ngắn (5-10 giây).
(4) Tránh suy nghĩ lại khéo léo và công nghệ cao, nhưng nó tạo ra một hệ thống đặt cược hai tầng vẫn có rủi ro tập trung. Rủi ro phụ thuộc rất nhiều vào các quyền cụ thể mà các cấp đặt cược thấp hơn có được. Ví dụ:
Nếu những người đặt cược cấp thấp hơn cần ủy quyền quyền chứng thực của họ cho những người đặt cược cấp cao hơn thì việc ủy quyền có thể trở nên tập trung và chúng ta sẽ có hai cấp độ đặt cược tập trung cao độ. Nếu cần lấy mẫu ngẫu nhiên ở các cấp độ thấp hơn để phê duyệt từng khối, kẻ tấn công có thể chi một lượng ETH nhỏ để ngăn chặn tính hữu hạn. Nếu những người đặt cược cấp thấp chỉ có thể tạo ra danh sách bao gồm, thì lớp bằng chứng có thể vẫn được tập trung, tại thời điểm đó, một cuộc tấn công 51% vào lớp bằng chứng có thể kiểm duyệt chính danh sách bao gồm.
Nhiều chiến lược có thể được kết hợp, chẳng hạn như:
· (1 + 2): Thêm quỹ đạo mà không thực hiện tính toán cuối cùng của một khe.
· (1 + 3): Sử dụng các kỹ thuật vũ lực để giảm kích thước tiền gửi tối thiểu mà không thực thi tính chính xác cuối cùng của một khe. Lượng trùng hợp cần thiết ít hơn 64 lần so với trường hợp (3) nguyên chất nên bài toán trở nên dễ dàng hơn.
· (2 + 3): Thực thi Orbit SSF với các tham số thận trọng (ví dụ: ủy ban xác thực 128k thay vì 8k hoặc 32k) và sử dụng các kỹ thuật vũ lực để làm cho nó siêu hiệu quả.
· (1 + 4): Thêm đặt cược cầu vồng mà không thực thi tính hữu hạn của một khe duy nhất.
Nó tương tác với các phần khác của lộ trình như thế nào?
Trong số các lợi ích khác, tính hữu hạn của một khe giúp giảm rủi ro xảy ra một số loại tấn công MEV đa khối. Hơn nữa, trong thế giới hữu hạn một khe, thiết kế tách biệt người chứng minh-người đề xuất và các quy trình sản xuất khối nội giao thức khác cần phải được thiết kế khác nhau.
Điểm yếu của chiến lược vũ phu là chúng khiến việc rút ngắn thời gian đánh bạc trở nên khó khăn hơn.
Bầu cử lãnh đạo bí mật duy nhất
Chúng ta đang cố gắng giải quyết vấn đề gì?
Hôm nay, người xác nhận nào sẽ đề xuất khối tiếp theo đã được biết trước. Điều này tạo ra lỗ hổng bảo mật: kẻ tấn công có thể giám sát mạng, xác định trình xác thực nào tương ứng với địa chỉ IP nào và khởi động một cuộc tấn công DoS vào trình xác thực khi chúng chuẩn bị đề xuất chặn.
nó là gì vậy? Nó hoạt động như thế nào?
Phương pháp tốt nhất để giải quyết vấn đề DoS là ẩn thông tin về trình xác thực nào sẽ tạo khối tiếp theo, ít nhất là cho đến khi khối đó thực sự được tạo. Lưu ý rằng điều này thật dễ dàng nếu chúng ta loại bỏ yêu cầu "duy nhất": một giải pháp là cho phép bất kỳ ai tạo khối tiếp theo, nhưng yêu cầu randao tiết lộ ít hơn 2256/N. Trung bình, chỉ có một trình xác nhận đáp ứng yêu cầu này - nhưng đôi khi có hai hoặc nhiều hơn và đôi khi không có. Việc kết hợp yêu cầu “bảo mật” với yêu cầu “đoàn kết” luôn là một bài toán khó.
Giao thức bầu cử người lãnh đạo bí mật duy nhất giải quyết vấn đề này bằng cách sử dụng một số kỹ thuật crypto để tạo ID người xác thực "mù" cho mỗi người xác thực, sau đó tạo cơ hội cho nhiều người đề xuất xáo trộn và làm mù lại nhóm ID mù (điều này tương tự như Cách mạng lai hoạt động). Ở mỗi thời kỳ, một ID mù ngẫu nhiên được chọn. Chỉ chủ sở hữu ID mù mới có thể tạo bằng chứng hợp lệ để đề xuất chặn, nhưng không ai biết ID mù tương ứng với trình xác thực nào.
Một số liên kết đến nghiên cứu hiện có là gì?
· Bài viết của Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
· Whisk (một Đề án thiết thực cho Ethereum , 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
· Thẻ bầu cử lãnh đạo bí mật duy nhất trên ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
· SSLE đơn giản hóa sử dụng chữ ký vòng: https://ethresear.ch/t/simplified-ssle/12315
Còn lại gì để làm? Sự đánh đổi là gì?
Thực sự, tất cả những gì còn lại là tìm và triển khai một giao thức đủ đơn giản để chúng ta có thể dễ dàng triển khai nó trên mạng chính. Chúng tôi rất coi trọng Ethereum như một giao thức khá đơn giản và chúng tôi không muốn độ phức tạp tăng thêm. Việc triển khai SSLE mà chúng tôi đã thấy đã bổ sung thêm hàng trăm dòng mã đặc tả và đưa ra các giả định mới về crypto phức tạp . Việc tìm kiếm một triển khai SSLE kháng lượng tử đủ hiệu quả cũng là một vấn đề mở.
Cuối cùng có thể xảy ra rằng "độ phức tạp bổ sung cận biên" của SSLE sẽ chỉ giảm khi chúng tôi giới thiệu cơ chế Bằng chứng không tri thức chung trên L1 của giao thức Ethereum vì các lý do khác (ví dụ: cây trạng thái, ZK-EVM) ở mức đủ thấp.
Một tùy chọn khác là bỏ qua SSLE và sử dụng các biện pháp giảm nhẹ ngoài giao thức (chẳng hạn như ở lớp p2p) để giải quyết các vấn đề DoS.
Nó tương tác với các phần khác của lộ trình như thế nào?
Nếu chúng tôi thêm cơ chế phân tách người chứng minh-người đề xuất (APS), chẳng hạn như vé thực thi, thì SSLE sẽ không cần thiết để thực thi các khối (tức là các khối chứa giao dịch Ethereum) vì chúng tôi có thể dựa vào các nhà xây dựng khối chuyên dụng. Tuy nhiên, đối với các khối đồng thuận (tức là các khối chứa thông báo giao thức (ví dụ: bằng chứng, có thể là một phần của danh sách, v.v.)), chúng tôi vẫn sẽ được hưởng lợi từ SSLE.
Xác nhận giao dịch nhanh hơn
Chúng ta đang giải quyết vấn đề gì?
Có giá trị trong việc Ethereum giảm thêm thời gian xác nhận giao dịch, từ 12 giây xuống còn 4 giây. Làm như vậy sẽ cải thiện đáng kể trải nghiệm người dùng dựa trên L1 và tổng hợp đồng thời làm cho giao thức defi hiệu quả hơn. Nó cũng sẽ giúp L2 phi tập trung dễ dàng hơn vì nó sẽ cho phép lượng lớn ứng dụng L2 hoạt động theo thứ tự dựa trên tổng hợp, do đó giảm nhu cầu L2 xây dựng sắp xếp phi tập trung dựa trên ủy ban của riêng mình.
nó là gì vậy? Nó hoạt động như thế nào?
Có khoảng hai kỹ thuật ở đây:
· Giảm thời gian đánh bạc, ví dụ xuống còn 8 giây hoặc 4 giây. Điều này không nhất thiết có nghĩa là 4 giây cuối cùng: về cơ bản, về cơ bản yêu cầu ba vòng liên lạc, vì vậy chúng tôi có thể biến mỗi vòng liên lạc thành một khối riêng biệt, với ít nhất xác nhận sơ bộ sau 4 giây.
· Cho phép người đề xuất đưa ra xác nhận trước trong thời gian trống. Trong trường hợp đặc biệt, người đề xuất có thể kết hợp các giao dịch mà họ nhìn thấy vào khối của mình trong thời gian thực và ngay lập tức xuất bản thông báo xác nhận trước cho mỗi giao dịch ("Giao dịch đầu tiên của tôi là 0x1234...", "Tôi Giao dịch thứ hai là 0x5678. ..).). Tình huống người đề xuất đưa ra hai xác nhận trái ngược nhau có thể được xử lý theo hai cách: (i) chém người đề xuất, hoặc (ii) dùng người chứng minh để bình chọn xem ai đến sớm hơn.
Một số liên kết đến nghiên cứu hiện có là gì?
· Dựa trên các xác nhận trước: https://ethresear.ch/t/based-preconfirmations/17353
· Cam kết của người đề xuất được thực thi theo giao thức (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
· Khoảng thời gian so le trên Chuỗi song song (ý tưởng để đạt được độ trễ thấp vào năm 2018): https://ethresear.ch/t/staggered- Periods/1793
Những gì còn lại phải làm và sự đánh đổi là gì?
Không rõ việc giảm thời gian đánh bạc sẽ thực tế đến mức nào. Thậm chí ngày nay, những người đặt cược ở nhiều nơi trên thế giới vẫn phải vật lộn để có được bằng chứng đủ nhanh. Việc cố gắng dành khoảng thời gian 4 giây rủi ro tập trung bộ trình xác thực và khiến việc trở thành trình xác thực bên ngoài một số khu vực đặc quyền là không thực tế do độ trễ.
Điểm yếu của phương pháp xác nhận trước người đề xuất là nó cải thiện đáng kể thời gian đưa vào trường hợp trung bình, nhưng không phải là thời gian đưa vào trường hợp xấu nhất: nếu người đề xuất hiện tại đang chạy tốt, giao dịch của bạn sẽ được xác nhận trước sau 0,5 giây, trong khi đó thì không (trung bình) Sẽ có 6 giây, nhưng nếu người đề xuất hiện tại ngoại tuyến hoặc hoạt động không tốt, bạn vẫn phải đợi đủ 12 giây trước khi vị trí tiếp theo có thể bắt đầu và cung cấp người đề xuất mới.
Ngoài ra, còn có câu hỏi mở về cách khích lệ việc xác nhận trước. Những người đề xuất có động cơ để tối đa hóa khả năng lựa chọn của họ càng lâu càng tốt. Nếu người chứng minh ký xác nhận trước kịp thời thì người gửi giao dịch có thể đưa ra một phần phí cho việc xác nhận trước ngay lập tức, nhưng điều này sẽ tạo thêm gánh nặng cho người chứng minh và có thể khiến người chứng minh gặp khó khăn hơn trong việc tiếp tục hoạt động như một "ống câm" trung lập.
Mặt khác, nếu chúng ta không cố gắng thực hiện điều này và giữ thời gian hoàn thiện ở mức 12 giây (hoặc lâu hơn), hệ sinh thái sẽ chú trọng hơn vào cơ chế xác nhận trước do Lớp 2 ban hành và các tương tác giữa Lớp 2 sẽ diễn ra. thời gian lâu hơn.
Nó tương tác với các phần khác của lộ trình như thế nào?
Xác nhận trước dựa trên người đề xuất thực sự dựa vào các cơ chế phân tách người chứng minh-người đề xuất (APS), chẳng hạn như phiếu thực hiện. Mặt khác, áp lực cung cấp xác nhận trước theo thời gian thực có thể tạo ra áp lực quá tập trung lên những người xác nhận thông thường.
Các lĩnh vực nghiên cứu khác
Phục hồi tấn công 51%
Người ta thường cho rằng rằng trong trường hợp xảy ra cuộc tấn công 51% (bao gồm các cuộc tấn công không thể được chứng minh crypto, chẳng hạn như kiểm duyệt), cộng đồng sẽ cùng nhau thực hiện một soft fork thiểu số, đảm bảo rằng người tốt giành chiến thắng và kẻ xấu bị loại. bị rò rỉ hoặc bị cắt bớt do không hoạt động. Tuy nhiên, mức độ phụ thuộc quá mức vào tầng lớp xã hội này được cho là không lành mạnh. Chúng ta có thể cố gắng giảm sự phụ thuộc vào tầng xã hội và làm cho quá trình phục hồi trở nên tự động nhất có thể.
Không thể tự động hóa hoàn toàn vì nếu đúng như vậy thì thuật toán này sẽ được tính là thuật toán đồng thuận có khả năng chịu lỗi >50% và chúng tôi đã biết những hạn chế (rất nghiêm ngặt) có thể chứng minh được về mặt toán học của các thuật toán đó. Nhưng chúng ta có thể đạt được tự động hóa một phần: ví dụ: máy trạm có thể tự động từ chối chấp nhận Chuỗi là cuối cùng hoặc thậm chí từ chối chấp nhận chuỗi đó với tư cách là người đứng đầu lựa chọn fork , nếu máy trạm đã xem xét giao dịch mà máy trạm đã xem từ lâu đủ. Mục tiêu chính là đảm bảo rằng kẻ xấu trong cuộc tấn công ít nhất không giành được chiến thắng nhanh chóng.
Tăng ngưỡng đại biểu
Hôm nay, nếu 67% người đặt cược ủng hộ nó, khối sẽ được hoàn thiện. Một số người cho rằng điều này quá cực đoan. Trong toàn bộ lịch sử của Ethereum , chỉ có một thất bại cuối cùng (rất ngắn). Nếu tỷ lệ phần trăm này tăng lên 80%, số lượng kỷ nguyên không có tính hữu hạn tăng lên sẽ tương đối thấp, nhưng Ethereum sẽ đạt được tính bảo mật: đặc biệt, nhiều tình huống gây tranh cãi hơn sẽ dẫn đến việc tạm thời đình chỉ tính hữu hạn. Điều này có vẻ lành mạnh hơn nhiều so với việc "nhầm bên" giành chiến thắng ngay lập tức, cho dù bên sai là kẻ tấn công hay có lỗi máy trạm.
Điều này cũng trả lời câu hỏi "Mục đích của một người đặt cược riêng biệt là gì?" Ngày nay, hầu hết những người đặt cược đều đã đặt cược thông qua các nhóm và có vẻ như không có một người đặt cược nào sẽ nhận được tới 51% số ETH đặt cược. Tuy nhiên, việc khiến một người đặt cược solo tiếp cận được thiểu số chặn đa số dường như có thể thực hiện được nếu chúng ta làm việc chăm chỉ, đặc biệt nếu đa số đạt 80% (vì vậy chỉ cần 21% để chặn đa số). Miễn là những người đặt cược đơn độc không tham gia vào cuộc tấn công 51% (dù là đảo ngược hay xem xét cuối cùng), cuộc tấn công này sẽ không đạt được "chiến thắng rõ ràng" và những người đặt cược đơn độc sẽ tích cực giúp tổ chức soft fork thiểu số.
Kháng lượng tử
Metaculus hiện cho rằng, mặc dù có sai số lớn, nhưng máy tính lượng tử có thể sẽ bắt đầu phá vỡ mật mã vào khoảng những năm 2030:
Các chuyên gia điện toán lượng tử, chẳng hạn như Scott Aaronson, gần đây cũng đã bắt đầu xem xét nghiêm túc hơn khả năng máy tính lượng tử sẽ thực sự hoạt động trong trung hạn. Điều này có ý nghĩa đối với toàn bộ lộ trình Ethereum: nó có nghĩa là mọi phần của giao thức Ethereum hiện dựa trên các đường cong elip sẽ cần một số loại giải pháp thay thế dựa trên hàm băm hoặc kháng lượng tử khác. Đặc biệt, điều này có nghĩa là chúng ta không thể cho rằng chúng ta sẽ có thể dựa vào các thuộc tính ưu việt của tập hợp BLS để xử lý chữ ký từ các bộ xác thực lớn. Điều này Bằng chứng cổ phần chủ nghĩa bảo thủ trong các giả định về hiệu suất của thiết kế bằng chứng cổ phần và là lý do để phát triển mạnh mẽ hơn các giải pháp thay thế kháng lượng tử.
Chào mừng bạn tham gia cộng đồng chính thức BlockBeats BlockBeats:
Nhóm đăng ký Telegram: https://t.me/theblockbeats
Nhóm liên lạc Telegram: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
