在一次調用失敗後仍持續運行的合約，今天沒有可靠的方法來判斷被調用方是故意回退，還是僅僅耗盡了gas，這取決於發送方的選擇。 這一缺口正是gas不足惡意攻擊的根源，而一項新的草案提案試圖在EVM層面填補這一漏洞。 EIP-8456於週一在Ethereum Magicians上開放討論，新增了一個稱為CALLSTATUS的指令，暫定操作碼為0xA5，耗費2 gas。 該指令會將當前幀中最近一次調用或創建操作的完成狀態以三位二進制位的形式推入堆棧。 位0表示回退，位1表示異常中止（例如gas耗盡），位2表示下方某幀發生了中止。 作者指出，目前唯一的證據是調用後的gasleft()算術運算，而每一次重新定價分叉都破壞了這些閾值。 EIP-8037提出的二維gas機制將使這種算術更加無效，因為其儲備池無法通過GAS操作碼訪問。 那麼，為何需要第三位？ 大多數實際調用都經過中介層，例如代理、OpenZeppelin的functionCall封裝器、Multicall3或ERC-1271簽名檢查器。 如果僅報告直接被調用方的結束狀態，一個捕獲gas耗盡中止並以原因回退的封裝器，將看起來像是一次故意回退。 該草案保留了一個粘性標誌，會向上傳遞至每一幀，因此僅控制gas的發送方永遠無法讓調用方讀取到純粹的回退。 它報告的是結果而非原因，被調用方仍可通過INVALID故意產生中止。 它僅保護在其發布後編寫的代碼，因為已部署的合約無法讀取它。 目前尚無外部審查，操作碼編號仍開放，且針對58個列出案例的原型及測試仍在等待中。 連結 - https://t.co/KnByUBgWrY
大多數以太坊錢包仍會向任何擁有您地址的人顯示您的完整財務歷史，而以太坊基金會現在將此視為一個安全漏洞，而非僅僅是隱私的加分項。 週一，基金會發文表示，過去一週的攻擊和漏洞利用讓他們更清楚地意識到：隱私與安全不能被視為獨立的目標。 他們的觀點是，當隱私成為預設時，您就無需過度擔心攻擊者利用您的鏈上歷史來針對您。 該文章引用了基金會以隱私為先的錢包工具項目 Kohaku 的最新進展。 該 JavaScript 儲存庫將功能拆分為多個套件，錢包團隊可逐個採用。 其中包含 Privacy Pools 和 Tornado Cash 的函式庫，以及一份目前標記為「維護中」的 Railgun 函式庫。 一個插件套件定義了遮蔽池協議的標準介面，使錢包能以相同方式與所有協議互動。 一個提供者套件對 ethers、viem、Helios 和 Colibri 進行了抽象化。 該儲存庫還內建了一個後量子 ERC-4337 帳戶。 Rust 套件則位於另一個獨立的姊妹儲存庫中。 我喜歡這是以 SDK 的形式呈現，而非又一個要求用戶轉移資金的隱私錢包。 其理念是讓現有錢包無需各自重新實現三種協議，即可新增遮蔽流程。 README 明確說明了當前狀態： 部分功能標示為尚未準備好用於生產環境，且套件中包含未經審計的程式碼。 Ambire 的 Jordan Enev 上週五表示，團隊已花費數月測試整合，但尚未公布任何公開上線日期。 根據活動議程，Vitalik 與 Nicolas Consigny 將於下週二在 @EFDevcon 上與 Ambire 一起在以太坊主網上示範 Kohaku。 儲存庫連結：https://t.co/egNbLgAo0J
您的終端現在可以回應您，有趣的是，它無需調用任何雲端 API 即可做到這一點。 於週六，Ollama 推出了 0.40.11 版本，為 macOS 增加了文字轉語音功能。 首個語音模型為 Phonon，這是 Gradium 開發的一系列小型 TTS 模型。 您可透過 ollama pull phonon 拉取並像其他模型一樣運行它。 開發者真正關心的部分是 API。 Phonon 與本機 localhost 上的 OpenAI 兼容 /v1/audio/speech 端點配合使用。 如果您的代碼已使用 OpenAI SDK 進行語音處理，官方文件指出您只需更換新的基底 URL 即可。 響應會在語音生成時即時串流，因此播放可在完整文字輸出前開始。 您甚至可直接將聊天模型的回覆傳入 Phonon，它會在第一句話完成後立即開始朗讀。 輸出預設為 24 kHz 單聲道 WAV 格式，若要求則可輸出原始 16 位元 PCM。 文件中列出了幾個容易觸發的限制。 每個請求最多支援 4,096 個字元，不過 ollama run 會自動將較長文字分割。 價格、符號、郵件和網址會被逐字拼出，而數字日期則按原樣朗讀，因此文件建議以文字形式書寫日期。 不支援的選項（如速度或指令）會返回 400 錯誤，而非被靜默忽略。 在發布任何產品前，請仔細閱讀授權條款。 預設的英文 Phonon 模型採用 Apache 2.0 授權。 40M 的法語、德語、西班牙語、葡萄牙語及多語言變體採用 CC BY-NC 4.0 授權，禁止商業用途。 Ollama 還提到，在 M5 Max MacBook Pro 上，其運行速度比 Gradium 自家的運行時快了 35%，但此為其自身基準測試結果，非獨立測試。 目前語音功能僅支援 Apple Silicon，Windows 和 Linux 支援列為即將推出。
一個接受零簽名的以太坊 L2 聽起來像是安全漏洞，但 BB84 是故意這樣做，以避開量子攻擊。 上個週末，其創始人 Hadamard 在 Ethereum Research 上發布了該設計，並請求批判性反饋。 BB84 是一個運行於主網的 OP Stack rollup，自 9 月 30 日起上線，其 L2 交易完全不使用 ECDSA。 每個帳戶都是由秘密構建的 keccak-256 哈希鏈的頂端，預設包含 1,000 步。 要支出時，您的錢包會揭示鏈中的前一個值，任何人都可以通過一次哈希驗證。 在 L2 內部，唯一保留的假設是 keccak-256 的原像抵抗性，而 Grover 算法將其削弱至約 2^128 的運算量。 揭示秘密會使其公開，因此協議增加了一個提交與揭示步驟，以將每個原像綁定至單一交易。 op-geth 中新增了兩種交易類型來處理此機制，發送者檢查取代了 ecrecover。 即使呼叫回退，授權仍會被消耗；若錢包錯過最後一鏈的續約步驟，該地址即失效。 該文章也提及團隊在撰寫時發現的一個搶跑漏洞。 提交不帶簽名，因此新提交曾可取代待處理的提交，攻擊者可將已揭示的秘密重新綁定至自己的付款。 自 10 月 21 日起生效的規則規定，第一個提交為有效。 限制條件明確列出： L1 的充幣與提幣仍使用 ECDSA。 目前尚無錯誤證明，且根據文章所述，該鏈甚至未達到 L2BEAT 第 0 階段。 序列器由團隊運行，160 位地址僅提供約 2^80 的量子次原像抵抗性。 該文章也提問：哈希鏈帳戶能否成為 EIP-7702 或通用 L2 上的原生帳戶抽象驗證模式？
OpenZeppelin 已將 Chainlink 設為其代幣工具中跨鏈與合規的預設選項，若你勾選合規框，你的代幣授權將會改變。 一週前，OpenZeppelin 宣布與 Chainlink 建立戰略合作關係。 CCIP 和 ACE——Chainlink 的跨鏈協議及其自動合規引擎——現已內建於 Contracts Wizard，即 OpenZeppelin 的 AI 工具與文件中。 ERC20、穩定幣和 RWA 生成器均提供這兩個選項。 選擇 CCIP 選項會使代幣對 Chainlink 燒毀與鑄造池所需的 mint 和 burn 調用開放，並透過代幣自身的權限進行控制。 同時也會指定一名 CCIP 註冊管理員。 此部分保留你原本選擇的授權，因為並未引入任何 Chainlink 代碼。 ACE 選項則不同。 它會將轉帳、鑄造與燒毀操作轉發至你部署並配置的政策引擎。OpenZeppelin 自己的文件指出，使用 ACE 的代幣將受 BUSL-1.1 授權約束，生產環境使用必須符合 ACE 授權及其額外使用授權。 多年來，由 OpenZeppelin 生成的代幣僅承襲你所選擇的授權，通常是 MIT。 如今，單單一個勾選框便會改變這一點，而一位趕時間的初級開發者可能根本不會注意到。 該生成器並不會為你的池子註冊、設定權限或撰寫你的政策。 附加政策引擎也不會自動配置任何政策，你仍需自行負責符合適用於你的所有規則。 該公告亦提及從 OpenZeppelin Defender 遷移至 Chainlink 運行環境的路徑。 這些內容並未隱藏，對於已經希望使用 Chainlink 的 RWA 團隊而言，這能節省實際的整合工作。 我只是希望開發者能主動選擇此選項，而非因為向導自動放置了它。
智能合約愛好者， 您的 Solidity 編譯器可能已悄悄刪除了您需要的儲存操作，而您在原始碼中永遠不會發現。 Solidity 0.8.38 於上週四發布。 它修復了從 0.8.19 到 0.8.37 每個版本中都存在的 Yul 優化器錯誤。 優化器會記錄記憶體和儲存中的內容， 並利用這些記錄，以已知的值取代載入操作，或跳過寫入相同資料的儲存操作。 為判斷兩個位址是否可能重疊，它將每個位址描述為基礎變數加上偏移量。 相同基礎、不同偏移，因此必須是不同插槽。 這些描述會被快取。 然後有人重新指派了基礎變數， 但優化器並非總能察覺。 現在，它會將一個基於舊值構建的位址，與一個基於新值構建的位址進行比較，並假設它們共享同一基礎。 它判斷它們不同，但在執行時它們指向同一位置。 結果是過時的記錄。 後續的載入操作可能返回舊值， 您需要的儲存操作可能被移除， 對該位置進行 keccak256 運算可能雜湊過時的資料。 僅當啟用優化器編譯的程式碼才會受影響。 使用 via-IR 時，任何程式碼都可能觸發此問題，即使沒有內聯組合語言。 使用預設的傳統流程時，僅部分內聯組合語言和編譯器生成的輔助函式會受影響。 未優化的建置是安全的。 團隊將此問題評為低嚴重性，並做了我期望每個編譯器團隊都做的事： 他們使用修復前後的版本，重新編譯了 Sourcify 資料庫中所有已驗證的合約，結果所有位元組碼均完全相同。 因此，此問題極為罕見。 但「罕見」不等於「從未發生」，尤其是當您代碼是新寫的且尚未部署時。 此錯誤最初由以太坊基金會的漏洞懸賞計畫發現，第二份報告顯示，即使沒有使用組合語言的純 Solidity 代碼也可能觸發此問題。
男性對成為 ETH 最大支持者的衝動。🥳
以太坊就是以太坊，將永遠如此。 在下一次分叉中，以太坊社群將見到該協議的真正魔力。