Vitalik: Menjelaskan Perbedaan Berbagai Jenis L2

Proyek L2 akan semakin mengarah pada heterogenitas.

Judul Asli: "Different types of layer 2s"

Penulis: Vitalik Buterin

Penerjemah: BlockBeats

Ekosistem telah berkembang pesat dalam setahun terakhir. Secara tradisional, ekosistem ZK-EVM rollup yang diwakili oleh StarkNet, Arbitrum, Optimism, dan Scroll berkembang dengan cepat, terus meningkatkan keamanannya, dan halaman L2beat merangkum status setiap proyek dengan baik.

Selain itu, kami juga melihat beberapa tim sedang membangun sidechain, sekaligus mulai mengembangkan solusi rollup (seperti Polygon), beberapa proyek L1 mencoba bergerak ke arah validasi validitas (seperti Celo), serta upaya baru (seperti Linea, Zeth…).

Salah satu hasil yang tak terhindarkan adalah, kita melihat proyek L2 cenderung menjadi semakin heterogeneous (yaitu "heterogen"). Catatan penerjemah: Dalam dunia kripto, "heterogenitas" mengacu pada situasi di mana berbagai jenis atau sifat yang berbeda hidup berdampingan atau bercampur. Istilah ini biasanya digunakan untuk menggambarkan blockchain, protokol, teknologi, atau aset yang berbeda, yang memiliki karakteristik, aturan, atau atribut yang berbeda.

Saya memperkirakan tren ini akan terus berlanjut, dengan alasan sebagai berikut:

Saat ini, beberapa proyek L1 independen sedang mencari cara untuk lebih terhubung dengan ekosistem Ethereum, dan berpotensi bertransformasi menjadi proyek L2. Proyek-proyek ini mungkin ingin mengambil pendekatan transisi bertahap. Transisi total secara langsung akan menurunkan ketersediaan, karena teknologinya belum siap untuk memindahkan semua hal ke dalam solusi rollup. Sementara transisi total yang terlambat mungkin akan mengorbankan momentum dan kehilangan makna praktis.

Beberapa proyek terpusat ingin memberikan jaminan keamanan lebih kepada penggunanya, dan sedang mengeksplorasi jalur berbasis blockchain. Dalam banyak kasus, proyek-proyek ini sebelumnya mungkin akan meneliti "permissioned consortium chain". Faktanya, mereka mungkin hanya perlu mencapai tingkat "semi-terdesentralisasi". Selain itu, mereka biasanya memiliki throughput yang sangat tinggi, setidaknya dalam jangka pendek tidak cocok menggunakan solusi rollup.

Aplikasi non-keuangan, seperti game atau media sosial, ingin terdesentralisasi, tetapi hanya membutuhkan tingkat keamanan tertentu.

Dalam kasus media sosial, sebenarnya melibatkan penanganan bagian-bagian aplikasi yang berbeda dengan cara berbeda: aktivitas langka dan bernilai tinggi seperti pendaftaran nama pengguna dan pemulihan akun sebaiknya dilakukan di solusi rollup, tetapi aktivitas yang sering dan bernilai rendah seperti posting dan voting hanya memerlukan jaminan keamanan yang lebih rendah. Jika blockchain gagal dan posting Anda hilang, itu adalah harga yang dapat diterima; tetapi jika blockchain gagal dan Anda kehilangan akun Anda, itu adalah masalah yang jauh lebih besar.

Satu tema penting adalah, meskipun aplikasi dan pengguna yang saat ini berada di Ethereum L1 dalam jangka pendek bersedia membayar biaya rollup yang kecil namun tetap terlihat, pengguna dari dunia non-blockchain tidak terlalu bersedia melakukan hal tersebut: jika sebelumnya Anda membayar 1 dolar, maka membayar 0,10 dolar lebih mudah diterima, tetapi jika sebelumnya Anda membayar 0 dolar, maka akan sulit diterima.

Ini berlaku untuk aplikasi yang hari ini masih terpusat, serta proyek L1 kecil yang biasanya memiliki biaya sangat rendah ketika basis penggunanya masih kecil.

Pertanyaan alami yang muncul adalah: untuk aplikasi tertentu, di antara berbagai pertimbangan kompleks antara solusi rollup, validium (validitas), dan sistem lain, mana yang paling masuk akal?

Rollups vs Validiums vs Sistem Terputus

Dimensi pertama keamanan dan skalabilitas yang akan kita bahas dapat dijelaskan sebagai berikut: Jika Anda memiliki aset yang diterbitkan di L1, lalu menyimpannya ke L2, kemudian mentransfernya ke tangan Anda, seberapa besar jaminan yang Anda dapatkan bahwa aset tersebut dapat diambil kembali ke L1?

Pada saat yang sama, ada pertanyaan terkait: pilihan teknologi apa yang menyebabkan tingkat jaminan ini, dan apa pertimbangan dari pilihan teknologi tersebut?

Kita dapat menggambarkan masalah ini dengan grafik sederhana:

Perlu disebutkan bahwa ini adalah skema yang disederhanakan, di mana terdapat banyak opsi di tengah. Misalnya:

Di antara rollup dan validium: Pada validium, siapa pun dapat melakukan pembayaran on-chain untuk membayar biaya transaksi, pada saat itu, operator akan dipaksa untuk menyediakan beberapa data ke chain, jika tidak mereka akan kehilangan deposit.

Di antara plasma dan validium: Sistem Plasma memberikan jaminan keamanan mirip rollup, dengan ketersediaan data off-chain, tetapi hanya mendukung sejumlah aplikasi terbatas. Sebuah sistem dapat menyediakan EVM lengkap, dan untuk pengguna yang tidak menggunakan aplikasi yang lebih kompleks ini diberikan jaminan tingkat Plasma, sedangkan untuk pengguna yang menggunakan aplikasi tersebut diberikan jaminan tingkat validium.

Opsi-opsi di tengah ini dapat dianggap sebagai spektrum antara rollup dan validium. Namun, apa yang mendorong aplikasi memilih titik tertentu pada spektrum ini, bukan di kiri atau kanan? Di sini, ada dua faktor utama:

1. Biaya ketersediaan data asli Ethereum, yang seiring perkembangan teknologi, biaya ini akan menurun seiring waktu. Hard fork Ethereum berikutnya, Dencun, memperkenalkan EIP-4844 (juga dikenal sebagai "proto-danksharding"), yang menyediakan sekitar 32 kB/detik ketersediaan data on-chain.

Diperkirakan dalam beberapa tahun ke depan, seiring peluncuran danksharding penuh, ketersediaan data ini akan meningkat secara bertahap, dengan target akhir sekitar 1,3 MB/detik ketersediaan data. Sementara itu, peningkatan kompresi data akan memungkinkan kita melakukan lebih banyak dengan jumlah data yang sama.

2. Kebutuhan aplikasi itu sendiri: seberapa parah kerugian pengguna akibat biaya tinggi, dibandingkan dengan masalah pada aplikasi? Aplikasi keuangan akan kehilangan lebih banyak jika terjadi kegagalan aplikasi; game dan media sosial melibatkan banyak aktivitas pengguna dengan nilai relatif rendah, sehingga bagi mereka, pertimbangan keamanan yang berbeda masuk akal.

Pertimbangan ini secara garis besar terlihat seperti pada gambar berikut:

Tipe lain yang patut disebut adalah pre-confirmations (pra-konfirmasi). Pre-confirmation adalah pesan yang ditandatangani oleh sekelompok partisipan dalam rollup atau validium, yang menyatakan "kami membuktikan transaksi ini dimasukkan dalam urutan ini, dan post-state root-nya adalah ini". Para partisipan ini mungkin saja menandatangani pre-confirmation yang tidak sesuai kenyataan, tetapi jika memang demikian, deposit mereka akan dihancurkan.

Ini sangat berguna untuk aplikasi bernilai rendah (seperti pembayaran konsumen), sedangkan aplikasi bernilai tinggi (seperti transfer keuangan jutaan dolar) mungkin akan menunggu konfirmasi "reguler" yang didukung oleh keamanan sistem penuh.

Pre-confirmation dapat dianggap sebagai contoh lain dari sistem hybrid, mirip dengan "plasma/validium hybrid" yang disebutkan di atas, tetapi kali ini merupakan hybrid antara rollup (atau validium) dengan keamanan penuh namun latensi tinggi, dan sistem dengan tingkat keamanan lebih rendah namun latensi rendah. Aplikasi yang membutuhkan latensi rendah akan mendapatkan keamanan lebih rendah, tetapi dapat hidup berdampingan dalam ekosistem yang sama dengan aplikasi yang bersedia menanggung latensi lebih tinggi demi keamanan maksimal.

Membaca Ethereum Tanpa Kepercayaan

Bentuk koneksi lain yang jarang dipertimbangkan namun sangat penting, berkaitan dengan kemampuan sistem untuk membaca blockchain Ethereum. Secara khusus, ini mencakup kemampuan sistem untuk melakukan rollback jika terjadi rollback pada Ethereum. Untuk memahami mengapa ini berharga, pertimbangkan situasi berikut:

Misalkan seperti pada gambar, blockchain Ethereum mengalami rollback. Ini bisa berupa gangguan sementara dalam satu epoch, di mana blockchain belum final; atau bisa juga karena terlalu banyak validator offline, menyebabkan blockchain tidak dapat difinalkan dalam waktu lama (periode nonaktif).

Kemungkinan terburuk yang mungkin terjadi adalah sebagai berikut: Misalkan blok pertama dari top chain membaca beberapa data dari blok paling kiri pada chain Ethereum. Misalnya, seseorang menyetor 100 ETH ke top chain di Ethereum. Kemudian Ethereum mengalami rollback, namun top chain tidak ikut rollback. Akibatnya, blok-blok top chain selanjutnya mengikuti blok Ethereum yang baru dan benar, tetapi transaksi yang salah (yaitu deposit 100 ETH) tetap ada di top chain. Kerentanan ini dapat menyebabkan inflasi mata uang, mengubah ETH yang dijembatani di top chain menjadi fractional reserve.

Ada dua cara untuk mengatasi masalah ini:

1. Top chain hanya dapat membaca blok Ethereum yang telah difinalkan, sehingga tidak pernah perlu melakukan rollback;

2. Jika Ethereum mengalami rollback, top chain juga dapat mengalami rollback. Keduanya dapat mencegah masalah ini. Cara pertama lebih mudah diterapkan, tetapi jika Ethereum memasuki periode nonaktif, dapat menyebabkan hilangnya fungsi dalam waktu lama. Cara kedua lebih sulit diterapkan, tetapi dapat memastikan fungsi optimal setiap saat.

Perhatikan bahwa cara pertama memang memiliki satu kasus khusus. Jika Ethereum mengalami serangan 51%, menyebabkan dua blok baru yang tidak kompatibel muncul secara bersamaan, keduanya tampak telah difinalkan, maka top chain mungkin memilih blok yang salah (yaitu blok yang akhirnya tidak didukung oleh konsensus sosial Ethereum), dan perlu rollback untuk beralih ke blok yang benar. Bisa dikatakan, menulis kode untuk menangani situasi ini sebelumnya tidak diperlukan; dapat diatasi dengan hard fork pada top chain.

Kemampuan blockchain untuk membaca Ethereum tanpa kepercayaan penting karena dua alasan:

Pertama, kemampuan ini dapat mengurangi masalah keamanan yang terkait dengan menjembatani token yang diterbitkan di Ethereum (atau solusi layer 2 lainnya) ke chain tersebut;

Kedua, kemampuan ini memungkinkan dompet abstraksi akun dengan struktur penyimpanan kunci bersama untuk dengan aman menyimpan aset di chain tersebut.

Meskipun kontroversial, pentingnya cara pertama telah diakui secara luas. Demikian pula, cara kedua juga penting, karena berarti Anda dapat memiliki dompet yang dapat dengan mudah mengganti kunci, dan menyimpan aset di banyak chain berbeda.

Apakah Memiliki Bridge Dapat Menjadi Validium?

Misalkan top chain awalnya diluncurkan sebagai chain independen, lalu seseorang menerapkan kontrak bridge di Ethereum. Kontrak bridge hanyalah kontrak yang menerima block header dari top chain, yang akan memverifikasi apakah setiap block header yang dikirimkan kepadanya disertai sertifikat yang valid, membuktikan bahwa block header tersebut telah diterima oleh konsensus top chain, dan menambahkannya ke daftar.

Aplikasi dapat membangun fungsi di atasnya, seperti deposit dan penarikan token. Setelah bridge seperti itu dibangun, apakah itu memberikan jaminan keamanan aset yang telah kita sebutkan sebelumnya?

Sampai saat ini, belum! Ada dua alasan:

1. Kita memverifikasi tanda tangan blok, tetapi tidak memverifikasi apakah transisi statusnya benar. Jadi, jika Anda menyimpan aset yang diterbitkan di Ethereum ke top chain, dan validator top chain menjadi tidak jujur, mereka dapat menandatangani transisi status yang tidak valid, sehingga mencuri aset tersebut;

2. Top chain masih belum dapat membaca Ethereum. Oleh karena itu, Anda tidak dapat menyimpan aset asli Ethereum ke top chain, kecuali mengandalkan bridge pihak ketiga lain (yang mungkin tidak aman).

Sekarang, mari kita bangun bridge sebagai bridge verifikasi: ia tidak hanya memverifikasi konsensus, tetapi juga memverifikasi apakah status blok baru yang dihitung menggunakan bukti ZK-SNARK benar.

Setelah langkah ini dilakukan, validator top chain tidak dapat mencuri dana Anda. Mereka dapat menerbitkan blok yang berisi data yang tidak tersedia, sehingga mencegah semua orang menarik dana, tetapi mereka tidak dapat mencuri dana (kecuali mencoba meminta tebusan kepada pengguna untuk mengungkapkan data yang memungkinkan mereka menarik dana). Ini memiliki model keamanan yang sama dengan validium.

Namun, kita masih belum menyelesaikan masalah kedua: top chain tidak dapat membaca data Ethereum. Untuk mencapai ini, kita perlu mengambil salah satu dari dua cara berikut:

1. Tempatkan kontrak bridge yang memverifikasi blok Ethereum yang telah difinalkan di top chain;

2. Sertakan hash blok Ethereum terbaru di setiap blok top chain, dan gunakan aturan pemilihan fork untuk memaksa tautan hash. Artinya, blok top chain yang terhubung ke blok Ethereum non-main chain itu sendiri adalah blok non-main chain. Jika blok Ethereum yang terhubung ke blok top chain awalnya di main chain, tetapi kemudian menjadi non-main chain, maka blok top chain juga harus menjadi non-main chain.

Tautan ungu ini bisa berupa tautan hash, atau kontrak bridge yang memverifikasi konsensus Ethereum

Apakah ini cukup? Sebenarnya, belum, karena ada beberapa kasus tepi kecil:

1. Apa yang terjadi jika Ethereum mengalami serangan 51%?

2. Bagaimana menangani upgrade hard fork Ethereum?

3. Bagaimana menangani upgrade hard fork chain Anda?

Serangan 51% pada Ethereum akan menyebabkan konsekuensi serupa dengan serangan 51% pada top chain, tetapi sebaliknya. Hard fork Ethereum dapat menyebabkan bridge Ethereum di dalam top chain gagal. Komitmen sosial, yaitu jika Ethereum membatalkan blok yang telah difinalkan, maka akan dibatalkan, jika Ethereum melakukan hard fork, maka akan melakukan hard fork, adalah cara paling bersih untuk mengatasi masalah ini.

Komitmen seperti itu sebenarnya mungkin tidak pernah benar-benar perlu dijalankan: jika lembaga tata kelola top chain menemukan bukti kemungkinan serangan atau hard fork, mereka dapat mengaktifkan lembaga tata kelola, dan hanya melakukan hard fork pada top chain jika lembaga tata kelola gagal.

Untuk masalah ketiga, satu-satunya jawaban yang layak adalah menyiapkan semacam lembaga tata kelola di Ethereum, sehingga kontrak bridge di Ethereum dapat menyadari upgrade hard fork pada top chain.

Kesimpulan: Bridge verifikasi dua arah hampir cukup untuk membuat blockchain menjadi validium. Elemen utama yang tersisa adalah komitmen sosial, yaitu jika terjadi situasi abnormal pada Ethereum yang menyebabkan kontrak bridge tidak dapat berfungsi, blockchain lain akan melakukan hard fork sebagai respons.

Kesimpulan

"Terkoneksi dengan Ethereum" memiliki dua dimensi kunci:

1. Keamanan penarikan ke Ethereum;

2. Keamanan membaca Ethereum.

Keduanya sangat penting, dan memiliki pertimbangan yang berbeda. Dalam kedua kasus terdapat spektrum kontinu:

Perhatikan bahwa setiap dimensi memiliki dua cara pengukuran berbeda (sebenarnya ada empat dimensi): keamanan penarikan dapat diukur dengan (i) tingkat keamanan, dan (ii) berapa banyak pengguna atau penggunaan yang mendapat manfaat dari tingkat keamanan tertinggi;

Sementara keamanan membaca dapat diukur dengan (i) seberapa cepat chain dapat membaca blok Ethereum, khususnya perbedaan antara blok yang telah difinalkan dan blok apa pun, serta (ii) tingkat komitmen sosial chain dalam menangani kasus tepi seperti serangan 51% dan hard fork.

Di banyak area dalam ruang desain ini terdapat nilai bagi proyek. Untuk beberapa aplikasi, keamanan tinggi dan koneksi erat sangat penting. Untuk aplikasi lain, demi skalabilitas yang lebih besar, kondisi yang lebih longgar dapat diterima. Dalam banyak kasus, memulai dengan kondisi yang lebih longgar hari ini, dan secara bertahap bertransisi ke keterikatan yang lebih erat seiring kemajuan teknologi dalam sepuluh tahun ke depan mungkin merupakan pilihan optimal.