Xây dựng Helios: Truy cập hoàn toàn không cần tin cậy vào Ethereum

Một trong những lý do chính khiến chúng tôi sử dụng blockchain là sự không tin cậy. Tài sản này hứa hẹn sẽ cho phép chúng ta có quyền tự chủ truy cập vào tài sản và dữ liệu của mình. Phần lớn, các chuỗi khối như Ethereum đã thực hiện được lời hứa này - tài sản của chúng tôi thực sự là của chúng tôi. 

Tuy nhiên, chúng tôi đã có những nhượng bộ vì sự thuận tiện. Một lĩnh vực như vậy là việc chúng tôi sử dụng máy chủ RPC (cuộc gọi thủ tục 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ư Alchemy. Các công ty này chạy các nút hiệu suất cao trên máy chủ đám mây để những công ty khác có thể dễ dàng truy cập dữ liệu chuỗi. Khi một ví truy vấn số dư token của nó hoặc kiểm tra xem một giao dịch đang chờ xử lý có được đưa vào một khối hay không, nó hầu như luôn thực hiện việc đó thông qua một trong những nhà cung cấp tập trung này. 

Vấn đề với hệ thống hiện tại là người dùng cần phải tin tưởng vào nhà cung cấp và không có cách nào để xác minh tính chính xác của các truy vấn của họ.

đăng ký hạng mục thi Helios, một ứng dụng khách nhẹ Ethereum dựa trên Rust mà chúng tôi đã phát triển để cung cấp quyền truy cập hoàn toàn không cần sự tin cậy vào Ethereum. Helios — sử dụng giao thức client nhẹ của Ethereum, được thực hiện nhờ chuyển đổi gần đây đến bằng chứng cổ phần — chuyển đổi dữ liệu từ nhà cung cấp RPC tập trung không đáng tin cậy thành RPC cục bộ, an toàn có thể xác minh. Helios hoạt động cùng với các RPC tập trung để có thể xác minh tính xác thực của chúng mà không cần chạy nút đầy đủ. 

Sự cân bằng giữa tính di động và tính phân cấp là một điểm khó khăn chung, nhưng khách hàng của chúng tôi – mà chúng tôi đã cung cấp cho công chúng để xây dựng và hơn thế nữa – đồng bộ hóa trong khoảng hai giây, không cần lưu trữ và cho phép người dùng truy cập dữ liệu chuỗi an toàn từ bất kỳ thiết bị nào (bao gồm cả điện thoại di động và tiện ích mở rộng trình duyệt). Nhưng cái gì là những cạm bẫy tiềm tàng của việc dựa vào cơ sở hạ tầng tập trung? Chúng tôi đề cập đến cách chúng có thể diễn ra trong bài đăng này, xem xét các quyết định thiết kế của chúng tôi và cũng phác thảo một số ý tưởng để những người khác đóng góp cho cơ sở mã.

Cạm bẫy của cơ sở hạ tầng tập trung: những sinh vật lý thuyết trong “khu rừng tối” của Ethereum

Một sinh vật (lý thuyết) ẩn nấp trong rừng tối. Kẻ này không săn lùng con mồi trong bộ nhớ Ethereum mà thay vào đó đặt bẫy bằng cách bắt chước cơ sở hạ tầng tập trung mà chúng ta đã dựa vào. Những người dùng mắc vào cái bẫy này không mắc bất kỳ sai lầm nào: Họ truy cập vào sàn giao dịch phi tập trung yêu thích của họ, đặt ra mức độ trượt giá hợp lý và mua và bán token như bình thường… Họ làm mọi thứ đúng, nhưng vẫn trở thành nạn nhân của một loại giao dịch mới. cuộc tấn công bánh sandwich, một cái bẫy được đặt tỉ mỉ ngay lối vào khu rừng tối tăm của Ethereum: các nhà cung cấp RPC.

Trước khi giải thích chi tiết, chúng ta hãy xem cách giao dịch hoạt động trên các sàn giao dịch phi tập trung. Khi người dùng gửi giao dịch hoán đổi, họ sẽ cung cấp một số tham số cho hợp đồng thông minh — mã thông báo nào sẽ trao đổi, số tiền hoán đổi và quan trọng nhất là số lượng mã thông báo tối thiểu mà người dùng phải nhận để giao dịch được thực hiện. Tham số cuối cùng này chỉ định rằng việc hoán đổi phải đáp ứng “đầu ra tối thiểu” hoặc hoàn nguyên. Điều này thường được gọi là “dung sai trượt giá”, vì nó đặt ra mức thay đổi giá tối đa một cách hiệu quả có thể xảy ra giữa thời điểm giao dịch được gửi đến mempool và khi giao dịch được đưa vào một khối. Nếu tham số này được đặt quá thấp, người dùng sẽ chấp nhận khả năng nhận được ít mã thông báo 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 kẹp giá thầu một cách hiệu quả vào giữa hai giao dịch hoán đổi độc hại. Việc hoán đổi làm tăng giá giao ngay và buộc giao dịch của người dùng phải thực hiện ở mức giá kém thuận lợi hơn. Kẻ tấn công sau đó bán ngay lập tức để thu về một khoản lợi nhuận nhỏ.

Miễn là thông số đầu ra tối thiểu này được đặt gần giá trị hợp lý, bạn sẽ an toàn trước các cuộc tấn công xen kẽ. Nhưng điều gì sẽ xảy ra nếu nhà cung cấp RPC của bạn không cung cấp báo giá chính xác từ hợp đồng thông minh trao đổi phi tập trung? Sau đó, người dùng có thể bị lừa ký một giao dịch hoán đổi với tham số đầu ra tối thiểu thấp hơn và tệ hơn là gửi giao dịch thẳng đến nhà cung cấp RPC độc hại. Thay vì phát sóng giao dịch này tới mempool công cộng, nơi hàng chục bot cạnh tranh để thực hiện cuộc tấn công sandwich, nhà cung cấp có thể giữ lại nó và gửi gói giao dịch tấn công trực tiếp đến Flashbots, đảm bảo lợi nhuận cho chính họ.

Nguyên nhân cốt lõi của cuộc tấn công này là tin tưởng người khác lấy trạng thái của blockchain. Theo truyền thống, người dùng có kinh nghiệm thường giải quyết vấn đề này bằng cách chạy các nút Ethereum của riêng họ - một nỗ lực tốn nhiều thời gian và tài nguyên, ít nhất, đòi hỏi một máy trực tuyến liên tục, hàng trăm gigabyte dung lượng lưu trữ và khoảng một ngày để đồng bộ hóa từ đầu. Quá trình này chắc chắn dễ dàng hơn trước đây; các nhóm như Ethereum trên ARM đã làm việc không mệt mỏi để có thể chạy các nút trên phần cứng giá rẻ (chẳng hạn như Raspberry Pi có gắn ổ cứng ngoài). Nhưng ngay cả với những yêu cầu tương đối tối thiểu này, việc chạy một nút vẫn khó khăn đối với hầu hết người dùng, đặc biệt đối với những người sử dụng thiết bị di động.

Điều quan trọng cần lưu ý là các cuộc tấn công của nhà cung cấp RPC tập trung, mặc dù hoàn toàn hợp lý, nhưng nhìn chung là các cuộc tấn công lừa đảo đơn giản - và điều chúng tôi mô tả vẫn chưa xảy ra. Mặc dù hồ sơ theo dõi của các nhà cung cấp lớn hơn như Alchemy cho chúng ta rất ít lý do để nghi ngờ họ, nhưng vẫn đáng để thực hiện một số nghiên cứu sâu hơn trước khi thêm các nhà cung cấp RPC không quen thuộc vào ví của bạn.

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

Bằng cách giới thiệu giao thức máy khách nhẹ (có thể thực hiện được nhờ chuyển sang Proof of Stake gần đây), Ethereum đã mở ra những khả năng mới thú vị để tương tác nhanh chóng với chuỗi khối và xác minh các điểm cuối RPC với yêu cầu phần cứng tối thiểu. Trong tháng kể từ Hợp nhất, chúng tôi đã thấy một nhóm khách hàng ánh sáng mới xuất hiện độc lập với nhau (ngôi sao dẫn đường, Nimbusvà dựa trên JavaScript Kevlar) đã thực hiện các cách tiếp cận khác nhau để phục vụ cùng một mục tiêu: truy cập hiệu quả và không cần tin cậy mà không cần sử dụng nút đầy đủ.

Giải pháp của chúng tôi, Helios, là một ứng dụng khách Ethereum nhẹ, đồng bộ hóa trong khoảng hai giây, không yêu cầu bộ nhớ và cung cấp quyền truy cập hoàn toàn không cần tin cậy vào Ethereum. Giống như tất cả các máy khách Ethereum, Helios bao gồm lớp thực thi và lớp đồng thuận. Không giống như hầu hết các ứng dụng khách khác, Helios kết hợp chặt chẽ cả 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. (Eragon cũng đang đi theo hướng này bằng cách thêm ứng dụng khách nhẹ lớp đồng thuận được tích hợp trực tiếp vào nút lưu trữ của họ). 

Vì vậy, làm thế nào nó hoạt động? Lớp đồng thuận Helios sử dụng hàm băm chuỗi đèn hiệu đã biết trước đó và kết nối với RPC không đáng tin cậy để đồng bộ hóa có thể xác minh được với khối hiện tại. Lớp thực thi Helios sử dụng các khối chuỗi báo hiệu đã được xác thực này song song với RPC của lớp thực thi không đáng tin cậy để chứng minh thông tin tùy ý về trạng thái chuỗi như số dư tài khoản, lưu trữ hợp đồng, biên lai giao dịch và kết quả cuộc gọi hợp đồng thông minh. Các thành phần này phối hợp với nhau để cung cấp cho người dùng một RPC hoàn toàn không cần tin cậy mà không cần phải chạy một nút đầy đủ.

…Ở lớp đồng thuận

Ứng dụng khách ánh sáng lớp đồng thuận phù hợp với ứng dụng khách ánh sáng chuỗi đèn hiệu đặc điểm kỹ thuậtvà sử dụng các ủy ban đồng bộ hóa của beacon chain (được giới thiệu trước đợt hard fork Hợp nhất trong Altair). Ủy ban đồng bộ hóa là một tập hợp con được chọn ngẫu nhiên gồm 512 trình xác nhận hoạt động trong khoảng thời gian ~27 giờ. 

Khi người xác thực tham gia ủy ban đồng bộ hóa, họ sẽ ký vào mọi tiêu đề khối chuỗi beacon mà họ nhìn thấy. Nếu hơn hai phần ba ủy ban ký vào một tiêu đề khối nhất định thì rất có khả năng khối đó nằm trong chuỗi đèn hiệu chuẩn. Nếu Helios biết thành phần của ủy ban đồng bộ hiện tại, nó có thể tự tin theo dõi người đứng đầu chuỗi bằng cách yêu cầu một RPC không tin cậy cung cấp chữ ký của ủy ban đồng bộ gần đây nhất. 

Cảm ơn BLS chữ ký tổng hợp, chỉ cần một lần kiểm tra duy nhất để xác thực tiêu đề mới. Nếu chữ ký hợp lệ và đã được hơn 2/3 thành viên ủy ban ký thì có thể giả định rằng khối đó đã được đưa vào chuỗi (tất nhiên nó có thể được tổ chức lại khỏi chuỗi, nhưng tính hữu hạn của khối theo dõi có thể cung cấp đảm bảo chặt chẽ hơn).

Tuy nhiên, rõ ràng có một phần còn thiếu trong chiến lược này: làm thế nào để tìm được ủy ban đồng bộ hóa hiện tại. Điều này bắt đầu bằng việc có được nguồn gốc của sự tin cậy được gọi là điểm kiểm tra chủ quan yếu. Đừng để cái tên làm bạn sợ hãi — nó chỉ có nghĩa là một blockhash cũ mà chúng tôi có thể đảm bảo đã được đưa vào chuỗi tại một thời điểm nào đó trong quá khứ. Có một số phép toán thú vị đằng sau việc điểm kiểm tra có thể tồn tại chính xác bao nhiêu tuổi; phân tích trường hợp xấu nhất cho thấy khoảng hai tuần, trong khi ước tính thực tế hơn cho thấy nhiều tháng. 

Nếu điểm kiểm tra quá cũ, có tấn công lý thuyết có thể lừa các nút đi theo chuỗi sai. Việc đạt được một điểm kiểm tra tính chủ quan yếu nằm ngoài khả năng của giao thức. Cách tiếp cận của chúng tôi với Helios cung cấp một điểm kiểm tra ban đầu được mã hóa cứng vào cơ sở mã (có thể dễ dàng bị ghi đè); sau đó nó lưu cục bộ blockhash cuối cùng gần đây nhất để sử dụng làm điểm kiểm tra trong tương lai, bất cứ khi nào nút được đồng bộ hóa. 

Một cách thuận tiện, các khối chuỗi báo hiệu có thể được băm để tạo ra một khối băm báo hiệu duy nhất. Điều này có nghĩa là thật dễ dàng để yêu cầu một nút cung cấp một khối báo hiệu đầy đủ và sau đó chứng minh nội dung khối là hợp lệ bằng cách băm nó và so sánh với một khối băm đã biết. Helios sử dụng thuộc tính này để tìm nạp và chứng minh các trường nhất định bên trong khối điểm kiểm tra tính chủ quan yếu, bao gồm hai trường rất quan trọng: ủy ban đồng bộ hóa hiện tại và ủy ban đồng bộ hóa tiếp theo. Điều quan trọng là cơ chế này cho phép các client nhẹ tua nhanh lịch sử của blockchain.

Bây giờ chúng tôi có điểm kiểm tra chủ quan yếu, chúng tôi có thể tìm nạp và xác minh các ủy ban đồng bộ hiện tại và tiếp theo. Nếu người đứng đầu chuỗi hiện tại nằm trong cùng khoảng thời gian của ủy ban đồng bộ hóa với điểm kiểm tra thì chúng tôi sẽ ngay lập tức bắt đầu xác minh các khối mới với các tiêu đề ủy ban đồng bộ hóa đã ký. Nếu điểm kiểm tra của chúng tôi nằm ở phía sau một số ủy ban đồng bộ, chúng tôi có thể:

1. Sử dụng ủy ban đồng bộ hóa tiếp theo sau điểm kiểm tra của chúng tôi để tìm nạp và xác minh khối tạo ra một ủy ban đồng bộ hóa trong tương lai.
2. Sử dụng khối mới này để tìm nạp ủy ban đồng bộ hóa tiếp theo mới.
3. Nếu vẫn còn chậm thì quay lại bước 1.

Mỗi lần lặp lại của quy trình này cho phép chúng tôi tua nhanh qua 27 giờ lịch sử của chuỗi, bắt đầu với bất kỳ blockhash nào trong quá khứ và đồng bộ hóa với blockhash hiện tại.

…Tại lớp thực thi

Mục tiêu của máy khách hạng nhẹ lớp thực thi là lấy các tiêu đề khối báo hiệu đã được lớp đồng thuận xác minh và sử dụng chúng cùng 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 minh. Dữ liệu này sau đó có thể được truy cập thông qua máy chủ RPC được Helios lưu trữ cục bộ.

Đây là một ví dụ đơn giản về việc tìm nạp số dư của tài khoản, bắt đầu bằng phần tóm tắt nhanh về cách lưu trữ trạng thái trong Ethereum. Mỗi tài khoản chứa một vài trường, chẳng hạn như hàm băm mã hợp đồng, số nonce, hàm băm lưu trữ và số dư. Các tài khoản này được lưu trữ trong một kho lưu trữ lớn, đã được sửa đổi Cây Merkle-Patricia gọi là cây trạng thái. Nếu chúng ta biết gốc của cây trạng thái, chúng ta có thể xác thực bằng chứng merkle để chứng minh sự tồn tại (hoặc loại trừ) của bất kỳ tài khoản nào trong cây. Những bằng chứng này thực sự không thể giả mạo được.

Helios có trạng thái gốc được xác thực từ lớp đồng thuận. Đang dùng root này và yêu cầu bằng chứng merkle tới RPC lớp thực thi không đá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 áp dụng các kỹ thuật khác nhau để xác minh tất cả các loại dữ liệu được lớp thực thi sử dụng; được sử dụng cùng nhau, những điều này cho phép chúng tôi xác thực tất cả dữ liệu được truy xuất từ ​​RPC không đáng tin cậy. Mặc dù RPC không đáng tin cậy có thể từ chối quyền truy cập vào dữ liệu nhưng nó không thể cung cấp cho chúng tôi kết quả không chính xác nữa.

Sử dụng Helios trong tự nhiên

Sự cân bằng giữa tính di động và tính phân quyền là một điểm khó khăn chung — nhưng vì Helios rất nhẹ nên 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 cả điện thoại di động và tiện ích mở rộng trình duyệt). Khả năng chạy Helios ở mọi nơi giúp nhiều người có thể truy cập dữ liệu Ethereum không đáng tin cậy hơn, bất kể phần cứng của họ là gì. Điều này có nghĩa là người dùng có thể sử dụng Helios làm nhà cung cấp RPC trong MetaMask và truy cập các dapp một cách đáng tin cậy mà không cần bất kỳ thay đổi nào khác. 

Hơn nữa, sự hỗ trợ của Rust dành cho WebAssugging giúp các nhà phát triển ứng dụng có thể 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ẽ giúp Ethereum an toàn hơn và giảm nhu cầu tin tưởng vào cơ sở hạ tầng tập trung của chúng ta.

Chúng tôi nóng lòng muốn xem cộng đồng sẽ nghĩ ra điều gì. Tuy nhiên, trong lúc này, có rất nhiều cách để đóng góp cho Helios — nếu không quan tâm đến việc đóng góp cho cơ sở mã, bạn cũng có thể xây dựng phần mềm tích hợp Helios để tận dụng các lợi ích của nó. Đây chỉ là một vài ý tưởng mà chúng tôi rất hào hứng:

• Hỗ trợ tìm nạp dữ liệu máy khách nhẹ trực tiếp từ mạng P2P thay vì qua RPC
• Triển khai một số phương pháp RPC còn thiếu
• Xây dựng phiên bản Helios biên dịch sang WebAssugging
• Tích hợp trực tiếp Helios vào phần mềm ví
• Xây dựng trang tổng quan web để xem số dư mã thông báo của bạn để tìm nạp dữ liệu từ Helios được nhúng vào trang web bằng WebAssembly
• Triển khai API công cụ để lớp đồng thuận của Helios có thể được kết nối với nút đầy đủ của lớp thực thi hiện có

Kiểm tra cơ sở mã để bắt đầu — chúng tôi hoan nghênh các báo cáo lỗi, yêu cầu tính năng và mã của bạn. Và nếu bạn xây dựng được điều gì đó hơn nữa, hãy chia sẻ nó với chúng tôi trên Twitter, Telegramhoặc Farcaster @a16zcrypto.

***
Các quan điểm được thể hiện ở đây là quan điểm của từng nhân viên AH Capital Management, LLC (“a16z”) được trích dẫn và không phải là quan điểm của a16z hoặc các chi nhánh của nó. Một số thông tin nhất định trong đây đã được lấy từ các nguồn của bên thứ ba, bao gồm từ các công ty danh mục đầu tư của các quỹ do a16z quản lý. Mặc dù được lấy từ các nguồn được cho là đáng tin cậy, a16z đã không xác minh độc lập thông tin đó và không đưa ra tuyên bố về tính chính xác hiện tại hoặc lâu dài của thông tin hoặc sự phù hợp của nó đối với một tình huống nhất định. Ngoài ra, nội dung này có thể bao gồm các quảng cáo của bên thứ ba; a16z đã không xem xét các quảng cáo đó và không xác nhận bất kỳ nội dung quảng cáo nào có trong đó.

Nội dung này chỉ được cung cấp cho mục đích thông tin và không được dựa vào như lời khuyên về pháp lý, kinh doanh, đầu tư hoặc thuế. Bạn nên tham khảo ý kiến ​​của các cố vấn của riêng mình về những vấn đề đó. Các tham chiếu đến bất kỳ chứng khoán hoặc tài sản kỹ thuật số nào chỉ dành cho mục đích minh họa và không cấu thành khuyến nghị đầu tư hoặc đề nghị cung cấp dịch vụ tư vấn đầu tư. Hơn nữa, nội dung này không hướng đến cũng như không nhằm mục đích sử dụng cho bất kỳ nhà đầu tư hoặc nhà đầu tư tiềm năng nào và không được dựa vào bất kỳ trường hợp nào khi đưa ra quyết định đầu tư vào bất kỳ quỹ nào do a16z quản lý. (Đề nghị đầu tư vào quỹ a16z sẽ chỉ được thực hiện bởi bản ghi nhớ phát hành riêng lẻ, thỏa thuận đăng ký và các tài liệu liên quan khác về bất kỳ quỹ nào như vậy và phải được đọc toàn bộ.) Bất kỳ khoản đầu tư hoặc công ty danh mục đầu tư nào được đề cập, đề cập đến, hoặc được mô tả không phải là đại diện cho tất cả các khoản đầu tư vào xe do a16z quản lý và không thể đảm bảo rằng các khoản đầu tư sẽ sinh lời hoặc các khoản đầu tư khác được thực hiện trong tương lai sẽ có các đặc điểm hoặc kết quả tương tự. Danh sách các khoản đầu tư được thực hiện bởi các quỹ do Andreessen Horowitz quản lý (không bao gồm các khoản đầu tư mà tổ chức phát hành không cho phép a16z tiết lộ công khai cũng như các khoản đầu tư không thông báo vào tài sản kỹ thuật số được giao dịch công khai) có tại https://a16z.com/investments /.

Các biểu đồ và đồ thị được cung cấp bên trong chỉ nhằm mục đích cung cấp thông tin và không nên dựa vào khi đưa ra bất kỳ quyết định đầu tư nào. Hiệu suất trong quá khứ không cho thấy kết quả trong tương lai. Nội dung chỉ nói kể từ ngày được chỉ định. Mọi dự đoán, ước tính, dự báo, mục tiêu, triển vọng và / hoặc ý kiến ​​thể hiện trong các tài liệu này có thể thay đổi mà không cần thông báo và có thể khác hoặc trái ngược với ý kiến ​​của người khác. Vui lòng xem https://a16z.com/disclosures để biết thêm thông tin quan trọng