Yazan: Vitalik Buterin

Derleyen: Yangz, Techub Haberleri

Ethereum protokol tasarımında, Ethereum'un başarısı için kritik olan ancak daha büyük bir alt kategoriye tam olarak uymayan birçok "küçük dokunuş" vardır. Uygulamada içeriğin yaklaşık yarısı çeşitli EVM iyileştirmeleriyle ilgili, geri kalanı ise çeşitli niş konularla ilgili. Bu makale bu konuyu inceleyecektir.

The Splurge, 2023 Yol Haritası The Splurge'ın temel hedefleri:

Mevcut EVM'nin statik olarak analiz edilmesi zordur, bu da verimli uygulamalar oluşturmayı, kodu resmi olarak doğrulamayı ve zaman içinde daha da genişletmeyi zorlaştırır. Ek olarak, son derece verimsizdir ve ön derleme yoluyla açıkça desteklenmedikçe birçok gelişmiş şifreleme tekniği formunun uygulanmasını zorlaştırır.

Mevcut EVM iyileştirme yol haritasının ilk adımı, bir sonraki hard fork'ta tanıtılması planlanan EVM Nesne Formatıdır (EOF) . EOF, EVM kodunun birçok önemli özelliğe sahip yeni bir versiyonunu belirten bir dizi EIP'dir ; bunlardan en öne çıkanları şunlardır:

EOF Kod Çerçevesi Her ne kadar eski sözleşmeler en sonunda kullanımdan kaldırılsa da (ve hatta belki de EOF koduna zorlanabilir), eski sözleşmeler var olmaya devam edecek ve oluşturulabilecektir. Yeni sözleşmeler, program işlevselliği nedeniyle biraz daha küçük bayt kodlarının yanı sıra EOF'ye özgü yeni özellikler veya benzersiz gaz maliyeti azaltımı da dahil olmak üzere, EOF'nin getirdiği verimlilik iyileştirmelerinden yararlanacaktır. EOF'nin kullanıma sunulmasıyla daha fazla yükseltme daha kolay hale gelecektir. Şu anda en eksiksiz olanı EVM Modüler Aritmetik Uzantısıdır (EVM-MAX) . EVM-MAX, özellikle modüler aritmetik için yeni bir dizi işlem oluşturur ve bunları diğer işlem kodlarının erişemeyeceği yeni bir bellek alanına yerleştirir. Bu sayede Montgomery çarpımı gibi optimizasyon işlemlerinden yararlanılabilir. Daha yeni bir fikir ise EVM-MAX'ı tek talimatlı çoklu veri (SIMD) işlevselliğiyle birleştirmektir. SIMD , Greg Colvin'in EIP-616'sından başlayarak uzun süredir Ethereum'da küçük bir tasarım olarak ortalıkta dolaşıyor. SIMD, karma işlevleri, 32 bit STARK'lar ve kafes şifreleri dahil olmak üzere birçok şifreleme algoritması biçimini hızlandırmak için kullanılabilir. EVM-MAX ve SIMD, EVM'nin performans odaklı uzantılarının doğal bir birleşimidir. Birleşik EIP'nin genel tasarım fikri, EIP-6690'ı başlangıç ​​noktası olarak almak ve ardından:

Bu, eliptik eğri şifrelemesi, küçük etki alanı şifrelemesi (Poseidon, daire STARK'lar gibi), geleneksel karma işlevleri (SHA256, KECCAK, BLAKE gibi) ve kafes şifreleri dahil olmak üzere birçok şifreleme algoritması biçimini uygulamak için yeterlidir. Elbette başka EVM yükseltmeleri de mümkündür ancak şu ana kadar çok daha az ilgi gördüler.

Bu, eliptik eğri şifrelemesi, küçük etki alanı şifrelemesi (Poseidon, daire STARK'lar gibi), geleneksel karma işlevleri (SHA256, KECCAK, BLAKE gibi) ve kafes şifreleri dahil olmak üzere birçok şifreleme algoritması biçimini uygulamak için yeterlidir. Elbette başka EVM yükseltmeleri de mümkündür ancak şu ana kadar çok daha az ilgi gördüler.

Şu anda EOF'un bir sonraki hard fork'a dahil edilmesi planlanıyor. Bir planın kaldırılma ihtimali her zaman mevcut olsa da (önceki son dakikada planların hard forklardan kaldırıldığı durumlar olmuştur), bunu yapmak çetin bir mücadele olacaktır. EOF'un kaldırılması, gelecekte EVM'ye yapılacak yükseltmelerin EOF gerektirmeyeceği anlamına gelir; bu yapılabilir ancak daha zor olabilir. EVM ile temel denge, L1 karmaşıklığına karşı altyapı karmaşıklığıdır. Bir EVM uygulamasına EOF eklemek çok fazla kod gerektirir ve statik kod kontrolü oldukça karmaşıktır. Ancak bunun karşılığında üst düzey dili basitleştirebilir, EVM uygulamasını basitleştirebilir ve başka avantajlar elde edebiliriz. Şöyle söyleyelim, Ethereum L1'de sürekli iyileştirmelere öncelik veren bir yol haritası EOF'yi içerecek ve üzerine inşa edilecek. Önemli görevlerden biri EVM-MAX plus SIMD'ye benzer işlevleri uygulamak ve çeşitli şifreleme işlemleri tarafından ne kadar gaz tüketildiğine ilişkin kıyaslama testleri yapmaktır.

L1, EVM'sini ayarladıktan sonra L2 daha kolay bir şekilde kopyalayabilir. Bir tarafın ayarlanması ve diğer tarafın ayarlanmaması uyumsuzluğa yol açabilir ve bunun da kendi dezavantajları vardır. Ayrıca EVM-MAX plus SIMD, birçok doğrulama sisteminin gaz maliyetini azaltarak L2 verimliliğini artırabilir. Önceden derlenmiş kodun EVM koduyla değiştirilmesinin verimlilik üzerinde çok büyük bir etkisi olmayabilir, ancak aynı görevi yerine getirerek daha fazla önceden derlenmiş kodun kaldırılmasını kolaylaştıracaktır.

Günümüzde işlemler yalnızca tek yönlü olarak, ECDSA imzalarıyla doğrulanabilmektedir. Hesap soyutlamanın asıl amacı, hesap doğrulama mantığının herhangi bir EVM kodu olabilmesi için bu temelde genişletmektir. Bu, aşağıdakiler de dahil olmak üzere bir dizi uygulamaya olanak tanır:

Hesap soyutlamanın 2015 yılında başlamasından bu yana, bu hedefler geniş bir dizi "kolaylık hedefine" dönüştü; öyle ki, ETH'si olmayan ancak diğer ERC20 tokenleri olan bir hesap, bu tokenları gas ücretlerini ödemek için kullanabilir. Aşağıdaki şekil bu hedeflerin özetidir:

MPC, bir anahtarı birden fazla parçaya bölen, bunları birden fazla cihazda depolayan ve anahtar parçaları doğrudan birleştirmeden imzalar oluşturmak için kriptografiyi kullanan 40 yıllık bir teknoloji olan çok partili hesaplamayı ifade eder. EIP-7702 , bir sonraki hard fork'ta tanıtılması planlanan bir EIP'dir ve kısa vadede kullanıcı deneyimini geliştirmek için EOA kullanıcıları da dahil olmak üzere tüm kullanıcıların hesap soyutlamanın rahatlığından yararlanmasına izin verme ihtiyacının giderek daha fazla tanınmasının bir parçasıdır. Ve iki ekolojiye bölünme sonucundan kaçının. Bu çalışma EIP-3074'te başladı ve EIP-7702'de sona erdi. EIP-7702, hesap soyutlamanın "kolaylık özelliğini" artık EOA (harici hesaplar, ECDSA imzaları tarafından kontrol edilen hesaplar) dahil olmak üzere tüm kullanıcılar için kullanılabilir hale getiriyor. Grafikten, bazı zorlukların (özellikle "kolaylık" ile ilgili) çok taraflı hesaplama veya EIP-7702 gibi artımlı teknolojiler ile çözülebileceğini ancak ilk hesap soyutlama teklifini motive eden güvenlik hedeflerinin çoğunun bu ancak geri dönüp akıllı sözleşme kodunun işlem doğrulamasını kontrol etmesine izin veren orijinal sorunu çözerek çözüldü. Bu henüz yapılmadı çünkü bunu güvenli bir şekilde başarmak hâlâ zorlu bir iş.

Hesap soyutlamanın özü, yalnızca EOA'ların işlemleri başlatması yerine akıllı sözleşmelere izin vermektir ve karmaşıklık, bunun merkezi olmayan bir ağı korumaya ve hizmet reddi saldırılarına direnmeye yardımcı olacak bir şekilde nasıl uygulanacağından kaynaklanmaktadır. Çoklu doğrulama sorunları önemli bir zorluktur:

Doğrulama işlevlerinin tümü tek bir S değerine bağlı olan 1000 hesap olduğunu ve bellek havuzundaki işlemlerin hepsinin geçerli S değeri altında geçerli olduğunu varsayalım. Bu durumda, S değerini değiştiren tek bir işlem, bellek havuzundaki tüm diğer işlemleri geçersiz kılacaktır. Bu sayede saldırganlar çok düşük maliyetle mempool'a spam gönderebilir ve ağdaki düğüm kaynaklarını tıkayabilir. Yıllar boyunca DoS risklerini sınırlandırırken işlevselliği genişletmek için çok çalıştık ve sonunda "ideal hesap soyutlamasına" nasıl ulaşılacağı konusunda fikir birliğine vardık ve ERC-4337'yi önerdik.

ERC-4337, kullanıcı işlemlerinin işlenmesini doğrulama ve yürütme olmak üzere iki aşamaya ayırır. Önce tüm doğrulamalar, ardından tüm yürütmeler gerçekleştirilir. Mempool'da bir kullanıcı işlemi, yalnızca kullanıcı işleminin doğrulama aşamasının yalnızca kendi hesabını içermesi ve ortam değişkenlerini okumaması durumunda kabul edilecektir. Bu, çoklu doğrulama saldırılarını önler ve aynı zamanda doğrulama adımında katı gaz sınırlarını zorunlu kılar. ERC-4337, protokol dışı standart (ERC) olarak tasarlandı çünkü o zamanlar Ethereum istemci geliştiricileri Birleştirme ile meşguldü ve diğer özellikleri geliştirmek için boş kapasiteleri yoktu. ERC-4337'nin normal işlemler yerine nesne olarak kullanıcı işlemlerini kullanmasının nedeni budur. Ancak son zamanlarda ERC-4337'de önerilen özelliklerin en azından bir kısmının protokole dahil edilmesinin gerekli olduğunu fark ettik. Bunun iki ana nedeni şunlardır:

Ayrıca ERC-4337 iki işlevi de genişletir:

Çözülmesi gereken asıl konu, hesap soyutlamanın protokole tam olarak nasıl dahil edileceğidir. Son zamanlarda en popüler çözümlerden biri, EOF'ye dayalı hesap soyutlamayı amaçlayan EIP-7701'dir. Yani hesap, doğrulama için ayrı bir kod segmenti belirleyebilir. hesap işleminde Kod yürütülecektir.

Hesaplar için EIP-7701 EOF kod yapısı Bu yaklaşımın güzelliği, yerel hesap soyutlamasını görüntülemenin iki eşdeğer yolu olduğunu açıkça göstermesidir:

Doğrulama sırasında çalıştırılabilir kodun karmaşıklığını baştan itibaren sıkı bir şekilde sınırlandırırsak (harici duruma erişime izin vermezsek, hatta gazı ilk etapta kuantum dirençli veya gizliliği koruyan uygulamalar için yararlı olamayacak kadar düşük sınırlandırırsak), o zaman bu Bu yaklaşımın güvenliği hemen ortadadır: ECDSA doğrulamasını, benzer bir zaman alan EVM kod yürütmesiyle değiştirir. Ancak zamanla, gizliliği koruyan uygulamaların tekrarlayıcılar olmadan çalışmasına izin vermek ve kuantum direncine sahip olmak önemli olduğundan, bu kısıtlamaları gevşetmemiz gerekecek. Bunu yapmak için, doğrulama adımlarının son derece minimalist olmasına gerek kalmadan DoS risklerini daha esnek bir şekilde ele almanın yollarını gerçekten bulmamız gerekiyor. Ana ödün, daha az tatmin edici bir şeyi olabildiğince çabuk benimsemek ile daha uzun süre beklemek ve belki de daha ideal bir çözüm bulmak arasında görünüyor. İdeal çözüm büyük olasılıkla bir tür hibrit olacaktır. Hibrit bir yaklaşım, bazı kullanım durumlarını daha hızlı bir şekilde dahil ederek diğerlerini ele almak için daha fazla zaman bırakmak olacaktır. Diğer bir seçenek de hesap soyutlama sürümünü ilk önce L2'ye dağıtmaktır. Ancak buradaki zorluk, L2 ekibinin bir teklifi benimsemeye istekli olması için, L1 ve/veya diğer L2'lerin daha sonraki bir tarihte uyumlu versiyonları benimseyeceklerinden emin olmaları gerektiğidir. Açıkça dikkate almamız gereken diğer bir uygulama, hesapla ilgili durumu L1'de veya özel bir L2'de saklayabilen ve aynı zamanda L1 ve herhangi bir uyumlu L2'de de kullanılabilen anahtar depolama hesaplarıdır . Bunu verimli bir şekilde yapmak için L2'nin, L1SLOAD veya REMOTESTATICCALL gibi işlem kodlarının yanı sıra L2'de hesap soyutlama uygulamasını desteklemesi gerekebilir.

Dahil etme listelerinin hesap özeti işlemlerini desteklemesi gerekir. Uygulamada, kapsanan bir listenin ihtiyaçları ile merkezi olmayan bir bellek havuzunun ihtiyaçları çok benzer olacaktır, ancak ilki biraz daha esnektir. Ek olarak, hesap soyutlamanın uygulanması L1 ve L2'de mümkün olduğu kadar birleşik olmalıdır. Gelecekte çoğu kullanıcının anahtar depolama toplamalarını kullanmasını beklersek, hesap soyutlaması tasarlanırken bu dikkate alınmalıdır.

EIP-1559, 2021'de Ethereum'da etkinleştirildi ve ortalama blok ekleme sürelerini önemli ölçüde iyileştirdi.

Ancak EIP-1559'un mevcut uygulamasının aşağıdaki yönlerden kusurları vardır:

Ancak EIP-1559'un mevcut uygulamasının aşağıdaki yönlerden kusurları vardır:

Blob'lara yönelik daha sonraki çözüm ( EIP-4844 ), açıkça ilk sorunu çözmek için tasarlanmıştır ve genel olarak daha basittir. Ancak ne EIP-1559'un kendisi ne de EIP-4844 ikinci sorunu çözmeye çalışmıyor. Dolayısıyla mevcut statüko, iki farklı mekanizmanın kafa karıştırıcı bir durumudur ve hatta her iki mekanizmanın da zaman içinde iyileştirilmesi gerekmesi mümkündür. Buna ek olarak, Ethereum kaynak fiyatlandırmasında EIP-1559 ile ilgili olmayan ancak EIP-1559'un ayarlanmasıyla çözülebilecek başka kusurlar da vardır. Ana sorunlardan biri ortalama durum ile en kötü durum arasındaki farktır; yani Ethereum'un kaynak fiyatlandırması en kötü durumu ele alacak şekilde ayarlanmalıdır; yani bir bloğun tüm gaz tüketimi bir kaynağı kaplar, ancak ortalama durum en kötü durumu ele alacak şekilde ayarlanmalıdır. kasa kullanımının çok daha az olması verimliliğin düşmesine neden olur.

Çok boyutlu gaz , farklı kaynaklar için farklı fiyatlar ve limitler belirleyerek bu verimsizliklere bir çözümdür. Bu kavram teknik olarak EIP-1559'dan bağımsızdır ancak EIP-1559 bunu kolaylaştırır. EIP-1559 olmadan, birden fazla kaynak kısıtlamasına sahip bir bloğun paketlenmesinin nasıl optimize edileceği, karmaşık , çok boyutlu bir "sırt çantası" sorunu olacaktır. EIP-1559 ile çoğu blok hiçbir kaynakta tam kapasitede olmayacaktır, dolayısıyla "yeterli ücret ödeyen herhangi bir işlemi kabul et" şeklindeki basit algoritma yeterli olacaktır. Bugün yürütme ve bloblarda çok boyutlu gaz kurulumumuz var ve prensipte bunu çağrı verileri, durum okuma/yazma ve durum boyutu genişletme dahil olmak üzere daha fazla boyuta genişletebiliriz. EIP-7706 çağrı verilerine yeni bir gaz boyutu getiriyor. Aynı zamanda, çok boyutlu gaz mekanizmasını da basitleştirerek üç gaz türünün tamamının tek bir (EIP-4844 tarzı) çerçeveye ait olmasını sağlar ve böylece EIP-1559'un matematiksel kusurlarını çözer. EIP-7623, tamamen yeni bir boyut getirmeden, maksimum çağrı verilerine daha sıkı sınırlar koyarak, ortalama durum ve en kötü durum kaynak sorununa daha kapsamlı bir çözümdür. Diğer bir yön ise güncelleme hızı problemini çözmek ve EIP-4844 mekanizmasının getirdiği anahtar değişmezini korurken daha hızlı bir taban ücret hesaplama algoritması bulmaktır (yani, uzun vadede ortalama kullanım hedef değere çok yakındır).

Çok boyutlu gazın iki ana dezavantajı vardır:

Çağrı verileri için protokol karmaşıklığı nispeten küçük bir sorundur, ancak "EVM içindeki" gaz boyutu (depolama okuma ve yazma gibi) için daha büyük bir sorun haline gelir. Buradaki zorluk, gas limitini belirleyenin yalnızca kullanıcı değil, aynı zamanda diğer sözleşmeleri çağırırken limiti de sözleşmenin belirlemesidir. Artık sınır koyabilmelerinin tek yolu tek boyutludur. Bu sorunu çözmenin basit bir yolu, çok boyutlu gazın yalnızca EOF içinde kullanılabilmesidir çünkü EOF, sözleşmelerin diğer sözleşmeleri çağırırken gaz limitleri belirlemesine izin vermez. EOF olmayan sözleşmeler, depolama işlemlerini gerçekleştirirken tüm gaz türleri için ücret ödemek zorundadır (örneğin, SLOAD ücreti blok depolama erişim gaz limitinin %0,03'ü ise, bu durumda EOF olmayan kullanıcılardan da yürütme ücretinin %0,03'ü kadar ücret alınacaktır) gaz limiti). Çok boyutlu gaz hakkında daha fazla araştırma yapılması, aradaki dengenin anlaşılmasına ve ideal dengenin belirlenmesine yardımcı olacaktır.

Çok boyutlu gazın başarılı bir şekilde uygulanması, belirli "en kötü durum" koşulları altında kaynak kullanımını önemli ölçüde azaltabilir, böylece STARK tabanlı karma ikili ağaçları desteklemek için performansı optimize etme baskısını hafifletebilir. Eyalet büyüklüğündeki büyüme için zor bir hedef belirlemek, müşteri geliştiricilerinin gelecekteki ihtiyaçları planlamasını ve öngörmesini kolaylaştıracaktır. Yukarıda belirtildiği gibi, EOF gazın gözlemlenemeyen özelliklerine sahip olduğundan, çok boyutlu gazın daha ekstrem versiyonlarının uygulanmasını kolaylaştırabilir.

Şu anda Ethereum, teklif verenleri seçmek için RANDAO tabanlı rastgelelik kullanıyor. RANDAO tabanlı rastgelelik, her teklif sahibinin önceden taahhüt ettikleri bir sırrı açıklamasını gerektirerek ve açıklanan her sırrı rastgeleliğe karıştırarak çalışır. Bu nedenle, her teklif sahibinin "1 manipülasyon gücü" vardır ve gelmeyerek (bir maliyet karşılığında) rastgeleliği değiştirebilir. Bir tekliften vazgeçip kendinize iki yeni teklif almak nadir olduğundan, bu teklif sahibi için mantıklıdır. Ancak rastgelelik gerektiren zincir içi uygulamalar için bu uygun değildir. İdeal durumda, daha güçlü bir rastgelelik kaynağı buluruz.

Doğrulanabilir Gecikme Fonksiyonu (VDF), yalnızca sıralı olarak hesaplanabilen ve paralelleştirme ile hızlandırılamayan bir fonksiyondur. Basit bir örnek, tekrarlanan karma işlemidir: for i in range(10**9): x = hash(x) hesaplama. SNARK doğruluk kanıtı ile çıktı rastgele bir değer olarak kullanılabilir. Buradaki fikir, girdilerin T zamanında mevcut olan bilgilere göre seçilmesi, ancak T zamanında çıktıların henüz bilinmemesidir: çıktılar yalnızca T zamanından bir süre sonra, birisi hesaplamayı tamamen çalıştırdığında bilinecektir. Hesaplamaları herkes yapabildiğinden, sonuçları saklamak ve dolayısıyla onları manipüle etmek imkansızdır. Doğrulanabilir gecikme fonksiyonlarının ana riski beklenmedik optimizasyondur. Birisi bir fonksiyonun beklenenden çok daha hızlı nasıl çalıştırılacağını keşfederse, T zamanında ortaya çıkardıkları bilgiler gelecekteki çıktılara göre manipüle edilebilir. Beklenmeyen optimizasyon iki şekilde gerçekleşebilir:

Başarılı bir VDF oluşturmak, verimli ve pratik kalarak bu sorunların her ikisinden de kaçınmakla ilgilidir. (Örneğin, karma tabanlı yaklaşımlarla ilgili bir sorun, gerçek zamanlı SNARK kanıtlarının çok fazla donanım gerektirmesidir. Donanım hızlandırma genellikle kamu çıkarını ilgilendiren aktörlerin VDF için en uygun ASIC'leri makul derecede yakın oluşturmalarına ve dağıtmalarına izin verilerek çözülür.)

Şu anda Ethereum araştırmacılarının gereksinimlerini tam anlamıyla karşılayan bir VDF yapısı bulunmuyor. Böyle bir işlevi bulmak için hala yapılması gereken çok iş var. Mükemmel VDF yapısını bulursak, temel ödünler işlevsellik, protokol karmaşıklığı ve güvenlik riskleri olacaktır. Bir VDF'nin güvenli olduğunu düşünürsek ancak güvensiz olduğu ortaya çıkarsa, nasıl uygulandığına bağlı olarak güvenlik, RANDAO varsayımına (her saldırgan yalnızca 1 biti işleyebilir) veya daha kötüsüne indirgenir. Bu nedenle, VDF yanlış gitse bile protokolü bozmaz ancak uygulamayı veya büyük ölçüde VDF'ye dayanan herhangi bir yeni protokol işlevini bozar.

VDF, Ethereum protokolünün nispeten bağımsız bir bileşenidir, teklif verenin seçiminin güvenliğini artırmanın yanı sıra, şifrelenmiş bellek havuzlarının yanı sıra rastgeleliğe dayanan zincir içi uygulamalar için de kullanılabilir. Bununla birlikte, VDF tabanlı kriptografik bellek havuzları hâlâ henüz gerçekleşmemiş ek kriptografik keşiflere dayanmaktadır. Akılda tutulması gereken bir nokta, donanım belirsizlikleri nedeniyle, VDF çıktısının üretildiği zaman ile bu çıktının dahil edildiği zaman arasında bir miktar "boşluk" olacağıdır. Bu, bilginin birkaç blok önceden elde edilmesi gerektiği anlamına gelir. Bu, ödenmesi kabul edilebilir bir bedel olabilir ancak tek slotlu sonuçlandırma veya komite seçimi gibi tasarımlarda dikkate alınmalıdır.

Nick Szabo'nun en ünlü makalelerinden biri " Tanrı Anlaşması " üzerine 1997 tarihli bir makaledir. Bu makalede, çok taraflı uygulamaların etkileşimleri yönetmek için genellikle "güvenilir üçüncü taraflara" güvendiğine dikkat çekiyor. Ona göre, kriptografinin rolü, aslında herhangi bir aktöre güvenmeden aynı işi yapan, simüle edilmiş güvenilir bir üçüncü taraf yaratmaktır.

Nick Szabo'dan "Matematiksel Olarak Güvenilir Protokoller" Şu ana kadar bu ideale yalnızca kısmen yaklaştık. İhtiyacımız olan tek şey şeffaf bir sanal bilgisayarsa (verilerin ve hesaplamaların kapatılamayacağı, sansürlenemeyeceği veya değiştirilemeyeceği) ve amaç gizlilik değilse, o zaman blockchain sınırlı ölçeklenebilirlikle de olsa bunu yapabilir. Ancak eğer gizlilik hedeflerden biriyse, yakın zamana kadar belirli uygulamalar için yalnızca birkaç özel protokole sahip olabiliyorduk; örneğin temel kimlik doğrulama için dijital imzalar, ham anonimlik için halka imzalar ve zincirlenebilir halka imzalar , kimlik tabanlı şifreleme (daha fazlasını etkinleştirmek için) güvenilir ihraççılar hakkındaki belirli varsayımlar altında uygun şifreleme), Chaumian elektronik parası için kör imzalar vb. Bu yaklaşım her yeni uygulama için büyük çaba gerektirir. 2010'larda programlanabilir kriptografiye dayalı daha güçlü bir yaklaşımı ilk kez gördük. Her yeni uygulama için yeni bir protokol oluşturmak yerine, keyfi programlara kriptografik garantiler eklemek için güçlü yeni protokoller (özellikle ZK-SNARK) kullanabiliriz. ZK-SNARK'lar, kullanıcıların ellerinde tuttukları verilerle ilgili keyfi iddiaları, doğrulanması kolay bir şekilde kanıtlamalarına olanak tanır ve iddianın kendisi dışında herhangi bir veriyi açığa çıkarmaz. Bu, hem gizlilik hem de ölçeklenebilirlik açısından ileriye doğru atılmış büyük bir adım ve bana göre Google'ın yapay zeka alanındaki Transformer'ı gibi. Binlerce yıllık uygulamaya özel problemler birdenbire, her türlü can sıkıcı problemi çözmek için kullanabileceğimiz evrensel bir çözüme kavuştu. Dahası, ZK-SNARK'lar benzer son derece güçlü üç genel amaçlı ilkelden yalnızca ilkidir. Bu protokoller o kadar güçlü ki, ne zaman onları düşünsem, çocukluğumdan kalma son derece güçlü Mısır Tanrıları destesi geliyor aklıma (o kadar güçlü ki düellolarda kullanılmasına izin verilmiyor). Benzer şekilde kriptografide de "Üç Tanrı Anlaşması" vardır: ZK-SNARK'lar, Tamamen Homomorfik Şifreleme (FHE) ve Şaşırtma.

ZK-SNARK'ları yüksek bir olgunluk seviyesine kadar geliştirdik . Geçtiğimiz beş yılda kanıtlayıcı hızı ve geliştirici dostu olma özelliği önemli ölçüde gelişti ve ZK-SNARK'lar Ethereum'un ölçeklenebilirlik ve gizlilik stratejilerinin temel taşı haline geldi. Ancak ZK-SNARK'ların önemli bir sınırlaması var; o da, bunu kanıtlamak için verinin bilinmesinin gerekli olmasıdır. ZK-SNARK uygulamasındaki her durumun bir "sahibi" olması gerekir ve bu "sahip", uygulamadaki tüm okuma veya yazma işlemlerini onaylayabilmelidir. İkinci protokolde bu kısıtlama yoktur, tamamen homomorfik şifrelemedir (FHE). FHE, verileri görmeden şifrelenmiş veriler üzerinde herhangi bir hesaplama yapılmasına olanak tanır. Bu şekilde, veriler ve algoritmalar gizli tutulurken, kullanıcı yararına kullanıcı verileri üzerinde hesaplamalar yapılabilir. Ayrıca MACI gibi oylama sistemlerini neredeyse mükemmel güvenlik ve gizlilik garantileriyle genişletebilir. FHE her zaman pratik uygulamalar için fazla verimsiz olduğu için eleştirildi, ancak artık yeterince verimli hale geldi ve ilgili uygulamalar ortaya çıktı.

Cursive, ortak çıkarları keşfetmek ve gizliliği korumak için iki taraflı bilgi işlem ve FHE'yi kullanan bir uygulamadır. Bununla birlikte, FHE'nin de kendi sınırlamaları vardır. FHE'ye dayalı herhangi bir teknolojinin hâlâ anahtarı elinde tutacak birine ihtiyacı vardır. Anahtar tutma yöntemi, M-of-N dağıtılmış bir kurulum olabilir veya hatta ikinci bir savunma katmanı eklemek için TEE bile kullanılabilir, ancak bu yine de bir sınırlamadır. Bu da üçüncü protokole, yani ayırt edilemezlik bulanıklığına yol açıyor. Protokol henüz olgunlaşmamış olsa da, 2020 yılı itibarıyla standart güvenlik varsayımlarına dayanan teorik olarak geçerli bir protokolümüz var ve uygulamaya yakın zamanda başlandı . Ayırt edilemeyen gizleme, keyfi hesaplamalar gerçekleştiren "şifreli bir programın" oluşturulmasına olanak tanır ve böylece programın tüm dahili ayrıntılarını gizler. Basit bir örnek olarak, özel anahtarınızı, onu yalnızca asal sayıları imzalamak için kullanmanıza izin veren karmaşık bir programa koyabilir ve ardından programı diğer insanlara dağıtabilirsiniz. Bu kişiler daha sonra programı herhangi bir asal sayıyı imzalamak için kullanabilir, ancak anahtarı alamazlar. Elbette, ayırt edilemez gizlemenin yetenekleri bunun çok ötesine geçer ve karma algoritmalarla birlikte, diğer herhangi bir kriptografik ilkel ve hatta daha fazlasını uygulamak için kullanılabilir. Şaşırtılmış bir programın yapamayacağı tek şey kendisinin kopyalanmasını engellemektir. Ancak bunun için ufukta çok daha güçlü bir şey belirecek: Herkesin bir kuantum bilgisayarı olduğu varsayılırsa, tek seferlik kuantum imzalar .

Gizleme ve tek seferlik imzalama ile neredeyse mükemmel, güvenilmez bir üçüncü taraf yaratabiliriz. Yalnızca kriptografiyle yapamayacağımız ve hâlâ blockchain'e ihtiyacımız olan şey, sansüre karşı direnci garanti etmektir. Bu teknolojiler yalnızca Ethereum'un kendisini daha güvenli hale getirmekle kalmayacak, aynı zamanda onun üzerine daha güçlü uygulamaların oluşturulmasına da olanak tanıyacak. Bu ilkellerin nasıl güçlendirildiğini anlamak için “oy verme” örneğini inceleyerek daha da anlayabiliriz. Oylama, çok güçlü doğrulanabilirlik ve gizlilik de dahil olmak üzere bir dizi zorlu güvenlik özelliğini karşılaması gereken ilginç bir konudur. Güçlü güvenlik özelliklerine sahip oylama protokolleri onlarca yıldır ortalıkta olsa da, ikinci dereceden oylama , ikili sınırlı ikinci dereceden finansman , küme eşleştirme ikinci dereceden finansman vb. gibi keyfi oylama protokollerini idare edebilecek bir tasarıma ihtiyacımız olsaydı, o zaman şunu umuyoruz: "oy sayma" adımı keyfi bir prosedür olacaktır:

Ayırt edilemez gizleme aynı zamanda diğer güçlü uygulamalara da olanak tanır. Örneğin:

Tek seferlik imzalarla, sansür saldırıları hala mümkün olmasına rağmen, blok zincirini %51 kesinlik tersine çevirme saldırılarına karşı bağışık hale getirebiliriz. Tek kullanımlık imzalara benzer ilkeller, kuantum parayı güçlendirebilir ve çift harcama sorununu blockchain olmadan çözebilir, ancak daha birçok karmaşık uygulama hala bir blockchain gerektiriyor. Eğer bu ilkeller yeterince verimli hale getirilebilirse, dünyadaki uygulamaların çoğu merkezi olmayan hale getirilebilir. Ana darboğaz uygulamanın doğruluğunun doğrulanmasıdır.

Her şeyden önce, ayırt edilemeyen gizleme teknolojisinin gelişimi son derece olgunlaşmamış olup, aday yapıların geliştirme hızı, uygulamaya göre milyonlarca kat daha yavaştır ve hiçbir şekilde kullanılamaz. Ayırt edilemezlik gizlemesi, "teorik" polinom zamanında çalışmasıyla ünlüdür, ancak aslında evrenin ömründen daha uzun bir sürede çalışır. Her ne kadar son protokoller çalışma sürelerini daha az aşırı hale getirmiş olsa da, ek yük düzenli kullanım için hala çok yüksektir. Üstelik kuantum bilgisayarlar mevcut bile değil. Şu anda internette okuyabileceğimiz tüm yapılar ya 4 bitten daha büyük hesaplamalar yapamayan prototiplerdir ya da gerçek kuantum bilgisayarları değildirler çünkü kuantum bileşenlere sahip olsalar da gerçekten anlamlı şekilde çalışamazlar. Shor'un algoritması veya Grover'ın algoritması gibi hesaplamalar. Son zamanlarda "gerçek" kuantum bilgisayarların artık çok uzakta olmadığına dair işaretler var. Ancak "gerçek" kuantum bilgisayarlar yakında piyasaya çıksa bile, sıradan insanların dizüstü bilgisayarlarında veya cep telefonlarında kuantum bilgisayarlarının olacağı gün büyük olasılıkla bu olacak. Güçlü kurumların eliptik eğri kriptografisini kırabilen kuantum bilgisayarları satın almalarından onlarca yıl sonra geldi. Ayırt edilemeyen gizleme için önemli bir değiş-tokuş güvenlik varsayımıdır. Egzotik varsayımları kullanan daha radikal tasarımlar da var. Bu tasarımların çalışma süreleri genellikle daha gerçekçidir ancak bu özel varsayımlar eninde sonunda bozulabilir . Zamanla, kafes şifreleri hakkında kırılamayacak varsayımlarda bulunmaya yetecek kadar bilgi edinebiliriz. Ancak bu yol daha risklidir. Daha ihtiyatlı bir yaklaşım, güvenliğinin "standart" varsayımlara indirgenebileceği kanıtlanan protokollere bağlı kalmak olacaktır, ancak bu, yeterince hızlı çalışan bir protokol elde etmenin daha uzun süreceği anlamına gelebilir.

Son derece güçlü şifreleme teknolojisi oyunun kurallarını tamamen değiştirebilir. Örneğin:

Başlangıçta uygulama katmanı büyük fayda sağlayacaktır çünkü Ethereum L1'in kendisinin güvenlik varsayımlarına uyması gerekmektedir. Ancak uygulama katmanının tek başına kullanılması, tıpkı ZK-SNARK'ların ortaya çıkması gibi, oyunun kurallarını değiştirebilir.