Beam Sync: Một cách mới để đồng bộ hóa các nút Ethereum
Lưu ý của biên tập viên: Bài viết này là từ:Những người đam mê Ethereum (ID: ethfans)Những người đam mê Ethereum (ID: ethfans)
, Tác giả: Jason Carver, bản dịch & hiệu đính: Chen Liang & A Jian, được Odaily tái bản với sự cho phép.
chữ
Tại sao phải cải thiện trải nghiệm đồng bộ hóa nút?
Tôi hơi rùng mình khi nghĩ về việc có bao nhiêu người vẫn đang sử dụng Infura (thông qua Metamask, Gnosis-Safe, v.v.) để tương tác với các ứng dụng trên chuỗi. Dịch vụ của Infura rất tuyệt, nhưng rõ ràng sẽ không ổn nếu hầu hết người dùng không chạy các nút của riêng họ. Ngay cả những nhà phát triển có năng lực và động lực cao nhất cũng không thể hoàn toàn thoát khỏi sự phụ thuộc vào Infura. Tại thời điểm này, chúng tôi vẫn chưa hoàn thành một phần quan trọng trong tầm nhìn "tự xác thực" của Ethereum.
Nhóm của chúng tôi muốn góp phần đảo ngược xu hướng này. Nhiệm vụ của chúng tôi là tăng số lượng nút trên mạng càng nhiều càng tốt, đặc biệt là những nút được điều hành bởi những người có sở thích, nhà nghiên cứu và nhà phát triển. Khi chúng tôi hỏi tại sao họ không chạy nút của riêng mình, câu trả lời đại loại như: "Tôi đã cài đặt phần mềm máy khách và tôi đã cố gắng đồng bộ hóa chuỗi khối, nhưng nó dường như không bao giờ đồng bộ hóa. Vì vậy, tôi đã dừng lại vì tôi có những thứ khác để LÀM."
tiêu đề cấp đầu tiên
Các phương pháp đồng bộ hóa hiện có
tiêu đề phụ
Full Sync (phương pháp đồng bộ hóa đầy đủ)
Cách tiếp cận hoàn toàn đồng bộ là thực thi mọi khối kể từ khối gốc. Khối gốc đánh dấu trạng thái gốc ban đầu (nội dung của trạng thái bao gồm số dư tài khoản, mã byte hợp đồng, nội dung lưu trữ hợp đồng, v.v.). Cái gọi là "khối thực thi" có nghĩa là mỗi khi một khối được tải xuống, trạng thái trước đó sẽ được đọc và một trạng thái mới được tạo ra (theo nội dung của khối) và trạng thái mới được sử dụng để xác minh trạng thái gốc trong tiêu đề khối (để xác minh rằng khối khối không phải là khối hợp lệ). Đồng bộ hóa hoàn toàn diễn ra rất chậm trên mạng chính Ethereum và khi mạng già đi, sẽ ngày càng mất nhiều thời gian hơn để đồng bộ hóa với khối mới nhất bằng phương pháp đồng bộ hóa đầy đủ. Vì vậy, mọi người đã phát triển phương pháp "đồng bộ hóa nhanh".
tiêu đề phụ
Fast Sync (phương thức đồng bộ nhanh)
Trước khi đồng bộ hóa nhanh có thể thực thi khối bắt đầu, trạng thái khối bắt buộc bao gồm: mã byte hợp đồng, tài khoản và nội dung lưu trữ hợp đồng. Bất kỳ giá trị nào trong số này có thể cần được đọc khi thực hiện giao dịch. Do đó, phương pháp đồng bộ hóa nhanh yêu cầu có được ảnh chụp nhanh trạng thái trước khi khối được bắt đầu từ các đồng nghiệp khác. Ảnh chụp nhanh được đánh dấu bằng giá trị băm gốc trạng thái; cái gọi là giá trị băm gốc trạng thái là giá trị gốc cây băm Merkle của tất cả nội dung trạng thái. Các nút sử dụng hàm băm gốc trạng thái này để xác minh rằng dữ liệu trạng thái được tải xuống từ các nút ngang hàng khác khớp với trạng thái được công cụ khai thác yêu cầu trong khối.
Sau khi phương thức đồng bộ nhanh đã tải xuống tất cả các trạng thái cần thiết, điều đó có nghĩa là nút đã có tất cả dữ liệu cần thiết để thực hiện giao dịch. Sau đó, từ thời điểm này, nút có thể chuyển sang chế độ đồng bộ hoàn toàn và các khối có thể được thực thi lần lượt từ khối bắt đầu, giống như nút đã hoàn thành quá trình đồng bộ hóa đầy đủ trước khối bắt đầu.
tiêu đề phụ
Các phương pháp khác
Các phương pháp đồng bộ hóa nhanh khác bao gồm Warp Sync cũng như một số phương pháp đồng bộ hóa hiện chưa được chứng minh. Ở mức độ trừu tượng hơn, chúng đều thuộc các dạng khác nhau của phương pháp đồng bộ nhanh. Ngoài ra, ngay cả việc hiểu các nguyên tắc của các phương pháp đồng bộ hóa khác này cũng sẽ không giúp hiểu được chiến lược đồng bộ hóa Beam, vì vậy các nguyên tắc đồng bộ hóa này không phải là trọng tâm của bài viết của chúng tôi và tôi sẽ nói về nó sau.
tiêu đề cấp đầu tiên
Phương pháp đồng bộ nhanh nhanh như thế nào?
Phương pháp đồng bộ hóa nhanh phải đối mặt với một số thách thức trong môi trường vận hành mạng chính hiện tại, vì đồng bộ hóa cần tải xuống rất nhiều dữ liệu, thậm chí hơn 100GB dữ liệu, do đó, có thể thực hiện được trong bước thứ hai "Nhận tất cả trạng thái" được hiển thị ở trên hình ' sẽ bị mắc kẹt trong một thời gian dài.
Nếu bạn không thể tải xuống tất cả dữ liệu trạng thái trong 30 phút (cảnh báo tiết lộ nội dung: bạn thực sự không thể hoàn thành nó), bạn cần thực hiện xoay (trục), nghĩa là chuyển sang khối khởi động mới và khởi động lại quá trình đồng bộ hóa, mặc dù không phải từ 0 nhưng cũng tăng thời gian tải xuống và xác minh các khối.
tiêu đề cấp đầu tiên
Tổng quan
Phương pháp đồng bộ tia
tiêu đề phụ
Phương pháp đồng bộ hóa chùm là kết quả của việc cải tiến trực tiếp phương pháp đồng bộ hóa nhanh.Sự khác biệt giữa hai phương pháp đồng bộ hóa là phương pháp đồng bộ hóa chùm trực tiếp thực thi khối khởi động ngay từ đầu và chỉ yêu cầu dữ liệu trạng thái bị thiếu trong cơ sở dữ liệu cục bộ và đặt trạng thái đầu vào và trạng thái đầu ra Lưu cục bộ. Sau khi thực hiện một khối, nó sẽ đồng bộ hóa với khối tiếp theo và lặp lại quy trình, yêu cầu dữ liệu bị thiếu nếu cần.
Theo thời gian, dữ liệu bị thiếu sẽ ngày càng ít đi. Lưu ý rằng nếu một trạng thái nhất định không bao giờ được truy cập, máy khách sẽ không bao giờ yêu cầu nó (và do đó không bao giờ nhận được phần dữ liệu trạng thái này), vì vậy chúng tôi chạy một quy trình khác trong nền để lấp đầy những khoảng trống này. Thông qua quy trình chèn lấp này, Beam Sync cuối cùng sẽ tìm nạp tất cả dữ liệu trạng thái và lưu cục bộ, sau đó nút có thể chuyển sang trạng thái được đồng bộ hóa hoàn toàn.
Chúng tôi gọi tập dữ liệu cần thiết để thực thi từng khối là "nhân chứng khối". Nhờ cấu trúc của cây Merkle, chúng tôi có thể chứng minh rằng dữ liệu nhân chứng thực sự được lấy từ trạng thái này mà không cần tải xuống trạng thái hoàn chỉnh (Ghi chú của người dịch: Đó là cái gọi là "bằng chứng Merkle").
tiêu đề phụ
Để đơn giản, chúng tôi sử dụng "kích thước dữ liệu nhân chứng khối" để chỉ số lượng phần tử dữ liệu cần thiết để thực thi một khối. Các thành phần dữ liệu như vậy có thể là một nút trên cây trạng thái tài khoản chính hoặc một nút trên cây lưu trữ hợp đồng hoặc mã byte hoàn chỉnh của hợp đồng (Ghi chú của người dịch: "Cây trạng thái" ở đây, "Cây lưu trữ" đều là dữ liệu có cấu trúc cây Merkle ).
Phân tích kích thước dữ liệu nhân chứng khối là chìa khóa để hiểu hiệu suất của phương pháp đồng bộ hóa Beam. Phương thức đồng bộ hóa nhanh phải tải xuống tất cả dữ liệu trạng thái trước khi thực hiện khối đầu tiên (tức là khối bắt đầu), trong khi Đồng bộ hóa tia chỉ cần tải xuống dữ liệu chứng kiến của một khối, nếu dữ liệu chứng kiến khối đã tải xuống chứa một phần ba trạng thái hoàn chỉnh Thứ nhất, khi đó Beam Sync sẽ chạy hiệu quả gấp khoảng ba lần so với Fast Sync.
Vì vậy, rõ ràng, bước tiếp theo là xem dữ liệu nhân chứng của mainnet thực sự lớn đến mức nào. Có thể còn quá sớm để đưa ra kết luận trực tiếp, nhưng kết quả thử nghiệm ban đầu cho thấy rằng 3000 nút cây trạng thái là một ước tính hợp lý (mức độ tin cậy 90%). Tổng thông tin trạng thái của mạng chính có hơn 300 triệu nút cây.
tiêu đề phụ
Cải thiện tốc độ cho Beam sync
Hãy xác định một tiêu chí mới: thời gian "bắt đầu thực hiện". Đây là thời gian cần thiết từ khi bắt đầu một nút có cơ sở dữ liệu trống đến khi hoàn thành việc nhập đầy đủ khối gần đây nhất.
Nếu Beam chỉ cần tải xuống 3000 nút cây trạng thái và đồng bộ hóa nhanh cần tải xuống 300 triệu nút cây, thì chúng ta có thể xác định giới hạn tốc độ của phương pháp Beam Sync: khi đồng bộ hóa mạng chính, nó có thể ở trong thời gian "bắt đầu thực hiện" Nhận mức tăng lên tới 100.000 lần!
Tuy nhiên, phương pháp Beam Sync thường không thực sự đạt được mức cải thiện 100.000 lần. Lý do bao gồm nhưng không giới hạn ở:
Dữ liệu nhân chứng khối được xác định theo yêu cầu, có nghĩa là chúng tôi không thể dự đoán trước dữ liệu trạng thái nào sẽ cần thiết (chỉ sau khi nhận được một dữ liệu, chúng tôi mới có thể xác định dữ liệu cần thiết tiếp theo là gì). Vì vậy, khi chúng tôi yêu cầu dữ liệu từ các nút ngang hàng, chúng tôi chỉ có thể yêu cầu một dữ liệu trạng thái tại một thời điểm. Ngược lại, Fast Sync có thể yêu cầu tối đa 384 nút cây cùng một lúc, điều này khiến Beam Sync nhạy cảm hơn với độ trễ của mạng ngang hàng.
Việc tìm các nút đồng bộ chất lượng cao, độ trễ thấp cần có thời gian. Thành thật mà nói, loại nút ngang hàng nào sẽ gặp phải là một sự kiện ngẫu nhiên thực sự.
Không giống như phương pháp đồng bộ nhanh, phương pháp đồng bộ chùm sẽ tiếp tục tải xuống trạng thái khối sau khối bắt đầu, điều này cũng sẽ làm chậm thời gian nhập khối. Nếu bạn có một số trực giác về điều này, bạn có thể nhận thấy rằng nếu thời gian trung bình để thu thập nhân chứng khối dài hơn thời gian trung bình để tạo ra một khối, thì vấn đề sẽ trở nên trầm trọng hơn.
tiêu đề phụ
Độ trễ đồng bộ tia
Độ trễ trong việc thu thập dữ liệu nhân chứng khối có thể tăng dần và sau đó bạn sẽ thấy rằng nút đồng bộ hóa Beam của mình bị trễ 5 phút. Điều đó có nghĩa là, khối mới nhất mà bạn có cục bộ thực sự là khối được tạo bởi toàn bộ mạng cách đây 5 phút, có nghĩa là khi RPC gọi số dư tài khoản nút hiện tại của bạn, nút của bạn sẽ phản hồi số dư năm phút trước.
Beam Sync Pivot
Trong thử nghiệm giai thoại, thông thường thời gian trễ rất khác nhau, từ 1 phút đến 20 phút. May mắn thay, chúng tôi có một số thủ thuật để phục hồi sau khi đồng bộ hóa khối bị trễ và trên thực tế, nói chung, bạn càng tụt lại phía sau, bạn càng phục hồi tốt hơn, điều này dẫn đến sự biến động lớn về thời gian trễ: , tiếp theo là bắt kịp nhanh và chu kỳ lặp đi lặp lại.
Một lý do khiến chúng tôi có thể bắt kịp nhanh hơn nếu một khối ở phía sau là chúng tôi có thể tạo dữ liệu nhân chứng cho nhiều khối trước và đồng thời. Rốt cuộc, bạn chỉ có thể tận dụng lợi thế của các khối tương lai này nếu bạn đi sau. Tất nhiên, nếu thời gian cần thiết để thu thập dữ liệu khối cần thiết luôn vượt quá thời gian tạo khối, thì không còn nghi ngờ gì nữa, bạn sẽ ngày càng đi sau sự phát triển của chuỗi khối. Chúng tôi hy vọng điều này sẽ không bao giờ xảy ra, nhưng chúng tôi cần Lập kế hoạch cho việc này.
tiêu đề phụ
Cơ chế xoay vòng trong đồng bộ hóa chùm giống như trong đồng bộ hóa nhanh, nút của bạn chọn một loạt khối để bỏ qua và chọn tiêu đề khối mới gần đầu chuỗi, sau đó, đồng bộ hóa chùm bắt đầu lại và nút Nó không chính xác đồng bộ hóa từ đầu, nó vẫn có tất cả dữ liệu từ lần đồng bộ hóa trước đó.
Được rồi, để xem tình hình thực tế như thế nào.
tiêu đề cấp đầu tiên
Đồng bộ chùm tia trên máy khách Trinity
tiêu đề phụ
nguyên mẫu được công bố
Một phiên bản alpha mới của ứng dụng khách Trinity đã được công bố vào tuần trước và phiên bản này bao gồm một nguyên mẫu của phương pháp đồng bộ hóa Beam chạy trên phần cứng cao cấp.
Lưu ý: Việc tăng Giới hạn Gas của khối từ 8 triệu lên 10 triệu dường như làm tăng thời gian trễ trung bình và nâng cấp Istanbul có thể giảm thời gian trễ vì nó làm tăng mức tiêu thụ gas cần thiết để ghi dữ liệu trạng thái trên chuỗi khối.
Hiện tại, Trinity vẫn là phiên bản alpha và phiên bản mới nhất vẫn còn nhiều vấn đề, chẳng hạn như việc đồng bộ hóa có thể bị dừng đột ngột sau một hoặc hai ngày. Cài đặt ứng dụng khách Trinity yêu cầu thêm công việc và đầu ra dòng lệnh là một mớ hỗn độn. Do đó, Trinity hiện chỉ sẵn sàng cho các nhà phát triển và nhà nghiên cứu tò mò và không ngại chơi với nó.
Các vấn đề chưa được giải quyết về cơ bản được phơi bày trong quá trình phát triển hàng ngày, vì vậy những vấn đề này là "lỗi trên nhật ký nền". Tại thời điểm này, có thể nói rằng không ai lo lắng rằng Beam Sync sẽ là một giấc mơ không thể đạt được. Sự tự tin trong việc đồng bộ hóa Beam là một điều mới mẻ. Nhưng chúng tôi cũng nghĩ rằng có thể sẽ có những vấn đề đột ngột chưa được giải quyết trong tương lai, giống như một tháng trước!
công việc còn lại
Ngoài công việc triển khai và gỡ lỗi cơ bản, chúng tôi vẫn còn rất nhiều công việc khác phải làm. Trinity chưa triển khai cơ chế chèn lấp cho trạng thái (tức là tải xuống các sự kiện, giao dịch và dữ liệu cũ trước khối bắt đầu). Hiện tại, cách duy nhất để kích hoạt cơ chế chuyển đổi là khởi động lại Trinity và chưa biết cấu hình phần cứng tối thiểu cần thiết cho phương thức đồng bộ hóa Beam (chúng tôi hoan nghênh mọi người giúp chúng tôi thu thập dữ liệu liên quan).
Tất cả các vấn đề trên đều đang được R&D tích cực và đây chỉ là một trong nhiều công việc trên Trinity, cảm ơn Ethereum Foundation đã tài trợ và hỗ trợ cho những nỗ lực này.
tiêu đề cấp đầu tiên
Có gì mới về Beam Sync?
Phương pháp đồng bộ hóa chùm tia, giống như các lý thuyết khác, dựa trên công trình nghiên cứu trước đó. Phương pháp tăng tốc độ đồng bộ hóa bằng cách tải xuống trạng thái mới nhất và bỏ qua việc thực thi các khối cũ (phương pháp đồng bộ hóa nhanh) không phải do chúng tôi phát minh ra. Phương thức thực thi các khối bằng cách dựa vào dữ liệu nhân chứng thay vì trạng thái hoàn chỉnh để tăng tốc độ thực thi không phải do chúng tôi phát minh. Để biết chi tiết, vui lòng tham khảo ứng dụng khách không trạng thái.
