Author: francescov

Lisk ResearchおよびLIPに関するシリーズは、Lisk Magazineで継続されています。今日は、現在のプロトコルのトランザクションオブジェクトの不要なプロパティの削除を推奨するLIP-12を扱います。 LIP-12はOliver Beddowsの寄稿により、Andreas Kendziorraによって原案がまとめられました。開発者は、トランザクションのサイズとプロトコルの複雑さを増加させるメリットのないトランザクションオブジェクトの冗長なプロパティに気付き、それを削除することを提案しています。 Andreasは、現在のプロトコルでは、必要でも使用中でもないトランザクションオブジェクトでプロパティと値のペアを使用することが可能であると説明しました。これらのプロパティと値のペアは、トランザクションの通信に使用されるJSONオブジェクトと、トランザクションシグネチャおよびtransactionID生成の入力メッセージの両方で使用されます。その結果、ペアはノード間で送信されるデータを増やし、トランザクション処理を遅くします。開発者が説明しているように、たとえ効果が最小であっても、プロトコルを読み取るときに混雑が生じ、その実装が不必要に大きくなる場合があります。これらの理由から、トランザクションオブジェクトのプロパティと値のペアを削除することを提案しています。 プロパティはすべて同じように冗長ではありません。たとえば、amountとrecipientIdプロパティはbalance transferトランザクションにのみ必要であり、他のタイプのトランザクションには必要ありません。別の例を挙げると、requesterPublicKeyプロパティは従来のプロパティであり、どのタイプのトランザクションにも必要なくなりました。 特に、送信時のトランザクションJSONオブジェクトでは、これらのプロパティが許可されます：amount、asset、fee、id(オプション)、recipientId、recipientPublicKey(オプション)、requesterPublicKey(オプション)、senderId(オプション)、senderPublicKey、signature、signatures(オプション), signSignature(オプション), timestamp, type。 冗長として識別されるプロパティは、amount、fee、id、recipientId、recipientPublicKey、requesterPublicKey、そしてsenderIdです。残りは基本的なものなので、開発者はそれらを削除しないことを提案します。 Andreasは、冗長なプロパティをより詳細に分析しました。 AmountおよびrecipientId：この2つのプロパティはすべてのトランザクションオブジェクトに必要ですが、 balance transferトランザクションにのみ関連します。そのため、開発者はそれらをトランザクションオブジェクトからbalance transferトランザクションのassetプロパティに移動することを提案します。 Fee：固定料金システムにより、トランザクションの料金は常にトランザクションタイプから差し引かれます。そのため、この必要はありません。 Id：トランザクションのIDは他のプロパティから常に判断できます。さらに、トランザクションを受信するノードはすべてのプロパティを検証する必要があるため、トランザクションを送信するときにIDを提供することに利点はありません。そのため、開発者はトランザクションJSONオブジェクトからidプロパティを削除することを提案します。 RecipientPublicKey：balance transferの受信者は常にそのアドレスによって決定される必要があり、他のすべてのトランザクションタイプには受信者がいません。そのため、開発者はこのプロパティは必要ないため、削除することをお勧めします。 RequesterPublicKey：最初、このプロパティは、非アカウント所有者によるマルチシグネチャトランザクションの要求に使用するように設計されていました。ただし、この機能は現在有効になっていないため、開発者は削除することをお勧めします。 SenderId：senderPublicKeyはすべてのトランザクションオブジェクトに必要なプロパティであり、アドレス/ IDは常に公開キーから計算できるため、senderIdプロパティは必要ありません。 トピックについて詳しく知りたい場合は、GitHubのLIPページで各LIPの説明を読むことができます。 _________________________________ Lisk MagazineはLisk Italian GroupとEliteXによってサポートされているプロジェクトです。 私達の仕事をサポートし、Lisk Magazineに投票してください。...

ここにLisk Reserchについての別の記事があります。今回は、異なるチェーンでのトランザクションリプレイを減少させることを目的としたLIP-9を取り上げたいと思います。 LIP-9は、Oliver Beddows、Andreas KendziorraそしてJan Hackfeldと共に、Manu Nelamane SiddalingegowdaとIker Alustizaによって共同でまとめられました。この提案には、異なるチェーンでのトランザクションリプレイを減少させるためにトランザクション署名の系統的コンポーネントとして実装されているネットワークIDの導入が含まれています。 現在のシステムの問題は、この問題(issue)でも報告されているようにトランザクションを他のチェーンでも再現できることです。例えばTestnetへ送信されたトランザクションをMainnetで再現することができます。さらにシステムにサイドチェーンが導入されることで問題は強調されます。 現在、この問題は2つの方法で解決されています。1) ユーザーが異なるブロックチェーンに同じパスフレーズを設定することを思いとどまらせる。 2) 1の解決策が適応できない場合に備えて異なるブロックチェーンに異なる2つ目のパスフレーズを登録することを提案する。ただし、この方法は宣伝されているLiskプラットフォームの長所の一つであるメインチェーンやサイドチェーンを含む複数のブロックチェーンでパスフレーズを再利用できる可能性とは対照的です。 上記の理由により、開発者はネットワークIDをトランザクション署名の統合コンポーネントとして提案します。具体的には、ネットワークIDはブロックチェーンのnethashに連結するhash、コミュニティID、およびコミュニティIDに関連するバージョンの3つのコンポーネントで構成されます。この3つの要素の組み合わせは、排他的であり、信頼できる人物にとって必須の要件でなくてはなりません。このようにして、既存のブロックチェーンからLiskメインネットまたはテストネットへのトランザクションリプレイアタックが回避され、署名は特定のネットワークで有効になります。 更にサイドチェーンを実装したエコシステムでは、各サイドチェーンに一意のネットワークIDが割り当てられ、異なるチェーン間でのトランザクションリプレイが削減されます。ただし、悪意のあるサイドチェーン開発者は、メインネットまたは別のサイドチェーンから一意のIDをコピーし、元のチェーン上の独自のサイドチェーンからトランザクションを複製する可能性があります。このため、サイドチェーンユーザーはトランザクションオブジェクトの署名とネットワークIDを確認する必要があります。 このことから、サイドチェーンの開発者が悪意のある署名機能を提供する可能性を避けるために、サイドチェーンに関して、開発者はLisk Elementsに実装された機能を使用する必要があることを推奨しています。 トピックについて詳しく知りたい場合は、Githubのページで各LIPの説明を読むことができます。 _________________________________ Lisk MagazineはLisk Italian GroupとEliteXによってサポートされているプロジェクトです。 私達の仕事をサポートし、Lisk Magazineに投票してください。 この記事はLisk Japanによって翻訳されました。

Continuing the overview of the Lisk Improvement Proposals, today we briefly introduce LIP 7 and 8. The former proposes a new versioning system for Lisk Core while the latter is aimed at the removal...