Giới thiệu DEADR: Bước tiếp theo của Cover Traffic và Staking
Kể từ khi mã thông báo HOPR được ra mắt vào tháng 2, xem ra mọi thứ có vẻ yên tĩnh trên phương diện công nghệ. Tuy nhiên, trong thực tế thì hoàn toàn ngược lại, chúng tôi rất bận rộn cho việc hoàn thành bản nâng cấp Eiger.
Chúng tôi biết rằng các bạn đã kiên nhẫn chờ đợi (một số ít thì không) để bắt đầu staking mã thông báo HOPR của mình. Nhưng đó là một hành động được đền đáp xứng đáng khi bạn đặt niềm tin, sự riêng tư của mình vào một mạng lưới thông tin hỗn hợp, mạng đó cần phải có sự an toàn, tin cậy và bình đẳng giữa những người dùng.
Một rào cản lớn nhất của giao thức là quá phụ thuộc vào các máy chủ bootstrap, nơi mà những người tham gia testnet đều biết đây là một nguyên nhân chính gây ra sự không ổn định và thời gian mạng bị lỗi. Rào cản đó cuối cùng đã được xóa bỏ với DEADR, được giới thiệu trong bản phát hành Kiautschou sẽ đến với bạn vào cuối tuần tới, khi các thử nghiệm nội bộ diễn ra tốt đẹp.
Những vấn đề phát sinh
Ngay cả trước khi ra mắt mã thông báo, nhóm kỹ sư tại HOPR đã làm việc không mệt mỏi để phát triển giao thức HOPR.
Chúng tôi nhắc lại lần nữa, giao thức HOPR, là giao thức đang triển khai mạng mixnet bảo mật lớp-0, cho phép mọi người trao đổi dữ liệu một cách riêng tư. Cho tới hiện tại, có thể bạn đã chạy thử nghiệm bản phát hành Jungfrau chính thức của chúng tôi , bằng cách khởi tạo một vài kênh, gửi một vài tin nhắn và nhận được một số vé ticket với mã thông báo chuyển đổi wxHOPR. Các hoạt động này được sử dụng trên mạng xDai, giúp các bạn hiểu thêm về khái niệm bằng chứng chuyển tiếp_Proof of relay.
Thật không may, nếu bạn đang chạy Jungfrau, bạn có thể tình cờ gặp màn hình sau:
Chú thích: Tương đương với màn hình xanh khi nút HOPR của bạn không hoạt động.
Khi hỏi về điều này trong nhóm Telegram của chúng tôi , các đại sứ có thể sẽ điều hướng bạn đến trang Status. Bạn có thể tìm thấy những câu hỏi và câu trả lời tương tự như: Sự chẩn đoán là gì? Máy chủ bootstrap đang có khả năng bị lỗi. Giải pháp? Hãy thử lại node của bạn sau khi máy chủ khởi động lại.
Điều đó chẳng có gì thú vị cả và đó là một vấn đề nghiêm trọng khi nói đến việc triển khai tính năng Cover traffic và Staking của giao thức HOPR. Điều tuyệt vời nhất của mô hình Staking trong HOPR là nó được tích hợp ngay vào giao thức quyền riêng tư: nó không chỉ là một cách tùy ý để giảm sự ảnh hưởng của các tổ chức lớn, mà là một phần cơ bản của việc khuyến khích một mixnet.
Nhưng điều đó chỉ hiệu quả nếu mọi người đều có cơ hội truy cập mạng. Staking không phải là vấn đề chính, mà Bootstrap mới là vấn đề chúng ta cần xem xét vì nó có thể khóa mọi người ngẫu nhiên ra khỏi mạng HOPR.
May mắn thay, bản phát hành HOPR tiếp theo đã thay đổi hoàn toàn cách các nút tham gia vào mạng HOPR và chuyển tiếp dữ liệu, giảm đáng kể sự phụ thuộc vào các máy chủ bootstrap và mở đường cho Cover traffic và Staking.
Để biết những điều này hoạt động như thế nào, chúng ta cần xem tại sao HOPR lại phụ thuộc vào các máy chủ bootstrap trong một thời gian dài.
Vậy máy chủ Bootstrap là gì?
Các mạng phi tập trung không phải chỉ mới xuất hiện. Các nút cần biết nơi để bắt đầu tham gia mạng và sau đó nó cần tìm các thành viên khác trong mạng đó để trao đổi dữ liệu, ngay cả khi các nút mới hoạt động hay đang ngoại tuyến. Điều đó đã đủ khó trước khi bạn đưa quyền riêng tư vào mạng hỗn hợp mixnet: vậy làm thế nào để bạn tham gia và theo dõi một mạng mà không ai được biết vị trí của bất kỳ ai?
Câu trả lời đơn giản nhất là sử dụng máy chủ bootstrap.
Trong một mạng phi tập trung, một máy chủ bootstrap giống như chủ của một bữa tiệc mà những người được mời đã biết. Đó là một (hoặc nhiều) nút lưu trữ thông tin về các nút khác trong mạng bằng cách trở thành điểm vào đầu tiên và lưu trữ địa chỉ của mọi người trong một cấu trúc dữ liệu được gọi là bảng băm phân tán ( DHT) . Bất cứ khi một nút HOPR nào khởi động, nó sẽ tìm kiếm một máy chủ bootstrap mặc định nơi nó tự thông báo để những người khác tìm thấy. Đây là một cách tiếp cận khá tiêu chuẩn. Ví dụ: Golem sử dụng chiến lược tương tự để thông báo các phần của cơ sở hạ tầng cho các nhà cung cấp của họ.
Chú thích: Trong quá trình khởi động trong một mạng phi tập trung (được hiển thị bên trái), thường có một hoặc nhiều điểm vào. Các nút đăng ký địa chỉ của chúng (1) với máy chủ bootstrap để nó ghi lại, vì vậy các nút khác có thể nhìn thấy chúng. Khi phát hiện ra, một kết nối trực tiếp (2) được cố gắng thiết lập giữa các nút, bỏ qua sự có mặt của máy chủ bootstrap. Tuy nhiên, khi điều này không thành công, máy chủ bootstrap có thể tiếp tục được sử dụng như một nút chuyển tiếp (3).
Hiện tại, với hầu hết các ứng dụng blockchain, đây không phải là một vấn đề. Đầu tiên, hầu hết các ứng dụng khách (ví dụ: geth, bitcoind) thường yêu cầu phần mềm được thực hiện đằng sau một IP có thể truy cập công khai hoặc yêu cầu người dùng chuyển tiếp thiết lập tại nhà của mình hoặc sử dụng IP tĩnh. Thứ hai, bất cứ khi nào các kết nối bị thiếu và/hoặc các nút không tự thông báo được cho các nút khác, chúng có thể tiếp tục gửi yêu cầu lệnh tới các nút khác cho đến khi chúng đạt được đủ các nút cần được xem xét. Điều này là hoàn toàn thực hiện được, vì thông thường bạn chỉ cần đồng ý về trạng thái mới nhất của khối và theo dõi các giao dịch mới nhất được thực hiện bởi các nút.
Tuy nhiên, cách tiếp cận này là không đủ cho giao thức HOPR. Nếu không có kết nối ổn định giữa các nút, các gói được chia sẻ giữa chúng có thể bị mất trong quá trình truyền. Điều này có nghĩa là người gửi sẽ không nhận được các ticket và do đó không có động lực để chạy nút của họ . Bởi vì HOPR không thể hoạt động như một mixnet nếu không có chuyển tiếp thích hợp, nhiều cuộc tấn công có thể xảy ra đối với mạng, làm lộ quyền riêng tư của người dùng trong mạng HOPR. Không giống như các giao thức khác có thể hoạt động chỉ với một vài nút đáng tin cậy, HOPR cần càng nhiều nút càng tốt để nó hoạt động bình thường .
Quay trở lại vấn đề ban đầu của chúng tôi, việc sử dụng máy chủ bootstrap với chiến lược này làm giảm độ tin cậy của toàn bộ mạng. Bất cứ khi nào máy chủ gặp sự cố, các nút mới không kết nối được và các kết nối trực tiếp giữa các không thể chuyển tiếp. Nói tóm lại, nó trở thành một điểm lỗi duy nhất không chỉ đối với các nút mới không thể kết nối mà còn đối với các nút hiện có sử dụng nó để chuyển tiếp dữ liệu.
Giới thiệu DEADR, một chiến lược để từ bỏ máy chủ Bootstrap
Vì các máy chủ bootstrap chạy cùng một phần mềm với các nút HOPR “tiêu chuẩn”, chúng tôi nhanh chóng nhận ra rằng chúng tôi có thể tăng độ tin cậy của các máy chủ bootstrap bằng cách loại bỏ chúng ra khỏi Hiệp hội HOPR. Nói tóm lại, nếu chúng ta định cấu hình các nút HOPR để “tự nhận dạng” bất cứ khi nào chúng được xuất hiện công khai trên mạng (tức là đằng sau một IP công khai), chúng có thể được sử dụng như là máy chủ bootstrap và như các nút bình thường.
Trên hết, chúng ta có thể tránh phải yêu cầu danh sách các nút trong mạng DHT từ một máy chủ bootstrap nếu mỗi khi một nút mới gia nhập vào mạng. Chúng tôi lưu trữ địa chỉ của nó ở đâu đó không phải DHT của máy chủ bootstrap. Vì chúng tôi đã sử dụng blockchain để giải quyết các khoản thanh toán của các nút, chúng tôi cũng có thể sử dụng blockchain để lưu trữ dữ liệu này và tìm nạp nó sau đó. Xét cho cùng, chúng tôi sử dụng cùng một cơ chế để lưu trữ các kênh thanh toán của mình.
Với những ý tưởng trên, chiến lược Quảng cáo đầu vào phi tập trung & Chuyển tiếp phân tán (hoặc chỉ là DEADR) đã ra đời. DEADR xác định ba nguyên tắc cơ bản cốt lõi của nó:
-
Bất cứ khi nào có thể, một nút HOPR đằng sau một IP có thể quảng bá địa chỉ của mình tới hợp đồng thông minh HOPR để được đăng ký làm máy chủ bootstrap.
-
Tất cả các máy chủ sẽ có khả năng tự đăng ký làm nút vào mạng bằng cách sử dụng blockchain, ngay sau khi bắt đầu một nút.
-
Việc chuyển tiếp không còn bị giới hạn bởi một máy chủ bootstrap vào duy nhất mà có thể được thực hiện bởi bất kỳ nút HOPR nào đã đăng ký trước đó làm nút vào.
DEADR đã được xuất bản trong GitHub của chúng tôi và việc triển khai đầu tiên sẽ xuất hiện trực tuyến như một phần của bản phát hành Kiautschou (nó thực ra là một phần của bản phát hành Stirlingi) nhưng có một số tính năng khác mà chúng tôi muốn triển khai trước khi chia sẻ với công chúng. Như mọi khi, bạn có thể kiểm tra tất cả những điều này trong GitHub của chúng tôi.
Câu hỏi thường gặp
Có một số câu hỏi bạn có thể hỏi:
Điều đó có nghĩa là nút của tôi sẽ được sử dụng bởi những người chạy nút khác để chuyển tiếp lưu lượng truy cập? Điều đó sẽ không làm rò rỉ sự riêng tư của các gói tin chứ?
Nếu nút của bạn nằm sau một IP có sẵn công khai (rất có thể nếu bạn đang sử dụng nhà cung cấp dịch vụ đám mây), thì nút của bạn có thể sẽ được sử dụng như một bộ chuyển tiếp. Tuy nhiên, vì HOPR sử dụng định dạng gói SPHINX, ngay cả khi nút của bạn được sử dụng để chuyển tiếp lưu lượng, bạn cũng không có khả năng kiểm tra bất kỳ lưu lượng nào được chia sẻ giữa các nút trong mạng.
Liệu nút của tôi được sử dụng như một nút chuyển tiếp thì nó có ảnh hưởng đến hiệu suất hoặc bộ nhớ của nó so với các nút khác không?
Chúng tôi chưa đo lường chính xác điều này, nhưng qua phân tích máy chủ bootstrap của chúng tôi cho thấy điều này có thể xảy ra. Tuy nhiên, nếu nút của bạn được sử dụng như một bộ chuyển tiếp, điều đó có nghĩa là nó có các kênh mở đến các nút khác và do đó có nhiều khả năng được chọn làm chuyển tiếp lưu lượng dữ liệu truy cập_Cover traffic. Vì vậy, bạn sẽ được thưởng cho việc làm đó và là điều nên làm.
Các bước tiếp theo và con đường tới Staking
Chúng tôi đang đợi để triển khai trực tiếp chiến lược DEADR đầu tiên trong giao thức HOPR ở bản phát hành công khai tiếp theo của chúng tôi, Kiautschou. Nếu tất cả mọi thứ tốt đẹp và suôn sẻ, bản cập nhật này sẽ được phát hành để cộng đồng chạy thử vào ngày 18 tháng 6. Phiên bản này chưa được công bố hết, nhưng nếu các bạn có hứng thú muốn trải nghiệm quá trình chúng tôi làm sản phẩm thì đây là cơ hội tuyệt vời để bạn thiết lập các nút và chạy kiểm tra hệ thống mạng. Như thường lệ, chúng tôi khuyến cáo các bạn không nên gửi quá 10wxHOPR vào nút của mình cho mục đích thử nghiệm và cũng không có lợi nào nếu bạn gửi nhiều wxHOPR vào nút của mình.
Việc triển khai DEADR cuối cùng cũng mở ra con đường cho Cover traffic và Staking, cơ chế khuyến khích được Hiệp hội HOPR sử dụng để khởi động lưu lượng truy cập vào mạng.
Trong một tin tức thú vị khác, chúng tôi sẽ có một cuộc thảo luận trong cộng đồng HOPR vào ngày 18 tháng 6 , cùng ngày với bản phát hành Kiautschou. Trong cuộc thảo luận này, chúng tôi sẽ giới thiệu bản phát hành và đưa ra các kế hoạch cho Staking và Cover traffic cùng bản tóm tắt những gì đang diễn ra trong cộng đồng HOPR trong vài tháng qua. Thông tin chi tiết hơn về cuộc thảo luận này sẽ được chia sẻ vào tuần tới. Chúng tôi hy vọng tất cả các bạn sẽ tham gia cùng chúng tôi
Jose Aguinaga,
Trưởng bộ phận Kỹ thuật HOPR