Intelligent Oracle'lar ve vahşi web

Nereye gittiğimizi anlamak için önce bulunduğumuz yerin sınırlarını kabul etmemiz gerekiyor. Geleneksel akıllı sözleşmeler güçlüdür, ama özünde dünyadan yalıtılmıştır. Deterministik koda ve zincir üstündeki iç duruma dayanırlar; fiilen bir kara kutunun içinde çalışırlar. Dış dünyayı “görebilmek” için kendilerine veri gönderen üçüncü taraf aracılara, yani standart oracle'lara ihtiyaç duyarlar.

Intelligent Oracle'lar bu yalıtımı kırıyor.

GenLayer üzerine inşa edilen Intelligent Oracle'lar dış dünyaya açılan bir kapı işlevi görür ve deterministik olmayan görevleri yürütebilen yerel bir Python ortamında çalışır. İşlevsel açıdan bir Intelligent Oracle, herkese açık herhangi bir web verisini (metin, HTML ya da görüntü) çekmek, bu veriyi büyük dil modelleriyle (LLM'ler) işlemek ve sonuç üzerinde güven gerektirmeyen bir konsensüse varmak için tasarlanmış bir Intelligent Contract'tır. Veriyi yalnızca saklamakla kalmaz, onu yorumlayacak mantığa da sahiptir.

Mühendislik açısından asıl zorluk konsensüste yatıyor: Merkeziyetsiz bir ağ, dinamik bir web sitesinin içeriği üzerinde nasıl anlaşır? Web verisi ve yapay zekâ çıkarımı deterministik olmayabileceği için farklı düğümler aynı görev için farklı sonuçlar döndürebilir.

GenLayer bu sorunu Optimistic Democracy ile çözer. Tek bir veri kaynağına güvenmek yerine, rastgele seçilen bir doğrulayıcı grubu konsensüse varmakla görevlendirilir. Rastgele seçilen bir lider bir sonuç önerir, bir doğrulayıcı paneli de bu sonucu önceden tanımlanmış “anlaşma kurallarına” göre doğrular.

Bu kurallara Eşdeğerlik İlkeleri denir:

• Katı Eşdeğerlik (gl.eq_principle.strict_eq): Doğrulayıcılar görevi bağımsız olarak yürütür ve liderin sonucuyla karakteri karakterine birebir eşleşme ister. Geçmiş token fiyatları gibi deterministik veriler için idealdir.
• Karşılaştırmalı Eşdeğerlik (gl.eq_principle.prompt_comparative): Doğrulayıcılar görevi bağımsız olarak yürütür. Doğrulamak için hem liderin sonucunu hem de kendi sonuçlarını geliştiricinin tanımladığı kriterlere göre değerlendiren bir LLM istemi çalıştırırlar. LLM iki çıktı arasındaki ilişkinin bu kriterleri karşıladığına karar verirse anlaşma sağlanmış olur.
• Karşılaştırmasız Eşdeğerlik (gl.eq_principle.prompt_non_comparative): Doğrulayıcılar görevi yeniden çalıştırmaz. Bunun yerine bir LLM'i yargıç olarak kullanır ve liderin önerdiği sonucun geliştiricinin tanımladığı kriterleri mantıksal olarak karşılayıp karşılamadığını doğrularlar.
• Özel Eşdeğerlik: İleri düzey kullanım senaryolarında geliştiriciler bu varsayılanlarla sınırlı değildir. Liderin ve doğrulayıcıların konsensüse tam olarak nasıl varacağını belirleyen, tamamen size kalmış Python fonksiyonları tanımlayabilirsiniz.

Not: Optimistic Democracy'nin ve Eşdeğerlik İlkeleri'nin işleyişine dair daha derin bir analiz bu yazının kapsamı dışında. Konsensüs mimarisinin ayrıntılı bir dökümünü isterseniz buradan okuyabilirsiniz.

Oracle manzarası

Intelligent Oracle'ları mevcut çözümlerden ayıran şeyi anlamanın en iyi yolu, verinin blokzincire nasıl girdiğini sınıflandırmak. Blokzincirler çalışabilmek için oracle'lara, yani veriyi zincir üstüne aktaran zincir dışı aracılara dayanır. Bunlar iki baskın mimariye indirgenebilir: gerçek zamanlı veri akışları ya da insan katılımcıların öne sürdüğü, itiraz edilebilir veri önerileri.

Veri akışı tabanlı oracle'lar (Chainlink, Pyth) yüksek hızlı abonelik hizmetleridir. Varlık fiyatları gibi standart veriler için inanılmaz derecede verimlidirler, ama katıdırlar: Uygulamanızın var olabilmesi, belirli bir veri akışının desteklenmesine bağlıdır.

Bu sınırlamayı aşmak için iyimser oracle'lar (UMA) daha açık uçlu ama daha yavaş veri önerilerine izin verir. Herkes finansal bir teminat stake ederek bir sonuç önerebilir ve sistem, bir “canlılık süresi” (liveness period) içinde açıkça itiraz edilmediği sürece bu sonucun doğru olduğunu varsayar. Esnek olsa da bu model gizli bir tavana çarpar: insan dikkati. Anlaşmazlıklar elle oylama gerektirir. Bir DAO'dan günde 10.000 mikro işlemi doğrulamasını isteyemezsiniz. Sonuç olarak bu modeller doğal olarak yüksek değerli, düşük sıklıklı piyasalara yönelir ve günlük, daha düşük riskli anlaşmazlıkların oluşturduğu “uzun kuyruğu” fiilen göz ardı eder.

GenLayer üçüncü bir yol sunuyor: Intelligent Oracle'lar uygulamanıza bir beyin ve dış dünyaya erişim kazandırarak körlük sorununu giderir. Açık ve güven gerektirmeyen bir biçimde.

Intelligent Oracle'lar nasıl çalışır?

Intelligent Oracle'ların en yaygın uygulaması, kaotik ve yapılandırılmamış web'i yapılandırılmış zincir üstü olgulara dönüştürmektir.

Intelligent Oracle'ların gücünü anlamak için varsayımsal senaryolara ihtiyacımız yok. Bütün geliştiriciler, standart EVM'in sınırlarını aşan aynı basit döngüye dayanır:

1. gl.nondet.web.render(): Blokzincirden çıkıp web'e erişebilme yeteneği.
2. gl.nondet.exec_prompt(): Bu veriyi bir LLM ile işleyebilme yeteneği.
3. gl.eq_principle: Yapay zekâ modellerinden oluşan ağı tek bir doğru üzerinde konsensüse varmaya zorlayan kurallar.

Hangi Eşdeğerlik İlkesi'ni seçeceğiniz tamamen ihtiyaç duyduğunuz verinin doğasına bağlıdır:

• Çıktının tüm düğümlerde birebir aynı olması gerekiyorsa sözdizimsel eşdeğerliği (strict_eq) kullanın (örneğin belirli bir adresi ya da belirli bir tokenın geçmiş verilerini çıkarırken).
• İfadenin değişebileceği ama anlamın aynı kalması gereken metinler çıkarıyorsanız anlamsal eşdeğerliği (prompt_non_comparative, prompt_comparative) kullanın (örneğin bir haberi özetlerken ya da duygu analizi yaparken).
• Son derece oynak verileri (canlı token fiyatları gibi) çekiyorsanız özel doğrulama kullanın. Bu değerler an be an değiştiği için katı eşdeğerlik çoğu zaman başarısız olur. Muhtemelen tam bir karşılaştırmalı LLM çağrısı yapmak da istemezsiniz; en azından bu verimli değildir. Burada özel bir eşdeğerlik, birebir eşleşme istemek yerine bir “tolerans aralığı” tanımlamanıza olanak tanır (örneğin fiyatlar arasındaki fark %1'i geçmemeli).

“Okuyucu” kalıbı (“text” ya da “html”)

Bu kalıpta sözleşme içeriği metin ya da HTML biçiminde çeker (bu, doğrulayıcı düğümünün belirli bir URL'yi render etmesini tetikler), ardından içerikten belirli bilgileri ayıklaması için onu bir LLM'e verir.

Örnek: Bir Bitcoin fiyat oracle'ı

Bu kod parçasında sözleşme bir web sayfasını çeker ve LLM'den fiyatı çıkarmasını ister. Bu örnekte basitlik adına katı eşdeğerlik kullanıyoruz ve LLM'in durağan bir anlık görüntüden tam sayıyı birebir çıkardığını varsayıyoruz. Yüksek sıklıklı bir üretim ortamında, daha önce bahsettiğimiz özel “tolerans aralığı” ilkesi daha güvenli olurdu.

Örneğin tamamına buradan ulaşabilirsiniz.

“Görme” kalıbı (“screenshot”)

Metin güçlü olsa da bazı doğrular görseldir. Bu kalıp, görüntüleri işleyip yorumlamak için çok modlu LLM'lerden yararlanır.

Metin ayıklamanın aksine görsel analiz doğası gereği özneldir. İki kişi aynı görüntüyü farklı biçimde tarif edebilir. Bu yüzden bu kalıp en iyi, anlamsal uyum arandığında işe yarar.

Örnek: “Proof of Steak” doğrulama aracı

Bu kod parçasında sözleşme, bir görüntü URL'sini analiz ederek görüntüde pişmiş bir biftek olup olmadığını belirler. Yapay zekânın “Yes” yanıtını ifade ediş biçimindeki farklılıkları tolere etmek için karşılaştırmalı bir kontrol kullanır.

Örneğin tamamına buradan ulaşabilirsiniz.

Teoriden pratiğe

Bu kalıplar varsayımsal değil. Geliştiriciler şu anda onları, daha önce zincir üstünde çözülmesi imkânsız olan sorunlar için yayına alıyor.

• Luk'un “Proof of Steak” projesi: GenLayer Kasım 2025 Hackathon'unun kazananı olan bu proje, eğlenceli ve doğrulanabilir bir sosyal oyun oluşturmak için Görme kalıbını kullandı. Kullanıcılar akşam yemeklerinin ya da başka içeriklerin fotoğraflarını yükler, merkeziyetsiz jüri de içeriği doğrulayıp puanlar.
• Ying'in Price Prediction Oracle projesi: Okuyucu kalıbını kullanan Ying, büyük haber sitelerinden ve borsalardan ham HTML çeken bir sistem kurdu. Böylece herkese açık her URL'yi, API anahtarına ya da izne gerek kalmadan potansiyel bir oracle kaynağına dönüştürdü.
• Jay'in “Watchdog” projesi: Harici sunucuların (GitHub ya da CoinGecko gibi) sağlığını izleyen bir güvenlik uygulaması. Kesintileri tespit etmek için Okuyucu kalıbını kullanır ve kesinti sırasında sözleşmeleri duraklatmak için zincir üstündeki devre kesicileri otomatik olarak tetikler.
• Pavel'in “Guess the Picture” projesi: Görme kalıbının oyunlaştırılmış bir uygulaması. Kullanıcılar kavramları çizer, bir yapay zekâ jürisi de çizimleri anlamsal doğruluklarına göre puanlar.

Artık gören, okuyan ve tepki veren sözleşmelerimiz var. Ancak EVM'in deterministik güvenliğinden internetin oynaklığına geçmek risksiz değil. Kalıcı sistemler kurmak için Intelligent Oracle'ların sınırlarını anlamak, yeteneklerini anlamak kadar önemli hâle geliyor.

Mevcut sınırlamalar: “Doğru”nun kırılganlığı

Asıl zorluk yapay zekâ değil, web'in kendisi: “World Wild Web”, yani istikrarın nadir olduğu vahşi bir ortam. Bugün güvenilir olan bir kaynak yarın ödeme duvarının arkasına geçebilir, Cloudflare engeline takılabilir ya da çevrim dışı kalabilir. Bu da tehlikeli bir gerilim yaratır: “Güven gerektirmezliği” sağlamak için sözleşmenize belirli bir URL'yi sabit kodlarsanız, o web sitesinin bot karşıtı politikasını hiçbir zaman değiştirmeyeceğine bahse girmiş olursunuz. Durağan URL'lere dayanmak tek bir hata noktası oluşturur ve sizi maliyetli bir yeniden yayına alma işlemine zorlayabilir.

Geliştirici ipucu: Herhangi bir sözleşmeyi yayına almadan önce kaynaklarınızı doğrulayın. Hedef URL'nizin içeriğine gerçekten erişilebildiğini teyit etmek için Intelligent Crawler aracını kullanabilirsiniz.

Öte yandan kullanıcıların herhangi bir URL göndermesine izin vermek de bir o kadar tehlikeli. Kötü niyetli biri, oracle'ınıza yanlış veri beslemek için kolayca sahte bir haber sitesi ya da saygın bir alan adının kopyasını kurabilir. Çözüm ikisinin ortasında: alan adı beyaz listesi. Geliştiriciler URL'leri durağan kod olarak değil, değiştirilebilir durum olarak ele almalı. Onaylı ve güvenilir alan adlarının zincir üstünde tutulan bir listesini (örneğin coindesk.com, bbc.com) koruyarak yanlış bilginin önüne geçersiniz ve belirli bir URL bozulduğunda protokolünüze kaynak değiştirme esnekliği kazandırırsınız; hem de tamamen güven gerektirmeyen bir biçimde.

Bu, alan adı beyaz listesi için bir kod parçası. Burada bir URL'yi normalleştirdikten sonra beyaz listede uygun biçimde yer alıp almadığını kontrol ediyoruz. Bu önemli bir adım: Mantığı burada siz tanımlarsınız (örneğin bir alan adı için yalnızca çok belirli yollara mı izin vereceğinizi, yoksa alan adı içindeki her yolu mu kabul edeceğinizi).

Kodun tamamını buradan görebilirsiniz.

Dahası, Intelligent Oracle'lar standart HTTP istekleriyle (GET/POST) teknik olarak herhangi bir API'den veri çekebilse de bir sorun var: gizlilik. Çoğu API, kimlik doğrulama için özel bir API anahtarı ister. Geleneksel bir sunucuda bu anahtarı güvenli bir .env dosyasında saklarsınız. Ama blokzincirde her şey şeffaftır. OPENAI_API_KEY ya da BLOOMBERG_KEY anahtarınızı sözleşmenize sabit kodlarsanız ağdaki her doğrulayıcı ve blok gezgini onu görebilir. Kötü niyetli kişiler anahtarınızı anında kopyalayıp kotanızı tüketebileceği için özel, abonelik tabanlı API'leri entegre etmek mevcut modelde gerçekçi değil.

Son olarak, zekânın bir maliyeti var. GenLayer her konsensüs turunda birden çok LLM çıkarımı çalıştırır. Hesap makinesinin işini süper bilgisayara yaptırmayın. Yalnızca ETH fiyatına ihtiyacınız varsa Chainlink ya da Pyth gibi bu işe özel, deterministik bir veri akışı kullanın; o iş için daha hızlı ve daha ucuzdurlar. GenLayer'ı “uzun kuyruk” için saklayın: yalnızca aritmetik değil, anlamayı gerektiren milyonlarca öznel, dağınık ve karmaşık soru için.

Potansiyel: Ekonomik ajanlar olarak Intelligent Oracle'lar

Gizlilik bir kısıt olmaya devam etse de sektör, Intelligent Oracle'ları pasif okuyuculardan aktif ekonomik ajanlara dönüştüren bir çözüm etrafında birleşiyor.

Bu dönüşümü yönlendiren en umut verici standart, HTTP 402 “Payment Required” üzerine kurulu x402 protokolü.

x402 kimlik doğrulama modelini tersine çeviriyor: Oracle gizli bir API anahtarı saklamak yerine tükettiği şeyin bedelini doğrudan ödüyor. Bir sözleşme premium veri istediğinde sunucu içerik yerine bir ödeme adresi döndürür. Oracle da yanıtın “kilidini açmak” için otonom olarak bir mikro işlem imzalar.

Bu, sır saklama ihtiyacını fiilen ortadan kaldırır. “Kimlik doğrulama”, “ödeme”ye dönüşür.

Hâlâ pürüzler var (özellikle GenLayer üzerinde çalışan bir oracle için zincirler arası mikro ödemeler konusunda), ama bu mimari çok büyük bir kapı aralıyor. Intelligent Contract'ların açık web'den yalnızca veri kazımakla kalmayacağı bir geleceğe zemin hazırlıyor: Erişimi kısıtlı, yüksek kaliteli bilgiler için kendi başlarına gezinebilecek, pazarlık edebilecek ve ödeme yapabilecekler; üstelik hiçbir zaman özel anahtar tutmadan.

Şunu açıkça belirtmek önemli: GenLayer, mevcut zincirinizin yerini alacak sıradan bir L1 ya da L2 olmaya çalışmıyor. Deterministik olmayan kararları üstlenmek için diğer dApp'lere bağlanan bir Karar Katmanı, bir tür “internetin mahkemesi” işlevi görüyor.

Hesap yapan “akıllı” sözleşmelerden anlayan Intelligent Contract'lara geçtik. Hemen geliştirmeye başlamak istiyorsanız IntelligentOracle.com adresini ziyaret edin.

Orada yalnızca dokümantasyon bulmayacaksınız. İlk Intelligent Oracle kalıbınızı gerçek zamanlı olarak uygulamanıza yardım etmeye hazır, bu işte uzmanlaşmış bir yapay zekâ ajanı da bulacaksınız. Altyapı yayında. Tarayıcı açık. Geriye tek bir şey kalıyor: sırada ne inşa edeceğinize karar vermek.

Zincirler arası ilk Intelligent dApp'inizi geliştirmeye başlayın. points.genlayer.foundation adresindeki Builders Program'ımızı kaçırmayın.