Được viết bởi: Vitalik Buterin

Biên soạn bởi: Alex Liu, Tin tức tầm nhìn xa

Đặc biệt cảm ơn Justin Drake, Hsiao-wei Wang, @antanttc, Anders Elowsson và Francesco vì phản hồi và đánh giá của họ.

Ban đầu, “sự hợp nhất” đề cập đến sự kiện quan trọng nhất trong lịch sử của giao thức Ethereum kể từ khi ra mắt: quá trình chuyển đổi được chờ đợi từ lâu và khó khăn mới đạt được từ Proof of Work (PoW) sang Proof of Stake (PoS). Ngày nay, Ethereum đã là một hệ thống bằng chứng cổ phần ổn định và hoạt động được gần hai năm và hệ thống bằng chứng cổ phần này đã 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 về cổ phần cần được cải thiện.

Lộ trình năm 2023 của tôi 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 truy cập cho các trình xác thực nhỏ, cũng như những thay đổi kinh tế nhằm giải quyết các rủi ro của việc tập trung hóa. Cái trước lấy danh hiệu "Hợp nhất" và cái sau trở thành một phần của "Tai họa".

Bài viết này sẽ tập trung vào phần “Hợp nhất”: Thiết kế kỹ thuật của Proof of Stake có thể được cải thiện ở đâu và những cách nào để đạt được mục tiêu này?

Đây không phải là danh sách đầy đủ những điều mà bằng chứng cổ phần có thể làm; đú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 cố gắng 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. Điều này bắt đầu như một sự thỏa hiệp để cân bằng ba mục tiêu :

Ba mục tiêu này xung đột với nhau: để đạt được mục đích kinh tế cuối cùng (có nghĩa là: kẻ tấn công sẽ cần đốt rất nhiều ETH để đảo ngược khối cuối cùng), bạn cần mọi người xác nhận mỗi khi quá trình hoàn tất xảy ra Ký cả hai tin nhắn. Vì vậy, nếu bạn có nhiều trình xác thực, bạn cần nhiều thời gian để xử lý tất cả chữ ký của họ hoặc bạn cần các nút rất mạnh để xử lý tất cả chữ ký cùng một lúc.

Ba mục tiêu này xung đột với nhau: để đạt được mục tiêu kinh tế cuối cùng (có nghĩa là: kẻ tấn công sẽ cần đốt rất nhiều ETH để đảo ngược khối cuối cùng), bạn cần mọi người xác thực mỗi khi quá trình hoàn tất xảy ra Ký cả hai tin nhắn. Vì vậy, nếu bạn có nhiều trình xác thực, bạn cần nhiều thời gian để xử lý tất cả chữ ký của họ hoặc bạn cần các nút rất mạnh để xử lý tất cả chữ ký cùng một lúc.

Ba mục tiêu này xung đột với nhau: để đạt được mục tiêu kinh tế cuối cùng (có nghĩa là: kẻ tấn công sẽ cần đốt nhiều ETH để giả mạo các khối cuối cùng), bạn cần mọi trình xác thực mỗi khi quá trình hoàn thiện xảy ra Ký cả hai tin nhắn. Vì vậy, nếu bạn có nhiều trình xác thực, bạn cần nhiều thời gian để xử lý tất cả chữ ký của họ hoặc bạn cần các 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 có điều kiện dựa trên mục tiêu chính của Ethereum: đảm bảo rằng ngay cả các cuộc tấn công thành công cũng gây ra chi phí cao 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 để hoàn thiện từng khối. Những chuỗi không cố gắng đạt được mục tiêu kinh tế cuối cùng, chẳng hạn như Algorand, thường chỉ làm được điều đó . Nhưng vấn đề với cách tiếp cận này là nếu kẻ tấn công kiểm soát 51% trình xác thực thì chúng có thể thực hiện cuộc tấn công (khôi phục các khối cuối cùng, kiểm duyệt hoặc trì hoãn việc hoàn thiện) với chi phí rất thấp: chỉ cần kiểm soát các nút của chúng, một số nút trong . Trong ủy ban, một người có thể bị phát hiện vì tham gia vào một cuộc tấn công và bị trừng phạt, cho dù thông qua việc chém hoặc một soft fork phối hợp xã hội . Đ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 nhiều lần, chỉ mất một phần nhỏ cổ phần trong mỗi lần tấn công. Do đó, nếu chúng ta muốn đạt được mục đích kinh tế cuối cùng, cách tiếp cận đơ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 có sự tham gia đầy đủ của người xác nhận.

Lý tưởng nhất là chúng ta muốn duy trì mục tiêu kinh tế đồng thời cải thiện hiện trạng ở hai lĩnh vực:

Mục tiêu đầu tiên có hai mục tiêu, cả hai đều có thể được xem 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 thực sự được hưởng lợi từ mức độ đảm bảo bảo mật cao hơn đạt được thông qua cơ chế cuối cùng. Ngày nay, hầu hết người dùng không làm điều này vì họ không muốn đợi 15 phút; với việc hoàn tất một khe, người dùng sẽ thấy giao dịch của họ gần như hoàn tất ngay 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 đảo ngược chuỗi (ngoại trừ trường hợp rò rỉ không hoạt động tương đối hiếm).

Mục tiêu thứ hai là do mong muốn hỗ trợ các staker solo. Cuộc thăm dò này đến cuộc thăm dò khác liên tục cho thấy 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 được vấn đề này và các vấn đề khác sẽ trở thành yếu tố chi phối hạn chế việc đặt cược của từng cá nhân.

Mục tiêu thứ hai là do mong muốn hỗ trợ các staker solo. Cuộc thăm dò này đến cuộc thăm dò khác liên tục cho thấy 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 được vấn đề này và các vấn đề khác sẽ trở thành yếu tố chi phối hạn chế việc đặt cược của từng cá nhân.

Có một thách thức: cả hai mục tiêu hoàn thiện 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ế, thực tế này là toàn bộ lý do khiến chúng tôi không bắt đầu với tính hữu hạn của một vị trí. Tuy nhiên, nghiên cứu gần đây cho thấy một số cách khả thi để giải quyết 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ó khăn: 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. Một thuộc tính bắt buộc duy nhất đối với Ethereum mà Tendermint không hỗ trợ là rò rỉ không hoạt động , cho phép chuỗi tiếp tục chạy 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, điều này đã được giải quyết: đã có đề xuất sửa đổi cơ chế đồng thuận kiểu Tendermint để khắc phục tình trạng rò rỉ không hoạt động.

Đề xuất cuối cùng về một vị trí dẫn đầu

Phần khó hơn 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:

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 các ủy ban cỡ trung được lựa 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 cách để nghĩ về Orbit SSF là nó mở ra một không gian thỏa hiệp giữa hai lựa chọn, 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 của Ethereum), với thứ gì đó ở giữa “Ethereum vẫn có đủ tính hữu hạn về kinh tế để rất an toàn, nhưng đồng thời chúng tôi chỉ cần một mẫu trình xác nhận ngẫu nhiên có quy mô vừa phải để tham gia vào từng vị trí nhằm đạt được lợi thế về hiệu quả.”

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 vai trò cho các trình xác nhận nhỏ. Ngoài ra, Orbit sử dụng tốc độ luân chuyển ủy ban chậm để đảm bảo mức độ chồng chéo cao giữa các đại biểu liền kề, do đó đảm bảo rằng mục đích kinh tế của nó vẫn nằm trong giới hạn chuyển đổi ủy ban.

Các kết nối với nghiên cứu hiện tại là gì?

Cần phải làm gì nữa, cần phải đánh đổi những gì?

Có bốn con đường chính có thể lựa chọn (chúng ta cũng có thể chọn con đường kết hợp):

(1) có nghĩa là không làm gì và để nguyên như vậy, 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.

(2) Sử dụng công nghệ tiên tiến để giải quyết vấn đề một cách bạo lực. Để đạt được điều này, cần phải tổng hợp một số lượng lớn chữ ký (1 triệu+) trong thời gian rất ngắn (5-10 giây). Một cách để nghĩ về cách tiếp cận này là nó liên quan đến việc giảm thiểu độ phức tạp của hệ thống bằng cách chấp nhận hoàn toàn sự phức tạp của việc đóng gói .

(3) Tránh "các kỹ thuật tiên tiến" và giải quyết vấn đề bằng cách suy nghĩ lại một cách thông minh xung quanh 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ế" để theo đuổi việc thực hiện các cuộc tấn công tốn kém, nhưng chấp nhận rằng chi phí của các cuộc tấn công có thể thấp hơn chi phí hiện nay gấp 10 lần của cuộc tấn công (ví dụ: cuộc tấn công tiêu tốn 2,5 tỷ USD thay vì 25 tỷ USD). Người ta thường chấp nhận 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 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ư hiệu quả tối đa) cho phép hợp nhất số dư của người xác thực tự nguyện, điều này ngay lập tức giảm chi phí xác minh chuỗi ở một mức độ nào đó và đóng vai trò hiệu quả như giai đoạn đầu trong quá trình triển khai Orbit.

(4) Nó tránh sự phản ánh thông minh và công nghệ tiên tiến, nhưng nó tạo ra một hệ thống đặt cược hai cấp vẫn có nguy cơ tập trung hóa. Rủi ro phụ thuộc phần lớn vào các quyền cụ thể có được ở mức đặt cược thấp hơn. Ví dụ:

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 cần hoàn thiện một vị trí

(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 cần hoàn tất một vị trí. 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): Sử dụng các tham số thận trọng (chẳng hạn như ủy ban xác thực 128k thay vì 8k hoặc 32k) cho Orbit SSF và sử dụng công nghệ để làm cho nó siêu hiệu quả.

(1 + 4): Thêm đặt cược cầu vồng mà không cần hoàn thiện một vị trí

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 nguy cơ xảy ra một số loại tấn công MEV đa khối nhất định . Hơn nữa, trong thế giới hữu hạn một khe, thiết kế phân tách người chứng minh-người đề xuất và các quy trình sản xuất khối trong giao thức khác yêu cầu các thiết kế khác nhau.

Điểm yếu của các chiến lược bạo lực là chúng khiến việc giảm 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 ( 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à tiến hành tấn công DoS trên mỗi trình xác thực khi trình xác thực chuẩn bị đề xuất một khối.

Nó là gì và nó hoạt động như thế nào?

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à thực hiện tấn công DoS trên mỗi trình xác thực khi trình xác thực chuẩn bị đề xuất một khối.

Nó là gì và nó hoạt động như thế nào?

Cách 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 "đơn": 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 Reveal nhỏ hơn 2 (256)/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 “thống nhất” luôn là bài toán khó.

Giao thức bầu cử thủ lĩnh 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 mã hóa để tạo ID trình xác thực "mù" cho mỗi trình xác thực và sau đó cung cấp cho nhiều người đề xuất cơ hội xáo trộn nhóm ID mù (tương tự như cách của mixnet ) hoạt động). Trong mỗi vị trí, một ID mù ngẫu nhiên được chọn. Chỉ chủ sở hữu ID bị ẩn mới có thể tạo bằng chứng hợp lệ để đề xuất khối, nhưng không ai khác biết ID bị ẩn tương ứng với trình xác thực nào.

Các kết nối với nghiên cứu hiện tại là gì?

Cần phải làm gì nữa, cần phải đánh đổi những 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 đánh giá cao 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ã chuẩn và đưa ra các giả định mới về mật mã phức tạp. Việc tìm kiếm các triển khai SSLE kháng lượng tử đủ hiệu quả cũng là một vấn đề mở.

Điều cuối cùng có thể xảy ra là một khi chúng tôi quyết tâm giới thiệu các cơ chế cho bằng chứng không có kiến ​​thức phổ quát trong giao thức Ethereum tại L1 (ví dụ: cây trạng thái, ZK-EVM) vì các lý do khác, độ phức tạp bổ sung do SSLE đưa ra sẽ giảm xuống mức thấp. đủ.

Một tùy chọn khác là hoàn toàn không xem xét SSLE và sử dụng các biện pháp giảm nhẹ ngoài giao thức (ví dụ: ở lớp p2p) để giải quyết 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?

Một tùy chọn khác là hoàn toàn không xem xét SSLE và sử dụng các biện pháp giảm nhẹ ngoài giao thức (ví dụ: ở lớp p2p) để giải quyết 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?

Ví dụ: nếu chúng ta thêm cơ chế phân tách người giới thiệu-người đề xuất (APS). vé thực thi , khi đó việc thực thi các khối (tức là các khối chứa giao dịch Ethereum) sẽ không yêu cầu SSLE 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, chúng tôi vẫn sẽ được hưởng lợi từ các khối đồng thuận của SSLE (tức là các khối chứa thông báo giao thức, chẳng hạn như chứng thực, có thể là các đoạn chứa danh sách, v.v.).

Xác nhận giao dịch nhanh hơn

Chúng ta đang cố gắng giải quyết vấn đề gì?

Sẽ rất có giá trị nếu giảm hơn nữa thời gian xác nhận giao dịch của Ethereum, chẳng hạn từ 12 giây xuống còn 4 giây. Làm như vậy sẽ cải thiện trải nghiệm người dùng của L1 và Bản tổng hợp dựa trên đồng thời làm cho giao thức defi hiệu quả hơn. Nó cũng sẽ giúp L2 phân cấp dễ dàng hơn vì nó sẽ cho phép một lớp lớn các ứng dụng L2 hoạt động trên Dựa trên Bản tổng hợp, do đó giảm nhu cầu L2 xây dựng trật tự phi tập trung dựa trên ủy ban của riêng mình.

Nó là gì và nó hoạt động như thế nào?

Giảm thời gian đánh bạc, chẳng hạn như 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 để hoàn tất: quá trình hoàn thiệ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, điều này ít nhất sẽ được xác nhận tạm thời sau 4 giây.

Cho phép người đề xuất đưa ra xác nhận trước trong quá trình chọn chỗ. Trong trường hợp cực đoan, người đề xuất có thể thêm các giao dịch mà họ thấy trong thời gian thực vào khối riêng của họ 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...", "Giao dịch thứ hai của tôi 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) sử dụng người chứng minh để bỏ phiếu cho xác nhận trước đó.

Các kết nối với nghiên cứu hiện tại là gì?

Cần phải làm gì nữa, cần phải đánh đổi những gì?

Không rõ liệu việc giảm thời gian đánh bạc có thực tế hay không. 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 thời gian 4 giây sẽ có nguy cơ tập trung vào 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 đã phát triển là không thực tế do độ trễ. Cụ thể, việc chuyển sang các khe thời gian 4 giây yêu cầu giảm giới hạn độ trễ mạng ("delta") xuống còn hai giây.

Nhược điểm 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 trong trường hợp trung bình, nhưng không phải trong 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 sẽ được xác nhận trước sau 0,5 giây thay vì 6 được bao gồm số giây (trung bình), 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 bắt đầu và người đề xuất mới được phân phát.

Hơn nữa, làm thế nào để khuyến khích việc xác nhận trước cũng là một câu hỏi mở. Những người đề xuất có động cơ để tối đa hóa các lựa chọn của họ càng lâu càng tốt. Nếu người chứng nhận ký xác nhận trước để đảm bảo tính kịp thời thì người gửi giao dịch có thể yêu cầu 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 thêm gánh nặng cho người chứng nhận và có thể gây khó khăn hơn cho người chứng nhận trong việc tiếp tục hoạt động với tư cách là "Ống câm" trung tính.

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 quyết toá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 của L2 và các tương tác giữa các L2 sẽ mất nhiều thời gian hơn.

Nó tương tác với các phần khác của lộ trình như thế nào?

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 quyết toá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 của L2 và các tương tác giữa các L2 sẽ mất nhiều thời gian 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 lên những người xác nhận thường xuyên để cung cấp xác nhận trước theo thời gian thực có thể quá tập trung.

Thời gian của vị trí có thể ngắn đến mức nào cũng phụ thuộc vào cấu trúc vị trí, điều này phụ thuộc phần lớn vào phiên bản APS mà cuối cùng chúng tôi triển khai, danh sách bao gồm, v.v. Một số cấu trúc khe chứa ít vòng hơn và do đó thân thiện hơn với thời gian khe ngắn, nhưng chúng có sự cân bằng ở những nơi khác.

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 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 bằng mật mã, chẳng hạn như kiểm duyệt), cộng đồng sẽ cùng nhau triển khai 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 nhận được. không hoạt động bị rò rỉ hoặc bị cắt. Tuy nhiên, việc phụ thuộc quá nhiều vào khía cạnh xã hội đượ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 bằng cách tự động hóa quá trình phục hồi nhiều nhất có thể.

Không thể tự động hóa hoàn toàn vì nếu đúng như vậy, đó sẽ được coi 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 tôi có thể đạt được tự động hóa một phần: ví dụ: khách hàng có thể tự động từ chối chấp nhận chuỗi cuối cùng hoặc thậm chí là phần đầu được chọn trong nhánh nếu khách hàng đã xem một giao dịch đủ lâu. Mục tiêu quan trọng là đảm bảo rằng kẻ xấu tấn công ít nhất không thể giành được chiến thắng nhanh chóng và sạch sẽ.

Tăng ngưỡng đại biểu

Hôm nay, nếu những người nắm giữ 67% cổ phần ủ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ỉ xảy ra một lỗi cuối cùng (rất ngắn). Ví dụ: nếu tỷ lệ phần trăm này tăng lên 80%, thì số lượng giai đoạn không cuối cùng được thêm vào sẽ tương đối thấp, nhưng Ethereum sẽ đạt được các đặ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 dừng giai đoạn cuối cùng. Đ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ù đó là khi bên sai là kẻ tấn công hay có khách hàng bị lỗi.

Điều này cũng trả lời cho câu hỏi “Việc cầm cố riêng có ý nghĩa gì?” Ngày nay, hầu hết những người đặt cược đã đặt cược thông qua các nhóm khai thác và có vẻ như không có một người đặt cược nào sẽ nhận được 51% số ETH đặt cược. Tuy nhiên, nếu chúng ta làm việc chăm chỉ, việc yêu cầu các cá nhân đặt cược đạt đủ số đại biểu để chặn thiểu số, đặc biệt nếu số đại biểu là 80% (vì vậy chỉ cần số đại biểu 21% để chặn thiểu số), dường như có thể đạt được. Miễn là những người đặt cược riêng lẻ không đồng ý với cuộc tấn công 51% (dù là phục hồi hay xem xét cuối cùng), cuộc tấn công như vậy sẽ không đạt được "chiến thắng rõ ràng" và những người đặt cược cá nhân sẽ có động cơ giúp tổ chức một đợt soft fork thiểu số.

Lưu ý rằng có sự tương tác giữa ngưỡng đại biểu và cơ chế Quỹ đạo: nếu chúng tôi kết thúc sử dụng Orbit, thì chính xác "21% số người đặt cược" nghĩa là gì sẽ là một câu hỏi phức tạp hơn và sẽ phụ thuộc một phần vào việc phân phối trình xác thực.

kháng lượng tử

Metaculus hiện tin rằng , mặc dù có phạm vi lỗi rộng, máy tính lượng tử có thể 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ử 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ử hoạt động hiệu quả trong trung hạn. Điều này có ý nghĩa đối với toàn bộ lộ trình của 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ố 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 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 biện minh cho sự thận trọng của các giả định xung quanh hiệu suất của thiết kế bằng chứng cổ phần và là lý do để chủ động hơn trong việc phát triển các giải pháp thay thế kháng lượng tử.