Membangun Helios: Akses tanpa kepercayaan penuh ke Ethereum

Salah satu alasan utama kami menggunakan blockchain adalah tidak dapat dipercaya. Properti ini berjanji untuk memberi kami akses berdaulat sendiri ke kekayaan dan data kami. Sebagian besar, blockchain seperti Ethereum telah memenuhi janji ini — aset kami benar-benar milik kami. 

Namun, ada kelonggaran yang kami buat demi kenyamanan. Salah satu area tersebut adalah penggunaan server RPC (panggilan prosedur jarak jauh) terpusat. Pengguna biasanya mengakses Ethereum melalui penyedia terpusat seperti Alchemy. Perusahaan-perusahaan ini menjalankan node berkinerja tinggi di server cloud sehingga orang lain dapat dengan mudah mengakses data berantai. Saat dompet menanyakan saldo tokennya atau memeriksa apakah transaksi yang tertunda telah dimasukkan ke dalam blok, hampir selalu melakukannya melalui salah satu penyedia terpusat ini. 

Masalah dengan sistem yang ada adalah pengguna harus mempercayai penyedia, dan tidak ada cara untuk memverifikasi kebenaran permintaan mereka.

Enter Helios, klien ringan Ethereum berbasis Rust yang kami kembangkan yang menyediakan akses tanpa kepercayaan penuh ke Ethereum. Helios — yang menggunakan protokol klien ringan Ethereum, dimungkinkan oleh saklar baru-baru ini untuk bukti kepemilikan — mengonversi data dari penyedia RPC terpusat yang tidak tepercaya menjadi RPC lokal yang benar-benar aman. Helios bekerja sama dengan RPC terpusat untuk memungkinkan verifikasi keasliannya tanpa menjalankan node penuh. 

Pertukaran antara portabilitas dan desentralisasi adalah masalah umum, tetapi klien kami – yang telah kami sediakan untuk publik untuk dibangun dan lebih banyak lagi – menyinkronkan dalam waktu sekitar dua detik, tidak memerlukan penyimpanan, dan memungkinkan pengguna untuk mengakses data rantai aman dari perangkat apa pun (termasuk ponsel dan ekstensi browser). Tapi apa potensi jebakan mengandalkan infrastruktur terpusat? Kami membahas bagaimana mereka mungkin bermain di posting ini, berjalan melalui keputusan desain kami, dan juga menguraikan beberapa ide untuk orang lain untuk berkontribusi pada basis kode.

Perangkap infrastruktur terpusat: makhluk teoretis di "hutan gelap" Ethereum

Makhluk (teoritis) mengintai di hutan gelap. Yang ini tidak memburu mangsanya di mempool Ethereum, melainkan memasang jebakannya dengan meniru infrastruktur terpusat yang telah kami andalkan. Pengguna yang terjebak dalam perangkap ini tidak melakukan kesalahan apa pun: Mereka mengunjungi bursa terdesentralisasi favorit mereka, menetapkan toleransi selip yang masuk akal, dan membeli dan menjual token seperti biasa… Mereka melakukan segalanya dengan benar, tetapi tetap menjadi korban jenis baru serangan sandwich, jebakan yang dipasang dengan cermat di pintu masuk ke hutan gelap Ethereum: penyedia RPC.

Sebelum kita menguraikan, mari kita lihat bagaimana perdagangan bekerja di bursa terdesentralisasi. Saat pengguna mengirim transaksi swap, mereka memberikan beberapa parameter ke kontrak cerdas — token mana yang akan ditukar, jumlah swap, dan yang paling penting, jumlah minimum token yang harus diterima pengguna agar transaksi dapat dilalui. Parameter terakhir ini menentukan bahwa swap harus memenuhi "output minimum", atau kembali. Ini sering dikenal sebagai "toleransi selip", karena ini secara efektif menetapkan perubahan harga maksimum yang dapat terjadi antara saat transaksi dikirim ke mempool dan saat dimasukkan ke dalam blok. Jika parameter ini disetel terlalu rendah, pengguna menerima kemungkinan menerima lebih sedikit token. Situasi ini juga dapat menyebabkan serangan sandwich, di mana penyerang secara efektif mengapit penawaran di antara dua pertukaran berbahaya. Swap menaikkan harga spot dan memaksa perdagangan pengguna untuk dieksekusi dengan harga yang kurang menguntungkan. Penyerang kemudian segera menjual untuk mengumpulkan keuntungan kecil.

Selama parameter keluaran minimum ini disetel mendekati nilai wajar, Anda aman dari serangan sandwich. Tetapi bagaimana jika penyedia RPC Anda tidak memberikan penawaran harga yang akurat dari kontrak pintar pertukaran terdesentralisasi? Seorang pengguna kemudian dapat tertipu untuk menandatangani transaksi swap dengan parameter keluaran minimum yang lebih rendah, dan, yang lebih buruk lagi, mengirimkan transaksi langsung ke penyedia RPC jahat. Alih-alih menyiarkan transaksi ini ke mempool publik, di mana lusinan bot bersaing untuk melakukan serangan sandwich, penyedia dapat menahannya dan mengirimkan bundel transaksi serangan langsung ke Flashbots, mengamankan keuntungan untuk diri mereka sendiri.

Akar penyebab serangan ini adalah mempercayai orang lain untuk mengambil status blockchain. Pengguna berpengalaman secara tradisional memecahkan masalah ini dengan menjalankan node Ethereum mereka sendiri — upaya intensif waktu dan sumber daya yang, paling tidak, membutuhkan mesin yang selalu online, penyimpanan ratusan gigabyte, dan sekitar satu hari untuk menyinkronkan dari awal. Proses ini tentunya lebih mudah dari sebelumnya; kelompok suka Ethereum di ARM telah bekerja tanpa lelah untuk memungkinkan menjalankan node pada perangkat keras berbiaya rendah (seperti Raspberry Pi dengan hard drive eksternal yang diikatkan padanya). Tetapi bahkan dengan persyaratan yang relatif minimal ini, menjalankan sebuah node masih sulit bagi sebagian besar pengguna, terutama bagi mereka yang menggunakan perangkat seluler.

Penting untuk dicatat bahwa serangan penyedia RPC terpusat, meskipun sepenuhnya masuk akal, pada umumnya serangan phishing sederhana - dan yang kami gambarkan belum terjadi. Meskipun rekam jejak penyedia yang lebih besar seperti Alchemy memberi kami sedikit alasan untuk meragukannya, ada baiknya melakukan penelitian lebih lanjut sebelum menambahkan penyedia RPC yang tidak dikenal ke dompet Anda.

Memperkenalkan Helios: akses sepenuhnya tanpa kepercayaan ke Ethereum

Dengan memperkenalkan protokol klien ringannya (dimungkinkan oleh peralihan baru-baru ini ke Proof of Stake), Ethereum membuka kemungkinan baru yang menarik untuk berinteraksi dengan blockchain dengan cepat dan memverifikasi titik akhir RPC dengan persyaratan perangkat keras minimal. Pada bulan sejak Penggabungan, kami telah melihat potongan baru klien ringan muncul secara independen satu sama lain (Pedoman, nimbus, dan berbasis JavaScript Kevlar) yang telah mengambil pendekatan berbeda dalam melayani tujuan yang sama: akses yang efisien dan tidak dapat dipercaya, tanpa menggunakan simpul penuh.

Solusi kami, Helios, adalah klien ringan Ethereum yang menyinkronkan sekitar dua detik, tidak memerlukan penyimpanan, dan menyediakan akses yang sepenuhnya tanpa kepercayaan ke Ethereum. Seperti semua klien Ethereum, Helios terdiri dari lapisan eksekusi dan lapisan konsensus. Tidak seperti kebanyakan klien lain, Helios memasangkan kedua lapisan dengan erat sehingga pengguna hanya perlu menginstal dan menjalankan satu perangkat lunak. (erigon bergerak ke arah ini juga, dengan menambahkan klien cahaya lapisan konsensus yang dibangun langsung ke node arsip mereka). 

Jadi bagaimana cara kerjanya? Lapisan konsensus Helios menggunakan blockhash rantai suar yang dikenal sebelumnya dan koneksi ke RPC yang tidak tepercaya untuk menyinkronkan ke blok saat ini. Lapisan eksekusi Helios menggunakan blok rantai suar yang diautentikasi ini bersama-sama dengan RPC lapisan eksekusi yang tidak tepercaya untuk membuktikan informasi sewenang-wenang tentang status rantai seperti saldo akun, penyimpanan kontrak, tanda terima transaksi, dan hasil panggilan kontrak cerdas. Komponen-komponen ini bekerja bersama untuk melayani pengguna RPC yang sepenuhnya tidak dapat dipercaya, tanpa perlu menjalankan node penuh.

…Pada lapisan konsensus

Klien cahaya lapisan konsensus sesuai dengan klien cahaya rantai suar spesifikasi, dan memanfaatkan komite sinkronisasi rantai suar (diperkenalkan sebelum hard fork Merge di Altair). Komite sinkronisasi adalah subset yang dipilih secara acak dari 512 validator yang melayani selama periode ~27 jam. 

Saat validator berada di komite sinkronisasi, mereka menandatangani setiap header blok rantai suar yang mereka lihat. Jika lebih dari dua pertiga panitia menandatangani tajuk blok yang diberikan, kemungkinan besar blok tersebut berada dalam rantai suar kanonis. Jika Helios mengetahui susunan komite sinkronisasi saat ini, ia dapat dengan yakin melacak kepala rantai dengan meminta RPC yang tidak tepercaya untuk tanda tangan komite sinkronisasi terbaru. 

Terima kasih kepada BLS tanda tangan agregasi, hanya satu pemeriksaan yang diperlukan untuk memvalidasi header baru. Jika tanda tangannya valid dan telah ditandatangani oleh lebih dari dua pertiga panitia, dapat diasumsikan bahwa blok tersebut termasuk dalam rantai (tentu saja dapat diatur ulang keluar dari rantai, tetapi finalitas blok pelacakan dapat memberikan jaminan yang lebih ketat).

Namun, ada bagian yang hilang dalam strategi ini: bagaimana menemukan komite sinkronisasi saat ini. Ini dimulai dengan memperoleh akar kepercayaan yang disebut pos pemeriksaan subjektivitas yang lemah. Jangan biarkan namanya mengintimidasi Anda — itu hanya berarti blockhash lama yang dapat kami jamin telah dimasukkan ke dalam rantai di beberapa titik di masa lalu. Ada beberapa matematika menarik di balik berapa tepatnya usia pos pemeriksaan itu; analisis kasus terburuk menyarankan sekitar dua minggu, sementara perkiraan yang lebih praktis menyarankan berbulan-bulan. 

Jika pos pemeriksaan terlalu tua, ada serangan teoretis yang dapat mengelabui node agar mengikuti rantai yang salah. Memperoleh pos pemeriksaan subjektivitas yang lemah tidak sesuai dengan protokol. Pendekatan kami dengan Helios menyediakan pos pemeriksaan awal yang di-hardcode ke dalam basis kode (yang dapat dengan mudah diganti); itu kemudian menyimpan blockhash final terbaru secara lokal untuk digunakan sebagai pos pemeriksaan di masa mendatang, setiap kali node disinkronkan. 

Mudahnya, blok rantai suar dapat di-hash untuk menghasilkan blok suar yang unik. Ini berarti mudah untuk meminta node untuk blok suar penuh, dan kemudian membuktikan bahwa konten blok itu valid dengan melakukan hashing dan membandingkannya dengan blockhash yang dikenal. Helios menggunakan properti ini untuk mengambil dan membuktikan bidang tertentu di dalam blok pos pemeriksaan subjektivitas yang lemah, termasuk dua bidang yang sangat penting: komite sinkronisasi saat ini, dan komite sinkronisasi berikutnya. Secara kritis, mekanisme ini memungkinkan klien ringan untuk maju cepat melalui sejarah blockchain.

Sekarang kami memiliki pos pemeriksaan subjektivitas yang lemah, kami dapat mengambil dan memverifikasi komite sinkronisasi saat ini dan berikutnya. Jika kepala rantai saat ini berada dalam periode komite sinkronisasi yang sama dengan pos pemeriksaan, maka kami segera mulai memverifikasi blok baru dengan header komite sinkronisasi yang ditandatangani. Jika pos pemeriksaan kami berada di belakang beberapa komite sinkronisasi, kami dapat:

1. Gunakan komite sinkronisasi berikutnya setelah pos pemeriksaan kami untuk mengambil dan memverifikasi blok yang berasal dari satu komite sinkronisasi di masa mendatang.
2. Gunakan blok baru ini untuk mengambil komite sinkronisasi baru berikutnya.
3. Jika masih tertinggal, kembali ke langkah 1.

Setiap iterasi dari proses ini memungkinkan kita untuk mempercepat 27 jam sejarah rantai, mulai dengan blockhash apa pun di masa lalu, dan menyinkronkan ke blockhash saat ini.

…Pada lapisan eksekusi

Tujuan dari klien cahaya lapisan eksekusi adalah untuk mengambil tajuk blok suar yang diverifikasi oleh lapisan konsensus, dan menggunakannya bersama dengan RPC lapisan eksekusi yang tidak tepercaya untuk menyediakan data lapisan eksekusi yang diverifikasi. Data ini kemudian dapat diakses melalui server RPC yang dihosting secara lokal oleh Helios.

Berikut adalah contoh sederhana untuk mengambil saldo akun, dimulai dengan panduan cepat tentang bagaimana status disimpan di Ethereum. Setiap akun berisi beberapa bidang, seperti hash kode kontrak, nonce, hash penyimpanan, dan saldo. Akun ini disimpan dalam jumlah besar, dimodifikasi Pohon Merkle-Patricia disebut pohon negara. Jika kita mengetahui akar dari pohon status, kita dapat memvalidasi bukti merkle untuk membuktikan keberadaan (atau pengecualian) dari akun apa pun di dalam pohon. Bukti-bukti ini secara efektif tidak mungkin dipalsukan.

Helios memiliki root status yang diautentikasi dari lapisan konsensus. Menggunakan akar ini dan permintaan bukti merkle ke RPC lapisan eksekusi yang tidak dipercaya, Helios dapat memverifikasi secara lokal semua data yang disimpan di Ethereum.

Kami menerapkan berbagai teknik untuk memverifikasi semua jenis data yang digunakan oleh lapisan eksekusi; digunakan bersama, ini memungkinkan kami mengotentikasi semua data yang diambil dari RPC yang tidak dipercaya. Meskipun RPC yang tidak tepercaya dapat menolak akses ke data, RPC tidak dapat lagi memberikan hasil yang salah kepada kami.

Menggunakan Helios di alam liar

Pertukaran antara portabilitas dan desentralisasi adalah masalah umum — tetapi karena Helios sangat ringan, pengguna dapat mengakses data rantai aman dari perangkat apa pun (termasuk ponsel dan ekstensi browser). Kemampuan untuk menjalankan Helios di mana saja memungkinkan lebih banyak orang mengakses data Ethereum yang tidak dapat dipercaya, apa pun perangkat kerasnya. Ini berarti pengguna dapat menggunakan Helios sebagai penyedia RPC mereka di MetaMask, dan mengakses dapp tanpa kepercayaan tanpa perubahan apa pun. 

Lebih lanjut, dukungan Rust untuk WebAssembly memudahkan pengembang aplikasi untuk menyematkan Helios di dalam aplikasi Javascript (seperti dompet dan dapps). Integrasi ini akan membuat Ethereum lebih aman, dan mengurangi kebutuhan kita untuk mempercayai infrastruktur terpusat.

Kami tidak sabar untuk melihat apa yang dihasilkan komunitas. Namun sementara itu, ada banyak cara untuk berkontribusi pada Helios — jika Anda tidak tertarik untuk berkontribusi pada basis kode, Anda juga dapat membuat perangkat lunak yang mengintegrasikan Helios untuk memanfaatkan manfaatnya. Ini hanyalah beberapa ide yang membuat kami bersemangat:

• Mendukung pengambilan data klien ringan langsung dari jaringan P2P daripada melalui RPC
• Terapkan beberapa metode RPC yang hilang
• Bangun versi Helios yang dikompilasi ke WebAssembly
• Integrasikan Helios langsung ke perangkat lunak dompet
• Bangun dasbor web untuk melihat saldo token Anda yang mengambil data dari Helios yang disematkan ke situs web dengan WebAssembly
• Terapkan mesin API sehingga lapisan konsensus Helios dapat dihubungkan ke simpul penuh lapisan eksekusi yang ada

Lihat basis kodenya untuk memulai — kami menerima laporan bug, permintaan fitur, dan kode Anda. Dan jika Anda membangun sesuatu yang lebih, bagikan dengan kami Twitter, Telegram, atau Farcaster @a16zcrypto.

***
Pandangan yang diungkapkan di sini adalah pandangan individu AH Capital Management, LLC (“a16z”) yang dikutip dan bukan pandangan a16z atau afiliasinya. Informasi tertentu yang terkandung di sini telah diperoleh dari sumber pihak ketiga, termasuk dari perusahaan portofolio dana yang dikelola oleh a16z. Meskipun diambil dari sumber yang dipercaya dapat dipercaya, a16z belum memverifikasi informasi tersebut secara independen dan tidak membuat pernyataan tentang keakuratan informasi saat ini atau yang bertahan lama atau kesesuaiannya untuk situasi tertentu. Selain itu, konten ini mungkin termasuk iklan pihak ketiga; a16z belum meninjau iklan tersebut dan tidak mendukung konten iklan apa pun yang terkandung di dalamnya.

Konten ini disediakan untuk tujuan informasi saja, dan tidak boleh diandalkan sebagai nasihat hukum, bisnis, investasi, atau pajak. Anda harus berkonsultasi dengan penasihat Anda sendiri mengenai hal-hal itu. Referensi ke sekuritas atau aset digital apa pun hanya untuk tujuan ilustrasi, dan bukan merupakan rekomendasi investasi atau penawaran untuk menyediakan layanan konsultasi investasi. Selanjutnya, konten ini tidak ditujukan atau dimaksudkan untuk digunakan oleh investor atau calon investor mana pun, dan dalam keadaan apa pun tidak dapat diandalkan saat membuat keputusan untuk berinvestasi dalam dana yang dikelola oleh a16z. (Penawaran untuk berinvestasi dalam dana a16z hanya akan dilakukan dengan memorandum penempatan pribadi, perjanjian berlangganan, dan dokumentasi lain yang relevan dari dana tersebut dan harus dibaca secara keseluruhan.) Setiap investasi atau perusahaan portofolio yang disebutkan, dirujuk, atau dijelaskan tidak mewakili semua investasi dalam kendaraan yang dikelola oleh a16z, dan tidak ada jaminan bahwa investasi tersebut akan menguntungkan atau bahwa investasi lain yang dilakukan di masa depan akan memiliki karakteristik atau hasil yang serupa. Daftar investasi yang dilakukan oleh dana yang dikelola oleh Andreessen Horowitz (tidak termasuk investasi yang penerbitnya tidak memberikan izin kepada a16z untuk mengungkapkan secara publik serta investasi yang tidak diumumkan dalam aset digital yang diperdagangkan secara publik) tersedia di https://a16z.com/investments /.

Bagan dan grafik yang disediakan di dalamnya hanya untuk tujuan informasi dan tidak boleh diandalkan saat membuat keputusan investasi apa pun. Kinerja masa lalu tidak menunjukkan hasil di masa depan. Konten berbicara hanya pada tanggal yang ditunjukkan. Setiap proyeksi, perkiraan, prakiraan, target, prospek, dan/atau pendapat yang diungkapkan dalam materi ini dapat berubah tanpa pemberitahuan dan mungkin berbeda atau bertentangan dengan pendapat yang diungkapkan oleh orang lain. Silakan lihat https://a16z.com/disclosures untuk informasi penting tambahan