Ethereum
Kontrak yang terus berjalan setelah panggilan gagal saat ini tidak memiliki cara andal untuk menentukan apakah penerima membatalkan secara sengaja atau hanya kehabisan gas yang dipilih oleh pengirim. Kesenjangan ini adalah akar dari griefing gas yang tidak mencukupi, dan sebuah proposal draf baru berusaha menutupnya pada tingkat EVM. EIP-8456, yang dibuka untuk diskusi di Ethereum Magicians pada hari Senin, menambahkan instruksi bernama CALLSTATUS, sementara di opcode 0xA5 dengan biaya 2 gas. Instruksi ini mendorong status penyelesaian dari panggilan atau operasi create terbaru dalam frame saat ini sebagai tiga bit. Bit 0 berarti revert, bit 1 berarti henti luar biasa seperti kehabisan gas, dan bit 2 berarti sesuatu di frame di bawahnya menghentikan eksekusi. Penulis menunjukkan bahwa satu-satunya bukti saat ini adalah aritmetika gasleft() setelah panggilan, dan setiap fork repricing telah merusak ambang batas tersebut. Gas dua dimensi yang diusulkan oleh EIP-8037 akan membuat aritmetika ini semakin lemah, karena reservoirnya tidak terlihat melalui opcode GAS. Jadi, mengapa bit ketiga? Sebagian besar panggilan nyata melewati perantara seperti proxy, wrapper functionCall OpenZeppelin, Multicall3, atau checker tanda tangan ERC-1271. Jika hanya status akhir penerima langsung yang dilaporkan, sebuah wrapper yang menangkap henti kehabisan gas dan melakukan revert dengan alasan akan tampak seperti revert yang disengaja. Draf ini mempertahankan flag sticky yang bergerak naik melalui setiap frame, sehingga pengirim yang hanya mengontrol gas tidak pernah bisa membuat caller membaca revert biasa. Draf ini melaporkan hasil daripada penyebab, dan penerima tetap dapat menghasilkan henti secara sengaja dengan INVALID. Hanya melindungi kode yang ditulis setelah rilisnya, karena kontrak yang sudah dideploy tidak akan membacanya. Belum ada tinjauan eksternal, nomor opcode masih terbuka, dan prototipe plus tes untuk 58 kasus yang terdaftar masih menunggu. Link - https://t.co/KnByUBgWrY
Sebagian besar dompet Ethereum masih menampilkan seluruh riwayat keuangan Anda kepada siapa pun yang memiliki alamat Anda, dan Ethereum Foundation kini menganggap hal ini sebagai lubang keamanan, bukan sekadar fitur privasi yang diinginkan. Pada Senin, Foundation memposting bahwa serangan dan eksploitasi minggu lalu membuat satu poin menjadi lebih jelas bagi mereka, yaitu privasi dan keamanan tidak bisa diperlakukan sebagai tujuan yang terpisah. Mereka menyatakan bahwa Anda bisa kurang khawatir jika penyerang memanfaatkan riwayat onchain Anda ketika privasi menjadi standar bawaan. Postingan tersebut mengutip pembaruan mengenai Kohaku, proyek alat privasi pertama milik Foundation. Repo JavaScript ini dibagi menjadi paket-paket yang dapat diambil oleh tim dompet satu per satu. Ada perpustakaan untuk Privacy Pools dan Tornado Cash, ditambah perpustakaan Railgun yang saat ini ditandai sebagai sedang dalam pemeliharaan di README. Paket plugin mendefinisikan antarmuka standar untuk protokol shielded pool, sehingga dompet dapat berkomunikasi dengan semuanya dengan cara yang sama. Paket provider mengabstraksi ethers, viem, Helios, dan Colibri. Repo ini juga menyertakan akun ERC-4337 pasca-kuantum. Crate Rust berada di repositori saudara terpisah. Saya menyukai pendekatan ini sebagai SDK, bukan dompet privasi lain yang meminta pengguna untuk memindahkan dana. Idenya adalah dompet yang sudah ada dapat menambahkan alur shielded tanpa setiap tim harus mengimplementasikan ulang tiga protokol. README secara jujur menyatakan kondisi saat ini. Beberapa bagian ditandai belum siap untuk produksi, dan paket-paket tersebut berisi kode yang belum diaudit. Jordan Enev dari Ambire mengatakan pada Jumat lalu bahwa tim telah menghabiskan berbulan-bulan menguji integrasi tersebut, dan belum ada tanggal peluncuran publik yang diumumkan. Vitalik dan Nicolas Consigny dijadwalkan untuk mendemonstrasikan Kohaku bersama Ambire di Ethereum mainnet pada Selasa depan di @EFDevcon, menurut daftar sesi. Berikut adalah repositorinya - https://t.co/egNbLgAo0J
Terminal Anda sekarang dapat berbicara kembali kepada Anda, dan yang lucu adalah ia melakukannya tanpa memanggil API cloud apa pun. Pada Sabtu, Ollama merilis 0.40.11 dengan text-to-speech di macOS. Model bicara pertama adalah Phonon, keluarga model TTS kecil dari Gradium. Anda mengunduhnya dengan ollama pull phonon dan menjalankannya seperti model lainnya. Bagian yang benar-benar akan menjadi perhatian pengembang adalah API. Phonon bekerja dengan endpoint /v1/audio/speech yang kompatibel dengan OpenAI di localhost. Jika kode Anda sudah menggunakan OpenAI SDK untuk suara, dokumentasi mengatakan Anda hanya perlu URL dasar baru. Respons streaming saat audio sedang dihasilkan, sehingga pemutaran dapat dimulai sebelum teks sepenuhnya selesai. Anda bahkan dapat mengalirkan balasan model obrolan langsung ke Phonon, dan ia mulai berbicara setelah kalimat pertama. Output adalah 24 kHz mono, secara default dalam format WAV atau PCM 16-bit mentah jika Anda memintainya. Dokumentasi mencantumkan beberapa batasan yang mudah dilanggar. Setiap permintaan dapat menampung hingga 4.096 karakter, meskipun ollama run membagi teks yang lebih panjang untuk Anda. Harga, simbol, email, dan URL dieja secara huruf per huruf, sementara tanggal numerik dibaca sesuai penulisannya, sehingga dokumentasi menyarankan menulis tanggal dalam bentuk kata-kata. Opsi yang tidak didukung seperti kecepatan atau instruksi mengembalikan kesalahan 400 alih-alih diabaikan diam-diam. Lisensi patut dibaca dengan cermat sebelum Anda merilis apa pun. Model Phonon bahasa Inggris default berlisensi Apache 2.0. Varian Prancis, Jerman, Spanyol, Portugis, dan multibahasa 40M berlisensi CC BY-NC 4.0, yang melarang penggunaan komersial. Ollama juga menyatakan bahwa di MacBook Pro M5 Max, ia berjalan 35 persen lebih cepat daripada runtime milik Gradium sendiri, yang merupakan tolok ukur mereka, bukan yang independen. Suara saat ini hanya tersedia untuk Apple Silicon, dengan dukungan Windows dan Linux tercantum akan segera hadir.
Sebuah L2 Ethereum yang menerima nol tanda tangan terdengar seperti lubang keamanan, tetapi BB84 melakukannya secara sengaja untuk menghindari serangan kuantum. Akhir pekan lalu, pendirinya, yang posting dengan nama Hadamard, mempublikasikan desainnya di Ethereum Research dan meminta umpan balik kritis. BB84 adalah rollup OP Stack di mainnet, aktif sejak 30 September, di mana transaksi L2 sama sekali tidak menggunakan ECDSA. Setiap akun adalah ujung dari rantai hash keccak-256 yang dibangun dari rahasia, dengan 1.000 langkah secara default. Untuk menghabiskan, dompet Anda mengungkapkan nilai sebelumnya dalam rantai, yang dapat diverifikasi siapa pun dengan melakukan hashing sekali. Di dalam L2, satu-satunya asumsi yang tersisa adalah ketahanan preimage dari keccak-256, yang algoritma Grover kurangi menjadi sekitar 2^128 kerja. Mengungkapkan rahasia membuatnya menjadi publik, sehingga protokol menambahkan langkah commit dan reveal untuk mengikat setiap preimage ke satu transaksi terlebih dahulu. Dua jenis transaksi baru di op-geth menangani ini, dan pemeriksaan pengirim menggantikan ecrecover. Otorisasi dikonsumsi bahkan ketika panggilan gagal, dan jika dompet melewatkan langkah pembaruan pada tautan terakhir, alamat tersebut mati. Postingan tersebut juga mencantumkan kelemahan front-running yang ditemukan tim saat menulisnya. Commit tidak membawa tanda tangan, sehingga commit baru dulu bisa menggantikan commit yang sedang menunggu, dan penyerang bisa mengikat ulang rahasia yang diungkap ke pembayaran mereka sendiri. Aturan yang berlaku mulai 21 Oktober membuat commit pertama yang menang. Batas-batasnya dijelaskan secara jelas. Setoran dan penarikan L1 masih menggunakan ECDSA. Belum ada fault proof, dan menurut akun postingan itu sendiri, rantai ini bahkan belum mencapai Tahap 0 L2BEAT. Sequencer dijalankan oleh tim, dan alamat 160-bit menyisakan sekitar 2^80 ketahanan kuantum second-preimage. Postingan tersebut juga menanyakan apakah akun rantai-hash bisa menjadi mode validasi EIP-7702 atau abstraksi akun native pada L2 umum.
OpenZeppelin menjadikan Chainlink sebagai pilihan default untuk lintas-chain dan kepatuhan dalam perangkat token-nya, dan jika Anda mencentang kotak kepatuhan, lisensi token Anda berubah. Seminggu yang lalu, OpenZeppelin mengumumkan kemitraan strategis dengan Chainlink. CCIP dan ACE, protokol lintas-chain Chainlink dan Automated Compliance Engine-nya, kini telah terintegrasi ke dalam Contracts Wizard, perangkat AI OpenZeppelin dan dokumentasinya. Generator ERC20, Stablecoin, dan RWA semuanya menawarkan kedua opsi tersebut. Memilih opsi CCIP membuat token membuka panggilan mint dan burn yang dibutuhkan oleh pool burn-and-mint Chainlink, di balik izin token itu sendiri. Ini juga menentukan administrator untuk pendaftaran CCIP. Bagian ini tetap mempertahankan lisensi yang Anda pilih, karena tidak ada kode Chainlink yang dimasukkan. Opsi ACE berbeda. Ini meneruskan transfer, mint, dan burn ke Policy Engine yang Anda deploy dan konfigurasi. Dokumentasi OpenZeppelin sendiri menyatakan bahwa token yang menggunakan ACE berada di bawah lisensi BUSL-1.1, dan penggunaan produksi harus memenuhi lisensi ACE dan tambahan izin penggunaannya. Selama bertahun-tahun, token yang dihasilkan oleh OpenZeppelin membawa lisensi yang Anda pilih, biasanya MIT. Satu kotak centang sekarang mengubah itu, dan seorang pengembang junior yang terburu-buru mungkin tidak menyadarinya. Generator ini tidak mendaftarkan pool Anda, mengatur izin, atau menulis kebijakan Anda. Mengaitkan Policy Engine tidak mengonfigurasi kebijakan apa pun, dan Anda tetap bertanggung jawab untuk memenuhi aturan apa pun yang berlaku bagi Anda. Pengumuman tersebut juga menyebutkan jalur migrasi dari OpenZeppelin Defender ke Runtime Environment Chainlink. Tidak ada dari ini yang disembunyikan, dan bagi tim RWA yang sudah menginginkan Chainlink, ini menghemat pekerjaan integrasi nyata. Saya hanya ingin para pembangun memilihnya dengan sengaja, bukan karena wizard menempatkannya di sana.
Smart contract maxis, Compiler Solidity Anda mungkin telah menghapus secara diam-diam sebuah penyimpanan yang Anda butuhkan, dan Anda tidak akan pernah melihatnya di sumber kode Anda. Solidity 0.8.38 dirilis Kamis lalu. Ini memperbaiki bug pada Yul optimiser yang ada di setiap rilis dari 0.8.19 hingga 0.8.37. Optimiser menyimpan catatan tentang apa yang ada di memori dan penyimpanan. Ia menggunakan catatan tersebut untuk mengganti pemuatan dengan nilai yang sudah diketahuinya, dan melewati penyimpanan yang menulis data yang sudah ada. Untuk menentukan apakah dua alamat dapat tumpang tindih, ia menggambarkan masing-masing sebagai variabel dasar ditambah offset. Basis yang sama, offset berbeda, jadi mereka pasti berada di slot yang berbeda. Deskripsi-deskripsi ini disimpan dalam cache. Kemudian seseorang menetapkan ulang variabel dasar. Optimiser tidak selalu menyadarinya. Sekarang ia membandingkan alamat yang dibangun dari nilai lama dengan alamat yang dibangun dari nilai baru seolah-olah keduanya berbagi basis yang sama. Ia memutuskan bahwa mereka berbeda, tetapi pada runtime keduanya menunjuk ke tempat yang sama. Hasilnya adalah catatan yang usang. Pemuatan selanjutnya dapat mengembalikan nilai lama. Penyimpanan yang Anda butuhkan dapat dihapus. Keccak256 atas lokasi tersebut dapat menghasilkan hash data yang sudah kadaluarsa. Hanya kode yang dikompilasi dengan optimiser aktif yang terpapar. Dengan via-IR, semua kode dapat terkena dampaknya, bahkan tanpa inline assembly. Dengan pipeline legacy default, hanya beberapa inline assembly dan helper yang dihasilkan compiler. Build tanpa optimasi aman. Tim menilai ini sebagai tingkat keparahan rendah, dan mereka melakukan sesuatu yang saya harap semua tim compiler lakukan. Mereka mengompilasi ulang setiap kontrak terverifikasi di database Sourcify dengan dan tanpa perbaikan, dan bytecode-nya identik untuk semuanya. Jadi, ini jarang terjadi. Jarang tidak sama dengan tidak pernah, terutama jika kode Anda baru dan belum dideploy. Bug ini ditemukan melalui bug bounty Ethereum Foundation, dan laporan kedua menunjukkan bahwa Solidity biasa tanpa assembly pun dapat memicunya.
Dorongan maskulin untuk menjadi ETH maxi. 🥳
Ethereum adalah Ethereum dan akan selamanya demikian. Pada fork berikutnya, komunitas Ethereum akan melihat keajaiban sejati dari protokol tersebut.