"Saat ini, x402 hanyalah "loli" 😅 di jalur pembayaran Saya telah mengalami x402 dalam beberapa hari terakhir, dari sudut pandang seorang insinyur, masih banyak ruang untuk perbaikan dalam hal ini, dan akan ada beberapa masalah yang menghambat pengembangan x402 secara keseluruhan. Jika mereka tidak dapat diselesaikan, saya pikir mereka hanya dapat bertahan dalam tahap konsep dan tidak dapat diterapkan dalam skala besar. 1. Kompleksitas ⚙️ penyematan teknik x402 menyediakan SDK pengambilan dan beberapa middleware HTTP untuk mengimplementasikan fungsi pembayaran ini. Tetapi paket fetch sebenarnya adalah paket khusus, jika Anda perlu menggunakannya, maka dalam kode Anda hanya dapat menggunakan fetch mereka untuk mengakses dengan mudah, jika tidak, Anda perlu menyelesaikan logika akses yang sangat kompleks secara manual. Pada saat yang sama, akses middleware diprioritaskan, meskipun sudah mendukung kerangka kerja arus utama, tetapi masih perlu diasah. Tentu saja, ini adalah masalah terkecil, dan dengan perkembangan ekosistem, masalah ini adalah hal-hal kecil. 2. Tidak ada perubahan 🧩 penting yang terjadi Meskipun kode status 402 terdengar menggertak dan mengagumkan, sebenarnya tidak masalah apa yang dikembalikannya sama sekali, itu dapat mengembalikan 402, 200 dengan json, atau apa pun dan banyak data. Pada dasarnya, ini hanya enkapsulasi teknik yang menambahkan proses pembayaran. 3. Tidak dapat diandalkan ⏱️ di bawah panggilan frekuensi tinggi Dalam kasus artikel kedua, masalah akan muncul, yang disebut masalah frekuensi tinggi. Kita tahu bahwa konsep arus utama saat ini adalah bahwa AI Agent memanggil API untuk mendapatkan data atau konten lainnya, tetapi dengan penambahan logika pembayaran ini, seluruh proses menjadi sangat panjang. Permintaan frekuensi rendah Agen AI tidak apa-apa (karena Agen sudah lambat membuat permintaan...... Setelah memasuki permintaan frekuensi tinggi, waktu permintaan API akan berlipat ganda, dan permintaan API dapat diperpanjang hingga 3 hingga 10 kali lipat dari aslinya (pengujian resmi adalah bahwa setiap permintaan ditunda 2 detik, tetapi saya pikir itu adalah data optimis). Jika saya perlu mendapatkan banyak data, waktu seluruh proses sangat menghancurkan. Karena jumlah permintaan meningkat, dan Anda juga perlu menunggu konfirmasi transaksi on-chain dan penundaan RPC, API frekuensi tinggi pada dasarnya tidak dapat memilih mode x402 saat ini (tentu saja, dapat dimodifikasi di masa mendatang). 4. Proses 🔁 yang sangat tidak sempurna Sebagai protokol berorientasi pembayaran, saya sama sekali tidak melihat ketelitian produk ini sebagai middleware keuangan. Saya tidak tahu bagaimana dia menangani permintaan aktual setelah pembayaran karena fluktuasi jaringan, dan saya tidak melihat hubungan yang mengikat antara permintaan API dan catatan transaksi. Dalam kasus tradisional Web2, pembayaran tidak hanya memiliki metode panggilan balik (setelah pembayaran selesai, pembayaran akan diarahkan ke halaman yang ditunjuk pedagang), tetapi juga permintaan ulang berkala (jika panggilan balik tidak dieksekusi, itu akan menjadi 3 detik, 5 detik, 1 menit,。。。 tunggu beberapa waktu untuk mencoba melakukan re-callback hingga berhasil mencegah transaksi hilang). Saya tidak melihatnya sama sekali di x402. Ini seperti Anda seorang pedagang kecil di warung pinggir jalan dan membeli sesuatu di supermarket. Anda membeli sesuatu di kios, tidak ada faktur, tidak ada informasi produk, tidak ada jumlah, dan ketika Anda pulang, Anda menemukan bahwa barang-barang yang Anda beli sudah busuk, dan Anda hanya ingin membela hak Anda dan mencari tahu, hei, kios ini sudah melarikan diri. Tetapi ketika Anda membeli sesuatu di supermarket, setidaknya ada yang fisik, ada faktur, ada pemantauan, dan jika Anda bertemu dengan Donglai yang gemuk, Anda bahkan dapat menikmati pengembalian dana tanpa syarat. x402 sebagai produk B-end, sekarang benda ini sama sekali tidak memenuhi syarat dan tidak bertanggung jawab. 5. Hampir tidak ada proses ⚖️ regulasi Saya tahu banyak orang berpikir bahwa tidak ada pengawasan adalah hal yang baik, yang disebut desentralisasi, yang dibayarkan adalah tidak ada KYC dan tidak ada pengawasan, kita tidak akan berbicara tentang seringnya terjadinya insiden keamanan yang disebabkan oleh penerapan teknologi baru di sini, mari kita bicara tentang apa yang disebut penyedia API, jika karena berbagai masalah, memberikan data yang tidak sesuai, atau karena jumlah permintaan terlalu besar, mengakibatkan kesalahan dalam permintaan tertentu dari pedagang, atau serangkaian permintaan salah, tetapi Anda telah membayar, bagaimana Anda mengembalikan uang pertanyaan. Saya tidak melihat mekanisme yang relevan saat ini, yaitu, jika suatu hari Anda tidak beruntung dan terjebak di jaringan setelah membayar, atau mereka macet di jaringan, atau mereka macet di layanan, atau Anda menyegarkannya, maka selamat, pembayaran Anda tidak valid. Kemudian Anda mencari cara mengembalikan dana, dan setelah banyak melihat-lihat, Anda menemukan bahwa hehe, tidak ada, tidak ada yang bertanggung jawab atas perilaku pembayaran ini, paling banyak Anda pergi ke penyedia, mengatakan bahwa Anda telah membayar, tetapi tidak menyediakan layanan, dan kemudian memainkan bola selama berbulan-bulan. Jika Anda tidak beruntung, penyedia layanan tidak memiliki pemantauan yang cukup untuk kode tersebut, dan mereka bahkan tidak akan dapat menemukan catatan permintaan Anda.

@taowang1 @Cloudflare Nama salah eja murah