Vitalik: Kế hoạch ngắn hạn và trung hạn nhằm cải thiện tính không cần cho phép và phi tập trung của Ethereum
Tuyển chọn TechFlowTuyển chọn TechFlow
Vitalik: Kế hoạch ngắn hạn và trung hạn nhằm cải thiện tính không cần cho phép và phi tập trung của Ethereum
Lớp 1 Ethereum có thể và chắc chắn nên trở thành một lớp nền tảng mạnh mẽ cho các dự án lớp 2 áp dụng phương pháp quy mô cực lớn.
Chuyên sâu báo cáo Web3Tác giả: Vitalik Buterin
Biên dịch: Đặng Thông, Jinse Finance
Tôi đang ngồi đây viết bài này vào ngày cuối cùng của sự kiện Ethereum Devconnect tại Kenya, nơi chúng tôi đã đạt được tiến triển lớn trong việc thực hiện và giải quyết các chi tiết kỹ thuật cho những cải tiến Ethereum quan trọng sắp tới, đáng chú ý nhất là PeerDAS, quá trình chuyển đổi cây Verkle và phương pháp phi tập trung để lưu trữ dữ liệu lịch sử trong bối cảnh EIP 4444. Theo góc nhìn cá nhân, tốc độ phát triển của Ethereum cũng như khả năng triển khai các tính năng lớn và quan trọng liên tục được tăng cường, giúp cải thiện đáng kể trải nghiệm cho cả người vận hành nút và người dùng (L1 và L2).
Các nhóm client Ethereum hợp tác cung cấp devnet Pectra
Khi năng lực kỹ thuật ngày càng mạnh mẽ, một câu hỏi quan trọng cần đặt ra là: Liệu chúng ta có đang đi đúng hướng không? Gần đây, Peter Szilagyi – nhà phát triển lõi lâu năm của Geth – đã đăng loạt tweet bày tỏ bất mãn, thúc đẩy chúng ta suy ngẫm về vấn đề này:
Những lo ngại này đều có lý. Đây là mối bận tâm mà nhiều người trong cộng đồng Ethereum từng chia sẻ. Cá nhân tôi cũng đã nhiều lần lo lắng về những vấn đề này. Tuy nhiên, tôi không nghĩ tình hình bi quan như những gì dòng tweet của Peter gợi ý. Ngược lại, nhiều vấn đề đã và đang được giải quyết thông qua các tính năng giao thức đang phát triển, còn nhiều vấn đề khác có thể khắc phục bằng cách điều chỉnh rất thực tế đối với lộ trình hiện tại.
Để hiểu rõ điều này trong thực tiễn, hãy cùng xem xét từng ví dụ mà Peter đưa ra. Những vấn đề này là mối quan tâm phổ biến của nhiều thành viên cộng đồng, và việc giải quyết chúng là rất quan trọng.
MEV và sự phụ thuộc vào người xây dựng khối
Trước đây, các khối Ethereum do thợ đào tạo ra, họ sử dụng các thuật toán tương đối đơn giản để tạo khối. Người dùng gửi giao dịch vào mạng ngang hàng công cộng, thường gọi là "mempool" (hoặc "txpool"). Các thợ đào theo dõi mempool, chấp nhận các giao dịch hợp lệ kèm phí. Họ đưa các giao dịch có thể thực hiện vào khối, nếu không đủ chỗ thì sẽ ưu tiên theo thứ tự phí cao nhất.
Hệ thống này rất đơn giản và thân thiện với phi tập trung: làm thợ đào, bạn chỉ cần chạy phần mềm mặc định, bạn vẫn kiếm được mức thu nhập từ phí tương đương với các mỏ đào chuyên biệt. Tuy nhiên, khoảng năm 2020, người ta bắt đầu tận dụng giá trị có thể khai thác bởi thợ đào (MEV): thu nhập chỉ có được khi áp dụng các chiến lược phức tạp hiểu rõ hoạt động bên trong các giao thức DeFi.
Ví dụ, hãy xét sàn giao dịch phi tập trung Uniswap. Giả sử tại thời điểm T, tỷ giá USD/ETH trên sàn tập trung và Uniswap là 3.000 USD. Đến thời điểm T+11, tỷ giá USD/ETH trên sàn tập trung tăng lên 3.005 USD. Nhưng lúc này Ethereum chưa có khối mới nào. Đến thời điểm T+12, một khối mới được tạo ra. Bất kỳ ai tạo khối đó đều có thể đặt giao dịch đầu tiên là một loạt lệnh mua ETH trên Uniswap ở mức giá từ 3.000 đến 3.004 USD để mua hết lượng ETH có sẵn. Đây là nguồn thu nhập bổ sung, gọi là MEV. Các ứng dụng ngoài DEX cũng gặp vấn đề tương tự. Bài báo Flash Boys 2.0 xuất bản năm 2019 mô tả chi tiết về điều này.
Biểu đồ trong bài báo Flash Boys 2.0 cho thấy số tiền có thể thu được bằng các phương pháp khác nhau như trên.
Vấn đề nằm ở chỗ, điều này phá vỡ lý do tại sao khai thác (hoặc đề xuất khối sau 2022) có thể "công bằng": giờ đây, các đối tượng lớn có khả năng tối ưu hóa thuật toán khai thác tốt hơn sẽ kiếm được lợi nhuận tốt hơn từ mỗi khối.
Kể từ đó, hai chiến lược đã được tranh luận, tôi gọi là giảm thiểu MEV và cô lập MEV. Giảm thiểu MEV có hai hình thức: (i) tích cực phát triển các lựa chọn thay thế không có MEV cho Uniswap (ví dụ Cowswap), và (ii) xây dựng các công nghệ nội giao thức như mempool mã hóa nhằm giảm thông tin sẵn có cho người sản xuất khối, từ đó giảm thu nhập họ có thể kiếm được. Đặc biệt, mempool mã hóa có thể ngăn chặn các chiến lược như tấn công sandwich (giao dịch được đặt trước và sau giao dịch của người dùng để khai thác kinh tế - "front-running").
Cô lập MEV hoạt động bằng cách chấp nhận MEV nhưng cố gắng hạn chế ảnh hưởng của nó đến sự tập trung staking thông qua việc tách thị trường thành hai loại người tham gia: người xác thực chịu trách nhiệm chứng minh và đề xuất khối, nhưng việc lựa chọn nội dung khối được xử lý thông qua một giao thức đấu giá. Người staking cá nhân giờ đây không cần lo lắng về việc tự tối ưu arbitrage DeFi; họ chỉ cần tham gia giao thức đấu giá và nhận mức giá cao nhất. Điều này được gọi là phân tách người đề xuất / người xây dựng (PBS). Phương pháp này đã có tiền lệ trong các ngành khác: lý do chính khiến các nhà hàng có thể duy trì mức độ phi tập trung cao là vì họ thường dựa vào các nhà cung cấp khá tập trung cho các hoạt động kinh doanh có lợi ích kinh tế nhờ quy mô. Cho đến nay, PBS đã khá thành công trong việc đảm bảo môi trường cạnh tranh công bằng giữa người xác thực nhỏ và lớn, ít nhất là về mặt MEV. Tuy nhiên, nó mang đến một vấn đề khác: việc lựa chọn giao dịch để đưa vào khối trở nên tập trung hơn.
Quan điểm của tôi luôn là giảm thiểu MEV là tốt và chúng ta nên theo đuổi nó (bản thân tôi thường xuyên dùng Cowswap!), mặc dù mempool mã hóa đối mặt với nhiều thách thức, nhưng giảm thiểu MEV có thể vẫn chưa đủ; MEV sẽ không giảm xuống bằng 0 hay gần bằng 0. Vì vậy, chúng ta cũng cần một dạng cô lập MEV nào đó. Điều này dẫn đến một nhiệm vụ thú vị: làm sao để chúng ta thu nhỏ "chiếc hộp cô lập MEV" càng nhỏ càng tốt? Làm sao để trao cho người xây dựng càng ít quyền lực càng tốt, đồng thời vẫn cho phép họ thực hiện vai trò hấp thụ tối ưu arbitrage và các hình thức thu thập MEV khác?
Nếu người xây dựng có quyền loại hoàn toàn giao dịch khỏi khối, thì rất dễ xảy ra tấn công. Giả sử bạn có một vị thế nợ thế chấp (CDP) trên một giao thức DeFi, được hỗ trợ bởi tài sản đang giảm giá nhanh chóng. Bạn muốn tăng tài sản thế chấp hoặc thoát khỏi CDP. Một người xây dựng ác ý có thể cấu kết để từ chối đưa giao dịch của bạn vào, trì hoãn giao dịch cho đến khi giá giảm đủ sâu để buộc thanh lý CDP của bạn. Nếu điều này xảy ra, bạn sẽ phải trả khoản phạt lớn, và người xây dựng sẽ chiếm được phần lớn. Vậy làm sao để ngăn người xây dựng loại bỏ giao dịch và thực hiện các cuộc tấn công kiểu này?
Đây là lúc danh sách bao gồm (inclusion list) phát huy tác dụng.
Nguồn: ethresear.ch
Danh sách bao gồm cho phép người đề xuất khối (tức là người nắm giữ stake) lựa chọn các giao dịch bắt buộc phải đưa vào khối. Người xây dựng vẫn có thể thay đổi thứ tự giao dịch hoặc chèn thêm 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 để ràng buộc khối kế tiếp chứ không phải khối hiện tại. Dù theo cách nào, chúng cũng tước bỏ khả năng loại hoàn toàn giao dịch khỏi khối của người xây dựng.
MEV là một vấn đề phức tạp; ngay cả mô tả trên cũng bỏ sót nhiều sắc thái quan trọng. Như người ta nói, "có thể bạn không đang tìm kiếm MEV, nhưng MEV đang tìm kiếm bạn". Các nhà nghiên cứu Ethereum đã rất kiên trì theo đuổi mục tiêu "thu nhỏ tối đa chiếc hộp cô lập", nhằm giảm thiểu thiệt hại mà người xây dựng có thể gây ra (ví dụ, thông qua việc loại bỏ hoặc trì hoãn giao dịch để tấn công một ứng dụng cụ thể).
Tuy nhiên, tôi thực sự nghĩ rằng chúng ta có thể đi xa hơn. Trong lịch sử, danh sách bao gồm thường được coi là một "tính năng đặc biệt": thông thường, bạn không cần quan tâm đến chúng, nhưng nếu người xây dựng ác ý bắt đầu hành động điên rồ, chúng sẽ cho bạn một "lối thoát 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 cho 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 bước chuyển triết học trong cách nhìn nhận danh sách bao gồm: coi danh sách bao gồm như khối, và vai trò người xây dựng như chức năng bổ trợ thêm một vài giao dịch để thu thập MEV. Nếu người xây dựng chỉ có giới hạn 2,1 triệu gas thì sao?
Tôi cho rằng những ý tưởng theo hướng này – thực sự đẩy "chiếc hộp cô lập" nhỏ nhất có thể – rất thú vị, và tôi ủng hộ việc phát triển theo hướng này. Đây là một sự thay đổi so với "triết lý thời 2021": trong triết lý thời 2021, chúng ta nhiệt tình hơn với ý tưởng rằng vì hiện nay đã có người xây dựng, chúng ta có thể "giao thêm nhiệm vụ" cho họ, để họ phục vụ người dùng theo cách phức tạp hơn, ví dụ như hỗ trợ thị trường phí ERC-4337. Trong triết lý mới này, phần xác minh giao dịch của ERC-4337 phải được tích hợp vào giao thức. May mắn thay, nhóm ERC-4337 cũng ngày càng ủng hộ hướng đi này.
Tóm lại: tư duy về MEV đã quay trở lại hướng trao quyền cho người sản xuất khối, bao gồm cả việc trao quyền trực tiếp cho người sản xuất khối để đảm bảo giao dịch của người dùng được đưa vào. Các đề xuất về trừu tượng tài khoản (account abstraction) cũng quay trở lại hướng loại bỏ sự phụ thuộc vào các bộ chuyển tiếp tập trung hoặc thậm chí cả các bộ gói giao dịch (bundler). Tuy nhiên, có một lập luận thuyết phục rằng chúng ta chưa đi đủ xa, và tôi cho rằng áp lực thúc đẩy quá trình phát triển đi xa hơn theo hướng này là rất đáng hoan nghênh.
Staking linh hoạt
Ngày nay, tỷ lệ người staking riêng lẻ trong tổng số staking Ethereum tương đối nhỏ, và phần lớn việc staking được thực hiện bởi các nhà cung cấp khác nhau – một số là các nhà vận hành tập trung và các DAO khác như Lido và RocketPool.
Tôi đã tự mình nghiên cứu – qua các khảo sát, thăm dò ý kiến, các cuộc trò chuyện trực tiếp – đặt câu hỏi "Tại sao bạn – đặc biệt là bạn – hôm nay không staking riêng lẻ?". Đối với tôi, đến nay, một hệ sinh thái staking riêng lẻ mạnh mẽ là kết quả mong muốn nhất đối với staking Ethereum, và một trong những điều tuyệt vời nhất về Ethereum là chúng ta thực sự cố gắng hỗ trợ một hệ sinh thái staking riêng lẻ mạnh mẽ, thay vì đơn giản buông xuôi cho ủy quyền. Tuy nhiên, chúng ta vẫn còn rất xa mục tiêu này. Trong các khảo sát và thăm dò của tôi, có một vài xu hướng rõ rệt:
Phần lớn lớn những người không staking riêng lẻ cho biết nguyên nhân chính là mức tối thiểu 32 ETH.
Trong số những người đưa ra các lý do khác, lớn nhất là thách thức kỹ thuật trong việc vận hành và duy trì nút xác thực.
Việc mất khả năng sử dụng ETH ngay lập tức, rủi ro an ninh với khóa riêng "nóng", và mất khả năng tham gia đồng thời vào các giao thức DeFi, đều là những vấn đề lớn nhưng nhỏ hơn.
Khảo sát Farcaster cho thấy các lý do chính khiến người ta không staking riêng lẻ.
Nghiên cứu về staking cần giải quyết hai vấn đề then chốt:
Chúng ta làm gì để giải quyết những lo ngại này?
Mặc dù có các giải pháp hợp lý cho hầu hết các vấn đề, nhưng nếu phần lớn mọi người vẫn không muốn staking riêng lẻ, thì làm sao để chúng ta vẫn giữ cho giao thức ổn định và vững chắc trước các cuộc tấn công?
Nhiều dự án nghiên cứu và phát triển đang diễn ra nhằm giải quyết chính những vấn đề này:
Cây Verkle kết hợp với EIP-4444 cho phép các nút staking 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 staking đồng bộ gần như ngay lập tức, đơn giản hóa đáng kể quá trình thiết lập và các thao tác như chuyển từ một phiên bản triển khai sang phiên bản khác. Chúng cũng làm cho các client nhẹ Ethereum khả thi hơn bằng cách giảm băng thông dữ liệu cần thiết để cung cấp bằng chứng cho mỗi truy cập trạng thái.
Nghiên cứu (ví dụ như các đề xuất này) cho phép tập hợp xác thực lớn hơn (giúp giảm mức staking tối thiểu), đồng thời giảm chi phí cho các nút đồng thuận. Những ý tưởng này có thể được thực hiện như một phần của tính năng xác nhận một slot. Việc này cũng sẽ làm cho client nhẹ an toàn hơn, vì họ có thể xác minh toàn bộ chữ ký thay vì phụ thuộc vào hội đồng đồng bộ.
Các tối ưu hóa client Ethereum liên tục diễn ra, làm giảm chi phí và độ khó trong việc vận hành nút xác thực, mặc dù dữ liệu lịch sử ngày càng tăng.
Nghiên cứu về giới hạn phạt (slashing cap) có thể làm giảm lo ngại về rủi ro khóa riêng và cho phép người staking đồng thời đưa ETH của họ vào các giao thức DeFi (nếu họ muốn).
Chứng chỉ rút tiền 0x01 cho phép người staking thiết lập địa chỉ ETH làm địa chỉ rút tiền. Điều này làm cho các nhóm staking phi tập trung khả thi hơn, mang lại lợi thế so với các nhóm staking tập trung.
Tuy nhiên, chúng ta vẫn có thể làm được nhiều hơn nữa. Về lý thuyết, có thể cho phép người xác thực rút tiền nhanh hơn: ngay cả khi tập hợp xác thực thay đổi vài phần trăm mỗi lần xác nhận (tức là mỗi kỳ một lần), Casper FFG vẫn an toàn. Do đó, nếu chúng ta nỗ lực, chúng ta có thể rút ngắn đáng kể chu kỳ. Nếu muốn giảm đáng kể quy mô tiền gửi tối thiểu, chúng ta có thể đưa ra những quyết định khó khăn, đánh đổi theo hướng khác. Ví dụ, nếu tăng thời gian xác nhận lên 4 lần, thì quy mô tiền gửi tối thiểu sẽ giảm 4 lần. Tính năng xác nhận một slot sau này sẽ giải quyết vấn đề này bằng cách hoàn toàn vượt qua mô hình "mỗi người staking tham gia mỗi kỳ".
Một phần quan trọng khác của toàn bộ vấn đề là kinh tế học của staking. Một câu hỏi then chốt là: chúng ta có muốn staking trở thành một hoạt động tương đối nhỏ lẻ, hay chúng ta muốn mọi người hoặc gần như mọi người staking tất cả ETH của họ? Nếu mọi người đều staking, thì chúng ta muốn mỗi người gánh vác trách nhiệm gì? Nếu mọi người cuối cùng đơn giản ủy quyền vì sự lười biếng, thì cuối cùng có thể dẫn đến sự 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 sai có thể khiến Ethereum đi vào con đường tập trung và "tái tạo lại hệ thống tài chính truyền thống thông qua các bước bổ sung"; câu trả lời đúng có thể tạo ra một ví dụ sáng ngời về một hệ sinh thái thành công với một tập hợp rộng rãi và đa dạng các người staking độc lập và các nhóm staking cao độ phi tập trung. Những vấn đề này liên quan đến nền tảng kinh tế và giá trị cốt lõi của Ethereum, vì vậy chúng ta cần sự tham gia đa dạng hơn.
Yêu cầu phần cứng nút
Nhiều vấn đề then chốt về sự phi tập trung của Ethereum cuối cùng đều quy về một câu hỏi đã định nghĩa blockchain suốt một thập kỷ: chúng ta muốn việc vận hành nút thuận tiện đến đâu, và làm sao để đạt được điều đó?
Ngày nay, việc vận hành nút rất khó khăn. Hầu hết mọi người không làm điều đó. Trên chiếc laptop tôi dùng để viết bài này, tôi có một nút reth chiếm 2,1 TB – đã là kết quả của kỹ thuật phần mềm và tối ưu hóa đầy dũng cảm. Tôi cần mua thêm một ổ cứng 4 TB để gắn vào laptop nhằm lưu trữ nút đó. Tất cả chúng ta đều mong muốn việc vận hành nút 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ể vận hành nút trên điện thoại di động.
Như tôi đã viết ở trên, EIP-4444 và cây Verkle là hai công nghệ then chốt giúp chúng ta tiến gần hơn đến lý tưởng này. Nếu cả hai đều được triển khai, nhu cầu phần cứng của nút cuối cùng có thể giảm xuống dưới một trăm gigabyte, và nếu hoàn toàn loại bỏ trách nhiệm lưu trữ dữ liệu lịch sử (có thể chỉ áp dụng cho các nút không staking), thì con số này có thể gần bằng không. ZK-EVM loại 1 sẽ loại bỏ nhu cầu tự chạy tính toán EVM, vì bạn chỉ cần xác minh 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 ta sẽ xếp chồng tất cả các công nghệ này lại, thậm chí cả ví mở rộng trình duyệt Ethereum (ví dụ như Metamask, Rabby) cũng có một nút tích hợp để xác minh các bằng chứng, thực hiện lấy mẫu khả dụng dữ liệu, và đảm bảo chuỗi là chính xác.
Tầm nhìn nêu trên thường được gọi là "The Verge".
Tất cả điều này đều được biết đến và hiểu rõ, ngay cả những người bày tỏ lo ngại về quy mô nút Ethereum. Tuy nhiên, có một mối bận tâm quan trọng: nếu chúng ta gỡ bỏ trách nhiệm duy trì trạng thái và cung cấp bằng chứng, thì điều đó chẳng phải là một vector tập trung sao? Ngay cả khi họ không thể gian lận bằng cách cung cấp dữ liệu sai, nhưng quá phụ thuộc vào họ chẳng phải đi ngược lại các nguyên tắc của Ethereum sao?
Một phiên bản gần đây của mối lo ngại này là sự khó chịu của nhiều người đối với EIP-4444: nếu các nút Ethereum thông thường không còn cần lưu trữ dữ liệu lịch sử cũ, thì ai sẽ cần làm điều đó? Một câu trả lời phổ biến là: chắc chắn sẽ có đủ nhiều đối tượng lớn (ví dụ như các trình khám phá khối, sàn giao dịch, Layer 2) có động lực giữ dữ liệu này, và so với 100 PB mà Wayback Machine lưu trữ, chuỗi Ethereum rất nhỏ. Vì vậy, ý tưởng cho rằng bất kỳ dữ liệu lịch sử nào thực sự sẽ bị mất là điều vô lý.
Tuy nhiên, lập luận này phụ thuộc vào một số lượng nhỏ các đối tượng lớn. Trong phân loại mô hình tin cậy của tôi, đây là giả định 1 trong N, nhưng N rất nhỏ. Điều này tiềm ẩn các rủi ro đuôi (tail risks). Một việc chúng ta có thể làm là lưu trữ dữ liệu 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 nhỏ dữ liệu. Mạng như vậy vẫn sẽ sao chép đủ để đảm bảo độ bền: mỗi dữ liệu sẽ có hàng ngàn bản sao, và trong tương lai chúng ta có thể sử dụng mã xóa (erasure coding) (thực tế, bằng cách đưa lịch sử vào các blob theo kiểu EIP-4844, điều này đã có sẵn mã xóa) để tăng độ ổn định hơn nữa.
Blob có mã xóa cả bên trong và giữa các blob. Cách đơn giản nhất để cung cấp lưu trữ siêu ổn định cho toàn bộ lịch sử Ethereum có lẽ là đưa các khối beacon và khối thực thi vào các blob. Ảnh: codex.storage
Lâu nay, công việc này bị xếp vào hạng thứ yếu. Mạng cổng (portal network) thực sự tồn tại, nhưng thực tế nó không nhận được mức độ quan tâm tương xứng với tầm quan trọng của nó trong tương lai Ethereum. May mắn thay, hiện nay đang có sự quan tâm mạnh mẽ đến việc đổ thêm nguồn lực vào phiên bản cổng tối giản tập trung vào lưu trữ phân tán và khả năng truy cập lịch sử. Chúng ta nên tận dụng điều này, cùng nhau nỗ lực triển khai nhanh chóng EIP-4444, đi kèm với một mạng ngang hàng phi tập trung mạnh mẽ để lưu trữ và truy xuất dữ liệu lịch sử cũ.
Đối với trạng thái và ZK-EVM, phương pháp phân tán này khó khăn hơn. Để xây dựng một khối hiệu quả, bạn cần sở hữu toàn bộ trạng thái. Trong trường hợp này, cá nhân tôi thiên về cách tiếp cận thực dụng: chúng ta định nghĩa và cam kết một mức độ yêu cầu phần cứng nhất định để vận hành một nút "làm mọi việc", mức này cao hơn chi phí (trong lý tưởng là ngày càng giảm) của một nút xác minh đơn giản, nhưng vẫn đủ thấp để những người đam mê có thể chi trả. Chúng ta dựa vào giả định 1 trong N, đảm bảo rằng N đủ lớn.
Bằng chứng ZK-EVM có thể là phần khó xử lý nhất, bộ tạo bằng chứng ZK-EVM thời gian thực có thể cần phần cứng mạnh hơn nút lưu trữ, ngay cả với những tiến bộ như Binius và giới hạn worst-case của Gas đa chiều. Chúng ta có thể nỗ lực xây dựng mạng chứng minh phân tán, trong đó mỗi nút đảm nhận trách nhiệm chứng minh, ví dụ: 1% việc thực thi khối, sau đó người sản xuất khối chỉ cần tập hợp 100 bằng chứng cuối cùng. Cây tập hợp bằng chứng có thể hỗ trợ thêm. Nhưng nếu điều này không hoạt động tốt, thì một thỏa hiệp khác là cho phép yêu cầu phần cứng cho việc tạo bằng chứng cao hơn, nhưng đảm bảo rằng một nút "làm mọi việc" có thể trực tiếp xác minh khối Ethereum (không cần bằng chứng) một cách đủ nhanh để tham gia hiệu quả vào mạng.
Tổng kết
Tôi cho rằng, miễn là tồn tại một cơ chế thị trường hoặc hệ thống bằng chứng kiến thức không (zero-knowledge proof) nào đó buộc các đối tượng tập trung hành xử trung thực, tư duy Ethereum thời 2021 thực sự đã quen với việc chuyển giao trách nhiệm cho một số ít đối tượng lớn. Những hệ thống như vậy thường hoạt động tốt trong điều kiện bình thường, nhưng có thể sụp đổ thảm khốc trong trường hợp xấu nhất.
Đồng thời, tôi cho rằng cần nhấn mạnh rằng các đề xuất giao thức Ethereum hiện tại đã lệch đáng kể so với mô hình đó, và đang nghiêm túc hơn với nhu cầu về một mạng lưới thực sự phi tập trung. Các ý tưởng xoay quanh nút vô trạng thái, giảm thiểu MEV, xác nhận một slot và các khái niệm tương tự đã đi xa hơn theo hướng này. Một năm trước, người ta từng nghiêm túc cân nhắc ý tưởng lấy mẫu khả dụng dữ liệu thông qua các bộ chuyển tiếp như các nút bán tập trung. Năm nay, chúng ta đã không còn cần làm những điều này nữa, PeerDAS đã đạt được tiến triển mạnh mẽ đáng ngạc nhiên.
Tuy nhiên, đối với cả ba vấn đề trung tâm mà tôi đã nêu ở trên và nhiều vấn đề quan trọng khác, chúng ta có thể làm rất nhiều việc để đi xa hơn theo hướng này. Helios đã đạt được tiến bộ lớn trong việc cung cấp cho Ethereum một "client nhẹ thực sự". Bây giờ, chúng ta cần mặc định tích hợp nó vào ví Ethereum, và yêu cầu các nhà cung cấp RPC cung cấp bằng chứng cùng kết quả của chúng để có thể xác minh, đồng thời mở rộng công nghệ client nhẹ sang các giao thức lớp 2. Nếu Ethereum mở rộng thông qua lộ trình tập trung vào Rollup, thì lớp 2 cần có được các đảm bảo an toàn và phi tập trung giống như lớp 1. Trong thế giới tập trung vào Rollup, còn nhiều việc khác mà chúng ta nên nghiêm túc hơn; cầu nối giữa các L2 phân tán và hiệu quả là một trong nhiều ví dụ. Nhiều dapp lấy log thông qua các giao thức tập trung vì việc quét log gốc của Ethereum trở nên quá chậm. Chúng ta có thể cải thiện điều này bằng các giao thức con phi tập trung chuyên dụng; đây là một đề xuất của tôi về cách làm điều đó.
Có gần như vô hạn số lượng các dự án blockchain nhắm vào thị trường "chúng tôi có thể siêu nhanh, chúng tôi sẽ xem xét phi tập trung sau". Tôi cho rằng Ethereum không nên gia nhập hàng ngũ này. Lớp 1 Ethereum có thể và chắc chắn nên trở thành một tầng nền mạnh mẽ cho các dự án lớp 2 sử dụng phương pháp quy mô lớn, sử dụng Ethereum như trụ cột về sự phi tập trung và an toàn. Ngay cả phương pháp tập trung vào lớp 2 cũng đòi hỏi lớp 1 phải có đủ khả năng mở rộng để xử lý lượng lớn hoạt động. Nhưng chúng ta nên hết sức tôn trọng những đặc điểm làm nên sự độc đáo của Ethereum, và tiếp tục nỗ lực duy trì và cải thiện những đặc điểm đó khi Ethereum phát triển.
Xin chân thành cảm ơn Dankrad Feist, Caspar Schwarz-Schilling và Francesco đã phản hồi và rà soát nhanh chóng.
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
