Giriş

Ya her saat başı hafızanızı kaybederseniz? Ve sürekli olarak birinden size ne yaptığınızı söylemesini istemeniz mi gerekiyor? Akıllı sözleşmelerin mevcut durumu budur. Ethereum gibi blockchainlerde akıllı sözleşmeler 256 bloğun ötesindeki durumlara doğrudan erişemez. Bu sorun, farklı yürütme katmanları üzerinden verilerin alınmasının ve doğrulanmasının daha da zor olduğu çok zincirli ekosistemde daha da kötüleşiyor.

2020'de Vitalik Buterin ve Tomasz Stanczak, verilere zaman içinde erişmenin bir yolunu önerdi . EIP durgunlaşırken, toparlanma merkezli çok zincirli dünyada ihtiyacı yeniden ortaya çıktı. Günümüzde akıllı sözleşmelere farkındalık ve hafıza kazandırmak için depolama kanıtları bir sınır olarak ortaya çıkmıştır.

Zincir içi verilere erişme

DApp'lerin verilere ve duruma erişebilmesinin çeşitli yolları vardır. Yaklaşımların tümü, uygulamanın insanlara/varlıklara veya kripto ekonomik güvenliğine veya koduna güvenmesini ve bazı ödünleşimlere sahip olmasını gerektirir:

İnsanlara/kurumlara güven:

• Arşiv düğümleri: Operatörler bir arşiv düğümünü kendileri çalıştırabilir veya Genesis bloğundan bu yana tüm verilere erişmek için Alchemy veya Infura gibi arşiv düğümü hizmet sağlayıcılarına güvenebilirler. Tam Düğüm ile aynı verileri sağlarlar, aynı zamanda tüm blok zincirinin tüm geçmiş durum verilerini de sağlarlar. Etherscan ve Dune Analytics gibi zincir dışı hizmetler, zincir içi verilere erişmek için arşiv düğümlerini kullanır. Zincir dışı aktörler bu verilerin geçerliliğini doğrulayabilir ve zincir içi akıllı sözleşmeler, verilerin güvenilir bir aktör/komite tarafından imzalandığını doğrulayabilir. Temel verilerin bütünlüğü doğrulanmadı. Bu yaklaşım, dapp'in arşiv düğümü hizmet sağlayıcısının altyapıyı doğru ve herhangi bir kötü niyet olmadan çalıştırdığına güvenmesini gerektirir.

Kripto ekonomik güvenliğine güvenin:

• Dizin oluşturucular: Dizin oluşturma protokolü, Blockchain üzerindeki tüm verileri düzenleyerek geliştiricilerin uygulamaların sorgulayabileceği açık API'ler oluşturmasına ve yayınlamasına olanak tanır. Bireysel indeksleyiciler, indeksleme ve sorgu işleme hizmetleri sağlamak için belirteçleri hisselendiren düğüm operatörleridir. Ancak sunulan veriler yanlış olduğunda anlaşmazlıklar ortaya çıkabilir ve tahkim süreci zaman alabilir. Üstelik The Graph gibi indeksleyicilerden gelen veriler, akıllı sözleşmelerin iş mantığı tarafından doğrudan kullanılamaz ve web2 tabanlı veri analitiği bağlamında kullanılır.
• Oracle'lar: Oracle servis sağlayıcıları birçok bağımsız düğüm operatöründen toplanan verileri kullanır. Buradaki zorluk, Oracle'lardan elde edilen verilerin sık sık güncellenmemesi ve kapsamının sınırlı olmasıdır. Chainlink gibi Oracle'lar genellikle fiyat feed'leri gibi yalnızca belirli durumları korur ve uygulamaya özel durumlar ve geçmiş için bunlar mümkün değildir. Üstelik bu yaklaşım aynı zamanda verilerde belirli bir düzeyde sapmaya neden olmakta ve düğüm operatörlerine güvenilmesini gerektirmektedir.

Güven Kodu:

• Özel Değişken ve İşlevler: Ethereum gibi blok zincirleri, esas olarak blok zinciri hakkında bilgi sağlamak için kullanılan veya genel kullanımlı yardımcı işlevler olan özel değişkenlere ve işlevlere sahiptir. Akıllı bir sözleşmenin yalnızca en son 256 bloğun blok karma değerine erişmesi mümkündür. Ölçeklenebilirlik nedeniyle blok karmaları tüm bloklar için mevcut değildir. Tarihsel blok karmalarına erişim, onlara karşı kanıtların doğrulanmasına izin verebileceği için faydalı olacaktır. EVM yürütmesinde eski blok içeriklerine veya önceki işlem içeriklerine veya makbuz çıktılarına erişime izin veren bir işlem kodu yoktur, böylece bir düğüm bunları güvenli bir şekilde unutabilir ve yine de yeni blokları işleyebilir. Bu yöntem aynı zamanda tek bir blockchain ile sınırlıdır.

Bu çözümlerin zorlukları ve sınırlamaları göz önüne alındığında, blok karmalarının zincir üzerinde saklanması ve sağlanmasına açık bir ihtiyaç vardır. Depolama kanıtlarının devreye girdiği yer burasıdır. Depolama kanıtlarını daha iyi anlamak için blok zincirlerdeki veri depolamaya hızlıca bir göz atalım.

Blockchain'de veri depolama

Blockchain, bir ağdaki birçok bilgisayar arasında güncellenen ve paylaşılan halka açık bir veritabanıdır. Veriler ve durum, blok adı verilen ardışık gruplarda depolanır ve her blok, önceki blok başlığının karmasını depolayarak kriptografik olarak üst öğesine referans verir.

Örnek olarak Ethereum bloğunu ele alalım. Ethereum, "Merkle Patricia ağacı" (MPT) olarak bilinen belirli bir Merkle ağacı türünden yararlanır. Ethereum blok başlıkları dört farklı Merkle-Patricia denemesinin köklerini içerir; Durum üçlüsü, Depolama üçlüsü, Makbuzlar üçlüsü ve İşlem üçlüsü. Bu 4 deneme, tüm Ethereum verilerini içeren eşlemeleri kodlar. Merkle Ağaçları veri depolamadaki verimlilikleri nedeniyle kullanılmaktadır. Özyinelemeli karmalar kullanıldığında, sonuçta yalnızca kök karmanın depolanması gerekir, bu da çok fazla alan tasarrufu sağlar. Düğümleri yinelemeli olarak karma işleminin aynı kök karma değerine yol açtığını kanıtlayarak herkesin ağaçtaki bir öğenin varlığını kanıtlamasına olanak tanır. Merkle kanıtları, Ethereum'daki hafif istemcilerin aşağıdaki gibi soruların yanıtlarını almasına olanak tanır:

• Bu işlem belirli bir blokta mevcut mu?
• Hesabımın güncel bakiyesi nedir?
• Bu hesap mevcut mu?

Bir "hafif istemci", her işlemi ve her bloğu indirmek yerine yalnızca blok başlıkları zincirini indirebilir ve Merkle Kanıtlarını kullanarak bilgileri doğrulayabilir. Bu, genel süreci oldukça verimli hale getirir. Merkle Ağaçları ile ilgili uygulamayı, avantajları ve zorlukları daha iyi anlamak için Vitalik ve Maven11 tarafından yazılan bu blog araştırma makalesine bakın.

Saklama Kanıtları

Depolama kanıtları, veritabanında bir şeyin kaydedildiğini ve kriptografik taahhütler kullanılarak da geçerli olduğunu kanıtlamamıza olanak tanır. Eğer böyle bir kanıt sunabilirsek, bu, blockchainde bir şeyler yaşandığına dair doğrulanabilir bir iddiadır.

Depolama kanıtları neleri mümkün kılabilir?

Depolama kanıtları iki ana işlevselliğe izin verir:

1. Son 256 bloktan sonraki zincir içi verilere, başlangıç bloğuna kadar erişin
2. Konsensüs doğrulaması veya L2'ler durumunda L1-L2 köprüsü yardımıyla başka bir blok zincirindeki bir blok zincirinin zincir üstü verilerine (geçmişin yanı sıra güncel) erişim

Depolama kanıtları nasıl çalışır?

Depolama kanıtları, belirli bir bloğun blok zincirinin kanonik geçmişinin bir parçası olup olmadığını çok yüksek düzeyde kontrol eder ve ardından istenen belirli verilerin bloğun parçası olup olmadığını doğrular. Bu şu şekilde başarılabilir:

• Zincir içi işleme: dapp'ler ilk güvenilir bloğu alabilir, önceki bloğa erişmek için bloğu çağrı verileri olarak iletebilir ve oluşum bloğuna kadar geri dönebilir. Bu, zincir üzerinde çok fazla hesaplama ve büyük miktarda çağrı verisi gerektirir. Bu yaklaşım, zincir üzerinde gereken büyük miktarda hesaplama nedeniyle pratik olarak mümkün değildir. Aragon, 2018'de zincir üstü yaklaşımı kullanmayı denedi ancak yüksek zincir üstü maliyet nedeniyle bu mümkün olmadı.
• ZK kanıtlarının kullanılması: Yaklaşım, ZK kanıtlayıcısının karmaşık hesaplamayı zincir dışına taşımak için kullanılması dışında zincir içi işleme benzer.

1. Aynı zincirdeki verilere erişim: ZK kanıtı, rastgele bir tarihsel blok başlığının, yürütme ortamında erişilebilen en yeni 256 blok başlığından birinin atası olduğunu iddia etmek için kullanılabilir. Diğer yaklaşım ise kaynak zincirinin tüm geçmişini indekslemek ve indekslemenin doğru gerçekleştiğini kanıtlamak için bunun ZK kanıtını oluşturmaktır. Bu kanıt, kaynak zincirine yeni bloklar eklendikçe düzenli olarak güncellenmektedir. Zincirler arası verilere erişim: Sağlayıcı, hedef zincirdeki kaynak zincirinin blok başlıklarını toplar ve ZK fikir birliği kanıtını kullanarak bu blok başlıklarının geçerliliğini doğrular. Blok başlıklarını sorgulamak için Axelar, Celer veya LayerZero gibi mevcut bir AMP çözümünü kullanmak da mümkündür.
2. Kaynak zincirinin blok başlıklarının karmalarının bir önbelleği veya zincir dışı blok karma akümülatörünün kök karması, hedef zincirde tutulur. Bu önbellek düzenli olarak güncellenir ve belirli bir bloğun var olduğunu ve eyaletten erişilebilen yeni bir blok karmasına kriptografik bağlantıya sahip olduğunu zincir üzerinde etkili bir şekilde kanıtlamak için kullanılır. Bu işleme zincirin devamlılığının kanıtlanması denir. Tüm kaynak zincirlerin blok başlıklarını depolamak için özel bir blok zinciri kullanmak da mümkündür.
3. Geçmiş verilere/bloğa, hedef zincirdeki dapp tarafından talep edildiği şekilde zincir dışı indekslenmiş verilerden veya zincir içi önbellekten (isteğin karmaşıklığına bağlı olarak) erişilir. Blok başlıklarının karmasının önbelleği zincir üzerinde tutulurken, gerçek veriler zincir dışında saklanabilir.
4. Belirtilen bloktaki verinin varlığı merkle içerme kanıtları ile kontrol edilir ve buna yönelik zk kanıtı oluşturulur. Bu kanıt, doğru endekslemenin zk kanıtı veya ZK fikir birliği kanıtı ile birleştirilir ve kanıt, güvenilir olmayan doğrulama için zincir üzerinde sunulur.
5. DApp'ler daha sonra bu kanıtı zincir üzerinde doğrulayabilir ve istenen eylemi gerçekleştirmek için verileri kullanabilir. ZK kanıtının doğrulanmasının yanı sıra, blok numarası ve blok karması gibi genel parametreler, zincir üzerinde tutulan blok başlıklarının önbelleğine göre kontrol edilir.

Bu yaklaşımı benimseyen projelerden bazıları Herodot, Lagrange, Axiom, Hyper Oracle, Brevis Network ve nil Foundation'dır. Uygulamaların birden fazla blok zincirinde durum farkındalığına sahip hale getirilmesi için önemli çaba sarf edilirken, IBC (Inter Blockchain Communication), ICQ (Interchain querys) ve ICA (Interchain Accounts) gibi uygulamalara olanak tanıyan bir birlikte çalışabilirlik standardı olarak öne çıkıyor. ICQ, A Zincirindeki uygulamaların, sorguyu basit bir IBC paketine dahil ederek B zincirinin durumunu sorgulamasına olanak tanır ve ICA, bir blockchain'in başka bir blockchain üzerindeki bir hesabı güvenli bir şekilde kontrol etmesine olanak tanır. Bunları birleştirmek ilginç zincirler arası kullanım senaryolarını mümkün kılabilir. Saga gibi RaaS sağlayıcıları, IBC'yi kullanarak bu işlevleri varsayılan olarak tüm uygulama zincirlerine sunar.

Bellek tüketimi, kanıtlama süresi, doğrulama süresi, bilgi işlem verimliliği ve geliştirici deneyimi arasında doğru dengeyi bulmak için depolama kanıtlarının optimize edilebileceği birçok yol vardır. Genel süreç genel olarak 3 ana alt sürece ayrılabilir.

• Veri erişimi
• Veri işleme
• Veri erişimi ve işleme için ZK Proof üretimi

Veri erişimi: Bu alt süreçte servis sağlayıcı, kaynak zincirinin blok başlıklarına yerel olarak yürütme katmanından veya zincir içi bir önbellek sağlayarak erişir. Zincirler arası veri erişimi için hedef zincirdeki kaynak zinciri konsensüsünün doğrulanması gerekir. Benimsenen yaklaşımlardan ve optimizasyonlardan bazıları şunlardır:

• Mevcut Ethereum Blok Zinciri: Ethereum blok zincirinin mevcut yapısı, ZKP kullanılarak mevcut blok başlığına göre herhangi bir tarihsel depolama yuvasının değerini kanıtlamak için kullanılabilir. Bu, büyük bir dahil edilme kanıtı olarak düşünülebilir. Bu, b yüksekliğinde yeni bir blok başlığı X verildiğinde, bk yüksekliğinde X'in atası olan Y blok başlığının var olduğunun kanıtıdır. Ethereum'un fikir birliğinin güvenliğine dayanır ve verimlilik için kendini hızlı kanıtlayan bir sistem gerektirir. Lagrange'ın kullandığı yaklaşım budur.
• Zincir içi Merkle Sıradağları (MMR) önbelleği: Bir Merkle Sıradağları, iki ağaç aynı boyuta ulaştığında ayrı Merkle ağaçlarının birleştirildiği Merkle ağaçlarının bir listesi olarak görüntülenebilir. MMR'deki bireysel Merkle ağaçları, ağaçların önceki köklerine ana düğümler eklenerek birleştirilir. MMR, özellikle büyük veri kümelerinden sıralı verileri okurken öğelerin verimli bir şekilde eklenmesi ve verimli veri sorguları gibi bazı ek avantajlara sahip olan Merkle ağaçlarına benzer bir veri yapısıdır. Merkle ağacı aracılığıyla yeni başlıklar eklemek, her seviyedeki tüm kardeş düğümlerin geçmesini gerektirir. Verileri verimli bir şekilde eklemek için Axiom, zincirdeki blok başlıklarının karmasının önbelleğini korumak için MMR'yi kullanır. Herodot, MMR blok hash toplayıcısının kök karmasını zincir üzerinde saklar. Bu, dahil edilme kanıtları aracılığıyla getirilen verileri bu blok başlığı karmalarına göre kontrol etmelerine olanak tanır. Bu yaklaşım, önbelleğin düzenli olarak güncellenmesini gerektirir ve merkezi değilse canlılık endişelerini beraberinde getirir.
• Herodot iki farklı MMR'ye sahiptir. Belirli blok zincirine veya katmana bağlı olarak akümülatörler, farklı karma işlevlerini kullanacak şekilde özelleştirilebilir, böylece verimlilik ve hesaplama maliyetleri optimize edilebilir. Starknet'te kanıtlamak için poseidon karması kullanılabilir ancak EVM zincirleri için Keccack karması kullanılabilir.
• Zincir dışı MMR önbelleği: Herodot, verilerin tekrar istenmesi durumunda daha hızlı getirilebilmesini sağlamak için önceden getirilen sorguların ve sonuçların zincir dışı bir önbelleğini tutar. Bu, yalnızca bir arşiv düğümünü çalıştırmaktan daha fazla ek altyapı gerektirir. Zincir dışı altyapıda yapılan optimizasyonlar, son kullanıcı için maliyetleri potansiyel olarak azaltabilir.
• Depolama için özel blockchain: Brevis, onayladıkları tüm zincirlerin tüm blok başlıklarını depolamak için özel bir ZK toplamasına (toplama katmanı) güveniyor. Bu toplama katmanı olmadan, her zincirin diğer zincirlerin blok başlıklarını saklaması gerekir, bu da N blok zinciri için O(N2) "bağlantıları" ile sonuçlanır. Bir toplama katmanı eklendiğinde, her blok zincirinin yalnızca toplama için durum kökünü depolaması gerekir, bu da O(N) ile olan genel bağlantıları azaltır. Bu katman aynı zamanda blok başlıkları/sorgu sonuçları için birden fazla kanıtı bir araya getirmek için kullanılır ve bağlı her blok zincirinde doğrulama için tek bir kanıt gönderilebilir.
• L1-L2 mesajının iletilmesi: L2'ler L1'de L2 sözleşmelerinin güncellenmesi için yerel mesajlaşmayı desteklediğinden, L2'ler durumunda kaynak zinciri konsensüsünün doğrulanması önlenebilir. Önbellek Ethereum üzerinde güncellenebilir ve L1-L2 mesaj aktarımı, blok karmasını veya zincir dışında derlenen ağacın kökünü diğer L2'lere göndermek için kullanılabilir. Herodot bu yaklaşımı benimsiyor ancak bu, diğer L1'ler için mümkün değil.

Veri işleme:

Akıllı sözleşmeler, verilere erişimin yanı sıra veriler üzerinde keyfi hesaplamalar da yapabilmelidir. Bazı kullanım durumları hesaplama gerektirmese de diğer birçok kullanım durumu için önemli bir katma değerli hizmettir. Hesaplamanın zk kanıtı oluşturulabildiğinden ve geçerlilik için zincir üzerinde sağlanabildiğinden, hizmet sağlayıcıların çoğu veriler üzerinde hesaplamalara izin verir. Axelar, LayerZero, Polyhedra Network gibi mevcut AMP çözümleri veri erişimi için potansiyel olarak kullanılabildiğinden, veri işleme, depolamaya dayanıklı hizmet sağlayıcılar için farklılaştırıcı bir unsur haline gelebilir.

Örneğin Hyper Oracle, geliştiricilerin JavaScript ile özel zincir dışı hesaplamalar tanımlamasına olanak tanır. Brevis, dApp'lerden gelen veri sorgularını kabul eden ve bunları onaylanmış blok başlıklarını kullanarak işleyen açık bir ZK Sorgu Motorları pazarı tasarladı. Akıllı sözleşme, pazardaki bir kanıtlayıcı tarafından alınan bir veri sorgusu gönderir. Prover, sorgu girişine, ilgili blok başlıklarına (Brevis toplama katmanından) ve sonuçlara dayalı bir kanıt oluşturur. Lagrange, SQL, MapReduce ve Spark/RDD gibi dağıtılmış programlama modellerini kanıtlamak için ZK Büyük Veri Yığını'nı tanıttı. Kanıtlar modülerdir ve mevcut zincirler arası köprülerden ve AMP protokollerinden kaynaklanan herhangi bir blok başlığından oluşturulabilir. Lagrange ZK BigData yığınındaki ilk ürün olan ZK MapReduce, büyük miktarda çok zincirli veri kümelerini içeren hesaplama sonuçlarını kanıtlamaya yönelik dağıtılmış bir hesaplama motorudur (iyi bilinen MapReduce programlama modeline dayalı). Örneğin, tek bir ZKMR kanıtı, belirli bir zaman penceresi boyunca 4-5 zincire dağıtılan bir DEX'in likiditesindeki değişiklikleri kanıtlamak için kullanılabilir. Nispeten basit sorgular için hesaplama, şu anda Herodot tarafından yapıldığı gibi doğrudan zincir üzerinde de yapılabilir.

Kanıt oluşturma:

• Güncellenebilir kanıtlar: Güncellenebilir kanıtlar, bir kanıtın hareketli bir blok akışı üzerinde hesaplanması ve verimli bir şekilde sürdürülmesi gerektiğinde kullanılabilir. Bir dapp, yeni bloklar oluşturulurken bir sözleşme değişkeni (token fiyatı gibi) için hareketli ortalamaya yönelik bir kanıt sağlamak istediğinde, yeni kanıtı sıfırdan yeniden hesaplamadan mevcut kanıtlar verimli bir şekilde güncellenebilir. Zincir içi bir durumda dinamik veri paralel hesaplamasını kanıtlamak için Lagrange, MPT'nin bir kısmının üstüne Recproof adı verilen bir toplu vektör taahhüdü oluşturur, onu anında günceller ve bunun üzerinden dinamik olarak hesaplama yapar. Lagrange, MPT'nin üzerinde yinelemeli olarak bir Verkle ağacı oluşturarak, büyük miktarlarda dinamik zincir içi durum verilerini verimli bir şekilde hesaplayabiliyor.
• Verkle Ağaçları: Bir ebeveyni paylaşan tüm düğümleri sağlamamız gereken Merkle ağaçlarından farklı olarak Verkle Ağaçları yalnızca köke giden yolu gerektirir. Bu yol, Merkle ağacındaki tüm kardeş düğümlerle karşılaştırıldığında çok daha küçüktür. Ethereum ayrıca, Ethereum tam düğümlerinin tutması gereken durum miktarını en aza indirmek için gelecekteki sürümlerde Verkle ağaçlarının kullanımını da araştırıyor . Brevis, onaylanmış blok başlıklarını ve sorgulama sonuçlarını toplama katmanında depolamak için Verkle Tree'den yararlanıyor. Özellikle ağaç çok sayıda öğe içerdiğinde veri ekleme kanıt boyutunu önemli ölçüde azaltır ve aynı zamanda bir veri kümesi için etkili ekleme kanıtını destekler.
• Daha hızlı kanıt üretimi için bellek havuzu izleme: Herodot yakın zamanda geliştiricilerin veri sorgusunu belirlemek için akıllı sözleşme kodlarına birkaç satır kod eklemelerine olanak tanıyan turboyu duyurdu. Herodot, turbo sözleşmeyle etkileşime giren akıllı sözleşme işlemleri için bellek havuzunu izler. Kanıt oluşturma süreci, işlem bellek havuzunda olduğunda başlar. Kanıt zincir üzerinde oluşturulup doğrulandıktan sonra sonuçlar, zincir üstü turbo takas sözleşmesine yazılır. Sonuçlar yalnızca depolama kanıtlarıyla doğrulandıktan sonra turbo takas sözleşmesine yazılabilir. Bu gerçekleştiğinde, işlem ücretlerinin bir kısmı sıralayıcı veya blok oluşturucu ile paylaşılır ve bu da onları ücretleri toplamak için biraz daha beklemeye teşvik eder. Basit veri sorguları için, kullanıcıdan gelen işlem bloğa dahil edilmeden önce talep edilen verinin zincir üzerinde kullanıma sunulması mümkündür.

Durum/depolama kanıtlarının uygulanması

Durum ve depolama kanıtları, uygulama, ara yazılım ve altyapı katmanındaki akıllı sözleşmeler için birçok yeni kullanım durumunun kilidini açabilir. Bunlardan bazıları:

Uygulama katmanı:

Yönetim:

• Zincirler Arası Oylama: Zincir içi bir oylama protokolü, B Zinciri'ndeki kullanıcıların A Zinciri'ndeki varlıkların sahipliğini kanıtlamalarına olanak tanıyabilir. Kullanıcıların yeni bir zincirde oylama gücü kazanmak için varlıkları arasında köprü kurması gerekmeyecek. Örnek: Herodot'ta SnapshotX
• Yönetişim belirteci dağıtımı: Uygulamalar, aktif kullanıcılara veya erken benimseyenlere daha fazla yönetişim belirteci dağıtabilir. Örnek: Lagrange'da RetroPGF

Kimlik ve İtibar:

• Sahiplik kanıtı: Bir kullanıcı, A zincirindeki belirli bir NFT, SBT veya varlıkların mülkiyetine dair kanıt sağlayarak B Zincirinde belirli eylemleri gerçekleştirmesine olanak sağlayabilir. Örneğin, bir oyun uygulama zinciri, NFT koleksiyonunu şu adreste başlatmaya karar verebilir: Ethereum veya herhangi bir L2 gibi mevcut likiditeye sahip başka bir zincir. Bu, oyunun başka bir yerde var olan likiditeden yararlanmasına ve NFT'lerin köprülenmesine gerek kalmadan NFT yardımcı programı arasında köprü kurmasına olanak tanıyacak.
• Kullanım kanıtı: Kullanıcılara, platformun geçmiş kullanımlarına bağlı olarak indirimler veya premium özellikler verilebilir (Uniswap'te kullanıcı tarafından işlem gören X hacminin kanıtlanması)
• OG Kanıtı: Bir kullanıcı, X günden daha eski bir aktif hesaba sahip olduğunu kanıtlayabilir
• Zincir içi kredi puanı: Çok zincirli bir kredi puanı platformu, bir kredi puanı oluşturmak için tek bir kullanıcının birden fazla hesabından verileri toplayabilir

Yukarıdaki kanıtların tümü, kullanıcılara özelleştirilmiş bir deneyim sağlamak için kullanılabilir. Dapps, deneyimli yatırımcıları veya kullanıcıları elde tutmak için indirimler veya ayrıcalıklar sunabilir ve acemi kullanıcılar için basitleştirilmiş bir kullanıcı deneyimi sunabilir.

Kesinlikle:

• Zincirler arası borç verme: Kullanıcılar, varlıkları Zincir A'da kilitleyebilir ve tokenlar arasında köprü oluşturmak yerine Zincir B'den kredi alabilir
• Zincir üstü sigorta: Arızalar, zincir üzerindeki geçmiş verilere erişilerek belirlenebilir ve sigorta tamamen zincir üzerinde çözülebilir.
• Havuzdaki varlık fiyatının TWAP'i: Bir uygulama, belirli bir süre boyunca bir AMM havuzundaki varlığın ortalama fiyatını hesaplayabilir ve getirebilir. Örnek: Axiom ile Uniswap TWAP Oracle
• Opsiyon fiyatlandırması: Zincir içi bir opsiyon protokolü, merkezi olmayan bir borsada bir varlığın geçmiş n bloktaki volatilitesini kullanarak bir opsiyonu fiyatlandırabilir.

Son iki kullanım durumu, kaynak zincirine her yeni blok eklendiğinde kanıtın güncellenmesini gerektirecektir.

Ara yazılım:

• Amaçlar: Depolama kanıtları, kullanıcıların niyetlerini daha açık ve net ifade etmelerine olanak tanır. Kullanıcının amacını gerçekleştirmek için gerekli adımları uygulamak çözümleyicilerin işi olsa da, kullanıcı zincir içi verilere ve parametrelere dayalı olarak koşulları daha net bir şekilde belirleyebilir. Çözücüler aynı zamanda en uygun çözümü bulmak için kullanılan zincir üstü verilerin geçerliliğini de kanıtlayabilir.
• Hesap Soyutlama: Kullanıcılar, Hesap Soyutlama aracılığıyla kuralları belirlemek için depolama kanıtlarını kullanan diğer zincirlerden gelen verilere güvenebilirler. Örnek: Her cüzdanın bir nonce’ı vardır. Bir yıl önce nonce'ın belirli bir sayı olduğunu ve şu anda nonce'nin aynı olduğunu kanıtlayabiliriz. Bu, bu cüzdanın hiç kullanılmadığını kanıtlamak için kullanılabilir ve daha sonra cüzdana erişim başka bir cüzdana devredilebilir.
• Zincir İçi Otomasyon: Akıllı sözleşmeler, zincir içi verilere bağlı olan önceden tanımlanmış koşullara dayalı olarak belirli eylemleri otomatikleştirebilir. AMM'nin optimum fiyat akışını sürdürmek veya sorunlu borçlardan kaçınarak borç verme protokollerini sağlıklı tutmak için belirli aralıklarla akıllı sözleşmelerin çağrılması için otomatik programlara ihtiyaç vardır. Hyper Oracle, zincir üstü verilere erişimin yanı sıra otomasyona da olanak tanır.

Altyapı

• Güvenilmez zincir üstü Oracle: Merkezi olmayan oracle ağları, bir oracle ağı içindeki çok sayıda bireysel oracle düğümünden gelen yanıtları toplar. Oracle Networks bu fazlalığı ortadan kaldırabilir ve zincirdeki veriler için kriptografik güvenlikten yararlanabilir. Oracle ağı, birden fazla zincirden (L1'ler, L2'ler ve alt L1'ler) verileri tek bir zincire alabilir ve başka yerlerdeki depolama kanıtlarını kullanarak varlığını kanıtlayabilir. Önemli çekiş gücüne sahip DeFi çözümleri, özel bir çözüm üzerinde de çalışabilir. Örneğin, en büyük likidite staking sağlayıcısı olan Lido Finance, zkOracle'ın gelişimini finanse etmek için Nil Vakfı ile işbirliği yaptı. Çözümler, EVM içi geçmiş verilere güvenilir veri erişimi sağlayacak ve Lido Finance hisseli Ethereum likiditesinde 15 milyar dolar güvence altına alacak.
• AMP Protokolleri: Mevcut AMP çözümleri, depolamaya dayanıklı hizmet sağlayıcılarla ortaklık kurarak mesajlarının ifade edilebilirliğini artırabilir. Bu, Lagrange'ın Modüler Tez makalesinde önerdiği bir yaklaşımdır.

Çözüm

Farkındalık, teknoloji şirketlerinin müşterilerine daha iyi hizmet vermelerini sağlar. Teknoloji şirketleri, kullanıcı kimliğinden satın alma davranışına ve sosyal grafiklere kadar hassas hedefleme, müşteri segmentasyonu ve viral pazarlama gibi yeteneklerin kilidini açmak için farkındalıktan yararlanıyor. Geleneksel teknoloji şirketlerinin, kullanıcılarından açık izin alması gerekiyor ve kullanıcı verilerini yönetirken dikkatli olmaları gerekiyor. Bununla birlikte, izinsiz blok zincirlerdeki tüm kullanıcı verileri, kullanıcı kimliğinin açıklanmasına gerek kalmadan kamuya açıktır. Akıllı sözleşmeler, kullanıcılara daha iyi hizmet verebilmek için kamuya açık verilerden yararlanabilmelidir. Daha uzmanlaşmış ekosistemlerin geliştirilmesi ve benimsenmesi, zaman içinde devlet farkındalığını ve blok zincirlerini çözülmesi gereken giderek daha önemli bir sorun haline getirecektir. Depolama kanıtları, Ethereum'un bir yerleşim katmanı olmanın yanı sıra bir kimlik ve varlık sahipliği katmanı olarak ortaya çıkmasını sağlayabilir. Kullanıcılar, varlıkları her zaman köprülemeden birden fazla blok zincirinde kullanılabilecek kimliklerini ve önemli varlıklarını Ethereum'da tutabilirler. Gelecekte açılacak yeni olanaklar ve kullanım durumları konusunda heyecanımızı sürdürmeye devam ediyoruz.

Yasal Uyarı:

1. Bu makale [orta]'dan yeniden basılmıştır. Tüm telif hakları orijinal yazara [LongHash Ventures] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.