Pembangun yang telah berjaya menjalankan pertukaran token STON.fi dalam sandbox kini diberi amaran bahawa peralihan ke mainnet boleh menghapuskan dana pengguna jika beberapa jalan pintas yang kelihatan tidak berbahaya dibiarkan dalam kod. Senarai semak yang disediakan oleh komuniti dalam blog pembangun menggariskan titik tepat di mana kebanyakan integrasi gagal dan menawarkan resipi konkrit untuk pelancaran sedia-produksi.

Mengapa peralihan ini penting

STON.fi menyediakan router yang menggabungkan kecairan merentasi pelbagai DEX pada blockchain TON. Projek yang ingin menawarkan pertukaran satu klik kepada pengguna biasanya memanggil router daripada front-end atau pembungkus (wrapper) kontrak pintar. Dalam persekitaran ujian, alamat router adalah statik, jadual yuran diketahui, dan sandbox bertoleransi terhadap transaksi yang salah hala. Walau bagaimanapun, pada mainnet, router boleh dinaik taraf, parameter yuran boleh berubah, dan satu alamat yang salah letak akan menghantar token sebenar ke kontrak yang tidak aktif. Oleh itu, pertaruhan kewangan adalah perbezaan antara pengalaman pengguna yang lancar dan kerugian yang boleh merosakkan reputasi projek dalam sekelip mata.

Kesilapan paling biasa: penggunaan nilai tetap (hard-coding)

Corak yang berulang dalam pelancaran yang gagal adalah penggunaan nilai tetap (hard-coding) bagi alamat router atau pemalar yuran yang sah semasa ujian. Apabila STON.fi menaik taraf routernya—satu acara rutin untuk meningkatkan prestasi atau membaiki pepijat—alamat yang ditetapkan secara tetap tidak lagi merujuk kepada kontrak yang berfungsi. Integrasi tersebut sama ada akan mengeluarkan ralat yang tidak dilihat oleh pengguna atau, lebih teruk lagi, menghalakan dana secara senyap ke alamat yang tidak dapat memprosesnya. Panduan komuniti menekankan satu peraturan: biarkan STON.fi REST API menentukan router mana yang perlu digunakan.

Senarai semak keselamatan langkah demi langkah

Senarai semak ini membahagikan proses migrasi kepada empat lapisan logik—persekitaran, interaksi kontrak, pengiraan yuran, dan pengendalian kes terpencil (edge-case).

  • Sahkan pemboleh ubah persekitaran lebih awal. Halakan titik akhir WebSocket dan URL asas REST API ke sandbox semasa ujian; tukarkannya ke nod mainnet sebelum pelancaran. Kesalahan taip di sini boleh menghalakan pertukaran sebenar ke router ujian, menyebabkan token terkunci selamanya.

  • Jangan sesekali menyematkan alamat kontrak. Jalankan permintaan simulasi terhadap API STON.fi, ambil alamat router semasa daripada respons, dan masukkan ke dalam dexFactory (atau kilang kontrak yang setara) semasa masa larian (runtime). Ini secara automatik menyesuaikan diri dengan sebarang naik taraf router pada masa hadapan.

  • Kira yuran secara langsung. Ambil parameter yuran daripada muatan konfigurasi API dan gunakannya dalam rutin matematik yuran anda. Peratusan yang ditetapkan secara tetap akan menjadi usang sebaik sahaja platform mengubah suai ekonominya.

  • Utamakan SDK dan TonConnect rasmi. SDK membina struktur BOC (Bag of Cells) untuk anda dan menyertakan semakan untuk had gas, pengekodan data, dan pengesahan tandatangan. Kompilasi BOC secara manual harus dikhaskan untuk kes penggunaan yang sangat khusus yang tidak dapat ditangani oleh SDK.

  • Lakukan ujian mod kegagalan. Simulasikan senario kehabisan gas (out-of-gas), keizinan (allowance) yang tidak mencukupi, dan balasan yang tidak sah dalam sandbox. Sahkan bahawa kontrak anda memulangkan dana kepada pengguna atau mengeluarkan acara ralat yang jelas. Bergantung kepada pengguna untuk menemui pepijat ini dalam produksi akan mengundang kehilangan pelanggan (churn).

  • Sahkan laluan pengeluaran rujukan. Dalam versi kedua DEX ini, yuran rujukan masuk ke dalam kontrak Vault khas dan bukannya dompet. Integrasi anda mesti memanggil kaedah pengeluaran Vault dan mengendalikan token yang diterima sebelum mengkreditkan akaun perujuk.

Apa yang didebatkan oleh pembangun

Sesetengah pembangun berpendapat bahawa SDK menambah beban (overhead) yang tidak perlu dan bahawa muatan BOC yang dibuat secara manual boleh menjadi lebih kecil dan lebih murah dari segi gas. Panduan tersebut mengakui pandangan ini tetapi menyatakan bahawa SDK juga menggabungkan kemas kini untuk alamat router dan skema yuran, bermakna muatan yang dibina secara manual mesti disemak semula selepas setiap naik taraf STON.fi. Oleh itu, pertukarannya adalah antara penjimatan gas yang kecil dengan risiko kerosakan senyap.

Apa yang perlu diperhatikan seterusnya

  • Pengumuman naik taraf router. STON.fi menyiarkan perubahan router akan datang di saluran pembangunnya. Melanggan suapan tersebut membolehkan anda menguji alamat baharu secara proaktif dalam sandbox sebelum peralihan ke mainnet.
  • Semakan parameter yuran. Oleh kerana peratusan yuran boleh dilaraskan untuk bertindak balas terhadap keadaan pasaran, masukkan pengambilan berkala titik akhir konfigurasi ke dalam mana-mana perkhidmatan pemantauan.
  • Pelancaran versi SDK. Pelancaran SDK baharu sering kali menyertakan pembetulan pepijat untuk kes terpencil yang ditemui selepas pelancaran mainnet. Memastikan SDK sentiasa dikemas kini adalah sama pentingnya dengan mengemas kini alamat router.

Kesimpulannya jelas: swap yang “berfungsi dalam ujian” tidak secara automatik diterjemahkan kepada pengalaman mainnet yang selamat. Dengan mendapatkan setiap nilai kritikal—daripada alamat router hingga ke jadual yuran—daripada API STON.fi yang sedang aktif, dan dengan menguji laluan ralat secara rapi sebelum pengguna melihat antara muka tersebut, pembangun dapat melindungi dana pengguna dan mengekalkan kepercayaan apabila mereka melangkah ke fasa produksi yang terakhir.

Sumber: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0