Bài viết mới của Vitalik: Tương lai có thể có của Ethereum, the Merge
Tuyển chọn TechFlowTuyển chọn TechFlow
Bài viết mới của Vitalik: Tương lai có thể có của Ethereum, the Merge
Chế độ dân chủ hóa, xác nhận giao dịch nhanh hơn, chống lại các cuộc tấn công lượng tử... Tương lai của Ethereum sẽ ra sao?
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin
Biên dịch: Alex Liu, Foresight News
Cảm ơn đặc biệt đến Justin Drake, Hsiao-wei Wang, @antonttc, Anders Elowsson và Francesco vì những góp ý và phản biện.
Ban đầu, "The Merge" (Sự hợp nhất) ám chỉ 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 mong đợi từ lâu và đầy công sức từ bằng chứng công việc (PoW) sang bằng chứng cổ phần (PoS). Ngày nay, Ethereum đã hoạt động ổn định như một hệ thống PoS gần trọn vẹn hai năm, và cơ chế PoS này đã thể hiện rất tốt về tính ổn định, hiệu suất và tránh rủi ro tập trung hóa. Tuy nhiên, vẫn còn một số lĩnh vực quan trọng cần cải thiện đối với PoS.
Lộ trình năm 2023 của tôi chia vấn đề này thành nhiều phần: cải tiến các chức năng kỹ thuật như tính ổn định, hiệu suất và khả năng tiếp cận cho các bộ xác thực nhỏ, cũng như các thay đổi kinh tế nhằm giải quyết rủi ro tập trung. Phần trước kế thừa tiêu đề "the Merge", phần 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 "Merge": Thiết kế kỹ thuật của PoS còn có thể cải thiện ở những điểm nào, và con đường để đạt được điều đó là gì?
Đây không phải là danh sách đầy đủ tất cả những điều có thể làm với PoS; thay vào đó, đây là danh sách các ý tưởng đang được xem xét tích cực.
Xác nhận cuối cùng trong một slot duy nhất và dân chủ hóa việc đặt cược
Chúng ta đang giải quyết vấn đề gì?
Hiện tại, cần 2-3 epochs (khoảng 15 phút) để hoàn tất một khối, và cần 32 ETH mới có thể trở thành người đặt cược. Ban đầu, đây là một thỏa hiệp nhằm cân bằng ba mục tiêu:
-
Tối đa hóa số lượng bộ xác thực có thể tham gia đặt cược (điều này đồng nghĩa với việc giảm tối thiểu lượng ETH cần đặt cược)
-
Tối thiểu hóa thời gian hoàn tất
-
Tối thiểu hóa chi phí vận hành nút, cụ thể là chi phí tải xuống, xác minh và phát lại tất cả các chữ ký từ các bộ xác thực khác
Ba mục tiêu này mâu thuẫn nhau: để đảm bảo tính hoàn tất về mặt kinh tế (có nghĩa là: kẻ tấn công cần đốt một lượng lớn ETH để đảo ngược khối đã được hoàn tất), mỗi lần hoàn tất, bạn cần mỗi bộ xác thực ký hai thông điệp. Do đó, nếu có rất nhiều bộ xác thực, hoặc bạn cần rất nhiều thời gian để xử lý tất cả chữ ký, hoặc bạn cần các nút cực mạnh để xử lý đồng thời tất cả các chữ ký.
Lưu ý rằng tất cả điều này đều dựa trên một mục tiêu then chốt của Ethereum: đảm bảo ngay cả một cuộc tấn công thành công cũng khiến kẻ tấn công phải trả giá rất cao. Đây chính là ý nghĩa của cụm từ "tính hoàn tất kinh tế". Nếu không có mục tiêu này, chúng ta có thể giải quyết vấn đề bằng cách chọn ngẫu nhiên một ủy ban để hoàn tất từng khối. Các chuỗi không cố gắng đạt được tính hoàn tất kinh tế, ví dụ như Algorand, thường làm như vậy. 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% bộ xác thực, họ có thể thực hiện tấn công với chi phí rất thấp (khôi phục khối đã hoàn tất, kiểm duyệt hoặc trì hoãn hoàn tất): chỉ cần kiểm soát một phần các nút trong ủy ban, có thể bị phát hiện là tham gia tấn công và bị xử phạt, dù là thông qua giảm đặt cược (slashing) hay phân nhánh mềm do cộng đồng phối hợp. Điều này có nghĩa là kẻ tấn công có thể lặp lại nhiều lần việc tấn công chuỗi, chỉ mất một phần nhỏ tài sản trong mỗi lần tấn công. Vì vậy, nếu muốn có tính hoàn tất kinh tế, phương pháp đơn giản dựa trên ủy ban là không khả thi, và dường như chúng ta thực sự cần sự tham gia của tất cả các bộ xác thực.
Lý tưởng nhất là giữ được tính hoàn tất kinh tế, đồng thời cải thiện hiện trạng ở hai lĩnh vực:
-
Hoàn tất khối trong một slot duy nhất (lý tưởng là giữ hoặc thậm chí rút ngắn độ dài hiện tại 12 giây), thay vì 15 phút
-
Cho phép bộ xác thực đặt cược với 1 ETH (thấp hơn 32 ETH)
Mục tiêu đầu tiên có hai mục đích, cả hai đều có thể được coi là "làm cho các thuộc tính của Ethereum phù hợp hơn với các chuỗi L1 tập trung hóa hơn nhưng chú trọng hiệu suất".
Thứ nhất, nó đảm bảo tất cả người dùng Ethereum thực sự được hưởng lợi từ mức độ an toàn cao hơn nhờ cơ chế hoàn tất. Hiện tại, hầu hết người dùng không làm vậy vì họ không muốn chờ 15 phút; với việc hoàn tất trong một slot, người dùng gần như thấy giao dịch của họ được hoàn tất ngay sau khi xác nhận. Thứ hai, 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ừ các trường hợp tương đối hiếm gặp như inactivity leak), nó sẽ đơn giản hóa giao thức và hạ tầng xung quanh.
Mục tiêu thứ hai xuất phát từ mong muốn hỗ trợ người đặt cược độc lập (solo stakers). Các cuộc khảo sát liên tục cho thấy yếu tố chính ngăn cản nhiều người tham gia đặt cược độc lập là giới hạn tối thiểu 32 ETH. Giảm giới hạn này xuống 1 ETH sẽ giải quyết vấn đề này, và các vấn đề khác sẽ trở thành yếu tố chính hạn chế việc đặt cược độc lập.
Hiện tại tồn tại một thách thức: mục tiêu hoàn tất nhanh hơn và dân chủ hóa việc đặt cược đều mâu thuẫn với mục tiêu giảm thiểu chi phí vận hành. Thực tế, chính điều này là lý do chúng ta chưa bắt đầu với việc hoàn tất trong một slot. Tuy nhiên, các nghiên cứu gần đây đã đưa ra một số hướng giải quyết vấn đề này.
Nó là gì và hoạt động như thế nào?
Việc hoàn tất trong một slot liên quan đến việc sử dụng một thuật toán đồng thuận để hoàn tất khối trong một slot. Bản thân điều này không phải là mục tiêu khó: nhiều thuật toán, ví dụ như đồng thuận Tendermint, đã làm được điều này. Một thuộc tính yêu cầu riêng của Ethereum là inactivity leak, mà Tendermint không hỗ trợ, thuộc tính này 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 bộ 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 đồng thuận kiểu Tendermint để thích nghi với inactivity leak.
Đề xuất hàng đầu cho việc hoàn tất trong một slot
Phần khó hơn của vấn đề là tìm ra cách để việc hoàn tất trong một slot có thể hoạt động với số lượng bộ xác thực rất lớn mà không gây ra chi phí vận hành cực cao cho các nhà vận hành nút. Để giải quyết điều này, có một số giải pháp hàng đầu:
-
Tùy chọn 1: Cưỡng ép - Nỗ lực phát triển giao thức tổng hợp chữ ký tốt hơn, có thể sử dụng ZK-SNARK, thực tế cho phép xử lý hàng triệu chữ ký từ bộ xác thực trong mỗi slot.
Horn, một trong những thiết kế được đề xuất cho giao thức tổng hợp tốt hơn
Tùy chọn 2: Ủy ban Orbit — một cơ chế mới cho phép một ủy ban trung bình được chọn ngẫu nhiên chịu trách nhiệm hoàn tất chuỗi, nhưng theo cách bảo toàn thuộc tính chi phí tấn công mà chúng ta đang tìm kiếm.
Một cách hiểu về Orbit SSF là nó mở rộng không gian thỏa hiệp giữa hai lựa chọn, từ x=0 (kiểu ủy ban Algorand, không có tính hoàn tất kinh tế) đến x=1 (hiện trạng Ethereum), tạo ra điểm "Ethereum vẫn có đủ tính hoàn tất kinh tế để rất an toàn, nhưng đồng thời chúng ta chỉ cần một mẫu bộ xác thực nhỏ vừa phải tham gia vào mỗi slot để đạt được lợi thế về hiệu quả".
Orbit tận dụng sự khác biệt sẵn có trong quy mô tiền gửi của bộ xác thực để đạt được càng nhiều tính hoàn tất kinh tế càng tốt, đồng thời vẫn đảm bảo vai trò tương xứng cho các bộ xác thực nhỏ. Ngoài ra, Orbit sử dụng việc luân chuyển ủy ban chậm để đảm bảo mức độ trùng lặp cao giữa các nhóm bỏ phiếu liền kề, từ đó đảm bảo tính hoàn tất kinh tế vẫn áp dụng được ở ranh giới chuyển đổi ủy ban.
-
Tùy chọn 3: Đặt cược hai cấp — một cơ chế có hai loại người đặt cược, một loại có yêu cầu tiền gửi cao, một loại có yêu cầu thấp. Chỉ lớp đặt cược có tiền gửi cao hơn mới trực tiếp tham gia vào việc cung cấp tính hoàn tất kinh tế. Có nhiều đề xuất về quyền và trách nhiệm của lớp đặt cược thấp hơn (ví dụ, xem bài đăng Rainbow Staking). Các ý tưởng phổ biến bao gồm:
-
Quyền ủy thác đặt cược cho người đặt cược cấp cao hơn
-
Một số bộ xác thực cấp thấp ngẫu nhiên cần phải chứng minh và hoàn tất từng khối
-
Quyền tạo ra danh sách bao gồm (inclusion lists)
Có liên hệ gì với các nghiên cứu hiện tại?
-
Paths toward single slot finality (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality Đường đi đến việc hoàn tất trong một slot (2022)
-
A concrete proposal for a single slot finality protocol for Ethereum (2023): https://eprint.iacr.org/2023/280 Đề xuất cụ thể cho giao thức hoàn tất trong một slot dành cho Ethereum (2023)
-
Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
-
Further analysis on Orbit-style mechanisms: https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464 Phân tích sâu hơn về các cơ chế kiểu Orbit
-
Horn, signature aggregation protocol (2022): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219 Horn, giao thức tổng hợp chữ ký (2022)
-
Signature merging for large-scale consensus (2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn Gộp chữ ký cho đồng thuận quy mô lớn (2023)
-
Signature aggregation protocol proposed by Khovratovich et al: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/ Giao thức tổng hợp chữ ký do Khovratovich và cộng sự đề xuất
-
STARK-based signature aggregation (2022): https://hackmd.io/@vbuterin/stark_aggregation Tổng hợp chữ ký dựa trên STARK (2022)
-
Rainbow staking: https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683 Rainbow staking
Cần làm gì thêm, và cần cân nhắc những gì?
Có bốn con đường chính có thể lựa chọn (chúng ta cũng có thể kết hợp các hướng đi):
-
Duy trì hiện trạng
-
SSF cưỡng ép
-
Orbit SSF
-
SSF với đặt cược hai cấp
(1) có nghĩa là không làm gì và giữ nguyên, nhưng điều này sẽ làm tệ hơn trải nghiệm bảo mật và tính tập trung hóa của Ethereum.
(2) dùng công nghệ tiên tiến để giải quyết vấn đề. Để thực hiện điều này, cần gộp một lượng lớn chữ ký (trên 1 triệu) trong thời gian rất ngắn (5-10 giây). Một cách hiểu về phương pháp này là nó liên quan đến việc chấp nhận phức tạp gói gọn để giảm thiểu độ phức tạp hệ thống bằng mọi giá.
(3) tránh "công nghệ cao cấp", và giải quyết vấn đề bằng cách suy nghĩ lại khéo léo về các giả định giao thức: chúng ta nới lỏng yêu cầu "tính hoàn tất kinh tế" để theo đuổi mục tiêu khiến chi phí tấn công cao, nhưng có thể chấp nhận chi phí tấn công có thể thấp hơn 10 lần so với hiện tại (ví dụ, chi phí tấn công 2,5 tỷ USD thay vì 25 tỷ USD). Người ta thường cho rằng tính hoàn tất kinh tế của Ethereum hiện tại vượt xa nhu cầu, và rủi ro an ninh chính nằm ở nơi khác, nên đây có thể là một sự đánh đổi chấp nhận được.
Công việc chính là xác minh cơ chế Orbit là an toàn và có các thuộc tính mong muốn, sau đó hình thức hóa hoàn toàn và triển khai. Ngoài ra, EIP-7251 (tăng mức dư tối đa hợp lệ) cho phép tự nguyện gộp số dư bộ xác thực, ngay lập tức giảm một phần chi phí xác minh chuỗi, và hiệu quả hoạt động như giai đoạn khởi đầu cho việc triển khai Orbit.
(4) tránh suy nghĩ sâu sắc và công nghệ cao cấp, nhưng tạo ra một hệ thống đặt cược hai cấp vẫn tiềm ẩn rủi ro tập trung hóa. Rủi ro phụ thuộc lớn vào các quyền cụ thể mà lớp đặt cược thấp hơn nhận được. Ví dụ:
-
Nếu bộ xác thực cấp thấp cần ủy quyền quyền chứng minh cho bộ xác thực cấp cao, thì việc ủy quyền có thể tập trung, do đó chúng ta cuối cùng sẽ có hai tầng đặt cược cực kỳ tập trung.
-
Nếu cần một mẫu ngẫu nhiên từ tầng thấp hơn để phê duyệt từng khối, kẻ tấn công có thể chi một lượng rất nhỏ ETH để ngăn chặn việc hoàn tất.
-
Nếu bộ xác thực tầng thấp chỉ có thể tạo danh sách bao gồm, thì tầng chứng minh có thể vẫn bị tập trung, lúc đó một cuộc tấn công 51% vào tầng chứng minh có thể tự mình kiểm duyệt danh sách bao gồm.
Có thể kết hợp nhiều chiến lược, ví dụ:
(1 + 2): Thêm Orbit mà không hoàn tất trong một slot
(1 + 3): Sử dụng công nghệ cưỡng ép để giảm kích thước tiền gửi tối thiểu, mà không hoàn tất trong một slot. Số lượng tổng hợp cần thiết ít hơn 64 lần so với trường hợp (3) thuần túy, do đó vấn đề trở nên dễ dàng hơn.
(2 + 3): Sử dụng Orbit SSF với tham số thận trọng (ví dụ, ủy ban 128k bộ xác thực thay vì 8k hoặc 32k) và dùng công nghệ để làm cho nó siêu hiệu quả.
(1 + 4): Thêm rainbow staking mà không hoàn tất trong một slot
Nó tương tác như thế nào với các phần khác trong lộ trình?
Ngoài các lợi ích khác, việc hoàn tất trong một slot còn giảm rủi ro của một số loại tấn công MEV nhiều khối. Ngoài ra, trong thế giới hoàn tất trong một slot, thiết kế tách biệt người chứng minh - người đề xuất và các đường ống sản xuất khối nội giao thức cần được thiết kế khác đi.
Điểm yếu của chiến lược cưỡng ép là chúng khiến việc giảm thời gian slot trở nên khó khăn hơn.
Bầu chọn lãnh đạo bí mật duy nhất (Single secret leader election)
Chúng ta đang giải quyết vấn đề gì?
Ngày nay, ai sẽ đề xuất khối tiếp theo là điều được biết trước. Điều này tạo ra một lỗ hổng bảo mật: kẻ tấn công có thể giám sát mạng, xác định bộ 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 từ chối dịch vụ (DoS) lên từng bộ xác thực khi chúng sắp đề xuất khối.
Nó là gì và hoạt động như thế nào?
Cách tốt nhất để giải quyết vấn đề DoS là che giấu thông tin về bộ 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 ra. Lưu ý rằng nếu chúng ta bỏ yêu cầu "duy nhất", điều này rất dễ: 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 bộ xác thực có thể đáp ứng yêu cầu này - nhưng đôi khi có hai hoặc nhiều hơn, và đôi khi là không có ai. Việc kết hợp yêu cầu "bí mật" với yêu cầu "duy nhất" luôn là một thách thức.
Giao thức bầu chọn 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 mã hóa để tạo ra một ID bộ xác thực "ẩn" cho mỗi bộ xác thực, sau đó cung cấp cơ hội xáo trộn cho nhiều người đề xuất trong nhóm ID ẩn (điều này giống như cách mạng mixnet hoạt động). Trong mỗi slot, một ID ẩn ngẫu nhiên sẽ được chọn. Chỉ chủ sở hữu ID ẩ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 ẩn đó tương ứng với bộ xác thực nào.
Có liên hệ gì với các nghiên cứu hiện tại?
-
Bài báo của Dan Boneh (2020): https://eprint.iacr.org/2020/025.pdf
-
Whisk (đề xuất cụ thể cho Ethereum, 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
-
Thẻ Single secret leader election trên ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election
-
SSLE đơn giản hóa bằng chữ ký vòng: https://ethresear.ch/t/simplified-ssle/12315
Cần làm gì thêm, và cần cân nhắc những gì?
Thực tế, điều 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 trên mainnet. Chúng tôi đánh giá cao Ethereum là một giao thức khá đơn giản, và không muốn làm tăng thêm độ phức tạp. Các triển khai SSLE mà chúng tôi thấy thêm hàng trăm dòng mã quy chuẩn và đưa ra các giả định mới trong mật mã học phức tạp. Việc tìm ra một triển khai SSLE kháng lượng tử đủ hiệu quả cũng vẫn là một câu hỏi chưa có lời giải.
Có thể trong tương lai, khi chúng tôi đã mạo hiểm thử và giới thiệu cơ chế chứng minh zero-knowledge chung trong giao thức Ethereum L1 vì các lý do khác (ví dụ như cây trạng thái, ZK-EVM), thì độ phức tạp bổ sung do SSLE mang lại sẽ giảm xuống mức đủ thấp.
Một lựa 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ụ như ở lớp p2p) để giải quyết vấn đề DoS.
Nó tương tác như thế nào với các phần khác trong lộ trình?
Nếu chúng ta thêm cơ chế tách biệt người chứng minh - người đề xuất (APS), ví dụ như execution tickets, thì khối thực thi (tức là khối chứa giao dịch Ethereum) sẽ không cần SSLE, vì chúng ta có thể dựa vào các bộ xây dựng khối chuyên dụng. Tuy nhiên, chúng ta vẫn sẽ được hưởng lợi từ SSLE ở khối đồng thuận (tức là khối chứa các thông điệp giao thức như chứng minh (attestations), và có thể là các đoạn danh sách bao gồm, v.v.).
Xác nhận giao dịch nhanh hơn
Chúng ta đang giải quyết vấn đề gì?
Việc giảm thời gian xác nhận giao dịch của Ethereum thêm nữa là có giá trị, từ 12 giây xuống ví dụ như 4 giây. Làm như vậy sẽ cải thiện trải nghiệm người dùng cho L1 và các Rollup dựa trên L1, đồng thời giúp các giao thức defi hiệu quả hơn. Nó cũng sẽ giúp L2 dễ phi tập trung hóa hơn, vì nó cho phép một loạt lớn các ứng dụng L2 hoạt động trên các Rollup dựa trên L1, từ đó giảm nhu cầu L2 tự xây dựng hệ thống sắp xếp phi tập trung dựa trên ủy ban.
Nó là gì và hoạt động như thế nào?
Giảm thời gian slot, ví dụ 8 giây hoặc 4 giây. Điều này không nhất thiết có nghĩa là hoàn tất trong 4 giây: việc hoàn tất về bản chất cần ba vòng truyền thông, do đó chúng ta có thể làm cho mỗi vòng truyền thông trở thành một khối riêng biệt, ít nhất sẽ có xác nhận sơ bộ sau 4 giây.
Cho phép người đề xuất công bố xác nhận trước trong quá trình slot. Trong trường hợp cực đoan, người đề xuất có thể thêm các giao dịch họ thấy trực tiếp vào khối của mình và ngay lập tức công bố tin nhắn xác nhận trước cho từng giao dịch ("Giao dịch đầu tiên của tôi là 0×1234...", "Giao dịch thứ hai của tôi là 0×5678..."). Trường hợp người đề xuất công bố hai xác nhận mâu thuẫn có thể được xử lý theo hai cách: (i) giảm đặt cược (slashing) người đề xuất, hoặc (ii) sử dụng người chứng minh để bỏ phiếu cho xác nhận xuất hiện sớm hơn.
Có liên hệ gì với các nghiên cứu hiện tại?
-
Based preconfirmations: https://ethresear.ch/t/based-preconfirmations/17353
-
Protocol-enforced proposer commitments (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
-
Staggered periods across parallel chains (một ý tưởng thời 2018 nhằm đạt được độ trễ thấp): https://ethresear.ch/t/staggered-periods/1793
Cần làm gì thêm, và cần cân nhắc những gì?
Hiện tại chưa rõ liệu việc giảm thời gian slot có khả thi hay không. Ngay cả ngày nay, nhiều nhà đặt cược ở nhiều khu vực trên thế giới cũng khó có thể nhận được các xác nhận đủ nhanh. Thử nghiệm với thời gian slot 4 giây sẽ tiềm ẩn rủi ro tập trung hóa bộ xác thực và khiến việc trở thành bộ xác thực ở ngoài một vài khu vực phát triển trở nên không thực tế do độ trễ. Cụ thể, chuyển sang thời gian slot 4 giây sẽ cần 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 của người đề xuất là nó có thể cải thiện đáng kể thời gian bao gồm trong trường hợp trung bình, nhưng không thể cải thiện trường hợp xấu nhất: nếu người đề xuất hiện tại hoạt động tốt, giao dịch sẽ được xác nhận trước trong 0,5 giây thay vì được bao gồm trong 6 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 kém, bạn vẫn phải chờ trọn vẹn 12 giây để bắt đầu slot tiếp theo và có người đề xuất mới.
Hơn nữa, cách khuyến khích xác nhận trước cũng vẫn là một câu hỏi chưa có lời giải. Người đề xuất có động lực tối đa hóa quyền lựa chọn của họ càng lâu càng tốt. Nếu người chứng minh ký cam kết về tính kịp thời của xác nhận trước, thì người gửi giao dịch có thể thu một phần phí với điều kiện 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 việc người chứng minh tiếp tục hoạt động trở nên khó khăn hơn như một "ống dẫn ngu ngốc" trung lập.
Mặt khác, nếu chúng ta không thử làm điều này và giữ thời gian hoàn tất ở 12 giây (hoặc lâu hơn), hệ sinh thái sẽ coi trọng hơn các cơ chế xác nhận trước của L2, và tương tác giữa các L2 sẽ cần nhiều thời gian hơn.
Nó tương tác như thế nào với các phần khác trong lộ trình?
Xác nhận trước dựa trên người đề xuất thực tế phụ thuộc vào cơ chế tách biệt người chứng minh - người đề xuất (APS), ví dụ như execution tickets. Nếu không, áp lực cung cấp xác nhận trước thời gian thực có thể quá tập trung đối với các bộ xác thực thông thường.
Thời gian slot có thể ngắn đến đâu còn phụ thuộc vào cấu trúc slot, điều này phần lớn phụ thuộc vào phiên bản APS, danh sách bao gồm, v.v. mà chúng ta cuối cùng triển khai. Một số cấu trúc slot có ít vòng hơn, do đó thân thiện hơn với thời gian slot ngắn, nhưng chúng đánh đổi ở những nơi khác.
Các lĩnh vực nghiên cứu khác
Phục hồi sau tấn công 51%
Người ta thường giả định rằng nếu xảy ra tấn công 51% (bao gồm các cuộc tấn công không thể chứng minh bằng mật mã, ví dụ như kiểm duyệt), cộng đồng sẽ đoàn kết thực hiện phân nhánh mềm phe thiểu số để đảm bảo người tốt thắng, kẻ xấu bị inactivity leak hoặc bị giảm đặt cược (slashed). Tuy nhiên, sự phụ thuộc quá mức vào tầng xã hội như vậy có thể được coi 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 làm cho quá trình phục hồi càng tự động càng tốt.
Tự động hóa hoàn toàn là không thể, bởi nếu có thể thì đó sẽ được coi là thuật toán đồng thuận dung sai lỗi >50%, và chúng ta đã biết những giới hạn toán học nghiêm ngặt có thể chứng minh được của các thuật toán như vậy. Nhưng chúng ta có thể đạt được tự động hóa một phần: ví dụ, nếu client kiểm duyệt đã thấy một giao dịch đủ lâu, client có thể tự động từ chối chấp nhận chuỗi đã hoàn tất, thậm chí từ chối chấp nhận đầu phân nhánh chọn lựa. Một mục tiêu quan trọng là đảm bảo kẻ xấu trong cuộc tấn công ít nhất không thể giành chiến thắng nhanh chóng và sạch sẽ.
Nâng cao ngưỡng bỏ phiếu
Ngày nay, một khối sẽ được hoàn tất nếu 67% người đặt cược ủng hộ. Có người cho rằng điều này quá quyết liệt. Trong suốt lịch sử Ethereum, chỉ xảy ra một lần (rất ngắn) thất bại hoàn tất. Nếu tỷ lệ này tăng lên, ví dụ đến 80%, thì số lượng giai đoạn không hoàn tất sẽ tăng tương đối thấp, nhưng Ethereum sẽ có thuộc tính an toàn: đặ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 hoàn tất. Điều này dường như khỏe mạnh hơn nhiều so với việc "bên sai" thắng ngay lập tức, dù bên sai là kẻ tấn công hay là client mắc lỗi.
Điều này cũng trả lời câu hỏi "ý nghĩa của việc đặt cược độc lập là gì?". Ngày nay, phần lớn người đặt cược đã đặt cược thông qua các bể đào, và dường như người đặt cược độc lập khó có thể chiếm tới 51% lượng ETH đặt cược. Tuy nhiên, nếu chúng ta nỗ lực, để người đặt cược độc lập đạt tới mức chặn đa số, đặc biệt nếu ngưỡng bỏ phiếu là 80% (do đó chỉ cần 21% để chặn đa số), thì điều này dường như khả thi. Miễn là người đặt cược độc lập không đồng ý với cuộc tấn công 51% (dù là phục hồi hoàn tất hay kiểm duyệt), cuộc tấn công như vậy sẽ không giành được "chiến thắng sạch", và người đặt cược độc lập sẽ có động lực giúp tổ chức phân nhánh mềm phe thiểu số.
Lưu ý rằng có sự tương tác giữa ngưỡng bỏ phiếu và cơ chế Orbit: nếu cuối cùng chúng ta sử dụng Orbit, thì "21% người đặt cược" thực sự có nghĩa gì sẽ trở thành một vấn đề phức tạp hơn, và một phần phụ thuộc vào phân bố bộ xác thực.
Kháng lượng tử
Metaculus hiện tại cho rằng, mặc dù có sai số lớn, máy tính lượng tử có thể bắt đầu phá vỡ mật mã vào một lúc nào đó trong thập kỷ 2030:
Các chuyên gia điện toán lượng tử như Scott Aaronson gần đây cũng bắt đầu coi trọng 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 ảnh hưởng đến toàn bộ lộ trình Ethereum: có nghĩa là mọi phần hiện tại của giao thức Ethereum dựa trên đường cong elliptic cần được thay thế bằng một cái gì đó dựa trên hàm băm hoặc các phương án kháng lượng tử khác. Điều này đặc biệt có nghĩa là chúng ta không thể giả định có thể mãi mãi dựa vào các đặc tính tuyệt vời của tổng hợp BLS để xử lý chữ ký từ tập hợp bộ xác thực lớn. Điều này chứng minh tính đúng đắn của việc bảo thủ trong các giả định về hiệu suất thiết kế PoS, và là lý do để chủ động phát triển các phương án thay thế kháng lượng tử hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@VitalikButerin
