分散化:NEM vs イーサリアム

 最終更新日2018/02/04    この記事は 約8分 で読めます。

とっかかりとして、イーサリアムよりもNEMの方が容易である件はようやく周知されてきましたが、個人的にはそれぞれに可能性を秘めているので必要以上に比較しなくてもいいかなと思ってます。

それぞれがそれぞれで経済圏作るなりして、人間は都合よくそれらが元になったサービス等をTPOに合わせて利用していけばいいのではないかと。もちろん本音を丸裸にした投資家目線では「できればNEMで!」というのはあります。

イーサリアムだけに限らず、他のプロジェクトについてもちゃんとコミュニティが動いて真っ当に開発と活動を広げているならば、積極的な投資や賛同はしなくても、リスペクトする気持ちは忘れないようにします。

では、和訳したので読んでみましょう。
(開発者寄りな内容なので記事の評価は開発者さんお願いします)

ビットコインから生まれた奇跡の子であるイーサリアムと、そのイーサリアム仮想マシン(EVM)は、最も有名なブロックチェーンのユースケースの1つです。多くのICOがスマートコントラクトを使ってビジネスを構築してきました。

そうしたスマートコントラクトの1つに分散型アプリケーション、通称DAppsがあります。この記事では私たちは次のことを検討していきます。イーサリアムは本当に分散型なのか?ブロックチェーンアプリケーションを開発するための別の方法、もしくはより優れた方法はないのか?

ビットコインの基本的なスクリプト言語を使って、ユーザーは自動的にあるタスクを行ってくれるアプリケーションを作ることができます。そうしたアプリケーションはほとんどがプライベートなサーバー上で稼働しており、中央集権的な機関に管理されています。

それらのアプリケーションはNEMのものと同様の仕組みです。NEMとはゼロから構築されたまったく新しいブロックチェーンで、ビットコインよりもアクセスしやすい幅広い機能を持っています。

NEM(第二位の人気を誇るICOプラットフォーム)を攻撃する人々の主な言い分は、NEMが分散型スマートコントラクトを採用していないというものです。しかし、イーサリアムは本当に彼らが宣伝しているような分散型のものなのでしょうか?アプリケーションの強度やセキュリティを犠牲にしてまで分散化を試してみる価値はあるのでしょうか?

NEM上でコントラクトを構築するためには、1つ以上のAPIリクエストを使用して、それをオフチェーンのアプリケーションでグループ化しなければなりません。技術的には、NEMプラットフォーム上のオープンソースコードが本当にエンティティのサーバー上で稼働しているコードなのかを確かめるのは困難です。しかし、だからといってそれがイーサリアムのコントラクトよりも分散化されていないと言えるのでしょうか?

分散化を擁護するための最初の反論は、イーサリアムのソースコードのコンパイルについてのものでしょう。現在、EVM上のアプリケーションのほとんどはSolidityによりコンパイル済みのバイトコードで、Serpentによってコンパイル済みのものは少数派です。では、シンプルなHelloWorldのコントラクトを例にとってみましょう。

あるコントラクトを信頼できるか確認しようとするたびに、私たちユーザーはオープンソースコードを利用し、それを元々使われていたものと同じコンパイラーでコンパイルし、それから私たちがその作業で得たバイトコードがアップロードされたコントラクトのバイトコードと一致するかを確かめなければなりません。

Bytecode:
“0x6060604052341561000f57600080fd5b6101578061001e6000396000f300606060405260043610610041576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063942ae0a714610046575b600080fd5b341561005157600080fd5b6100596100d4565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561009957808201518184015260208101905061007e565b50505050905090810190601f1680156100c65780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b6100dc610117565b6040805190810160405280600a81526020017f68656c6c6f576f726c6400000000000000000000000000000000000000000000815250905090565b6020604051908101604052806000815250905600a165627a7a72305820e417728d298add6f4e1210005cf05cb6f6f0f2bdfcf162e4e756e53e71d478660029”

(イーサリアムのSolidityコントラクトと、バイトコードへとコンパイルされてEVM上へのアップロードの準備が整った同じコントラクト)

しかし、使用するあらゆるコントラクトをコンパイルしてバイトコードを確認することが最大の問題なのではありません。現在、Solidityのコントラクトをより堅牢で「アップグレード可能」なものにするためには、Solidityの開発者はOwnable.solと呼ばれる特別なコントラクトを使って、コントラクトの所有者が変数の修正、コントラクトの無効化、所有者の変更などを行えるようにしなければなりません。

Ownable.solはコントラクト作成の際によく使われており、イーサリアム上の主要なコントラクトも採用しています。そのことがイーサリアム上のコントラクトを中央集権的なものにし、それと同時にはるかに堅牢なものにしています。それによってコントラクトの所有者が、コントラクトのロジックを変更することなく外部のデータストレージに書き込みを行うことが可能になります。

また、もっとも現代的なコントラクトは、変更不可能なデータストレージから更新可能な、バージョン管理システムやand/orのデタッチロジックを用いてアップグレード可能です。

イーサリアム仮想マシン(EVM)向けのSolidityコードを書く際には、そうした技術を使うのは良い習慣だと考えられています。しかし、それは、よりコントラクトを主眼に置きつつもコードの上でより安全なスクリプト言語(歴史のあるビットコインや将来性のあるNEM)とは大きく異なります。

結局のところ、現代的なSolidityのコントラクトは、タイムスタンプのデータをブロックチェーン上に保存しているという点でしか分散化されてはいないのです。一方で優れた設計を持つコントラクトは所有者によって変更可能です。

しかし、もしもそれがチューリング不完全なブロックチェーンと変わらないのであれば、ブロックチェーンにアクセスするために、なぜまた別の複雑な言語を学ぶ必要があるのでしょうか?RestfulAPI ベースのNEMブロックチェーンを使えばよいだけでしょう。

 - NEM(ネム) ,

  著者プロフィール

お忙しいところ、貴重なお時間の中での当サイトへのご訪問ありがとうございます。

WEBデザイナー/ディレクターとしてのリーマン生活を脱却し、FX専業(兼業?)トレーダーをやりながら、MT4のEA/インジケーターの開発やFX関連情報サイトを運営していました。

今ではもう暗号通貨に絞って福岡を拠点に隠密活動しています。主にNEMをガッツリ、EthereumのDappsは趣味程度に。10年近いトレーダー経験を活かし、暗号通貨相場のテクニカル分析もやってます。

またの機会にぜひ当サイトをご利用いただけるご縁があればとても嬉しく思います。今後ともよろしくおねがいいたします。