最近ツイッターで文章を書いていて、「ですます調」のほうが血の通った感じで書けそうなので、今回から文体を変えて書いてみます。過去の記事も順次書き直していこうと思います。

スマートコントラクトはアップデートしづらい

ソフトウェア業界にいる方ならわかっていただけると思いますが、デジタル 世界は基本的に「アップデート主義」です。

多くの時間をかけて作った自慢のサービスを満を持してリリースして、不具合が見つかったらすぐにパッチをあてる、ユーザーからのフィードバックを受けて機能を改善していく。日々その繰り返しです。

Kindleの電子書籍も、たまに更新通知がきて表紙とか内容が変わりますよね。更新しづらいと言われてきた出版物ですら、そんな感じです。

しかし、この当たり前がスマートコントラクトの世界では通用しない！

スマートコントラクトの売りのひとつが、「プログラム自体がブロックチェーン上に展開されるため、プログラムも改ざんできない」です。

改ざんできないということは、言葉を変えると「ずっと変わらない」ということ。

ずっと変わらないことを前提としてるから、スマートコントラクトの更新前後の整合性については、プラットフォームでは特にサポートしていません。

で、でもですね、アップデートしないわけにはいかないんですよ！！

そこそこの行数のコードを書けば、バグは含まれてるし、何よりユーザーのニーズはどんどん変わる。パブリックチェーンであってもプライベートチェーンであっても、アップデートは避けて通れないのです。

アップデート戦略を考えよう

スマートコントラクトでプログラムを書くのであれば、初期段階でアップデート戦略を考えておいたほうがいいです。

特に気をつけたほうがいいのが、データ構造が変わること。

スマートコントラクトの世界では、データ構造が変更になったからといって、たやすく過去のデータを補正するなんてできません。

データ補正専用のスマートコントラクトを作ってリリースしなければならず、しかも一時的なプログラムにも関わらず、未来永劫ブロックチェーンに残りつづけてしまう有様です。

したがって、過去のデータは過去のデータとして受け入れ、スマートコントラクト上で過去のデータと新しいデータを整合させるという、後方互換対応が求められます。

スマートコントラクトでアプリケーションを作るときは、通常のWEBアプリケーションを作る時よりも、後方互換性に注意して設計したほうがいいです。

未来を予測して、余白を作ろう

スマートコントラクトのデータ設計で大事なことは「未来を予測すること」と「余白を作ること」に尽きます。

今の仕様に基づいて、精密機械のような緻密さで設計してしまうと、一つの変更が全体に波及するリスクが高くなります。

このプロダクトの未来に何が起きるかを限界まで想像して、必要となる項目は初期段階から組み込んでおくほうが無難です。

カラシニコフ自動小銃のように、部品間に意図的に”余白(遊び)”を持たせて、変化の激しい状況でも作動しつづけることを目指すのです。

なぜゴルゴはかの銃を選んだか？AK-47 VS M16

スマートコントラクトで扱うデータの中に、備考1〜備考10くらいの空き枠を作っておくのも、案外バカにできない設計だったりします。
新しい項目を追加するのに比べれば、備考1は〇〇と認識レベルで解決してしまったほうが楽です。

{
    "documentType": "PaymentToken",
    "amount" : 10000,
    "description1" : "xxxxxx",
    "description2" : "xxxxxx",
    "description3" : "xxxxxx",
    "description4" : "xxxxxx",
    "description5" : "xxxxxx",
    "description6" : "xxxxxx",
    "description7" : "xxxxxx",
    "description8" : "xxxxxx",
    "description9" : "xxxxxx",
    "description10" : "xxxxxx"
}

周囲からは無駄だと批判されるかもしれませんが、これくらいの雑さが、動作の確実性に大きな影響を与えるのです。