見出し画像

スマートコントラクトを作ってみた

イケガミコフ

スマートコントラクトを作ってみた

スマートコントラクトとは

スマートコントラクトとは、ブロックチェーン上で保存された、決められた条件で実行されるプログラムのことで、今後、DAO（自律分散組織）やDApps（分散型アプリケーション）への応用が期待されています。

スマートコントラクトは、よく自動販売機にも喩えられます。お金を入れると飲料が出てくるというような自動化された取引というような意味合いです。このデジタル世界における「自動販売機」が広く普及することで、様々な取引の合理化が可能になると考えられているのです。

そんなスマートコントラクトを用いて、今回は実験的に独自トークンと暗号資産の交換を実装してみました。

どんなものを作ったか？

今回実装した内容は、サクラストークン（SK）という独自トークンをMATICという暗号資産に自動的に交換する（あるいはその逆も）というものです。

計画当初のメモ

今回、交換レートは1SK=10MATICで固定しています。
なお2024年2月4日現在、1MATICは115円前後で取引されています。

どの程度実用性があるのか？検証

今回は単にスマートコントラクトを実装したというだけでなく、実業での応用可能性を念頭に、社内での実験も行っています。

検証したかったこととしては、報酬を受取るためにメンバーは、ウォレットのセットアップなど環境構築のハードルを乗り越えてくれるのか？ということです。暗号通貨の取扱いにあたっては、一般に、（現在のところ）最初のハードルが高いことが知られています。

今回は、12月度の表彰対象者に対し副賞としてこのサクラストークンを付与しました。配布対象者は今回のスマートコントラクトを活用することによって、副賞として配られたトークンを暗号資産に変換できることになります。

配布時の様子


これまでの経緯

なぜ今回そんなことをやりたいと思ったか？　本章では当社におけるこれまでの経緯についても、簡単に紹介しておきたいと思います。

大人数の組織

導入の動機の1つめは、当社における働き方です。
当社では創立当初からほぼフルリモートで業務委託の面々を中心に構成されていて、現在も50名のメンバーがいます。

一方でひと月の労働時間はのべ511時間（2024年1月・社員1名を除く）ほどしかなく、フルコミットの社員に換算するとわずか3人ほどの分量を50名で行っていることになります。

もちろんこの511時間には、きわめて労働集約的な作業から専門的なアドバイスの時間まで様々な時間が含まれているため、単純に合計してよいものではありませんが、業務量に比べてとても人数が多いことは確かです。

そのため、メンバーと契約して発注して検収をして支払をするといったマネジメント業務を大人数に対して行っていく部分で、合理化の必要性がとても高いということがあります。

オフチェーンでのDAO的組織運営

導入の動機の2つめとして、過去のDAO的な取り組みがあります。

上記のような大人数組織（業務量に対しては大人数）の合理化ニーズがあるなかで、当社では、もともと様々な先進的組織運営の試みを行ってきました。オフチェーンでのDAO的組織運営もそのひとつです。

これは、2022年3月より1年間実践していたもので、納品物や会議参加毎に独自トークンを付与し、そのトークンを報酬額の決定や自動人事評価、組織運営のための投票などに使用していました。

但し、トークンといってもその管理をスプレッドシート上で行うというものです。スプシで行っていては、まるでWeb3的で無いと思うかもしれませんが、重要なのは（技術的仕様に強制される以前に）組織運営がそもそも自律分散型であることと考え、当時は今よりもさらに技術的な制約が多かったこともあり、技術よりも先に運営をDAO化するということをやっていました。

参考迄に当時の記事はこちらです。（※こちらの記事中の「サクラストークン」と今回発行した「サクラストークン（SK）」は別のものです）


対応力の高い組織

導入の動機の3つめは、動機というか、それが可能な文化的な下地があるということです。

50人の業務委託、（オフチェーンですが）トークン運営、などかなり先進的な取組みにも挑戦してきたということで、変化への対応力は高い組織と言えると思います。

本業でデジタル改革を支援していることもあり、デジタルにももちろん明るいメンバーで、Z世代中心で平均年齢が20代と若い（平均をとれば・・・）こともあります。

そのため折角その下地があるのだから、（web3はまだまだマスアダプションできてないと言われるけど）常に「最先端」に挑戦し続けたいと思っています。

実装方法

ここでは、開発環境等について解説します。
※以下、本章は今回、実際に実装してくれたYH24君による解説です。

ブロックチェーンについて

ブロックチェーンは、Polygonを使用しました。PolygonはEthereumの拡張を目的としたブロックチェーンで、MATICという独自の暗号資産が使用されています。Ethereumよりも取引手数料（ガス代）が大幅に安いことが特徴です。

プログラミング言語について

プログラミング言語は、Solidityです。Solidityはスマートコントラクトを作成するための機能を備えたプログラミング言語です。 オブジェクト指向であり、人間にとって理解しやすい構文である高級言語です。

開発環境について

トークンの発行とスマートコントラクトの開発には、OpenZeppelinというプラットフォームを使用しています。OpenZeppelinを使用することで、1からスマートコントラクトを書く必要がなくなり、開発効率を向上させることができます。

サイトにアクセスし、トークンの名前、シンボル、発行量を入力します。
右上のOpen in Remixのボタンをクリックすると、Solidityをデプロイするためのサイト「Remix」に接続し、雛形が入力された状態になります。

https://docs.openzeppelin.com/contracts/5.x/wizard

今回の場合はここにさらに機能を追加したいので、次節で紹介するコードを追加しています。

コード追記後は、Remixの左側のメニューから、「SOLIDITY COMPILER」を選択し、青色の「Compile」ボタンをクリックします。
※この時、下にある「ABI」の部分でコピーできるテキストを必ず保存しておいてください。

コンパイルが終わりチェックマークが出ると、左側のメニューから「DEPLOY & RUN TRANSACTIONS」を選択します。このページでコントラクトをデプロイします。「ENVIRONMENT」で「Injected Provider - MetaMask」を選択し、MetaMaskの自分のアカウントを連携します。

オレンジ色の「Deploy」ボタンの右に自分のMetaMaskのアカウントアドレスをペーストし、クリックすれば完了です。
※この際に「Deployed Contracts」に現れるデプロイしたコントラクトアドレスを必ず保存しておいてください。

ソースコードの内容

最後に、今回追記したコードを紹介します。上から順にトークンを買う機能、トークンを売る機能、トークンとMATICのレートを設定する機能、コントラクトアドレスにあるMATICを引き出す機能です。

なおトークンとMATICのレートを設定する機能とコントラクトアドレスにあるMATICを引き出す機能はオーナー権限のあるアカウントのみ使うことができるように設定してあります。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts@5.0.1/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts@5.0.1/token/ERC20/extensions/ERC20Permit.sol";
import "@openzeppelin/contracts@5.0.1/access/Ownable.sol";

contract MyToken is ERC20, ERC20Permit, Ownable {
     uint256 public conversionRate = 10;

    constructor(address initialOwner)
        ERC20("MyToken", "MTK")
        ERC20Permit("MyToken")
        Ownable(initialOwner)
    {
        _mint(msg.sender, 200000 * 10 ** decimals());
    }

    // Function to buy tokens with MATIC
    function buyTokens() public payable {
        uint256 tokensToBuy = msg.value * conversionRate;
        _mint(msg.sender, tokensToBuy);
    }

    // Function to sell tokens for MATIC
    function sellTokens(uint256 _tokenAmount) public {
        require(balanceOf(msg.sender) >= _tokenAmount, "Not enough tokens");
        uint256 maticToTransfer = _tokenAmount / conversionRate;
        payable(msg.sender).transfer(maticToTransfer);
        _burn(msg.sender, _tokenAmount);
    }

    // Function to set conversion rate
    function setConversionRate(uint256 _newRate) public onlyOwner{
        // Add onlyOwner modifier or similar access control for production
        conversionRate = _newRate;
    }

    // Function to withdraw MATIC (for owner)
    function withdrawMatic(uint256 _amount) public onlyOwner{
        // Add onlyOwner modifier or similar access control for production
        payable(msg.sender).transfer(_amount);
    }

    // Fallback function to handle receiving MATIC
    receive() external payable {
        buyTokens();
    }
}


実験の結果

ここからは再び池上による紹介で、まずは今回の取り組みの結果です。

下準備としてトークンを準備

なお、そもそも下準備として、配布する側の私（会社側の役割）も、予めMATICを購入し、それをサクラストークンに変換、トークンを入手しておきます。
それを各メンバーのウォレットに配布しました。


どの程度使われたか？

今回は11月度の表彰対象者、4人に対してアナウンスを実施し、うち3人にサクラストークンを送付しました。さらに2人はMATICへの変換まで済ませたようです。

今回は日本円にして1万円相当の価値のものを送りましたが、金額によっても結果は変わってきたものと思います。

各自でウォレットを設定してトークンを受け取り、さらにそれをスマートコントラクトで暗号通貨に変換するという一連の流れでしたが、今回は4分の2のメンバーが期限内に最後まで操作してくれたようですが、「自動販売機」と呼ぶにはやはりまだまだハードルが高いように思います。

やってみてわかることも

発行する側としては魅力的

一方で、トークンを発行する会社側の手間はそれほど多くないと感じました。

最初にコントラクトやトークンの発行など必要な手続きを済ませておけば、クラウドサインや発注書の送付、銀行振込など既存の業務フロー全体に比べて効率化できる可能性は高いと感じます。

（もちろん税務面・法務面・セキュリティ面など別の問題はあるかと思いますのでそれがクリアになればですが）

今後の計画

最後に本章では、今後の計画について個人的な見解を書いておきます。

未来の組織の姿は？

まず、未来の組織の姿として想像していることを書きます。

※実際には、様々な技術的・法的な制約、セキュリティ上の懸念等を乗り越える必要があるとは思いますが、5年後くらいの話として、ここではいったんゼロベースで列挙してみます。

  • 会社発行トークンが分散型取引所で取引される

  • 業績に連動したレートでの、会社による自社トークン買い

  • 納品や会議参加による自動的なトークン付与

  • 採用と資金調達、マーケティングの境界線が薄くなる

先々はこうしたことが可能になるのではないかと予想しています。
このあたりのことは、もっと書きたいことがあるので詳細はまた別の機会に譲りたいと思います。

今後の開発内容の例

もう少し現実的な計画として、次に開発してみたい機能は例えば以下のようなものを考えています。

  • スマートコントラクトと連携したNFTの発行

  • 事業部別トークン買取り価格の設定

  • タイムシートからのトークン付与

こうしたことを開発していくことで、未来像と現在の間にひとつ具体的な像を結んでこのブログでもまた紹介できると思います。

実際に経済的なインパクトを出すというよりも、シンボル？アート？彫刻？に近い開発になってしまうかも・・しれませんが・・それでもなるべく実用性あるものを作れるように頑張りたいです。

おわりに

「スマートコントラクト」というのは概念としては非常に面白いものだと思っていたので、今回、実際に作って動かしてみて手触り感を持てたことは非常に良かったと思います。

web3まわりはどうしても抽象的な話が多く理解しにくいことも多いと思うので、今後も具体的な実務への応用を可能な限りやっていきたいと思います。

※本記事は、ブログの読者に向けた一般的な情報を提供することのみを目的としています。本サービスのいかなる内容も、投資家を対象としたものではなく、また投資家が依拠すべきものでもありません。本記事は、当社や金融商品への投資を勧誘したり投資を募集する意図はありません。本記事に含まれる情報および資料の正確性、妥当性、または完全性を保証せず、資料および情報の誤りまたは脱落に対する責任は負いません。暗号通貨に関する税務上の取扱いや金商法会社法上のトークンの取扱い等については専門家のアドバイスに従って下さい

免責事項


この記事が気に入ったらサポートをしてみませんか？