メインコンテンツまでスキップ

「Ethereum」タグの記事が52件件あります

全てのタグを見る

· 約4分

イーサリアムは 2015 年から稼働してから既に 7 年間以上稼働しています。 全体的な完成度は、vitalik は 2022年9月15日実施された The Merge の後、ようやく 55% になっていると発言しています。 改めて、イーサリアム 2.0 のロードマップを確認してみたいです。

· 約3分

The Merge が実施され、イーサリアムは順調に 2.0 に進んでいます。 コンセンサスアルゴリズムが PoS に切り替え、シャーディングも実装されるため、1.0 よりアーキテクチャが複雑になってきたので、整理してみました。

2022 年 12 月では、シャーディングまだ実装できていません

· 約3分

イーサリアム 2.0 の The Merge 実施できて PoS に切り替えたので、テストネット Ropsten / Rinkeby / Kiln がシャットダウンして、今後は、テストネットは Goerli と Sepolia が稼働するためこちらを使いましょうと発表されました。

https://blog.ethereum.org/2022/06/21/testnet-deprecation

本記事では、Goerli テストネットの ETH 入手方法を紹介します。

· 約4分

web3.0 アプリケーションを開発するとブロックチェーンの RPC サーバーが必要になりますが、自分で用意せずに他のサービスを使う場面も多々あります。

infura.io は老舗ですが、後続のサービスとして、alchemy も有力な選択肢になってきています。また、基本のブロックチェーン RPC サーバー以外、他の便利な API が提供されていて、かつ SDK も提供されているので、詳細内容を紹介します。

image0.png

· 約5分

スマートコントラクトで実装する web3.0 アプリケーションは、公開・透明を実現する為ほとんどオープンソースしているので、資産を持っている上に全ての処理を公開していて、非常時攻撃されやすい状況になっています。 よって、web3.0 アプリケーションにとっては、スマートコントラクトのセキュリティは一番重要なことと言っても過言ではありません。

本記事では、初心者向けに、Re-Entrancy 攻撃と対応方法を紹介します。

· 約4分

OpenZepplin の ERC721 スマートコントラクトのソースに、知らなかったキーワード unchecked があったので調べてみました。

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol#L286-L308

function _mint(address to, uint256 tokenId) internal virtual {
    require(to != address(0), "ERC721: mint to the zero address");
    require(!_exists(tokenId), "ERC721: token already minted");

    _beforeTokenTransfer(address(0), to, tokenId, 1);

    // Check that tokenId was not minted by `_beforeTokenTransfer` hook
    require(!_exists(tokenId), "ERC721: token already minted");

    unchecked {
        // Will not overflow unless all 2**256 token ids are minted to the same owner.
        // Given that tokens are minted one by one, it is impossible in practice that
        // this ever happens. Might change if we allow batch minting.
        // The ERC fails to describe this case.
        _balances[to] += 1;
    }

    _owners[tokenId] = to;

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

    _afterTokenTransfer(address(0), to, tokenId, 1);
}

· 約4分

Ethereum のアカウントが下記２種類があるのは既に知られていると思います。

  • EOA：外部所有アカウント、つまり人間がプライベートキーで制御して使うアカウント
  • CA：コントラクトアカウント、スマートコントラクトをデプロイしてできたアカウント。プライベートキーなし

また、現状はプロトコル上、トランザクションは EOA による電子署名したものである前提になっている為、すべてのトランザクションが EOA からトリガーさせて実行していて、CA からはトリガーできません。

せっかく CA でいろいろ自動化できているので、この差をなくして EOA なしでもっとコントラクトウォレットを利用したいことが結構初期段階から考えられています。 また、 EOA の場合プライベートキーでフルコントロールできるため、セキュリティ向上は重要な課題であり、常に問題視されています。 これらを解決するために、EOA ではなく、CA を活用しよりセキュアなウォレットを実現したいのが、Account Abstraction （AA）になります。

他の EIP もありますが、新しいトランザクションタイプの追加や新しい opcode の追加のようなプロトコルレイヤーの修正が必要なので、あんまり進められていませんでした。ERC4337 は、それらの修正の必要ない新しい考案であるため注目されています。

ERC4337 の設計は、メタトランザクションを参考して実現しています。参考記事が詳細があるので、ここはシーケンス図を載せておきます。