シリアル化は、情報をバイトにエンコードするプロセスです。 楽しかった！ しかし、ああ、ブロックチェーンに非常に役立ちます。 このブログ投稿のトピックは他のトピックよりも少し技術的ですが、その主要なコンポーネントを明確でわかりやすい方法で説明するように努めます。
このブログ投稿では、そもそもシリアル化が必要な理由と、これまでLiskプロジェクトでどのように実装されてきたかについて説明しています。 続いて、Liskコーデックの概要と、SDK開発者エクスペリエンスにもたらす改善点について説明します。 最後に、Liskネットワークをどのように強化するかと組み合わせて、いくつかの利点を紹介します。
用語解説
- メッセージ、オブジェクト：JavaScriptオブジェクトなどのデータ構造。 たとえば、Liskでは、メッセージはトランザクション、ブロック、またはアカウントを表すことができます。
- バイナリメッセージ：一連のバイト。 シリアル化メソッドは、バイナリメッセージを出力します。
- エンコード、シリアル化：メッセージをバイナリメッセージに変換します。
- デコード、逆シリアル化：バイナリメッセージをメッセージに変換します。
次の図の左側には、残高転送トランザクションに対応するメッセージが表示され、右側には、対応するバイナリメッセージが表示されます。 読みやすさを向上させるために、公開鍵と署名が短縮され、句読点がバイナリメッセージに追加されました。
シリアル化の目標と用途
Liskブロックチェーンは、トランザクション、ブロック、アカウントなどのいくつかのオブジェクトを使用します。 ほとんどの非ブロックチェーンプロジェクトでは、デバイスによってオブジェクトがバイトに変換される方法は実際には重要ではありません。 メッセージは、不要な問題を引き起こすことなく、表示、保存、コピー、および変更できます。
ただし、ブロックチェーンプロジェクトでは、同じオブジェクトが毎回、すべてのユーザーによって同じバイトシーケンスに変換されることが不可欠です。 そうしないと、署名やID（バイナリメッセージをハッシュすることによって取得される）などのプロパティが無効になるか、変更されます。 デバイスでトランザクションに署名し、この同じトランザクションが他の誰かによって異なる方法でシリアル化された場合、他の誰かがあなたの署名を拒否し、トランザクションが無効であると見なします。
この重要な特性に加えて、効率的なシリアル化方法は、エコシステムの他の部分に利益をもたらす可能性があります。 ブロックチェーンが直面している問題のXNUMXつは、ストレージとネットワークの要件の増大です。 この点で、送信、受信、および保存するバイト数が少なくなると、アプリケーション全体が軽量になり、同期が高速化されます。 これにより、小さなバイナリを生成するシリアル化方式を使用する利点が浮き彫りになります。
最後に、Liskの分散化を改善するには、Liskプロトコルをさまざまなプログラミング言語で実装できること、およびさまざまなチームがエコシステム用のツールの作成に取り組むことができることが重要です。 したがって、Liskプロトコルで使用されるシリアル化方法は、明確に定義され、実装に依存しない必要があります。
現在のソリューションの欠点
バージョン4.0.0まで、Liskツールキットには、上記のすべての要件を満たすシリアル化方法が含まれていませんでした。 バイナリメッセージは署名にのみ使用され、通信とストレージには使用されませんでした。そのため、シリアル化方法は速度とサイズが最適化されていませんでした。
現在のアーキテクチャのもうXNUMXつの問題点は、カスタムトランザクションのシリアル化です。 メインネットトランザクションをシリアル化するために、LiskはgetBytes関数を実装しました。 カスタムトランザクションの場合、アプリケーション開発者は、以下に示すXNUMXつのシリアル化の選択肢があるカスタムトランザクションアセットを指定する必要があります。
1.アセットをJSON文字列としてシリアル化します。
assetToBytes(asset) = Buffer.from(JSON.stringify(asset), 'utf-8');2.カスタムassetToBytes関数を記述します。
最初のオプションは高速ですが、サイズの点では効率的ではなく、さらにノードバージョンが異なれば実装もわずかに異なる可能性があります。 XNUMX番目のオプションは時間がかかり、エラーにつながる可能性があります。 さらに、カスタムassetToBytes関数がそのサイズとエンコード速度に関して効率的であるという保証はありません。
統一されたエコシステムでは、さまざまなプロジェクトで、オブジェクトの送信とシリアル化に同様のエンコーディングを使用する必要があります。 この負担が開発者の肩に残っている場合、エコシステムはあらゆる種類の非正統的なバイナリで満たされる可能性があります。 最悪のシナリオでは、これは危険な行動につながる可能性があり、場合によっては資金の損失につながる可能性があります。
Liskコーデック
これらの問題に対処するために、SDKのバージョン5.0.0で、LiskチームはLiskコーデックを導入しています。 Liskコーデックは、ユーザーがJavaScriptオブジェクトをエンコードおよびデコードできるようにする効率的で軽量なモジュールです。 コーデックを使用すると、アプリケーション開発者は各サイドチェーンオブジェクトにJSONスキーマを提供するだけで済みます。 次に、スキーマは、オブジェクトの検証、エンコード、およびデコードに使用されます。
LiskコーデックのもうXNUMXつの利点は、キー値ストアへのLisk遷移をサポートできることです。 バイナリシーケンスは直接保存でき、アプリケーションで使用する場合にのみデコードする必要があります。 バイナリメッセージを直接保存および送信することで、ネットワークをよりスムーズに実行し、不要なエンコードとデコードによる遅延を回避できます。 最後に、ノードは、要求されたキーに対応するバイト値を直接送信することにより、API要求に応答できます。
LiskコーデックはProtocolbuffers（protobuf）に基づいており、ブロックチェーンプロジェクトのニーズに合うように調整されています。 Protobufはよく知られているシリアル化メカニズムです。つまり、エンコードとデコードのLiskコーデックの動作は、ほとんどのprotobuf実装で再現できます。 ただし、protobufのシリアル化は必ずしも決定論的であるとは限らないため、このユースケースには直接適していません。
次の例は、Liskコーデックを使用して空のブロックをシリアル化する方法を示しています。
blockData = { "header": { "version": 3, "timestamp": 180, "height": 16, "previousBlockID": "e194ce4e908c148ea4d11719cd40a016d07f393d31031ea150d7a8b7904a22d5", "transactionRoot": , "generatorPublicKey": "ed3b9fd50b188d35f5d2ea3fef05cb894363931c5ba50a5967c224ae5b16b339", "reward": 100000000, "asset": { "maxHeightPreviouslyForged": 3, "maxHeightPrevoted": 10, "seedReveal": "8038ec83c421fa4844c5c65995cb2a66" }, "signature": "bfc186b17132180057c8604640c276b85169fcaba72255bdc24f9220e620aa3e9731e6308a131f87097979e5696a7c38a25212bcb4779b099fab7df576b50207" }, "payload": []
} blockMsg = { 0aac01: { 08: 03, 10: b401, 18: 10, 2220: e194ce4e908c148ea4d11719cd40a016d07f393d31031ea150d7a8b7904a22d5, 2a00: , 3220: ed3b9fd50b188d35f5d2ea3fef05cb894363931c5ba50a5967c224ae5b16b339, 38: 80c2d72f, 4216: { 08: 03, 10: 0a, 1a10: 8038ec83c421fa4844c5c65995cb2a66 }, 4a40: bfc186b17132180057c8604640c276b85169fcaba72255bdc24f9220e620aa3e9731e6308a131f87097979e5696a7c38a25212bcb4779b099fab7df576b50207 }
}トランザクションのシリアル化のその他の例については、 リップ 0028 とのブロックの例 リップ 0029.
開発者の経験
Liskコーデックを使用すると、カスタムアプリケーションの開発エクスペリエンスが向上します。
すべてのLiskトランザクションには、一連の共通のbaseTransactionプロパティ（手数料、ナンス、送信者公開鍵など）と、アセットで定義された一連のトランザクション固有のプロパティが含まれるようになりました。
カスタムトランザクションも同様に、アセットを指定するJSONスキーマによって定義されます。 このスキーマに関するシリアル化と検証はバックグラウンドで行われ、追加の開発者入力は必要ありません。 これにより、開発時間が節約され、エラーが発生するリスクが最小限に抑えられます。 SDKには、カスタムアセットスキーマの構文を検証するためのツールも含まれています。
以下の例は、残高移行トランザクションの資産スキーマを示しています。
balanceTransferAsset = { "type": "object", "properties": { "amount": { "dataType": "uint64", "fieldNumber": 1 }, "recipientAddress": { "dataType": "bytes", "fieldNumber": 2 }, "data": { "dataType": "string", "fieldNumber": 3 } }, "required": ["amount","recipientAddress","data"]
}または、自転車の返却とその新しい位置を通知するカスタムトランザクションを以下に表示します。
returnBikeAsset = { "type": "object", "properties": { "bikeID": { "dataType": "bytes", "fieldNumber": 1 }, "returnPosition": { "type": "object", "properties": { "longitude": {"dataType": "uint64","fieldNumber": 1}, "latitude": {"dataType": "uint64","fieldNumber": 2} }, "required": ["longitude","latitude"], "fieldNumber": 2 }, "bikeState": { "dataType": "string", "fieldNumber": 3 } }, "required": ["bikeID","returnPosition","bikeState"]
}Liskコーデックのパフォーマンス
Liskコーデックのパフォーマンスのベンチマークは、Liskコーデックで利用できます。 倉庫。 通常のトランザクションのエンコードとデコードは、200,000秒あたり50,000トランザクションの速度で実行できます。 フルブロックは、毎秒XNUMXブロックの速度でエンコードおよびデコードできます。
上記のように、Liskコーデックを使用することは、ノード間で通信し、ブロックチェーンを格納するためのサイズの点でも有益です。 現在、オブジェクトはJSON形式で保存および交換されています。 通常のバランス転送（データフィールドなし、マルチシグニチャなし）は約500バイトです。 Liskコーデックでエンコードされた場合、同じオブジェクトは150バイトになります。 これは70％の削減です！ 他のオブジェクトでも同様のサイズの縮小が見られます。これはLiskネットワークにとって素晴らしいニュースであり、将来の拡張に役立ちます。
まとめ
ここで要約すると、Liskコーデックを導入すると、エンドユーザーはLiskアプリケーション全体を合理化し、ネットワーク通信を減らし、ブロックチェーンのグローバルサイズを小さくすることができます。 Liskコーデックの正確な仕様は次の場所にあります。 リップ 0027、トランザクション、ブロック、およびアカウントに使用されるスキーマは、 リップ 0028, リップ 0029, リップ 0030それぞれ。
このトピックに関するその他の質問やコメントについては、AMAをホストします。 リスクチャット Maxime Gagnebin（研究科学者）と今週の金曜日、21月4日午後XNUMX時CEST。 また、すべてのコミュニティメンバーに LiskResearchフォーラム 皆様からのフィードバックをお待ちしており、このトピックやその他のトピックに関するディスカッションに参加できます。
タグ
無料のアカウントを作成して、カスタムの読書体験のロックを解除します。
コインスマート。 BesteBitcoin-ヨーロッパのBörse
ソース：https：//hackernoon.com/what-is-the-lisk-codec-and-how-well-does-it-perform-8ft3275？source = rss
