ethereum
Kontrak yang terus berjalan selepas panggilan gagal tidak mempunyai cara yang boleh dipercayai hari ini untuk menentukan sama ada penerima membatalkan dengan sengaja atau hanya kehabisan gas yang dipilih oleh penghantar. Kesenjangan ini adalah punca utama serangan griefing gas yang tidak mencukupi, dan cadangan draf baharu cuba menutupnya pada peringkat EVM. EIP-8456, yang dibuka untuk perbincangan di Ethereum Magicians pada hari Isnin, menambah arahan bernama CALLSTATUS, sementara di opcode 0xA5 dengan 2 gas. Ia mendorong status penyelesaian operasi panggilan atau cipta paling terkini dalam bingkai semasa sebagai tiga bit. Bit 0 bermaksud pembatalan, bit 1 bermaksud penghentian luar biasa seperti kehabisan gas, dan bit 2 bermaksud sesuatu dalam bingkai di bawahnya berhenti. Pengarang menunjukkan bahawa bukti tunggal hari ini ialah aritmetik gasleft() selepas panggilan, dan setiap cabang penyesuaian semula telah memecahkan ambang-ambang tersebut. Gas dua dimensi yang dicadangkan oleh EIP-8037 akan membuat aritmetik ini lebih lemah lagi, kerana rezervornya tidak kelihatan melalui opcode GAS. Jadi, mengapa bit ketiga? Kebanyakan panggilan sebenar melalui perantara seperti proxy, pembungkus functionCall OpenZeppelin, Multicall3 atau pemeriksa tanda tangan ERC-1271. Jika hanya kesudahan penerima langsung dilaporkan, pembungkus yang menangkap penghentian kehabisan gas dan membatalkan dengan sebab akan kelihatan seperti pembatalan yang disengajakan. Draf ini mengekalkan bendera melekat yang bergerak ke atas setiap bingkai, jadi penghantar yang hanya mengawal gas tidak pernah boleh membuat pemanggil membaca pembatalan biasa. Ia melaporkan kesudahan bukan punca, dan penerima masih boleh menghasilkan penghentian dengan sengaja menggunakan INVALID. Ia hanya melindungi kod yang ditulis selepas ia dilancarkan, kerana kontrak yang telah dideploy tidak akan membacanya. Belum ada ulasan luar, nombor opcode masih terbuka, dan prototaip serta ujian untuk 58 kes yang disenaraikan masih tertunda. Pautan - https://t.co/KnByUBgWrY
Sebahagian besar dompet ethereum masih menunjukkan sejarah kewangan penuh anda kepada sesiapa sahaja yang mempunyai alamat anda, dan Yayasan Ethereum kini menganggap ini sebagai lubang keselamatan, bukan sekadar keistimewaan privasi. Pada hari Isnin, Yayasan itu memposting bahawa serangan dan eksploitasi seminggu lalu membuat satu perkara lebih jelas kepada mereka, iaitu privasi dan keselamatan tidak boleh dianggap sebagai matlamat yang berasingan. Mereka berpendapat bahawa anda boleh kurang risau tentang penyerang yang menggunakan sejarah onchain anda melawan anda apabila privasi adalah laluan lalai. Post itu mengutip kemas kini mengenai Kohaku, projek alat privasi pertama Yayasan. Repositori JavaScript ini dibahagikan kepada pakej yang boleh diambil oleh pasukan dompet satu per satu. Terdapat pustaka untuk Privacy Pools dan Tornado Cash, ditambah pustaka Railgun yang pada README kini ditandakan sebagai sedang dalam penyelenggaraan. Satu pakej plugin mentakrifkan antaramuka piawai untuk protokol kolam terlindung, supaya dompet boleh berkomunikasi dengan semua protokol tersebut dengan cara yang sama. Satu pakej penyedia mengabstrakkan ethers, viem, Helios dan Colibri. Repositori ini juga menyediakan akaun ERC-4337 pasca-kuantum. Krat Rust berada di repositori adik beradik yang berasingan. Saya suka bahawa ini dirangka sebagai SDK, bukan dompet privasi lagi yang meminta pengguna untuk memindahkan dana. Idenya ialah dompet sedia ada menambah aliran terlindung tanpa setiap pasukan perlu melaksanakan semula tiga protokol. README secara terus terang menyatakan keadaan semasa. Beberapa bahagian ditandakan sebagai belum bersedia untuk pengeluaran, dan pakej-pakej tersebut mengandungi kod yang belum diaudit. Jordan Enev dari Ambire mengatakan pada Jumaat lepas bahawa pasukan telah menguji integrasi selama berbulan-bulan, dan tiada tarikh pelancaran awam telah diberikan. Vitalik dan Nicolas Consigny dijadualkan untuk memperagakan Kohaku bersama Ambire di rangkaian utama ethereum pada Selasa depan di @EFDevcon, menurut senarai sesi. Berikut ialah repositori - https://t.co/egNbLgAo0J
Terminal anda kini boleh berbalas kepada anda, dan yang lucu ialah ia melakukannya tanpa memanggil sebarang API awan. Pada Sabtu, Ollama melancarkan 0.40.11 dengan teks-ke-suara di macOS. Model suara pertama ialah Phonon, satu keluarga model TTS kecil dari Gradium. Anda muat turunnya dengan ollama pull phonon dan jalankan seperti mana-mana model lain. Bahagian yang benar-benar akan menarik perhatian pembangun ialah API. Phonon berfungsi dengan endpoint /v1/audio/speech yang kompatibel dengan OpenAI di localhost. Jika kod anda sudah menggunakan OpenAI SDK untuk suara, dokumen menyatakan anda hanya perlu URL asas baru. Respons disalurkan semasa audio sedang dihasilkan, jadi pemutaran boleh bermula sebelum teks penuh selesai. Anda bahkan boleh menghantar balasan model perbualan terus ke Phonon, dan ia akan bercakap selepas ayat pertama. Output ialah 24 kHz mono, sebagai WAV secara lalai atau PCM 16-bit mentah jika anda meminta. Dokumen menyenaraikan beberapa had yang mudah dilanggar. Setiap permintaan mengambil sehingga 4,096 aksara, walaupun ollama run memisahkan teks yang lebih panjang untuk anda. Harga, simbol, emel dan URL dieja, manakala tarikh nombor dibaca seperti yang ditulis, jadi dokumen mencadangkan menulis tarikh dalam perkataan. Pilihan yang tidak disokong seperti kelajuan atau arahan akan mengembalikan ralat 400 bukannya diabaikan secara senyap. Pembenaran perlu dibaca dengan teliti sebelum anda melancarkan apa-apa. Model Phonon bahasa Inggeris lalai ialah Apache 2.0. Varian Perancis, Jerman, Sepanyol, Portugis dan pelbagai bahasa 40M ialah CC BY-NC 4.0, yang melarang penggunaan komersial. Ollama juga menyatakan bahawa pada MacBook Pro M5 Max, ia berjalan 35 peratus lebih pantas daripada runtime Gradium sendiri, yang merupakan tolok ukur mereka bukan yang bebas. Suara kini hanya tersedia untuk Apple Silicon, dengan sokongan Windows dan Linux disenaraikan akan datang segera.
Sebuah L2 Ethereum yang menerima tanda tangan sifar kelihatan seperti kelemahan keselamatan, tetapi BB84 melakukannya dengan sengaja untuk mengelakkan serangan kuantum. Akhir pekan lepas, pendirinya, yang memposting sebagai Hadamard, menerbitkan reka bentuknya di Ethereum Research dan meminta maklum balas kritikal. BB84 ialah rollup OP Stack di rangkaian utama, aktif sejak 30 September, di mana transaksi L2 tidak membawa ECDSA sama sekali. Setiap akaun ialah hujung rantai hash keccak-256 yang dibina daripada rahsia, dengan 1,000 langkah secara lalai. Untuk mengeluarkan dana, dompet anda mengungkap nilai sebelumnya dalam rantai itu, yang mana sesiapa sahaja boleh mengesahkan dengan menghash sekali sahaja. Di dalam L2, satu-satunya anggapan yang tinggal ialah ketahanan preimage keccak-256, yang algoritma Grover kurangkan kepada kira-kira 2^128 kerja. Mengungkap rahsia menjadikannya awam, jadi protokol menambah langkah commit dan reveal untuk mengikat setiap preimage kepada satu transaksi terlebih dahulu. Dua jenis transaksi baru dalam op-geth mengendalikan ini, dan pemeriksaan penghantar menggantikan ecrecover. Otorisasi habis digunakan walaupun panggilan gagal, dan jika dompet terlepas langkah pengemaskinian pada pautan terakhir, alamat itu mati. Post tersebut juga menyebut kelemahan front-running yang ditemui oleh pasukan semasa menulisnya. Commit tidak membawa tanda tangan, jadi commit baru dahulu boleh menggantikan commit yang masih menunggu, dan penyerang boleh mengikat semula rahsia yang diungkap kepada pembayaran mereka sendiri. Peraturan yang berkuat kuasa pada 21 Oktober membuatkan commit pertama menang. Had-had tersebut dinyatakan dengan jelas. Deposit dan penarikan dana L1 masih menggunakan ECDSA. Belum ada fault proof, dan menurut post itu sendiri, rantai ini bahkan tidak mencapai Tahap 0 L2BEAT. Sequencer dijalankan oleh pasukan, dan alamat 160-bit meninggalkan ketahanan kuantum second-preimage kira-kira 2^80. Post tersebut juga bertanya sama ada akaun rantai hash boleh menjadi mod pengesahan EIP-7702 atau abstraksi akaun asli pada L2 umum.
OpenZeppelin menjadikan Chainlink sebagai pilihan lalai untuk lintas rantai dan kepatuhan dalam peralatan token-nya, dan jika anda menandai kotak kepatuhan, lesen token anda akan berubah. Seminggu yang lalu, OpenZeppelin mengumumkan kemitraan strategik dengan Chainlink. CCIP dan ACE, protokol lintas rantai Chainlink dan Mesin Kepatuhan Automatiknya, kini telah dibina ke dalam Contracts Wizard, peralatan AI OpenZeppelin dan dokumennya. Penghasil ERC20, Koin Stabil dan RWA semuanya menawarkan kedua-dua pilihan tersebut. Memilih pilihan CCIP akan membuka panggilan mint dan burn yang diperlukan oleh kolam burn-and-mint Chainlink, di belakang kebenaran token itu sendiri. Ia juga menamakan pentadbir untuk pendaftaran CCIP. Bahagian ini mengekalkan lesen yang anda pilih, kerana tiada kod Chainlink dimasukkan. Pilihan ACE berbeza. Ia meneruskan pindah, mint dan burn ke Mesin Dasar yang anda deploy dan konfigurasi. Dokumen OpenZeppelin sendiri menyatakan bahawa token yang menggunakan ACE berada di bawah BUSL-1.1, dan penggunaan produksi mesti memenuhi lesen ACE dan grant penggunaan tambahannya. Selama bertahun-tahun, token yang dihasilkan oleh OpenZeppelin membawa lesen yang anda pilih, biasanya MIT. Satu kotak semak sahaja kini mengubahnya, dan seorang pembangun junior yang tergesa-gesa mungkin tidak menyedari. Penghasil ini tidak mendaftarkan kolam anda, menetapkan kebenaran atau menulis dasar anda. Mengaitkan Mesin Dasar tidak mengkonfigurasi sebarang dasar, dan anda tetap bertanggungjawab untuk memenuhi sebarang peraturan yang berlaku kepada anda. Pengumuman tersebut juga menyebut tentang laluan migrasi dari OpenZeppelin Defender ke Lingkungan Runtime Chainlink. Semua ini tidak disembunyikan, dan untuk pasukan RWA yang sudah menginginkan Chainlink, ia menghemat kerja integrasi yang sebenar. Saya hanya ingin pembina memilihnya dengan sengaja, bukan kerana wizard meletakkannya di sana.
Maxis kontrak pintar, Pembilik Solidity anda mungkin telah menghapus secara senyap satu simpanan yang anda perlukan, dan anda tidak akan pernah melihatnya dalam sumber anda. Solidity 0.8.38 dikeluarkan pada hari Kamis lepas. Ia memperbaiki satu ralat dalam pengoptimum Yul yang wujud dalam semua versi dari 0.8.19 hingga 0.8.37. Pengoptimum menyimpan catatan mengenai apa yang berada dalam memori dan simpanan. Ia menggunakan catatan itu untuk menggantikan satu beban dengan nilai yang sudah diketahui, dan untuk melepaskan satu simpanan yang menulis data yang sudah ada. Untuk menentukan sama ada dua alamat boleh bertindih, ia menggambarkan setiap alamat sebagai pemboleh ubah asas ditambah dengan sela. Asas yang sama, sela yang berbeza, jadi mereka mesti berada dalam slot yang berbeza. Penggambaran ini disimpan dalam cache. Kemudian seseorang mengganti semula pemboleh ubah asas. Pengoptimum tidak selalu menyedari perkara ini. Sekarang, ia membandingkan alamat yang dibina daripada nilai lama dengan alamat yang dibina daripada nilai baru seolah-olah keduanya berkongsi asas yang sama. Ia memutuskan bahawa mereka berbeza, tetapi pada masa pelaksanaan, kedua-duanya menunjuk ke tempat yang sama. Hasilnya ialah catatan usang. Satu beban kemudian boleh mengembalikan nilai lama. Satu simpanan yang anda perlukan boleh dihapuskan. Satu keccak256 atas lokasi itu boleh menghakis data yang sudah usang. Hanya kod yang dikompilasi dengan pengoptimum dihidupkan yang terjejas. Dengan via-IR, mana-mana kod boleh terjejas, walaupun tanpa assembly dalam baris. Dengan paip warisan lalai, hanya beberapa assembly dalam baris dan pembantu yang dihasilkan oleh kompilator. Build tanpa pengoptimum adalah selamat. Pasukan menilainya sebagai keparahan rendah, dan mereka melakukan sesuatu yang saya harap setiap pasukan kompilator lakukan. Mereka mengompilasi semula setiap kontrak yang disahkan dalam pangkalan data Sourcify dengan dan tanpa pembaikan, dan bytecode untuk semua kontrak tersebut adalah identik. Jadi, ia jarang berlaku. Jarang bukan bermakna tidak pernah berlaku, terutamanya jika kod anda baru dan belum dideploy. Ralat ini ditemui melalui bounty ralat Ethereum Foundation, dan laporan kedua menunjukkan bahawa Solidity biasa tanpa assembly juga boleh memicunya.
Dorongan maskulin untuk menjadi ETH maxi. 🥳
Ethereum adalah Ethereum dan akan tetap begitu selamanya. Dalam cabang berikutnya, komunitas Ethereum akan melihat keajaiban sebenarnya dari protokol tersebut.