Gizlilik serimizin 1. bölümü'gizlilik'ın ne anlama geldiğini, blok zinciri ağlarında gizliliğin web2 gizliliğinden nasıl farklı olduğunu ve neden blok zincirlerinde bunun başarılmasının zor olduğunu kapsadık.

Bu gönderinin ana argümanı, arzulanabilir son durumun, herhangi bir tek nokta arızası olmadan paylaşılan özel durumu işleyebilen programlanabilir gizlilik altyapısına sahip olmak olduğunu savunmaktadır ve bu durumda tüm yollar MPC'ye çıkar. Ayrıca MPC'nin olgunluğunu ve güven varsayımlarını araştırıyor, alternatif yaklaşımları vurguluyor, karşılaştırmalı avantajları karşılaştırıyor ve endüstri genel bir bakış sunuyor.

Hepimiz aynı şeyi mi inşa ediyoruz? Devam etmek için okumaya devam et.

TeşekkürlerAvishay (SodaLabs)Lukas (Taceo), Michael (Dengede) veNico (Arcium) bu gönderiyi şekillendiren tartışmalar için.

Geçmişten Arındırılmış Olabilen Şey Nedir

Mevcut blok zincirlerindeki gizlilik altyapısı, özel ödemeler veya oy verme gibi çok belirli kullanım durumlarıyla başa çıkmak üzere tasarlanmıştır. Bu oldukça dar bir görüş ve çoğunlukla blok zincirlerinin şu anda kullanıldığı şeyleri yansıtır (ticaret, transferler ve spekülasyon). Tom Walpo söyledi - Kripto bir Fermi Paradoksu'ndan muzdarip:

Bireysel özgürlüğü artırmanın yanı sıra, gizliliğin blok zincirlerinin tasarım alanını mevcut spekülatif metanın ötesine genişletmek için bir ön koşul olduğuna inanıyoruz. Birçok uygulamanın düzgün çalışması için bazı özel durum ve/veya gizli mantık gerekir:

• Gizli durum: Finansal kullanım durumlarının büyük çoğunluğu en azından diğer kullanıcılardan gizlilik gerektirir ve birçok çok oyunculu oyun bazı gizli durum olmadan oynanması önemli ölçüde daha az eğlenceli olur (örneğin, poker masasındaki herkes birbirinin kartlarını görebilirse).
• Gizli mantık: Bazı kullanım durumları, uygulamayı kullanmasına izin verirken bazı mantığı gizleme gerektirir, örneğin eşleşme motoru, zincir üstü ticaret stratejisi vb.

Deneysel analiz (hem web2 hem de web3'ten) çoğu kullanıcının ek gizlilik için ekstra ödeme yapmaya veya ek döngülere girmeye istekli olmadığını gösteriyor ve gizlilik tek başına bir satış noktası olmadığını kabul ediyoruz. Bununla birlikte, blok zincirlerinin üstünde yeni ve (umuyoruz ki) daha anlamlı kullanım durumlarının var olmasını sağlar - Fermi Paradoksu'ndan çıkmamıza izin verir.

Gizlilik artırıcı teknolojiler (GAT'lar) ve modern kriptografi çözümleri (“programlanabilir kriptografi“) bu vizyonu gerçekleştirmek için temel yapı taşlarıdır (bkz. ekdaha fazla bilgi için mevcut farklı çözümler ve bunların avantajlarını ve dezavantajlarını içeren).

Görüşlerimizi Şekillendiren Üç Hipotez

Üç temel hipotez, blok zincirlerinde gizlilik altyapısının nasıl evrimleşebileceğine dair görüşlerimizi şekillendiriyor.

1. Kriptografi, uygulama geliştiricilerinden soyutlanacak: Çoğu uygulama geliştiricisi, gizlilik için gereken kriptografi ile uğraşmak istemez (veya nasıl yapılacağını bilmez). Kendi kriptografilerini uygulamak ve özel uygulama zincirleri oluşturmak (örneğin,Zcash veya Namada) veya genel bir zincirin üstündeki özel uygulamalar (ör. Tornado Cash). Bu, şu anda çoğu geliştirici için tasarım alanını kısıtlayan çok fazla karmaşıklık ve ek yüktür (bazı gizlilik garantileri gerektiren uygulamalar oluşturamaz). Bu nedenle, kriptografi bölümünü yönetmenin karmaşıklığının uygulama geliştiricilerinden soyutlanması gerektiğine inanıyoruz. Buradaki iki yaklaşım, programlanabilir gizlilik altyapısı (paylaşılan özel L1/L2) veya gizli bilgi işlemin dış kaynak kullanımını sağlayan "hizmet olarak gizlilik"tir.
2. Birçok kullanım durumu (muhtemelen düşündüğümüzden daha fazla) paylaşılan özel bir duruma ihtiyaç duyar: Daha önce belirtildiği gibi, birçok uygulama düzgün çalışabilmesi için bazı gizli durum ve/veya mantık gerektirir. Paylaşılan özel durum bunun bir alt kümesidir, burada birden fazla taraf aynı özel durum parçası üzerinde hesaplama yapar. Merkezi bir tarafın bunu yapması için güvenebiliriz ve işi bitirebiliriz, ancak tek noktada başarısız olmamak için güveni en aza indirmek istiyoruz. Sıfır bilgi kanıtları (ZKP) bunu tek başına başaramaz - bu gibi durumları başarmak için güvenilir yürütme ortamları (TEE), tam homomorfik şifreleme (FHE) ve/veya çoklu taraf hesaplaması (MPC) gibi ek araçlardan yararlanmamız gerekmektedir.
3. Daha büyük korumalı setler gizliliği maksimum düzeye çıkarır: En çok bilgi açığa çıkarılırken giriş veya çıkış yapmaKorunan set, bu yüzden bunu en aza indirmeye çalışmalıyız. Aynı blok zinciri üzerinde inşa edilmiş birden fazla özel uygulamanın olması, aynı korunan set içindeki kullanıcı ve işlemlerin sayısını artırarak gizlilik garantisini güçlendirebilir.

Gizlilik Altyapısının Son Oyunu

Yukarıdaki hipotezler göz önünde bulundurulduğunda - blok zincirlerinde gizlilik altyapısı için son oyun nedir? Her uygulama için uygun olan tek bir yaklaşım var mı? Onları yönetecek tek bir gizlilik geliştirme teknolojisi var mı?

Tam olarak değil. Tüm bunlar farklı ödünler içeriyor ve zaten çeşitli şekillerde birleştirildiklerini görüyoruz. Toplamda, 11 farklı yaklaşım belirledik (bkz.ek).

Bugün, blok zincirlerinde gizlilik altyapısı oluşturmak için en popüler iki yaklaşım ZKPs veya FHE kullanmaktır. Bununla birlikte, her ikisinin de temel kusurları vardır:

• ZK-tabanlı gizlilik protokolleri istemci tarafından kanıtlama ile güçlü gizlilik garantileri sunabilir, ancak aynı özel durum üzerinde birden fazla tarafın hesaplama yapmasına izin vermez. Bu, ifade yeteneğini, yani geliştiricilerin hangi tür uygulamaları oluşturabileceğini sınırlar.
• FHE, şifreli veri ve paylaşılan özel durum üzerinde hesaplama yapmayı mümkün kılar, ancak bu durumun sahibi olan, yani şifre çözme anahtarını kimin elinde tuttuğu sorusunu ortaya çıkarır. Bu, gizlilik garantilerinin gücünü sınırlar ve bugün özel olanın yarın da özel kalacağına ne kadar güvenebileceğimizi belirler.

Eğer arzulanabilir son durum, tek bir başarısızlık noktası olmadan paylaşılan özel durumu işleyebilen programlanabilir gizlilik altyapısına sahip olmaksa, o zaman her iki yol da MPC'ye çıkar:

Dikkat edin, bu iki yaklaşım sonunda birleşse de, MPC farklı şeyler için kaldıraçlı kullanılır:

• ZKP ağları: MPC, paylaşılan özel bir durum üzerinde hesaplama yaparak ifade yeteneği eklemek için kullanılır.
• FHE ağları: Güvenliği artırmak ve gizlilik garantilerini güçlendirmek için, şifre çözme anahtarını tek bir üçüncü taraf yerine bir MPC komitesine dağıtarak MPC kullanılır.

Tartışma daha nüanslı bir bakışa doğru kaymaya başlarken, farklı yaklaşımların arkasındaki garantiler henüz yeterince araştırılmamış durumda. Güven varsayımlarımız MPC'nin varsayımlarına indirgendiğinden, sormamız gereken üç temel soru şunlar:

1. MPC protokollerinin blok zincirlerinde sağlayabileceği gizlilik garantileri ne kadar güçlüdür?
2. Teknoloji yeterince olgun mu? Değilse, engelleyen faktörler nelerdir?
3. Söz konusu güvencelerin gücü ve getirdiği ek yük göz önüne alındığında, alternatif yaklaşımlarla karşılaştırıldığında mantıklı mıdır?

Bu soruları daha detaylı ele alalım.

MPC ile Riskleri ve Zayıflıkları Analiz Etmek

Herhangi bir çözüm FHE kullanıyorsa, her zaman sormak gerekir: "Kim şifre çözme anahtarını tutuyor?". Eğer cevap "ağ" ise, takip eden soru şudur: "Bu ağı oluşturan gerçek varlıklar hangileridir?". Sonraki soru, bazı şekil veya formda MPC'ye güvenen tüm kullanım durumları için relevanttir.

Kaynak: Zama ETH CC'de konuşuyor

MPC ile ilgili ana risk, yeterli sayıda tarafın kötü niyetli olarak hareket ederek verileri şifrelemek veya hesaplamayı yanlış kullanmak için işbirliği yapmasıdır. İşbirliği, zincir dışında anlaşılabilir ve kötü niyetli tarafların açıkça bir şey yapması durumunda (şantaj yapmak, havada token basmak vb.) ortaya çıkar. Söylemeye gerek yok, bu, sistem tarafından sağlanan gizlilik garantileri üzerinde önemli etkileri olan bir durumdur. İşbirliği riski şuna bağlıdır:

• Protokolün dayanabileceği kötü niyetli taraf eşiği nedir?
• Ağdaki taraflar kimlerdir ve ne kadar güvenilirler?
• Ağda yer alan farklı tarafların sayısı ve dağılımları - Ortak saldırı vektörleri var mı?
• Ağ izinsiz mi yoksa izinli mi (ekonomik pay vs itibar/hukuk temelli)?
• Kötü niyetli davranışlar için ceza nedir? Oyun teorik olarak en iyi sonuç olarak anlaşma yapmak mıdır?

1. Blok zincirlerinde MPC protokolleri ne kadar güçlü gizlilik garantileri sağlayabilir?

Özet: Tek merkezi üçüncü tarafa güvenmekten daha güçlü olmasa da istediğimiz kadar güçlü değil.

Şifre çözmek için gereken eşik, büyük ölçüde canlılık ('garantili çıktı teslimi') ve güvenlik arasında bir tercih olan MPC şemasına bağlıdır. Bir düğüm yalnızca çevrimdışı olduğunda bozulan çok güvenli ancak N/N şemasına sahip olabilirsiniz. Öte yandan, daha sağlam olan N/2 veya N/3 şemaları daha fazla işbirliği riskine sahip olmasına rağmen.

Dengelenmesi gereken iki koşul vardır:

1. Gizli bilgiler asla sızdırılmaz (örneğin, şifre çözme anahtarı)
2. Gizli bilgi asla kaybolmaz (hatta tarafların 1/3'ü aniden ayrılsa bile).

Seçilen şema, uygulamalara göre değişir. Örneğin, Zama N/3'e odaklanıyor, Arcium ise şu anda bir N/N şemasıancak daha sonra daha yüksek canlılık garantileri (ve daha büyük güven varsayımları) olan şemaları da desteklemeyi hedefliyor.

Bu ödünleşme sınırı boyunca bir uzlaşma, karma bir çözüme sahip olmaktır:

• Anahtar işlemlerini yapan yüksek güvenilirlikteki komite, örneğin N/3 eşiği ile çalışır.
• Döner nitelikte ve örneğin N-1 eşik değerine sahip hesaplama komiteleri (veya kullanıcıların seçebileceği farklı özelliklere sahip birden fazla hesaplama komitesi).

Bu teoride çekici olsa da, aynı zamanda hesaplama komitesinin yüksek güven komitesiyle nasıl etkileşimde bulunacağı gibi ek karmaşıklıklar da ortaya çıkar.

Güvenlik garantilerini güçlendirmenin başka bir yolu, anahtar paylaşımlarının güvenli bir kripta saklandığı güvenilir donanım içinde MPC'nin çalıştırılmasıdır. Bu, protokol tarafından tanımlandığından başka bir şey için anahtar paylaşımlarının çıkarılmasını veya kullanılmasını daha zor hale getirir. En azındanZamaveArciumTEE açısını keşfediyorlar.

Daha ince riskler, örneğin bir üst düzey mühendis MPC kümesine dahil olan tüm şirketler tarafından 10-15 yıl boyunca istihdam edildiği sosyal mühendislik gibi durumlar etrafında oluşabilir.

2. Teknoloji yeterince olgun mu? Değilse, engeller nelerdir?

Performans açısından, MPC'nin ana zorluğu iletişim fazlasıdır. Hesaplamanın karmaşıklığı ve ağdaki düğüm sayısı ile birlikte artar (daha fazla geriye ve ileriye iletişim gereklidir). Blok zinciri kullanım durumları için, bu iki pratik sonuca yol açar:

1. Küçük işletmeci seti: İletişim yükünü yönetilebilir tutmak için, mevcut çoğu protokol şu anda küçük işletmeci setlerine sınırlıdır. Örneğin, Zama'nın şifre çözme ağı şu anda en fazla 4 düğüm (ancak 16'ya genişletmeyi planladıkları) izin verir. Zama'nın şifre çözme ağı (TKMS) için yayımlanan ilk performans ölçümlerine göre, sadece 4 düğümlü bir kümeyle bile şifre çözmenin 0.5-1 saniye sürdüğü görülmüştür (tam e2e işlemi çok daha uzun sürer). Başka bir örnek ise Taceo'nun ...Dünya para birimi iris veritabanı için MPC uygulaması, 2/3 dürüst parti varsayımıyla 3 tarafı olan

1. Kaynak: Zama ETH CC'de konuşuyor
2. İzinli operatör kümesi: Çoğu durumda, operatör kümesi izinlidir. Bu, ekonomik veya kriptografik güvenlik yerine itibar ve yasal sözleşmelere dayandığımız anlamına gelir. İzinli olmayan bir operatör kümesiyle ilgili ana zorluk, insanların zincir dışında işbirliği yapılıp yapılmadığını bilmememizdir. Ayrıca, düğümlerin ağa dinamik olarak girebilmesi/çıkabilmesi için düzenli olarak anahtar payının yeniden dağıtılması veya yeniden başlatılmasını gerektirir. İzinli olmayan operatör kümeleri son hedef olsa da ve Zama tarafından bir eşik MPC için PoS mekanizmasını nasıl genişleteceği üzerine sürekli araştırmalar yapılsa da, şu anda izinli yol en iyi ilerleme şekli gibi görünmektedir.

Alternatif Yaklaşımlar

Tamamen gizlilik kokteyli şunlardan oluşur:

• Delege edilmiş özel hesaplama için FHE
• FHE hesaplamanın doğru bir şekilde yürütüldüğünü doğrulamak için ZKP
• Eşik deşifre için MPC
• Her MPC düğümü ek güvenlik için bir TEE içinde çalışır.

Bu karmaşık, keşfedilmemiş birçok kenar durumunu ortaya çıkarıyor, yüksek işletme maliyetine sahip ve yakın gelecekte birçok yönüyle pratikte mümkün olmayabilir. Başka bir risk, birbirlerinin üstüne eklenen birden fazla karmaşık kavramın eklenmesinden kaynaklanan yanlış güven duygusudur. Daha fazla karmaşıklık ve güven varsayımları ekledikçe, genel çözümün güvenliği hakkında akıl yürütme daha da zorlaşır.

Buna değer mi? Belki, ancak yalnızca biraz daha zayıf gizlilik garantileri pahasına önemli ölçüde daha iyi hesaplama verimliliği sağlayabilecek alternatif yaklaşımları keşfetmeye değer. Gibi Seismic'ten Lyronnoted - gereken gizlilik düzeyi için kriterlerimizi karşılayan en basit çözüme odaklanmalı ve sadece bunun için aşırı mühendislik yapmak yerine kabul edilebilir uzlaşmalara odaklanmalıyız.

1. Genel Hesaplama İçin MPC'yi Doğrudan Kullanma

Eğer hem ZK hem de FHE sonunda MPC'nin güven varsayımlarına geri dönüyorsa, neden hesaplama için doğrudan MPC kullanılmıyor? Bu geçerli bir soru ve gibi takımların da olduğu bir şeyArcium, SodaLabs (kullanılan Cotiv2),Taceo, ve NillionMPC'nin birçok formunu ele alır, ancak üç ana yaklaşımdan biri olarak, burada şifre paylaşımı ve karıştırılmış devre (GC) tabanlı protokollere atıfta bulunuyoruz, şifreleme için MPC kullanan FHE tabanlı protokoller değil.

MPC, dağıtılmış imzalar ve daha güvenli cüzdanlar gibi basit hesaplamalar için zaten kullanılmaktadır, ancak MPC'nin daha genel hesaplama için kullanılmasındaki ana zorluk, iletişim ağırlığıdır (hesaplamanın karmaşıklığı ve dahil olan düğümlerin sayısı ile artar).

Aşırı yükü azaltmanın bazı yolları vardır, örneğin protokolün en pahalı kısımlarını önceden ve çevrimdışı olarak ön işleme yaparak - hem ArciumveSodaLabskeşfediyoruz. Hesaplama daha sonra çevrimiçi aşamada gerçekleştirilir ve çevrimdışı aşamada üretilen verilerin bir kısmı tüketilir. Bu, genel iletişim yükünü önemli ölçüde azaltır.

Aşağıdaki tablo, SodaLabs tarafından gcEVM'de farklı opcode'ların 1.000 kez yürütülme süresini (mikrosaniye cinsinden) gösteren ilk kıyaslama sonuçlarını gösteriyor. Bu doğru yönde atılmış bir adım olsa da, verimliliği artırmak ve operatör setini birkaç düğümden öteye genişletmek için hala çok çalışma gerekiyor.

Kaynak: SodaLabs

ZK tabanlı yaklaşımın faydası, yalnızca paylaşılan özel bir durum üzerinde hesaplama gerektiren kullanım durumları için MPC kullanmanızdır. FHE, daha doğrudan MPC ile rekabet eder ve donanım hızlandırmasına ağırlık verir.

2. Güvenilir Yürütme Ortamları

Son zamanlarda, TEE'lerde yeniden ilgi görülmektedir. Bunlar, izolasyon halinde (TEE tabanlı özel blok zincirleri veya yardımcı işlemciler) veya ZK tabanlı çözümler gibi diğer PET'lerle birlikte (yalnızca paylaşılan özel durum üzerinde hesaplama için TEE kullanma) kullanılabilir.

TEE'ler bazı yönlerden daha olgun olsa da ve daha az performans üstünlüğü getirse de, dezavantajsız değillerdir. İlk olarak, TEE'ler farklı güven varsayımlarına (1/N) sahiptir ve yazılım yerine donanım tabanlı bir çözüm sunar. Sıkça duyulan eleştiri genellikle geçmiştekiSGX'nin zayıflıkları, ancak TEE'nin Intel SGX ile eşit olmadığını belirtmek önemlidir. TEE'ler ayrıca donanım sağlayıcısına güvenmeyi ve donanımın pahalı olmasını gerektirir (çoğu kişiye erişilemez). Fiziksel saldırı riskine bir çözüm, olabilir.uzayda TEE'leri çalıştırınönemli görevler için.

Genel olarak, TEE'ler, yalnızca kısa vadeli gizlilik gerektiren doğrulama veya kullanım durumları için daha uygun görünüyor (eşik şifre çözme, karanlık emir defterleri vb). Kalıcı veya uzun vadeli gizlilik için, güvenlik garantileri daha az çekici görünüyor.

3. Özel DAC ve gizlilik için güvenilir 3. taraflara dayanan diğer yaklaşımlar

Aracılı gizlilik, diğer kullanıcılardan gizlilik sağlayabilir, ancak gizlilik garantileri yalnızca üçüncü bir tarafa güvenmekten gelir (tek hata noktası). "Web2 gizliliğine" (diğer kullanıcılardan gizlilik) benzese de, ek garantilerle (kriptografik veya ekonomik) güçlendirilebilir ve doğru yürütmenin doğrulanmasına izin verebilir.

Özel veri erişilebilirlik komiteleri (DAC'ler) bunun bir örneğidir; DAC üyeleri verileri zincir dışında depolar ve kullanıcılar onlara verileri doğru bir şekilde depolamak ve durum geçiş güncellemelerini uygulamak konusunda güvenir. Bunun başka bir örneği ise Franchise DizgiciTom Walpo tarafından önerildi.

Bu yaklaşım, gizlilik garantilerinde büyük ödünleşimler yapsa da, maliyet ve performans açısından (en azından şimdilik) daha düşük değerli, yüksek performanslı uygulamalar için tek uygun alternatif olabilir. Bir örnek Lens Protokolü, şu anda maliyet ve diğer seçeneklerin getirdiği maliyet ve gereksinimler göz önüne alındığında, gizlilik ve maliyet/performans arasındaki denge muhtemelen makul olacaktır.

4. Gizli Adresler

Gizli adresler, her işlem için yeni bir adres oluşturmak kadar benzer gizlilik garantileri sağlayabilir, ancak işlem arka planda otomatikleştirilir ve kullanıcılardan soyutlanır. Daha fazla bilgi için buraya bakın Vitalik'in genel bakışıveya bufarklı yaklaşımlara derinlemesine bir dalış. Bu alandaki ana oyuncular arasında UmbraveFluidkey.

Gizli adresler, nispeten basit bir çözüm sunarken, temel dezavantajları, genel amaçlı hesaplama için gizlilik garantileri ekleyememeleridir. Bu, yukarıda bahsedilen diğer üç çözümden farklılıklarını ortaya koyar.

Ayrıca, gizlilik garantileri sağladığı gizli adreslerin sağladığı kadar güçlü değil. Anonimlik basit kümeleme analizi, özellikle gelen ve giden transferler benzer bir aralıkta değilse (örneğin $10.000 almak, ancak ortalama olarak günlük işlemlerde $10-100 harcamak). Gizli adreslerle ilgili başka bir zorluk da, bugünün anahtarlarının güncellenmesidir, bu da bu problemle ilgili olarak her bir cüzdan için ayrı ayrı yapılması gerekmektedir (anahtar deposu rollup'ları bu problemle yardımcı olabilir). UX tarafından, gizli adres protokolleri ayrıca hesap soyutlaması veya hesabın ücret jetonuna sahip olmaması durumunda ücretleri karşılamak için bir ödeme ustasını da gerektirir (örneğin ETH).

Tezimizdeki Riskler

Hızlı gelişme temposu ve farklı teknik çözüm seçenekleri etrafındaki belirsizlikler göz önüne alındığında, MPC'nin son çözüm olma tezimize karşı birkaç risk bulunmaktadır. MPC'nin herhangi bir şekilde gerekli olmama nedenleri arasında başlıca sebepler şunlardır:

1. Paylaşılan özel durum, önemsediğimiz kadar önemli değildir: Bu durumda, ZK tabanlı altyapı, daha güçlü gizlilik garantilerine ve FHE'den daha düşük maliyete sahip olduğu için kazanmaya daha hazırdır. ZK tabanlı sistemlerin, özel ödeme protokolü gibi izole kullanım durumları için iyi çalıştığı zaten kullanım örnekleri vardır.Payy.
2. Performansta yapılan fedakarlık, gizlilik garantilerindeki faydaya değmez: Birisi, 2-3 izin verilen taraflı bir MPC ağına olan güven varsayımlarının, tek bir merkezi oyuncudan anlamlı bir şekilde farklı olmadığını ve maliyet/üstünlükteki önemli artışın buna değmeyeceğini iddia edebilir. Bu, özellikle düşük değerli, maliyet duyarlı uygulamalar için (örneğin, sosyal veya oyun) birçok durum için doğru olabilir. Bununla birlikte, yasal sorunlar veya büyük koordinasyon sürtünmesi nedeniyle işbirliğinin şu anda çok pahalı (veya imkansız) olduğu birçok yüksek değerli kullanım durumu da mevcuttur. Sonuncusu, MPC ve FHE tabanlı çözümlerin parladığı yerdir.
3. Özelleşme genel amaçlı tasarıma üstünlük sağlar: Yeni bir zincir inşa etmek ve kullanıcılar ve geliştiriciler topluluğunu başlatmak zordur. Bu nedenle, genel amaçlı gizlilik altyapısı (L1/L2'ler) izlenim sağlamakta zorlanabilir. Başka bir soru özelleşme ile ilgilidir; tek bir protokol tasarımının tam ticaret uzayını kapsaması çok zordur. Bu dünyada, mevcut ekosistemler için gizlilik sağlayan çözümler (hizmet olarak gizlilik) veya özel kullanım durumları (örneğin ödemeler için) öne çıkar. Ancak, uygulama geliştiricilerine bazı kriptografiyi kendilerinin uygulamaları gerektiğinden (soyutlanmış olmaması durumunda) karmaşıklık getirdiği için sonuncusu konusunda şüpheliyiz.
4. Düzenlemeler, gizlilik çözümleri etrafında deney yapmayı engellemeye devam ediyor: Bu, hem gizlilik altyapısı hem de bazı gizlilik garantileri olan uygulamalar inşa eden herkes için bir risktir. Finansal olmayan kullanım durumları daha az düzenleyici riskle karşı karşıya kalır, ancak izinsiz gizlilik altyapısı üzerine inşa edilen şeyleri kontrol etmek zordur (imkansızdır). Muhtemelen teknik sorunları düzenleyici sorunlardan önce çözeceğiz.
5. MPC ve FHE tabanlı şemaların baş aşağı kalma maliyeti, çoğu kullanım durumu için hala çok yüksektir: MPC öncelikle iletişim maliyetinden muzdariptir, FHE takımları ise performanslarını artırmak için donanım ivmesine ağır bir şekilde güvenirler. Ancak, ZK tarafındaki özel donanımın evrimini ekstrapole edebilirsek, üretime hazır FHE donanımına ulaşmadan önce çoğu insanın istediğinden çok daha uzun zaman alacaktır. FHE donanım ivmesi üzerinde çalışan takımlara örnek olarak, Gate.io gibi takımlar verilebilir.Optalysys (Optalysys), fhela, ve Niobyum.

Özet

Sonuç olarak, bir zincir, en zayıf halkası kadar güçlüdür. Programlanabilir gizlilik altyapısı durumunda, güven garantileri, tek bir nokta arızası olmadan paylaşılan özel durumu işleyebilmek istiyorsak MPC (Çok Paydaşlı Hesaplama) güvencelerine dayanır.

Bu yazı MPC'ye karşı eleştirel gibi görünebilir, ancak değildir. MPC, merkezi üçüncü taraflara güvenmekten kaynaklanan mevcut durumda büyük bir iyileştirme sunar. Bizim görüşümüze göre, endüstride yanlış bir güven duygusu ve gözden kaçırılan sorunlar ana sorundur. Bunun yerine, sorunlarla doğrudan başa çıkmalı ve potansiyel riskleri değerlendirmeye odaklanmalıyız.

Ancak, tüm sorunların aynı araçlar kullanılarak çözülmesi gerekmez. MPC'nin son oyun olduğuna inanmamıza rağmen, aşırı yüksek kalması durumunda alternatif yaklaşımlar uygun seçeneklerdir. Her zaman çözmeye çalıştığımız problemlerin belirli ihtiyaç/karakteristiklerine en iyi uyan yaklaşımın ve ne tür fedakarlıklar yapmaya istekli olduğumuzun dikkate alınması her zaman değerlidir.

Dünyanın en iyi çekici bile olsa, her şey bir çivi değildir.

Ek 1: Blok Zincirlerinde Gizlilik İçin Farklı Yaklaşımlar

Gizlilik artırıcı teknolojilerveya PET'ler, yukarıdakilerin bir veya daha fazla yönünü iyileştirmeyi amaçlar. Daha somut olarak, depolama, bilgi işlem ve iletişim sırasında verileri korumak için teknik çözümlerdir.

Seçilebilecek pek çok farklı PET bulunmaktadır, ancak blockchain endüstrisi için en önemlileri üç harfli çorba - ZKP, MPC, FHE ve TEE - ile birlikte gizli adresler gibi ek yöntemlerdir:

Bu PET'ler, farklı ödünleşimler ve güven varsayımları elde etmek için çeşitli şekillerde birleştirilebilir. Ayrıca, özel veri kullanılabilirliği komiteleri (DAC) gibi güvenilir bir üçüncü tarafa (aracılı gizlilik) dayanan çözümlerimiz de vardır. Bunlar, diğer kullanıcılardan gizliliği sağlayabilir, ancak gizlilik garantileri yalnızca üçüncü bir tarafa güvenmekten gelir. Bu anlamda "web2 gizliliğine" (diğer kullanıcılardan gizlilik) benzer, ancak ek garantilerle (kriptografik veya ekonomik) güçlendirilebilir.

Toplamda, blok zinciri ağlarında bazı gizlilik garantilerine ulaşmak için 11 farklı yaklaşım belirledik. Gözlemlenen bazı fedakarlıklar arasında:

• Güvenilirlik karşı Güven-minimized gizlilik (Tek bir başarısızlık noktası var mı?)
• Donanım vs Yazılım yaklaşımı
• İzole örnekler vs birden fazla PET'in kombinasyonu
• L1 vs L2
• Yeni zincir vs mevcut zincirlere ek gizlilik ("hizmet olarak gizlilik")
• Kalkanlı setin boyutu (Çoklu zincir > Tek zincir > Uygulama > Tek varlık)

Ek 2: Endüstri Genel Bakışı

Bu 11 kategori içinde birçok farklı şirket bir veya daha fazla çözüm üzerinde çalışıyor. Aşağıda, endüstrinin mevcut durumuna ilişkin (kapsamlı olmayan) bir genel bakış yer almaktadır:

Açıklama:

1. Bu makale [den yeniden basıldıdengede], Tüm telif hakları orijinal yazarına aittir [Hannes Huitula]. Bu yeniden basım konusunda itirazlarınız varsa, lütfen iletişime geçin.Kapı Öğrenimiekip, ve onlar hızlı bir şekilde bununla ilgilenecekler.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüşler yalnızca yazarın görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.