Nostr 2.0 có thể xây dựng dựa trên Bitcoin dưới dạng Lớp 2, cung cấp khả năng lưu trữ dữ liệu ngoài chuỗi an toàn, giống như Lightning Network cung cấp các khoản thanh toán ngoài chuỗi ngay lập tức dưới dạng Lớp 2.
Bài viết này sẽ giải thích cách rơle Nostr đồng bộ hóa dữ liệu của nó trong khi vẫn duy trì tính chất nhẹ của nó, cho phép người dùng xóa dữ liệu có chọn lọc, điều không có sẵn trong các chuỗi khối Lớp 1. Đồng thời, so với việc lưu trữ một lượng lớn dữ liệu trong chuỗi khối Bitcoin, do dung lượng và tốc độ hạn chế của các khối Bitcoin, việc lưu trữ dữ liệu bằng cách sử dụng rơle Nostr có thể rẻ hơn.
Thiết kế khoa học máy tính đơn giản sau đây cải thiện các thuộc tính phân phối của mạng Nostr theo tiêu chí định lý CAP được tiêu chuẩn hóa. CAP là viết tắt của Tính nhất quán, Tính khả dụng và Dung sai phân vùng
**Nostr rơle không biết khi tệp cấu hình không đầy đủ, rơle thiếu tính nhất quán (C trong định lý CAP). **
Rơle thiếu tính nhất quán (C trong định lý CAP)
Tính nhất quán có nghĩa là các cơ sở dữ liệu được đồng bộ hóa trên mỗi máy tính đều giống nhau. Các rơle Nostr không thể thực hiện đồng bộ hóa tối thiểu hóa độ tin cậy theo cách tương tự như cách các chuỗi khối đồng bộ hóa từng khối dữ liệu của chúng. Không giống như các nút đầy đủ của Bitcoin, cơ sở dữ liệu được lưu trữ bởi chuyển tiếp Nostr thường không đầy đủ. Ngoài việc yêu cầu một cách mù quáng tất cả các bài đăng được ký bởi một người dùng cụ thể, Nostr relay không thể phát hiện ra dữ liệu bị thiếu.
Các vấn đề về tính nhất quán/đồng bộ hóa của Nostr:
Nếu hai người dùng tải các bài đăng tương ứng của họ lên các rơle Nostr khác nhau, hai người dùng đó có thể không nhìn thấy bài đăng của nhau vì Nostr không giống như một chuỗi khối. Trong chuỗi khối, mỗi khi có một bản ghi mới, tất cả các nút đầy đủ sẽ đồng bộ hóa chuỗi khối. Tất cả các nút đầy đủ sẽ thêm dữ liệu này dưới dạng một khối vào chuỗi khối của chúng cùng một lúc. Mọi nút đầy đủ trên chuỗi khối Bitcoin đều sở hữu cùng một chuỗi khối.
Nếu chúng tôi muốn người dùng Nostr luôn có thể nhìn thấy bài đăng của nhau, thì tất cả các chuyển tiếp Nostr cần có cách xác định dữ liệu bị thiếu trong hồ sơ người dùng để họ có thể yêu cầu các phần còn thiếu từ các chuyển tiếp Nostr hoặc người dùng khác.
Sử dụng gốc Merkle trên chuỗi hàng tuần và băm toàn bộ cây để đồng bộ hóa chuyển tiếp Nostr
Khoảng một lần một tuần, người dùng có thể sắp xếp tất cả các bài đăng của họ thành một cây Merkle.
Mỗi lá trong cây Merkle chứa hàm băm của một bài đăng, giống như mỗi lá trong Bitcoin chứa hàm băm của một giao dịch.
Sau khi người dùng đã tổ chức toàn bộ hồ sơ của họ thành cây Merkle, họ sẽ xuất bản gốc Merkle trong OP_RETURN trên chuỗi, bên dưới giao dịch Bitcoin thông thường. Đây là lý do tại sao Nostr 2.0 không yêu cầu hard fork của chuỗi khối để hoạt động. OP_RETURN là một phần bên dưới giao dịch Bitcoin cho phép thêm một ghi chú nhỏ trước chữ ký của người gửi.
Ngoài ra, người dùng sẽ băm toàn bộ cây và tải nó lên chuỗi cùng với gốc Merkle (trong OP_RETURN). Gốc Merkle chỉ là hàm băm của nhánh trên cùng, không phải toàn bộ cây. Hàm băm của toàn bộ cây là cần thiết để người dùng và người chuyển tiếp có thể phát hiện xem dữ liệu hồ sơ có bị thiếu hay không.
Để có được hàm băm của toàn bộ cây, hãy đặt gốc Merkle ở gốc của tệp văn bản. Sau đó, đặt nhánh Merkle trên dòng bên dưới gốc. Sau đó, đặt lá Merkle ở hàng bên dưới nhánh. Sau khi cây được sắp xếp như mô tả, hãy băm tất cả cùng một lúc. Dưới đây là một ví dụ về hàm băm toàn bộ cây về giao diện của hàm băm toàn bộ cây đối với cây Merkle được hiển thị ở trên. Băm toàn bộ cây (băm tất cả dữ liệu cây Merkle cùng một lúc)
Gốc Merkle và băm toàn bộ cây cung cấp hai chức năng chính:
Merkle root cho phép người dùng và người chuyển tiếp tải xuống một phần của tệp cấu hình tại một thời điểm, chẳng hạn như có thể tải xuống một giao dịch mà không phải tải xuống toàn bộ khối.
Băm toàn bộ cây cho phép người dùng và người chuyển tiếp biết nếu tệp cấu hình được lưu trữ của họ không đầy đủ. Không giống như gốc Merkle, toàn bộ hàm băm của cây sẽ chỉ khớp nếu bạn có tất cả các bit trong cây Merkle.
Phương pháp rẻ tiền này có thể được sử dụng để cập nhật toàn bộ tệp cấu hình theo tần suất hàng tuần hoặc do người dùng xác định. Nostr vẫn sẽ hoạt động như hiện tại, nhưng người dùng đôi khi có thể trả một số sats để đồng bộ hóa dữ liệu của họ giữa các chuyển tiếp Nostr nếu họ muốn tất cả người dùng nhìn thấy bài đăng của mình.
Người dùng và người chuyển tiếp có thể tải xuống các bài đăng cho một nhánh tại một thời điểm. Sau mỗi nhánh, họ băm nhánh đó với một nhánh khác gần gốc Merkle nhất để kiểm tra xem nó có khớp với gốc Merkle trên chuỗi không (tương tự như SPV). Nếu các nhánh đó băm với nhau để khớp với gốc Merkle, thì họ sẽ biết nhánh đó là một phần của hồ sơ người dùng, ngay cả khi họ chưa có hồ sơ người dùng đầy đủ. Người dùng có thể tải xuống các nhánh khác nhau của cùng một tệp cấu hình từ nhiều thân cây Nostr khác nhau, đồng thời xác minh tính hợp lệ của từng nhánh và đảm bảo rằng tệp cấu hình đã tải xuống hoàn tất.
Tải xuống từng nhánh một để ngăn chặn các cuộc tấn công trì hoãn có thể đánh sập nhiều mạng phân tán, đó là lý do tại sao gốc và nhánh Merkle được sử dụng trong sách trắng Bitcoin để bảo vệ ví nhẹ SPV.
**Tại sao gốc Merkle không thể hoạt động như băm toàn bộ cây? **
**Nếu rơle Nostr chỉ phụ thuộc vào gốc Merkle, thì chúng sẽ không thể biết khi nào cây Merkle hoàn thành, vì mọi cặp nhánh gần gốc Merkle nhất sẽ băm vào cùng một gốc Merkle. **
Để đảm bảo hồ sơ của người dùng hoàn tất, người chuyển tiếp hoặc người dùng sẽ băm toàn bộ cây Merkle đã cập nhật của họ và xác minh rằng nó khớp với toàn bộ cây băm trên chuỗi. Nếu toàn bộ giá trị băm của cây khớp với nhau thì dữ liệu người dùng đã hoàn tất. Nếu toàn bộ hàm băm của cây không khớp, thì một rơle hoặc người dùng có thể cho các rơle khác biết số lá mới nhất của họ và yêu cầu nhánh bị thiếu cho đến khi toàn bộ hàm băm của cây khớp. Để theo dõi tất cả các gốc Merkle mới được thêm vào mỗi tuần hoặc lâu hơn, các chuyển tiếp Nostr phải trở thành các nút đầy đủ của Bitcoin. Chuyển tiếp Nostr 2.0 được thanh toán gián tiếp để lưu trữ chuỗi khối Bitcoin đồng thời tăng cường tính bảo mật của Bitcoin và Nostr.
Giới hạn lưu trữ Nostr: Quy tắc ngón tay cái của người dùng
Vì những người chuyển tiếp có quyền chọn những gì sẽ lưu trữ, không giống như các nút đầy đủ của Bitcoin, nên những người chuyển tiếp Nostr có thể mất một số dữ liệu người dùng. Do đó, người dùng chỉ nên lưu trữ dữ liệu trên rơle Nostr, nếu người dùng có thể sao lưu cục bộ. Dịch vụ tự lưu trữ của Web5 cho phép người dùng đồng bộ hóa các bản sao lưu với tất cả các thiết bị cục bộ của họ, điều này sẽ giảm rủi ro cho những người dùng lo lắng về việc sử dụng Nostr. Vào cuối ngày, chỉ có blockchain là nơi dữ liệu thực sự bất biến. Điều đó nói rằng, Nostr là một giải pháp lai khá an toàn sẽ vẫn hoạt động tốt cho nhiều ứng dụng. Sự đánh đổi được liệt kê dưới đây:
Ba lớp giảm thiểu tin cậy
Bậc 1: Lưu trữ dữ liệu bất biến và đắt tiền, cực kỳ khó kiểm duyệt. (Các khối trên chuỗi đồng bộ hóa tất cả các nút đầy đủ của Bitcoin)
Bậc 2: Lưu trữ dữ liệu dễ thay đổi, giá rẻ, độ khó kiểm duyệt vừa phải. (cây Merkle ngoài chuỗi và hàm băm trên chuỗi, chuyển tiếp Nostr đồng bộ theo yêu cầu)
Lưu trữ dữ liệu cục bộ được đồng bộ hóa với tất cả các thiết bị cục bộ, dễ bị kiểm duyệt. (tập trung cục bộ)
Sự đánh đổi cơ bản giữa chuỗi khối dựa trên sự đồng thuận của Nakamoto và Nostr
**Càng nhiều rơle Nostr lưu trữ dữ liệu cho một địa chỉ cụ thể thì càng khó kiểm duyệt dữ liệu đó. Điều này có nghĩa là dữ liệu phổ biến được lưu trữ bởi nhiều rơle Nostr có thể khó kiểm duyệt hơn dữ liệu không phổ biến hiếm khi được tải xuống. **
**Mặt khác, chuỗi khối đồng thuận Nakamoto ngăn chặn kiểm duyệt dựa trên tuổi của dữ liệu. Dữ liệu tồn tại trong chuỗi khối càng lâu thì càng khó xóa dữ liệu đó bằng cuộc tấn công 51%. **
Vì chúng tôi có thể xác minh rằng một số nhánh nhất định thuộc về người dùng cụ thể, nên các chuyển tiếp Nostr có thể được trả tiền mỗi khi họ chuyển một phần dữ liệu nhỏ cho người dùng. Để đạt được điều này, người dùng cần tải xuống phần đầu của chuỗi khối (như trong SPV) để có thể thực hiện các chức năng điển hình của ví nhẹ. Người dùng sẽ tận dụng chức năng SPV của ví nhẹ để tìm nạp một giao dịch cụ thể từ chuỗi, giao dịch này sẽ bao gồm gốc Merkle của hồ sơ người dùng và toàn bộ hàm băm cây trong OP_RETURN của nó. Giờ đây, người dùng có thể trả phí chuyển tiếp để tải xuống từng nhánh hồ sơ của người dùng đó và xác minh từng nhánh bằng cách băm chúng để khớp với gốc Merkle trên chuỗi.
Để gửi sats (đơn vị nhỏ nhất của Bitcoin) đến rơle Nostr để đổi lấy việc cung cấp dữ liệu, chúng tôi sử dụng thiết kế ZKCP của Gregory Maxwell (nhà phát triển Bitcoin Core nổi tiếng) (Thanh toán có điều kiện bằng không kiến thức) [1] Phiên bản cải tiến của ZKCSP: Bằng chứng về khả năng truy xuất [2] Kết hợp với Lightning Network.
Theo mô tả của sách trắng ZKCSP:
"...không cần bên thứ ba đáng tin cậy...Chúng tôi cũng đã triển khai giao thức ZKCSP cho trường hợp bằng chứng về khả năng truy xuất, trong đó khách hàng trả tiền cho máy chủ để chứng minh rằng dữ liệu của khách hàng được lưu trữ chính xác trên máy chủ." [2]
Người dùng bắt đầu hợp đồng thông minh Lightning với một số nhà tài chính.
Người dùng gửi yêu cầu đến các nhà tài chính xung quanh. Nhà tài chính ký vào yêu cầu.
Người dùng gửi yêu cầu có chữ ký của các nhà tài chính trực tiếp tới rơle Nostr được kết nối với các nhà tài chính đó.
Người dùng hiện khởi tạo các cấu trúc ZKCSP để đảm bảo rằng các chuyển tiếp Nostr chỉ được thanh toán từ các nhà tài chính sau khi dữ liệu được yêu cầu chính xác được gửi đi.
Sau khi bước 3 diễn ra, người dùng sẽ thực hiện các sửa đổi trên yêu cầu ban đầu được ký bởi nhà tài chính trước khi bắt đầu xây dựng ZKCSP ở bước 4. Người dùng sẽ thêm một khoản bổ sung vào yêu cầu ban đầu, chỉ định số tiền được khấu trừ từ số dư của cả người dùng và nhà tài chính (chúng phải bằng nhau, cộng với phí của nhà tài chính), sau đó người dùng sẽ thêm vào tin nhắn gốc nội dung ký.
**Nếu người dùng chỉ định gửi nhiều sats hơn họ sở hữu hoặc nhiều hơn số sats mà nhà tài chính đã đóng băng trên chuyển tiếp Nostr đó, thì chuyển tiếp Nostr sẽ từ chối yêu cầu vì chuyển tiếp sẽ không thể được thanh toán. **
Bằng cách này, người dùng có thể kết nối với nhiều rơle Nostr trong khi đóng băng tiền của họ chỉ với một số nhà tài trợ. Một cách tiếp cận tương tự có thể được thực hiện với Lightning Network, nơi các nhà tài chính giảm thiểu sự tin cậy là trung gian không được phép giữa người dùng và người bán. Các bước nhảy chớp nhoáng P2P thông thường cũng có sẵn trong Nostr 2.0, nhưng điều này có thể hữu ích nếu việc định tuyến và cân bằng kênh thường xuyên bị lỗi.
Danh sách trắng Mở khóa Rơle Nostr trả phí
Rơle Nostr có thể đưa vào danh sách trắng một số khóa nhất định nếu chúng muốn lưu trữ dữ liệu được xem bởi tất cả những người dùng này. Nếu rơle Nostr không thể đưa người dùng vào danh sách trắng muốn lưu trữ dữ liệu, họ sẽ lưu trữ bất kỳ dữ liệu nào được gửi cho họ. Nếu người dùng luôn có thể gửi dữ liệu đến rơle miễn phí, thì người dùng sẽ không bao giờ phải trả tiền cho rơle Nostr. Nostr chỉ có thể cung cấp các tùy chọn trả phí nếu người chuyển tiếp có tùy chọn từ chối lưu trữ dữ liệu không thể trả phí. Rơle miễn phí vẫn tồn tại, nhưng tùy chọn cho rơle trả phí hiện không tồn tại.
Thay vì cố gắng lưu trữ miễn phí tất cả dữ liệu Nostr, chuyển tiếp Nostr trả phí có thể sử dụng danh sách trắng để lưu trữ có chọn lọc tất cả dữ liệu mà người dùng trả phí xem hàng ngày. Một số rơle Nostr sẽ tiếp tục hoạt động theo mô hình miễn phí, nhưng ở quy mô lớn nhất, điều này không bền vững vì hầu hết các rơle miễn phí chỉ là những người đam mê nhiệt tình. Việc lập danh sách trắng (ngay cả khi chúng tôi có thể chỉ định khóa công khai một cách an toàn cho từng cấu hình Nostr) mang lại cho chuyển tiếp Nostr khả năng quyết định dữ liệu nào sẽ lưu trữ sẽ không thể thực hiện được.
Một khóa công khai trên mỗi hồ sơ sẽ mở khóa tính năng danh sách trắng: địa chỉ Bitcoin trở thành khóa công khai Nostr của bạn.
Cuối cùng, hệ thống này cho phép chúng tôi gán khóa chung cho từng tệp cấu hình.
Không có lợi ích gì khi người dùng tạo khóa công khai mới cho mỗi bài đăng... vì tất cả chúng đều được liên kết với hồ sơ của họ! Địa chỉ này không giống với địa chỉ Bitcoin. Không giống như Bitcoin, việc người dùng có nhiều khóa công khai trong cùng một ứng dụng không cải thiện quyền riêng tư.
**Khóa chung của hồ sơ Nostr phải khớp với khóa chung của giao dịch Bitcoin chứa hàm băm hàng tuần (gốc Merkle của tất cả các bài đăng của người dùng và toàn bộ hàm băm của cây). Không giống như người dùng Nostr sử dụng chữ ký Schnorr, họ sẽ cần sử dụng ví Bitcoin (ví di động/ví nhẹ hoặc nút đầy đủ) để ký. **
Cái hay của điều này là mỗi tài khoản Nostr sẽ được đại diện bởi địa chỉ Bitcoin của nó,** có nghĩa là người dùng có thể gửi thanh toán trực tiếp đến tài khoản Nostr mà không cần yêu cầu hai khóa công khai khác nhau. Điều này làm giảm chi phí nhận thức của người dùng mới trong hệ thống. Thay vì sử dụng tên người dùng, người dùng vẫn cần gửi cho nhau khóa công khai hoặc DNS để tìm thấy nhau trên Nostr. **
Nếu các ứng dụng Nostr khác sử dụng các khóa công khai khác nhau, chúng vẫn có thể được gắn vào cùng một danh tính phi tập trung (DID) - theo cách này, cách tài khoản của bạn được xác định vẫn nhất quán giữa các ứng dụng. Tuy nhiên, quy tắc đồng thuận Nostr này sẽ giới hạn việc chỉ sử dụng một khóa công khai cho mỗi hồ sơ trên mỗi ứng dụng Nostr.
DHT hoạt động như một bảng xếp hạng để khám phá bạn bè.
Rơle có thể sử dụng Bảng băm phân tán (DHT) để tìm các Rơle khác. Rơle có thể chia sẻ danh sách trắng của chúng trong bảng băm phân tán bằng cách liệt kê khóa chung nơi dữ liệu được lưu trữ. Bằng cách này, các rơle bị thiếu các nhánh dữ liệu cho một khóa chung nhất định có thể quét DHT và kết nối trực tiếp với địa chỉ IP của các rơle khác yêu cầu lưu trữ các nhánh bị thiếu đó. Sau đó, các rơle có thể tải xuống các nhánh bị thiếu trực tiếp từ các rơle Nostr này.
Người chuyển tiếp cũng sẽ có thể tìm thấy những người chuyển tiếp tích cực nhất bằng cách kiểm tra xem có bao nhiêu giao dịch ZKCSP trước đó mà những người chuyển tiếp đó đã giải quyết trên chuỗi - gần đây và mọi lúc. Trong hệ thống này, tất cả các rơle Nostr đều trở thành các nút đầy đủ, vì vậy việc kiểm tra các giao dịch trước đó của các rơle khác sẽ không gây khó khăn. Điều này sẽ khiến việc giả mạo niềm tin trở nên tốn kém, vì các giao dịch trực tuyến luôn yêu cầu phí giao dịch. Nếu một rơle Nostr mở nhiều kênh để tạo niềm tin với chính mình nhằm lấy lòng tin của các rơle khác, anh ta sẽ phải trả rất nhiều phí giao dịch để duy trì danh tiếng giả hàng tuần. Sau khi kẻ tấn công không cung cấp được nhánh bị thiếu, thời gian chờ sẽ khiến rơle ngắt kết nối - vì vậy đây chỉ là một cuộc tấn công tạm thời, tốn kém (giống như một cuộc tấn công 51% là một cuộc tấn công tạm thời, tốn kém).
DHT không ẩn danh như khai thác, vì mỗi khóa công khai của rơle Nostr sẽ được liệt kê bên cạnh địa chỉ IP trong DHT, nhưng nó sẽ tránh được việc rơle gửi yêu cầu một cách mù quáng qua mạng - ở quy mô đủ lớn, điều này sẽ làm quá tải mạng. Những người chuyển tiếp Nostr đang tìm kiếm quyền riêng tư hơn có thể sử dụng VPN hoặc dịch vụ bảo vệ IP khác.
Người dùng sẽ không có quyền truy cập vào cùng một hệ thống tin cậy này vì họ không phải là các nút đầy đủ. Tuy nhiên, người dùng có thể dựa vào nó.
Người hâm mộ được kết nối gián tiếp với hàng trăm rơle Nostr
Vì người dùng tự động lưu trữ tất cả các tiêu đề khối trong ví nhẹ của họ, nên người dùng có thể biết ai là người khai thác tích cực nhất. Những người khai thác trở thành nhà đầu tư tài chính sẽ cho phép người dùng lọc ra những người khai thác phổ biến nhất để họ không phải ràng buộc tiền một cách mù quáng với những nhà đầu tư tài chính ngẫu nhiên không có mối tương quan với khả năng tồn tại của mạng.
**Các nhà tài chính (thợ mỏ) chỉ cần khóa sats của họ bằng rơle Nostr mà không cần truyền dữ liệu giữa người dùng và rơle. **Nhà tài chính (thợ mỏ) chỉ cần ký vào yêu cầu của người dùng là người dùng có thể tương tác trực tiếp với tất cả các rơle Nostr mà nhà tài chính đã kết nối - 4 bước cho ZKCSP+Lightning như trên.
Tóm lại là
Mạng Lightning sẽ không tồn tại nếu không có chuỗi khối đồng thuận Nakamoto của Bitcoin, vì người dùng sẽ không có nơi nào để lưu trữ bằng chứng đi kèm về các giao dịch ngoài chuỗi của họ.
Giống như người dùng gộp tất cả các giao dịch Lightning Network này lại với nhau và đưa các bằng chứng nhỏ vào chuỗi khối, chúng tôi sẽ gộp tất cả dữ liệu Nostr và đưa các bằng chứng nhỏ vào chuỗi khối. Cũng giống như cách Lightning Network cung cấp thanh toán tức thì ở lớp thứ hai, Nostr có thể cung cấp lưu trữ dữ liệu ở lớp thứ hai mà không gặp rủi ro về chuỗi bên không an toàn. **
**Nó sử dụng cách tiếp cận tương tự như Lightning Network, với chuỗi khối đồng thuận Nakamoto của Bitcoin ở lớp đầu tiên và Nostr+ZKCSP Lightning ở lớp thứ hai. **
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Nostr2.0: là lớp lưu trữ dữ liệu trong chuỗi Bitcoin Lớp 2
Tác giả: Colby Serpa Biên dịch: DAOrayaki
Nostr 2.0 có thể xây dựng dựa trên Bitcoin dưới dạng Lớp 2, cung cấp khả năng lưu trữ dữ liệu ngoài chuỗi an toàn, giống như Lightning Network cung cấp các khoản thanh toán ngoài chuỗi ngay lập tức dưới dạng Lớp 2.
Bài viết này sẽ giải thích cách rơle Nostr đồng bộ hóa dữ liệu của nó trong khi vẫn duy trì tính chất nhẹ của nó, cho phép người dùng xóa dữ liệu có chọn lọc, điều không có sẵn trong các chuỗi khối Lớp 1. Đồng thời, so với việc lưu trữ một lượng lớn dữ liệu trong chuỗi khối Bitcoin, do dung lượng và tốc độ hạn chế của các khối Bitcoin, việc lưu trữ dữ liệu bằng cách sử dụng rơle Nostr có thể rẻ hơn.
Thiết kế khoa học máy tính đơn giản sau đây cải thiện các thuộc tính phân phối của mạng Nostr theo tiêu chí định lý CAP được tiêu chuẩn hóa. CAP là viết tắt của Tính nhất quán, Tính khả dụng và Dung sai phân vùng
**Nostr rơle không biết khi tệp cấu hình không đầy đủ, rơle thiếu tính nhất quán (C trong định lý CAP). **
Rơle thiếu tính nhất quán (C trong định lý CAP)
Tính nhất quán có nghĩa là các cơ sở dữ liệu được đồng bộ hóa trên mỗi máy tính đều giống nhau. Các rơle Nostr không thể thực hiện đồng bộ hóa tối thiểu hóa độ tin cậy theo cách tương tự như cách các chuỗi khối đồng bộ hóa từng khối dữ liệu của chúng. Không giống như các nút đầy đủ của Bitcoin, cơ sở dữ liệu được lưu trữ bởi chuyển tiếp Nostr thường không đầy đủ. Ngoài việc yêu cầu một cách mù quáng tất cả các bài đăng được ký bởi một người dùng cụ thể, Nostr relay không thể phát hiện ra dữ liệu bị thiếu.
Các vấn đề về tính nhất quán/đồng bộ hóa của Nostr:
Nếu hai người dùng tải các bài đăng tương ứng của họ lên các rơle Nostr khác nhau, hai người dùng đó có thể không nhìn thấy bài đăng của nhau vì Nostr không giống như một chuỗi khối. Trong chuỗi khối, mỗi khi có một bản ghi mới, tất cả các nút đầy đủ sẽ đồng bộ hóa chuỗi khối. Tất cả các nút đầy đủ sẽ thêm dữ liệu này dưới dạng một khối vào chuỗi khối của chúng cùng một lúc. Mọi nút đầy đủ trên chuỗi khối Bitcoin đều sở hữu cùng một chuỗi khối.
Nếu chúng tôi muốn người dùng Nostr luôn có thể nhìn thấy bài đăng của nhau, thì tất cả các chuyển tiếp Nostr cần có cách xác định dữ liệu bị thiếu trong hồ sơ người dùng để họ có thể yêu cầu các phần còn thiếu từ các chuyển tiếp Nostr hoặc người dùng khác.
Sử dụng gốc Merkle trên chuỗi hàng tuần và băm toàn bộ cây để đồng bộ hóa chuyển tiếp Nostr
Gốc Merkle và băm toàn bộ cây cung cấp hai chức năng chính:
Phương pháp rẻ tiền này có thể được sử dụng để cập nhật toàn bộ tệp cấu hình theo tần suất hàng tuần hoặc do người dùng xác định. Nostr vẫn sẽ hoạt động như hiện tại, nhưng người dùng đôi khi có thể trả một số sats để đồng bộ hóa dữ liệu của họ giữa các chuyển tiếp Nostr nếu họ muốn tất cả người dùng nhìn thấy bài đăng của mình.
Người dùng và người chuyển tiếp có thể tải xuống các bài đăng cho một nhánh tại một thời điểm. Sau mỗi nhánh, họ băm nhánh đó với một nhánh khác gần gốc Merkle nhất để kiểm tra xem nó có khớp với gốc Merkle trên chuỗi không (tương tự như SPV). Nếu các nhánh đó băm với nhau để khớp với gốc Merkle, thì họ sẽ biết nhánh đó là một phần của hồ sơ người dùng, ngay cả khi họ chưa có hồ sơ người dùng đầy đủ. Người dùng có thể tải xuống các nhánh khác nhau của cùng một tệp cấu hình từ nhiều thân cây Nostr khác nhau, đồng thời xác minh tính hợp lệ của từng nhánh và đảm bảo rằng tệp cấu hình đã tải xuống hoàn tất.
Tải xuống từng nhánh một để ngăn chặn các cuộc tấn công trì hoãn có thể đánh sập nhiều mạng phân tán, đó là lý do tại sao gốc và nhánh Merkle được sử dụng trong sách trắng Bitcoin để bảo vệ ví nhẹ SPV.
**Tại sao gốc Merkle không thể hoạt động như băm toàn bộ cây? **
**Nếu rơle Nostr chỉ phụ thuộc vào gốc Merkle, thì chúng sẽ không thể biết khi nào cây Merkle hoàn thành, vì mọi cặp nhánh gần gốc Merkle nhất sẽ băm vào cùng một gốc Merkle. **
Để đảm bảo hồ sơ của người dùng hoàn tất, người chuyển tiếp hoặc người dùng sẽ băm toàn bộ cây Merkle đã cập nhật của họ và xác minh rằng nó khớp với toàn bộ cây băm trên chuỗi. Nếu toàn bộ giá trị băm của cây khớp với nhau thì dữ liệu người dùng đã hoàn tất. Nếu toàn bộ hàm băm của cây không khớp, thì một rơle hoặc người dùng có thể cho các rơle khác biết số lá mới nhất của họ và yêu cầu nhánh bị thiếu cho đến khi toàn bộ hàm băm của cây khớp. Để theo dõi tất cả các gốc Merkle mới được thêm vào mỗi tuần hoặc lâu hơn, các chuyển tiếp Nostr phải trở thành các nút đầy đủ của Bitcoin. Chuyển tiếp Nostr 2.0 được thanh toán gián tiếp để lưu trữ chuỗi khối Bitcoin đồng thời tăng cường tính bảo mật của Bitcoin và Nostr.
Giới hạn lưu trữ Nostr: Quy tắc ngón tay cái của người dùng
Vì những người chuyển tiếp có quyền chọn những gì sẽ lưu trữ, không giống như các nút đầy đủ của Bitcoin, nên những người chuyển tiếp Nostr có thể mất một số dữ liệu người dùng. Do đó, người dùng chỉ nên lưu trữ dữ liệu trên rơle Nostr, nếu người dùng có thể sao lưu cục bộ. Dịch vụ tự lưu trữ của Web5 cho phép người dùng đồng bộ hóa các bản sao lưu với tất cả các thiết bị cục bộ của họ, điều này sẽ giảm rủi ro cho những người dùng lo lắng về việc sử dụng Nostr. Vào cuối ngày, chỉ có blockchain là nơi dữ liệu thực sự bất biến. Điều đó nói rằng, Nostr là một giải pháp lai khá an toàn sẽ vẫn hoạt động tốt cho nhiều ứng dụng. Sự đánh đổi được liệt kê dưới đây:
Ba lớp giảm thiểu tin cậy
Sự đánh đổi cơ bản giữa chuỗi khối dựa trên sự đồng thuận của Nakamoto và Nostr
**Càng nhiều rơle Nostr lưu trữ dữ liệu cho một địa chỉ cụ thể thì càng khó kiểm duyệt dữ liệu đó. Điều này có nghĩa là dữ liệu phổ biến được lưu trữ bởi nhiều rơle Nostr có thể khó kiểm duyệt hơn dữ liệu không phổ biến hiếm khi được tải xuống. **
**Mặt khác, chuỗi khối đồng thuận Nakamoto ngăn chặn kiểm duyệt dựa trên tuổi của dữ liệu. Dữ liệu tồn tại trong chuỗi khối càng lâu thì càng khó xóa dữ liệu đó bằng cuộc tấn công 51%. **
Vì chúng tôi có thể xác minh rằng một số nhánh nhất định thuộc về người dùng cụ thể, nên các chuyển tiếp Nostr có thể được trả tiền mỗi khi họ chuyển một phần dữ liệu nhỏ cho người dùng. Để đạt được điều này, người dùng cần tải xuống phần đầu của chuỗi khối (như trong SPV) để có thể thực hiện các chức năng điển hình của ví nhẹ. Người dùng sẽ tận dụng chức năng SPV của ví nhẹ để tìm nạp một giao dịch cụ thể từ chuỗi, giao dịch này sẽ bao gồm gốc Merkle của hồ sơ người dùng và toàn bộ hàm băm cây trong OP_RETURN của nó. Giờ đây, người dùng có thể trả phí chuyển tiếp để tải xuống từng nhánh hồ sơ của người dùng đó và xác minh từng nhánh bằng cách băm chúng để khớp với gốc Merkle trên chuỗi.
Để gửi sats (đơn vị nhỏ nhất của Bitcoin) đến rơle Nostr để đổi lấy việc cung cấp dữ liệu, chúng tôi sử dụng thiết kế ZKCP của Gregory Maxwell (nhà phát triển Bitcoin Core nổi tiếng) (Thanh toán có điều kiện bằng không kiến thức) [1] Phiên bản cải tiến của ZKCSP: Bằng chứng về khả năng truy xuất [2] Kết hợp với Lightning Network.
Theo mô tả của sách trắng ZKCSP:
"...không cần bên thứ ba đáng tin cậy...Chúng tôi cũng đã triển khai giao thức ZKCSP cho trường hợp bằng chứng về khả năng truy xuất, trong đó khách hàng trả tiền cho máy chủ để chứng minh rằng dữ liệu của khách hàng được lưu trữ chính xác trên máy chủ." [2]
Sau khi bước 3 diễn ra, người dùng sẽ thực hiện các sửa đổi trên yêu cầu ban đầu được ký bởi nhà tài chính trước khi bắt đầu xây dựng ZKCSP ở bước 4. Người dùng sẽ thêm một khoản bổ sung vào yêu cầu ban đầu, chỉ định số tiền được khấu trừ từ số dư của cả người dùng và nhà tài chính (chúng phải bằng nhau, cộng với phí của nhà tài chính), sau đó người dùng sẽ thêm vào tin nhắn gốc nội dung ký.
**Nếu người dùng chỉ định gửi nhiều sats hơn họ sở hữu hoặc nhiều hơn số sats mà nhà tài chính đã đóng băng trên chuyển tiếp Nostr đó, thì chuyển tiếp Nostr sẽ từ chối yêu cầu vì chuyển tiếp sẽ không thể được thanh toán. **
Bằng cách này, người dùng có thể kết nối với nhiều rơle Nostr trong khi đóng băng tiền của họ chỉ với một số nhà tài trợ. Một cách tiếp cận tương tự có thể được thực hiện với Lightning Network, nơi các nhà tài chính giảm thiểu sự tin cậy là trung gian không được phép giữa người dùng và người bán. Các bước nhảy chớp nhoáng P2P thông thường cũng có sẵn trong Nostr 2.0, nhưng điều này có thể hữu ích nếu việc định tuyến và cân bằng kênh thường xuyên bị lỗi.
Danh sách trắng Mở khóa Rơle Nostr trả phí
Rơle Nostr có thể đưa vào danh sách trắng một số khóa nhất định nếu chúng muốn lưu trữ dữ liệu được xem bởi tất cả những người dùng này. Nếu rơle Nostr không thể đưa người dùng vào danh sách trắng muốn lưu trữ dữ liệu, họ sẽ lưu trữ bất kỳ dữ liệu nào được gửi cho họ. Nếu người dùng luôn có thể gửi dữ liệu đến rơle miễn phí, thì người dùng sẽ không bao giờ phải trả tiền cho rơle Nostr. Nostr chỉ có thể cung cấp các tùy chọn trả phí nếu người chuyển tiếp có tùy chọn từ chối lưu trữ dữ liệu không thể trả phí. Rơle miễn phí vẫn tồn tại, nhưng tùy chọn cho rơle trả phí hiện không tồn tại.
Thay vì cố gắng lưu trữ miễn phí tất cả dữ liệu Nostr, chuyển tiếp Nostr trả phí có thể sử dụng danh sách trắng để lưu trữ có chọn lọc tất cả dữ liệu mà người dùng trả phí xem hàng ngày. Một số rơle Nostr sẽ tiếp tục hoạt động theo mô hình miễn phí, nhưng ở quy mô lớn nhất, điều này không bền vững vì hầu hết các rơle miễn phí chỉ là những người đam mê nhiệt tình. Việc lập danh sách trắng (ngay cả khi chúng tôi có thể chỉ định khóa công khai một cách an toàn cho từng cấu hình Nostr) mang lại cho chuyển tiếp Nostr khả năng quyết định dữ liệu nào sẽ lưu trữ sẽ không thể thực hiện được.
Một khóa công khai trên mỗi hồ sơ sẽ mở khóa tính năng danh sách trắng: địa chỉ Bitcoin trở thành khóa công khai Nostr của bạn.
Cuối cùng, hệ thống này cho phép chúng tôi gán khóa chung cho từng tệp cấu hình.
Không có lợi ích gì khi người dùng tạo khóa công khai mới cho mỗi bài đăng... vì tất cả chúng đều được liên kết với hồ sơ của họ! Địa chỉ này không giống với địa chỉ Bitcoin. Không giống như Bitcoin, việc người dùng có nhiều khóa công khai trong cùng một ứng dụng không cải thiện quyền riêng tư.
**Khóa chung của hồ sơ Nostr phải khớp với khóa chung của giao dịch Bitcoin chứa hàm băm hàng tuần (gốc Merkle của tất cả các bài đăng của người dùng và toàn bộ hàm băm của cây). Không giống như người dùng Nostr sử dụng chữ ký Schnorr, họ sẽ cần sử dụng ví Bitcoin (ví di động/ví nhẹ hoặc nút đầy đủ) để ký. **
Cái hay của điều này là mỗi tài khoản Nostr sẽ được đại diện bởi địa chỉ Bitcoin của nó,** có nghĩa là người dùng có thể gửi thanh toán trực tiếp đến tài khoản Nostr mà không cần yêu cầu hai khóa công khai khác nhau. Điều này làm giảm chi phí nhận thức của người dùng mới trong hệ thống. Thay vì sử dụng tên người dùng, người dùng vẫn cần gửi cho nhau khóa công khai hoặc DNS để tìm thấy nhau trên Nostr. **
Nếu các ứng dụng Nostr khác sử dụng các khóa công khai khác nhau, chúng vẫn có thể được gắn vào cùng một danh tính phi tập trung (DID) - theo cách này, cách tài khoản của bạn được xác định vẫn nhất quán giữa các ứng dụng. Tuy nhiên, quy tắc đồng thuận Nostr này sẽ giới hạn việc chỉ sử dụng một khóa công khai cho mỗi hồ sơ trên mỗi ứng dụng Nostr.
DHT hoạt động như một bảng xếp hạng để khám phá bạn bè.
Rơle có thể sử dụng Bảng băm phân tán (DHT) để tìm các Rơle khác. Rơle có thể chia sẻ danh sách trắng của chúng trong bảng băm phân tán bằng cách liệt kê khóa chung nơi dữ liệu được lưu trữ. Bằng cách này, các rơle bị thiếu các nhánh dữ liệu cho một khóa chung nhất định có thể quét DHT và kết nối trực tiếp với địa chỉ IP của các rơle khác yêu cầu lưu trữ các nhánh bị thiếu đó. Sau đó, các rơle có thể tải xuống các nhánh bị thiếu trực tiếp từ các rơle Nostr này.
Người chuyển tiếp cũng sẽ có thể tìm thấy những người chuyển tiếp tích cực nhất bằng cách kiểm tra xem có bao nhiêu giao dịch ZKCSP trước đó mà những người chuyển tiếp đó đã giải quyết trên chuỗi - gần đây và mọi lúc. Trong hệ thống này, tất cả các rơle Nostr đều trở thành các nút đầy đủ, vì vậy việc kiểm tra các giao dịch trước đó của các rơle khác sẽ không gây khó khăn. Điều này sẽ khiến việc giả mạo niềm tin trở nên tốn kém, vì các giao dịch trực tuyến luôn yêu cầu phí giao dịch. Nếu một rơle Nostr mở nhiều kênh để tạo niềm tin với chính mình nhằm lấy lòng tin của các rơle khác, anh ta sẽ phải trả rất nhiều phí giao dịch để duy trì danh tiếng giả hàng tuần. Sau khi kẻ tấn công không cung cấp được nhánh bị thiếu, thời gian chờ sẽ khiến rơle ngắt kết nối - vì vậy đây chỉ là một cuộc tấn công tạm thời, tốn kém (giống như một cuộc tấn công 51% là một cuộc tấn công tạm thời, tốn kém).
DHT không ẩn danh như khai thác, vì mỗi khóa công khai của rơle Nostr sẽ được liệt kê bên cạnh địa chỉ IP trong DHT, nhưng nó sẽ tránh được việc rơle gửi yêu cầu một cách mù quáng qua mạng - ở quy mô đủ lớn, điều này sẽ làm quá tải mạng. Những người chuyển tiếp Nostr đang tìm kiếm quyền riêng tư hơn có thể sử dụng VPN hoặc dịch vụ bảo vệ IP khác.
Người dùng sẽ không có quyền truy cập vào cùng một hệ thống tin cậy này vì họ không phải là các nút đầy đủ. Tuy nhiên, người dùng có thể dựa vào nó.
Người hâm mộ được kết nối gián tiếp với hàng trăm rơle Nostr
Vì người dùng tự động lưu trữ tất cả các tiêu đề khối trong ví nhẹ của họ, nên người dùng có thể biết ai là người khai thác tích cực nhất. Những người khai thác trở thành nhà đầu tư tài chính sẽ cho phép người dùng lọc ra những người khai thác phổ biến nhất để họ không phải ràng buộc tiền một cách mù quáng với những nhà đầu tư tài chính ngẫu nhiên không có mối tương quan với khả năng tồn tại của mạng.
**Các nhà tài chính (thợ mỏ) chỉ cần khóa sats của họ bằng rơle Nostr mà không cần truyền dữ liệu giữa người dùng và rơle. **Nhà tài chính (thợ mỏ) chỉ cần ký vào yêu cầu của người dùng là người dùng có thể tương tác trực tiếp với tất cả các rơle Nostr mà nhà tài chính đã kết nối - 4 bước cho ZKCSP+Lightning như trên.
Tóm lại là
Mạng Lightning sẽ không tồn tại nếu không có chuỗi khối đồng thuận Nakamoto của Bitcoin, vì người dùng sẽ không có nơi nào để lưu trữ bằng chứng đi kèm về các giao dịch ngoài chuỗi của họ.
Giống như người dùng gộp tất cả các giao dịch Lightning Network này lại với nhau và đưa các bằng chứng nhỏ vào chuỗi khối, chúng tôi sẽ gộp tất cả dữ liệu Nostr và đưa các bằng chứng nhỏ vào chuỗi khối. Cũng giống như cách Lightning Network cung cấp thanh toán tức thì ở lớp thứ hai, Nostr có thể cung cấp lưu trữ dữ liệu ở lớp thứ hai mà không gặp rủi ro về chuỗi bên không an toàn. **
**Nó sử dụng cách tiếp cận tương tự như Lightning Network, với chuỗi khối đồng thuận Nakamoto của Bitcoin ở lớp đầu tiên và Nostr+ZKCSP Lightning ở lớp thứ hai. **