Bản dịch tiếng Trung của lộ trình Ethereum được chú thích
Tiêu đề gốc: " Lộ trình Ethereum được chú thích 》
Bản tổng hợp gốc: domothy, trang web ETH tiếng Trung
Ghi chú của người dịch: Bài viết này được chú thích dựa trên lộ trình mới nhất của Ethereum, hình dưới đây là bản tiếng Trung do ECN dịch.
Mục đích của tài liệu này là cung cấp cơ sở để người đọc hiểu từng phần của lộ trình Ethereum. Mỗi phần được giới thiệu ngắn gọn. Nếu bạn muốn hiểu rõ hơn, vui lòng tham khảo nội dung, đính kèm link chi tiết.
Đây là tài liệu được cập nhật liên tục. Nếu bạn thấy bất kỳ thông tin nào được cung cấp ở đây không rõ ràng , thông tin không chính xác, lỗi thời hoặc thiếu, vui lòng liên hệ với tôi.
Lưu ý: Theo chỉ dẫn bằng mũi tên trên lộ trình, các đoạn liệt kê không phải là công việc liên tiếp, và sự thăng tiến của họ là song song.
Sáp nhập
Mục tiêu: Thực hiện một cơ chế đồng thuận PoS lý tưởng, ngắn gọn, mạnh mẽ và phi tập trung
Công việc đã hoàn thành
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 PoS, với người xác thực cam kết ETH sẽ duy trì tính bảo mật mạng của lớp này
· Chuỗi beacon nằm ở Thông số đồng thuận được gọi là Giai đoạn 0 (Phiên bản có chú thích của Vitalik và Phiên bản có chú thích của Danny Ryan )
Ngày 27 tháng 10 năm 2021 - Warm-up Fork (Altair) - Các nhà phát triển ứng dụng khách lớp đồng thuận đã tiến hành chạy thử trong việc phối hợp nâng cấp hard fork
· Altair giới thiệu Ủy ban đồng bộ hóa sẽ hỗ trợ các khách hàng nhẹ và thực hiện một số điều chỉnh đối với các hình phạt
· Thông báo nâng cấp mạng chính của Altair
· Altair Spec (Phiên bản có chú thích)
· "Có gì mới trong ETH2" Vấn đề Altair được giải thích
Ngày 15 tháng 9 năm 2022 - Hợp nhất! Ngừng sử dụng PoW - Hoàn thành việc hợp nhất lớp đồng thuận và lớp thực thi ở độ cao khối 15,537,394
Bước tiếp theo ;
Rút tiền —cho phép người xác nhận rút toàn bộ hoặc một phần số tiền đã cam kết của họ
· Ngã ba Capella ;Chỉ định các thay đổi trong lớp đồng thuận
· EIP-4895 Chỉ định thực thi Thay đổi trong các lớp
· Câu hỏi thường gặp của Tim Beiko về việc rút tiền
· ;Đặc tả meta rút tiền và các thông tin khác
Trình xác thực được phân phối —"Đa chữ ký, chỉ để đặt cược". Trong công nghệ này, n mọi người chia sẻ cùng một trình xác thực và ;m-of-n phải đồng ý về cách thức nó sẽ hoạt động
· Tăng cường cơ chế đặt cược bằng cách ngăn chặn việc cắt xén vô tình và Giúp việc tham gia trở nên dễ dàng hơn (ví dụ: bằng cách bảo vệ một cách đáng tin cậy các yêu cầu 32 ETH giữa nhiều người tham gia)
· Tính năng này không hoạt động trong giao thức, SSV và ;Obol đang thực hiện nghiên cứu này
Xem hợp nhất —Điều chỉnh quy tắc lựa chọn phân 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 là "buộc" những người xác minh trung thực nhìn thấy đúng người đứng đầu chuỗi để giảm bớt hành vi xấu xa. Cơ hội cho người xác thực chia phiếu bầu và tổ chức lại khối theo hướng có lợi cho mình.
· bài đăng ethresear.ch Có rất nhiều kiến thức nền tảng (rất kỹ thuật) về nghiên cứu này trong a> Sự trùng hợp cải tiến ; —Ethereum cố gắng hỗ trợ càng nhiều người xác thực càng tốt, nhưng việc để mỗi người xác thực bỏ phiếu trên mỗi khối (và xác thực mọi phiếu bầu của người xác thực khác) sẽ tiêu tốn quá nhiều băng thông. Điều tốt nhất tiếp theo là tổng hợp chữ ký, nhưng việc này có những hạn chế và có thể được thực hiện tốt hơn · Giới thiệu về lợi ích của chữ ký tổng hợp BLS Bài giải thích · Công nghệ chữ ký ứng viên tiềm năng: Horn Tính hoàn thiện của việc triển khai một vị trí (SSF) —hoàn thiện mọi trạng thái chuỗi vị trí khác (12 giây) thay vì mọi trạng thái kỷ nguyên (12,8 phút) · Đường dẫn đến vị trí cuối cùng duy nhất (Phiên bản tiếng Trung) Ngoài việc cải thiện việc tổng hợp chữ ký, chúng tôi cũng phải tìm ra hai điều: Thuật toán đồng thuận SSF ;- Thuật toán tương thích với SSF hiện tại là chưa đủ, chúng tôi muốn một thuật toán có thể giữ cho chuỗi tồn tại ngay cả khi có hơn 1313 trình xác nhận ngoại tuyến. Kinh tế của người xác thực SSF - Nếu cuối cùng chúng ta phải hạn chế số lượng người xác nhận, thì làm cách nào để hạn chế tỷ lệ tham gia và chúng ta cần phải hy sinh những gì? Bầu cử lãnh đạo bí mật (SLE) ·Hiện tại, người xác nhận (người đứng đầu một vị trí riêng lẻ) được chọn để đề xuất một khối đã được biết trước một chút, 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 đứng đầu của khối sắp tới. · ethresear.ch ;Có một bài đăng về một giao thức bầu cử người lãnh đạo bí mật duy nhất dựa trên sự xáo trộn ngẫu nhiên: không ai ngoại trừ chính người lãnh đạo biết ai sẽ là người đứng đầu vị trí này cho đến khi họ khớp khối của họ với người đứng đầu. Bằng chứng sẽ được công bố cùng nhau. · Bầu cử lãnh đạo bí mật không duy nhất cũng có thể là một lựa chọn. Hỗ trợ nhiều trình xác thực hơn —Nỗ lực liên tục, lâu dài: Hỗ trợ nhiều trình xác thực hơn một cách an toàn luôn là mục tiêu của chúng tôi Chữ ký thân thiện với hội tụ, an toàn lượng tử —làm cho lượng tử Ethereum trước khi máy tính lượng tử trở thành mối quan tâm chính đáng Bảo mật là một phần trong nỗ lực lâu dài của chúng tôi · Lược đồ chữ ký BLS được sử dụng dựa trên mật mã được biết là có thể bị phá vỡ bởi máy tính lượng tử, nhưng các lược đồ chữ ký thay thế được biết là an toàn lượng tử không tổng hợp chữ ký hiệu quả như BLS (do đó cần có một sơ đồ vừa an toàn lượng tử vừa thân thiện với tổng hợp). · Hai giải pháp bảo mật lượng tử chính là dựa trên STARK và dựa trên Lattice. Mục tiêu: Đảm bảo độ tin cậy và đáng tin cậy Quy trình đóng gói giao dịch trung lập tránh được rủi ro tập trung hóa và các giao thức khác do MEV mang lại. Các liên kết liên quan: · Sử dụng tính trung lập đáng tin cậy làm nguyên tắc chỉ đạo · Danh sách các liên kết về PBS Thị trường MEV ngoài thỏa thuận—Trung cấp MEV-Boost Phần mềm 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ự mình thực hiện 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 thiện , Vì nó có vấn đề về kiểm duyệt · Đọc bài viết "Cái giá của khả năng phục hồi" and "Tương lai của MEV là TUYỆT VỜI", hãy tìm hiểu về các kế hoạch giúp thị trường MEV ngoài những thỏa thuận này trở nên linh hoạt hơn Danh sách đóng gói hoặc các lựa chọn thay thế —Hãy để người đề xuất khối xây dựng các hạn chế khối, nghĩa là buộc chúng phải được đưa vào các giao dịch · Ghi chú liên quan đến danh sách đóng gói Nghiên cứu cách thực hiện để hạn chế những người xây dựng mà không làm tăng gánh nặng cho những người đề xuất · PBS trong giao thức —Viết trực tiếp thị trường xây dựng khối vào giao thức Phá hủy MEV —cho phép chuỗi khối nhận được giá trị ban đầu được trích xuất từ nền kinh tế trên chuỗi · Thông qua đấu giá người đề xuất Đề xuất trực tiếp tiêu diệt MEV · Phân phối đồng đều MEV do ủy ban điều khiển Giúp giao thức nhận thức được MEVThe Scourge (giải quyết những mối nguy hiểm tiềm ẩn)
Công việc đã hoàn thành
Bước tiếp theo ;
Giảm thiểu MEV của lớp ứng dụng —Công việc này không liên quan trực tiếp đến L1, nó Khi điều quan trọng là các nhà phát triển cần lưu ý đến MEV khi thiết kế dapp của họ. Dưới đây là một số ví dụ về các dapp áp dụng chiến lược giảm thiểu MEV
Lộ trình xây dựng phân tán
Vì quy trình đề xuất khối vẫn được phân cấp nên giờ đây chúng tôi có một vấn đề riêng là việc xây dựng khối trở nên tập trung. Ngay cả khi mọi thứ khác trong lộ trình đều hướng đến việc giảm thiểu các tình huống xấu nhất mà việc tập trung xây dựng khối có thể mang lại, việc có thể phân phối xây dựng khối trên nhiều nút vẫn là một lợi ích lớn.
· Cấu trúc Blob - Đang tìm cách giảm bớt yêu cầu xử lý và băng thông cao của việc phân chia dữ liệu trên nhiều nút ở cấp độ người tiêu dùng thông thường. Phần cứng có thể chạy.
· Dịch vụ xác nhận trước - Cung cấp cho người dùng sự đảm bảo chắc chắn rằng các giao dịch của họ sẽ được đưa vào khối tiếp theo
· Bảo vệ chạy trước - Giảm thiểu độc tính MEV, chẳng hạn như các cuộc tấn công bánh sandwich , cho phép các quy trình xây dựng phân tán duy trì độ tin cậy và trung lập
Đây vẫn là một lĩnh vực nghiên cứu tích cực , có những cân nhắc về thiết kế rất cởi mở, vì vậy không rõ liệu hai hộp đầu tiên có nên được ghi vào nghị định thư hay không (do đó có dấu hỏi trong lộ trình), đây là các liên kết có liên quan:
· Bài phát biểu trên Xây dựng khối sau sáp nhập, đề cập đến việc xây dựng khối phi tập trung
· Bài phát biểu về Nhà xây dựng phi tập trung
· Một số suy nghĩ về việc xây dựng khối phân tán
The Verge
Mục tiêu: Việc xác minh các khối phải cực kỳ dễ dàng - 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 một SNARK và bạn đã hoàn tất.
Phần này về cơ bản là nhằm lấp đầy khoảng trống "Những thiếu sót của ứng dụng khách": 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 lựa chọn thay thế không đáng tin cậy hoặc giảm thiểu độ tin cậy, dễ chạy và không yêu cầu dung lượng lưu trữ và băng thông lớn. Mục tiêu cuối cùng của The Verge là yêu cầu những ứng dụng khách nhẹ này cung cấp sự đảm bảo bảo mật giống như các nút đầy đủ hiện đang cung cấp.
Tất cả điều này đều dựa trên các kỹ thuật không có kiến thức như SNARK và STARK, vốn dựa vào các sơ đồ cam kết đa thức. Dưới đây là một số liên kết về vấn đề này:
· Giới thiệu lý do tại sao có thể sử dụng zk-SNARK Phiên bản tiếng Trung
· Giả sử bạn là người biết một số môn toán và lập trình, zkSNARK sẽ được giải thích cho bạn
· Về vai trò của kế hoạch cam kết đa thức trong việc mở rộng Ethereum
Công việc đã hoàn thành
Đã giải quyết các vấn đề DoS EVM nghiêm trọng nhất —chủ yếu là vấn đề về giá gas, đã được giải quyết nâng cấp tại Berlin
Hỗ trợ ứng dụng khách nhẹ 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 ứng dụng khách nhẹ của Lớp tuân thủ sự đồng thuận
· Tìm hiểu Cách khách hàng Helios sử dụng các ủy ban đồng bộ hóa (giải thích rõ ràng về cách thức hoạt động của các ủy ban này)
Bước tiếp theo
Triển khai EIP-4844 —Triển khai EIP-4844 trên mạng chính
· Cần có một "buổi lễ" để tạo khởi tạo đáng tin cậy: Giải thích, Dòng thời gian ước tính, Thông số kỹ thuật
· Tổng quan về tiến trình triển khai EIP-4844
Mở rộng tổng hợp cơ bản —dựa vào công việc sau:
· EIP-4844 - Khả năng mở rộng đạt được vẫn được coi là cơ bản/có giới hạn do tính chất "mỗi nút tải xuống tất cả dữ liệu ” giới hạn dung lượng khả dụng của blobspace
· Giai đoạn cuộn lên của bánh xe phụ bị hạn chế (bài viết đề xuất loại bỏ bánh xe phụ của rollup Lộ trình) (Phiên bản tiếng Trung)
Hoàn thành việc mở rộng tổng hợp —phụ thuộc vào công việc sau:
· Thiết kế P2P của DAS (Data Availability Sampling): Một số công việc và nghiên cứu liên quan đến vấn đề kết nối mạng bảo vệ dữ liệu
· Data Availability Sampling Client: Phát triển một client nhẹ có thể được truy cập bằng cách Lấy mẫu ngẫu nhiên vài kilobyte để nhanh chóng xác định xem dữ liệu có sẵn hay không
· DA tự phục hồi hiệu quả: có thể tái tạo lại hiệu quả tất cả dữ liệu trong điều kiện mạng tồi tệ nhất (ví dụ: cuộc tấn công của trình xác thực độc hại hoặc khối lớn Thời gian ngừng hoạt động kéo dài của các nút)
· Triển khai không có bánh xe huấn luyện: trình sắp xếp chuỗi phi tập trung hoàn toàn, bằng chứng gian lận không đáng tin cậy, hợp đồng bất biến, v.v
Lời hứa về khởi tạo an toàn lượng tử, không cần tin cậy —Điều gì làm cho Ethereum an toàn lượng tử trước khi máy tính lượng tử trở thành mối lo ngại chính đáng Một phần trong nỗ lực lâu dài của chúng tôi
· Mặc dù hiệu quả và mạnh mẽ nhưng các cam kết đa thức (KZG) được sử dụng ở mọi nơi không an toàn lượng tử và cần có quá trình khởi tạo đá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à trao đổi nóng KZG một cách bí mật
SNARK / Mạch tích hợp dành riêng cho ứng dụng STARK —phần cứng được sử dụng đặc biệt để tạo bằng chứng
Cây Verkle ;—Thay thế cấu trúc dữ liệu được sử dụng cho nhà nước toàn cầu với một phiên bản hiệu quả hơn
· Danh sách liên kết của Verkle Tree
· Lợi ích chính là khả năng tạo ra các bằng chứng rất ngắn gọn mà các client nhẹ có thể dễ dàng vượt qua. Các tiêu đề khối có thể dễ dàng xác minh những bằng chứng này để xác minh những thứ như số dư tài khoản - họ có thể tận dụng các ủy ban đồng bộ hóa để xác minh rằng tiêu đề khối nhất định thực sự là một phần của chuỗi chính
· Cần phải viết ra các thông số kỹ thuật phù hợp, đảm bảo quá trình di chuyển an toàn và tìm hiểu xem nó sẽ diễn ra như thế nào ảnh hưởng đến chi phí khí EVM của trạng thái cập nhật/chỉnh sửa (điều này cũng phụ thuộc vào công việc hoàn tác "TỰ HỦY" trong phần The Purge)
Ứng dụng khách nhẹ dựa trên SNARK —tạo bằng chứng SNARK cho các chuyển đổi trạng thái của ủy ban đồng bộ hóa để nhanh chóng chứng minh trình xác thực nào tạo nên ủy ban đồng bộ hóa hiện tại
Ethereum hoàn toàn dựa trên SNARK —Ba mục sau đây cùng nhau tạo thành một cột mốc quan trọng trong "Bức tranh cuối cùng về Ethereum" (phiên bản tiếng Trung), tức là việc hiện thực hóa khối cực kỳ hiệu quả và không cần tin cậy xác minh:
· SNARK cho bằng chứng Verkle - bằng cách kết hợp các bằng chứng Verkle thành một SNARK duy nhất, các khối sẽ chứa một bằng chứng độc lập ngắn về trạng thái một phần mà họ đã sửa đổi, do đó không cần phải xác minh toàn bộ trạng thái của khối N-1 để xác minh rằng khối N-1 đã sửa đổi nó một cách chính xác.
· SNARK để chuyển đổi trạng thái đồng thuận—chuyển từ ủy ban đồng bộ hóa giảm thiểu độ tin cậy sang xác minh hoàn toàn không cần tin cậy đối với mọi thứ xảy ra trên lớp đồng thuận
· Đối với SNARK cho L1 EVM —Tận dụng công việc mà nhóm tổng hợp đã thực hiện trên zk-EVM để tích hợp trực tiếp zk-EVM vào L1
· Đọc về Bài đăng ghi tổng hợp trong giao thức
Tăng giới hạn gas L1 ;—Cho phép xác minh các khối không cần tin cậy bằng cách loại bỏ gánh nặng hiện tại là "mọi nút cần lưu trữ mọi thứ", điều này sẽ giúp việc hình thành các khối lớn hơn dễ dàng hơn để có thêm khả năng mở rộng L1 (tự động nâng cao hiệu ứng của tất cả tỷ lệ L2)
Chuyển sang SNARK an toàn lượng tử (như STARK) —Trước khi máy tính lượng tử trở thành mối quan tâm chính đáng, làm cho Ethereum trở nên an toàn lượng tử là một phần trong nỗ lực lâu dài của chúng tôi
· SNARK dựa trên mật mã được biết là có thể bị bẻ khóa bởi máy tính lượng tử, nhưng STARK không phải là
Cuộc thanh trừng
Mục tiêu: Đơn giản hóa giao thức, xóa nợ kỹ thuật và hạn chế chi phí tham gia mạng bằng cách làm sạch dữ liệu lịch sử
Công việc đã hoàn thành
· Hiểu hầu hết các khoản hoàn tiền gas —all Định giá lại gasCông việc đã hoàn thành trong quá trình nâng cấp ở Berlin
· Đồng bộ hóa nhanh chuỗi Beacon —đồng bộ hóa từ kỷ nguyên được hoàn thiện gần đây (được gọi là "điểm kiểm tra" trong hầu hết quá trình đồng bộ hóa máy khách lớp đồng thuận") thay vì đồng bộ hóa từ nguồn gốc, tất cả công việc phát triển về vấn đề này đã được thực hiện
· Thông số kỹ thuật EIP-4444 —Đọc Thông số kỹ thuật EIPHiểu
Các bước tiếp theo
Lịch sử ngủ đông dữ liệu —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 ngủ đông các trạng thái lịch sử cũ
· Đọc phần này Bài đăng dài trên Twitter
· Dựa vào việc triển khai EIP-4444, một giải pháp thay thế cho việc truy cập trạng thái lịch sử thông qua các phương tiện khác như Mạng cổng thông tin
· AMA của Vitalik về chế độ ngủ đông dữ liệu lịch sử
Trạng thái ngủ đông —Giới thiệu về trạng thái, khắc phục vấn đề "thanh toán một lần, lưu trữ dữ liệu vĩnh viễn"
· Ý tưởng chủ yếu là tự động cho các phần không sử dụng của hệ thống ngủ đông trạng thái, chỉ để lại gốc cây verkle mà người dùng có thể sử dụng để kích hoạt trạng thái ngủ đông nếu cần thiết
· AMA của Vitalik về cơ chế ngủ đông trạng thái
· Phụ thuộc vào các công việc sau:
- Đặc tả chế độ ngủ đông có trạng thái cơ bản: cách chúng tôi dự định triển khai nó, hãy xem Lộ trình tiềm năng này ( 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 để tránh xung đột và thêm dữ liệu về chu kỳ trạng thái
p>- Phân tích ứng dụng : Tìm hiểu xem nó sẽ phá vỡ các ứng dụng/hợp đồng hiện tại như thế nào và các ứng dụng/hợp đồng đó cần phải thích ứng như thế nào
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 hiệu quả hơn các chuỗi sự kiện lịch sử Phối hợp - 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ẽ dần dần từ bỏ RLP và sử dụng SSZ
Xóa 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ã máy khách (hy sinh một số khả năng tương thích ngược)
Tuyến đường đơn giản hóa EVM
· Hủy TỰ ĐỘNG— Mã opcode này là nguồn gốc của nhiều vấn đề
- Các giải pháp thiết thực để loại bỏ SELFDESTRUCT giải thích lý do và cách loại bỏ opcode này
- Các EIP liên quan: EIP-4758, EIP-4760 và các cuộc thảo luận
· Đơn giản hóa cơ chế khí - liên quan đến việc loại bỏ nhiều tính năng EVM liên quan đến khí, được đề cập ở đây Pass
· Precompilation-> Triển khai EVM—Bỏ hợp đồng được biên dịch trước và sử dụng triển khai EVM trực tiếp (tức là hoạt động mô-đun lớn, xem The Splurge)
The Splurge
Mục tiêu: Cải thiện những thứ khác
Tất cả những thứ tốt không cần mức độ ưu tiên cao hơn đều thuộc về The Splurge. Vấn đề lớn nhất là trừu tượng hóa tài khoản nhưng cũng có những chỉnh sửa nhỏ đối với nội dung hiện có.
Công việc đã hoàn thành
· EIP-1559 ;—EIP nổi tiếng nàyEIP mang đến nhiềuLợi ích thay vì chỉ là sự phá hủy
· Thông số kỹ thuật ETHERC-4337 —đây là ERC Nhằm mục đích giới thiệu tính năng trừu tượng hóa tài khoản mà không sửa đổi giao thức cốt lõi
Các bước tiếp theo
Dạng cuối cùng của EIP-1559 —bằng cách biến nó thành đa chiều. Để cải thiện EIP-1559, nó giống một đường cong AMM hơn và nhận biết theo thời gian
· Lộ trình cải tiến và đơn giản hóa EVM trong The Purge Together, các lộ trình hình thành nên hình thức cuối cùng của EVM
· Định dạng đối tượng EVM (EOF)—một tập hợp nhiều EIP cho phép xác minh và lập phiên bản mã byte EVM khi nó được triển khai. Xem bài viết giải thích này và chủ đề Twitter
· Số học mô-đun lớn — Phần lớn mật mã trong lộ trình dựa trên số học mô-đun trên số lượng lớn, có thể được thực hiện trực tiếp hiệu quả hơn trong EVM
· Tinh chỉnh thêm EVM—bất cứ điều gì khác đáng được thêm vào để cải thiện EVM hoặc loại bỏ thứ gì đó để loại bỏ sự phức tạp
Lộ trình trừu tượng hóa tài khoản để đạt được hình thức trừu tượng hóa tài khoản cuối cùng. Xem mô tả của Vitalik để biết chi tiết về:
· ERC-4337—Ví thông minh thực sự được chấp nhận, tương thích với sự phát triển
· Tự nguyện chuyển đổi tài khoản EOA - thông qua EIP, các tài khoản thông thường được phép thêm mã không thể đảo ngược để chuyển đổi chúng thành hợp đồng, do đó trở thành ví thông minh tương thích 4337.
·Được ghi vào giao thức—bắt buộc chuyển đổi ở trên trên tất cả các tài khoản hiện có
Chức năng trì hoãn có thể xác minh (VDF)— Về cơ bản " bằng chứng công việc không song song" sẽ nâng cao tính ngẫu nhiên được sử dụng trong PoS và những thứ khác
· Xem Bài đăng này giới thiệu VDF và các ứng dụng tiềm năng của chúng p>
Khám phá các giải pháp cho các tài khoản cũ—việc giải cứu những “tài sản bụi bặm” này tốn nhiều xăng hơn giá trị của chúng. Xem nhiều ý tưởng tại đây
Liên kết gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
Bài viết liên quan
