Nostr 2.0, tıpkı Lightning Network'ün bir Katman 2 olarak anında zincir dışı ödemeler sağlaması gibi, güvenli zincir dışı veri depolama sağlayan Katman 2 olarak Bitcoin'in üzerine inşa edebilir.
Bu makale, Nostr rölesinin hafif doğasını korurken verilerini nasıl senkronize ettiğini açıklayacak ve kullanıcıların Katman 1 blok zincirlerinde bulunmayan verileri seçerek silmelerine izin verecektir. Aynı zamanda, Bitcoin blok zincirinde büyük miktarda veri depolamaya kıyasla, Bitcoin bloklarının sınırlı kapasitesi ve hızı nedeniyle, Nostr rölelerini kullanarak veri depolamak daha ucuz olabilir.
Aşağıdaki basit bilgisayar bilimi tasarımı, standartlaştırılmış CAP teoremi kriteri altında Nostr ağlarının dağıtım özelliklerini geliştirir. CAP, Tutarlılık, Kullanılabilirlik ve Bölüm toleransı anlamına gelir
**Nostr rölesi, bir yapılandırma dosyasının ne zaman eksik olduğunu bilmez, rölenin tutarlılığı yoktur (CAP teoreminde C). **
Röle tutarlılıktan yoksundur (CAP teoreminde C)
Tutarlılık, her bilgisayarda senkronize edilen veritabanlarının aynı olduğu anlamına gelir. Nostr röleleri, blok zincirlerin verilerini blok blok senkronize etmelerine benzer bir şekilde güveni en aza indirilmiş senkronizasyon yapamaz. Bitcoin tam düğümlerinden farklı olarak, Nostr rölesi tarafından depolanan veritabanı genellikle eksiktir. Nostr geçişi, belirli bir kullanıcı tarafından imzalanan tüm gönderileri körü körüne istemenin yanı sıra, eksik verileri bulamıyor.
Nostr Tutarlılık/Senkronizasyon Sorunları:
İki kullanıcı kendi gönderilerini farklı Nostr rölelerine yüklerse, Nostr bir blockchain gibi olmadığı için bu iki kullanıcı birbirlerinin gönderilerini göremeyebilir. Blok zincirinde, her yeni kayıt olduğunda, tüm tam düğümler blok zincirini senkronize eder. Tüm tam düğümler, bu verileri blok zincirine aynı anda bir blok olarak ekleyecektir. Bitcoin blok zincirindeki her tam düğüm, tamamen aynı blok zincirine sahiptir.
Nostr kullanıcılarının birbirlerinin gönderilerini her zaman görebilmelerini istiyorsak, tüm Nostr geçişlerinin, diğer Nostr geçişlerinden veya kullanıcılarından eksik parçaları talep edebilmeleri için kullanıcı profillerindeki eksik verileri tespit edecek bir yola ihtiyacı vardır.
Nostr rölesini senkronize etmek için haftalık zincir üzerinde Merkle kökünü ve tam ağaç karmalarını kullanın
Kullanıcılar haftada yaklaşık bir kez tüm gönderilerini bir Merkle ağacında düzenleyebilir.
Merkle ağacındaki her yaprak, tıpkı Bitcoin'deki her yaprağın bir işlem hash'i içermesi gibi, bir gönderinin hash'ini içerir.
Bir kullanıcı tüm profilini bir Merkle ağacında düzenlediğinde, Merkle kökünü OP_RETURN on-zincirinde, normal bir Bitcoin işleminin altında yayınlayacaktır. Bu nedenle Nostr 2.0'ın çalışması için blok zincirinin sert bir çatalını gerektirmez. OP_RETURN, bir Bitcoin işleminin altında, gönderenin imzasından önce küçük bir notun eklenmesine izin veren bir bölümdür.
Ek olarak, kullanıcı tüm ağacı özetleyecek ve onu Merkle kökü (OP_RETURN'de) ile birlikte zincire yükleyecektir. Merkle kökü, ağacın tamamı değil, yalnızca en üst dalın özetidir. Tüm ağacın karması, profil verilerinin eksik olup olmadığını tespit edebilmek için kullanıcılar ve aktarıcılar için gereklidir.
Tüm ağacın özetini elde etmek için Merkle kökünü metin dosyasının köküne yerleştirin. Ardından, Merkle dalını kökün altındaki satıra koyun. Ardından Merkle yapraklarını dalın altındaki sıraya yerleştirin. Ağaç açıklandığı gibi düzenlendiğinde, hepsini bir kerede özetleyin. Aşağıda, yukarıda gösterilen Merkle ağacı için bütün bir ağaç karmasının nasıl görüneceğine dair bir bütün ağaç karması örneği verilmiştir. Bütün ağaç hashing (tüm Merkle ağaç verilerini aynı anda hashing)
Merkle kökü ve tüm ağaç sağlamaları iki temel işlev sağlar:
Merkle kökleri, kullanıcıların ve aktarıcıların, tüm bloğu indirmek zorunda kalmadan bir işlemi indirebilmeleri gibi, bir yapılandırma dosyasının bir bölümünü aynı anda indirmelerine izin verir.
Tüm ağaç karma, kullanıcıların ve aktarıcıların depolanan yapılandırma dosyalarının eksik olup olmadığını bilmelerini sağlar. Bir Merkle kökünün aksine, tüm ağaç hash'i yalnızca Merkle ağacındaki tüm bitlere sahipseniz eşleşecektir.
Bu ucuz yöntem, tüm yapılandırma dosyasını haftalık veya kullanıcı tanımlı bir sıklıkta güncellemek için kullanılabilir. Nostr şimdi olduğu gibi çalışmaya devam edecek, ancak kullanıcılar gönderilerinin tüm kullanıcılar tarafından görülmesini istiyorlarsa, verilerini Nostr geçişleri arasında senkronize etmek için ara sıra bazı sats'lar ödeyebilirler.
Kullanıcılar ve aktarıcılar aynı anda bir dal için gönderileri indirebilir. Her daldan sonra, zincirdeki Merkle köküyle (SPV'ye benzer) eşleşip eşleşmediğini kontrol etmek için o dalı Merkle köküne en yakın başka bir dalla özetlerler. Bu dallar, Merkle kökünü eşleştirmek için bir araya getirirse, henüz tam kullanıcı profiline sahip olmasalar bile, şubenin kullanıcı profilinin bir parçası olduğunu bileceklerdir. Kullanıcılar, her dalın geçerliliğini doğrularken ve indirilen yapılandırma dosyasının eksiksiz olduğundan emin olurken, birçok farklı Nostr gövdesinden aynı yapılandırma dosyasının farklı dallarını indirebilir.
Çatalları tek tek indirmek, birçok dağıtılmış ağı çökertebilecek gecikme saldırılarını önler, bu nedenle SPV hafif cüzdanlarını korumak için Bitcoin teknik incelemesinde Merkle kökleri ve çatalları kullanılır.
**Neden bir Merkle kökü bütün bir ağaç hash'i gibi işlev göremiyor? **
**Nostr röleleri yalnızca Merkle köküne bağlı olsaydı, Merkle köküne en yakın her dal çifti aynı Merkle köküne karma olacağından Merkle ağacının ne zaman tamamlandığını bilemezlerdi. **
Kullanıcının profilinin tamamlandığından emin olmak için aktarıcı veya kullanıcı, güncellenmiş Merkle ağacının tamamını özetleyecek ve zincirdeki ağaç karmasının tamamıyla eşleştiğini doğrulayacaktır. Tüm ağaç karmaları eşleşirse, kullanıcı verileri tamamlanır. Tüm ağaç hash'i eşleşmezse, bir geçiş veya kullanıcı diğer rölelere en son yaprak numarasını söyleyebilir ve tüm ağaç hash'i eşleşene kadar eksik dalı talep edebilir. Her hafta eklenen tüm yeni Merkle köklerini takip etmek için, Nostr geçişlerinin Bitcoin tam düğümleri haline gelmesi gerekir. Nostr 2.0 röleleri, Bitcoin ve Nostr'ın güvenliğini artırırken Bitcoin blok zincirini depolamak için dolaylı olarak ödenir.
Nostr Depolama Sınırları: Kullanıcı Kuralı
Aktarıcılar, Bitcoin tam düğümlerinin aksine neyi depolayacaklarını seçme hakkına sahip olduğundan, Nostr geçişleri bazı kullanıcı verilerini kaybedebilir. Bu nedenle, kullanıcılar verileri yalnızca yerel olarak yedekleme yapabiliyorsa Nostr rölesinde depolamalıdır. Web5'in kendi kendine barındırılan hizmeti, kullanıcıların yedeklemeleri tüm yerel cihazlarıyla senkronize etmelerine izin vererek, Nostr kullanma konusunda endişe duyan kullanıcılar için riski azaltacaktır. Günün sonunda, verilerin gerçekten değişmez olduğu yalnızca blok zinciridir. Bununla birlikte, Nostr birçok uygulama için iyi çalışacak oldukça güvenli bir hibrittir. Takaslar aşağıda listelenmiştir:
Üç güven azaltma katmanı
Tier 1: Sansürlemesi son derece zor olan değişmez ve pahalı veri depolama. (Zincirdeki bloklar, tüm Bitcoin tam düğümlerini senkronize eder)
Tier 2: Değiştirilebilir ve ucuz veri depolama, orta zorlukta sansür. (zincir dışı Merkle ağacı ve zincir üstü hash, istek üzerine senkronize Nostr rölesi)
Sansürlenmesi kolay, tüm yerel cihazlarla senkronize edilmiş yerel veri depolama. (yerel merkezileştirme)
Nakamoto fikir birliğine dayalı blok zincirleri ve Nostr arasındaki temel dengeler
**Belirli bir adres için veri depolayan Nostr röleleri ne kadar fazla olursa, bu verileri sansürlemek o kadar zor olur. Bu, birçok Nostr rölesi tarafından barındırılan popüler verilerin sansürlenmesinin, nadiren indirilen popüler olmayan verilere göre daha zor olabileceği anlamına gelir. **
**Öte yandan, Nakamoto mutabakat blok zinciri, verilerin eskiliğine dayalı sansürü önler. Blok zincirinde ne kadar uzun veri varsa, onu %51 saldırısı kullanarak silmek o kadar zor olur. **
Belirli çatalların belirli kullanıcılara ait olduğunu doğrulayabildiğimiz için, bir kullanıcıya küçük bir veri parçası ilettiklerinde Nostr geçişlerine ödeme yapılabilir. Bunu başarmak için kullanıcının hafif bir cüzdanın tipik işlevlerini yerine getirebilmesi için blok zincirinin başını (SPV'de olduğu gibi) indirmesi gerekir. Kullanıcı, kullanıcı profilinin Merkle kökünü ve OP_RETURN'deki tüm ağaç karmasını içerecek olan zincirden belirli bir işlemi almak için hafif cüzdanın SPV işlevselliğinden yararlanacaktır. Kullanıcılar artık, o kullanıcının profilini dal bazında indirmek için röleye ödeme yapabilir ve her dalı, zincir üzerindeki Merkle köküyle eşleşecek şekilde hashleyerek doğrulayabilir.
Veri sağlama karşılığında sats (Bitcoin'in en küçük birimi) Nostr rölesine göndermek için Gregory Maxwell'in (ünlü Bitcoin Core geliştiricisi) ZKCP tasarımını (Sıfır Bilgi Koşullu Ödemeler) kullanıyoruz. [1] ZKCSP'nin gelişmiş bir versiyonu: Alınabilirlik Kanıtı [2] Lightning Network ile birlikte.
ZKCSP tanıtım belgesinin açıklamasına göre:
"...güvenilir bir üçüncü tarafa gerek yok... Ayrıca, müşterinin verilerinin sunucuda doğru bir şekilde depolandığının kanıtı için müşterinin sunucuya ödeme yaptığı geri alınabilirlik kanıtı durumu için ZKCSP protokolünü uyguladık." [2]
Bir kullanıcı, birkaç finansörle bir Lightning akıllı sözleşmesi başlatır.
Kullanıcılar, finansörler tarafından imzalanan istekleri doğrudan bu finansörlere bağlı Nostr rölelerine gönderir.
Kullanıcılar artık Nostr geçişlerinin finansörlerden yalnızca doğru şekilde istenen veriler teslim edildikten sonra ödeme almasını sağlamak için ZKCSP yapılarını başlatıyor.
adım gerçekleştiğinde kullanıcı, 4. adımda ZKCSP inşaatını başlatmadan önce finansör tarafından imzalanan orijinal talebin üzerine değişiklikler yapacaktır. Kullanıcı, orijinal talebin üzerine, hem kullanıcının hem de finansörün bakiyelerinden düşülecek tutarı belirterek (aynı tutar artı finansörün ücreti olmalıdır) bir ekstra ekleyecektir. imzalamak için içerik.
**Kullanıcı sahip olduklarından veya finansörün o Nostr geçişinde dondurduğundan daha fazla uydu göndermeyi belirtirse, geçiş ödeme alamayacağı için Nostr geçişi talebi reddedecektir. **
Bu sayede kullanıcılar, sadece birkaç fon sağlayıcı ile fonlarını dondururken birçok Nostr rölesine bağlanabilir. Benzer bir yaklaşım, güveni en aza indirilmiş finansörlerin kullanıcılar ve satıcılar arasında izinsiz aracılar olduğu Lightning Network için de kullanılabilir. Nostr 2.0'da normal P2P yıldırım atlamaları da mevcuttur, ancak yönlendirme ve kanal dengeleme sık sık başarısız olursa bu yararlı olabilir.
Beyaz Liste Ücretli Nostr Aktarımının Kilidini Açın
Nostr röleleri, tüm bu kullanıcılar tarafından görüntülenen verileri depolamak isterlerse belirli anahtarları beyaz listeye alabilir. Nostr geçişleri, veri depolamak isteyen kullanıcıları beyaz listeye alamazsa, kendilerine gönderilen tüm verileri depolar. Kullanıcılar geçişlere her zaman ücretsiz olarak veri gönderebiliyorsa, kullanıcıların hiçbir zaman Nostr geçişleri için ödeme yapması gerekmeyecektir. Nostr, yalnızca aktarıcının ödemesi yapılamayan verileri depolamayı reddetme seçeneğine sahip olması durumunda ücretli seçenekler sunabilir. Ücretsiz geçişler hala mevcuttur, ancak ücretli geçiş seçeneği şu anda mevcut değildir.
Tüm Nostr verilerini ücretsiz olarak depolamaya çalışmak yerine, ücretli bir Nostr geçişi, ödeme yapan kullanıcılarının günlük olarak görüntülediği tüm verileri seçerek depolamak için bir beyaz liste kullanabilir. Bazı Nostr röleleri ücretsiz bir model üzerinde çalışmaya devam edecek, ancak en büyük ölçekte bu sürdürülebilir değil çünkü çoğu ücretsiz röle sadece hevesli meraklılar. Beyaz listeye alma (her bir Nostr profiline güvenli bir ortak anahtar atayabilsek bile), Nostr rölesine hangi verilerin depolanacağına karar verme yeteneği verir.
Profil başına bir genel anahtar, beyaz liste özelliğinin kilidini açar: Bitcoin adresi, Nostr genel anahtarınız olur.
Bu sistem nihayet her yapılandırma dosyasına bir genel anahtar atamamıza izin verir.
Kullanıcıların her gönderi için yeni ortak anahtarlar oluşturmasının bir faydası yoktur... çünkü bunların tümü profilleriyle ilişkilendirilmiştir! Bu, bir Bitcoin adresi ile aynı değildir. Bitcoin'den farklı olarak, kullanıcıların aynı uygulama içinde birden çok ortak anahtarı olması gizliliği iyileştirmez.
**Nostr profilinin genel anahtarı, haftalık hash'i (kullanıcının tüm gönderilerinin Merkle kökü ve tüm ağaç hash'i) içeren Bitcoin işleminin genel anahtarıyla eşleşmelidir. Schnorr imzalarını kullanan Nostr kullanıcılarının aksine, imzalamak için bir Bitcoin cüzdanı (mobil cüzdan/hafif cüzdan veya tam düğüm) kullanmaları gerekecek. **
Bunun güzelliği, her bir Nostr hesabının kendi Bitcoin adresiyle temsil edilecek olmasıdır**, bu da kullanıcıların iki farklı genel anahtar talep etmeden doğrudan Nostr hesaplarına ödeme gönderebileceği anlamına gelir. Bu, sistemdeki yeni kullanıcıların bilişsel maliyetini azaltır. Kullanıcı adlarını kullanmak yerine, Nostr'da birbirlerini bulmak için kullanıcıların yine de birbirlerine ortak anahtarlar veya DNS göndermeleri gerekir. **
Diğer Nostr uygulamaları farklı ortak anahtarlar kullanıyorsa, yine de aynı merkezi olmayan kimliğe (DID) eklenebilirler - bu şekilde hesabınızın tanımlanma şekli, uygulamalar arasında tutarlı kalır. Ancak, bu Nostr mutabakat kuralı, her Nostr uygulamasında profil başına yalnızca bir genel anahtarın kullanımını sınırlayacaktır.
DHT, akran keşfi için bir liderlik tablosu görevi görür.
Röleler, diğer Röleleri bulmak için Dağıtılmış Karma Tablo (DHT) kullanabilir. Geçişler, verilerin depolandığı genel anahtarı listeleyerek beyaz listelerini dağıtılmış bir karma tabloda paylaşabilir. Bu şekilde, belirli bir ortak anahtar için veri çatalları eksik olan röleler, DHT'yi tarayabilir ve bu eksik çatalları sakladığını iddia eden diğer rölelerin IP adreslerine doğrudan bağlanabilir. Geçişler daha sonra eksik dalları doğrudan bu Nostr geçişlerinden indirebilir.
Aktarıcılar ayrıca, aktarıcıların zincir üzerinde çözdüğü önceki ZKCSP işlemlerinin sayısını kontrol ederek en aktif aktarıcıları bulabilecektir - son ve tüm zamanlar. Bu sistemde, tüm Nostr röleleri tam düğüm haline gelir, bu nedenle diğer rölelerin önceki işlemlerini denetlemek zahmetsiz olacaktır. Zincir üstü işlemler her zaman işlem ücreti gerektirdiğinden, bu, güven oluşturmayı pahalı hale getirir. Bir Nostr rölesi, diğer rölelerin güvenini kazanmak için kendisiyle güven oluşturmak için birçok kanal açarsa, sahte itibarını korumak için her hafta çok fazla işlem ücreti ödemek zorunda kalacaktır. Saldırgan eksik dalı sağlamayı başaramazsa, zaman aşımı rölenin bağlantısının kesilmesine neden olur - yani bu yalnızca geçici, pahalı bir saldırıdır (tıpkı %51 saldırısının geçici, pahalı bir saldırı olması gibi).
DHT, madencilik kadar anonim değildir, çünkü her Nostr rölesinin genel anahtarı DHT'deki IP adresinin yanında listelenir, ancak rölelerin ağ üzerinden körü körüne istek gönderme ihtiyacını ortadan kaldırır - yeterince büyük bir ölçekte, Bu ağı aşırı yükleyecektir. Daha fazla gizlilik arayan Nostr aktarıcıları, bir VPN veya başka bir IP koruma hizmeti kullanabilir.
Kullanıcılar, tam düğüm olmadıkları için aynı güven sistemine erişemezler. Ancak, kullanıcılar buna güvenebilir.
Meraklıları dolaylı olarak yüzlerce Nostr aktarımına bağlıdır
Kullanıcılar tüm blok başlıklarını otomatik olarak hafif cüzdanlarında sakladıklarından, kullanıcılar en aktif madencilerin kim olduğunu görebilir. Finansör haline gelen madenciler, kullanıcıların en popüler madencileri filtrelemesine izin verecek, böylece fonları ağın uygulanabilirliği ile hiçbir ilgisi olmayan rastgele finansörlere körü körüne bağlamak zorunda kalmayacaklar.
**Finans sağlayıcıların (madenciler), verilerin kendisini kullanıcılar ve geçiş arasında iletmeden yalnızca Nostr geçişiyle uydularını kilitlemeleri gerekir. **Finansmancının (madencinin), kullanıcının finansörün bağlı olduğu tüm Nostr röleleriyle doğrudan etkileşim kurabilmesi için kullanıcının talebini imzalaması yeterlidir - ZKCSP+Lightning için yukarıdaki 4 adım.
Sonuç olarak
Lightning Network, Bitcoin'in Nakamoto mutabakat blok zinciri olmadan var olamazdı, çünkü kullanıcılar zincir dışı işlemlerin toplu kanıtlarını saklayacak hiçbir yere sahip olmayacaktı.
Tıpkı kullanıcıların tüm bu Lightning Network işlemlerini bir araya toplayıp blok zincirine küçük kanıtlar koyması gibi, biz de tüm Nostr verilerini bir araya toplayıp blok zincirine küçük kanıtlar koyacağız. Lightning Network'ün ikinci katmanda anında ödeme sağlaması gibi, Nostr da güvenli olmayan bir yan zincir riski olmadan ikinci katmanda veri depolama sağlayabilir. **
**İlk katmanda Bitcoin'in Nakamoto mutabakat blok zinciri ve ikinci katmanda Nostr+ZKCSP Lightning ile Lightning Network ile aynı yaklaşımı kullanır. **
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Nostr2.0: Bitcoin Layer 2 zincirinin altındaki veri depolama katmanı olarak
Yazar: Colby Serpa Derleyen: DAOrayaki
Nostr 2.0, tıpkı Lightning Network'ün bir Katman 2 olarak anında zincir dışı ödemeler sağlaması gibi, güvenli zincir dışı veri depolama sağlayan Katman 2 olarak Bitcoin'in üzerine inşa edebilir.
Bu makale, Nostr rölesinin hafif doğasını korurken verilerini nasıl senkronize ettiğini açıklayacak ve kullanıcıların Katman 1 blok zincirlerinde bulunmayan verileri seçerek silmelerine izin verecektir. Aynı zamanda, Bitcoin blok zincirinde büyük miktarda veri depolamaya kıyasla, Bitcoin bloklarının sınırlı kapasitesi ve hızı nedeniyle, Nostr rölelerini kullanarak veri depolamak daha ucuz olabilir.
Aşağıdaki basit bilgisayar bilimi tasarımı, standartlaştırılmış CAP teoremi kriteri altında Nostr ağlarının dağıtım özelliklerini geliştirir. CAP, Tutarlılık, Kullanılabilirlik ve Bölüm toleransı anlamına gelir
**Nostr rölesi, bir yapılandırma dosyasının ne zaman eksik olduğunu bilmez, rölenin tutarlılığı yoktur (CAP teoreminde C). **
Röle tutarlılıktan yoksundur (CAP teoreminde C)
Tutarlılık, her bilgisayarda senkronize edilen veritabanlarının aynı olduğu anlamına gelir. Nostr röleleri, blok zincirlerin verilerini blok blok senkronize etmelerine benzer bir şekilde güveni en aza indirilmiş senkronizasyon yapamaz. Bitcoin tam düğümlerinden farklı olarak, Nostr rölesi tarafından depolanan veritabanı genellikle eksiktir. Nostr geçişi, belirli bir kullanıcı tarafından imzalanan tüm gönderileri körü körüne istemenin yanı sıra, eksik verileri bulamıyor.
Nostr Tutarlılık/Senkronizasyon Sorunları:
İki kullanıcı kendi gönderilerini farklı Nostr rölelerine yüklerse, Nostr bir blockchain gibi olmadığı için bu iki kullanıcı birbirlerinin gönderilerini göremeyebilir. Blok zincirinde, her yeni kayıt olduğunda, tüm tam düğümler blok zincirini senkronize eder. Tüm tam düğümler, bu verileri blok zincirine aynı anda bir blok olarak ekleyecektir. Bitcoin blok zincirindeki her tam düğüm, tamamen aynı blok zincirine sahiptir.
Nostr kullanıcılarının birbirlerinin gönderilerini her zaman görebilmelerini istiyorsak, tüm Nostr geçişlerinin, diğer Nostr geçişlerinden veya kullanıcılarından eksik parçaları talep edebilmeleri için kullanıcı profillerindeki eksik verileri tespit edecek bir yola ihtiyacı vardır.
Nostr rölesini senkronize etmek için haftalık zincir üzerinde Merkle kökünü ve tam ağaç karmalarını kullanın
Merkle kökü ve tüm ağaç sağlamaları iki temel işlev sağlar:
Bu ucuz yöntem, tüm yapılandırma dosyasını haftalık veya kullanıcı tanımlı bir sıklıkta güncellemek için kullanılabilir. Nostr şimdi olduğu gibi çalışmaya devam edecek, ancak kullanıcılar gönderilerinin tüm kullanıcılar tarafından görülmesini istiyorlarsa, verilerini Nostr geçişleri arasında senkronize etmek için ara sıra bazı sats'lar ödeyebilirler.
Kullanıcılar ve aktarıcılar aynı anda bir dal için gönderileri indirebilir. Her daldan sonra, zincirdeki Merkle köküyle (SPV'ye benzer) eşleşip eşleşmediğini kontrol etmek için o dalı Merkle köküne en yakın başka bir dalla özetlerler. Bu dallar, Merkle kökünü eşleştirmek için bir araya getirirse, henüz tam kullanıcı profiline sahip olmasalar bile, şubenin kullanıcı profilinin bir parçası olduğunu bileceklerdir. Kullanıcılar, her dalın geçerliliğini doğrularken ve indirilen yapılandırma dosyasının eksiksiz olduğundan emin olurken, birçok farklı Nostr gövdesinden aynı yapılandırma dosyasının farklı dallarını indirebilir.
Çatalları tek tek indirmek, birçok dağıtılmış ağı çökertebilecek gecikme saldırılarını önler, bu nedenle SPV hafif cüzdanlarını korumak için Bitcoin teknik incelemesinde Merkle kökleri ve çatalları kullanılır.
**Neden bir Merkle kökü bütün bir ağaç hash'i gibi işlev göremiyor? **
**Nostr röleleri yalnızca Merkle köküne bağlı olsaydı, Merkle köküne en yakın her dal çifti aynı Merkle köküne karma olacağından Merkle ağacının ne zaman tamamlandığını bilemezlerdi. **
Kullanıcının profilinin tamamlandığından emin olmak için aktarıcı veya kullanıcı, güncellenmiş Merkle ağacının tamamını özetleyecek ve zincirdeki ağaç karmasının tamamıyla eşleştiğini doğrulayacaktır. Tüm ağaç karmaları eşleşirse, kullanıcı verileri tamamlanır. Tüm ağaç hash'i eşleşmezse, bir geçiş veya kullanıcı diğer rölelere en son yaprak numarasını söyleyebilir ve tüm ağaç hash'i eşleşene kadar eksik dalı talep edebilir. Her hafta eklenen tüm yeni Merkle köklerini takip etmek için, Nostr geçişlerinin Bitcoin tam düğümleri haline gelmesi gerekir. Nostr 2.0 röleleri, Bitcoin ve Nostr'ın güvenliğini artırırken Bitcoin blok zincirini depolamak için dolaylı olarak ödenir.
Nostr Depolama Sınırları: Kullanıcı Kuralı
Aktarıcılar, Bitcoin tam düğümlerinin aksine neyi depolayacaklarını seçme hakkına sahip olduğundan, Nostr geçişleri bazı kullanıcı verilerini kaybedebilir. Bu nedenle, kullanıcılar verileri yalnızca yerel olarak yedekleme yapabiliyorsa Nostr rölesinde depolamalıdır. Web5'in kendi kendine barındırılan hizmeti, kullanıcıların yedeklemeleri tüm yerel cihazlarıyla senkronize etmelerine izin vererek, Nostr kullanma konusunda endişe duyan kullanıcılar için riski azaltacaktır. Günün sonunda, verilerin gerçekten değişmez olduğu yalnızca blok zinciridir. Bununla birlikte, Nostr birçok uygulama için iyi çalışacak oldukça güvenli bir hibrittir. Takaslar aşağıda listelenmiştir:
Üç güven azaltma katmanı
Nakamoto fikir birliğine dayalı blok zincirleri ve Nostr arasındaki temel dengeler
**Belirli bir adres için veri depolayan Nostr röleleri ne kadar fazla olursa, bu verileri sansürlemek o kadar zor olur. Bu, birçok Nostr rölesi tarafından barındırılan popüler verilerin sansürlenmesinin, nadiren indirilen popüler olmayan verilere göre daha zor olabileceği anlamına gelir. **
**Öte yandan, Nakamoto mutabakat blok zinciri, verilerin eskiliğine dayalı sansürü önler. Blok zincirinde ne kadar uzun veri varsa, onu %51 saldırısı kullanarak silmek o kadar zor olur. **
Belirli çatalların belirli kullanıcılara ait olduğunu doğrulayabildiğimiz için, bir kullanıcıya küçük bir veri parçası ilettiklerinde Nostr geçişlerine ödeme yapılabilir. Bunu başarmak için kullanıcının hafif bir cüzdanın tipik işlevlerini yerine getirebilmesi için blok zincirinin başını (SPV'de olduğu gibi) indirmesi gerekir. Kullanıcı, kullanıcı profilinin Merkle kökünü ve OP_RETURN'deki tüm ağaç karmasını içerecek olan zincirden belirli bir işlemi almak için hafif cüzdanın SPV işlevselliğinden yararlanacaktır. Kullanıcılar artık, o kullanıcının profilini dal bazında indirmek için röleye ödeme yapabilir ve her dalı, zincir üzerindeki Merkle köküyle eşleşecek şekilde hashleyerek doğrulayabilir.
Veri sağlama karşılığında sats (Bitcoin'in en küçük birimi) Nostr rölesine göndermek için Gregory Maxwell'in (ünlü Bitcoin Core geliştiricisi) ZKCP tasarımını (Sıfır Bilgi Koşullu Ödemeler) kullanıyoruz. [1] ZKCSP'nin gelişmiş bir versiyonu: Alınabilirlik Kanıtı [2] Lightning Network ile birlikte.
ZKCSP tanıtım belgesinin açıklamasına göre:
"...güvenilir bir üçüncü tarafa gerek yok... Ayrıca, müşterinin verilerinin sunucuda doğru bir şekilde depolandığının kanıtı için müşterinin sunucuya ödeme yaptığı geri alınabilirlik kanıtı durumu için ZKCSP protokolünü uyguladık." [2]
**Kullanıcı sahip olduklarından veya finansörün o Nostr geçişinde dondurduğundan daha fazla uydu göndermeyi belirtirse, geçiş ödeme alamayacağı için Nostr geçişi talebi reddedecektir. **
Bu sayede kullanıcılar, sadece birkaç fon sağlayıcı ile fonlarını dondururken birçok Nostr rölesine bağlanabilir. Benzer bir yaklaşım, güveni en aza indirilmiş finansörlerin kullanıcılar ve satıcılar arasında izinsiz aracılar olduğu Lightning Network için de kullanılabilir. Nostr 2.0'da normal P2P yıldırım atlamaları da mevcuttur, ancak yönlendirme ve kanal dengeleme sık sık başarısız olursa bu yararlı olabilir.
Beyaz Liste Ücretli Nostr Aktarımının Kilidini Açın
Nostr röleleri, tüm bu kullanıcılar tarafından görüntülenen verileri depolamak isterlerse belirli anahtarları beyaz listeye alabilir. Nostr geçişleri, veri depolamak isteyen kullanıcıları beyaz listeye alamazsa, kendilerine gönderilen tüm verileri depolar. Kullanıcılar geçişlere her zaman ücretsiz olarak veri gönderebiliyorsa, kullanıcıların hiçbir zaman Nostr geçişleri için ödeme yapması gerekmeyecektir. Nostr, yalnızca aktarıcının ödemesi yapılamayan verileri depolamayı reddetme seçeneğine sahip olması durumunda ücretli seçenekler sunabilir. Ücretsiz geçişler hala mevcuttur, ancak ücretli geçiş seçeneği şu anda mevcut değildir.
Tüm Nostr verilerini ücretsiz olarak depolamaya çalışmak yerine, ücretli bir Nostr geçişi, ödeme yapan kullanıcılarının günlük olarak görüntülediği tüm verileri seçerek depolamak için bir beyaz liste kullanabilir. Bazı Nostr röleleri ücretsiz bir model üzerinde çalışmaya devam edecek, ancak en büyük ölçekte bu sürdürülebilir değil çünkü çoğu ücretsiz röle sadece hevesli meraklılar. Beyaz listeye alma (her bir Nostr profiline güvenli bir ortak anahtar atayabilsek bile), Nostr rölesine hangi verilerin depolanacağına karar verme yeteneği verir.
Profil başına bir genel anahtar, beyaz liste özelliğinin kilidini açar: Bitcoin adresi, Nostr genel anahtarınız olur.
Bu sistem nihayet her yapılandırma dosyasına bir genel anahtar atamamıza izin verir.
Kullanıcıların her gönderi için yeni ortak anahtarlar oluşturmasının bir faydası yoktur... çünkü bunların tümü profilleriyle ilişkilendirilmiştir! Bu, bir Bitcoin adresi ile aynı değildir. Bitcoin'den farklı olarak, kullanıcıların aynı uygulama içinde birden çok ortak anahtarı olması gizliliği iyileştirmez.
**Nostr profilinin genel anahtarı, haftalık hash'i (kullanıcının tüm gönderilerinin Merkle kökü ve tüm ağaç hash'i) içeren Bitcoin işleminin genel anahtarıyla eşleşmelidir. Schnorr imzalarını kullanan Nostr kullanıcılarının aksine, imzalamak için bir Bitcoin cüzdanı (mobil cüzdan/hafif cüzdan veya tam düğüm) kullanmaları gerekecek. **
Bunun güzelliği, her bir Nostr hesabının kendi Bitcoin adresiyle temsil edilecek olmasıdır**, bu da kullanıcıların iki farklı genel anahtar talep etmeden doğrudan Nostr hesaplarına ödeme gönderebileceği anlamına gelir. Bu, sistemdeki yeni kullanıcıların bilişsel maliyetini azaltır. Kullanıcı adlarını kullanmak yerine, Nostr'da birbirlerini bulmak için kullanıcıların yine de birbirlerine ortak anahtarlar veya DNS göndermeleri gerekir. **
Diğer Nostr uygulamaları farklı ortak anahtarlar kullanıyorsa, yine de aynı merkezi olmayan kimliğe (DID) eklenebilirler - bu şekilde hesabınızın tanımlanma şekli, uygulamalar arasında tutarlı kalır. Ancak, bu Nostr mutabakat kuralı, her Nostr uygulamasında profil başına yalnızca bir genel anahtarın kullanımını sınırlayacaktır.
DHT, akran keşfi için bir liderlik tablosu görevi görür.
Röleler, diğer Röleleri bulmak için Dağıtılmış Karma Tablo (DHT) kullanabilir. Geçişler, verilerin depolandığı genel anahtarı listeleyerek beyaz listelerini dağıtılmış bir karma tabloda paylaşabilir. Bu şekilde, belirli bir ortak anahtar için veri çatalları eksik olan röleler, DHT'yi tarayabilir ve bu eksik çatalları sakladığını iddia eden diğer rölelerin IP adreslerine doğrudan bağlanabilir. Geçişler daha sonra eksik dalları doğrudan bu Nostr geçişlerinden indirebilir.
Aktarıcılar ayrıca, aktarıcıların zincir üzerinde çözdüğü önceki ZKCSP işlemlerinin sayısını kontrol ederek en aktif aktarıcıları bulabilecektir - son ve tüm zamanlar. Bu sistemde, tüm Nostr röleleri tam düğüm haline gelir, bu nedenle diğer rölelerin önceki işlemlerini denetlemek zahmetsiz olacaktır. Zincir üstü işlemler her zaman işlem ücreti gerektirdiğinden, bu, güven oluşturmayı pahalı hale getirir. Bir Nostr rölesi, diğer rölelerin güvenini kazanmak için kendisiyle güven oluşturmak için birçok kanal açarsa, sahte itibarını korumak için her hafta çok fazla işlem ücreti ödemek zorunda kalacaktır. Saldırgan eksik dalı sağlamayı başaramazsa, zaman aşımı rölenin bağlantısının kesilmesine neden olur - yani bu yalnızca geçici, pahalı bir saldırıdır (tıpkı %51 saldırısının geçici, pahalı bir saldırı olması gibi).
DHT, madencilik kadar anonim değildir, çünkü her Nostr rölesinin genel anahtarı DHT'deki IP adresinin yanında listelenir, ancak rölelerin ağ üzerinden körü körüne istek gönderme ihtiyacını ortadan kaldırır - yeterince büyük bir ölçekte, Bu ağı aşırı yükleyecektir. Daha fazla gizlilik arayan Nostr aktarıcıları, bir VPN veya başka bir IP koruma hizmeti kullanabilir.
Kullanıcılar, tam düğüm olmadıkları için aynı güven sistemine erişemezler. Ancak, kullanıcılar buna güvenebilir.
Meraklıları dolaylı olarak yüzlerce Nostr aktarımına bağlıdır
Kullanıcılar tüm blok başlıklarını otomatik olarak hafif cüzdanlarında sakladıklarından, kullanıcılar en aktif madencilerin kim olduğunu görebilir. Finansör haline gelen madenciler, kullanıcıların en popüler madencileri filtrelemesine izin verecek, böylece fonları ağın uygulanabilirliği ile hiçbir ilgisi olmayan rastgele finansörlere körü körüne bağlamak zorunda kalmayacaklar.
**Finans sağlayıcıların (madenciler), verilerin kendisini kullanıcılar ve geçiş arasında iletmeden yalnızca Nostr geçişiyle uydularını kilitlemeleri gerekir. **Finansmancının (madencinin), kullanıcının finansörün bağlı olduğu tüm Nostr röleleriyle doğrudan etkileşim kurabilmesi için kullanıcının talebini imzalaması yeterlidir - ZKCSP+Lightning için yukarıdaki 4 adım.
Sonuç olarak
Lightning Network, Bitcoin'in Nakamoto mutabakat blok zinciri olmadan var olamazdı, çünkü kullanıcılar zincir dışı işlemlerin toplu kanıtlarını saklayacak hiçbir yere sahip olmayacaktı.
Tıpkı kullanıcıların tüm bu Lightning Network işlemlerini bir araya toplayıp blok zincirine küçük kanıtlar koyması gibi, biz de tüm Nostr verilerini bir araya toplayıp blok zincirine küçük kanıtlar koyacağız. Lightning Network'ün ikinci katmanda anında ödeme sağlaması gibi, Nostr da güvenli olmayan bir yan zincir riski olmadan ikinci katmanda veri depolama sağlayabilir. **
**İlk katmanda Bitcoin'in Nakamoto mutabakat blok zinciri ve ikinci katmanda Nostr+ZKCSP Lightning ile Lightning Network ile aynı yaklaşımı kullanır. **