Manfaat utamanya adalah mengurangi jumlah data yang disimpan di Ethereum, sehingga mengurangi biaya bagi pengguna untuk bertransaksi di L2.
**Ditulis oleh: **OneTrueKirk
Disusun oleh: Yvonne, MarsBit
** Posting asli dari OneTrueKirk di ethresear.ch **
Ini adalah pertama kalinya saya memposting tentang suatu topik di sini, jadi saya minta maaf jika saya menyinggung Anda dengan cara apa pun. Saya telah memikirkan ide ini (Stateless Rollups) sebagian besar untuk pembatalan khusus untuk protokol pinjaman kami, tetapi mudah-mudahan ini dapat diterapkan secara umum, umpan balik apa pun dihargai.
TLDR：
Hanya root status yang dipublikasikan, bukan calldata.
(Catatan MarsBit: Calldata adalah nilai bagian data dalam transaksi kontrak dan tidak dapat diubah.)
##detail
Bagaimana jika alih-alih menggunakan Ethereum sebagai lapisan ketersediaan data, dengan memublikasikan status lengkap sebagai calldata, dan hanya memublikasikan root status ke mainnet? Manfaat utamanya adalah mengurangi jumlah data yang disimpan di Ethereum, sehingga mengurangi biaya bagi pengguna untuk bertransaksi di L2. Bahkan dengan EIP-4844, blobace tidak gratis.
Risiko utama adalah Serangan Pemotongan Data, di mana pengusul menerbitkan root negara yang valid tetapi menahan data lengkap dari node rollup lain untuk memonopoli produksi blok di masa mendatang atau menahan dana sebagai sandera. Untuk mencegah hal ini, node yang jujur harus mempertanyakan pembaruan status apa pun yang datanya tidak dapat disediakan oleh peer. Bukti penipuan interaktif gaya arbitrum dapat digunakan untuk memaksa pengusul untuk mengungkapkan status penuh di mainnet, tetapi masih menyebabkan tantangan gagal jika root valid, sehingga bahkan dalam kasus kegagalan, biaya tantangannya rendah.
(Catatan MarsBit: Serangan Pemotongan Data mengacu pada penyerang yang dengan sengaja tidak mengembalikan semua data atau mengembalikan data yang salah saat mengakses data yang dilindungi, untuk mencapai tujuan penipuan atau penghancuran.
Jika biaya kegagalan tantangan rendah, pengusul yang jujur dapat dibuat sengsara dengan memaksa mereka membayar untuk memposting semua data negara bagian ke mainnet untuk mempertahankan tantangan tersebut, bahkan jika mereka menyebarkan data negara bagian secara point-to-point dengan benar. Biaya untuk mengajukan gugatan harus sebanding dengan biaya pembelaan untuk memastikan bahwa pengusul yang jujur tidak dapat diserang dengan cara ini.
Dalam kasus terburuk, jika penyerang dapat membelanjakan $1 untuk biaya pengusul yang jujur $1, mereka dapat memaksa pengusul untuk menyerah dan mendapatkan blokir mereka kembali. Pengusul baru yang jujur kemudian dapat menawar, dan kecuali penyerang dapat mengulangi serangan terhadap semua calon pengusul jujur, termasuk semua orang yang memiliki dana, mereka tidak dapat menyebabkan downtime permanen. Dimungkinkan untuk menambahkan klausul lain, di mana biaya tantangan naik ketika terlalu lama berlalu sejak blok yang valid diselesaikan. Dengan cara ini, mudah untuk menantang pengusul yang tidak jujur, tetapi tidak mungkin untuk menghentikan transisi negara dalam waktu lama.
Secara lebih optimis, jika node menyebarkan data di antara peer, mereka dapat menentukan pencadangan data dan solusi aksesibilitas mereka sendiri, dan pengguna lebih baik menyimpan data yang mereka perlukan secara lokal untuk transisi keadaan mereka sendiri. Dalam konteks satu aplikasi tertentu, saya memikirkan pengkodean keadaan rollup dengan cara yang sama sekali berbeda dari EVM untuk mengoptimalkannya. Semua status yang terkait dengan akun pengguna tertentu dapat dikodekan ke dalam hash yang sama, sehingga pengguna dapat lebih mudah memverifikasi perubahan pada akun mereka tanpa mengetahui status global (yaitu mengonfirmasi bahwa Anda menerima jumlah token tanpa khawatir dari mana asalnya).
Ringkas
Saya ingin mendengar pendapat Anda, dan sangat menghargai tautan ke pekerjaan terkait. Tidak seperti rollup optimis biasa, dalam rollup optimis, mudah untuk menentukan apakah data panggilan yang dikirimkan cocok dengan root status jaringan utama, dan apakah keduanya valid, tetapi tidak mungkin untuk mengetahui apakah pembaruan valid dari root status saja, jadi perlu untuk mempertimbangkan dengan hati-hati ekonomi periode tantangan dan kesedihan (yaitu perilaku jahat).
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Pandangan Cepat tentang Keuntungan dan Potensi Masalah dari Stateless Rollup
**Ditulis oleh: **OneTrueKirk
Disusun oleh: Yvonne, MarsBit
** Posting asli dari OneTrueKirk di ethresear.ch **
Ini adalah pertama kalinya saya memposting tentang suatu topik di sini, jadi saya minta maaf jika saya menyinggung Anda dengan cara apa pun. Saya telah memikirkan ide ini (Stateless Rollups) sebagian besar untuk pembatalan khusus untuk protokol pinjaman kami, tetapi mudah-mudahan ini dapat diterapkan secara umum, umpan balik apa pun dihargai.
TLDR：
Hanya root status yang dipublikasikan, bukan calldata.
(Catatan MarsBit: Calldata adalah nilai bagian data dalam transaksi kontrak dan tidak dapat diubah.)
##detail
Bagaimana jika alih-alih menggunakan Ethereum sebagai lapisan ketersediaan data, dengan memublikasikan status lengkap sebagai calldata, dan hanya memublikasikan root status ke mainnet? Manfaat utamanya adalah mengurangi jumlah data yang disimpan di Ethereum, sehingga mengurangi biaya bagi pengguna untuk bertransaksi di L2. Bahkan dengan EIP-4844, blobace tidak gratis.
Risiko utama adalah Serangan Pemotongan Data, di mana pengusul menerbitkan root negara yang valid tetapi menahan data lengkap dari node rollup lain untuk memonopoli produksi blok di masa mendatang atau menahan dana sebagai sandera. Untuk mencegah hal ini, node yang jujur harus mempertanyakan pembaruan status apa pun yang datanya tidak dapat disediakan oleh peer. Bukti penipuan interaktif gaya arbitrum dapat digunakan untuk memaksa pengusul untuk mengungkapkan status penuh di mainnet, tetapi masih menyebabkan tantangan gagal jika root valid, sehingga bahkan dalam kasus kegagalan, biaya tantangannya rendah.
(Catatan MarsBit: Serangan Pemotongan Data mengacu pada penyerang yang dengan sengaja tidak mengembalikan semua data atau mengembalikan data yang salah saat mengakses data yang dilindungi, untuk mencapai tujuan penipuan atau penghancuran.
Jika biaya kegagalan tantangan rendah, pengusul yang jujur dapat dibuat sengsara dengan memaksa mereka membayar untuk memposting semua data negara bagian ke mainnet untuk mempertahankan tantangan tersebut, bahkan jika mereka menyebarkan data negara bagian secara point-to-point dengan benar. Biaya untuk mengajukan gugatan harus sebanding dengan biaya pembelaan untuk memastikan bahwa pengusul yang jujur tidak dapat diserang dengan cara ini.
Dalam kasus terburuk, jika penyerang dapat membelanjakan $1 untuk biaya pengusul yang jujur $1, mereka dapat memaksa pengusul untuk menyerah dan mendapatkan blokir mereka kembali. Pengusul baru yang jujur kemudian dapat menawar, dan kecuali penyerang dapat mengulangi serangan terhadap semua calon pengusul jujur, termasuk semua orang yang memiliki dana, mereka tidak dapat menyebabkan downtime permanen. Dimungkinkan untuk menambahkan klausul lain, di mana biaya tantangan naik ketika terlalu lama berlalu sejak blok yang valid diselesaikan. Dengan cara ini, mudah untuk menantang pengusul yang tidak jujur, tetapi tidak mungkin untuk menghentikan transisi negara dalam waktu lama.
Secara lebih optimis, jika node menyebarkan data di antara peer, mereka dapat menentukan pencadangan data dan solusi aksesibilitas mereka sendiri, dan pengguna lebih baik menyimpan data yang mereka perlukan secara lokal untuk transisi keadaan mereka sendiri. Dalam konteks satu aplikasi tertentu, saya memikirkan pengkodean keadaan rollup dengan cara yang sama sekali berbeda dari EVM untuk mengoptimalkannya. Semua status yang terkait dengan akun pengguna tertentu dapat dikodekan ke dalam hash yang sama, sehingga pengguna dapat lebih mudah memverifikasi perubahan pada akun mereka tanpa mengetahui status global (yaitu mengonfirmasi bahwa Anda menerima jumlah token tanpa khawatir dari mana asalnya).
Ringkas
Saya ingin mendengar pendapat Anda, dan sangat menghargai tautan ke pekerjaan terkait. Tidak seperti rollup optimis biasa, dalam rollup optimis, mudah untuk menentukan apakah data panggilan yang dikirimkan cocok dengan root status jaringan utama, dan apakah keduanya valid, tetapi tidak mungkin untuk mengetahui apakah pembaruan valid dari root status saja, jadi perlu untuk mempertimbangkan dengan hati-hati ekonomi periode tantangan dan kesedihan (yaitu perilaku jahat).