Ada banyak tabel database yang berjalan di sebuah chain, tetapi chain itu sendiri hampir tidak menyimpan data. Saat pertama kali melihat desain ini, saya kira ini cuma jalan pintas. Namun, semakin dipikirkan, semakin terasa bahwa ini memang disengaja.
Di SXT Chain, yang disimpan di chain hanyalah komitmen kriptografis untuk setiap tabel—bisa dianggap sebagai sidik jari tabel tersebut. Data sebenarnya tetap berada di luar chain. Node Prover menangani kueri dan pembuktiannya, lalu mengembalikan hasil beserta buktinya. Pihak yang memverifikasi cukup mencocokkannya dengan sidik jari untuk mengetahui apakah data telah diubah. Detail pentingnya: sidik jari ini bisa diperbarui. Saat data baru masuk, sidik jari baru dapat dihitung dari sidik jari lama dan data baru, tanpa perlu menelusuri kembali data lama. Jadi, tabel bisa terus bertambah tanpa membuat chain ikut membengkak.
Penilaian saya: sikap menahan diri ini adalah bagian paling cerdas sekaligus taruhan terbesarnya. Cerdas karena proyek ini sama sekali tidak mencoba bersaing dengan Ethereum atau Solana dalam eksekusi umum. Mereka langsung keluar dari persaingan itu dan hanya mengerjakan hal yang paling dibutuhkan kontrak: kemampuan untuk mengajukan kueri. Taruhannya, nilai chain yang hanya menyimpan komitmen data sepenuhnya bergantung pada “ada orang yang bersedia terus membayar kueri yang dapat diverifikasi”. Chain serbaguna sekalipun sepi masih bisa mengandalkan aplikasi lain sebagai penopang. Chain ini tidak punya penopang; jika permintaan tak kunjung datang, jadinya hanya chain kosong yang sangat cantik.
Ada satu hal lain yang menurut saya kurang diperhatikan: validator harus melakukan staking SXT, dan mereka akan terkena slashing jika berbuat curang. Pemicu slashing mencakup pengubahan komitmen, hasil kueri yang tidak dapat diverifikasi, serta respons yang terlalu lambat. Sederhananya, keamanan di sini bukan hanya soal mencegah pengeluaran ganda, tetapi juga mencegah “data diam-diam diubah”. Ini adalah cara pandang yang berbeda tentang keamanan.
Jadi, saat menilai proyek ini, saya tidak terpaku pada TPS. Saya hanya memperhatikan dua hal: apakah permintaan kueri nyata terus bertambah, dan siapa sebenarnya yang membayar. Yang pertama menunjukkan permintaan; yang kedua menentukan apakah permintaan itu benar-benar ada atau hanya dibentuk oleh subsidi.
Apakah jalur @SpaceandTime ini bisa berhasil? Nilai $SXT dipertaruhkan di sini. #SXT
#sxt $SXT
Di SXT Chain, yang disimpan di chain hanyalah komitmen kriptografis untuk setiap tabel—bisa dianggap sebagai sidik jari tabel tersebut. Data sebenarnya tetap berada di luar chain. Node Prover menangani kueri dan pembuktiannya, lalu mengembalikan hasil beserta buktinya. Pihak yang memverifikasi cukup mencocokkannya dengan sidik jari untuk mengetahui apakah data telah diubah. Detail pentingnya: sidik jari ini bisa diperbarui. Saat data baru masuk, sidik jari baru dapat dihitung dari sidik jari lama dan data baru, tanpa perlu menelusuri kembali data lama. Jadi, tabel bisa terus bertambah tanpa membuat chain ikut membengkak.
Penilaian saya: sikap menahan diri ini adalah bagian paling cerdas sekaligus taruhan terbesarnya. Cerdas karena proyek ini sama sekali tidak mencoba bersaing dengan Ethereum atau Solana dalam eksekusi umum. Mereka langsung keluar dari persaingan itu dan hanya mengerjakan hal yang paling dibutuhkan kontrak: kemampuan untuk mengajukan kueri. Taruhannya, nilai chain yang hanya menyimpan komitmen data sepenuhnya bergantung pada “ada orang yang bersedia terus membayar kueri yang dapat diverifikasi”. Chain serbaguna sekalipun sepi masih bisa mengandalkan aplikasi lain sebagai penopang. Chain ini tidak punya penopang; jika permintaan tak kunjung datang, jadinya hanya chain kosong yang sangat cantik.
Ada satu hal lain yang menurut saya kurang diperhatikan: validator harus melakukan staking SXT, dan mereka akan terkena slashing jika berbuat curang. Pemicu slashing mencakup pengubahan komitmen, hasil kueri yang tidak dapat diverifikasi, serta respons yang terlalu lambat. Sederhananya, keamanan di sini bukan hanya soal mencegah pengeluaran ganda, tetapi juga mencegah “data diam-diam diubah”. Ini adalah cara pandang yang berbeda tentang keamanan.
Jadi, saat menilai proyek ini, saya tidak terpaku pada TPS. Saya hanya memperhatikan dua hal: apakah permintaan kueri nyata terus bertambah, dan siapa sebenarnya yang membayar. Yang pertama menunjukkan permintaan; yang kedua menentukan apakah permintaan itu benar-benar ada atau hanya dibentuk oleh subsidi.
Apakah jalur @SpaceandTime ini bisa berhasil? Nilai $SXT dipertaruhkan di sini. #SXT
#sxt $SXT