Vitalik tentang kemungkinan masa depan Ethereum (enam): The Splurge

Dalam desain protokol Ethereum, sekitar setengah dari kontennya berkaitan dengan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik khusus—itulah makna dari "Splurge" (kemakmuran).

Judul Asli: "Possible futures of the Ethereum protocol, part 6: The Splurge"

Penulis: Vitalik Buterin

Penerjemah: zhouzhou, BlockBeats

Berikut adalah isi artikel asli (beberapa bagian telah disusun ulang untuk memudahkan pemahaman):

Beberapa hal sulit dikategorikan ke dalam satu kategori saja. Dalam desain protokol Ethereum, terdapat banyak "detail" yang sangat penting bagi keberhasilan Ethereum. Faktanya, sekitar setengah dari kontennya berkaitan dengan berbagai jenis peningkatan EVM, sementara sisanya terdiri dari berbagai topik khusus—itulah makna dari "Splurge" (kemakmuran).

Peta Jalan 2023: Splurge

Splurge: Tujuan Utama

• Mengubah EVM menjadi "status akhir" yang berkinerja tinggi dan stabil
• Memperkenalkan abstraksi akun ke dalam protokol, memungkinkan semua pengguna menikmati akun yang lebih aman dan nyaman
• Mengoptimalkan ekonomi biaya transaksi, meningkatkan skalabilitas sekaligus mengurangi risiko
• Mengeksplorasi kriptografi canggih untuk meningkatkan Ethereum secara signifikan dalam jangka panjang

Peningkatan EVM

Masalah apa yang diselesaikan?

Saat ini, EVM sulit untuk dianalisis secara statis, yang membuat pembuatan implementasi yang efisien, verifikasi kode formal, dan ekspansi lebih lanjut menjadi sulit. Selain itu, efisiensi EVM relatif rendah, sehingga sulit untuk mengimplementasikan banyak bentuk kriptografi tingkat lanjut kecuali didukung secara eksplisit melalui precompile.

Apa itu dan bagaimana cara kerjanya?

Langkah pertama dalam peta jalan peningkatan EVM saat ini adalah EVM Object Format (EOF), yang direncanakan akan dimasukkan dalam hard fork berikutnya. EOF adalah serangkaian EIP yang menentukan versi kode EVM baru dengan banyak fitur unik, yang paling menonjol adalah:

• Pemisahan antara kode (dapat dieksekusi tetapi tidak dapat dibaca dari EVM) dan data (dapat dibaca tetapi tidak dapat dieksekusi)
• Melarang lompatan dinamis, hanya mengizinkan lompatan statis
• Kode EVM tidak lagi dapat mengamati informasi terkait gas
• Menambahkan mekanisme subrutin eksplisit yang baru

Struktur kode EOF

Splurge: Peningkatan EVM (lanjutan)

Kontrak lama akan tetap ada dan dapat dibuat, meskipun pada akhirnya kontrak lama mungkin akan dihentikan secara bertahap (bahkan mungkin dipaksa untuk dikonversi ke kode EOF). Kontrak baru akan mendapat manfaat dari peningkatan efisiensi yang dibawa oleh EOF—pertama melalui pengurangan ukuran bytecode berkat fitur subrutin, kemudian melalui fitur baru khusus EOF atau pengurangan biaya gas.

Setelah pengenalan EOF, peningkatan lebih lanjut menjadi lebih mudah. Saat ini, yang paling berkembang adalah EVM Modular Arithmetic eXtensions (EVM-MAX). EVM-MAX menciptakan seperangkat operasi baru yang khusus untuk operasi modular, dan menempatkannya di ruang memori baru yang tidak dapat diakses oleh opcode lain, memungkinkan optimasi seperti Montgomery multiplication.

Ide yang lebih baru adalah menggabungkan EVM-MAX dengan fitur Single Instruction Multiple Data (SIMD). SIMD telah menjadi konsep di Ethereum untuk waktu yang lama, pertama kali diusulkan oleh Greg Colvin melalui EIP-616. SIMD dapat digunakan untuk mempercepat berbagai bentuk kriptografi, termasuk fungsi hash, STARKs 32-bit, dan kriptografi berbasis lattice. Kombinasi EVM-MAX dan SIMD membuat kedua ekstensi yang berorientasi pada performa ini menjadi pasangan alami.

Desain kasar dari EIP gabungan akan dimulai dari EIP-6690, lalu:

• Mengizinkan (i) bilangan ganjil mana pun atau (ii) pangkat dua hingga 2768 sebagai modulus
• Untuk setiap opcode EVM-MAX (penjumlahan, pengurangan, perkalian), menambahkan versi yang tidak lagi menggunakan 3 bilangan langsung x, y, z, melainkan menggunakan 7 bilangan langsung: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Dalam kode Python, opcode ini bekerja seperti:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Dalam implementasi nyata, ini akan diproses secara paralel.

• Mungkin menambahkan XOR, AND, OR, NOT, dan SHIFT (termasuk rotasi dan non-rotasi), setidaknya untuk modulus pangkat dua. Juga menambahkan ISZERO (yang mendorong output ke stack utama EVM), yang cukup kuat untuk mengimplementasikan kriptografi kurva eliptik, kriptografi bidang kecil (seperti Poseidon, Circle STARKs), fungsi hash tradisional (seperti SHA256, KECCAK, BLAKE), dan kriptografi berbasis lattice. Peningkatan EVM lainnya juga mungkin diimplementasikan, tetapi sejauh ini mendapat perhatian lebih sedikit.

Tautan penelitian yang ada

• EOF: 
• EVM-MAX: 
• SIMD: 

Pekerjaan yang tersisa dan pertimbangan

Saat ini, EOF direncanakan akan dimasukkan dalam hard fork berikutnya. Meskipun selalu ada kemungkinan untuk menghapusnya di saat-saat terakhir—fitur pernah dihapus sementara pada hard fork sebelumnya—tetapi melakukan hal tersebut akan menghadapi tantangan besar. Menghapus EOF berarti peningkatan EVM di masa depan harus dilakukan tanpa EOF, meskipun bisa dilakukan, namun mungkin akan lebih sulit.

Pertimbangan utama EVM adalah kompleksitas L1 versus kompleksitas infrastruktur. EOF adalah sejumlah besar kode yang perlu ditambahkan ke implementasi EVM, dan pemeriksaan kode statis juga relatif kompleks. Namun, sebagai gantinya, kita dapat menyederhanakan bahasa tingkat tinggi, menyederhanakan implementasi EVM, dan manfaat lainnya. Bisa dikatakan, peta jalan yang memprioritaskan peningkatan berkelanjutan L1 Ethereum harus mencakup dan dibangun di atas EOF.

Pekerjaan penting yang perlu dilakukan adalah mengimplementasikan fitur seperti EVM-MAX plus SIMD, dan melakukan benchmark konsumsi gas untuk berbagai operasi kriptografi.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

L1 yang menyesuaikan EVM-nya membuat L2 juga lebih mudah melakukan penyesuaian serupa; jika keduanya tidak melakukan penyesuaian secara sinkron, bisa terjadi ketidakcocokan yang berdampak buruk. Selain itu, EVM-MAX dan SIMD dapat menurunkan biaya gas untuk banyak sistem pembuktian, sehingga membuat L2 lebih efisien. Ini juga memudahkan untuk menggantikan lebih banyak precompile dengan kode EVM yang dapat melakukan tugas yang sama, mungkin tanpa berdampak besar pada efisiensi.

Abstraksi Akun

Masalah apa yang diselesaikan?

Saat ini, transaksi hanya dapat diverifikasi dengan satu cara: tanda tangan ECDSA. Awalnya, abstraksi akun bertujuan untuk melampaui ini, memungkinkan logika verifikasi akun menjadi kode EVM apa pun. Ini dapat mengaktifkan berbagai aplikasi:

• Beralih ke kriptografi tahan kuantum
• Rotasi kunci lama (secara luas dianggap sebagai praktik keamanan yang direkomendasikan)
• Dompet multisig dan dompet pemulihan sosial
• Menggunakan satu kunci untuk operasi bernilai rendah, dan kunci lain (atau sekelompok kunci) untuk operasi bernilai tinggi

Memungkinkan protokol privasi bekerja tanpa relayer, secara signifikan mengurangi kompleksitasnya dan menghilangkan satu titik ketergantungan sentral yang penting

Sejak abstraksi akun diusulkan pada 2015, tujuannya juga telah berkembang mencakup banyak "tujuan kenyamanan", misalnya, akun yang tidak memiliki ETH tetapi memiliki beberapa ERC20 dapat membayar gas dengan ERC20. Berikut adalah diagram ringkasan tujuan-tujuan tersebut:

MPC (Multi-Party Computation) adalah teknologi yang telah ada selama 40 tahun, digunakan untuk membagi kunci menjadi beberapa bagian dan menyimpannya di beberapa perangkat, menggunakan teknik kriptografi untuk menghasilkan tanda tangan tanpa harus menggabungkan bagian-bagian kunci tersebut secara langsung.

EIP-7702 adalah proposal yang direncanakan akan diperkenalkan pada hard fork berikutnya. EIP-7702 adalah hasil dari meningkatnya kesadaran untuk menyediakan kenyamanan abstraksi akun bagi semua pengguna (termasuk pengguna EOA), dengan tujuan meningkatkan pengalaman semua pengguna dalam jangka pendek dan menghindari perpecahan menjadi dua ekosistem.

Pekerjaan ini dimulai dari EIP-3074, dan akhirnya membentuk EIP-7702. EIP-7702 memberikan "fitur kenyamanan" abstraksi akun kepada semua pengguna, termasuk EOA (Externally Owned Account, yaitu akun yang dikontrol oleh tanda tangan ECDSA) saat ini.

Dari diagram, dapat dilihat bahwa meskipun beberapa tantangan (terutama tantangan "kenyamanan") dapat diselesaikan dengan teknologi bertahap seperti MPC atau EIP-7702, tujuan keamanan utama dari proposal abstraksi akun yang awalnya diusulkan hanya dapat dicapai dengan kembali ke dan menyelesaikan masalah aslinya: memungkinkan kode kontrak pintar mengontrol verifikasi transaksi. Alasan mengapa ini belum terwujud hingga saat ini adalah karena implementasinya secara aman merupakan tantangan.

Apa itu dan bagaimana cara kerjanya?

Inti dari abstraksi akun sangat sederhana: memungkinkan kontrak pintar untuk memulai transaksi, bukan hanya EOA. Seluruh kompleksitas berasal dari bagaimana mengimplementasikannya dengan cara yang ramah terhadap pemeliharaan jaringan terdesentralisasi dan mencegah serangan penolakan layanan (DoS).

Salah satu tantangan utama adalah masalah kegagalan ganda:

Jika ada 1000 akun dengan fungsi verifikasi yang semuanya bergantung pada satu nilai S, dan nilai S saat ini membuat transaksi di mempool valid, maka satu transaksi yang mengubah nilai S dapat membuat semua transaksi lain di mempool menjadi tidak valid. Ini memungkinkan penyerang mengirim transaksi sampah ke mempool dengan biaya sangat rendah, sehingga membebani sumber daya node jaringan.

Setelah bertahun-tahun upaya untuk memperluas fungsionalitas sambil membatasi risiko DoS, akhirnya ditemukan solusi untuk mewujudkan "abstraksi akun ideal": ERC-4337.

Cara kerja ERC-4337 adalah memproses operasi pengguna dalam dua tahap: verifikasi dan eksekusi. Semua verifikasi diproses terlebih dahulu, semua eksekusi diproses setelahnya. Di mempool, hanya operasi pengguna yang tahap verifikasinya hanya melibatkan akun itu sendiri dan tidak membaca variabel lingkungan yang akan diterima. Ini mencegah serangan kegagalan ganda. Selain itu, batas gas yang ketat juga diterapkan pada langkah verifikasi.

ERC-4337 dirancang sebagai standar protokol tambahan (ERC), karena pada saat itu pengembang klien Ethereum fokus pada Merge dan tidak memiliki sumber daya untuk menangani fitur lain. Itulah mengapa ERC-4337 menggunakan objek yang disebut user operation, bukan transaksi biasa. Namun, baru-baru ini kami menyadari perlunya menuliskan setidaknya sebagian dari fitur ini ke dalam protokol.

Dua alasan utama adalah:

1. EntryPoint sebagai kontrak secara inheren tidak efisien: setiap bundel memiliki overhead tetap sekitar 100.000 gas, dan setiap operasi pengguna menambah ribuan gas lagi.
2. Kebutuhan untuk memastikan properti Ethereum: seperti jaminan inklusi yang diciptakan oleh inclusion list perlu dialihkan ke pengguna abstraksi akun.

Selain itu, ERC-4337 juga memperluas dua fitur:

• Paymasters: fitur yang memungkinkan satu akun membayar biaya untuk akun lain, yang melanggar aturan bahwa tahap verifikasi hanya dapat mengakses akun pengirim itu sendiri, sehingga penanganan khusus diperkenalkan untuk memastikan keamanan mekanisme paymaster.
• Aggregators: mendukung fitur agregasi tanda tangan, seperti agregasi BLS atau agregasi berbasis SNARK. Ini diperlukan untuk mencapai efisiensi data maksimum di Rollup.

Tautan penelitian yang ada

• Presentasi tentang sejarah abstraksi akun:
• ERC-4337:
• EIP-7702:
• Kode BLSWallet (menggunakan fitur agregasi):
• EIP-7562 (abstraksi akun yang ditulis ke protokol):
• EIP-7701 (abstraksi akun berbasis EOF yang ditulis ke protokol):

Pekerjaan yang tersisa dan pertimbangan

Saat ini, yang utama perlu diselesaikan adalah bagaimana sepenuhnya memasukkan abstraksi akun ke dalam protokol. EIP abstraksi akun yang ditulis ke protokol dan baru-baru ini populer adalah EIP-7701, yang mengimplementasikan abstraksi akun di atas EOF. Sebuah akun dapat memiliki bagian kode terpisah untuk verifikasi; jika akun mengatur bagian kode tersebut, maka kode itu akan dijalankan selama langkah verifikasi transaksi dari akun tersebut.

Keunikan pendekatan ini adalah, ia dengan jelas menunjukkan dua perspektif ekuivalen dari abstraksi akun native:

1. Menjadikan EIP-4337 sebagai bagian dari protokol
2. Jenis EOA baru, di mana algoritma tanda tangan adalah eksekusi kode EVM

Jika kita memulai dengan batasan ketat pada kompleksitas kode yang dapat dieksekusi selama verifikasi—tidak mengizinkan akses ke status eksternal, bahkan batas gas awal yang sangat rendah sehingga tidak efektif untuk aplikasi tahan kuantum atau perlindungan privasi—maka keamanan pendekatan ini sangat jelas: hanya mengganti verifikasi ECDSA dengan eksekusi kode EVM yang membutuhkan waktu serupa.

Namun, seiring waktu, kita perlu melonggarkan batasan ini, karena memungkinkan aplikasi perlindungan privasi bekerja tanpa relayer dan ketahanan terhadap kuantum sangat penting. Untuk itu, kita perlu menemukan cara yang lebih fleksibel untuk mengatasi risiko DoS, tanpa mengharuskan langkah verifikasi harus sangat sederhana.

Pertimbangan utama tampaknya adalah "menulis cepat solusi yang memuaskan lebih sedikit orang" versus "menunggu lebih lama, mungkin mendapatkan solusi yang lebih ideal", dan pendekatan ideal mungkin adalah metode campuran. Salah satu metode campuran adalah menulis lebih cepat untuk beberapa use case, dan memberikan lebih banyak waktu untuk mengeksplorasi use case lain. Metode lain adalah pertama-tama menerapkan versi abstraksi akun yang lebih ambisius di L2. Namun, tantangannya adalah tim L2 harus sangat yakin dengan proposal yang diadopsi agar mau mengimplementasikannya, terutama untuk memastikan L1 dan/atau L2 lain di masa depan dapat mengadopsi solusi yang kompatibel.

Aplikasi lain yang perlu dipertimbangkan secara eksplisit adalah akun penyimpanan kunci, yaitu akun yang menyimpan status terkait akun di L1 atau L2 khusus, tetapi dapat digunakan di L1 dan L2 kompatibel mana pun. Melakukan ini secara efektif mungkin memerlukan L2 untuk mendukung opcode seperti L1SLOAD atau REMOTESTATICCALL, tetapi ini juga memerlukan implementasi abstraksi akun di L2 yang mendukung operasi tersebut.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Inclusion list perlu mendukung transaksi abstraksi akun. Dalam praktiknya, kebutuhan inclusion list sangat mirip dengan kebutuhan mempool terdesentralisasi, meskipun inclusion list sedikit lebih fleksibel. Selain itu, implementasi abstraksi akun harus dikoordinasikan sebanyak mungkin antara L1 dan L2. Jika di masa depan kita mengharapkan sebagian besar pengguna menggunakan key storage Rollup, desain abstraksi akun harus didasarkan pada hal tersebut.

Peningkatan EIP-1559

Masalah apa yang diselesaikan?

EIP-1559 diaktifkan di Ethereum pada tahun 2021, secara signifikan meningkatkan waktu rata-rata penyertaan blok.

Waktu tunggu

Namun, implementasi EIP-1559 saat ini tidak sempurna dalam beberapa aspek:

1. Formulanya agak cacat: ia tidak menargetkan 50% blok penuh, melainkan sekitar 50-53% blok penuh, tergantung pada varians (ini berkaitan dengan "ketidaksamaan rata-rata aritmatika-geometri" dalam matematika).
2. Penyesuaian tidak cukup cepat dalam situasi ekstrem.

Formula yang digunakan untuk blobs (EIP-4844) dirancang khusus untuk mengatasi masalah pertama, dan secara keseluruhan juga lebih sederhana. Namun, baik EIP-1559 maupun EIP-4844 tidak mencoba mengatasi masalah kedua. Oleh karena itu, status saat ini adalah keadaan peralihan yang membingungkan, melibatkan dua mekanisme berbeda, dan ada pandangan bahwa seiring waktu, keduanya perlu ditingkatkan.

Selain itu, ada kelemahan lain dalam penetapan harga sumber daya Ethereum yang tidak terkait dengan EIP-1559, tetapi dapat diatasi dengan penyesuaian EIP-1559. Salah satu masalah utama adalah perbedaan antara kasus rata-rata dan kasus terburuk: harga sumber daya di Ethereum harus ditetapkan untuk menangani kasus terburuk, yaitu satu blok yang menggunakan seluruh konsumsi gas untuk satu sumber daya, tetapi penggunaan rata-rata sebenarnya jauh di bawah itu, menyebabkan inefisiensi.

Apa itu Multi-dimensional Gas dan bagaimana cara kerjanya?

Solusi untuk masalah inefisiensi ini adalah Multi-dimensional Gas: menetapkan harga dan batas yang berbeda untuk sumber daya yang berbeda. Konsep ini secara teknis independen dari EIP-1559, tetapi keberadaan EIP-1559 membuat implementasinya lebih mudah. Tanpa EIP-1559, mengemas blok yang optimal dengan berbagai batas sumber daya adalah masalah knapsack multidimensi yang rumit. Dengan EIP-1559, sebagian besar blok tidak mencapai batas pada sumber daya apa pun, sehingga algoritma sederhana "terima transaksi mana pun yang membayar biaya cukup" sudah cukup.

Saat ini kita sudah memiliki Multi-dimensional Gas untuk eksekusi dan data blob; secara prinsip, kita dapat memperluasnya ke lebih banyak dimensi: seperti calldata (data transaksi), pembacaan/penulisan status, dan ekspansi ukuran status.

EIP-7706 memperkenalkan dimensi gas baru khusus untuk calldata. Pada saat yang sama, ia juga menyederhanakan mekanisme Multi-dimensional Gas dengan menyatukan tiga jenis gas ke dalam satu kerangka kerja (gaya EIP-4844), sehingga juga mengatasi cacat matematika EIP-1559. EIP-7623 adalah solusi yang lebih presisi, menargetkan masalah sumber daya kasus rata-rata dan terburuk dengan membatasi maksimum calldata secara lebih ketat tanpa memperkenalkan seluruh dimensi baru.

Arah penelitian lebih lanjut adalah mengatasi masalah laju pembaruan, mencari algoritma perhitungan biaya dasar yang lebih cepat sambil mempertahankan invarians penting yang diperkenalkan oleh mekanisme EIP-4844 (yaitu: dalam jangka panjang, penggunaan rata-rata tepat mendekati nilai target).

Tautan penelitian yang ada

• FAQ EIP-1559: 
• Analisis empiris tentang EIP-1559: 
• Proposal peningkatan untuk penyesuaian cepat: 
• Bagian tentang mekanisme biaya dasar di FAQ EIP-4844: 
• EIP-7706: 
• EIP-7623: 
• Multi-dimensional Gas: 

Apa pekerjaan yang tersisa dan pertimbangannya?

Ada dua pertimbangan utama untuk Multi-dimensional Gas:

1. Menambah kompleksitas protokol: memperkenalkan Multi-dimensional Gas membuat protokol menjadi lebih kompleks.
2. Menambah kompleksitas algoritma optimal untuk mengisi blok: algoritma terbaik untuk mengisi blok hingga kapasitas juga menjadi lebih kompleks.

Kompleksitas protokol relatif kecil untuk calldata, tetapi untuk dimensi gas di dalam EVM (seperti pembacaan dan penulisan penyimpanan), kompleksitasnya meningkat. Masalahnya adalah, tidak hanya pengguna yang menetapkan batas gas, kontrak juga menetapkan batas saat memanggil kontrak lain. Saat ini, mereka hanya dapat menetapkan batas satu dimensi.

Salah satu solusi sederhana adalah membuat Multi-dimensional Gas hanya tersedia di dalam EOF, karena EOF tidak mengizinkan kontrak menetapkan batas gas saat memanggil kontrak lain. Kontrak non-EOF harus membayar semua jenis biaya gas untuk operasi penyimpanan (misal, jika SLOAD menggunakan 0,03% dari batas gas akses penyimpanan blok, maka pengguna non-EOF juga akan dikenakan biaya 0,03% dari batas gas eksekusi).

Penelitian lebih lanjut tentang Multi-dimensional Gas akan membantu memahami pertimbangan ini dan menemukan titik keseimbangan yang ideal.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Keberhasilan implementasi Multi-dimensional Gas dapat secara signifikan mengurangi penggunaan sumber daya "kasus terburuk" tertentu, sehingga mengurangi tekanan untuk mengoptimalkan performa, misalnya untuk kebutuhan pohon biner berbasis hash STARK. Menetapkan target yang jelas untuk pertumbuhan ukuran status akan memudahkan pengembang klien untuk merencanakan dan memperkirakan kebutuhan di masa depan.

Seperti disebutkan sebelumnya, keberadaan EOF membuat implementasi versi Multi-dimensional Gas yang lebih ekstrem menjadi lebih sederhana, karena sifat gas yang tidak dapat diamati.

Verifiable Delay Functions (VDFs)

Masalah apa yang diselesaikan?

Saat ini, Ethereum menggunakan randomisasi berbasis RANDAO untuk memilih proposer. Randomisasi RANDAO bekerja dengan meminta setiap proposer mengungkapkan rahasia yang telah mereka komit sebelumnya, dan setiap rahasia yang diungkapkan dicampur ke dalam randomisasi.

Setiap proposer dengan demikian memiliki "1 bit kekuatan manipulasi": mereka dapat mengubah randomisasi dengan tidak muncul (dengan biaya). Cara ini masuk akal untuk pemilihan proposer, karena kemungkinan Anda melepaskan satu kesempatan untuk mendapatkan dua kesempatan baru sangat kecil. Namun, untuk aplikasi on-chain yang membutuhkan randomisasi, ini tidak ideal. Idealnya, kita harus menemukan sumber randomisasi yang lebih kuat.

Apa itu VDF dan bagaimana cara kerjanya?

Verifiable Delay Function adalah fungsi yang hanya dapat dihitung secara berurutan dan tidak dapat dipercepat dengan paralelisasi. Contoh sederhana adalah hash berulang: for i in range(10**9): x = hash(x). Hasil output, dengan bukti SNARK atas kebenarannya, dapat digunakan sebagai nilai acak.

Idenya adalah memilih input berdasarkan informasi yang tersedia pada waktu T, sementara output pada waktu T belum diketahui: output hanya akan tersedia setelah seseorang benar-benar menjalankan perhitungan setelah waktu T. Karena siapa pun dapat menjalankan perhitungan, tidak ada kemungkinan menyembunyikan hasil, sehingga tidak ada kemampuan untuk memanipulasi hasil.

Risiko utama VDF adalah optimasi tak terduga: seseorang menemukan cara menjalankan fungsi lebih cepat dari yang diharapkan, sehingga dapat memanipulasi informasi yang diungkapkan pada waktu T.

Optimasi tak terduga dapat terjadi dengan dua cara:

1. Percepatan perangkat keras: seseorang membuat ASIC yang menjalankan loop perhitungan lebih cepat dari perangkat keras yang ada.
2. Paralelisasi tak terduga: seseorang menemukan cara menjalankan fungsi secara paralel dengan kecepatan lebih tinggi, meskipun membutuhkan 100 kali sumber daya.

Tugas menciptakan VDF yang sukses adalah menghindari kedua masalah ini, sambil tetap menjaga efisiensi yang praktis (misalnya, metode berbasis hash memiliki masalah karena membuktikan hash secara real-time dengan SNARK membutuhkan perangkat keras berat). Percepatan perangkat keras biasanya diatasi dengan peserta kepentingan publik yang membuat dan mendistribusikan ASIC VDF yang hampir optimal.

Tautan penelitian yang ada

• Situs penelitian VDF: 
• Pemikiran tentang serangan VDF di Ethereum, 2018: 
• Serangan terhadap VDF MinRoot yang diusulkan: 

Pekerjaan yang tersisa dan pertimbangan

Saat ini, belum ada konstruksi VDF yang sepenuhnya memenuhi semua persyaratan peneliti Ethereum. Masih diperlukan lebih banyak pekerjaan untuk menemukan fungsi seperti itu. Jika ditemukan, pertimbangan utamanya adalah apakah akan memasukkannya: pertimbangan sederhana antara fungsionalitas dan kompleksitas protokol serta risiko keamanan.

Jika kita menganggap VDF aman, tetapi ternyata tidak, maka tergantung pada implementasinya, keamanannya akan menurun ke asumsi RANDAO (setiap penyerang memiliki 1 bit kekuatan manipulasi) atau sedikit lebih buruk. Jadi, bahkan jika VDF gagal, itu tidak akan merusak protokol, tetapi akan merusak aplikasi yang sangat bergantung padanya atau fitur protokol baru apa pun.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

VDF adalah bagian yang relatif terisolasi dalam protokol Ethereum. Selain meningkatkan keamanan pemilihan proposer, VDF juga memiliki aplikasi di (i) aplikasi on-chain yang bergantung pada randomisasi dan (ii) mempool terenkripsi, meskipun membuat mempool terenkripsi berbasis VDF masih bergantung pada penemuan kriptografi tambahan yang belum terjadi.

Satu hal yang perlu diingat adalah, mengingat ketidakpastian perangkat keras, akan ada "buffer" antara waktu output VDF dihasilkan dan waktu dibutuhkan. Ini berarti informasi akan tersedia beberapa blok sebelumnya. Ini bisa menjadi biaya yang dapat diterima, tetapi harus dipertimbangkan dalam desain finalitas satu slot atau pemilihan komite.

Obfuscation dan Tanda Tangan Sekali Pakai: Masa Depan Kriptografi yang Jauh

Masalah apa yang diselesaikan?

Salah satu artikel Nick Szabo yang paling terkenal adalah makalahnya tahun 1997 tentang "God Protocol". Dalam makalah tersebut, ia menunjukkan bahwa banyak aplikasi multi-pihak bergantung pada "pihak ketiga tepercaya" untuk mengelola interaksi. Menurutnya, peran kriptografi adalah menciptakan pihak ketiga tepercaya simulasi yang melakukan pekerjaan yang sama, tanpa benar-benar membutuhkan kepercayaan pada peserta tertentu.

Sejauh ini, kita hanya dapat mewujudkan sebagian dari ideal ini. Jika yang kita butuhkan hanyalah komputer virtual transparan, dengan data dan komputasi yang tidak dapat dimatikan, disensor, atau dimanipulasi, dan privasi bukanlah tujuan, maka blockchain dapat mewujudkan tujuan ini, meskipun skalabilitasnya terbatas.

Jika privasi adalah tujuannya, hingga baru-baru ini, kita hanya dapat mengembangkan beberapa protokol khusus untuk aplikasi tertentu: tanda tangan digital untuk otentikasi dasar, ring signature dan linkable ring signature untuk anonimitas dasar, enkripsi berbasis identitas untuk enkripsi yang lebih nyaman dengan asumsi penerbit tepercaya tertentu, dan blind signature untuk uang elektronik Chaumian, dan sebagainya. Pendekatan ini mengharuskan banyak pekerjaan untuk setiap aplikasi baru.

Pada 2010-an, kita pertama kali melihat sekilas pendekatan yang berbeda dan lebih kuat, berdasarkan kriptografi yang dapat diprogram. Alih-alih membuat protokol baru untuk setiap aplikasi, kita dapat menggunakan protokol baru yang kuat—khususnya ZK-SNARKs—untuk menambahkan jaminan kriptografi ke program apa pun.

ZK-SNARKs memungkinkan pengguna membuktikan klaim arbitrer tentang data yang mereka miliki, dan buktinya (i) mudah diverifikasi, dan (ii) tidak mengungkapkan data apa pun selain klaim itu sendiri. Ini adalah lompatan besar dalam privasi dan skalabilitas; saya membandingkannya dengan dampak transformer dalam kecerdasan buatan. Ribuan tahun kerja aplikasi khusus tiba-tiba digantikan oleh solusi umum ini, yang dapat menangani masalah yang sangat luas dan tak terduga.

Namun, ZK-SNARKs hanyalah yang pertama dari tiga primitif universal yang sangat kuat. Protokol-protokol ini begitu kuat sehingga ketika saya memikirkannya, mereka mengingatkan saya pada satu set kartu yang sangat kuat dalam 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, konon proses pembuatannya bisa mematikan, dan kekuatannya membuatnya dilarang digunakan dalam duel. Demikian pula, dalam kriptografi, kita juga memiliki tiga protokol Dewa Mesir ini:

Apa itu ZK-SNARKs dan bagaimana cara kerjanya?

ZK-SNARKs adalah salah satu dari tiga protokol yang sudah kita miliki, dengan tingkat kematangan yang tinggi. Dalam lima tahun terakhir, kecepatan prover dan kemudahan pengembangan yang meningkat pesat telah menjadikan ZK-SNARKs sebagai landasan strategi skalabilitas dan privasi Ethereum. Namun, ZK-SNARKs memiliki satu keterbatasan penting: Anda harus mengetahui data untuk membuktikannya. Setiap status dalam aplikasi ZK-SNARK harus memiliki satu "pemilik" unik, yang harus hadir untuk menyetujui pembacaan atau penulisan status tersebut.

Protokol kedua yang tidak memiliki batasan ini adalah Fully Homomorphic Encryption (FHE), yang memungkinkan Anda melakukan perhitungan apa pun pada data terenkripsi tanpa melihat datanya. Ini memungkinkan Anda melakukan perhitungan pada data pengguna demi kepentingan pengguna, sambil menjaga kerahasiaan data dan algoritma.

Ini juga memungkinkan Anda memperluas sistem voting seperti MACI untuk mendapatkan jaminan keamanan dan privasi yang hampir sempurna. Untuk waktu yang lama, FHE dianggap terlalu tidak efisien untuk digunakan secara praktis, tetapi sekarang akhirnya cukup efisien untuk mulai digunakan dalam aplikasi nyata.

Cursive adalah aplikasi yang menggunakan komputasi dua pihak dan FHE untuk menemukan minat bersama secara privat.

Namun, FHE juga memiliki keterbatasan: teknologi berbasis FHE tetap memerlukan seseorang yang memegang kunci dekripsi. Ini bisa berupa pengaturan terdistribusi M-of-N, Anda bahkan dapat menggunakan Trusted Execution Environment (TEE) untuk menambah lapisan perlindungan kedua, tetapi ini tetap merupakan batasan.

Selanjutnya adalah protokol ketiga, yang lebih kuat dari gabungan dua sebelumnya: indistinguishability obfuscation. Meskipun teknologi ini masih jauh dari matang, sejak 2020 kita telah memiliki protokol yang secara teoritis valid berdasarkan asumsi keamanan standar, dan baru-baru ini mulai diimplementasikan.

Indistinguishability obfuscation memungkinkan Anda membuat "program terenkripsi" yang melakukan perhitungan arbitrer sambil menyembunyikan semua detail internal program. Contoh sederhana, Anda dapat memasukkan private key ke dalam program obfuscation, yang hanya mengizinkan Anda menggunakannya untuk menandatangani bilangan prima, dan mendistribusikan program ini ke orang lain. Mereka dapat menggunakan program ini untuk menandatangani bilangan prima apa pun, tetapi tidak dapat mengekstrak kuncinya. Namun, kemampuannya jauh lebih luas: dikombinasikan dengan hash, ia dapat digunakan untuk mengimplementasikan primitif kriptografi lain, dan lebih banyak lagi.

Satu-satunya hal yang tidak dapat dilakukan program obfuscation adalah mencegah dirinya sendiri disalin. Namun, untuk itu, ada teknologi yang lebih kuat menanti di masa depan, meskipun bergantung pada semua orang memiliki komputer kuantum: quantum one-shot signatures.

Dengan menggabungkan obfuscation dan one-shot signatures, kita dapat membangun pihak ketiga tanpa kepercayaan yang hampir sempurna. Satu-satunya tujuan yang tidak dapat dicapai hanya dengan kriptografi, dan masih memerlukan blockchain untuk menjamin, adalah resistensi sensor. Teknologi-teknologi ini tidak hanya dapat membuat Ethereum sendiri lebih aman, tetapi juga memungkinkan aplikasi yang lebih kuat dibangun di atasnya.

Untuk lebih memahami bagaimana primitif ini menambah kemampuan ekstra, mari kita ambil voting sebagai contoh utama. Voting adalah masalah menarik karena membutuhkan banyak atribut keamanan yang kompleks, termasuk verifiabilitas dan privasi yang sangat kuat. Meskipun protokol voting dengan atribut keamanan kuat telah ada selama puluhan tahun, kita dapat menantang diri sendiri dengan merancang protokol yang dapat menangani voting arbitrer: seperti quadratic voting, quadratic funding dengan batas pasangan, quadratic funding dengan cluster matching, dan sebagainya. Dengan kata lain, kita ingin langkah "penghitungan suara" menjadi program arbitrer.

Pertama, misalkan kita menempatkan hasil voting secara publik di blockchain. Ini memberi kita verifiabilitas publik (siapa pun dapat memverifikasi hasil akhir benar, termasuk aturan penghitungan dan kelayakan) dan resistensi sensor (tidak dapat mencegah orang untuk voting). Namun, kita tidak memiliki privasi.

Kemudian, kita menambahkan ZK-SNARKs, sekarang kita memiliki privasi: setiap suara anonim, sambil memastikan hanya pemilih yang berwenang yang dapat voting, dan setiap pemilih hanya dapat voting sekali.

Selanjutnya, kita memperkenalkan mekanisme MACI, suara dienkripsi ke kunci dekripsi server pusat. Server pusat bertanggung jawab untuk proses penghitungan suara, termasuk menghapus suara duplikat, dan menerbitkan bukti ZK-SNARK atas hasilnya. Ini mempertahankan jaminan sebelumnya (bahkan jika server curang!), tetapi jika server jujur, ia juga menambah jaminan anti-paksaan: pengguna tidak dapat membuktikan bagaimana mereka voting, bahkan jika mereka ingin. Ini karena meskipun pengguna dapat membuktikan suara mereka, mereka tidak dapat membuktikan bahwa mereka tidak voting untuk membatalkan suara tersebut. Ini mencegah penyuapan dan serangan lainnya.

Kita menjalankan penghitungan suara di FHE, lalu melakukan dekripsi threshold N/2-of-N. Ini meningkatkan jaminan anti-paksaan menjadi N/2-of-N, bukan 1-of-1.

Kita melakukan obfuscation pada program penghitungan suara, dan merancang program obfuscation agar hanya dapat mengeluarkan hasil jika mendapat otorisasi, misalnya bukti konsensus blockchain, bukti kerja, atau kombinasi keduanya. Ini membuat jaminan anti-paksaan hampir sempurna: dalam kasus konsensus blockchain, 51% validator harus bersekongkol untuk membobolnya; dalam kasus bukti kerja, bahkan jika semua orang bersekongkol, melakukan penghitungan ulang dengan subset pemilih berbeda untuk mengekstrak perilaku pemilih individu akan sangat mahal. Kita bahkan dapat membuat program melakukan sedikit penyesuaian acak pada hasil akhir untuk lebih meningkatkan kesulitan mengekstrak perilaku pemilih individu.

Kita menambahkan one-shot signatures, primitif berbasis kuantum yang memungkinkan tanda tangan hanya digunakan sekali untuk jenis informasi tertentu. Ini membuat jaminan anti-paksaan benar-benar sempurna.

Indistinguishability obfuscation juga mendukung aplikasi kuat lainnya. Misalnya:

1. Decentralized Autonomous Organizations (DAOs), lelang on-chain, dan aplikasi lain dengan status rahasia internal arbitrer.
2. Trusted setup universal sejati: seseorang dapat membuat program obfuscation berisi kunci, menjalankan program apa pun dan memberikan output, memasukkan hash(key, program) ke dalam program. Dengan program seperti itu, siapa pun dapat memasukkan program 3 ke dalam dirinya sendiri, menggabungkan pre-key program dan kunci mereka sendiri, sehingga memperluas setup. Ini dapat digunakan untuk menghasilkan trusted setup 1-of-N untuk protokol apa pun.
3. Verifikasi ZK-SNARKs hanya memerlukan satu tanda tangan: ini sangat mudah diimplementasikan—atur lingkungan tepercaya, biarkan seseorang membuat program obfuscation yang hanya akan menandatangani pesan dengan kunci jika ZK-SNARK valid.
4. Mempool terenkripsi: transaksi terenkripsi menjadi sangat mudah, sehingga transaksi hanya dapat didekripsi ketika suatu peristiwa on-chain terjadi di masa depan. Ini bahkan dapat mencakup eksekusi Verifiable Delay Function (VDF) yang berhasil.

Dengan one-shot signatures, kita dapat membuat blockchain kebal terhadap serangan 51% pada finalitas, meskipun serangan sensor masih mungkin. Primitif seperti one-shot signatures memungkinkan quantum money, sehingga menyelesaikan masalah double spending tanpa blockchain, meskipun banyak aplikasi yang lebih kompleks masih memerlukan chain.

Jika primitif ini menjadi cukup efisien, maka sebagian besar aplikasi di dunia dapat didesentralisasi. Hambatan utama adalah memverifikasi kebenaran implementasi.

Berikut beberapa tautan penelitian yang ada:

• Protokol indistinguishability obfuscation (2021): 
• Bagaimana obfuscation membantu Ethereum: 
• Konstruksi one-shot signature pertama yang diketahui: 
• Implementasi obfuscation percobaan (1): 
• Implementasi obfuscation percobaan (2): 

Apa lagi yang perlu dilakukan dan apa pertimbangannya?

Masih banyak pekerjaan yang harus dilakukan, indistinguishability obfuscation masih sangat belum matang, dan konstruksi kandidatnya sangat lambat (jika tidak lebih), sehingga tidak dapat digunakan dalam aplikasi. Indistinguishability obfuscation terkenal "secara teori" berjalan dalam waktu polinomial, tetapi dalam praktiknya, waktu jalannya bisa lebih lama dari usia alam semesta. Protokol terbaru telah memperbaiki waktu jalan, tetapi overheadnya masih terlalu tinggi untuk penggunaan rutin: seorang implementator memperkirakan waktu jalan satu tahun.

Komputer kuantum bahkan belum ada: semua konstruksi yang Anda lihat di internet, baik itu prototipe yang tidak dapat melakukan lebih dari 4 bit operasi, atau sama sekali bukan komputer kuantum yang substansial, meskipun mungkin memiliki bagian kuantum, tetapi tidak dapat menjalankan perhitungan bermakna seperti algoritma Shor atau Grover. Baru-baru ini ada tanda-tanda bahwa "komputer kuantum sejati" tidak terlalu jauh. Namun, bahkan jika "komputer kuantum sejati" muncul dalam waktu dekat, orang biasa mungkin harus menunggu puluhan tahun sebelum dapat menggunakan komputer kuantum di laptop atau ponsel mereka, sebelum institusi kuat dapat membobol kriptografi kurva eliptik.

Untuk indistinguishability obfuscation, salah satu pertimbangan utama adalah asumsi keamanan, ada desain yang lebih agresif menggunakan asumsi khusus. Desain ini biasanya memiliki waktu jalan yang lebih realistis, tetapi asumsi khusus terkadang akhirnya rusak. Seiring waktu, kita mungkin akan lebih memahami lattice, sehingga dapat mengusulkan asumsi yang lebih tahan rusak. Namun, jalur ini lebih berisiko. Pendekatan yang lebih konservatif adalah tetap menggunakan protokol yang keamanannya dapat dibuktikan berkurang ke asumsi "standar", tetapi ini mungkin berarti kita harus menunggu lebih lama untuk mendapatkan protokol yang cukup cepat.

Bagaimana berinteraksi dengan bagian lain dari peta jalan?

Kriptografi yang sangat kuat dapat mengubah permainan secara drastis, misalnya:

1. Jika kita mendapatkan verifikasi ZK-SNARKs yang semudah tanda tangan, kita mungkin tidak lagi memerlukan protokol agregasi apa pun; kita dapat langsung melakukan verifikasi on-chain.
2. One-shot signatures dapat berarti protokol proof-of-stake yang lebih aman.
3. Banyak protokol privasi yang kompleks mungkin hanya memerlukan satu EVM privasi untuk menggantikannya.
4. Mempool terenkripsi menjadi lebih mudah diimplementasikan.

Pada awalnya, manfaatnya akan muncul di lapisan aplikasi, karena L1 Ethereum pada dasarnya harus tetap konservatif dalam asumsi keamanannya. Namun, penggunaan di lapisan aplikasi saja bisa sangat disruptif, seperti munculnya ZK-SNARKs.