客 hàng ánh sáng Ethereum Helios：truy cập dữ liệu on-chain không cần tin tưởng

Vào ngày 8 tháng 11, một tổ chức đầu tư mạo hiểm nổi tiếng đã ra mắt khách hàng ánh sáng Ethereum Helios. Khách hàng này được viết bằng ngôn ngữ Rust, 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ợi thế lớn của công nghệ blockchain là không cần phải tin tưởng vào bên thứ ba. Thông qua blockchain, người dùng có thể tự do kiểm soát tài sản và dữ liệu của mình. Các blockchain như Ethereum thực sự đã thực hiện cam kết này trong hầu hết các trường hợp: 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 sự tiện lợi, chúng tôi cũng đã thực hiện một số thỏa hiệp. Một trong số đó là việc sử dụng máy chủ RPC (gọi từ xa) tập trung. 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í kiểm tra số dư token hoặc kiểm tra xem giao dịch đang chờ có được đóng gói hay không, hầu như đều sử dụng dịch vụ của những 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 mà không thể xác minh độ chính xác của kết quả truy vấn.

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ộ an toàn và có thể xác minh. 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 đủ.

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. Ứng dụng khách hàng mới này (mở cho công chúng tiếp tục phát triển) có thể hoàn thành đồng bộ trong khoảng hai giây, và không cần không gian lưu trữ, người dùng có thể truy cập dữ liệu trên chuỗi một cách an toàn thông qua bất kỳ thiết bị nào (bao gồm cả điện thoại di động và tiện ích trình duyệt). Vậy, những rủi ro tiềm ẩn nào liên quan đến việc phụ thuộc vào cơ sở hạ tầng tập trung? Bài viết này sẽ khám phá chi tiết những rủi ro này, giới thiệu thiết kế của Helios và cung cấp một số gợi ý, giúp các nhà phát triển đóng góp cho kho mã.

Những rủi ro tiềm ẩn của cơ sở hạ tầng tập trung: Mối đe dọa lý thuyết trong hệ sinh thái Ethereum

Trong hệ sinh thái Ethereum tiềm ẩn một mối đe dọa lý thuyết. Nó không tìm kiếm mục tiêu trong bộ nhớ giao dịch (Mempool), mà là thông qua việc mô phỏng cơ sở hạ tầng tập trung mà chúng ta phụ thuộc để thiết lập bẫy. Người dùng rơi vào bẫy này không làm gì sai: họ chỉ đơn giản là truy cập vào DEX quen thuộc như thường lệ, thiết lập độ trượt hợp lý và thực hiện giao dịch token... Hành động của họ không có vấn đề gì, nhưng có thể gặp phải một loại tấn công sandwich mới, đó là một cái bẫy được bố trí tinh vi tại cổng vào của hệ sinh thái Ethereum - nhà cung cấp RPC.

Trước khi giải thích chi tiết, chúng ta hãy xem xét cách DEX xử lý giao dịch. Khi người dùng thực hiện việc trao đổi token, 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 sẵn sàng chấp nhận. Tham số cuối cùng xác định "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à "trượt giá", vì nó hiệu quả giới hạn biến động giá tối đa có thể xảy ra từ khi giao dịch được gửi đến mempool cho đến khi được đóng gói vào khố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 token ít hơn. Tình huống này cũng có thể dẫn đến cuộc tấn công sandwich, khi kẻ tấn công có thể kẹp giao dịch 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á spot lên cao, buộc người dùng phải giao dịch với giá bất lợi. Ngay sau đó, kẻ tấn công sẽ bán token ngay lập tức để thu lợi nhỏ.

Chỉ cần tham số sản lượng tối thiểu được thiết lập trong khoảng hợp lý, người dùng sẽ không bị ảnh hưởng bởi cuộc 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? Trong trường hợp này, người dùng có thể bị dẫn dắt để ký giao dịch trao đổi với tham số sản lượng 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 đến nhà cung cấp RPC độc hại. Nhà cung cấp có thể chọn không phát tán giao dịch này đến bộ nhớ công cộng (nơi có nhiều bot đang cạnh tranh thực hiện cuộc tấn công sandwich), mà giữ bí mật và gửi gói giao dịch bị tấn công trực tiếp đến nền tảng cụ thể để thu lợi từ đó.

Nguyên nhân cơ bản của cuộc tấn công này là do tin tưởng người khác để giúp 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ọn chạy nút Ethereum của riêng mình. Điều này cần đầu tư nhiều thời gian và tài nguyên, ít nhất là một thiết bị luôn trực tuyến, hàng trăm GB không gian lưu trữ, và khoảng một ngày để đồng bộ hóa từ đầu. Mặc dù quá trình này đã được đơn giản hóa nhiều so với trước đây, một số đội ngũ vẫn đang nỗ lực giúp người dùng chạy nút bằng phần cứng chi phí thấp (như Raspberry Pi có ổ cứng ngoài). Nhưng ngay cả khi yêu cầu giảm đáng kể, đối với hầu hết người dùng, đặc biệt là người dùng thiết bị di động, việc chạy nút vẫn là một nhiệm vụ khó khăn.

Cần lưu ý rằng, mặc dù các nhà cung cấp RPC tập trung có thể bị tấn công, nhưng hiện tại vẫn chỉ là rủi ro lý thuyết và chưa xảy ra trong thực tế. Mặc dù hồ sơ trong quá khứ của các nhà cung cấp chính thống đáng tin cậy, nhưng trước khi thêm các nhà cung cấp RPC không quen thuộc vào ví, vẫn nên thực hiện nghiên cứu đầy đủ.

Giới thiệu về Helios: Truy cập Ethereum hoàn toàn không cần tin cậy

Giao thức khách hàng ánh sáng do Ethereum phát triển đã mở ra những khả năng thú vị cho việc tương tác nhanh chóng với 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. Chỉ trong một tháng sau khi hợp nhất, nhiều khách hàng ánh sáng độc lập đã xuất hiện liên tiếp, họ áp dụng các phương pháp khác nhau nhưng đều hướng tới 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 không gian 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 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.

Cách hoạt động của nó như sau: Lớp đồng thuận Helios 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ộ hóa đến khối hiện tại một cách có thể xác minh. Lớp thực hiện Helios kết hợp các khối chuỗi tín hiệu đã được xác minh với RPC lớp thực hiện không đáng tin cậy để xác minh thông tin khác nhau về 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 lai giao dịch và kết quả gọi hợp đồng thông minh. Những thành phần này làm việc 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 và sử dụng ủy ban đồng bộ của chuỗi tín hiệu (được giới thiệu trong phân nhánh cứng Altair trước khi hợp nhất). Ủy ban đồng bộ là một tập hợp con gồm 512 người xác thực được chọn ngẫu nhiên, có chu kỳ phục vụ khoảng 27 giờ.

Các người xác thực sẽ ký tất cả các tiêu đề khối chuỗi tín hiệu mà họ nhìn thấy sau khi gia nhập ủy ban đồng bộ. Nếu hơn hai phần ba thành viên ủy ban ký một tiêu đề khối, thì khối đó rất có khả năng nằm trong chuỗi tín hiệu tiêu chuẩn. Nếu Helios hiểu được cấu trúc hiện tại của ủy ban đồng bộ, nó có thể theo dõi đầu chuỗi với độ tin cậy cao bằng cách truy vấn chữ ký ủy ban đồng bộ gần đây từ RPC không tin cậy.

Nhờ vào việc tổng hợp chữ ký BLS, chỉ cần một lần truy vấn là có thể 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 hai phần ba thành viên ủy ban hoàn thành chữ ký, thì có thể đảm bảo rằng khối đã được bao gồm trong chuỗi (tất nhiên, nó cũng có thể bị tái cấu trúc ra khỏi chuỗi, trong khi 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 trong chiến lược này thiếu một khía cạnh: làm thế nào để tìm ra ủy ban đồng bộ hiện tại. Trước tiên, cần phải có một gốc tin cậy gọi là điểm kiểm tra chủ quan yếu. Đây chỉ là một hàm băm khối cũ được đảm bảo đã được đưa vào chuỗi vào một thời điểm nào đó trong quá khứ. Về thời gian tồn tại chính xác của điểm kiểm tra, có một số tính toán toán học thú vị đứng sau: phân tích trường hợp tệ nhất cho thấy khoảng hai tuần, trong khi ước tính thực tế hơn chỉ ra rằng có thể kéo dài hàng tháng.

Nếu điểm kiểm tra quá cũ, về lý thuyết có thể có cuộc tấn công lừa đảo mà khiến các nút theo đuổ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ã hóa cứng vào kho mã (dễ dàng bị ghi đè), nó sẽ lưu trữ băm khối cuối cùng mới nhất tại địa phương để được 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 mã băm khối tín hiệu duy nhất. Bằng cách này, có thể dễ dàng truy vấn khối tín hiệu đầy đủ tới các nút, sau đó bằng cách thực hiện thao tác băm và so sánh với mã 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 đặc điểm 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 để kiểm tra nhanh chóng 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 đều thuộc cùng một chu kỳ ủy ban đồng bộ, chúng ta có thể ngay lập tức bắt đầu sử dụng đầu ủy ban đồng bộ đã ký để xác minh các khối mới. Nếu điểm kiểm tra của chúng ta lạc hậu so với một vài ủy ban đồng bộ, thì chúng ta 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 sẽ được tạo ra bởi một ủy ban đồng bộ trong tương lai.

2. Sử dụng khối mới này để lấy ủy ban đồng bộ tiếp theo.

3. Nếu điểm kiểm tra vẫn ở phía sau, quay lại bước 1.

Thông qua quá trình này, chúng tôi có thể kiểm tra nhanh chóng 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 khi đồng bộ với 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 ở tầng thực thi là kết hợp tiêu đề khối beacon đã được xác minh qua tầng đồng thuận với RPC tầng thực thi không tin cậy, cung cấp dữ liệu tầng thực thi đã được xác minh. Những dữ liệu này sau đó có thể được truy cập thông qua Helios trên máy chủ RPC được lưu trữ cục bộ.

Hãy lấy việc lấy số dư tài khoản làm ví dụ, để giới thiệu đơn giản về cách Ethereum lưu trữ trạng thái. Mỗi tài khoản bao gồm một vài 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 sửa đổi, đượ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, có thể xác minh chứng thực Merkle, để chứng minh xem có tồn tại bất kỳ tài khoản nào trong cây hay không. Chứng thực này không thể bị làm giả.

Helios đã nhận được gốc trạng thái đã được xác minh từ lớp đồng thuận. Bằng cách áp dụng gốc trạng thái này và yêu cầu chứng minh Merkle vào RPC lớp thực thi không tin cậy, Helios có thể xác minh cục bộ tất cả dữ liệu được lưu trữ trên Ethereum.

Chúng tôi sử dụng các công nghệ khác nhau để xác thực các dữ liệu khác nhau được sử dụng bởi lớp thực thi. Bằng cách này, chúng tôi 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.

Sử dụng Helios trong môi trường phức tạp

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 vấn đề phổ biến. Thông qua Helios nhẹ, 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). Điều này sẽ cho phép nhiều người hơn truy cập dữ liệu Ethereum mà không cần phải tin tưởng, không bị giới hạn bởi phần cứng. Người dùng có thể thiết lập Helios làm nhà cung cấp RPC trong một số ví, cho phép truy cập các DApp mà 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, 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 sự phụ thuộc của chúng ta vào cơ sở hạ tầng tập trung.

Phản ứng của cộng đồng đối với điều này thật đáng mong đợi. Có nhiều cách để đóng góp cho Helios, ngoài việc xây dựng thêm vào kho mã, còn có thể phát triển phần mềm tích hợp Helios để tận dụng lợi ích 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 (không phải RPC)
• Thực hiện một số phương pháp RPC chưa được hỗ trợ
• Phát triển phiên bản Helios có thể biên dịch thành 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ó.