- Topik
76k Popularitas
30k Popularitas
9k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
12k Popularitas
2k Popularitas
- Sematkan
76k Popularitas
30k Popularitas
9k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
12k Popularitas
2k Popularitas
Helios: Implementasi klien ringan Ethereum untuk akses data on-chain tanpa kepercayaan
Light Client Ethereum Helios: Akses Data On-Chain Tanpa Kepercayaan
Pada 8 November, sebuah lembaga modal ventura terkenal meluncurkan klien ringan Ethereum Helios. Klien yang ditulis dalam bahasa Rust ini bertujuan untuk menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan.
Salah satu keuntungan besar dari teknologi blockchain adalah tidak memerlukan kepercayaan kepada pihak ketiga. Melalui blockchain, pengguna dapat mengontrol kekayaan dan data mereka sendiri. Blockchain seperti Ethereum memang dalam banyak kasus telah memenuhi janji ini: aset kita benar-benar milik kita sendiri.
Namun, untuk mengejar kenyamanan, kami juga melakukan beberapa kompromi. Salah satunya adalah menggunakan server RPC (Remote Procedure Call) yang terpusat. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud, membantu pengguna dengan mudah mendapatkan data on-chain. Ketika dompet memeriksa saldo token atau memeriksa apakah transaksi yang tertunda telah dibundel, hampir selalu menggunakan layanan dari penyedia terpusat ini.
Masalah sistem saat ini adalah pengguna perlu mempercayai penyedia ini, dan tidak dapat memverifikasi akurasi hasil kueri.
Helios adalah klien ringan Ethereum berbasis Rust yang dapat menyediakan akses Ethereum tanpa kepercayaan secara penuh. Ini memanfaatkan protokol klien ringan yang diimplementasikan setelah Ethereum beralih ke PoS, yang dapat mengubah data dari penyedia RPC terpusat yang tidak tepercaya menjadi RPC lokal yang aman dan dapat diverifikasi. Dengan menggabungkan RPC terpusat, Helios dapat memverifikasi keaslian data tanpa perlu menjalankan node penuh.
Kesulitan untuk menyeimbangkan kemudahan dan desentralisasi adalah titik sakit yang umum. Klien baru ini (terbuka untuk pengembangan publik) dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, dan tidak memerlukan ruang penyimpanan. Pengguna dapat mengakses data on-chain dengan aman melalui perangkat apa pun (termasuk ponsel dan plugin browser). Jadi, apa saja risiko potensial yang terkait dengan ketergantungan pada infrastruktur terpusat? Artikel ini akan membahas risiko-risiko tersebut secara rinci, memperkenalkan solusi desain Helios, dan memberikan beberapa rekomendasi untuk membantu pengembang berkontribusi pada basis kode.
Risiko Potensial dari Infrastruktur Terpusat: Ancaman Teoretis dalam Ekosistem Ethereum
Di ekosistem Ethereum terdapat ancaman teoritis yang mengintai. Ia tidak mencari target di dalam mempool transaksi, tetapi menjebak dengan meniru infrastruktur terpusat yang kita andalkan. Pengguna yang terjebak dalam jebakan ini tidak melakukan kesalahan: mereka hanya mengakses DEX yang sudah mereka kenal seperti biasa, mengatur slippage yang wajar, dan melakukan perdagangan token... operasi mereka tidak ada masalah, tetapi mungkin mengalami jenis serangan sandwich baru, yang merupakan jebakan yang disiapkan dengan cermat di pintu masuk ekosistem Ethereum — penyedia RPC.
Sebelum menjelaskan secara rinci, mari kita lihat bagaimana DEX menangani transaksi. Ketika pengguna melakukan pertukaran token, mereka akan memberikan beberapa parameter kepada kontrak pintar: token yang akan ditukar, jumlah pertukaran, dan yang paling penting, jumlah token minimum yang bersedia diterima pengguna. Parameter terakhir ini menentukan "hasil minimum" yang harus dicapai untuk pertukaran, jika tidak, transaksi akan dibatalkan. Ini biasanya disebut sebagai "slippage", karena secara efektif membatasi fluktuasi harga maksimum yang mungkin terjadi dari saat transaksi dikirim ke mempool hingga dikemas ke dalam blok. Jika pengaturan slippage terlalu rendah, pengguna mungkin hanya mendapatkan sedikit token. Situasi ini juga dapat menyebabkan serangan sandwich, di mana penyerang mungkin menyisipkan transaksi pengguna di antara dua transaksi jahat. Transaksi ini akan mendorong harga spot naik, memaksa pengguna untuk menyelesaikan transaksi pada harga yang merugikan. Setelah itu, penyerang akan segera menjual token, mendapatkan keuntungan kecil.
Selama parameter hasil minimum diatur dalam rentang yang wajar, pengguna tidak akan terpengaruh oleh serangan sandwich. Namun, bagaimana jika penyedia RPC tidak memberikan kutipan yang akurat untuk kontrak pintar DEX? Dalam kasus ini, pengguna mungkin akan terbawa untuk menandatangani transaksi pertukaran dengan parameter hasil minimum yang lebih rendah. Yang lebih buruk, pengguna mungkin akan mengirim transaksi langsung ke penyedia RPC yang jahat. Penyedia dapat memilih untuk tidak menyiarkan transaksi ini ke mempool publik (di mana banyak robot berlomba-lomba melakukan serangan sandwich), tetapi menyimpannya secara pribadi dan langsung mengirimkan paket transaksi yang akan diserang ke platform tertentu untuk mendapatkan keuntungan.
Penyebab mendasar dari serangan ini adalah kepercayaan kepada orang lain untuk membantu mendapatkan status blockchain. Untuk mengatasi masalah ini, pengguna yang berpengalaman biasanya memilih untuk menjalankan node Ethereum mereka sendiri. Ini membutuhkan investasi waktu dan sumber daya yang besar, setidaknya memerlukan satu perangkat yang selalu online, ratusan GB ruang penyimpanan, dan sekitar satu hari waktu untuk menyinkronkan dari awal. Meskipun proses ini telah disederhanakan jauh lebih banyak dibandingkan sebelumnya, beberapa tim telah bekerja keras untuk membantu pengguna menjalankan node melalui perangkat keras berbiaya rendah (seperti Raspberry Pi dengan hard drive eksternal). Namun, meskipun tuntutan biaya dapat diturunkan secara signifikan, menjalankan node tetap merupakan tugas yang sulit bagi sebagian besar pengguna, terutama bagi mereka yang menggunakan perangkat mobile.
Perlu dicatat bahwa meskipun serangan dari penyedia RPC terpusat sangat mungkin terjadi, saat ini itu masih merupakan risiko teoritis dan belum terjadi dalam praktiknya. Meskipun rekam jejak penyedia utama dapat dipercaya, tetap disarankan untuk melakukan penelitian yang memadai sebelum menambahkan penyedia RPC yang tidak dikenal ke dalam dompet.
Helios: Akses Ethereum Tanpa Kepercayaan
Protokol light client yang diluncurkan oleh Ethereum membuka kemungkinan menarik untuk interaksi blockchain yang cepat dan verifikasi titik akhir RPC dengan persyaratan perangkat keras minimum. Dalam sebulan setelah penggabungan, beberapa light client independen muncul berturut-turut, masing-masing dengan pendekatan yang berbeda, tetapi semua bertujuan untuk mencapai akses yang efisien tanpa perlu percaya, tanpa harus menggunakan node penuh.
Helios adalah light client Ethereum yang dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, tanpa memerlukan ruang penyimpanan, dan menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. Seperti semua klien Ethereum, Helios terdiri dari lapisan eksekusi dan lapisan konsensus. Namun, berbeda dengan sebagian besar klien lainnya, Helios menggabungkan kedua lapisan ini dengan erat, sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak.
Cara kerjanya adalah sebagai berikut: Lapisan konsensus Helios menggunakan hash blok rantai beacon yang dikenal, dan menghubungkan RPC yang tidak tepercaya, untuk menyinkronkan ke blok saat ini dengan cara yang dapat diverifikasi. Lapisan eksekusi Helios menggabungkan blok rantai beacon yang telah diverifikasi dengan RPC lapisan eksekusi yang tidak tepercaya, untuk memverifikasi berbagai informasi tentang status rantai, seperti saldo akun, penyimpanan kontrak, bukti transaksi, dan hasil pemanggilan kontrak pintar. Komponen-komponen ini bekerja sama untuk memberikan RPC yang sepenuhnya tidak memerlukan kepercayaan, tanpa perlu menjalankan node lengkap.
lapisan konsensus
Klien ringan lapisan konsensus mengikuti spesifikasi klien ringan rantai beacon, dan memanfaatkan komite sinkron dari rantai beacon (diperkenalkan dalam hard fork Altair sebelum penggabungan). Komite sinkron adalah subset dari 512 validator yang dipilih secara acak, dengan periode layanan sekitar 27 jam.
Validator yang masuk ke dalam komite sinkronisasi akan menandatangani semua header blok beacon chain yang mereka lihat. Jika lebih dari dua pertiga anggota komite menandatangani sebuah header blok, maka blok tersebut sangat mungkin berada di dalam beacon chain yang sesuai. Jika Helios mengetahui komposisi komite sinkronisasi saat ini, ia dapat dengan sangat yakin melacak kepala rantai dengan melakukan kueri RPC yang tidak tepercaya untuk menanyakan tanda tangan komite sinkronisasi terbaru.
Berkat agregasi tanda tangan BLS, verifikasi terhadap header blok baru hanya memerlukan satu permintaan. Selama tanda tangan valid dan lebih dari dua pertiga anggota dewan telah menyelesaikan tanda tangan, blok dapat dijamin telah termasuk dalam rantai (tentu saja, blok tersebut juga bisa saja direstrukturisasi keluar dari rantai, sementara pelacakan finalitas blok dapat memberikan jaminan yang lebih kuat).
Namun, jelas ada satu aspek yang hilang dalam strategi ini: bagaimana cara menemukan komite sinkron saat ini. Pertama, perlu mendapatkan akar kepercayaan yang disebut titik pemeriksaan subyektif yang lemah. Ini hanyalah hash blok lama yang dapat dipastikan telah dimasukkan ke dalam rantai pada waktu tertentu di masa lalu. Mengenai waktu keberadaan titik pemeriksaan yang tepat, ada beberapa perhitungan matematika menarik di baliknya: analisis kasus terburuk menunjukkan sekitar dua minggu, sementara estimasi yang lebih realistis menunjukkan bahwa itu bisa berlangsung selama beberapa bulan.
Jika titik pemeriksaan terlalu tua, secara teori ada kemungkinan untuk menipu node agar mengikuti rantai yang salah. Dalam hal ini, mendapatkan titik pemeriksaan subjektivitas lemah melampaui batas kemampuan protokol. Solusi Helios adalah menyediakan titik pemeriksaan awal, yang di-hardcode ke dalam repositori kode (sangat mudah untuk ditimpa), yang akan menyimpan hash blok final terbaru secara lokal untuk digunakan sebagai titik pemeriksaan saat node disinkronkan.
Melalui operasi hash, blok beacon di blockchain dapat dengan mudah menghasilkan hash blok beacon yang unik. Dengan cara ini, node dapat dengan mudah meminta blok beacon lengkap, dan kemudian dengan melakukan operasi hash dan membandingkannya dengan hash blok yang dikenal, untuk membuktikan validitas konten blok. Helios memanfaatkan fitur ini untuk mendapatkan dan memverifikasi beberapa field dalam blok checkpoint subyektif lemah, termasuk dua field yang sangat penting: dewan sinkronisasi saat ini dan dewan sinkronisasi berikutnya. Yang paling penting, klien ringan dapat memanfaatkan mekanisme ini untuk memeriksa sejarah blockchain dengan cepat.
Dengan titik pemeriksaan subyektif yang lemah, kita dapat memperoleh dan memverifikasi dewan sinkronisasi saat ini dan berikutnya. Jika kepala rantai saat ini dan titik pemeriksaan berada dalam periode dewan sinkronisasi yang sama, kita dapat segera mulai menggunakan kepala dewan sinkronisasi yang telah ditandatangani untuk memverifikasi blok baru. Jika titik pemeriksaan kita tertinggal beberapa dewan sinkronisasi, maka kita dapat:
Gunakan komite sinkronisasi berikutnya setelah titik pemeriksaan untuk mendapatkan dan memverifikasi blok yang akan menghasilkan komite sinkronisasi di masa depan.
Gunakan blok baru ini untuk mendapatkan dewan sinkronisasi berikutnya.
Jika titik pemeriksaan masih di belakang, kembali ke langkah 1.
Melalui proses ini, kami dapat dengan cepat memeriksa sejarah blockchain dalam interval 27 jam, mulai dari hash blok mana pun di masa lalu hingga disinkronkan dengan hash blok saat ini.
lapisan eksekusi
Tujuan dari light client di lapisan eksekusi adalah untuk menggabungkan header blok beacon yang telah diverifikasi oleh lapisan konsensus dengan RPC lapisan eksekusi yang tidak tepercaya, untuk menyediakan data lapisan eksekusi yang telah diverifikasi. Data ini kemudian dapat diakses melalui server RPC yang dihosting secara lokal oleh Helios.
Mari kita ambil contoh mendapatkan saldo akun untuk memperkenalkan secara singkat bagaimana Ethereum menyimpan status. Setiap akun berisi beberapa bidang, seperti hash kode kontrak, angka acak, hash penyimpanan, dan saldo. Akun-akun ini disimpan dalam pohon Merkle-Patricia besar yang dimodifikasi, yang disebut pohon status. Selama kita mengetahui akar pohon status, kita dapat memverifikasi bukti Merkle untuk membuktikan apakah ada akun dalam pohon tersebut. Bukti ini tidak dapat dipalsukan.
Helios mendapatkan akar status yang telah diverifikasi dari lapisan konsensus. Dengan menerapkan akar status ini dan permintaan bukti Merkle ke RPC lapisan eksekusi yang tidak tepercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.
Kami menggunakan teknologi yang berbeda untuk memverifikasi berbagai data yang digunakan oleh lapisan eksekusi. Dengan cara ini, kami dapat memverifikasi semua data yang berasal dari RPC yang tidak tepercaya. RPC yang tidak tepercaya dapat menolak untuk memberikan akses data, tetapi tidak dapat memberikan hasil yang salah.
Menggunakan Helios dalam Lingkungan yang Kompleks
Kesulitan untuk menyeimbangkan kenyamanan dan desentralisasi adalah masalah yang umum. Melalui Helios yang ringan, pengguna dapat mengakses data on-chain dengan aman dari perangkat mana pun (termasuk ponsel dan plugin browser). Ini akan memungkinkan lebih banyak orang untuk mengakses data Ethereum tanpa harus mempercayai, tanpa batasan perangkat keras. Pengguna dapat mengatur Helios sebagai penyedia RPC di beberapa dompet, memungkinkan akses tanpa kepercayaan ke berbagai DApp, seluruh proses ini tidak memerlukan perubahan lain.
Selain itu, dukungan Rust untuk WebAssembly memungkinkan pengembang aplikasi untuk dengan mudah mengintegrasikan Helios ke dalam aplikasi JavaScript (seperti dompet dan DApp). Integrasi ini akan meningkatkan keamanan Ethereum dan mengurangi ketergantungan kita pada infrastruktur terpusat.
Reaksi komunitas terhadap ini sangat dinanti. Ada berbagai cara untuk berkontribusi pada Helios, selain menyumbangkan kode ke repositori, Anda juga dapat membangun perangkat lunak yang mengintegrasikan Helios untuk memanfaatkan keuntungannya. Berikut adalah beberapa ide menarik: