Log Peristiwa

Apa Itu Log Peristiwa dalam Kripto?

Log peristiwa adalah catatan terstruktur yang dibuat smart contract selama eksekusi transaksi blockchain.

Log ini memungkinkan smart contract memublikasikan informasi yang dapat ditemukan dan diproses oleh wallet, aplikasi terdesentralisasi, blockchain explorer, platform analitik, dan sistem off-chain lainnya.

Di Ethereum dan jaringan berbasis EVM lainnya, developer biasanya membuat log peristiwa dengan mendeklarasikan event Solidity dan menggunakan keyword emit ketika tindakan terkait terjadi.

Misalnya, kontrak token dapat menghasilkan event saat token ditransfer, di-mint, di-burn, atau disetujui untuk digunakan.

Protokol keuangan terdesentralisasi dapat menghasilkan log saat pengguna menyetor agunan, meminjam kripto, melunasi utang, menerima reward, atau menutup posisi.

Dokumentasi Solidity tentang event menjelaskan bahwa event merupakan abstraksi yang dibangun di atas fungsi logging EVM.

Log peristiwa biasanya tidak mengendalikan status kontrak atau menjalankan logika bisnis tambahan setelah dibuat.

Sebaliknya, log peristiwa menyediakan catatan yang efisien untuk membantu perangkat lunak eksternal memahami apa yang terjadi selama transaksi.

Hal ini menjadikan log peristiwa penghubung penting antara smart contract on-chain dan aplikasi off-chain yang menampilkan aktivitas blockchain kepada pengguna.

Bagaimana Log Peristiwa Bekerja

Log peristiwa dibuat saat Ethereum Virtual Machine memproses jalur eksekusi yang berhasil di dalam suatu transaksi.

Smart contract terlebih dahulu mendeklarasikan event dengan nama dan daftar parameter.

Kontrak kemudian menghasilkan event tersebut ketika kodenya mencapai instruksi terkait.

Compiler Solidity mengubah penerbitan event menjadi salah satu operasi logging EVM.

Log yang dihasilkan berisi alamat kontrak yang menerbitkannya, daftar topic yang dapat ditelusuri, dan field data yang memuat informasi tambahan yang dienkode.

Log menjadi bagian dari tanda terima transaksi setelah transaksi dimasukkan ke dalam blok.

Aplikasi dapat mengambil log melalui node Ethereum, penyedia RPC, blockchain explorer, atau blockchain indexer khusus.

Panduan Ethereum tentang pencatatan event smart contract menjelaskan bahwa aplikasi terdesentralisasi dapat memantau event yang diterbitkan dan mengambil tindakan off-chain ketika event tersebut muncul.

Jika transaksi di-revert, log yang dibuat dalam eksekusi yang di-revert juga dihapus dari hasil akhir transaksi.

Artinya, log yang terlihat selama simulasi atau execution trace mungkin tidak muncul dalam tanda terima yang dikonfirmasi jika seluruh pemanggilan gagal.

Event vs. Log Peristiwa

Event adalah deklarasi yang ditentukan developer untuk menjelaskan informasi yang dapat dipublikasikan kontrak.

Log peristiwa adalah catatan aktual yang dibuat saat kontrak menerbitkan event tersebut selama transaksi.

Misalnya, kontrak dapat mendefinisikan event Transfer dalam kode sumbernya.

Setiap transfer yang selesai dapat menghasilkan log tersendiri berdasarkan definisi event tersebut.

Event berfungsi seperti templat, sedangkan setiap log adalah satu kejadian yang tercatat berdasarkan templat itu.

Satu transaksi dapat menghasilkan nol, satu, atau banyak log.

Transaksi yang berinteraksi dengan beberapa smart contract dapat menghasilkan log dari setiap kontrak yang terlibat dalam eksekusi.

Aplikasi menggunakan Application Binary Interface kontrak, atau ABI, untuk mencocokkan log mentah dengan deklarasi event dan mendekode nilainya.

Informasi Apa yang Tersimpan dalam Log Peristiwa?

Log event EVM berisi alamat kontrak yang menerbitkannya, nol hingga empat topic, dan field data dengan panjang yang bervariasi.

Alamat penerbit mengidentifikasi kontrak yang eksekusinya menghasilkan log tersebut.

Topic berisi nilai yang dirancang agar dapat difilter dan ditelusuri secara efisien.

Field data menyimpan parameter event yang tidak ditandai sebagai indexed.

Metadata transaksi dan blok juga dikembalikan bersama log melalui antarmuka RPC yang umum.

Metadata tersebut dapat mencakup hash transaksi, indeks transaksi, hash blok, nomor blok, dan indeks log.

Indeks log mengidentifikasi posisi log di antara log lain dalam blok yang sama.

Aplikasi umumnya sebaiknya menggunakan kombinasi chain ID, hash blok, hash transaksi, dan indeks log saat membuat pengenal catatan unik.

Nama event atau hash transaksi saja mungkin tidak cukup karena satu transaksi dapat menerbitkan event yang sama beberapa kali.

Apa Itu Topic Event?

Topic adalah nilai 32-byte yang ditempatkan di bagian log EVM yang dapat ditelusuri secara khusus.

Topic memungkinkan aplikasi memfilter riwayat blockchain tanpa perlu mendekode setiap field data event satu per satu.

Event Solidity non-anonim standar dapat menggunakan hingga empat topic.

Topic pertama biasanya mengidentifikasi jenis event, sedangkan hingga tiga topic tambahan mewakili parameter yang ditandai sebagai indexed.

Urutan topic berpengaruh, sehingga memfilter nilai di posisi topic kedua berbeda dengan memfilter nilai yang sama di posisi topic ketiga.

Dokumentasi resmi Ethereum JSON-RPC untuk eth_getLogs menjelaskan bahwa filter topic bergantung pada urutan dan dapat mencakup nilai alternatif untuk posisi yang sama.

Topic sangat berguna untuk mencari event yang terkait dengan alamat wallet, ID token, pasar, proposal, atau nilai lain yang sering ditanyakan.

Pemilihan parameter indexed yang kurang tepat dapat membuat data historis aplikasi sulit atau mahal untuk ditelusuri.

Apa Itu Topic 0?

Topic 0 biasanya berisi hash Keccak-256 dari signature event kanonis.

Signature kanonis menggabungkan nama event dengan jenis parameter dalam urutan tertentu.

Nama parameter dan keyword indexed tidak disertakan dalam hash signature event.

Misalnya, event bernama Transfer dengan jenis parameter address, address, dan uint256 memiliki signature event yang dapat ditentukan.

Aplikasi dapat membandingkan topic 0 dengan hash signature yang diketahui untuk mengidentifikasi event yang direpresentasikan oleh log mentah.

Mengubah nama event, urutan parameter, atau jenis parameternya akan menghasilkan signature event yang berbeda.

Karena itu, dua event dengan nama sama tetapi jenis parameter berbeda memiliki nilai topic 0 yang berbeda.

Spesifikasi ABI Solidity untuk event menjelaskan cara signature event dan argumennya dienkode ke dalam topic dan data.

Parameter Event Indexed

Parameter indexed adalah argumen event yang disimpan dalam topic agar sistem eksternal dapat memfilternya secara efisien.

Solidity mengizinkan hingga tiga parameter indexed dalam event non-anonim biasa.

Posisi topic yang tersisa digunakan untuk signature event.

Address, integer, nilai Boolean, dan nilai lain yang muat dalam satu word 32-byte dapat disimpan langsung dalam topic menggunakan encoding yang kompatibel dengan ABI.

Nilai dinamis seperti string, array byte, array dinamis, dan struktur kompleks diperlakukan secara berbeda.

Jika nilai dinamis diindeks, topic menyimpan hash Keccak-256 dari nilai yang dienkode, bukan nilai asli yang dapat dibaca.

Aplikasi dapat memfilter berdasarkan hash tersebut jika sudah mengetahui nilai yang ingin ditemukan.

Namun, aplikasi tidak dapat memperoleh kembali string atau array byte asli yang tidak diketahui hanya dari hash tersebut.

Developer terkadang menyertakan informasi yang sama dua kali, yaitu versi hash dalam parameter indexed dan versi yang dapat dibaca dalam parameter non-indexed.

Desain ini meningkatkan kemudahan pencarian sekaligus mempertahankan nilai asli untuk didekode.

Parameter Event Non-Indexed

Parameter tanpa keyword indexed disimpan di field data log.

Nilai ini dienkode sesuai aturan ABI Ethereum.

ABI diperlukan karena data log mentah tidak memberi label nama dan jenis yang mudah dibaca pada setiap nilai.

Aplikasi memerlukan definisi event yang benar agar dapat mendekode data dengan andal.

Parameter non-indexed dapat memuat nilai yang lebih besar atau kompleks daripada topic individual.

Parameter ini sesuai untuk jumlah, nilai konfigurasi terperinci, array, string, dan informasi lain yang tidak perlu difilter langsung melalui topic.

Aplikasi biasanya tidak dapat meminta eth_getLogs untuk memfilter nilai arbitrer di dalam field data.

Aplikasi harus mengambil log terlebih dahulu menggunakan alamat kontrak dan topic, lalu mendekode dan memeriksa datanya secara lokal.

Event Anonim

Event Solidity dapat dideklarasikan sebagai anonymous.

Event anonim tidak secara otomatis menempatkan hash signature event-nya di topic 0.

Hal ini memungkinkan keempat posisi topic digunakan untuk parameter indexed.

Namun, penghapusan topic signature membuat perangkat lunak eksternal lebih sulit mengidentifikasi jenis event secara otomatis.

Event anonim yang berbeda dapat sulit dibedakan jika struktur topic dan datanya serupa.

Event anonim dapat sesuai untuk desain tingkat rendah tertentu, tetapi event aplikasi biasa umumnya lebih mudah diindeks dan didekode jika tidak anonim.

Developer sebaiknya menggunakan event anonim hanya jika tambahan topic indexed memberikan manfaat jelas yang lebih besar daripada berkurangnya kemudahan identifikasi event.

Opcode Logging EVM

EVM menyediakan lima opcode logging bernama LOG0 hingga LOG4.

Angka dalam nama setiap opcode menunjukkan jumlah topic yang disertakan dalam log.

LOG0 membuat log tanpa topic, sedangkan LOG4 membuat log dengan empat topic.

Setiap operasi logging juga membaca rentang memori EVM tertentu dan menyimpannya sebagai field data log.

Event Solidity dikompilasi menjadi instruksi logging tingkat rendah ini.

Alamat kontrak ditambahkan ke log oleh lingkungan eksekusi, bukan diberikan sebagai parameter event biasa.

Operasi logging menggunakan gas berdasarkan faktor seperti jumlah topic dan banyaknya data yang dicatat.

Referensi opcode Ethereum mencantumkan instruksi logging EVM dan biaya eksekusinya.

Log Peristiwa dan Tanda Terima Transaksi

Tanda terima transaksi adalah catatan eksekusi yang dihasilkan setelah transaksi dimasukkan ke dalam blok.

Tanda terima memuat informasi seperti status eksekusi, penggunaan gas kumulatif, bloom log, dan log yang diterbitkan oleh transaksi.

Respons RPC dapat menambahkan field berguna lainnya seperti alamat pembuatan kontrak, harga gas efektif, dan gas yang digunakan oleh transaksi tersebut.

Array log mempertahankan urutan penerbitan event selama eksekusi.

Transaksi yang berhasil dapat memiliki array log kosong jika tidak ada kontrak yang menerbitkan event.

Transaksi yang gagal biasanya tidak memiliki log peristiwa yang bertahan karena perubahan status dan log-nya di-revert.

Aplikasi sebaiknya memeriksa status tanda terima, bukan menganggap keberadaan hash transaksi sebagai bukti bahwa eksekusi berhasil.

Metode JSON-RPC Ethereum untuk tanda terima transaksi menjelaskan field tanda terima yang dikembalikan execution client.

Log Peristiwa dan Tanda Terima Blok

Tanda terima transaksi terikat secara kriptografis melalui receipts root blok.

Komitmen ini memungkinkan peserta blockchain memverifikasi bahwa tanda terima termasuk dalam riwayat blok tertentu.

Setiap tanda terima memuat log yang dihasilkan transaksinya.

Header blok juga menyertakan bloom filter yang merangkum alamat log dan topic dari transaksi dalam blok tersebut berdasarkan format blok eksekusi saat ini.

Bloom filter membantu client menentukan apakah suatu blok mungkin berisi log yang cocok dengan kueri.

Kecocokan bloom positif tidak membuktikan bahwa log yang cocok benar-benar ada karena bloom filter dapat menghasilkan false positive.

Kecocokan negatif menunjukkan bahwa alamat atau topic yang dicari tidak muncul dalam bloom tersebut.

Aplikasi tetap memerlukan log tanda terima yang sebenarnya untuk mengonfirmasi nilai event secara tepat.

Log Peristiwa vs. Storage Kontrak

Log peristiwa dan storage smart contract memiliki fungsi yang berbeda.

Storage kontrak memuat data persisten yang dapat dibaca langsung oleh eksekusi smart contract di masa mendatang.

Log peristiwa terutama dirancang untuk pengamatan eksternal dan pengindeksan historis.

Kontrak Solidity tidak dapat membaca langsung log peristiwa historis, termasuk log yang diterbitkan kontrak itu sendiri.

Referensi event Solidity menyatakan bahwa data log dan event tidak dapat diakses dari dalam kontrak.

Kontrak tidak boleh mengandalkan event sebelumnya sebagai satu-satunya sumber data yang diperlukan untuk keputusan on-chain di masa mendatang.

Jika logika kontrak di masa mendatang memerlukan suatu nilai, nilai tersebut biasanya perlu disimpan dalam status kontrak atau diberikan melalui mekanisme yang dapat diverifikasi.

Log umumnya lebih murah daripada storage persisten untuk informasi yang hanya ditujukan bagi pengguna off-chain.

Namun, penggunaan log alih-alih storage mengubah hal-hal yang dapat diverifikasi atau diambil oleh smart contract di kemudian hari.

Log Peristiwa vs. Data Return Fungsi

Data return fungsi dikirim kembali kepada pemanggil langsung selama eksekusi kontrak.

Log peristiwa disimpan dalam tanda terima transaksi agar dapat diambil kemudian secara off-chain.

Transaksi yang mengubah status tidak memberikan data return kepada antarmuka pengguna dalam format historis yang semudah log peristiwa.

Aplikasi sering mengandalkan tanda terima dan event untuk mengetahui hasil transaksi yang dikirim.

Pemanggilan hanya-baca dapat mengembalikan nilai tanpa membuat log peristiwa atau mengubah status blockchain.

Developer sebaiknya menggunakan nilai return untuk komunikasi langsung dalam pemanggilan kontrak dan event untuk notifikasi off-chain yang tersimpan.

Event tidak boleh dianggap sebagai respons fungsi langsung karena beberapa kontrak dapat menerbitkan log selama satu transaksi.

Cara Aplikasi Mengueri Log Peristiwa

Aplikasi biasanya mengueri log peristiwa historis melalui metode JSON-RPC eth_getLogs.

Kueri dapat menentukan blok awal, blok akhir, alamat kontrak, hash blok, dan filter topic.

Metode ini mengembalikan array yang berisi log yang sesuai dengan filter.

Kueri yang lebih spesifik biasanya lebih andal dan efisien daripada meminta semua log dalam rentang blok yang sangat besar.

Penyedia RPC dapat menetapkan batas rentang blok, ukuran respons, waktu permintaan, atau frekuensi kueri.

Aplikasi sebaiknya membagi pencarian historis yang besar menjadi rentang blok yang lebih kecil dan menyimpan progresnya.

Aplikasi juga sebaiknya mencoba kembali permintaan yang gagal dengan jeda terkontrol, bukan menganggap respons kosong atau gagal sebagai bukti bahwa event tidak ada.

Penggunaan filter blockHash yang ditetapkan oleh EIP-234 dapat membantu aplikasi meminta log dari satu blok tertentu.

Polling dan Subscription Event

Aplikasi dapat menemukan log peristiwa baru melalui polling atau subscription.

Polling berulang kali meminta log atau perubahan filter dari node dari waktu ke waktu.

Subscription mempertahankan koneksi aktif agar node dapat mengirim notifikasi log baru saat blok tiba.

Subscription dapat memberikan pembaruan lebih cepat, tetapi koneksinya dapat terputus atau melewatkan informasi saat terjadi gangguan.

Polling dapat lebih mudah dipulihkan karena aplikasi dapat meminta kembali rentang blok yang sudah diketahui.

Sistem produksi yang tangguh sering menggabungkan subscription langsung dengan rekonsiliasi berkala berbasis blok.

Pendekatan ini memungkinkan aplikasi mendeteksi log yang terlewat saat terjadi gangguan jaringan atau node dimulai ulang.

Dokumentasi API JSON-RPC Ethereum menjelaskan metode filter untuk mengambil log yang muncul sejak polling sebelumnya.

Log Peristiwa dan Reorganisasi Chain

Reorganisasi chain terjadi ketika blok yang sebelumnya dianggap bagian dari chain aktif digantikan oleh riwayat blok yang berbeda.

Log dari blok yang digantikan tidak lagi menjadi bagian dari blockchain kanonis.

Aplikasi yang langsung bertindak berdasarkan log tersebut mungkin perlu membatalkan perubahan di basis data lokalnya.

Beberapa respons subscription RPC dapat menunjukkan bahwa log yang sebelumnya dilaporkan telah dihapus akibat reorganisasi.

Namun, gangguan jaringan dapat mencegah aplikasi menerima notifikasi penghapusan tersebut.

Indexer yang andal melacak hash blok dan hubungan parent agar dapat mendeteksi blok pengganti secara mandiri.

Penjelasan di balik pemfilteran log berbasis hash blok menjelaskan mengapa aplikasi harus menangani reorganisasi dan gangguan koneksi dengan cermat.

Sistem keuangan biasanya sebaiknya menunggu jumlah konfirmasi atau ambang finalitas yang sesuai sebelum menganggap event tidak dapat dibatalkan.

Ambang yang diperlukan bergantung pada chain, nilai aplikasi, dan konsekuensi jika bertindak terlalu dini.

Log Peristiwa dan Finalitas

Event yang baru diterbitkan dapat muncul dalam blok usulan sebelum blok tersebut mencapai finalitas konsensus yang lebih kuat.

Aplikasi dapat mengueri log menggunakan tag blok seperti latest, safe, atau finalized jika didukung client yang terhubung.

Tag latest memberikan informasi lebih cepat, tetapi dapat mencakup blok dengan risiko reorganisasi yang lebih tinggi.

Tag finalized memberikan keyakinan lebih kuat, tetapi membutuhkan waktu tambahan.

Antarmuka portofolio dapat menampilkan event latest, sedangkan bridge atau transfer keuangan bernilai besar mungkin memerlukan konfirmasi yang lebih kuat.

Aplikasi sebaiknya memilih kebijakan konfirmasi berdasarkan risiko ekonomi, bukan menggunakan satu aturan untuk semua event.

Log Peristiwa dalam Kontrak Token

Standar token menggunakan log peristiwa agar transfer dan persetujuan dapat dilihat oleh wallet dan sistem data blockchain.

Token fungibel biasanya menerbitkan event Transfer saat nilai berpindah ant alamat.

Token juga dapat menerbitkan event Approval saat pemilik mengubah allowance penggunaan untuk alamat lain.

Kontrak NFT biasanya menerbitkan event transfer dan persetujuan yang memuat pengenal token.

Kontrak multi-token dapat menerbitkan event transfer tunggal dan transfer batch.

Struktur event terstandar memungkinkan alat eksternal mendukung banyak kontrak token dengan logika decoding yang sama.

Namun, token dapat menerbitkan event yang menyesatkan atau tidak mengikuti standar dengan benar.

Event saja tidak membuktikan bahwa kontrak sah, bernilai, atau aman.

Log Peristiwa dalam Keuangan Terdesentralisasi

Protokol keuangan terdesentralisasi menggunakan log peristiwa untuk menjelaskan tindakan keuangan yang kompleks.

Contoh umum mencakup deposit, penarikan, swap, pinjaman, pelunasan, likuidasi, pembaruan bunga, klaim reward, dan perubahan tata kelola.

Antarmuka pengguna dapat memantau event ini untuk memperbarui saldo dan riwayat transaksi.

Sistem analitik dapat mengagregasikannya untuk menghitung volume, likuiditas, aktivitas pinjaman, atau pendapatan protokol.

Layanan pemantauan risiko dapat mengawasi event likuidasi atau agunan untuk mendeteksi posisi yang tertekan.

Karena satu transaksi DeFi dapat memanggil beberapa kontrak, tanda terimanya dapat berisi banyak log terkait.

Aplikasi harus memperhatikan alamat penerbit dan urutan log, bukan mendekode setiap signature event yang familier seolah-olah berasal dari kontrak protokol utama.

Log Peristiwa dalam Wallet dan Blockchain Explorer

Wallet menggunakan log peristiwa untuk membuat riwayat yang mudah dibaca dari transaksi smart contract mentah.

Transfer token mungkin tidak muncul sebagai perpindahan aset native langsung dalam field dasar transaksi.

Wallet dapat mendekode event Transfer dari kontrak token untuk menampilkan aset, pengirim, penerima, dan jumlahnya.

Blockchain explorer juga mendekode log menggunakan ABI kontrak yang terverifikasi dan signature event yang diketahui.

Jika informasi kode sumber atau ABI tidak tersedia, explorer dapat menampilkan nilai topic dan data mentah.

Label hasil decoding sebaiknya dipandang sebagai interpretasi atas log mentah, bukan jaminan independen mengenai maksud kontrak.

Pengguna sebaiknya memverifikasi alamat kontrak penerbit sebelum memercayai deskripsi event.

Log Peristiwa dan Blockchain Indexer

Blockchain indexer membaca blok dan tanda terima, lalu menyimpan data event terpilih dalam basis data yang mudah dikueri.

Indexer memudahkan pencarian jawaban atas pertanyaan yang sulit ditangani melalui permintaan RPC langsung.

Contohnya mencakup mengambil setiap transfer token untuk suatu wallet, menghitung aktivitas protokol dari waktu ke waktu, atau melacak semua posisi yang dibuka di pasar pinjaman.

Indexer biasanya dimulai dari blok yang dipilih dan memproses blok baru secara berurutan.

Indexer mendekode log terkait, membuat catatan basis data, dan menyimpan informasi blok yang diperlukan untuk menangani reorganisasi.

Indexer sebaiknya dapat melanjutkan proses setelah crash tanpa melewatkan atau menggandakan event.

Indexer juga sebaiknya memproses ulang data historis ketika skema decoding atau logika aplikasi berubah.

Dokumentasi data dan analitik Ethereum menjelaskan cara sistem data blockchain menggunakan log, tanda terima, trace, dan informasi eksekusi lainnya.

Log Peristiwa dan Otomatisasi Off-Chain

Layanan off-chain dapat memantau log peristiwa dan memicu tindakan di luar blockchain.

Layanan dapat mengirim notifikasi setelah deposit, memperbarui basis data internal setelah trading, atau memulai alur kerja lain setelah voting tata kelola.

Log itu sendiri tidak memaksa layanan off-chain untuk bertindak.

Layanan harus tetap online, menerima event, memvalidasinya, dan menentukan tindakan yang akan dilakukan.

Otomatisasi off-chain sebaiknya memverifikasi chain ID, alamat kontrak, status blok, dan nilai yang telah didekode sebelum mengambil tindakan sensitif.

Otomatisasi juga sebaiknya bersifat idempoten, artinya pemrosesan event yang sama dua kali tidak menghasilkan duplikasi yang keliru.

Perlindungan ini penting karena percobaan ulang, koneksi ulang, dan reorganisasi dapat menyebabkan log yang sama teramati lebih dari sekali.

Bisakah Smart Contract Membaca Log Peristiwa?

Smart contract tidak dapat mencari log peristiwa historis secara langsung melalui eksekusi EVM biasa.

Log dirancang untuk aplikasi eksternal, bukan sebagai status yang dapat dibaca kontrak.

Kontrak yang memerlukan informasi dari event sebelumnya harus menerima informasi tersebut melalui mekanisme lain.

Mekanisme yang dapat digunakan mencakup storage kontrak, bukti kriptografis, oracle, atau protokol pesan lintas blockchain.

Kontrak harus memverifikasi bahwa informasi yang diberikan dapat dipercaya sebelum menggunakannya.

Keterbatasan ini mencegah smart contract menganggap respons RPC off-chain otomatis valid sebagai data on-chain.

Bisakah Log Peristiwa Diubah?

Log yang telah dikonfirmasi tidak dapat diedit secara terpisah dari transaksi dan blok yang menghasilkannya.

Perubahan pada log mengharuskan riwayat blockchain yang memuat tanda terima tersebut diganti atau tidak berlaku.

Reorganisasi chain dapat menghapus log dari riwayat aktif sebelum finalitas yang lebih kuat tercapai.

Transaksi baru dapat menerbitkan event koreksi atau pembalik, tetapi tidak menghapus log kanonis sebelumnya.

Aplikasi sebaiknya mempertahankan event historis dan mencatat koreksi sebagai entri baru, bukan diam-diam menulis ulang data blockchain asli.

Bisakah Log Peristiwa Dipalsukan?

Smart contract apa pun dapat mendefinisikan dan menerbitkan event dengan nama serta signature yang familier.

Karena itu, kontrak berbahaya dapat menerbitkan event Transfer yang terlihat mirip dengan event dari kontrak token yang sah.

Signature event saja tidak mengidentifikasi aset atau membuktikan bahwa perubahan saldo nyata terjadi di kontrak tepercaya.

Aplikasi harus memverifikasi alamat kontrak penerbit dan memahami kode serta status kontrak tersebut.

Token penipuan juga dapat menerbitkan nilai menyesatkan atau membuat event yang seolah-olah menunjukkan bahwa wallet yang tidak aktif menerima aset.

Wallet dan explorer sebaiknya tidak menganggap setiap signature event yang familier sama-sama tepercaya.

Pengguna sebaiknya tidak berinteraksi dengan token hanya karena transfer yang tidak terduga muncul dalam riwayat transaksi.

Log Peristiwa dan Keamanan Smart Contract

Desain event merupakan bagian dari keamanan smart contract karena sistem pemantauan bergantung pada log yang akurat.

Tindakan administratif penting sebaiknya menerbitkan event yang jelas saat izin, biaya, alamat oracle, implementasi upgrade, atau pengaturan darurat berubah.

Event yang tidak ada dapat membuat perubahan berbahaya lebih sulit dideteksi pengguna dan tim keamanan.

Nilai event yang keliru dapat menyebabkan sistem off-chain menampilkan hasil yang tidak sesuai dengan status kontrak.

Kontrak sebaiknya menerbitkan event hanya setelah pemeriksaan dan perubahan status terkait berhasil.

Developer sebaiknya menguji agar setiap jalur eksekusi penting menerbitkan log yang diharapkan tepat satu kali.

Developer juga sebaiknya menguji bahwa transaksi yang di-revert tidak menyisakan log akhir yang menyesatkan.

Event tidak boleh dianggap sebagai pengganti penerapan izin dan aturan saldo dalam kode kontrak.

Biaya Gas Log Peristiwa

Penerbitan event menggunakan gas karena EVM harus memproses instruksi logging dan menambahkan informasi ke tanda terima transaksi.

Jumlah topic dan ukuran field data yang lebih besar umumnya meningkatkan biaya logging.

Karena itu, event dengan beberapa nilai berukuran besar dapat lebih mahal daripada event minimal.

Log sering kali lebih murah daripada menyimpan informasi yang sama dalam storage kontrak persisten.

Namun, log yang tidak diperlukan tetap meningkatkan biaya transaksi pengguna dan ukuran riwayat blockchain.

Developer sebaiknya menerbitkan informasi yang benar-benar dibutuhkan untuk pengindeksan, pemantauan, audit, atau antarmuka pengguna.

Developer sebaiknya tidak menyalin setiap perhitungan internal ke event terpisah jika sistem eksternal tidak memerlukannya.

Optimasi gas tidak boleh menghilangkan transparansi penting yang diperlukan untuk memantau aktivitas protokol dengan aman.

Praktik Terbaik untuk Mendesain Event

Nama event sebaiknya menjelaskan tindakan yang terjadi dengan jelas.

Nama parameter sebaiknya cukup spesifik agar developer dan analis memahami maknanya.

Nilai yang sering dicari pengguna sebaiknya dipertimbangkan sebagai parameter indexed.

Nilai indexed yang umum mencakup alamat akun, ID token, ID pasar, dan ID proposal.

Jumlah dan nilai konfigurasi terperinci biasanya dapat tetap berada di field data jika tidak perlu difilter secara langsung.

Developer sebaiknya menghindari pengindeksan nilai dinamis kecuali pemfilteran berbasis hash memang berguna.

Setiap event sebaiknya memuat konteks yang cukup agar dapat ditafsirkan tanpa bergantung pada asumsi rapuh tentang urutan transaksi.

Kontrak yang mendukung beberapa aset atau pasar sebaiknya menyertakan pengenal aset atau pasar yang relevan.

Event upgrade sebaiknya mengidentifikasi nilai lama dan baru jika informasi tersebut membantu pemantauan.

Deklarasi event sebaiknya tetap stabil ketika aplikasi eksternal bergantung pada signature dan tata letak parameternya.

Praktik Terbaik untuk Membaca Log Peristiwa

Aplikasi sebaiknya memfilter berdasarkan alamat kontrak yang diharapkan serta signature event yang diharapkan.

Aplikasi sebaiknya mendekode log menggunakan versi ABI yang benar untuk implementasi kontrak yang aktif pada blok tersebut.

Kontrak yang dapat di-upgrade mungkin mengubah event yang tersedia setelah upgrade implementasi.

Indexer sebaiknya menyimpan hash blok, nomor blok, hash transaksi, indeks transaksi, dan indeks log.

Indexer sebaiknya memproses log sesuai urutan blok kanonis dan mendukung rollback setelah reorganisasi.

Kueri historis yang besar sebaiknya dibagi menjadi rentang blok yang dapat dikelola.

Aplikasi sebaiknya membedakan respons kosong yang valid dari permintaan yang gagal, terpotong, atau terkena pembatasan laju.

Tindakan keuangan sebaiknya menunggu tingkat konfirmasi yang sesuai dengan nilai dan risikonya.

Aplikasi sebaiknya membandingkan nilai yang diperoleh dari event dengan status kontrak ketika akurasi sangat penting.

Log Peristiwa di Jaringan Layer 2

Jaringan Layer 2 berbasis EVM umumnya menggunakan log peristiwa dengan struktur serupa log Ethereum.

Developer sering kali dapat menggunakan event Solidity, topic, ABI, dan kueri JSON-RPC yang familier.

Namun, sistem Layer 2 dapat memiliki waktu blok, aturan konfirmasi, sequencer, struktur biaya, dan proses penyelesaian akhir yang berbeda.

Log yang dikonfirmasi oleh sequencer Layer 2 mungkin belum mencapai status penyelesaian terkuat di Ethereum.

Event terkait bridge dapat muncul di jaringan sumber dan tujuan pada tahap transfer yang berbeda.

Aplikasi harus melacak chain yang benar dan tidak menganggap event dari jaringan yang terpisah sebagai satu riwayat log bersama.

Alamat kontrak atau signature event yang sama dapat merepresentasikan kontrak dan aset yang berbeda di chain yang berbeda.

Log Peristiwa dalam Transfer Lintas Blockchain

Sistem lintas blockchain sering menggunakan event untuk menandakan bahwa aset telah dikunci, di-burn, dilepas, atau di-mint.

Relayer off-chain atau protokol di chain tujuan dapat mengamati event di chain sumber sebelum melanjutkan proses transfer.

Tindakan di chain tujuan harus memverifikasi event sumber melalui sistem proof atau validator bridge.

Melihat log melalui penyedia RPC biasa saja tidak cukup bagi smart contract tanpa kepercayaan untuk membuktikan bahwa event tersebut valid.

Bridge juga harus memperhitungkan reorganisasi dan finalitas chain sumber.

Bridge yang bertindak terlalu cepat dapat memproses event yang kemudian dihapus dari riwayat sumber kanonis.

Pengguna sebaiknya memahami bahwa event bridge yang diterbitkan dapat menandai dimulainya transfer, bukan penyelesaian akhirnya.

Contoh Log Peristiwa

Misalkan pengguna mentransfer 500 unit token fungibel ke wallet lain.

Pengguna mengirim transaksi yang memanggil fungsi transfer pada kontrak token.

Kontrak memeriksa saldo pengirim lalu memperbarui saldo pengirim dan penerima.

Kontrak kemudian menerbitkan event Transfer yang memuat alamat pengirim, alamat penerima, dan jumlah yang ditransfer.

Alamat pengirim dan penerima dapat disimpan sebagai topic indexed, sedangkan jumlahnya dienkode dengan ABI di field data.

Hash signature event muncul di topic 0.

Setelah transaksi dimasukkan ke dalam blok, log muncul dalam tanda terima transaksi.

Wallet mengambil dan mendekode log tersebut untuk menampilkan perpindahan token dalam riwayat transaksi yang mudah dibaca.

Indexer juga mencatat event agar pengguna dapat mencari semua transfer yang melibatkan salah satu alamat.

Contoh ini menunjukkan bagaimana satu log peristiwa menghubungkan eksekusi kontrak dengan wallet, explorer, dan analitik blockchain.

Kesalahan Umum terkait Log Peristiwa

Salah satu kesalahan umum adalah menganggap event dapat dibaca oleh smart contract lain.

Kesalahan lainnya adalah menganggap signature event yang familier membuktikan bahwa kontrak penerbit sah.

Kesalahan ketiga adalah mendekode log tanpa memeriksa alamat kontraknya.

Kesalahan keempat adalah menganggap string indexed dapat diperoleh langsung dari hash topic-nya.

Kesalahan kelima adalah hanya menggunakan hash transaksi sebagai pengenal log.

Kesalahan keenam adalah tidak menangani reorganisasi chain.

Kesalahan ketujuh adalah memproses log yang sama dua kali setelah percobaan ulang RPC atau aplikasi dimulai ulang.

Kesalahan kedelapan adalah mengueri rentang blok yang sangat besar lalu menganggap permintaan yang timeout sebagai hasil kosong.

Kesalahan kesembilan adalah hanya mengandalkan event ketika logika smart contract di masa mendatang memerlukan data yang sama di storage.

Kesalahan kesepuluh adalah menganggap event yang berhasil didekode membuktikan bahwa semua perubahan status yang dimaksud telah terjadi dengan benar.

FAQ

Apa itu log peristiwa dalam kripto?

Log peristiwa adalah catatan terstruktur yang diterbitkan smart contract untuk menjelaskan tindakan yang terjadi selama eksekusi transaksi blockchain.

Di mana log peristiwa Ethereum disimpan?

Log peristiwa Ethereum disertakan dalam tanda terima transaksi, yang terikat sebagai bagian dari riwayat eksekusi blok.

Apa perbedaan event dan log?

Event adalah deklarasi dalam kode smart contract, sedangkan log adalah catatan aktual yang dibuat saat event tersebut diterbitkan.

Bisakah smart contract membaca log peristiwa lama?

Tidak. Smart contract tidak dapat mencari atau membaca log historis secara langsung melalui eksekusi EVM biasa.

Apa itu topic 0 dalam log peristiwa Ethereum?

Topic 0 biasanya berisi hash Keccak-256 dari nama event dan jenis parameter kanonisnya.

Berapa banyak topic yang dapat dimiliki log peristiwa?

Log EVM dapat memiliki hingga empat topic, dan event Solidity biasa biasanya menggunakan satu topic untuk signature event.

Apa arti indexed dalam event Solidity?

Parameter indexed disimpan dalam topic agar aplikasi eksternal dapat memfilter log berdasarkan nilai tersebut.

Bisakah string diindeks dalam log peristiwa?

Bisa, tetapi string indexed direpresentasikan sebagai hash Keccak-256, bukan string asli yang dapat dibaca.

Apa yang terjadi pada log peristiwa ketika transaksi di-revert?

Log yang dihasilkan dalam eksekusi yang di-revert dihapus dari hasil akhir transaksi.

Apakah log peristiwa menggunakan gas?

Ya, penerbitan log menggunakan gas yang sebagian bergantung pada topic dan ukuran datanya.

Bisakah log peristiwa membuktikan token itu sah?

Tidak. Kontrak apa pun dapat menerbitkan event yang familier, sehingga pengguna harus memverifikasi kontrak penerbit dan status aktualnya.

Bagaimana developer mengambil log peristiwa?

Developer dapat mengambil log melalui metode seperti eth_getLogs, kueri tanda terima, filter, subscription, blockchain explorer, atau layanan pengindeksan.

Bisakah reorganisasi blockchain menghapus log peristiwa?

Bisa. Log dari blok yang digantikan akan dihapus dari riwayat chain kanonis.

Apakah log peristiwa sama di setiap chain EVM?

Struktur dasarnya biasanya serupa, tetapi chain ID, kontrak, riwayat blok, finalitas, dan perilaku RPC dapat berbeda.

Apakah log peristiwa lebih murah daripada storage kontrak?

Log sering kali lebih murah untuk informasi historis off-chain, tetapi tidak dapat menggantikan storage yang perlu dibaca oleh eksekusi smart contract di masa mendatang.

Mengapa wallet menggunakan log peristiwa?

Wallet menggunakan log peristiwa untuk mengidentifikasi transfer token, persetujuan, swap, dan tindakan smart contract lainnya yang tidak terlihat jelas hanya dari field dasar transaksi.

Kesimpulan

Log peristiwa adalah catatan terstruktur yang menghubungkan eksekusi smart contract dengan wallet, aplikasi terdesentralisasi, blockchain explorer, sistem analitik, dan layanan off-chain lainnya.

Log dibuat melalui instruksi logging EVM dan disimpan dalam tanda terima transaksi setelah transaksi berhasil dieksekusi.

Log berisi alamat kontrak penerbit, topic yang dapat ditelusuri, dan data event yang dienkode dengan ABI.

Topic 0 biasanya mengidentifikasi signature event, sedangkan parameter indexed menyediakan opsi pemfilteran tambahan.

Parameter non-indexed disimpan di field data dan memerlukan ABI yang benar untuk didekode.

Log peristiwa berbeda dari storage kontrak karena smart contract tidak dapat membaca log historis secara langsung.

Log peristiwa juga berbeda dari data return fungsi karena dirancang agar tersedia untuk pemrosesan historis off-chain.

Aplikasi dapat mengambil log melalui filter JSON-RPC, subscription, tanda terima transaksi, blockchain explorer, dan indexer khusus.

Sistem yang andal harus menangani pemrosesan duplikat, keterbatasan RPC, reorganisasi chain, upgrade kontrak, dan tingkat konfirmasi yang berbeda.

Pengguna harus ingat bahwa nama event yang familier tidak membuktikan bahwa kontrak penerbit tepercaya atau tokennya sah.

Developer sebaiknya merancang event dengan nama yang jelas, parameter indexed yang berguna, konteks yang cukup, dan skema yang stabil.

Memahami log peristiwa membantu pengguna dan developer kripto menafsirkan transfer token, aktivitas DeFi, perubahan smart contract, tanda terima transaksi, dan data aplikasi on-chain dengan lebih akurat.