Bằng cách khởi động lại Ethereum, có thể giảm bớt gánh nặng cho các nút không?
Lưu ý của biên tập viên: Bài viết này đến từNhững người đam mê Ethereum (ID: ethfans)Những người đam mê Ethereum (ID: ethfans)
Những người đam mê Ethereum (ID: ethfans)
, Tác giả: Alexey Akhunov, dịch & hiệu đính: Min Min & A Jian, được Odaily tái bản với sự cho phép.
Trải nghiệm từ Cosmos Hub
Nếu bạn đã xem cách Cosmos Hub được nâng cấp từ phiên bản 1.0 lên phiên bản 2.0 lên phiên bản 3.0, bạn sẽ biết rằng việc nâng cấp Cosmos Hub về cơ bản đạt được bằng cách khởi động lại chuỗi khối bằng một khối genesis mới. Khi nâng cấp, người vận hành nút cần tắt nút, sau đó tạo ảnh chụp nhanh về trạng thái Cosmos Hub, sau đó đóng gói ảnh chụp nhanh này vào khối genesis mới để tạo chuỗi khối mới.
tiêu đề phụ
Chúng tôi có thể "khởi động lại" ETH 1.0 không?
Hãy tưởng tượng nếu phương pháp tương tự có thể được áp dụng cho Ethereum. Chuỗi khối Ethereum rất lớn (150-160 Gb) và trạng thái cũng rất lớn (40-100 Gb, tùy thuộc vào cách bạn lưu trữ trạng thái). Một lợi thế rõ ràng của việc "khởi động lại" chuỗi khối Ethereum là các nút mới tham gia cần tải xuống trạng thái khởi tạo 40Gb thay vì chuỗi khối 150Gb. Tuy nhiên, tải xuống trạng thái gốc 40 Gb cũng không phải là một trải nghiệm tuyệt vời.
Lưu trữ trạng thái của Ethereum ngoài chuỗi, chỉ hàm băm gốc Merkle hiển thị trên chuỗi
Giả sử chúng ta có thể lưu trữ 40 Gb "ngoài chuỗi" này và chỉ đóng gói hàm băm gốc vào khối gốc, chúng ta có thể bắt đầu từ trạng thái trống. Nhưng làm cách nào để chúng tôi cấp cho các giao dịch quyền truy cập vào trạng thái ẩn này?
tiêu đề phụ
Đây không phải là ethereum không trạng thái sao?
tiêu đề phụ
Bằng chứng trong khối so với Bằng chứng trong giao dịch
tiêu đề phụ
Nhược điểm của bằng chứng giao dịch
Giả sử chúng ta muốn người gửi giao dịch thêm bằng chứng về mọi trạng thái có liên quan vào giao dịch. Lợi ích của việc làm này là nó sẽ đơn giản hóa công việc chúng ta cần làm để nạp thêm xăng cho những người chứng kiến. Nhược điểm chính của điều này là điều này thường cần đạt được với Truy cập trạng thái động (DSA, trái ngược với Truy cập trạng thái tĩnh (SSA)). Nếu một giao dịch liên quan đến một hợp đồng thông minh đặc biệt phức tạp, chẳng hạn như với một số lượng lớn các cuộc gọi lồng nhau đến các hợp đồng khác, thì có thể khó tính toán trước các mục trạng thái mà giao dịch sẽ liên quan. Kẻ tấn công thậm chí có thể sử dụng DSA để "thiết lập" người dùng, nghĩa là chiếm trước giao dịch của họ (gửi các giao dịch có cùng nội dung nhưng phí gas cao hơn, được đóng gói trước mặt họ) để giao dịch của người dùng không thành công do không đủ bằng chứng.
Giảm thiểu được cung cấp bởi ReGenesis
Mặc dù rất khó để giải quyết hoàn toàn những nguy cơ tiềm ẩn của DSA, nhưng rủi ro của nó có thể được giảm thiểu nhiều nhất có thể, để người dùng không cảm thấy bất tiện và sẽ không bị giới hạn mãi mãi trong tình huống không thể đạt được quá trình chuyển đổi trạng thái như mong đợi. Việc giảm thiểu này yêu cầu đưa ra quy tắc bổ sung rằng bất kỳ bằng chứng nào được cung cấp cùng với giao dịch (đã được xác minh đối với gốc trạng thái, nhưng không đủ để đảm bảo giao dịch thành công) sẽ trở thành một phần của trạng thái ẩn. Do đó, khi người dùng liên tục cố gắng thực hiện giao dịch, trạng thái ẩn sẽ tăng lên và cuối cùng giao dịch thành công. Những kẻ tấn công cố gắng "hack" người dùng phải tìm những cách tinh vi hơn để chuyển hướng quyền truy cập trạng thái của người dùng ra ngoài trạng thái ẩn hiện có và cuối cùng thất bại.
Khi trạng thái ẩn phát triển từ không có (vừa khởi động lại) sang trạng thái bao gồm trạng thái ngày càng được truy cập tích cực hơn, các giao dịch cần cung cấp ít bằng chứng hơn. Sau một thời gian, hầu hết các giao dịch thậm chí không cần phải có bất kỳ bằng chứng nào kèm theo, ngoại trừ những giao dịch liên quan đến các quốc gia từ rất lâu trước đây.
Chúng tôi có thể thực hiện ReGenesis một cách thường xuyên
Tôi gọi đây là quá trình tái tạo "khởi động lại", có thể được thực hiện định kỳ để giảm tải cho các nút không khai thác. ReGenesis cũng đại diện cho một phiên bản ít triệt để hơn của Ethereum không trạng thái.
Việc triển khai ReGenesis nhiều lần sẽ đơn giản hóa kiến trúc triển khai ứng dụng khách Ethereum, gần như loại bỏ nhu cầu về thuật toán đồng bộ hóa ảnh chụp nhanh cấp cao hơn. Nếu chúng tôi thực hiện ReGenesis cứ sau 1 triệu khối (khoảng 6 tháng), các ảnh chụp nhanh trạng thái và tệp chuỗi khối có thể được công khai trên BitTorrent, Swarm và IPFS. Hiện tại, chúng tôi không thể thực hiện việc này (dung lượng lưu trữ được tạo) vì trạng thái chuyển đổi cứ sau 15 giây thay vì 6 tháng. Nếu việc triển khai ứng dụng khách có thể phát lại các khối có giá trị trong 6 tháng, thì chúng tôi không cần các thuật toán chụp nhanh phức tạp. Do đó, sự phức tạp của việc triển khai Ethereum sẽ giảm đi.
tiêu đề phụ
Nhược điểm của ReGenesis
Tôi chưa tìm hiểu sâu về vấn đề này, nhưng ba nhược điểm mà tôi thấy là:
