結論から言います。ぼくはクリプトが未来だと考えています。

その理由を語るには、結構な労力と時間が必要なのかもしれませんが、言語化することによって、自分の頭の整理にもなるので、ここで僕はそれに挑戦したいと思います。

少し想像してみてくださいね。

現実世界のどんなものでも（サービス、不動産、債権、キャッシュ、買い物、国債、ゴールド、ホテルのいち日泊まる権利、などなどありとあらゆるもの）、また、バーチャル世界にあるどんなものでも（ゲームアイテム、音楽、バーチャル世界の土地、ゲームキャラのスキンなどなど）、インターネット上でボーダレスにミドルマンなしで、オープンに公平に取引ができる時代

国境など関係なしにスムーズに多文化多言語協力関係の組織を築けて、そして報酬を直接的に自分のアカウントでもらえる。なにか没頭できるようなことに関してグローバルに募集して組織を一瞬に作って何かをやったり、収益化できたり

これが僕が考えたブロックチェーンの近未来です。もちろん、様々な壁やハードルが立ちはだかっているのは間違いないです。けれど、それが何年かかるかわかりませんが、近いうちそれに近い形態になると思います。なぜなら、そういったインフラはすでにできてきて改善もどんどんされていっている時代なので、そうなっていくのは目に見えたからです。

また、自分が考えた世界に比べて実際にはもっと進んでいる可能性が結構高いと思います。なぜかというと、人間は線形的に物事を考えがちであり、今の状況がよりよい状況になるという想像しかできません。実際には今では考えたことのない状況になったりするのもあり得ます。自分が想像力に欠けるのも無理はありません。ただ、現時点に基づいて予測をしないと何も始まりませんよね。

結果を言ったのはいいけど、なんでそうなるんだ？と思うと思いますので、ここから述べていきます。言いたいことが山程あるので、記事はシリーズ化します。

リアルからバーチャルへ​

大きな理由としては、人間社会はリアルからバーチャルへ遷移していることが大きな理由です。

Metaverse​

最近だと、メタバースというワードがかなり耳に入ってくる様になったのではないでしょうか。メタバースと聞くと、わけがわからないのかもしれませんが、自分の理解ですと、このワードはまだ意味が定まっていないと思います。あえて意見を言わせてもらうと、メタバースはいわゆるバーチャル世界そのものの定義になります。誰でも作れますし、すでにあるインターネットそのものも広義的にメタバースなのです。

例えば、すでに僕達のグーグルアカウントあるいはイーサリアムウォレットのアカウントとかがメタバースの僕達の分身と理解してもよいでしょう。ただ、このメタバースはまだまだ初歩的な段階なので、本当に使えるバーチャル世界と言えるのかというところが確かにあります。

"Software is eating the world"​

英語圏ではとても有名な言葉があります。それはこの「Software is eating the world. (ソフトウェアは世界を飲み込んでいる)」という言葉です。

これは 2011 年に A16Z というとても先進的な視野を持つ VC のファンダーが話した言葉です。その後の世界はご存知の通り、彼が言った通りになり、ソフトウェアは世界を飲み込んでいきました。

Companies' market cap ranking​

上の画像でわかるように、その過程では世界時価総額ランキングの上位はほとんどインターネット企業、いわゆる FANG または GAFA と呼ばれる企業に独占されるようになりました。

一昔前日本企業があれだけ独占していたランキングですが、日本がインターネットの波を完全に逃したせいで、今やランキングの下位となっています。アメリカの企業がほとんどで、たまに中国や韓国の企業が現れて、31 位になって初めてトヨタが出てきています。世の中の時流はものづくり時代からインターネット時代になったということです。

こういった企業のサービスを使ったことがある方はわかると思いますが、とても役に立っていて、一度使うとなかなかそのエコシステムから抜け出せなくなります。このように、ソフトウェアが世界を飲み込んでいます。しかし、これでは終わらないのです。

これは見方を変えると、人類がバーチャル世界へ進んだ第一歩に過ぎず、まだまだ道のりは長いです。現在こういった大企業が作っている初歩的な「メタバース」の世界はこれはこれでインフォメーションをデジタル化することに成功していますが、まだお金というものは現実世界から切り離した形でデジタル化できていません。（例えば paypay とかはお金と同等なように思われますが、独立した形でお金というものではなく、結局は日本円の分身であり、paypay の運用会社に大きく依存した形です → 運用会社はその世界の神様です）

神様のいない（非中央集権的な）世界​

ブロックチェーンはこれを解決してくれます。ブロックチェーンは今のインターネットにおけるなんでもコピーできてしまう問題を解決し、バーチャルなものにリアル世界と同じような誰にも関与されない希少性、改ざん耐性を与えて、初めてバーチャル世界を「世界」として成り立たせることができるのです。先程、神様といったのは例えばあなたの生きる世界に神様がどこかの人間になると、怖くありませんか？その人の決定で何もかも変わる可能性があります。極端な話、生存の権利さえも奪われるリスクが潜んでいます。そんな世界ってディストピアで嫌ですよね？

すでに気づいてるかと思いますが、今僕達はまさにこの神様がいる（中央集権的な）インターネット世界に住んでいます。youtuber さんはわけがなくチャンネル停止されるし、アマゾンでは明確な理由が与えられず出店停止処分になったりします。ツイッターだってトランプさんのアカウントがバンされたことで有名でしたね。

もちろん、悪さをしてバンされたらそれはそれで仕方ないのですが、ただ会社側の一任ですべてが決定されてしまうのは果たして正義なのかどうかは議論の余地があるのではないでしょうか？

実際にイーサリアムの創始者であるビタリック氏はワールドオブワークラフトの MMO ゲーム内の好きなキャラクタが弱体化されたことで嫌気が差したのがイーサリアムというブロックチェーンの始まりだとも言われています。神様のいない世界は人類史上なかったので、さぞかしビタリック氏は作りたかったんだろうね。

ブロックチェーンであれば、神様のいない世界が作れるという点が非常に大きいです。これによって万人平等で同じルールに則った世界が構築できる様になったといえます。

ただ、今はこの大きな課題解決の現在進行系であり、あれやこれの不具合や満足の行かない点がたくさんあるでしょう。

そういったときには、僕の意見としては未来志向がいいです。未来志向は何かというと、クレーマーにならず暖かく見守ってあげて一緒に成長するのがベストだと思います。クレーマーになるのは簡単であり、課題を解決する側に回って色々考えて行動することこそ社会が進化していく力となっていくので、結局はみんなウィンウィンになるわけです。

話がそれましたが、人間社会はリアルからバーチャルへという大きな方向性は間違いがなく、すでに自分たちの活動はたくさんインターネットへ移植しています。これが加速していきます。

Human society's GDP​

出典

人類の歴史における 一人当たりの GDP は上のグラフを見て下さい。わかるかと思いますが、指数関数的に増加していることがわかります。これの主な要因には、一つとしてリアルな世界ではリアルな資源の開発ができる部分がたくさんあったことと、技術的な進歩が爆発的に増加したと思います。産業革命以後、人類はパンドラのボックスを開いたように、知の集合体として大きく成長し、もはや産業革命のときみたいに一種の技術進歩で大きく人類が前進するという状況ではなくなっています。

今現在だけでも、自分の認識している範囲ですと、5G、ブロックチェーン、AI、Iot など、様々な技術が雨後の筍のように現れてきて、同時に進化して融合しつつ、次の産業革命として人類社会を爆発的に前進させるでしょう。想像を絶するような世界がまた 10 年 20 年後には現れて人間社会のこれまでの知識、経験、哲学や価値観をすべて考え直さなければならないのかもしれません。今はこれだけ進化の速度が早くて、毎日が新たな歴史のページをめくっているようなものです。

Why human will go virtual​

また、なぜバーチャルが良いのかという疑問もあろうかと思います。

昔マルクスの人口論でも有名ですが、人類の発展はいずれ現実世界の限界を迎えてしまい、減速してしまうでしょうという理論です。自分は人間社会の GDP はますます増加していくことは間違いないと思っています。なぜなら現実世界は制約がありますが、バーチャル空間は制約が少ないからです。

人間は大航海時代以来、影響範囲を拡大しようと、地球をたくさん探索し続け開発してきました。今や宇宙へ行こうとしています。ただ、宇宙開発はそう簡単にできるわけではありません。宇宙の開発を突破するには時間と空間というとてつもなく困難な壁がありました。そこで、この制限がかかっていないバーチャル空間の開発が容易なのではないかと普通は考えます。バーチャルな世界にいると、瞬間移動もできてスペースの問題も解決されます。

Web3 が来ると人類のバーチャル化が更に加速していきます。価値が容易にインターネット内でやり取りできるようになり、機械と機械がミドルマンなしで価値のやり取りができるようになります。少し予言しますが、将来はこの機械間の価値の交換がメインになるでしょう。いわゆるお金については、ますますプログラマブルマネー（コーディングで制御できるお金）になっていくわけです。

バーチャルな世界で生きている人間にとっては当然バーチャル世界ネイティブな資産が生まれてもおかしくないでしょう。それがクリプト（仮想通貨）です。

Why people cannot understand this trend?​

この話はめちゃめちゃ重要で、なぜ気づいていない人々が多いのか？という疑問を抱くと思います。これについては、まあいろいろな理由があるでしょう。でもこれを知ってもらったあなたにはこのトレンドのことを覚えてほしいです。

技術というものは歴史において毎回何かを一新して、既得権益者の利益に触れます。そうすると必ず反発を受けます。

だけど、短期的には既得権益のほうが勝つかもしれませんが、長期的には勝てません。時代のトレンドというのは逆らうことがほぼ不可能なのです。

英語ではよく言われる言葉として以下があります。

First they ignore you, then they laugh at you, then they fight you, then you win.

これはクリプトの業界でもめちゃくちゃぴんとくる言葉です。「最初に彼らあなたを無視し、それからあざ笑わい、それから抗い、最終的にはあなたの勝利」というような感じで、歴史においては様々なトレンドがたどってきた運命なのです。

車の歴史もそうですし、発明された当初、めちゃくちゃ効率が悪くデザインも良くなかったので、馬車のほうが全然いいと思っていた人が少なからずいました。また、そのあとのインターネットも発明された当初は誰にも理解されず、ビル・ゲイツがテレビでインターネットを紹介していたときには観客と司会者の方から大いに笑われていました。今だから言えるのですが、当初のビル・ゲイツが想像した世界よりも遥かに進んだインターネット社会ができています。

"History Doesn’t Repeat Itself, but It Often Rhymes" - Mark Twain

Mark Twain 氏が言っている通りです。

そこで、今度はブロックチェーンの番です。「ディスられる、怒られる、軽蔑される、無視される、それでも進化し続けて社会を変えていき、我々の生き方も変えてくれる」、これがクリプトです。

だらだらと書いてしまいましたが、普段友人に聞かれて説明すると結構な時間をかけて説明できたりしますが、いざ書くとなるとうまく書けないんですね。まだ書ききれないほどありますので、また次回をお楽しみに！

免責事項​

本 website にかかれている内容はあくまで個人的な見解であり、Financial advice ではありません。

TL;DR

• NFT は非代替性トークンのこと

• シンプルにいうとデジタル所有権のこと

• コードで理解しましょう

BTC や ETH のようなトークンは FT と呼ばれ、代替性トークンのことです。特徴としては、お互いに交換可能で大きな違いはないことです（厳密には違いもありますが、ここではその議論をしない）。また、アート、コレクション、不動産などのようなお互い違いをかなり持っているようなものは非代替性トークンで代表されることがほとんどです。

イーサリアムでは EIP721 が提案されて、ERC721 のスタンダードが形成されました。

EIP, ERC とは

結論：EIP が ERC を含んでいる

まず、理解しなければならないのは、ERC721 です。この２つの間にはなんの関係があるのでしょうか。EIP とは、Ethereum Improvement Proposals のことで、イーサリアムコミュニティが提案したプロトコルなどを改善するための提案のことです。EIP はイーサリアムの中の任意の分野の改善で、例えば新たな機能、ERC、プロトコル改善などがあります。

ERC とは、Ethereum Request For Comment のことで、イーサリアム上の各種アプリケーションのプロトコルとスタンダードのこととなっています。典型的な ERC20, ERC721、あるいは URI のスタンダード ERC67、あるいはウォレットのフォーマット EIP75, EIP85 などがある。

ERC スタンダードはイーサリアムの発展における重要な構成要素で、ERC20, ERC721, ERC223, ERC777 などのスタンダードがイーサリアムのエコシステムに多大な影響を与えていました。

ERC165

まず ERC165 について理解しましょう。 スマートコントラクトはインターフェースを宣言して他のスマートコントラクトがチェックするためにやっているのが ERC165 のことです。

シンプルにいうと、ERC165 を通してとあるコントラクトが ERC721, ERC1155 をサポートしているかチェックできるという仕組みです。

interface IERC165 {
    /**
     * @dev コントラクトが当該スタンダードの`interfaceId`を実装していればtrueを返す
     * 詳細はこちら：https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section]
     *
     */
    function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

次に実際には ERC721 がどのように supportsInterface()を実現したのか見てみましょう。

function supportsInterface(bytes4 interfaceId) external pure override returns (bool)
    {
        return
            interfaceId == type(IERC721).interfaceId ||
            interfaceId == type(IERC165).interfaceId;
    }

この関数supportsInterfaceは IERC721 あるいは IERC165 の interfaceId が引数として入力された場合に、trueを返し、そうでない場合はfalseを返します。

IERC721

IERC721の中身を見てみましょう。 IERC721はERC721のインターフェーススタンダードのコントラクトで、ERC721 が実現すべき一般的な関数を定義してます。tokenIdを使って非代替性トークンを代表しています。アプルーブあるいはトランスファに際して、tokenIdは必ず出番があります。しかし、ERC20 はトランスファにおける数量だけを定義すればよくて、tokenId はありません。

/**
 * @dev ERC721スタンダードのインターフェース
 */
interface IERC721 is IERC165 {
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);

    function balanceOf(address owner) external view returns (uint256 balance);

    function ownerOf(uint256 tokenId) external view returns (address owner);

    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes calldata data
    ) external;

    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;

    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;

    function approve(address to, uint256 tokenId) external;

    function setApprovalForAll(address operator, bool _approved) external;

    function getApproved(uint256 tokenId) external view returns (address operator);

    function isApprovedForAll(address owner, address operator) external view returns (bool);
}

IERC721 の event

3 つの event を含まれています。Transfer、Approvalは ERC20 にも存在します。

• Transfer: トークントランスファのときに放出。送り元from、送り先to、tokenId。

• Approvel: アプルーブするときに放出。アプルーブする側のアドレスowner、アプルーブした先のアドレスapproved、tokenId。

• ApprovalForAll: 一気に大量にアプルーブするときに放出するイベント。アプルーブする側のアドレスowner、アプルーブされる側のアドレスoperator、アプルーブする場合approvedは true で、逆に権限を剥奪する場合、approvedは false にする

IERC721 関数

• balanceOf: とあるアドレスの持っている NFT の数量を返す

• ownerOf: tokenId のオーナーを返す

• transferFrom: 普通のトランスファ、引数は from は送り元で、to は送り先、tokenId も必要

• safeTransferFrom:安全なトランスファ、もし受ける側はコントラクトの場合、ERC721Receiverの実装が求められる。引数は送り元のfrom、送り先のto、tokenId

• approve: 他のアドレスにあなたの NFT を使用する権利を渡す。権利を付与するアドレスはto、そしてtokenIdも引数に

• getApproved: tokenIdがどのアドレスに権限を付与したのか確認する

• setApprovalFroAll: 自分の持っているこのコントラクトのすべての NFT をとあるアドレスに対して全権移譲する

• isApprovedForAll: 全権移譲しているアドレスがあるか確認する

• safeTransferFrom: 安全なトランスファ関数のオーバーライド関数、引数にdata`が含まれている

IERC721Receiver

コントラクトがもし ERC721 の実現をしていない場合、送られてきた NFT はブラックホールに送ったように、永遠に取り出せなくなります。これを防止するために、ERC721 はsafetransferFrom()関数を実装している。ターゲットコントラクトがIERCReceiverインターフェースを実装している場合のみ、ERC721 トークンを受け取ることができます。そうでない場合はrevertされます。IERC721Receiver インターフェースは一個のonERC721Receiver()関数しかありません。

// ERC721Receiverのインターフェース：　コントラクトはこれを実装して安全なトランスファを受けることができる
interface IERC721Receiver {
    function onERC721Received(
        address operator,
        address from,
        uint tokenId,
        bytes calldata data
    ) external returns (bytes4);
}

次にERC721がどうやって_checkOnERC721Receivedを使ってコントラクトがonERC721Receiver()関数を実装していることを確認しているのを見てみましょう。

function _checkOnERC721Received(
        address from,
        address to,
        uint tokenId,
        bytes memory _data
    ) private returns (bool) {
        if (to.isContract()) {
            return
                IERC721Receiver(to).onERC721Received(
                    msg.sender,
                    from,
                    tokenId,
                    _data
                ) == IERC721Receiver.onERC721Received.selector;
        } else {
            return true;
        }
    }

IERC721Metadata

IERC721Metadata は ERC721 の拡張インターフェイス。３つの metadata 用関数を用いている。

• name()：トークン名を返す

• symbol():トークン符号

• tokenURI():tokenId を使って metadata の url をとってくる。ERC721 特有の関数

interface Ierc721Metadata is IERC721 {
    function name() external view returns (string memory);

    function symbol() external view returns (string memory);

    function tokenURI(uint256 tokenId) external view returns (string memory);
}

ERC721 メインコントラクト

ERC721 メインコントラクトは IERC721, IERC165, IERC721Metadata のすべての機能を定義した。4 つの状態変数、17 個の関数を含まれている。シンプルに実装されている。詳細はコメントを読んでください。

// SPDX-License-Identifier: MIT
// by 0xAA
pragma solidity ^0.8.4;

import "./IERC165.sol";
import "./IERC721.sol";
import "./IERC721Receiver.sol";
import "./IERC721Metadata.sol";
import "./Address.sol";　// library
import "./String.sol"; // library

contract ERC721 is IERC721, IERC721Metadata{
    using Address for address; // Address libraryを使う（isContractを使うため）
    using Strings for uint256; // String library

    // Token名
    string public override name;
    // Tokenシンボル
    string public override symbol;
    // tokenId -> owner address のマッピング
    mapping(uint => address) private _owners;
    // address -> バランスのマッピング
    mapping(address => uint) private _balances;
    // tokenID -> アプルーブされたアドレスのマッピング
    mapping(uint => address) private _tokenApprovals;
    //  owner -> operatorアドレス -> bool（権限渡した場合はtrue）
    mapping(address => mapping(address => bool)) private _operatorApprovals;

    /**
     * constructor, name, symbolを初期化する
     */
    constructor(string memory name_, string memory symbol_) {
        name = name_;
        symbol = symbol_;
    }

    // ERC165のsupportsInterface関数
    function supportsInterface(bytes4 interfaceId)
        external
        pure
        override
        returns (bool)
    {
        return
            interfaceId == type(IERC721).interfaceId ||
            interfaceId == type(IERC165).interfaceId ||
            interfaceId == type(IERC721Metadata).interfaceId;
    }

    // IERC721のbalanceOf関数、_balancesを使って調べたいアドレスの残高を返す
    function balanceOf(address owner) external view override returns (uint) {
        require(owner != address(0), "owner = zero address");
        return _balances[owner];
    }

    // IERC721のownerOf関数、_owners変数を使ってtokenIdのownerを返す
    function ownerOf(uint tokenId) public view override returns (address owner) {
        owner = _owners[tokenId];
        require(owner != address(0), "token doesn't exist");
    }

    // IERC721のisApprovedForAll、_operatorApprovals変数を
    // 使ってownerがoperatorに権限を移譲したかどうかをチェックする。
    // 権限移譲した場合はtrueを返す
    function isApprovedForAll(address owner, address operator)
        external
        view
        override
        returns (bool)
    {
        return _operatorApprovals[owner][operator];
    }

    // IERC721のsetApprovalForAllを実装。持っているトークンをすべてoperatorに権限を渡す(true),
    // あるいはoperatorの権限を剥奪する(false)。_setApprovalForAll関数を呼び出す。
    function setApprovalForAll(address operator, bool approved) external override {
        _operatorApprovals[msg.sender][operator] = approved;
        emit ApprovalForAll(msg.sender, operator, approved);
    }

    // 实现IERC721的getApproved，利用_tokenApprovals变量查询tokenId的授权地址。
    function getApproved(uint tokenId) external view override returns (address) {
        require(_owners[tokenId] != address(0), "token doesn't exist");
        return _tokenApprovals[tokenId];
    }

    // _approve関数。_tokenApprovalsを書き換えて，toアドレスに tokenIdをいじる権限を渡す。
    // Approvalイベントを放出。
    function _approve(
        address owner,
        address to,
        uint tokenId
    ) private {
        _tokenApprovals[tokenId] = to;
        emit Approval(owner, to, tokenId);
    }

    // IERC721のapprove関数，tokenIdの権限を to アドレスに渡す。
    // 条件：toはownerではないこと，かつmsg.senderはownerあるいはapproveされたアドレス。
    // _approve関数を呼び出す
    function approve(address to, uint tokenId) external override {
        address owner = _owners[tokenId];
        require(
            msg.sender == owner || _operatorApprovals[owner][msg.sender],
            "not owner nor approved for all"
        );
        _approve(owner, to, tokenId);
    }

    //  spenderアドレスがtokenIdを使う権限があるかないかを調べる。（あるのはownerか
    // approveされたかのいずれだ。approveされた場合は通常のapproveあるいは
    // setApprovalForAllの2パターン）
    function _isApprovedOrOwner(
        address owner,
        address spender,
        uint tokenId
    ) private view returns (bool) {
        return (spender == owner ||
            _tokenApprovals[tokenId] == spender ||
            _operatorApprovals[owner][spender]);
    }

    /*
     * トランスファ関数。_balances、_ownerのバランスを調整して tokenId を from から toに
     * トランスファする。同時にTransferイベントを放出。
     * 前提条件:
     * 1. tokenId は from によって所有されている
     * 2. to はゼロアドレスでない
     * 条件を満たさない場合はrevert
     */
    function _transfer(
        address owner,
        address from,
        address to,
        uint tokenId
    ) private {
        require(from == owner, "not owner");
        require(to != address(0), "transfer to the zero address");

        _approve(owner, address(0), tokenId); // トランスファするので権限をリセットする

        _balances[from] -= 1;
        _balances[to] += 1;
        _owners[tokenId] = to;

        emit Transfer(from, to, tokenId);
    }

    // IERC721のtransferFrom関数の実装，セーフトランスファではないので、
    // この関数を使うのは推奨されていない。
    function transferFrom(
        address from,
        address to,
        uint tokenId
    ) external override {
        address owner = ownerOf(tokenId);
        require(
            _isApprovedOrOwner(owner, msg.sender, tokenId),
            "not owner nor approved"
        );
        _transfer(owner, from, to, tokenId);
    }

    /**
     * セーフトランスファ，安全にtokenIdをfromからtoへトランスファする。スマートコントラクトが
     * erc721に対応しているかどうかをチェックした上で、トランスファをするので、NFTが永遠に
     * ロックされる実態を回避する。_transfer、_checkOnERC721Received関数を呼び出す。
     * 条件：
     * from はゼロアドレスではない
     * to はゼロアドレスではない
     * tokenId が存在してしかもfromアドレスが所有
     * toがスマートコントラクトの場合、必ずIERC721Receiver-onERC721Receivedをサポートされる
     * ことが求められる
     */
    function _safeTransfer(
        address owner,
        address from,
        address to,
        uint tokenId,
        bytes memory _data
    ) private {
        _transfer(owner, from, to, tokenId);
        require(_checkOnERC721Received(from, to, tokenId, _data), "not ERC721Receiver");
    }

    /**
     * IERC721のsafeTransferFromを実装。セーフトランスファ関数，_safeTransfer関数を呼び出している
     */
    function safeTransferFrom(
        address from,
        address to,
        uint tokenId,
        bytes memory _data
    ) public override {
        address owner = ownerOf(tokenId);
        require(
            _isApprovedOrOwner(owner, msg.sender, tokenId),
            "not owner nor approved"
        );
        _safeTransfer(owner, from, to, tokenId, _data);
    }

    // safeTransferFromのオーバライド関数、引数が違う
    function safeTransferFrom(
        address from,
        address to,
        uint tokenId
    ) external override {
        safeTransferFrom(from, to, tokenId, "");
    }

    /**
     * mint関数。_balances、_ownersのバランスをいじることで、tokenIdをtoへトランスファする。
     * 同時にTransferイベントを放出する。
     * 現在の状態では、誰でもミントできるので、開発者は普通この関数を書き換える
     * 条件:
     * 1. tokenIdがまだ存在しない
     * 2. toはゼロアドレスでない
     */
    function _mint(address to, uint tokenId) internal virtual {
        require(to != address(0), "mint to zero address");
        require(_owners[tokenId] == address(0), "token already minted");

        _balances[to] += 1;
        _owners[tokenId] = to;

        emit Transfer(address(0), to, tokenId);
    }

    // バーン関数，_balances、_owners変数を調整してtokenIdをバーンする。同時にTransferイベントを放出
    // 条件：tokenId存在。
    function _burn(uint tokenId) internal virtual {
        address owner = ownerOf(tokenId);
        require(msg.sender == owner, "not owner of token");

        _approve(owner, address(0), tokenId); // 権限を更新

        _balances[owner] -= 1;
        delete _owners[tokenId];

        emit Transfer(owner, address(0), tokenId);
    }

    // _checkOnERC721Received：IERC721Receiver-onERC721Received関数, 送り先はERC721互換かどうかをチェックするため
    function _checkOnERC721Received(
        address from,
        address to,
        uint tokenId,
        bytes memory _data
    ) private returns (bool) {
        if (to.isContract()) {
            return
                IERC721Receiver(to).onERC721Received(
                    msg.sender,
                    from,
                    tokenId,
                    _data
                ) == IERC721Receiver.onERC721Received.selector;
        } else {
            return true;
        }
    }

    /**
     * IERC721MetadataのtokenURI関数，metadataを返す
     */
    function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
        require(_owners[tokenId] != address(0), "Token Not Exist");

        string memory baseURI = _baseURI();
        return bytes(baseURI).length > 0 ? string(abi.encodePacked(baseURI, tokenId.toString())) : "";
    }

    /**
     * {tokenURI}のBaseURI。tokenURIはbaseURI、tokenIdをつないでできたもの。
     * 開発者がこの関数を書きかえる
     * 例えばBAYCのbaseURIはipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/
     */
    function _baseURI() internal view virtual returns (string memory) {
        return "";
    }
}

free mint の APE を作ろう

それでは、free mint の APE を作りましょうか。totalSupply を 10000 個にして、mint 関数や baseURI を書き換えるだけで済みます。

baseURI()の設定を BAYS と全く同じようにすることで、BAYC の猿が表示されるはずです。

// SPDX-License-Identifier: MIT
// by 0xAA
pragma solidity ^0.8.4;

import "./ERC721.sol";

contract OmaenoApe is ERC721{
    uint public MAX_APES = 10000; // 総数

    // コンストラクタ
    constructor(string memory name_, string memory symbol_) ERC721(name_, symbol_){
    }

    //BAYCのbaseURIはipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/
    function _baseURI() internal pure override returns (string memory) {
        return "ipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/";
    }

    // mint関数
    function mint(address to, uint tokenId) external {
        require(tokenId >= 0 && tokenId < MAX_APES, "tokenId out of range");
        _mint(to, tokenId);
    }
}

それでは remix を開いてコードを書きましょう。

ERC721 を発行しよう

ERC721 スタンダードがあれば、ブロックチェーンにて NFT を発行することは非常にシンプルになります。 今、上記のコードができたので、remix にて発行しましょう。

実際の手順はまたの機会で書きます。

ERC165 と ERC721

NFT を NFT についてコントロールできないコントラクトへ送付してしまうと、永遠に消失してしまうため、これを防ぐためにERC721TokenReceiverインターフェイスの実装が求められます。

interface ERC721TokenReceiver {
    function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);
}

実はこのインターフェイスとは、この onERC721REceived 関数のことです。この関数を実装していれば、NFT を処理する能力があるという宣言になります。

THE END

Never Give Up

以前書いた時から、EVM について理解できてきているので、当時は読みづらかった技術系の文章もすらすら読めるようになりました。そこで EVM のことあるいは他のなにかで頑張っているあなたももしかして何かができずに悩んでいるのかもしれません。

ここで行っておきますが、僕もそうだったので、安心してください。そのうち理解できるようになるだろう。

ちなみに、こちらの画像をみてごらん。

本当に経験した人しかわからないと思いますし、経験したとしてももう一度経験すると、やはり信じられない気持ちになると思うよね。

何がどうなっても、続けることが一番大切。

• 遅くてもいい

• 理想と現実

• 「続けてても意味ない」

• 最初の第一歩が一番むずいけどね

• 三日坊主 VS 続ける

今回は、メモリーについて説明する。

Part 1 では、EVM がどのようにバイトコードのどこを狙って run させるかを見てきた。 それは、外部の calldata を入力してきてコントラクトのどの関数を呼んでいるかを判別して run すべきバイトコードの箇所を決めていることがわかった。

これを理解することで、関数の署名・call stack・calldata・EVM のオペコード について理解が進んだと思う。

Part 2 では、EVM におけるメモリーについて色々見ていこう。

Memory

Part1 のコードを思いだしてみて。1_Storage.solというコントラクトがあった。

pragma solidity >=0.7.0 <0.9.0;

contract Storage {
    uint256 number;

    function store(uint256 num) public {
        number = num;
    }

    function retrieve() public view returns (uint256) {
        return number;
    }
}

これのバイトコードを生成すると、こうなっている。

608060405234801561001057600080fd....

今回はこの部分にフォーカスして説明したいと思う。一番最初の 5bytes だ。

60 80                       =   PUSH1 0x80
60 40                       =   PUSH1 0x40
52                          =   MSTORE

これが聞いたことあるがかもしれないけど、いわゆる「free memory pointer」だ。

これを理解するには、まずはコントラクトのメモリーを理解しなければならない。

メモリのデータ構造

コントラクトのメモリはシンプルにいうと、byte の array だ。32bytes(256bit)あるいは 1byte(8bit)の単位として保存される。読まれるときには、32bytes(256bit)単位ごとになる。下記の画像は話した内容を具現化したもの。

この機能は３つの opcode に左右されている。

• MSTORE(x, y): 32 byte(256 bit) の値 y をメモリのロケーションの x に保存

• MLOAD(x): 32 byte(256 bit) のメモリの場所をロケーション x から読み出し、スタックに入れる

• MSOTRE8(x, y): 1 byte (8 bit)の値 y をメモリロケーションの x に保存する

メモリロケーションのことはどこからメモリを読み取る/書き込むかを決めていると考えてよい。もし、1byte より多く読み取る/書き込むことをしたいのであれば、そのまま継続すればよいだけの話になる。

EVM playground

この EVM playground はあなたの理解の手助けができるだろう。Run をクリックして、右上の矢印をクリックしてみよう。矢印ボタンはコードの稼働プロセスをたどっていってくれる。スタック、メモリはどうなっているのかもわかる。すごく直感的なツールだと感心する。

// MSTORE 32 bytes 0x11...1 at memory location 0
PUSH32 0x1111111111111111111111111111111111111111111111111111111111111111
PUSH1 0x00
MSTORE

// MSTORE8 1 byte 0x22 at memory location 32 (0x20 in hex)
PUSH1 0x22
PUSH1 0x20
MSTORE8

// MSTORE8 1 byte 0x33 at memory location 33 (0x21 in hex)
PUSH1 0x33
PUSH1 0x21
MSTORE8

// MLOAD 32 bytes to the call stack from memory location 0 ie 0-32 bytes of memory
PUSH1 0x00
MLOAD

// MLOAD 32 bytes to the call stack from memory location 32 ie 32-64 bytes of memory
PUSH1 0x20
MLOAD

// MLOAD 32 to the call stack from memory location 33 ie 33-65 bytes of memory
PUSH1 0x21
MLOAD

opcode についても、英語だが説明文がついている。

やってみて変だなと思うことはないのか？ まず、MSTORE8 を使って 1 byte の 0x22 をメモリの 0x20 に書き込んでいるつもりだが、何故かメモリはここから、

こう変わるんだ。

この余分なゼロってなんだと思うだろう。

メモリの拡張​

コントラクトがメモリへなにかを書き込む際、byte 数に従ってガス代を支払っている。これが opcode のコストと言う。もし、これまでメモリへ書き込んだことがない場所へ書き込む場合、追加的にメモリ拡張のコストがかかる。

これまで書き込んだことがない箇所へ書き込む場合、メモリは 32bytes(256bit)拡張されることになる。

メモリのコストの増え方に関しては、最初の 724bytes は線形的に増加するが、それ以降は二次指数関数的になる。

上の例では、まず 0x00 のロケーションへ 32 bytes 書き込んだが、そこからさらに書き込むとなると、メモリ拡張をしなければならず、結果的に、メモリは 64 bytes になった。

メモリにある保存領域の最初のデフォルト値はゼロ。だから 2200000000000000000000000000000000000000000000000000000000000000 がメモリに追加された。

メモリは byte の Array だから​

次に注意しないといけないのは、メモリロケーションの 33(0x21)から MLOAD したときに、下記の値が返された。

32 bytes ずつ読み込んでいなくても、読み込めるということであった。

memory はただの byte array なので、どこの場所からでも読み込めることを覚えて下さい。32bytes の制限は特になく、どこからでも byte 単位から読み込める。

関数内でのみ新たにメモリを作成することができます。それは新たにインスタンス化された複雑な型（例えば new int[...] など）であったり、ストレージ参照変数からコピーされたものであったりします。

現在、我々はデータ構造について理解できたので、free memory の話へ戻ろう。

Free Memory Pointer

Free Memory Pointer とは、簡単にいうとメモリロケーションのポインターであり、Free Memory がどこからスタートすべきなのかを記録している。言い換えると、メモリのロケーションはどこまで書き込まれていて、どこから書き込むべきなのかを記録している。

これはコントラクトがメモリを上書きするのを防ぐためでもある。

変数がメモリへ書き込むときに、コントラクトはまず Free Memory Pointer を参照し、どこから書き込むべきかを決めないといけない。それから Free Memory Pointer をアップデートし、最新のメモリの「境界値」あるいは「オフセット」を記録する。

  newFreeMemoryPointer = freeMemoryPointer + dataSizeBytes

Bytecode​

先程にも言及したように、Free Memory Pointer は最初の runtime bytecode のこの部分によって定義される。

60 80                       =   PUSH1 0x80
60 40                       =   PUSH1 0x40
52                          =   MSTORE

これは基本的に何を言っているかというと、Free Memory Pointer はメモリロケーションの 0x40(64 in decimal)で、値は 0x80(128 in decimal)となる。

すぐに疑問に思うのは、なぜこの数字なのということだろう。

答え：

0x00 - 0x3f (64 bytes): scratch space

0x40 - 0x5f (32 bytes): free memory pointer

0x60 - 0x7f (32 bytes): zero slot

0x40 は solidity が定義した一番最初の Free Memory Pointer のメモリロケーションだ。値 0x80 は単に最初の 4 つの 32 bytes のポジションを記録している。

これらの予約されたメモリについて

• Scrach space: inline assembly のハッシングメソッドとして使っても良い

• Free memroy pointer: 今のメモリのサイズ、free memory のスタートロケーション、最初は 0x80

• The zero slot: 動的な Memory Array の初期値であり、どんなときにでも書き込まれることはない

コントラクトのメモリ

リアルなコントラクトのメモリについて見ていくとしようか。

非常にシンプルなコントラクトを作成した。こいつの名は MemoryLane。たった一個の関数を持っており、２つの Array を持っている。それから b[0]に値 1 を付与する。

3 行程度のコードだけど、かなり多くのことが起きているよ。

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.3;

contract MemoryLane {
    function memoryLane() public pure {
        bytes32[5] memory a;
        bytes32[5] memory b;
        b[0] = bytes32(uint256(1));
    }
}

上記のコードをもう一度 remix へ投入。

それから、コンパイルし、デプロイしてください。

memoryLane()関数を run して、debugging mode へ入ってください。

opcode を少しずつ見ていこう。

少し簡単なバージョンをEVM playgroundへ入れている。その opcode はそのようになっている。

この簡単なバージョンは opcode を順番に構成し、JUMP などのメモリ操作と関連しないことを除外した。いろいろコメントもしているので、参照してほしい。

このコードは 6 部分から構成されていて、これから dive in する。

play ground を使うことを強くおすすめする。

Free Memory Pointer Initialisation (EVM Playground Lines 1-15)

まず、“free memory pointer initialisation”からやっていく。上記でもあったように、0x80(128 in decimal)をスタックに入れる。これは free memory pointer の値として保存される。Solidity の memory のレイアウトを決めている。

この段階では、まだメモリにはなにもない。

続いて free memory pointer のロケーションの 0x40(64 in decimal)をプッシュする。

最後に、MSTORE を使って、0x40 ロケーションに 0x80 の値を記録。

この後、スタックには何もなく、メモリになにかを残せたことになる。メモリは 16 進数になっており、数字ごとに 4bit のデータを記録している。

今となって、192 の 16 進数の数字となっている（数字 2 桁 = 1 byte = 8 bit）。

先程の内容を思い出してください。最初の 64bytes は scrach space で、次の 32bytes は free memory pointer になる。これはまさに下記の状態。

Memory Allocation Variable “a” & Free Memory Pointer Update (EVM Playground Lines 16-34)

残りの部分については、簡単にするために一旦最後の飛ばしてハイレベルの概要を見てみよう。

次のメモリに関して、変数a(bytes32[5])のことを配置して free memory pointer をアップデートするということをしなければならないのがわかる。

コンパイラは array size によってどれくらいのスペースが必要か決定する。

メモリ array の要素の占める領域は 32 bytes の倍数になる。これは bytes1[]に対しても通用する。ただし、bytes や string は違う。

array のサイズ ×32bytes でどれくらいのメモリを食うかわかる。

この場合、5 * 32 bytes で、0xa0 (160)になるのだ。したがってその値は stack にプッシュされ、現在の free memory pointer に保存された。

この後、前の free memory pointer の値と足し算をして、値 0x120 (288)が生成された。この値が free memory pointer に保存された。

stack には変数aメモリをロケーション 0x80 にキープして後から参照できるようにしている。0xffffは JUMP のロケーションを意味しており、関係ないので当面は無視してよい(stack の underflow を防ぐためにある)。

Memory Initialisation Variable “a” (EVM Playground Lines 35-95)

今ではメモリに保存されて free memory pointer がアップデートされた。ここからは変数aのメモリにおける初期化をする。変数は宣言されて値代入していないので、ゼロ値になっているはず。

これをするためには、EVM の CALLDATACOPY を使って実施する。この opcode は３つの引数が必要：

• memoryOffset（メモリロケーションへコピーする場所）

• calldataOffset（calldata における byte offset のこと）

• size（コピーする byte size）

今回の場合、memoryOffset はaのメモリロケーション 0x80。

calldataOffset は実際の calldata のサイズ、なぜならそもそも calldata の copy がいらない。メモリをゼロ値で初期化したい。結果的にサイズが 0xa0 あるいは 160 bytes になる。

ここで、メモリが 288 bytes になったとわかる(zero slot も含めて)。stack は今もう一度変数のメモリロケーションと JUMP ロケーションを持っている状態。

（その間に細かい操作については、何度も pop しているのがあるが、個人的にはまだなぞで、わかる方なら教えて下さい）

Memory Allocation Variable “b” & Free Memory Pointer Update (EVM Playground Lines 96-112)

ここでの操作は上記の流れと非常に似ているが、ただし、今回はbytes32[2] memory bとなる。

free memory pointer を 0x160(352 in decimal)にアップデートする(前の free memory pointer 288 + 新しい変数のサイズ 64 bytes)。

注意としては、free memory pointer はメモリにて 0x160 にアップデートされ、そこで現在は変数bのメモリロケーション(0x120)をスタックに入れてある。

Memory Initialisation Variable “b” (EVM Playground Lines 113-162)

続いて変数b初期化について説明する。

現在、メモリは 352bytes へ拡張された。スタックにはメモリロケーションを 2 個持っている。

Assign Value to b[0] (EVM Playground Lines 163-207)

やっと最後の段階に来れた。正直にいって難しかった。

ここでは、array b の index 0に値を付与したい。

コードでは b[0] = 1 となっている。

まず、この値が stack に突っ込まれる。その後、bit shift が起きるが、これ移動したのは 0 で何も変わりはないことを意味する。

次に array の index には 0x00 へ書き込まれ、0 positon へ書き込むことを意味する。その際に、array length の 2 を超えていないことをチェック。もし条件をクリアできない場合、異なるバイトコードのポジションへ飛び、エラーハンドリングの部分へ飛ばされる。

MUL、ADD opcode はメモリいにおいて値が書き込まれる場所を決めている。

0x20 (32 in decimal) * 0x00 (0 in decimal) = 0x00

メモリの array は 32 byte 単位であることを思い出してほしい。こちらは 0x00 になるので、offset は不要でそのまま 0 のポジションから書着込む。

0x00 + 0x120 = 0x120 (288 in decimal)

ADD は offset の値をメモリにある変数 b のロケーションを定義するように使われた。offset は今回 0 なので、そのまま、free memory pointer の位置に書き込むこととなる。

一番最後に、MSTORE を使って値 0x01 をメモリロケーションの 0x120 へ書き込む。そして、スタックにあるすべての要素を pop し、終了。

これでメモリはb[0] = 1となっている。下から 3 行目のところに 1 という数字が入っているのがわかる。

今回の記事はここまで！Bye！

Reference​

https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy-d6b?s=r

EVM(Ethereum Virtual Machine) の世界では、Re-entrancy の攻撃というのがある。

まさにこの攻撃手法が取られることがある。

攻撃のコントラクトはコントラクトに何度も入り込んで、チェックする条件が反映される前になんども同じ操作をされてしまうというやり口である。本来なら一度のみ呼ばれるものが何度もチェックを抜けて呼ばれると予期しない挙動になったりして、資産が盗まれたりする。

この攻撃手法は昔の The DAO 事件がやられた手法でもある。歴史に残る大事件だ。

他のソフトウェア環境では起こらないよう脆弱性だ。これは新しい開発者だとやりがちなミスになる。

このような状況において、Checks-Effects-Interactions を適用してください。

• 外部のコントラクトを呼び出すのは避けられない

• Re-entrancy 攻撃を避けたい

実装

• まず、check

関数を呼び出してまず実行する条件をチェック（例えば十分な資金をもっているか）。

• 次、effect

その次にすべての状態変数を更新すべき

• 最後、interaction

最後に外部のコントラクトとのインタラクションをすべき。内部の状態が完全に更新された後に、初めて外部のコントラクトを呼び出す。

この順番さえ守れば、Re-entrancy 攻撃は最初の関門をくぐりぬけれなくなります。

もし、最後に状態の変更をするとなると、状態変更される前に何回も同じ関数の部分が呼び出されてしまい、Re-entrancy 攻撃の罠にハマってしまう。

実例

pragma solidity 0.8.13;


contract reentrancyVictim{
    mapping(address => uint256) public balances;
    uint256 public contractBalance;

    function payIn() public payable{
        balances[msg.sender] += msg.value;
    }

    function withdraw() public payable{
        require(balances[msg.sender] > 0, "Insufficiant balance");
        payable(msg.sender).call{value: balances[msg.sender]}("");
        balances[msg.sender] = 0;
    }

    function updateContractBalance() public{
        contractBalance = address(this).balance;
    }
}

このコードは一見して大丈夫なように見えるが、withdraw()関数の 2 行目に十分な資産があるかを確認している。次にアセットをユーザーへ送付している。最後にバランスを更新している。

これは check-effect-interaction のルールを守っていない。

• check: require(balances[msg.sender] > 0, "Insufficiant balance");

• interaction: payable(msg.sender).call{value: balances[msg.sender]}("");

• effect: balances[msg.sender] = 0;

となっており、effect と interaction の順番が逆。

その結果、Re-entrancy 攻撃が可能となる。

具体的なスキームはこのような感じ：

adjust funds の前に、何回も何回も資産が抜き出されて、最後に資金が底をつくことになるだろう。

Attacker のコードは以下：

pragma solidity 0.8.13;


contract reentrancyAttack{

    address public victim;
    uint256 public amount;
    uint256 public counter;

    constructor(address _victim) payable{
        victim = _victim;
        amount = msg.value;
    }

    receive() external payable{ // イーサ受け取り用のreceive関数
        counter++;
        attack();
    }

    function payIn() public returns (bool success){
        (bool success, bytes memory data) = payable(victim).call{value: amount}(abi.encodeWithSignature("payIn()"));
    }

    function withdrawAttack() public{
        if(counter < 4){
            // もう一度withdrawを呼ぶ用
            payable(victim).call(abi.encodeWithSignature("withdraw()"));
        }
    }
}

ソリューション

その対策としては、実はものすごくシンプルにwithdraw()の第 3, 4 行を逆転させて、修正を加える。

 function withdraw() public payable{
    // check
    require(balances[msg.sender] > 0, "Insufficiant balance");
    // effect
    uint256 payBalance = balances[msg.sender];
    balances[msg.sender] = 0;
    // interaction
    (bool success, bytes memory data) = payable(msg.sender).call{value: payBalance}("");
        if(!success){ // catch the case where the send was unsuccesful
            balances[msg.sender] = payBalance;
        }
}

もし、success が false の場合、バランスを元通りに戻す操作をしている。 // interaction の行において re-enterancy されても、すでにバランスはゼロなので、revert されて問題がない。

普段私は主にこちらのサイトに記事をパブリッシュしています。よかったら見てみてね。

https://omaeno.xyz/blog/EVM-deep-dive-part1

それでは、Bye!

THE END

スマートコントラクトの世界では、EVM とその周りにあるアルゴリズム、データ構造に関しては、まさにこの First Principle である。Solidity あるいはスマートコントラクトはこの基礎の上に作る構造物なのだ。EVM のことを理解せずにはグレートな solidity dev と称するにはまだ早いと言ってよいだろう。

基礎：Solidity → Bytecode → Opcode

まず、基礎的な部分について一定程度の知識を有することを前提としている。

• おさらい：

  • Bytecode & ABI: バイトコードとは EVM 上で実行可能なコードで、ABI とはこの EVM バイトコードとやり取りができるための interface。

  • Solidity コードはまずバイトコードへコンパイルしてから、イーサリアムブロックチェーンへ乗せるという流れになる。バイトコードは実は色々なオペコードを意味している。

今回は基本的な solidity コントラクトについてのバイトコードの一部を一緒にみていき、EVM がどのように関数を選んでいるかを見よう。

コントラクトのバイトコードはコントラクトからコンパイルされたもので、コントラクトにはいくつかもの関数があるだろう。

よくある質問は、デプロイした後、EVM はどのようにバイトコードのどの部分を実行すべきかがわかったのかというのがある。

今回はそれについて詳しく見ていきましょう。

1_Storage.sol コントラクト

pragma solidity >=0.7.0 <0.9.0;

contract Storage {
    uint256 number;

    function store(uint256 num) public {
        number = num;
    }

    function retrieve() public view returns (uint256) {
        return number;
    }
}

今回のコントラクトは上記のものとなる。コントラクトには二個の関数がある。store()と retrieve()。

runtime のバイトコードは以下の通り：

608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100d9565b60405180910390f35b610073600480360381019061006e919061009d565b61007e565b005b60008054905090565b8060008190555050565b60008135905061009781610103565b92915050565b6000602082840312156100b3576100b26100fe565b5b60006100c184828501610088565b91505092915050565b6100d3816100f4565b82525050565b60006020820190506100ee60008301846100ca565b92915050565b6000819050919050565b600080fd5b61010c816100f4565b811461011757600080fd5b5056fea2646970667358221220404e37f487a89a932dca5e77faaf6ca2de3b991f93d230604b1b8daaef64766264736f6c63430008070033

今回フォーカスするのは以下の部分：

この部分は全体のバイトコードから抜き取ったもの。

関数のセレクタのロジックが含まれている。

言い遅れたが、EVM のオペコードに関しては、ここから確認できる。

オペコードは 1 byte の長さになる。そうすると自然に 256 パターンがあると分ると思う。

しかし、実際には 140 子のオペコードしか存在しない。

以下はバイトコードを関係するオペコードへ変換したもの。

60 00                       =   PUSH1 0x00
35                          =   CALLDATALOAD
60 e0                       =   PUSH1 0xe0
1c                          =   SHR
80                          =   DUP1
63 2e64cec1                 =   PUSH4 0x2e64cec1
14                          =   EQ
61 003b                     =   PUSH2 0x003b
57                          =   JUMPI
80                          =   DUP1
63 6057361d                 =   PUSH4 0x6057361d
14                          =   EQ
61 0059                     =   PUSH2 0x0059
57                          =   JUMPI

スマコンの関数呼び出しや Calldata

オペコードへダイブする前に、コントラクトの関数の呼び出しについて復習しよう。

関数の呼び出しの前に、calldata に、関数の署名、そして続いて引数も入れる。

Solidity のコードに表現してもらうと、こうなるだろう。

event FunctionCalldata(bytes);
bytes memory functionCalldata = abi.encodeWithSignature('store(uint256)', 10);
emit FunctionCalldata(functionCalldata);
address(storageContract).call(functionCalldata);

今回の場合、僕は store 関数を呼び、10 引数として代入したい。

上の長い数字の配列は abi.encodeWithSignature(”store(uint256)”,10)の結果。

関数シグネチャーは４バイトの Keccak ハッシュ値によって定義されている「0x6057361d」。

keccak256(“store(uint256)”) →  first 4 bytes = 6057361d

keccak256(“retrieve()”) → first 4 bytes = 2e64cec1

先程の calldata を見ると、全部で 36bytes あった。最初の 4bytes: 6057361dは関数のセレクタ関連で、store(uint256)と関係する。

ご自身ではッシュしてみて →ここ

6057361d = function signature (4 bytes)

000000000000000000000000000000000000000000000000000000000000000a = uint256 input (32 bytes)

以上、calldata の準備だった。

オペコード＆スタック

それでは、EVM レベルへダイブしていこう。スタックについて理解しておく必要がある。わからない場合はこれを見て。

先程のオペコードはこれ：

60 00                       =   PUSH1 0x00
35                          =   CALLDATALOAD
60 e0                       =   PUSH1 0xe0
1c                          =   SHR
80                          =   DUP1
63 2e64cec1                 =   PUSH4 0x2e64cec1
14                          =   EQ
61 003b                     =   PUSH2 0x003b
57                          =   JUMPI
80                          =   DUP1
63 6057361d                 =   PUSH4 0x6057361d
14                          =   EQ
61 0059                     =   PUSH2 0x0059
57                          =   JUMPI

PUSH1 は 1byte のデータをスタックへ入れることを意味する。そうすると、スタックはこうなる

PUSH1 0x00    | 0 |

続いて CALLDATALOAD は最初の stack(0)の値をポップさせる。この 0 値を input として使用し、offset として使う。スタックアイテムのサイズは 32bytes なのに対し、今回の calldata は 36bytes になっている。プッシュする値は msg.data[i : i+32]で、i は今回の input 値となる。これは毎回プッシュする値が 32bytes になることを保証できる。同時に、どの部分にもアクセルできる。

今回の場合、offset はなかったので、32bytes の calldata の値をスタックに push した。さきほど用意した calldata はこれ。やっと出番がきた。

0x6057361d000000000000000000000000000000000000000000000000000000000000000a。

というのは、最後の0000000aが除外された 32bytes が今回の入力となる。

CALLDATALOAD    | 0x6057361d0...00 |

次に PUSH1 を使って hex value の 0xe0 をスタックに入れる。これは十進数だと 224。

PUSH1 0xe0      |       224        |
                | 0x6057361d0...00 |

SHR を使ってライトシフトさせる。今回は最初のアイテムである 224 を取り出し、input として扱う。スタックにある二番目のアイテムをどれくらい右へライトシフトさせるかを定義している。256 - 244 = 32 bit とわかるように、最後には 4bytes のセレクタが call stack に残る。

SHR    | 0x6057361d |

DUP1 を使ってスタックの一番上の値をコピーする。

DUP1    | 0x6057361d |
        | 0x6057361d |

PUSH4 を使って 4byte の関数のシグネチャーのretrieve() (0x2e64cec1) をスタックにプッシュする。

PUSH4 0x2e64cec1        | 0x2e64cec1 |
                | 0x6057361d |
            	| 0x6057361d |

EQ は二個の値をスタックから出し、イコールなのかどうかをチェックする。もしイコールなら 1（true） をスタックにプッシュ、そうでない場合は 0（false） をプッシュする。

EQ    		　　　|      0     |
        　　　| 0x6057361d |

次に PUSH2 を使って二個の値をプッシュ。（0x003b, 十進数だと 59）

ここでは、59 が出たのはプログラムカウンターがバイトコードに次の実行コマンドはどこにあるのかを確認しているから。この 59 は retrieve()がスタート地点は 59 を意味している。

PUSH2 0x003b    |     59     |
        |      0     |
        | 0x6057361d |

JUMPI は”jump if”を意味する。二個の値をポップさせ、一個目の値は 59 で、二個目は 0。二個目の値は bool 値でこの jump を実行すべきかを確定している。1 = true, 0 = false。

もし true の場合、プログラムカウンターはアップデートされ実行はそちらへ jump する。今回は false なので、スキップ。

JUMPI    | 0x6057361d |

DUP1 again

DUP1    | 0x6057361d |
        | 0x6057361d |

PUSH4 は 4byte の値をスタックにプッシュする

PUSH4 0x6057361d    | 0x6057361d |
        　　　　　　　　| 0x6057361d |
        　　　　　　　　| 0x6057361d |

また EQ して、今回は true なので。シグネチャーが合った。

EQ　　　　　　　　　　|      1     |
　　　　　　　　　　　　　　| 0x6057361d |

JUMPI、今回は true なんで jump を実行する。プログラムカウンターは 89 で、バイトコードの違う場所へ移動。

PUSH2 0x0059    |     89     |
        |      1     |
        | 0x6057361d |

この場所に JUMPDEST オペコードがある。これがないと失敗する。

JUMPI      | 0x6057361d |

そこで終わり。これでオペコードの実行はstore(uint156)の場所へ移動できた。

今回は二個の関数しかないものの、たとえ 20 個の関数があったとしても、プロセスは一緒。

このリンクは非常におすすめ。触ってみると吉。

EVMのスタック・メモリ・ストレージをシミュレートしてくれる。

日本語圏にはこういった記事が少ないと思いますので、もし役に立ったのであれば幸いだと思います。今後も記事を作成していきますので、よろしくお願いします。

普段私は主にこちらのサイトに記事をパブリッシュしています。

https://omaeno.xyz/blog/EVM-deep-dive-part1

Reference

This is a translated article. All rights reserved for the original author.

https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy