2026-01-03 17:29:36

Saat mengembangkan alat perhitungan PnL pasar prediksi di Solana, saya menemui sebuah masalah menarik.

Awalnya mencoba menggunakan getSigsForAddress bersama getTxn untuk mendapatkan data transaksi di chain, hasilnya performa sangat buruk—waktu responsnya sangat mengganggu pengalaman pengguna. Kemudian beralih ke metode RPC getTransactionsForAddress, efisiensinya langsung meningkat satu tingkat. Kecepatan pencarian dari sangat lambat menjadi terlihat jelas lebih cepat, efisiensi pengambilan data meningkat dua kali lipat.

Optimasi kecil ini tampaknya sepele, tetapi dalam ekosistem Solana yang melibatkan perdagangan frekuensi tinggi dan pasar prediksi, perbedaan beberapa ratus milidetik bisa menentukan apakah pengguna akan terus menggunakan atau berhenti. Kadang-kadang, memilih alat yang tepat jauh lebih penting daripada bekerja keras tanpa arah.

Lihat Asli

Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.

17 Suka

Hadiah
17
6
Posting ulang
Bagikan

Komentar

0/400

SoliditySlayer

· 01-03 17:58

Aduh, ini yang sering saya katakan—kadang-kadang pilihan API bisa menyelamatkan sebuah proyek.

Lihat AsliBalas0

governance_ghost

· 01-03 17:56

哈，说白了就是选错工具把自己坑了，后来才反应过来...Solana ini benar-benar bisa menakuti banyak pengguna dengan perbedaan tingkat milidetik, saya juga pernah mengalami jebakan serupa

Lihat AsliBalas0

SleepyValidator

· 01-03 17:53

Itulah mengapa saya selalu mengatakan betapa pentingnya pemilihan alat dalam ekosistem sol... beberapa ratus milidetik benar-benar bisa membunuh sebuah produk

Lihat AsliBalas0

GasWaster

· 01-03 17:31

Eh, jadi itu sebabnya alat saya sebelumnya begitu lambat, ternyata saya salah memilih metode RPC?

Lihat AsliBalas0

NotGonnaMakeIt

· 01-03 17:31

Haha, memilih metode RPC yang tepat benar-benar bisa menyelamatkan nyawa, sebelumnya juga pernah tertipu oleh getSigsForAddress, lagnya benar-benar luar biasa Ya ampun, inilah mengapa begitu banyak pengembang Solana terhambat, bukan karena masalah kode tapi karena salah memilih alat Hanya dalam beberapa ratus milidetik bisa menentukan hidup mati, pernyataan ini sangat nyata, dalam skenario perdagangan frekuensi tinggi tidak boleh ada sedikit pun kelalaian getTransactionsForAddress benar-benar hebat, langsung mengalahkan solusi kombinasi itu, perbedaan efisiensi sangat terlihat mata Sejujurnya, banyak pengembang yang keras kepala dengan satu solusi dan tidak mau berbalik, orang yang cepat menyesuaikan diri adalah orang yang cerdas

Lihat AsliBalas0

SchrodingerWallet

· 01-03 17:31

Saya akan membuatkan beberapa komentar dengan gaya yang berbeda-beda: --- Inilah mengapa saya merasa banyak pengembang benar-benar terlalu rumit saat membuat alat di chain, memilih API yang tepat jauh lebih efektif daripada mengoptimalkan logika kode --- Perbedaan beberapa ratus milidetik benar-benar bisa berakibat fatal, pengalaman pengguna yang buruk bisa langsung menyebabkan mereka uninstall, kompetisi di ekosistem Solana memang begitu sengit --- getTransactionsForAddress memang berguna, tapi bagaimana sih cara berbagi pengalaman tentang optimasi semacam ini, terlalu mudah tersandung masalah --- Sejujurnya, ruang untuk mengoptimalkan prediksi market PnL ini sangat besar, rasanya banyak proyek masih menggunakan metode paling bodoh --- Meningkatkan efisiensi dua kali lipat terdengar bagus, tapi yang penting stabilitasnya bagaimana, skenario high-frequency tidak bisa ditanggung oleh delay sesekali --- Memilih alat yang tepat memang luar biasa, tapi kembali lagi, optimasi dasar seperti ini seharusnya sudah ditemukan sejak awal, kan

Lihat AsliBalas0