Ethereum light client Helios: mewujudkan akses blockchain tanpa kepercayaan
Pada 8 November, sebuah klien ringan Ethereum baru bernama Helios diluncurkan. Klien yang dikembangkan dengan bahasa Rust ini bertujuan untuk menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan.
Salah satu alasan utama kami menggunakan Blockchain adalah karena tidak perlu saling percaya. Melalui Blockchain, kami dapat mengendalikan kekayaan dan data kami sendiri. Dalam banyak kasus, Blockchain seperti Ethereum benar-benar memenuhi janji ini: aset kami benar-benar milik kami.
Namun, untuk mengejar kenyamanan, kami juga melakukan beberapa kompromi. Salah satunya adalah menggunakan RPC( terpusat untuk memanggil) server. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud, membantu pengguna dengan mudah mengakses data di blockchain. Ketika dompet memeriksa saldo token atau memeriksa apakah transaksi yang tertunda telah dimasukkan ke dalam blok, penyedia terpusat ini hampir selalu digunakan.
Masalah dalam sistem saat ini adalah pengguna perlu mempercayai penyedia ini, tanpa dapat memverifikasi apakah hasil query tersebut benar.
Helios adalah klien ringan Ethereum yang berbasis Rust, yang dapat memberikan 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 menjalankan node lengkap.
Sulit untuk menyeimbangkan kenyamanan dan desentralisasi adalah masalah umum, klien baru ini dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, dan tidak memerlukan penyimpanan, pengguna dapat mengakses data on-chain yang aman melalui perangkat apa pun ( termasuk ponsel dan plugin browser ). Namun, apa risiko potensial yang terkait dengan bergantung pada infrastruktur terpusat? Artikel ini akan merangkum risiko-risiko tersebut, memperkenalkan desain Helios, dan memberikan beberapa pemikiran untuk membantu pengembang berkontribusi pada repositori kode.
Risiko Infrastruktur Terpusat: Produk Teoretis dalam "Hutan Gelap" Ethereum
Sebuah produk teoretis bersembunyi di dalam hutan gelap. Ia tidak mencari mangsa di dalam mempool transaksi Ethereum, tetapi mengatur perangkap dengan mensimulasikan infrastruktur terpusat yang kita andalkan. Pengguna yang terjebak dalam perangkap tersebut tidak melakukan kesalahan: mereka hanya mengunjungi bursa terdesentralisasi yang biasa mereka gunakan, mengatur slippage yang wajar, dan membeli serta menjual token seperti biasa... Mereka tidak melakukan kesalahan, tetapi tetap mengalami serangan sandwich baru, yaitu perangkap yang dipasang dengan cermat di pintu masuk hutan gelap Ethereum — penyedia RPC.
Sebelum menjelaskan secara rinci, mari kita lihat bagaimana bursa terdesentralisasi menangani transaksi. Ketika pengguna melakukan transaksi pertukaran, mereka akan memberikan beberapa parameter kepada kontrak pintar: token yang akan dipertukarkan, jumlah pertukaran, dan yang paling penting, jumlah token minimum yang harus diterima pengguna untuk memproses transaksi. Parameter terakhir menunjukkan "hasil minimum" yang harus dicapai untuk pertukaran, jika tidak, transaksi akan dibatalkan. Ini biasanya disebut sebagai "slippage", karena secara efektif menetapkan selisih harga maksimum yang mungkin terjadi antara pengiriman transaksi ke mempool dan transaksi yang dimasukkan ke dalam blok. Jika pengaturan slippage terlalu rendah, pengguna mungkin hanya dapat menerima token yang lebih sedikit. Situasi ini juga dapat menyebabkan serangan sandwich, di mana penyerang dapat menyisipkan tawaran pengguna di antara dua transaksi jahat. Transaksi ini akan mendorong harga spot naik, memaksa pengguna untuk berdagang dengan harga yang kurang menguntungkan. Kemudian, penyerang akan segera menjual token, mendapatkan keuntungan kecil.
Selama parameter hasil minimum ini ditetapkan di dekat nilai yang wajar, Anda tidak akan terkena serangan sandwich. Tetapi bagaimana jika penyedia RPC Anda tidak memberikan kutipan akurat untuk kontrak pintar bursa terdesentralisasi? Dengan demikian, pengguna mungkin akan tertipu dan menandatangani transaksi pertukaran dengan parameter hasil minimum yang lebih rendah, lebih buruk lagi, pengguna mungkin juga mengirim transaksi langsung ke penyedia RPC yang berbahaya. Penyedia dapat memilih untuk tidak menyiarkan transaksi ini ke dalam mempool publik ( di mana puluhan bot bersaing untuk meluncurkan serangan sandwich ), dan secara pribadi menahan dan mengirim paket transaksi yang diserang langsung ke platform MEV tertentu untuk mendapatkan keuntungan.
Penyebab mendasar dari serangan ini adalah mempercayai orang lain untuk membantu Anda mendapatkan status Blockchain. Untuk mengatasi masalah ini, pengguna yang berpengalaman biasanya akan menjalankan node Ethereum mereka sendiri, pekerjaan ini membutuhkan banyak waktu dan sumber daya, setidaknya memerlukan satu perangkat yang selalu online, ratusan GB ruang penyimpanan, dan sekitar satu hari waktu untuk menyinkronkan dari awal. Proses ini jelas telah disederhanakan dibandingkan dengan masa lalu. Beberapa kelompok telah berusaha tanpa lelah, membantu semua orang menjalankan node dengan perangkat keras berbiaya rendah seperti komputer mini Raspberry Pi ( dengan hard drive eksternal ). Namun, meskipun permintaan untuk mengurangi secara drastis, menjalankan node masih sulit bagi sebagian besar pengguna, terutama pengguna yang menggunakan perangkat seluler.
Perlu dicatat bahwa serangan penyedia RPC terpusat meskipun sepenuhnya mungkin terjadi, biasanya hanya serangan phishing yang sederhana, serangan yang kami maksudkan belum pernah terjadi. Meskipun rekam jejak penyedia besar tidak memberi kami alasan untuk meragukan mereka, melakukan penelitian lebih lanjut sebelum menambahkan penyedia RPC yang tidak dikenal ke dompet masih sangat berharga.
Helios: Akses Ethereum Tanpa Kepercayaan Penuh
Ethereum meluncurkan protokol light client, membuka kemungkinan menarik untuk interaksi blockchain yang cepat dan verifikasi endpoint RPC dengan kebutuhan perangkat keras minimal. Dalam sebulan setelah The Merge, sekelompok light client yang saling independen bermunculan, masing-masing menjelajahi jalannya sendiri, hanya untuk satu tujuan: akses efisien tanpa perlu mempercayai, dan tanpa harus menggunakan node penuh.
Helios adalah sebuah light client Ethereum, dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, tanpa perlu penyimpanan, dan menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. Seperti semua klien Ethereum, Helios terdiri dari lapisan eksekusi dan lapisan konsensus. Namun, berbeda dengan kebanyakan klien lainnya, Helios menggabungkan kedua lapisan ini secara erat, sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak.
Bagaimana cara kerjanya? Lapisan konsensus Helios menggunakan hash blok rantai sinyal yang sudah dikenal, dan menghubungkan RPC yang tidak tepercaya, untuk menyinkronkan ke blok saat ini dengan cara yang dapat diverifikasi. Lapisan eksekusi Helios menggabungkan blok rantai sinyal yang telah diverifikasi dengan RPC lapisan eksekusi yang tidak tepercaya, untuk memverifikasi berbagai informasi tentang status di rantai, seperti saldo akun, penyimpanan kontrak, tanda terima transaksi, dan hasil panggilan kontrak pintar. Komponen-komponen ini bekerja sama untuk menyediakan RPC yang sepenuhnya tidak memerlukan kepercayaan bagi pengguna, tanpa perlu menjalankan node penuh.
lapisan konsensus
Light client di lapisan konsensus memenuhi spesifikasi light client dari Beacon Chain, dan memanfaatkan komite sinkronisasi Beacon Chain ( yang diluncurkan sebelum Merge dari hard fork Altair ). Komite sinkronisasi terdiri dari subset 512 validator yang dipilih secara acak, dengan periode layanan sekitar 27 jam.
Setelah validator bergabung dengan dewan sinkronisasi, mereka akan menandatangani semua header blok rantai beacon yang terlihat (block header). Jika lebih dari dua pertiga anggota dewan menandatangani satu header blok, maka blok tersebut sangat mungkin berada di dalam rantai beacon standar. Jika Helios memahami komposisi dewan sinkronisasi saat ini, ia dapat dengan percaya diri melacak kepala rantai dengan menanyakan tanda tangan dewan sinkronisasi terbaru melalui RPC yang tidak tepercaya.
Berkat agregasi tanda tangan BLS, verifikasi terhadap kepala blok baru dapat dilakukan dengan satu permintaan. Selama tanda tangan valid dan lebih dari dua pertiga anggota komite telah menyelesaikan tanda tangan, blok dapat dipastikan telah termasuk dalam rantai (. Tentu saja, itu juga bisa direorganisasi ke luar rantai, dan pelacakan finalitas blok dapat memberikan jaminan yang lebih kuat ).
Tetapi jelas bahwa strategi ini kekurangan satu aspek: bagaimana menemukan komite sinkron saat ini. Pertama-tama, perlu mendapatkan akar kepercayaan yang disebut titik pemeriksaan subyektivitas lemah (weak subjectivity checkpoint). Jangan takut dengan namanya, itu hanya menunjukkan hash blok lama yang dapat dijamin telah dimasukkan ke dalam rantai pada titik waktu tertentu di masa lalu. Ada beberapa perhitungan matematika menarik di balik waktu keberadaan titik pemeriksaan yang tepat: analisis kasus terburuk menunjukkan sekitar dua minggu, sementara estimasi yang lebih realistis menunjukkan beberapa bulan.
Jika titik pemeriksaan terlalu tua, secara teori ada serangan yang dapat menipu node untuk mengikuti rantai yang salah. Dalam hal ini, mendapatkan titik pemeriksaan subjektivitas lemah berada di luar kemampuan protokol. Solusi Helios adalah menyediakan titik pemeriksaan awal, yang dikodekan secara keras ke dalam repositori kode ( yang mudah ditimpa ), yang akan menyimpan hash blok akhir 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. Dengan demikian, mudah untuk meminta blok beacon lengkap dari node, dan kemudian dengan melakukan operasi hash pada blok tersebut dan membandingkannya dengan hash blok yang diketahui, untuk membuktikan validitas konten blok. Helios memanfaatkan atribut ini untuk mendapatkan dan memverifikasi beberapa bidang dalam blok titik pemeriksaan subjektif lemah, termasuk dua bidang penting: komite sinkron saat ini dan komite sinkron berikutnya. Yang paling penting, klien ringan dapat memanfaatkan mekanisme ini untuk dengan cepat meninjau sejarah blockchain.
Sekarang dengan adanya titik pemeriksaan subyektif yang 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 mulai menggunakan header komite sinkronisasi yang telah ditandatangani untuk memverifikasi blok baru. Jika titik pemeriksaan kita terletak setelah beberapa komite sinkronisasi, maka kita dapat:
Gunakan dewan sinkronisasi berikutnya setelah titik pemeriksaan untuk mendapatkan dan memverifikasi blok dari dewan sinkronisasi yang akan dihasilkan di masa depan.
2.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 unit waktu 27 jam, mulai dari hash blok mana pun di masa lalu hingga sinkron dengan hash blok saat ini.
lapisan eksekusi
Tujuan dari light client lapisan eksekusi adalah untuk menggabungkan header blok beacon yang telah divalidasi 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 mari kita perkenalkan secara singkat bagaimana Ethereum menyimpan status. Setiap akun terdiri dari beberapa bidang, seperti hash kode kontrak, nomor acak, 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 di dalam pohon tersebut. Bukti ini tidak dapat dipalsukan.
Helios memiliki sebuah root status yang diverifikasi dari lapisan konsensus (state root). Dengan menerapkan root status ini dan permintaan bukti Merkle melalui RPC lapisan eksekusi yang tidak terpercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.
Kami menggunakan berbagai teknologi untuk memverifikasi berbagai data yang digunakan oleh lapisan eksekusi, dengan cara ini, kami dapat memverifikasi semua data yang berasal dari RPC yang tidak dipercaya. RPC yang tidak dipercaya dapat menolak memberikan akses data, tetapi tidak dapat lagi memberikan hasil yang salah.
Menggunakan Helios di Dunia Nyata
Sulit untuk menyeimbangkan kemudahan dan desentralisasi adalah titik nyeri 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 kepercayaan, terlepas dari perangkat keras yang digunakan. Pengguna dapat menjadikan Helios sebagai penyedia RPC mereka di dompet tertentu, untuk mengakses berbagai DApp tanpa kepercayaan, seluruh proses tidak memerlukan perubahan lebih lanjut.
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, mengurangi kebutuhan kita akan kepercayaan pada infrastruktur terpusat.
Ada banyak cara untuk berkontribusi pada Helios, selain menambah kode pada repositori, Anda juga dapat membangun perangkat lunak yang terintegrasi dengan Helios untuk memanfaatkan keuntungannya. Berikut adalah beberapa ide menarik:
Mendukung pengambilan data light client langsung dari jaringan P2P, bukan dari RPC
Mengimplementasikan beberapa metode RPC yang hilang
Membangun 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 Ethereum tanpa kepercayaan
Ethereum light client Helios: mewujudkan akses blockchain tanpa kepercayaan
Pada 8 November, sebuah klien ringan Ethereum baru bernama Helios diluncurkan. Klien yang dikembangkan dengan bahasa Rust ini bertujuan untuk menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan.
Salah satu alasan utama kami menggunakan Blockchain adalah karena tidak perlu saling percaya. Melalui Blockchain, kami dapat mengendalikan kekayaan dan data kami sendiri. Dalam banyak kasus, Blockchain seperti Ethereum benar-benar memenuhi janji ini: aset kami benar-benar milik kami.
Namun, untuk mengejar kenyamanan, kami juga melakukan beberapa kompromi. Salah satunya adalah menggunakan RPC( terpusat untuk memanggil) server. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud, membantu pengguna dengan mudah mengakses data di blockchain. Ketika dompet memeriksa saldo token atau memeriksa apakah transaksi yang tertunda telah dimasukkan ke dalam blok, penyedia terpusat ini hampir selalu digunakan.
Masalah dalam sistem saat ini adalah pengguna perlu mempercayai penyedia ini, tanpa dapat memverifikasi apakah hasil query tersebut benar.
Helios adalah klien ringan Ethereum yang berbasis Rust, yang dapat memberikan 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 menjalankan node lengkap.
Sulit untuk menyeimbangkan kenyamanan dan desentralisasi adalah masalah umum, klien baru ini dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, dan tidak memerlukan penyimpanan, pengguna dapat mengakses data on-chain yang aman melalui perangkat apa pun ( termasuk ponsel dan plugin browser ). Namun, apa risiko potensial yang terkait dengan bergantung pada infrastruktur terpusat? Artikel ini akan merangkum risiko-risiko tersebut, memperkenalkan desain Helios, dan memberikan beberapa pemikiran untuk membantu pengembang berkontribusi pada repositori kode.
Risiko Infrastruktur Terpusat: Produk Teoretis dalam "Hutan Gelap" Ethereum
Sebuah produk teoretis bersembunyi di dalam hutan gelap. Ia tidak mencari mangsa di dalam mempool transaksi Ethereum, tetapi mengatur perangkap dengan mensimulasikan infrastruktur terpusat yang kita andalkan. Pengguna yang terjebak dalam perangkap tersebut tidak melakukan kesalahan: mereka hanya mengunjungi bursa terdesentralisasi yang biasa mereka gunakan, mengatur slippage yang wajar, dan membeli serta menjual token seperti biasa... Mereka tidak melakukan kesalahan, tetapi tetap mengalami serangan sandwich baru, yaitu perangkap yang dipasang dengan cermat di pintu masuk hutan gelap Ethereum — penyedia RPC.
Sebelum menjelaskan secara rinci, mari kita lihat bagaimana bursa terdesentralisasi menangani transaksi. Ketika pengguna melakukan transaksi pertukaran, mereka akan memberikan beberapa parameter kepada kontrak pintar: token yang akan dipertukarkan, jumlah pertukaran, dan yang paling penting, jumlah token minimum yang harus diterima pengguna untuk memproses transaksi. Parameter terakhir menunjukkan "hasil minimum" yang harus dicapai untuk pertukaran, jika tidak, transaksi akan dibatalkan. Ini biasanya disebut sebagai "slippage", karena secara efektif menetapkan selisih harga maksimum yang mungkin terjadi antara pengiriman transaksi ke mempool dan transaksi yang dimasukkan ke dalam blok. Jika pengaturan slippage terlalu rendah, pengguna mungkin hanya dapat menerima token yang lebih sedikit. Situasi ini juga dapat menyebabkan serangan sandwich, di mana penyerang dapat menyisipkan tawaran pengguna di antara dua transaksi jahat. Transaksi ini akan mendorong harga spot naik, memaksa pengguna untuk berdagang dengan harga yang kurang menguntungkan. Kemudian, penyerang akan segera menjual token, mendapatkan keuntungan kecil.
Selama parameter hasil minimum ini ditetapkan di dekat nilai yang wajar, Anda tidak akan terkena serangan sandwich. Tetapi bagaimana jika penyedia RPC Anda tidak memberikan kutipan akurat untuk kontrak pintar bursa terdesentralisasi? Dengan demikian, pengguna mungkin akan tertipu dan menandatangani transaksi pertukaran dengan parameter hasil minimum yang lebih rendah, lebih buruk lagi, pengguna mungkin juga mengirim transaksi langsung ke penyedia RPC yang berbahaya. Penyedia dapat memilih untuk tidak menyiarkan transaksi ini ke dalam mempool publik ( di mana puluhan bot bersaing untuk meluncurkan serangan sandwich ), dan secara pribadi menahan dan mengirim paket transaksi yang diserang langsung ke platform MEV tertentu untuk mendapatkan keuntungan.
Penyebab mendasar dari serangan ini adalah mempercayai orang lain untuk membantu Anda mendapatkan status Blockchain. Untuk mengatasi masalah ini, pengguna yang berpengalaman biasanya akan menjalankan node Ethereum mereka sendiri, pekerjaan ini membutuhkan banyak waktu dan sumber daya, setidaknya memerlukan satu perangkat yang selalu online, ratusan GB ruang penyimpanan, dan sekitar satu hari waktu untuk menyinkronkan dari awal. Proses ini jelas telah disederhanakan dibandingkan dengan masa lalu. Beberapa kelompok telah berusaha tanpa lelah, membantu semua orang menjalankan node dengan perangkat keras berbiaya rendah seperti komputer mini Raspberry Pi ( dengan hard drive eksternal ). Namun, meskipun permintaan untuk mengurangi secara drastis, menjalankan node masih sulit bagi sebagian besar pengguna, terutama pengguna yang menggunakan perangkat seluler.
Perlu dicatat bahwa serangan penyedia RPC terpusat meskipun sepenuhnya mungkin terjadi, biasanya hanya serangan phishing yang sederhana, serangan yang kami maksudkan belum pernah terjadi. Meskipun rekam jejak penyedia besar tidak memberi kami alasan untuk meragukan mereka, melakukan penelitian lebih lanjut sebelum menambahkan penyedia RPC yang tidak dikenal ke dompet masih sangat berharga.
Helios: Akses Ethereum Tanpa Kepercayaan Penuh
Ethereum meluncurkan protokol light client, membuka kemungkinan menarik untuk interaksi blockchain yang cepat dan verifikasi endpoint RPC dengan kebutuhan perangkat keras minimal. Dalam sebulan setelah The Merge, sekelompok light client yang saling independen bermunculan, masing-masing menjelajahi jalannya sendiri, hanya untuk satu tujuan: akses efisien tanpa perlu mempercayai, dan tanpa harus menggunakan node penuh.
Helios adalah sebuah light client Ethereum, dapat menyelesaikan sinkronisasi dalam waktu sekitar dua detik, tanpa perlu penyimpanan, dan menyediakan akses Ethereum yang sepenuhnya tanpa kepercayaan. Seperti semua klien Ethereum, Helios terdiri dari lapisan eksekusi dan lapisan konsensus. Namun, berbeda dengan kebanyakan klien lainnya, Helios menggabungkan kedua lapisan ini secara erat, sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak.
Bagaimana cara kerjanya? Lapisan konsensus Helios menggunakan hash blok rantai sinyal yang sudah dikenal, dan menghubungkan RPC yang tidak tepercaya, untuk menyinkronkan ke blok saat ini dengan cara yang dapat diverifikasi. Lapisan eksekusi Helios menggabungkan blok rantai sinyal yang telah diverifikasi dengan RPC lapisan eksekusi yang tidak tepercaya, untuk memverifikasi berbagai informasi tentang status di rantai, seperti saldo akun, penyimpanan kontrak, tanda terima transaksi, dan hasil panggilan kontrak pintar. Komponen-komponen ini bekerja sama untuk menyediakan RPC yang sepenuhnya tidak memerlukan kepercayaan bagi pengguna, tanpa perlu menjalankan node penuh.
lapisan konsensus
Light client di lapisan konsensus memenuhi spesifikasi light client dari Beacon Chain, dan memanfaatkan komite sinkronisasi Beacon Chain ( yang diluncurkan sebelum Merge dari hard fork Altair ). Komite sinkronisasi terdiri dari subset 512 validator yang dipilih secara acak, dengan periode layanan sekitar 27 jam.
Setelah validator bergabung dengan dewan sinkronisasi, mereka akan menandatangani semua header blok rantai beacon yang terlihat (block header). Jika lebih dari dua pertiga anggota dewan menandatangani satu header blok, maka blok tersebut sangat mungkin berada di dalam rantai beacon standar. Jika Helios memahami komposisi dewan sinkronisasi saat ini, ia dapat dengan percaya diri melacak kepala rantai dengan menanyakan tanda tangan dewan sinkronisasi terbaru melalui RPC yang tidak tepercaya.
Berkat agregasi tanda tangan BLS, verifikasi terhadap kepala blok baru dapat dilakukan dengan satu permintaan. Selama tanda tangan valid dan lebih dari dua pertiga anggota komite telah menyelesaikan tanda tangan, blok dapat dipastikan telah termasuk dalam rantai (. Tentu saja, itu juga bisa direorganisasi ke luar rantai, dan pelacakan finalitas blok dapat memberikan jaminan yang lebih kuat ).
Tetapi jelas bahwa strategi ini kekurangan satu aspek: bagaimana menemukan komite sinkron saat ini. Pertama-tama, perlu mendapatkan akar kepercayaan yang disebut titik pemeriksaan subyektivitas lemah (weak subjectivity checkpoint). Jangan takut dengan namanya, itu hanya menunjukkan hash blok lama yang dapat dijamin telah dimasukkan ke dalam rantai pada titik waktu tertentu di masa lalu. Ada beberapa perhitungan matematika menarik di balik waktu keberadaan titik pemeriksaan yang tepat: analisis kasus terburuk menunjukkan sekitar dua minggu, sementara estimasi yang lebih realistis menunjukkan beberapa bulan.
Jika titik pemeriksaan terlalu tua, secara teori ada serangan yang dapat menipu node untuk mengikuti rantai yang salah. Dalam hal ini, mendapatkan titik pemeriksaan subjektivitas lemah berada di luar kemampuan protokol. Solusi Helios adalah menyediakan titik pemeriksaan awal, yang dikodekan secara keras ke dalam repositori kode ( yang mudah ditimpa ), yang akan menyimpan hash blok akhir 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. Dengan demikian, mudah untuk meminta blok beacon lengkap dari node, dan kemudian dengan melakukan operasi hash pada blok tersebut dan membandingkannya dengan hash blok yang diketahui, untuk membuktikan validitas konten blok. Helios memanfaatkan atribut ini untuk mendapatkan dan memverifikasi beberapa bidang dalam blok titik pemeriksaan subjektif lemah, termasuk dua bidang penting: komite sinkron saat ini dan komite sinkron berikutnya. Yang paling penting, klien ringan dapat memanfaatkan mekanisme ini untuk dengan cepat meninjau sejarah blockchain.
Sekarang dengan adanya titik pemeriksaan subyektif yang 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 mulai menggunakan header komite sinkronisasi yang telah ditandatangani untuk memverifikasi blok baru. Jika titik pemeriksaan kita terletak setelah beberapa komite sinkronisasi, maka kita dapat:
2.Gunakan blok baru ini untuk mendapatkan komite sinkronisasi berikutnya.
Melalui proses di atas, kami dapat dengan cepat meninjau sejarah Blockchain dalam unit waktu 27 jam, mulai dari hash blok mana pun di masa lalu hingga sinkron dengan hash blok saat ini.
lapisan eksekusi
Tujuan dari light client lapisan eksekusi adalah untuk menggabungkan header blok beacon yang telah divalidasi 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 mari kita perkenalkan secara singkat bagaimana Ethereum menyimpan status. Setiap akun terdiri dari beberapa bidang, seperti hash kode kontrak, nomor acak, 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 di dalam pohon tersebut. Bukti ini tidak dapat dipalsukan.
Helios memiliki sebuah root status yang diverifikasi dari lapisan konsensus (state root). Dengan menerapkan root status ini dan permintaan bukti Merkle melalui RPC lapisan eksekusi yang tidak terpercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.
Kami menggunakan berbagai teknologi untuk memverifikasi berbagai data yang digunakan oleh lapisan eksekusi, dengan cara ini, kami dapat memverifikasi semua data yang berasal dari RPC yang tidak dipercaya. RPC yang tidak dipercaya dapat menolak memberikan akses data, tetapi tidak dapat lagi memberikan hasil yang salah.
Menggunakan Helios di Dunia Nyata
Sulit untuk menyeimbangkan kemudahan dan desentralisasi adalah titik nyeri 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 kepercayaan, terlepas dari perangkat keras yang digunakan. Pengguna dapat menjadikan Helios sebagai penyedia RPC mereka di dompet tertentu, untuk mengakses berbagai DApp tanpa kepercayaan, seluruh proses tidak memerlukan perubahan lebih lanjut.
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, mengurangi kebutuhan kita akan kepercayaan pada infrastruktur terpusat.
Ada banyak cara untuk berkontribusi pada Helios, selain menambah kode pada repositori, Anda juga dapat membangun perangkat lunak yang terintegrasi dengan Helios untuk memanfaatkan keuntungannya. Berikut adalah beberapa ide menarik: