Helios khách hàng ánh sáng Ethereum: thực hiện truy cập Blockchain không cần tin tưởng
Vào ngày 8 tháng 11, một khách hàng ánh sáng Ethereum mới mang tên Helios đã ra mắt. Khách hàng này được phát triển dựa trên ngôn ngữ Rust và nhằm cung cấp quyền truy cập Ethereum hoàn toàn không cần tin cậy.
Một trong những lý do chính mà chúng tôi sử dụng Blockchain là không cần phải tin tưởng. Thông qua Blockchain, chúng tôi có thể tự do kiểm soát tài sản và dữ liệu của mình. Trong hầu hết các trường hợp, các Blockchain như Ethereum thực sự đã thực hiện được lời hứa này: tài sản của chúng tôi thực sự thuộc về chúng tôi.
Tuy nhiên, để theo đuổi sự tiện lợi, chúng tôi cũng đã phải đưa ra một số thỏa hiệp. Một trong số đó là việc sử dụng RPC( tập trung để gọi xa) máy chủ. Người dùng thường truy cập Ethereum thông qua các nhà cung cấp tập trung. Những công ty này chạy các nút hiệu suất cao trên máy chủ đám mây, giúp người dùng dễ dàng truy cập dữ liệu trên chuỗi. Khi ví truy vấn số dư token hoặc kiểm tra xem giao dịch đang chờ xử lý đã được đưa vào khối hay chưa, hầu như luôn có sự tham gia của các nhà cung cấp tập trung này.
Vấn đề hiện tại của hệ thống là người dùng cần phải tin tưởng vào những nhà cung cấp này, trong khi không thể xác minh xem kết quả truy vấn có chính xác hay không.
Helios là một khách hàng ánh sáng Ethereum dựa trên Rust, có khả năng cung cấp quyền truy cập Ethereum hoàn toàn không cần tin cậy. Nó tận dụng giao thức khách hàng ánh sáng được thực hiện sau khi Ethereum chuyển sang PoS, có thể chuyển đổi dữ liệu từ các nhà cung cấp RPC tập trung không đáng tin cậy thành RPC cục bộ có thể xác minh an toàn. Kết hợp với RPC tập trung, Helios có thể xác minh tính xác thực của dữ liệu mà không cần chạy nút đầy đủ.
Việc khó có thể cân bằng giữa tính tiện lợi và phi tập trung là một điểm đau thường gặp, khách hàng ánh sáng mới này có thể hoàn thành việc đồng bộ trong khoảng hai giây và không cần lưu trữ, người dùng có thể truy cập dữ liệu trên chuỗi an toàn từ bất kỳ thiết bị nào ( bao gồm điện thoại di động và tiện ích mở rộng trình duyệt ). Nhưng việc phụ thuộc vào cơ sở hạ tầng tập trung có những rủi ro tiềm ẩn nào? Bài viết này sẽ hệ thống lại những rủi ro này, giới thiệu thiết kế của Helios và cung cấp một số ý tưởng, giúp các nhà phát triển đóng góp cho kho mã.
Rủi ro của hạ tầng tập trung: Sản phẩm lý thuyết trong "Rừng tối" của Ethereum
Một sản phẩm lý thuyết ẩn nấp trong rừng đen tối. Nó không tìm kiếm con mồi trong bộ nhớ giao dịch của Ethereum, mà thiết lập bẫy thông qua việc mô phỏng cơ sở hạ tầng tập trung mà chúng ta phụ thuộc. Người dùng rơi vào bẫy đó không mắc sai lầm nào: họ chỉ truy cập vào sàn giao dịch phi tập trung mà họ thường xuyên lui tới, đặt mức trượt hợp lý và giao dịch token như thường lệ... họ không làm gì sai, nhưng vẫn gặp phải một loại tấn công sandwich mới, đó là một cái bẫy được thiết lập cẩn thận tại lối vào rừng đen tối của Ethereum - nhà cung cấp RPC.
Trước khi đi vào chi tiết, chúng ta hãy xem cách mà sàn giao dịch phi tập trung xử lý các giao dịch. Khi người dùng thực hiện giao dịch trao đổi, họ sẽ cung cấp cho hợp đồng thông minh một vài tham số: token cần trao đổi, số lượng trao đổi, và quan trọng nhất, số lượng token tối thiểu mà người dùng phải nhận khi giao dịch được thực hiện. Tham số cuối cùng này chỉ ra "sản lượng tối thiểu" mà giao dịch phải đạt được, nếu không, giao dịch sẽ bị hủy. Điều này thường được gọi là "slippage", vì nó thiết lập hiệu quả mức chênh lệch giá tối đa có thể xảy ra từ khi giao dịch được gửi đến bộ nhớ và cho đến khi giao dịch được đưa vào khối. Nếu mức slippage được đặt quá thấp, người dùng có thể chỉ nhận được một số lượng token ít hơn. Tình huống này cũng có thể dẫn đến một cuộc tấn công sandwich, trong đó kẻ tấn công có thể chèn giá thầu của người dùng giữa hai giao dịch độc hại. Những giao dịch này sẽ đẩy giá giao ngay lên, buộc người dùng phải giao dịch với mức giá không tốt. Sau đó, kẻ tấn công sẽ ngay lập tức bán token, thu về lợi nhuận nhỏ.
Chỉ cần tham số sản xuất tối thiểu này được thiết lập gần với giá trị công bằng, bạn sẽ không bị tấn công sandwich. Nhưng nếu nhà cung cấp RPC của bạn không cung cấp báo giá chính xác cho hợp đồng thông minh của sàn giao dịch phi tập trung thì sao? Như vậy, người dùng có thể bị đánh lừa và ký giao dịch đổi với tham số sản xuất tối thiểu thấp hơn, tệ hơn nữa, người dùng có thể gửi giao dịch trực tiếp cho nhà cung cấp RPC độc hại. Nhà cung cấp có thể không phát tán giao dịch này đến bộ nhớ công cộng ( trong đó hàng chục robot đang cạnh tranh thực hiện tấn công sandwich ), mà giữ lại một cách riêng tư và gửi gói giao dịch bị tấn công trực tiếp đến một nền tảng MEV nào đó để kiếm lợi.
Nguyên nhân cơ bản gây ra cuộc tấn công này là sự tin tưởng vào người khác để giúp bạn lấy trạng thái Blockchain. Để giải quyết vấn đề này, người dùng có kinh nghiệm thường chạy nút Ethereum của riêng mình, công việc này cần tiêu tốn nhiều thời gian và tài nguyên, ít nhất cần một thiết bị luôn trực tuyến, hàng trăm GB dung lượng lưu trữ, và khoảng một ngày để đồng bộ hóa từ đầu. Quá trình này rõ ràng đã được đơn giản hóa hơn so với trước đây. Một số nhóm đã không ngừng nỗ lực, giúp mọi người chạy nút thông qua phần cứng chi phí thấp (, ví dụ như máy tính mini Raspberry Pi ) với ổ cứng ngoài. Nhưng ngay cả khi yêu cầu giảm đáng kể, việc chạy nút vẫn rất khó khăn đối với hầu hết người dùng, đặc biệt là những người sử dụng thiết bị di động.
Cần lưu ý rằng, mặc dù các cuộc tấn công của nhà cung cấp RPC tập trung hoàn toàn có thể xảy ra, nhưng thường chỉ là các cuộc tấn công lừa đảo đơn giản, loại tấn công mà chúng tôi đề cập chưa xảy ra. Mặc dù hồ sơ trong quá khứ của các nhà cung cấp lớn không cho chúng tôi lý do để nghi ngờ họ, nhưng việc nghiên cứu thêm trước khi thêm các nhà cung cấp RPC không quen thuộc vào ví vẫn là điều đáng giá.
Giới thiệu Helios: Truy cập Ethereum hoàn toàn không cần tin tưởng
Ethereum ra mắt giao thức khách hàng ánh sáng, mở ra những khả năng thú vị cho sự tương tác nhanh chóng trên Blockchain và xác thực các điểm RPC với yêu cầu phần cứng tối thiểu. Trong một tháng sau The Merge, một loạt các khách hàng ánh sáng độc lập lần lượt xuất hiện, mỗi cái đều có hướng đi riêng, nhưng cùng một mục tiêu: truy cập hiệu quả không cần tin cậy, mà không cần sử dụng nút đầy đủ.
Helios là một khách hàng ánh sáng Ethereum, có thể hoàn thành đồng bộ trong khoảng hai giây, không cần lưu trữ, và cung cấp quyền truy cập Ethereum hoàn toàn không cần tin tưởng. Giống như tất cả các khách hàng Ethereum khác, Helios bao gồm một lớp thực thi và một lớp đồng thuận. Nhưng khác với hầu hết các khách hàng khác, Helios kết hợp chặt chẽ hai lớp này, người dùng chỉ cần cài đặt và chạy một phần mềm duy nhất.
Nó hoạt động như thế nào? Lớp đồng thuận Helios sử dụng một băm khối chuỗi tín hiệu đã biết và kết nối với một RPC không đáng tin cậy, để đồng bộ hóa một cách có thể xác minh đến khối hiện tại. Lớp thực thi Helios kết hợp các khối chuỗi tín hiệu đã được xác minh này với RPC lớp thực thi không đáng tin cậy, để xác minh nhiều thông tin liên quan đến trạng thái trên chuỗi, chẳng hạn như số dư tài khoản, lưu trữ hợp đồng, biên nhận giao dịch và kết quả gọi hợp đồng thông minh. Những thành phần này hoạt động cùng nhau để cung cấp cho người dùng RPC hoàn toàn không cần tin cậy và không cần chạy nút đầy đủ.
lớp đồng thuận
Lớp đồng thuận khách hàng ánh sáng phù hợp với tiêu chuẩn khách hàng ánh sáng của chuỗi tín hiệu, và đã sử dụng ủy ban đồng bộ của chuỗi tín hiệu ( được ra mắt trước khi phân nhánh cứng Altair của Merge ). Ủy ban đồng bộ là một tập hợp con gồm 512 xác nhận viên được chọn ngẫu nhiên, với chu kỳ phục vụ khoảng 27 giờ.
Khi các người xác thực vào ủy ban đồng bộ, họ sẽ ký tất cả các tiêu đề khối chuỗi tín hiệu mà họ thấy (block header). Nếu hơn hai phần ba thành viên của ủy ban ký một tiêu đề khối, thì khối đó rất có thể nằm trong chuỗi tín hiệu theo quy chuẩn. Nếu Helios hiểu về thành phần của ủy ban đồng bộ hiện tại, nó có thể theo dõi đầu chuỗi một cách chắc chắn bằng cách truy vấn chữ ký ủy ban đồng bộ gần đây từ RPC không đáng tin cậy.
Nhờ vào việc tổng hợp chữ ký BLS, chỉ cần một truy vấn là có thể hoàn thành việc xác minh tiêu đề khối mới. Chỉ cần chữ ký hợp lệ và hơn hai phần ba thành viên ủy ban hoàn thành chữ ký, có thể đảm bảo khối đã được bao gồm trong chuỗi (. Tất nhiên, nó cũng có thể được tái cấu trúc ra khỏi chuỗi, và việc theo dõi tính cuối cùng của khối có thể cung cấp sự đảm bảo mạnh mẽ hơn ).
Nhưng rõ ràng có một khâu thiếu trong chiến lược này: làm thế nào để tìm ra ủy ban đồng bộ hiện tại. Đầu tiên cần có một gốc tin cậy gọi là điểm kiểm tra chủ quan yếu (weak subjectivity checkpoint). Đừng để cái tên làm bạn sợ, nó chỉ đơn giản là một cái gì đó có thể đảm bảo rằng một hash khối cũ nào đó đã được đưa vào chuỗi tại một thời điểm nào đó trong quá khứ. Về thời gian chính xác tồn tại của điểm kiểm tra, có một số tính toán toán học thú vị: phân tích tình huống tồi tệ nhất cho thấy khoảng hai tuần, trong khi ước tính thực tế hơn cho thấy có thể là vài tháng.
Nếu điểm kiểm tra quá cũ, về lý thuyết có thể xảy ra cuộc tấn công lừa đảo các nút theo chuỗi sai. Lúc này, việc lấy điểm kiểm tra chủ quan yếu đã vượt quá khả năng của giao thức. Giải pháp của Helios là cung cấp một điểm kiểm tra ban đầu, được mã hóa cứng vào kho mã ( rất dễ bị ghi đè ), nó sẽ lưu trữ băm khối cuối cùng mới nhất trên máy tính địa phương, để sử dụng làm điểm kiểm tra khi các nút đồng bộ.
Thông qua thao tác băm, khối chuỗi tín hiệu có thể dễ dàng tạo ra băm khối tín hiệu duy nhất. Như vậy, có thể dễ dàng truy vấn khối tín hiệu hoàn chỉnh từ các nút, sau đó thông qua thao tác băm và so sánh với băm khối đã biết để chứng minh tính hợp lệ của nội dung khối. Helios tận dụng thuộc tính này để lấy và xác minh một số trường trong khối điểm kiểm tra chủ quan yếu, bao gồm hai trường quan trọng: ủy ban đồng bộ hiện tại và ủy ban đồng bộ tiếp theo. Quan trọng nhất, khách hàng ánh sáng có thể tận dụng cơ chế này để nhanh chóng xem xét lịch sử chuỗi khối.
Bây giờ với điểm kiểm tra tính chủ quan yếu, chúng ta có thể lấy và xác minh hội đồng đồng bộ hiện tại và tiếp theo. Nếu đầu chuỗi hiện tại và điểm kiểm tra đều trong cùng một chu kỳ hội đồng đồng bộ, chúng ta có thể ngay lập tức bắt đầu sử dụng tiêu đề hội đồng đồng bộ đã ký để xác minh khối mới. Nếu điểm kiểm tra của chúng ta đứng sau một số hội đồng đồng bộ, thì có thể:
1.Sử dụng ủy ban đồng bộ tiếp theo sau điểm kiểm tra để lấy và xác minh một khối của ủy ban đồng bộ sẽ được tạo ra trong tương lai.
2.Sử dụng khối mới này để nhận ủy ban đồng bộ tiếp theo.
Nếu điểm kiểm tra vẫn ở phía sau, quay lại bước 1.
Thông qua quy trình trên, chúng tôi có thể nhanh chóng xem xét lịch sử của Blockchain theo đơn vị 27 giờ, bắt đầu từ bất kỳ băm khối nào trong quá khứ cho đến băm khối hiện tại.
lớp thực thi
Mục tiêu của khách hàng ánh sáng của lớp thực thi là kết hợp tiêu đề khối tín hiệu đã được xác thực qua lớp đồng thuận với RPC lớp thực thi không đáng tin cậy, cung cấp dữ liệu lớp thực thi đã được xác thực. Sau đó, dữ liệu này có thể được truy cập thông qua máy chủ RPC được lưu trữ cục bộ bởi Helios.
Dưới đây là một ví dụ đơn giản về việc lấy số dư tài khoản, trước tiên hãy giới thiệu một cách đơn giản về cách Ethereum lưu trữ trạng thái. Mỗi tài khoản chứa một số trường, chẳng hạn như băm mã hợp đồng, số ngẫu nhiên, băm lưu trữ và số dư. Những tài khoản này được lưu trữ trong một cây Merkle-Patricia lớn đã được điều chỉnh, được gọi là cây trạng thái. Chỉ cần biết gốc của cây trạng thái, bạn có thể xác minh chứng minh Merkle, để chứng minh xem có bất kỳ tài khoản nào tồn tại trong cây hay không. Chứng minh này không thể bị làm giả.
Helios có một trạng thái gốc đã được xác thực từ lớp đồng thuận (state root). Bằng cách áp dụng trạng thái gốc này và yêu cầu chứng minh Merkle từ lớp thực thi không tin cậy, Helios có thể xác minh tất cả dữ liệu lưu trữ trên Ethereum một cách cục bộ.
Chúng tôi sử dụng các công nghệ khác nhau để xác thực dữ liệu khác nhau được sử dụng bởi lớp thực thi, nhờ đó, chúng tôi có thể xác thực tất cả dữ liệu từ RPC không đáng tin cậy. RPC không đáng tin cậy có thể từ chối cung cấp quyền truy cập dữ liệu, nhưng không thể cung cấp kết quả sai.
Sử dụng Helios trong thế giới thực
Khó khăn trong việc cân bằng giữa tính tiện lợi và phi tập trung là một điểm đau phổ biến, thông qua Helios nhẹ, người dùng có thể truy cập dữ liệu chuỗi an toàn từ bất kỳ thiết bị nào ( bao gồm điện thoại di động và plugin trình duyệt ). Điều này sẽ cho phép nhiều người hơn có thể truy cập dữ liệu Ethereum không cần tin tưởng, bất kể phần cứng nào được sử dụng. Người dùng có thể sử dụng Helios làm nhà cung cấp RPC của họ trong một ví nào đó, để truy cập các DApp khác nhau một cách không cần tin tưởng, toàn bộ quá trình không cần bất kỳ thay đổi nào khác.
Ngoài ra, sự hỗ trợ của Rust cho WebAssembly cho phép các nhà phát triển ứng dụng dễ dàng nhúng Helios vào các ứng dụng Javascript ( như ví và DApp ). Những tích hợp này sẽ nâng cao tính bảo mật của Ethereum, giảm bớt nhu cầu tin tưởng vào cơ sở hạ tầng tập trung.
Có nhiều cách để đóng góp cho Helios, ngoài việc xây dựng mã nguồn, bạn cũng có thể phát triển phần mềm tích hợp Helios để tận dụng những lợi thế của nó. Dưới đây là một số ý tưởng thú vị:
Hỗ trợ lấy dữ liệu khách hàng ánh sáng trực tiếp từ mạng P2P, thay vì từ RPC.
Triển khai một số phương thức RPC bị thiếu
Xây dựng phiên bản Helios có thể biên dịch sang WebAssembly
Tích hợp Helios trực tiếp vào phần mềm ví
Xây dựng bảng điều khiển mạng để xem số dư token, nhúng Helios vào trang web sử dụng WebAssembly để lấy dữ liệu
Triển khai API động cơ, kết nối lớp đồng thuận Helios với nút toàn bộ của lớp thực thi hiện có
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Helios khách hàng ánh sáng: thực hiện truy cập Ethereum không cần tin cậy
Helios khách hàng ánh sáng Ethereum: thực hiện truy cập Blockchain không cần tin tưởng
Vào ngày 8 tháng 11, một khách hàng ánh sáng Ethereum mới mang tên Helios đã ra mắt. Khách hàng này được phát triển dựa trên ngôn ngữ Rust và nhằm cung cấp quyền truy cập Ethereum hoàn toàn không cần tin cậy.
Một trong những lý do chính mà chúng tôi sử dụng Blockchain là không cần phải tin tưởng. Thông qua Blockchain, chúng tôi có thể tự do kiểm soát tài sản và dữ liệu của mình. Trong hầu hết các trường hợp, các Blockchain như Ethereum thực sự đã thực hiện được lời hứa này: tài sản của chúng tôi thực sự thuộc về chúng tôi.
Tuy nhiên, để theo đuổi sự tiện lợi, chúng tôi cũng đã phải đưa ra một số thỏa hiệp. Một trong số đó là việc sử dụng RPC( tập trung để gọi xa) máy chủ. Người dùng thường truy cập Ethereum thông qua các nhà cung cấp tập trung. Những công ty này chạy các nút hiệu suất cao trên máy chủ đám mây, giúp người dùng dễ dàng truy cập dữ liệu trên chuỗi. Khi ví truy vấn số dư token hoặc kiểm tra xem giao dịch đang chờ xử lý đã được đưa vào khối hay chưa, hầu như luôn có sự tham gia của các nhà cung cấp tập trung này.
Vấn đề hiện tại của hệ thống là người dùng cần phải tin tưởng vào những nhà cung cấp này, trong khi không thể xác minh xem kết quả truy vấn có chính xác hay không.
Helios là một khách hàng ánh sáng Ethereum dựa trên Rust, có khả năng cung cấp quyền truy cập Ethereum hoàn toàn không cần tin cậy. Nó tận dụng giao thức khách hàng ánh sáng được thực hiện sau khi Ethereum chuyển sang PoS, có thể chuyển đổi dữ liệu từ các nhà cung cấp RPC tập trung không đáng tin cậy thành RPC cục bộ có thể xác minh an toàn. Kết hợp với RPC tập trung, Helios có thể xác minh tính xác thực của dữ liệu mà không cần chạy nút đầy đủ.
Việc khó có thể cân bằng giữa tính tiện lợi và phi tập trung là một điểm đau thường gặp, khách hàng ánh sáng mới này có thể hoàn thành việc đồng bộ trong khoảng hai giây và không cần lưu trữ, người dùng có thể truy cập dữ liệu trên chuỗi an toàn từ bất kỳ thiết bị nào ( bao gồm điện thoại di động và tiện ích mở rộng trình duyệt ). Nhưng việc phụ thuộc vào cơ sở hạ tầng tập trung có những rủi ro tiềm ẩn nào? Bài viết này sẽ hệ thống lại những rủi ro này, giới thiệu thiết kế của Helios và cung cấp một số ý tưởng, giúp các nhà phát triển đóng góp cho kho mã.
Rủi ro của hạ tầng tập trung: Sản phẩm lý thuyết trong "Rừng tối" của Ethereum
Một sản phẩm lý thuyết ẩn nấp trong rừng đen tối. Nó không tìm kiếm con mồi trong bộ nhớ giao dịch của Ethereum, mà thiết lập bẫy thông qua việc mô phỏng cơ sở hạ tầng tập trung mà chúng ta phụ thuộc. Người dùng rơi vào bẫy đó không mắc sai lầm nào: họ chỉ truy cập vào sàn giao dịch phi tập trung mà họ thường xuyên lui tới, đặt mức trượt hợp lý và giao dịch token như thường lệ... họ không làm gì sai, nhưng vẫn gặp phải một loại tấn công sandwich mới, đó là một cái bẫy được thiết lập cẩn thận tại lối vào rừng đen tối của Ethereum - nhà cung cấp RPC.
Trước khi đi vào chi tiết, chúng ta hãy xem cách mà sàn giao dịch phi tập trung xử lý các giao dịch. Khi người dùng thực hiện giao dịch trao đổi, họ sẽ cung cấp cho hợp đồng thông minh một vài tham số: token cần trao đổi, số lượng trao đổi, và quan trọng nhất, số lượng token tối thiểu mà người dùng phải nhận khi giao dịch được thực hiện. Tham số cuối cùng này chỉ ra "sản lượng tối thiểu" mà giao dịch phải đạt được, nếu không, giao dịch sẽ bị hủy. Điều này thường được gọi là "slippage", vì nó thiết lập hiệu quả mức chênh lệch giá tối đa có thể xảy ra từ khi giao dịch được gửi đến bộ nhớ và cho đến khi giao dịch được đưa vào khối. Nếu mức slippage được đặt quá thấp, người dùng có thể chỉ nhận được một số lượng token ít hơn. Tình huống này cũng có thể dẫn đến một cuộc tấn công sandwich, trong đó kẻ tấn công có thể chèn giá thầu của người dùng giữa hai giao dịch độc hại. Những giao dịch này sẽ đẩy giá giao ngay lên, buộc người dùng phải giao dịch với mức giá không tốt. Sau đó, kẻ tấn công sẽ ngay lập tức bán token, thu về lợi nhuận nhỏ.
Chỉ cần tham số sản xuất tối thiểu này được thiết lập gần với giá trị công bằng, bạn sẽ không bị tấn công sandwich. Nhưng nếu nhà cung cấp RPC của bạn không cung cấp báo giá chính xác cho hợp đồng thông minh của sàn giao dịch phi tập trung thì sao? Như vậy, người dùng có thể bị đánh lừa và ký giao dịch đổi với tham số sản xuất tối thiểu thấp hơn, tệ hơn nữa, người dùng có thể gửi giao dịch trực tiếp cho nhà cung cấp RPC độc hại. Nhà cung cấp có thể không phát tán giao dịch này đến bộ nhớ công cộng ( trong đó hàng chục robot đang cạnh tranh thực hiện tấn công sandwich ), mà giữ lại một cách riêng tư và gửi gói giao dịch bị tấn công trực tiếp đến một nền tảng MEV nào đó để kiếm lợi.
Nguyên nhân cơ bản gây ra cuộc tấn công này là sự tin tưởng vào người khác để giúp bạn lấy trạng thái Blockchain. Để giải quyết vấn đề này, người dùng có kinh nghiệm thường chạy nút Ethereum của riêng mình, công việc này cần tiêu tốn nhiều thời gian và tài nguyên, ít nhất cần một thiết bị luôn trực tuyến, hàng trăm GB dung lượng lưu trữ, và khoảng một ngày để đồng bộ hóa từ đầu. Quá trình này rõ ràng đã được đơn giản hóa hơn so với trước đây. Một số nhóm đã không ngừng nỗ lực, giúp mọi người chạy nút thông qua phần cứng chi phí thấp (, ví dụ như máy tính mini Raspberry Pi ) với ổ cứng ngoài. Nhưng ngay cả khi yêu cầu giảm đáng kể, việc chạy nút vẫn rất khó khăn đối với hầu hết người dùng, đặc biệt là những người sử dụng thiết bị di động.
Cần lưu ý rằng, mặc dù các cuộc tấn công của nhà cung cấp RPC tập trung hoàn toàn có thể xảy ra, nhưng thường chỉ là các cuộc tấn công lừa đảo đơn giản, loại tấn công mà chúng tôi đề cập chưa xảy ra. Mặc dù hồ sơ trong quá khứ của các nhà cung cấp lớn không cho chúng tôi lý do để nghi ngờ họ, nhưng việc nghiên cứu thêm trước khi thêm các nhà cung cấp RPC không quen thuộc vào ví vẫn là điều đáng giá.
Giới thiệu Helios: Truy cập Ethereum hoàn toàn không cần tin tưởng
Ethereum ra mắt giao thức khách hàng ánh sáng, mở ra những khả năng thú vị cho sự tương tác nhanh chóng trên Blockchain và xác thực các điểm RPC với yêu cầu phần cứng tối thiểu. Trong một tháng sau The Merge, một loạt các khách hàng ánh sáng độc lập lần lượt xuất hiện, mỗi cái đều có hướng đi riêng, nhưng cùng một mục tiêu: truy cập hiệu quả không cần tin cậy, mà không cần sử dụng nút đầy đủ.
Helios là một khách hàng ánh sáng Ethereum, có thể hoàn thành đồng bộ trong khoảng hai giây, không cần lưu trữ, và cung cấp quyền truy cập Ethereum hoàn toàn không cần tin tưởng. Giống như tất cả các khách hàng Ethereum khác, Helios bao gồm một lớp thực thi và một lớp đồng thuận. Nhưng khác với hầu hết các khách hàng khác, Helios kết hợp chặt chẽ hai lớp này, người dùng chỉ cần cài đặt và chạy một phần mềm duy nhất.
Nó hoạt động như thế nào? Lớp đồng thuận Helios sử dụng một băm khối chuỗi tín hiệu đã biết và kết nối với một RPC không đáng tin cậy, để đồng bộ hóa một cách có thể xác minh đến khối hiện tại. Lớp thực thi Helios kết hợp các khối chuỗi tín hiệu đã được xác minh này với RPC lớp thực thi không đáng tin cậy, để xác minh nhiều thông tin liên quan đến trạng thái trên chuỗi, chẳng hạn như số dư tài khoản, lưu trữ hợp đồng, biên nhận giao dịch và kết quả gọi hợp đồng thông minh. Những thành phần này hoạt động cùng nhau để cung cấp cho người dùng RPC hoàn toàn không cần tin cậy và không cần chạy nút đầy đủ.
lớp đồng thuận
Lớp đồng thuận khách hàng ánh sáng phù hợp với tiêu chuẩn khách hàng ánh sáng của chuỗi tín hiệu, và đã sử dụng ủy ban đồng bộ của chuỗi tín hiệu ( được ra mắt trước khi phân nhánh cứng Altair của Merge ). Ủy ban đồng bộ là một tập hợp con gồm 512 xác nhận viên được chọn ngẫu nhiên, với chu kỳ phục vụ khoảng 27 giờ.
Khi các người xác thực vào ủy ban đồng bộ, họ sẽ ký tất cả các tiêu đề khối chuỗi tín hiệu mà họ thấy (block header). Nếu hơn hai phần ba thành viên của ủy ban ký một tiêu đề khối, thì khối đó rất có thể nằm trong chuỗi tín hiệu theo quy chuẩn. Nếu Helios hiểu về thành phần của ủy ban đồng bộ hiện tại, nó có thể theo dõi đầu chuỗi một cách chắc chắn bằng cách truy vấn chữ ký ủy ban đồng bộ gần đây từ RPC không đáng tin cậy.
Nhờ vào việc tổng hợp chữ ký BLS, chỉ cần một truy vấn là có thể hoàn thành việc xác minh tiêu đề khối mới. Chỉ cần chữ ký hợp lệ và hơn hai phần ba thành viên ủy ban hoàn thành chữ ký, có thể đảm bảo khối đã được bao gồm trong chuỗi (. Tất nhiên, nó cũng có thể được tái cấu trúc ra khỏi chuỗi, và việc theo dõi tính cuối cùng của khối có thể cung cấp sự đảm bảo mạnh mẽ hơn ).
Nhưng rõ ràng có một khâu thiếu trong chiến lược này: làm thế nào để tìm ra ủy ban đồng bộ hiện tại. Đầu tiên cần có một gốc tin cậy gọi là điểm kiểm tra chủ quan yếu (weak subjectivity checkpoint). Đừng để cái tên làm bạn sợ, nó chỉ đơn giản là một cái gì đó có thể đảm bảo rằng một hash khối cũ nào đó đã được đưa vào chuỗi tại một thời điểm nào đó trong quá khứ. Về thời gian chính xác tồn tại của điểm kiểm tra, có một số tính toán toán học thú vị: phân tích tình huống tồi tệ nhất cho thấy khoảng hai tuần, trong khi ước tính thực tế hơn cho thấy có thể là vài tháng.
Nếu điểm kiểm tra quá cũ, về lý thuyết có thể xảy ra cuộc tấn công lừa đảo các nút theo chuỗi sai. Lúc này, việc lấy điểm kiểm tra chủ quan yếu đã vượt quá khả năng của giao thức. Giải pháp của Helios là cung cấp một điểm kiểm tra ban đầu, được mã hóa cứng vào kho mã ( rất dễ bị ghi đè ), nó sẽ lưu trữ băm khối cuối cùng mới nhất trên máy tính địa phương, để sử dụng làm điểm kiểm tra khi các nút đồng bộ.
Thông qua thao tác băm, khối chuỗi tín hiệu có thể dễ dàng tạo ra băm khối tín hiệu duy nhất. Như vậy, có thể dễ dàng truy vấn khối tín hiệu hoàn chỉnh từ các nút, sau đó thông qua thao tác băm và so sánh với băm khối đã biết để chứng minh tính hợp lệ của nội dung khối. Helios tận dụng thuộc tính này để lấy và xác minh một số trường trong khối điểm kiểm tra chủ quan yếu, bao gồm hai trường quan trọng: ủy ban đồng bộ hiện tại và ủy ban đồng bộ tiếp theo. Quan trọng nhất, khách hàng ánh sáng có thể tận dụng cơ chế này để nhanh chóng xem xét lịch sử chuỗi khối.
Bây giờ với điểm kiểm tra tính chủ quan yếu, chúng ta có thể lấy và xác minh hội đồng đồng bộ hiện tại và tiếp theo. Nếu đầu chuỗi hiện tại và điểm kiểm tra đều trong cùng một chu kỳ hội đồng đồng bộ, chúng ta có thể ngay lập tức bắt đầu sử dụng tiêu đề hội đồng đồng bộ đã ký để xác minh khối mới. Nếu điểm kiểm tra của chúng ta đứng sau một số hội đồng đồng bộ, thì có thể:
1.Sử dụng ủy ban đồng bộ tiếp theo sau điểm kiểm tra để lấy và xác minh một khối của ủy ban đồng bộ sẽ được tạo ra trong tương lai.
2.Sử dụng khối mới này để nhận ủy ban đồng bộ tiếp theo.
Thông qua quy trình trên, chúng tôi có thể nhanh chóng xem xét lịch sử của Blockchain theo đơn vị 27 giờ, bắt đầu từ bất kỳ băm khối nào trong quá khứ cho đến băm khối hiện tại.
lớp thực thi
Mục tiêu của khách hàng ánh sáng của lớp thực thi là kết hợp tiêu đề khối tín hiệu đã được xác thực qua lớp đồng thuận với RPC lớp thực thi không đáng tin cậy, cung cấp dữ liệu lớp thực thi đã được xác thực. Sau đó, dữ liệu này có thể được truy cập thông qua máy chủ RPC được lưu trữ cục bộ bởi Helios.
Dưới đây là một ví dụ đơn giản về việc lấy số dư tài khoản, trước tiên hãy giới thiệu một cách đơn giản về cách Ethereum lưu trữ trạng thái. Mỗi tài khoản chứa một số trường, chẳng hạn như băm mã hợp đồng, số ngẫu nhiên, băm lưu trữ và số dư. Những tài khoản này được lưu trữ trong một cây Merkle-Patricia lớn đã được điều chỉnh, được gọi là cây trạng thái. Chỉ cần biết gốc của cây trạng thái, bạn có thể xác minh chứng minh Merkle, để chứng minh xem có bất kỳ tài khoản nào tồn tại trong cây hay không. Chứng minh này không thể bị làm giả.
Helios có một trạng thái gốc đã được xác thực từ lớp đồng thuận (state root). Bằng cách áp dụng trạng thái gốc này và yêu cầu chứng minh Merkle từ lớp thực thi không tin cậy, Helios có thể xác minh tất cả dữ liệu lưu trữ trên Ethereum một cách cục bộ.
Chúng tôi sử dụng các công nghệ khác nhau để xác thực dữ liệu khác nhau được sử dụng bởi lớp thực thi, nhờ đó, chúng tôi có thể xác thực tất cả dữ liệu từ RPC không đáng tin cậy. RPC không đáng tin cậy có thể từ chối cung cấp quyền truy cập dữ liệu, nhưng không thể cung cấp kết quả sai.
Sử dụng Helios trong thế giới thực
Khó khăn trong việc cân bằng giữa tính tiện lợi và phi tập trung là một điểm đau phổ biến, thông qua Helios nhẹ, người dùng có thể truy cập dữ liệu chuỗi an toàn từ bất kỳ thiết bị nào ( bao gồm điện thoại di động và plugin trình duyệt ). Điều này sẽ cho phép nhiều người hơn có thể truy cập dữ liệu Ethereum không cần tin tưởng, bất kể phần cứng nào được sử dụng. Người dùng có thể sử dụng Helios làm nhà cung cấp RPC của họ trong một ví nào đó, để truy cập các DApp khác nhau một cách không cần tin tưởng, toàn bộ quá trình không cần bất kỳ thay đổi nào khác.
Ngoài ra, sự hỗ trợ của Rust cho WebAssembly cho phép các nhà phát triển ứng dụng dễ dàng nhúng Helios vào các ứng dụng Javascript ( như ví và DApp ). Những tích hợp này sẽ nâng cao tính bảo mật của Ethereum, giảm bớt nhu cầu tin tưởng vào cơ sở hạ tầng tập trung.
Có nhiều cách để đóng góp cho Helios, ngoài việc xây dựng mã nguồn, bạn cũng có thể phát triển phần mềm tích hợp Helios để tận dụng những lợi thế của nó. Dưới đây là một số ý tưởng thú vị: