Ứng dụng khách Fluffy: một ứng dụng khách cực kỳ nhẹ cho Ethereum

Làm thế nào chúng ta có thể thiết kế mạng sao cho máy khách chỉ cần đóng góp một lượng nhỏ dữ liệu vào mạng, để toàn bộ mạng (những đóng góp này) có thể có nhiều ý nghĩa?

—— Piper Merriam

Chúng tôi vui mừng thông báo rằng Nimbus sẽ tham gia nhóm "Mạng cổng thông tin" của Ethereum Foundation với tư cách là một trong những khách hàng khởi chạy của Mạng cổng thông tin.

Tóm tắt một câu: "Mạng cổng thông tin" là một dự án khách hàng chéo đang được phát triển để mô phỏng lại ứng dụng khách nhẹ của Ethereum và phát triển trải nghiệm ứng dụng khách nhẹ thực tế và có thể sử dụng được.

Để trích dẫn đặc điểm kỹ thuật trực tiếp:

"Mạng cổng thông tin" là một dự án đang được phát triển để cho phép truy cập nhẹ vào giao thức cho các thiết bị có tài nguyên hạn chế.

Thuật ngữ "cổng" có nghĩa là các mạng này có thể quan sát hiện trạng hoạt động của giao thức, nhưng không quan tâm đến hoạt động của giao thức Ethereum cốt lõi.

Mạng cổng thông tin sẽ bao gồm một hoặc nhiều mạng ngang hàng phi tập trung cung cấp chung dữ liệu và chức năng cần thiết để hiển thị API JSON-RPC tiêu chuẩn.

Các mạng này được thiết kế đặc biệt để đảm bảo rằng các máy khách này chỉ cần trả băng thông mạng, CPU, RAM và tài nguyên đĩa cứng cơ học tối thiểu để tham gia.

Thuật ngữ "mạng cổng thông tin" cũng được sử dụng để mô tả phần mềm tham gia vào các mạng này và hiển thị API JSPN-PRC tiêu chuẩn.

Cụ thể, mục tiêu của chúng tôi là hợp tác với EF để phát triển một bộ giao thức Ethereum mới xung quanh các giao thức Ethereum hiện có, có thể phục vụ cụ thể cho phương pháp truy cập dữ liệu Ethereum mới này.

Mục tiêu tổng thể là cung cấp một mô hình hoạt động cho Ethereum có thể phục vụ các kiểu sử dụng phổ biến, thay vì theo dõi trạng thái đầy đủ trong thời gian thực (đó là những gì máy khách hiện tại làm).

Những gì chúng ta đang thảo luận là phát triển một ứng dụng khách hoàn hảo cho ví, một ứng dụng khách rất nhẹ có thể đóng góp cho mạng nhưng không yêu cầu đồng bộ hóa chuỗi khối (nghĩa là có thể khởi động lại sau khi ngoại tuyến và sau khi cài đặt có sẵn ngay lập tức).

Nó cũng không khó như nó có vẻ. Tôi cho rằng hầu hết các ví đều nhúng trực tiếp ứng dụng khách nhẹ, ví dụ: @ethstatus sẽ tích hợp ứng dụng khách nhẹ @ethnimbus. Vì vậy, có thể xảy ra trường hợp hầu hết người dùng bắt đầu chạy ứng dụng khách nhẹ mà không hề hay biết.

May 24, 2021

Vì vậy, một trong những mục tiêu cuối cùng của chúng tôi là loại khách hàng này được đưa ngay vào ứng dụng Trạng thái.

lý lịch

lý lịch

Mạng cổng thông tin bắt nguồn từ mục tiêu ban đầu của nhà phát triển Piper Merriam và nhóm Trinity: phát triển một ứng dụng khách nhẹ trên mạng hiện có. Nó ra đời vì họ nhận ra rằng mạng hiện tại không đủ linh hoạt cho loại khách hàng mà họ hình dung.

Theo lời của Piper:

Khi chúng tôi bắt đầu phát triển ứng dụng khách Trinity, mục tiêu của chúng tôi là phát triển một ứng dụng khách nhẹ. Nhưng sau khi dành gần ba năm để hiểu sâu về giao thức và khám phá các cách phát triển ứng dụng khách mà chúng tôi đã hình dung, cuối cùng chúng tôi đã đi đến kết luận rằng điều đó không thể thực hiện được trên mạng hiện có.

Đây là ý định ban đầu của mạng cổng thông tin. Chúng tôi sẽ quay trở lại giao diện mà chúng tôi muốn máy khách trông như thế nào, sau đó thiết kế chức năng mạng cần thiết để nó hoạt động.

tiêu đề cấp đầu tiên

Động lực (quan điểm khách hàng nhẹ)

Mạng DevP2P LES hiện có được thiết kế với kiến ​​trúc máy khách/máy chủ, với các máy khách nhẹ là máy khách và các nút đầy đủ là máy chủ (cho đến nay, thuật ngữ "máy khách nhẹ" đề cập đến máy khách DevP2P LES hiện có của mạng).

Do kiến ​​trúc này gán tất cả tải cho nút đầy đủ và chi phí vận hành của nút đầy đủ đã cao nên các nhà khai thác nút không muốn kích hoạt chức năng này.

Vì vậy, trong khi thiết kế mạng hiện tại đạt được mục tiêu ban đầu tốt, thì nó lại thất bại nặng nề từ góc độ máy khách nhẹ.

Làm thế nào để chúng ta giải quyết vấn đề này? Như nhóm Trinity của Piper đã phát hiện ra, thực tế cho thấy không có giải pháp dễ dàng nào cho vấn đề này. Các mạng hiện tại không đủ linh hoạt để thiết kế máy khách nhẹ hiệu quả.

tiêu đề cấp đầu tiên

thiết kế

Một mạng thân thiện với máy khách nhẹ phải được thiết kế sao cho các nút có thể tham gia vào mạng và đóng góp vào mạng chỉ với một lượng nhỏ dung lượng lưu trữ và một lượng công việc nhỏ, thay vì yêu cầu mỗi nút phải chịu tải cao (tức là : trong Toàn bộ lịch sử của chuỗi khối được lưu trong bộ nhớ).

Nói cách khác, một mạng như vậy phải cho phép các máy khách nhẹ thực sự đóng góp vào mạng, sao cho mỗi khi có thêm các máy khách tham gia vào mạng, nó sẽ làm tăng dung lượng của mạng.

Cụ thể, điều này có nghĩa là đưa ra một thiết kế mạng giúp giảm chi phí xác thực đối với dữ liệu được yêu cầu không thường xuyên của bạn và giảm chi phí cơ bản của việc truyền thông điệp qua mạng.

Mạng cổng nhằm thực hiện điều này bằng cách chia cấu trúc tổng thể của giao thức Ethereum thành ba mạng riêng biệt: trạng thái và lịch sử Gossip (giao dịch và khối); trọng tâm phát triển ban đầu là mạng trạng thái.

Các mạng này sẽ cùng tồn tại với giao thức ETH - nhưng không giống như giao thức ETH, chúng không nhất thiết phải hoàn toàn bất khả xâm phạm, nhưng chúng cần có khả năng hoạt động gần như không ngừng nghỉ.

Hy vọng là các mạng mới này, theo thời gian, có thể được tích hợp chặt chẽ hơn với các mạng hiện có. Ví dụ: chúng ta có thể tưởng tượng một thế giới nơi các máy khách đầy đủ tính năng có thể sử dụng mạng cổng lịch sử để cung cấp cho người vận hành nút tùy chọn bổ sung là chỉ lưu trữ lịch sử mà họ quan tâm (có thể là 200 MB) thay vì toàn bộ chuỗi khối (lớn hơn 200 MB). GB). Điều tương tự cũng xảy ra với dữ liệu trạng thái.

Nói chung, kiến ​​trúc mô-đun này - nơi dữ liệu (trạng thái và lịch sử chuỗi khối) được chia sẻ theo kiểu P2P, trong khi các giao dịch và khối được lan truyền thông qua tin đồn - cho phép các ứng dụng khách nhẹ chọn mức độ lưu trữ/cung cấp dữ liệu và dữ liệu lịch sử.

tiêu đề cấp đầu tiên

Ghi chú JSON RPC

phiên dịch tiếng trungphiên dịch tiếng trung): Hầu hết các ví, bao gồm cả ví của chúng tôi, đều chuẩn hóa trên API JSON RPC.

Chức năng chính xác của ví Trạng thái yêu cầu các điểm cuối JSON RPC sau:

• eth_blockNumber được sử dụng để theo dõi đỉnh của chuỗi

• eth_getBalance và eth_getTransactionCount được sử dụng để lấy thông tin tài khoản

• eth_call được sử dụng để đọc thông tin hợp đồng

• eth_estimateGas và eth_gasPrice được sử dụng để ước tính phí gas

• eth_sendRawTransaction được sử dụng để gửi giao dịch của người dùng

• eth_getTransactionReceipt Nhận biên lai sau khi giao dịch được thực hiện trên chuỗi

• Nếu chúng tôi sắp xếp thêm các thành phần cần thiết để thực hiện chức năng ví, chúng tôi có thể nhận được các yêu cầu cấp thấp hơn sau:

• Truy cập các mục lưu trữ hợp đồng và tài khoản (trạng thái) để hỗ trợ: eth_call, eth_estimateGas, eth_getBalance và eth_getTransactionCount

• Truy cập mạng buôn chuyện (Gossip) để theo dõi đầu dây chuyền và eth_sendRawTransaction

• Lịch sử của chuỗi truy cập (lịch sử), được sử dụng cho eth_getTransactionReceipt

• Mở ra khả năng truy cập nhẹ vào trạng thái, tin đồn và lịch sử, Portal Networks mở ra cơ hội cho các ứng dụng khách nhẹ có thể nhúng vào ví đáp ứng các nhu cầu này mà không cần đồng bộ hóa chuỗi khối và hy sinh quyền riêng tư và bảo mật tình dục.

  tiêu đề cấp đầu tiên

Tình trạng của dự án

Chúng tôi đã bắt đầu phát triển một phương thức hoạt động cho Nimbus, ban đầu được đặt tên là nlpn nhưng hiện được đổi tên thành smooth, phương thức này sẽ tồn tại và chạy song song với ứng dụng khách Ethereum 1.

smooth sẽ cho phép máy khách nimbus-eth1 hoạt động như một nút máy khách rất nhẹ trong mạng.

Công việc ban đầu là phát triển giao thức Portal Wire, một giao thức thứ cấp được xây dựng dựa trên giao thức Node Discovery v5.1.

Bước tiếp theo

Bước tiếp theo

Bước tiếp theo là truyền dữ liệu qua giao thức Portal Wire. Chúng tôi đang xử lý dữ liệu trạng thái.

Điều này yêu cầu các "nút cầu nối" để nhập dữ liệu trạng thái cho mạng cổng thông tin. Cách tiếp cận hiện tại là sử dụng plugin máy khách Nethermind làm API JSON-PRC tùy chỉnh để cung cấp dữ liệu cho các nút cổng thông tin sẵn sàng hoạt động như các nút cầu nối. Công việc này đã bắt đầu (thông số kỹ thuật dự thảo tại đây).

tiêu đề cấp đầu tiên

nguồn

• Bạn có thể tìm thấy Máy khách Mạng Cổng thông tin Nimbus (nlpn) trong kho lưu trữ nimbus-eth1 của chúng tôi: https://github.com/status-im/nimbus-eth1/tree/master/fluffy

• Giao thức Portal Wire đã được thêm vào cơ sở mã nim-eth làm giao thức phụ cho giao thức khám phá nút v5.1: https://github.com/status-im/nim-eth

• Thông số kỹ thuật: https://github.com/ethereum/stateless-ethereum-specs/

• Trang web: https://www.ethportal.net/

• Một số nội dung về thử nghiệm giao thức Portal Wire đầu tiên với ddht và trin: https://Gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53

• Chuỗi blog của Piper Merriam: Con đường quanh co đến với các khách hàng ánh sáng chức năng

• Một video bài giảng về chủ đề

• Lưu ý: Thuận tiện là tất cả cơ sở hạ tầng cần thiết để triển khai các ứng dụng khách nhẹ chức năng cũng sẽ tự nhiên mở rộng sang các ứng dụng khách không trạng thái, do đó sẽ có nhiều sự chồng chéo với Ethereum không trạng thái. Trên thực tế, việc cho phép các máy khách phi trạng thái phục vụ hầu hết các API JSON-PRC là một trong những động lực cốt lõi của mạng cổng thông tin.