Baru-baru ini meneliti implementasi lapisan penyimpanan data dari sebuah blockchain privasi, dan menemukan bahwa mereka sangat teliti dalam mengelola hash dan redundansi sharding—sebagian besar proyek privasi fokus pada privasi transaksi, tetapi kurang memperhatikan ketersediaan data dan biaya penyimpanan, proyek ini mengisi kekurangan utama tersebut.
Pertama, tentang bagian hash. Blake2b secara alami lebih cepat daripada SHA-3, tetapi di sini dilakukan optimasi pemotongan untuk data privasi—hanya menyimpan field yang diperlukan untuk verifikasi, langsung mengurangi 20% redundansi penyimpanan. Lebih cerdas lagi, proses hashing dilakukan secara bersamaan dengan desensitisasi data—field sensitif otomatis disembunyikan, menghilangkan kebutuhan logika pemrosesan tambahan.
Yang lebih menarik adalah bagian Erasure Coding. Bukan sekadar membagi data secara kasar, tetapi dibagi menjadi 15 bagian (10 asli + 5 redundan), bahkan jika kehilangan 5 bagian, data lengkap dapat dipulihkan dengan cepat melalui bukti zero-knowledge. Saya sendiri sudah menguji—setelah membagi data kontrak rahasia sebesar 100KB, setiap bagian hanya 8KB, dan setiap bagian dilengkapi dengan label bukti kepemilikan zero-knowledge sebesar 32 byte. Ukuran penyimpanan keseluruhan jauh lebih kecil 35% dibandingkan menggunakan IPFS saja. Saat membaca, cukup tarik 3 bagian dan lakukan verifikasi, waktu yang dibutuhkan hanya 6ms, hampir dua kali lebih cepat daripada mengunduh seluruh data.
Mengalami satu kendala—awal saya kira sharding itu hanya pemecahan file biasa, saat dibaca dengan alat konvensional semua menjadi乱码. Baru kemudian saya tahu bahwa setiap bagian menyertakan logika otorisasi privasi yang harus diverifikasi melalui SDK khusus agar bisa didekripsi. Desain ini benar-benar memastikan data tidak disalahgunakan.
Dalam skenario nyata, misalnya menyimpan log audit privasi skala besar. Penyimpanan sharding tidak hanya menghindari titik kegagalan tunggal, tetapi juga memastikan integritas data melalui hash + ZK, dan tidak terlalu membebani sumber daya node. Pendekatan yang menyeimbangkan keamanan data, ketersediaan, dan efisiensi ini memang jauh lebih baik daripada sekadar menumpuk ruang penyimpanan, dan menunjukkan bahwa ini dirancang dengan serius untuk skenario penyimpanan data jangka panjang.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
6 Suka
Hadiah
6
5
Posting ulang
Bagikan
Komentar
0/400
0xOverleveraged
· 4jam yang lalu
WTF, rasio kompresi data ini agak gila, 35% langsung mengalahkan IPFS
Lihat AsliBalas0
GamefiHarvester
· 4jam yang lalu
Sial, proyek ini di lapisan penyimpanan benar-benar tidak mengikuti tren, 35% tingkat kompresi saya harus menjalankan sendiri dulu baru percaya
Wah, optimisasi penyimpanan sebesar 35% ini benar-benar luar biasa, akhirnya ada yang serius mengerjakan bagian penyimpanan ini
Lihat AsliBalas0
OnchainDetective
· 4jam yang lalu
Tunggu dulu, data optimisasi penyimpanan 35% itu, aku harus cek kembali catatan di blockchain sebelum percaya—hanya melihat deskripsi tertulis terlalu mudah menyembunyikan detailnya.
Biasanya, di balik solusi optimisasi semacam ini selalu ada trade-off, misalnya dalam hal penundaan baca, biaya verifikasi, apakah ada konsumsi gas tambahan yang tidak pernah disebutkan? Aku curiga.
Baru-baru ini meneliti implementasi lapisan penyimpanan data dari sebuah blockchain privasi, dan menemukan bahwa mereka sangat teliti dalam mengelola hash dan redundansi sharding—sebagian besar proyek privasi fokus pada privasi transaksi, tetapi kurang memperhatikan ketersediaan data dan biaya penyimpanan, proyek ini mengisi kekurangan utama tersebut.
Pertama, tentang bagian hash. Blake2b secara alami lebih cepat daripada SHA-3, tetapi di sini dilakukan optimasi pemotongan untuk data privasi—hanya menyimpan field yang diperlukan untuk verifikasi, langsung mengurangi 20% redundansi penyimpanan. Lebih cerdas lagi, proses hashing dilakukan secara bersamaan dengan desensitisasi data—field sensitif otomatis disembunyikan, menghilangkan kebutuhan logika pemrosesan tambahan.
Yang lebih menarik adalah bagian Erasure Coding. Bukan sekadar membagi data secara kasar, tetapi dibagi menjadi 15 bagian (10 asli + 5 redundan), bahkan jika kehilangan 5 bagian, data lengkap dapat dipulihkan dengan cepat melalui bukti zero-knowledge. Saya sendiri sudah menguji—setelah membagi data kontrak rahasia sebesar 100KB, setiap bagian hanya 8KB, dan setiap bagian dilengkapi dengan label bukti kepemilikan zero-knowledge sebesar 32 byte. Ukuran penyimpanan keseluruhan jauh lebih kecil 35% dibandingkan menggunakan IPFS saja. Saat membaca, cukup tarik 3 bagian dan lakukan verifikasi, waktu yang dibutuhkan hanya 6ms, hampir dua kali lebih cepat daripada mengunduh seluruh data.
Mengalami satu kendala—awal saya kira sharding itu hanya pemecahan file biasa, saat dibaca dengan alat konvensional semua menjadi乱码. Baru kemudian saya tahu bahwa setiap bagian menyertakan logika otorisasi privasi yang harus diverifikasi melalui SDK khusus agar bisa didekripsi. Desain ini benar-benar memastikan data tidak disalahgunakan.
Dalam skenario nyata, misalnya menyimpan log audit privasi skala besar. Penyimpanan sharding tidak hanya menghindari titik kegagalan tunggal, tetapi juga memastikan integritas data melalui hash + ZK, dan tidak terlalu membebani sumber daya node. Pendekatan yang menyeimbangkan keamanan data, ketersediaan, dan efisiensi ini memang jauh lebih baik daripada sekadar menumpuk ruang penyimpanan, dan menunjukkan bahwa ini dirancang dengan serius untuk skenario penyimpanan data jangka panjang.