Ether light client Helios: Mewujudkan akses blockchain tanpa kepercayaan
Pada 8 November, sebuah klien ringan Ethereum baru bernama Helios resmi diluncurkan. Klien ini dikembangkan dengan bahasa Rust, bertujuan untuk memberikan akses Ethereum yang sepenuhnya tanpa kepercayaan.
Salah satu tujuan utama penggunaan Blockchain adalah untuk mencapai ketidakpercayaan. Melalui Blockchain, kita dapat menguasai kekayaan dan data kita sendiri. Dalam banyak kasus, Blockchain seperti Ethereum benar-benar memenuhi janji ini: aset kita benar-benar milik kita sendiri.
Namun, untuk mengejar kenyamanan, kami juga melakukan beberapa kompromi. Salah satunya adalah menggunakan RPC( yang terpusat untuk memanggil) server. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud, membantu semua orang dengan mudah mendapatkan data di blockchain. Ketika dompet memeriksa saldo token atau memeriksa status transaksi, hampir selalu melibatkan penyedia terpusat ini.
Masalah saat ini adalah pengguna harus mempercayai penyedia ini, tidak dapat memverifikasi apakah hasil kueri benar.
Helios adalah klien ringan Ethereum yang berbasis Rust, yang dapat menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. 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.
Klien ini dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, dan tidak memerlukan penyimpanan. Pengguna dapat mengakses data di blockchain dengan aman melalui perangkat apa pun ( termasuk ponsel dan plugin browser ). Namun, apa saja risiko potensial yang bergantung pada infrastruktur terpusat? Selanjutnya, kami akan menganalisis risiko ini, memperkenalkan desain Helios, dan memberikan beberapa pemikiran untuk membantu menyempurnakan pustaka kode.
Risiko Potensial dari Infrastruktur Terpusat
Sebuah metode serangan teoretis mengintai di "hutan gelap" Ethereum. Ini tidak mencari target di mempool transaksi, melainkan menjebak dengan meniru infrastruktur terpusat yang kita andalkan. Pengguna, bahkan tanpa melakukan kesalahan, dapat terjebak: mereka hanya berdagang di DEX seperti biasa, mengatur slippage yang wajar... tetapi masih dapat mengalami serangan sandwich baru, yang merupakan jebakan yang dirancang dengan cermat di penyedia RPC.
Saat melakukan transaksi di bursa terdesentralisasi, pengguna perlu memberikan beberapa parameter kepada kontrak pintar: token yang ingin ditukar, jumlah pertukaran, dan yang paling penting, jumlah minimum token yang bersedia diterima oleh pengguna. Parameter terakhir menunjukkan "output minimum" yang harus dicapai dalam pertukaran, jika tidak, transaksi akan dibatalkan. Ini biasanya disebut "slippage", yang secara efektif menetapkan selisih harga maksimum yang mungkin terjadi antara pengiriman transaksi dan transaksi yang dicatat di blockchain. Jika pengaturan slippage terlalu rendah, pengguna mungkin hanya dapat memperoleh token yang lebih sedikit, dan juga dapat mengalami serangan sandwich.
Selama parameter output minimum diatur dalam rentang yang wajar, serangan sandwich tidak akan terjadi. Namun, bagaimana jika penyedia RPC tidak memberikan kutipan yang akurat untuk kontrak pintar DEX? Ini dapat menyebabkan pengguna tersesat dan menandatangani transaksi pertukaran dengan parameter output minimum yang lebih rendah. Yang lebih buruk, pengguna juga dapat mengirim transaksi langsung ke penyedia RPC yang jahat. Penyedia dapat memilih untuk tidak menyiarkan transaksi ke mempool publik, tetapi menahan secara pribadi dan mengirimkan paket transaksi yang diserang langsung ke entitas tertentu untuk mendapatkan keuntungan.
Penyebab mendasar dari serangan ini adalah mempercayai orang lain untuk mendapatkan status blockchain. Untuk mengatasi masalah ini, pengguna yang berpengalaman biasanya akan menjalankan node Ethereum mereka sendiri, tetapi ini memerlukan banyak waktu dan sumber daya, setidaknya memerlukan satu perangkat yang selalu online, ratusan GB ruang penyimpanan, dan sekitar satu hari untuk menyinkronkan dari awal. Meskipun sekarang ambang batas untuk menjalankan node telah diturunkan, bagi sebagian besar pengguna masih sangat sulit, terutama bagi pengguna yang menggunakan perangkat seluler.
Perlu dicatat bahwa serangan penyedia RPC terpusat memang mungkin terjadi, tetapi biasanya hanya serangan phishing sederhana, dan jenis serangan yang kami deskripsikan belum terjadi. Meskipun rekam jejak penyedia utama terpercaya, melakukan penelitian lebih banyak sebelum menggunakan penyedia RPC yang tidak dikenal tetap merupakan pilihan yang bijaksana.
Helios: Mewujudkan Akses Ethereum Tanpa Kepercayaan
Ethereum meluncurkan protokol light client, membuka kemungkinan baru untuk interaksi blockchain yang cepat dan verifikasi titik akhir RPC dengan kebutuhan perangkat keras minimum. Dalam sebulan setelah The Merge, beberapa light client independen diluncurkan berturut-turut, mereka menggunakan berbagai metode, tetapi memiliki tujuan yang sama: mencapai akses tanpa kepercayaan yang efisien tanpa menjalankan node lengkap.
Helios adalah light client Ethereum, yang dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, tanpa perlu penyimpanan, dan menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. Seperti semua client Ethereum, Helios mencakup lapisan eksekusi dan lapisan konsensus. Namun, berbeda dengan sebagian besar client, Helios menggabungkan kedua lapisan secara erat, sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak.
Cara kerja Helios adalah sebagai berikut: lapisan konsensus menggunakan hash blok dari rantai beacon yang diketahui, dan menghubungkan ke RPC yang tidak tepercaya, untuk mensinkronkan ke blok saat ini dengan cara yang dapat diverifikasi. Lapisan eksekusi menggabungkan blok rantai beacon yang telah diverifikasi ini dengan RPC lapisan eksekusi yang tidak tepercaya, untuk memverifikasi berbagai informasi tentang status di 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 kepada pengguna, dan tanpa perlu menjalankan node lengkap.
lapisan konsensus
Klien ringan lapisan konsensus mengikuti spesifikasi klien ringan rantai beacon, memanfaatkan komite sinkronisasi dari rantai beacon. Komite sinkronisasi terdiri dari subset 512 validator yang dipilih secara acak, dengan periode layanan sekitar 27 jam.
Validator yang masuk ke dalam komite sinkronisasi akan menandatangani semua header blok rantai beacon yang mereka lihat. Jika lebih dari 2/3 anggota komite menandatangani sebuah header blok, maka blok tersebut sangat mungkin berada di dalam rantai beacon yang sesuai. Jika Helios memahami komposisi komite sinkronisasi saat ini, ia dapat secara andal melacak kepala rantai dengan meng-query tanda tangan komite sinkronisasi terbaru.
Berkat agregasi tanda tangan BLS, verifikasi terhadap kepala blok baru dapat diselesaikan hanya dengan satu kueri. Selama tanda tangan valid dan lebih dari 2/3 anggota komite menyelesaikan tanda tangan, blok tersebut dapat dipastikan telah termasuk dalam rantai. Tentu saja, melacak finalitas blok dapat memberikan jaminan yang lebih kuat.
Dalam strategi ini, perlu juga dipecahkan bagaimana menemukan masalah dewan sinkronisasi saat ini. Pertama, perlu untuk mendapatkan akar kepercayaan yang disebut titik pemeriksaan subjektif yang lemah. Ini menunjukkan hash blok lama yang dapat dijamin dimasukkan ke dalam rantai pada suatu saat di masa lalu. Mengenai waktu keberadaan titik pemeriksaan, analisis teoretis menunjukkan bahwa dalam kasus terburuk, sekitar dua minggu, sementara perkiraan sebenarnya bisa berlangsung hingga beberapa bulan.
Jika titik pemeriksaan terlalu tua, secara teori ada kemungkinan untuk menipu node agar mengikuti rantai yang salah. Pada saat ini, mendapatkan titik pemeriksaan subyektif yang lemah melampaui kemampuan protokol. Solusi Helios adalah memberikan titik pemeriksaan awal, yang dikodekan secara keras ke dalam repositori kode ( yang mudah ditimpa ), yang akan menyimpan hash blok final terbaru secara lokal, untuk digunakan sebagai titik pemeriksaan saat node disinkronkan.
Dengan operasi hash, blok rantai beacon dapat dengan mudah menghasilkan hash blok beacon yang unik. Ini memungkinkan pencarian lengkap blok beacon dengan mudah, dan kemudian membuktikan validitas konten blok melalui perbandingan hash. Helios memanfaatkan atribut ini untuk mendapatkan dan memverifikasi bidang kunci dalam blok titik pemeriksaan subjektif lemah, termasuk komite sinkron saat ini dan komite sinkron berikutnya. Yang paling penting, klien ringan dapat memanfaatkan mekanisme ini untuk dengan cepat meninjau sejarah blockchain.
Dengan adanya titik pemeriksaan subjek lemah, kita dapat memperoleh dan memverifikasi komite sinkronisasi saat ini dan berikutnya. Jika kepala rantai saat ini dan titik pemeriksaan berada dalam siklus komite sinkronisasi yang sama, kita dapat segera menggunakan header komite sinkronisasi yang telah ditandatangani untuk memverifikasi blok baru. Jika titik pemeriksaan berada beberapa komite sinkronisasi setelahnya, maka kita dapat:
Gunakan komite sinkron berikutnya setelah titik pemeriksaan untuk mendapatkan dan memverifikasi blok yang akan dihasilkan oleh komite sinkron di masa depan.
Gunakan blok baru ini untuk mendapatkan komite sinkronisasi berikutnya.
Jika titik pemeriksaan masih di belakang, kembali ke langkah 1.
Melalui proses di atas, kami dapat dengan cepat meninjau sejarah blockchain dalam satuan 27 jam, mulai dari hash blok mana pun di masa lalu hingga disinkronkan dengan hash blok saat ini.
lapisan eksekusi
Tujuan dari light client layer 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 di Helios.
Berikut adalah contoh sederhana untuk mendapatkan saldo akun, pertama-tama memperkenalkan secara singkat bagaimana Ethereum menyimpan status. Setiap akun berisi beberapa bidang, seperti hash kode kontrak, nonce, hash penyimpanan, dan saldo. Akun-akun ini disimpan dalam pohon Merkle-Patricia besar yang telah disesuaikan, 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 pada lapisan eksekusi RPC yang tidak tepercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.
Kami menggunakan berbagai teknologi untuk memverifikasi berbagai data yang digunakan oleh lapisan eksekusi, sehingga kami dapat memverifikasi semua data dari RPC yang tidak tepercaya. RPC yang tidak tepercaya dapat menolak untuk memberikan akses data, tetapi tidak dapat memberikan hasil yang salah.
Prospek Aplikasi Helios
Sulit untuk mengakomodasi kenyamanan dan desentralisasi adalah titik sakit yang umum. Melalui Helios yang ringan, pengguna dapat mengakses data on-chain yang aman dari perangkat apa pun ( termasuk ponsel dan plugin browser ). Ini akan memungkinkan lebih banyak orang untuk mengakses data Ethereum tanpa perlu percaya, terlepas dari perangkat keras yang digunakan. Pengguna dapat menggunakan Helios sebagai penyedia RPC di dompet mereka untuk mengakses berbagai DApp tanpa perlu percaya, seluruh proses tanpa perubahan tambahan.
Selain itu, dukungan Rust untuk WebAssembly memungkinkan pengembang aplikasi dengan mudah menyematkan Helios ke dalam aplikasi Javascript ( seperti dompet dan DApp ). Integrasi ini akan meningkatkan keamanan Ethereum dan mengurangi kebutuhan kami untuk mempercayai infrastruktur terpusat.
Komunitas dapat berkontribusi pada Helios dengan berbagai cara, selain memperbaiki repositori kode, mereka juga dapat membangun perangkat lunak yang mengintegrasikan Helios untuk memanfaatkan keuntungannya. Berikut adalah beberapa arah pengembangan yang potensial:
Mendukung pengambilan data klien ringan secara langsung dari jaringan P2P, bukan bergantung pada RPC
Mengimplementasikan metode RPC yang hilang
Mengembangkan versi Helios yang dapat dikompilasi ke WebAssembly
Mengintegrasikan Helios langsung ke dalam perangkat lunak dompet
Membangun dasbor jaringan untuk melihat saldo token, menyematkan Helios ke dalam situs web yang menggunakan WebAssembly untuk mendapatkan data
Menerapkan API mesin, menghubungkan lapisan konsensus Helios ke node penuh lapisan eksekusi yang ada
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Helios light client: Mewujudkan akses data Ethereum on-chain tanpa kepercayaan
Ether light client Helios: Mewujudkan akses blockchain tanpa kepercayaan
Pada 8 November, sebuah klien ringan Ethereum baru bernama Helios resmi diluncurkan. Klien ini dikembangkan dengan bahasa Rust, bertujuan untuk memberikan akses Ethereum yang sepenuhnya tanpa kepercayaan.
Salah satu tujuan utama penggunaan Blockchain adalah untuk mencapai ketidakpercayaan. Melalui Blockchain, kita dapat menguasai kekayaan dan data kita sendiri. Dalam banyak kasus, Blockchain seperti Ethereum benar-benar memenuhi janji ini: aset kita benar-benar milik kita sendiri.
Namun, untuk mengejar kenyamanan, kami juga melakukan beberapa kompromi. Salah satunya adalah menggunakan RPC( yang terpusat untuk memanggil) server. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud, membantu semua orang dengan mudah mendapatkan data di blockchain. Ketika dompet memeriksa saldo token atau memeriksa status transaksi, hampir selalu melibatkan penyedia terpusat ini.
Masalah saat ini adalah pengguna harus mempercayai penyedia ini, tidak dapat memverifikasi apakah hasil kueri benar.
Helios adalah klien ringan Ethereum yang berbasis Rust, yang dapat menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. 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.
Klien ini dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, dan tidak memerlukan penyimpanan. Pengguna dapat mengakses data di blockchain dengan aman melalui perangkat apa pun ( termasuk ponsel dan plugin browser ). Namun, apa saja risiko potensial yang bergantung pada infrastruktur terpusat? Selanjutnya, kami akan menganalisis risiko ini, memperkenalkan desain Helios, dan memberikan beberapa pemikiran untuk membantu menyempurnakan pustaka kode.
Risiko Potensial dari Infrastruktur Terpusat
Sebuah metode serangan teoretis mengintai di "hutan gelap" Ethereum. Ini tidak mencari target di mempool transaksi, melainkan menjebak dengan meniru infrastruktur terpusat yang kita andalkan. Pengguna, bahkan tanpa melakukan kesalahan, dapat terjebak: mereka hanya berdagang di DEX seperti biasa, mengatur slippage yang wajar... tetapi masih dapat mengalami serangan sandwich baru, yang merupakan jebakan yang dirancang dengan cermat di penyedia RPC.
Saat melakukan transaksi di bursa terdesentralisasi, pengguna perlu memberikan beberapa parameter kepada kontrak pintar: token yang ingin ditukar, jumlah pertukaran, dan yang paling penting, jumlah minimum token yang bersedia diterima oleh pengguna. Parameter terakhir menunjukkan "output minimum" yang harus dicapai dalam pertukaran, jika tidak, transaksi akan dibatalkan. Ini biasanya disebut "slippage", yang secara efektif menetapkan selisih harga maksimum yang mungkin terjadi antara pengiriman transaksi dan transaksi yang dicatat di blockchain. Jika pengaturan slippage terlalu rendah, pengguna mungkin hanya dapat memperoleh token yang lebih sedikit, dan juga dapat mengalami serangan sandwich.
Selama parameter output minimum diatur dalam rentang yang wajar, serangan sandwich tidak akan terjadi. Namun, bagaimana jika penyedia RPC tidak memberikan kutipan yang akurat untuk kontrak pintar DEX? Ini dapat menyebabkan pengguna tersesat dan menandatangani transaksi pertukaran dengan parameter output minimum yang lebih rendah. Yang lebih buruk, pengguna juga dapat mengirim transaksi langsung ke penyedia RPC yang jahat. Penyedia dapat memilih untuk tidak menyiarkan transaksi ke mempool publik, tetapi menahan secara pribadi dan mengirimkan paket transaksi yang diserang langsung ke entitas tertentu untuk mendapatkan keuntungan.
Penyebab mendasar dari serangan ini adalah mempercayai orang lain untuk mendapatkan status blockchain. Untuk mengatasi masalah ini, pengguna yang berpengalaman biasanya akan menjalankan node Ethereum mereka sendiri, tetapi ini memerlukan banyak waktu dan sumber daya, setidaknya memerlukan satu perangkat yang selalu online, ratusan GB ruang penyimpanan, dan sekitar satu hari untuk menyinkronkan dari awal. Meskipun sekarang ambang batas untuk menjalankan node telah diturunkan, bagi sebagian besar pengguna masih sangat sulit, terutama bagi pengguna yang menggunakan perangkat seluler.
Perlu dicatat bahwa serangan penyedia RPC terpusat memang mungkin terjadi, tetapi biasanya hanya serangan phishing sederhana, dan jenis serangan yang kami deskripsikan belum terjadi. Meskipun rekam jejak penyedia utama terpercaya, melakukan penelitian lebih banyak sebelum menggunakan penyedia RPC yang tidak dikenal tetap merupakan pilihan yang bijaksana.
Helios: Mewujudkan Akses Ethereum Tanpa Kepercayaan
Ethereum meluncurkan protokol light client, membuka kemungkinan baru untuk interaksi blockchain yang cepat dan verifikasi titik akhir RPC dengan kebutuhan perangkat keras minimum. Dalam sebulan setelah The Merge, beberapa light client independen diluncurkan berturut-turut, mereka menggunakan berbagai metode, tetapi memiliki tujuan yang sama: mencapai akses tanpa kepercayaan yang efisien tanpa menjalankan node lengkap.
Helios adalah light client Ethereum, yang dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, tanpa perlu penyimpanan, dan menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. Seperti semua client Ethereum, Helios mencakup lapisan eksekusi dan lapisan konsensus. Namun, berbeda dengan sebagian besar client, Helios menggabungkan kedua lapisan secara erat, sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak.
Cara kerja Helios adalah sebagai berikut: lapisan konsensus menggunakan hash blok dari rantai beacon yang diketahui, dan menghubungkan ke RPC yang tidak tepercaya, untuk mensinkronkan ke blok saat ini dengan cara yang dapat diverifikasi. Lapisan eksekusi menggabungkan blok rantai beacon yang telah diverifikasi ini dengan RPC lapisan eksekusi yang tidak tepercaya, untuk memverifikasi berbagai informasi tentang status di 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 kepada pengguna, dan tanpa perlu menjalankan node lengkap.
lapisan konsensus
Klien ringan lapisan konsensus mengikuti spesifikasi klien ringan rantai beacon, memanfaatkan komite sinkronisasi dari rantai beacon. Komite sinkronisasi terdiri dari subset 512 validator yang dipilih secara acak, dengan periode layanan sekitar 27 jam.
Validator yang masuk ke dalam komite sinkronisasi akan menandatangani semua header blok rantai beacon yang mereka lihat. Jika lebih dari 2/3 anggota komite menandatangani sebuah header blok, maka blok tersebut sangat mungkin berada di dalam rantai beacon yang sesuai. Jika Helios memahami komposisi komite sinkronisasi saat ini, ia dapat secara andal melacak kepala rantai dengan meng-query tanda tangan komite sinkronisasi terbaru.
Berkat agregasi tanda tangan BLS, verifikasi terhadap kepala blok baru dapat diselesaikan hanya dengan satu kueri. Selama tanda tangan valid dan lebih dari 2/3 anggota komite menyelesaikan tanda tangan, blok tersebut dapat dipastikan telah termasuk dalam rantai. Tentu saja, melacak finalitas blok dapat memberikan jaminan yang lebih kuat.
Dalam strategi ini, perlu juga dipecahkan bagaimana menemukan masalah dewan sinkronisasi saat ini. Pertama, perlu untuk mendapatkan akar kepercayaan yang disebut titik pemeriksaan subjektif yang lemah. Ini menunjukkan hash blok lama yang dapat dijamin dimasukkan ke dalam rantai pada suatu saat di masa lalu. Mengenai waktu keberadaan titik pemeriksaan, analisis teoretis menunjukkan bahwa dalam kasus terburuk, sekitar dua minggu, sementara perkiraan sebenarnya bisa berlangsung hingga beberapa bulan.
Jika titik pemeriksaan terlalu tua, secara teori ada kemungkinan untuk menipu node agar mengikuti rantai yang salah. Pada saat ini, mendapatkan titik pemeriksaan subyektif yang lemah melampaui kemampuan protokol. Solusi Helios adalah memberikan titik pemeriksaan awal, yang dikodekan secara keras ke dalam repositori kode ( yang mudah ditimpa ), yang akan menyimpan hash blok final terbaru secara lokal, untuk digunakan sebagai titik pemeriksaan saat node disinkronkan.
Dengan operasi hash, blok rantai beacon dapat dengan mudah menghasilkan hash blok beacon yang unik. Ini memungkinkan pencarian lengkap blok beacon dengan mudah, dan kemudian membuktikan validitas konten blok melalui perbandingan hash. Helios memanfaatkan atribut ini untuk mendapatkan dan memverifikasi bidang kunci dalam blok titik pemeriksaan subjektif lemah, termasuk komite sinkron saat ini dan komite sinkron berikutnya. Yang paling penting, klien ringan dapat memanfaatkan mekanisme ini untuk dengan cepat meninjau sejarah blockchain.
Dengan adanya titik pemeriksaan subjek lemah, kita dapat memperoleh dan memverifikasi komite sinkronisasi saat ini dan berikutnya. Jika kepala rantai saat ini dan titik pemeriksaan berada dalam siklus komite sinkronisasi yang sama, kita dapat segera menggunakan header komite sinkronisasi yang telah ditandatangani untuk memverifikasi blok baru. Jika titik pemeriksaan berada beberapa komite sinkronisasi setelahnya, maka kita dapat:
Gunakan komite sinkron berikutnya setelah titik pemeriksaan untuk mendapatkan dan memverifikasi blok yang akan dihasilkan oleh komite sinkron di masa depan.
Gunakan blok baru ini untuk mendapatkan komite sinkronisasi berikutnya.
Jika titik pemeriksaan masih di belakang, kembali ke langkah 1.
Melalui proses di atas, kami dapat dengan cepat meninjau sejarah blockchain dalam satuan 27 jam, mulai dari hash blok mana pun di masa lalu hingga disinkronkan dengan hash blok saat ini.
lapisan eksekusi
Tujuan dari light client layer 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 di Helios.
Berikut adalah contoh sederhana untuk mendapatkan saldo akun, pertama-tama memperkenalkan secara singkat bagaimana Ethereum menyimpan status. Setiap akun berisi beberapa bidang, seperti hash kode kontrak, nonce, hash penyimpanan, dan saldo. Akun-akun ini disimpan dalam pohon Merkle-Patricia besar yang telah disesuaikan, 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 pada lapisan eksekusi RPC yang tidak tepercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.
Kami menggunakan berbagai teknologi untuk memverifikasi berbagai data yang digunakan oleh lapisan eksekusi, sehingga kami dapat memverifikasi semua data dari RPC yang tidak tepercaya. RPC yang tidak tepercaya dapat menolak untuk memberikan akses data, tetapi tidak dapat memberikan hasil yang salah.
Prospek Aplikasi Helios
Sulit untuk mengakomodasi kenyamanan dan desentralisasi adalah titik sakit yang umum. Melalui Helios yang ringan, pengguna dapat mengakses data on-chain yang aman dari perangkat apa pun ( termasuk ponsel dan plugin browser ). Ini akan memungkinkan lebih banyak orang untuk mengakses data Ethereum tanpa perlu percaya, terlepas dari perangkat keras yang digunakan. Pengguna dapat menggunakan Helios sebagai penyedia RPC di dompet mereka untuk mengakses berbagai DApp tanpa perlu percaya, seluruh proses tanpa perubahan tambahan.
Selain itu, dukungan Rust untuk WebAssembly memungkinkan pengembang aplikasi dengan mudah menyematkan Helios ke dalam aplikasi Javascript ( seperti dompet dan DApp ). Integrasi ini akan meningkatkan keamanan Ethereum dan mengurangi kebutuhan kami untuk mempercayai infrastruktur terpusat.
Komunitas dapat berkontribusi pada Helios dengan berbagai cara, selain memperbaiki repositori kode, mereka juga dapat membangun perangkat lunak yang mengintegrasikan Helios untuk memanfaatkan keuntungannya. Berikut adalah beberapa arah pengembangan yang potensial: