Các tương lai có thể của giao thức Ethereum, phần 1: Sự hợp nhất

Nâng cao10/22/2024, 4:19:33 AM
Bài viết này bàn về Ethereum "Merge" và khám phá các lĩnh vực cần cải thiện trong thiết kế kỹ thuật của Proof of Stake, cũng như các cách tiềm năng để đạt được những cải thiện này.

Ban đầu, “the Merge” đề cập đến sự kiện quan trọng nhất trong lịch sử giao thức Ethereum kể từ khi ra đời: sự chuyển đổi được mong chờ và đạt được từ dạng chứng minh công việc sang chứng minh cổ phần. Hiện nay, Ethereum đã trở thành một hệ thống chứng minh cổ phần ổn định chạy một cách ổn định trong gần hai năm, và hệ thống chứng minh cổ phần này đã hoạt động rất tốt trong sự ổn định, hiệu suất và tránh rủi ro tập trungTuy nhiên, vẫn còn một số lĩnh vực quan trọng mà cần cải thiện trong chứng minh cổ phần.

Sơ đồ con đường của tôi từ năm 2023 chia ra thành các phần: cải thiện các tính năng kỹ thuật như tính ổn định, hiệu suất và tính khả dụng đối với các máy chủ xác nhận nhỏ hơn, và thay đổi kinh tế để giải quyết các rủi ro tập trung. Phần đầu tiên đã tiếp quản việc đảm nhận vị trí đầu trang cho “Việc hợp nhất”, và phần sau trở thành một phần của “Cuộc thanh trừng”.

The Merge, phiên bản lộ trình năm 2023.

Bài đăng này sẽ tập trung vào phần “Merge”: những gì vẫn có thể được cải thiện trong thiết kế kỹ thuật của chứng minh cổ phần, và những con đường nào để đạt được điều đó?

Điều này không được coi là một danh sách toàn diện của những điều có thể thực hiện để chứng minh sở hữu; thay vào đó, đó là một danh sách các ý tưởng đang được xem xét tích cực.

The Merge: mục tiêu chính

  • Độ chắc chắn cuối cùng một slot
  • Xác nhận giao dịch và hoàn tất càng nhanh càng tốt, đồng thời bảo toàn sự phi tập trung
  • Nâng cao tính khả thi của việc đặt cược cho người chơi đơn lẻ
  • Nâng cao tính ổn định
  • Tăng cường khả năng chống lại và phục hồi từ các cuộc tấn công 51% đối với Ethereum (bao gồm việc đảo ngược tính cuối cùng, chặn tính cuối cùng và kiểm duyệt)

Trong chương này

Độc quyền khe cắm cuối cùng và dân chủ hóa việc đặt cược

Chúng tôi đang giải quyết vấn đề gì?

Hôm nay, việc hoàn thiện một khối mất 2-3 epochs (~15 phút), và cần 32 ETH để trở thành người stake. Điều này ban đầu là một sự thỏa hiệp được dự định để @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">balance 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 ngầm định trực tiếp việc giảm thiểu số ETH tối thiểu cần thiết để đặt cược)
  • Tối thiểu hóa thời gian đến sự hoàn tất
  • Tối thiểu hóa chi phí vận hành một nút, trong trường hợp này là chi phí tải xuống, xác minh và phát lại tất cả các chữ ký của các nhà xác minh khác

Ba mục tiêu đang xung đột: để việc định rõ kinh tế trở thành khả thi (nghĩa là một kẻ tấn công sẽ cần đốt một lượng lớn ETH để quay lại một khối đã được định rõ), bạn cần mỗi validator ký hai thông điệp mỗi khi sự rõ ràng xảy ra. Và nếu bạn có nhiều validator, bạn entweder cần một thời gian dài để 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ý đồng thời.

Lưu ý rằng tất cả điều này đều phụ thuộc vào một mục tiêu quan trọng của Ethereum: đảm bảo rằng ngay cả khi tấn công thành công, chi phí cho kẻ tấn công cũng rất cao. Đây chính là ý nghĩa của thuật ngữ “sự hoàn thiện 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 mỗi slot. Các chuỗi không cố gắng đạt được sự hoàn thiện kinh tế, như Algorand, thường xuyên làm chính xác điều nàyTuy nhiên, vấn đề của cách tiếp cận này là nếu một kẻ tấn công kiểm soát 51% số lượng người xác thực, họ có thể thực hiện một cuộc tấn công (quay ngược lại một khối đã hoàn tất, hoặc kiểm duyệt, hoặc trì hoãn tính cuối cùng) với chi phí rất thấp: chỉ có một phần của các nút của họ trong ủy ban có thể bị phát hiện tham gia vào cuộc tấn công và bị phạt, dù thông quaslashinghoặcphân nhánh mềm được phối hợp xã hộiĐiều này có nghĩa là một kẻ tấn công có thể tấn công chuỗi nhiều lần, chỉ mất một phần nhỏ của số cổ phần của họ trong mỗi cuộc tấn công. Do đó, nếu chúng ta muốn sự kết thúc kinh tế, một phương pháp dựa trên ủy ban ngây thơ không hoạt động, và có vẻ như ngay từ cái nhìn đầu tiên, chúng ta cần toàn bộ bộ kiểm định viên tham gia.

Lý tưởng nhất, chúng tôi muốn bảo tồn tính chất kinh tế cuối cùng, đồng thời cải thiện tình trạng hiện tại ở hai lĩnh vực:

  1. Hoàn tất các khối trong một khe (lý tưởng là giữ hoặc thậm chí là giảm độ dài hiện tại của 12s), thay vì 15 phút
  2. Cho phép các nhà xác thực đặt cược với 1 ETH (giảm từ 32 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à “đưa các thuộc tính của Ethereum vào đúng với các blockchain L1 tập trung hơn về hiệu suất”.

Đầu tiên, nó đảm bảo rằng tất cả người dùng Ethereum thực sự hưởng lợi từ mức độ đảm bảo bảo mật cao hơn được đạt được thông qua cơ chế hoàn thiện. Ngày nay, hầu hết người dùng không, vì họ không muốn chờ đợi 15 phút; với sự hoàn thiện theo từng khe, người dùng sẽ thấy giao dịch của họ được hoàn tất gần như ngay khi chúng đượ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 cần lo lắng về khả năng chuỗi sẽ quay lại trừ khi trong trường hợp hiếm hoi.rò rỉ không hoạt động.

Mục tiêu thứ hai được chứng minh bởi mong muốn hỗ trợ người đặt cược độc lập. Cuộc thăm dò sau cuộc thăm dò 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à mức tối thiểu là 32 ETH. Việc giảm mức tối thiểu xuống còn 1 ETH sẽ giải quyết vấn đề này, đến mức mà các lo ngại khác trở thành yếu tố chính hạn chế việc đặt cược độc lập.

Có một thách thức: mục tiêu về việc hoàn tất nhanh hơn và việc đặt cược dân chủ hơn đều xung đột với mục tiêu giảm thiểu chi phí hoạt động. Và thực tế, đây chính là lý do tại sao chúng tôi không bắt đầu với việc hoàn tất đơn lẻ từ đầu. Tuy nhiên, nghiên cứu gần đây đưa ra một số hướng đi khả thi xung quanh vấn đề.

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

Single-slot finality involves using a consensus algorithm that finalizes blocks in one slot. This in itself is not a difficult goal: plenty of algorithms, such as sự đồng thuận Tendermint, đã thực hiện điều này với các thuộc tính tối ưu. Một thuộc tính mong muốn duy nhất của Ethereum, mà Tendermint không hỗ trợ, là rò rỉ không hoạt động, 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ố xác minh viên ngừng hoạt động. May mắn thay, mong muốn này đã được giải quyết: có đã có đề xuấtcải biên giao thức Tendermint để thích nghi với rò rỉ không hoạt động.

Một đề xuất về độ tin cậy duy nhất hàng đầu

Phần khó hơn của vấn đề là tìm cách làm cho việc hoàn thành một khe duy nhất hoạt động với một số lượng validator rất cao, mà không dẫn đến overhead của người vận hành nút cực kỳ cao. Đối với điều này, có một số giải pháp hàng đầu:

  • Tùy chọn 1: Brute force - làm việc chăm chỉ để triển khai các giao thức tổng hợp chữ ký tốt hơn, có khả năng sử dụng ZK-SNARK, điều này thực sự sẽ cho phép chúng tôi xử lý chữ ký từ hàng triệu trình xác thực trong mỗi vị trí.

Horn, một trong những mẫu thiết kế đề xuất cho một giao thức tổng hợp tốt hơn.

  • Option 2: Ban điều hành vòng quỹ- một cơ chế mới cho phép một ủy ban có quy mô trung bình được chọn ngẫu nhiên để chịu trách nhiệm cho việc hoàn thiện chuỗi, nhưng một cách giữ nguyên các tính chất về 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ở ra một không gian các lựa chọn thỏa hiệp theo một phổ từ x=0 (các hội đồng kiểu Algorand, không có tính kinh tế cuối cùng) đến x=1 (trạng thái hiện tại của Ethereum), mở ra các điểm ở giữa nơi Ethereum vẫn có đủ tính kinh tế cuối cùng để rất an toàn, nhưng đồng thời chúng ta cũng có được các lợi ích về hiệu quả khi chỉ cần một mẫu ngẫu nhiên cỡ trung bình của các validators tham gia mỗi khe thời gian.

Orbit tận dụng sự không đồng nhất có sẵn trong kích thước tiền gửi của trình xác thực để có được càng nhiều tính cuối cùng về kinh tế càng tốt, vẫn sẽ mang lại cho các trình xác nhận nhỏ một vai trò tương xứng. Ngoài ra, Orbit sử dụng luân chuyển ủy ban chậm để đảm bảo sự chồng chéo cao giữa các đại biểu liền kề, đảm bảo rằng tính cuối cùng kinh tế của nó vẫn áp dụng ở ranh giới chuyển đổi ủy ban.

  • Tùy chọn 3: giao thức giao cấp đôi - một cơ chế trong đó có hai lớp người stakeholder, một lớp có yêu cầu ký quỹ cao hơn và một lớp có yêu cầu ký quỹ thấp hơn. Chỉ có lớp ký quỹ cao hơn sẽ trực tiếp tham gia cung cấp tính kết thúc kinh tế. Có nhiều đề xuất (ví dụ, xem bài đăng về Rainbow staking) vì chính xác những quyền lợi và trách nhiệm mà hạng mục tiền gửi thấp có. Các ý tưởng phổ biến bao gồm:
    • quyền ủy quyền cược cho người chơi cấp cao hơn
    • một mẫu ngẫu nhiên của người chơi cấp thấp xác nhận, và cần thiết để hoàn tất, mỗi khối
    • quyền tạo ra danh sách bao gồm

Còn gì để làm, và phải đối mặt với những sự đánh đổi gì?

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

  1. Giữ nguyên trạng thái
  2. Brute-force SSF
  3. Orbit SSF
  4. SSF với việc đặt cược hai tầng

(1) có nghĩa là không làm việc gì cả và để lại việc đặt cọc như hiện tại, nhưng nó khiến cho trải nghiệm bảo mật và tính tập trung của Ethereum xấu đi so với những gì có thể.

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

(3) tránh "công nghệ cao" và giải quyết vấn đề bằng cách suy nghĩ lại thông minh xung quanh các giả định giao thức: chúng tôi nới lỏng yêu cầu "tính cuối cùng về kinh tế" để chúng tôi yêu cầu các cuộc tấn công phải tốn kém, nhưng ổn với chi phí tấn công có lẽ thấp hơn 10 lần so với hiện nay (ví dụ: chi phí tấn công 2,5 tỷ đô la thay vì 25 tỷ đô la). Đó là một quan điểm phổ biến rằng Ethereum ngày nay có nhiều tính cuối cùng về kinh tế hơn mức cần thiết và rủi ro bảo mật chính của nó là ở nơi khác, và vì vậy đây được cho là một sự hy sinh ổn để thực hiện.

Công việc chính cần làm là xác minh rằng cơ chế Orbit là an toàn và có những tính chất mà chúng ta muốn, sau đó hoàn toàn hóa và triển khai nó. Ngoài ra, EIP-7251 (tăng cường số dư hiệu quả tối đa)cho phép tổng hợp cân đối người xác minh tự nguyện ngay lập tức giảm bớt phần nào chi phí xác minh chuỗi, và hoạt động như một giai đoạn ban đầu hiệu quả cho việc triển khai Orbit.

(4) tránh sự suy nghĩ thông minh 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ó nguy cơ tập trung. Nguy cơ phụ thuộc nhiều vào quyền cụ thể mà tầng đặt cược thấp hơn nhận được. Ví dụ:

  • Nếu một người tham gia cấp thấp cần ủy quyền quyền chứng thực của mình cho một người tham gia cấp cao, thì việc ủy quyền có thể tập trung và do đó chúng ta sẽ kết thúc với hai cấp độ giao thức độ tập trung cao.
  • Nếu một mẫu ngẫu nhiên của tầng dưới là cần thiết để phê duyệt mỗi khối, thì kẻ tấn công có thể chi một lượng rất nhỏ ETH để chặn tính cuối cùng.
  • Nếu người stake cấp thấp chỉ có thể tạo danh sách bao gồm, thì tầng chứng thực có thể vẫn duy trì tính trung tâm, tại đó một cuộc tấn công 51% vào tầng chứng thực có thể kiểm duyệt chính danh sách bao gồm.

Có thể kết hợp nhiều chiến lược, ví dụ:

(1 + 2): sử dụng các kỹ thuật tấn công mạnh mẽ để giảm kích thước gửi tiền tối thiểu mà không cần thực hiện sự cuối cùng của một khe đơn lẻ. 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, vì vậy vấn đề trở nên dễ dàng hơn.

(1 + 3): thêm Orbit mà không thực hiện tính đến việc kết thúc một khe đơn lẻ

(2 + 3): thực hiện Orbit SSF với các tham số bảo thủ (ví dụ: 128k ủy ban xác nhận thay vì 8k hoặc 32k), và sử dụng các kỹ thuật tấn công mạnh mẽ để làm cho nó siêu hiệu quả.

(1 + 4): thêm rainbow staking mà không cần thực hiện việc hoàn thành từng khe đơn lẻ

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

Ngoài các lời ích khác, sự hoàn thành một khe duy nhất giảm thiệu rộng rào củacác loại tấn công MEV đa khối cụ thểNgoài ra, các thiết kế chia tách người chứng thực - người đề xuất và các đường ống sản xuất khối trong giao thức cần được thiết kế khác biệt trong một thế giới với tính kết thúc chỉ có một khe cắm.

Chiến lược vét cạn có điểm yếu là làm cho việc giảm thời gian khe càng khó khăn hơn.

Bầu cử lãnh đạo bí mật đơn lẻ

Vấn đề chúng tôi đang giải quyết là gì?

Hôm nay, người xác minh nào sẽ đề xuất khối tiếp theo đã biết trước. Điều này tạo ra một lỗ hổng bảo mật: một kẻ tấn công có thể theo dõi mạng, xác định xem người xác minh nào tương ứng với địa chỉ IP nào, và tấn công DoS vào mỗi người xác minh ngay khi họ chuẩn bị đề xuất một khối.

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

Cách tốt nhất để khắc phục vấn đề DoS là ẩn thông tin về validator nào sẽ tạo khối tiếp theo, ít nhất cho đến khi khối thực sự được tạo ra. Lưu ý rằng điều này 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 cứ ai tạo khối tiếp theo, nhưng yêu cầu randao revealít hơn 2256 / N. Trung bình, chỉ có một validator 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 không có. Kết hợp yêu cầu “bí mật” với yêu cầu “đơn lẻ” đã lâu là vấn đề khó khăn.

Các giao thức bầu cử lãnh đạo bí mật đơn giản giải quyết vấn đề này bằng cách sử dụng một số kỹ thuật mật mã để tạo ra một ID xác thực 'mù' cho mỗi người xác thực, sau đó cho nhiều người đề xuất cơ hội xáo trộn và làm cho các ID mù (điều này tương tự như cách một mixnet công trình). Trong mỗi khe, một ID mù ngẫu nhiên được chọn. Chỉ chủ sở hữu của ID bị mù đó mới có thể tạo bằng chứng hợp lệ để đề xuất chặn, nhưng không ai khác biết ID bị mù tương ứng với trình xác thực nào.

Whisk SSLE giao thức

Còn gì để làm, và phải đối mặt với những sự đánh đổi nào?

Một cách hợp lý, những gì còn lại là tìm kiếm và triển khai một giao thức đủ đơn giản để chúng tôi cảm thấy thoải mái khi triển khai trên mainnet. Chúng tôi rất trân trọng việc Ethereum là một giao thức tương đối đơn giản, và chúng tôi không muốn độ phức tạp tăng thêm. Các triển khai SSLE mà chúng tôi đã thấy thêm hàng trăm dòng mã cụ thể, và giới thiệu các giả thuyết mới trong mật mã phức tạp. Việc tìm ra một triển khai SSLE đủ hiệu quả chống lại quantum cũng là một vấn đề mở.

Có thể xảy ra trường hợp phức tạp được giới thiệu bởi SSLE chỉ giảm đủ khi chúng ta tiến xa và giới thiệu máy móc để thực hiện chứng minh không cần biết một cách tổng quát vào giao thức Ethereum tại L1 vì các lý do khác (ví dụ: cây trạng thái, ZK-EVM).

Một lựa chọn thay thế khác là đơn giản là không quan tâm đến SSLE, và sử dụng các biện pháp giảm nhẹ ngoài giao thức (ví dụ ở tầng p2p) để giải quyết các vấn đề DoS.

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

Nếu chúng ta thêm một cơ chế phân biệt người chứng thực - người đề xuất (APS), ví dụ.vé thực thi, sau đó các khối thực thi (tức là các khối chứa giao dịch Ethereum) sẽ không cần SSLE, vì chúng ta có thể tin cậy vào người xây dựng khối là chuyên nghiệp. Tuy nhiên, chúng ta vẫn sẽ được lợi từ SSLE cho các khối đồng thuận (tức là các khối chứa các thông điệp giao thức như các chứng nhận, có lẽ là các phần của danh sách bao gồm, v.v.).

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

Vấn đề chúng ta đang giải quyết là gì?

Có giá trị trong Ethereum’sthời gian xác nhận giao dịch giảm thêm, từ 12 giây xuống còn 4 giây chẳng hạn. Việc làm này sẽ cải thiện đáng kể trải nghiệm người dùng cả đối với L1 lẫn các rollups dựa trên, đồng thời làm cho giao thức defi hiệu quả hơn. Nó cũng sẽ làm cho việc phân quyền cho L2 dễ dàng hơn, vì nó sẽ cho phép một lớp lớn ứng dụng L2 hoạt động trên Bản tổng hợp dựa trên, giảm nhu cầu xây dựng ủy ban phi tập trung của riêng họ cho việc xếp hàng phi tập trung.

Điều này là gì và nó hoạt động như thế nào?

Có rộng rãi hai gia đình kỹ thuật ở đây:

  1. Giảm thời gian khe cắm, xuống còn ví dụ. 8 giâyhoặc 4 giây. Điều này không nhất thiết phải có nghĩa là sự cố định trong vòng 4 giây: sự cố định vốn cần ba vòng giao tiếp, và vì vậy chúng ta có thể làm cho mỗi vòng giao tiếp là một khối riêng biệt, điều này sau 4 giây sẽ nhận được ít nhất là một xác nhận dự bị.
  2. Cho phép người đề xuất công bố các bản xác nhận trước trong suốt một khe. Ở mức cực đoan, một người đề xuất có thể bao gồm các giao dịch mà họ thấy vào khối của họ trong thời gian thực và ngay lập tức công bố một 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à 0×1234…", "Giao dịch thứ hai của tôi là 0×5678…"). Trường hợp một người đề xuất công bố hai thông báo xác nhận xung đột có thể được xử lý theo hai cách: (i) bằng cách cắt giảm số lượng người đề xuất, hoặc (ii) bằng cách sử dụng các người chứng thực để bỏ phiếu cho cái nào được thực hiện trước.

Còn gì cần làm, và phải đối mặt với những điều đổi lấy điều gì?

Chưa rõ việc rút ngắn thời gian khe cắm có thực sự thực tế hay không. Ngay cả ngày nay, người stakeholder ở nhiều khu vực trên thế giới đều gặp khó khăn khi cố gắng bao gồm xác nhận nhanh chóng đủ. Cố gắng chạy 4 giây khe cắm có nguy cơ tập trung bộ kiểm tra, và khiến việc trở thành bộ kiểm tra bên ngoài một số địa lý đặc quyền trở nên không thực tế do độ trễ. Cụ thể, chuyển sang 4 giây khe cắm sẽ đòi hỏi rút ngắn giới hạn về độ trễ mạng ("delta") xuống hai giây.

Phương pháp đề xuất trước có điểm yếu là nó có thể cải thiện đáng kể thời gian bao gồm trường hợp trung bình, nhưng không phải là 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 của bạn sẽ được xác nhận trước trong 0,5 giây thay vì được bao gồm trong (trung bình) 6 giây, nhưng nếu người đề xuất hiện tại không hoạt động hoặc không hoạt động tốt, bạn vẫn phải chờ đợi lên đến 12 giây đầy đủ cho khe tiếp theo bắt đầu và cung cấp một người đề xuất mới.

Ngoài ra, có một câu hỏi mở về cách xác nhận trước sẽ được khuyến khích. Người đề xuất có động lực để tối đa hóa tính tùy chọn của họ càng lâu càng tốt. Nếu người đính kèm ký vào tính kịp thời của xác nhận trước, thì người gửi giao dịch có thể thực hiện một phần phí có điều kiện xác nhận trước ngay lập tức, nhưng điều này sẽ gây thêm gánh nặng cho người đính kèm và có khả năng gây khó khăn hơn cho người đính kèm để 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 thử nghiệm điều này và giữ thời gian kết thúc ở 12 giây (hoặc lâu hơn), hệ sinh thái sẽ đặt trọng lượng lớn hơn vào các cơ chế xác nhận trước được tạo ra bởi lớp 2, và tương tác giữa các lớp 2 sẽ mất thời gian hơn.

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

Các xác nhận trước dựa vào người đề xuất thực tế phụ thuộc vào cơ chế phân tách người chứng nhận-người đề xuất (APS), ví dụ như.vé thực thiNế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 nhà xác thực thông thường.

Chính xác như thế nào thời gian khe cắm ngắn có thể phụ thuộc vào cấu trúc khe cắm, mà phụ thuộc nặng nề vào những phiên bản của APS, danh sách bao gồm, v.v chúng ta kết thúc triển khai. Có cấu trúc khe cắm chứa ít vòng và do đó thân thiện hơn với thời gian khe cắm ngắn, nhưng họ thực hiện sự đá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 cuộc tấn công 51%

Thường có một giả định rằng nếu một cuộc tấn công 51% xảy ra (bao gồm cả các cuộc tấn công không thể chứng minh bằng mật mã, như kiểm duyệt), cộng đồng sẽ đoàn kết để thực hiện một phần đa soft forkđảm bảo rằng những người tốt sẽ chiến thắng, và những người xấu sẽ bị rò rỉ hoặc bị trừng phạt vì 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ó thể đượ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 lớp xã hội bằng cách làm cho quá trình phục hồi tự động hóa càng nhiều càng tốt.

Toàn bộ việc tự động hoàn toàn không thể, vì nếu như vậy, điều đó sẽ được tính là một thuật toán đồng thuận chịu lỗi >50%, và chúng ta đã biết rằng (rất hạn chế)các hạn chế có thể chứng minh toán học của những loại thuật toán đóNhưng chúng ta có thể đạt được sự tự động hóa một phần: ví dụ, một khách hàng có thể tự động từ chối chấp nhận một chuỗi là đã hoàn thiện, hoặc thậm chí là đầu của lựa chọn khối phân nhánh, nếu nó kiểm duyệt các giao dịch mà khách hàng đã thấy đủ lâu. Một mục tiêu quan trọng là đảm bảo rằng những kẻ xấu trong một cuộc tấn công ít nhất là không thể dễ dàng chiến thắng sạch sẽ.

Tăng ngưỡng quorum

Ngày nay, một khối hoàn tất nếu 67% người đặt cược ủng hộ nó. Có ý kiến cho rằng điều này là quá hung hăng. Chỉ có một thất bại cuối cùng (rất ngắn) trong toàn bộ lịch sử của Ethereum. Nếu tỷ lệ này được tăng lên, ví dụ. đến 80%, sau đó số lượng thời gian 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 thuộ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 dừng tính cuối cùng. Đây có vẻ là một tình huống lành mạnh hơn nhiều so với "bên sai" nhận được chiến thắng ngay lập tức, cả khi bên sai là kẻ tấn công và khi đó là khách hàng có lỗi.

Điều này cũng đưa ra câu trả lời cho câu hỏi “điểm mấu chốt của người đặt cược đơn”? Ngày nay, hầu hết người đặt cược đang đặt cược thông qua các nhóm, và có vẻ rất không thể để có được người đặt cược đơn lên đến 51% ETH đã cược. Tuy nhiên, việc đưa người đặt cược đơn lên thành một phần nhỏ chặn quyền biểu quyết, đặc biệt nếu quyền biểu quyết là 80% (vì vậy một phần nhỏ chặn quyền biểu quyết chỉ cần 21%) có vẻ có thể đạt được nếu chúng ta làm việc chăm chỉ. Miễn là người đặt cược đơn không tham gia vào cuộc tấn công 51% (dù là đảo ngược tính chất cuối cùng hoặc kiểm duyệt), một cuộc tấn công như vậy sẽ không có được một “chiến thắng sạch sẽ”, và người đặt cược đơn sẽ được động viên để giúp tổ chức một cuộc nâng cấp mềm của phần nhỏ chặn quyền biểu quyết.

Lưu ý rằng có sự tương tác giữa ngưỡng quorum và cơ chế Orbit: nếu chúng ta kết thúc việc sử dụng Orbit, thì điều gì chính xác là “21% số người stake” sẽ trở thành một câu hỏi phức tạp hơn, và sẽ phần nào phụ thuộc vào phân phối của các validators.

Kháng chiến lược lượng tử

Metaculus hiện tại tin rằng, mặc dù có các thanh ghi lỗi rộng, rằng máy tính lượng tử có khả năng bắt đầu phá vỡ mật mã vào khoảng thập kỷ 2030:

Các chuyên gia về máy tính lượng tử như Scott Aaronson cũng đã bắt đầu xem xét khả năng các máy tính lượng tử thực sự hoạt động trong trung hạn nghiêm túc hơn nhiều. Điều này có hậu quả trên toàn bộ lộ trình Ethereum: điều này có nghĩa là mỗi phần của giao thức Ethereum hiện tại phụ thuộc vào các đường cong elliptic sẽ cần phải có một phương thức thay thế dựa trên băm hoặc chống lại quantum. Điều này đặc biệt có nghĩa là chúng ta không thể giả định rằng chúng ta sẽ có thể dựa vào các đặc tính xuất sắc của việc tổng hợp BLS để xử lý chữ ký từ một bộ xác thực lớn mãi mãi. Điều này biện minh cho chủ nghĩa bảo thủ trong các giả định xung quanh hiệu suất của các thiết kế bằng chứng cổ phần, và cũng là một nguyên nhân để chủ động hơn để phát triển các lựa chọn thay thế kháng lượng tử.

Disclaimer:

  1. Bài viết này được sao chép từ [ Vitalik Buterin]Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Học cửađội, và họ sẽ xử lý nhanh chóng.
  2. Bản pháp lý từ chối trách nhiệm: Các quan điểm được thể hiện trong bài viết này chỉ thuộc về tác giả và không hề cung cấp bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép.

Các tương lai có thể của giao thức Ethereum, phần 1: Sự hợp nhất

Nâng cao10/22/2024, 4:19:33 AM
Bài viết này bàn về Ethereum "Merge" và khám phá các lĩnh vực cần cải thiện trong thiết kế kỹ thuật của Proof of Stake, cũng như các cách tiềm năng để đạt được những cải thiện này.

Ban đầu, “the Merge” đề cập đến sự kiện quan trọng nhất trong lịch sử giao thức Ethereum kể từ khi ra đời: sự chuyển đổi được mong chờ và đạt được từ dạng chứng minh công việc sang chứng minh cổ phần. Hiện nay, Ethereum đã trở thành một hệ thống chứng minh cổ phần ổn định chạy một cách ổn định trong gần hai năm, và hệ thống chứng minh cổ phần này đã hoạt động rất tốt trong sự ổn định, hiệu suất và tránh rủi ro tập trungTuy nhiên, vẫn còn một số lĩnh vực quan trọng mà cần cải thiện trong chứng minh cổ phần.

Sơ đồ con đường của tôi từ năm 2023 chia ra thành các phần: cải thiện các tính năng kỹ thuật như tính ổn định, hiệu suất và tính khả dụng đối với các máy chủ xác nhận nhỏ hơn, và thay đổi kinh tế để giải quyết các rủi ro tập trung. Phần đầu tiên đã tiếp quản việc đảm nhận vị trí đầu trang cho “Việc hợp nhất”, và phần sau trở thành một phần của “Cuộc thanh trừng”.

The Merge, phiên bản lộ trình năm 2023.

Bài đăng này sẽ tập trung vào phần “Merge”: những gì vẫn có thể được cải thiện trong thiết kế kỹ thuật của chứng minh cổ phần, và những con đường nào để đạt được điều đó?

Điều này không được coi là một danh sách toàn diện của những điều có thể thực hiện để chứng minh sở hữu; thay vào đó, đó là một danh sách các ý tưởng đang được xem xét tích cực.

The Merge: mục tiêu chính

  • Độ chắc chắn cuối cùng một slot
  • Xác nhận giao dịch và hoàn tất càng nhanh càng tốt, đồng thời bảo toàn sự phi tập trung
  • Nâng cao tính khả thi của việc đặt cược cho người chơi đơn lẻ
  • Nâng cao tính ổn định
  • Tăng cường khả năng chống lại và phục hồi từ các cuộc tấn công 51% đối với Ethereum (bao gồm việc đảo ngược tính cuối cùng, chặn tính cuối cùng và kiểm duyệt)

Trong chương này

Độc quyền khe cắm cuối cùng và dân chủ hóa việc đặt cược

Chúng tôi đang giải quyết vấn đề gì?

Hôm nay, việc hoàn thiện một khối mất 2-3 epochs (~15 phút), và cần 32 ETH để trở thành người stake. Điều này ban đầu là một sự thỏa hiệp được dự định để @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">balance 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 ngầm định trực tiếp việc giảm thiểu số ETH tối thiểu cần thiết để đặt cược)
  • Tối thiểu hóa thời gian đến sự hoàn tất
  • Tối thiểu hóa chi phí vận hành một nút, trong trường hợp này là chi phí tải xuống, xác minh và phát lại tất cả các chữ ký của các nhà xác minh khác

Ba mục tiêu đang xung đột: để việc định rõ kinh tế trở thành khả thi (nghĩa là một kẻ tấn công sẽ cần đốt một lượng lớn ETH để quay lại một khối đã được định rõ), bạn cần mỗi validator ký hai thông điệp mỗi khi sự rõ ràng xảy ra. Và nếu bạn có nhiều validator, bạn entweder cần một thời gian dài để 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ý đồng thời.

Lưu ý rằng tất cả điều này đều phụ thuộc vào một mục tiêu quan trọng của Ethereum: đảm bảo rằng ngay cả khi tấn công thành công, chi phí cho kẻ tấn công cũng rất cao. Đây chính là ý nghĩa của thuật ngữ “sự hoàn thiện 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 mỗi slot. Các chuỗi không cố gắng đạt được sự hoàn thiện kinh tế, như Algorand, thường xuyên làm chính xác điều nàyTuy nhiên, vấn đề của cách tiếp cận này là nếu một kẻ tấn công kiểm soát 51% số lượng người xác thực, họ có thể thực hiện một cuộc tấn công (quay ngược lại một khối đã hoàn tất, hoặc kiểm duyệt, hoặc trì hoãn tính cuối cùng) với chi phí rất thấp: chỉ có một phần của các nút của họ trong ủy ban có thể bị phát hiện tham gia vào cuộc tấn công và bị phạt, dù thông quaslashinghoặcphân nhánh mềm được phối hợp xã hộiĐiều này có nghĩa là một kẻ tấn công có thể tấn công chuỗi nhiều lần, chỉ mất một phần nhỏ của số cổ phần của họ trong mỗi cuộc tấn công. Do đó, nếu chúng ta muốn sự kết thúc kinh tế, một phương pháp dựa trên ủy ban ngây thơ không hoạt động, và có vẻ như ngay từ cái nhìn đầu tiên, chúng ta cần toàn bộ bộ kiểm định viên tham gia.

Lý tưởng nhất, chúng tôi muốn bảo tồn tính chất kinh tế cuối cùng, đồng thời cải thiện tình trạng hiện tại ở hai lĩnh vực:

  1. Hoàn tất các khối trong một khe (lý tưởng là giữ hoặc thậm chí là giảm độ dài hiện tại của 12s), thay vì 15 phút
  2. Cho phép các nhà xác thực đặt cược với 1 ETH (giảm từ 32 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à “đưa các thuộc tính của Ethereum vào đúng với các blockchain L1 tập trung hơn về hiệu suất”.

Đầu tiên, nó đảm bảo rằng tất cả người dùng Ethereum thực sự hưởng lợi từ mức độ đảm bảo bảo mật cao hơn được đạt được thông qua cơ chế hoàn thiện. Ngày nay, hầu hết người dùng không, vì họ không muốn chờ đợi 15 phút; với sự hoàn thiện theo từng khe, người dùng sẽ thấy giao dịch của họ được hoàn tất gần như ngay khi chúng đượ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 cần lo lắng về khả năng chuỗi sẽ quay lại trừ khi trong trường hợp hiếm hoi.rò rỉ không hoạt động.

Mục tiêu thứ hai được chứng minh bởi mong muốn hỗ trợ người đặt cược độc lập. Cuộc thăm dò sau cuộc thăm dò 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à mức tối thiểu là 32 ETH. Việc giảm mức tối thiểu xuống còn 1 ETH sẽ giải quyết vấn đề này, đến mức mà các lo ngại khác trở thành yếu tố chính hạn chế việc đặt cược độc lập.

Có một thách thức: mục tiêu về việc hoàn tất nhanh hơn và việc đặt cược dân chủ hơn đều xung đột với mục tiêu giảm thiểu chi phí hoạt động. Và thực tế, đây chính là lý do tại sao chúng tôi không bắt đầu với việc hoàn tất đơn lẻ từ đầu. Tuy nhiên, nghiên cứu gần đây đưa ra một số hướng đi khả thi xung quanh vấn đề.

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

Single-slot finality involves using a consensus algorithm that finalizes blocks in one slot. This in itself is not a difficult goal: plenty of algorithms, such as sự đồng thuận Tendermint, đã thực hiện điều này với các thuộc tính tối ưu. Một thuộc tính mong muốn duy nhất của Ethereum, mà Tendermint không hỗ trợ, là rò rỉ không hoạt động, 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ố xác minh viên ngừng hoạt động. May mắn thay, mong muốn này đã được giải quyết: có đã có đề xuấtcải biên giao thức Tendermint để thích nghi với rò rỉ không hoạt động.

Một đề xuất về độ tin cậy duy nhất hàng đầu

Phần khó hơn của vấn đề là tìm cách làm cho việc hoàn thành một khe duy nhất hoạt động với một số lượng validator rất cao, mà không dẫn đến overhead của người vận hành nút cực kỳ cao. Đối với điều này, có một số giải pháp hàng đầu:

  • Tùy chọn 1: Brute force - làm việc chăm chỉ để triển khai các giao thức tổng hợp chữ ký tốt hơn, có khả năng sử dụng ZK-SNARK, điều này thực sự sẽ cho phép chúng tôi xử lý chữ ký từ hàng triệu trình xác thực trong mỗi vị trí.

Horn, một trong những mẫu thiết kế đề xuất cho một giao thức tổng hợp tốt hơn.

  • Option 2: Ban điều hành vòng quỹ- một cơ chế mới cho phép một ủy ban có quy mô trung bình được chọn ngẫu nhiên để chịu trách nhiệm cho việc hoàn thiện chuỗi, nhưng một cách giữ nguyên các tính chất về 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ở ra một không gian các lựa chọn thỏa hiệp theo một phổ từ x=0 (các hội đồng kiểu Algorand, không có tính kinh tế cuối cùng) đến x=1 (trạng thái hiện tại của Ethereum), mở ra các điểm ở giữa nơi Ethereum vẫn có đủ tính kinh tế cuối cùng để rất an toàn, nhưng đồng thời chúng ta cũng có được các lợi ích về hiệu quả khi chỉ cần một mẫu ngẫu nhiên cỡ trung bình của các validators tham gia mỗi khe thời gian.

Orbit tận dụng sự không đồng nhất có sẵn trong kích thước tiền gửi của trình xác thực để có được càng nhiều tính cuối cùng về kinh tế càng tốt, vẫn sẽ mang lại cho các trình xác nhận nhỏ một vai trò tương xứng. Ngoài ra, Orbit sử dụng luân chuyển ủy ban chậm để đảm bảo sự chồng chéo cao giữa các đại biểu liền kề, đảm bảo rằng tính cuối cùng kinh tế của nó vẫn áp dụng ở ranh giới chuyển đổi ủy ban.

  • Tùy chọn 3: giao thức giao cấp đôi - một cơ chế trong đó có hai lớp người stakeholder, một lớp có yêu cầu ký quỹ cao hơn và một lớp có yêu cầu ký quỹ thấp hơn. Chỉ có lớp ký quỹ cao hơn sẽ trực tiếp tham gia cung cấp tính kết thúc kinh tế. Có nhiều đề xuất (ví dụ, xem bài đăng về Rainbow staking) vì chính xác những quyền lợi và trách nhiệm mà hạng mục tiền gửi thấp có. Các ý tưởng phổ biến bao gồm:
    • quyền ủy quyền cược cho người chơi cấp cao hơn
    • một mẫu ngẫu nhiên của người chơi cấp thấp xác nhận, và cần thiết để hoàn tất, mỗi khối
    • quyền tạo ra danh sách bao gồm

Còn gì để làm, và phải đối mặt với những sự đánh đổi gì?

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

  1. Giữ nguyên trạng thái
  2. Brute-force SSF
  3. Orbit SSF
  4. SSF với việc đặt cược hai tầng

(1) có nghĩa là không làm việc gì cả và để lại việc đặt cọc như hiện tại, nhưng nó khiến cho trải nghiệm bảo mật và tính tập trung của Ethereum xấu đi so với những gì có thể.

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

(3) tránh "công nghệ cao" và giải quyết vấn đề bằng cách suy nghĩ lại thông minh xung quanh các giả định giao thức: chúng tôi nới lỏng yêu cầu "tính cuối cùng về kinh tế" để chúng tôi yêu cầu các cuộc tấn công phải tốn kém, nhưng ổn với chi phí tấn công có lẽ thấp hơn 10 lần so với hiện nay (ví dụ: chi phí tấn công 2,5 tỷ đô la thay vì 25 tỷ đô la). Đó là một quan điểm phổ biến rằng Ethereum ngày nay có nhiều tính cuối cùng về kinh tế hơn mức cần thiết và rủi ro bảo mật chính của nó là ở nơi khác, và vì vậy đây được cho là một sự hy sinh ổn để thực hiện.

Công việc chính cần làm là xác minh rằng cơ chế Orbit là an toàn và có những tính chất mà chúng ta muốn, sau đó hoàn toàn hóa và triển khai nó. Ngoài ra, EIP-7251 (tăng cường số dư hiệu quả tối đa)cho phép tổng hợp cân đối người xác minh tự nguyện ngay lập tức giảm bớt phần nào chi phí xác minh chuỗi, và hoạt động như một giai đoạn ban đầu hiệu quả cho việc triển khai Orbit.

(4) tránh sự suy nghĩ thông minh 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ó nguy cơ tập trung. Nguy cơ phụ thuộc nhiều vào quyền cụ thể mà tầng đặt cược thấp hơn nhận được. Ví dụ:

  • Nếu một người tham gia cấp thấp cần ủy quyền quyền chứng thực của mình cho một người tham gia cấp cao, thì việc ủy quyền có thể tập trung và do đó chúng ta sẽ kết thúc với hai cấp độ giao thức độ tập trung cao.
  • Nếu một mẫu ngẫu nhiên của tầng dưới là cần thiết để phê duyệt mỗi khối, thì kẻ tấn công có thể chi một lượng rất nhỏ ETH để chặn tính cuối cùng.
  • Nếu người stake cấp thấp chỉ có thể tạo danh sách bao gồm, thì tầng chứng thực có thể vẫn duy trì tính trung tâm, tại đó một cuộc tấn công 51% vào tầng chứng thực có thể kiểm duyệt chính danh sách bao gồm.

Có thể kết hợp nhiều chiến lược, ví dụ:

(1 + 2): sử dụng các kỹ thuật tấn công mạnh mẽ để giảm kích thước gửi tiền tối thiểu mà không cần thực hiện sự cuối cùng của một khe đơn lẻ. 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, vì vậy vấn đề trở nên dễ dàng hơn.

(1 + 3): thêm Orbit mà không thực hiện tính đến việc kết thúc một khe đơn lẻ

(2 + 3): thực hiện Orbit SSF với các tham số bảo thủ (ví dụ: 128k ủy ban xác nhận thay vì 8k hoặc 32k), và sử dụng các kỹ thuật tấn công mạnh mẽ để làm cho nó siêu hiệu quả.

(1 + 4): thêm rainbow staking mà không cần thực hiện việc hoàn thành từng khe đơn lẻ

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

Ngoài các lời ích khác, sự hoàn thành một khe duy nhất giảm thiệu rộng rào củacác loại tấn công MEV đa khối cụ thểNgoài ra, các thiết kế chia tách người chứng thực - người đề xuất và các đường ống sản xuất khối trong giao thức cần được thiết kế khác biệt trong một thế giới với tính kết thúc chỉ có một khe cắm.

Chiến lược vét cạn có điểm yếu là làm cho việc giảm thời gian khe càng khó khăn hơn.

Bầu cử lãnh đạo bí mật đơn lẻ

Vấn đề chúng tôi đang giải quyết là gì?

Hôm nay, người xác minh nào sẽ đề xuất khối tiếp theo đã biết trước. Điều này tạo ra một lỗ hổng bảo mật: một kẻ tấn công có thể theo dõi mạng, xác định xem người xác minh nào tương ứng với địa chỉ IP nào, và tấn công DoS vào mỗi người xác minh ngay khi họ chuẩn bị đề xuất một khối.

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

Cách tốt nhất để khắc phục vấn đề DoS là ẩn thông tin về validator nào sẽ tạo khối tiếp theo, ít nhất cho đến khi khối thực sự được tạo ra. Lưu ý rằng điều này 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 cứ ai tạo khối tiếp theo, nhưng yêu cầu randao revealít hơn 2256 / N. Trung bình, chỉ có một validator 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 không có. Kết hợp yêu cầu “bí mật” với yêu cầu “đơn lẻ” đã lâu là vấn đề khó khăn.

Các giao thức bầu cử lãnh đạo bí mật đơn giản giải quyết vấn đề này bằng cách sử dụng một số kỹ thuật mật mã để tạo ra một ID xác thực 'mù' cho mỗi người xác thực, sau đó cho nhiều người đề xuất cơ hội xáo trộn và làm cho các ID mù (điều này tương tự như cách một mixnet công trình). Trong mỗi khe, một ID mù ngẫu nhiên được chọn. Chỉ chủ sở hữu của ID bị mù đó mới có thể tạo bằng chứng hợp lệ để đề xuất chặn, nhưng không ai khác biết ID bị mù tương ứng với trình xác thực nào.

Whisk SSLE giao thức

Còn gì để làm, và phải đối mặt với những sự đánh đổi nào?

Một cách hợp lý, những gì còn lại là tìm kiếm và triển khai một giao thức đủ đơn giản để chúng tôi cảm thấy thoải mái khi triển khai trên mainnet. Chúng tôi rất trân trọng việc Ethereum là một giao thức tương đối đơn giản, và chúng tôi không muốn độ phức tạp tăng thêm. Các triển khai SSLE mà chúng tôi đã thấy thêm hàng trăm dòng mã cụ thể, và giới thiệu các giả thuyết mới trong mật mã phức tạp. Việc tìm ra một triển khai SSLE đủ hiệu quả chống lại quantum cũng là một vấn đề mở.

Có thể xảy ra trường hợp phức tạp được giới thiệu bởi SSLE chỉ giảm đủ khi chúng ta tiến xa và giới thiệu máy móc để thực hiện chứng minh không cần biết một cách tổng quát vào giao thức Ethereum tại L1 vì các lý do khác (ví dụ: cây trạng thái, ZK-EVM).

Một lựa chọn thay thế khác là đơn giản là không quan tâm đến SSLE, và sử dụng các biện pháp giảm nhẹ ngoài giao thức (ví dụ ở tầng p2p) để giải quyết các vấn đề DoS.

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

Nếu chúng ta thêm một cơ chế phân biệt người chứng thực - người đề xuất (APS), ví dụ.vé thực thi, sau đó các khối thực thi (tức là các khối chứa giao dịch Ethereum) sẽ không cần SSLE, vì chúng ta có thể tin cậy vào người xây dựng khối là chuyên nghiệp. Tuy nhiên, chúng ta vẫn sẽ được lợi từ SSLE cho các khối đồng thuận (tức là các khối chứa các thông điệp giao thức như các chứng nhận, có lẽ là các phần của danh sách bao gồm, v.v.).

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

Vấn đề chúng ta đang giải quyết là gì?

Có giá trị trong Ethereum’sthời gian xác nhận giao dịch giảm thêm, từ 12 giây xuống còn 4 giây chẳng hạn. Việc làm này sẽ cải thiện đáng kể trải nghiệm người dùng cả đối với L1 lẫn các rollups dựa trên, đồng thời làm cho giao thức defi hiệu quả hơn. Nó cũng sẽ làm cho việc phân quyền cho L2 dễ dàng hơn, vì nó sẽ cho phép một lớp lớn ứng dụng L2 hoạt động trên Bản tổng hợp dựa trên, giảm nhu cầu xây dựng ủy ban phi tập trung của riêng họ cho việc xếp hàng phi tập trung.

Điều này là gì và nó hoạt động như thế nào?

Có rộng rãi hai gia đình kỹ thuật ở đây:

  1. Giảm thời gian khe cắm, xuống còn ví dụ. 8 giâyhoặc 4 giây. Điều này không nhất thiết phải có nghĩa là sự cố định trong vòng 4 giây: sự cố định vốn cần ba vòng giao tiếp, và vì vậy chúng ta có thể làm cho mỗi vòng giao tiếp là một khối riêng biệt, điều này sau 4 giây sẽ nhận được ít nhất là một xác nhận dự bị.
  2. Cho phép người đề xuất công bố các bản xác nhận trước trong suốt một khe. Ở mức cực đoan, một người đề xuất có thể bao gồm các giao dịch mà họ thấy vào khối của họ trong thời gian thực và ngay lập tức công bố một 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à 0×1234…", "Giao dịch thứ hai của tôi là 0×5678…"). Trường hợp một người đề xuất công bố hai thông báo xác nhận xung đột có thể được xử lý theo hai cách: (i) bằng cách cắt giảm số lượng người đề xuất, hoặc (ii) bằng cách sử dụng các người chứng thực để bỏ phiếu cho cái nào được thực hiện trước.

Còn gì cần làm, và phải đối mặt với những điều đổi lấy điều gì?

Chưa rõ việc rút ngắn thời gian khe cắm có thực sự thực tế hay không. Ngay cả ngày nay, người stakeholder ở nhiều khu vực trên thế giới đều gặp khó khăn khi cố gắng bao gồm xác nhận nhanh chóng đủ. Cố gắng chạy 4 giây khe cắm có nguy cơ tập trung bộ kiểm tra, và khiến việc trở thành bộ kiểm tra bên ngoài một số địa lý đặc quyền trở nên không thực tế do độ trễ. Cụ thể, chuyển sang 4 giây khe cắm sẽ đòi hỏi rút ngắn giới hạn về độ trễ mạng ("delta") xuống hai giây.

Phương pháp đề xuất trước có điểm yếu là nó có thể cải thiện đáng kể thời gian bao gồm trường hợp trung bình, nhưng không phải là 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 của bạn sẽ được xác nhận trước trong 0,5 giây thay vì được bao gồm trong (trung bình) 6 giây, nhưng nếu người đề xuất hiện tại không hoạt động hoặc không hoạt động tốt, bạn vẫn phải chờ đợi lên đến 12 giây đầy đủ cho khe tiếp theo bắt đầu và cung cấp một người đề xuất mới.

Ngoài ra, có một câu hỏi mở về cách xác nhận trước sẽ được khuyến khích. Người đề xuất có động lực để tối đa hóa tính tùy chọn của họ càng lâu càng tốt. Nếu người đính kèm ký vào tính kịp thời của xác nhận trước, thì người gửi giao dịch có thể thực hiện một phần phí có điều kiện xác nhận trước ngay lập tức, nhưng điều này sẽ gây thêm gánh nặng cho người đính kèm và có khả năng gây khó khăn hơn cho người đính kèm để 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 thử nghiệm điều này và giữ thời gian kết thúc ở 12 giây (hoặc lâu hơn), hệ sinh thái sẽ đặt trọng lượng lớn hơn vào các cơ chế xác nhận trước được tạo ra bởi lớp 2, và tương tác giữa các lớp 2 sẽ mất thời gian hơn.

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

Các xác nhận trước dựa vào người đề xuất thực tế phụ thuộc vào cơ chế phân tách người chứng nhận-người đề xuất (APS), ví dụ như.vé thực thiNế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 nhà xác thực thông thường.

Chính xác như thế nào thời gian khe cắm ngắn có thể phụ thuộc vào cấu trúc khe cắm, mà phụ thuộc nặng nề vào những phiên bản của APS, danh sách bao gồm, v.v chúng ta kết thúc triển khai. Có cấu trúc khe cắm chứa ít vòng và do đó thân thiện hơn với thời gian khe cắm ngắn, nhưng họ thực hiện sự đá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 cuộc tấn công 51%

Thường có một giả định rằng nếu một cuộc tấn công 51% xảy ra (bao gồm cả các cuộc tấn công không thể chứng minh bằng mật mã, như kiểm duyệt), cộng đồng sẽ đoàn kết để thực hiện một phần đa soft forkđảm bảo rằng những người tốt sẽ chiến thắng, và những người xấu sẽ bị rò rỉ hoặc bị trừng phạt vì 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ó thể đượ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 lớp xã hội bằng cách làm cho quá trình phục hồi tự động hóa càng nhiều càng tốt.

Toàn bộ việc tự động hoàn toàn không thể, vì nếu như vậy, điều đó sẽ được tính là một thuật toán đồng thuận chịu lỗi >50%, và chúng ta đã biết rằng (rất hạn chế)các hạn chế có thể chứng minh toán học của những loại thuật toán đóNhưng chúng ta có thể đạt được sự tự động hóa một phần: ví dụ, một khách hàng có thể tự động từ chối chấp nhận một chuỗi là đã hoàn thiện, hoặc thậm chí là đầu của lựa chọn khối phân nhánh, nếu nó kiểm duyệt các giao dịch mà khách hàng đã thấy đủ lâu. Một mục tiêu quan trọng là đảm bảo rằng những kẻ xấu trong một cuộc tấn công ít nhất là không thể dễ dàng chiến thắng sạch sẽ.

Tăng ngưỡng quorum

Ngày nay, một khối hoàn tất nếu 67% người đặt cược ủng hộ nó. Có ý kiến cho rằng điều này là quá hung hăng. Chỉ có một thất bại cuối cùng (rất ngắn) trong toàn bộ lịch sử của Ethereum. Nếu tỷ lệ này được tăng lên, ví dụ. đến 80%, sau đó số lượng thời gian 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 thuộ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 dừng tính cuối cùng. Đây có vẻ là một tình huống lành mạnh hơn nhiều so với "bên sai" nhận được chiến thắng ngay lập tức, cả khi bên sai là kẻ tấn công và khi đó là khách hàng có lỗi.

Điều này cũng đưa ra câu trả lời cho câu hỏi “điểm mấu chốt của người đặt cược đơn”? Ngày nay, hầu hết người đặt cược đang đặt cược thông qua các nhóm, và có vẻ rất không thể để có được người đặt cược đơn lên đến 51% ETH đã cược. Tuy nhiên, việc đưa người đặt cược đơn lên thành một phần nhỏ chặn quyền biểu quyết, đặc biệt nếu quyền biểu quyết là 80% (vì vậy một phần nhỏ chặn quyền biểu quyết chỉ cần 21%) có vẻ có thể đạt được nếu chúng ta làm việc chăm chỉ. Miễn là người đặt cược đơn không tham gia vào cuộc tấn công 51% (dù là đảo ngược tính chất cuối cùng hoặc kiểm duyệt), một cuộc tấn công như vậy sẽ không có được một “chiến thắng sạch sẽ”, và người đặt cược đơn sẽ được động viên để giúp tổ chức một cuộc nâng cấp mềm của phần nhỏ chặn quyền biểu quyết.

Lưu ý rằng có sự tương tác giữa ngưỡng quorum và cơ chế Orbit: nếu chúng ta kết thúc việc sử dụng Orbit, thì điều gì chính xác là “21% số người stake” sẽ trở thành một câu hỏi phức tạp hơn, và sẽ phần nào phụ thuộc vào phân phối của các validators.

Kháng chiến lược lượng tử

Metaculus hiện tại tin rằng, mặc dù có các thanh ghi lỗi rộng, rằng máy tính lượng tử có khả năng bắt đầu phá vỡ mật mã vào khoảng thập kỷ 2030:

Các chuyên gia về máy tính lượng tử như Scott Aaronson cũng đã bắt đầu xem xét khả năng các máy tính lượng tử thực sự hoạt động trong trung hạn nghiêm túc hơn nhiều. Điều này có hậu quả trên toàn bộ lộ trình Ethereum: điều này có nghĩa là mỗi phần của giao thức Ethereum hiện tại phụ thuộc vào các đường cong elliptic sẽ cần phải có một phương thức thay thế dựa trên băm hoặc chống lại quantum. Điều này đặc biệt có nghĩa là chúng ta không thể giả định rằng chúng ta sẽ có thể dựa vào các đặc tính xuất sắc của việc tổng hợp BLS để xử lý chữ ký từ một bộ xác thực lớn mãi mãi. Điều này biện minh cho chủ nghĩa bảo thủ trong các giả định xung quanh hiệu suất của các thiết kế bằng chứng cổ phần, và cũng là một nguyên nhân để chủ động hơn để phát triển các lựa chọn thay thế kháng lượng tử.

Disclaimer:

  1. Bài viết này được sao chép từ [ Vitalik Buterin]Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Học cửađội, và họ sẽ xử lý nhanh chóng.
  2. Bản pháp lý từ chối trách nhiệm: Các quan điểm được thể hiện trong bài viết này chỉ thuộc về tác giả và không hề cung cấp bất kỳ lời khuyên đầu tư nào.
  3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500