Tìm hiểu về tiến trình triển khai lộ trình Ethereum trong một bài viết
Tổng hợp văn bản gốc: The Way of DeFi
Tổng hợp văn bản gốc: The Way of DeFi
Lưu ý: Tài liệu này nhằm phục vụ như một điểm khởi đầu cho các dự án khác nhau trên lộ trình Ethereum, cung cấp một bản tóm tắt nhanh chóng và các liên kết cho những ai muốn tìm hiểu sâu hơn.
Đây là một tài liệu sống, vui lòng liên hệ với tôi nếu bất kỳ thông tin nào được cung cấp ở đây không rõ ràng, không chính xác, lỗi thời hoặc thiếu các liên kết tốt hơn.
Như được chỉ ra bởi các mũi tên trên lộ trình, các giai đoạn được liệt kê không tuần tự và các nỗ lực khác nhau đang diễn ra song song.
1. Hợp nhất
Mục tiêu: Để có được sự đồng thuận bằng chứng cổ phần (PoS) lý tưởng, đơn giản, mạnh mẽ và phi tập trung.
những gì đã được thực hiện
1. Ngày 1 tháng 12 năm 2020 - Ra mắt chuỗi Beacon.
Giới thiệu lớp đồng thuận Ethereum được bảo đảm bằng ETH do người xác thực đặt cược;
Được gọi là Giai đoạn 0 trong đặc tả đồng thuận (phiên bản có chú thích của Vitalik và Danny Ryan);
2. Ngày 27 tháng 10 năm 2021 - Khởi động fork (Altair) - Các nhà phát triển máy khách đồng thuận chạy thử bản nâng cấp hard fork phối hợp.
Altair đã giới thiệu một ủy ban đồng bộ hóa để hỗ trợ các khách hàng nhẹ và điều chỉnh một số hình phạt;
Thông báo Altair;
Thông số kỹ thuật của Altair (phiên bản có chú thích);
Bài viết "Có gì mới trong ETH 2" trên Altair;
3. Ngày 15 tháng 9 năm 2022 - hợp nhất! Không còn PoW - Lớp đồng thuận và lớp Thực thi đã có một sự hợp nhất lớn tại khối 15.537.394.
cái gì tiếp theo
1. Rút tiền – cho phép người xác thực rút toàn bộ hoặc một phần số ETH đã đặt cọc của họ.
Capella fork chỉ định các thay đổi đối với lớp đồng thuận;
EIP-4895 chỉ định các thay đổi đối với lớp thực thi;
Câu hỏi thường gặp của Tim Beiko về việc rút tiền;
thông số meta rút tiền với thông tin bổ sung;
2. Trình xác thực phân tán - giới thiệu nhiều chữ ký, trong đó n cá nhân chia sẻ cùng một trình xác nhận và m-of-n phải đồng ý về cách nó sẽ hoạt động.
Tăng cường đặt cược bằng cách ngăn chặn tình cờ cắt giảm và làm cho nó dễ tiếp cận hơn (ví dụ: bằng cách phân phối 32 ETH cần thiết một cách đáng tin cậy giữa nhiều người tham gia);
Đây không phải là thứ nằm trong giao thức, các nhóm như SSV và Obol đang làm việc với nó;
3. Xem hợp nhất - điều chỉnh các quy tắc lựa chọn rẽ nhánh (cách người xác thực bỏ phiếu) để giảm thiểu một loại tấn công.
Về cơ bản, cho phép những người xác thực trung thực "áp đặt" ý kiến của họ về người đứng đầu chính xác của chuỗi để giảm khả năng những người xác nhận độc hại chia phiếu bầu và sau đó tổ chức lại các khối theo ý muốn của họ;
ethresear.ch đăng bài với rất nhiều nền tảng nghiên cứu (rất kỹ thuật);
4. Tổng hợp được cải thiện - Ethereum cố gắng hỗ trợ càng nhiều trình xác nhận càng tốt, nhưng việc mỗi trình xác thực bỏ phiếu trên mỗi khối (và xác minh phiếu bầu của tất cả các trình xác nhận khác) quá tốn băng thông. Điều tốt nhất tiếp theo là chữ ký tổng hợp, nhưng điều đó có những hạn chế và có thể được thực hiện tốt hơn.
Một bài khoa học phổ biến về lợi ích của tập hợp BLS;
Ứng cử viên tiềm năng: Horn;
5. Độ cuối cùng của một vị trí (SSF) - chuỗi được xác định cho mỗi vị trí (12 giây), không phải theo kỷ nguyên (12,8 phút).
Con đường đến SSF;
Ngoài việc tổng hợp chữ ký được cải thiện, chúng tôi cần giải quyết hai vấn đề khác:
(1) Thuật toán đồng thuận SSF - Thuật toán tương thích với SSF hiện có là không đủ, chúng tôi muốn có một thuật toán có thể giữ cho chuỗi hoạt động ngay cả khi hơn 1/3 số trình xác thực đang ngoại tuyến;
(2) Tính kinh tế của trình xác thực SSF - nếu cuối cùng chúng tôi phải giới hạn số lượng trình xác nhận, thì làm cách nào để hạn chế sự tham gia và chúng tôi phải hy sinh những gì?
6. Bầu thủ lĩnh bí mật (SLE)
Ngày nay, các trình xác nhận (lãnh đạo vị trí) được chọn để đề xuất một khối đã được biết trước, cho phép các cuộc tấn công DoS tiềm năng nhắm mục tiêu cụ thể vào người dẫn đầu của một khối sắp tới.
Bài đăng của ethresear.ch trên một giao thức SLE duy nhất với sự xáo trộn ngẫu nhiên: Không ai biết ai sẽ là người dẫn đầu của một vị trí ngoại trừ chính người dẫn đầu cho đến khi họ tiết lộ các khối và bằng chứng về khả năng lãnh đạo của mình.
Bầu cử lãnh đạo bí mật không đơn lẻ cũng có thể là một lựa chọn.
7. Hỗ trợ nhiều người xác thực hơn - một nỗ lực lâu dài không ngừng: Việc hỗ trợ nhiều người xác thực hơn một cách an toàn luôn là điều mong muốn.
8. Chữ ký thân thiện với tập hợp an toàn lượng tử - giúp Ethereum an toàn trước các cuộc tấn công máy tính lượng tử.
Mật mã đằng sau lược đồ chữ ký BLS được Ethereum sử dụng được biết là đã bị máy tính lượng tử phá vỡ, nhưng các lược đồ chữ ký thay thế an toàn lượng tử đã biết không tổng hợp hiệu quả như lược đồ chữ ký BLS (do đó cần có một phương pháp vừa an toàn lượng tử và tổng hợp-thân thiện).kế hoạch);
Hai phương pháp bảo mật lượng tử hàng đầu dựa trên STARK và Lattice;
9. Triển khai EIP-4844 - Áp dụng EIP-4844 cho mạng chính Ethereum.
Một "buổi lễ" sẽ được yêu cầu để tạo ra một thiết lập đáng tin cậy: giải thích, thời gian ước tính, thông số kỹ thuật;
Tổng quan về lịch trình triển khai EIP-4844;
10. Mở rộng tổng số cơ bản - phụ thuộc vào những điều sau:
EIP-4844 - Chia tỷ lệ vẫn được coi là cơ bản/bị hạn chế do tính chất "mọi nút tải xuống tất cả dữ liệu" làm hạn chế dung lượng khả dụng của không gian blobspace;
Rollup bánh xe đào tạo giới hạn (xem các mốc quan trọng được đề xuất);
11. Mở rộng tổng số hoàn chỉnh - phụ thuộc vào những điều sau:
Thiết kế P2P để lấy mẫu tính khả dụng của dữ liệu: Tất cả các nỗ lực và nghiên cứu liên quan đến mạng cần thiết để chia sẻ dữ liệu
Máy khách lấy mẫu DA: phát triển một máy khách nhẹ có thể nhanh chóng xác định xem dữ liệu có sẵn hay không thông qua lấy mẫu ngẫu nhiên vài kilobyte
Tự phục hồi DA hiệu quả: có thể tái tạo lại tất cả dữ liệu một cách hiệu quả trong các điều kiện mạng tồi tệ nhất (ví dụ: các cuộc tấn công của trình xác thực độc hại hoặc thời gian chết kéo dài của một số lượng lớn các nút)
Tổng hợp không có bánh xe đào tạo: trình sắp xếp phi tập trung hoàn toàn, chứng minh gian lận đáng tin cậy, hợp đồng bất biến, v.v.
12. Bảo mật lượng tử và lời hứa về cài đặt không đáng tin cậy - khiến Ethereum trở nên miễn nhiễm với máy tính lượng tử.
Mặc dù các cam kết đa thức (KZG) hiệu quả và mạnh mẽ, nhưng chúng không an toàn lượng tử và yêu cầu thiết lập đáng tin cậy. Nghiên cứu về một cam kết dài hạn lý tưởng hơn đang được tiến hành, với mục tiêu cuối cùng là "hoán đổi nóng" KZG dưới mui xe;
2. Tai họa
Liên kết liên quan:
Liên kết liên quan:
Được hướng dẫn bởi tính trung lập đáng tin cậy;
Nhiều tweet khác nhau về MEV;
Các bài báo về MEV và PBS;
Một danh sách các liên kết trên PBS;
những gì đã được thực hiện
1. Thị trường MEV bên ngoài giao thức - Phần mềm trung gian MEV-Boost cho phép những người xác thực thông thường kiếm lợi nhuận từ MEV mà không cần phải tự chạy các chiến lược MEV phức tạp.
Bản thân giải pháp này chưa hoàn chỉnh vì nó có vấn đề về kiểm duyệt;
Xem Chi phí phục hồi và SUAVE để biết các ý tưởng và kế hoạch làm cho các thị trường ngoài thỏa thuận này trở nên linh hoạt hơn;
cái gì tiếp theo
1. Danh sách bao gồm hoặc lựa chọn thay thế - hãy để những người đề xuất khối áp đặt các hạn chế đối với những người xây dựng khối, tức là buộc họ phải bao gồm các giao dịch.
( 1 ) chứa chú thích danh sách;
(2) Nghiên cứu về việc hạn chế những người xây dựng khối mà không tạo gánh nặng cho những người đề xuất khối;
2. PBS trong giao thức – Kết hợp thị trường cho các trình tạo khối trực tiếp vào giao thức.
3. Đốt cháy MEV - Hãy để chuỗi khối nắm bắt giá trị được trích xuất từ nền kinh tế trực tuyến.
(1) Hủy trực tiếp các đề xuất MEV thông qua đấu giá người đề xuất;
(2) Việc làm mịn MEV do ủy ban điều khiển sẽ cho phép các giao thức nhận biết MEV;
(3) Việc giới hạn bộ xác nhận thông qua các ưu đãi kinh tế sẽ gián tiếp đốt cháy MEV thông qua việc phát hành tiêu cực;
4. Tối thiểu hóa MEV của lớp ứng dụng - Không liên quan trực tiếp đến L1, dự án này liên quan đến việc các nhà phát triển tính đến MEV khi thiết kế dapp. Dưới đây là một số ví dụ về dapps sử dụng chiến lược giảm thiểu MEV.
Theo dõi trình xây dựng phân tán
Khi các đề xuất khối vẫn được phân cấp, giờ đây chúng tôi có một vấn đề riêng về việc xây dựng khối trở nên tập trung. Ngay cả với tất cả các dự án khác trên lộ trình nhằm giảm thiểu các tác động tiêu cực tồi tệ nhất có thể xảy ra của việc xây dựng khối tập trung, thì khả năng phân phối việc xây dựng khối trên nhiều nút vẫn là một lợi ích chính.
Xây dựng blob - tìm cách giảm tải băng thông cao và nhu cầu xử lý dữ liệu sharding trên nhiều nút nơi phần cứng tiêu dùng thông thường có thể chạy;
Dịch vụ xác nhận trước - mang đến cho người dùng sự đảm bảo chắc chắn rằng giao dịch của họ sẽ được đưa vào khối tiếp theo;
Bảo vệ chì - Giảm thiểu các MEV độc hại như giao dịch bánh sandwich để giữ cho các bản dựng phân tán trung lập một cách đáng tin cậy;
Đây vẫn là một lĩnh vực nghiên cứu tích cực với những cân nhắc về thiết kế rất cởi mở, vì vậy vẫn chưa rõ liệu hai mục đầu tiên có nên được đưa vào giao thức hay không (do đó có trạng thái dấu chấm hỏi trên lộ trình).
Dưới đây là một số liên kết có liên quan:
Nói về xây dựng khối hợp nhất, đề cập đến xây dựng khối phi tập trung: https://www.youtube.com/watch?v=KP 5 ppCRH 0 iM
Nói chuyện với những người xây dựng khối phi tập trung: https://www.youtube.com/watch?v=fAgrIdyWIqc
Một số suy nghĩ về xây dựng khối phân tán: https://github.com/flashbots/mev-boost/issues/139
3. Bờ vực
Mục tiêu: Việc xác minh một khối phải cực kỳ đơn giản - tải xuống N byte dữ liệu, thực hiện một số phép tính cơ bản, xác minh SNARK và bạn đã hoàn tất.
Giai đoạn này về cơ bản là lấp đầy "khoảng trống máy khách" bằng cách cuối cùng triển khai các máy khách nhẹ: không phải ai cũng muốn hoặc có thể chạy một nút đầy đủ. Mục tiêu của The Verge là giới thiệu các giải pháp thay thế không tin cậy hoặc giảm thiểu tin cậy, dễ chạy và không yêu cầu nhiều dung lượng lưu trữ và băng thông. Mục tiêu cuối cùng của The Verge là dành cho các ứng dụng khách nhẹ này để cung cấp các đảm bảo bảo mật giống như các nút đầy đủ ngày nay.
Mọi thứ đều dựa trên các kỹ thuật không có kiến thức như SNARK và STARK, bản thân chúng dựa trên các sơ đồ cam kết đa thức. Dưới đây là một số liên kết có liên quan:
Giới thiệu ngắn gọn về cách triển khai zk-SNARK;
Phân tích của STARK;
Nếu bạn biết một chút về toán học và lập trình, bài viết này có thể giúp bạn hiểu zk-SNARK là gì;
Về vai trò của chương trình Cam kết đa thức trong việc mở rộng quy mô Ethereum;
những gì đã được thực hiện
1. Đã giải quyết vấn đề EVM DoS nghiêm trọng nhất - chủ yếu là vấn đề giá gas, đã được khắc phục trong bản nâng cấp Berlin.
2. Hỗ trợ light client cơ bản (ủy ban đồng bộ hóa) - Nhờ có ủy ban đồng bộ hóa, thật dễ dàng để xây dựng các light client tuân theo lớp đồng thuận.
Kiểm tra cách ứng dụng khách Helios sử dụng các ủy ban đồng bộ (và một bài viết hay về cách các ủy ban này hoạt động)
cái gì tiếp theo
1. SNARK / STARK ASIC - phần cứng được chế tạo đặc biệt để tạo bằng chứng.
2. Cây Verkle - thay thế cấu trúc dữ liệu được sử dụng cho trạng thái toàn cầu bằng cấu trúc dữ liệu hiệu quả hơn:
(1) Danh sách liên kết các cây Verkle;
(2) Lợi ích chính là có bằng chứng rất ngắn gọn rằng các ứng dụng khách nhẹ có thể dễ dàng xác minh để xác minh những thứ như số dư tài khoản chỉ bằng các tiêu đề khối - họ đã có thể tận dụng các ủy ban đồng bộ hóa để xác minh rằng một khối nhất định. Tiêu đề khối thực sự là một phần của chính xích;
(3) Dựa vào việc tìm ra thông số kỹ thuật chính xác, cách chuyển đổi an toàn và cách nó sẽ ảnh hưởng đến chi phí khí EVM của trạng thái cập nhật/chỉnh sửa (cũng phụ thuộc vào việc không cho phép TỰ HỦY trong The Purge);
3. Ứng dụng khách nhẹ dựa trên SNARK – Quá trình chuyển đổi ủy ban đồng bộ hóa SNARKify để nhanh chóng chứng minh ủy ban đồng bộ hóa hiện tại bao gồm những trình xác thực nào
4. Ethereum hoàn toàn SNARKed - 3 mục sau đây cùng nhau tạo thành một cột mốc quan trọng để Ethereum có được kết quả xác minh khối cực kỳ hiệu quả và đáng tin cậy:
(1) SNARK cho bằng chứng Verkle - Bằng cách kết hợp bằng chứng Verkle vào SNARK, các khối sẽ chứa bằng chứng ngắn, độc lập về trạng thái một phần mà chúng sửa đổi, do đó không cần xác minh toàn bộ trạng thái của khối N-1 để xác minh xem khối đó có hay không. N sửa đổi nó một cách chính xác.
(2) SNARK cho quá trình chuyển đổi trạng thái đồng thuận — chuyển từ các ủy ban đồng bộ tối thiểu hóa độ tin cậy sang xác minh hoàn toàn không tin cậy đối với mọi thứ xảy ra trên lớp đồng thuận.
(3) SNARK cho L1 EVM - Tận dụng nỗ lực của nhóm triển khai trên zk-EVM bằng cách tích hợp trực tiếp zk-EVM vào L1 (xem bài đăng về các bản tổng hợp được tăng cường).
5. Tăng giới hạn gas L1 - bằng cách loại bỏ gánh nặng "mọi nút cần lưu trữ mọi thứ" ngày nay để xác minh các khối theo cách không đáng tin cậy, việc có các khối lớn hơn sẽ giúp dễ dàng có được nhiều khả năng mở rộng L1 hơn (Điều này sẽ tự động kết hợp tất cả các phần mở rộng L2)
6. Chuyển sang sử dụng SNARK an toàn lượng tử (chẳng hạn như STARK) - để làm cho Ethereum miễn nhiễm với các cuộc tấn công của máy tính lượng tử (hiệu quả của SNARK phụ thuộc vào mật mã được biết là bị máy tính lượng tử bẻ khóa, trong khi STARK thì không).
4. Cuộc thanh trừng
Mục tiêu: Đơn giản hóa giao thức, loại bỏ nợ kỹ thuật và hạn chế chi phí tham gia mạng bằng cách xóa lịch sử cũ.
những gì đã được thực hiện
1. Loại bỏ hầu hết các khoản hoàn trả gas - tất cả việc định giá lại gas được thực hiện trong bản nâng cấp Berlin.
2. Đồng bộ hóa nhanh chuỗi đèn hiệu - tất cả công việc phát triển được đồng bộ hóa từ kỷ nguyên hoàn thành gần đây nhất, không phải từ nguồn gốc (được gọi là "đồng bộ hóa điểm kiểm tra" trong hầu hết các máy khách đồng thuận).
3. Thông số kỹ thuật EIP-4444—xem thông số kỹ thuật EIP.
cái gì tiếp theo
1. Hết hạn lịch sử - Giảm yêu cầu lưu trữ, thời gian đồng bộ hóa và độ phức tạp của mã bằng cách hết hạn lịch sử cũ.
(1) Xem bài đăng trên twitter này;
(2) Phụ thuộc vào việc triển khai EIP-4444, phụ thuộc vào việc truy cập lịch sử thay thế thông qua các phương tiện khác (chẳng hạn như Mạng cổng thông tin)
(3) AMA của Vitalik hết hạn lịch sử;
2. Hết hạn trạng thái - Giải quyết toàn bộ vấn đề "thanh toán một lần, lưu dữ liệu mãi mãi" về trạng thái.
(1) Ý tưởng là tự động hết hạn các phần không sử dụng của trạng thái và chỉ giữ lại gốc cây verkle mà người dùng có thể sử dụng để khôi phục trạng thái đã hết hạn khi cần;
(2) AMA của Vitalik về việc hết hạn trạng thái;
(3) Dựa vào: Thông số kỹ thuật hết hạn trạng thái cơ sở - Cách chúng tôi thực sự làm điều đó, xem lộ trình tiềm năng (và các tùy chọn khác);
Mở rộng không gian địa chỉ - Tăng kích thước địa chỉ từ 20 byte lên 32 byte để ngăn xung đột và thêm dữ liệu về chu kỳ trạng thái;
Phân tích ứng dụng - tìm hiểu xem nó có thể phá vỡ các ứng dụng/hợp đồng hiện tại như thế nào và chúng phù hợp như thế nào;
3. Cải cách nhật ký - Đơn giản hóa cách hoạt động của nhật ký sự kiện để tìm kiếm các sự kiện lịch sử hiệu quả hơn.
4. Phối hợp tuần tự hóa - lớp thực thi sử dụng RLP để tuần tự hóa dữ liệu, trong khi lớp đồng thuận sử dụng SSZ, lớp này sẽ loại bỏ RLP và sử dụng SSZ ở mọi nơi.
5. Loại bỏ các loại giao dịch cũ - ngừng hỗ trợ các loại giao dịch cũ (xem EIP-2718) để loại bỏ độ phức tạp của mã khỏi máy khách (với chi phí tương thích ngược).
6. Bản nhạc đơn giản hóa EVM.
(1) Vô hiệu hóa SELFDESTRUCT - opcode này là nguồn gốc của nhiều vấn đề (EIP liên quan: EIP-4758 và EIP-4760 và thảo luận);
(2) Đơn giản hóa cơ chế gas - liên quan đến việc loại bỏ nhiều tính năng EVM liên quan đến gas được đề cập ở đây;
(3) Biên dịch trước -> triển khai EVM -- loại bỏ các hợp đồng được biên dịch trước và hỗ trợ triển khai EVM trực tiếp (nghĩa là các hoạt động mô-đun lớn, xem The Splurge);
5. Sự phung phí
Mục tiêu: sửa chữa mọi thứ khác
Tất cả những cải tiến tốt đẹp không cần thiết cho các nâng cấp ưu tiên cao hơn đều thuộc về The Splurge. Mục cải tiến lớn nhất là trừu tượng hóa tài khoản, nhưng cũng có những điều chỉnh nhỏ đối với những thứ hiện có.
những gì đã được thực hiện
1. EIP-1559 - EIP nổi tiếng này có nhiều lợi ích ngoài việc đốt ETH.
2. Đặc tả ERC-4337 - ERC này nhằm mục đích giới thiệu tính trừu tượng của tài khoản mà không sửa đổi giao thức cốt lõi (bài viết giải thích ban đầu về ERC-4337).
cái gì tiếp theo
1. EIP-1559 trong giai đoạn hoàn thiện – EIP-1559 được tăng cường thông qua nhiều chiều.
2. Lộ trình cải tiến EVM và lộ trình đơn giản hóa từ The Purge đến giai đoạn cuối cùng của EVM.
(1) Định dạng đối tượng EVM (EOF) — một tập hợp các EIP cho phép xác minh và lập phiên bản mã byte EVM khi được triển khai. Xem bài viết giải thích này và chủ đề twitter;
(2) Các hoạt động theo mô-đun lớn - phần lớn mật mã trong lộ trình dựa trên số lượng rất lớn cho các hoạt động theo mô-đun, có thể được thực hiện trực tiếp hiệu quả hơn trong EVM;
(3) Các cải tiến EVM khác - bất kỳ thứ gì khác đáng được thêm vào để cải thiện EVM - hoặc bất kỳ thứ gì được loại bỏ để loại bỏ sự phức tạp;
3. Theo dõi trích xuất tài khoản dẫn đến trích xuất tài khoản giai đoạn cuối. Để biết thêm thông tin, hãy xem mô tả của Vitalik về các mục sau:
(1) ERC-4337 - Phát triển ví thông minh tương thích để áp dụng thực tế;
(2) Chuyển đổi EOA tự nguyện - thông qua EIP, tài khoản thông thường có thể được thêm mã không thể đảo ngược để chuyển đổi chúng thành tài khoản hợp đồng, tức là ví thông minh đáp ứng tiêu chuẩn 4337;
(3) Chuyển đổi nội bộ thỏa thuận - thực hiện chuyển đổi trên bắt buộc đối với tất cả các tài khoản hiện có;
4. Chức năng trì hoãn có thể xác minh (VDF) - về cơ bản là "bằng chứng công việc không song song" sẽ tăng cường tính ngẫu nhiên trong PoS trong số những thứ khác (xem bài đăng trên ethresear.ch về VDF và cách sử dụng tiềm năng của chúng)
5. Khám phá các giải pháp cho tài khoản bụi - tiết kiệm "quỹ bụi" tốn nhiều chi phí để di chuyển hơn giá trị của chúng. Có rất nhiều ý tưởng ở đây: https://ethereum-magicians.org/t/some-medium-term-dust-cleanup-ideas/6287
