Judul asli: (Kemungkinan masa depan protokol Ethereum, bagian 6: The Splurge)
Penulis asli: @VitalikButerin
Kompilasi asli: zhouzhou, BlockBeats
Berikut konten aslinya (konten asli telah diedit agar mudah dibaca dan dipahami):
Beberapa hal sulit untuk dimasukkan ke dalam satu kategori, dan ada banyak “detail kecil” dalam desain protokol Ethereum yang sangat penting bagi kesuksesan Ethereum. Faktanya, sekitar separuh konten membahas berbagai jenis peningkatan EVM, dan sisanya terdiri dari berbagai topik khusus, yang merupakan inti dari "berkembang".
Peta Jalan 2023: Kemakmuran
Kemakmuran: tujuan utama
Ubah EVM menjadi "keadaan akhir" yang berkinerja tinggi dan stabil
Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna menikmati akun yang lebih aman dan nyaman
Mengoptimalkan keekonomian biaya transaksi, meningkatkan skalabilitas sekaligus mengurangi risiko
Jelajahi kriptografi tingkat lanjut untuk meningkatkan Ethereum secara signifikan dalam jangka panjang
Isi bab ini
Peningkatan EVM
Abstraksi akun
Peningkatan EIP-1559
VDF (Fungsi Penundaan yang Dapat Diverifikasi)
Kebingungan dan tanda tangan satu kali: masa depan kriptografi yang panjang
Peningkatan EVM
Masalah apa yang terpecahkan?
EVM saat ini sulit untuk dianalisis secara statis, sehingga sulit untuk membuat implementasi yang efisien, memverifikasi kode secara formal, dan membuat ekstensi lebih lanjut. Selain itu, EVM tidak efisien dan sulit untuk mengimplementasikan berbagai bentuk kriptografi tingkat lanjut kecuali didukung secara eksplisit melalui prakompilasi.
Apa itu dan bagaimana cara kerjanya?
Langkah pertama dalam peta jalan peningkatan EVM saat ini adalah EVM Object Format (EOF), yang rencananya akan disertakan dalam hard fork berikutnya. EOF adalah rangkaian EIP yang menentukan versi kode EVM baru dengan sejumlah karakteristik unik, terutama:
Pemisahan antara kode (dapat dieksekusi, namun tidak dapat dibaca dari EVM) dan data (dapat dibaca, namun tidak dapat dieksekusi)
Lompatan dinamis dilarang dan hanya lompatan statis yang diperbolehkan
Kode EVM tidak dapat lagi mengamati informasi terkait bahan bakar
Menambahkan mekanisme subrutin eksplisit baru
Struktur kode EOF
Boom: Peningkatan EVM (lanjutan)
Kontrak lama akan terus ada dan dapat dibuat, meskipun pada akhirnya kontrak tersebut mungkin akan dihapuskan secara bertahap (dan bahkan mungkin dipaksa menggunakan kode EOF). Kontrak model baru akan mendapatkan keuntungan dari peningkatan efisiensi yang dihasilkan oleh EOF—pertama dari bytecode yang sedikit lebih kecil melalui fitur subrutin, dan kemudian dari fungsionalitas khusus EOF baru atau pengurangan biaya bahan bakar.
Setelah diperkenalkannya EOF, peningkatan lebih lanjut menjadi lebih mudah, dan yang paling berkembang saat ini adalah ekstensi aritmatika modul EVM (EVM-MAX). EVM-MAX menciptakan serangkaian operasi baru khusus untuk aritmatika modular dan menempatkannya di ruang memori baru yang tidak dapat diakses melalui opcode lain, sehingga memungkinkan untuk menggunakan optimasi seperti perkalian Montgomery.
Ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruksi Multiple Data (SIMD). SIMD telah menjadi ide di Ethereum sejak lama, pertama kali diusulkan oleh EIP-616 milik Greg Colvin. SIMD dapat digunakan untuk mempercepat berbagai bentuk kriptografi, termasuk fungsi hash, STARK 32-bit, dan kriptografi berbasis kisi, dan kombinasi EVM-MAX dan SIMD menjadikan kedua ekstensi berorientasi kinerja ini sebagai pasangan alami.
Desain kasar EIP gabungan akan dimulai dengan EIP-6690 dan kemudian:
Mengizinkan (i) bilangan ganjil atau (ii) pangkat 2 hingga 2768 sebagai modulus
Untuk setiap opcode EVM-MAX (penjumlahan, pengurangan, perkalian), tambahkan versi yang alih-alih menggunakan 3 perintah langsung x, y, z, menggunakan 7 perintah langsung: x_start, x_skip, y_start, y_skip , z_start, z_skip, count. Dalam kode Python, opcode ini berfungsi seperti:
untuk i dalam rentang (hitungan): mem[z_start + z_skip * hitung] = op(mem[x_start + x_skip * hitung], mem[y_start + y_skip * hitung])
Dalam implementasi sebenarnya, hal ini akan ditangani secara paralel.
Mungkin menambahkan XOR, AND, OR, NOT dan SHIFT (baik siklik maupun asiklik), setidaknya untuk pangkat 2 modulo. Tambahkan juga ISZERO (push output ke tumpukan utama EVM), yang akan cukup kuat untuk mengimplementasikan kriptografi kurva elips, kriptografi domain kecil (seperti Poseidon, Circle STARKs), fungsi hash tradisional (seperti SHA 256, KECCAK, BLAKE) dan Kriptografi berbasis kisi. Peningkatan EVM lainnya mungkin dilakukan tetapi sejauh ini kurang mendapat perhatian.
Tautan ke penelitian yang ada
Sumber: https://evmobjectformat.org/
EVM-MAX:https://eips.ethereum.org/EIPS/eip-6690
SIMD:https://eips.ethereum.org/EIPS/eip-616
Pekerjaan yang tersisa dan trade-off
Saat ini, EOF rencananya akan dimasukkan ke dalam hard fork berikutnya. Meskipun selalu memungkinkan untuk menghapusnya pada menit-menit terakhir - fitur-fitur telah dihapus sementara di hard fork sebelumnya, namun hal ini akan cukup menantang. Menghapus EOF berarti bahwa setiap peningkatan EVM di masa mendatang perlu dilakukan tanpa EOF, yang dapat dilakukan, tetapi mungkin lebih sulit.
Pengorbanan utama EVM adalah kompleksitas L1 dan kompleksitas infrastruktur, EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis relatif kompleks. Namun, sebagai imbalannya, kami mendapatkan bahasa tingkat tinggi yang disederhanakan, implementasi EVM yang disederhanakan, dan manfaat lainnya. Bisa dibilang, peta jalan yang memprioritaskan perbaikan berkelanjutan pada Ethereum L1 harus mencakup dan dibangun berdasarkan EOF.
Pekerjaan penting yang perlu dilakukan adalah mengimplementasikan fungsionalitas seperti EVM-MAX plus SIMD dan mengukur konsumsi gas dari berbagai operasi kriptografi.
Bagaimana cara saya berinteraksi dengan bagian lain dari peta jalan?
L1 menyesuaikan EVM-nya sehingga L2 dapat lebih mudah menyesuaikannya. Jika keduanya tidak melakukan penyesuaian secara bersamaan, hal ini dapat menyebabkan ketidakcocokan dan membawa dampak buruk. Selain itu, EVM-MAX dan SIMD dapat mengurangi biaya bahan bakar pada banyak sistem bukti, menjadikan L2 lebih efisien. Hal ini juga mempermudah penggantian lebih banyak prakompilasi dengan kode EVM yang dapat melakukan tugas yang sama, mungkin tanpa mempengaruhi efisiensi secara drastis.
Abstraksi akun
Masalah apa yang terpecahkan?
Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun dimaksudkan untuk melampaui hal ini, memungkinkan logika verifikasi akun menjadi kode EVM yang berubah-ubah. Hal ini memungkinkan berbagai aplikasi:
Beralih ke kriptografi tahan kuantum
Memutar kunci lama (secara luas dianggap sebagai praktik keamanan yang direkomendasikan)
Dompet multi-tanda tangan dan dompet pemulihan sosial
Gunakan satu kunci untuk operasi bernilai rendah dan kunci lain (atau sekumpulan kunci) untuk operasi bernilai tinggi
Memungkinkan protokol privasi bekerja tanpa relay, secara signifikan mengurangi kompleksitasnya dan menghilangkan titik ketergantungan pusat utama
Sejak abstraksi akun diusulkan pada tahun 2015, tujuannya juga telah diperluas untuk mencakup sejumlah besar "tujuan kenyamanan". Misalnya, akun tanpa ETH tetapi beberapa ERC 20 dapat membayar bahan bakar dengan ERC 20. Berikut adalah bagan ringkasan tujuan-tujuan tersebut:
MPC (Multi-Party Computation) adalah teknologi berusia 40 tahun yang digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, menggunakan teknik kriptografi untuk menghasilkan tanda tangan tanpa menggabungkan bagian-bagian kunci secara langsung.
EIP-7702 adalah proposal yang direncanakan untuk diperkenalkan pada hard fork berikutnya. EIP-7702 adalah hasil dari meningkatnya kesadaran untuk memberikan kemudahan abstraksi akun untuk memberi manfaat bagi semua pengguna, termasuk pengguna EOA, dan bertujuan untuk meningkatkan semua pengguna dalam jangka pendek. .mengalami dan menghindari perpecahan menjadi dua ekosistem.
Pekerjaan dimulai sebagai EIP-3074 dan akhirnya mengarah ke EIP-7702. EIP-7702 menghadirkan "fungsi kenyamanan" abstraksi akun untuk semua pengguna, termasuk EOA saat ini (akun milik eksternal, yaitu akun yang dikontrol oleh tanda tangan ECDSA).
Seperti yang dapat Anda lihat dari grafik, meskipun beberapa tantangan (khususnya tantangan "kenyamanan") dapat diselesaikan dengan teknologi tambahan seperti komputasi multi-pihak atau EIP-7702, sasaran keamanan utama dari proposal abstraksi akun asli hanya dapat diselesaikan dengan menelusuri kembali dan menyelesaikan masalah awal. Untuk mencapai: Izinkan kode kontrak pintar untuk mengontrol verifikasi transaksi. Alasan mengapa hal ini belum mungkin dilakukan hingga saat ini adalah karena implementasinya yang aman merupakan sebuah tantangan.
Apa itu dan bagaimana cara kerjanya?
Inti dari abstraksi akun sederhana: izinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari penerapan ini dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi dan perlindungan terhadap serangan penolakan layanan.
Tantangan utama yang umum terjadi adalah masalah kegagalan ganda:
Jika ada 1.000 akun yang fungsi verifikasinya semuanya bergantung pada satu nilai S, dan nilai S saat ini membuat semua transaksi di mempool valid, maka satu transaksi yang membalikkan nilai S dapat membuat semua transaksi lain di mempool Transaksi menjadi tidak valid . Hal ini memungkinkan penyerang mengirim spam transaksi ke mempool dengan biaya yang sangat rendah, sehingga menyumbat sumber daya node jaringan.
Setelah kerja keras selama bertahun-tahun yang bertujuan untuk memperluas fungsionalitas sekaligus membatasi risiko Penolakan Layanan (DoS), solusi untuk mencapai “abstraksi akun ideal” akhirnya tiba di: ERC-4337.
ERC-4337 bekerja dengan membagi pemrosesan operasi pengguna menjadi dua tahap: verifikasi dan eksekusi. Semua validasi ditangani terlebih dahulu, semua eksekusi ditangani kemudian. Di mempool, tindakan pengguna hanya akan diterima jika fase validasi hanya melibatkan akunnya sendiri dan tidak membaca variabel lingkungan. Hal ini mencegah beberapa serangan pembatalan. Selain itu, batasan gas yang ketat diberlakukan pada langkah verifikasi.
ERC-4337 dirancang sebagai standar protokol tambahan (ERC) karena pada saat itu pengembang klien Ethereum sedang fokus pada penggabungan dan tidak memiliki tenaga ekstra untuk menangani fungsi lainnya. Inilah sebabnya ERC-4337 menggunakan objek yang disebut Tindakan Pengguna, bukan transaksi biasa. Namun, baru-baru ini kami menyadari bahwa setidaknya sebagian dari hal ini perlu ditulis ke dalam protokol.
Dua alasan utama adalah sebagai berikut:
1. Inefisiensi yang melekat pada EntryPoint sebagai kontrak: overhead tetap sekitar 100.000 gas per bundel, dan ribuan gas lagi per operasi pengguna.
2. Pentingnya memastikan properti Ethereum: Jaminan penyertaan yang dibuat oleh daftar penyertaan perlu ditransfer ke pengguna abstrak akun.
Selain itu, ERC-4337 juga memiliki dua fungsi:
Paymasters: Fitur yang memungkinkan satu akun membayar biaya atas nama akun lain. Hal ini melanggar aturan bahwa hanya akun pengirim itu sendiri yang dapat diakses selama tahap verifikasi, sehingga dilakukan penanganan khusus untuk menjamin keamanan mekanisme master pembayaran.
Agregator: Mendukung fungsi agregasi tanda tangan, seperti agregasi BLS atau agregasi berbasis SNARK. Hal ini diperlukan untuk mencapai efisiensi data maksimum pada Rollup.
Tautan ke penelitian yang ada
Kuliah tentang sejarah abstrak akun: https://www.youtube.com/watch?v=iLf8qpOmxQc
ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
Kode BLSWallet (menggunakan fungsi agregasi): https://github.com/getwax/bls-wallet
EIP-7562 (abstraksi akun ditulis ke dalam protokol): https://eips.ethereum.org/EIPS/eip-7562
EIP-7701 (abstraksi akun protokol tulis berbasis EOF): https://eips.ethereum.org/EIPS/eip-7701
Pekerjaan yang tersisa dan trade-off
Hal utama yang perlu diselesaikan saat ini adalah bagaimana memperkenalkan abstraksi akun sepenuhnya ke dalam protokol. EIP abstraksi akun populer yang ditulis ke dalam protokol adalah EIP-7701. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi, dan jika akun tersebut telah menyiapkan bagian kode tersebut, kode tersebut akan dieksekusi selama langkah verifikasi transaksi dari akun tersebut.
Hal yang menarik dari pendekatan ini adalah bahwa pendekatan ini dengan jelas menggambarkan dua perspektif yang setara mengenai abstraksi rekening lokal:
1. Sertakan EIP-4337 sebagai bagian dari protokol
2. Tipe EOA baru yang algoritma tanda tangannya adalah eksekusi kode EVM
Jika kita mulai dengan menetapkan batasan ketat pada kompleksitas kode yang dapat dieksekusi selama verifikasi - tidak ada akses ke keadaan eksternal yang diizinkan, dan bahkan batas gas yang ditetapkan pada awalnya terlalu rendah untuk efektif untuk aplikasi yang tahan kuantum atau yang menjaga privasi - maka pendekatan ini Keamanannya sangat jelas: cukup ganti verifikasi ECDSA dengan eksekusi kode EVM yang membutuhkan waktu yang sama.
Namun, seiring berjalannya waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi yang menjaga privasi bekerja tanpa relay, serta tahan terhadap kuantum, keduanya merupakan hal yang penting. Untuk melakukan hal ini, kita perlu menemukan cara yang lebih fleksibel untuk mengatasi risiko Denial of Service (DoS) tanpa memerlukan langkah verifikasi yang minimalis.
Pilihan utamanya adalah "tulis solusi dengan cepat yang menyenangkan lebih sedikit orang" versus "menunggu lebih lama dan berpotensi mendapatkan solusi yang lebih ideal." Pendekatan yang ideal mungkin adalah semacam pendekatan hibrida. Pendekatan hibrid adalah menulis beberapa kasus penggunaan dengan lebih cepat dan memberikan lebih banyak waktu untuk mengeksplorasi kasus penggunaan lainnya. Pendekatan lain adalah dengan menerapkan versi abstraksi akun yang lebih ambisius di L2 terlebih dahulu. Namun tantangannya adalah tim L2 harus percaya diri dalam mengadopsi proposal tersebut agar bersedia melaksanakannya, terutama untuk memastikan bahwa L1 dan/atau L2 lainnya dapat mengadopsi pendekatan yang kompatibel di masa depan.
Aplikasi lain yang perlu kita pertimbangkan secara eksplisit adalah akun penyimpanan utama, yang menyimpan status terkait akun di L1 atau L2 khusus, namun dapat digunakan di L1 dan L2 apa pun yang kompatibel. Melakukan hal ini secara efisien mungkin memerlukan opcode dukungan L2 seperti L1S LOAD atau REMOTESTATICCALL, tetapi ini juga mengharuskan implementasi abstraksi akun pada L2 mendukung operasi ini.
Bagaimana interaksinya dengan bagian lain dari peta jalan?
Daftar yang disertakan harus mendukung transaksi abstrak akun, dan dalam praktiknya kebutuhan daftar yang disertakan sebenarnya sangat mirip dengan kebutuhan mempool yang terdesentralisasi, meskipun ada sedikit lebih banyak fleksibilitas untuk daftar yang disertakan. Selain itu, implementasi abstraksi akun harus dikoordinasikan antara L1 dan L2 bila memungkinkan. Jika di masa mendatang kami memperkirakan sebagian besar pengguna akan menggunakan rollup penyimpanan kunci, desain abstraksi akun harus didasarkan pada hal ini.
Peningkatan EIP-1559
Masalah apa yang dipecahkannya?
EIP-1559 diaktifkan di Ethereum pada tahun 2021, secara signifikan meningkatkan waktu penyertaan blok rata-rata.
waktu tunggu
Namun implementasi EIP-1559 saat ini masih belum sempurna dalam beberapa aspek:
1. Rumusnya sedikit cacat: rumus ini tidak menargetkan 50% blok, tetapi sekitar 50-53% dari seluruh blok, bergantung pada variansnya (hal ini tidak konsisten dengan apa yang oleh ahli matematika disebut sebagai "ketidaksetaraan rata-rata aritmatika-geometris" " terkait).
2. Tidak cukup cepat menyesuaikan diri dalam situasi ekstrem.
Rumus blob selanjutnya (EIP-4844) dirancang khusus untuk memecahkan masalah pertama dan secara keseluruhan lebih bersih. Namun, baik EIP-1559 sendiri maupun EIP-4844 tidak berupaya mengatasi masalah kedua. Oleh karena itu, status quo merupakan keadaan tengah yang berantakan dan melibatkan dua mekanisme berbeda, dan terdapat argumen bahwa keduanya perlu diperbaiki seiring berjalannya waktu.
Selain itu, ada kelemahan lain dalam penetapan harga sumber daya Ethereum yang tidak terkait dengan EIP-1559, namun dapat diatasi melalui penyesuaian terhadap EIP-1559. Salah satu masalah utamanya adalah perbedaan antara skenario rata-rata dan skenario terburuk: harga sumber daya di Ethereum harus ditetapkan untuk menangani skenario terburuk, di mana konsumsi gas penuh dalam satu blok menghabiskan sumber daya, namun penggunaan rata-rata sebenarnya adalah jauh lebih rendah dari ini, sehingga menyebabkan inefisiensi.
Apa itu Gas Multidimensi dan bagaimana cara kerjanya?
Solusi terhadap inefisiensi ini adalah Gas multidimensi: menetapkan harga dan batasan yang berbeda untuk sumber daya yang berbeda. Konsep ini secara teknis independen dari EIP-1559, namun keberadaan EIP-1559 memudahkan penerapan skema ini. Tanpa EIP-1559, mengemas blok yang berisi banyak kendala sumber daya secara optimal akan menjadi masalah knapsack multi-dimensi yang kompleks. Dengan EIP-1559, sebagian besar blok tidak akan mencapai kapasitas penuh pada sumber daya apa pun, jadi algoritme sederhana seperti "terima transaksi apa pun yang membayar biaya yang cukup" sudah cukup.
Saat ini kami memiliki gas multidimensi untuk eksekusi dan blok data; pada prinsipnya, kami dapat memperluasnya ke lebih banyak dimensi: seperti data panggilan (data transaksi), pembacaan/penulisan status, dan perluasan ukuran status.
EIP-7706 memperkenalkan dimensi gas baru khusus untuk data panggilan. Pada saat yang sama, hal ini juga menyederhanakan mekanisme gas multi-dimensi dengan menyatukan tiga jenis gas ke dalam kerangka (gaya EIP-4844), sehingga juga memecahkan kelemahan matematis EIP-1559. EIP-7623 adalah solusi yang lebih tepat yang secara lebih ketat membatasi data panggilan maksimum untuk masalah sumber daya rata-rata dan terburuk tanpa memperkenalkan dimensi baru.
Arah penelitian lebih lanjut adalah untuk mengatasi masalah tingkat pembaruan dan menemukan algoritme penghitungan biaya dasar yang lebih cepat sambil tetap mempertahankan invarian kunci yang diperkenalkan oleh mekanisme EIP-4844 (yaitu, penggunaan rata-rata mendekati nilai target dalam jangka panjang).
Tautan ke penelitian yang ada
Tanya Jawab EIP-1559: Tanya Jawab EIP-1559
Analisis empiris pada EIP-1559: Analisis empiris
Usulan perbaikan yang memungkinkan penyesuaian cepat: Usulan perbaikan
Bagian tentang mekanisme biaya dasar di FAQ EIP-4844: FAQ EIP-4844
EIP-7706: EIP-7706
EIP-7623: EIP-7623
Gas Multidimensi: Gas multidimensi
Apa saja upaya dan trade-off yang tersisa?
Ada dua trade-off utama dengan Gas multidimensi:
1. Meningkatkan kompleksitas protokol: Pengenalan Gas multi-dimensi akan membuat protokol menjadi lebih kompleks.
2. Meningkatkan kompleksitas algoritma optimal yang diperlukan untuk mengisi sebuah blok: Algoritma optimal yang diperlukan untuk membawa sebuah blok ke kapasitasnya juga menjadi kompleks.
Kompleksitas protokol relatif kecil untuk data panggilan, namun meningkat untuk dimensi gas yang bersifat internal pada EVM (seperti penyimpanan baca dan tulis). Masalahnya, tidak hanya pengguna yang menetapkan batasan bahan bakar, kontrak juga menetapkan batasan saat memanggil kontrak lain. Dan saat ini, satu-satunya cara mereka dapat menetapkan batasan adalah dengan satu dimensi.
Solusi sederhananya adalah membuat Gas multidimensi hanya tersedia di dalam EOF, karena EOF tidak mengizinkan kontrak menetapkan batas gas saat membatalkan kontrak lain. Kontrak non-EOF diharuskan membayar biaya untuk semua jenis gas saat melakukan operasi penyimpanan (misalnya, jika SLOAD memakan 0,03% dari batas gas akses penyimpanan blok, maka pengguna non-EOF juga akan dikenakan biaya 0,03% dari eksekusi biaya batas gas).
Penelitian lebih lanjut mengenai Gas multidimensi akan membantu memahami trade-off ini dan menemukan keseimbangan yang ideal.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Implementasi Gas multi-dimensi yang berhasil dapat secara signifikan mengurangi penggunaan sumber daya "kasus terburuk", sehingga mengurangi tekanan untuk mengoptimalkan kinerja guna mendukung persyaratan seperti pohon biner berbasis hash yang di-STARK. Menetapkan tujuan yang jelas untuk pertumbuhan ukuran negara bagian akan memudahkan pengembang klien untuk merencanakan dan memperkirakan kebutuhan di masa depan.
Seperti disebutkan sebelumnya, keberadaan EOF memudahkan penerapan versi Gas multidimensi yang lebih ekstrem karena sifat Gasnya yang tidak dapat teramati.
Fungsi Penundaan yang Dapat Diverifikasi (VDF)
Masalah apa yang dipecahkannya?
Saat ini, Ethereum menggunakan keacakan berbasis RANDAO untuk memilih pengusul, yang bekerja dengan mengharuskan setiap pengusul untuk mengungkapkan rahasia yang mereka janjikan sebelumnya, dan menggabungkan setiap rahasia yang terungkap ke dalam keacakan.
Oleh karena itu, setiap pengusul memiliki "1 kendali": mereka dapat mengubah keacakan dengan tidak muncul (dengan biaya tertentu). Pendekatan ini masuk akal untuk mencari pengusul karena sangat jarang Anda melepaskan satu peluang dan mendapatkan dua peluang baru. Namun hal ini tidak ideal untuk aplikasi on-chain yang membutuhkan keacakan. Idealnya, kita harus menemukan sumber keacakan yang lebih kuat.
Apa itu VDF dan bagaimana cara kerjanya?
Fungsi penundaan yang dapat diverifikasi adalah fungsi yang hanya dapat dievaluasi secara berurutan dan tidak dapat dipercepat dengan paralelisasi. Contoh sederhananya adalah hashing berulang: untuk i dalam rentang (10** 9): x = hash(x). Outputnya, terbukti benar menggunakan SNARK, dapat digunakan sebagai nilai acak.
Idenya adalah bahwa masukan dipilih berdasarkan informasi yang tersedia pada waktu T, sedangkan keluarannya belum diketahui pada waktu T: keluaran hanya akan tersedia pada suatu saat setelah T setelah seseorang menjalankan komputasi sepenuhnya. Karena siapapun dapat menjalankan penghitungan, tidak ada kemungkinan untuk menahan hasil dan oleh karena itu tidak ada kemampuan untuk memanipulasi hasil.
Risiko utama pada fungsi tertunda yang dapat diverifikasi adalah pengoptimalan yang tidak disengaja: seseorang menemukan bahwa menjalankan fungsi lebih cepat dari yang diharapkan dapat memanipulasi informasi yang diungkapkannya pada waktu T .
Pengoptimalan yang tidak terduga dapat terjadi dalam dua cara:
1. Akselerasi perangkat keras: Seseorang membuat ASIC yang dapat menjalankan loop komputasi lebih cepat daripada perangkat keras yang ada.
2. Paralelisasi yang tidak disengaja: Seseorang menemukan cara untuk menjalankan suatu fungsi lebih cepat dengan memparalelkannya, meskipun hal itu memerlukan sumber daya 100x lipat.
Tugas menciptakan VDF yang sukses adalah menghindari kedua masalah sekaligus menjaga efisiensi tetap praktis (misalnya satu masalah dengan pendekatan berbasis hash adalah bahwa pemeriksaan hash SNARK secara real time memerlukan perangkat keras yang berat). Akselerasi perangkat keras sering kali ditangani oleh pelaku kepentingan publik yang membuat dan mendistribusikan sendiri VDF ASIC yang hampir optimal.
Tautan ke penelitian yang ada
Situs web penelitian VDF: vdfresearch.org
Memikirkan serangan terhadap VDF di Ethereum, 2018: Memikirkan serangan
Serangan terhadap VDF MinRoot yang diusulkan: Serangan terhadap MinRoot
Apa saja upaya dan trade-off yang tersisa?
Saat ini, tidak ada konstruksi VDF yang sepenuhnya memenuhi persyaratan peneliti Ethereum di semua aspek. Masih diperlukan lebih banyak pekerjaan untuk menemukan fungsi tersebut. Jika ditemukan, trade-off utamanya adalah apakah akan menyertakannya: trade-off sederhana antara fungsionalitas dan kompleksitas protokol serta risiko keamanan.
Jika kita menganggap VDF aman, namun ternyata tidak aman, bergantung pada cara penerapannya, keamanan akan menurun sesuai asumsi RANDAO (1 kontrol per penyerang) atau sedikit lebih buruk. Oleh karena itu, bahkan jika VDF gagal, itu tidak akan merusak protokol, namun akan merusak aplikasi yang sangat bergantung padanya atau fitur protokol baru.
Bagaimana interaksinya dengan bagian lain dari peta jalan?
VDF adalah komponen protokol Ethereum yang relatif mandiri yang, selain menambah keamanan pada pemilihan pengusul, memiliki aplikasi dalam (i) aplikasi on-chain yang mengandalkan keacakan dan (ii) kumpulan memori kriptografi, meskipun berdasarkan pada pembuatan VDF kumpulan memori terenkripsi masih bergantung pada penemuan kriptografi tambahan yang belum terjadi.
Satu hal penting untuk diingat adalah, dengan mempertimbangkan ketidakpastian perangkat keras, terdapat beberapa "margin" antara pembangkitan keluaran VDF dan kebutuhan. Artinya informasi tersebut akan tersedia beberapa blok yang lalu. Ini mungkin merupakan biaya yang dapat diterima namun harus dipertimbangkan ketika menyelesaikan sebuah tangki atau panitia yang memilih desain.
Kebingungan dan tanda tangan satu kali: masa depan kriptografi yang jauh
Masalah apa yang dipecahkannya?
Salah satu artikel Nick Szabo yang paling terkenal adalah makalahnya pada tahun 1997 tentang "Perjanjian Tuhan". Dalam makalahnya, ia menunjukkan bahwa banyak aplikasi multi-pihak bergantung pada “pihak ketiga tepercaya” untuk mengelola interaksi. Dalam pandangannya, peran kriptografi adalah menciptakan simulasi pihak ketiga tepercaya yang melakukan pekerjaan yang sama tanpa benar-benar memerlukan kepercayaan pada peserta tertentu.
Sejauh ini kita hanya mampu mencapai sebagian cita-cita tersebut. Jika yang kita butuhkan hanyalah komputer virtual transparan yang data dan penghitungannya tidak dapat dimatikan, disensor, atau dirusak, dan privasi bukanlah tujuannya, maka blockchain dapat mencapai tujuan ini, meskipun dengan skalabilitas terbatas.
Jika privasi adalah tujuannya, maka hingga saat ini kami hanya dapat mengembangkan beberapa protokol spesifik untuk aplikasi spesifik: tanda tangan digital untuk otentikasi dasar, tanda tangan dering dan tanda tangan dering yang dapat ditautkan untuk anonimitas mentah, enkripsi berbasis identitas untuk Mengaktifkan enkripsi yang lebih nyaman dengan asumsi spesifik tentang penerbit terpercaya, tanda tangan buta untuk uang elektronik ala Chaim, dan banyak lagi. Pendekatan ini memerlukan banyak pekerjaan untuk setiap aplikasi baru.
Pada tahun 2010-an, kami pertama kali melihat sekilas pendekatan yang berbeda dan lebih kuat, yang didasarkan pada kriptografi yang dapat diprogram. Daripada membuat protokol baru untuk setiap aplikasi baru, kita dapat menggunakan protokol baru yang kuat—khususnya ZK-SNARK—untuk menambahkan jaminan kriptografi pada program arbitrer.
ZK-SNARK memungkinkan pengguna untuk membuktikan klaim sewenang-wenang tentang data yang mereka miliki, dan buktinya (i) mudah diverifikasi, dan (ii) tidak mengungkapkan data apa pun selain klaim itu sendiri. Ini merupakan peningkatan besar dalam hal privasi dan skalabilitas, dan saya menyamakannya dengan dampak transformator pada kecerdasan buatan. Lamaran ribuan orang selama bertahun-tahun pada suatu pekerjaan tertentu tiba-tiba digantikan oleh solusi universal yang dapat menangani berbagai macam masalah yang tidak terduga.
Namun, ZK-SNARK hanyalah yang pertama dari tiga primitif serba guna yang sangat kuat. Protokol-protokol ini sangat kuat sehingga ketika saya memikirkannya, mereka mengingatkan saya pada serangkaian kartu yang sangat kuat di (Yu-Gi-Oh!) - permainan kartu dan acara TV yang saya mainkan saat kecil: Kartu Dewa Mesir.
Kartu Dewa Mesir adalah tiga kartu yang sangat kuat, legenda mengatakan bahwa proses pembuatan kartu ini bisa mematikan, dan kekuatannya membuat kartu tersebut dilarang untuk digunakan dalam duel. Demikian pula, dalam kriptografi kita memiliki tiga protokol dewa Mesir:
Apa itu ZK-SNARK dan bagaimana cara kerjanya?
ZK-SNARK adalah salah satu dari tiga protokol yang kami miliki yang memiliki tingkat kematangan lebih tinggi. Selama lima tahun terakhir, peningkatan dramatis dalam kecepatan pembuktian dan keramahan pengembang telah menjadikan ZK-SNARK sebagai landasan skalabilitas dan strategi privasi Ethereum. Namun ZK-SNARK memiliki batasan penting: Anda perlu mengetahui data untuk membuktikannya. Setiap negara bagian dalam aplikasi ZK-SNARK harus memiliki "pemilik" unik yang harus hadir untuk menyetujui membaca atau menulis ke negara bagian tersebut.
Protokol kedua yang tidak memiliki batasan ini adalah enkripsi homomorfik penuh (FHE). FHE memungkinkan Anda melakukan komputasi apa pun pada data terenkripsi tanpa melihat datanya. Hal ini memungkinkan Anda melakukan komputasi pada data pengguna, demi kepentingan pengguna, sekaligus menjaga privasi data dan algoritme.
Ini juga memungkinkan Anda memperluas sistem pemungutan suara seperti MACI untuk jaminan keamanan dan privasi yang hampir sempurna. FHE telah lama dianggap terlalu tidak efisien untuk penggunaan praktis, namun kini FHE menjadi cukup efisien sehingga aplikasi praktis mulai bermunculan.
Kursif adalah aplikasi yang memanfaatkan komputasi dua pihak dan enkripsi homomorfik penuh (FHE) untuk penemuan kepentingan bersama yang menjaga privasi.
Namun, FHE memiliki keterbatasan: teknologi apa pun yang berbasis FHE masih memerlukan seseorang untuk memegang kunci dekripsinya. Ini bisa berupa pengaturan terdistribusi M-of-N, dan Anda bahkan dapat menambahkan perlindungan lapisan kedua menggunakan Trusted Execution Environments (TEEs), namun itu masih merupakan batasan.
Berikutnya adalah protokol ketiga yang lebih kuat daripada kombinasi dua protokol pertama: ketidakjelasan yang tidak dapat dibedakan. Meskipun teknologi ini masih jauh dari matang, pada tahun 2020 kami memiliki protokol yang secara teoritis valid berdasarkan asumsi keamanan standar dan baru-baru ini mulai mengerjakan implementasinya.
Kebingungan yang tidak dapat dibedakan memungkinkan Anda membuat "program terenkripsi" yang melakukan perhitungan sewenang-wenang sambil menyembunyikan semua detail internal program. Sebagai contoh sederhana, Anda dapat memasukkan kunci pribadi Anda ke dalam program yang dikaburkan yang hanya memungkinkan Anda menggunakannya untuk menandatangani bilangan prima, dan mendistribusikan program ini kepada orang lain. Mereka dapat menandatangani bilangan prima apa pun menggunakan program ini, tetapi tidak dapat mengekstrak kuncinya. Namun, kemampuannya lebih dari itu: dikombinasikan dengan hash, ia dapat digunakan untuk mengimplementasikan kriptografi primitif lainnya, dan banyak lagi.
Satu-satunya hal yang tidak dapat dilakukan oleh obfuscator yang tidak dapat dibedakan adalah mencegah dirinya disalin. Namun, pada titik ini, ada teknologi yang lebih kuat yang menunggu, meskipun teknologi ini bergantung pada setiap orang yang memiliki komputer kuantum: tanda tangan kuantum satu kali.
Dengan menggabungkan kebingungan dan tanda tangan satu kali, kita dapat membangun pihak ketiga yang hampir sempurna dan tidak dapat dipercaya. Satu-satunya tujuan yang tidak dapat dicapai hanya dengan kriptografi dan masih membutuhkan blockchain adalah ketahanan terhadap sensor. Teknologi ini tidak hanya membuat Ethereum menjadi lebih aman, namun juga memungkinkan aplikasi yang lebih kuat dibangun di atasnya.
Untuk lebih memahami bagaimana primitif ini menambahkan kemampuan tambahan, kami menggunakan voting sebagai contoh utama. Pemungutan suara merupakan masalah yang menarik karena harus memenuhi sejumlah properti keamanan yang kompleks, termasuk kemampuan verifikasi dan privasi yang sangat kuat. Meskipun protokol pemungutan suara dengan sifat keamanan yang kuat telah ada selama beberapa dekade, kita dapat mempersulit diri kita sendiri dan memerlukan desain yang dapat menangani protokol pemungutan suara sewenang-wenang: seperti pemungutan suara kuadrat, pendanaan kuadrat yang dibatasi secara berpasangan, pendanaan kuadrat yang disesuaikan dengan cluster, dll. tunggu dulu . Dengan kata lain, kami ingin langkah "penghitungan" menjadi prosedur yang sewenang-wenang.
Pertama, asumsikan kita mempublikasikan hasil pemungutan suara di blockchain. Hal ini memberi kita kemampuan untuk diverifikasi secara publik (siapa pun dapat memverifikasi kebenaran hasil akhir, termasuk aturan penghitungan suara dan kualifikasi) dan penolakan terhadap sensor (orang tidak dapat dilarang untuk memilih). Tapi kami tidak punya privasi.
Selanjutnya, kami menambahkan ZK-SNARK, dan sekarang kami memiliki privasi: setiap suara bersifat anonim sambil memastikan bahwa hanya pemilih yang berwenang yang dapat memilih, dan setiap pemilih hanya dapat memilih satu kali.
Selanjutnya, kami memperkenalkan mekanisme MACI, dimana suara dienkripsi ke kunci dekripsi server pusat. Server pusat bertugas melakukan proses penghitungan suara, termasuk menghilangkan duplikat suara, dan mengeluarkan hasil bukti ZK-SNARK. Hal ini mempertahankan jaminan sebelumnya (bahkan jika server curang!), namun juga menambahkan jaminan tahan paksaan jika server jujur: pengguna tidak dapat membuktikan cara mereka memilih, meskipun mereka menginginkannya. Hal ini karena meskipun pengguna dapat membuktikan suara mereka, mereka tidak dapat membuktikan bahwa mereka tidak memilih untuk mengimbangi suara tersebut. Hal ini mencegah penyuapan dan serangan lainnya.
Kami menjalankan penghitungan suara di FHE diikuti dengan penghitungan dekripsi ambang batas N/2-of-N. Hal ini meningkatkan jaminan resistensi paksaan menjadi N/2-of-N, bukan 1-of-1.
Kami mengaburkan program penghitungan suara dan merancang program kebingungan sehingga hanya dapat menampilkan hasil jika diotorisasi. Metode otorisasi dapat berupa bukti konsensus blockchain, semacam bukti kerja, atau kombinasi keduanya. Hal ini membuat jaminan anti-paksaan hampir sempurna: dalam kasus konsensus blockchain, 51% validator harus berkolusi untuk melakukan crack; dalam kasus bukti kerja, bahkan jika semua orang berkolusi, suara akan dihitung ulang dengan kelompok pemilih yang berbeda untuk dicoba. Tindakan mengekstraksi pemilih perorangan juga akan memakan biaya yang sangat mahal. Kita bahkan dapat meminta program ini melakukan penyesuaian kecil secara acak terhadap penghitungan suara akhir untuk semakin meningkatkan kesulitan dalam mengekstraksi perilaku masing-masing pemilih.
Kami menambahkan tanda tangan satu kali, sebuah sistem primitif yang mengandalkan komputasi kuantum untuk memungkinkan tanda tangan hanya digunakan sekali untuk jenis informasi tertentu. Hal ini membuat jaminan anti-kekuatan benar-benar sempurna.
Kebingungan yang tidak dapat dibedakan juga mendukung aplikasi canggih lainnya. Misalnya:
1. Organisasi otonom terdesentralisasi (DAO), lelang on-chain, dan aplikasi lain dengan status rahasia internal yang sewenang-wenang.
2. Pengaturan tepercaya yang benar-benar universal: seseorang dapat membuat program yang dikaburkan yang berisi kunci, dan menjalankan program apa pun dan memberikan keluaran, dengan memasukkan hash(kunci, program) sebagai masukan ke dalam program. Dengan adanya program seperti itu, siapa pun dapat memasukkan Program 3 ke dalam dirinya sendiri, menggabungkan kunci program yang telah dikunci sebelumnya dengan miliknya sendiri, sehingga memperluas pengaturannya. Ini dapat digunakan untuk menghasilkan pengaturan tepercaya 1-of-N untuk protokol apa pun.
3. Verifikasi ZK-SNARK hanya memerlukan tanda tangan: Penerapannya sangat sederhana: Siapkan lingkungan tepercaya dan minta seseorang membuat program yang dikaburkan yang hanya akan menandatangani pesan dengan kunci jika terdapat ZK-SNARK yang valid.
4. Kumpulan memori terenkripsi: Mengenkripsi transaksi menjadi sangat sederhana, sehingga transaksi hanya dapat didekripsi ketika peristiwa on-chain tertentu terjadi di masa mendatang. Ini bahkan dapat mencakup Fungsi Penundaan Verifikasi (VDF) yang berhasil dijalankan.
Dengan tanda tangan satu kali, kita dapat membuat blockchain kebal terhadap serangan 51% pada pembalikan finalitas, meskipun serangan sensor masih mungkin terjadi. Hal-hal primitif seperti tanda tangan satu kali memungkinkan mata uang kuantum, memecahkan masalah pembelanjaan ganda tanpa blockchain, meskipun banyak aplikasi yang lebih kompleks masih memerlukan rantai.
Jika sistem primitif ini dapat dibuat cukup efisien, sebagian besar aplikasi di dunia dapat didesentralisasi. Hambatan utama adalah memverifikasi kebenaran implementasi.
Berikut ini tautan ke beberapa penelitian yang ada:
1. Protokol Kebingungan yang Tidak Dapat Dibedakan (2021): Kebingungan yang Tidak Dapat Dibedakan
2. Bagaimana Kebingungan Dapat Membantu Ethereum: Bagaimana Kebingungan Dapat Membantu Ethereum
3. Pembuatan Tanda Tangan Sekali Pakai yang Pertama Diketahui: Pembuatan Tanda Tangan Sekali Pakai yang Pertama Diketahui
4. Percobaan Penerapan Kebingungan (1): Percobaan Penerapan Kebingungan (1)
5. Percobaan Penerapan Kebingungan (2): Percobaan Penerapan Kebingungan (2)
Pekerjaan apa yang masih harus dilakukan, dan apa saja dampaknya?
Masih banyak pekerjaan yang harus diselesaikan, kebingungan yang tidak bisa dibedakan masih sangat belum matang, dan konstruksi kandidat berjalan sangat lambat (jika tidak lebih) agar berguna dalam aplikasi. Kebingungan yang tidak dapat dibedakan diketahui memerlukan waktu polinomial "teoretis", namun dalam penerapan praktisnya dapat berlangsung lebih lama daripada masa hidup alam semesta. Protokol terbaru telah menunjukkan beberapa perbaikan dalam waktu proses, namun biaya overhead masih terlalu tinggi untuk penggunaan rutin: salah satu pelaksana memperkirakan waktu proses adalah satu tahun.
Komputer kuantum bahkan belum ada: semua konstruksi yang Anda lihat di internet adalah prototipe yang tidak dapat melakukan lebih dari 4 bit, atau mereka sama sekali bukan komputer kuantum yang substansial, dan meskipun mereka mungkin memiliki bagian kuantum, mereka tidak dapat menjalankan hal-hal seperti algoritma Shor Atau perhitungan yang berarti seperti algoritma Grover. Ada tanda-tanda baru-baru ini bahwa komputer kuantum "nyata" sudah dekat. Namun, bahkan jika komputer kuantum "nyata" segera tersedia, rata-rata orang yang menggunakan komputer kuantum di laptop atau ponsel mereka mungkin masih harus menunggu beberapa dekade sebelum lembaga yang kuat dapat memecahkan kriptografi kurva elips.
Untuk kebingungan yang tidak bisa dibedakan, trade-off utamanya terletak pada asumsi keamanan, dan ada desain yang lebih radikal yang menggunakan asumsi khusus. Desain ini umumnya memiliki runtime yang lebih realistis, namun asumsi khusus terkadang dilanggar. Seiring waktu, kita mungkin akan memahami kisi-kisi tersebut dengan lebih baik, sehingga memungkinkan kita merumuskan hipotesis yang tidak mudah dipatahkan. Namun, jalur ini lebih berisiko. Pendekatan yang lebih konservatif adalah dengan tetap menggunakan protokol yang keamanannya terbukti direduksi menjadi asumsi "standar", namun hal ini mungkin berarti diperlukan waktu lebih lama sebelum kita mendapatkan protokol yang berjalan cukup cepat.
Bagaimana cara berinteraksi dengan bagian lain dari peta jalan?
Kriptografi yang sangat kuat dapat merevolusi permainan, seperti:
1. Jika kami mendapatkan ZK-SNARK yang verifikasinya semudah penandatanganan, maka kami mungkin tidak lagi memerlukan protokol agregasi apa pun; kami dapat memverifikasi secara langsung secara on-chain.
2. Penandatanganan satu kali dapat berarti protokol bukti kepemilikan yang lebih aman.
3. Banyak protokol privasi kompleks yang mungkin hanya perlu diganti dengan Mesin Virtual Ethereum (EVM) yang menjaga privasi.
4. Kumpulan memori terenkripsi menjadi lebih mudah diimplementasikan.
Pada awalnya, keuntungan akan terjadi pada lapisan aplikasi, karena L1 Ethereum secara inheren harus konservatif dalam asumsi keamanannya. Namun, penggunaan lapisan aplikasi saja dapat mengganggu, seperti halnya munculnya ZK-SNARKs.
Tautan asli
