Tôi đang ngồi đây viết điều này vào ngày cuối cùng của một sự tương tác giữa các nhà phát triển Ethereum tại Kenya, nơi chúng tôi đã đạt được một lượng lớn tiến triển trong việc triển khai và làm rõ các chi tiết kỹ thuật của các cải tiến quan trọng của Ethereum sắp tới, đặc biệt là PeerDAS , các Chuyển đổi cây Verklevà các phương pháp phân quyền lưu trữ lịch sử trong bối cảnh củaEIP 4444Từ góc nhìn của riêng tôi, cảm giác như tốc độ phát triển của Ethereum, và khả năng của chúng tôi để triển khai các tính năng lớn và quan trọng giúp cải thiện trải nghiệm một cách đáng kể cho các nhà điều hành node và người dùng (L1 và L2), đang tăng lên.

Các nhóm phát triển Ethereum cùng nhau làm việc để triển khai Pectra devnet.

Với khả năng kỹ thuật lớn hơn, một câu hỏi quan trọng cần đặt ra là: chúng ta đang xây dựng hướng tới những mục tiêu đúng đắn không? Một gợi ý để suy nghĩ về điều này là một loạt các tweets không hạnh phúc gần đây từ nhà phát triển lõi Geth lâu năm Peter Szilagyi:

Đây là những mối quan tâm hợp lệ. Đó là những mối quan tâm mà nhiều người trong cộng đồng Ethereum đã thể hiện. Đó là những mối quan tâm mà tôi cá nhân đã từng có trên nhiều dịp. Tuy nhiên, tôi cũng không nghĩ rằng tình hình đến nỗi tuyệt vọng như những bài đăng trên Twitter của Peter ngụ ý; thay vào đó, nhiều mối quan tâm đã được giải quyết thông qua các tính năng giao thức đang được triển khai và nhiều vấn đề khác có thể được giải quyết thông qua các điều chỉnh rất thực tế trên lộ trình hiện tại.

Để hiểu ý nghĩa thực tế của điều này, chúng ta hãy đi qua ba ví dụ mà Peter cung cấp một cách cụ thể. Mục tiêu không phải là tập trung vào Peter cụ thể; đó là những lo ngại mà rất nhiều thành viên cộng đồng chia sẻ rộng rãi, và quan trọng là phải đối diện với chúng.

MEV, và sự phụ thuộc vào người xây dựng

Trong quá khứ, các khối Ethereum được tạo ra bởi các thợ đào, họ sử dụng một thuật toán tương đối đơn giản để tạo ra các khối. Người dùng gửi giao dịch đến một mạng p2p công cộng thường được gọi là “mempool” (hoặc “txpool”). Các thợ đào lắng nghe mempool và chấp nhận các giao dịch hợp lệ và trả phí. Họ bao gồm các giao dịch mà họ có thể, và nếu không đủ không gian, họ ưu tiên theo phí cao nhất trước.

Đây là một hệ thống rất đơn giản và thân thiện với phân cấp: như một người đào, bạn chỉ cần chạy phần mềm mặc định, và bạn có thể nhận được cùng mức thu nhập phí từ một khối mà bạn có thể nhận được từ các trang trại đào tạo chuyên nghiệp. Tuy nhiên, vào khoảng năm 2020, mọi người bắt đầu lợi dụng những gì được gọi là giá trị khai thác của người đào (MEV): thu nhập chỉ có thể được đạt được thông qua việc thực hiện các chiến lược phức tạp mà nhận thức được các hoạt động diễn ra bên trong các giao protocô defi khác nhau.

Ví dụ, hãy xem xét các sàn giao dịch phi tập trung như Uniswap. Giả sử rằng vào thời điểm T, tỷ lệ trao đổi USD/ETH - trên các sàn giao dịch tập trung và trên Uniswap - là $3000. Vào thời điểm T+11, tỷ lệ trao đổi USD/ETH trên các sàn giao dịch tập trung tăng lên $3005. Nhưng Ethereum vẫn chưa có khối tiếp theo. Vào thời điểm T+12, nó có. Người tạo khối có thể làm cho giao dịch đầu tiên của họ là một loạt mua trên Uniswap, mua hết ETH có sẵn trên Uniswap với giá từ $3000 đến $3004. Đây là doanh thu bổ sung, và được gọi là MEV. Các ứng dụng khác ngoài DEXes cũng có các vấn đề tương tự. Flash Boys 2.0 paperđược xuất bản vào năm 2019 đi vào chi tiết này.

Một biểu đồ từ bài báo Flash Boys 2.0 cho thấy lượng doanh thu có thể thu được bằng cách sử dụng các phương pháp được mô tả ở trên.

Vấn đề là điều này phá vỡ cốt truyện về lý do tại sao việc khai thác (hoặc, sau năm 2022, đề xuất khối) có thể là "công bằng": bây giờ, các nhà sản xuất lớn có khả năng tối ưu hóa các thuật toán khai thác loại này có thể nhận được lợi nhuận tốt hơn mỗi khối.

Kể từ đó đã có một cuộc tranh luận giữa hai chiến lược, mà tôi sẽ gọi là giảm thiểu MEV và cách ly MEV. Việc giảm thiểu MEV có hai hình thức: (i) làm việc mạnh mẽ trên các lựa chọn không có MEV cho Uniswap (ví dụ, Hoán đổi bò) và (ii) xây dựng các kỹ thuật trong giao thức, như mempools được mã hóa, giảm thông tin có sẵn cho các nhà sản xuất khối, và do đó giảm doanh thu mà họ có thể thu được. Cụ thể, mempools được mã hóa ngăn chặn các chiến lược như tấn công sandwich, đặt giao dịch ngay trước và sau giao dịch của người dùng để khai thác tài chính từ họ ("front-running").

MEV quarantining works by accepting MEV, but trying to limit its impact on staking centralization by separating the market into two kinds of actors: validators are responsible for attesting and proposing blocks, but the task of choosing the block’s contents gets outsourced to specialized builders through an auction protocol. Individual stakers now no longer need to worry about optimizing defi arbitrage themselves; they simply join the auction protocol, and accept the highest bid. This is called proposer/builder separation (PBS). This approach has precedents in other industries: a major reason why restaurants are able to remain so decentralized is that they often rely on a fairly concentrated set of providers for various operations that do have large economies of scale. So far, PBS has been reasonably successful at ensuring that small validators and large validators are on a fair playing field, at least as far as MEV is concerned. However, it creates another problem: the task of choosing which transactions get included becomes more concentrated.

Quan điểm của tôi về điều này luôn là giảm thiểu MEV là tốt và chúng ta nên theo đuổi nó (cá nhân tôi sử dụng Cowswap thường xuyên!) - mặc dù các mempool được mã hóa có rất nhiều thách thức, nhưng giảm thiểu MEV có thể sẽ không đủ; MEV sẽ không giảm xuống 0, hoặc thậm chí gần bằng không. Do đó, chúng ta cũng cần một số loại cách ly MEV. Điều này tạo ra một nhiệm vụ thú vị: làm thế nào để chúng ta làm cho "hộp cách ly MEV" càng nhỏ càng tốt? Làm thế nào để chúng ta cung cấp cho các nhà xây dựng ít năng lượng nhất có thể, trong khi vẫn giữ cho họ có khả năng hấp thụ vai trò tối ưu hóa chênh lệch giá và các hình thức thu thập MEV khác?

Nếu những người xây dựng có quyền loại bỏ giao dịch khỏi một khối hoàn toàn, sẽ có những cuộc tấn công có thể mọc lên khá dễ dàng. Giả sử rằng bạn có một vị trí nợ thế chấp (CDP)Trong một giao thức defi, được hỗ trợ bởi một tài sản mà giá đang giảm nhanh. Bạn muốn tăng tài sản đảm bảo hoặc thoát khỏi CDP. Những người xây dựng độc hại có thể cố gắng kết hợp để từ chối bao gồm giao dịch của bạn, làm trễ nó cho đến khi giá giảm đủ để họ có thể buộc phải thanh lý CDP của bạn. Nếu điều đó xảy ra, bạn sẽ phải trả một khoản phạt lớn, và những người xây dựng sẽ nhận được một phần lớn của nó. Vậy làm thế nào để ngăn người xây dựng loại trừ giao dịch và thực hiện những loại tấn công này?

Đây là nơi mà danh sách bao gồm đến.

Nguồn: bài đăng này trên ethresear.ch.

Danh sách bao gồm cho phép người đề xuất khối (nghĩa là người đặt cược) chọn giao dịch cần phải vào khối. Người xây dựng vẫn có thể sắp xếp lại các giao dịch hoặc chèn các giao dịch của riêng họ, nhưng họ phải bao gồm các giao dịch của người đề xuất. Cuối cùng, danh sách bao gồm đã được sửa đổiđể hạn chế khối tiếp theo thay vì khối hiện tại. Trong cả hai trường hợp, họ đã lấy đi khả năng của người xây dựng để đẩy giao dịch ra khỏi khối hoàn toàn.

Tất cả những điều trên đều là một cái hang thỏ sâu về nền tảng phức tạp. Nhưng MEV là một vấn đề phức tạp; thậm chí cả mô tả trên bỏ sót rất nhiều sắc thái quan trọng. Như câu ca dao cũ, "bạn có thể không tìm kiếm MEV, nhưng MEV đang tìm bạn". Các nhà nghiên cứu Ethereum đã khá đồng thuận về mục tiêu "tối thiểu hóa hộp cách ly", giảm thiểu thiệt hại mà những người xây dựng có thể gây ra (ví dụ, bằng cách loại trừ hoặc trì hoãn giao dịch như một cách tấn công vào các ứng dụng cụ thể) càng nhiều càng tốt.

Tuy nhiên, tôi nghĩ rằng chúng ta có thể đi xa hơn nữa. Lịch sử cho thấy, danh sách bao gồm thường được hiểu như là một "tính năng đặc biệt nằm ngoài lề": thông thường, bạn sẽ không nghĩ đến chúng, nhưng chỉ để phòng trường hợp những người xây dựng độc hại bắt đầu làm những điều điên rồ, chúng cung cấp cho bạn một "con đường thứ hai". Thái độ này được phản ánh trong các quyết định thiết kế hiện tại: trong EIP hiện tại, giới hạn gas của một danh sách bao gồm khoảng 2,1 triệu. Nhưng chúng ta có thể thực hiện một sự chuyển đổi triết học trong cách chúng ta nghĩ về danh sách bao gồm: hãy coi danh sách bao gồm như là khối, và hãy coi vai trò của người xây dựng là một chức năng phụ bên cạnh để thêm một số giao dịch để thu thập MEV. Làm sao nếu người xây dựng mới là người có giới hạn gas 2,1 triệu?

Tôi nghĩ rằng những ý tưởng trong hướng này - thực sự thúc đẩy việc làm cho hộp cách ly trở nên càng nhỏ càng tốt - rất thú vị, và tôi ủng hộ việc đi theo hướng đó. Điều này là một sự thay đổi so với 'triết lý thời đại 2021': trong triết lý thời đại 2021, chúng ta đã phấn khích hơn với ý tưởng rằng, vì chúng ta có các nhà xây dựng bây giờ, chúng ta có thể 'quá tải' chức năng của họ và có họ phục vụ người dùng theo cách phức tạp hơn, ví dụ, bằng cách hỗ trợ Thị trường phí ERC-4337Trong triết lý mới này, các phần xác minh giao dịch của ERC-4337 sẽ phải được thụ vào giao thức. May mắn thay, nhóm ERC-4337 đã @yoav/AA-roadmap-May-2024#Native-AA---a-modular-roadmap">ngày càng ấm áp với hướng đi này.

Tóm tắt: Ý tưởng MEV đã đang quay trở lại hướng tăng cường cho các nhà sản xuất khối, bao gồm việc cho phép các nhà sản xuất khối có quyền trực tiếp đảm bảo việc bao gồm các giao dịch của người dùng. Những đề xuất về trừu tượng tài khoản đã quay trở lại hướng loại bỏ sự phụ thuộc vào các bên trung gian tập trung, thậm chí cả người gói. Tuy nhiên, có một lập luận tốt rằng chúng ta chưa đi đủ xa, và tôi nghĩ áp lực thúc đẩy quá trình phát triển tiến xa hơn trong hướng đó là rất hoan nghênh.

Liquid staking

Hiện nay, người solo stakers chỉ chiếm một tỷ lệ nhỏ trong tổng số Ethereum đang giao dịch, và hầu hết việc giao dịch được thực hiện bởi các nhà cung cấp khác nhau - một số là các nhà điều hành trung tâm, và một số khác là các DAO, như Lido và RocketPool.

Tôi đã tự tìm hiểu - các cuộc thăm dò khác nhau [1] [2], khảo sát, trò chuyện trực tiếp, đặt câu hỏi “tại sao bạn - cụ thể là bạn - không tham gia solo staking hôm nay?” Đối với tôi, một hệ sinh thái solo staking mạnh mẽ là kết quả mà tôi ưa thích nhất cho Ethereum staking, và một trong những điều tốt nhất về Ethereum là chúng ta thực sự cố gắng hỗ trợ một hệ sinh thái solo staking mạnh mẽ thay vì chỉ đầu hàng cho việc ủy quyền. Tuy nhiên, chúng ta vẫn còn rất xa đến kết quả đó. Trong các cuộc khảo sát và bình chọn của tôi, có một số xu hướng nhất định:

1. Đa số người không tham gia độc lập trong việc đặt cược đều cho biết lý do chính của họ là mức tối thiểu 32 ETH.
2. Trong số những người trích dẫn lý do khác, lý do cao nhất là thách thức kỹ thuật của việc chạy và duy trì một nút xác thực.
3. Sự mất mát của việc sẵn có ngay lập tức của ETH, các rủi ro về bảo mật của các khóa riêng 'nóng', và sự mất mất khả năng tham gia đồng thời vào các giao thức defi, đều là những vấn đề quan trọng nhưng nhỏ hơn.

Những lý do chính tại sao mọi người không tự gửi cược, theo cuộc thăm dò của Farcaster.

Có hai câu hỏi chính mà nghiên cứu về staking cần giải quyết:

1. Làm thế nào chúng ta giải quyết những lo ngại này?
2. Nếu, mặc dù có các giải pháp hiệu quả cho hầu hết những vấn đề này, hầu hết mọi người vẫn không muốn đầu tư độc lập, chúng ta phải làm thế nào để giữ cho giao thức ổn định và mạnh mẽ chống lại các cuộc tấn công mặc dù điều đó?

Nhiều mục tiêu nghiên cứu và phát triển đang được đặt mục tiêu chính xác vào việc giải quyết những vấn đề này:

1. cây VerkleplusEIP-4444cho phép các nút đặt cược hoạt động với yêu cầu ổ cứng rất thấp. Ngoài ra, chúng cho phép các nút đặt cược đồng bộ hóa gần như ngay lập tức, đơn giản hóa quá trình thiết lập, cũng như các hoạt động như chuyển từ một triển khai sang triển khai khác. Chúng cũng khiến cho các khách hàng nhẹ Ethereum trở nên khả thi hơn nhiều, bằng cách giảm băng thông dữ liệu cần thiết để cung cấp chứng minh cho mọi truy cập trạng thái.
2. Nghiên cứu (ví dụ những đề xuất này)vào cách cho phép một tập hợp người xác thực lớn hơn nhiều (cho phép mức tối thiểu cược nhỏ hơn nhiều) đồng thời giảm overhead nút đồng thuận. Những ý tưởng này có thể được triển khai như một phần của độ tin cậy khe duy nhất. Việc này cũng khiến cho các máy khách nhẹ an toàn hơn, vì họ sẽ có thể xác minh toàn bộ bộ chữ ký thay vì phụ thuộc vào ủy ban đồng bộ).
3. Việc tối ưu hóa liên tục của máy khách Ethereum tiếp tục giảm chi phí và độ khó của việc chạy một nút xác minh, mặc dù lịch sử ngày càng phát triển.
4. Nghiên cứu vềhình phạt giới hạncó thể giảm thiểu các lo ngại về rủi ro khóa riêng tư và làm cho việc đặt cược ETH của họ vào các giao protocal defi đồng thời nếu họ muốn.
5. 0x01 Withdrawal credentialscho phép người đặt cược đặt địa chỉ ETH làm địa chỉ rút tiền của họ. Điều này làm cho các hồ bơi đặt cược phi tập trung trở nên khả thi hơn, giúp họ có lợi thế so với các hồ bơi đặt cược tập trung.

Tuy nhiên, một lần nữa có thêm điều chúng ta có thể làm. Lí thuyết cho phép các nhà xác minh rút tiền nhanh hơn nhiều: Casper FFG vẫn an toàn ngay cả khi bộ xác minh thay đổi một vài phần trăm mỗi khi hoàn tất (tức là mỗi kỷ nguyên). Do đó, chúng ta có thể giảm thời gian rút tiền nhiều hơn nếu chúng ta cố gắng vào đó. Nếu chúng ta muốn giảm kích thước tiền gửi tối thiểu một cách đáng kể, chúng ta có thể đưa ra quyết định khó khăn để đánh đổi ở các hướng khác, ví dụ nếu chúng ta tăng thời gian hoàn tất lên 4 lần, điều đó sẽ cho phép một @VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">Giảm kích thước tiền gửi tối thiểu 4 lần. Sự hoàn tất của từng khe sau này sẽ loại bỏ hoàn toàn mô hình “mỗi người gửi tham gia vào mỗi thời kỳ".

Một phần quan trọng khác của toàn bộ câu hỏi này là tính kinh tế của việc đặt cược. Một câu hỏi quan trọng là: chúng ta có muốn đặt cọc là một hoạt động tương đối thích hợp hay chúng ta muốn tất cả mọi người hoặc hầu hết mọi người đặt cược tất cả ETH của họ? Nếu tất cả mọi người đang đặt cược, thì trách nhiệm mà chúng tôi muốn mọi người đảm nhận là gì? Nếu mọi người cuối cùng chỉ đơn giản là ủy thác trách nhiệm này vì họ lười biếng, điều đó có thể dẫn đến tập trung. Có những câu hỏi triết học quan trọng và sâu sắc ở đây. Câu trả lời không chính xác có thể dẫn Ethereum xuống con đường tập trung hóa và "tái tạo hệ thống tài chính truyền thống với các bước bổ sung"; Câu trả lời đúng có thể tạo ra một ví dụ sáng chói về một hệ sinh thái thành công với một tập hợp rộng lớn và đa dạng các người đặt cọc một mình và các nhóm đặt cọc phi tập trung cao. Đây là những câu hỏi liên quan đến kinh tế và giá trị cốt lõi của Ethereum, và vì vậy chúng ta cần sự tham gia đa dạng hơn ở đây.

Yêu cầu phần cứng của các nút

Nhiều câu hỏi then chốt trong việc phân quyền Ethereum cuối cùng lại dẫn đến một câu hỏi đã định nghĩa cho chính trị blockchain trong một thập kỷ: mức độ truy cập mà chúng ta muốn làm cho việc chạy một nút trở nên như thế nào, và như thế nào?

Hôm nay, việc chạy một node là khó khăn. Đa số mọi người không thực hiện điều đó. Trên chiếc laptop mà tôi đang sử dụng để viết bài viết này, tôi có một Ethernode, và nó chiếm 2.1 terabyte - đã là kết quả của kỹ thuật phần mềm và tối ưu hóa anh hùng. Tôi cần đi mua thêm ổ cứng 4 TB để đặt vào laptop của mình để lưu trữ node này. Chúng tôi đều muốn việc chạy node trở nên dễ dàng hơn. Trong thế giới lý tưởng của tôi, mọi người sẽ có thể chạy node trên điện thoại của họ.

Như tôi đã viết ở trên, EIP-4444 và cây Verkle là hai công nghệ chính giúp chúng ta tiến gần hơn tới mục tiêu này. Nếu cả hai đều được triển khai, yêu cầu về phần cứng của một nút có thể có khả năng giảm dần xuống dưới một trăm gigabyte, và có lẽ gần như bằng không nếu chúng ta loại bỏ trách nhiệm lưu trữ lịch sử (có lẽ chỉ dành cho các nút không tham gia đặt cược) hoàn toàn.Loại 1 ZK-EVMssẽ loại bỏ nhu cầu chạy tính toán EVM của bạn, bởi bạn có thể thay vào đó đơn giản là xác minh một bằng chứng rằng việc thực thi là chính xác. Trong thế giới lý tưởng của tôi, chúng tôi xếp các công nghệ này cùng nhau, và thậm chí cả các ví mở rộng trình duyệt Ethereum (ví dụ Metamask, Rabby) có một node tích hợp có khả năng xác minh các bằng chứng này, thực hiện mẫu dữ liệu có sẵn, và hài lòng rằng chuỗi là chính xác.

Tầm nhìn được mô tả ở trên thường được gọi là “The Verge”.

Tất cả đều được biết và hiểu, ngay cả bởi những người đang đặt ra lo ngại về kích thước nút Ethereum. Tuy nhiên, có một lo ngại quan trọng: nếu chúng ta chuyển giao trách nhiệm duy trì trạng thái và cung cấp bằng chứng, thì liệu đó có phải là một vector tập trung hóa không? Ngay cả khi họ không thể gian lận bằng cách cung cấp dữ liệu không hợp lệ, liệu điều đó có phải là đối lập với nguyên tắc của Ethereum khi trở nên quá phụ thuộc vào họ không?

Một phiên bản gần đây của mối quan ngại này là sự không thoải mái của rất nhiều người đối với EIP-4444: nếu các nút Ethereum thông thường không cần lưu trữ lịch sử cũ nữa, thì ai cần? Một câu trả lời phổ biến là: chắc chắn có đủ nhiều nhà diễn viên lớn (ví dụ: khám phá khối, sàn giao dịch, lớp 2) có động cơ để giữ dữ liệu đó, và so với 100 petabyte được lưu trữ bởi Máy Wayback, chuỗi Ethereum nhỏ bé. Vì vậy, việc nghĩ rằng bất kỳ lịch sử nào sẽ thực sự bị mất là điều ngớ ngẩn.

Tuy nhiên, lập luận này dựa vào sự phụ thuộc vào một số lượng nhỏ các nhà hoạt động lớn. Trong phân loại các mô hình tin cậy, đó là một giả định 1 trên N, nhưng N khá nhỏ. Điều này có những rủi ro đuôi. Một điều chúng ta có thể làm thay vì là lưu trữ lịch sử cũ trong một mạng ngang hàng, nơi mỗi nút chỉ lưu trữ một phần trăm nhỏ dữ liệu. Loại mạng này vẫn đủ sao chép đảm bảo tính chắc chắn: sẽ có hàng ngàn bản sao của mỗi mảnh dữ liệu, và trong tương lai chúng ta có thể sử dụng mã hóa xóa (hiện thực, bằng cách đưa lịch sử vàoEIP-4844-style blobs, mà đã tích hợp mã hóa xóa trước) để tăng tính mạnh mẽ hơn.

Blobs có mã hóa xóa trong các blobs và giữa các blobs. Cách dễ nhất để tạo lưu trữ siêu mạnh mẽ cho toàn bộ lịch sử Ethereum có thể chỉ đơn giản là đưa các khối beacon và thực thi vào các blobs.Nguồn hình ảnh: codex.storage

Trong một thời gian dài, công việc này đã được để lại phía sau; Mạng CổngTuy nhiên, thực tế là nó chưa nhận được mức độ chú ý phù hợp với tầm quan trọng của Ethereum trong tương lai. May mắn thay, hiện nay đã có sự quan tâm mạnh mẽ hướng đến việc đưa thêm nhiều tài nguyên vào một phiên bản tối giản của Cổng mà tập trung vào việc lưu trữ phân tán và tiện ích của lịch sử. Đà này nên được xây dựng, và chúng ta nên cố gắng triển khai EIP-4444 sớm, kết hợp với một mạng lưới ngang hàng phân cấp mạnh mẽ để lưu trữ và truy xuất lịch sử cũ.

Với trạng thái và ZK-EVMs, cách tiếp cận phân phối này khó hơn. Để xây dựng một khối hiệu quả, bạn chỉ cần có toàn bộ trạng thái. Trong trường hợp này, cá nhân tôi ủng hộ một cách tiếp cận thực dụng: chúng ta xác định và tuân thủ một mức yêu cầu phần cứng cần thiết để có một “nút làm tất cả mọi thứ”, cao hơn so với chi phí (lý tưởng là ngày càng giảm) của việc chỉ việc kiểm tra chuỗi, nhưng vẫn đủ thấp để phù hợp với người làm theo sở thích. Chúng ta dựa vào giả định 1 trên N, nơi chúng ta đảm bảo rằng N là khá lớn. Ví dụ, điều này có thể là một laptop tiêu dùng cao cấp.

Chứng minh ZK-EVM có thể sẽ là phần khó nhất, và các công cụ chứng minh ZK-EVM thời gian thực có thể sẽ cần phần cứng mạnh mẽ hơn đáng kể so với một nút lưu trữ, ngay cả với sự tiến bộ như Binius, và giới hạn trường hợp xấu nhất với khí đa chiềuChúng tôi có thể làm việc chăm chỉ trên mạng lưới chứng minh phân tán, nơi mỗi nút đảm nhận trách nhiệm chứng minh ví dụ 1 phần trăm của việc thực thi một khối, sau đó người tạo khối chỉ cần tổng hợp trăm chứng minh vào cuối. Cây tổng hợp chứng minh có thể giúp thêm. Nhưng nếu điều này không hoạt động tốt, thì một sự thoả hiệp khác sẽ là cho phép yêu cầu về phần cứng của việc chứng minh trở nên cao hơn, nhưng đảm bảo rằng một “nút làm tất cả” có thể xác minh các khối Ethereum trực tiếp (không cần chứng minh), đủ nhanh để tham gia hiệu quả vào mạng lưới.

Kết luận

Tôi nghĩ rằng thực sự đúng rằng Ethereum thời kỳ 2021 trở nên quá thoải mái khi giao trách nhiệm cho một số lượng nhỏ các nhà diễn viên quy mô lớn, miễn là cơ chế thị trường hoặc hệ thống chứng minh zero knowledge tồn tại để buộc các nhà diễn viên trung tâm phải hành động trung thực. Những hệ thống như vậy thường hoạt động tốt trong trường hợp trung bình, nhưng thất bại một cách thảm họa trong trường hợp tồi tệ nhất.

Chúng tôi không làm điều này.

Đồng thời, tôi nghĩ điều quan trọng là phải nhấn mạnh rằng các đề xuất giao thức Ethereum hiện tại đã tránh xa đáng kể loại mô hình đó và coi nhu cầu về một mạng lưới phi tập trung thực sự nghiêm túc hơn nhiều. Các ý tưởng xung quanh các nút không trạng thái, giảm thiểu MEV, tính cuối cùng của một khe và các khái niệm tương tự, đã đi xa hơn nhiều theo hướng này. Một năm trước, ý tưởng lấy mẫu dữ liệu sẵn có bằng cách cõng trên rơle dưới dạng các nút bán tập trung đã được xem xét nghiêm túc. Năm nay, chúng tôi đã vượt ra khỏi nhu cầu làm những việc như vậy, với tiến bộ mạnh mẽ đáng ngạc nhiên PeerDAS.

Nhưng có rất nhiều điều chúng ta có thể làm để đi xa hơn trong hướng này, trên cả ba trục mà tôi đã nói ở trên, cũng như nhiều trục quan trọng khác.Heliosđã tiến triển rất nhiều trong việc cung cấp cho Ethereum một “light client” thực sự. Bây giờ, chúng ta cần phải đưa nó vào mặc định trong các ví Ethereum, và yêu cầu các nhà cung cấp RPC cung cấp chứng minh kèm theo kết quả của họ để chúng có thể được xác minh, và mở rộng công nghệ light client đến các giao thức layer 2. Nếu Ethereum đang mở rộng thông qua một lộ trình tập trung vào rollup, các layer 2 cần phải có các bảo đảm an ninh và phân quyền tương tự như layer 1. Trong một thế giới tập trung vào rollup, có nhiều điều khác mà chúng ta nên nghiêm túc hơn; cầu nối cross-L2 phi tập trung và hiệu quả là một ví dụ. Nhiều dapps nhận được logs của họ thông qua các giao thức tập trung, vì việc quét log native của Ethereum đã trở nên quá chậm. Chúng ta có thể cải thiện điều này với một sub-protocol phi tập trung được phân định rõ ràng; @vbuterin/parallel_post_state_roots">dưới đây là một đề xuất của tôi về cách thực hiện điều này.

Có một số lượng gần như không giới hạn các dự án blockchain nhắm đến lĩnh vực 'chúng ta có thể rất nhanh, chúng ta sẽ nghĩ về phân quyền sau'. Tôi không nghĩ rằng Ethereum nên là một trong những dự án đó. Ethereum L1 có thể và chắc chắn nên là một lớp cơ sở mạnh mẽ cho các dự án tầng 2 mà thực sự áp dụng phương pháp siêu quy mô, sử dụng Ethereum như một cột sống cho phân quyền và bảo mật. Ngay cả một hướng tiếp cận tập trung vào tầng 2 cũng đòi hỏi tầng 1 chính nó có đủ khả năng mở rộng để xử lý một số lượng đáng kể các hoạt động. Nhưng chúng ta nên tôn trọng sâu sắc các thuộc tính làm cho Ethereum độc đáo, và tiếp tục làm việc để duy trì và cải thiện những thuộc tính đó khi Ethereum mở rộng.

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ệ với Cổng Họcđội, và họ sẽ xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến đượ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 ra các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn bản dịch là không được phép.