Kiến thức cơ bản về HOPR_Tập 6: Bằng chứng chuyển tiếp

Kiến thức cơ bản về HOPR: Bằng chứng chuyển tiếp
image

Tiến sĩ Sebastian Bürgel

28 tháng 7 · 4 phút đọc

Đây là tập thứ sáu trong loạt bài của chúng tôi bao gồm những kiến thức cơ bản về HOPR. Các liên kết đến các tập trước có thể tìm thấy ở cuối bài viết.

Có một nghịch lý chính trong việc xây dựng một mixnet được khuyến khích là làm thế nào để bạn đảm bảo rằng các nút thực hiện đúng nhiệm vụ chuyển tiếp dữ liệu của chúng, nút chỉ nhận sự khuyến khích và không làm gì cả?

Giải pháp của HOPR được gọi là bằng chứng chuyển tiếp , và tập này sẽ giải thích cách hoạt động của nó.

Quyền riêng tư đáng tin cậy

Chúng ta không thể dựa vào mọi người tuân theo các quy tắc bởi vì đó là điều đúng đắn phải làm. Chúng ta cần làm cho việc tuân theo các quy tắc trở nên hợp lý và có lợi. Đây là nền tảng của nhiều hệ thống mật mã, và điều gì khiến họ tin c ậy (một thuật ngữ hơi khó hiểu đó có nghĩa một hệ thống đáng tin cậy bởi vì bạn không cần phải tin tưởng vào bất cứ thành viên trong nhóm). Về cơ bản, khi cách cư xử ích kỷ nhất cũng là cách hệ thống muốn bạn cư xử, chúng ta không cần phải dựa dẫm vào bất cứ ai.
image

Trong trường hợp của HOPR, chúng tôi cần một cách để đảm bảo mọi người đều được thưởng công bằng, nhưng chỉ sau khi họ đã chuyển tiếp dữ liệu. Cơ chế này cần giữ cho mọi người tính trung thực mà không cần theo dõi và kiểm tra rõ ràng mọi người, nếu không tất cả các công việc riêng tư liên quan đến thiết kế mixnet sẽ bị hoàn tác.

Giữ các nút trung thực

Trong tập trước, chúng ta đã xem xét một cách tiếp cận đơn giản đối với các khoản thanh toán trong đó người dùng sẽ thanh toán trả trước cho toàn bộ chi phí trên mạng và tại mỗi bước nhảy, một người chạy nút sẽ lấy phần của họ và chuyển phần còn lại xuống chuỗi.

Vấn đề ở trên không có gì đảm bảo sau khi được thanh toán, nút có chuyển tiếp số liệu cho nút tiếp theo hay không? Tại sao nút chỉ lấy tiền và không chuyển tiếp dữ liệu? Tính ẩn danh của mạng HOPR sẽ cho phép các nút ăn cắp từ hệ thống mà không cần thực hiện công việc chuyển tiếp của chúng. Hãy nhớ rằng, chỉ người gửi mới biết toàn bộ tuyến đường mà gói dữ liệu phải đi và việc trộn có nghĩa là sẽ không có cách nào để theo dõi vị trí mà ở đó tuyến đường truyền tải đang bị lỗi.

Vì vậy, chúng tôi cần một cách để đảm bảo các nút chỉ được thanh toán sau khi họ thực hiện xong việc chuyển tiếp. Đây là một giải pháp trực quan. Xét cho cùng, mọi người thường được trả lương sau khi làm việc, chứ không phải trước đó. Nhưng làm thế nào để đạt được điều đó?

Một cách tiếp cận đơn giản là thử và yêu cầu mỗi nút trong chuỗi trả cho nút tr ướ c đó . Vì vậy, khi Dmytro nhận được dữ liệu từ Chāo, anh ta sẽ gửi khoản thanh toán của Chāo như một phần thưởng. Nhưng bây giờ chúng ta lại gặp phải vấn đề tương tự. Tại sao Dmytro phải bận tâm? Tại sao không chỉ tiết kiệm công sức và phải gửi lại tiền? Một lần nữa, sự riêng tư của mạng có nghĩa là không có cách nào để bị phát hiện.

(Đây là một sự đơn giản hóa nhẹ - sau tất cả, Chāo biết rằng anh ấy đã gửi một số dữ liệu cho Dmytro và biết rằng anh ấy không nhận được bất kỳ khoản thanh toán nào. Nhưng anh ấy không thể ch ng minh điều đó là độc hại. Mọi thứ đều trục trặc trong mạng! Và ngay cả khi Dmytro không chuyển tiếp thanh toán, anh ta có thể rời khỏi mạng và bắt đầu lại với danh tính mới. Một lần nữa, quyền riêng tư lại trở thành con dao hai lưỡi.)

Vì vậy, làm thế nào chúng ta có thể giải quyết điều này?

Bằng chứng chuyển tiếp

Sự đổi mới của HOPR là làm cho mỗi cặp nút liên tiếp trong một chuỗi d a v à o nhau đ thanh to á n . Chāo không thể yêu cầu thanh toán cho đến khi anh ta chuyển dữ liệu cho Dmytro, nhưng Dmytro cũng không thể yêu cầu thanh toán cho đến khi anh ta mở phần của Chāo.

Điều này đạt được thông qua một kỹ thuật mật mã, nhưng nó thực sự đơn giản để hiểu.

Khi dữ liệu được gửi qua mạng HOPR, một khoản thanh toán được tạo cho mỗi nút trong chuỗi. Điều này được khóa bằng một khóa mật mã. Nếu bạn có toàn bộ chìa khóa, bạn có thể yêu cầu việc thanh toán của mình. Nhưng nếu thiếu bất kỳ phần nào của nó thì nó vô giá trị.

Các khóa này được chia đôi, vì vậy bạn chỉ có thể yêu cầu thanh toán khi bạn có cả hai khóa.
image

Khi dữ liệu đi dọc theo chuỗi, các cặp nút liên tiếp hoán đổi mỗi nửa chìa khóa với nhau. Chāo đổi nửa đầu chìa khóa của mình lấy nửa sau chìa khóa của Betty. Anh ta hoán đổi nửa đầu chìa khóa của Dmytro cho nửa sau của chìa khóa của anh ta. Sau đó, anh ta có thể yêu cầu thanh toán của mình, nhưng chỉ vì dữ liệu đã chuyển thành công từ Betty sang Chāo sang Dmytro.

Điều này buộc mọi người phải chơi theo luật. Nếu tôi là nút nhận dữ liệu từ bạn, không ai trong chúng tôi có thể yêu cầu bất kỳ khoản tiền nào trừ khi chúng tôi hoán đổi các nửa khóa. Không có lợi gì khi trốn tránh trách nhiệm của bạn, không có sơ hở để lấy cắp tiền. Điều cần làm thiết thực là hợp tác, có nghĩa là tính ưu đãi được áp dụng cho tất cả mọi người.

Gìn giữ quyền riêng tư

Sự đổi mới đơn giản nhưng cực kỳ mạnh mẽ này mở ra cả một thế giới tiềm năng. Với bằng chứng của sự chuyển tiếp, cuối cùng chúng ta có thể xây dựng một mạng mixnet riêng được khuyến khích đầy đủ có thể phát triển ở quy mô không giới hạn, bởi vì chúng ta không phải dựa vào việc tìm kiếm những người đáng tin cậy để điều hành nó.

Tuy nhiên, chúng tôi vẫn chưa thoát ra khỏi sự phức tạp. Nếu mỗi khoản thanh toán tạo ra một giao dịch trên một blockchain công khai, chúng ta đang tiến gần đến việc vô tình cung cấp một cơ sở dữ liệu về mọi thứ xảy ra trong mạng. HOPR sử dụng các khoản thanh toán theo xác suất để tách lớp thanh toán của HOPR khỏi lớp nhắn tin, đảm bảo quyền riêng tư được bảo toàn. Chúng tôi sẽ giải thích cách hoạt động vào lần tới.

Sebastian Bürgel,
Người sáng lập HOPR

Trang web: https://www.hoprnet.org

Twitter: https://twitter.com/hoprnet

Telegram: Telegram: Contact @hoprnet

Discord: hoprnet

LinkedIn: https:// www.linkedin.com/company/hoprnet

Diễn đàn: http://forum.hoprnet.org

Github: HOPR Association · GitHub

Các tập Cơ bản về HOPR trước đây:

Tập 1 : HOPR là gì?
Tập 2 : Siêu dữ liệu là gì?
Tập 3 : Định tuyến ẩn danh
Tập 4 : Mixnets
Tập 5 : Ưu đãi