EthBackNode: mengapa aplikasi Anda memerlukan “pengatur jarak” antara aplikasi dan node Ethereum

Jika Anda pernah mencoba membuat dompet kripto, gateway pembayaran, atau sekadar “backend yang dapat mengirim dan menerima ETH”, maka hal yang tidak menyenangkan akan segera menjadi jelas: node Ethereum bukanlah backend Anda.

Ini adalah infrastruktur canggih yang berbicara kepada Anda dalam bahasa protokol (JSON-RPC), dan tidak harus nyaman untuk pengembangan produk.

Di atas kertas, semuanya tampak sepele: “sambungkan ke geth, minta saldo, kirim transaksi, terima hash.” Namun dalam praktiknya, Anda tiba-tiba mulai menulis apa yang tidak ingin Anda tulis:

• tempat menyimpan kunci dan cara mengeluarkannya beserta alamatnya,
• cara memulihkan dompet menggunakan frase benih,
• cara melacak transaksi masuk/keluar di sejumlah besar alamat
• cara membuat notifikasi “real-time” daripada polling tanpa akhir
• bagaimana semua ini bertahan saat layanan dimulai ulang dan tidak kehilangan statusnya.

Di sinilah EthBackNode muncul - layanan sumber terbuka di Go yang berperan sebagai “adaptor” antara aplikasi Anda dan node Ethereum, dan menyediakan API JSON-RPC 2.0 murni untuk tugas backend standar.

Mengapa hidup langsung dengan Ethereum JSON-RPC itu sulit (dan terkadang mahal)

Ethereum JSON-RPC adalah hal yang bagus, tetapi levelnya rendah. Ini menunjukkan kemampuan node, dan tidak menjawab pertanyaan “bagaimana membuat suatu produk.” Saat melakukan integrasi, Anda segera menyadari bahwa tugas yang sama dibagi menjadi selusin tugas kecil, dan setengahnya sama sekali bukan tentang blockchain.

Misalnya, “terima pembayaran ke alamat”:

1. Anda perlu memberikan alamat kepada klien.
2. Anda perlu memastikan bahwa alamat tersebut dikaitkan dengan pesanan/faktur tertentu.
3. Anda perlu memantau jaringan dan memahami bahwa transaksi benar-benar telah tiba.
4. Anda perlu menunggu konfirmasi (dan ingat bahwa ada reorganisasi).
5. Anda perlu mengirimkan acara ke backend Anda: “pembayaran telah diterima, Anda dapat mengirimkannya.”
6. Kita perlu menyimpan seluruh status ini sehingga memulai ulang layanan tidak berpura-pura “tidak terjadi apa-apa.”

Jika Anda memiliki satu pesanan sehari, Anda dapat melakukannya sambil berlutut. Jika Anda memiliki lusinan/ratusan alamat dan ini setidaknya cukup penting untuk bisnis, rekayasa dimulai.

Dan di sini penting untuk diperhatikan: rata-rata pengembang backend biasanya menginginkan satu hal - API yang dapat diprediksi, peristiwa yang dapat dipahami, dan permukaan serangan yang minimal. Dan bukan mendalami seluk-beluk “cara kerja simpul”.

Apa yang dilakukan EthBackNode

EthBackNode adalah layanan "ringan" yang Anda instal di sebelah node (atau terhubung dengannya), dan aplikasi Anda sudah berkomunikasi dengannya. Dari luar tampak seperti JSON-RPC 2.titik akhir .0, di dalam - sekumpulan modul (manajer) yang bertanggung jawab atas alamat, langganan, transaksi, dan kontrak pintar.

Fitur utama yang disediakan melalui API:

1) Pembuatan dan pengelolaan alamat

Layanan ini dapat membuat dan memelihara alamat di sisi backend. Hal yang penting bukanlah “alamat dapat dibuat” (Anda dapat melakukannya sendiri), namun ada satu tempat di mana alamat tersebut berada sebagai sebuah entitas: mengikat ke userId / invoiceId Anda, penyimpanan, pemulihan.

2) Memulihkan dompet menggunakan frase awal (BIP-39/44)

Kesulitan tersendiri adalah mengimpor dan memulihkan dompet. EthBackNode menyediakan pekerjaan dengan frase awal (BIP-39) dan derivasi (BIP-44) sehingga Anda dapat membuat skenario pemulihan "normal" tanpa sepeda Anda sendiri.

3) Pemantauan transaksi masuk/keluar

Bagian paling praktis: memantau alamat. Layanan ini mengambil tugas untuk “memantau alamat-alamat ini dan melaporkan ketika sesuatu terjadi.” Artinya, Anda tidak mengubah aplikasi Anda menjadi pemindai blok, dan tidak menulis logika langganan lagi.

4) Transfer: ETH dan ERC-20

EthBackNode memungkinkan Anda mentransfer token ETH dan ERC-20 asli. Bagi backend, ini terlihat seperti operasi “transfer” tunggal, bukan serangkaian panggilan dan pemeriksaan tingkat rendah yang terpisah. Selain itu, ada perkiraan biaya - tanpanya, Anda hanya “menebak” atau membuat permintaan tambahan sendiri.

5) Notifikasi panggilan balik tentang acara

Mungkin, yang benar-benar menyelamatkan saraf: pemberitahuan acara. Daripada bertanya “apakah sudah sampai?” setiap N detik, Anda dapat mengatur panggilan balik dan menerima peristiwa “ada transaksi/pemblokiran baru/konfirmasi” di backend Anda.

Detail arsitektur yang terlihat membosankan namun menyelesaikan separuh masalah

Dalam layanan seperti itu, yang biasanya penting bukanlah “banyak fitur”, namun bagaimana layanan tersebut akan dioperasikan.

Mulai + cepathttp

Kinerja dan kemudahan penerapan. Satu biner, mulai cepat, pemuatan dapat dimengerti. Di backend kripto, ini bukan “optimasi” abstrak, melainkan kebutuhan biasa: banyak alamat, banyak peristiwa, banyak permintaan.

Menghubungkan ke node: HTTP-RPC dan IPC

EthBackNode mendukung bekerja dengan node baik melalui HTTP-RPC dan melalui soket IPC. IPC sering dipilih ketika layanan dan geth berada pada mesin yang sama: permukaan jaringan lebih sedikit, lebih sedikit masalah dengan konfigurasi akses, dan sering kali lebih dapat diandalkan..

BadgerDB sebagai penyimpanan tersemat

Pilihan pragmatis lainnya: database bawaan, tanpa Postgres/Redis eksternal wajib di awal. Hal ini sangat menurunkan ambang batas: Anda dapat meningkatkan layanan, memberinya direktori untuk data, dan layanan akan menyimpan statusnya sendiri.

Konfigurasi di HCL

HCL adalah format manusia dari “dunia Hashicorp”. Ini ramah dengan pendekatan infrastruktur (Git, ulasan, lingkungan), dan pada saat yang sama lebih mudah dibaca daripada konfigurasi JSON 200 baris.

Modularitas: pengelola alamat, langganan, transaksi, kontrak

Ini lebih penting daripada kelihatannya. Ketika Anda memiliki segalanya di satu tempat, setiap perubahan menjadi berisiko. Jika ada batasan yang jelas, akan lebih mudah untuk diuji, lebih mudah diperluas, dan lebih mudah dipahami.

Mana yang benar-benar berguna

EthBackNode tidak mencoba menjadi “pengindeks universal” atau platform analitik. Nichenya adalah backend aplikasi untuk produk.

• Pemroses pembayaran: penerbitan alamat setoran, pemantauan pembayaran, pemberitahuan, penarikan/pembersihan selanjutnya.
• Dompet kustodian: kumpulan alamat, penarikan dana, pelacakan status.
• Layanan notifikasi: satu komponen memantau jaringan, sisanya menerima peristiwa.
• Backend-for-frontend: API seluler/web tidak mengetahui tentang blockchain - hanya mengetahui tentang acara bisnis.
• Pertukaran dan layanan dengan banyak alamat: pemantauan simpanan secara massal tanpa “pemindai seluruh blockchain” yang ditulis sendiri.

Contoh kecil: seperti apa tampilannya di toko online

Misalkan Anda memiliki e-niaga kecil dan ingin menerima pembayaran dalam ETH dan satu stablecoin ERC-20 yang populer.

Skenarionya bisa seperti ini:

1. Pengguna melakukan pemesanan → backend Anda membuat orderId.
2. Backend meminta EthBackNode alamat baru untuk pesanan ini.
3. Backend mendaftarkan URL panggilan balik: “jika ada sesuatu yang masuk ke alamat ini, beri tahu saya.”
4. Pengguna membayar.
5. EthBackNode melihat transaksi dan mengirimkan peristiwa ke panggilan balik Anda: jumlah, token, hash, status.
6. Anda menunggu jumlah konfirmasi yang diperlukan dan mentransfer pesanan ke status “dibayar”.
7. Sesuai jadwal (atau segera) Anda menarik dana ke alamat penyimpanan utama.

Akibatnya, “bagian kripto” berhenti menyebar ke seluruh kode toko Anda. Ia hidup dalam satu layanan, di mana logis untuk memelihara dan mengujinya..

Mengapa ini penting (tidak ada slogan)

Web3 memiliki banyak kerumitan yang bukan merupakan “keajaiban blockchain”. Itu hanya rutinitas teknis: alamat, kunci, langganan, status transaksi, konfirmasi, notifikasi, penyimpanan negara.

EthBackNode menyediakan layanan backend untuk Anda: Anda perlu melakukan lebih banyak hal lagi ya, Anda harus melakukan ini dengan benar. Dan ini mungkin merupakan bentuk “abstraksi” yang paling berguna dalam pengembangan kripto terapan: bukan untuk menyembunyikan blockchain, namun untuk membuat pengoperasiannya dapat diprediksi.

Jika Anda memiliki produk yang perlu menerima dan mengirim ETH/ERC-20 dengan andal, dan Anda tidak ingin mengubah kode utama menjadi sekumpulan kruk di sekitar JSON-RPC, lapisan adaptor seperti itu sepertinya bukan sebuah kemewahan, tetapi masuk akal.

Berdasarkan materi dari itprolab.dev