Cara Bermigrasi dari Ethereum ke Solana: Panduan untuk Developer

Apa yang dibahas dalam artikel ini?

Ethereum adalah salah satu inovasi terpenting dalam beberapa tahun terakhir. Untuk pertama kalinya dalam sejarah, kita memiliki platform global terdesentralisasi yang dibangun untuk koordinasi sosial dan berpotensi merevolusi banyak industri. Terlepas dari perannya yang penting, lingkungan runtime Ethereum, Ethereum Virtual Machine (EVM), dalam kondisinya saat ini belum dirancang untuk aplikasi kelas konsumen. Jaringan ini menggunakan satu thread, berbasis gas, dan memiliki biaya yang fluktuatif. Sebaliknya, Solana hadir sebagai jaringan dengan throughput tinggi dan latensi rendah. Solana menawarkan infrastruktur yang diparalelkan dengan biaya rendah dan dapat diprediksi. Solana secara langsung mengatasi keterbatasan EVM dan menyempurnakan desain awalnya, sehingga menjadi pilihan menarik bagi developer yang ingin membangun aplikasi yang skalabel dan efisien.

Artikel ini merupakan panduan migrasi komprehensif bagi developer EVM yang ingin membangun di Solana. Artikel ini membahas perbedaan mendasar di antara keduanya, termasuk mekanisme konsensus Ethereum dan Solana, cara keduanya memproses transaksi, serta bahasa yang digunakan untuk mengembangkan smart contract. Selanjutnya, artikel ini membahas model akun Solana, yang menawarkan pendekatan lebih seragam dan multifungsi terhadap akun. Artikel ini juga mengulas Solang dan Neon EVM, dua alat yang mendukung Solidity dan meningkatkan pengalaman pengembangan di Solana.

Perbedaan Mendasar

Bagian ini mengulas perbedaan penting antara Ethereum dan Solana, dua blockchain yang bertujuan menciptakan mesin status terdesentralisasi untuk koordinasi global. Namun, keduanya sangat berbeda dalam mekanisme konsensus, metode pemrosesan transaksi, dan bahasa yang digunakan untuk mengembangkan smart contract. Pemahaman lebih mendalam tentang perbedaan mendasar ini menunjukkan keunggulan Solana dibandingkan Ethereum sebagai mesin status global berperforma tinggi.

Mekanisme Konsensus

Mekanisme konsensus merupakan fondasi setiap jaringan blockchain. Mekanisme ini menentukan cara transaksi diverifikasi dan blok ditambahkan ke blockchain dengan aman, efisien, dan terdesentralisasi. Ethereum dan Solana sama-sama merupakan jaringan Proof of Stake (PoS). Meski memiliki fondasi PoS yang sama, pendekatan keduanya untuk mencapai konsensus berbeda karena aturan konfirmasinya.

Ethereum menggunakan Gasper, sebuah kombinasi dari Casper the Friendly Finality Gadget (Casper-FFG) dan algoritma pemilihan fork LMD-GHOST. Kombinasi ini membentuk mekanisme konsensus yang mengamankan Ethereum.

Casper adalah sistem finalitas berbasis PoS yang meningkatkan status konfirmasi blok menjadi “final.” Sebuah blok dianggap final di Ethereum ketika dua pertiga dari total stake memberikan suara untuk memasukkan blok tersebut dan blok lain dibangun di atasnya. Karena finalitas memerlukan persetujuan dua pertiga dari total stake bahwa sebuah blok bersifat kanonis, penyerang tidak dapat membuat rantai final alternatif tanpa memiliki atau memanipulasi dua pertiga dari total stake dan menghancurkan setidaknya sepertiganya melalui slashing. Casper memungkinkan peserta baru melakukan sinkronisasi dengan rantai kanonis secara meyakinkan. 

LMD-GHOST adalah singkatan dari “Latest Message-Driven Greedy Heaviest Observed Sub-Tree.” Ini adalah algoritma yang menentukan fork Ethereum mana yang harus diikuti. Algoritma ini memilih fork yang menerima dukungan (yaitu, “bobot”) paling besar dari validator jaringan (karena itu disebut “greedy heaviest sub-tree”). Kemudian, algoritma memastikan bahwa hanya pesan terbaru dari setiap validator yang dipertimbangkan. Setiap kali blok baru diajukan ke Ethereum, validator menggunakan aturan ini untuk menentukan apakah blok tersebut harus menjadi bagian dari rantai kanonis.

Sebagai perbandingan, Solana menggunakan hash Proof of History (PoH) untuk mencapai konsensus. Terlepas dari namanya yang membingungkan, PoH bukan algoritma konsensus. PoH adalah cara untuk membuktikan waktu dalam jaringan adversarial. Lebih spesifiknya, PoH merupakan fungsi penanda waktu kriptografis yang memungkinkan node menyepakati urutan peristiwa tanpa berkomunikasi satu sama lain. Leader (yaitu validator yang menambahkan entri ke ledger) menerapkan stempel waktu pada blok untuk membuktikan bahwa sejumlah waktu telah berlalu sejak blok terakhir. 

Penambahan stempel waktu ini membentuk catatan historis karena membuktikan bahwa data telah ada pada waktu tertentu. Catatan historis dibuat menggunakan fungsi hash sekuensial yang tahan preimage, dengan setiap hash bergantung pada hash sebelumnya. Verifiable Delay Functions (VDFs) berperan penting dalam menghasilkan hash ini. VDF memastikan setiap hash dibangun di atas hash sebelumnya dan menyertakan waktu yang telah berlalu. Integrasi VDF menambahkan dimensi temporal ke proses hashing, sehingga urutan peristiwa dengan stempel waktu yang dapat diverifikasi dapat dibuat di Solana.

Setelah memahami cara mekanisme Proof of History Solana menciptakan urutan peristiwa yang andal melalui stempel waktu kriptografis, penting untuk memahami integrasinya dengan mekanisme konsensus Solana, Tower BFT. Tower Byzantine Fault Tolerance (BFT) adalah varian Solana dari model konsensus Byzantine Fault Tolerance tradisional yang dioptimalkan untuk PoH. Tower BFT menggunakan catatan historis yang dibuat PoH sebagai kerangka acuan. Kerangka ini memungkinkan validator memberikan suara terhadap status ledger secara efisien dan akurat. Tower BFT bekerja dengan membuat validator memberikan suara yang dikunci untuk waktu lama, dan komitmennya semakin kuat seiring bertambahnya suara. Berkat PoH, validator dapat mengambil keputusan yang lebih cepat dan lebih informatif tentang status ledger tanpa perlu berkomunikasi satu sama lain. Kombinasi PoH dan Tower BFT mempercepat konsensus serta meningkatkan keamanan dan keandalan jaringan. Hasilnya adalah lingkungan blockchain ber-throughput tinggi dan skalabel yang mengonfirmasi transaksi dengan cepat.

Pemrosesan Transaksi dan Lingkungan Eksekusi

Efisiensi dan skalabilitas blockchain terutama ditentukan oleh kemampuan pemrosesan transaksi dan lingkungan eksekusinya. Faktor-faktor ini menentukan kecepatan eksekusi transaksi dan efisiensi biaya operasi pada jaringan. Pendekatan blockchain terhadap pemrosesan transaksi dan detail lingkungan eksekusinya sangat memengaruhi pengalaman developer.

Lingkungan runtime Ethereum beroperasi sebagai mesin stack deterministik dengan satu thread yang dikenal sebagai Ethereum Virtual Machine (EVM). EVM berperilaku seperti fungsi matematika. Artinya, EVM menghasilkan output deterministik saat menerima input. Ethereum dapat didefinisikan sebagai sistem yang memiliki fungsi transisi status: f(S, T) = S’. Dengan status lama (S) dan kumpulan transaksi valid baru (T), EVM menghasilkan status output valid baru (S’). EVM akan selalu mencapai status akhir yang sama jika menerima kumpulan transaksi yang sama. Hal ini sangat penting untuk menjaga konsistensi di seluruh node jaringan.

EVM memproses transaksi secara berurutan. Pemrosesan berurutan memastikan setiap transaksi dieksekusi dalam lingkungan yang secara akurat mencerminkan status jaringan hingga titik tersebut. Eksekusi berurutan memungkinkan perhitungan perubahan status dan biaya gas secara tepat. Prediktabilitas ini memberi developer dan pengguna pemahaman yang jelas tentang hasil serta biaya transaksi.

Ethereum menyederhanakan lingkungan eksekusi smart contract dengan menerapkan model eksekusi satu thread. Model ini memberi developer keuntungan berupa perubahan status yang dapat diprediksi karena setiap transaksi diproses secara berurutan. Perubahan status yang dapat diprediksi membuat lingkungan pengembangan Ethereum relatif lebih mudah didekati developer baru karena mereka dapat lebih berfokus pada logika smart contract daripada kompleksitas eksekusi. Namun, kesederhanaan ini menyulitkan skalabilitas. Pemrosesan berurutan membatasi throughput jaringan. Hal ini dapat menyebabkan kemacetan, waktu tunggu transaksi yang lebih lama, dan biaya gas yang lebih tinggi saat permintaan meningkat. Karena setiap transaksi mengonsumsi gas, developer harus mengoptimalkan efisiensi gas. Optimasi dilakukan untuk meningkatkan pengalaman pengguna secara keseluruhan dan mengatasi periode kemacetan, ketika kode yang tidak efisien dapat membuat aplikasi tidak dapat digunakan oleh pengguna pada umumnya.

Developer Solana tidak perlu mengkhawatirkan optimasi penggunaan gas seperti developer Ethereum. Solana dirancang sebagai mesin status ber-throughput tinggi dan berlatensi rendah yang dikenal sebagai Solana Virtual Machine (SVM). Komponen penting SVM adalah Sealevel. Sealevel merupakan mesin runtime yang memproses transaksi secara paralel. Di Solana, setiap transaksi memberi tahu runtime bagian status mana yang akan dibaca atau ditulis saat dieksekusi. Runtime memproses transaksi yang tidak berkonflik dan transaksi yang membaca status yang sama secara paralel. Sealevel mengoptimalkan eksekusi smart contract dengan mendistribusikan beban kerja transaksi ke beberapa thread pada perangkat keras validator. Jadi, saat validator memproses transaksi pada satu core, transaksi lain dapat diproses secara bersamaan pada core lainnya.

Paralelisme bawaan Solana secara signifikan mengurangi biaya transaksi. Transaksi Solana memiliki dua biaya: biaya dasar dan biaya prioritas. Biaya dasar ditetapkan sebesar 5000 lamport per tanda tangan; sebagian besar transaksi hanya memiliki satu tanda tangan. Biaya prioritas bersifat opsional dan memungkinkan transaksi memprioritaskan dirinya dibandingkan transaksi lain. Transaksi dengan biaya prioritas lebih tinggi diprioritaskan secara nondeterministik oleh scheduler. Biaya transaksi sering kali di bawah $0,001 USD, dengan rata-rata biaya non-voting dalam rentang 0,000005 hingga 0,00007 SOL. Batas atasnya lebih tinggi daripada biasanya karena peningkatan penggunaan biaya prioritas baru-baru ini. Dengan harga SOL saat ini sebesar ~$98,96, biaya ini setara dengan sekitar $0,000494 hingga $0,006968 USD. 

Biaya ini juga dapat diprediksi. Solana menggunakan pasar biaya terlokalisasi untuk mengelola permintaan. Ruang blok disusun untuk mencegah satu pusat aktivitas tertentu (misalnya mint NFT yang sedang populer) mendominasi ruang blok dan menaikkan biaya di seluruh jaringan. Hanya transaksi yang mencoba mengakses pusat aktivitas tertentu dengan permintaan tinggi yang akan mengalami kenaikan biaya. Pasar biaya terlokalisasi memungkinkan biaya prioritas tanpa memicu perang gas besar-besaran. Lokalisasi ini berbeda dari jaringan berbasis gas seperti Ethereum, tempat transaksi diproses secara berurutan dan kemacetan global menyebabkan biaya berfluktuasi.

Ethereum adalah lingkungan runtime satu thread yang hanya memproses satu kontrak dalam satu waktu. Saat ini, Ethereum tidak memanfaatkan perangkat keras multi-core modern sehingga perangkat keras validator kurang dimanfaatkan. Keinginan untuk mempertahankan persyaratan perangkat keras yang rendah bagi node makin membatasi pemrosesan transaksi Ethereum. Sebagai perbandingan, kemampuan pemrosesan paralel Solana memungkinkan Solana memproses lebih banyak transaksi dengan memanfaatkan semua core validator yang tersedia. Bersama pasar biaya terlokalisasi, Solana menjadi mesin status global dengan performa yang jauh lebih tinggi. 

Bahasa Smart Contract

Bahasa utama untuk pengembangan smart contract di Ethereum adalah Solidity. Solidity adalah bahasa bertipe statis dengan kurung kurawal yang dirancang untuk membuat smart contract yang berjalan di EVM. Bahasa ini sangat dipengaruhi oleh JavaScript, C++, dan Python, sehingga mudah dipelajari oleh developer yang sudah mengenal bahasa-bahasa tersebut.

Yul adalah bahasa perantara tingkat rendah yang dioptimalkan untuk blockchain yang kompatibel dengan EVM. Yul memberi developer kendali lebih besar atas eksekusi bytecode sehingga sangat efisien untuk menyempurnakan konsumsi gas dan mengelola operasi tingkat rendah lainnya. Developer dapat membuat kontrak yang lebih efisien dengan menulis kode langsung dalam Yul atau menggunakannya sebagai target kompilasi.

Vyper adalah bahasa populer bergaya Python yang menekankan kesederhanaan dan keamanan. Vyper sengaja memiliki lebih sedikit fitur daripada Solidity karena bertujuan mengurangi kompleksitas dan potensi kerentanan keamanan. Filosofi desain Vyper mengutamakan keterbacaan dan kemudahan audit. Pendekatan ini telah menginspirasi pengembangan bahasa serupa, seperti Fe, serta bahasa yang dikompilasi ke Vyper, seperti Dasy.

Rust adalah lingua franca untuk pengembangan smart contract (yang sehari-hari disebut program) di Solana. Rust adalah bahasa yang cepat dan hemat memori dengan performa sebanding dengan C++. Karakteristik ini membuatnya cocok untuk mengembangkan aplikasi bagi jaringan ber-throughput tinggi dan berlatensi rendah. Sistem tipe yang kaya dan model kepemilikan Rust memastikan keamanan memori dan thread, sehingga developer harus membangun aplikasi yang andal dan aman. 

Meski Rust memiliki kurva pembelajaran yang tajam bagi orang yang baru mengenal pemrograman sistem, imbalannya adalah kemampuan untuk membuat kode yang tangguh dan efisien. Sebagian besar pengembangan Rust dilakukan menggunakan Anchor. Anchor adalah framework dengan konvensi yang tegas, yang menyederhanakan pengembangan program dengan mengurangi boilerplate, menjalankan berbagai pemeriksaan keamanan standar, dan merampingkan proses (de)serialisasi. Dengan demikian, pengetahuan Rust tingkat lanjut tidak terlalu penting untuk memulai. Sebagai konteks, dokumentasi Anchor menyarankan pengguna memahami sembilan bab pertama Rust Book (yaitu memahami dasar-dasar Rust). Solana Playground memiliki beberapa tutorial Anchor untuk membantu Anda memulai.

Meskipun Rust lebih disukai, developer tidak terbatas pada bahasa tersebut. C, C++, dan bahasa apa pun yang menargetkan backend BPF milik LLVM (yaitu bahasa apa pun yang dapat dikompilasi menjadi bytecode BPF) dapat digunakan. Bagi developer yang mengenal bahasa bergaya Python seperti Vyper, Seahorse Lang memungkinkan penulisan program dalam Python. Dengan demikian, developer memperoleh kemudahan penggunaan Python sambil tetap mempertahankan jaminan keamanan yang sama seperti jika menulis kode dalam Rust. Sejumlah tutorial Seahorse yang bermanfaat, seperti Seahorse University dan Seahorse Cookbook, tersedia untuk membantu Anda mulai memprogram di Solana sekarang juga.

Developer yang bermigrasi dari Ethereum ke Rust tidak terbatas pada Rust. Meskipun mempelajari dan menggunakan framework seperti Anchor dan Seahorse disarankan karena popularitas serta jaminan keamanannya, hal ini tidak selalu memungkinkan. Berkat perkembangan terbaru dari Solang dan Neon Labs dengan compiler dan lingkungan developer yang kompatibel dengan EVM, developer dapat menggunakan Solidity dalam pengembangan program. Solidity memiliki tempat di Solana. Untuk memulai pengembangan program dengan Solidity, kita perlu mempelajari lebih dalam detail model pemrograman Solana. Memahami model akun Solana sangat penting bagi developer yang melakukan transisi ini karena model tersebut menjadi fondasi pengembangan dan interaksi program di jaringan.

Memahami Model Akun

Ethereum membagi akun menjadi dua kategori utama: externally owned accounts (EOA) dan akun kontrak. EOA adalah jenis akun standar bagi pengguna. Akun ini dikendalikan oleh private key dan dapat menyimpan saldo Ether, mengirim transaksi, serta berinteraksi dengan akun kontrak. Di sisi lain, akun kontrak berbeda karena operasinya diatur oleh kode smart contract yang tertanam di dalamnya. Akun ini tidak dapat memulai transaksi secara mandiri dan hanya dapat bertindak sebagai respons terhadap transaksi yang diterima dari EOA atau akun kontrak lain.

Solana menerapkan model akun yang lebih seragam dengan memperlakukan akun sebagai kontainer multifungsi yang menyimpan data secara persisten. Model ini memungkinkan akun apa pun menjadi program, sehingga mengaburkan batas tradisional antara akun dan smart contract. Tidak seperti Ethereum yang menggabungkan kode dan status dalam satu akun, program Solana bersifat stateless. Artinya, program tidak menyimpan status apa pun secara internal. Sebaliknya, semua data yang diperlukan untuk beroperasi disimpan dalam akun terpisah dan diteruskan sebagai referensi bersama transaksi. Meneruskan akun sebagai referensi memungkinkan satu deployment program generik berinteraksi dengan akun yang berbeda. Model akun Solana memisahkan kode dan data, sehingga menciptakan lingkungan pengembangan yang lebih efisien dan modular. Hal ini menguntungkan pengguna yang ingin berinteraksi dengan beberapa protokol tanpa memindahkan aset di antara program yang berbeda. Segala sesuatu di Solana adalah akun. 

Akun Solana secara umum dapat dibagi menjadi akun executable dan non-executable. Sederhananya, akun executable adalah akun yang dapat menjalankan kode. Akun non-executable digunakan untuk menyimpan data tanpa kemampuan menjalankan kode. Hal ini karena akun tersebut tidak menyimpan kode apa pun.

Akun executable adalah akun yang menyimpan program. Program dapat memiliki akun tambahan, membaca dari atau mengkredit akun lain, mengubah data, atau mendebit akun yang dimilikinya. Akun executable dapat dibagi lebih lanjut menjadi program on-chain atau native. Program on-chain adalah kode yang ditulis pengguna dan di-deploy ke jaringan. Program ini dapat ditingkatkan oleh upgrade authority-nya, yang biasanya merupakan akun yang melakukan deployment. Program native adalah subset khusus akun executable, serupa dengan kontrak prapeluncuran Ethereum, tetapi memiliki fungsi yang lebih luas. Program ini terintegrasi ke dalam inti Solana dan menyediakan fungsi yang diperlukan validator untuk beroperasi. Salah satu contoh program native adalah System Program. Program ini bertanggung jawab untuk membuat akun baru, mengalokasikan data akun, menetapkan akun ke program, mentransfer lamport dari akun yang dimilikinya, dan membayar biaya transaksi. Daftar lengkap program native dapat ditemukan di sini.

Terlepas dari apakah akun tersebut executable atau non-executable, semua akun memiliki field yang sama: 

• Field lamports untuk melacak saldo native akun dalam SOL
• Field data, yang merujuk pada array byte data mentah yang disimpan akun
• Field owner yang menunjukkan program yang dapat mengubah akun ini
• Field signer, yang digunakan dalam transaksi untuk menunjukkan apakah akun dapat menyetujui transaksi
• Field writable untuk menentukan apakah data akun dapat diubah. Field ini memfasilitasi pemrosesan paralel dengan menandai akun yang disertakan dalam transaksi sebagai read-only atau writable
• Field executable untuk menunjukkan apakah akun menyimpan program
• Field rent epoch untuk menunjukkan epoch berikutnya saat akun harus membayar rent

Rent adalah biaya penyimpanan untuk mempertahankan akun di Solana dan memastikan akun tersebut tersimpan dalam memori validator. Karena itu, akun harus mempertahankan saldo minimum agar tetap aktif. Rent mengurangi pembengkakan status dengan memastikan jaringan pada akhirnya memulihkan akun yang tidak digunakan atau kekurangan dana. Pembaruan terbaru membuat mainnet tidak lagi memiliki akun yang membayar rent. Sebaliknya, semua akun harus bebas rent saat dibuat. Akun bebas rent jika mempertahankan saldo minimum yang setara dengan pembayaran rent selama dua tahun. Alat seperti Test Drive dan subperintah rent di Solana CLI dapat digunakan untuk memperkirakan jumlah SOL yang diperlukan agar akun bebas rent. Hal ini berbeda dari sistem alokasi sumber daya Ethereum, tempat penyimpanan tetap ada kecuali dihapus secara eksplisit. Pendekatan Solana menawarkan struktur biaya penyimpanan status yang lebih dapat diprediksi sekaligus mengurangi pembengkakan status.

Alamat dan Program Derived Addresses (PDA)

Semua akun diidentifikasi berdasarkan alamatnya, yaitu public key unik berukuran 32 byte. Hal ini berbeda dari model data Ethereum, yang alamatnya berukuran 20 byte. Solana menggunakan ed25519 (yaitu skema tanda tangan EdDSA yang menggunakan SHA-512 dan kurva eliptik Curve22519) untuk menghasilkan alamat. Sebuah akun harus berupa titik pada kurva ed25519 agar memiliki pasangan kunci yang valid. 

Program Derived Addresses (PDA) adalah akun yang dihasilkan di luar kurva menggunakan bump (yaitu nilai yang mendorong output keluar dari kurva). PDA memerlukan tiga bagian utama: alamat program induknya, kumpulan seed, dan bump. Seed adalah array string yang dapat memiliki nilai arbitrer. Namun, sebagian besar developer membuat seed tertentu yang terkait dengan variabel status dalam program induk untuk membuat struktur data menyerupai hashmap. Dengan demikian, PDA dibuat dengan melakukan hashing terhadap ID program, seed, dan bump menggunakan fungsi hash SHA-512.

Tujuan PDA berada di luar kurva adalah agar hanya program asal PDA tersebut yang dapat menandatangani atas nama PDA. Hal ini merampingkan alur transaksi dengan menghasilkan tanda tangan transaksi secara terprogram sehingga dApp trustless dapat beroperasi dengan lancar tanpa intervensi.

Berinteraksi dengan Akun

Transaksi Ethereum adalah tindakan yang mengubah status dan dimulai oleh EOA. Smart contract tidak dapat memulai transaksi secara mandiri; smart contract hanya dapat merespons transaksi. Kode kontrak menentukan respons tersebut, sedangkan biaya eksekusi transaksi diukur dalam gas. Pengguna harus menyediakan Ether yang cukup untuk membayar biaya gas ini.

Transaksi Ethereum biasanya menjalankan satu operasi, seperti memanggil fungsi smart contract tertentu. Meskipun satu transaksi dapat menghasilkan beberapa perubahan status dalam kontrak, semua perubahan terbatas pada cakupan pemanggilan kontrak tersebut.

Di Solana, sebuah transaksi terdiri dari array akun yang akan dibaca atau ditulis, satu atau beberapa tanda tangan, serta satu atau beberapa instruksi. Instruksi adalah arahan untuk satu pemanggilan program. Instruksi merupakan unit terkecil logika eksekusi dan unit operasional paling mendasar. Instruksi menentukan program yang dieksekusi, semua akun yang terlibat, dan data operasional. Program menafsirkan data dari instruksi dan beroperasi pada akun yang ditentukan. Struktur ini memungkinkan satu transaksi menjalankan serangkaian tindakan di beberapa program secara atomik. Artinya, semua instruksi berhasil atau gagal secara bersamaan. Alur transaksi Solana berbeda dari model Ethereum, tempat transaksi biasanya ditautkan ke satu smart contract atau tindakan EOA.

Cross-Program Invocations (CPI) memungkinkan sebuah program memanggil program lain selama transaksi yang sama. Jumlah byte data akun per compute unit yang dibebankan selama CPI adalah 250. Jumlah ini kira-kira 50 MB pada 200.000 unit. CPI memungkinkan tanda tangan yang dihasilkan secara terprogram digunakan saat melakukan pemanggilan antarprogram. Hal ini serupa dengan smart contract Ethereum yang memanggil kontrak lain secara efisien dan atomik. Namun, program pemanggil dihentikan sementara hingga program yang dipanggil selesai memproses instruksi. Reentrancy dibatasi pada rekursi mandiri langsung dengan kedalaman tetap maksimum 4. Hal ini mencegah situasi ketika sebuah program memanggil program lain dari status perantara tanpa mengetahui bahwa program tersebut mungkin akan dipanggil kembali nanti.

Transaksi Solana mematuhi batas ukuran demi efisiensi, serupa dengan batas gas Ethereum. Namun, fokusnya adalah ukuran data. Transaksi Solana mematuhi standar IPv6 Maximum Transmission Unit (MTU) untuk menjamin transmisi data yang andal. Setelah menyisihkan ruang header yang diperlukan, tersedia 1232 byte untuk data paket. Solana memperkenalkan transaksi berversi untuk mendukung beberapa format transaksi guna mengatasi keterbatasan ukuran. Selain format legacy (yaitu format transaksi asli), Versi 0 dirilis untuk mendukung Address Lookup Tables (ALT). ALT menyimpan alamat dalam struktur data menyerupai tabel secara on-chain, dengan setiap alamat diindeks menggunakan indeks u8 berukuran 1 byte. Hal ini secara signifikan mengurangi ukuran transaksi karena setiap akun hanya memerlukan 1 byte, bukan 32 byte.

Solang

Solang adalah compiler Solidity untuk Solana dan Polkadot. Solang bertujuan mencapai kompatibilitas file sumber dengan versi 0.8 dari compiler Solidity EVM, meski dengan beberapa variasi agar selaras dengan arsitektur Solana dan Polkadot. Salah satu aspek penting Solang adalah penggunaan LLVM, infrastruktur compiler yang canggih. Fleksibilitas LLVM memungkinkan Solang memperluas dukungan ke bahasa pemrograman lain di masa mendatang, sehingga implementasi dan kompilasi menjadi lebih mudah. Karakteristik ini sejalan dengan tujuan Solang untuk memudahkan transisi developer ke Solana atau Polkadot serta memperluas cakupan pengembangan Solidity. Solang terus dikembangkan dengan fokus pada peningkatan kompatibilitas, efisiensi, dan kemudahan penggunaan. Developer Ethereum yang ingin membawa keahlian mereka ke lintas chain perlu memahami Solang beserta berbagai batasannya.

Instalasi

Ada beberapa cara untuk menginstal Solang. Di Mac, pengguna dapat mengunduh Solang dengan Brew menggunakan tap privat:

brew install hyperledger/solang/solang

Cara lain untuk menginstal Solang adalah menggunakan container Solang. Cara ini sangat cocok jika Anda lebih suka menggunakan Docker, karena image baru tersedia secara otomatis di container tersebut. Tersedia tag v.0.3.3 dan tag latest:

docker pull ghcr.io/hyperledger/solang:latest

Salah satu cara yang lebih mudah untuk menginstal dan menggunakan Solang adalah melalui Ancor. Sebelum memulai, pastikan Rust dan Node.js telah terinstal di sistem Anda. Pengguna Windows juga perlu menyiapkan Windows Subsystem for Linux. Selanjutnya, kita perlu menginstal Tool Suite Solana. Di Mac dan Linux, hal ini dapat dilakukan dengan perintah berikut:

 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Jika Anda menginginkan versi perangkat lunak lain, ganti “v1.17.13” dengan tag rilis yang sesuai. Sebagai alternatif, Anda dapat menggunakan salah satu nama channel simbolis berikut: stable, beta, atau edge. Bergantung pada sistem Anda, variabel lingkungan PATH mungkin perlu diperbarui. Jika pesan ini muncul, salin dan tempel perintah yang disarankan di bawah untuk memperbarui PATH. Anda dapat mengonfirmasi versi solana yang diinginkan dengan menjalankan solana --version.

Di Windows, buka Command Prompt sebagai Administrator. Salin dan tempel perintah berikut untuk mengunduh installer Solana ke direktori sementara:

cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Kemudian, salin dan tempel perintah berikut untuk menginstal versi terbaru Solana: C:\solana-install-tmp\solana-install-init.exe v1.17.13. Setelah instalasi selesai, tekan Enter.

Tutup jendela Command Prompt, lalu buka kembali sebagai pengguna biasa. Konfirmasikan bahwa versi solana yang diinginkan telah terinstal dengan menjalankan solana –-version.

Selanjutnya, instal Anchor.

Sebaiknya instal Anchor menggunakan Anchor version manager (avm). Anda dapat melakukannya melalui cargo dengan perintah:

cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Kemudian, instal dan gunakan versi terbaru:

avm install latest
avm use latest

# Verify the installation
avm –version

Anchor versi 0.28 memungkinkan developer melakukan build langsung dengan Solang. Developer dapat membuat proyek Solang baru dengan perintah: anchor init project_name —solidity. Perintah ini membuat program Solang baru dan file pengujian yang menunjukkan cara berinteraksi dengan program melalui client.

Pertimbangkan untuk menginstal ekstensi Solang guna membantu penyorotan sintaks jika Anda menggunakan Visual Studio Code. Nonaktifkan ekstensi Solidity aktif lainnya agar ekstensi Solang berfungsi dengan benar.

Membuat Proyek Baru

Buat proyek baru dengan perintah anchor-init project_name –solidity. Perintah ini membuat direktori baru dengan nama proyek Anda. Flag Solidity memberi tahu Anchor bahwa kita ingin menggunakan Solang. Direktori ./solidity proyek akan menyediakan program awal. Contract tersebut akan terlihat seperti berikut:

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

Program ini memiliki constructor untuk membuat program, menginisialisasi variabel state value menjadi true, dan mencatat “Hello, World!” ke log program. Fungsi flip memperbarui variabel state saat dipanggil. Fungsi get mengembalikan nilai variabel state saat ini. Ini tampak seperti smart contract Solidity biasa, tetapi memiliki beberapa perbedaan. Perbedaan paling signifikan adalah penggunaan anotasi.

Anotasi

Anotasi digunakan untuk pengelolaan account. Perhatikan anotasi @program_id(“...”). Anotasi ini digunakan untuk menentukan alamat on-chain program jika sudah diketahui sebelumnya. Jika Anda ingin memanggil contract melalui panggilan eksternal, program harus memiliki notasi @program_id atau dipanggil menggunakan argumen {program_id: … }:

@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Saat kita membuat proyek baru, contoh contract yang disediakan memiliki anotasi @payer di atas constructor. Anotasi ini menentukan account yang akan membayar inisialisasi data account program. Sintaks @payer(payer) mendeklarasikan account bernama payer, yang akan diperlukan pada setiap pemanggilan constructor.

Saat contract dibuat instansinya, contract tersebut memerlukan program account untuk menyimpan kode yang dapat dieksekusi dan data account untuk menyimpan variabel state. Data account dapat dibuat menggunakan kode sisi client, lalu diteruskan ke transaction yang memanggil constructor. Sebagai alternatif, data account dapat dibuat oleh constructor. Setidaknya, anotasi @payer harus disediakan. Seed dan bump harus disediakan jika data account akan menjadi PDA. Anotasi @seed menentukan seed untuk memperoleh PDA dan dapat berupa literal string atau string heksadesimal dengan format hex”1234”. Jika berada sebelum suatu argumen, anotasi seed harus merujuk pada argumen bertipe bytes, address, atau array byte dengan panjang tetap. Anotasi @bump menentukan nilai yang digunakan untuk menghasilkan alamat off-curve. Nilainya harus berupa satu byte bertipe bytes1. Anotasi opsional @space dapat digunakan untuk menentukan ukuran data account. Anotasi ini adalah ekspresi uint64 yang dapat berupa konstanta atau menggunakan salah satu argumen constructor. Menurut dokumentasi Solang, setidaknya @space harus berukuran sama dengan ukuran yang diberikan saat menjalankan perintah solang -v:

$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Jika program tidak memiliki constructor, anotasi ini dapat dipasangkan dengan constructor kosong. Dokumentasi Solang memberikan contoh berikut:

@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

Anotasi fungsi digunakan untuk mendeklarasikan account yang diperlukan bagi fungsi eksternal:

• @account(foo) mendeklarasikan account foo sebagai account hanya-baca
• @mutableAccount(bar) mendeklarasikan account bar sebagai account yang dapat diubah
• @signer(fizz) mendeklarasikan account fizz sebagai penanda tangan hanya-baca
• @mutableSigner(buzz) mendeklarasikan account buzz sebagai penanda tangan yang dapat diubah

Account yang dideklarasikan dengan anotasi @payer pada constructor dapat diakses di dalamnya. Account yang dideklarasikan dengan anotasi fungsi tersedia dalam vector tx.accounts. Misalnya, Anda akan menggunakan tx.accounts.ichigo untuk mengakses account yang dideklarasikan sebagai @account(ichigo). Ini akan mengembalikan struct bawaan AccountInfo. Struct ini mengikuti struktur yang sama dengan yang dijelaskan dalam bagian “Memahami Model Account”. Penamaannya sedikit berbeda:

• key: alamat atau public key account. Bertipe address
• lamports: saldo lamport account. Bertipe uint64
• data: data account. Bertipe bytes
• owner: pemilik account. Bertipe address
• rent_epoch: epoch berikutnya saat rent account jatuh tempo. Bertipe uint64
• is_signer: menentukan apakah account menandatangani transaction. Bertipe bool
• is_writable: menentukan apakah account dapat ditulis dalam transaction ini. Bertipe bool
• executable: menentukan apakah account merupakan program. Bertipe bool

Keterbatasan

Ketidakkompatibilitas utama antara Solang dan pengembangan Ethereum tradisional adalah:

• msg.sender tidak tersedia di Solana. Dengan model account, contract Rust dapat mengakses berbagai data account, lalu account mana yang harus dianggap sebagai pemanggil? Dalam banyak kasus, kita tidak dapat mengidentifikasi satu account sebagai pemanggil. Selain itu, runtime tidak memiliki mekanisme untuk mengambil account pemanggil
• Tidak ada fungsi ecrecover(), tetapi tersedia fungsi signatureVerify() untuk memeriksa tanda tangan ed25519.
• Pernyataan try-catch tidak berfungsi. Runtime akan menghentikan eksekusi dan membatalkan seluruh transaction jika panggilan eksternal atau pembuatan contract gagal.
• Definisi error dan revert dengan pesan error belum berfungsi
• Transfer native value melalui pemanggilan fungsi tidak berfungsi.
• Banyak fungsi bawaan Yul tidak tersedia. Solang mendukung sebagian besar fungsi bawaan, tetapi operasi memori dan chain belum diimplementasikan.
• Format ERC-20 saat ini belum didukung. SPL Token ditentukan sesuai Token Program. Token Program adalah cara native Solana untuk membuat, mencetak, mentransfer, dan membakar token. File spl_token.sol harus disalin ke source tree Anda dan diimpor saat diperlukan untuk menggunakan library SplToken

Selain itu, register SVM memiliki lebar 64 bit. Artinya, integer 64 bit (yaitu uint64 dan int64) lebih disarankan daripada integer 256 bit. Operasi dengan tipe yang lebih lebar dari 64 bit, seperti uint256 atau int256, dipecah menjadi beberapa operasi. Hal ini membuatnya lebih lambat dan mengonsumsi lebih banyak unit komputasi.

Untuk alamat, literal alamat harus ditentukan menggunakan sintaks address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D". Sintaks heksadesimal Ethereum (misalnya, 0xE0f5206BBD039e7b0592d8918820024e2a7437b9) tidak didukung. Semua saldo dan nilai di Solana memiliki lebar 64 bit. Artinya, fungsi bawaan untuk alamat (yaitu .balance(), .transfer(), dan .send()) menggunakan integer 64 bit.

Meskipun Solang menawarkan jalur menarik bagi developer EVM untuk memasuki ekosistem Solana, Solang memiliki sejumlah keterbatasan yang perlu dipertimbangkan dengan cermat. Peralihan ke model berbasis account Solana bukan sekadar perubahan sintaks—ini merupakan perubahan mendasar pada logika smart contract. Fungsi, pola coding, dan fitur tertentu yang khusus untuk EVM tidak tersedia di Solang. Developer tidak dapat memindahkan smart contract Ethereum ke Solang dan mengharapkannya berfungsi tanpa penyesuaian signifikan. Fitur yang belum tersedia, seperti definisi error yang tepat dan revert dengan pesan error, dapat menjadi masalah serius. Namun, penting untuk diingat bahwa Solang adalah alat yang terus berkembang, dengan setiap pembaruan ditujukan untuk meningkatkan pengalaman developer Solidity di Solana. Solang menawarkan beberapa keunggulan khusus untuk meningkatkan pengalaman ini.

Keunggulan

Terlepas dari keterbatasan tersebut, tersedia sejumlah fungsi bawaan dan pilihan desain untuk meningkatkan pengalaman developer. Misalnya, contract yang dikembangkan di Solang dapat berinteraksi dengan program Anchor. Hal ini dapat dilakukan dengan menghasilkan interface Solidity dari IDL program Anchor. IDL adalah singkatan dari “Interface Description Language”. Pada dasarnya, IDL merupakan file JSON yang berisi semua spesifikasi program. File ini mencakup semua yang perlu Anda ketahui untuk berinteraksi dengan program Anchor. Anchor secara otomatis menghasilkan IDL saat mengembangkan program menggunakan framework-nya. Ini sangat mirip dengan ABI di Ethereum. Untuk menghasilkan interface Solidity dari IDL, gunakan perintah berikut: solang idl [-output directory] [IDL file]. Setelah itu, file dapat diimpor menggunakan sintaks import “...”;.

Solang menyediakan library Solana, yaitu serangkaian library yang memungkinkan contract Solidity berinteraksi dengan instruction khusus Solana. Solang menyediakan library SPL Token untuk mencetak, membakar, dan mentransfer token. Library ini dapat dianggap setara dengan ERC-20 dan ERC-721. Solang juga menyediakan library System Instructions agar developer dapat berinteraksi dengan System Program Solana.

Solang juga menyertakan beberapa fungsi bawaan yang dapat diimpor dengan solana. Ini mencakup struct AccountMeta dan AccountInfo. Struct AccountMeta digunakan untuk menentukan account yang harus diteruskan kepada pihak yang dipanggil dalam panggilan eksternal (yaitu CPI). Struct AccountMeta memiliki struktur berikut:

• pubkey: alamat atau public key account. Bertipe address
• is_writable: menentukan apakah pihak yang dipanggil dapat menulis ke account ini. Bertipe bool
• is_signer: menentukan apakah pihak yang dipanggil dapat menganggap account ini telah menandatangani transaction. Bertipe bool

Jika argumen accounts dihilangkan dalam panggilan eksternal, compiler Solang secara otomatis menghasilkan array AccountMeta. Hal ini hanya berfungsi jika fungsi dideklarasikan sebagai external. Jika tidak, array AccountMeta harus dibuat secara manual sesuai urutan account yang ditentukan dalam IDL. Jika suatu panggilan tidak memerlukan account, teruskan vector kosong: {accounts: []}. Dokumentasi Solang memberikan contoh yang jelas tentang cara membuat array AccountMetas:

function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

Solang juga memiliki fungsi bawaan untuk:

• Menghitung saldo minimum yang diperlukan untuk membuat account tertentu
• Membuat PDA untuk alamat program berdasarkan seed dan bump yang diberikan
• Menemukan PDA untuk alamat program berdasarkan seed dan bump yang diberikan

Solang menjembatani kesenjangan antara Solana dan Ethereum dengan menyediakan compiler beserta rangkaian alat lengkap yang memudahkan transisi bagi developer EVM. Meski memiliki keterbatasan, Solang menawarkan beberapa fitur untuk meningkatkan pengalaman developer, termasuk kemampuan berinteraksi dengan program Anchor, mengakses library khusus Solana, dan menggunakan fungsi bawaan. Integrasi konsep yang sudah dikenal seperti IDL dan standar token semakin memudahkan proses pembelajaran. Tidak perlu mengkhawatirkan atau melakukan optimasi untuk gas juga menjadi nilai tambah. Solang merupakan langkah penting menuju interoperabilitas antara Solana dan Ethereum. Bagi developer EVM yang ingin berekspansi ke dunia Solana berperforma tinggi, Solang dapat menjadi salah satu alat yang tepat.

Neon EVM

Solang bukan satu-satunya pilihan bagi developer Solidity yang ingin membangun di Solana. Neon EVM menyebut dirinya sebagai EVM pertama di dunia yang dapat diparalelkan. Neon EVM adalah lingkungan Ethereum yang sepenuhnya kompatibel di Solana. Ini merupakan solusi sinergis bagi siapa pun yang ingin meningkatkan skala dApp Ethereum di Solana dengan cara yang ramah developer. Developer dapat men-deploy dApp tanpa mengonfigurasi ulang smart contract, tetap menggunakan bahasa dan alat yang mereka sukai.

Arsitektur

Neon EVM terdiri dari tiga komponen utama: program Neon EVM, Neon Proxy, dan Neon DAO.

Neon EVM adalah program Solana yang menerima transaction serupa Ethereum dan memprosesnya di Solana sesuai aturan EVM. Transaction serupa Ethereum yang diarahkan ke Neon EVM disebut Neon Transactions. Transaction tersebut merupakan subset metode JSON RPC sesuai Ethereum JSON-RPC API.

Neon Proxy memungkinkan developer Ethereum memindahkan dApp mereka ke Neon dengan perubahan minimal. Neon Proxy membungkus transaction EVM ke dalam transaction Solana dan bertindak sebagai solusi terkontainerisasi bagi Neon Operators. Operator ini menjalankan server Neon Proxy, menerima pembayaran dalam NEON, dan melakukan pembayaran dalam ekosistem Solana menggunakan SOL. NEON merupakan token utilitas sekaligus tata kelola: Neon Operators mengumpulkannya untuk membayar biaya gas yang diperlukan bagi eksekusi transaction, sementara pemiliknya dapat berpartisipasi dalam Neon DAO.

Neon DAO adalah model tata kelola berbasis komunitas yang dirancang untuk memberdayakan pemegang token NEON dalam proses pengambilan keputusan Neon EVM. Neon DAO terdiri dari pengguna, operator, kontributor, serta developer inti dan aplikasi yang bersama-sama membahas aturan tata kelola dan evolusi protokol. DAO beroperasi melalui berbagai majelis terdesentralisasi yang berfokus pada ekosistem, pengembangan, dan keamanan. Setiap majelis memfasilitasi pengambilan keputusan kolaboratif dan peninjauan proposal untuk bidang masing-masing. Majelis yang berfokus pada ekosistem mengawasi pertumbuhan ekosistem yang berkelanjutan serta mengelola dana untuk hibah dan inisiatif. Majelis yang berfokus pada pengembangan menangani peningkatan teknis program Neon dan intervensi darurat. Majelis yang berfokus pada keamanan melindungi treasury Neon dan program Neon dari potensi ancaman.

Kompatibilitas EVM

Neon EVM memfasilitasi interaksi EVM di Solana dengan:

• Mengimplementasikan sebagian besar metode Ethereum JSON-RPC API
• Menggunakan proxy khusus untuk menangani panggilan Ethereum
• Menyesuaikan diri dengan perbedaan dan keterbatasan yang ditimbulkan oleh arsitektur Solana

Berinteraksi dengan Neon EVM serupa dengan berinteraksi dengan EVM lainnya. Developer dapat menggunakan metode RPC API yang sudah dikenal dan mengarahkannya ke Neon Proxy, sehingga pengalaman developer tetap lancar. Fitur utamanya meliputi:

• Kompatibilitas dengan smart contract Solidity dan Vyper, serta alat pengembangan Ethereum standar seperti Metamask, Foundry, dan Remix
• Dukungan untuk sebagian besar Opcode Ethereum tanpa perubahan
• Penerimaan permintaan transaction Ethereum tipe 0 / legacy. Transaction EIP-1559 saat ini belum didukung

Tentu saja, sejumlah penyesuaian diperlukan agar Neon EVM berfungsi dengan benar di Solana. Perbedaan penting meliputi:

• Neon EVM mendukung semua contract prakompilasi yang ditentukan di evm.code. Namun, contract Solidity yang berisi panggilan berikut tidak akan dieksekusi: bigModExp, bn256Add, bn256ScalarMult, dan bn256Pairing. Neon EVM memerlukan implementasi system call Solana agar dapat mendukung contract tersebut di masa mendatang
• Meskipun sebagian besar opcode didukung tanpa perubahan, opcode COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE, dan GAS tidak didukung. Opcode ini dikenal sebagai opcode varian dan disesuaikan untuk digunakan di Neon EVM.
• Konsumsi gas dan perhitungan biaya berbeda dari Ethereum. Umumnya, biayanya lebih rendah karena Solana berperan sebagai settlement layer
• Method transfer() dan send() milik Solidity tidak aman dari reentrancy di Neon EVM karena perhitungan gas yang berbeda
• Model account Solana memengaruhi penyimpanan smart contract, dengan fungsi penyimpanan dan izin akses yang berbeda untuk account yang dapat dan tidak dapat dieksekusi
• Neon EVM menggunakan transaction berversi, yang membatasi jumlah maksimum account dalam satu transaction menjadi 64
• Neon EVM menggunakan Berkley Packet Filter (BPF) Solana dengan batas memori heap 256 KB. Hal ini membatasi ukuran panggilan contract dan memerlukan strategi optimasi untuk mengelola penggunaan memori secara efektif
• Fungsi berbasis waktu seperti block.number dan block.timestamp berperilaku berbeda. Developer sangat disarankan untuk tidak menggunakannya saat mengembangkan di Neon EVM

Meskipun Neon EVM menyediakan lingkungan yang kompatibel dan sudah dikenal, developer EVM harus memahami serta menyesuaikan diri dengan perbedaan utama agar berhasil bermigrasi dan membangun di Solana.

Menghubungkan ke Neon RPC

Developer dapat dengan mudah terhubung ke Neon RPC menggunakan Chainlist. Di sini, developer dapat terhubung ke Neon EVM Mainnet atau Devnet. Klik Connect Wallet pada modal Mainnet atau Devnet, lalu klik Approve saat wallet Anda muncul.

Pengguna sebaiknya memilih operator optimal sebelum mengirim transaction ke Neon EVM. Perluas detail kartu untuk melihat endpoint RPC yang tersedia bagi setiap network:

Jika Anda memilih Operator selain operator default yang disediakan saat menghubungkan wallet, Anda perlu membuat koneksi secara manual. Dokumentasi Neon EVM menyediakan panduan lengkap untuk terhubung ke Proxy menggunakan Foundry, Hardhat, Remix, dan Truffle. Kita akan membahas cara terhubung dengan Foundry dalam bagian deployment.

Setelah terhubung, developer dapat menggunakan Neon Faucet untuk memperoleh NEON atau token pengujian ERC-20 lainnya. Developer juga dapat menggunakan endpoint request_neon untuk meminta token secara terprogram:

curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Perintah ini mengirimkan permintaan POST untuk menerima token ke alamat wallet yang ditentukan.

Siklus Hidup Transaction dan Biaya Gas

Ada tiga langkah utama untuk mengeksekusi transaction dari dApp Ethereum di Solana melalui Neon EVM:

• Pengguna memulai transaction serupa Ethereum yang telah ditandatangani dan diarahkan ke endpoint Neon RPC
• Transaction diteruskan ke Neon Proxy melalui Ethereum API. Proxy memperkirakan gas yang diperlukan untuk mengeksekusi transaction, memulai broadcast dengan membungkus transaction serupa Ethereum ke dalam transaction Solana, lalu mengirim transaction yang telah dibungkus ke Neon EVM. Proses ini menghasilkan receipt Solana dan receipt transaction Neon EVM yang sesuai. Smart contract Neon membuka pembungkus transaction, memverifikasi tanda tangan pengguna, dan memuat state EVM dari penyimpanan Solana. Transaction dieksekusi di dalam BPF Solana
• Solana dan Neon EVM memperbarui state masing-masing untuk menyelesaikan permintaan transaction

Inilah seluruh siklus hidup transaction di Neon EVM, mulai dari inisiasi hingga eksekusi. Developer dapat mengunjungi NeonScan untuk melihat transaction dan block terbaru serta mencari account, token, block, atau hash transaction.

Developer juga dapat mengirim transaction tanpa gas. Fitur ini diimplementasikan untuk mendukung pengguna yang tidak memiliki cukup token NEON guna membayar biaya transaction awal. Developer dapat memperoleh paket awal transaction tanpa gas dengan menghubungi info@neonevm.org. Proxy Operator yang dipilih developer tetap akan menangani transaction tersebut, tetapi Neon menanggung biaya transaction. Setiap account Neon baru biasanya mendapatkan minimal tiga transaction tanpa gas.

Proses transaction tanpa gas adalah sebagai berikut:

• Pengguna akhir memulai transaction melalui dApp
• dApp meminta harga gas saat ini dari Proxy Operator yang dipilih. Jika memenuhi syarat, Proxy Operator menandai account Neon untuk sejumlah transaction tanpa gas yang ditentukan
• Untuk transaction tersebut, dApp akan menampilkan biaya gas sebesar nol
• Pengguna akhir menandatangani transaction tanpa biaya gas
• Proxy Operator mengeksekusi transaction, dengan biaya gas SOL dibayar oleh Neon Foundation

Dokumentasi Neon EVM menyediakan cuplikan berikut untuk menunjukkan cara meminta transaction tanpa gas:

try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

NeonPass adalah alat untuk mentransfer token antara Solana dan Neon EVM. Alat ini memungkinkan transfer aset yang lancar antara Associated Token Accounts Solana dan account token ERC-20 Neon EVM. NeonPass menggunakan interface contract Neon EVM dan penyimpanan account khusus. Token Solana Program Library (SPL) dibungkus ke dalam interface ERC-20 di dalam factory contract Neon EVM. Hal ini memungkinkan SPL disimpan dalam account token ERC-20 yang kompatibel dengan dApp Solidity. NeonPass memungkinkan transfer token dua arah antara account Solana dan Neon EVM. Tidak seperti bridge tradisional yang mengunci dan mencetak aset baru, NeonPass memindahkan token secara langsung antara kedua jenis account tersebut. Hal ini memungkinkan transisi token Solana dan Neon EVM yang lancar.

Deployment

Developer dapat melakukan deployment ke Neon EVM menggunakan Hardhat, Foundry, Truffle, dan Remix. Karena cara termudah menggunakan Solang adalah melalui Anchor, semua pengujian dilakukan dalam TypeScript. Namun, kini semua penggemar berat Solidity akhirnya dapat menguji dan men-deploy dApp Solidity ke Solana melalui Foundry.

Pertama, pastikan Anda memiliki wallet yang kompatibel dengan EVM dan terhubung ke Neon EVM Devnet. Kemudian, clone proyek contoh Foundry milik Neon dan buka direktorinya:

git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Selanjutnya, instal Foundryup, installer toolchain Foundry, lalu jalankan foundryup untuk menginstal binary prakompilasi terbaru (nightly) (yaitu force, cast, anvil, dan chisel):

curl -L https://foundry.paradigm.xyz | bash
foundryup

Instal library yang diperlukan:

forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Sekarang, dapatkan private key untuk account wallet Anda. Di Metamask, misalnya, Anda dapat melihat private key dengan mengeklik menu hamburger dan membuka Account Details > Show Private Key. Anda akan diminta memasukkan kata sandi. Klik Confirm untuk mengakses private key account Anda. Jangan berikan key ini kepada siapa pun dan lakukan langkah-langkah yang diperlukan untuk melindunginya.

Kemudian, buat file .env dengan variabel berikut:

RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Ganti <YOUR_PRIVATE_KEY> dengan private key Anda, lalu jalankan source .env.

Untuk mengompilasi contract proyek, buka direktori src dan jalankan forge build. Console seharusnya menampilkan bahwa proses compiler berhasil. Contract juga dapat diuji menggunakan perintah forge test. Untuk men-deploy contract proyek, jalankan perintah berikut:

forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Anda akan melihat output yang serupa dengan berikut:

[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Untuk memverifikasi contract Anda, jalankan perintah berikut:

forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Ganti <contract_address> dengan alamat smart contract Anda. Anda seharusnya menerima respons OK beserta URL yang mengarah ke alamat contract di BlockScout, explorer Devnet milik Neon. Anda juga dapat mengonfigurasi file .env untuk menggunakan NeonScan sebagai pengganti BlockScout, yang juga mendukung devnet.

Keunggulan dan Keterbatasan

Developer yang menginginkan pengalaman pengembangan serupa Ethereum sebaiknya memilih Neon EVM. Neon EVM merupakan lingkungan yang kompatibel dengan EVM, mengirim transaction serupa Ethereum, dan menggunakan alat yang sudah dikenal. Fitur seperti NeonPass, dukungan untuk sebagian besar opcode EVM, dan penyediaan transaction tanpa gas sangat memudahkan transisi ke Solana. Namun, Neon EVM tidak sempurna. Neon EVM memiliki sejumlah keterbatasan, seperti perubahan logika smart contract agar sesuai dengan infrastruktur Solana, pengoperasian dalam batasan Berkeley Packet Filter (BFP) dan model account Solana, serta pembatasan tertentu pada opcode dan contract prakompilasi. Memahami dan menangani nuansa ini sangat penting agar deployment ke Solana dari lingkungan yang kompatibel dengan EVM berhasil.

Migrasi Sebelumnya

Beberapa tugas kompleks harus diselesaikan agar protokol Ethereum berskala besar dapat diterapkan pada chain non-EVM. Di antaranya merekrut engineer non-Solidity untuk membangun ulang basis kode dari awal, menemukan mitra audit tepercaya, mengaudit ulang basis kode baru, dan menyesuaikan kontrak tata kelola untuk menegakkan keputusan DAO. Upaya ini berpotensi menelan biaya jutaan dolar dan membutuhkan kerja khusus selama berbulan-bulan. Hal ini tidak memungkinkan bagi sebagian besar proyek. Namun, ini pernah dilakukan sebelumnya.

Helium adalah jaringan LoRaWAN yang bertujuan menciptakan infrastruktur nirkabel terdesentralisasi untuk mendukung perangkat Internet of Things (IoT). Hal ini dilakukan menggunakan hotspot, yaitu perangkat kecil berdaya rendah yang menyerupai menara seluler mini dan terhubung ke hotspot lain dari jarak jauh. Helium awalnya berjalan pada blockchain Layer 1 (L1) miliknya sendiri, tetapi tim developernya mengusulkan perpindahan ke Solana melalui HIP 70. Perpindahan ini memungkinkan Helium mencapai waktu aktif lebih tinggi, komposabilitas lebih baik, dan pengalaman pengguna lebih cepat, sembari mempertahankan tingkat keamanan yang tinggi dan biaya penggunaan yang rendah. Komunitas memberikan suara mayoritas mutlak untuk mendukung proposal tersebut, dan Helium bermigrasi ke Solana pada April 2023. COO Helium Scott Sigel menggambarkan migrasi tersebut sebagai peristiwa yang membosankan —tidak ada masalah dengan jaringan maupun infrastruktur Helium. Itu adalah impian setiap engineer. Tim tersebut juga menguraikan seluruh proses migrasi dalam serangkaian panduan di dokumentasi mereka. Migrasi Helium meraih kesuksesan besar dan memberikan manfaat signifikan bagi komunitas.

Migrasi ini bukan peristiwa yang berdiri sendiri. The Render Network, platform rendering GPU terdesentralisasi pertama di dunia, berhasil meningkatkan infrastruktur intinya dari Ethereum ke Solana pada November 2023. Komunitas memberikan suara yang mendukung RNP-002 untuk bermigrasi ke Solana. Pendiri Render, Jules Urbach, menggambarkan migrasi tersebut sebagai momen penting yang membawa perubahan besar. Ia menyatakan: “Kecepatan transaksi Solana yang luar biasa, biayanya yang rendah, dan komitmennya terhadap arsitektur berskala web menjadikannya pilihan sempurna bagi Render Network seiring kami terus membangun infrastruktur metaverse yang dapat diskalakan dan terdesentralisasi.”

Migrasi Render tidak memberikan dampak yang terlalu negatif bagi penggunanya. Pengguna dapat melakukan bridge dana dari Ethereum ke Solana menggunakan Upgrade Assistant milik Render. Pengguna menghubungkan dompet Ethereum mereka, menentukan jumlah RNDR yang ingin dimigrasikan, lalu menunggu token dikirimkan ke dompet Solana yang ditentukan. 

Maker adalah proyek Ethereum yang sangat representatif. Mereka bertujuan membuka potensi keuangan terdesentralisasi melalui Maker Platform, sebuah platform inklusif yang dirancang untuk meningkatkan pemberdayaan ekonomi dan kesetaraan akses ke pasar keuangan global. Platform ini terdiri dari MakerDAO untuk mengelola proyek Maker dan protokol Maker untuk DAI, “mata uang netral pertama di dunia dan stablecoin terdesentralisasi terkemuka.” Rune Christensen, pendiri Maker, menulis di Twitter tentang penggunaan fork dari basis kode Solana untuk mengembangkan appchain Maker: 

Migrasi pada dasarnya kompleks. Terlepas dari biaya finansial, reputasi, dan waktu untuk memigrasikan seluruh infrastruktur proyek dari Ethereum ke Solana, berbagai proyek memilih Solana. Dengan alat seperti Solang dan Neon EVM, migrasi tidak harus selalu kompleks. Seperti migrasi Helium, prosesnya bisa terasa membosankan dan nyaris tidak berdampak buruk terhadap dana pengguna, sebagaimana yang dialami Render Network. Solana adalah blockchain dengan performa tertinggi di pasar dan dibangun untuk skala web. Inilah tempat untuk membangun, dan semakin banyak proyek mulai menyadarinya.

Kesimpulan

Solidity adalah lingua franca dalam pengembangan kontrak pintar. EVM telah menjadi lingkungan kontrak pintar yang dominan sejak pertama kali hadir. Namun, EVM memiliki kelemahan. Aplikasi berskala web dan kelas konsumen memerlukan jaringan dengan throughput tinggi serta latensi rendah untuk mendukung operasinya. Lingkungan Ethereum yang berutas tunggal dan berbasis gas yang volatil tidak dapat mendukung proyek Decentralized Physical Infrastructure Network (DePIN) ber-throughput tinggi seperti Helium. 

Sebagai jawaban atas tantangan tersebut, Solana hadir sebagai alternatif yang tangguh. Cara terbaik untuk memanfaatkan keunggulan Solana yang sebenarnya adalah dengan membangun langsung di Solana. Berkat perkembangan terbaru, alat seperti Solang dan Neon EVM memungkinkan developer EVM yang tertarik untuk bermigrasi menggunakan alat dan bahasa yang sudah familier. Artikel ini menawarkan panduan komprehensif tentang arsitektur Solana, perbandingannya dengan Ethereum, dan bagaimana developer EVM dapat mulai mengembangkan aplikasi di Solana. Solana adalah blockchain dengan performa tertinggi di pasar. Solana terus meraih momentum, semakin dikenal, dan menarik berbagai aplikasi kelas konsumen bereputasi baik. Mengapa menunggu Ethereum meningkatkan skalanya jika Anda dapat menikmati manfaat blockchain yang cepat dan dapat diskalakan sekarang juga?

Jika Anda sudah membaca sejauh ini, terima kasih, anon! Pastikan Anda memasukkan alamat email di bawah agar tidak pernah melewatkan kabar terbaru tentang Solana. Siap mempelajari lebih jauh? Bergabunglah dengan Discord kami untuk mulai membangun masa depan di blockchain dengan performa tertinggi hari ini.

Referensi Lebih Lanjut

• Mengevaluasi Solana untuk Penggunaan Enterprise: Panduan Komprehensif
• Neon EVM
• Dokumentasi Solang untuk Solana
• Buku Rust
• Model Pemrograman Solana: Pengantar Pengembangan di Solana
• Tower BFT: Implementasi PBFT Berperforma Tinggi dari Solana
• Apa Itu SVM — Mesin Virtual Solana