Nostr 2.0 mungkin dapat dibangun di atas Bitcoin sebagai Lapisan 2, menyediakan penyimpanan data off-chain yang aman, sama seperti Lightning Network menyediakan pembayaran off-chain instan sebagai Lapisan 2.
Artikel ini akan menjelaskan bagaimana relai Nostr menyinkronkan datanya sambil mempertahankan sifatnya yang ringan, memungkinkan pengguna untuk menghapus data secara selektif, yang tidak tersedia di blockchain Lapisan 1. Pada saat yang sama, dibandingkan dengan menyimpan data dalam jumlah besar di blockchain Bitcoin, karena kapasitas dan kecepatan blok Bitcoin yang terbatas, mungkin lebih murah untuk menyimpan data menggunakan relai Nostr.
Desain ilmu komputer sederhana berikut meningkatkan sifat distribusi jaringan Nostr di bawah kriteria teorema CAP standar. CAP adalah singkatan dari Konsistensi, Ketersediaan, dan Toleransi partisi
**Relai Nostr tidak mengetahui kapan file konfigurasi tidak lengkap, relai kurang konsisten (C dalam teorema CAP). **
Relai tidak memiliki konsistensi (C dalam teorema CAP)
Konsistensi berarti database yang disinkronkan pada setiap komputer adalah sama. Relai Nostr tidak dapat melakukan sinkronisasi yang diminimalkan kepercayaan dengan cara yang mirip dengan cara blockchain menyinkronkan data mereka blok demi blok. Tidak seperti node penuh Bitcoin, database yang disimpan oleh relai Nostr biasanya tidak lengkap. Selain secara membabi buta meminta semua posting yang ditandatangani oleh pengguna tertentu, relai Nostr tidak dapat menemukan data yang hilang.
Masalah Konsistensi/Sinkronisasi Nostr:
Jika dua pengguna mengunggah postingan mereka masing-masing ke relai Nostr yang berbeda, kedua pengguna tersebut mungkin tidak dapat melihat postingan satu sama lain karena Nostr tidak seperti blockchain. Di blockchain, setiap kali ada rekor baru, semua node penuh akan menyinkronkan blockchain. Semua node penuh akan menambahkan data ini sebagai blok ke blockchain mereka secara bersamaan. Setiap node penuh pada blockchain Bitcoin memiliki blockchain yang sama persis.
Jika kami ingin pengguna Nostr selalu dapat melihat kiriman satu sama lain, maka semua relai Nostr memerlukan cara untuk mengidentifikasi data yang hilang di profil pengguna sehingga mereka dapat meminta bagian yang hilang dari relai atau pengguna Nostr lain.
Gunakan root Merkle on-chain mingguan dan hash pohon penuh untuk menyinkronkan relai Nostr
Sekitar seminggu sekali, pengguna dapat mengatur semua postingan mereka ke dalam pohon Merkle.
Setiap daun di pohon Merkle berisi hash dari sebuah postingan, sama seperti setiap daun di Bitcoin berisi hash dari sebuah transaksi.
Setelah pengguna mengatur seluruh profil mereka ke dalam pohon Merkle, mereka akan menerbitkan root Merkle di OP_RETURN on-chain, di bawah transaksi Bitcoin normal. Inilah mengapa Nostr 2.0 tidak membutuhkan hard fork dari blockchain untuk bekerja. OP_RETURN adalah bagian di bawah transaksi Bitcoin yang memungkinkan catatan kecil ditambahkan sebelum tanda tangan pengirim.
Selain itu, pengguna akan mencirikan seluruh pohon dan mengunggahnya ke rantai bersama dengan akar Merkle (di OP_RETURN). Akar Merkle hanyalah hash dari cabang teratas, bukan seluruh pohon. Hash dari keseluruhan pohon sangat penting bagi pengguna dan penyalur untuk dapat mendeteksi jika data profil hilang.
Untuk mendapatkan hash dari seluruh pohon, tempatkan root Merkle di root file teks. Kemudian, letakkan cabang Merkle pada baris di bawah root. Kemudian, letakkan daun Merkle pada baris di bawah cabang. Setelah pohon diatur seperti yang dijelaskan, hash semuanya sekaligus. Di bawah ini adalah contoh seluruh hash pohon seperti apa bentuk seluruh hash pohon untuk pohon Merkle yang ditunjukkan di atas. Seluruh pohon hashing (hashing semua data pohon Merkle sekaligus)
Merkle root dan whole tree hash menyediakan dua fungsi utama:
Akar Merkle memungkinkan pengguna dan penyampai untuk mengunduh sebagian file konfigurasi sekaligus, seperti dapat mengunduh transaksi tanpa harus mengunduh seluruh blok.
Seluruh pohon hashing memungkinkan pengguna dan penyalur mengetahui jika file konfigurasi yang disimpan tidak lengkap. Tidak seperti akar Merkle, seluruh hash pohon hanya akan cocok jika Anda memiliki semua bit di pohon Merkle.
Metode murah ini dapat digunakan untuk memperbarui seluruh file konfigurasi pada frekuensi mingguan atau yang ditentukan pengguna. Nostr akan tetap berfungsi seperti sekarang, tetapi pengguna kadang-kadang dapat membayar sejumlah sat untuk menyinkronkan data mereka antara relai Nostr jika ingin postingan mereka dilihat oleh semua pengguna.
Pengguna dan penyalur dapat mengunduh kiriman untuk satu cabang dalam satu waktu. Setelah setiap cabang, mereka melakukan hash pada cabang tersebut dengan cabang lain yang paling dekat dengan akar Merkle untuk memeriksa apakah cocok dengan akar Merkle pada rantai (mirip dengan SPV). Jika cabang-cabang itu digabungkan untuk mencocokkan root Merkle, mereka akan tahu bahwa cabang itu adalah bagian dari profil pengguna, bahkan jika mereka belum memiliki profil pengguna lengkap. Pengguna dapat mengunduh cabang berbeda dari file konfigurasi yang sama dari banyak batang Nostr yang berbeda, sambil memverifikasi validitas setiap cabang dan memastikan bahwa file konfigurasi yang diunduh selesai.
Mengunduh garpu satu per satu mencegah serangan tunda yang dapat melumpuhkan banyak jaringan terdistribusi, itulah sebabnya akar dan garpu Merkle digunakan dalam kertas putih Bitcoin untuk melindungi dompet ringan SPV.
**Mengapa akar Merkle tidak dapat berfungsi seperti seluruh hash pohon? **
**Jika relai Nostr hanya bergantung pada akar Merkle, mereka tidak akan dapat mengetahui kapan pohon Merkle selesai, karena setiap pasangan cabang yang paling dekat dengan akar Merkle akan di-hash ke dalam akar Merkle yang sama. **
Untuk memastikan profil pengguna sudah lengkap, relayer atau pengguna akan melakukan hash pada seluruh pohon Merkle yang telah diperbarui dan memverifikasi bahwa itu cocok dengan seluruh hash pada rantai pohon. Jika seluruh hash pohon cocok, maka data pengguna lengkap. Jika seluruh hash pohon tidak cocok, maka relai atau pengguna dapat memberi tahu relai lain nomor daun terbaru mereka dan meminta cabang yang hilang hingga seluruh hash pohon cocok. Untuk melacak semua root Merkle baru yang ditambahkan setiap minggu atau lebih, relai Nostr harus menjadi node penuh Bitcoin. Relay Nostr 2.0 dibayar secara tidak langsung untuk menyimpan blockchain Bitcoin sekaligus meningkatkan keamanan Bitcoin dan Nostr.
Batas Penyimpanan Nostr: Aturan Praktis Pengguna
Karena relai memiliki hak untuk memilih apa yang akan disimpan, tidak seperti node penuh Bitcoin, relai Nostr dapat kehilangan beberapa data pengguna. Oleh karena itu, pengguna hanya boleh menyimpan data pada relai Nostr, jika pengguna dapat membuat cadangan secara lokal. Layanan self-hosted Web5 memungkinkan pengguna menyinkronkan cadangan ke semua perangkat lokal mereka, yang akan mengurangi risiko bagi pengguna yang khawatir menggunakan Nostr. Pada akhirnya, hanya blockchain yang datanya benar-benar tidak dapat diubah. Yang mengatakan, Nostr adalah solusi hybrid yang cukup aman yang masih akan bekerja dengan baik untuk banyak aplikasi. Trade-off tercantum di bawah ini:
Minimalisasi kepercayaan tiga lapis
Tier 1: Penyimpanan data yang tidak dapat diubah dan mahal yang sangat sulit untuk disensor. (Blok pada rantai menyinkronkan semua node penuh Bitcoin)
Tier 2: Penyimpanan data yang dapat diubah dan murah, penyensoran yang cukup sulit. (Pohon Merkle off-chain dan hash on-chain, relai Nostr sinkron sesuai permintaan)
Penyimpanan data lokal disinkronkan ke semua perangkat lokal, mudah disensor. (sentralisasi lokal)
Pertukaran mendasar antara blockchain berbasis konsensus Nakamoto dan Nostr
**Semakin banyak relai Nostr yang menyimpan data untuk alamat tertentu, semakin sulit untuk menyensor data tersebut. Artinya, data populer yang dihosting oleh banyak relai Nostr mungkin lebih sulit disensor daripada data tidak populer yang jarang diunduh. **
**Di sisi lain, blockchain konsensus Nakamoto mencegah penyensoran berdasarkan usia data. Semakin lama data ada di blockchain, semakin sulit untuk menghapusnya menggunakan serangan 51%. **
Karena kami dapat memverifikasi bahwa fork tertentu milik pengguna tertentu, relai Nostr dapat dibayar setiap kali mereka mengirimkan sebagian kecil data ke pengguna. Untuk mencapai ini, pengguna perlu mengunduh kepala blockchain (seperti dalam SPV) untuk dapat menjalankan fungsi khas dompet ringan. Pengguna akan memanfaatkan fungsionalitas SPV dompet ringan untuk mengambil transaksi tertentu dari rantai, yang akan menyertakan root Merkle profil pengguna dan seluruh hash pohon di OP_RETURN-nya. Pengguna sekarang dapat membayar relai untuk mengunduh cabang profil pengguna itu demi cabang, dan memverifikasi setiap cabang dengan melakukan hashing agar cocok dengan rantai root Merkle.
Untuk mengirim sats (unit terkecil Bitcoin) ke relai Nostr sebagai imbalan untuk menyediakan data, kami menggunakan desain ZKCP Gregory Maxwell (pengembang Bitcoin Core terkenal) (Pembayaran Bersyarat Zero-Knowledge) [1] Versi ZKCSP yang berevolusi: Bukti Retrievabilitas [2] Dikombinasikan dengan Jaringan Petir.
Menurut deskripsi kertas putih ZKCSP:
"...tidak perlu pihak ketiga yang tepercaya...Kami juga menerapkan protokol ZKCSP untuk kasus bukti pengambilan, di mana klien membayar server untuk bukti bahwa data klien disimpan dengan benar di server." [2]
Seorang pengguna memulai kontrak pintar Lightning dengan beberapa pemodal.
Pengguna mengirimkan permintaan ke pemodal sekitar. Pemodal menandatangani permintaan tersebut.
Pengguna mengirim permintaan yang ditandatangani oleh pemodal langsung ke relai Nostr yang terhubung dengan pemodal tersebut.
Pengguna sekarang memulai konstruksi ZKCSP untuk memastikan bahwa relai Nostr dibayar dari pemodal hanya setelah data yang diminta dengan benar dikirim.
Setelah langkah 3 terjadi, pengguna akan membuat amandemen di atas permintaan asli yang ditandatangani oleh pemodal sebelum memulai konstruksi ZKCSP di langkah 4. Pengguna akan menambahkan ekstra di atas permintaan awal, menentukan jumlah yang akan dipotong dari saldo pengguna dan pemodal (jumlahnya harus sama, ditambah biaya pemodal), yang kemudian akan ditambahkan pengguna ke pesan asli konten untuk ditandatangani.
**Jika pengguna menentukan untuk mengirim lebih banyak sat daripada yang mereka miliki, atau lebih dari yang telah dibekukan pemodal pada relai Nostr tersebut, maka relai Nostr akan menolak permintaan karena relai tidak akan dapat menerima pembayaran. **
Dengan cara ini, pengguna dapat terhubung dengan banyak relai Nostr sambil membekukan dana mereka hanya dengan beberapa pemberi dana. Pendekatan serupa dapat diambil dengan Lightning Network, di mana pemodal yang diminimalkan kepercayaan adalah perantara tanpa izin antara pengguna dan pedagang. Lompatan petir P2P normal juga tersedia di Nostr 2.0, tetapi ini mungkin berguna jika perutean dan penyeimbangan saluran sering gagal.
** Relay Nostr Berbayar Buka Kunci Daftar Putih**
Relai Nostr dapat memasukkan kunci tertentu ke daftar putih jika mereka ingin menyimpan data yang dilihat oleh semua pengguna ini. Jika relai Nostr tidak dapat memasukkan pengguna yang ingin menyimpan data ke daftar putih, mereka akan menyimpan data apa pun yang dikirimkan kepada mereka. Jika pengguna selalu dapat mengirim data ke relai secara gratis, maka pengguna tidak perlu membayar relai Nostr. Nostr dapat menawarkan opsi berbayar hanya jika relayer memiliki opsi untuk menolak menyimpan data yang tidak dapat dibayar. Relai gratis masih ada, tetapi opsi untuk relai berbayar saat ini tidak ada.
Alih-alih mencoba menyimpan semua data Nostr secara gratis, relai Nostr berbayar dapat menggunakan daftar putih untuk menyimpan secara selektif semua data yang dilihat pengguna berbayar setiap hari. Beberapa relai Nostr akan terus beroperasi pada model bebas, tetapi pada skala terbesar ini tidak berkelanjutan karena sebagian besar relai gratis hanyalah penggemar yang antusias. Daftar putih (bahkan jika kami dapat menetapkan kunci publik dengan aman untuk setiap profil Nostr) memberi relai Nostr kemampuan untuk memutuskan data mana yang akan disimpan tidak mungkin dilakukan.
Satu kunci publik per profil membuka fitur daftar putih: alamat Bitcoin menjadi kunci publik Nostr Anda.
Sistem ini akhirnya memungkinkan kami untuk menetapkan kunci publik ke setiap file konfigurasi.
Tidak ada manfaat bagi pengguna yang membuat kunci publik baru untuk setiap kiriman... karena semuanya terkait dengan profil mereka! Ini tidak sama dengan alamat Bitcoin. Tidak seperti Bitcoin, membuat pengguna memiliki beberapa kunci publik dalam aplikasi yang sama tidak meningkatkan privasi.
**Kunci publik dari profil Nostr harus cocok dengan kunci publik dari transaksi Bitcoin yang berisi hash mingguan (akar Merkle dari semua postingan pengguna dan seluruh hash pohon). Tidak seperti pengguna Nostr yang menggunakan tanda tangan Schnorr, mereka harus menggunakan dompet Bitcoin (dompet seluler/dompet ringan atau simpul penuh) untuk menandatangani. **
Keindahannya adalah setiap akun Nostr akan diwakili oleh alamat Bitcoin-nya,** yang berarti pengguna dapat mengirim pembayaran langsung ke akun Nostr tanpa meminta dua kunci publik yang berbeda. Ini mengurangi biaya kognitif pengguna baru dalam sistem. Alih-alih menggunakan nama pengguna, pengguna masih perlu saling mengirim kunci publik atau DNS untuk menemukan satu sama lain di Nostr. **
Jika aplikasi Nostr lain menggunakan kunci publik yang berbeda, mereka masih dapat dilampirkan ke identitas terdesentralisasi (DID) yang sama - dengan cara ini, cara akun Anda diidentifikasi tetap konsisten di seluruh aplikasi. Namun, aturan konsensus Nostr ini akan membatasi penggunaan hanya satu kunci publik per profil pada setiap aplikasi Nostr.
DHT bertindak sebagai papan peringkat untuk penemuan rekan.
Relai dapat menggunakan Tabel Hash Terdistribusi (DHT) untuk menemukan Relai lainnya. Relai dapat membagikan daftar putihnya dalam tabel hash terdistribusi dengan mencantumkan kunci publik tempat data disimpan. Dengan cara ini, relai dengan fork data yang hilang untuk kunci publik tertentu dapat memindai DHT dan terhubung langsung ke alamat IP relai lain yang mengklaim menyimpan fork yang hilang tersebut. Relai kemudian dapat mengunduh cabang yang hilang langsung dari relai Nostr ini.
Relai juga akan dapat menemukan relai yang paling aktif dengan memeriksa berapa banyak transaksi ZKCSP sebelumnya yang telah diselesaikan oleh relai tersebut secara on-chain - terkini dan sepanjang masa. Dalam sistem ini, semua relai Nostr menjadi node penuh, jadi mengaudit transaksi sebelumnya dari relai lain tidak akan merepotkan. Ini akan membuat kepercayaan mahal, karena transaksi on-chain selalu membutuhkan biaya transaksi. Jika relai Nostr membuka banyak saluran untuk membangun kepercayaan dengan dirinya sendiri untuk mendapatkan kepercayaan dari relai lain, dia harus membayar banyak biaya transaksi untuk mempertahankan reputasi palsu setiap minggu. Setelah penyerang gagal memasok cabang yang hilang, batas waktu akan menyebabkan relai terputus - jadi ini hanya serangan sementara yang mahal (sama seperti serangan 51% adalah serangan sementara yang mahal).
DHT tidak anonim seperti penambangan, karena setiap kunci publik relai Nostr akan dicantumkan di sebelah alamat IP di DHT, tetapi ini akan menghindari kebutuhan relai untuk mengirim permintaan secara membabi buta ke seluruh jaringan - pada skala yang cukup besar, Ini akan membebani jaringan. Penyalur Nostr yang mencari lebih banyak privasi dapat menggunakan VPN atau layanan perlindungan IP lainnya.
Pengguna tidak akan memiliki akses ke sistem kepercayaan yang sama karena mereka bukan node penuh. Namun, pengguna dapat mengandalkannya.
Peternak terhubung secara tidak langsung ke ratusan relai Nostr
Karena pengguna secara otomatis menyimpan semua header blok di dompet ringan mereka, pengguna dapat melihat siapa penambang yang paling aktif. Penambang yang menjadi pemodal akan memungkinkan pengguna untuk menyaring penambang yang paling populer sehingga mereka tidak perlu secara membabi buta mengikat dana ke pemodal acak yang tidak memiliki korelasi dengan kelangsungan jaringan.
**Pemodal (penambang) hanya perlu mengunci sat mereka dengan relai Nostr, tanpa meneruskan data itu sendiri antara pengguna dan relai. **Pemodal (penambang) hanya perlu menandatangani permintaan pengguna sehingga pengguna dapat langsung berinteraksi dengan semua relai Nostr yang terhubung dengan pemodal - 4 langkah untuk ZKCSP+Lightning seperti di atas.
Kesimpulannya
Lightning Network tidak akan ada tanpa blockchain konsensus Nakamoto Bitcoin, karena pengguna tidak akan memiliki tempat untuk menyimpan bukti transaksi off-chain yang dibundel.
Sama seperti pengguna menggabungkan semua transaksi Jaringan Petir ini dan memasukkan bukti kecil ke dalam blockchain, kami akan menggabungkan semua data Nostr dan memasukkan bukti kecil ke dalam blockchain. Dengan cara yang sama seperti Lightning Network menyediakan pembayaran instan di lapisan kedua, Nostr mungkin dapat menyediakan penyimpanan data di lapisan kedua tanpa risiko sidechain yang tidak aman. **
** Ia menggunakan pendekatan yang sama dengan Lightning Network, dengan blockchain konsensus Nakamoto Bitcoin pada lapisan pertama dan Nostr+ZKCSP Lightning pada lapisan kedua. **
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Nostr2.0: sebagai lapisan penyimpanan data di bawah rantai Bitcoin Layer 2
Pengarang: Colby Serpa Penyusun: DAOrayaki
Nostr 2.0 mungkin dapat dibangun di atas Bitcoin sebagai Lapisan 2, menyediakan penyimpanan data off-chain yang aman, sama seperti Lightning Network menyediakan pembayaran off-chain instan sebagai Lapisan 2.
Artikel ini akan menjelaskan bagaimana relai Nostr menyinkronkan datanya sambil mempertahankan sifatnya yang ringan, memungkinkan pengguna untuk menghapus data secara selektif, yang tidak tersedia di blockchain Lapisan 1. Pada saat yang sama, dibandingkan dengan menyimpan data dalam jumlah besar di blockchain Bitcoin, karena kapasitas dan kecepatan blok Bitcoin yang terbatas, mungkin lebih murah untuk menyimpan data menggunakan relai Nostr.
Desain ilmu komputer sederhana berikut meningkatkan sifat distribusi jaringan Nostr di bawah kriteria teorema CAP standar. CAP adalah singkatan dari Konsistensi, Ketersediaan, dan Toleransi partisi
**Relai Nostr tidak mengetahui kapan file konfigurasi tidak lengkap, relai kurang konsisten (C dalam teorema CAP). **
Relai tidak memiliki konsistensi (C dalam teorema CAP)
Konsistensi berarti database yang disinkronkan pada setiap komputer adalah sama. Relai Nostr tidak dapat melakukan sinkronisasi yang diminimalkan kepercayaan dengan cara yang mirip dengan cara blockchain menyinkronkan data mereka blok demi blok. Tidak seperti node penuh Bitcoin, database yang disimpan oleh relai Nostr biasanya tidak lengkap. Selain secara membabi buta meminta semua posting yang ditandatangani oleh pengguna tertentu, relai Nostr tidak dapat menemukan data yang hilang.
Masalah Konsistensi/Sinkronisasi Nostr:
Jika dua pengguna mengunggah postingan mereka masing-masing ke relai Nostr yang berbeda, kedua pengguna tersebut mungkin tidak dapat melihat postingan satu sama lain karena Nostr tidak seperti blockchain. Di blockchain, setiap kali ada rekor baru, semua node penuh akan menyinkronkan blockchain. Semua node penuh akan menambahkan data ini sebagai blok ke blockchain mereka secara bersamaan. Setiap node penuh pada blockchain Bitcoin memiliki blockchain yang sama persis.
Jika kami ingin pengguna Nostr selalu dapat melihat kiriman satu sama lain, maka semua relai Nostr memerlukan cara untuk mengidentifikasi data yang hilang di profil pengguna sehingga mereka dapat meminta bagian yang hilang dari relai atau pengguna Nostr lain.
Gunakan root Merkle on-chain mingguan dan hash pohon penuh untuk menyinkronkan relai Nostr
Merkle root dan whole tree hash menyediakan dua fungsi utama:
Metode murah ini dapat digunakan untuk memperbarui seluruh file konfigurasi pada frekuensi mingguan atau yang ditentukan pengguna. Nostr akan tetap berfungsi seperti sekarang, tetapi pengguna kadang-kadang dapat membayar sejumlah sat untuk menyinkronkan data mereka antara relai Nostr jika ingin postingan mereka dilihat oleh semua pengguna.
Pengguna dan penyalur dapat mengunduh kiriman untuk satu cabang dalam satu waktu. Setelah setiap cabang, mereka melakukan hash pada cabang tersebut dengan cabang lain yang paling dekat dengan akar Merkle untuk memeriksa apakah cocok dengan akar Merkle pada rantai (mirip dengan SPV). Jika cabang-cabang itu digabungkan untuk mencocokkan root Merkle, mereka akan tahu bahwa cabang itu adalah bagian dari profil pengguna, bahkan jika mereka belum memiliki profil pengguna lengkap. Pengguna dapat mengunduh cabang berbeda dari file konfigurasi yang sama dari banyak batang Nostr yang berbeda, sambil memverifikasi validitas setiap cabang dan memastikan bahwa file konfigurasi yang diunduh selesai.
Mengunduh garpu satu per satu mencegah serangan tunda yang dapat melumpuhkan banyak jaringan terdistribusi, itulah sebabnya akar dan garpu Merkle digunakan dalam kertas putih Bitcoin untuk melindungi dompet ringan SPV.
**Mengapa akar Merkle tidak dapat berfungsi seperti seluruh hash pohon? **
**Jika relai Nostr hanya bergantung pada akar Merkle, mereka tidak akan dapat mengetahui kapan pohon Merkle selesai, karena setiap pasangan cabang yang paling dekat dengan akar Merkle akan di-hash ke dalam akar Merkle yang sama. **
Untuk memastikan profil pengguna sudah lengkap, relayer atau pengguna akan melakukan hash pada seluruh pohon Merkle yang telah diperbarui dan memverifikasi bahwa itu cocok dengan seluruh hash pada rantai pohon. Jika seluruh hash pohon cocok, maka data pengguna lengkap. Jika seluruh hash pohon tidak cocok, maka relai atau pengguna dapat memberi tahu relai lain nomor daun terbaru mereka dan meminta cabang yang hilang hingga seluruh hash pohon cocok. Untuk melacak semua root Merkle baru yang ditambahkan setiap minggu atau lebih, relai Nostr harus menjadi node penuh Bitcoin. Relay Nostr 2.0 dibayar secara tidak langsung untuk menyimpan blockchain Bitcoin sekaligus meningkatkan keamanan Bitcoin dan Nostr.
Batas Penyimpanan Nostr: Aturan Praktis Pengguna
Karena relai memiliki hak untuk memilih apa yang akan disimpan, tidak seperti node penuh Bitcoin, relai Nostr dapat kehilangan beberapa data pengguna. Oleh karena itu, pengguna hanya boleh menyimpan data pada relai Nostr, jika pengguna dapat membuat cadangan secara lokal. Layanan self-hosted Web5 memungkinkan pengguna menyinkronkan cadangan ke semua perangkat lokal mereka, yang akan mengurangi risiko bagi pengguna yang khawatir menggunakan Nostr. Pada akhirnya, hanya blockchain yang datanya benar-benar tidak dapat diubah. Yang mengatakan, Nostr adalah solusi hybrid yang cukup aman yang masih akan bekerja dengan baik untuk banyak aplikasi. Trade-off tercantum di bawah ini:
Minimalisasi kepercayaan tiga lapis
Pertukaran mendasar antara blockchain berbasis konsensus Nakamoto dan Nostr
**Semakin banyak relai Nostr yang menyimpan data untuk alamat tertentu, semakin sulit untuk menyensor data tersebut. Artinya, data populer yang dihosting oleh banyak relai Nostr mungkin lebih sulit disensor daripada data tidak populer yang jarang diunduh. **
**Di sisi lain, blockchain konsensus Nakamoto mencegah penyensoran berdasarkan usia data. Semakin lama data ada di blockchain, semakin sulit untuk menghapusnya menggunakan serangan 51%. **
Karena kami dapat memverifikasi bahwa fork tertentu milik pengguna tertentu, relai Nostr dapat dibayar setiap kali mereka mengirimkan sebagian kecil data ke pengguna. Untuk mencapai ini, pengguna perlu mengunduh kepala blockchain (seperti dalam SPV) untuk dapat menjalankan fungsi khas dompet ringan. Pengguna akan memanfaatkan fungsionalitas SPV dompet ringan untuk mengambil transaksi tertentu dari rantai, yang akan menyertakan root Merkle profil pengguna dan seluruh hash pohon di OP_RETURN-nya. Pengguna sekarang dapat membayar relai untuk mengunduh cabang profil pengguna itu demi cabang, dan memverifikasi setiap cabang dengan melakukan hashing agar cocok dengan rantai root Merkle.
Untuk mengirim sats (unit terkecil Bitcoin) ke relai Nostr sebagai imbalan untuk menyediakan data, kami menggunakan desain ZKCP Gregory Maxwell (pengembang Bitcoin Core terkenal) (Pembayaran Bersyarat Zero-Knowledge) [1] Versi ZKCSP yang berevolusi: Bukti Retrievabilitas [2] Dikombinasikan dengan Jaringan Petir.
Menurut deskripsi kertas putih ZKCSP:
"...tidak perlu pihak ketiga yang tepercaya...Kami juga menerapkan protokol ZKCSP untuk kasus bukti pengambilan, di mana klien membayar server untuk bukti bahwa data klien disimpan dengan benar di server." [2]
Setelah langkah 3 terjadi, pengguna akan membuat amandemen di atas permintaan asli yang ditandatangani oleh pemodal sebelum memulai konstruksi ZKCSP di langkah 4. Pengguna akan menambahkan ekstra di atas permintaan awal, menentukan jumlah yang akan dipotong dari saldo pengguna dan pemodal (jumlahnya harus sama, ditambah biaya pemodal), yang kemudian akan ditambahkan pengguna ke pesan asli konten untuk ditandatangani.
**Jika pengguna menentukan untuk mengirim lebih banyak sat daripada yang mereka miliki, atau lebih dari yang telah dibekukan pemodal pada relai Nostr tersebut, maka relai Nostr akan menolak permintaan karena relai tidak akan dapat menerima pembayaran. **
Dengan cara ini, pengguna dapat terhubung dengan banyak relai Nostr sambil membekukan dana mereka hanya dengan beberapa pemberi dana. Pendekatan serupa dapat diambil dengan Lightning Network, di mana pemodal yang diminimalkan kepercayaan adalah perantara tanpa izin antara pengguna dan pedagang. Lompatan petir P2P normal juga tersedia di Nostr 2.0, tetapi ini mungkin berguna jika perutean dan penyeimbangan saluran sering gagal.
** Relay Nostr Berbayar Buka Kunci Daftar Putih**
Relai Nostr dapat memasukkan kunci tertentu ke daftar putih jika mereka ingin menyimpan data yang dilihat oleh semua pengguna ini. Jika relai Nostr tidak dapat memasukkan pengguna yang ingin menyimpan data ke daftar putih, mereka akan menyimpan data apa pun yang dikirimkan kepada mereka. Jika pengguna selalu dapat mengirim data ke relai secara gratis, maka pengguna tidak perlu membayar relai Nostr. Nostr dapat menawarkan opsi berbayar hanya jika relayer memiliki opsi untuk menolak menyimpan data yang tidak dapat dibayar. Relai gratis masih ada, tetapi opsi untuk relai berbayar saat ini tidak ada.
Alih-alih mencoba menyimpan semua data Nostr secara gratis, relai Nostr berbayar dapat menggunakan daftar putih untuk menyimpan secara selektif semua data yang dilihat pengguna berbayar setiap hari. Beberapa relai Nostr akan terus beroperasi pada model bebas, tetapi pada skala terbesar ini tidak berkelanjutan karena sebagian besar relai gratis hanyalah penggemar yang antusias. Daftar putih (bahkan jika kami dapat menetapkan kunci publik dengan aman untuk setiap profil Nostr) memberi relai Nostr kemampuan untuk memutuskan data mana yang akan disimpan tidak mungkin dilakukan.
Satu kunci publik per profil membuka fitur daftar putih: alamat Bitcoin menjadi kunci publik Nostr Anda.
Sistem ini akhirnya memungkinkan kami untuk menetapkan kunci publik ke setiap file konfigurasi.
Tidak ada manfaat bagi pengguna yang membuat kunci publik baru untuk setiap kiriman... karena semuanya terkait dengan profil mereka! Ini tidak sama dengan alamat Bitcoin. Tidak seperti Bitcoin, membuat pengguna memiliki beberapa kunci publik dalam aplikasi yang sama tidak meningkatkan privasi.
**Kunci publik dari profil Nostr harus cocok dengan kunci publik dari transaksi Bitcoin yang berisi hash mingguan (akar Merkle dari semua postingan pengguna dan seluruh hash pohon). Tidak seperti pengguna Nostr yang menggunakan tanda tangan Schnorr, mereka harus menggunakan dompet Bitcoin (dompet seluler/dompet ringan atau simpul penuh) untuk menandatangani. **
Keindahannya adalah setiap akun Nostr akan diwakili oleh alamat Bitcoin-nya,** yang berarti pengguna dapat mengirim pembayaran langsung ke akun Nostr tanpa meminta dua kunci publik yang berbeda. Ini mengurangi biaya kognitif pengguna baru dalam sistem. Alih-alih menggunakan nama pengguna, pengguna masih perlu saling mengirim kunci publik atau DNS untuk menemukan satu sama lain di Nostr. **
Jika aplikasi Nostr lain menggunakan kunci publik yang berbeda, mereka masih dapat dilampirkan ke identitas terdesentralisasi (DID) yang sama - dengan cara ini, cara akun Anda diidentifikasi tetap konsisten di seluruh aplikasi. Namun, aturan konsensus Nostr ini akan membatasi penggunaan hanya satu kunci publik per profil pada setiap aplikasi Nostr.
DHT bertindak sebagai papan peringkat untuk penemuan rekan.
Relai dapat menggunakan Tabel Hash Terdistribusi (DHT) untuk menemukan Relai lainnya. Relai dapat membagikan daftar putihnya dalam tabel hash terdistribusi dengan mencantumkan kunci publik tempat data disimpan. Dengan cara ini, relai dengan fork data yang hilang untuk kunci publik tertentu dapat memindai DHT dan terhubung langsung ke alamat IP relai lain yang mengklaim menyimpan fork yang hilang tersebut. Relai kemudian dapat mengunduh cabang yang hilang langsung dari relai Nostr ini.
Relai juga akan dapat menemukan relai yang paling aktif dengan memeriksa berapa banyak transaksi ZKCSP sebelumnya yang telah diselesaikan oleh relai tersebut secara on-chain - terkini dan sepanjang masa. Dalam sistem ini, semua relai Nostr menjadi node penuh, jadi mengaudit transaksi sebelumnya dari relai lain tidak akan merepotkan. Ini akan membuat kepercayaan mahal, karena transaksi on-chain selalu membutuhkan biaya transaksi. Jika relai Nostr membuka banyak saluran untuk membangun kepercayaan dengan dirinya sendiri untuk mendapatkan kepercayaan dari relai lain, dia harus membayar banyak biaya transaksi untuk mempertahankan reputasi palsu setiap minggu. Setelah penyerang gagal memasok cabang yang hilang, batas waktu akan menyebabkan relai terputus - jadi ini hanya serangan sementara yang mahal (sama seperti serangan 51% adalah serangan sementara yang mahal).
DHT tidak anonim seperti penambangan, karena setiap kunci publik relai Nostr akan dicantumkan di sebelah alamat IP di DHT, tetapi ini akan menghindari kebutuhan relai untuk mengirim permintaan secara membabi buta ke seluruh jaringan - pada skala yang cukup besar, Ini akan membebani jaringan. Penyalur Nostr yang mencari lebih banyak privasi dapat menggunakan VPN atau layanan perlindungan IP lainnya.
Pengguna tidak akan memiliki akses ke sistem kepercayaan yang sama karena mereka bukan node penuh. Namun, pengguna dapat mengandalkannya.
Peternak terhubung secara tidak langsung ke ratusan relai Nostr
Karena pengguna secara otomatis menyimpan semua header blok di dompet ringan mereka, pengguna dapat melihat siapa penambang yang paling aktif. Penambang yang menjadi pemodal akan memungkinkan pengguna untuk menyaring penambang yang paling populer sehingga mereka tidak perlu secara membabi buta mengikat dana ke pemodal acak yang tidak memiliki korelasi dengan kelangsungan jaringan.
**Pemodal (penambang) hanya perlu mengunci sat mereka dengan relai Nostr, tanpa meneruskan data itu sendiri antara pengguna dan relai. **Pemodal (penambang) hanya perlu menandatangani permintaan pengguna sehingga pengguna dapat langsung berinteraksi dengan semua relai Nostr yang terhubung dengan pemodal - 4 langkah untuk ZKCSP+Lightning seperti di atas.
Kesimpulannya
Lightning Network tidak akan ada tanpa blockchain konsensus Nakamoto Bitcoin, karena pengguna tidak akan memiliki tempat untuk menyimpan bukti transaksi off-chain yang dibundel.
Sama seperti pengguna menggabungkan semua transaksi Jaringan Petir ini dan memasukkan bukti kecil ke dalam blockchain, kami akan menggabungkan semua data Nostr dan memasukkan bukti kecil ke dalam blockchain. Dengan cara yang sama seperti Lightning Network menyediakan pembayaran instan di lapisan kedua, Nostr mungkin dapat menyediakan penyimpanan data di lapisan kedua tanpa risiko sidechain yang tidak aman. **
** Ia menggunakan pendekatan yang sama dengan Lightning Network, dengan blockchain konsensus Nakamoto Bitcoin pada lapisan pertama dan Nostr+ZKCSP Lightning pada lapisan kedua. **