Ethereum
Ang isang contract na patuloy na nagpapatakbo pagkatapos ng isang nabigo mong pagtawag ay walang maaasahang paraan ngayon upang malaman kung ang callee ay nag-revert nang may layunin o simpleng nawalan ng gas na pinili ng sender. Ang puwang na ito ay ang ugat ng insufficient gas griefing, at isang bagong draft na propuesta ay subukang isara ito sa EVM level. Ang EIP-8456, na binuksan para sa diskusyon sa Ethereum Magicians noong Lunes, ay nagdaragdag ng isang instruction na tawagin na CALLSTATUS, pansamantalang sa opcode 0xA5 para sa 2 gas. Ipinipilit nito ang completion status ng pinakabagong call o create operation sa kasalukuyang frame bilang tatlong bit. Ang bit 0 ay nangangahulugan ng revert, ang bit 1 ay nangangahulugan ng exceptional halt tulad ng out of gas, at ang bit 2 ay nangangahulugan ng isang bagay sa isang frame sa ibaba na huminto. Inilalarawan ng may-akda na ang tanging ebidensya ngayon ay ang gasleft() arithmetic pagkatapos ng call, at ang bawat repricing fork ay nagbroke sa mga threshold na ito. Ang ipinaproposang two-dimensional gas ng EIP-8037 ay gagawing mas mahina ang arithmetic na ito, dahil ang kanyang reservoir ay hindi nakikita sa pamamagitan ng GAS opcode. Kaya bakit ang ikatlong bit? Ang karamihan sa tunay na mga call ay dumadaan sa mga intermediary tulad ng proxies, OpenZeppelin’s functionCall wrapper, Multicall3 o ERC-1271 signature checkers. Kung tanging ang dulo ng direktang callee ang iirereport, ang isang wrapper na nakakakuha ng out-of-gas halt at nagre-revert nang may dahilan ay magiging tila isang deliberate revert. Ang draft ay panatilihin ang sticky flag na umuusbong sa bawat frame, kaya ang isang sender na tanging kontrolado ang gas ay hindi kayang gawing basahin ng caller ang isang simpleng revert. Ito ay nagrereport ng mga resulta kaysa sa mga sanhi, at ang callee ay maaari pa ring lumikha ng halt nang may layunin gamit ang INVALID. Ito ay protektado lamang para sa code na isusulat pagkatapos nito ay ipinapalabas, dahil ang mga deployed na contract ay hindi magbabasa nito. Wala pa ring external reviews, ang opcode number ay patuloy na bukas, at ang isang prototype kasama ang mga test para sa 58 listahing kaso ay nasa pending pa rin. Link - https://t.co/KnByUBgWrY
Karamihan pa rin ng mga Ethereum wallet ay nagpapakita ng buong kasaysayan ng iyong pananalapi sa sinumang may akses sa iyong address, at ang Ethereum Foundation ay ngayon ay itinuturing ito bilang isang security hole kaysa isang privacy na “nice-to-have.” Noong Lunes, inilabas ng Foundation na ginawang mas malinaw ng mga attack at exploit noong nakaraang linggo na ang privacy at security ay hindi maaaring tratuhin bilang magkahiwalay na layunin. Ang kanilang pahayag ay ang pagkakaroon ng privacy bilang default ay nagpapababa ng pag-aalala tungkol sa paggamit ng isang attacker ng iyong onchain history laban sa iyo. Isinama ng post ang isang update tungkol sa Kohaku, ang privacy-first na wallet tooling project ng Foundation. Ang JavaScript repo ay nahahati sa mga package na maaaring kunin ng isang wallet team nang isang-isa. Mayroon silang mga library para sa Privacy Pools at Tornado Cash, kasama ang isang Railgun library na kasalukuyang nakalabas bilang “under maintenance” sa README. Ang isang plugins package ay nagtataguyod ng isang standard interface para sa shielded pool protocols, kaya maaaring makipag-ugnayan ang wallet sa lahat ng ito nang parehong paraan. Ang isang provider package ay nag-aabstract sa ethers, viem, Helios at Colibri. Ang repo ay kasama rin ang isang post-quantum ERC-4337 account. Ang mga Rust crates ay nasa hiwalay na sister repository. Gusto ko na ito ay isinabuhay bilang isang SDK kaysa isang karagdagang privacy wallet na hinihingi sa mga user na ilipat ang kanilang pera. Ang ideya ay ang mga umiiral na wallet ay magdaragdag ng shielded flows nang hindi kailangan na i-implement muli ng bawat team ang tatlong protocols. Malinaw sa README kung saan nasaan ang mga bagay. Ang ilang bahagi ay nakalabas bilang hindi handa para sa production, at ang mga package ay naglalaman ng unaudited code. Sinabi ni Jordan Enev ng Ambire noong Biyernes na ang team ay nagpasa ng ilang buwan sa pagsubok ng mga integrasyon, at wala pang pinalabas na petsa para sa public launch. Iskedyul na si Vitalik at Nicolas Consigny na ipakita ang Kohaku kasama ang Ambire sa Ethereum mainnet sa @EFDevcon susunod na Martes, ayon sa listahan ng sesyon. ito ang repo - https://t.co/egNbLgAo0J
Ang iyong terminal ay maaari na ngayong magsalita pabalik sa iyo, at ang kakaibang bagay ay ginagawa nito nang walang pagtawag sa anumang cloud API. Noong Sabado, inilabas ng Ollama ang 0.40.11 na may text-to-speech sa macOS. Ang unang speech model ay ang Phonon, isang pamilya ng maliit na TTS models mula sa Gradium. Ipinopull mo ito gamit ang ollama pull phonon at pinapatakbo mo ito tulad ng anumang ibang model. Ang bahaging tunay na mahalaga sa mga developer ay ang API. Ang Phonon ay gumagana gamit ang OpenAI-compatible /v1/audio/speech endpoint sa localhost. Kung ang iyong code ay gumagamit na ng OpenAI SDK para sa speech, sinasabi ng dokumentasyon na kailangan mo lang ng bagong base URL. Ang response ay stream habang ginagawa ang audio, kaya maaari nang magsimula ang playback bago matapos ang buong teksto. Maaari mo pa ring i-pipe ang sagot ng chat model diretso sa Phonon, at magsisimula itong magsalita pagkatapos ng unang pangungusap. Ang output ay 24 kHz mono, bilang WAV sa default o raw 16-bit PCM kung hingi mo ito. Ang dokumentasyon ay listahan ang ilang limitasyon na madaling masira. Bawat request ay kumukuha ng hanggang 4,096 characters, bagaman hinahati ng ollama run ang mas mahabang teksto para sa iyo. Ang mga presyo, simbolo, email at URL ay sinasalita nang buo, samantalang ang mga numeric dates ay binabasa tulad ng isinusulat, kaya inirerekomenda ng dokumentasyon na isulat ang mga petsa nang salita. Ang mga hindi suportadong opsyon tulad ng speed o instructions ay bumabalik ng 400 error kesa na lang na i-ignore nang tahimik. Dapat basahin nang mabuti ang licensing bago ilabas ang anumang bagay. Ang default English phonon model ay Apache 2.0. Ang 40M French, German, Spanish, Portuguese at multilingual variants ay CC BY-NC 4.0, na nagbabawal sa commercial use. Sinasabi rin ng Ollama na sa isang M5 Max MacBook Pro, ito ay tumakbo 35 porsiyento mas mabilis kaysa sa sariling runtime ng Gradium, na isang benchmark nila kesa isang independiyenteng isa. Ang speech ay Apple Silicon lang para sa kasalukuyan, na may suporta para sa Windows at Linux na nakalista bilang darating na.
Isang Ethereum L2 na tumatanggap ng zero signature ay tila isang security bug, ngunit ginagawa ito ng BB84 nang may layunin upang iwasan ang quantum attacks. Noong nakaraang weekend, ang founder nito, na nagpapost bilang Hadamard, ay nag-publish ng disenyo sa Ethereum Research at humingi ng kritikal na feedback. Ang BB84 ay isang OP Stack rollup sa mainnet, aktibo na mula noong Setyembre 30, kung saan ang mga L2 transaction ay walang ECDSA. Ang bawat account ay ang dulo ng isang keccak-256 hash chain na binubuo mula sa isang lihim, na may 1,000 steps bilang default. Para mag-spent, ang iyong wallet ay ipinapakita ang nakaraang value sa chain, na maaaring i-verify ng sinuman sa pamamagitan ng isang pag-hash. Sa loob ng L2, ang tanging aksiyon na natitira ay ang preimage resistance ng keccak-256, na binabawasan ng Grover’s algorithm sa halos 2^128 na paggawa. Ang pagpapakita ng isang lihim ay ginagawa itong publiko, kaya idinagdag ng protokolo ang isang commit at reveal step upang i-bind ang bawat preimage sa isang transaction muna. Dalawang bagong uri ng transaction sa op-geth ang nagdadala nito, at ang sender check ay nagpalit sa ecrecover. Ang pagpapahintulot ay kinokonsumo kahit na mababawi ang call, at kung ang wallet ay mawawala sa renewal step sa huling link, patay na ang address na iyon. Ang post ay naglalaman din ng isang front-running flaw na natuklasan ng team habang isinusulat ito. Ang mga commit ay walang signature, kaya dating nagpapalit ang isang bagong commit sa isang pending one, at maaaring i-rebind ng isang attacker ang ipinakita na lihim sa kanilang sariling bayad. Isang patakaran na naging epektibo noong Oktubre 21 ay nagpapasiya na ang unang commit ang mananalo. Ang mga limitasyon ay malinaw na isinulat. Ang mga L1 deposito at withdrawal ay gumagamit pa rin ng ECDSA. Wala pa ring fault proofs, at ayon sa sariling pagsusuri ng post, hindi pa makakarating ang chain sa L2BEAT Stage 0. Ang sequencer ay pinapatakbo ng team, at ang 160-bit addresses ay nag-iwan ng halos 2^80 quantum second-preimage resistance. Hinihingi rin ng post kung maaari bang maging EIP-7702 o native account abstraction validation mode ang hash-chain accounts sa general L2s.
Ginawa ng OpenZeppelin ang Chainlink bilang default para sa cross-chain at compliance sa kanyang token tooling, at kung i-tick mo ang compliance box, babago ang lisensya ng iyong token. Isang linggo ang nakalipas, inanunsyo ng OpenZeppelin ang isang strategic partnership sa Chainlink. Ang CCIP at ACE, ang cross-chain protocol at Automated Compliance Engine ng Chainlink, ay nai-integrate na sa Contracts Wizard, ang AI tooling at dokumentasyon ng OpenZeppelin. Ang mga generator para sa ERC20, Stablecoin at RWA ay nag-aalok ng parehong opsyon. Ang pagpili ng CCIP option ay nagpapakita ng mint at burn calls na kailangan ng Chainlink burn-and-mint pool, sa likod ng sariling permissions ng token. Kasama rin nito ang pagtukoy ng isang administrator para sa CCIP registration. Ang bahaging ito ay nananatiling ang lisensya na iyong napili, dahil walang Chainlink code ang pumasok. Ang ACE option ay iba. Ito ay ipinapadala ang mga transfer, mint at burn sa isang Policy Engine na iyong i-deploy at i-configure. Sinasabi ng sariling dokumentasyon ng OpenZeppelin na ang mga token na gumagamit ng ACE ay sumasailalim sa BUSL-1.1, at ang production use ay dapat magsatisfy sa ACE license at karagdagang use grants nito. Sa maraming taon, ang isang generated na OpenZeppelin token ay nagdadala ng anumang lisensya na iyong napili, karaniwan ay MIT. Ngayon, isang checkbox lang ang nagbabago nito, at maaaring hindi napapansin ng isang junior dev na may abala. Hindi rehistrado ng generator ang iyong pool, hindi ito nagtatatakda ng permissions o sumusulat ng iyong mga patakaran. Ang pagkakapirme ng isang Policy Engine ay hindi nag-configure ng anumang patakaran, at ikaw pa rin ang responsable para sa pagtutugon sa anumang patakaran na umaapply sa iyo. Binanggit din ng anunsyo ang isang migration path mula sa OpenZeppelin Defender patungo sa Chainlink’s Runtime Environment. Hindi ito nakatago, at para sa isang RWA team na nais na ang Chainlink, ito ay nagliligtas sa tunay na integration work. Gusto ko lang na piliin ng mga builder ito nang may layunin, hindi dahil isinama ito ng wizard.
Mga smart contract maxis, Maaaring maluwag na tanggalin ng inyong Solidity compiler ang isang store na kailangan ninyo, at hindi ninyo makikita ito sa inyong source. Lumabas ang Solidity 0.8.38 noong nakaraang Huwebes. Ito ay nag-aayos ng isang bug sa Yul optimiser na nasa bawat release mula 0.8.19 hanggang 0.8.37. Ang optimizer ay nagtutala ng mga bagay na nasa memorya at storage. Ginagamit nito ang mga tala na ito upang palitan ang isang load gamit ang value na alam na nito, at upang i-skips ang isang store na sumusulat ng nasa loob na doon. Upang matukoy kung maaaring mag-overlap ang dalawang address, iginlalayout nito ang bawat isa bilang isang base variable kasama ang offset. Parehong base, iba’t ibang offset, kaya dapat iba’t ibang slot. Ang mga paglalarawan na ito ay naka-cache. Pagkatapos, may nag-reassign ng base variable. Hindi laging napapansin ng optimiser. Ngayon, ihahambing nito ang isang address na gawa sa lumang halaga kasama ang isa na gawa sa bagong halaga bilang kung mayroon silang parehong base. Papasyahan nito na iba’t iba sila, ngunit sa runtime, patutungo sila sa parehong lugar. Ang resulta ay isang stale note. Maaaring bumalik ang isang mas lumang value sa isang susunod na load. Maaaring tanggalin ang store na kailangan ninyo. Maaaring mag-hash ang keccak256 sa lugar na ito ng outdated na data. Lahat ng code na i-compile gamit ang optimizer ay eksposed. Gamit ang via-IR, maaaring makasagot ang anumang code, kahit walang inline assembly. Gamit ang default legacy pipeline, ilan lamang sa inline assembly at compiler-generated helpers. Ligtas ang unoptimized builds. Ang team ay nagbigay ng mababang severity, at ginawa nila ang isang bagay na gustong-gusto kong gawin ng lahat ng compiler team. Ibinahagi nila ang lahat ng verified contract sa database ng Sourcify gamit at hindi gamit ang fix, at pareho ang bytecode ng lahat. Kaya ito ay rare. Ang rare ay hindi katumbas ng never, lalo na kung ang inyong code ay bago at hindi pa deployed. Nakuha ang bug sa pamamagitan ng Ethereum Foundation bug bounty, at ipinakita ng pangalawang report na maaaring ma-trigger ito ng simpleng Solidity nang walang assembly.
Ang lalaking pangangailangan na maging ETH maxi. 🥳
Ang Ethereum ay Ethereum at magiging ganito lagi. Sa susunod na fork, makikita ng komunidad ng Ethereum ang tunay na kamangha-manghang katangian ng protokolo.