<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Blockchain on Debimate</title><link>https://debimate.jp/tags/blockchain/</link><description>Recent content in Blockchain on Debimate</description><image><title>Debimate</title><url>https://debimate.jp/images/default-ogp.webp</url><link>https://debimate.jp/images/default-ogp.webp</link></image><generator>Hugo -- 0.166.0</generator><language>ja-JP</language><lastBuildDate>Tue, 10 Nov 2026 22:30:20 +0900</lastBuildDate><atom:link href="https://debimate.jp/tags/blockchain/index.xml" rel="self" type="application/rss+xml"/><item><title>ERC-1967 / ERC-7201 - プロキシで更新できるコントラクトと storage の配置</title><link>https://debimate.jp/notes/blockchain-systems/upgradeable-proxy/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/upgradeable-proxy/</guid><description>&lt;p&gt;カウンターの &lt;code&gt;increment()&lt;/code&gt; を 1 回呼んだだけで、そのコントラクトが以後まともな値を返さなくなることがあります。後述の実験では、呼び出しの前に保存領域の slot 0 にあった &lt;code&gt;0x…5fbdb2315678afecb367f032d93f642f64180aa3&lt;/code&gt; が、呼び出しの後に末尾が &lt;code&gt;aa4&lt;/code&gt; に増えていました。この値は、カウンターの値ではなく、処理を任せる先のコントラクトのアドレスでした。&lt;/p&gt;</description></item><item><title>Ethereum Hard Forks - EVM の規則は全ノードで同時に切り替わる</title><link>https://debimate.jp/notes/blockchain-systems/ethereum-hard-forks/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/ethereum-hard-forks/</guid><description>&lt;p&gt;&lt;a href="https://soliditylang.org/"&gt;Solidity&lt;/a&gt; のコンパイラ（solc）を 0.8.19 から 0.8.20 に上げると、ソースを 1 行も変えていないのに、一部のチェーンでデプロイが失敗することがあります。0.8.20 から、出力するバイトコードに PUSH0 という命令が入るようになったからです。&lt;/p&gt;</description></item><item><title>ERC-7562 - アカウント抽象化の検証に Bundler が課す規則</title><link>https://debimate.jp/notes/blockchain-systems/erc-7562/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/erc-7562/</guid><description>&lt;p&gt;&lt;a href="https://eips.ethereum.org/EIPS/eip-7562"&gt;ERC-7562&lt;/a&gt; は、&lt;a href="../erc-4337/"&gt;ERC-4337&lt;/a&gt; の Bundler が UserOperation を受け付ける前に、検証のコードが使って良い命令と storage を決めた規則です。スマートアカウントの検証（&lt;code&gt;validateUserOp&lt;/code&gt;）には任意のコードを書けますが、Bundler が mempool に入れるのは、この規則の範囲で書かれた検証だけです。&lt;/p&gt;</description></item><item><title>EIP-712 / ERC-1271 - 型付きの署名と、コントラクトの署名</title><link>https://debimate.jp/notes/blockchain-systems/eip-712/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/eip-712/</guid><description>&lt;p&gt;EIP-712 は、Ethereum で構造を持つデータ（型と項目名の付いたデータ）をハッシュし、署名する手順を定めた規格です。ウォレットは署名を求める画面で &lt;code&gt;spender&lt;/code&gt;・&lt;code&gt;value&lt;/code&gt;・&lt;code&gt;deadline&lt;/code&gt; のような項目を並べて表示でき、コントラクトは同じ手順でハッシュを計算して署名を検証します。ERC-1271 は、秘密鍵を持たないコントラクトのアカウントが「この署名は自分のものとして有効か」を返すための関数の規格です。&lt;/p&gt;</description></item><item><title>ERC-721 - 1 つずつ区別できるトークン（NFT）の所有と移転</title><link>https://debimate.jp/notes/blockchain-systems/erc-721/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/erc-721/</guid><description>&lt;p&gt;ERC-721 は、Ethereum 上で 1 つずつ区別できるトークンを扱うための規格です。このトークンは NFT（Non-Fungible Token、代替できないトークン）と呼ばれます。&lt;a href="../erc-20/"&gt;ERC-20&lt;/a&gt; がアドレスごとの数量を記録するのに対して、ERC-721 は &lt;code&gt;tokenId&lt;/code&gt; という番号ごとに所有者を記録します。ゲームのアイテム、会員証、作品の所有証明などに使われます。&lt;/p&gt;</description></item><item><title>ERC-4337 - プロトコルを変えないアカウント抽象化</title><link>https://debimate.jp/notes/blockchain-systems/erc-4337/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/erc-4337/</guid><description>&lt;p&gt;&lt;a href="https://eips.ethereum.org/EIPS/eip-4337"&gt;ERC-4337&lt;/a&gt; は、Ethereum のプロトコルを変えずに、スマートコントラクトのアカウントを取引の送り主のように使えるようにする規格です。署名の検証方法をアカウントのコードで決められるので、複数人の承認や鍵の差し替えを組み込めます。手数料を別の誰かに肩代わりしてもらうこともできます。&lt;/p&gt;</description></item><item><title>Multisig - 複数の鍵で承認する仕組み</title><link>https://debimate.jp/notes/blockchain-systems/multisig/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/multisig/</guid><description>&lt;p&gt;マルチシグ（multisig、multi-signature）は、登録した n 個の鍵のうち m 個の署名が揃った時だけ資産を動かせるようにする仕組みです。「3 個のうち 2 個」なら 2-of-3 と書きます。1 個の鍵を盗まれても送金されず、1 個を失くしても残りの 2 個で資産を動かせます。&lt;/p&gt;</description></item><item><title>Snowman - 少数への問い合わせを繰り返す Avalanche の合意</title><link>https://debimate.jp/notes/blockchain-systems/snowman/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/snowman/</guid><description>&lt;p&gt;Snowman は、&lt;a href="https://www.avax.network/"&gt;Avalanche&lt;/a&gt; のチェーンが次に繋ぐブロックを決める合意プロトコルです。各ノードは、無作為に選んだ少数のバリデータ（validator、合意に参加するノード）に「どのブロックを支持しているか」を尋ね、同じ答えが規定の回数だけ続いたらブロックを確定します。&lt;a href="https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance"&gt;PBFT&lt;/a&gt;（Practical Byzantine Fault Tolerance）や &lt;a href="https://github.com/cometbft/cometbft"&gt;CometBFT&lt;/a&gt;（Cosmos 系のチェーンが使う合意エンジン）のように、全員の票を集めて 2/3 を数えることはしません。&lt;/p&gt;</description></item><item><title>Ethereum Address - アドレスの決まり方</title><link>https://debimate.jp/notes/blockchain-systems/ethereum-address/</link><pubDate>Tue, 10 Nov 2026 00:00:00 +0000</pubDate><guid>https://debimate.jp/notes/blockchain-systems/ethereum-address/</guid><description>&lt;p&gt;&lt;code&gt;0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266&lt;/code&gt; は、開発用のローカルノードである &lt;a href="https://getfoundry.sh/anvil/overview/"&gt;Anvil&lt;/a&gt; が最初に用意するテスト用アカウントのアドレスです。chain ID（チェーンを区別する番号）を 31337 にしても 31338 にしても、このアカウントは同じアドレスで現れます。&lt;/p&gt;</description></item></channel></rss>