ethereum
Bir hatalı çağrıdan sonra çalışmaya devam eden bir sözleşme, bugün çağrılan tarafın kasıtlı olarak geri döndüğünü mü yoksa basitçe gazını tükettiğini mi belirlemek için güvenilir bir yola sahip değil. Bu boşluk, yetersiz gaz nedeniyle oluşan rahatsızlık sorununun kökünü oluşturuyor ve yeni bir taslak önerisi, EVM seviyesinde bu boşluğu kapatmayı amaçlıyor. Pazartesi günü Ethereum Magicians'ta tartışma için açılan EIP-8456, geçici olarak 2 gaz maliyetiyle 0xA5 opcode'unda CALLSTATUS adlı bir komut ekliyor. Bu komut, mevcut çerçevedeki en son çağrı veya oluşturma işleminin tamamlanma durumunu üç bit olarak itiyor. Bit 0, geri dönmeyi; bit 1, gaz tükenmesi gibi istisnai bir durdurmayı; bit 2 ise alttaki bir çerçevede durdurma olduğunu gösteriyor. Yazar, bugünün tek kanıttan gazleft() aritmetiğinden ibaret olduğunu ve her repricing çatallanmasının bu eşikleri bozduğunu belirtiyor. Önerilen EIP-8037'in iki boyutlu gaz sistemi, bu aritmetiği daha da zayıflatacak, çünkü rezervu GAS opcode'u aracılığıyla görünmez olacak. Peki üçüncü bit neden gerekli? Çoğu gerçek çağrı, proxy'ler, OpenZeppelin'in functionCall sarmalayıcısı, Multicall3 veya ERC-1271 imza denetleyicileri gibi ara birimlerden geçer. Sadece doğrudan çağrılanın son durumu raporlanırsa, gaz tükenmesi durdurmasını yakalayıp nedenle geri dönen bir sarmalayıcı, kasıtlı bir geri dönüş gibi görünecektir. Taslak, her çerçeve boyunca ilerleyen bir tutucu bayrak tutar; böylece sadece gazı kontrol eden bir gönderici, bir çağrının basit bir geri dönüş okumasını asla sağlayamaz. Bu sistem nedenleri değil sonuçları raporlar ve bir çağrılan hala INVALID ile kasıtlı bir durdurma üretebilir. Yalnızca yayınlandıktan sonra yazılan kodları korur, çünkü dağıtılmış sözleşmeler bunu okumaz. Henüz dış incelemeler yoktur, opcode numarası hâlâ açık olup, 58 listelenen durum için bir prototype ve testler hâlâ beklenmektedir. Bağlantı - https://t.co/KnByUBgWrY
Çoğu Ethereum cüzdanı, adresinizi bilen herkese tam finansal geçmişinizi göstermeye devam ediyor ve Ethereum Vakfı, bu durumu artık bir gizlilik ayrıntısı değil, bir güvenlik açıklaması olarak tanımlıyor. Pazartesi günü Vakıf, geçen haftanın saldırılarını ve istismarlarını daha net bir şekilde vurguladı: gizlilik ve güvenlik, ayrı hedefler olarak ele alınamaz. Vakıf, gizliliğin varsayılan durum olduğu zaman, bir saldırganın sizin zincir üstü geçmişinizi kullanmasına karşı endişelenmeniz daha az gerekli olacak dedi. Yayın, Vakfın gizlilik odaklı cüzdan araçları projesi olan Kohaku hakkında bir güncelleme alıntıladı. JavaScript deposu, bir cüzdan ekibinin tek tek seçebileceği paketlere bölünmüştür. Gizlilik Havuzları ve Tornado Cash için kütüphaneler mevcuttur; README şu anda Railgun kütüphanesini bakım altında olarak işaretlemektedir. Bir eklenti paketi, korumalı havuz protokolleri için standart bir arayüz tanımlar, böylece bir cüzdan tümüne aynı şekilde bağlanabilir. Bir sağlayıcı paketi, ethers, viem, Helios ve Colibri üzerinde soyutlama yapar. Depo ayrıca post-kuantum ERC-4337 hesabı da içerir. Rust crate'leri ayrı bir kardeş depoda yer alır. Bu projenin, kullanıcıların fonlarını taşımalarını isteyen başka bir gizlilik cüzdanı değil, bir SDK olarak şekillendirilmiş olması beni memnun ediyor. Amacımız, mevcut cüzdanların her ekip üç protokolü yeniden uygulamadan korumalı akışları eklemesidir. README, durumun nerede olduğunu açıkça belirtiyor. Bazı bölümler üretim için hazır değil olarak işaretlenmiş ve paketler denetlenmemiş kodlar içeriyor. Ambire'den Jordan Enev, geçen Cuma günü ekibin entegrasyonları test etmek için aylar harcadığını ve henüz herhangi bir kamuoyuna duyurulmuş bir başlatma tarihi olmadığını söyledi. Vitalik ve Nicolas Consigny, @EFDevcon'da önümüzdeki Salı günü Ambire ile Kohaku'yı Ethereum ana ağında gösterecekler.
Terminaliniz artık size yanıt verebiliyor, ve ilginç olan şey, herhangi bir bulut API'sini çağırmadan bunu yapıyor. Cumartesi günü, Ollama, macOS'ta metinden konuşmaya (text-to-speech) desteğiyle 0.40.11 sürümünü yayınladı. İlk konuşma modeli, Gradium'dan gelen küçük TTS modelleri ailesi olan Phonon. Onu `ollama pull phonon` komutuyla indirip diğer herhangi bir model gibi çalıştırabilirsiniz. Geliştiricilerin gerçekten ilgileneceği kısım API'dir. Phonon, yerel makinede OpenAI uyumlu `/v1/audio/speech` uç noktasını kullanır. Eğer kodunuz zaten konuşma için OpenAI SDK'sını kullanıyorsa, belgeler sadece yeni bir temel URL gerektirdiğini söylüyor. Yanıt, ses üretilirken akış halinde gelir, bu nedenle tam metin bitmeden önce oynatma başlayabilir. Hatta bir sohbet modelinin yanıtını doğrudan Phonon'a aktarabilir ve ilk cümle tamamlandığında konuşmaya başlar. Çıktı, varsayılan olarak WAV formatında 24 kHz mono ses; isterseniz 16-bit PCM olarak da alınabilir. Belgelerde, kolayca aşılabilecek bazı sınırlar listelenmiştir. Her istek en fazla 4.096 karakter alır, ancak `ollama run` daha uzun metinleri sizin için böler. Fiyatlar, semboller, e-postalar ve URL'ler harf harf okunurken, sayısal tarihler yazıldığı gibi okunur; bu nedenle belgeler tarihleri kelimelerle yazmanızı önerir. Hız veya talimatlar gibi desteklenmeyen seçenekler sessizce yoksayılır yerine 400 hatası döndürür. Lisanslamayı herhangi bir şeyi yayınlamadan önce dikkatlice okumalısınız. Varsayılan İngilizce Phonon modeli Apache 2.0'dır. 40M Fransızca, Almanca, İspanyolca, Portekizce ve çok dilli varyantlar CC BY-NC 4.0'dır, bu da ticari kullanımını yasaklar. Ollama ayrıca M5 Max MacBook Pro'da Gradium'ın kendi çalışma zamanından %35 daha hızlı çalıştığını belirtiyor; bu, bağımsız bir ölçüm değil kendi referanslarıdır. Şu anda konuşma yalnızca Apple Silicon için destekleniyor; Windows ve Linux desteği yakında eklenecek olarak listelenmiştir.
Sıfır imza kabul eden bir Ethereum L2, güvenlik açığı gibi görünse de, BB84, kuantum saldırılarından kaçmak için bunu kasıtlı olarak yapıyor. Geçen hafta sonu, Hadamard takma adıyla yayın yapan kurucusu, tasarımı Ethereum Research’de yayınladı ve eleştirel geri bildirim istedi. BB84, 30 Eylül'den beri ana ağda faaliyette olan bir OP Stack rollup’tır ve L2 işlemleri tamamen ECDSA içermemektedir. Her hesap, bir gizli anahtarla oluşturulmuş bir keccak-256 hash zincirinin son halkasıdır ve varsayılan olarak 1.000 adımdan oluşur. Harcamak için cüzdanınız, zincirdeki önceki değeri açığa çıkarır; bu değer, bir kez hashlenerek herkes tarafından doğrulanabilir. L2 içinde kalan tek varsayım, keccak-256’nın öncü resim direncidir; bu direnç, Grover algoritmasıyla yaklaşık 2^128 işe düşürülür. Bir gizli anahtarın açığa çıkarılması, onu kamuoyuna duyurur; bu nedenle protokol, her öncü resmi ilk olarak bir işlemle bağlamak için bir commit ve reveal aşaması ekler. Bu işlemi yönetmek için op-geth’de iki yeni işlem türü tanımlanmıştır ve gönderici doğrulaması ecrecover yerine geçer. Yetkilendirme, çağrı geri alındığında bile tüketilir ve bir cüzdan son halkadaki yenileme aşamasını kaçırsa, bu adres ölü hale gelir. Yazıda, ekip yazarken bulduğu bir öncül saldırı kusuru da yer almaktadır. Commitler imza taşımaz; bu nedenle yeni bir commit, bekleyen bir commiti değiştirebilirdi ve bir saldırgan, açığa çıkarılmış bir gizli anahtarı kendi ödemesine yeniden bağlayabilirdi. 21 Ekim’de yürürlüğe giren bir kural, ilk commitin kazanacağını belirtmektedir. Sınırlar açıkça belirtilmiştir. L1 yatırma ve çekme işlemleri hâlâ ECDSA kullanmaktadır. Henüz hata kanıtları mevcut değildir ve yazının kendi ifadesine göre zincir, L2BEAT Stage 0’a bile ulaşamaz. Sequencer, ekip tarafından çalıştırılmaktadır ve 160-bit adresler yaklaşık 2^80 kuantum ikinci öncü resim direnci bırakmaktadır. Yazı ayrıca, hash zinciri hesaplarının genel L2’lerde EIP-7702 veya yerel hesap soyutlama doğrulama modu haline gelip gelmeyeceğini soruyor.
OpenZeppelin, zincirler arası ve uyumluluk için Chainlink'i varsayılan olarak seçti ve uyumluluk kutusunu işaretlerseniz, token lisansınız değişir. Bir hafta önce OpenZeppelin, Chainlink ile stratejik bir ortaklık duyurdu. CCIP ve ACE, Chainlink'in zincirler arası protokolü ve Otomatik Uyumluluk Motoru, şimdi OpenZeppelin'in AI araçları ve belgeleri olan Contracts Wizard'a entegre edildi. ERC20, Stablecoin ve RWA üreticileri her iki seçeneği de sunuyor. CCIP seçeneğini seçmek, token'in kendi izinleri arka planında, Chainlink'in yakma-çıkarma havuzunun ihtiyaç duyduğu mint ve burn çağrılarını açığa çıkarır. Ayrıca CCIP kaydı için bir yönetici belirler. Bu kısım, seçtiğiniz lisansı korur, çünkü Chainlink kodu dahil edilmez. ACE seçeneği farklıdır. Transferleri, mint ve burn işlemlerini, dağıttığınız ve yapılandırdığınız bir Politika Motoruna yönlendirir. OpenZeppelin'in kendi belgelerine göre ACE kullanan token'lar BUSL-1.1 altında yer alır ve üretim kullanımı, ACE lisansını ve ek kullanım izinlerini karşılamalıdır. Yıllarca üretilen bir OpenZeppelin token'ı, genellikle MIT gibi seçtiğiniz lisansı taşırdu. Şimdi tek bir onay kutusu bunu değiştiriyor ve acele eden bir junior geliştirici bunu fark etmeyebilir. Üretici, havuzunuzu kaydetmez, izinleri ayarlamaz veya politikalarınızı yazmaz. Bir Politika Motoru eklemek, herhangi bir politikayı yapılandırmaz ve siz, size uygulanabilecek kuralları karşılamakla sorumlusunuz. Duyuruda ayrıca OpenZeppelin Defender'dan Chainlink'in Runtime Environment'ine geçiş yolu da bahsediliyor. Bu hiçbir şey gizli değil ve Chainlink isteyen bir RWA ekibi için gerçek entegrasyon işini tasarruf eder. Sadece yapımcıların, sihirli sihirbazın oraya koyduğu için değil, bilinçli olarak bunu seçmesini istiyorum.
Akıllı sözleşme uzmanları, Solidity derleyiciniz, ihtiyaç duyduğunuz bir depolama alanını sessizce silebilir ve kaynak kodunuzda bunu asla göremezsiniz. Solidity 0.8.38, geçen Perşembe günü yayınlandı. Bu sürüm, 0.8.19 ile 0.8.37 arasındaki tüm sürümlerde bulunan bir Yul optimizasyon hatasını düzeltiyor. Optimizatör, bellekte ve depolamada ne olduğunu not eder. Bu notları, zaten bildiği bir değeri yüklemek için kullanır ve zaten var olan veriyi yazan bir depolama işlemini atlar. İki adresin çakışıp çakışmadığını belirlemek için, her birini bir temel değişken artı bir ofset olarak tanımlar. Aynı temel, farklı ofset — bu nedenle farklı slotlar olmalı. Bu tanımlar önbelleğe alınmıştı. Sonra biri temel değişkeni yeniden atadı. Optimizatör her zaman bunu fark etmezdi. Şimdi eski değerden oluşturulan bir adresle yeni değerden oluşturulan bir adresi, aynı temele sahipmiş gibi karşılaştırıyor. İkisinin farklı olduğunu kararlaştırıyor, ancak çalışma zamanında aynı yeri işaret ediyorlar. Sonuç olarak, eski bir not kalıyor. Sonraki bir yüklemeyi eski bir değer döndürebilir. İhtiyacınız olan bir depolama işlemi kaldırılabilir. Bu konum üzerindeki keccak256, güncel olmayan verileri hashleyebilir. Yalnızca optimizasyon etkinleştirilmiş şekilde derlenmiş kodlar etkilenir. via-IR ile, inline assembly kullanmasanız bile tüm kodlar etkilenebilir. Varsayılan eski işlem hattıyla, yalnızca bazı inline assembly ve derleyici tarafından oluşturulan yardımcı fonksiyonlar etkilenebilir. Optimizasyonsuz derlemeler güvendedir. Takım, bu hatayı düşük ciddiyette değerlendiriyor ve ben her derleyici ekibinin yapmasını dilediği bir şey yaptılar: Sourcify veritabanındaki tüm doğrulanmış sözleşmeleri, düzeltme ile ve düzeltme olmadan yeniden derlediler ve tümünün bayt kodu aynı çıktı. Yani nadirdir. Nadir, asla olmadığı anlamına gelmez, özellikle kodunuz yeni ise ve henüz dağıtılmamışsa. Hata, Ethereum Vakfı'nın hata ödül programı aracılığıyla geldi ve ikinci bir rapor, assembly kullanmadan basit Solidity kodunun da bu hatayı tetikleyebileceğini gösterdi.
Erkekçe ETH maksisi olma arzusu. 🥳
Ethereum, Ethereum'dir ve kalıcı olarak öyle kalacaktır. Sonraki çatallanmada, Ethereum topluluğu protokolün gerçek mucizesini görecektir.