Hai, saya salah satu pengembang dari blockchain Near Protocol, dan dalam artikel ini ingin berbicara tentang apa yang dimaksud dengan sharding blockchain, bagaimana penerapannya, dan masalah apa yang ada dalam desain sharding blockchain.
Diketahui bahwa Ethereum, blockchain tujuan umum yang paling banyak digunakan pada saat penulisan ini, hanya dapat memproses kurang dari 20 transaksi per detik pada rantai utama. Keterbatasan ini, ditambah dengan popularitas jaringan, menyebabkan harga gas yang tinggi (biaya melakukan transaksi di jaringan) dan waktu konfirmasi yang lama; Terlepas dari kenyataan bahwa pada saat penulisan ini, sebuah blok baru diproduksi kira-kira setiap 10-20 detik, waktu rata-rata yang dibutuhkan untuk sebuah transaksi untuk ditambahkan ke blockchain adalah 1,2 menit, menurut ETH Gas Station . Throughput rendah, harga tinggi, dan latensi tinggi semuanya membuat Ethereum tidak cocok untuk menjalankan layanan yang perlu ditingkatkan dengan adopsi.
Apa alasan utama untuk throughput rendah Ethereum? Alasannya adalah bahwa setiap node dalam jaringan perlu memproses setiap transaksi. Pengembang telah mengusulkan banyak solusi untuk mengatasi masalah throughput pada tingkat protokol. Solusi ini sebagian besar dapat dipisahkan menjadi orang-orang yang mendelegasikan semua perhitungan ke satu set kecil node yang kuat, dan orang-orang yang memiliki masing-masing node dalam jaringan hanya melakukan sebagian dari jumlah total pekerjaan. Kasus ekstrem dari pendekatan sebelumnya adalah Thunder yang memiliki satu simpul tunggal yang memproses semua transaksi dan klaim untuk mencapai 1200 tx / detik, peningkatan 100x dari Ethereum (saya tidak, bagaimanapun, mendukung Thunder, atau membuktikan validitas klaim mereka. ) Algorand , SpaceMesh , Solana semuanya masuk ke dalam kategori sebelumnya, membangun berbagai peningkatan dalam konsensus dan struktur blockchain itu sendiri untuk menjalankan lebih banyak transaksi secara signifikan, tetapi masih terikat oleh apa yang dapat diproses oleh satu mesin (walaupun sangat kuat).
Pendekatan yang terakhir, di mana pekerjaan dibagi di antara semua node yang berpartisipasi, disebut sharding. Ini adalah bagaimana Yayasan Ethereum saat ini merencanakan untuk mengukur Ethereum. Pada saat penulisan ini, spesifikasi lengkapnya masih belum dipublikasikan. Berikut ini tautan ke ikhtisar terperinci tentang rantai pecahan Ethereum dan rantai Beacon .
Dalam posting ini saya merangkum ide-ide inti dari sharding blockchain, yang menjadi dasar dari dekat dan mayoritas dari protokol sharded lainnya. Posting selanjutnya akan menguraikan topik lebih lanjut dalam sharding.
Sharding paling sederhana, alias beanstalk
Mari kita mulai dengan pendekatan paling sederhana untuk sharding, bahwa kita sepanjang tulisan ini akan memanggil Beanstalk. Ini juga yang oleh Vitalik disebut “scaling by a seribu altcoin” dalam presentasi ini .
Dalam pendekatan ini alih-alih menjalankan satu blockchain, kami akan menjalankan banyak blockchain, dan menyebut masing-masing blockchain tersebut sebagai "shard". Setiap pecahan akan memiliki set validator sendiri. Di sini dan di bawah ini kami menggunakan istilah umum "validator" untuk merujuk kepada peserta yang memverifikasi transaksi dan menghasilkan blok, baik dengan menambang, seperti dalam Bukti Kerja, atau melalui mekanisme berbasis suara. Untuk sekarang mari kita asumsikan bahwa pecahan tidak pernah berkomunikasi satu sama lain.
Desain Beanstalk, meskipun sederhana, cukup untuk menguraikan beberapa tantangan utama dalam sharding.
Partisi Validator dan rantai suar
Tantangan pertama adalah bahwa dengan setiap beling memiliki validator sendiri, setiap beling sekarang 10 kali lebih aman daripada seluruh rantai. Jadi, jika rantai non-beling dengan validator X memutuskan untuk melakukan hard-fork menjadi rantai beling, dan memecah validator X menjadi 10 beling, setiap beling sekarang hanya memiliki validator X / 10, dan merusak satu beling hanya membutuhkan kerusakan 5,1% (51%) / 10) dari jumlah total validator.
Yang membawa kita ke poin kedua: siapa yang memilih validator untuk setiap pecahan? Mengontrol 5,1% validator hanya merusak jika semua 5,1% validator itu berada di beling yang sama. Jika validator tidak dapat memilih beling mana yang akan divalidasi, peserta yang menguasai 5,1% validator sangat tidak mungkin mendapatkan semua validator mereka di beling yang sama, sangat mengurangi kemampuan mereka untuk mengkompromikan sistem.
Hampir semua desain pecahan saat ini bergantung pada beberapa sumber keacakan untuk menetapkan validator ke pecahan. Keacakan pada blockchain pada dirinya sendiri adalah topik yang sangat menantang dan pantas mendapatkan posting blog terpisah di kemudian hari, tetapi untuk sekarang mari kita asumsikan ada beberapa sumber keacakan yang bisa kita gunakan.
Pengacakan dan pengesahan validator memerlukan komputasi yang tidak spesifik untuk pecahan tertentu. Untuk perhitungan itu, praktis semua desain yang ada memiliki blockchain terpisah yang ditugaskan untuk melakukan operasi yang diperlukan untuk pemeliharaan seluruh jaringan. Selain menghasilkan angka acak dan menugaskan validator ke pecahan, operasi ini sering juga termasuk menerima pembaruan dari pecahan dan mengambil snapshot dari mereka, memproses taruhan dan menebas dalam sistem Proof-of-Stake, dan menyeimbangkan pecahan ketika fitur itu didukung. Rantai seperti itu disebut rantai Beacon di Ethereum dan Near, rantai Relay di PolkaDot, dan Cosmos Hub di Cosmos.
Sepanjang posting ini kita akan merujuk ke rantai seperti rantai Beacon . Keberadaan rantai Beacon membawa kita ke topik menarik berikutnya, pecahan kuadratik.
Sharding kuadratik
Sharding sering diiklankan sebagai solusi yang berskala tak terbatas dengan jumlah node yang berpartisipasi dalam operasi jaringan. Meskipun secara teori dimungkinkan untuk merancang solusi beling seperti itu, solusi apa pun yang memiliki konsep rantai Beacon tidak memiliki skalabilitas tak terbatas. Untuk memahami alasannya, perhatikan bahwa rantai Beacon harus melakukan perhitungan pembukuan, seperti menetapkan validator ke pecahan, atau blok rantai pecahan snapshotting, yang proporsional dengan jumlah pecahan dalam sistem. Karena rantai Beacon itu sendiri merupakan blockchain tunggal, dengan perhitungan yang dibatasi oleh kemampuan komputasi dari simpul yang mengoperasikannya, jumlah pecahan secara alami terbatas.
Namun, struktur jaringan yang terbagi tidak memberikan efek multiplikasi pada setiap perbaikan pada node-nya. Pertimbangkan kasus di mana peningkatan sewenang-wenang dibuat untuk efisiensi node dalam jaringan yang akan memungkinkan mereka waktu pemrosesan transaksi lebih cepat.
Jika node yang mengoperasikan jaringan, termasuk node dalam rantai Beacon, menjadi empat kali lebih cepat, maka setiap pecahan akan dapat memproses empat kali lebih banyak transaksi, dan rantai Beacon akan dapat mempertahankan pecahan 4 kali lebih banyak. Throughput di seluruh sistem akan meningkat dengan faktor 4 x 4 = 16 - demikian nama sharding kuadratik .
Sulit untuk memberikan pengukuran yang akurat untuk berapa banyak pecahan yang dapat hidup hari ini, tetapi tidak mungkin bahwa di masa mendatang, kebutuhan throughput dari pengguna blockchain akan melampaui batasan sharding kuadratik. Banyaknya jumlah node yang diperlukan untuk mengoperasikan volume pecahan dengan aman adalah urutan besarnya lebih tinggi dari jumlah node yang mengoperasikan semua blockchain yang digabungkan hari ini.
Namun, jika kita ingin membangun protokol bukti di masa depan, mungkin ada baiknya mulai meneliti solusi untuk masalah ini hari ini. Usulan yang paling berkembang saat ini adalah pecahan eksponensial, di mana pecahan itu sendiri membentuk pohon, dan setiap pecahan induk mengatur serangkaian pecahan anak, sementara itu sendiri dapat menjadi anak dari pecahan lain.
Vlad Zamfir dari Ethereum Foundation diketahui bekerja pada desain sharding yang tidak melibatkan rantai suar; Saya bekerja dengannya di salah satu prototipe, gambaran terperinci yang ada di sini .
Sharding negara
Hingga saat ini kami belum mendefinisikan dengan baik apa sebenarnya dan tidak terpisah ketika jaringan dibagi menjadi pecahan. Secara khusus, node dalam blockchain melakukan tiga tugas penting: mereka tidak hanya 1) memproses transaksi, mereka juga 2) menyampaikan transaksi yang divalidasi dan menyelesaikan blok ke node lain dan 3) menyimpan status dan sejarah dari seluruh buku besar jaringan. Masing-masing dari tiga tugas ini memberlakukan persyaratan yang meningkat pada node yang mengoperasikan jaringan:
- Kebutuhan untuk memproses transaksi membutuhkan daya komputasi yang lebih besar dengan meningkatnya jumlah transaksi yang diproses;
- Kebutuhan untuk menyampaikan transaksi dan memblokir memerlukan lebih banyak bandwidth jaringan dengan meningkatnya jumlah transaksi yang disampaikan;
- Kebutuhan untuk menyimpan data membutuhkan lebih banyak penyimpanan saat negara tumbuh. Yang penting, tidak seperti kekuatan pemrosesan dan jaringan, persyaratan penyimpanan tumbuh bahkan jika laju transaksi (jumlah transaksi yang diproses per detik) tetap konstan.
Dari daftar di atas, mungkin tampak bahwa persyaratan penyimpanan akan menjadi yang paling mendesak, karena itu adalah satu-satunya yang meningkat dari waktu ke waktu bahkan jika jumlah transaksi per detik tidak berubah, tetapi dalam praktiknya persyaratan yang paling mendesak saat ini adalah kekuatan komputasi. Seluruh keadaan Ethereum pada tulisan ini adalah 100GB, mudah dikelola oleh sebagian besar node. Tetapi jumlah transaksi yang dapat diproses oleh Ethereum adalah sekitar 20, pesanan besarnya kurang dari apa yang dibutuhkan untuk banyak kasus penggunaan praktis.
Zilliqa adalah proyek paling terkenal yang pecahan pemrosesan tetapi tidak penyimpanan. Proses pecahan adalah masalah yang lebih mudah karena setiap node memiliki seluruh status, yang berarti bahwa kontrak dapat dengan bebas meminta kontrak lain dan membaca data apa pun dari blockchain. Beberapa rekayasa yang cermat diperlukan untuk memastikan pembaruan dari beberapa pecahan memperbarui bagian yang sama dari negara tidak bertentangan. Dalam hal itu Zilliqa mengambil pendekatan yang sangat sederhana, kritik yang dapat ditemukan di posting ini .
Sementara pecahan penyimpanan tanpa pecahan pemrosesan diusulkan, saya tidak mengetahui adanya proyek yang mengerjakannya. Jadi dalam prakteknya sharding of storage, atau State Sharding, hampir selalu menyiratkan sharding dari pemrosesan dan sharding dari jaringan.
Secara praktis, di bawah State Sharding, node di setiap shard sedang membangun blockchain mereka sendiri yang berisi transaksi yang hanya memengaruhi bagian lokal dari negara global yang ditugaskan ke shard itu. Oleh karena itu, validator di beling hanya perlu menyimpan bagian lokal mereka dari negara global dan hanya mengeksekusi, dan dengan demikian hanya menyampaikan, transaksi yang mempengaruhi bagian negara mereka. Partisi ini secara linear mengurangi persyaratan pada semua daya komputasi, penyimpanan, dan bandwidth jaringan, tetapi memperkenalkan masalah baru, seperti ketersediaan data dan transaksi lintas-beling, yang keduanya akan kita bahas di bawah ini.
Transaksi lintas-beling
Beanstalk sebagai model bukanlah pendekatan yang sangat berguna untuk sharding, karena jika pecahan individu tidak dapat berkomunikasi satu sama lain, mereka tidak lebih baik daripada beberapa blockchains independen. Bahkan hari ini, ketika sharding tidak tersedia, ada permintaan besar untuk interoperabilitas antara berbagai blockchain.
Mari kita sekarang hanya mempertimbangkan transaksi pembayaran sederhana, di mana setiap peserta memiliki akun tepat pada satu pecahan. Jika seseorang ingin mentransfer uang dari satu akun ke akun lain dalam shard yang sama, transaksi dapat diproses sepenuhnya oleh validator dalam shard itu. Namun, jika Alice yang berada di shard # 1 ingin mengirim uang kepada Bob yang tinggal di shard # 2, tidak ada validator on shard # 1 (mereka tidak akan bisa mengkredit akun Bob) maupun validator on shard # 2 ( mereka tidak akan dapat mendebit akun Alice) dapat memproses seluruh transaksi.
Ada dua keluarga pendekatan untuk transaksi cross-shard:
- Sinkron : setiap kali transaksi lintas-beling perlu dijalankan, blok-blok dalam banyak pecahan yang berisi transisi keadaan terkait dengan transaksi semua diproduksi pada waktu yang sama, dan validator dari beberapa pecahan berkolaborasi dalam mengeksekusi transaksi tersebut. Proposal paling rinci yang saya kenal adalah Gabung Blok, dijelaskan di sini .
- Asynchronous : transaksi lintas-beling yang mempengaruhi banyak beling dieksekusi di beling-beling itu secara serempak, beling "Kredit" mengeksekusi setengahnya setelah memiliki bukti yang cukup bahwa beling "Debit" telah mengeksekusi bagiannya. Pendekatan ini cenderung lebih lazim karena kesederhanaan dan kemudahan koordinasi. Sistem ini hari ini diusulkan di Cosmos, Ethereum Serenity, Near, Kadena, dan lainnya. Masalah dengan pendekatan ini terletak pada bahwa jika blok diproduksi secara independen, ada kemungkinan bukan nol bahwa salah satu dari beberapa blok akan menjadi yatim, sehingga membuat transaksi hanya diterapkan sebagian. Perhatikan gambar di bawah ini yang menggambarkan dua pecahan yang keduanya bertemu dengan garpu, dan transaksi lintas-beling yang dicatat dalam blok A dan X 'secara bersamaan. Jika rantai AB dan V'-X'-Y'-Z 'berakhir menjadi kanonik di pecahan yang sesuai, transaksi sepenuhnya diselesaikan. Jika A'-B'-C'-D 'dan VX menjadi kanonik, maka transaksi sepenuhnya ditinggalkan, yang dapat diterima. Tetapi jika, misalnya, AB dan VX menjadi kanonik, maka satu bagian dari transaksi diselesaikan dan satu ditinggalkan, menciptakan kegagalan atomisitas. Kami akan membahas bagaimana masalah ini dibahas dalam protokol yang diusulkan di bagian kedua, ketika membahas perubahan pada aturan pilihan garpu dan algoritma konsensus yang diusulkan untuk protokol yang terbuang.
Perhatikan bahwa komunikasi antar rantai juga berguna di luar blokir berjumbai. Interoperabilitas antar rantai adalah masalah kompleks yang coba dipecahkan oleh banyak proyek. Dalam blockchains berjuntai, masalahnya agak lebih mudah karena struktur blok dan konsensus adalah sama di seluruh pecahan, dan ada rantai suar yang dapat digunakan untuk koordinasi. Namun, dalam blockchain yang terbelok, semua rantai beling adalah sama, sementara di ekosistem blockchains global ada banyak blockchain yang berbeda, dengan kasus penggunaan target yang berbeda, desentralisasi dan jaminan privasi.
Membangun sebuah sistem di mana satu set rantai memiliki sifat yang berbeda tetapi menggunakan konsensus dan struktur blok yang cukup mirip dan memiliki rantai suar yang sama dapat memungkinkan ekosistem dari blockchains heterogen yang memiliki subsistem interoperabilitas yang berfungsi. Sistem seperti itu tidak mungkin menampilkan rotasi validator, sehingga beberapa tindakan tambahan perlu diambil untuk memastikan keamanan. Baik Cosmos maupun PolkaDot adalah sistem yang efektif. Tulisan ini oleh Zaki Manian dari Cosmos memberikan tinjauan rinci dan perbandingan aspek-aspek kunci dari kedua proyek.
Perilaku berbahaya
Anda sekarang memiliki pemahaman yang baik tentang bagaimana sharding diimplementasikan, termasuk konsep rantai suar, rotasi validator, dan transaksi lintas-beling.
Dengan semua informasi itu, ada satu hal penting terakhir yang perlu dipertimbangkan. Secara khusus, perilaku permusuhan apa yang dapat dilakukan oleh validator jahat.
Fork berbahaya
Serangkaian validator jahat mungkin berupaya membuat garpu. Perhatikan bahwa tidak masalah apakah konsensus yang mendasari adalah BFT atau tidak, merusak cukup jumlah validator akan selalu memungkinkan untuk membuat garpu.
Secara signifikan lebih besar kemungkinannya bahwa lebih dari 50% pecahan tunggal rusak, daripada lebih dari 50% dari seluruh jaringan menjadi rusak (kami akan menyelami lebih dalam probabilitas ini di bagian kedua). Seperti dibahas di atas, transaksi lintas-beling melibatkan perubahan negara tertentu dalam beberapa pecahan, dan blok yang sesuai dalam pecahan tersebut yang menerapkan perubahan keadaan tersebut harus diselesaikan, misalnya muncul di rantai yang dipilih pada pecahan yang sesuai), atau semua menjadi yatim piatu. (Yaitu tidak muncul dalam rantai yang dipilih pada pecahan yang sesuai). Karena umumnya kemungkinan pecahan korup tidak dapat diabaikan, kita tidak dapat mengasumsikan bahwa percabangan tidak akan terjadi bahkan jika konsensus Bizantium tercapai di antara validator beling, atau banyak blok diproduksi di atas blok dengan perubahan negara .
Masalah ini memiliki beberapa solusi, yang paling umum adalah cross-linking sesekali dari blok rantai beling terbaru ke rantai suar. Aturan pilihan garpu di rantai beling kemudian diubah untuk selalu lebih memilih rantai yang terkait silang, dan hanya menerapkan aturan pilihan garpu khusus untuk blok yang diterbitkan sejak cross-link terakhir.
Menyetujui blok yang tidak valid
Serangkaian validator mungkin mencoba membuat blok yang salah menerapkan fungsi transisi negara. Misalnya, dimulai dengan keadaan di mana Alice memiliki 10 token dan Bob memiliki 0 token, blok mungkin berisi transaksi yang mengirim 10 token dari Alice ke Bob, tetapi berakhir dengan keadaan di mana Alice memiliki 0 token dan Bob memiliki 1000 token token.
Dalam blockchain non-sharded klasik serangan seperti itu tidak mungkin, karena semua peserta dalam jaringan memvalidasi semua blok, dan blok dengan transisi negara yang tidak valid akan ditolak oleh kedua produsen blok lain, dan peserta jaringan yang tidak membuat blok. Bahkan jika validator jahat terus membuat blok di atas blok yang tidak valid tersebut lebih cepat daripada validator jujur membangun rantai yang benar, sehingga memiliki rantai dengan blok yang tidak valid menjadi lebih lama, itu tidak masalah, karena setiap peserta yang menggunakan blockchain untuk tujuan apa pun memvalidasi semua blok, dan membuang semua blok yang dibangun di atas blok yang tidak valid.
Pada gambar di atas ada lima validator, tiga di antaranya berbahaya. Mereka membuat blok A 'yang tidak valid, dan kemudian melanjutkan membangun blok baru di atasnya. Dua validator yang jujur membuang A 'sebagai tidak valid dan membangun di atas blok valid terakhir yang diketahui oleh mereka, membuat garpu. Karena ada lebih sedikit validator di garpu jujur, rantai mereka lebih pendek. Namun, dalam blockchain non-sharded klasik, setiap peserta yang menggunakan blockchain untuk tujuan apa pun bertanggung jawab untuk memvalidasi semua blok yang mereka terima dan mengkomputasi ulang negara. Jadi setiap orang yang memiliki minat pada blockchain akan mengamati bahwa A 'tidak valid, dan dengan demikian juga segera membuang B', C 'dan D', dengan demikian mengambil rantai AB sebagai rantai valid terpanjang saat ini.
Namun, dalam blockchain yang terbelok, tidak ada peserta yang dapat memvalidasi semua transaksi di semua pecahan, sehingga mereka perlu memiliki beberapa cara untuk mengonfirmasi bahwa tidak ada titik dalam sejarah beling dari blockchain yang mana pun, tidak ada blok yang tidak valid yang dimasukkan.
Perhatikan bahwa tidak seperti garpu, hubungan silang ke rantai Beacon bukanlah solusi yang memadai, karena rantai Beacon tidak memiliki kapasitas untuk memvalidasi blok. Itu hanya dapat memvalidasi bahwa sejumlah cukup validator di beling itu menandatangani blok (dan dengan demikian membuktikan kebenarannya).
Saya sadar hanya ada dua solusi untuk masalah ini, yang tidak satu pun yang benar-benar memuaskan hari ini:
- Memiliki beberapa mekanisme masuk akal yang akan mengingatkan sistem jika upaya untuk menerapkan transisi keadaan secara salah dilakukan. Dengan asumsi bahwa setiap beling menjalankan semacam konsensus BFT, selama jumlah validator jahat di beling tertentu kurang dari ⅔, setidaknya satu validator yang jujur perlu membuktikan blok, dan memverifikasi bahwa fungsi transisi negara adalah diterapkan dengan benar. Jika lebih dari ⅔ dari node berbahaya, mereka dapat menyelesaikan blok tanpa satu pun simpul jujur yang berpartisipasi. Dengan asumsi bahwa setidaknya satu node di beling tidak berbahaya, beberapa mekanisme diperlukan yang akan memungkinkan node tersebut untuk memantau blok apa yang sedang diproduksi, dan memiliki waktu yang cukup untuk menantang node dengan transisi keadaan tidak valid.
- Memiliki beberapa informasi dalam blok yang cukup untuk membuktikan bahwa transisi negara diterapkan dengan benar tetapi secara signifikan lebih murah untuk divalidasi daripada aplikasi sebenarnya dari fungsi transisi negara. Mekanisme terdekat untuk mencapainya adalah zk-SNARKs (walaupun kita tidak benar-benar membutuhkan bagian "zk", atau nol-pengetahuan, sebuah SNARK non-zk sudah mencukupi), tetapi zk-SNARK terkenal lambat untuk menghitung pada titik ini.
Banyak protokol saat ini mengasumsikan bahwa dengan rotasi validator yang tepat dan konsensus toleran-kesalahan Bizantium, percabangan atau transisi keadaan yang tidak valid adalah mungkin. Alasan mengapa asumsi ini tidak masuk akal adalah topik untuk artikel terpisah.
Outro
Saya banyak menulis tentang blockchains dan sharding, dan kami juga memiliki seri video di mana kami berbicara dengan para pendiri protokol yang dapat diukur, seperti Cosmos dan Solana, dengan penyelaman mendalam yang berteknologi. Anda dapat mengikuti saya di twitter di sini .