Ethereum
失敗した呼び出し後に継続して実行されるコントラクトは、現在、呼び出された側が意図的にリバートしたのか、単にガスが足りなくなったのかを判別する信頼できる方法を持っていない。このギャップが、不十分なガスによる攻撃の根本的な原因であり、新しいドラフト提案はEVMレベルでこれを埋めようとしている。 月曜日にEthereum Magiciansで議論が開始されたEIP-8456は、暫定的にオペコード0xA5でガス2のCALLSTATUSという命令を追加する。これは、現在のフレーム内で最新のcallまたはcreate操作の完了状態を3ビットでプッシュする。 ビット0はリバートを意味し、ビット1はガス不足などの異常な停止を意味し、ビット2は下位フレームで何らかの停止が発生したことを意味する。 作者は、現在の唯一の証拠が呼び出し後のgasleft()の算術演算であり、すべての再価格付けフォークがそのしきい値を破壊してきたと指摘している。提案されているEIP-8037の二次元ガスは、その貯蔵量がGASオペコードを通じて見えないため、この算術演算をさらに弱める。 では、なぜ3番目のビットが必要なのか？ 実際の呼び出しのほとんどは、プロキシ、OpenZeppelinのfunctionCallラッパー、Multicall3、またはERC-1271署名チェッカーなどの中間者を経由する。もし直接的な呼び出し先の終了状態のみが報告されるなら、ガス不足停止をキャッチして理由付きでリバートするラッパーは、意図的なリバートのように見えることになる。 ドラフトは、各フレームを上昇する粘着性のフラグを保持し、ガスのみを制御する送信者が呼び出し元に単純なリバートを読み込ませることは不可能にする。 これは原因ではなく結果を報告し、呼び出し先は依然としてINVALIDを使用して意図的に停止を発生させることができる。 これは、展開済みコントラクトがそれを読み取らないため、この命令がリリースされた後に書かれたコードのみを保護する。 現在までに外部レビューはなく、オペコード番号は未確定であり、58のリストされたケースに対するプロトタイプとテストもまだ未実装である。 リンク - https://t.co/KnByUBgWrY
Ethereumウォレットの多くは、アドレスを知られた誰でもあなたの全財務履歴を表示できる状態です。Ethereum財団は、これをもはや「プライバシーの余裕」ではなく、セキュリティ上の脆弱点と位置づけています。 月曜日、財団は過去1週間の攻撃や悪用事例を通じて、プライバシーとセキュリティを別々の目標として扱うことはできないという点が明確になったと発表しました。 彼らの主張は、プライバシーがデフォルトであれば、攻撃者がオンチェーン履歴をあなたに不利に使うことをそれほど心配する必要がない、というものです。 この投稿では、財団のプライバシー最優先ウォレットツールプロジェクト「Kohaku」の最新情報が引用されています。 JavaScriptリポジトリは、ウォレットチームが1つずつ取り込めるようにパッケージに分割されています。 Privacy PoolsおよびTornado Cash用のライブラリに加え、READMEには現在「メンテナンス中」とマークされているRailgunライブラリも含まれています。 プラグインパッケージは、シャーデッドプールプロトコル用の標準インターフェースを定義し、ウォレットがすべてのプロトコルを同じ方法で操作できるようにします。 プロバイダーパッケージは、ethers、viem、Helios、Colibriを抽象化します。 リポジトリには、ポスト量子ERC-4337アカウントも同梱されています。 Rustのクレートは別の姉妹リポジトリに存在します。 私は、ユーザーに資金を移動させる新たなプライバシーウォレットではなく、SDKとして構築されている点を好ましく思います。 このアイデアは、既存のウォレットが各チームで3つのプロトコルを再実装することなく、シャーデッドフローを追加できるようにすることです。 READMEは現状を率直に記述しています。 一部の機能は本番環境向けではないとマークされており、パッケージには監査されていないコードが含まれています。 AmbireのJordan Enevは先週金曜日、チームが数ヶ月にわたり統合をテストしてきたと述べており、公開日は未定です。 VitalikとNicolas Consignyは、@EFDevconで来週火曜日にAmbireと連携してEthereumメインネット上でKohakuをデモする予定です（セッションリストより）。 リポジトリはこちら - https://t.co/egNbLgAo0J
あなたのターミナルは、クラウドAPIを呼び出さずにあなたに返答できるようになりました。 土曜日、OllamaはmacOS向けにテキスト-to-スピーチ機能を含むバージョン0.40.11をリリースしました。 最初の音声モデルはGradiumが開発した小さなTTSモデル群であるPhononです。 `ollama pull phonon`で取得し、他のモデルと同じように実行できます。 開発者が実際に注目するポイントはAPIです。 Phononは、ローカルホスト上のOpenAI互換の`/v1/audio/speech`エンドポイントと連携します。 すでにOpenAI SDKを使用して音声処理を行っている場合、ドキュメントによると、新しいベースURLを設定するだけで済みます。 音声が生成されている間にレスポンスがストリーミングされるため、全文が完了する前に再生を開始できます。 チャットモデルの返答をPhononに直接パイプし、最初の文が完了した時点で音声再生を開始することも可能です。 出力はデフォルトでWAV形式の24kHzモノラル、または要求すれば生の16ビットPCM形式です。 ドキュメントには、簡単に制限に引っかかる点がいくつか記載されています。 1リクエストあたり最大4,096文字まで対応していますが、`ollama run`は長いテキストを自動で分割します。 価格、記号、メールアドレス、URLは文字単位で読み上げられ、数値形式の日付はそのまま読み上げられます。そのため、ドキュメントでは日付を文字列で記述することを推奨しています。 speedやinstructionsなどの非対応オプションは静かに無視されるのではなく、400エラーを返します。 ライセンスについては、製品をリリースする前に注意深く確認してください。 デフォルトの英語PhononモデルはApache 2.0です。 40Mサイズのフランス語、ドイツ語、スペイン語、ポルトガル語および多言語バージョンはCC BY-NC 4.0であり、商用利用は不可です。 Ollamaはまた、M5 Max搭載のMacBook Proでは、Gradium自体のランタイムよりも35%高速に動作したと述べていますが、これは独立したベンチマークではなくGradium自身の基準です。 現在の音声機能はApple Silicon専用で、WindowsおよびLinux対応は近日中に予定されています。
ゼロ署名を受け付けるEthereum L2はセキュリティバグに見えるが、BB84は量子攻撃を回避するために意図的にそれを実装している。 先週末、Hadamardという名前で投稿している創設者は、Ethereum Researchにその設計を公開し、批判的なフィードバックを求めた。 BB84はメインネット上で9月30日から稼働しているOP Stackロールアップであり、L2トランザクションには一切ECDSAが使用されていない。 各アカウントは、シークレットから構築されたkeccak-256ハッシュチェーンの先端であり、デフォルトで1,000ステップ分ある。 支払いを行う際、ウォレットはチェーン内の前の値を公開し、誰でも1回のハッシュ計算で検証できる。 L2内部では、keccak-256のプリイメージ耐性のみが仮定され、これはGroverのアルゴリズムにより約2^128の計算量に削減される。 シークレットを公開するとそれが一般に知られてしまうため、プロトコルは各プリイメージを1つのトランザクションにバインドするためのコミットとリベールのステップを追加している。 op-gethにはこの処理を担う2つの新しいトランザクションタイプが導入され、送信者検証はecrecoverの代わりに実装されている。 呼び出しがリバートしても認証は消費され、ウォレットが最後のリンクの更新ステップを逃した場合、そのアドレスは無効となる。 この投稿には、開発チームが作成中に発見したフロントランニングの脆弱性も記載されている。 コミットには署名が含まれないため、以前は新しいコミットが保留中のコミットを上書きでき、攻撃者は公開されたシークレットを自らの支払いに再バインドすることが可能だった。 10月21日に適用されたルールにより、最初のコミットが有効となる。 制限事項は明確に記されている。 L1の入金と出金には依然としてECDSAが使用される。 まだフォールトプローフは実装されておらず、投稿自身でもこのチェーンはL2BEATのStage 0にすら達していないと述べられている。 シーケンサは開発チームが運用しており、160ビットアドレスは約2^80の量子第二原像耐性を残す。 また、投稿ではハッシュチェーンアカウントが一般的なL2上でEIP-7702またはネイティブなアカウント抽象化検証モードとして採用される可能性についても問いかけている。
OpenZeppelinは、トークンツールリングにおいてChainlinkをクロスチェーンおよびコンプライアンスのデフォルトとして採用し、コンプライアンスチェックボックスをオンにすると、トークンのライセンスが変更されます。 一週間前、OpenZeppelinはChainlinkとの戦略的パートナーシップを発表しました。 ChainlinkのクロスチェーンプロトコルであるCCIPと、自動コンプライアンスエンジンであるACEは、OpenZeppelinのAIツールであるContracts Wizardおよびドキュメントに組み込まれました。 ERC20、ステーブルコイン、RWAジェネレーターのすべてが、両方のオプションを提供しています。 CCIPオプションを選択すると、トークンの独自の権限の背後で、Chainlinkのバーン＆マインドプールが必要とするマインドとバーンの呼び出しを公開します。 また、CCIP登録用の管理者を指定します。 この部分では、選択したライセンスがそのまま維持されます。Chainlinkのコードは一切含まれないためです。 一方、ACEオプションは異なります。 これは、振替、マインド、バーンをあなたがデプロイして設定するポリシーエンジンに転送します。OpenZeppelinの公式ドキュメントによると、ACEを使用するトークンはBUSL-1.1の対象となり、本番利用にはACEライセンスおよびその追加使用許可を満たす必要があります。 これまで、生成されたOpenZeppelinトークンは、選択したライセンス（通常はMIT）をそのまま保持していました。 しかし、今や単一のチェックボックスをオンにすることでそのライセンスが変更され、急いでいるジュニア開発者は気づかない可能性があります。 ジェネレーターはプールを登録せず、権限を設定せず、ポリシーを記述しません。 ポリシーエンジンを接続しても、任何のポリシーが自動設定されることはありません。あなた自身が適用されるルールを満たす責任を負います。 発表では、OpenZeppelin DefenderからChainlinkのRuntime Environmentへの移行パスにも言及されています。 これらすべては隠されているわけではなく、すでにChainlinkを望んでいるRWAチームにとっては、実際の統合作業を削減できます。 ただ、私は開発者がウィザードがそこに置いたからという理由ではなく、意図的に選択してほしいと思っています。
スマートコントラクトマキシのみなさん、 Solidityコンパイラが、あなたのソースコードには存在しないにもかかわらず必要なストアを静かに削除していた可能性があります。 Solidity 0.8.38は先週木曜日にリリースされました。 このバージョンでは、0.8.19から0.8.37までのすべてのリリースに含まれていたYulオプティマイザのバグを修正しています。 オプティマイザは、メモリとストレージに何が格納されているかを記録し、その記録を使って、既に知っている値でロードを置き換えたり、すでに存在する値を書き込むストアをスキップしたりします。 2つのアドレスが重複するかどうかを判断するため、オプティマイザはそれぞれのアドレスを「ベース変数＋オフセット」で表現します。ベースが同じでオフセットが異なる場合、異なるスロットであると判断されます。これらの表現はキャッシュされていました。 その後、誰かがベース変数を再割り当てします。オプティマイザは常にその変更に気づくとは限りません。 今や、古い値から構築されたアドレスと新しい値から構築されたアドレスを、同じベースを持つものとして比較してしまいます。オプティマイザはこれらが異なると判断しますが、実行時には同じ場所を指しています。 その結果、古くなった記録が残ります。 後続のロードが古い値を返す可能性があります。 必要なストアが削除される可能性があります。 その場所に対するkeccak256は、古くなったデータをハッシュしてしまう可能性があります。 オプティマイザを有効にしてコンパイルされたコードのみが影響を受けます。 via-IRを使用する場合、インラインアセンブリがなくてもすべてのコードが影響を受けます。 デフォルトのレガシーパイプラインでは、一部のインラインアセンブリとコンパイラが生成するヘルパー関数のみが影響を受けます。 最適化されていないビルドは安全です。 開発チームはこのバグの深刻度を低めと評価しており、私はすべてのコンパイラチームに望むような対応を行いました。 彼らはSourcifyデータベース内のすべての検証済みコントラクトを、修正前と修正後でそれぞれ再コンパイルし、すべてのバイトコードが同一であることを確認しました。 したがって、このバグは稀です。 稀であることは「決して発生しない」と同じではありません。特に、あなたのコードが新しく、まだデプロイされていない場合です。 このバグはEthereum Foundationのバグバウンティプログラムを通じて発見され、その後の別の報告では、アセンブリを使用しない通常のSolidityコードでもこのバグを引き起こせることを示しました。
ETHマキになりたいという男性の衝動。🥳
EthereumはEthereumであり、永遠にそうであり続ける。 次回のフォークで、Ethereumコミュニティはプロトコルの真の魔力を体験するだろう。