FHE oyunu değiştiriyor ve hepimiz oynamaya davetliyiz.
Eğer neden bahsettiğim hakkında hiçbir fikrin yoksa son zamanlarda bir kayanın altında yaşıyorsun demektir. FHE.org'un kapsamlı kaynaklarından bazılarına göz atın ve geri dönün.
FHE'nin teknoloji dünyasına verdiği sözü yerine getirebilmesi için, herkesin kolayca homomorfik uygulamalar oluşturmak için kullanabileceği, geliştirme, derleme ve çalışma zamanı yürütmeye yönelik yeni nesil endüstriyel güçlü araçlarla birlikte gelmesi gerekir.
Ancak günümüzde FHE alanındaki pek çok uzman ve şirket, uzman olmayanlar için harika geliştirme araçları oluşturmaya odaklanmak yerine hala zamanlarının ve çabalarının çoğunu FHE'nin arkasındaki kriptografiyi geliştirmeye harcıyor. Beni burada iyi dinleyin: Temel FHE işlevlerini ve performansını geliştirmek her zaman iyi bir haber olacaktır. Ancak genel tabloya bakıldığında, bu artan iyileştirmeler küresel benimsemeyi en iyi ihtimalle marjinal olarak teşvik ediyor. Bunların bir noktada evlat edinmeye etkisi olacak ama şu anda değil.
Benim durduğum yerden, FHE destekli başarı öykülerinin kilidini açmak ve FHE'yi bir teknoloji trendinden dijital güvenlik işinde gerçek bir paradigma değişikliğine taşımak için teknoloji dünyasının bugün güçlü, geliştirici dostu FHE araç zincirlerine ihtiyacı olduğu açık. FHE hakkındaki mevcut bilgi durumunun - hem bilimsel hem de teknolojik olarak - bu tür araçları halihazırda oluşturmak ve bunları teknoloji meraklısı kitlelerin daha fazla gecikmeden kullanılabilir hale getirmek için zaten yeterli olduğuna inanıyorum. Yeni özelliklerin sürekli entegrasyonu zaman içinde doğal olarak ortaya çıkacaktır, her zaman böyle olur.
Ama olay şu: FHE'nin pek çok çeşidi var. Hangi şifreleme şemasını kullandığınıza veya onu hangi özel şekilde kullandığınıza bağlı olarak, hesaplamayı temsil etmenin ve homomorfik programları çalıştırmanın farklı bir yolu ortaya çıkar. Sanki FHE programları tamamen farklı hayvanlardır; biri size Turing makineleri, diğeri lambda hesabı verir. Biyoçeşitlilik teknolojide veya diğer açılardan her zaman iyidir, ancak bu aynı zamanda FHE'yi pratikte kullanırken uygulanabilir bir strateji belirlemeniz gerektiği anlamına da gelir.
Şirketim Zama, TFHE olan belirli bir FHE planına odaklanıyor. TFHE, çok özel varlıklarla homomorfik veri işlemeyi başarır: süper hızlı önyüklemeler ve tablo arama ağları olarak ifade edilen hesaplamalar. TFHE'yi FHE alanında zayıf bir oyuncu haline getiren bu özelliklerin nasıl homomorfik kitaplıklara, derlemeye, sanal makinelere veya donanım hızlandırmaya dönüştürülebileceğine dair derin bir anlayış kazanmaya başladık.
CKKS , BGV veya BFV gibi diğer önde gelen FHE yarışmacıları, pratik enstrümantasyonlarında çok farklı konseptler içerir: önyüklemeler bir seçenek olamayacak kadar yavaştır, bu nedenle işleme derinliği sınırlıdır, ancak veriler büyük gruplamayla vektörleştirilebilir, hesaplamalar polinom devreleri olarak ifade edilir ve - CKKS durumunda - sonuçlar yaklaşık değerlerdir. Dolayısıyla BGV/BFV ve CKKS'nin derleyicilere ve çalışma zamanlarına çevrilmesi, araç geliştiricilerden tamamen farklı bir zihniyet gerektirir.
Ancak geliştiricilerin, kolayca çalıştırılabildikleri ve konuşlandırılan homomorfik uygulamalarda performans gereksinimleri karşılanabildiği sürece, FHE takım zincirlerine ve çalışma zamanı ortamlarına hangi özel şemanın güç sağladığıyla pek ilgilenmeleri pek olası değildir. Onlar da yaratıcı inşaatçılardır ve kullanıcılarına sunabilecekleri yeni deneyimlere odaklanmalıdırlar.
Dolayısıyla, FHE teknolojisini etkinleştirenlerin son hedefi, yalnızca geliştirme çoklu evreninde en iyi zamanlarına hazır değil, aynı zamanda yeni bir endüstri standardı belirleyecek kadar güçlü araçlar tasarlamak ve sunmaktır. Bunu başarmak için hangi FHE planının onları oraya ulaştırma olasılığının daha yüksek olduğu şansını denemeleri gerekiyor.
Hadi oyun oynayalım.
FHE'nin inceliklerini bilmeyen ancak homomorfik bir uygulama oluşturmak isteyen bir geliştiriciyi ele alalım. Burada araç oluşturucu sizsiniz, ortak geliştirme uygulamalarına ve bilgisayar biliminin temellerine biraz aşinalık bekleyebileceğiniz ancak diğer her şeyin (ileri matematik ve benzeri) yasak olduğu geliştiriciyle karşı karşıyasınız . FHE uygulamasını kendi başlarına başarılı bir şekilde üretmelerini nasıl sağlayabilirsiniz?
Bu makale, TFHE'ye bahis yaparak bu oyunu kazanmak için çeşitli stratejileri araştırıyor.
Uygulamanın niteliğine (özel veri işleme, sinir ağları, akıllı sözleşmeler veya genel amaçlı programlama) bağlı olarak TFHE destekli kazanma yolları araştırılacaktır. Bu keşif bizi kolay bir yola, zorlu bir yola ve bunların arasında yer alan birkaç yola daha götürecek; bunların pratikte gerçekleştirilmesinde farklı teknolojik hazırlık düzeylerine sahip olacağız.
TFHE, Torus FHE anlamına gelir. Keşfedenlerin adlarından dolayı CGGI olarak da anılan TFHE, FHE ortamında benzersiz bir konuma sahiptir: programlanabilir önyüklemeyi (PBS) mümkün kılan en iyi bilinen mekanizmadır.
Özetle, PBS homomorfik bir tablo aramasıdır. Bir x
indeksinin şifrelenmesi göz önüne alındığında, T
seçtiğiniz tablolanmış bir fonksiyon olduğu T[x]
şifrelemesini döndürür. Çalışma hızı T
girişlerine bağlı olmayıp sadece giriş sayısına bağlıdır ve milisaniye aralığındadır. Ayrıca, bir PBS, çıkış şifreli metnine gömülü şifreleme gürültüsünü sıfırlar; böylece, homomorfik uygulamanızın her zaman temiz şifreli metinleri işleyeceğini bilerek PBS'leri süresiz olarak sırayla oluşturabilirsiniz.
TFHE'nin savunduğu hesaplamalı model mükemmel bir modeldir.
TFHE programlarındaki temel işlem birimi tam olarak bir nörona benzer ve 2 temel homomorfik işlemden oluşur:
Şifrelenmiş girişler E(x_1), …, E(x_n)
ve bir dizi düz metin ağırlığı w_1, …, w_n
verildiğinde E(x)
değerini döndüren girişlerin doğrusal birleşimi; burada x = w_1 x_1 + … + w_n x_n modulo m
.
E(x)
ten E(T[x])
hesaplayan bir PBS; burada T
, m
boyutunda bir düz metin tablosudur.
"TFHE nöronunda" m
, x_i
, w_i
ve ayrıca T[0], …, T[m-1]
girişlerinin tümü tamsayılardır ve m
, w_1, …, w_n
"parametreleri" serbestçe seçilebilir. w_1, …, w_n
ve T
. Doğrusal kombinasyonun neredeyse sıfır maliyete sahip olduğu göz önüne alındığında, verimlilik darboğazı, çalışma süresi yalnızca m
modülüne bağlı olan PBS'dir: m
arttıkça hız azalır. Bu, TFHE nöronlarındaki modüller için küçük değerlerin - tek veya çift, ancak en az 2 - kullanılmasına davet eder, ancak bunların hesaplamalı ifadelerinin çok ciddi bir şekilde azaltılmasını önlemek için bir denge bulunması gerekir.
Artık, paralellik ve HPC hilelerinden yararlanmak için sinir ağlarında nöronların katmanlar halinde bir araya getirilmesiyle aynı şekilde, TFHE ağları da TFHE nöronlarının katmanlarını biriktiriyor. Her katman bir ağırlık matrisi modülü, ortak bir modül m
ve m
boyutunda arama tablolarından oluşan bir vektör içerir. Ancak modülün, tıpkı katmanın şekli gibi, önceki veya sonraki katmanda farklılık göstermesi serbesttir.
Ve bu TFHE'yi tamamlıyor! İşte, işlevleri sistematik olarak arama ağları olarak ifade etmemiz gerekiyor. Artık homomorfik hesaplamalı modelimize sahibiz.
Gerçekte, TFHE bu modelin çoklu uzantılarını destekler (düşük seviyeli operatörlerin rastgele grafikleri, çeşitli türlerdeki şifreli metinler, çok çıkışlı tablo aramaları, değişkenleri paketlemenin çoklu yolları, vb.). Ancak şimdilik bu geliştirmeleri göz ardı edebiliriz çünkü arama ağı vizyonu zaten düz bir programı homomorfik bir eşdeğere dönüştürüp çalıştırmamıza izin verecek kadar güçlü. Böylece, en azından teknolojinin ilk yinelemesi için, bunu nasıl yapacağımıza odaklanabiliriz.
Bu nedenle, bir TFHE ağı yalnızca bir plandır ve henüz homomorfik bir uygulama içinde düzgün bir şekilde yürütülmeye hazır değildir. Modüller, ağırlık matrisleri ve arama tabloları tüm katmanları için tam olarak belirtilmiş olsa da, kriptografik parametrelendirme olan çok önemli bir bileşeni hala gözden kaçırıyor.
Kripto parametreleri, çalışma zamanında ağda ne olacağına ilişkin olası her ölçüyü belirler: somut şifreli metin boyutları, PBS'lerin içindeki anahtar değiştirme ve önyükleme anahtarlarının gerçek tensör boyutları, düşük seviyeli homomorfik operatörler içindeki çeşitli algoritmik seçenekler, düz metin hassasiyetleri ve gürültünün nasıl olacağı ağ genelinde seviyeler ve sonuçta nasıl şifreleneceği ve şifrenin nasıl çözüleceği ile ilgili ayrıntılar gelişir. Ayrıca bellek kullanımını ve performansı da öngörüyorlar.
Bir TFHE ağının yürütülmesini hangi parametre setinin optimize ettiğini bulmak zahmetli olabilir ve her durumda, her şey her şeye bağlı olduğundan, FHE'nin ilk günlerindeki gibi kalem ve kağıt stiliyle çalışmak - uzmanlar için bile - dayanılmaz derecede zor olabilir. . Ayrıca, birkaç optimal küme aynı anda bir arada var olabilir, bu nedenle genel anahtar boyutu, kritik yol gecikmesi veya maksimum verim arasında bir arbitraj gerektirir. Neyse ki, bu görevi otomatikleştirme sorunu son yıllarda çözüldü ve artık belirli bir TFHE ağının en iyi kriptografik örneklemesini hızlı bir şekilde belirlemek için güçlü optimizasyon araçları mevcut.
Bir TFHE ağı, kriptografik parametrelerle oluşturulduktan sonra gerçekten çalıştırılabilir hale gelir veya daha doğrusu, uygun bir derleme geçişi yoluyla gerçek bir yürütülebilir dosyaya uygun hale gelir.
Bir TFHE programı, "düz mantık" ile birbirine yapıştırılmış parametrelendirilmiş TFHE ağlarının bir koleksiyonudur.
Düz mantık oluşur
Düz metin değişkenleri (normal, şifrelenmemiş değişkenler anlamına gelir) üzerinde çalışan talimatlar,
koşulsuz veya düz metin yüklemlerine koşullandırılmış dallanma,
Düz metin adreslerinde hafıza okuma ve yazma, işaretçi aritmetiği,
altprogramlara/fonksiyonlara çağrılar.
Temel olarak, düz mantık, tek bir durum hariç olmak üzere, dil tarafından desteklenen programlama mantığını içerir: programın TFHE bölümlerinin ayrıcalığı olan şifrelenmiş program değişkenlerinin değiştirilmesi. Düz mantığın şifreli metinlerle (ve TFHE genel anahtarlarıyla) yapmasına izin verilen tek şey, bunları değiştirmeden taşımak ve sanki bunlar kendi ayrı işlemcileri veya konteynerleri içinde çalışıyormuş gibi TFHE parçalarına beslemektir.
Tüm niyet ve amaçlar açısından, bu tanıma uygun bir program, programlama dili ne olursa olsun, eksiksizdir ve tam teşekküllü bir homomorfik uygulama olmaya hazırdır. Özel derleme bu son eşlemeyi sağlayacaktır ve sonuçta elde edilen nesne daha sonra TFHE'nin etkin olduğu bir çalışma zamanının üzerinde veya tek başına, kendi kendine yeten bir yürütülebilir dosya olarak çalıştırılabilir.
Derlemenin aynı arka uç derleyiciyle gerçekleştirilebilmesi için TFHE programlarının temsilini (bazı DSL veya daha iyisi bir MLIR lehçesi gibi) birleştirmek için özel bir dil kullanılabilir.
Çalışma zamanının kesin doğası (paylaşılan/dinamik kitaplık, VM veya başka bir şey) burada yalnızca bir yöntemdir. Her iki seçenek de dağıtılabilen ve kullanıcılara sunulabilen, TFHE destekli işlevsel bir homomorfik uygulamaya yol açacaktır.
Şimdi bir dakikalığına oyundaki oyuna geri dönelim.
TFHE veya yukarıdakiler hakkında hiçbir şey bilmeyen ancak homomorfik bir uygulama oluşturmak isteyen bir geliştiriciyle karşı karşıyayız. Yukarıda tartışılan derleyiciyi ve varsa TFHE'nin etkin olduğu çalışma zamanını yayınladığımızı varsayalım.
Hedefimiz belirlendi, yürütülebilir bir dosyaya ulaşmak için sadece bir TFHE programına ihtiyacımız var. Ama... geliştiricinin ilk etapta TFHE programı kadar spesifik bir şeyi kendi kendine üretmesini nasıl sağlayacağız?
İşte kolay kazanma yolu geliyor: tüm karmaşıklığı kara kutulu bir FHE API'sine sığdırırsınız.
Herhangi bir programlama dilinde, (sade) bir program esasen 3 bileşenin birleşimi olarak görülebilir:
Dilde yerel talimatlar ve kapsam belirleme yapılarından oluşan programatik mantık,
değişkenler ve programın onlara atadığı, olası tüm veri türleri arasından seçilen veri türleri seçimi,
programın değişkenleri üzerinde çalışmak için kullandığı, mevcut tüm harici işlevler arasından seçilen bir dizi harici işlevi çağırır.
Veri türlerinin, bu yerel türleri genişletmek ve bunları daha yüksek düzeyde yapılandırılmış türlerle birleştirmek için yerel türler ve yazım yapılarının bir karışımı olan kendi alt dilleri vardır. Tip sistemi, programın ihtiyaç duyabileceği hemen hemen tüm veri yapılarını kapsayacak yeterli ifadeyi sağlamayı amaçlamaktadır. Dış işlevler, standart veya başka şekilde kütüphaneler tarafından sağlanan işlevlerdir, ancak bunlar aynı zamanda dilin yerel talimatları tarafından da dolaylı olarak çağrılabilir (modüler aritmetik veya bölme operatörlerini düşünün).
Yani sade programlar aslında "basittir":
Beni burada iyi dinle. Polimorfizm, üyeleri ve nitelikleriyle birlikte nesneler, sınıflar ve hiyerarşik kalıtım, şablonlar, makrolar, özellikler, iş parçacıkları, özyineleme, sözdizimsel şeker, ek açıklamalar ve akla gelebilecek diğer tüm sıfır maliyetli gibi tüm üst düzey programlama kavramlarının tamamının geçerli olduğunu söylemiyorum. Dilin sağladığı soyutlamalar, geliştiricinin işini kolaylaştırmak için icat edilmiş olmasına rağmen, basit olması gerekir.
Sadece şunu söylüyorum, bizim amacımız açısından bunlar derleme zamanında ortadan kaybolan zararsız süslemelerdir, çünkü programın daha düşük ama eşdeğer, normal formlu bir versiyonu kaynaktan çıkarılmıştır. Programın bu versiyonu, herhangi bir ara gösterimle (IR) ifade edilir, bazı kontrol akış grafikleriyle birbirine bağlanan düz çizgili temel bloklardan (bu IR'de temel olan talimat dizilerinden) oluşur.
Şimdi "basit" olan, normal formdaki bu programdır. Demek istediğim, homomorfik yeteneklerle güçlendirilebilecek kadar basit.
Dilde yerel bir FHE kütüphanesi yayınlayarak ve geliştiricinin onu en iyi nasıl kullanacağını düşünmesine izin vererek oyunu kazanırsınız.
Kitaplık, yeni veri türlerini - düz olanları tamamlamak için şifrelenmiş olanları - ve geliştiricinin aşina olduğu düz işlevleri taklit eden (az ya da çok) bir homomorfik işlevler koleksiyonunu ortaya çıkaracak, yalnızca bunlar şifrelenmiş veri türleriyle çalışır. Kısacası, tip sistemini ve kütüphane ekosistemini genişletiyorsunuz ve geliştiricinin zekasının, homomorfik uygulamalarını oluşturmak için bu uzantıları nasıl kullanacağını bulmasına izin veriyorsunuz.
Bu özellikle TFHE'ye bağlı değildir; herhangi bir FHE programı işe yarayacaktır. Çeşitli FHE kitaplıklarının sağlayıcılarının odaklandığı şey budur: düz kodlama deneyimine mümkün olduğunca yakın görünen ve hissettiren üst düzey homomorfik işlevleri ortaya çıkararak FHE'nin kullanılabilirliğini ve kullanıcı dostuluğunu geliştirmek. Tüm kriptografik karmaşıklık, programın kehanet çağrıları yapacağı kara kutulara soyutlanmıştır.
Bu elbette geliştiricinin işine yarayabilir. Peki... eğer kütüphane sağlayıcısı olarak pazarlığın kendi payına düşen kısmını yaparsan.
Şimdi buna benzeyen homomorfik bir program bulacaklar.
Artık bir arada var olan düz ve şifreli değişkenler var ve programın bu 2 nesne türü arasında katı bir ayrım yapması gerekiyor. Bunun nedeni, bir işlevi düz ve şifrelenmiş argümanların bir karışımına uyguladığınızda sonucun mutlaka şifreleneceğini söyleyen FHE altın kuralının bulunmasıdır; örneğin fhe_add(E(x), y)
E(x+y)
değerini döndürür ve yakında. Yani düz değişkenler bazı FHE fonksiyonlarına girebilir ancak onlardan asla çıkamaz. Homomorfik şifreleme, hesaplama yoluyla dokunduğu her şeyi "kirletir".
Peki bakın... şifrelenmiş bir değişkene koşullu olarak nasıl dallanırsınız?
Yapamazsın. Ama bu hiç de büyük bir sorun değil.
Bir FHE uygulamasında, koşullu dallanma şifrelenmiş olanlarda değil yalnızca düz booleanlarda etkili olabilir. Şifrelenmiş bir bit'e göre nereye atlayacağınızı nasıl bileceksiniz? Bu bitin şifresini çözecek kullanıcının özel anahtarına sahip değilsiniz.
Neyse ki, FHE size bunu çözecek basit püf noktaları da veriyor.
Geliştiricinin başlangıçta şöyle bir şey yapmak istediğini varsayalım.
if (x == 0) then y = 3 else z = 7
ancak bu noktada x
değişkeninin gerçekten şifrelenmiş olacağını fark eder. Bu kod parçası nasıl uyarlanır?
Yapılacak ilk şey, çoğullamayı kullanan eşdeğer bir düz çizgi kodu elde etmek için düz if
ifadesini yeniden çalışmaktır:
bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y = 3 * bit + y * (1 - bit) // y = 3 if bit == 1 otherwise no change z = z * bit + 7 * (1 - bit) // z = 7 if bit == 0 otherwise no change
İkinci geçişte geliştiricinin x
şifrelenmiş türde olduğu gerçeğini sonraki satırlara yayması gerekir:
bit = fhe_is_equal(x, 0) // bit, y_new and z_new are encrypted y_new = fhe_add(fhe_mul(3, bit), fhe_mul(y, fhe_sub(1, bit))) z_new = fhe_add(fhe_mul(z, bit), fhe_mul(7, fhe_sub(1, bit)))
Bunun işlevsel olarak geliştiricinin başlangıçtaki amacına eşdeğer olup olmadığı kontrol edilebilir, hepsi bu.
Programlama dili yerel operatörlerin aşırı yüklenmesine izin veriyorsa, FHE API ikinci pasajın açık FHE işlevlerini bile gereksiz hale getirebilir, böylece geliştiricinin yapması gereken tek şey ilk yeniden yazma olur.
Geliştiriciye fazladan bir sözdizimsel şeker dozu vermek için, aşırı yüklenmiş bir üçlü operatörü a? b : c
burada herhangi bir argüman şifrelenebilir veya şifrelenemez. Kod parçası daha da basitleşiyor:
bit = (x == 0) // bit = 1 if x == 0 otherwise 0 y_new = bit? 3: y // y = 3 if bit == 1 otherwise no change z_new = bit? z: 7 // z = 7 if bit == 0 otherwise no change
Bu kolayca keyfi if/switch
ifadelerine genelleştirilir: kontrol edilecek şifrelenmiş bir koşul olduğunda geliştiricinin, ifadenin birden fazla gövdesini eşdeğer düz kodlu tek bir blok halinde birleştirmek için çoğullamayı kullanması gerekir.
Artık şifrelenmiş koşulları içeren döngü yapıları aynı ruhla düzenlenebilir. Örneğin
for (i = 0; i < x; i++) do <body> // i is plain, x is encrypted
burada x
şifrelenmiş tipte olacaktır. İlk olarak, bunu bir düz for
ifadesi ve düzensiz bir if
ifadesi halinde ayrıştırın:
for (i = 0; i < known_max_value_of_x; i++) do if (i < x) then <body> // i is plain, x is encrypted
ve ardından if
ifadesini daha önce olduğu gibi düzenli hale getirin:
for (i = 0; i < known_max_value_of_x; i++) do bit = (i < x) // i is plain, x and bit are encrypted <new_body> // new body regularized using bit? _ : _
Bunun hemen bir known_max_value_of_x
değerini gerektirdiğini gözlemleyin. Şifrelenmiş x
türü tarafından desteklenen maksimum değer varsayılan olarak kullanılabilir, ancak çoğu durumda geliştirici x
üzerinde çok daha iyi bir üst sınır bilir ve bu da toplam döngü sayısını kesin bir minimuma indirmeye izin verir.
Günün sonunda, yukarıdaki dönüşümler, düzensiz kontrol akışını düzenlemek için sistematik bir yönteme kolayca genelleştirilebilir ve bu, kodlayıcıların özümsemesi ve kodlama alışkanlıklarına eklemesi kolaydır.
Zama'nın fhEVM'si, Ethereum Sanal Makinesi (EVM) üzerinde gizli akıllı sözleşmelerin geliştirilmesi ve dağıtımı için tam teşekküllü bir açık kaynaklı çerçevedir. fhEVM sözleşmeleri, geleneksel Solidity araç zincirleri kullanılarak oluşturulan basit Solidity sözleşmeleridir. Tanıdık geliştirici deneyimi, standart işlevler için şifrelenmiş veri türleri ve FHE değiştirmeleri sağlayan TFHE.sol
kitaplığı tarafından FHE ile zenginleştirilmiştir.
Desteklenen şifrelenmiş veri türleri şu anda
ebool, euint4, euint8, euint16, euint32, euint64, eaddress
ve şifrelenmiş imzalı tamsayılar da yakında dahil edilecek. Şifrelenmiş değişkenler, özel yapıcılar kullanılarak ham giriş şifreli metinlerden oluşturulur:
function mint(bytes calldata encryptedAmount) public onlyContractOwner { euint64 amount = TFHE.asEuint64(encryptedAmount); balances[contractOwner] = balances[contractOwner] + amount; totalSupply = totalSupply + amount; }
Solidity'nin yerel operatörleri +, -, *, &, |, ^, etc
geliştiricinin rahatlığı için aşırı yüklenmiştir ve sağlanan karşılaştırma operatörleri eq, ne, gt, lt, ge, le
şifrelenmiş bir boolean ebool
döndürür. Homomorfik üçlü operatör _? _ : _
select
olarak adlandırılır:
function bid(bytes calldata encryptedBid) internal { euint32 bid = TFHE.asEuint32(encryptedBid); ebool isAbove = TFHE.le(bid, highestBid); // Replace highest bid highestBid = TFHE.select(isAbove, bid, highestBid); }
Çalışma zamanı tarafında fhEVM, açık kaynaklı TFHE-rs
Rust kütüphanesinin entegrasyonundan kaynaklanan, homomorfik fonksiyonların önceden derlenmiş sözleşmeler olarak sunulduğu TFHE-etkin bir EVM sağlar.
Bu konuda daha fazla bilgi için fhEVM teknik incelemesine bakın.
Yürütülebilir TFHE programlarının, düz mantıkla bir araya getirilmiş parametreli TFHE ağlarına nasıl benzediğini hatırlıyor musunuz? Geliştiricinin yazılım mantığını bununla eşleştirmenin bir yoluna ihtiyacınız var.
İlk şart program mantığının "sade" olduğundan emin olmaktır. Geliştiriciye kontrol akış ifadelerini düzenleyerek kendi başlarına üretmelerini öğrettiğimiz şey tam olarak budur. Yani aslında bu konuda artık iyiyiz.
İkinci gereklilik, program tarafından çağrılan tüm homomorfik fonksiyonların önceden belirlenmiş parametreli TFHE ağlarına eşlenmesi gerektiğidir. Bu, çeşitli nedenlerden dolayı göründüğünden daha karmaşıktır.
Belirli bir işlevi uygulayan parametrelendirilmiş bir TFHE ağının önceden kurulması mutlaka önemsiz değildir.
Sadece 2 adet şifrelenmiş 64 bit işaretsiz tam sayının homomorfik bir toplamını oluşturmak sizi birçok teknik seçeneğe yönlendirir: 64 bit girişleri modüler tam sayıların vektörleri olarak nasıl temsil edersiniz? Tam olarak hangi modül (veya çoklu modül) ile? Peki tablo arama katmanlarına sahip 64 bitlik bir toplama devresini nasıl gerçekleştirirsiniz?
Orada birçok seçenek var. Ama eninde sonunda iyi bir mühendislik yaparak ve bol miktarda deney yaparak kararınızı vereceksiniz.
API'nin tüm işlevleri için TFHE ağlarını uyguladığınızı varsayarsak, bunların Lego blokları gibi istenildiği gibi oluşturulabileceğinden emin olmak istersiniz.
Aynı şifrelenmiş veri türünü temsil etmenin en iyi yolu bir işlevden diğerine farklılık gösterebileceğinden bu mutlaka garanti edilmez. Bu nedenle, TFHE ağlarınızın verimliliğinde çok fazla bozulmaya yol açmadan, her şifrelenmiş veri türünü temsil etmek için ortak bir aritmetik formatı benimsemeniz gerekir.
Yine birçok seçenek var ve bunlar arasında arbitraj yapmanız gerekecek.
Artık tüm TFHE ağlarının giriş/çıkış formatlarının tamamen uyumlu olduğunu varsayarsak, şekillendirilebilirlik hâlâ sağlanamayabilir.
Bunun nedeni, bir TFHE ağını başlatan kriptografik parametrelerin, diğerini başlatmak için kullanılanlarla uyumlu olmayabilmesidir. En önemlisi, giriş ve çıkış şifreli metinlerindeki şifreleme gürültüsünün seviyesi, gerçek şekillendirilebilirliği tespit etmek için ayarlanmalıdır.
Bu, elektronik devrelerdeki empedansa benzer; empedansta bir uyumsuzluk varsa bir devreyi diğerine bağlamanın hiçbir yolu yoktur. İlk önce empedans seviyelerini hizalamanız gerekir ve burada da aynı şey geçerlidir. Bunu yapmanın en kolay yolu, tüm API işlevleri arasında hizalamayı sağlayacak şekilde ayarlanmış sabit parametre kümeleri (hatta belki yalnızca tek bir benzersiz küme) kullanmaktır. Daha sonra, geliştiricinin kodu ne olursa olsun, kullanıcının ortak anahtarlarının formatı ve kullanıcı şifreleme ve şifre çözmede kullanılan parametreler sabitlenecektir.
TFHE ağlarınızı oluştururken ve parametrelerini ayarlarken bu 3 gereksinimi karşılamanın bir yolunu bulursanız ve yine de iyi bir genel performans elde ederseniz, tebrikler! Sen onu çıkardın.
FHE API'nin, geliştiricinin beklediği tüm standart işlevler için tam şekillendirilebilirlikle homomorfik değiştirmeler sağlayacak kadar kapsamlı olduğunu varsayarsak, genel amaçlı programlama için yeterince iyidirler .
Ancak uzmanlaşmış programlar için yeterince iyi olmayabilirler.
makine öğreniminde olduğu gibi büyük, bilgi işlem yoğunluklu işlevler,
özel, standart dışı işlevler.
İşte o zaman homomorfik derleme devreye giriyor.
Zor yol burada başlıyor: Genel amaçlı programlamanın dışında oyunu kazanmak için artık bir TFHE derleyicisi sunacaksınız.
Derleyici, geliştiricinin kendi başına nasıl yapılacağı hakkında hiçbir fikri olmayan şeyleri halledecektir. Geliştiricinin girdisi (ne olursa olsun, sizin çağrınız) ile beslenecek ve bir TFHE programına ulaşmak için eksik parçaları tamamlaması gerekecek.
Standart dışı uygulamaların tipik örneklerine bakalım.
Geliştirici, düz bir sinir ağını homomorfik bir eşdeğere dönüştürerek, kullanıcı giriş ve çıkışlarının uçtan uca şifrelendiği bir homomorfik çıkarım hizmeti oluşturacak ve dağıtacaktır.
Geliştiricinin, eğitimli bir nicelenmiş model üretecek veya halihazırda bir modele sahip olacak kadar makine öğrenimi konusunda yolunu bilmesi gerekiyor.
Derleyiciniz modelin temelde bir TFHE ağı olmasını veya basit bir yeniden yazma yoluyla kolayca bir TFHE ağı olmasını gerektireceğinden, nicelemenin nasıl yapıldığına ilişkin ayrıntılar burada gerçekten önemlidir. Mevcut açık kaynak tekniklerinin , önceden eğitilmiş bir modelin sonradan kuantalanması yoluyla veya tercihen, karşılaştırılan en son teknolojiye sahip doğruluk seviyelerine ulaşan Kuantizasyon Farkında Eğitim (QAT) gerçekleştirilerek bu niceleme biçimini desteklediği bilinmektedir. aynı veri kümesi üzerinde eğitilmiş nicelenmemiş modellere.
Temel olarak, TFHE ağ katmanlarında kullanılan modüller 2'nin değişken kuvvetleridir, böylece aktivasyon sinyallerinin kesinliği bit cinsinden ölçülür. Ağırlıklar işaretli tamsayılardır ve aktivasyon fonksiyonlarının kendisi de tablo aramaları olarak nicelenir ve somutlaştırılır. Aktivasyonlar, öğrenilmiş bir ofset ile kaydırılmış bir sabit işaret fonksiyonunu tablolaştırdığında, bu tanım BNN'ler , TNN'ler ve bunların çok bitli genellemeleri gibi model türlerini kapsar. Ancak prensip olarak, aktivasyon fonksiyonlarında isteğe bağlı arama tabloları kullanmakta özgürdür ve dolayısıyla bunlar daha iyi doğruluklara ulaşmak için eğitim sırasında bile öğrenilebilir.
Geliştiricinin nasıl yapılacağını bilmediği şey, TFHE ağını homomorfik bir yürütülebilir dosyaya dönüştürmektir. Yani burada eksik olan tek şey, o ağın kriptografik parametrelendirilmesidir ve arka uç derleme aşamasına geçmeden önce derleyicinizin yapması gereken tek şey budur.
Bir TFHE ağının parametrelendirilmesinin yürütülebilecek bir kriptografik örnekleme sağladığını unutmayın. Ayrıca, kullanıcı ortak anahtarlarının toplam boyutu ve toplam çalışma süresi gibi, söz konusu yürütmeyle ilgili tüm ölçümleri de kontrol eder. Bu nedenle, geliştirici çıkarım gecikmesini mutlak minimuma indirmeye çalıştığı için parametrelendirme burada kritik öneme sahiptir.
Bir TFHE ağının kriptografik parametrelerinde, hepsine kaba kuvvet uygulanamayacak kadar çok serbestlik derecesi vardır. Ayrıca optimize edilecek ölçümler tamamen ağın dışında olan 2 bileşene ve çalışma zamanının düşük seviyeli TFHE işlemlerini gerçekleştirmek için kullandığı algoritmalara bağlıdır:
Gürültü formüllerinden oluşan bir koleksiyon . Bir gürültü formülü, operatörün parametrelerini bilinmeyen değişkenler olarak kullanarak, bir operatörün uç noktalarındaki şifreleme gürültüsünün giriş ve çıkış dağılımlarını ilişkilendirir. Bunları oluşturmak, insan bilimsel analizini ve deneysel doğrulamayı gerektirir.
Maliyet ölçümlerinin bir koleksiyonu . Maliyet ölçümleri, bir operatörün çok boyutlu verimliliğini (bellek kullanımı, çalışma süresi vb.) parametrelerinin bir fonksiyonu olarak tahmin eder. Bunlar genellikle en uygun analiz yoluyla kıyaslama ölçümlerinden çıkarılır.
Çalışma zamanının uygulanmasındaki herhangi bir değişikliğin bu 2 modüle yansıtılması gerekir çünkü bunlar hem algoritmaya hem de donanıma oldukça bağımlıdır.
Çalışma zamanının gürültü formülleri ve maliyet modeli, verilen TFHE ağıyla birlikte, tüm optimizasyon sorunları sınıfının belirli bir örneğini formüle eder ve bu örnek, özel bir optimize ediciye devredilir. Burada birden fazla hedefi olan karma tamsayılı doğrusal olmayan programlamadan bahsediyoruz, dolayısıyla optimal parametre setlerinin Pareto cephesini bulmak, önemsiz olmayan optimizasyon problemleri sınıfını çözmeyi gerektirir.
İyi bilim ve mühendislik, bu tür optimizasyon problemlerinin birkaç saniye içinde çözülmesine yol açmıştır ve Concrete gibi TFHE derleyicileri halihazırda dahili bir modül olarak etkili bir TFHE parametre optimize ediciye sahiptir.
Çeşitli iyileştirmeler gelecekte TFHE optimize edicilerini daha da hızlı hale getirebilir, ancak bunlar olmasa bile TFHE ağlarının parametrelendirilmesinin - büyük ölçüde - bitmiş bir iş olduğu düşünülebilir.
Bu uygulamalar tamamen farklı türdendir. Geliştirici, hassas bir kısıtlamayla birlikte uygulanacak özel bir fonksiyonun matematiksel spesifikasyonunu tutar. Örneğin
burada x
, 0 ile 1 arasında bir gerçek sayıdır ve G
/ F
yaklaşımının kullanılması şu koşulda kabul edilebilir:
Geliştirici, standart API işlevleri oluşturarak G
bir zarfın arkasına uygulamanın muhtemelen çok yetersiz olacağını biliyor.
Derleyicinizin yapacağı şey, G
spesifikasyonunu karşılamak üzere özel olarak tasarlanmış yeni bir TFHE ağının anında üretilmesidir. Daha sonra bunu parametrelendirecek ve homomorfik uygulamayı üretmek için arka uç derlemesine devam edecek.
İşte bu noktada yol aniden daha engebeli hale geliyor.
Tam tanımını daha önce belirttiğim TFHE ağlarının otomatik olarak nasıl sentezlenebileceği konusunda günümüzde bilimsel bilgi eksikliği bulunmaktadır. Tamsayı değerli modüler aritmetiğe de dayanan bitişik devre türlerinin sentezine ilişkin araştırmalar bile en iyi ihtimalle azdır. Bu görevi A'dan Z'ye gerçekleştirebilecek önceden var olan herhangi bir sentezleyiciden bahsetmiyorum bile.
Sorunu çözmenin bir yolu, TFHE ağlarını boolean devrelere indirgeyerek hesaplama gücünün bir kısmından yararlanmaktır. Örneğin, bir TFHE nöronu üçlü boole kapısı görevi görmeye zorlanabilir.
ile
x_1, x_2, x_3
0/1 değerleri olarak uygulamak,m = 4
ve ağırlıklarını (w_1, w_2, w_3) = (2, -1, 1)
olarak ayarlayarak,[0, 1, 1, 0]
olarak ayarlıyor.
Aynı modüle sahip tüm olası ağırlıkları ve tabloları kaba kuvvetle zorlayarak, üçlü kapıların hesaplanmasına hizmet edebilecek bir TFHE nöronları sözlüğü oluşturulabilir. Bir sonraki adım aşağıdakilerden oluşur:
Bu, birçok açıklayıcı stratejiden sadece bir tanesidir çünkü boole devrelerine dayanan yöntemler çoktur. Ayrıca olağan ikili kapıları da göz önünde bulundurabilir ve bunları kısıtlı TFHE nöronlarıyla uygulayabilirsiniz. CEA'nın Cingulata'sı ve daha sonra Google'ın FHE aktarıcısı, TFHE ile bu yola tam anlamıyla öncülük etti.
Boolean sentezi agresif devre optimizasyon tekniklerinden yararlanır ve genel olarak çözülmüş bir teknik sorundur - ya da hemen hemen öyledir, bu yaklaşımı derleyiciyi oluşturan kişi için sağlam ve pratik kılar.
Ancak bir TFHE ağı bu şekilde oluşturulduktan sonra genişliği ve derinliği anormal derecede yüksek olabilir ve bu da genel performansın düşmesine neden olabilir. Dolayısıyla, TFHE nöronlarının -tamamen yapay- boole şartlandırmasını gevşeterek, onların tam ifade gücünden yararlanılabileceğine ve çok daha küçük, çok daha sığ ağlar elde edilebileceğine dair yaygın bir şüphe var.
Ancak yine de bunun nasıl yapılacağını açıkça belirlemek için daha fazla araştırmaya ihtiyaç var. TFHE ağını makine öğreniminden alınan uygun bir eğitim yöntemiyle öğrenmek gibi tamamen farklı yaklaşımların üstün sonuçlar vermesi mümkündür. Zaman gösterecek.
Sentez problemimizin çözüldüğünü ve verimli özel TFHE ağları sağladığını varsayarsak, kendinizi tüm hareketli parçaları bir araya getirmeye ve tüm işi yapan bir derleyici tasarlamaya hazır bulacaksınız:
Hassas değişkenlerin basitçe şifrelenmiş olarak açıklandığı düz bir program girdi olarak alınır.
Önceden eğitilmiş sinir ağlarını veya diğer makine öğrenimi modellerini kabul edecek ve bunları TFHE ağları olarak yeniden yorumlayacaktır.
Matematiksel spesifikasyondan yeni yapılmış fonksiyon maketlerini kabul edecek ve özel TFHE ağları oluşturmak için anında sentez gerçekleştirebilecek.
Derleme ünitesinde asılı bırakılan tüm parametrelenmemiş TFHE ağlarını, gerektiğinde bir optimize edici modül kullanarak yürütülebilir örneklere dönüştürecektir.
Çeşitli hedef TFHE çalışma zamanları ve/veya donanım mimarileri için derlemenin arka uç aşamasını gerçekleştirecektir.
Daha hızlı TFHE ağlarının sentezini ve parametrelendirilmesini sağlamak için belirli donanım hızlandırıcılardan (maliyet modelleri aracılığıyla) yararlanacaktır.
Kontrol akışının otomatik olarak düzenlenmesi için biraz destek de ekleseniz iyi olur, böylece geliştiricinin artık bunu umursamasına bile gerek kalmaz.
Bu, FHE uygulama geliştiricilerine en üst düzeyde geliştirme deneyimi sunacaktır.
Genel amaçlı FHE programlama bağlamında, bir TFHE kütüphanesi, önceden var olan araç zincirleriyle modülerlik ve tamamen özerk bir geliştirme deneyimi sağlayabilir.
TFHE, özellikle şifreli makine öğrenimi çıkarımı ve önümüzdeki yıllarda yüksek hızlı şifrelenmiş veri işleme ve diğer özel FHE uygulamaları için geliştiricinin ihtiyaçlarını bu noktanın ötesinde karşılayabilecek özel derleme tekniklerine öncülük etmektedir.
Genel olarak TFHE, yazılım geliştirme dünyasında büyük başarı sağlayabilecek daha entegre ve uyarlanabilir FHE araç zincirleri oluşturmak için net bir teknoloji yolu sağlar ve herkesin benzeri görülmemiş bir kolaylıkla oluşturup çalıştırabileceği, gizlilik öncelikli yeni çözümler dalgasını doğurur.
Yalnızca TFHE arama ağlarına odaklanarak, TFHE'nin destekleyebileceği birçok hesaplama modeli arasından yalnızca birini kullandım. Araştırmalar giderek daha fazla yeteneği ortaya çıkardıkça, TFHE'yi kullanmanın yeni yollarının gün yüzüne çıkacağına şüphe yok.
Hangileri ve ne zaman olduğu başka bir hikaye. Ancak bu hikayenin arkasında, gizli bilgi işlemin geleceğine ilişkin bir dizi heyecan verici ve potansiyel olarak aydınlatıcı sorular gizleniyor.