前提知識集とはJPYC研究開発チームの記事を読む上で必要な前提知識を集約する記事です!基本的に公式ドキュメント、公式サイトから引用しています。自社記事もリンク付けしていく予定です。前提知識Blockchainの概要ブロックチェーンはビットコインの誕生によって出現した言葉です。Wikipediaによると、ブロックチェーンは「2つの当事者間の取引を効率的かつ検証可能で恒久的な方法で記録することができるオープンな分散型台帳」です。これにより、次から次へとイノベーションがおきて、イーサリアムの誕生によりスマートコントラクトのようなトラストレス(カンターパーティリスクが除去された)なシステムが形成されて、手数料をとるミドルマンの除去、ひいては人間社会の協力関係まで一変させる可能性があると言われています。ブロックチェーンがweb3.0のベースレイヤーとも呼ばれたりします。ECDSAデジタル署名アルゴリズムの一つでイーサリアムにおいてハッシュメッセージの身元の検証に使われています。EVMオペコード自体に検証できるものが用意されていますが、メッセージに対して署名が一意である制約がないため、OpenZepplinのライブラリを使用した方が安全です。ExampleEIP2612ERC20トークンの一般的な移転方法にapproveとtransferFromの組み合わせがあります。これの相互作用により、EOA間に留まらないアプリケーション固有のトラストレスな取引を可能にしています。これらのトランザクションは通常、ユーザのEOAによって実行される必要があります。そこでEIP2612では新しい関数permitを用意し、ユーザーがトランザクションを実行することなく、EIP712に準拠した署名だけでapproveすることを可能にします。OpenZeppelin公式ドキュメントEIP3009EIP2612と機能は似ていますが互換性を最大化するために、コントラクトにはEIP2612とEIP3009の両方を実装することが望ましいです。EIP2612との違いはEIP2612がシーケンシャルナンスを使用するのに対しEIP3009ではランダムな32バイトのナンスを使用する点と、EIP2612ではapproveとtransferFromのパターンに依存している点です。attackの影響を受けやすいという問題があったのでEIP3009ではそれらに対応しました。ethreum.orgEIP712構造化データのハッシュ値を求める標準規格です。エンコーディング関数の正確さのための理論的フレームワークで、Solidity構造体に類似し、EVMでのハッシュアルゴリズムに最適化されています。リプレイ攻撃の対策はしていません。OpenZeppelin公式ドキュメントERC20代替可能トークンの標準規格です。ERC20トークンと呼ばれるにはERC20で定められている全てのメソッドとイベントを用意しなければいけません。ERC20には受信したERC20トークンを操作できないコントラクトにも送信できてしまう問題があり、その問題を解決するためERC223やERC777といった新しい標準規格が提案されています。OpenZeppelin公式ドキュメントOraclesオラクルを一言でいうと、「ネットワークの外にあるオフチェーンのデータを、ネットワーク上のオンチェーンに持ってくる仕組み」です。使われるオラクルですが、その中でもchainlinkがよく名前が上がります。chainlinkは外部のデータソースを分散化してインセンティブを与えた上でオラクルの仕組みや信頼を築いています。現在のブロックチェーンのdAppsの世界においてはなくてはならない存在と言っても過言ではありません。記事SoliditySolidityはスマートコントラクトを実装するためのオブジェクト指向の高級言語です。SolidityはEVMをターゲットにC++、Python、JavaScriptの影響を受け、設計されています。Exampeleが参考になると思います。Blogで確認できますが、基本的には最新版が推奨されています。BlogUpgradeabilityアップグレード可能なスマートコントラクトはコントラクトアドレス、ステート、バランスの状態を維持しながら、コードを変更することができます。それにより、新しい機能を追加したり、本番環境で見つかったバグを修正することができます。アップグレード可能なスマートコントラクトはproxyコントラクトとimplementationコントラクトの二つで構成されており、proxyコントラクトは全ての呼び出しをimplementationコントラクトに委任するだけの単純なコントラクトです。その呼び出しの際に使用されるdelegatecallですが、呼び出したコードの実行を、呼び出し元のコンテキストで行われるという特徴があり、それにより、proxyコントラクトが状態を保存しimplementationコントラクトがコードを提供することを可能にしています。改ざん不可能とされるスマートコントラクトを変更可能にしたので賛否両論はあります。伝統的な契約の場合、もし両者が後で同意すれば変更可能なのと同じように、スマートコントラクトも変更できるようにしたらどうなのかという発想から来ています。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。