Khách hàng ánh sáng Ethereum Helios: Thực hiện truy cập Blockchain không cần tin cậy
Vào ngày 8 tháng 11, một khách hàng ánh sáng Ethereum mới có tên Helios đã chính thức ra mắt. Khách hàng này được phát triển dựa trên ngôn ngữ Rust, nhằm cung cấp quyền truy cập Ethereum hoàn toàn không cần tin tưởng.
Một trong những mục đích chính của việc sử dụng Blockchain là đạt được sự không cần tin cậy. Thông qua Blockchain, chúng ta có thể tự chủ 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, Blockchain như Ethereum thực sự đã thực hiện được cam kết này: tài sản của chúng ta thực sự thuộc về chính chúng ta.
Tuy nhiên, để theo đuổi tính tiện lợi, chúng tôi cũng đã phải thỏa hiệp một số điều. Một trong số đó là việc sử dụng RPC( gọi từ xa ) trung tâm hóa. Người dùng thường truy cập vào Ethereum thông qua các nhà cung cấp trung tâm hóa. 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 mọi người dễ dàng lấy dữ liệu trên chuỗi. Khi ví kiểm tra số dư token hoặc kiểm tra trạng thái giao dịch, hầu như luôn có sự tham gia của các nhà cung cấp trung tâm hóa này.
Vấn đề của hệ thống hiện tại là người dùng cần phải tin tưởng vào những nhà cung cấp này, không thể xác minh 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ó sử 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ộ an toàn và có thể xác minh. Kết hợp với RPC tập trung, Helios không cần chạy nút đầy đủ để xác minh tính xác thực của dữ liệu.
Khách hàng 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 an toàn dữ liệu trên chuỗi 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 phụ thuộc vào cơ sở hạ tầng tập trung có những rủi ro tiềm ẩn nào? Tiếp theo sẽ phân tích 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 để hoàn thiện thư viện mã.
Rủi ro tiềm ẩn của cơ sở hạ tầng tập trung
Một hình thức tấn công lý thuyết tiềm ẩn trong "rừng đen" của Ethereum. Nó không tìm kiếm mục tiêu trong bộ nhớ giao dịch, mà thiết lập bẫy bằng cách mô phỏng hạ tầng tập trung mà chúng ta phụ thuộc vào. Người dùng ngay cả khi không mắc lỗi cũng có thể rơi vào bẫy: họ chỉ đơn giản là giao dịch trên DEX như thường lệ, thiết lập độ trượt hợp lý... nhưng vẫn có thể gặp phải một loại tấn công sandwich mới, đây là một cái bẫy được thiết lập một cách tinh vi tại nhà cung cấp RPC.
Khi xử lý giao dịch trên sàn giao dịch phi tập trung, người dùng cần cung cấp một số tham số cho hợp đồng thông minh: mã thông báo muốn đổi, số tiền đổi, và điều quan trọng nhất, số lượng mã thông báo tối thiểu mà người dùng sẵn sàng chấp nhận. Tham số cuối cùng này chỉ ra "sản lượng tối thiểu" mà việc đổi 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à "trượt giá", nó thiết lập mức chênh lệch giá tối đa có thể xảy ra từ khi gửi giao dịch cho đến khi giao dịch được ghi vào chuỗi. Nếu trượt giá được đặt quá thấp, người dùng có thể chỉ nhận được một lượng mã thông báo ít hơn, và còn có thể bị tấn công sandwich.
Chỉ cần tham số sản lượng tối thiểu được thiết lập trong phạm vi hợp lý, sẽ không bị tấn công sandwich. Nhưng nếu nhà cung cấp RPC không cung cấp báo giá chính xác cho hợp đồng thông minh DEX thì sao? Điều này có thể dẫn đến việc người dùng bị hướng dẫn sai, ký giao dịch trao đổi với tham số sản lượng tối thiểu thấp hơn. Thậm chí tồi tệ hơn, 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 sóng giao dịch đến vùng nhớ công cộng, mà giữ lại một cách riêng tư và gửi trực tiếp gói giao dịch bị tấn công đến một tổ chức cụ thể để thu lợi.
Nguyên nhân cơ bản gây ra cuộc tấn công này là việc tin tưởng người khác để lấy trạng thái Blockchain. Để giải quyết vấn đề này, những người dùng có kinh nghiệm thường chạy nút Ethereum của riêng họ, nhưng điều này đòi hỏi 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. Mặc dù hiện nay ngưỡng chạy nút đã giảm, nhưng đối với hầu hết người dùng vẫn còn khó khăn, đặ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 từ 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 mô tả vẫn chưa xảy ra. Mặc dù hồ sơ trong quá khứ của các nhà cung cấp chính thống là đáng tin cậy, nhưng việc nghiên cứu thêm trước khi sử dụng các nhà cung cấp RPC không quen thuộc vẫn là một lựa chọn khôn ngoan.
Helios:实现无需信任的 Ethereum 访问
Ethereum đã ra mắt giao thức khách hàng ánh sáng, mở ra những khả năng mới cho việc tương tác nhanh chóng trên blockchain và xác thực các điểm cuối RPC với yêu cầu phần cứng tối thiểu. Trong một tháng sau The Merge, nhiều khách hàng ánh sáng độc lập đã lần lượt ra mắt, chúng áp dụng các phương pháp khác nhau, nhưng mục tiêu thì nhất quán: đạt được quyền truy cập hiệu quả mà không cần chạy 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 cậy. Giống như tất cả các khách hàng Ethereum khác, Helios bao gồm lớp thực thi và lớp đồng thuận. Nhưng khác với hầu hết các khách hàng, Helios kết hợp chặt chẽ hai lớp, người dùng chỉ cần cài đặt và chạy một phần mềm duy nhất.
Cách hoạt động của Helios như sau: Lớp đồng thuận sử dụng một hàm 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ộ theo cách có thể xác minh tới khối hiện tại. Lớp thực thi 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 về trạng thái trên chuỗi, 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, mà không cần chạy nút đầy đủ.
lớp đồng thuận
Khách hàng ánh sáng của lớp đồng thuận tuân theo tiêu chuẩn khách hàng ánh sáng của chuỗi tín hiệu, sử dụng ủy ban đồng bộ của chuỗi tín hiệu. Ủy ban đồng bộ là một tập hợp con được chọn ngẫu nhiên từ 512 người xác thực, thời gian phục vụ khoảng 27 giờ.
Các xác thực sẽ ký tất cả các tiêu đề khối của chuỗi beacon mà họ nhìn thấy sau khi vào ủy ban đồng bộ. Nếu hơn 2/3 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 beacon chuẩn. Nếu Helios hiểu thành phần hiện tại của ủy ban đồng bộ, nó có thể theo dõi đáng tin cậy đầu chuỗi bằng cách truy vấn chữ ký của ủy ban đồng bộ gần đây.
Nhờ vào việc tổng hợp chữ ký BLS, chỉ cần một lần truy vấn để hoàn thành việc xác thực tiêu đề khối mới. Chỉ cần chữ ký hợp lệ và hơn 2/3 thành viên của ủy ban hoàn thành chữ ký, có thể đảm bảo rằng khối đã được đưa vào chuỗi. Tất nhiên, 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.
Chiến lược này cũng cần giải quyết vấn đề làm thế nào để tìm ra ủy ban đồng bộ hiện tại. Đầu tiên, cần lấy một điểm kiểm tra được gọi là điểm kiểm tra chủ quan yếu. Nó đại diện cho một cái có thể đảm bảo một khối cũ đã được đưa vào chuỗi tại một thời điểm nào đó trong quá khứ. Về thời gian tồn tại của điểm kiểm tra, phân tích lý thuyết cho thấy trường hợp xấu nhất khoảng hai tuần, trong khi ước tính thực tế có thể kéo dài vài tháng.
Nếu điểm kiểm tra quá cũ, về lý thuyết có thể có một cuộc tấn công lừa đảo các nút theo dõi 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ã cứng vào kho mã ( rất dễ bị ghi đè ), nó sẽ lưu trữ hash của khối cuối cùng mới nhất tại địa phương, để sử dụng làm điểm kiểm tra khi các nút đồng bộ.
Thông qua các thao tác băm, các khối trên chuỗi tín hiệu có thể dễ dàng tạo ra một giá trị băm khối tín hiệu duy nhất. Điều này cho phép dễ dàng truy vấn toàn bộ khối tín hiệu, sau đó sử dụng so sánh băm để 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 các trường quan trọng trong các khối điểm kiểm tra chủ quan yếu, bao gồm ủy ban đồng bộ hiện tại và ủy ban đồng bộ tiếp theo. Điều quan trọng nhất là, khách hàng ánh sáng có thể sử dụng cơ chế này để nhanh chóng xem xét lịch sử chuỗi khối.
Có điểm kiểm tra chủ quan yếu, chúng ta có thể lấy và xác minh ủy ban đồ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 nằm trong cùng một chu kỳ ủy ban đồng bộ, chúng ta có thể ngay lập tức sử dụng header ủy ban đồng bộ đã ký để xác minh khối mới. Nếu điểm kiểm tra đứng sau một vài ủy ban đồng bộ, thì có thể:
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 trong tương lai.
Sử dụng khối mới này để lấy ủ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 ta có thể nhanh chóng xem lại lịch sử của Blockchain theo đơn vị 27 giờ, bắt đầu từ bất kỳ hash khối nào trong quá khứ cho đến hash 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 của 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ữ tại địa phương bằng Helios.
Dưới đây là một ví dụ đơn giản về cách lấy số dư tài khoản, trước tiên hãy giới thiệu ngắn gọn về cách Ethereum lưu trữ trạng thái. Mỗi tài khoản bao gồm một số trường, chẳng hạn như mã hợp đồng băm, 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, 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 Merkle để chứng minh xem có tài khoản nào trong cây hay không. Chứng minh này không thể bị giả mạo.
Helios nhận được gốc trạng thái đã được xác minh từ lớp đồng thuận. Bằng cách ứng dụng gốc trạng thái này và yêu cầu chứng minh Merkle từ RPC lớp thực thi không đáng tin cậy, Helios có thể xác minh tất cả dữ liệu được lưu trữ trên Ethereum tại địa phương.
Chúng tôi sử dụng các công nghệ khác nhau để xác minh các dữ liệu khác nhau được sử dụng bởi lớp thực thi, từ đó có thể xác minh 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.
Triển vọng ứng dụng của Helios
Khó khăn trong việc cân bằng giữa sự tiện lợi và tính 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à tiện ích mở rộng trình duyệt ). Điều này sẽ cho phép nhiều người truy cập dữ liệu Ethereum mà không cần phải 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 trong ví của họ để truy cập các DApp khác nhau mà không cần phải 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 thiểu sự phụ thuộc của chúng ta vào nhu cầu tin tưởng vào cơ sở hạ tầng tập trung.
Cộng đồng có thể đóng góp cho Helios bằng nhiều cách, ngoài việc hoàn thiện kho mã, còn có thể xây dựng phần mềm tích hợp Helios để tận dụng lợi thế của nó. Dưới đây là một số hướng phát triển tiềm năng:
Hỗ trợ lấy dữ liệu khách hàng ánh sáng trực tiếp từ mạng P2P, không phụ thuộc vào RPC
Thực hiện các phương pháp RPC bị thiếu
Phát triển 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 đầy đủ 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 dữ liệu Ethereum on-chain không cần tin cậy.
Khách hàng ánh sáng Ethereum Helios: Thực hiện truy cập Blockchain không cần tin cậy
Vào ngày 8 tháng 11, một khách hàng ánh sáng Ethereum mới có tên Helios đã chính thức ra mắt. Khách hàng này được phát triển dựa trên ngôn ngữ Rust, nhằm cung cấp quyền truy cập Ethereum hoàn toàn không cần tin tưởng.
Một trong những mục đích chính của việc sử dụng Blockchain là đạt được sự không cần tin cậy. Thông qua Blockchain, chúng ta có thể tự chủ 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, Blockchain như Ethereum thực sự đã thực hiện được cam kết này: tài sản của chúng ta thực sự thuộc về chính chúng ta.
Tuy nhiên, để theo đuổi tính tiện lợi, chúng tôi cũng đã phải thỏa hiệp một số điều. Một trong số đó là việc sử dụng RPC( gọi từ xa ) trung tâm hóa. Người dùng thường truy cập vào Ethereum thông qua các nhà cung cấp trung tâm hóa. 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 mọi người dễ dàng lấy dữ liệu trên chuỗi. Khi ví kiểm tra số dư token hoặc kiểm tra trạng thái giao dịch, hầu như luôn có sự tham gia của các nhà cung cấp trung tâm hóa này.
Vấn đề của hệ thống hiện tại là người dùng cần phải tin tưởng vào những nhà cung cấp này, không thể xác minh 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ó sử 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ộ an toàn và có thể xác minh. Kết hợp với RPC tập trung, Helios không cần chạy nút đầy đủ để xác minh tính xác thực của dữ liệu.
Khách hàng 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 an toàn dữ liệu trên chuỗi 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 phụ thuộc vào cơ sở hạ tầng tập trung có những rủi ro tiềm ẩn nào? Tiếp theo sẽ phân tích 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 để hoàn thiện thư viện mã.
Rủi ro tiềm ẩn của cơ sở hạ tầng tập trung
Một hình thức tấn công lý thuyết tiềm ẩn trong "rừng đen" của Ethereum. Nó không tìm kiếm mục tiêu trong bộ nhớ giao dịch, mà thiết lập bẫy bằng cách mô phỏng hạ tầng tập trung mà chúng ta phụ thuộc vào. Người dùng ngay cả khi không mắc lỗi cũng có thể rơi vào bẫy: họ chỉ đơn giản là giao dịch trên DEX như thường lệ, thiết lập độ trượt hợp lý... nhưng vẫn có thể gặp phải một loại tấn công sandwich mới, đây là một cái bẫy được thiết lập một cách tinh vi tại nhà cung cấp RPC.
Khi xử lý giao dịch trên sàn giao dịch phi tập trung, người dùng cần cung cấp một số tham số cho hợp đồng thông minh: mã thông báo muốn đổi, số tiền đổi, và điều quan trọng nhất, số lượng mã thông báo tối thiểu mà người dùng sẵn sàng chấp nhận. Tham số cuối cùng này chỉ ra "sản lượng tối thiểu" mà việc đổi 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à "trượt giá", nó thiết lập mức chênh lệch giá tối đa có thể xảy ra từ khi gửi giao dịch cho đến khi giao dịch được ghi vào chuỗi. Nếu trượt giá được đặt quá thấp, người dùng có thể chỉ nhận được một lượng mã thông báo ít hơn, và còn có thể bị tấn công sandwich.
Chỉ cần tham số sản lượng tối thiểu được thiết lập trong phạm vi hợp lý, sẽ không bị tấn công sandwich. Nhưng nếu nhà cung cấp RPC không cung cấp báo giá chính xác cho hợp đồng thông minh DEX thì sao? Điều này có thể dẫn đến việc người dùng bị hướng dẫn sai, ký giao dịch trao đổi với tham số sản lượng tối thiểu thấp hơn. Thậm chí tồi tệ hơn, 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 sóng giao dịch đến vùng nhớ công cộng, mà giữ lại một cách riêng tư và gửi trực tiếp gói giao dịch bị tấn công đến một tổ chức cụ thể để thu lợi.
Nguyên nhân cơ bản gây ra cuộc tấn công này là việc tin tưởng người khác để lấy trạng thái Blockchain. Để giải quyết vấn đề này, những người dùng có kinh nghiệm thường chạy nút Ethereum của riêng họ, nhưng điều này đòi hỏi 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. Mặc dù hiện nay ngưỡng chạy nút đã giảm, nhưng đối với hầu hết người dùng vẫn còn khó khăn, đặ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 từ 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 mô tả vẫn chưa xảy ra. Mặc dù hồ sơ trong quá khứ của các nhà cung cấp chính thống là đáng tin cậy, nhưng việc nghiên cứu thêm trước khi sử dụng các nhà cung cấp RPC không quen thuộc vẫn là một lựa chọn khôn ngoan.
Helios:实现无需信任的 Ethereum 访问
Ethereum đã ra mắt giao thức khách hàng ánh sáng, mở ra những khả năng mới cho việc tương tác nhanh chóng trên blockchain và xác thực các điểm cuối RPC với yêu cầu phần cứng tối thiểu. Trong một tháng sau The Merge, nhiều khách hàng ánh sáng độc lập đã lần lượt ra mắt, chúng áp dụng các phương pháp khác nhau, nhưng mục tiêu thì nhất quán: đạt được quyền truy cập hiệu quả mà không cần chạy 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 cậy. Giống như tất cả các khách hàng Ethereum khác, Helios bao gồm lớp thực thi và lớp đồng thuận. Nhưng khác với hầu hết các khách hàng, Helios kết hợp chặt chẽ hai lớp, người dùng chỉ cần cài đặt và chạy một phần mềm duy nhất.
Cách hoạt động của Helios như sau: Lớp đồng thuận sử dụng một hàm 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ộ theo cách có thể xác minh tới khối hiện tại. Lớp thực thi 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 về trạng thái trên chuỗi, 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, mà không cần chạy nút đầy đủ.
lớp đồng thuận
Khách hàng ánh sáng của lớp đồng thuận tuân theo tiêu chuẩn khách hàng ánh sáng của chuỗi tín hiệu, sử dụng ủy ban đồng bộ của chuỗi tín hiệu. Ủy ban đồng bộ là một tập hợp con được chọn ngẫu nhiên từ 512 người xác thực, thời gian phục vụ khoảng 27 giờ.
Các xác thực sẽ ký tất cả các tiêu đề khối của chuỗi beacon mà họ nhìn thấy sau khi vào ủy ban đồng bộ. Nếu hơn 2/3 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 beacon chuẩn. Nếu Helios hiểu thành phần hiện tại của ủy ban đồng bộ, nó có thể theo dõi đáng tin cậy đầu chuỗi bằng cách truy vấn chữ ký của ủy ban đồng bộ gần đây.
Nhờ vào việc tổng hợp chữ ký BLS, chỉ cần một lần truy vấn để hoàn thành việc xác thực tiêu đề khối mới. Chỉ cần chữ ký hợp lệ và hơn 2/3 thành viên của ủy ban hoàn thành chữ ký, có thể đảm bảo rằng khối đã được đưa vào chuỗi. Tất nhiên, 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.
Chiến lược này cũng cần giải quyết vấn đề làm thế nào để tìm ra ủy ban đồng bộ hiện tại. Đầu tiên, cần lấy một điểm kiểm tra được gọi là điểm kiểm tra chủ quan yếu. Nó đại diện cho một cái có thể đảm bảo một khối cũ đã được đưa vào chuỗi tại một thời điểm nào đó trong quá khứ. Về thời gian tồn tại của điểm kiểm tra, phân tích lý thuyết cho thấy trường hợp xấu nhất khoảng hai tuần, trong khi ước tính thực tế có thể kéo dài vài tháng.
Nếu điểm kiểm tra quá cũ, về lý thuyết có thể có một cuộc tấn công lừa đảo các nút theo dõi 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ã cứng vào kho mã ( rất dễ bị ghi đè ), nó sẽ lưu trữ hash của khối cuối cùng mới nhất tại địa phương, để sử dụng làm điểm kiểm tra khi các nút đồng bộ.
Thông qua các thao tác băm, các khối trên chuỗi tín hiệu có thể dễ dàng tạo ra một giá trị băm khối tín hiệu duy nhất. Điều này cho phép dễ dàng truy vấn toàn bộ khối tín hiệu, sau đó sử dụng so sánh băm để 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 các trường quan trọng trong các khối điểm kiểm tra chủ quan yếu, bao gồm ủy ban đồng bộ hiện tại và ủy ban đồng bộ tiếp theo. Điều quan trọng nhất là, khách hàng ánh sáng có thể sử dụng cơ chế này để nhanh chóng xem xét lịch sử chuỗi khối.
Có điểm kiểm tra chủ quan yếu, chúng ta có thể lấy và xác minh ủy ban đồ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 nằm trong cùng một chu kỳ ủy ban đồng bộ, chúng ta có thể ngay lập tức sử dụng header ủy ban đồng bộ đã ký để xác minh khối mới. Nếu điểm kiểm tra đứng sau một vài ủy ban đồng bộ, thì có thể:
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 trong tương lai.
Sử dụng khối mới này để lấy ủ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 ta có thể nhanh chóng xem lại lịch sử của Blockchain theo đơn vị 27 giờ, bắt đầu từ bất kỳ hash khối nào trong quá khứ cho đến hash 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 của 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ữ tại địa phương bằng Helios.
Dưới đây là một ví dụ đơn giản về cách lấy số dư tài khoản, trước tiên hãy giới thiệu ngắn gọn về cách Ethereum lưu trữ trạng thái. Mỗi tài khoản bao gồm một số trường, chẳng hạn như mã hợp đồng băm, 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, 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 Merkle để chứng minh xem có tài khoản nào trong cây hay không. Chứng minh này không thể bị giả mạo.
Helios nhận được gốc trạng thái đã được xác minh từ lớp đồng thuận. Bằng cách ứng dụng gốc trạng thái này và yêu cầu chứng minh Merkle từ RPC lớp thực thi không đáng tin cậy, Helios có thể xác minh tất cả dữ liệu được lưu trữ trên Ethereum tại địa phương.
Chúng tôi sử dụng các công nghệ khác nhau để xác minh các dữ liệu khác nhau được sử dụng bởi lớp thực thi, từ đó có thể xác minh 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.
Triển vọng ứng dụng của Helios
Khó khăn trong việc cân bằng giữa sự tiện lợi và tính 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à tiện ích mở rộng trình duyệt ). Điều này sẽ cho phép nhiều người truy cập dữ liệu Ethereum mà không cần phải 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 trong ví của họ để truy cập các DApp khác nhau mà không cần phải 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 thiểu sự phụ thuộc của chúng ta vào nhu cầu tin tưởng vào cơ sở hạ tầng tập trung.
Cộng đồng có thể đóng góp cho Helios bằng nhiều cách, ngoài việc hoàn thiện kho mã, còn có thể xây dựng phần mềm tích hợp Helios để tận dụng lợi thế của nó. Dưới đây là một số hướng phát triển tiềm năng: