BitShares創設者：Liskのスマートコントラクトはスマートではなく、イーサリアムよりはるかに劣っている

Lisk のスマート コントラクトはそれほどスマートではありません。ブロックチェーン開発者として、私はLiskのマーケティング資料を読んだときに興奮しました。完全に JavaScript で駆動するブロックチェーン コンセプトとスマート コントラクト プラットフォーム。これは私がずっと構築したいと思っていたものです。これを行ったことがないのは、それに伴う複雑さが時間と予算の面で私の許容範囲を超えているからです。

（写真：BitSharesの創設者、ダニエル・ラリマー）

スマートコントラクトプラットフォームの目的

ブロックチェーン技術の開発は、ソフトウェアが決定論的に動作し、望ましくない副作用を残さずにエラーから回復できることを保証する必要があるため、困難です。浮動小数点数を使用した数学演算のような単純なものでも、非決定的な動作が発生し、損失につながる場合があります。

スマート コントラクト プラットフォームを設計する際に、開発者に次のツールを提供したいと考えています。

1. エラーが発生した場合の自動ロールバック。

2. 非決定論的なコードを生成できません。

3. 無限ループを防止したり、計算全体を測定したりする機能。

4. 無制限のメモリ増加を防止したり、メモリ消費を測定したりする機能。

私が最も感銘を受けたのは、Lisk が上記の問題のいずれも解決していないことです。彼らの「サンドボックス」は信頼できないコードを実行するために使用できず、彼らの理論的枠組みは非決定論的な動作に対する保護を提供しておらず、リソースの使用量を測定または制限する方法はなく、エラーを正しくロールバックできることを保証するツールさえ提供されていません。

状況はどのくらい悪いですか?

私は Lisk のいくつかの「アプリケーション」の例を調べることにしました。最初の例は、シンプルなメッセージング アプリケーションでした。このアプリケーションの目的は、ブロックチェーンを通じて人々が互いにメッセージを送信できるようにすることです。 Lisk 開発者として、次のことをやりたいです。

1. メッセージを定義し、シリアル化操作を実行します。

2. リクエストを手動で処理し、データベースへの変更を元に戻します。

3. ブロックチェーンの残高の変更を手動で解決します。

4. 「確認済み」および「未確認」ステータスを手動で処理します。

ご覧のとおり、Lisk は開発者にほとんど何の助けも提供していません。実際、開発者に提供される API は過度に複雑で、初期の BitShares 1.0 フレームワークを思い出させます。 BitShares 1.0 では、プロジェクトの速度が低下し、エラー率が信じられないほど高くなることがわかりました。

Lisk 対 非スマートコントラクト プラットフォーム

私は最近、スマート コントラクト プラットフォームでもない「Steem」に同様のメッセージング アプリ (別名プラグイン) を実装しました。私のメッセージング プラグインは、Lisk アプリよりも少し強力で複雑です。そこで、以下に簡略化したバージョンを示します。コードが理解できない場合は、心配せずに説明を読んでください。

ステップ1 – メッセージを定義する

構造体プライベートメッセージ{
文字列から;
文字列に;
文字列メッセージ;
};
FC_REFLECT( プライベートメッセージ、(送信元)(送信先)(メッセージ) )

ステップ2 - データベースとインデックスを定義する

この手順は、標準の Boost マルチインデックス コンテナーを使用する場合よりもそれほど複雑ではありません。これらに含まれるライブラリのパフォーマンスは、同様のインデックスを持つどの SQL データベースよりも優れています。この場合、受信または送信された順序で情報を簡単に要求できる強力なインデックスを構築します。これにより、各ユーザーは「受信トレイ」と「送信トレイ」の機能を使用できるようになります。

構造体メッセージオブジェクト{
受信時刻;
文字列から;
文字列に;
文字列メッセージ;
};
FC_REFLECT_DERIVED ( message_object, (db::object), (受信)(送信元)(送信先)(メッセージ) )

構造体by_to_date;
構造体by_from_date;
構造体by_id;
typedef マルチインデックスコンテナ<
メッセージオブジェクト、
インデックス付き<
ordered_unique< タグ< by_id >、 member< オブジェクト、 object_id_type、 &object::id > >、
ordered_unique< タグ< by_to_date >、
複合キー< メッセージオブジェクト、
メンバー< message_object, 文字列, &message_object::to >,
メンバー< message_object, time_point, &message_object::receive_time >,
メンバー<オブジェクト、オブジェクト ID タイプ、&オブジェクト::ID >
>、
複合キー比較<以下、
より大きい<時点>、
以下< オブジェクトIDタイプ > >
>、
ordered_unique< タグ< by_from_date >、
複合キー< メッセージオブジェクト、
メンバー< message_object, 文字列, &message_object::from >,
メンバー< message_object, time_point, &message_object::receive_time >,
メンバー<オブジェクト、オブジェクト ID タイプ、&オブジェクト::ID >
>、
複合キー比較<以下、
より大きい<時点>、
以下< オブジェクトIDタイプ > >
>
>
> メッセージマルチインデックスタイプ;

typedef generic_index< message_object, message_multi_index_type> private_message_index;

ステップ3 - APIを定義する

第三者がアプリケーションの状態を検査できるようにすることを目的とした API を定義します。この例では、受信トレイ用と送信トレイ用の 2 つの API 呼び出しが必要です。

クラス private_message_api : パブリック std::enable_shared_from_this<private_message_api> {
公共：
typedef vector<message_object> メッセージ;
private_message_api(const app::api_context& ctx):_app(&ctx.app){}

メッセージ get_inbox( 文字列 to、 time_point 最新、 uint16_t 制限 )const;
メッセージ get_outbox( string from、 time_point newest、 uint16_t limit )const;
プライベート：
app::application* _app = nullptr;
};

ステップ4 - メッセージハンドラーを実装する

このメソッドの目的は、各private_message操作がブロックチェーンに含まれるときに状態を更新することです。メッセージ ハンドラーは、メッセージが送信者によって署名されているかどうかを確認し、署名されている場合は情報をデータベースに追加する役割を担います。

 void private_message_plugin::on_operation(const operation_object& op_obj) {
if( op_obj.op.which() == operation::tag<custom_json_operation>::value ) {
const custom_json_operation& cop = op_obj.op.get<custom_json_operation>();
if( cop.id == "private_message" ) {
自動メッセージ = json::from_string(cop.json).as<private_message_operation>();
FC_ASSERT( cop.requires_auth(message.from),"送信者がメッセージに署名しませんでした" );

db.create<メッセージオブジェクト>( [&]( メッセージオブジェクト& pmo ) {
pmo.from = pm.from;
pmo.to は pm.to に置き換えられます。
pmo.message = pm.message;
pmo.receive_time = db.head_block_time();
});
}
}
}

ステップ5 - APIの実装

この API は、JSON RPC を介してsteemdプロセスにアクセスできます。 get_outbox API は、 by_to_dateの代わりに代替ディレクティブby_from_dateが使用される点を除いて、ほぼ同じです。

メッセージ private_message_api::get_inbox( 文字列 to,
time_point 最新、
uint16_t 制限 )const
{
const auto& pmi = db.get_index_type<プライベートメッセージインデックス>();
const auto& idx = pmi.indices().get<by_to_date>();

メッセージの結果;
自動 itr = idx.lower_bound( make_tuple( to, newest ) );
itr != idx.end() && limit && itr->to == to ) {
結果.push_back(*itr);
++itr; --制限;
}

結果を返します。
}

SteemとLiskの比較

この特定の情報アプリケーションの場合、Steem の例は Lisk の例よりも堅牢で簡潔です。特に、次の点に気付いた場合:

1. アプリ開発者は元に戻す機能を実装しませんでした。

2. アプリ開発者はコストを心配する必要がありません。

3. アプリケーション開発者は、確認済みと未確認の違いを気にする必要がありません。

4. アプリケーション開発者はシリアル化の問題を心配する必要がありません。

5. コードは短くても構いません。

Steem ブロックチェーンはこれらの複雑さを自動的に処理しますが、開発者は実装によって無限ループやメモリ リークが発生したり、非決定的な動作が発生したりしないように注意する必要があります。幸いなことに、決定論的な動作が必要な場合、C++ での開発ははるかに簡単です。多くの一般的な JavaScript 言語機能を使用すると、隠れた非決定的な動作が発生します。

Liskサイドチェーン

Lisk のスマート コントラクトの概念の 1 つは、サイドチェーンの使用です。 Lisk スマート コントラクトは、検証ノードがコードを実行しないため、資金を保持できません。 Lisk は、コードを評価し、トランザクションを承認するためにサードパーティのマルチ署名ソリューションに依存しています。

STEEM と BitShares を使用すると、開発者は同様の方法でスマート コントラクトを実装できます。主な違いは、JavaScript の代わりに C++ が使用されることです。 Steem には、他のスマート コントラクト プラットフォームにはない 1 つの大きな利点があります。それは、無料トランザクションです。つまり、契約に必要な手数料を気にすることなく、誰でもサイドチェーンの「スマート コントラクト プラグイン」を実装できるということです。

イーサリアムはより進歩している

これまでもイーサリアムについて多くの疑問を提起してきましたが、Liskと比較するとイーサリアムは開発者の楽園と呼べるのではないかと思います。 Ethereum は、多くの経験豊富なブロックチェーン開発者がかつて悩まされていた多くの問題を開発者が解決するのに役立ちます。新しい言語の構文を習得することは、自ら足を撃たないようにするための無数の方法を学ぶことに比べれば、取るに足らないことです。 Ethereum アプリケーションは非決定論的な動作を生成しません。

前進する

ブロックチェーン技術は進歩し続けており、Liskチームはプラットフォームを前進させるために多額の資金を調達したばかりです。 Lisk が直面する問題のほとんどは、高度にカスタマイズされた JavaScript 環境で解決できます。

現在、Liskとその目標の間には大きなギャップがあります。私が提起した問題を解決できれば、彼らのプラットフォームはいつの日かイーサリアムに対抗できるものとなるかもしれません。 Lisk 初心者にとって、そのアーキテクチャは Ethereum よりもスケーラビリティに優れており、JavaScript を使用できることが大きな利点です。 Lisk を現在の状態から Ethereum の真の競合相手にまで発展させるには、おそらくグループが調達したすべての資金、さらにそれ以上の資金が必要になるでしょう。

結論は

Lisk を JavaScript 言語で動作するスマート コントラクト プラットフォームと考えるなら、STEEM は Lisk が現在備えている機能よりも多くの機能を備えた強力な競争相手であると考えるべきです。 Steem を汎用スマート コントラクト プラットフォームと見なさないのであれば、Ethereum が依然として唯一の選択肢であることは明らかです。