Saya menyaksikan sebuah transaksi tertahan tanpa dipancarkan selama hampir satu menit minggu ini, dan hampir mengabaikannya.
Saya telah mengonfigurasi sebuah kebijakan yang hanya mengizinkan eksekusi ketika gas Ethereum turun di bawah ambang batas tertentu. Saat itu, harga gas sedang tinggi, jadi melihat transaksi menunggu tidak mengejutkan saya. Ketika jaringan mereda dan transaksi akhirnya berjalan, saya menutup tab dengan pikiran semuanya telah berperilaku persis seperti yang diharapkan.
Lalu ada transaksi lain yang menarik perhatian saya.
Itu digerakkan oleh sumber data gas yang sama, namun alih-alih menunggu biaya yang lebih murah, transaksi itu dipancarkan ulang dengan harga gas baru setelah kondisi berubah. Awalnya, saya mengira ada sesuatu yang tidak konsisten. Kedua kebijakan membaca umpan gas yang sama, jadi mengapa mereka bereaksi secara berbeda?
Jawabannya bukan pada oracle. Jawabannya ada pada kebijakannya (policy).
Saya sudah memperlakukan ambang batas gas seolah-olah selalu menghasilkan satu hasil yang bisa diprediksi: tunggu sampai gas cukup murah, lalu jalankan. Tetapi setelah menggali dokumentasi Newton, saya menyadari saya telah menyatukan beberapa perilaku berbeda ke dalam satu model mental.
Kebijakan ambang batas dapat dengan sederhana menunda eksekusi sampai gas turun di bawah level yang dipilih. Ia bisa memblokir transaksi sepenuhnya selama kemacetan berat. Atau ia bisa menyerahkan kendali kepada agen cerdas yang terus-menerus menghitung ulang harga (repricing) dan menyiarkan ulang transaksi saat kondisi jaringan berubah.
Umpan gas tidak pernah berubah. Respons terhadap umpan itulah yang berubah.
Itu mengubah cara saya memikirkan desain kebijakan.
Etherscan Gas Tracker memberikan informasi yang sama kepada setiap kebijakan yang menggunakannya. Setiap brankas (vault), agen, atau workflow dapat membaca harga gas dan sinyal kemacetan yang identik. Namun, masukan yang identik tidak menjamin hasil yang identik. Setiap kebijakan memutuskan apa arti angka-angka itu sebenarnya.
Dari luar, dua transaksi yang berperilaku berbeda di bawah kondisi pasar yang sama bisa terlihat seperti sebuah bug. Nyatanya, mereka sering kali mengikuti seperangkat aturan yang benar-benar berbeda.
Setelah saya menelusuri prosesnya dari ujung ke ujung, semuanya menjadi jauh lebih jelas.
Data gas dikumpulkan di luar rantai (off-chain), diverifikasi oleh jaringan operator Newton, lalu diubah menjadi data point yang terattest (terverifikasi) yang dapat dipercaya oleh kebijakan. Setelah itu, tanggung jawab oracle selesai. Apakah transaksi menunggu, ditolak, atau secara otomatis dihitung ulang harganya (repriced) ditentukan sepenuhnya oleh logika kebijakan yang dibangun di atas attestation tersebut.
Perbedaan itu terasa kecil di atas kertas, tetapi penting dalam praktik.
Bagian yang paling menarik bagi saya adalah agen repricing.
Jika sebuah agen diizinkan menyiarkan ulang transaksi saat gas bergerak, ia juga perlu memiliki strategi sendiri. Seberapa sering ia harus mencoba lagi? Seberapa tinggi seharusnya penawaran (bid) ditingkatkan setiap kali? Kapan ia harus berhenti mengejar pasar? Keputusan-keputusan itu tidak disediakan oleh oracle—keputusan itu berada di lapisan otomatisasi yang lain.
Oracle melaporkan realitas.
Kebijakan memutuskan apa yang harus dilakukan dengan itu.
Agen memutuskan seberapa agresif untuk bertindak.
Pemisahan itu mudah diabaikan sampai saya melihat dua transaksi bereaksi berbeda terhadap data yang sama.
Itu mengingatkan saya pada sebuah kesalahan yang saya buat dalam trading saya sendiri minggu ini. Saya mengira saya telah membuat stop-loss yang sederhana, tetapi saya lupa bahwa saya juga mengaktifkan aturan re-entry. Alih-alih keluar dan tetap keluar, posisi itu diam-diam terbuka lagi saat saya fokus ke hal lain. Masalahnya bukan di pasar. Masalahnya adalah saya menumpuk dua bagian logika yang saling independen tanpa memikirkan bagaimana keduanya akan berinteraksi.
Melihat kebijakan Newton lewat sudut pandang itu membuat desainnya menjadi jelas bagi saya.
Semakin banyak saya mengeksplorasi programmable compliance dan eksekusi otomatis, semakin saya tidak menganggap bahwa masalah tersulit ada pada pengumpulan data yang lebih baik. Masalahnya adalah membuat perilaku yang dibangun di atas data itu dapat diprediksi, dapat dipahami, dan mudah untuk dianalisis.
Satu pertanyaan masih terus melekat pada saya.
Selama periode kemacetan ekstrem, ketika harga gas berubah setiap beberapa detik, bisakah agen yang menyiarkan ulang (rebroadcast) dan menghitung ulang harga (reprice) akhirnya mengejar pasar begitu agresif hingga menghabiskan lebih banyak untuk percobaan berulang daripada biaya yang akan dikeluarkan kebijakan sederhana “tunggu sampai murah”? Oracle dapat memberi tahu Anda di mana gas berada. Memutuskan apakah mengejar itu sepadan adalah masalah yang benar-benar berbeda.
@NewtonProtocol #NEWT #Newt $NEWT
