Blockchain'den LLM'ye, veri indeksleme teknolojisinin gelişiminin ve zorluklarının derinlemesine bir yorumu

Satoshi Nakamoto, genesis bloğuna bir mesaj yerleştirmeye karar verdiğinden beri, Bitcoin zincirinin veri yapısı bir dizi değişikliğe uğradı.

2022'de blockchain gelişimini derinlemesine incelemeye başladım ve okuduğum ilk kitap "Ethereum'da Ustalaşmak" idi. Bu kitap mükemmel ve bana Ethereum ve Blockchain'in temelleri hakkında derinlemesine bir anlayış sağladı. Ancak bugünün bakış açısıyla, kitaptaki bazı geliştirme teknikleri biraz modası geçmiş durumda. Ön adımlar, cüzdan dApp için bile kişisel bir dizüstü bilgisayarda bir düğüm çalıştırmayı içerir ve hafif bir düğümün kendi başına indirilmesini gerektirir. Bu, 2015 ile 2018 yılları arasında blockchain geliştirme ekosistemindeki ilk geliştiricilerin ve bilgisayar korsanlarının davranış modelini yansıtıyor.

2017'de herhangi bir düğüm hizmeti sağlayıcımız yoktu. Arz ve talep açısından bakıldığında, ana işlevleri, sınırlı kullanıcı etkinliği nedeniyle işlem yapmaktır. Bu, işlemek için çok fazla RPC isteği olmadığından ve aktarım istekleri seyrek olduğundan, tam bir düğümü kendi başınıza korumanın veya barındırmanın çok fazla bir yük olmadığı anlamına gelir. Ethereum'u erken benimseyenlerin çoğu teknoloji meraklılarıdır. Bu erken kullanıcılar, blok zinciri geliştirme konusunda derin bir anlayışa sahiptir ve komut satırı veya entegre geliştirme ortamı aracılığıyla doğrudan Ethereum düğümlerini sürdürmek, işlemler oluşturmak ve hesapları yönetmek için kullanılır.

Bu nedenle, ilk projelerin genellikle çok temiz bir UI/UX'e sahip olduğunu gözlemleyebiliriz. Bu projelerden bazılarının bir ön ucu bile yoktur ve kullanıcı etkinliği oldukça düşüktür. Bu projelerin özellikleri temel olarak iki faktör tarafından belirlenir: kullanıcı davranışı ve zincirin veri yapısı.

Düğüm Sağlayıcıların Yükselişi

Blockchain ağına programlama geçmişi olmayan daha fazla kullanıcı katıldıkça, merkezi olmayan uygulamaların teknik mimarisi de değişti. Kullanıcılar tarafından orijinal barındırma düğümleri modu, kademeli olarak proje tarafları tarafından düğüm barındırma olarak değiştirildi.

İnsanlar, zincirdeki verilerin hızlı büyümesinin kişisel barındırma düğümlerinin maliyetini zamanla kademeli olarak artırması nedeniyle, düğüm barındırma hizmetlerini seçme eğilimindedir.

Bununla birlikte, proje ekipleri tarafından kendi kendini barındıran düğümler, sürekli bakım yatırımı ve donanım maliyetleri gerektiren küçük projelerin geliştiricileri için bir sorun olmaya devam ediyor. Bu nedenle, bu karmaşık düğüm barındırma işlemi genellikle düğüm bakımı konusunda uzmanlaşmış şirketlere emanet edilir. Bu şirketlerin büyük ölçekli inşaat ve kaynak yaratma zamanlamasının, Kuzey Amerika teknoloji endüstrisindeki bulut hizmetlerinin yükselen trendiyle aynı zamana denk geldiğini belirtmekte fayda var.

| Proje | Kategori | kurulduğundan beri | | --- | --- | --- | | simya | düğümler | 2017 | | Infura | Düğümler | 2016 | | ŞimdiDüğümler | düğümler | 2019 | | Hızlı Düğümler | düğümler | 2017 | | Çapa | düğümler | 2017 | | Zincir Yığını | düğümler | 2018 |

Özellikle DeFi ve NFT gibi ilgili protokollerin ortaya çıktığı bu dönemde, yalnızca düğümleri uzaktan barındırmak sorunu tamamen çözemez. Geliştiricilerin pek çok veri sorunuyla uğraşması gerekiyor, çünkü blockchain düğümlerinin kendileri tarafından sağlanan verilere standartlaştırılmamış ve temizlenmemiş ham veriler denir. İçindeki verilerin çıkarılması, temizlenmesi ve yüklenmesi gerekiyor.

Örneğin, bir NFT projesinin geliştiricisi olduğumu ve NFT işlemleri yapmak veya NFT'leri görüntülemek istediğimi varsayalım. Ardından ön ucumun kişisel EOA hesabındaki NFT verilerini gerçek zamanlı olarak okuması gerekiyor. NFT gerçekten sadece standartlaştırılmış bir belirteç biçimidir. Bir NFT'ye sahip olmak, NFT sözleşmesi tarafından oluşturulan benzersiz bir kimliğe sahip bir jetona sahip olduğum anlamına gelir ve NFT'nin görüntüsü aslında SVG verileri veya IPFS'deki bir görüntünün bağlantısı olabilecek meta verilerdir. Ethereum'un Geth istemcisi indeksleme talimatları sağlasa da, büyük ön uç gereksinimleri olan bazı projeler için Geth'i sürekli olarak istemek ve ardından ön uca geri dönmek pratik değildir. Emir müzayedesi ve NFT işlem toplama gibi bazı işlevler için, kullanıcı talimatlarını toplamak ve ardından bu talimatları uygun zamanda zincire göndermek için zincir dışında gerçekleştirilmelidir.

Bu nedenle, basit bir veri katmanı doğdu. Kullanıcıların gerçek zamanlı ve doğruluk gereksinimlerini karşılamak için, proje tarafının kendi veritabanını ve veri analiz fonksiyonlarını oluşturması gerekir.

**Veri indeksleyici nasıl gelişti? **

Bir projeye başlamak genellikle nispeten basit bir meseledir. Bir fikriniz var, bazı hedefler belirliyorsunuz, en iyi mühendisleri buluyorsunuz ve genellikle ön uç ve birkaç akıllı sözleşme içeren çalışan bir prototip oluşturuyorsunuz.

Ancak proje ölçeğini yapmak oldukça zordur. Projenin ilk gününden itibaren tasarım yapısı hakkında derinlemesine düşünmek gerekiyor. Aksi takdirde, genellikle "buzlanma sorunları" olarak adlandırdığım sorunlarla hızla karşılaşabilirsiniz.

Bu terimi "Iron Man" filminden ödünç aldım ve çoğu girişimin durumunu tarif etmek için çok uygun görünüyor. Startup'lar hızla büyüdüğünde (çok fazla kullanıcıyı cezbettiklerinde), ilk etapta bunu öngöremedikleri için genellikle sorun yaşarlar. Filmde kötü adam, "buzlanma sorununu" hesaba katmadığı için savaş teçhizatının uzaya uçacağını asla beklemiyordu. Aynı şekilde, birçok Web3 projesinin geliştiricileri için "donma sorunu", kitlesel kullanıcı benimsemesinin artan yüküyle uğraşmayı içerir. Bu, kullanıcı sayısı önemli ölçüde arttığı için sunucu tarafında ağır bir baskı oluşturur. Ağ sorunları veya düğümlerin kapanması gibi blok zincirin kendisiyle ilgili sorunlar da vardır.

Çoğu zaman bu bir arka uç sorunudur. Örneğin bazı blockchain oyun protokollerinde bu durum nadir görülen bir durum değil. Zincirdeki verileri ayrıştırmak için daha fazla sunucu eklemeyi ve daha fazla veri mühendisi tutmayı planladıklarında, bu kadar çok kullanıcının katılacağını öngörmediler. Bunu anladıklarında artık çok geçti. Ve bu teknik problemler sadece daha fazla arka uç mühendisi ekleyerek çözülemez. Daha önce de söylediğim gibi, bu hususlar baştan planın içine yerleştirilmelidir.

İkinci sorun, yeni blok zincirleri eklemeyi içerir. Muhtemelen sunucu tarafı sorunlarından en başta kaçındınız ve bir grup iyi mühendisi işe aldınız. Ancak, kullanıcılarınız mevcut blok zincirinden memnun olmayabilir. Hizmetinizin zk zincirleri veya L2 zincirleri gibi diğer popüler zincirlerde de çalışmasını istiyorlar. Proje yapınız şöyle görünebilir:

Bu tür bir sistemde, verileriniz üzerinde tam kontrole sahip olursunuz, bu da daha iyi yönetim ve artırılmış güvenlik sağlar. Sistem çağrı isteklerini sınırlayarak aşırı yüklenme riskini azaltır ve verimliliği artırır. Kurulum, ön uçla uyumludur ve sorunsuz bir entegrasyon ve kullanıcı deneyimi sağlar.

Ancak işletme ve bakım maliyetleri artar ve bu da kaynaklarınızı zorlayabilir. Her seferinde yeni bir blok zinciri eklemek, zaman alıcı ve verimsiz olabilen tekrarlanan çalışma gerektirir. Büyük veri kümelerinden veri seçmek, sorgu sürelerini azaltabilir ve potansiyel olarak süreci yavaşlatabilir. Geri alma ve yeniden düzenleme gibi blockchain ağ sorunları nedeniyle, veriler bozulabilir ve veri bütünlüğü ve güvenilirliği tehlikeye girebilir.

Projeler, ekip üyelerinizi yansıtacak şekilde tasarlanmıştır. Daha fazla düğüm eklemek ve arka uç odaklı bir sistem oluşturmaya çalışmak, bu düğümleri çalıştırmak ve ham verilerin kodunu çözmek için daha fazla mühendis tutmanız gerektiği anlamına gelir.

Bu model, e-ticaret platformlarının ve uygulama geliştiricilerin kendi IDC (İnternet Veri Merkezi) tesislerini kurmayı seçtikleri İnternet'in ilk günlerine benzer. Bununla birlikte, kullanıcı istekleri arttıkça ve blok zinciri ağının durumu patladığında, maliyet program tasarım karmaşıklığıyla el ele gider. Ayrıca, bu yaklaşım pazarın hızlı genişlemesini de engellemektedir. Bazı yüksek performanslı halka açık blok zincirleri, donanım açısından yoğun düğüm işlemleri gerektirirken veri senkronizasyonu ve temizleme, insan kaynaklarını ve zaman maliyetlerini tüketir.

Blockchain tabanlı bir NFT pazarı veya harika bir oyun oluşturmaya çalışıyorsanız, ekip üyelerinizin %65'inin arka uç ve veri mühendisleri olması şaşırtıcı değil mi?

**Belki de geliştiriciler, daha iyi ürünler oluşturmaya odaklanabilmeleri için neden hiç kimsenin bu zincir üstü verileri kendileri için çözmediğini ve iletmediğini merak edeceklerdir. **

**İndeksleyicilerin bu yüzden orada olduğuna inanıyorum. **

Web3 uygulamalarına ve blockchain ağlarına erişim zorluğunu azaltmak için, biz de dahil olmak üzere birçok geliştirme ekibi, arşiv düğümü bakımı, zincir üstü veri ETL'si (çıkarma, dönüştürme, yükleme) ve veritabanı çağrıları gibi adımları entegre etmeyi seçiyor. Bu görevler başlangıçta proje ekibinin kendilerini korumasını gerektiriyordu, ancak şimdi çok zincirli veriler ve düğüm API'leri sağlayarak entegre operasyonlar gerçekleştirdiler.

Bu API'lerin yardımıyla, kullanıcılar zincir üzerindeki verileri ihtiyaçlarına göre özelleştirebilir. Bu, popüler NFT meta verilerinden, belirli adreslerin zincir üzerindeki etkinliğini izlemeden, belirli belirteç likidite havuzlarının işlem verilerini izlemeye kadar her şeyi kapsar. Bu yaklaşıma sık sık modern Web3 projelerinin yapısının bir parçası olarak atıfta bulunuyorum.

Veri katmanı ve dizin katmanı projelerinin finansmanı ve inşası ağırlıklı olarak 2022 yılında gerçekleştirilecektir. Bu dizin katmanı ve veri katmanı projelerinin iş uygulamalarının, altta yatan veri mimarisinin tasarımıyla, özellikle OLAP (Çevrimiçi Analitik İşleme) sistemlerinin tasarımıyla yakından ilişkili olduğuna inanıyorum. Uygun bir çekirdek motorun benimsenmesi, indeksleme hızını iyileştirmek ve kararlılığını sağlamak da dahil olmak üzere indeks katmanının performansını optimize etmenin anahtarıdır. Yaygın olarak kullanılan motorlar arasında Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse vb. Bunlardan ClickHouse, internet şirketlerinde yaygın olarak kullanılan güçlü bir veri tabanıdır, 2016 yılında açık kaynak kodlu hale getirilmiş ve 2021 yılında 250 milyon ABD doları finansman almıştır.

Bu nedenle, yeni nesil veritabanlarının ortaya çıkması ve geliştirilmiş veri indeksi optimizasyon mimarileri, Web3 veri indeksi katmanının oluşturulmasına yol açmıştır. Bu, bu alandaki şirketlerin veri API hizmetlerini daha hızlı ve verimli bir şekilde sunmasını sağlar.

Bununla birlikte, zincir üstü veri indekslemenin inşası hala iki kara bulutla örtülüyor.

İki Kara Bulut

İlk kara bulut, blockchain ağ kararlılığının sunucu tarafındaki etkisiyle ilgilidir. Blockchain ağı güçlü bir kararlılığa sahip olsa da, veri iletimi ve işlenmesi sırasında durum böyle değildir. Örneğin, blok zincirinin yeniden düzenlenmesi (yeniden organize edilmesi) ve geri alınması (geri alınması) gibi olaylar, indeksleyicinin veri kararlılığı için zorluklar oluşturabilir.

Blok zincirinin yeniden düzenlenmesi, düğümlerin senkronizasyonu geçici olarak kaybederek blok zincirinin iki farklı versiyonunun aynı anda var olmasına neden olmasıdır. Bu tür durumlar, sistem arızaları, ağ gecikmeleri ve hatta kötü niyetli davranışlar tarafından tetiklenebilir. Düğümler yeniden senkronize edildiğinde, tek bir resmi zincire yakınsacaklar ve önceki alternatif "çatallı" bloklar atılacak.

Yeniden düzenleme gerçekleştiğinde, dizin oluşturucu, sonunda atılan ve veritabanını kirleten bloklardan gelen verileri işlemiş olabilir. Bu nedenle dizin oluşturucular, geçersiz zincirlerdeki verileri atarak ve yeni kabul edilen zincirlerdeki verileri yeniden işleyerek bu duruma uyum sağlamalıdır.

Bu tür ayarlamalar, kaynak kullanımının artmasına neden olabilir ve potansiyel olarak verilerin kullanılabilirliğini geciktirebilir. Ekstrem durumlarda, sık veya büyük ölçekli blok yeniden düzenlemeleri, verileri almak için API'leri kullanan Web3 uygulamaları da dahil olmak üzere dizin oluşturuculara bağlı hizmetlerin güvenilirliğini ve performansını ciddi şekilde etkileyebilir.

Ek olarak, blockchain ağlarında veri formatı uyumluluğu ve veri standartlarının çeşitliliği ile ilgili sorunlarla karşı karşıyayız.

Blockchain teknolojisi alanında, her biri kendine özgü veri standartlarına sahip birçok farklı ağ vardır. Örneğin EVM (Ethereum Virtual Machine) uyumlu zincirler, EVM olmayan zincirler ve zk (sıfır bilgi) zincirleri vardır ve bunların her birinin kendine özel veri yapısı ve formatı vardır.

Bu şüphesiz indeksleyiciler için büyük bir zorluktur. API'ler aracılığıyla yararlı ve doğru veriler sağlamak için dizin oluşturucuların bu çeşitli veri biçimlerini işleyebilmesi gerekir. Ancak, blockchain verileri için evrensel bir standart olmadığından, farklı indeksleyiciler farklı API standartları kullanabilir. Bu, bir indeksleyiciden çıkarılan ve dönüştürülen verilerin başka bir sistemde kullanılamayacağı veri uyumluluğu sorunlarına yol açabilir.

Ek olarak, geliştiriciler bu çok zincirli dünyayı keşfettikçe, genellikle bu farklı veri standartlarıyla uğraşma zorluğuyla karşılaşırlar. Bir blockchain ağı için çalışan bir çözüm, bir başkası için çalışmayabilir, bu da birden fazla ağ ile etkileşime girebilen uygulamaların geliştirilmesini zorlaştırır.

Gerçekten de, blockchain endeksleme endüstrisinin karşılaştığı zorluklar, 20. yüzyılın başlarında Lord Kelvin tarafından tanımlanan ve sonunda kuantum mekaniği ve termodinamik gibi devrim niteliğinde alanları doğuran fizikteki çözülmemiş iki sorunu anımsatıyor.

Bu zorluklarla karşı karşıya kalan endüstri, gerçekten de gecikme sağlamak veya akışı Kafka boru hattına entegre etmek ve hatta blok zinciri indeksleme endüstrisini güçlendirmek için bir standartlar konsorsiyumu kurmak gibi bazı adımlar attı. Bu önlemler şu anda blockchain ağlarının istikrarsızlığını ve veri standartlarının çeşitliliğini ele alabilmektedir, böylece indeksleyiciler doğru ve güvenilir veriler sağlayabilir.

Bununla birlikte, kuantum teorisinin ortaya çıkışı fiziksel dünya anlayışımızda devrim yarattığı gibi, blok zinciri veri altyapısını iyileştirmek için daha radikal yollar da düşünebiliriz.

**Sonuçta, özenle düzenlenmiş veri ambarları ve yığınlarıyla mevcut altyapı, gerçek olamayacak kadar mükemmel ve güzel görünebilir. **

Yani, **Başka bir yolu var mı? **

Kalıpları bulma

Düğüm sağlayıcıların ve dizin oluşturucuların ortaya çıkışıyla ilgili orijinal konuya geri dönelim ve tuhaf bir sorunu ele alalım. Neden 2010'da düğüm operatörleri ortaya çıkmadı da indeksleyiciler birdenbire çok sayıda ortaya çıktı ve 2022'de çok fazla yatırım aldı?

Yukarıdakilerimin bu soruları kısmen cevapladığına inanıyorum. Bunun nedeni, bulut bilişim ve veri ambarı teknolojilerinin sadece şifreleme alanında değil, yazılım endüstrisinde de yaygın olarak kullanılmasıdır.

Şifreleme dünyasında da özel bir şey oldu, özellikle de ERC20 ve ERC721 standartları halka açık medyada popüler hale geldiğinde. Ek olarak, DeFi yazı, zincir üstü verileri daha karmaşık hale getirdi. Erken aşamada olduğu gibi basit işlem verileri yerine farklı akıllı sözleşmelerde çeşitli çağrı işlemleri yönlendirilir, zincir üstü verilerin biçimi ve karmaşıklığı şaşırtıcı değişikliklere ve büyümeye maruz kalmıştır.

Kripto para birimi topluluğunda her zaman geleneksel Web2 teknolojisinden ayrılma vurgulansa da, göz ardı edemeyeceğimiz şey, kripto para birimi altyapısının gelişiminin matematik, kriptografi, bulut teknolojisi ve büyük veri alanlarındaki sürekli gelişime ve atılımlara dayanmasıdır. . . Geleneksel Çin zıvana ve zıvana yapısına benzer şekilde, kripto para birimi ekosistemindeki çeşitli bileşenler yakından bağlantılıdır.

Bilim ve teknolojinin ilerlemesi ve yenilikçi uygulaması her zaman bazı nesnel ilkelere bağlı olacaktır. Örneğin, eliptik eğri şifreleme teknolojisinin temel desteği olmadan, bugün kripto para ekosistemimiz var olamaz. Aynı şekilde, sıfır bilgi kanıtlarının pratik uygulaması, 1985'te MIT tarafından yayınlanan sıfır bilgi kanıtları üzerine önemli araştırma makalesi olmadan mümkün olmazdı. Böylece ilginç bir model görüyoruz. ** Düğüm hizmet sağlayıcılarının geniş uygulaması ve genişlemesi, küresel bulut hizmetlerinin ve sanallaştırma teknolojisinin hızlı büyümesine dayanmaktadır. ** Aynı zamanda, Zincir üzerindeki veri katmanının geliştirilmesi, mükemmel açık kaynak veritabanı mimarisi ve hizmetlerinin güçlü bir şekilde geliştirilmesine dayanmaktadır,** bu mimariler, birçok iş zekası ürününün sunduğu veri çözümleridir. son yıllara güvenin **. Bunların hepsi, ticari uygulanabilirliği elde etmek için yeni başlayanların karşılaması gereken teknik ön koşullardır. Web3 projeleri söz konusu olduğunda, gelişmiş altyapı kullananlar, eski mimarilere dayananlara göre daha avantajlıdır. OpenSea'nin pazar payının daha hızlı ve daha kullanıcı dostu NFT değiş tokuşları nedeniyle aşınması canlı bir örnektir.

Ek olarak, bariz bir eğilim de görebiliriz: yapay zeka (AI) ve LLM teknolojisi yavaş yavaş olgunlaştı ve geniş uygulama olasılığına sahip.

**Bu nedenle, önemli bir soru ortaya çıkıyor: Yapay zeka, zincirdeki veri modelini nasıl değiştirecek? **

Fal bakmak

Geleceği tahmin etmek her zaman zorluklarla doludur, ancak blok zinciri geliştirmede karşılaşılan sorunları anlayarak olası cevapları keşfedebiliriz. **Geliştiricilerin zincir üstü verilere yönelik açık bir talepleri var: İhtiyaç duydukları şey doğru, zamanında ve anlaşılması kolay zincir üstü veriler. **

Şu anda karşı karşıya olduğumuz sorunlardan biri, belirli verileri toplu halde elde etmek veya görüntülemek için karmaşık SQL sorgularının gerekli olmasıdır. Dune tarafından sağlanan açık kaynaklı SQL işlevselliğinin kripto topluluğunda bu kadar popüler olmasının nedeni budur. Kullanıcıların sıfırdan çizelge oluşturmak için sql yazmalarına gerek yoktur, sadece fork yapıp dikkat etmek istedikleri akıllı sözleşmenin adresini değiştirmeleri yeterlidir ve ardından ihtiyaç duydukları çizelgeleri oluşturabilirler. Ancak bu, yalnızca belirli koşullar altında likidite veya airdrop verilerini görüntülemek isteyen ortalama bir kullanıcı için hala çok karmaşıktır.

Kanımca, bu sorunu çözmenin ilk adımı LLM ve doğal dil işlemeyi kullanmaktır.

Daha kullanıcı merkezli bir "veri sorgulama" arayüzü oluşturabilir ve LLM tekniklerinden yararlanabiliriz. Mevcut durumlarda, kullanıcıların API veya Studios'tan ilgili zincir üstü verileri çıkarmak için SQL veya GraphQL gibi karmaşık sorgulama dillerini kullanması gerekir. Bununla birlikte, LLM'yi kullanarak, soru sormanın daha sezgisel ve insana benzer bir yolunu sunabiliriz. Bu sayede kullanıcılar sorularını "doğal dilde" ifade edebilir ve LLM bunları uygun sorgulara çevirerek kullanıcılara ihtiyaç duydukları yanıtları sağlar.

Geliştiricilerin bakış açısından yapay zeka, zincirdeki sözleşme olaylarının analizini ve ABI kod çözmeyi de optimize edebilir. Şu anda birçok DeFi sözleşmesinin ayrıntıları, geliştiricilerin bunları manuel olarak ayrıştırmasını ve kodunu çözmesini gerektiriyor. Bununla birlikte, yapay zeka devreye girerse, çeşitli sözleşmeli sökme tekniklerini önemli ölçüde geliştirebilir ve ilgili ABI'yi hızlı bir şekilde alabiliriz. Büyük bir dil modeli (LLM) ile birleştirilen bu yapılandırma, işlev imzalarını akıllıca ayrıştırabilir ve çeşitli veri türlerini verimli bir şekilde işleyebilir. Ayrıca, sistem "akış bilgi işlem" işleme çerçevesi ile birleştirildiğinde, kullanıcıların acil ihtiyaçlarını karşılamak için işlem verilerinin analizini gerçek zamanlı olarak işleyebilir.

Daha küresel bir bakış açısıyla, bir indeksleyicinin amacı, kullanıcılara doğru veriler sağlamaktır. Daha önce vurguladığım gibi, zincir üstü veri katmanıyla ilgili potansiyel bir sorun, bireysel veri parçalarının farklı dizin oluşturucu veritabanlarına dağılmış ve birbirinden izole edilmiş olmasıdır. Çeşitli veri ihtiyaçlarını karşılamak için, bazı tasarımcılar zincirdeki tüm verileri bir veritabanına entegre etmeyi seçerler, böylece kullanıcılar gerekli bilgileri tek bir veri kümesinden seçebilirler. Bazı protokoller, DeFi verileri ve NFT verileri gibi yalnızca bazı verileri dahil etmeyi seçer. Ancak uyumsuz veri standartları sorunu hala mevcuttur. Bazen, geliştiricilerin birden çok kaynaktan veri alması ve kendi veritabanlarında yeniden biçimlendirmesi gerekir ki bu da kuşkusuz bakım yüklerini artırır. Ayrıca, bir veri sağlayıcısında sorun olması durumunda başka bir sağlayıcıya zamanında geçemezler.

Peki, LLM ve AI bu sorunu nasıl çözebilir? LlamaIndex bana bir açıklama sağladı. Ya geliştiriciler bir indeksleyiciye ihtiyaç duymaz, ancak zincirdeki ham verileri doğrudan okumak için konuşlandırılmış bir proxy hizmeti (aracı) kullanırsa? Bu ajan, indeksleyici ve LLM teknolojilerini birleştirir. Kullanıcının bakış açısına göre, API veya sorgulama dili hakkında hiçbir şey bilmeleri gerekmez, sadece soru sormaları ve anında geri bildirim almaları gerekir.

LLM ve yapay zeka teknolojisi ile donatılmış Agent, ham verileri anlar, işler ve bunları kullanıcıların anlaması kolay bir biçime dönüştürür. Bu, kullanıcıların karmaşık API'lerle veya sorgulama dilleriyle karşılaşma ihtiyacını ortadan kaldırır ve basit bir şekilde doğal dilde soru sorabilir ve gerçek zamanlı geri bildirim alabilir. Bu özellik, verilerin erişilebilirliğini ve kullanım kolaylığını artırarak zincir üstü verilere erişmek için daha geniş bir kullanıcı tabanını çeker.

Ek olarak, ajan hizmetinin (Agent) yolu, veri standardı uyumsuzluğu sorununu çözer. Ham on-chain verileri ayrıştırma ve işleme yeteneği ile tasarlandığından, farklı veri formatlarına ve standartlarına uyum sağlayabilir. Sonuç olarak, geliştiricilerin farklı kaynaklardan gelen verileri yeniden biçimlendirmeleri gerekmez ve iş yükleri azalır.

Tabii ki, bu sadece zincir üstü verilerin gelecekteki gelişim yörüngesi hakkında bir spekülasyon. Ancak teknolojide, devrim niteliğindeki ilerlemeyi yönlendiren genellikle bu cesur fikirler ve teorilerdir. İster tekerleğin icadı, ister blok zincirinin doğuşu olsun, tüm büyük atılımların birisinin varsayımından veya "çılgın" fikrinden başladığını unutmamalıyız.

Değişimi ve belirsizliği benimserken, sürekli olarak olasılık sınırlarını zorlamamız da gerekiyor. Bu çerçevede, AI, LLM ve blockchain kombinasyonunun daha açık ve kapsayıcı bir teknolojik alan oluşturacağı bir dünya tasavvur ediyoruz.

Chainbase bu vizyonu destekliyor ve onu gerçeğe dönüştürmeye kararlı.

Chainbase'deki misyonumuz, açık, arkadaş canlısı, şeffaf ve sürdürülebilir bir şifreli veri altyapısı oluşturmaktır. Amacımız, bu verilerin geliştiriciler tarafından kullanımını basitleştirmek ve arka uç teknoloji yığınının karmaşık yeniden düzenleme ihtiyacını ortadan kaldırmaktır. Bu şekilde, teknolojinin kullanıcılara yalnızca hizmet etmekle kalmayıp onları güçlendirdiği bir geleceğe öncülük etmeyi umuyoruz.

Ancak, bunun bizim yol haritamız olmadığını açıklığa kavuşturmalıyım. Aksine, bu, bir geliştirici ilişkileri temsilcisi olarak topluluktaki zincir üstü verilerin son gelişimi ve ilerlemesi hakkındaki kişisel düşüncemdir.