State Sharding

Apa Itu State Sharding dalam Kripto?

State sharding adalah desain skalabilitas blockchain yang membagi state aktif jaringan menjadi bagian-bagian lebih kecil yang disebut shard, sehingga kelompok validator berbeda dapat memproses dan menyimpan bagian blockchain yang berbeda secara paralel.

Dalam kripto, state adalah catatan saat ini tentang akun, saldo, data smart contract, slot penyimpanan, informasi validator, dan nilai lain yang diperlukan untuk memproses transaksi baru.

Sharding berarti membagi sistem besar menjadi bagian-bagian lebih kecil sehingga seluruh jaringan tidak perlu menjalankan setiap tugas secara bersamaan.

Dokumentasi resmi skalabilitas Ethereum menjelaskan sharding sebagai proses membagi database sehingga subset validator dapat bertanggung jawab atas shard individual, alih-alih melacak semuanya.

State sharding menerapkan gagasan tersebut secara langsung pada state blockchain.

Alih-alih setiap validator menyimpan dan mengeksekusi seluruh state dari seluruh blockchain, setiap shard hanya dapat memelihara sebagian state.

Hal ini dapat meningkatkan throughput karena beberapa shard dapat memproses transaksi pada saat yang sama.

State sharding juga dapat mengurangi beban perangkat keras karena setiap node mungkin tidak perlu menyimpan seluruh state aktif.

Namun, state sharding sulit karena aplikasi blockchain sering perlu berinteraksi lintas shard.

Sederhananya, state sharding berupaya membuat blockchain lebih skalabel dengan membagi database aktif dan beban kerja eksekusinya ke banyak kelompok shard paralel.

Mengapa State Sharding Penting

State sharding penting karena blockchain smart contract dapat menjadi mahal untuk dijalankan seiring pertumbuhan penggunaan.

Setiap akun baru, saldo token, kontrak, NFT, posisi likuiditas, catatan governance, dan slot penyimpanan dapat meningkatkan jumlah state aktif yang harus dipelihara jaringan.

Jika setiap validator harus menyimpan dan mengeksekusi seluruh state selamanya, jaringan dapat menjadi lebih sulit diverifikasi secara mandiri oleh masyarakat umum.

Hal ini dapat melemahkan desentralisasi karena hanya operator besar yang mungkin mampu menjalankan full node.

State sharding berupaya menyelesaikan masalah ini dengan memungkinkan jaringan melakukan scaling horizontal.

Scaling horizontal berarti menambahkan lebih banyak kelompok validator dan shard, alih-alih memaksa setiap node menjadi lebih kuat.

Halaman resmi makalah NEAR menjelaskan Nightshade sebagai desain sharding ketika blockchain dibagi menjadi beberapa chain atau shard paralel untuk melakukan scaling horizontal sesuai permintaan.

Pendekatan ini menarik karena dapat meningkatkan kapasitas tanpa mengharuskan setiap node memproses setiap transaksi.

Oleh karena itu, state sharding bukan hanya peningkatan kecepatan.

State sharding juga merupakan strategi desentralisasi karena menjaga kebutuhan node tetap terkelola membantu lebih banyak peserta memverifikasi jaringan.

Cara Kerja State Sharding

Blockchain dengan state sharding membagi state global menjadi beberapa shard.

Setiap shard bertanggung jawab atas subset akun, kontrak, objek, atau entri state.

Validator dapat ditugaskan ke satu shard, beberapa shard, atau komite shard yang berotasi, bergantung pada desain protokol.

Transaksi yang hanya memengaruhi satu shard sering kali dapat diproses di dalam shard tersebut.

Transaksi yang memengaruhi beberapa shard memerlukan komunikasi cross-shard.

Koordinator, beacon chain, main chain, layer konsensus global, atau protokol komunikasi shard dapat membantu menjaga konsistensi sistem.

Jaringan harus memastikan tidak ada shard yang menerima transaksi tidak valid.

Jaringan juga harus memastikan tindakan cross-shard tidak menciptakan double spending, pesan yang hilang, atau state yang tidak konsisten.

Inilah sebabnya state sharding lebih kompleks daripada sekadar menjalankan banyak blockchain terpisah.

Chain dengan state sharding yang sebenarnya harus membuat banyak shard berperilaku sebagai satu sistem blockchain yang koheren.

State Sharding vs. Transaction Sharding

Transaction sharding membagi pemrosesan transaksi di antara kelompok yang berbeda.

State sharding membagi state blockchain sebenarnya di antara kelompok yang berbeda.

Sebuah sistem dapat melakukan sharding transaksi tanpa melakukan sharding state sepenuhnya apabila semua validator masih harus mengetahui seluruh state.

State sharding lebih mendalam karena setiap shard hanya menyimpan dan memperbarui sebagian database aktif.

Hal ini dapat memberikan manfaat skalabilitas yang lebih kuat, tetapi juga menciptakan tantangan koordinasi yang lebih besar.

Misalnya, pembayaran dari satu akun ke akun lain dalam shard yang sama dapat sederhana.

Pembayaran dari satu shard ke shard lain memerlukan sistem pesan atau receipt cross-shard yang aman.

Pemanggilan smart contract yang menyentuh kontrak pada dua shard mungkin memerlukan eksekusi asinkron, penguncian, receipt, atau aturan konsistensi lainnya.

Transaction sharding meningkatkan throughput dengan membagi pekerjaan.

State sharding meningkatkan throughput dan skalabilitas penyimpanan dengan membagi data yang menjadi dasar pekerjaan tersebut.

State Sharding vs. Data Sharding

State sharding berbeda dari data sharding.

State sharding membagi state eksekusi aktif sebuah blockchain.

Data sharding berfokus membuat data transaksi tersedia dalam bagian yang lebih kecil atau paralel agar sistem scaling dapat memublikasikan dan memverifikasi data dengan lebih murah.

Perbedaan ini penting karena roadmap scaling Ethereum modern berfokus pada data availability, bukan state sharding tradisional.

Dokumentasi resmi Ethereum danksharding menyatakan bahwa danksharding maupun proto-danksharding tidak mengikuti model sharding tradisional yang membagi blockchain menjadi banyak bagian.

Dokumentasi tersebut menjelaskan bahwa danksharding dirancang di sekitar data blob besar untuk rollup, alih-alih membagi Ethereum Mainnet menjadi execution shard tradisional.

Artinya, pengguna tidak boleh menganggap setiap penyebutan sharding Ethereum berarti state sharding.

Pembahasan roadmap Ethereum yang lebih lama mencakup gagasan execution sharding dan state sharding.

Scaling Ethereum modern menggunakan rollup, blob, riset data availability sampling, dan konsep danksharding, bukan model eksekusi banyak shard tradisional.

State sharding dan data sharding sama-sama merupakan gagasan scaling, tetapi menyelesaikan hambatan yang berbeda.

State Sharding vs. Rollup

Rollup menskalakan blockchain dengan mengeksekusi banyak transaksi di luar base layer dan memposting data atau proof kembali ke base layer.

State sharding menskalakan blockchain dengan membagi state dan eksekusi base layer ke berbagai shard.

Rollup dapat lebih mudah ditambahkan ke chain yang sudah ada karena tidak mengharuskan base layer membagi state eksekusinya sendiri.

State sharding merupakan perubahan arsitektur base layer yang lebih mendalam.

Rollup masih memerlukan data availability, settlement, dan verifikasi proof dari base chain.

Chain dengan state sharding memerlukan penugasan shard, komunikasi cross-shard, keamanan shard, dan finality bersama.

Dokumentasi resmi data availability Ethereum menjelaskan bahwa data availability penting karena rollup membutuhkan data transaksi yang tersedia agar pihak lain dapat memverifikasi atau merekonstruksi state rollup.

Inilah alasan roadmap Ethereum saat ini mendukung scaling rollup melalui data blob, bukan state sharding tradisional.

State sharding masih dapat digunakan oleh desain Layer 1 lainnya.

Perbedaan utamanya adalah rollup memisahkan eksekusi ke sistem Layer 2, sedangkan state sharding membagi eksekusi dan state di dalam Layer 1 itu sendiri.

Mengapa State Sharding Sulit

State sharding sulit karena blockchain harus tetap aman, konsisten, dan terdesentralisasi sambil membagi pekerjaan.

Jika sebuah shard memiliki terlalu sedikit validator, penyerang mungkin lebih mudah menargetkan shard tersebut.

Jika validator tidak ditugaskan secara acak dan aman, penyerang dapat memusatkan kekuatan pada satu shard.

Jika pesan cross-shard lambat, aplikasi dapat terasa terfragmentasi.

Jika pesan cross-shard tidak aman, pengguna dapat menghadapi risiko double spending atau state yang tidak konsisten.

Jika developer harus terus-menerus memikirkan lokasi shard, desain aplikasi menjadi lebih sulit.

Jika pengguna harus memahami shard secara manual, pengalaman pengguna menjadi lebih buruk.

Survei akademis Building Blocks of Sharding Blockchain Systems mengidentifikasi komponen sharding utama seperti pemilihan node, randomness, penugasan node, konsensus intra-shard, pemrosesan transaksi cross-shard, rekonfigurasi shard, dan mekanisme insentif.

Ini menunjukkan bahwa state sharding bukan satu fitur.

State sharding adalah arsitektur sistem lengkap dengan banyak bagian yang saling bergerak.

Shard

Shard adalah satu partisi state blockchain dan lingkungan eksekusi.

Setiap shard dapat memuat subset akun, kontrak, objek, penyimpanan, atau transaksi.

Dalam desain sederhana, akun dapat ditugaskan ke shard berdasarkan rentang alamat, nilai hash, atau lokasi akun eksplisit.

Dalam desain yang lebih lanjut, batas shard dapat berubah seiring waktu melalui resharding.

Shard seharusnya dapat memproses transaksi lokal tanpa meminta persetujuan dari setiap shard lain.

Pemrosesan paralel ini merupakan manfaat scaling utama.

Namun, shard tidak dapat sepenuhnya terisolasi jika pengguna dan aplikasi perlu berinteraksi di seluruh jaringan.

Desain sharding yang baik harus membuat shard cukup independen untuk performa, tetapi cukup terhubung untuk kegunaan.

Keseimbangan ini sulit karena terlalu banyak independensi memfragmentasi jaringan, sedangkan terlalu banyak koordinasi mengurangi manfaat scaling.

Oleh karena itu, shard merupakan unit scaling sekaligus tantangan koordinasi.

Validator Shard

Validator shard adalah validator yang ditugaskan untuk memeriksa, memproduksi, atau menyetujui aktivitas dalam shard tertentu.

Dalam beberapa desain, validator berotasi di berbagai shard untuk mengurangi risiko pengambilalihan shard jangka panjang.

Dalam desain lain, validator mungkin hanya melacak data shard tertentu atau menyediakan validasi stateless dengan witness.

Penugasan validator sangat penting karena setiap shard harus tetap aman meskipun hanya subset jaringan yang memvalidasinya secara langsung.

Jika penyerang dapat memprediksi atau memengaruhi penugasan validator, mereka mungkin berupaya mengendalikan satu shard.

Karena itu, randomness penting dalam banyak sistem sharding.

Insentif validator juga penting karena validator shard harus diberi reward atas partisipasi jujur dan dihukum atas perilaku tidak jujur.

State sharding tidak menghilangkan kebutuhan akan konsensus.

State sharding menciptakan banyak tanggung jawab konsensus yang lebih kecil, tetapi tetap harus terhubung dengan keamanan seluruh jaringan.

Keamanan chain dengan state sharding sangat bergantung pada cara validator ditugaskan, dirotasikan, dipantau, dan diamankan secara ekonomi.

Transaksi Cross-Shard

Transaksi cross-shard adalah transaksi yang memengaruhi state di lebih dari satu shard.

Transaksi cross-shard adalah salah satu bagian tersulit dari state sharding.

Transfer sederhana di dalam satu shard dapat diproses secara lokal.

Transfer dari akun pada satu shard ke akun pada shard lain harus dikoordinasikan antarshard.

Pemanggilan smart contract yang melibatkan beberapa shard dapat menjadi lebih kompleks.

Sistem harus memastikan shard sumber dan shard tujuan menyepakati apa yang terjadi.

Sistem juga harus memastikan dana tidak dibelanjakan dua kali dan efek kontrak terjadi dalam urutan yang benar.

Beberapa sistem menggunakan receipt asinkron, ketika satu shard mencatat tindakan keluar dan shard lain kemudian menerapkan hasil masuk.

Riset lain mengeksplorasi eksekusi cross-shard sinkron, two-phase commit, atau koordinasi berbasis proof.

Desain transaksi cross-shard sering menentukan apakah state sharding terasa lancar atau terfragmentasi bagi pengguna.

Eksekusi Asinkron

Eksekusi asinkron berarti tindakan lintas shard tidak terjadi secara instan dalam satu langkah global.

Sebaliknya, satu shard dapat membuat pesan atau receipt yang diproses shard lain kemudian.

Hal ini dapat meningkatkan skalabilitas karena shard tidak perlu berhenti dan mengoordinasikan setiap tindakan pada waktu yang sama.

Namun, eksekusi asinkron mengubah cara developer membangun aplikasi.

Kontrak mungkin tidak dapat memanggil shard lain dan menerima hasilnya secara langsung dalam transaksi yang sama.

Developer mungkin perlu merancang alur kerja berdasarkan callback, receipt, settlement tertunda, atau transisi state multi-langkah.

Hal ini dapat membuat DeFi, game, marketplace, dan aplikasi composable cross-shard lebih sulit.

Sharding asinkron sangat kuat, tetapi dapat melemahkan composability sederhana yang diharapkan pengguna dari lingkungan smart contract satu shard.

Trade-off-nya adalah kecepatan dan paralelisme versus kesederhanaan aplikasi sinkron.

Ekosistem state sharding yang baik memerlukan alat developer yang memudahkan penggunaan eksekusi asinkron secara aman.

Atomic Composability

Atomic composability berarti beberapa tindakan smart contract dapat terjadi bersama sebagai satu transaksi yang tidak dapat dibagi.

Jika satu bagian gagal, seluruh transaksi gagal.

Sistem smart contract satu shard sering membuat atomic composability lebih mudah karena seluruh state yang relevan tersedia dalam satu lingkungan eksekusi.

State sharding dapat membuat atomic composability lebih sulit ketika kontrak berada pada shard yang berbeda.

Trading DeFi mungkin perlu menyentuh protokol pinjaman, liquidity pool, oracle, dan vault dalam satu transaksi.

Jika kontrak tersebut berada pada shard berbeda, eksekusi sinkron mungkin sulit atau mahal.

Inilah salah satu alasan state sharding menciptakan tantangan desain bagi DeFi.

Beberapa sistem sharding dapat mendorong kontrak terkait untuk berada pada shard yang sama.

Sistem lain dapat menyediakan alat komunikasi cross-shard khusus.

Atomic composability adalah salah satu trade-off utama yang perlu dipahami pengguna dan developer saat mempelajari state sharding.

State Sharding dan Smart Contract

Smart contract membuat state sharding lebih sulit karena kontrak dapat bergantung pada state bersama.

Sistem pembayaran sederhana dapat menugaskan akun ke shard dan mengirim pesan di antaranya.

Ekosistem smart contract perlu menangani pemanggilan kontrak, pembacaan penyimpanan, penulisan penyimpanan, transfer token, persetujuan, likuidasi, swap, dan transaksi composable.

Jika setiap kontrak dapat memanggil setiap kontrak lain secara sinkron, jaringan dapat kehilangan sebagian besar manfaat sharding.

Jika pemanggilan cross-shard asinkron, developer memerlukan model pemrograman berbeda.

Inilah sebabnya platform smart contract dengan sharding harus merancang penempatan akun, deployment kontrak, penerusan pesan, dan alat developer secara cermat.

State sharding lebih mudah untuk transfer akun sederhana dibandingkan sistem DeFi yang sangat composable.

State sharding juga lebih mudah ketika aplikasi dapat dikelompokkan secara alami ke dalam shard.

Misalnya, lingkungan game atau lingkungan mirip appchain dapat menyimpan sebagian besar aktivitas dalam satu shard.

Aplikasi keuangan yang sangat saling terhubung mungkin memerlukan desain cross-shard yang lebih kompleks.

State Sharding dan NEAR

NEAR adalah salah satu contoh blockchain paling dikenal yang dirancang dengan sharding sebagai inti.

Dokumentasi resmi NEAR menyatakan bahwa sharding Nightshade memungkinkan scaling throughput linear seiring bertambahnya jumlah validator.

Nightshade adalah desain sharding NEAR.

Halaman makalah resmi NEAR menjelaskan Nightshade sebagai desain ketika state dan pemrosesan dibagi di antara shard dalam bentuk pembaruannya.

Arsitektur NEAR penting karena menunjukkan state sharding sebagai arah desain yang aktif, bukan hanya konsep riset.

NEAR juga telah mengembangkan validasi stateless, yang mengubah cara validator berpartisipasi dalam validasi shard.

Postingan resmi peluncuran NEAR Nightshade 2.0 menyatakan bahwa Nightshade 2.0 memperkenalkan validasi stateless ke NEAR Mainnet pada Agustus 2024.

Validasi stateless dapat mengurangi jumlah state yang perlu disimpan validator secara lokal untuk suatu shard.

Hal ini menunjukkan bagaimana state sharding dan validasi stateless dapat digabungkan untuk meningkatkan skalabilitas dan partisipasi node.

State Sharding dan Ethereum

Ethereum penting dalam sejarah state sharding karena roadmap scaling Ethereum awal banyak membahas sharding.

Namun, roadmap Ethereum saat ini tidak berfokus pada execution sharding atau state sharding tradisional untuk Mainnet.

Halaman resmi Ethereum tentang danksharding menyatakan bahwa proto-danksharding maupun danksharding tidak mengikuti model sharding tradisional.

Sebaliknya, Ethereum kini berfokus pada scaling rollup dengan menyediakan data availability yang lebih murah melalui blob dan danksharding di masa depan.

Perbedaan ini penting untuk SEO dan edukasi pengguna karena banyak artikel lama masih menggambarkan Ethereum sedang bergerak menuju shard chain tradisional.

Deskripsi lama tersebut dapat menyesatkan jika disajikan sebagai fakta roadmap saat ini.

Arah scaling Ethereum saat ini berpusat pada rollup.

Artinya, sistem Layer 2 menjalankan sebagian besar eksekusi, sedangkan Ethereum menyediakan settlement, keamanan, dan peningkatan data availability.

State sharding tetap merupakan konsep blockchain penting, tetapi tidak boleh digambarkan sebagai rencana eksekusi Mainnet Ethereum saat ini.

Untuk edukasi kripto yang akurat, Ethereum sebaiknya digunakan sebagai contoh bagaimana riset sharding berkembang, bukan sebagai penerapan state sharding saat ini.

State Sharding dan Validasi Stateless

Validasi stateless berarti validator dapat memverifikasi eksekusi blok atau shard tanpa menyimpan seluruh state relevan secara lokal.

Sebaliknya, validator menerima witness atau proof yang mencakup data state yang diperlukan untuk verifikasi.

Konsep ini dapat bekerja dengan state sharding karena validator mungkin tidak ingin menyimpan state setiap shard.

Konsep ini juga dapat membuat validasi shard lebih fleksibel karena validator dapat memverifikasi pekerjaan dengan kebutuhan penyimpanan lokal yang lebih kecil.

Nightshade 2.0 dari NEAR adalah contoh praktis validasi stateless yang ditambahkan ke arsitektur sharding.

Riset Ethereum juga mengeksplorasi stateless client dan witness yang lebih kecil melalui perubahan komitmen state.

Validasi stateless tidak sama dengan state sharding.

State sharding membagi state antarshard.

Validasi stateless mengurangi jumlah state yang harus disimpan validator untuk memverifikasi blok atau shard.

Bersama-sama, keduanya dapat membantu mengurangi kebutuhan perangkat keras node sambil mempertahankan verifikasi.

State Sharding dan Data Availability

Data availability adalah jaminan bahwa data yang diperlukan untuk memverifikasi atau merekonstruksi transisi state tersedia bagi jaringan.

State sharding tidak dapat aman jika validator tidak dapat mengakses data yang diperlukan untuk memverifikasi blok shard.

Produsen shard yang malicious dapat menyembunyikan data dan membuat pihak lain tidak dapat memeriksa apakah transisi state shard valid.

Inilah alasan data availability menjadi masalah inti dalam sistem sharding.

Blockchain dengan sharding mungkin memerlukan data availability sampling, erasure coding, komite, fraud proof, validity proof, atau mekanisme lain untuk mempersulit serangan penyembunyian data.

Dokumentasi data availability Ethereum menjelaskan bahwa data availability tidak sama dengan penyimpanan data karena berfokus pada apakah data telah cukup dipublikasikan untuk verifikasi.

Konsep ini berlaku luas bagi sistem scaling, termasuk rollup dan chain dengan sharding.

State sharding meningkatkan pentingnya data availability karena setiap shard dapat menghasilkan data yang perlu dipercaya oleh bagian lain jaringan.

Jika data shard tidak tersedia, pesan cross-shard dan konsensus global dapat menjadi tidak aman.

Desain state sharding yang kuat harus menyelesaikan pembagian eksekusi dan data availability.

State Sharding dan Keamanan

Keamanan dalam state sharding bergantung pada penugasan shard, kejujuran validator, randomness, proof cross-shard, finality, dan insentif.

Satu shard tidak boleh menjadi mudah dirusak hanya karena lebih sedikit validator yang ditugaskan kepadanya.

Hal ini kadang disebut masalah pengambilalihan satu shard.

Jika penyerang dapat mengendalikan satu shard, mereka mungkin mencoba membuat transaksi tidak valid, mencuri dana, atau merusak pesan cross-shard.

Protokol mengurangi risiko ini melalui penugasan validator acak, komite berotasi, slashing, keamanan bersama, fraud proof, validity proof, atau aturan finality global.

Keamanan juga harus menangani penyerang adaptif yang berupaya merusak validator setelah mengetahui penugasan shard mereka.

Rekonfigurasi shard harus dirancang dengan cermat karena pemindahan validator dan state antarshard dapat menciptakan celah serangan.

Transaksi cross-shard memerlukan sistem proof yang mencegah satu shard berbohong kepada shard lain.

State sharding dapat menskalakan jaringan, tetapi juga meningkatkan jumlah area tempat desain protokol dapat gagal.

Bagi pengguna, pertanyaan utamanya adalah apakah chain dengan sharding menjaga setiap shard tetap seaman yang diperlukan oleh seluruh jaringan.

State Sharding dan Desentralisasi

State sharding dapat mendukung desentralisasi dengan menurunkan beban sumber daya pada node individual.

Jika node tidak perlu menyimpan dan mengeksekusi seluruh state global, lebih banyak peserta mungkin dapat bergabung ke jaringan.

Hal ini dapat membantu menghindari masa depan ketika hanya pusat data besar yang dapat memverifikasi chain.

Namun, state sharding juga dapat menciptakan risiko desentralisasi jika hanya infrastruktur khusus yang dapat menangani koordinasi cross-shard.

Jika pengguna bergantung pada sejumlah kecil penyedia RPC untuk melacak semua shard, application layer dapat menjadi tersentralisasi.

Jika bridge atau router cross-shard menjadi titik hambatan, aktivitas ekonomi dapat terkonsentrasi di sekitar layanan tersebut.

Jika validator memerlukan infrastruktur kompleks untuk berpartisipasi, set validator tetap dapat menjadi tersentralisasi.

State sharding yang baik seharusnya mengurangi beban node individual tanpa menciptakan ketergantungan terpusat baru di tempat lain.

Desentralisasi harus diukur pada validator, full node, klien, penyedia RPC, bridge, wallet, dan infrastruktur aplikasi.

State sharding hanya membantu jika keseluruhan sistem tetap terbuka dan dapat diverifikasi.

State Sharding dan Pengalaman Pengguna

Idealnya, state sharding tidak terlihat oleh pengguna.

Pengguna seharusnya tidak perlu mengetahui shard mana yang menyimpan akunnya atau shard mana yang menyimpan smart contract.

Wallet seharusnya merutekan transaksi dengan benar tanpa mengharuskan pemilihan shard manual.

dApp harus menjelaskan penundaan atau langkah cross-shard dengan jelas saat terjadi.

Jika pengguna harus mengelola alamat shard, saldo gas shard, dan waktu cross-shard secara manual, adopsi dapat terganggu.

Transfer cross-shard dapat memerlukan waktu lebih lama daripada transfer dalam shard yang sama, bergantung pada desain protokol.

Interaksi smart contract cross-shard juga dapat memerlukan lebih banyak konfirmasi atau callback asinkron.

Antarmuka pengguna yang baik dapat menyembunyikan banyak kompleksitas ini.

Namun, pengguna tetap perlu memahami bahwa state sharding dapat memengaruhi waktu transaksi, composability, likuiditas, dan desain aplikasi.

Sistem dengan sharding terbaik terasa seperti satu chain, meskipun di bawahnya berjalan sebagai banyak lingkungan eksekusi paralel.

State Sharding dan Developer

Developer yang membangun di chain dengan state sharding harus memahami lokasi state aplikasi mereka.

Jika platform mengekspos batas shard, developer mungkin perlu memilih lokasi deployment kontrak.

Jika pemanggilan cross-shard asinkron, developer perlu merancang untuk hasil tertunda dan alur kerja parsial.

Jika pengguna dapat berasal dari shard berbeda, developer perlu menangani perutean pesan dan perpindahan saldo.

Jika likuiditas terbagi antarshard, aplikasi DeFi mungkin memerlukan perutean atau agregasi khusus.

Pengujian juga lebih kompleks karena developer harus menguji kasus dalam shard yang sama dan cross-shard.

Pemantauan dapat lebih sulit karena aktivitas aplikasi mungkin terjadi pada beberapa shard.

Tinjauan keamanan harus mencakup penanganan pesan cross-shard, perlindungan replay, logika callback, dan kondisi kegagalan.

State sharding memberikan kapasitas lebih besar kepada developer, tetapi juga dapat memerlukan arsitektur yang lebih cermat.

Platform developer terbaik menyediakan abstraksi yang menjadikan pemrograman yang sadar shard lebih aman dan lebih mudah.

State Sharding dan DeFi

DeFi sangat sensitif terhadap state sharding karena DeFi bergantung pada composability dan likuiditas bersama.

Swap dapat bergantung pada liquidity pool.

Likuidasi dapat bergantung pada oracle, pasar pinjaman, saldo jaminan, dan catatan utang.

Strategi yield dapat bergantung pada beberapa kontrak yang berinteraksi dalam satu transaksi.

Jika kontrak tersebut berada pada shard berbeda, eksekusi dapat menjadi asinkron atau lebih mahal.

Hal ini dapat mengurangi atomic composability.

Sistem DeFi dengan state sharding mungkin memerlukan perutean likuiditas, pesan cross-shard, liquidity pool khusus shard, atau pengelompokan aplikasi.

Beberapa aplikasi mungkin memilih untuk menyimpan semua kontrak inti dalam satu shard demi kesederhanaan.

Aplikasi lain dapat merancang alur kerja cross-shard native untuk menjangkau lebih banyak pengguna dan likuiditas.

State sharding dapat memperluas throughput total, tetapi developer DeFi harus mengelola risiko fragmentasi dengan cermat.

Bagi pengguna, perhatian utama adalah apakah DeFi cross-shard tetap aman, likuid, dan dapat diprediksi.

State Sharding dan NFT

NFT dapat memperoleh manfaat dari state sharding karena ekosistem NFT besar dapat menghasilkan banyak catatan kepemilikan, tautan metadata, listing marketplace, dan item game.

Sharding dapat mendistribusikan state ini ke beberapa shard.

Hal ini dapat mengurangi kemacetan ketika banyak pengguna berinteraksi dengan koleksi atau game yang berbeda secara bersamaan.

Namun, NFT juga menciptakan tantangan cross-shard.

NFT pada satu shard mungkin perlu dijual kepada pembeli pada shard lain.

Item game mungkin perlu berinteraksi dengan kontrak atau marketplace pada shard berbeda.

Wallet mungkin perlu menampilkan saldo NFT di berbagai shard.

Marketplace mungkin memerlukan sistem pengindeksan dan perutean yang memahami lokasi shard.

State sharding dapat mempermudah scaling NFT, tetapi juga dapat membuat penemuan, likuiditas, dan transfer lebih kompleks.

Infrastruktur wallet dan marketplace yang baik sangat penting untuk pengalaman NFT dengan sharding yang lancar.

State Sharding dan Bridge

State sharding dan bridge saling terkait karena komunikasi cross-shard dalam beberapa hal serupa dengan komunikasi cross-chain.

Pesan harus berpindah dari satu lingkungan state ke lingkungan state lain.

Lingkungan penerima harus mengetahui bahwa pesan tersebut valid.

Lingkungan pengirim harus mencegah penggunaan ganda atau replay.

Perbedaannya adalah shard biasanya merupakan bagian dari satu protokol bersama, sedangkan chain terpisah dapat memiliki asumsi keamanan independen.

Karena itu, pesan cross-shard dapat lebih aman daripada bridging biasa jika dibangun ke dalam protokol dasar dan diamankan oleh konsensus bersama.

Namun, sistem cross-shard yang dirancang buruk masih dapat menciptakan risiko serupa bridge.

Pengguna perlu memperhatikan apakah transfer cross-shard merupakan tindakan protokol native atau tindakan bridge tingkat aplikasi.

Pesan cross-shard native biasanya memiliki integrasi lebih kuat dengan aturan konsensus chain.

Bridge tingkat aplikasi dapat menambah risiko smart contract, validator, relayer, atau likuiditas.

State Sharding dan Resharding

Resharding adalah proses mengubah struktur shard dari waktu ke waktu.

Chain mungkin memerlukan resharding saat penggunaan meningkat, beberapa shard menjadi terlalu sibuk, atau distribusi state menjadi tidak merata.

Shard statis dapat menjadi tidak efisien jika satu shard menerima sebagian besar aktivitas sementara shard lain kurang digunakan.

Resharding dinamis berupaya menyesuaikan batas shard atau jumlah shard berdasarkan permintaan.

Hal ini dapat meningkatkan penggunaan sumber daya, tetapi menambah kompleksitas.

Pemindahan state antarshard harus aman dan konsisten.

Aplikasi harus tetap berfungsi saat penugasan shard berubah.

Validator dan indexer harus melacak tata letak baru dengan benar.

Wallet dan dApp tidak boleh rusak saat resharding terjadi.

Resharding menunjukkan bahwa state sharding bukan hanya tentang membagi state sekali, tetapi juga tentang mengelola state sepanjang masa hidup jaringan.

Manfaat State Sharding

Manfaat pertama state sharding adalah throughput yang lebih tinggi.

Beberapa shard dapat memproses transaksi secara paralel, alih-alih memaksa seluruh aktivitas melalui satu pipeline eksekusi.

Manfaat kedua adalah skalabilitas penyimpanan yang lebih baik.

Node mungkin tidak perlu menyimpan setiap bagian state global.

Manfaat ketiga adalah scaling horizontal yang lebih baik.

Jaringan dapat menambah kapasitas dengan menambahkan shard atau sumber daya validator, bukan hanya meningkatkan kebutuhan perangkat keras node.

Manfaat keempat adalah berkurangnya kemacetan bagi aplikasi yang dapat beroperasi terutama dalam satu shard.

Manfaat kelima adalah jalur menuju partisipasi yang lebih luas jika kebutuhan validator dan node tetap terkelola.

Manfaat keenam adalah spesialisasi yang lebih baik karena berbagai shard dapat melayani cluster aplikasi atau beban kerja berbeda, bergantung pada desain.

Manfaat tersebut menjadi alasan state sharding tetap merupakan konsep scaling penting.

Manfaat paling kuat ketika komunikasi cross-shard aman, cepat, dan mudah bagi pengguna serta developer.

Risiko dan Keterbatasan State Sharding

Risiko pertama adalah kompleksitas cross-shard.

Aplikasi yang memerlukan state dari beberapa shard dapat menjadi lebih sulit dibangun dan digunakan.

Risiko kedua adalah fragmentasi keamanan.

Setiap shard harus dilindungi dari serangan meskipun hanya sebagian set validator yang memvalidasinya secara langsung.

Risiko ketiga adalah fragmentasi likuiditas.

Aset dan pasar dapat terbagi antarshard, sehingga harga dan eksekusi menjadi kurang efisien.

Risiko keempat adalah atomic composability yang lebih lemah.

Transaksi yang sederhana dalam satu state bersama mungkin memerlukan desain asinkron antarshard.

Risiko kelima adalah kebingungan pengguna.

Pengguna mungkin tidak memahami penundaan cross-shard, perutean, atau pesan yang gagal.

Risiko keenam adalah kompleksitas infrastruktur.

Penyedia RPC, indexer, wallet, explorer, dan bridge harus melacak banyak shard dengan benar.

Risiko ketujuh adalah beban yang tidak merata.

Beberapa shard dapat mengalami kemacetan, sementara shard lain memiliki kapasitas kosong.

State sharding sangat kuat, tetapi bukan solusi scaling tanpa biaya.

Kesalahpahaman Umum tentang State Sharding

Salah satu kesalahpahaman umum adalah bahwa state sharding hanya berarti transaksi lebih cepat.

Pada kenyataannya, state sharding adalah arsitektur kompleks yang membagi tanggung jawab state, eksekusi, validasi, dan komunikasi.

Kesalahpahaman lainnya adalah bahwa state sharding sama dengan rollup.

Rollup memindahkan eksekusi ke sistem Layer 2, sedangkan state sharding membagi state dan eksekusi base layer itu sendiri.

Kesalahpahaman ketiga adalah bahwa roadmap Ethereum saat ini adalah state sharding tradisional.

Roadmap Ethereum saat ini berfokus pada rollup, blob, dan data availability bergaya danksharding, bukan shard chain execution-state tradisional.

Kesalahpahaman keempat adalah bahwa state sharding secara otomatis mempertahankan composability.

Composability cross-shard adalah salah satu bagian tersulit dari desain ini.

Kesalahpahaman kelima adalah bahwa chain dengan sharding hanyalah banyak chain terpisah.

Blockchain dengan sharding yang sebenarnya memerlukan keamanan bersama, finality bersama, dan komunikasi native antarshard.

Cara Mengevaluasi Blockchain dengan State Sharding

Mulailah dengan memeriksa apakah chain benar-benar melakukan sharding state atau hanya melakukan sharding data atau transaksi.

Kemudian, periksa cara validator ditugaskan ke shard.

Tinjau apakah penugasan validator menggunakan randomness yang kuat.

Periksa cara transaksi cross-shard diproses.

Tinjau apakah eksekusi cross-shard sinkron atau asinkron.

Periksa apakah aplikasi dapat mempertahankan atomic composability antarshard.

Tinjau cara protokol menangani data availability untuk blok shard.

Periksa apakah jaringan mendukung resharding dinamis atau shard tetap.

Tinjau pengalaman pengguna untuk transfer cross-shard.

Pelajari apakah wallet, explorer, penyedia RPC, dan indexer mendukung semua shard secara andal.

Blockchain dengan state sharding harus dinilai berdasarkan keamanan, kegunaan, pengalaman developer, dan throughput nyata dalam kondisi cross-shard.

Praktik Terbaik untuk Pengguna

Pahami apakah jaringan yang Anda gunakan memiliki alamat khusus shard, saldo gas, atau penundaan transfer.

Gunakan wallet yang menangani perutean shard secara otomatis jika memungkinkan.

Mulailah dengan transfer uji bernilai kecil sebelum memindahkan nilai yang berarti antarshard.

Periksa apakah aplikasi beroperasi dalam satu shard atau di berbagai shard.

Berhati-hatilah saat menggunakan bridge atau router yang bukan native dari protokol sharding.

Perhatikan kemungkinan penundaan tambahan saat dana berpindah antarshard.

Jangan menganggap transaksi telah final di semua shard sampai protokol atau wallet mengonfirmasinya.

Tinjau dokumentasi aplikasi saat menggunakan pasar DeFi atau NFT cross-shard.

Simpan token native yang cukup untuk biaya jika jaringan memerlukan pembayaran biaya khusus shard.

Perlakukan state sharding sebagai infrastruktur yang dapat meningkatkan performa, tetapi tidak menghilangkan risiko smart contract atau risiko pasar.

Praktik Terbaik untuk Developer

Rancang aplikasi dengan mempertimbangkan lokasi shard dan perilaku cross-shard.

Hindari pemanggilan cross-shard yang tidak diperlukan ketika desain dalam shard yang sama memungkinkan.

Gunakan pola asinkron secara aman apabila protokol mengharuskan eksekusi cross-shard asinkron.

Lindungi pesan cross-shard dari replay, bug pengurutan, dan logika callback yang gagal.

Uji alur transaksi dalam shard yang sama dan cross-shard secara terpisah.

Pantau fragmentasi likuiditas jika aplikasi bergantung pada pasar token.

Jelaskan penundaan cross-shard secara jelas dalam antarmuka pengguna.

Gunakan SDK dan dokumentasi protokol resmi untuk penerusan pesan dan perutean shard.

Rencanakan resharding jika jaringan mendukung perubahan shard dinamis.

Perlakukan eksekusi cross-shard sebagai bagian desain aplikasi yang sensitif terhadap keamanan.

FAQ

Apa arti state sharding?

State sharding berarti membagi state aktif blockchain menjadi beberapa shard agar kelompok validator berbeda dapat memproses dan menyimpan bagian yang berbeda secara paralel.

Apa itu shard?

Shard adalah satu partisi state blockchain dan beban kerja eksekusinya.

Mengapa blockchain menggunakan state sharding?

Blockchain menggunakan state sharding untuk meningkatkan throughput, mengurangi beban penyimpanan per node, dan menskalakan eksekusi di berbagai kelompok shard paralel.

Apakah state sharding sama dengan data sharding?

Tidak, state sharding membagi state eksekusi aktif, sedangkan data sharding berfokus menyediakan data transaksi dalam bagian yang skalabel.

Apakah state sharding sama dengan rollup?

Tidak, rollup mengeksekusi transaksi di luar base layer, sedangkan state sharding membagi state dan eksekusi base layer itu sendiri.

Apakah Ethereum saat ini menggunakan state sharding?

Tidak, roadmap Ethereum saat ini berfokus pada rollup, blob, dan data availability bergaya danksharding, bukan execution sharding atau state sharding tradisional.

Blockchain mana yang dikenal menggunakan state sharding?

NEAR dikenal luas melalui desain sharding Nightshade, yang membagi state dan pemrosesan di antara shard.

Apa itu transaksi cross-shard?

Transaksi cross-shard adalah transaksi yang memengaruhi state di lebih dari satu shard dan memerlukan komunikasi antarshard.

Mengapa state sharding sulit bagi DeFi?

State sharding sulit bagi DeFi karena DeFi sering bergantung pada atomic composability, likuiditas bersama, dan interaksi multi-kontrak dalam satu state terpadu.

Apakah state sharding membuat blockchain bebas risiko?

Tidak, state sharding dapat meningkatkan skalabilitas, tetapi tetap memiliki risiko seperti bug cross-shard, fragmentasi keamanan, fragmentasi likuiditas, dan kompleksitas infrastruktur.

Kesimpulan

State sharding adalah metode scaling blockchain yang membagi state aktif dan eksekusi ke beberapa shard.

Tujuan utamanya adalah meningkatkan throughput dan mengurangi beban pada validator atau node individual.

State sharding berbeda dari data sharding karena membagi state eksekusi sebenarnya, bukan hanya meningkatkan data availability.

State sharding juga berbeda dari rollup karena mengubah arsitektur base layer, bukan memindahkan eksekusi ke lingkungan Layer 2 terpisah.

State sharding dapat membuat blockchain lebih skalabel, tetapi juga menimbulkan masalah sulit terkait transaksi cross-shard, penugasan validator, data availability, atomic composability, fragmentasi likuiditas, dan pengalaman pengguna.

Desain Nightshade NEAR adalah contoh penting riset sharding yang menjadi infrastruktur produksi.

Ethereum penting secara historis, tetapi roadmap saat ini menggunakan scaling berpusat pada rollup dan data availability bergaya danksharding, bukan state sharding tradisional.

Bagi pengguna, state sharding dapat berarti aktivitas blockchain yang lebih cepat dan murah ketika dukungan wallet dan aplikasi kuat.

Bagi developer, state sharding berarti arsitektur aplikasi harus memperhitungkan lokasi shard, pesan cross-shard, eksekusi asinkron, dan kasus tepi keamanan.

Bagi jaringan, state sharding adalah cara mengejar scaling horizontal sambil berupaya mempertahankan desentralisasi.

Dalam konteks glosarium kripto, State Sharding berarti membagi state aktif blockchain ke shard paralel agar jaringan dapat memproses dan menyimpan lebih banyak aktivitas tanpa mengharuskan setiap validator menangani semuanya.

Poin utamanya adalah bahwa state sharding dapat meningkatkan skalabilitas secara signifikan, tetapi hanya jika protokol menyelesaikan komunikasi cross-shard, keamanan bersama, data availability, dan kegunaan developer tanpa melemahkan model kepercayaan blockchain.