Dari blockchain ke LLM, interpretasi mendalam tentang evolusi dan tantangan teknologi pengindeksan data

Sejak Satoshi Nakamoto memutuskan untuk menyematkan pesan di blok genesis, struktur data rantai Bitcoin telah mengalami serangkaian perubahan.

Saya mulai mempelajari pengembangan blockchain secara mendalam pada tahun 2022, dan buku pertama yang saya baca adalah "Mastering Ethereum". Buku ini sangat bagus dan memberi saya banyak pemahaman mendalam tentang dasar-dasar Ethereum dan Blockchain. Namun, dari sudut pandang hari ini, beberapa teknik pengembangan dalam buku ini sudah agak ketinggalan zaman. Langkah awal melibatkan menjalankan node pada laptop pribadi, bahkan untuk dompet dApp, membutuhkan light node untuk diunduh sendiri. Ini mencerminkan pola perilaku pengembang dan peretas awal dalam ekosistem pengembangan blockchain antara 2015 dan 2018.

Kembali pada tahun 2017, kami tidak memiliki penyedia layanan simpul. Dari perspektif penawaran dan permintaan, fungsi utamanya adalah melakukan transaksi karena aktivitas pengguna yang terbatas. Ini berarti bahwa memelihara atau menghosting node penuh sendiri tidak terlalu membebani, karena tidak banyak permintaan RPC untuk diproses dan permintaan transfer jarang terjadi. Sebagian besar pengadopsi awal Ethereum adalah ahli teknologi. Para pengguna awal ini memiliki pemahaman mendalam tentang pengembangan blockchain dan terbiasa memelihara node Ethereum secara langsung, membuat transaksi, dan mengelola akun melalui baris perintah atau lingkungan pengembangan terintegrasi.

Oleh karena itu, kami dapat mengamati bahwa proyek awal biasanya memiliki UI/UX yang sangat bersih. Beberapa dari proyek ini bahkan tidak memiliki tampilan depan, dan aktivitas pengguna cukup rendah. Karakteristik proyek ini terutama ditentukan oleh dua faktor: perilaku pengguna dan struktur data rantai.

Kebangkitan Penyedia Node

Karena semakin banyak pengguna tanpa latar belakang pemrograman bergabung dengan jaringan blockchain, arsitektur teknis aplikasi terdesentralisasi juga telah berubah. Mode asli hosting node oleh pengguna secara bertahap berubah menjadi hosting node oleh pihak proyek

Orang-orang cenderung memilih layanan node hosting, terutama karena pesatnya pertumbuhan data pada rantai membuat biaya node hosting pribadi meningkat secara bertahap dari waktu ke waktu.

Namun, node yang dihosting sendiri oleh tim proyek tetap menjadi tantangan bagi pengembang proyek kecil, yang membutuhkan investasi pemeliharaan dan biaya perangkat keras yang berkelanjutan. Oleh karena itu, proses hosting node yang kompleks ini biasanya dipercayakan kepada perusahaan yang berspesialisasi dalam pemeliharaan node. Perlu disebutkan bahwa waktu konstruksi dan penggalangan dana skala besar perusahaan ini bertepatan dengan tren peningkatan layanan cloud di industri teknologi Amerika Utara.

| Proyek | Kategori | Didirikan sejak | | --- | --- | --- | | Alkimia | Node | 2017 | | Infura | Node | 2016 | | Node Sekarang | Node | 2019 | | QuickNodes | Node | 2017 | | Jangkar | node | 2017 | | ChainStack | Node | 2018 |

Hanya menghosting node dari jarak jauh tidak dapat menyelesaikan masalah sepenuhnya, terutama sekarang protokol terkait seperti DeFi dan NFT sedang bermunculan. Pengembang perlu menangani banyak masalah data, karena data yang disediakan oleh node blockchain itu sendiri disebut data mentah, yang tidak distandarisasi dan dibersihkan. Data di dalamnya perlu diekstraksi, dibersihkan, dan dimuat.

Misalnya, saya adalah pengembang proyek NFT dan ingin melakukan transaksi NFT atau menampilkan NFT. Kemudian ujung depan saya perlu membaca data NFT di akun EOA pribadi secara real time. NFT sebenarnya hanyalah bentuk token standar. Memiliki NFT berarti saya memiliki token dengan ID unik yang dihasilkan oleh kontrak NFT, dan gambar NFT sebenarnya adalah metadata, yang mungkin berupa data SVG atau tautan ke gambar di IPFS. Meskipun klien Geth Ethereum menyediakan instruksi pengindeksan, untuk beberapa proyek dengan persyaratan front-end yang besar, tidak praktis untuk meminta Geth terus menerus dan kemudian kembali ke front-end. Untuk beberapa fungsi, seperti lelang pesanan dan agregasi transaksi NFT, mereka harus dilakukan secara off-chain untuk mengumpulkan instruksi pengguna, dan kemudian mengirimkan instruksi ini ke rantai pada waktu yang tepat.

Oleh karena itu, lahirlah lapisan data sederhana. Untuk memenuhi persyaratan real-time dan akurasi pengguna, pihak proyek perlu membangun basis data dan fungsi analisis datanya sendiri.

**Bagaimana pengindeks data berkembang? **

Memulai sebuah proyek biasanya merupakan urusan yang relatif sederhana. Anda punya ide, menetapkan beberapa tujuan, menemukan insinyur terbaik, dan membangun prototipe yang berfungsi, yang biasanya mencakup ujung depan dan beberapa kontrak pintar.

Namun, cukup sulit untuk membuat skala proyek. Seseorang perlu memikirkan secara mendalam tentang struktur desain sejak hari pertama proyek. Jika tidak, Anda dapat dengan cepat mengalami masalah, yang biasanya saya sebut sebagai "masalah icing".

Istilah ini saya pinjam dari film "Iron Man", dan sepertinya sangat cocok untuk menggambarkan situasi kebanyakan startup. Ketika startup berkembang pesat (menarik banyak pengguna), mereka sering mengalami masalah karena mereka tidak memperkirakannya sejak awal. Dalam film tersebut, penjahat tidak pernah mengharapkan perlengkapan perangnya terbang ke luar angkasa karena dia tidak memperhitungkan "masalah icing". Demikian juga, untuk pengembang banyak proyek Web3, "masalah pembekuan" melibatkan penanganan peningkatan beban adopsi pengguna massal. Ini memberi tekanan berat pada sisi server karena jumlah pengguna tumbuh secara dramatis. Ada juga masalah yang terkait dengan blockchain itu sendiri, seperti masalah jaringan atau penutupan node.

Sebagian besar waktu itu adalah masalah backend. Misalnya, dalam beberapa protokol game blockchain, situasi ini tidak jarang terjadi. Ketika mereka berencana untuk menambahkan lebih banyak server dan mempekerjakan lebih banyak insinyur data untuk mengurai data pada rantai, mereka tidak memperkirakan begitu banyak pengguna yang berpartisipasi. Pada saat mereka menyadari hal ini, semuanya sudah terlambat. Dan masalah teknis ini tidak dapat diselesaikan hanya dengan menambahkan lebih banyak insinyur back-end. Seperti yang saya katakan sebelumnya, pertimbangan ini harus dimasukkan ke dalam rencana sejak awal.

Masalah kedua melibatkan penambahan blockchain baru. Anda mungkin menghindari masalah sisi server sejak awal dan mempekerjakan banyak insinyur yang baik. Namun, pengguna Anda mungkin tidak senang dengan blockchain saat ini. Mereka ingin layanan Anda juga berjalan di rantai populer lainnya seperti rantai zk atau rantai L2. Struktur proyek Anda mungkin akan terlihat seperti ini:

Dalam jenis sistem ini, Anda memiliki kendali penuh atas data Anda, yang memungkinkan pengelolaan yang lebih baik dan peningkatan keamanan. Sistem membatasi permintaan panggilan, mengurangi risiko kelebihan beban, dan meningkatkan efisiensi. Dan penyiapannya kompatibel dengan ujung depan, memastikan integrasi yang mulus dan pengalaman pengguna.

Namun, biaya pengoperasian dan pemeliharaan berlipat ganda, yang dapat membebani sumber daya Anda. Menambahkan blockchain baru setiap kali membutuhkan pekerjaan berulang, yang dapat memakan waktu dan tidak efisien. Memilih data dari kumpulan data besar dapat mengurangi waktu kueri, berpotensi memperlambat proses. Karena masalah jaringan blockchain seperti rollback dan reorganisasi, data dapat ternoda, mengorbankan integritas dan keandalan data.

Proyek dirancang untuk mencerminkan anggota tim Anda. Menambahkan lebih banyak node dan mencoba membangun sistem yang berfokus pada backend berarti Anda perlu mempekerjakan lebih banyak insinyur untuk mengoperasikan node tersebut dan mendekode data mentah.

Model ini mirip dengan masa awal Internet, ketika platform e-commerce dan pengembang aplikasi memilih untuk membangun fasilitas IDC (Internet Data Center) sendiri. Namun, biaya berjalan seiring dengan kompleksitas desain program karena permintaan pengguna tumbuh dan keadaan jaringan blockchain meledak. Selain itu, pendekatan ini menghambat ekspansi pasar yang cepat. Beberapa blockchain publik berkinerja tinggi memerlukan operasi node intensif perangkat keras, sementara sinkronisasi dan pembersihan data menghabiskan sumber daya manusia dan biaya waktu.

Jika Anda mencoba membangun pasar NFT berbasis blockchain atau game keren, bukankah mengejutkan jika 65% anggota tim Anda adalah insinyur backend dan data?

**Mungkin pengembang akan bertanya-tanya mengapa tidak ada yang mendekode dan mentransmisikan data on-chain ini untuk mereka sehingga mereka dapat berfokus untuk membuat produk yang lebih baik. **

** Saya percaya inilah mengapa pengindeks ada di sana. **

Untuk mengurangi kesulitan mengakses aplikasi Web3 dan jaringan blockchain, banyak tim pengembangan termasuk kami memilih untuk mengintegrasikan langkah-langkah seperti pemeliharaan node arsip, ETL data on-chain (mengekstrak, mengubah, memuat) dan panggilan basis data. Tugas-tugas ini awalnya mengharuskan tim proyek untuk mempertahankan diri mereka sendiri, tetapi sekarang mereka telah menyadari operasi terintegrasi dengan menyediakan data multi-rantai dan API node.

Dengan bantuan API ini, pengguna dapat menyesuaikan data on-chain sesuai dengan kebutuhan mereka. Ini mencakup semuanya, mulai dari metadata NFT populer, memantau aktivitas on-chain dari alamat tertentu, hingga melacak data transaksi dari kumpulan likuiditas token tertentu. Saya sering menyebut pendekatan ini sebagai bagian dari struktur proyek Web3 modern.

Pembiayaan dan pembangunan proyek lapisan data dan lapisan indeks terutama akan dilakukan pada tahun 2022. Saya percaya bahwa praktik bisnis dari proyek lapisan indeks dan lapisan data ini terkait erat dengan desain arsitektur data yang mendasarinya, terutama dengan desain sistem OLAP (On-Line Analytical Processing). Mengadopsi mesin inti yang sesuai adalah kunci untuk mengoptimalkan kinerja lapisan indeks, termasuk meningkatkan kecepatan pengindeksan dan memastikan stabilitasnya. Mesin yang biasa digunakan termasuk Hive, Spark SQL, Presto, Kylin, Impala, Druid, ClickHouse, dll. Di antara mereka, ClickHouse adalah basis data yang kuat yang banyak digunakan di perusahaan Internet, bersumber terbuka pada tahun 2016 dan menerima pembiayaan sebesar 250 juta dolar AS pada tahun 2021.

Oleh karena itu, munculnya database generasi baru dan peningkatan arsitektur pengoptimalan indeks data telah mengarah pada pembuatan lapisan indeks data Web3. Hal ini memungkinkan perusahaan di bidang ini untuk menyediakan layanan API data secara lebih cepat dan efisien.

Namun, pembangunan pengindeksan data on-chain masih diselimuti oleh dua awan gelap.

Dua Awan Gelap

Awan gelap pertama adalah tentang dampak stabilitas jaringan blockchain di sisi server. Meskipun jaringan blockchain memiliki stabilitas yang kuat, tidak demikian halnya selama transmisi dan pemrosesan data. Misalnya, peristiwa seperti reorganisasi (reorg) dan pengembalian (rollback) dari blockchain dapat menimbulkan tantangan terhadap stabilitas data pengindeks.

Reorganisasi blockchain adalah ketika node untuk sementara kehilangan sinkronisasi, menyebabkan dua versi berbeda dari blockchain ada pada saat yang bersamaan. Situasi seperti itu dapat dipicu oleh kegagalan sistem, penundaan jaringan, atau bahkan perilaku berbahaya. Saat node disinkronkan ulang, mereka akan menyatu ke satu rantai resmi, dan blok "bercabang" alternatif sebelumnya akan dibuang.

Pada saat reorganisasi terjadi, pengindeks mungkin telah memproses data dari blok yang akhirnya dibuang, mencemari database. Oleh karena itu, pengindeks harus beradaptasi dengan situasi ini, membuang data pada rantai yang tidak valid dan memproses ulang data pada rantai yang baru diterima.

Penyesuaian tersebut dapat mengakibatkan peningkatan penggunaan sumber daya dan berpotensi menunda ketersediaan data. Dalam kasus yang ekstrim, reorganisasi blok yang sering atau berskala besar dapat sangat memengaruhi keandalan dan kinerja layanan yang bergantung pada pengindeks, termasuk aplikasi Web3 yang menggunakan API untuk mengambil data.

Selain itu, kami dihadapkan pada masalah terkait kompatibilitas format data dan keragaman standar data di seluruh jaringan blockchain.

Di bidang teknologi blockchain, ada banyak jaringan berbeda, masing-masing dengan standar data uniknya sendiri. Misalnya, ada rantai yang kompatibel dengan EVM (Ethereum Virtual Machine), rantai non-EVM, dan rantai zk (zero-knowledge), yang masing-masing memiliki struktur dan format data khusus sendiri.

Ini tidak diragukan lagi merupakan tantangan besar bagi pengindeks. Untuk menyediakan data yang berguna dan akurat melalui API, pengindeks harus mampu menangani beragam format data ini. Namun, karena tidak ada standar universal untuk data blockchain, pengindeks yang berbeda dapat menggunakan standar API yang berbeda. Hal ini dapat menyebabkan masalah kompatibilitas data, di mana data yang diekstraksi dan diubah dari satu pengindeks mungkin tidak dapat digunakan di sistem lain.

Selain itu, saat pengembang menjelajahi dunia multi-rantai ini, mereka sering menghadapi tantangan dalam menangani standar data yang berbeda ini. Solusi yang berfungsi untuk satu jaringan blockchain mungkin tidak berfungsi untuk yang lain, sehingga sulit untuk mengembangkan aplikasi yang dapat berinteraksi dengan banyak jaringan.

Memang, tantangan yang dihadapi industri pengindeksan blockchain mengingatkan pada dua masalah fisika yang belum terpecahkan yang diidentifikasi oleh Lord Kelvin pada awal abad ke-20, yang akhirnya melahirkan bidang revolusioner seperti mekanika kuantum dan termodinamika.

Menghadapi tantangan ini, industri memang telah mengambil beberapa langkah, seperti memperkenalkan latensi atau mengintegrasikan streaming dalam pipa Kafka, dan bahkan membentuk konsorsium standar untuk memperkuat industri pengindeksan blockchain. Langkah-langkah ini saat ini dapat mengatasi ketidakstabilan jaringan blockchain dan keragaman standar data, sehingga pengindeks dapat menyediakan data yang akurat dan andal.

Namun, sama seperti munculnya teori kuantum merevolusi pemahaman kita tentang dunia fisik, kita juga dapat mempertimbangkan cara yang lebih radikal untuk meningkatkan infrastruktur data blockchain.

**Lagipula, infrastruktur yang ada, dengan gudang dan tumpukan data yang tertata rapi, mungkin tampak terlalu sempurna dan terlalu indah untuk menjadi kenyataan. **

Jadi, ** Apakah ada cara lain? **

Menemukan pola

Mari kembali ke topik awal tentang kemunculan penyedia node dan pengindeks, dan pertimbangkan masalah yang aneh. Mengapa operator node tidak muncul di tahun 2010, tetapi pengindeks tiba-tiba muncul dalam jumlah besar dan menerima banyak investasi di tahun 2022?

Saya percaya saya di atas sebagian telah menjawab pertanyaan-pertanyaan ini. Ini karena meluasnya penggunaan teknologi komputasi awan dan pergudangan data di industri perangkat lunak, bukan hanya di bidang enkripsi.

Dalam dunia enkripsi, sesuatu yang istimewa juga terjadi, terutama ketika standar ERC20 dan ERC721 menjadi populer di media publik. Selain itu, musim panas DeFi telah membuat data on-chain menjadi lebih rumit. Berbagai transaksi panggilan dialihkan ke smart contract yang berbeda, alih-alih data transaksi sederhana seperti pada tahap awal, format dan kompleksitas data on-chain telah mengalami perubahan dan pertumbuhan yang mengejutkan.

Meskipun dalam komunitas cryptocurrency selalu ditekankan untuk memisahkan diri dari teknologi Web2 tradisional, namun yang tidak dapat kita abaikan adalah bahwa pengembangan infrastruktur cryptocurrency bergantung pada pengembangan dan terobosan berkelanjutan di bidang matematika, kriptografi, teknologi cloud, dan data besar. . . Mirip dengan struktur tanggam dan tenon Tiongkok tradisional, berbagai komponen dalam ekosistem mata uang kripto terhubung erat.

Kemajuan dan penerapan inovatif ilmu pengetahuan dan teknologi akan selalu terikat oleh beberapa prinsip objektif. Misalnya, tanpa dukungan dasar teknologi enkripsi kurva eliptik, ekosistem mata uang kripto kita saat ini tidak akan ada. Demikian pula, aplikasi praktis dari bukti tanpa pengetahuan tidak akan mungkin terjadi tanpa makalah penelitian penting tentang bukti tanpa pengetahuan yang diterbitkan oleh MIT pada tahun 1985. Jadi kita melihat pola yang menarik. ** Aplikasi luas dan perluasan penyedia layanan node didasarkan pada pertumbuhan pesat layanan cloud global dan teknologi virtualisasi. ** Pada saat yang sama, Pengembangan lapisan data pada rantai didasarkan pada pengembangan yang kuat dari arsitektur dan layanan database sumber terbuka yang sangat baik,** arsitektur ini adalah solusi data yang digunakan oleh banyak produk intelijen bisnis andalkan dalam beberapa tahun terakhir **. Ini semua adalah prasyarat teknis yang harus dipenuhi oleh startup untuk mencapai kelayakan komersial. Dalam hal proyek Web3, proyek yang menggunakan infrastruktur canggih cenderung memiliki keunggulan dibandingkan proyek yang mengandalkan arsitektur usang. Erosi pangsa pasar OpenSea dengan pertukaran NFT yang lebih cepat dan ramah pengguna adalah contoh nyata.

Selain itu, kita juga dapat melihat tren yang jelas: kecerdasan buatan (AI) dan teknologi LLM secara bertahap semakin matang dan memiliki kemungkinan untuk diterapkan secara luas.

**Oleh karena itu, muncul pertanyaan penting: Bagaimana AI akan mengubah pola data pada rantai? **

Meramal

Memprediksi masa depan selalu penuh dengan kesulitan, tetapi kita dapat mengeksplorasi kemungkinan jawaban dengan memahami masalah yang dihadapi dalam pengembangan blockchain. ** Pengembang memiliki permintaan yang jelas untuk data on-chain: yang mereka butuhkan adalah data on-chain yang akurat, tepat waktu, dan mudah dipahami. **

Salah satu masalah yang kami hadapi saat ini adalah kueri SQL yang kompleks diperlukan untuk mendapatkan atau menampilkan data tertentu secara berkelompok. Inilah mengapa fungsionalitas SQL open source yang disediakan oleh Dune sangat populer di komunitas crypto. Pengguna tidak perlu menulis sql untuk membuat bagan dari awal, mereka hanya perlu memotong dan mengubah alamat kontrak pintar yang ingin mereka perhatikan, lalu mereka dapat membuat bagan yang mereka butuhkan. Namun, ini masih terlalu rumit untuk rata-rata pengguna yang hanya ingin melihat data likuiditas atau airdrop dalam kondisi tertentu.

Menurut saya, langkah pertama dalam menyelesaikan masalah ini adalah dengan memanfaatkan LLM dan natural language processing.

Kami dapat membangun antarmuka "permintaan data" yang lebih berpusat pada pengguna dan memanfaatkan teknik LLM. Dalam kasus yang ada, pengguna harus menggunakan bahasa kueri yang kompleks seperti SQL atau GraphQL untuk mengekstrak data on-chain yang sesuai dari API atau Studios. Namun, dengan menggunakan LLM, kami dapat memperkenalkan cara mengajukan pertanyaan yang lebih intuitif dan manusiawi. Dengan cara ini, pengguna dapat mengungkapkan pertanyaan mereka dalam "bahasa alami", dan LLM akan menerjemahkannya menjadi pertanyaan yang sesuai dan memberikan jawaban yang dibutuhkan pengguna.

Dari perspektif pengembang, kecerdasan buatan juga dapat mengoptimalkan analisis peristiwa kontrak pada rantai dan decoding ABI. Saat ini, detail dari banyak kontrak DeFi mengharuskan pengembang untuk mengurai dan mendekodekannya secara manual. Namun, jika kecerdasan buatan diperkenalkan, kami dapat meningkatkan berbagai teknik pembongkaran kontrak secara signifikan dan dengan cepat mengambil ABI yang sesuai. Dikombinasikan dengan model bahasa besar (LLM), konfigurasi ini dapat dengan cerdas mengurai tanda tangan fungsi dan secara efisien menangani berbagai tipe data. Selanjutnya, ketika sistem digabungkan dengan kerangka pemrosesan "komputasi aliran", sistem dapat memproses analisis data transaksi secara real time untuk memenuhi kebutuhan mendesak pengguna.

Dari perspektif yang lebih global, tujuan pengindeks adalah menyediakan data yang akurat kepada pengguna. Seperti yang telah saya soroti sebelumnya, masalah potensial dengan lapisan data on-chain adalah bahwa setiap bagian data tersebar di database pengindeks yang berbeda dan diisolasi satu sama lain. Untuk memenuhi kebutuhan data yang beragam, beberapa desainer memilih untuk mengintegrasikan semua data pada rantai ke dalam database, sehingga pengguna dapat memilih informasi yang diperlukan dari kumpulan data tunggal. Beberapa protokol memilih untuk hanya menyertakan beberapa data, seperti data DeFi dan data NFT. Namun masalah standar data yang tidak kompatibel masih ada. Kadang-kadang, pengembang perlu mengambil data dari berbagai sumber dan memformat ulang dalam database mereka sendiri, yang tentunya menambah beban pemeliharaan mereka. Selain itu, mereka tidak dapat bermigrasi ke penyedia lain secara tepat waktu jika ada masalah dengan satu penyedia data.

Jadi, bagaimana LLM dan AI bisa mengatasi masalah ini? LlamaIndex memberi saya sebuah wahyu. Bagaimana jika pengembang tidak memerlukan pengindeks, tetapi menggunakan layanan proxy (agen) yang diterapkan untuk langsung membaca data mentah di rantai? Agen ini menggabungkan teknologi pengindeks dan LLM. Dari sudut pandang pengguna, mereka tidak perlu tahu apa-apa tentang API atau bahasa kueri, mereka hanya perlu mengajukan pertanyaan dan mendapatkan umpan balik instan.

Dilengkapi dengan LLM dan teknologi kecerdasan buatan, Agen memahami dan memproses data mentah dan mengubahnya menjadi format yang mudah dipahami pengguna. Hal ini menghilangkan kebutuhan pengguna untuk menghadapi API atau bahasa kueri yang rumit, dan mereka dapat dengan mudah mengajukan pertanyaan dalam bahasa alami dan mendapatkan umpan balik waktu nyata. Fitur ini meningkatkan aksesibilitas dan kemudahan penggunaan data, menarik basis pengguna yang lebih luas untuk mengakses data on-chain.

Selain itu, cara layanan agen (Agent) memecahkan masalah ketidakcocokan standar data. Karena telah dirancang dengan kemampuan untuk mengurai dan memproses data on-chain mentah, ia dapat beradaptasi dengan format dan standar data yang berbeda. Hasilnya, pengembang tidak perlu memformat ulang data dari berbagai sumber, sehingga mengurangi beban kerja mereka.

Tentu saja, ini hanyalah spekulasi tentang lintasan pengembangan data on-chain di masa mendatang. Namun dalam teknologi, seringkali ide dan teori yang berani inilah yang mendorong kemajuan revolusioner. Kita harus ingat bahwa apakah itu penemuan roda atau kelahiran blockchain, semua terobosan besar dimulai dari asumsi atau ide "gila" seseorang.

Saat kita merangkul perubahan dan ketidakpastian, kita juga ditantang untuk terus mendorong batas kemungkinan. Dengan latar belakang ini, kami membayangkan dunia di mana kombinasi AI, LLM, dan blockchain akan menghasilkan bidang teknologi yang lebih terbuka dan inklusif.

Chainbase menjunjung tinggi visi ini dan berkomitmen untuk mewujudkannya.

Misi kami di Chainbase adalah menciptakan infrastruktur data terenkripsi yang terbuka, ramah, transparan, dan berkelanjutan. Sasaran kami adalah untuk menyederhanakan penggunaan data ini oleh developer, menghilangkan kebutuhan akan pemfaktoran ulang yang rumit dari kumpulan teknologi backend. Dengan cara ini, kami berharap dapat mewujudkan masa depan di mana teknologi tidak hanya melayani pengguna, tetapi juga memberdayakan mereka.

Namun, saya harus mengklarifikasi bahwa ini bukan peta jalan kami. Sebaliknya, ini adalah refleksi pribadi saya tentang perkembangan dan kemajuan data on-chain baru-baru ini di komunitas sebagai perwakilan hubungan pengembang.