Sáp nhập sắp xảy ra: Giải thích chi tiết về lộ trình kỹ thuật mới nhất của Ethereum

Nền

Trước khi nói về Danksharding, chúng ta có thể dành chút thời gian để tìm hiểu nền tảng của nó. Cá nhân tôi đoán rằng nền tảng của bầu không khí cộng đồng do Danksharding đưa ra chủ yếu đến từ hai bài báo của Vitalik. Hai bài viết này đặt ra định hướng cho tương lai của Ethereum.

Trước hết , Vitalik Vào tháng 10 năm 2020, "Lộ trình Ethereum tập trung vào Rollup" đã được xuất bản, đề xuất rằng Ethereum cần cung cấp hỗ trợ tập trung cho Rollup trong ngắn hạn và trung hạn. Đầu tiên, việc mở rộng lớp cơ sở Ethereum sẽ tập trung vào việc mở rộng dung lượng dữ liệu của khối thay vì cải thiện hiệu quả của hoạt động tính toán trên chuỗi hoặc hoạt động IO. Nghĩa là: Phân mảnh Ethereum được thiết kế để cung cấp nhiều không gian hơn cho các đốm dữ liệu (không phải giao dịch), điều mà Ethereum không cần diễn giải, chỉ đảm bảo rằng dữ liệu có sẵn. Thứ hai, cơ sở hạ tầng của Ethereum được điều chỉnh để hỗ trợ Rollup (chẳng hạn như hỗ trợ L2 cho ENS, tích hợp ví L2 và chuyển tài sản chéo L2). Về lâu dài, tương lai của Ethereum sẽ là một phân đoạn thực thi duy nhất, có độ an toàn cao mà mọi người đều có thể làm việc trên đó và là lớp sẵn có của dữ liệu có thể mở rộng.

Nguồn hình ảnh: https://vitalik.ca/general/2021/12/06/endgame.html

Sau đó, Vitalik đã mô tả bức tranh cuối cùng về Ethereum trong "Endgame" xuất bản vào tháng 12 năm 2021: đầu ra khối được tập trung hóa, nhưng xác minh khối Đạt được sự tin cậy và phân cấp cao trong khi vẫn đảm bảo kiểm duyệt sức chống cự. Chuỗi cơ bản cung cấp sự đảm bảo về tính khả dụng của dữ liệu của các khối, trong khi Rollup cung cấp sự đảm bảo về tính hợp lệ của các khối (trong zkRollup, điều này đạt được thông qua SNARK; trong Optimistic Rollup, chỉ một người tham gia trung thực chạy nút chống gian lận). Tương tự như hệ sinh thái đa chuỗi của Cosmos, tương lai của Ethereum sẽ là sự cùng tồn tại của nhiều Rollups - tất cả đều dựa trên tính sẵn có của dữ liệu và bảo mật chung do Ethereum cung cấp. Người dùng dựa vào các cầu nối để di chuyển giữa các lần cuộn khác nhau mà không phải trả phí cao cho chuỗi chính.

Hai bài viết trên về cơ bản xác định hướng phát triển của Ethereum: tối ưu hóa việc xây dựng lớp cơ bản của Ethereum và xây dựng nền tảng cho Rollup Serve. Lập luận trên có thể dựa trên quan điểm rằng vì Rollup đã được chứng minh là có hiệu quả và được áp dụng tốt, "thay vì mất vài năm chờ đợi một giải pháp mở rộng phức tạp và không chắc chắn (lưu ý: đề cập đến sharding ban đầu), tốt hơn hết bạn nên chú ý để Tập trung vào các giải pháp dựa trên Rollup."

Sau đó, Dankrad đã đề xuất một giải pháp sharding mới, Danksharding. Dưới đây chúng tôi chia nhỏ các thành phần kỹ thuật cụ thể của Danksharding để bạn hiểu.

Proto-Danksharding

Nguồn hình ảnh: https://l2fees.info/

Nền tảng được Proto-Danksharding đề xuất là mặc dù giải pháp Rollup giúp giảm đáng kể chi phí giao dịch so với chuỗi chính Ethereum nhưng vẫn chưa đủ thấp. Điều này là do CALLDATA, công ty cung cấp dữ liệu sẵn có trên chuỗi chính Ethereum, vẫn chiếm chi phí lớn (16 gas/byte). Trong ý tưởng ban đầu, Ethereum đề xuất cung cấp 16 MB không gian dữ liệu chuyên dụng cho mỗi khối trong phân đoạn dữ liệu để Rollup sử dụng, nhưng việc triển khai phân đoạn dữ liệu thực tế vẫn còn rất xa.

Vào ngày 25 tháng 2 năm nay, Vitalik và DankRad cùng những người khác đã đề xuất đề xuất EIP-4844 (Giao dịch Shard Blob), đó cũng là Proto-Danksharding, nhằm mục đích mở rộng tính sẵn có của dữ liệu của Ethereum theo cách đơn giản và tương thích về phía trước để nó vẫn có thể được sử dụng sau khi Danksharding ra mắt. Những thay đổi được đề xuất chỉ xảy ra ở lớp đồng thuận và không yêu cầu công việc điều chỉnh bổ sung của khách hàng, người dùng và nhà phát triển Tổng hợp ở lớp thực thi.

Proto-Danksharding không thực sự thực hiện sharding nhưng giới thiệu tên cho sharding trong tương lai. Đây là định dạng giao dịch của sharding. "Giao dịch mang theo đốm màu". Định dạng giao dịch này khác với các giao dịch thông thường ở chỗ nó mang các khối dữ liệu bổ sung được gọi là blob (khoảng 125kB), làm cho các khối thực sự lớn hơn, do đó cung cấp dữ liệu sẵn có rẻ hơn CALLDATA (khoảng 10kB).

Tuy nhiên, một vấn đề phổ biến với "khối lớn" là yêu cầu về dung lượng ổ đĩa tiếp tục tích lũy, khi sử dụng Proto- Danksharding Điều này sẽ cho phép Ethereum bổ sung thêm 2,5TB dung lượng lưu trữ mỗi năm (hiện tại toàn bộ dữ liệu mạng chỉ là 986GB). Do đó, Proto-Danksharding đặt một khoảng thời gian (ví dụ: 30 ngày), sau đó blob sẽ bị xóa và người dùng hoặc giao thức có thể sao lưu dữ liệu blob trong khoảng thời gian này.

Nghĩa là, lớp đồng thuận của Ethereum chỉ đóng vai trò là một "bảng thông báo thời gian thực" có độ bảo mật cao để đảm bảo rằng những dữ liệu này được lưu trữ chính xác. được lưu trữ trong một thời gian đủ dài và cho phép người dùng hoặc giao thức khác có đủ thời gian để sao lưu dữ liệu, thay vì Ethereum giữ lại vĩnh viễn tất cả dữ liệu lịch sử blob.

Lý do là vì để lưu trữ, 2,5TB được bổ sung hàng năm không phải là vấn đề mà là để lưu trữ Các nút Ethereum mang lại rất nhiều gánh nặng. Trên thực tế, đối với các vấn đề về giả định độ tin cậy có thể xảy ra, miễn là một bên lưu trữ dữ liệu trung thực (1 trên N), hệ thống có thể hoạt động bình thường mà không cần tập hợp các nút xác thực tham gia xác minh và thực hiện đồng thuận trong thời gian thực (N/2 của N) để lưu trữ phần dữ liệu lịch sử này.

Vậy, có khuyến khích nào cho các bên thứ ba lưu trữ dữ liệu này không? Tác giả tạm thời chưa tìm ra phương án khuyến khích nào nhưng bản thân Vitalik đã đề xuất một số phương pháp lưu trữ dữ liệu khả thi:

1 , các giao thức dành riêng cho ứng dụng (chẳng hạn như Rollup). Họ có thể yêu cầu các nút lưu trữ dữ liệu lịch sử liên quan đến ứng dụng. Nếu dữ liệu lịch sử bị mất, nó sẽ gây rủi ro cho phần này của ứng dụng, vì vậy họ có động cơ lưu trữ nó;

2. BitTorrent;

3. Mạng cổng thông tin của Ethereum, một nền tảng cung cấp quyền truy cập nhẹ vào giao thức;

4. , nhà cung cấp API hoặc nhà cung cấp dịch vụ dữ liệu khác;

5. Những cá nhân đam mê hoặc học giả tham gia phân tích dữ liệu;

6. các giao thức như The Graph.

Danksharding Lấy mẫu tính sẵn có của dữ liệu (DAS)

Nguồn hình ảnh: https://notes.ethereum. org/@hww/workshop_feb_2022

Trong Proto-Danksharding, chúng tôi đã đề cập đến định dạng giao dịch mới Như một kết quả là khối thực sự trở nên lớn hơn và Rollup cũng tích lũy một lượng lớn dữ liệu và các nút cần tải xuống dữ liệu này để đảm bảo tính khả dụng của dữ liệu.

Ý tưởng của DAS là: nếu dữ liệu có thể được chia thành N khối và mỗi nút tải xuống ngẫu nhiên K khối, thì nó có thể xác minh xem tất cả dữ liệu có sẵn mà không cần tải xuống tất cả dữ liệu hay không, điều này có thể giảm đáng kể gánh nặng cho các nút. Nhưng nếu một khối dữ liệu bị mất thì sao? Rất khó để phát hiện một khối bị thiếu chỉ bằng cách tải xuống K khối một cách ngẫu nhiên.

Để triển khai DAS, công nghệ mã hóa xóa (Erasure Coding) được giới thiệu. Mã hóa xóa là một công nghệ mã hóa có khả năng chịu lỗi. Nguyên tắc cơ bản là phân đoạn dữ liệu, thêm một số kiểm tra nhất định và liên kết từng phân đoạn dữ liệu. Ngay cả khi một số phân đoạn dữ liệu bị mất, dữ liệu hoàn chỉnh vẫn có thể được tính toán thông qua thuật toán.

Nếu tỷ lệ dư thừa của mã hóa xóa được đặt thành 50%, điều đó có nghĩa là chỉ 50% của khối Một lần dữ liệu có sẵn, bất kỳ ai trên mạng đều có thể xây dựng lại tất cả dữ liệu khối và phát nó. Nếu kẻ tấn công muốn đánh lừa một nút, hắn sẽ phải ẩn hơn 50% số khối, nhưng với nhiều mẫu ngẫu nhiên, điều này gần như không bao giờ xảy ra. (Ví dụ: giả sử các khối được lấy mẫu ngẫu nhiên 30 lần, xác suất tất cả các khối này bị kẻ tấn công ẩn là )

Vì nút không tải xuống tất cả dữ liệu mà dựa vào mã hóa xóa để tái tạo lại dữ liệu, Sau đó, trước tiên bạn cần đảm bảo rằng mã xóa được mã hóa chính xác, nếu không thì tất nhiên dữ liệu không thể được xây dựng lại bằng mã xóa được mã hóa sai.

Theo cách này, Cam kết đa thức KZG được giới thiệu thêm. Cam kết đa thức là một dạng đơn giản "biểu thị" một đa thức, được sử dụng để chứng minh rằng giá trị của đa thức tại một vị trí cụ thể là phù hợp với giá trị đã chỉ định và Không cần thiết phải bao gồm tất cả dữ liệu cho đa thức. Danksharding thực hiện việc xác minh mã xóa bằng cách áp dụng cam kết KZG.

Sẽ dễ dàng nếu chúng ta có thể đưa tất cả dữ liệu vào cam kết KZG, nhưng xây dựng cam kết KZG này, Hoặc xây dựng lại dữ liệu này khi một số dữ liệu không còn khả dụng - yêu cầu tài nguyên của cả hai đều rất lớn. (Trên thực tế, dữ liệu của một khối yêu cầu phải đảm bảo nhiều cam kết KZG) Để giảm gánh nặng cho các nút và tránh tập trung hóa, Danksharding tiếp tục phân chia cam kết KZG và đề xuất khung cam kết KZG hai chiều.

Sau khi chúng tôi lần lượt giải quyết các vấn đề trên, dựa vào DAS, nút hoặc ứng dụng khách nhẹ chỉ cần tải xuống ngẫu nhiên K khối dữ liệu có thể xác minh rằng tất cả dữ liệu đều có sẵn theo cách này, ngay cả sau khi đưa ra "khối lớn", nó sẽ không làm tăng quá nhiều gánh nặng cho các nút.

(Lưu ý: Đặc biệt, thuật toán mã hóa xóa được sử dụng trong Danksharding là mã hóa Reed-Solomon; cam kết của KZG là Kế hoạch cam kết đa thức do Kate, Zaverucha và Goldberg công bố sẽ không được mở rộng ở đây. Những độc giả quan tâm đến các nguyên tắc của thuật toán có thể tự mình mở rộng. Ngoài ra, kế hoạch đảm bảo tính chính xác của mã xóa cũng bao gồm cả bằng chứng gian lận. được sử dụng trong Celestia).

Sự tách biệt giữa người đề xuất và người xây dựng khối (PBS)

Trong tình hình hiện tại, người khai thác PoW và người xác thực PoS đều là người xây dựng khối (Người xây dựng) và người đề xuất khối (Người đề xuất)—— Trong PoS, người xác thực có thể sử dụng lợi nhuận MEV để có được nhiều chỗ xác thực mới hơn, từ đó có nhiều cơ hội hơn để hiện thực hóa MEV. Ngoài ra, các nhóm xác minh lớn rõ ràng có khả năng nắm bắt MEV mạnh hơn những người xác thực thông thường, điều này dẫn đến vấn đề tập trung nghiêm trọng. Vì vậy, PBS đề xuất tách Người xây dựng và Người đề xuất.

Ý tưởng của PBS như sau: Người xây dựng xây dựng danh sách các giao dịch được sắp xếp và gửi giá thầu cho Người đề xuất. Người đề xuất chỉ cần chấp nhận danh sách giao dịch có giá thầu cao nhất và không ai có thể biết nội dung cụ thể của danh sách giao dịch cho đến khi chọn được người thắng cuộc đấu giá.

Cơ chế phân tách và đấu giá này giới thiệu sự "involution" giữa trò chơi và Builder: xét cho cùng, mỗi Builder đều nắm bắt được MEV Các khả năng không giống nhau. Người xây dựng cần cân nhắc mối quan hệ giữa lợi nhuận MEV tiềm năng và giá thầu đấu giá, điều này thực sự làm giảm thu nhập ròng của MEV bất kể khối do Người xây dựng gửi có thể được sản xuất thành công hay không, Người đề xuất cần phải được sản xuất thành công; chi phí đấu thầu. Theo cách này, Người đề xuất (nói rộng ra là tập hợp tất cả những người xác nhận, được chọn lại ngẫu nhiên trong một khoảng thời gian nhất định) tương đương với việc chia sẻ một phần thu nhập của MEV, làm suy yếu tính tập trung của MEV.

Trên đây đã giới thiệu những ưu điểm của PBS trong việc giải MEV, và còn có một lý do khác để giới thiệu PBS. Trong Danksharding, các yêu cầu đối với Builder là: tính toán bằng chứng KZG cho dữ liệu 32 MB trong khoảng 1 giây, yêu cầu CPU 32-64 lõi và phát 64 MB dữ liệu theo cách P2P trong một khoảng thời gian nhất định; yêu cầu băng thông 2,5Gbit/s. Rõ ràng người xác minh không thể đáp ứng yêu cầu như vậy.

Vì vậy PBS tách biệt hai phần này và Người đề xuất vẫn đóng vai trò là nút xác thực chung, chịu trách nhiệm chọn danh sách giao dịch và phát sóng khu vực Trưởng khối; và Builder với vai trò chuyên môn chịu trách nhiệm về công việc trên và xây dựng danh sách giao dịch.

Nguồn ảnh: https: //ethresear.ch/t/two-slot-proposer-builder-separation/10980

Tháng 10 năm ngoái, Vitalik đã đề xuất giải pháp PBS hai khe (lưu ý: mỗi Khe là 12 giây, là đơn vị thời gian của chuỗi báo hiệu), nhưng giải pháp PBS cụ thể vẫn đang được thảo luận.

Danh sách chống kiểm duyệt (crList)

Nguồn hình ảnh: https://notes.ethereum.org/@hww/workshop_feb_2022

Nhưng PBS cũng mang đến một vấn đề. Nếu Người xây dựng luôn trả giá cao nhất (hoặc thậm chí sẵn sàng chịu tổn thất tài chính) để thắng cuộc đấu giá, thì anh ta thực sự có khả năng xem xét giá cả. giao dịch. , bạn có thể loại trừ có chọn lọc một số giao dịch nhất định khỏi việc đưa vào khối.

Để đạt được mục đích này, Danksharding đã giới thiệu thêm danh sách kháng cự kiểm duyệt crList (tức là Danh sách kháng cự kiểm duyệt), tức là, Người đề xuất có quyền chỉ định Danh sách giao dịch, danh sách này phải được Người xây dựng đưa vào sau khi thắng cuộc đấu giá, Người xây dựng cần chứng minh rằng tất cả các giao dịch trong crList đã được đưa vào (hoặc khối đã đầy), nếu không sẽ bị khối được coi là không hợp lệ.

Tóm tắt

Nguồn hình ảnh: https://notes.ethereum.org/@hww/workshop_feb_2022

Kết hợp việc lấy mẫu tính khả dụng của dữ liệu (DAS), trình tạo khối và phân tách người đề xuất (PBS) và danh sách kháng cự kiểm duyệt (crList), bạn sẽ có được Danksharding hoàn chỉnh. Chúng tôi nhận thấy rằng khái niệm "sharding" thực sự đã bị giảm bớt. Mặc dù tên Sharding vẫn được giữ lại nhưng trọng tâm thực sự là hỗ trợ tính khả dụng của dữ liệu.

Vậy ưu điểm của Danksharding so với sharding ban đầu là gì?

(Bản thân Dakrad đã liệt kê 10 ưu điểm của Danksharding ở đây, chúng tôi chọn ra 2 để giải thích chi tiết)

Trong phân đoạn ban đầu, mỗi phân đoạn riêng lẻ có người đề xuất và ủy ban xác minh các giao dịch trong phân đoạn tương ứng. Việc bỏ phiếu được tiến hành và tất cả. kết quả bỏ phiếu được thu thập bởi người đề xuất chuỗi đèn hiệu. Công việc này khó hoàn thành trong một Khe duy nhất. Ở Danksharding, chỉ có một ủy ban (một tập hợp rộng rãi các trình xác nhận, được chọn lại ngẫu nhiên trong một khoảng thời gian nhất định) trên chuỗi beacon và ủy ban này xác minh các khối chuỗi beacon và dữ liệu phân đoạn. Điều này tương đương với việc đơn giản hóa 64 nhóm đề xuất và ủy ban ban đầu thành 1 nhóm, giảm đáng kể độ phức tạp của cả lý thuyết và triển khai kỹ thuật.

Một ưu điểm khác của Danksharding là khả năng thực hiện các cuộc gọi đồng bộ giữa chuỗi chính Ethereum và zkRollup. Như chúng tôi đã đề cập ở trên, trong phân đoạn ban đầu, chuỗi beacon cần thu thập kết quả bỏ phiếu của tất cả các phân đoạn, điều này sẽ gây ra sự chậm trễ trong việc xác nhận. Ở Danksharding, dữ liệu khối và phân đoạn của chuỗi beacon được ủy ban chuỗi beacon chứng nhận thống nhất, nghĩa là các giao dịch trong cùng một khối beacon có thể truy cập ngay vào dữ liệu phân đoạn. Điều này kích thích nhiều khả năng hơn về khả năng kết hợp: ví dụ: AMM (dAMM) phân tán do StarkWare đề xuất có thể hoán đổi hoặc chia sẻ thanh khoản trên L1/L2, từ đó giải quyết vấn đề phân mảnh thanh khoản.

Sau khi triển khai Danksharding, Ethereum sẽ trở thành lớp thanh toán thống nhất và lớp sẵn có dữ liệu của Rollup.

Suy nghĩ kết thúc

Trong hình trên, chúng tôi đưa ra bản tóm tắt về Danksharding.

Tóm lại, chúng ta có thể thấy đại khái hướng đi của lộ trình Ethereum trong 2 đến 3 năm tới. rất rõ ràng - nó xoay quanh dịch vụ Rollup. Mặc dù vẫn chưa biết liệu lộ trình có thay đổi trong quá trình này hay không: Danksharding dự kiến sẽ được triển khai trong 18-24 tháng tới, trong khi Proto-Danksharding sẽ được triển khai trong 6-9 tháng. Nhưng ít nhất chúng tôi đã nói rõ rằng Rollup, làm cơ sở cho sự mở rộng của Ethereum, chiếm một vị trí thống trị nhất định.

Dựa trên quan điểm do Vitalik đề xuất, ở đây chúng tôi cũng đưa ra một số suy nghĩ và phỏng đoán mang tính dự đoán:

Đầu tiên là hệ sinh thái đa chuỗi tương tự như Cosmos. Trong tương lai, sẽ có mô hình cạnh tranh đa chuỗi trên Ethereum. , với Ethereum cung cấp bảo mật cho họ về độ tin cậy và tính sẵn có của dữ liệu.

Thứ hai, cơ sở hạ tầng chéo L1/Rollup sẽ trở thành một nhu cầu cứng nhắc. MEV tên miền chéo sẽ mang đến các kết hợp chênh lệch giá phức tạp hơn, tương tự như dAMM đã đề cập ở trên, sẽ mang lại khả năng kết hợp phong phú hơn.

Thứ ba, nhiều ứng dụng sinh thái của Rollup sẽ vượt qua chính Ethereum. Vì vị trí của Ethereum chiếm vị trí thứ yếu trong lớp khả dụng dữ liệu của Rollup, nên chúng tôi đoán rằng sẽ có nhiều ứng dụng hơn được chuyển sang Rollup (nếu quan điểm thứ hai là đúng); hoặc ít nhất các ứng dụng sẽ được tạo trên cả Ethereum và Rollup cùng một lúc.

Tài liệu tham khảo:

https://consensys.net/blog/blockchain-explained/the-roadmap- to-serenity-2/

https://www.web3.university/article/ethereum-shending-an-introduction-to-blockchain-shending

https://ethereum -magicians.org/t/a-rollup-centric-ethereum-roadmap/4698

https://vitalik.ca/general/2021/12/06/endgame.html

https://notes.ethereum.org/@vbuterin/proto_danksharding_faq

https://twitter.com/pseudotheos/status/1504457560396468231

https://ethos.dev/ beacon-chain/

https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance#How-does-proposerbuilder-separation-PBS-work

https://notes. ethereum.org/@fradamt/H1ZqdtrBF

https://cloud.tencent.com/developer/article/1829995

https://medium.com/coinmonks/builder-proposer -separation-for-ethereum-explained-884c8f45f8dd

https://dankradfeist.de/ethereum/2021/10/13/kate-polynomial-commitments-mandarin.html

https ://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum

https://vitalik.ca/general/2019/09/22/plonk.html

Liên kết gốc