@NewtonProtocol Dokumentasi resmi bagian 8.3 menjelaskan mekanisme auto-retry Gateway hanya dengan satu kalimat: “Jika Operator tidak tersedia, Gateway akan secara otomatis memasukkan kembali Intent ke antrean untuk memastikan tingkat keberhasilan eksekusi.” Frasa “memastikan tingkat keberhasilan” memberi kesan ilusi altruistik. Namun begitu Anda mengirim satu Intent simulasi ke kontrak mainnet, lalu secara sengaja mematikan node Operator yang telah dialokasikan, Anda akan melihat sendiri tagihan sebenarnya dari “jaminan” tersebut.

Pengujian di jaringan pengembangan untuk direplikasi: kirim satu Intent pertukaran token, kunci $NEWT sebagai agunan biaya evaluasi. Intent masuk status pending, lalu Gateway menugaskannya ke Operator A. Saat itu, putuskan koneksi jaringan TEE milik A, dan setelah sekitar 45 detik, muncullah event AssignedFailed pertama di blockchain, sehingga biaya evaluasi dipotong. Intent kemudian dimasukkan kembali ke antrean, dan kali ini ditugaskan ke Operator B; karena B juga tidak tersedia, setelah 45 detik berikutnya terjadi pemotongan biaya evaluasi kedua. Siklus ini dilakukan sebanyak 11 kali, memakan waktu kurang dari sepuluh menit, dan total biaya evaluasi yang dipotong telah mencapai 11 kali perkiraan awal. Selama periode tersebut, di tampilan antarmuka dompet, pengguna selalu melihat “pending—menunggu eksekusi”, tidak ada “sedang mencoba ulang”, tidak ada “hitungan kegagalan”; bahkan di penjelajah blockchain pun hanya terlihat penugasan terakhir, sementara penugasan yang gagal di masa lalu telah diringkas (digulung).

Di sinilah letak daya rusak dari parameter infinite retry: ia merampas “visibilitas” kegagalan eksekusi, sekaligus memindahkan biaya kegagalan secara senyap ke pengguna. Menurut bagian 10.1 dari whitepaper, fee evaluasi sudah dipotong saat Operator mulai melakukan perhitungan. Namun dalam alokasi berulang yang disebabkan oleh Operator yang tidak terhubung, setiap alokasi memicu ulang langkah evaluasi; sumber daya TEE memang dijadwalkan, tetapi dari sudut pandang pengguna, tidak ada satupun yang menghasilkan output yang valid. Ini seperti kamu menyerahkan paket ke loket ekspedisi; kurir berangkat berkali-kali dan kembali lagi setiap kali, dan setiap putaran itu memotong biaya ekspedisi untukmu, sementara yang kamu lihat hanya “sedang dikirim”.

Lebih dalam lagi, dampak tersembunyi tersimpan di lapisan pencatatan biaya. Model akuntansi Newton saat ini tidak membedakan “pengurangan yang menghasilkan evaluasi yang valid” dan “pengurangan yang gagal dialokasikan”. Dua jenis biaya ini digolongkan menjadi satu dalam laporan pendapatan, semuanya dianggap sebagai “pendapatan biaya jaringan”, dan masuk ke dalam kumpulan pendapatan Operator serta pemegang koin. Apabila Intent terjebak dalam loop tak berujung karena sejumlah besar Operator di seluruh jaringan offline, jaringan tidak hanya gagal menyelesaikan layanan, tetapi justru menjadi satu-satunya pihak yang diuntungkan. Ini sama saja dengan sifat pemotongan berulang akibat gangguan sistem di keuangan tradisional oleh bank; bedanya, di rantai tidak ada layanan pelanggan untuk mengajukan banding, hanya ada kode yang menjadi aturan.$BTC

Jalur perbaikannya sebenarnya tidak rumit. Cukup atur di konfigurasi Gateway sebuah batas maksimum percobaan ulang default (misalnya 3 kali), dan pada setiap kali retry menulis field retryCount ke dalam event status Intent; maka front-end bisa menampilkan “Sedang retry (2/3)”. Ini tidak perlu mengubah lapisan konsensus—hanya penyesuaian pada parameter default dan pelengkapan logika yang terlihat. Namun, sejak seruan komunitas, perubahan ini sudah melampaui dua siklus pembaruan, tapi hingga kini belum juga diterapkan. Apakah kesulitan teknis terlalu tinggi, atau apakah pendapatan dari fee evaluasi akibat infinite retry ternyata jauh lebih penting bagi sistem daripada yang dibayangkan? Sebagai pemegang NEWT, tanda tanya ini tidak seharusnya dibiarkan berada di luar logika yang bullish.#Newt $NEWT @NewtonProtocol