Neon Web3 Proxy: Memfasilitasi Transaksi Tanpa Batas di Neon EVM
Tujuan Neon Labs adalah untuk membawa skalabilitas Solana dan biaya rendah ke ekosistem Ethereum dApps, pengembang, dan pengguna akhir. Solusi kami, Neon EVM, adalah alat kompatibilitas EVM asli Solana yang memungkinkan kontrak pintar Solidity diluncurkan pada platform untuk berinteraksi dengan token SPL tradisional dan token ERC20 yang "dibungkus SPL". Salah satu prinsip utama kami adalah menghadirkan kemampuan Neon EVM dengan cara yang tidak mengganggu pengalaman pengembang atau pengguna akhir. Singkatnya, kami ingin memberikan pengalaman EVM yang asli saat beroperasi di Solana.
Untuk membuat Neon EVM lebih “ramah pengguna” bagi pengembang dan pengguna akhir, kami membuat Proxy Web3 Neon — komponen infrastruktur opsional untuk ekosistem Neon. Proxy mengemas transaksi seperti Ethereum, yang disebut transaksi Neon, ke dalam transaksi Solana, menghilangkan beban penerapan logika konversi dari pengembang. Hal ini memungkinkan tim proyek untuk fokus membangun produk/layanan mereka daripada mengkhawatirkan kompatibilitas antara kontrak pintar Solidity dan Solana. Ini juga memungkinkan tim proyek untuk memindahkan kode sumber kontrak pintar Solidity yang ada ke dalam Neon EVM tanpa perubahan. Untuk pengguna akhir, proxy mengabaikan kebutuhan mereka untuk menyusun transaksi secara manual untuk eksekusi yang benar pada Neon EVM. Mereka dapat terus menggunakan Solidity dApps secara normal tanpa langkah tambahan apa pun.
Untuk mengatasi masalah kompatibilitas antara transaksi Ethereum dan Solana, tiga pertimbangan utama untuk desain solusi Neon Web3 Proxy adalah:
Anggaran komputasi Solana sebesar 200.000 instruksi BPF per transaksi. Anggaran komputasi diberlakukan untuk “mencegah program menyalahgunakan sumber daya komputasi.”
Batas ukuran transaksi Solana adalah 1232 byte. Batas ukuran transaksi diberlakukan untuk “memastikan transmisi jaringan yang cepat dan andal dari info cluster melalui UDP.”
Ukuran transaksi Ethereum yang besar. Transaksi Ethereum tidak dibatasi oleh dua batasan Solana di atas dan dapat menjadi besar dalam ukuran dan jumlah instruksi.
Saat Neon Web3 Proxy menerima transaksi Neon, ia akan mencoba mengemas transaksi Neon ke dalam satu transaksi Solana (kami akan menyebutnya sebagai transaksi non-iteratif di seluruh artikel) untuk dieksekusi oleh Neon EVM. Transaksi non-iteratif berisi informasi berikut:
Neon EVM sebagai target kontrak pintar yang mengeksekusi transaksi
Data Transaksi Berseri yang memuat, namun tidak terbatas pada: - Bendera fungsi Neon EVM. Ini memberi tahu Neon EVM cara menjalankan transaksi. - Pengirim transaksi. - Nama kontrak pintar. - Data transaksi dari transaksi Neon yang diminta. - Tanda tangan pengguna akhir dApp untuk transaksi Neon.
Daftar akun yang terpengaruh oleh transaksi dalam kapasitas baca/tulis
Namun, jika transaksi non-iteratif terlalu besar untuk diproses, proxy akan menghasilkan beberapa transaksi Solana berulang yang mewakili transaksi Neon asli. Transaksi berulang ini mengikuti pedoman anggaran dan ukuran komputasi Solana dan dapat dijalankan dengan sukses oleh Neon EVM di jaringan Solana.
Bagaimana Transaksi Iteratif Terstruktur dan Mengapa Penting
Transaksi berulang adalah serangkaian transaksi dengan data identik yang dapat dieksekusi secara berurutan untuk mencapai hasil yang sama dengan transaksi non-iterasi. Neon Web3 Proxy mengidentifikasi kebutuhan untuk transaksi berulang saat menerjemahkan transaksi Neon ke dalam transaksi non-iteratif awal.
Transaksi berulang diperlukan jika salah satu skenario berikut ini benar:
Transaksi non-iteratif yang dibuat dari transaksi Neon yang diminta lebih besar dari 1232 byte.
Transaksi non-iteratif yang dibuat dari transaksi Neon yang diminta berisi lebih dari 200.000 instruksi BPF.
Ada dua cara transaksi berulang dapat terstruktur:
Pertama. Misalkan transaksi asli non-iteratif yang dibuat dari transaksi Neon yang diminta kurang dari 1232 byte tetapi berisi lebih dari 200.000 instruksi BPF. Dalam hal ini, Proxy Web3 Neon akan menghasilkan beberapa transaksi Solana berulang yang berisi informasi yang hampir sama dengan transaksi non-iteratif asli. Seluruh rangkaian instruksi akan disimpan pada setiap transaksi berulang individu. Setiap transaksi berulang akan berisi data berikut:
Neon EVM sebagai target smart contract yang mengeksekusi transaksi.
Data Transaksi Berseri yang memuat, namun tidak terbatas pada: - Bendera fungsi Neon EVM. Ini memberi tahu Neon EVM cara menjalankan transaksi. Dalam hal ini, flag akan memberi tahu Neon EVM bahwa transaksi akan dieksekusi secara iteratif. - Pengirim transaksi. - Nama kontrak pintar. - Data transaksi dari transaksi Neon yang diminta. - Tanda tangan untuk transaksi Neon. - Jumlah maksimum Opcode (kode operasi) yang akan dieksekusi hingga transaksi dihentikan dan status Neon EVM disimpan ke dalam akun status yang ditentukan. Ini memungkinkan transaksi untuk dieksekusi di Solana meskipun memiliki lebih dari 200.000 instruksi BPF.
Daftar akun yang terpengaruh oleh transaksi dalam kapasitas baca/tulis. Daftar akun ini akan berisi akun khusus tambahan (Akun Negara) yang digunakan untuk menyimpan keadaan Neon EVM di antara pelaksanaan transaksi berulang.
Kedua. Misalkan transaksi asli non-iteratif yang dibuat dari transaksi Neon yang diminta lebih dari 1232 byte. Dalam hal ini, terlepas dari jumlah instruksi BPF, proxy akan meminta pembuatan akun Solana baru, yang disebut Akun Pemegang. Proxy kemudian akan memecah data transaksi asli menjadi potongan-potongan yang lebih kecil kurang dari 1232 byte. Data tersebut disimpan ke dalam Akun Pemegang yang baru saja dibuat. Secara paralel, proxy akan membuat transaksi berulang yang identik dengan data berikut:
Neon EVM sebagai target kontrak pintar yang mengeksekusi transaksi
Data Transaksi Berseri yang memuat, namun tidak terbatas pada: - Bendera fungsi Neon EVM. Dalam hal ini, flag akan memberi tahu Neon EVM untuk melakukan transaksi secara iteratif menggunakan data di Akun Pemegang. - Jumlah maksimum Opcode (kode operasi) yang akan dieksekusi hingga transaksi dihentikan dan status Neon EVM disimpan ke dalam akun status yang ditentukan.
Daftar akun yang terpengaruh oleh transaksi dalam kapasitas baca/tulis. Termasuk dalam daftar ini adalah (1) rekening khusus (Rekening Negara) yang digunakan untuk menyimpan keadaan Neon EVM di antara pelaksanaan transaksi berulang dan (2) Rekening Pemegang dengan data transaksi yang akan dieksekusi.
Selain informasi di atas, baik transaksi Solana non-iteratif dan iteratif juga akan berisi data logistik pembayaran berikut (Operator Neon akan dijelaskan lebih lanjut di bagian selanjutnya):
Akun operator Neon EVM yang akan membayar dan menandatangani transaksi Solana.
Akun operator Neon EVM yang pembayaran pengguna akhir akan dikirim untuk membayar layanan Operator
Akun Neon EVM tempat dana akan disetorkan untuk digunakan pada pelaksanaan transaksi berulang
Di Solana, tidak ada cara untuk mengetahui urutan transaksi berulang yang akan dieksekusi. Untuk alasan ini, tidak ada manfaat untuk transaksi berulang hanya berisi bagian tertentu dari instruksi yang akan dieksekusi. Ada kemungkinan sangat kecil transaksi berulang dijalankan dalam urutan yang benar untuk berhasil memproses seluruh transaksi Neon dengan benar. Sebaliknya, setiap transaksi akan berisi seluruh set instruksi dan memberi tahu Neon EVM jumlah instruksi yang harus dieksekusi. Neon EVM akan menggunakan State Account sebagai "bookmark" untuk mengingat instruksi mana yang telah diproses. Setiap kali transaksi berulang mulai dijalankan, Neon EVM akan memeriksa Rekening Negara dan mulai mengeksekusi sejumlah instruksi yang ditentukan, mengambil dari mana transaksi terakhir dihentikan.
Model transaksi berulang merupakan bagian integral untuk memungkinkan transaksi seperti Ethereum di Solana tanpa mengharuskan tim proyek untuk menulis ulang kontrak pintar apa pun. Fitur ini memungkinkan Neon Web3 Proxy untuk memfasilitasi transaksi tanpa batas di Neon EVM.
Di Balik Terpal Proxy Web3 Neon
Seperti disebutkan sebelumnya, Neon Web3 Proxy adalah komponen opsional untuk menggunakan Neon EVM. Pengembang memiliki opsi untuk menerapkan logika proxy secara langsung di dalam dApps mereka. Alat ini dimaksudkan untuk menjadi solusi out-of-the-box yang membuat transaksi dengan Neon EVM dApps semirip mungkin dengan Ethereum.
Fungsi proxy dilakukan dengan bantuan Operator Neon. Operator adalah peserta dalam ekosistem Neon yang mendukung pelaksanaan transaksi Solana yang dihasilkan oleh Proxy Web3 Neon. Saat transaksi Neon ditandatangani dan dikirim ke proxy oleh pengguna akhir dApp, transaksi tersebut dikemas ke dalam satu transaksi Solana non-iteratif atau beberapa transaksi Solana berulang tergantung pada ukuran dan jumlah instruksi. Untuk mengidentifikasi ukuran dan jumlah instruksi, proxy akan menjalankan transaksi melalui emulator EVM internal. Seiring dengan ukuran transaksi dan jumlah instruksi, emulator juga membantu mengidentifikasi biaya dan akun Solana yang diakses. Jumlah transaksi berulang yang dibuat kira-kira sama dengan jumlah total opcode yang dikembalikan oleh emulator internal, dibagi dengan jumlah opcode yang ditentukan per transaksi berulang. Transaksi Solana berulang ini ditandatangani dan dibayar oleh Operator Neon dan dikirim sekaligus ke Neon EVM untuk dieksekusi.
Untuk mengonfirmasi keberhasilan eksekusi seluruh transaksi Neon, Proksi Web3 akan meninjau tanda terima transaksi yang dikirim kembali oleh Neon EVM setelah eksekusi semua transaksi berulang. Proxy memeriksa dua hal:
Apakah setiap transaksi berulang individu telah dieksekusi dan dikonfirmasi ke blockchain Solana.
Jika salah satu tanda terima transaksi menyertakan tanda "penyelesaian". Bendera "penyelesaian" hanya ditetapkan oleh Neon EVM setelah transaksi Neon asli telah dieksekusi.
Proxy Web3 menghitung jumlah transaksi yang tidak dikonfirmasi ke Solana, jika ada. Kemudian mengirimkan gelombang kedua transaksi berulang ke Neon EVM untuk menyelesaikan eksekusi seluruh transaksi Neon. Jumlah transaksi pada gelombang kedua sama dengan jumlah transaksi yang tidak dikonfirmasi ke Solana pada percobaan pertama. Setiap transaksi berulang tambahan berisi data yang identik dengan transaksi berulang yang dikirim dalam upaya pertama.
Fungsi utama dari proxy meliputi:
Menerima permintaan melalui protokol API Web3 (Saat pengguna dApp meminta transaksi melalui UI klien, transaksi yang dihasilkan dikirim ke proxy melalui protokol API Web3).
Membentuk tanggapan menggunakan protokol API Web3.
Pengemasan transaksi Neon menjadi transaksi Solana.
Menjalankan metode kontrak Soliditas baca-saja.
Menyediakan metode untuk mengakses kontrak token SPL melalui transaksi Neon.
Emulator EVM yang digunakan untuk "menguji coba" transaksi Solana yang dihasilkan dari transaksi Neon. “Test run” mengidentifikasi akun Solana yang akan diakses oleh transaksi Neon dan perkiraan biaya transaksi Neon.
Memberi pengguna metode untuk mengeksekusi transaksi Neon tanpa "uji coba".
Bagaimana Proxy bekerja dengan Neon EVM
Mari selami bagaimana proxy memfasilitasi transaksi dalam panduan menyeluruh.
Proses ini dimulai oleh pengguna akhir yang meminta transaksi saat berinteraksi dengan Neon EVM dApp melalui klien mereka. Klien dApp menghasilkan transaksi seperti Ethereum (transaksi Neon), meminta tanda tangan pengguna (melalui MetaMask), dan mengirimkan transaksi ke Neon Web3 Proxy. Transaksi Neon yang dikirim ke proxy berisi jenis informasi yang sama yang ditemukan dalam transaksi Ethereum standar.
Proxy akan mengambil transaksi Neon dan melakukan "uji coba" menggunakan emulator EVM internalnya. “Uji coba” akan mengidentifikasi daftar akun yang diakses oleh transaksi bersama dengan atribut berikut dari setiap akun:
Bendera yang menunjukkan apakah itu akun yang sudah ada atau akun baru yang dibuat sebagai bagian dari transaksi
Bendera yang menunjukkan apakah transaksi akan membaca atau menulis ke akun
Emulator juga akan menghitung jumlah Opcode yang digunakan dalam “test run”, ini akan menginformasikan proxy berapa banyak instruksi iteratif yang diperlukan untuk menyelesaikan transaksi Neon. Selain itu, "uji coba" akan memperkirakan biaya keseluruhan transaksi.
Setelah "uji coba" proxy akan menghasilkan transaksi Solana non-iteratif dan mengirimkannya ke Neon EVM untuk mencoba eksekusi. Transaksi dibuat dengan informasi dari transaksi Neon asli bersama dengan daftar akun yang dikompilasi selama “uji coba.” Jika transaksi gagal karena batas ukuran atau anggaran komputasi, beberapa transaksi Solana berulang akan dibuat. Jumlah transaksi berulang yang dibuat sama dengan total opcode yang dibutuhkan, dibagi dengan jumlah opcode yang ditentukan per transaksi berulang.
Semua transaksi berulang dikirim ke Neon EVM secara bersamaan untuk dieksekusi. Neon EVM akan mengeksekusi transaksi berulang untuk jumlah instruksi yang ditentukan dan menyimpan statusnya ke Akun Negara saat dihentikan. Kemudian, pindah ke transaksi berulang berikutnya. Menggunakan informasi dari State Account, EVM menentukan titik mana dalam daftar instruksi untuk mulai dieksekusi. EVM akan mulai melakukan instruksi hingga mencapai batas instruksi yang ditentukan dalam data transaksi berulang.
Setelah semua transaksi berulang yang dikirim telah diproses, proxy meminta tanda terima transaksi dari Neon EVM. Proksi meninjau semua tanda terima untuk memeriksa apakah ada transaksi berulang yang tidak dikonfirmasi di blockchain Solana. Jika ada transaksi berulang yang belum dikonfirmasi, proxy akan mengirimkan gelombang kedua transaksi berulang untuk menyelesaikan keseluruhan transaksi Neon. Jumlah transaksi berulang di gelombang kedua sama dengan jumlah transaksi yang belum dikonfirmasi dari batch pertama yang dikirim.
Dalam skenario tertentu, proxy akan menemukan semua transaksi berulang yang dikonfirmasi di jaringan Solana tetapi tanpa "tanda yang diselesaikan" yang ada dalam tanda terima transaksi apa pun. Ini terjadi jika lebih banyak instruksi BFP diperlukan daripada yang diperkirakan sebelumnya. Dalam kasus ini, Proxy Web3 Neon akan mengirimkan transaksi berulang tambahan satu per satu ke EVM hingga "tanda selesai" dipicu untuk menyelesaikan transaksi Neon.
Ketika proxy akhirnya menemukan "bendera selesai" di salah satu tanda terima transaksi berulang, ia mencatat bahwa seluruh transaksi Neon telah selesai. Pengguna akhir yang memulai transaksi Neon membayar Operator Neon untuk layanan mereka dan untuk biaya transaksi Solana yang dikeluarkan. Dari sudut pandang pengguna, pembayaran mirip dengan membayar dApps melalui MetaMask. Semua logistik biaya transaksi Neon ditangani oleh Proxy Web3.
Next Steps
Jika Anda memiliki pertanyaan yang tersisa atau mencari detail lebih lanjut tentang Neon Web3 Proxy atau transaksi Iteratif, lihat dokumen pengembang kami yang ditautkan di bawah ini:
Kemampuan Ethereum dan Solana dalam Satu Solusi
Jika artikel ini atau dokumen yang ditautkan di atas membuat Anda memiliki pertanyaan lebih lanjut, hubungi tim kami melalui Discord. Kami akan dengan senang hati membantu Anda memahami bagaimana Proksi Web3 dan transaksi berulang memfasilitasi transaksi tanpa batas di Neon EVM. Terakhir, jika Anda tertarik untuk menjadi Operator Neon atau mempelajari lebih lanjut tentang ekonomi Operator Neon, lihat Panduan Operator Cepat kami.