Ini adalah bab kedua dari eksplorasi saya terhadap ICP - sejujurnya, saya tidak menyangka bisa menyelesaikannya begitu cepat, setelah bagian pertama diterbitkan, satu pertanyaan terus menghantui pikiran saya: mengapa blockchain selama bertahun-tahun tidak dapat mendukung aplikasi nyata?
Semakin saya menyelidiki, semakin jelas jawabannya: sebagian besar blockchain mempertahankan buku besar permanen.
Hampir tidak ada blockchain yang dapat menyediakan lingkungan eksekusi di mana aplikasi benar-benar berjalan, yang membuat saya sampai pada kesimpulan yang awalnya terasa agak tidak nyaman: sebagian besar rantai dapat mencatat aplikasi, tetapi mereka tidak dapat mendukung aplikasi.
Hanya ICP yang dapat benar-benar menjalankan aplikasi di rantai.
Mengapa? Karena model Canister + Subnet tidak dimaksudkan untuk mengoptimalkan TPS (transaksi per detik), tetapi untuk menyediakan lingkungan runtime bagi aplikasi, sebuah lingkungan yang dapat dieksekusi, berevolusi, dan tetap dapat diverifikasi secara kriptografi.
Ini sangat selaras dengan visi Caffeine: membuat aplikasi yang dihasilkan oleh kecerdasan buatan tidak hanya dapat dijalankan tetapi juga dapat membuktikan keasliannya.
Pengalaman saya menggunakan Caffeine AI
Saya mencoba membangun agregator berita X402 yang sederhana:
https://x402news-akn.caffeine.xyz
Arsitektur
Prosesnya sangat elegan:
Berdasarkan ide Anda, ia menghasilkan spec.md
Ia menggunakan Motoko untuk menulis frontend dan backend
Dan langsung menerapkan semuanya ke ICP
Setelah melalui banyak iterasi - dan banyak bug - akhirnya berjalan dengan normal, pengalaman Vibe-Coding saat ini belum mencapai tingkat Vercel, tetapi itu bukan bagian yang paling mengejutkan bagi saya, yang benar-benar mengejutkan saya adalah, saya merasakan untuk pertama kalinya: 'aplikasi saya sebenarnya berjalan di blockchain.'
Ini bukan kontrak, juga bukan transaksi, tetapi sebuah layanan backend - dihosting di rantai, berjalan terus, dapat dipanggil, dan dapat mengeksekusi logika secara mandiri.
Kemampuan ini tidak ada di sebagian besar rantai, kontrak pintar di tempat lain tidak dapat melakukan eksekusi secara proaktif, mereka hanya dapat bereaksi, ICP menyediakan apa yang belum pernah dibangun oleh perusahaan lain di industri: runtime tingkat rantai.
Mengapa Caffeine AI adalah hadiah terbaik ICP? Tetapi ini bukan hanya contoh lain dari kasus aplikasi blockchain, alasan mengapa Caffeine AI begitu menarik adalah bagaimana ia mewujudkan konsep aplikasi 'selalu online' di ICP.
Bagi Caffeine AI, fokus tidak hanya pada membangun aplikasi, tetapi juga pada membangun aplikasi yang dapat diverifikasi, persisten, dan berada di rantai, sehingga dapat terus berjalan, berevolusi dan meningkat, tanpa henti.
Inilah mengapa Caffeine AI menjadi hadiah terbaik ICP: ia tidak hanya menunjukkan potensi teknologi ICP, tetapi juga membawa kekuatan nyata ICP ke dunia nyata, membuka pintu bagi lebih banyak pengembang untuk membangun aplikasi yang dapat dijamin selalu ada selama node terus berjalan.
Apakah ekosistem lain bisa melakukan ini? Secara teori bisa:
Mengajukan nilai hash di Ethereum
Menyimpan kode di Filecoin atau EthStorage
Menggunakan zkVM untuk menerapkan eksekusi yang dapat diverifikasi
Pengkodean vibe berbasis Git seperti Vercel, dengan bukti pengiriman di rantai
Ya, Anda dapat menyusun 'pipa peningkatan yang dapat diverifikasi', tetapi kuncinya adalah, ketika Anda menerapkan dengan Caffeine AI, aplikasi Anda akan diterapkan di lingkungan runtime ICP, selama node terus berjalan, aplikasi Anda akan tetap berjalan.
Jaminan kelangsungan hidup ini - perasaan 'aplikasi saya benar-benar bertahan di rantai' - sangat sulit untuk digantikan, dan inilah alasan saya menulis bagian kedua.
Dalam artikel pertama, kami mendefinisikan kembali masalahnya: jika desentralisasi berhenti pada buku besar, internet tetap saja berada di luar rantai, artikel tersebut melakukan dua hal - mengalihkan fokus dari 'transaksi' ke 'aplikasi', dan mengubah kriteria evaluasi dari 'kecepatan pemutaran yang lebih cepat' menjadi hasil pengiriman yang dapat dijalankan, dapat berevolusi, dan dapat diverifikasi.
Tulisan ini tetap pada posisi ini, tetapi mengkategorikannya ke dalam bidang rekayasa: kami tidak lagi bertanya 'bagaimana membuat rantai lebih cepat', tetapi menjawab apa yang menjadi aplikasi yang berjalan di dalam batas protokol, dan kemampuan apa yang dibutuhkan untuk diinstitusionalisasikan.
Mekanisme penentuan tujuan, melihat 'transaksi' sebagai tujuan akan membuat sistem cenderung menyelesaikan dan memutar ulang, melihat 'aplikasi' sebagai tujuan akan memerlukan jalur publikasi yang lengkap, beroperasi, berevolusi dan dapat diverifikasi.
Oleh karena itu, kami memfokuskan perhatian pada kontainer ICP (Canister): bagaimana ia menyatukan kode, status, penyimpanan, dan publikasi ke dalam batas yang dapat diverifikasi; bagaimana ia mendukung evolusi frekuensi tinggi tanpa kehilangan memori; dan mengapa Caffeine AI sebagai 'aplikasi yang ditulis sendiri' harus berjalan langsung di atas kontainer, bukan melalui arsitektur 'cloud + kontrak' yang disambung.
Tulisan ini mencakup diagram struktur dan diagram urutan yang dapat ditindaklanjuti, serta menunjukkan pertimbangan dan kondisi batas yang penting.
1. Perubahan tujuan: dari transaksi ke aplikasi
Rantai 'berperforma tinggi' yang khas masih berfokus pada transaksi: kontrak bersifat pasif, eksekusi bersifat sementara, status global bersifat bersama, frontend berjalan di luar rantai.
ICP mengalihkan fokusnya ke aplikasi: kontainer membungkus kode, status, penyimpanan persisten dan antarmuka publikasi yang dapat diverifikasi, dan berjalan terus dengan model Aktor/asinkron.
Poin kunci
Semantik proses: persisten, dapat dijadwalkan, komunikasi asinkron antar kontainer, bukan lagi fungsi 'dihancurkan setelah dipanggil sekali'.
Batasan yang seragam: frontend, backend, status, publikasi, dan bukti semuanya berada dalam batas keamanan dan verifikasi yang sama.
Batasan bukanlah throughput, melainkan kondisi batas, rantai berkinerja tinggi mengoptimalkan batas 'semua orang memutar ulang buku besar yang sama', kontainer mengubah batas menjadi 'aplikasi yang berjalan lama dalam protokol, dan pengguna akhir dapat memverifikasi', yang pertama memperluas throughput, yang terakhir menyempurnakan siklus kemampuan.
2. Dapat diverifikasi dari ujung ke ujung: memasukkan frontend dan data ke dalam 'rantai penerbitan'
Agar seluruh situs web dapat secara tepercaya dihubungkan ke rantai, pengguna akhir harus dapat memverifikasi dalam browser 'apa yang saya lihat dipublikasikan oleh kontainer tertentu di bawah akar status tertentu', ICP menyediakan aset bersertifikat (sumber daya statis) dan variabel bersertifikat (snapshot dinamis) untuk menyelesaikan rantai penerbitan ini.
Petunjuk pelaksanaan
Aset bersertifikat: membangun pohon hash saat pembangunan, dan mengembalikan bukti dalam respons, browser memverifikasi melalui tanda tangan agregat subnet dan kunci publik tingkat rantai.
Variabel bersertifikat: mengekspor bukti snapshot dinamis, untuk menghindari pemutaran ulang klien, halaman mendapatkan data dan sumber enkripsi yang terikat pada akar status tertentu.
Publikasi adalah janji, ketika frontend dan variabel kunci bergabung dalam rantai sertifikasi, setiap publikasi menjadi janji kriptografi: penerbit, konten yang dipublikasikan, berdasarkan status konsensus apa, 'melihat' meningkat menjadi 'bukti', 'versi' meningkat menjadi 'bukti'.
3. Evolusi struktur: menjadikan 'perubahan rencana' sebagai pembaruan yang dapat diaudit
Produk yang didorong oleh kecerdasan buatan sering kali akan mengubah struktur data dan proses, migrasi implisit (skrip yang mengonsumsi bidang atau memperkecil tipe) adalah kegagalan implisit yang paling umum di cloud tradisional, kontainer menggunakan memori stabil dan kait pembaruan untuk secara eksplisit menetapkan batas evolusi, mengubah pembaruan menjadi peristiwa institusional yang dapat diaudit.
Daftar periksa operasi
Slot versi: menyimpan slot sebelumnya di memori stabil, setelah pembaruan, menangani nilai default/ekstensi secara eksplisit, dan melakukan rollback saat kegagalan.
CI akses: memeriksa perbedaan pola, kompatibilitas tipe dan migrasi idempotent sebelum penerapan, untuk mencegah 'migrasi yang tidak diverifikasi'.
Pembaruan akan mengeluarkan bukti: segera menyegarkan variabel yang telah terverifikasi setelah migrasi, sehingga klien mendapatkan snapshot baru yang telah diverifikasi.
Evolusi harus diinstitusionalisasikan, perpindahan implisit meninggalkan risiko kepada probabilitas, pembaruan eksplisit membawa risiko ke dalam proses, 'kegagalan menjadi bukti, rollback memiliki jalur, snapshot mendapatkan akreditasi' - desain rekayasa yang ketat diperlukan untuk mewujudkan evolusi yang sering.
4. Topologi asinkron antar kontainer: paralel tetapi batas jelas
Aplikasi yang dihasilkan oleh Caffeine sering kali dibagi menjadi beberapa kontainer (pengguna, autentikasi, pesanan, faktur, konten), menjaga jalur panas sebisa mungkin di dalam subnet yang sama untuk mengurangi latensi, dan mendorong jalur dingin ke asinkron.
Cycles melacak sumber daya: CPU/bandwidth/penyimpanan diukur berdasarkan sumber daya, panggilan silang dibayar di muka, bagian yang tidak terpakai dikembalikan.
Strategi topologi: menempatkan operasi baca/tulis dengan frekuensi tinggi/konsistensi kuat di dalam subnet yang sama, proses yang berjalan lama/rendah keterikatan dieksekusi secara asinkron.
Dapat diamati: konsumsi sumber daya di setiap jalur dapat ditelusuri, dapat memberikan informasi untuk penyesuaian gravitasi arsitektur.
Yang dapat dijalankan juga harus dapat dioperasikan, mengubah panggilan dari 'biaya persepsi' menjadi 'biaya akuntansi' menjadi dasar untuk pertimbangan rekayasa: menglokalisasi jalur panas, mengasinkronkan jalur dingin, sehingga desain dan biaya tetap konsisten.
5. Lapisan subnet: memasukkan paralelisme ke dalam pembangunan institusional
Setiap subnet adalah kluster eksekusi PBFT + threshold BLS: ia mencapai determinisme lokal yang final, dan mengeluarkan tanda tangan agregat berdasarkan akar status, lapisan protokol mendaftarkan subnet dan bahan kunci, Chain-Key mengekspos permukaan verifikasi yang bersatu di seluruh jaringan.
Eksekusi dan bukti peluncuran dilakukan di subnet
Verifikasi seluruh jaringan disederhanakan menjadi satu kunci publik dan rantai bukti
Tanpa pemutaran global, paralelisme adalah atribut protokol, bukan trik operasional
Pemrosesan paralel bukanlah solusi sementara, tetapi desain institusi, dengan memindahkan verifikasi dari 'eksekusi ulang' terpusat ke rantai bukti yang dapat diverifikasi secara independen, bahkan klien pun dapat melakukan verifikasi - sehingga menjaga keseimbangan antara paralelisme dan keamanan.
6. Identitas dan sesi: menjadikan login sebagai hak yang dapat dibawa
Caffeine menggunakan Internet Identity 2.0: login tanpa kata sandi (Passkey), dan mengagregasi informasi login Google / Apple / Microsoft, sesi disampaikan kepada kontainer aplikasi dalam bentuk delegasi yang dapat diverifikasi, bukan menggunakan cookie platform, pengguna yang ada dapat meningkatkan identitasnya selama login.
Dengan cara ini, 'siapa yang dapat mengakses dan berdasarkan apa' tetap konsisten dengan batasan yang dapat diverifikasi dari aplikasi, menghindari platform eksternal menjadi penguasa tersembunyi.
7. Jalur pengiriman Caffeine: dari diskusi ke bukti
'Aplikasi yang ditulis sendiri' harus beralih dari bahasa alami ke 'pengiriman yang dapat diverifikasi', setiap langkah menghasilkan hasil sementara yang dapat diverifikasi.
Apa yang akhirnya dilihat pengguna adalah antarmuka dengan bukti: sumber daya UI dan data penting dapat diverifikasi secara lokal dalam browser melalui rantai bukti, tidak lagi 'percaya pada platform'.
Mengubah pola pengiriman dari 'platform yang dapat dipercaya' menjadi 'verifikasi di tepi', bagi Caffeine, memilih kontainer bukan karena pertimbangan TPS, tetapi untuk menjadikan 'publikasi yang didukung bukti, evolusi yang memiliki proses, identitas yang dapat dipindahkan, biaya yang dapat dikendalikan' sebagai asumsi default.
8. Tiga profil biaya mekanisme untuk tujuan yang sama
Tabel ini mencerminkan dua aspek pertimbangan: desain kapasitas (eksekusi/simpan/paralelisme) dan batas yang dapat diverifikasi (bukti/identitas/biaya), kedua aspek ini harus dipenuhi agar aplikasi dapat berkembang dari 'menjalankan satu transaksi' menjadi 'beroperasi dalam jangka panjang'.
9. Dari 'buku besar yang lebih cepat' ke 'mekanisme untuk aplikasi'
Kami pertama-tama mengubah nama masalah ini: jika desentralisasi berhenti pada buku besar, maka internet tetap berada di luar rantai.
Sekarang kita dapat menjawab pertanyaan ini:
Menempatkan frontend dan data di dalam rantai penerbitan yang dapat diverifikasi, sehingga pengguna akhir tidak lagi bergantung pada kepercayaan platform.
Menjadikan evolusi struktur sebagai peristiwa peningkatan yang dapat diaudit untuk iterasi cepat yang terjamin secara institusional.
Mewujudkan paralelisme tingkat institusi di lapisan subnet, sehingga skala menjadi atribut protokol, bukan trik rekayasa.
Melihat identitas sebagai hak yang dapat dibawa, sehingga login menjadi delegasi yang dapat diverifikasi, bukan hak yang diberikan oleh platform.
Semua ini membentuk sebuah aplikasi yang berjalan di dalam batas protokol - bukan 'kontrak di rantai', tetapi 'seluruh aplikasi di dalam batas yang dapat diverifikasi'.
Mekanisme penentuan tujuan, ketika tujuan beralih dari 'transaksi' ke 'aplikasi', sistem harus berevolusi dari 'bagaimana mempercepat pemutaran buku besar' menjadi 'bagaimana menjaga agar aplikasi tetap dapat dijalankan, dapat berevolusi dan dapat diverifikasi', yang dapat memenuhi ketiga hal ini bukanlah buku besar yang lebih cepat, tetapi lingkungan runtime aplikasi terdesentralisasi.
Kontainer adalah unit runtime, Chain-Key / NNS menyediakan verifikasi dan tata kelola, Cycles / II 2.0 mengintegrasikan biaya dan kewarganegaraan ke dalam operasi sehari-hari.
Bagi Caffeine, pilihan ini bukan karena pertimbangan naratif, tetapi karena keharusan: ketika AI terus menulis ulang aplikasi, hasilnya harus dapat dijalankan dan dapat diverifikasi oleh pengguna - ini adalah masalah yang ingin dipecahkan oleh ICP.
Langkah berikutnya dari mimpi yang belum selesai
Dalam artikel pertama kami disebutkan, bahwa fokus revolusi blockchain tidak pernah pada pencetakan token, tetapi pada membentuk kembali wadah kepercayaan, sepuluh tahun telah berlalu, kami telah mencapai desentralisasi buku besar, tetapi internet masih beroperasi di server terpusat.
ICP memicu kemungkinan mengubah blockchain dari buku besar dunia menjadi sistem operasi dunia.
Tulisan ini dimulai dari sudut pandang rekayasa: kontainer (Canister) mengubah aplikasi dari 'kontrak + pengikat di luar rantai' menjadi lingkungan runtime di mana kode, status, frontend, dan identitas berada di dalam batas protokol, paralelisme subnet, verifikasi kunci rantai, dan pembaruan memori stabil membuat pola ini secara rekayasa dapat dilakukan, secara kriptografi dapat diverifikasi, dan secara ekonomi dapat dipertanggungjawabkan.
Ketika kecerdasan buatan mulai membangun, menerapkan, dan mengembangkan layanan secara iteratif di rantai, itu tidak memerlukan buku besar yang lebih cepat, tetapi membutuhkan komputer aplikasi yang terdesentralisasi.
Caffeine memilih ICP bukan karena TPS, tetapi karena pada akhirnya menjadikan 'pengiriman penuh tumpukan di rantai dan dapat diverifikasi' sebagai pengaturan default protokol - inilah titik awal yang benar untuk internet terdesentralisasi.
Dari buku besar ke komputer ke runtime aplikasi - mimpi blockchain yang belum selesai terus maju dengan menggantikan 'platform terpercaya' dengan 'bukti di tepi'.
Konten IC yang Anda pedulikan
Kemajuan teknologi | Informasi proyek | Kegiatan global
Simpan dan ikuti saluran IC Binance
Dapatkan informasi terbaru