的なことを様々な記事で書かれています。

ブロックチェーン初学者である私はそれを鵜呑みにした結果ふと疑問が浮かびました。

「スマートコントラクトのstorageってブロックチェーンに永久に刻まれるのになんで更新できるの？？」

https://mirror.xyz/0x221E25Ad7373Fbaf33C7078B8666816586222A09/0YK76_OJ5bkyH-RiFsiAiwFYD0yLxllKwIUPMocMaoo

storageについてこの記事で説明していますが、storageはブロックチェーン上に永久に保存される変数です。

ブロックチェーンは改竄できないという認識だったのでブロックチェーン上にあるstorageを更新できることに違和感を覚えていました。

しかし、この違和感の原因は「ブロックチェーンは不変である」という先入観にありました。

確かにブロックチェーンは不変ではありますが、その対象はブロックやトランザクションそれ自体です。

Bitcoinであれば取引金額を変えることはできません。これはトランザクションのデータになっているためです。

これがEthereumのスマートコントラクトになった場合はどうでしょうか？

よく言われているのは「コントラクトをデプロイすると永久に残り続けるので慎重に上げるべき」というような話です。

これは間違ってはいません。なぜならコントラクトの「コード」はトランザクションのデータになるので不変です。

しかし、スマートコントラクト内のstorageやmemoryの変数はトランザクションのデータというよりもすマートコントラクト内のデータなので変数として扱うことが可能です。

最後に

ここまで述べたようにブロックチェーンには不変である部分と不変ではない部分があることがわかりました。

この誤解はそもそもブロックチェーンの定義を曖昧にしていたことやそもそも明確に説明してある情報が少ないことも起因しているとも感じています。

これから自分でもどんどん発信していけるように頑張ります！

もし認識が間違っている箇所があれば教えていただきたいです🙏

【参考記事】

https://jaredstauffer.medium.com/is-the-ethereum-blockchain-really-immutable-71ff3753ace7

Ethereumのスケーリング技術の一つ。いわゆるL2ソリューション。

という説明だと理解しにくいので前提から説明します。

Rollup誕生の経緯

Rollupの内容の前になぜRollupが誕生したのかを見る必要があります。

ブロックチェーンのトリレンマ(分散性、セキュリティ、スケーラビリティ)の中でEthereumにおいてはスケーラビリティ(処理能力)が問題になる。

そこでベースのブロックチェーン(レイヤー1・この場合Ethereum)ではなく、ベースのものではないブロックチェーン(レイヤー2)で処理することでスケーラビリティ問題を解決しようとした。

そのレイヤー2(以下、L2)は大きく4つあります。zk-Rollup、Validium、Optimistic Rollup、Plasmaの4つです。

その中の2つのソリューションにRollupが使用されています。

RollUpの特徴

Rollupは、Plasmaに似たL2スケーリングソリューション。

Plasma

Ethereumのブロックチェーンを親ブロックチェーン(ルートブロックチェーン)として、それぞれのプラズマブロックチェーンをツリー状に接続していく。

トランザクションはPlasmaブロックチェーン上で処理され、その結果が接続している親Plasmaブロックチェーンに伝わっていく。最終的にEthereumブロックチェーンにトランザクションが記録される。

しかし、Plasmaではスマートコントラクトの複雑性やルートチェーンに51％攻撃を受けるとプラズマチェーン全体に影響を受けてしまうなど、可用性の部分で問題になってしまう。

一方でRollupはデータ処理の一部をL2で行うが、L1であるEthereumの方にも処理を部分的に残していることによってセキュリティを維持した状態でスケーラビリティを向上させることができます。

Rollupの基本的な処理

1. EVMを通じてトランザクションを実行

2. データの抽出

3. データの圧縮

4. Ethereumに書き込む

4でEthereumに書き込む際には何千ものトランザクションを1つのRollupブロックにまとめて書き込むようになっている。

しかし、4で書き込む際にデータの有効性や悪意のあるデータかどうかを判断する必要があります。その判断を行う手法が先ほど述べたzk-Rollup、Optimistic Rollupになります。

Optimistic Rollup

zk-Rollupとは異なり、毎回Rollupコントラクトで検証しない。代わりに不正を告発するための紛争期間（Dispute period）を1〜7日程度設け、その期間内で無効なトランザクションを指摘したオペレーターやユーザーは該当ブロックを元に戻す、悪意のあるトランザクションを生成した当事者にペナルティを与える。

課題

L1のファイナリティに時間がかかるため、L1からの引き出しに時間がかかる。

zk-Rollup

全ての状態遷移に関して**ゼロ知識証明(SNARK)**を生成する必要がある。メインチェーン(Ethereum)のRollupコントラクトで検証を行う。

ゼロ知識証明とは、秘密を知っていることを秘密を教えることなく、第三者に秘密を知っていると証明できる仕組みのことで、私も具体的な仕組みはあまり理解していません、、、

zk-Rollupの流れ

1. ユーザーがトランザクションに署名してオペレーターに渡す

2. オペレーターは複数のトランザクションを受け取る

3. オペレーターは回路にトランザクションやMerkle Treeの情報をinputとして計算する(Prove)

4. 検証者(Ethereumのコントラクト)にProof(3の生成物)を渡して検証する

5. 新しいMerkle RootがEthereumコントラクトに刻まれる→残高が反映され、状態遷移が完了する

課題

証明生成の計算に時間とコストがかかる。

https://beincrypto.com/ethereum-merge-successfully-kiln-testnet/

ついにEthereumのMergeがテストネットで成功しました🎉

それに伴ってコンセンサスアルゴリズムがPoWからPoSに変更になりました。そこで両者の違いを自分なりにまとめてみました。

PoW

Proof of Workの略。Bitcoinで使用されていることで有名。

ブロックチェーンの仕組上、取引がなされた際にその取引データは他の人に承認されてブロックに取り込まれる。

その際にブロックの承認を行うために必要な計算(Nonceの計算)があり、それを早く解き切るとマイナーに選ばれ、報酬を受け取ることができる。

しかし、電力消費量が非常に大きくため、環境に負荷がかかる・個人で行うには設備等で莫大な費用がかかる。

PoS

Proof of Stakeの略。

トークンを一定数以上ステーキング持っているユーザーからランダムに選択し(バリデーターの選出)、そのバリデーターがブロックを承認することによって報酬を得ることができる。

特徴

• トークンを一定数有していると一定の信用があるという考え方

• PoWのように高性能のハードウェアを必要としない

• 個人での参入障壁が下がる

• Layer2ソリューションのRollup等と組み合わせてスケーラビリティの問題に対処できる

EthereumにおけるPoSの動き

バリデーターのやること

選ばれた場合→ブロックの作成

選ばれなかった場合→ブロックの検証を行う

ブロックの検証をattestingといい、「このブロックは良さそうだ」というのを証明しているイメージ。

もし、悪意のブロックに対してattestingした場合にはステークを失う。

シャードチェーン

シャーディングによってネットワークの混雑を減らし、シャードチェーンを作成することによって、1 秒あたりのトランザクションを増加させる。

64のシャードチェーンが存在し、それぞれがネットワークの状態を共有することになっている。

シャーディング

データベースを水平に分割して負荷分散を行うプロセス。

ビーコンチェーン

シャードチェーンの調整を行うチェーン。

シャードから状態情報を受け取り、他のシャードがそれを利用できるようにすることで、ネットワークの同期を保つことができる。

また、ビーコンチェーンは、バリデータのステーク入金登録から報酬・ペナルティの発行も管理する。

バリデーションの働き

シャードでトランザクションを送信すると、バリデータがそのトランザクションをシャーブロックに追加する役割を担う。

バリデータはビーコンチェーンのアルゴリズムによって選ばれ、新しいブロックを提案できるようにする。

Attestation

上記とか異なりバリデータが新しいシャードブロックを提案するのに選ばれなかった場合、他のバリデータが行ったブロックの提案に対して認証を行う。

ビーコンチェーンには取引自体ではなく、この認証に対して行われている。

各シャードブロックには少なくとも128人のバリデータが必要で、これを 「committee」と呼ぶ。

committeeにはシャードブロックを提案し、検証するための時間枠があり、それを「slot」と呼ぶ。

1つのslotには1つの有効なブロックを作成する。そのslotが32個まとまったものを「epoch」といい、1つのepochの検証が終了したらcommitteeは解散する。

その後、再び異なるランダムな参加者でcommiteeが再結成される。これによって悪質なcommiteeからシャードを保護することができる。

Crosslink

新しいシャードブロックの提案に十分な認証が得られると、ビーコンチェーンにブロックと取引が含まれることを確認する「Crosslink」が作成される。

このCrosslinkでビーコンチェーンとシャードチェーンがつながり、同期を行っている。

Crosslinkができると、そのブロックを提案したバリデータは報酬を得ることができる。

Finality

分散型ネットワークでは、ある取引が変更不可能なブロックの一部となっている場合、その取引は「Finality」を持つ。

PoSでこれを実現するために、FinalityのプロトコルであるCasperが使用される。

これはあるチェックポイントでのブロックの状態についてバリデーターに同意させるもの。

バリデータの2/3が同意すれば、そのブロックはファイナライズされる。

もしバリデータは、ファイナライズされたブロックを51％攻撃によって元に戻そうとすると、すべてのステークを失うことになる。

Web3に関心があるのでこれからコーディング等のWeb3に関する知識のアウトプットに利用していこうと思います！

今回はdAppsを練習で実装している際に「storage」と「memory」の扱い方に関して少し戸惑ったので備忘録として残しておきます。

storage

storageはブロックチェーン上に永久に保存される変数。

可変長配列を使用する場合、storageで宣言する必要がある。

関数外で宣言する場合、デフォルトでstorageになっている。

ブロックチェーン上に保存するので、ガス代が高くなる。

memory

コントラクトを実行する場合にのみ保持される変数。

→ブロックチェーン自体に保存されるわけではないため、storageと異なりガス代もかからない。

関数内で宣言する場合にはデフォルトでmemoryになっている。

実装の際に苦労した点

可変長配列を返そうと考えたが、結構苦戦しました。

以下がうまくいかなかったコードです。

function _transferableNFTs(uint256 stage) private view returns (NFTItem[] memory) {
        // return用の変数の宣言
        NFTItem[] list;
        // itemsは状態変数
        for (uint256 index = 0; index < items.length; index++) {
            if (items[index].stage == stage && !items[index].sold) {
                list.push(items[index]);
            }
        }
        return list;
}

memoryであるにもかかわらず配列の宣言の際に初期化を行っていないのでエラーになりました。

そして次に書いたのが以下のコード

function _transferableNFTs(uint256 stage) private view returns (NFTItem[] storage) {
        // return用の変数の宣言
        NFTItem[] storage list;
        // itemsは状態変数
        for (uint256 index = 0; index < items.length; index++) {
            if (items[index].stage == stage && !items[index].sold) {
                list.push(items[index]);
            }
        }
        return list;
}

デフォルトでmemoryになっているので宣言の際に「storage」を追加し、返り値もstorageに変更しました。

しかし、storageを返り値にすることができないためエラーになります。

そして以下のようなコードに変更しました

function _transferableNFTs(uint256 stage) private view returns (NFTItem[] memory) {
        // _transferableNFTCountで事前に配列の数を取得する
        uint256 count = _transferableNFTCount(stage);

        // return用の変数の宣言
        NFTItem[] list = new NFTItemUnsupported embed;

        // 新しい配列用のインデックスの宣言
        uint256 currentIndex = 0;

        // itemsは状態変数
        for (uint256 index = 0; index < items.length; index++) {
            if (items[index].stage == stage && !items[index].sold) {
                // pushではなく代入にする
                list[currentIndex] = items[index];
                currentIndex++;
            }
        }
        return list;
}

storageで値を返すことはできないので、memoryの宣言に変更しました。

**memoryで宣言する場合、固定長配列になるので事前に配列の長さを定義しておく必要があります。**そのため、宣言前に配列の長さを取得しています。

また、固定長配列の場合は「push」ではなく、代入になるので「currentIndex」というインデックスを別途宣言しています。

これによってmemoryでも実質的に可変長配列を返却できるようになります。

最後に

solidityに可変長配列がなさそうだったので実質的に実装しました。

もしより効率的な方法があれば教えていただけると幸いです🙇