)

Temel fikirler:

1. FHE, "Kriptografinin Kutsal Kâsesi" olmayı vaat ediyor, ancak mevcut benimsenmesini sınırlayan birçok performans, geliştirici deneyimi ve güvenlik kaygısı var.

2. Yukarıdaki grafikte gösterildiği gibi, gerçek anlamda gizli ve güvenli, paylaşılan bir durum sistemi oluşturmak için FHE'nin ZKP'ler ve MPC ile birlikte kullanılması gerekecektir.

3.FHE hızla gelişiyor; Yeni derleyicilerin, kütüphanelerin, donanımların vb. geliştirilmesi. FHE'nin Web2 şirketlerinin (Intel, Google, DARPA vb.) Ar-Ge'sinden büyük ölçüde yararlandığını belirtmeden geçemeyeceğiz.

4.FHE ve onu çevreleyen ekosistem olgunlaştıkça, “doğrulanabilir FHE'nin” standart haline gelmesini bekliyoruz. FHE uygulamaları, hesaplama ve doğrulama işlemlerini FHE ortak işlemcilerine yaptırmayı tercih edebilir.

5. Zincir içi FHE'nin temel sınırlaması "şifre çözme anahtarını kimde tutuyor?" Eşik şifre çözme ve MPC çözümler sunar, ancak bunlar genellikle performans ve güvenlik dengesine bağlıdır.

Tanıtım:

Blok zincirlerinin şeffaf doğası iki tarafı keskin bir kılıçtır; Açıklığı ve gözlemlenebilirliği güzel olsa da, girişimin benimsenmesinin önünde temel bir engeldir.

Zincir içi gizlilik, neredeyse on yıldır kriptodaki en zorlu sorunlardan biri olmuştur. Zincir içi gizliliği sağlamak için ZK tabanlı sistemler geliştiren birçok ekip olmasına rağmen; paylaşılan, şifrelenmiş durumu destekleyemezler. Neden? Kısa cevap, bu programların bir dizi ZKP'nin bir fonksiyonu olması ve bu nedenle herhangi birinin mevcut duruma keyfi bir mantık uygulamasının imkansız olmasıdır. Bu ne anlama gelir? Temel olarak, yalnızca ZKP'leri kullanarak gizli paylaşılan durum uygulamaları (özel Uniswap'i düşünün) oluşturamayız.

Ancak son gelişmeler, ZKP'leri Tam Homomorfik Şifreleme (FHE) ile birleştirmenin tamamen genelleştirilebilir, gizli DeFi elde edilebileceğini gösterdi. Nasıl? FHE, şifrelenmiş veriler üzerinde keyfi hesaplamaya olanak tanıyan, gelişen bir kriptografi alanıdır (kulağa çılgınca geliyor değil mi?!) Yukarıdaki grafikte gösterildiği gibi, ZKP'ler kullanıcı girişlerinin ve hesaplamanın bütünlüğünü kanıtlayabilir ve FHE hesaplamayı kendisi işleyebilir.

FHE "Kriptografinin Kutsal Kâsesi" olmayı vaat ederken, biz de alanın, çeşitli zorlukların ve olası çözümlerin objektif bir analizini sunmaya çalışıyoruz. Aşağıdaki zincir içi FHE konularını ele alıyoruz:

• FHE Şemaları, Kütüphaneler ve Derleyiciler
• Güvenli Eşik Şifre Çözme
• Kullanıcı Girişleri + Bilgi İşlem Grubu için ZKP'ler
• Programlanabilir, Ölçeklenebilir DA Katmanı
• FHE Donanımı

FHE Şemaları, Kütüphaneler ve Derleyiciler

Zorluk: Yeni Oluşan FHE Şemaları, Kütüphaneler ve Derleyiciler

Zincir içi FHE'nin temel darboğazı, gecikmeli geliştirici araçları/altyapısında yatmaktadır. ZKP'ler veya MPC'den farklı olarak FHE, yalnızca 2009'dan beri ortalıkta ve bu nedenle olgunlaşması için çok daha kısa bir zaman çizelgesine sahip.

FHE DevEx'teki başlıca sınırlamalar şunlardır:

• Geliştiricilerin arka uç kriptografisi hakkında fazla bilgi sahibi olmadan kod yazabilecekleri, kullanımı kolay bir ön uç dili
• Tüm kirli işlerin üstesinden gelebilecek tamamen işlevsel bir FHE derleyicisi. (Parametre seçimi, BGV/BFV için SIMD optimizasyonu ve paralel optimizasyon)
• Mevcut FHE şemaları (özellikle TFHE), düz hesaplamaya kıyasla yaklaşık 1000 kat daha yavaştır

FHE'yi entegre etmenin inceliklerini gerçekten anlamak için geliştirici yolculuğunu inceleyelim:

FHE'yi uygulamanıza entegre etmenin ilk adımı, kullanılacak bir FHE şeması seçmektir. Aşağıdaki tablo birincil şemaları açıklamaktadır:

Yukarıdaki tabloda gösterildiği gibi, FHEW ve TFHE gibi boole devreleri en hızlı önyüklemeye sahiptir ve oldukça karmaşık bir parametre seçim prosedürünün karmaşıklığını ortadan kaldırabilir ve bunlar keyfi/genel hesaplamalarda kullanılabilir ancak nispeten yavaştır; BGV/BFV, yüksek hassasiyetli aritmetik hesaplamalarda daha verimli oldukları için genel DeFi'ye uygun olabilir ancak geliştiricilerin, planın tüm parametrelerini ayarlamak için devrenin derinliğini önceden bilmeleri gerekir. Spektrumun diğer ucunda CKKS, hassas hatalara izin verilen homomorfik çarpmayı destekler ve bu da onu ML gibi hassas olmayan kullanım durumları için ideal hale getirir.

Bir geliştirici olarak, diğer tüm tasarım kararlarını ve gelecekteki performansı etkileyeceği için FHE çözümünü çok dikkatli seçmeniz gerekir. Ek olarak, modül boyutunun seçimi ve polinom derecesinin rolü gibi FHE şemasını doğru şekilde ayarlamak için çok önemli olan birkaç temel parametre vardır.

Kitaplıklara geçersek, popüler FHE kitaplıklarının özellikleri ve yetenekleri aşağıdaki tablodan görülebilir:

Ancak kütüphanelerin şemalar ve derleyicilerle aşağıda gösterildiği gibi farklı ilişkileri de vardır:

FHE çözümünü seçtikten sonra geliştiricilerin parametreleri ayarlaması gerekir. Parametrelerin doğru seçiminin FHE planının performansı üzerinde büyük etkisi olacaktır. Daha da zor olan bu, soyut cebirin, yeniden doğrusallaştırma ve analogdan dijitale geçiş gibi FHE'ye özgü işlemlerin ve aritmetik veya ikili devrelerin biraz anlaşılmasını gerektirir. Son olarak, etkili parametre seçimi için bunların FHE şemasını nasıl etkilediğine dair kavramsal bir anlayış gereklidir.

Bu noktada geliştiriciler şunu sorabilir:

Düz metin alanımın ne kadar büyük olması gerekiyor? Hangi büyüklükteki şifreli metinler kabul edilebilir? Hesaplamayı nerede paralelleştirebilirim? Ve daha fazlası…

Ek olarak, FHE keyfi hesaplamaları desteklese de geliştiricilerin FHE programları yazarken zihniyetlerini değiştirmeleri gerekir. Örneğin programdaki bir değişkene bağlı olarak dal (if-else) yazılamaz çünkü programlar değişkenleri doğrudan düz veri gibi karşılaştıramaz. Bunun yerine, geliştiricilerin kodlarını dallardan tüm dalların koşullarını içerebilecek bir tür hesaplamaya değiştirmeleri gerekiyor. Benzer şekilde bu, geliştiricilerin kodlarında döngüler yazmasını engeller.

Kısacası, FHE konusunda tecrübesiz bir geliştirici için FHE'yi uygulamalarına entegre etmek neredeyse imkansızdır. FHE'nin sunduğu karmaşıklıkları ortadan kaldırmak için önemli düzeyde geliştirme araçları/altyapısı gerekecektir.

Çözüm:

1. Web3'e Özel FHE Derleyicileri

Google ve Microsoft gibi şirketler tarafından oluşturulmuş FHE derleyicileri halihazırda mevcut olsa da bunlar:

• Performans göz önünde bulundurularak tasarlanmamıştır; devreleri doğrudan yazmak yerine 1000 kat ek yük ekler
• CKKS (diğer adıyla ML) için optimize edilmiştir ve DeFi için gereken BFV/BGV açısından faydalı değildir
• Web3 için tasarlanmamıştır. ZKP şemaları, program zincirleme vb. ile uyumluluğu desteklemez.

Ta ki Sunscreen FHE derleyicisine kadar. Donanım hızlandırıcıları olmadan aritmetik işlemler için (DeFi'yi düşünün) en iyi performansın bazılarını sunan bir Web3 yerel derleyicisidir. Yukarıda tartışıldığı gibi parametre seçimi, bir FHE planının uygulanmasının tartışmasız en zor kısmıdır; Sunscreen yalnızca otomatik parametre seçimine sahip değildir, aynı zamanda veri kodlama, anahtar seçimi, yeniden doğrusallaştırma ve modül değiştirme işlemlerini gerçekleştirir, devreleri kurar ve SIMD tarzı işlemleri uygular.

Geleceğe ilerledikçe, yalnızca Sunscreen derleyicisinde değil, aynı zamanda diğer ekiplerin diğer yüksek seviyeli dilleri destekleyen kendi uygulamalarını geliştirmesinde daha fazla optimizasyon görmeyi bekliyoruz.

1. Yeni FHE kütüphanesi

Araştırmacılar yeni güçlü şemaları keşfetmeye devam ederken, FHE kütüphaneleri daha fazla geliştiricinin FHE'yi entegre etmesini sağlayabilir.

Örnek olarak FHE akıllı sözleşmelerini ele alalım. Farklı FHE kütüphaneleri arasından seçim yapmak zor olsa da, zincir içi FHE'den bahsettiğimizde bu daha kolay hale gelir çünkü Web3'te yalnızca birkaç baskın programlama dili vardır.

Örneğin, Zama'nın fhEVM'si, Zama'nın açık kaynak kütüphanesi TFHE-rs'yi tipik bir EVM'ye entegre ederek homomorfik işlemleri önceden derlenmiş sözleşmeler olarak ortaya çıkarır. Geliştiricilerin, derleme araçlarında herhangi bir değişiklik yapmadan, sözleşmelerinde şifrelenmiş verileri etkili bir şekilde kullanmalarına olanak tanır.

Diğer spesifik senaryolar için başka bir altyapı gerekli olabilir. Örneğin, C++ ile yazılmış TFHE kütüphanesi Rust versiyonu kadar iyi korunmuyor. TFHE-rs, C/C++ için dışa aktarmaları destekleyebilmesine rağmen, C++ geliştiricileri daha iyi uyumluluk ve performans istiyorsa, TFHE kitaplığının kendi sürümünü yazmaları gerekir.

Son olarak, pazarda FHE altyapısının bulunmamasının temel nedeni, FHE-RAM oluşturmanın etkili yollarından yoksun olmamızdır. Olası bir çözüm, belirli işlem kodları olmadan bir FHE-EVM üzerinde çalışmaktır.

Güvenli Eşik Şifre Çözme

Zorluk: Güvenli Olmayan/Merkezi Eşik Şifre Çözme

Her gizli, paylaşılan durum sistemi bir şifreleme/şifre çözme anahtarına dayanır. Tek bir tarafa güvenilemez, bu nedenle şifre çözme anahtarı ağ katılımcıları arasında paylaştırılır.

Zincir içi FHE'nin (Eşik FHE) en zorlu yönlerinden biri, güvenli ve önceden oluşturulmuş bir eşik şifre çözme protokolü oluşturmaktır. İki temel darboğaz vardır: (1) FHE tabanlı hesaplama önemli miktarda ek yük getirir, dolayısıyla yüksek performanslı düğümler gerektirir, bu da doğal olarak doğrulayıcı kümesinin potansiyel boyutunu azaltır (2) Şifre çözme protokolüne katılan düğümlerin sayısı arttıkça gecikme artar.

En azından şimdilik, FHE protokolleri doğrulayıcılar arasında dürüst bir çoğunluğa dayanıyor ancak yukarıda belirtildiği gibi Eşik FHE, daha küçük bir doğrulayıcı kümesi ve dolayısıyla daha yüksek gizli anlaşma ve kötü niyetli davranış olasılığını ima ediyor.

Peki ya eşik düğümleri gizli anlaşma yaparsa? Protokolü atlayabilecekler ve temel olarak kullanıcı girişlerinden zincir içi verilere kadar her şeyin şifresini çözebilecekler. Ayrıca, şifre çözme protokolünün mevcut sistemlerde tespit edilemeyecek şekilde gerçekleşebileceğini ("sessiz saldırı" olarak da bilinir) unutmamak önemlidir.

Çözüm: Geliştirilmiş Eşik Şifre Çözme veya Dinamik MPC

Eşik şifre çözmenin eksikliklerini gidermenin birkaç yolu vardır. (1) Gizli anlaşmayı zorlaştıracak bir n/2 eşiğini etkinleştirin (2) Bir HSM'nin içinde eşik şifre çözme protokolünü çalıştırın (3) Dinamik izin veren kimlik doğrulama için merkezi olmayan bir zincir tarafından kontrol edilen TEE tabanlı bir eşik şifre çözme ağı kullanın anahtar yönetimi.

Eşik şifre çözmeden yararlanmak yerine MPC'yi kullanmak mümkündür. Zincir içi FHE'de kullanılabilecek bir MPC protokolü örneği, Odsy'nin ilk işbirlikçi olmayan ve büyük ölçüde merkezi olmayan MPC algoritması olan yeni 2PC-MPC'sini içerir.

Farklı bir yaklaşım, verileri şifrelemek için yalnızca kullanıcının ortak anahtarını kullanmak olabilir. Doğrulayıcılar daha sonra homomorfik işlemleri işler ve gerekirse kullanıcılar kendileri de sonucun şifresini çözebilir. Yalnızca niş kullanım durumları için mümkün olsa da eşik varsayımından tamamen kaçınabiliriz.

Özetlemek gerekirse, zincir içi FHE'nin aşağıdaki özelliklere sahip etkili bir MPC uygulamasına ihtiyacı vardır: (1) Kötü niyetli aktörler olduğunda bile çalışır (2) Minimum gecikme sağlar (3) Düğümlerin izinsiz/esnek girişini mümkün kılar.

Kullanıcı Girişi ve Bilgi İşlem Ekibi için Sıfır Bilgi Kanıtı (ZKP)

Zorluk: Kullanıcı Girişlerinin Doğrulanabilirliği + Hesaplama:

Web2'de, hesaplamaya dayalı bir görevin gerçekleştirilmesini istediğimizde, belirli bir şirketin görevi tam olarak perde arkasında vaat ettiği gibi yürüteceğine tamamen güveniriz. Web3'te model tamamen ters çevrilmiştir; Bir şirketin itibarına güvenmek ve dürüst davranacaklarına güvenmek yerine, artık güvenilmez bir ortamda çalışıyoruz, bu da kullanıcıların kimseye güvenmek zorunda kalmaması gerektiği anlamına geliyor.

FHE, şifrelenmiş verilerin işlenmesine olanak sağlarken kullanıcı girişlerinin veya hesaplamanın doğruluğunu doğrulayamaz. Her ikisini de kontrol etme yeteneği olmadan FHE'nin blockchain bağlamında pek faydası yoktur.

Çözüm: Kullanıcı Girişleri + Bilgi İşlem Grubu için ZKP'ler:

FHE, herkesin şifrelenmiş veriler üzerinde keyfi hesaplama yapmasına olanak tanırken, ZKP'ler, kişinin temel bilgiyi açıklamadan bir şeyin doğru olduğunu kanıtlamasına olanak tanır. Peki aralarında nasıl bir ilişki var?

FHE ve ZKP'lerin birbirine uymasının üç temel yolu vardır:

1. Kullanıcının, giriş şifreli metninin iyi biçimlendirildiğine dair bir kanıt sunması gerekir. Bu, şifreli metnin şifreleme şemasının gereksinimlerini karşıladığı ve yalnızca rastgele veri dizileri olmadığı anlamına gelir.
2. Kullanıcının, giriş düz metninin belirli bir uygulamanın koşullarını karşıladığına dair bir kanıt sunması gerekir. Eski. miktar_bakiye > miktar_transfer
3. Doğrulayıcı düğümün (başka bir deyişle bilgi işlem tarafının) FHE hesaplamasını doğru şekilde yürüttüklerini kanıtlaması gerekir. Buna "doğrulanabilir FHE" denir ve toplamalar için gereken ZKP'lere benzer olarak görülebilir.

ZKP'nin uygulamalarını daha fazla keşfetmek için:

1. Şifreli Metnin ZKP'si

FHE, kafes tabanlı kriptografi üzerine inşa edilmiştir; bu, kriptografik ilkel yapının PQ (kuantum sonrası) güvenli olan kafesleri içerdiği anlamına gelir. Buna karşılık SNARKS, STARKS ve Bulletproofs gibi popüler ZKP'ler kafes tabanlı şifrelemeye dayanmaz.

Kullanıcının FHE şifreli metninin iyi biçimlendirilmiş olduğunu kanıtlamak için halkalardan gelen girdilerle bazı matris-vektör denklemlerini karşıladığını ve bu elemanların sayısal değerlerinin küçük olduğunu göstermemiz gerekir. Esasen, açık bir araştırma alanı olan kafes tabanlı ilişkileri ele almak için tasarlanmış, uygun maliyetli bir zincir üstü doğrulama kanıt sistemine ihtiyacımız var.

1. Düz Metin Girişinin ZKP'si

İyi biçimlendirilmiş bir şifreli metni kanıtlamanın yanı sıra, kullanıcının girdi düz metninin bir uygulamanın gereksinimlerini karşıladığını kanıtlaması gerekir. Neyse ki, önceki adımdan farklı olarak, kullanıcı girdilerinin geçerliliğini kanıtlamak için genel SNARK'ları kullanabiliriz, böylece geliştiricilerin mevcut ZKP şemalarından, kitaplıklarından ve altyapısından faydalanmasına olanak tanırız.

Ancak işin zor kısmı iki kanıt sistemini "bağlamamız" gerekiyor. Kullanıcının her iki prova sistemi için de aynı girişi kullandığından emin olmamız gerektiği gibi bağlanın; aksi takdirde kötü niyetli bir kullanıcı protokolü aldatabilir. Bir kez daha, bu inanılmaz derecede zor bir kriptografik başarıdır ve erken araştırmalara açık bir alandır.

Sunscreen ayrıca, SDLP'ye en kolay şekilde bağlanabilen Kurşun Geçirmezler için destek sunan ZKP derleyicisiyle de temelleri attı. FHE ve ZKP derleyicisini "bağlamak" için gelecekteki geliştirmeler yapılıyor.

Mind Network, güvenli hesaplama için FHE'den yararlanmanın yanı sıra sıfır güven giriş ve çıkışlarını sağlamak için ZKP'lerin entegrasyonuna öncülük ediyor.

1. Doğru Hesaplamanın ZKP'si

FHE'nin mevcut donanım üzerinde çalıştırılması son derece verimsiz ve pahalıdır. Daha önce ölçeklenebilirlik üçlemi dinamiğinin gerçekleştiğini gördüğümüz gibi, daha yüksek düğüm kaynağı gereksinimlerine sahip ağlar, yeterli düzeyde merkezi olmayan bir yapıya ölçeklenemez. Olası bir çözüm, bilgi işlem tarafının (doğrulayıcının) işlemlerin dürüst bir şekilde yürütüldüğünü kanıtlamak için bir ZKP sunduğu "Doğrulanabilir FHE" adı verilen bir süreç olabilir.

Doğrulanabilir FHE'nin erken bir prototipi, SherLOCKED adlı bir proje tarafından görüntülenebilir. Temel olarak FHE hesaplaması, şifrelenmiş veri zinciri dışında hesaplamayı işleyen ve sonucu bir ZKP ile döndüren ve zincirdeki durumu güncelleyen Risc ZERO'nun Bonsai'sine aktarılır.

Bir FHE yardımcı işlemcisinden yararlanmanın yeni bir örneği Aztec'in zincir üstü açık artırma demosunda görülebilir. Daha önce ele aldığımız gibi, mevcut FHE zincirleri tüm durumu bir eşik anahtarıyla şifreler; bu da sistemin yalnızca eşik komitesi kadar güçlü olduğu anlamına gelir. Bunun tersine, Aztek'te kullanıcı kendi verilerine sahiptir ve bu nedenle eşik güvenlik varsayımına tabi değildir.

Son olarak, bir geliştiricinin ilk etapta FHE uygulamasını nerede oluşturabileceğine değinmek önemlidir. Geliştiriciler, uygulamalarını FHE destekli bir L1, bir FHE toplaması veya herhangi bir EVM zinciri üzerine kurabilir ve bir FHE yardımcı işlemcisinden yararlanabilir. Her tasarım kendi ödünleşimleriyle birlikte gelir, ancak diğer avantajların yanı sıra güvenliği Ethereum'dan miras aldıkları için iyi tasarlanmış FHE toplamalarına (Fhenix'in öncülüğünde) veya FHE yardımcı işlemcilerine daha yatkınız.

Yakın zamana kadar, FHE şifreli veriler üzerinde sahtekarlığa karşı kanıt elde etmek karmaşıktı, ancak son zamanlarda Fhenix.io'daki ekip, WebAssembly'ye yönelik FHE mantık derlemesi ile eşleştirilmiş Arbitrum Nitro yığınını kullanarak sahtekarlığa karşı kanıtların nasıl elde edileceğini gösterdi.

FHE'nin Veri Kullanılabilirliği (DA) Katmanı

Zorluk: Özelleştirilebilirlik ve Verim Eksikliği

Web2'de depolama metalaştırılmış olsa da aynı durum Web3 için geçerli değildir. FHE'nin 10.000x+'lık büyük bir veri artışı sağladığı göz önüne alındığında, büyük FHE şifreli metinlerini nerede saklayacağımızı bulmamız gerekiyor. Belirli bir DA katmanındaki her düğüm operatörü, her FHE zincirinin verilerini indirip depolasaydı, yalnızca kurumsal operatörler talebe ayak uydurabilir ve bu da merkezileşme riskini doğurabilirdi.

Verim açısından Celestia 6,7 MB/sn ile zirveye çıkıyor; eğer herhangi bir FHEML formunu çalıştırmak istersek, kolaylıkla n GB+/sn'ye ihtiyacımız olur. 1k(x) tarafından paylaşılan son verilere göre, mevcut DA katmanları, verimi (kasıtlı olarak) sınırlayan tasarım kararları nedeniyle FHE'yi destekleyemiyor.

Çözüm: Yatay Ölçeklendirme + Özelleştirilebilirlik

Yatay ölçeklenebilirliği destekleyebilecek bir DA katmanına ihtiyacımız var. Mevcut DA mimarileri, tüm verileri ağdaki her düğüme yayar ve bu, ölçeklenebilirlik açısından önemli bir kısıtlamadır. Tersine, yatay ölçeklenebilirlik sayesinde, sisteme daha fazla DA düğümü girdikçe, her düğüm verinin 1/n'de birini depoluyor ve daha fazla blok alanı kullanıma sunuldukça performans ve maliyet artıyor.

Ayrı olarak, FHE ile ilişkili önemli veri boyutu göz önüne alındığında, geliştiricilere silme kodlama eşikleri etrafında daha yüksek düzeyde özelleştirilebilirlik sunmak mantıklı olacaktır. yani DA sisteminin ne kadarı garanti konusunda rahatsınız? Hisse bazlı ağırlıklandırma veya merkezi olmayan yönetim bazlı ağırlıklandırma olsun.

EigenDA'nın mimarisi, FHE için bir DA katmanının neye benzeyebileceğinin temelini oluşturur. Yatay ölçeklendirme, yapısal maliyet azaltma, DA ve fikir birliğinin ayrıştırılması vb. özelliklerinin tümü, bir gün FHE'yi destekleyebilecek bir ölçeklenebilirlik düzeyine yol açar.

Son olarak, şifreli metinler belirli bir kodlama şemasını takip ettiğinden, FHE şifreli metinleri depolamak için optimize edilmiş depolama yuvaları oluşturmak yüksek düzeyde bir fikir olabilir; dolayısıyla optimize edilmiş depolama yuvalarına sahip olmak, depolamanın verimli kullanımına ve daha hızlı erişime yardımcı olabilir.

Tamamen Homomorfik Şifreleme (FHE) Donanımı

Zorluk: Düşük Performanslı FHE Donanımı

Zincir içi tamamen homomorfik şifreleme (FHE) uygulamalarının tanıtımında, FHE'nin herhangi bir standart işleme donanımında çalıştırılmasını pratik olmayan hale getiren hesaplama yükünden kaynaklanan önemli gecikme önemli bir sorundur. Bu sınırlama, işlemcinin işlemesi gereken veri miktarının büyük olması nedeniyle bellekle olan etkileşimin büyük olmasından kaynaklanmaktadır. Bellek etkileşimlerine ek olarak, karmaşık polinom hesaplamaları ve zaman alan şifreli metin bakım işlemleri de çok fazla ek yük getirir.

FHE hızlandırıcıların durumunu daha iyi anlamak için tasarım alanını ortaya çıkarmamız gerekiyor: Uygulamaya özel FHE hızlandırıcılar ve genelleştirilebilir FHE hızlandırıcılar.

FHE için hesaplama karmaşıklığının ve donanım tasarımının özü her zaman belirli bir uygulama için gereken çarpma sayısıyla ilgilidir ve buna "homomorfik işlemin derinliği" adı verilir. Uygulamaya özel durumda derinlik bilinmektedir, dolayısıyla sistem parametreleri ve ilgili hesaplama sabittir. Bu nedenle, uygulamaya özel bu durum için donanım tasarımı daha kolay olacaktır ve genellikle genelleştirilebilir hızlandırıcı tasarımından daha iyi performans için optimize edilebilir. FHE'nin keyfi sayıda çarpmayı desteklemesinin gerekli olduğu genel durumda, homomorfik işlemlerde biriken gürültünün bir kısmını ortadan kaldırmak için önyükleme yapılması gerekir. Önyükleme pahalıdır ve çip üzerinde bellek, bellek bant genişliği ve hesaplama dahil önemli donanım kaynakları gerektirir; bu da donanım tasarımının uygulamaya özel tasarımdan çok farklı olacağı anlamına gelir. Bu nedenle, Intel, Duality, SRI, DARPA ve diğerleri de dahil olmak üzere alandaki büyük oyuncuların yaptığı çalışmalar, GPU ve ASIC tabanlı tasarımlarıyla şüphesiz sınırları zorluyor olsa da, bunlar 1:1 olarak uygulanamayabilir. Blockchain kullanım durumlarını destekleyin.

Geliştirme maliyetiyle ilgili olarak: Genelleştirilebilir donanımın tasarımı ve üretimi, uygulamaya özel olandan daha fazla sermaye gerektirir, ancak esnekliği, donanımın daha geniş bir uygulama kapsamında kullanılmasına olanak tanır. Öte yandan, uygulamaya özel tasarımda, eğer bir uygulamanın ihtiyaçları değişirse ve daha derin homomorfik hesaplama için destek gerektiriyorsa, o zaman uygulamaya özel donanımın MPC gibi bazı yazılım teknikleriyle birleştirilmesiyle aynı sonuca ulaşılması gerekecektir. genelleştirilebilir donanım

Zincir içi FHE'nin hızlandırılmasının uygulamaya özel kullanım durumlarına (örn. FHEML) kıyasla çok daha zor olduğunu belirtmek önemlidir çünkü daha niş bir kümeye kıyasla daha genel hesaplamaları işleme yeteneği gerektirir. Örnek vermek gerekirse, fhEVM devnet şu anda tek haneli TPS ile sınırlıdır.

Blockchain için özel olarak tasarlanmış bir FHE hızlandırıcıya ihtiyacımız olduğu göz önüne alındığında, dikkate alınması gereken bir diğer konu da işin ZKP donanımından FHE donanımına ne kadar aktarılabilir olduğudur.

ZKP ve FHE arasında sayı teorik dönüşümü (NTT) ve temel polinom işlemleri gibi bazı ortak modüller vardır. Ancak bu iki durumda kullanılan NTT'nin bit genişliği farklıdır. ZKP'de donanımın NTT için 64 bit ve 256 bit gibi geniş bir bit genişliği aralığını desteklemesi gerekirken, FHE'de NTT için işlenenler artık sayı sisteminde temsil edildiği için daha kısadır. İkinci olarak, ZKP'de ele alınan NTT'nin derecesi genel olarak FHE vakasınınkinden daha yüksektir. Bu iki nedenden dolayı hem ZKP hem de FHE için tatmin edici performansa ulaşan bir NTT modülü tasarlamak önemsiz değildir. NTT dışında FHE'de ZKP'lerde bulunmayan otomorfizm gibi başka hesaplama darboğazları da vardır. ZKP donanımını FHE ayarına aktarmanın saf bir yolu, NTT bilgi işlem görevini ZKP donanımına yüklemek ve hesaplamanın geri kalanını FHE'de gerçekleştirmek için CPU'yu veya diğer donanımı kullanmaktır.

Zorlukların üstesinden gelmek için, FHE ile şifrelenmiş veriler üzerinde işlem yapmak, düz metin verilere göre 100.000 kat daha yavaştı. Bununla birlikte, daha yeni şifreleme şemaları ve FHE donanımındaki son gelişmeler sayesinde mevcut performans, düz metin verilerine göre yaklaşık 100 kat daha yavaş olacak şekilde önemli ölçüde arttı.

Çözümler:

1. FHE Donanımında İyileştirme

FHE hızlandırıcılarını aktif olarak geliştiren birçok ekip var ancak genelleştirilebilir blockchain hesaplamasına özel FHE hızlandırıcıları üzerinde çalışmıyorlar (ör. TFHE). Blockchain'e özgü donanım hızlandırıcının bir örneği, Sabit Noktalı bir FPGA hızlandırıcı olan FPT'dir. FPT, TFHE önyüklemesini tamamen yaklaşık sabit nokta aritmetiğiyle uygulayarak FHE hesaplamalarında mevcut olan gürültüden büyük ölçüde yararlanan ilk donanım hızlandırıcıdır. FHE için yararlı olabilecek bir diğer proje ise buluttaki FHE hesaplamalarını önemli ölçüde hızlandırmayı amaçlayan bir donanım hızlandırıcı mimari ailesi olan BASALISC'dir.

Daha önce de belirtildiği gibi, FHE donanım tasarımındaki temel darboğazlardan biri bellekle olan yoğun etkileşimdir. Bu engeli aşmak için olası bir çözüm, bellekle etkileşimi mümkün olduğu kadar azaltmaktır. Bellekte işleme (PIM) veya yakın belleğe hesaplama bu senaryoda muhtemelen yardımcı olacaktır. PIM, belleğin hem hesaplama hem de bellek işlevlerine hizmet etmesine olanak tanıyan ve hesaplama ile bellek arasındaki ilişkinin radikal bir şekilde yenilenmesini vaat eden, gelecekteki bilgisayar sistemleri için "bellek duvarı" zorluklarını ele alan umut verici bir çözümdür. Geçtiğimiz on yılda, dirençli RAM, spin-transfer torklu manyetik RAM ve faz değişim belleği gibi kalıcı belleklerin bu amaç için tasarlanmasında büyük ilerleme kaydedildi. Bu özel belleği kullanarak, makine öğrenimi ve kafes tabanlı genel anahtar şifrelemede önemli hesaplama gelişmelerini gösteren çalışmalar yapılmıştır.

1. Optimize edilmiş yazılım ve donanım

Son gelişmelerde yazılım, donanım hızlandırma sürecinde kritik bir bileşen olarak kabul edilmektedir. Örneğin, F1 ve CraterLake gibi öne çıkan FHE hızlandırıcıları, hibrit yazılım/donanım ortak tasarım yaklaşımı için derleyicileri kullanıyor.

Alan ilerledikçe, tamamen işlevsel derleyicilerin blockchain'e özgü FHE derleyicileriyle birlikte tasarlanmasını bekleyebiliriz. FHE derleyicileri, ilgili FHE planının maliyet modeline dayalı olarak FHE programlarını optimize edebilir. Bu FHE derleyicileri, donanım düzeyinde bir maliyet modeli dahil edilerek uçtan uca performansı artırmak için FHE hızlandırıcı derleyicilerle entegre edilebilir.

1. FHE Hızlandırıcılarının Ağ Oluşturulması: Ölçek Büyütmeden Ölçeği Genişletmeye Geçiş

Mevcut FHE donanım hızlandırma çabaları büyük ölçüde "ölçek büyütmeye" odaklanıyor, bu da tek bir hızlandırıcının dikey olarak iyileştirilmesine odaklanmak anlamına geliyor. Öte yandan, "ölçek genişletme" yerleri, birden fazla FHE hızlandırıcıyı yatay olarak ağ oluşturarak bağlamaya odaklanır; bu, ZKP'lerle paralel kanıt oluşturmaya benzer şekilde performansı büyük ölçüde artırabilir.

FHE hızlandırmadaki başlıca zorluklardan biri veri enflasyonu sorunudur: Şifreleme ve hesaplama sırasında veri boyutunda meydana gelen önemli artışı ifade eder ve çip üzerindeki ve çip dışındaki bellekler arasında verimli veri hareketi için zorluklar yaratır.

Veri enflasyonu, birden fazla FHE hızlandırıcıyı yatay olarak ağ oluşturma yoluyla bağlama konusunda önemli bir zorluk teşkil etmektedir. Bu nedenle, FHE donanım ve ağ ortak tasarımı gelecekteki araştırmalar için umut verici bir yön olacaktır. Bir örnek, FHE hızlandırıcılar için uyarlanabilir bir ağ yönlendirmeyi içerebilir: Gerçek zamanlı hesaplama yüküne ve ağ trafiğine dayalı olarak FHE hızlandırıcılar arasındaki veri yollarını dinamik olarak ayarlayan bir yönlendirme mekanizmasının uygulanması. Bu, optimum veri aktarım hızlarını ve verimli kaynak kullanımını sağlayacaktır.

Çözüm

FHE, verileri platformlar arasında koruma şeklimizi temelden yeniden tasarlayacak ve benzeri görülmemiş bir gizlilik çağının önünü açacak. Böyle bir sistemi inşa etmek sadece FHE'de değil, ZKP'ler ve MPC'de de önemli ilerlemeler gerektirecektir.

Bu yeni sınıra doğru ilerlerken kriptograflar, yazılım mühendisleri ve donanım uzmanları arasındaki işbirlikçi çabalar zorunlu olacaktır. Kanun koyucular, politikacılar vb.'den bahsetmiyorum bile çünkü mevzuata uyum, genel kabulün tek yoludur.

Sonuçta FHE, veri gizliliği ve güvenliğinin artık birbirini dışlayan değil, ayrılmaz bir şekilde bütünleştiği bir geleceğin habercisi olarak, dönüştürücü bir dijital egemenlik dalgasının ön saflarında yer alacak.

Özel teşekkür:

İncelemeleri için Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ)'ya çok teşekkürler. Bu kişilerin bu alanda yaptıkları etkileyici çalışma ve çabaları okumayı sabırsızlıkla bekliyoruz!

Yasal Uyarı:

1. Bu makale [HashKey Capital]'den yeniden basılmıştır. Tüm telif hakları orijinal yazara [Jeffrey Hu、Arnav Pagidyala] 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.