Author: francescov

Lisk Research – LIP-12の概要

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 Research – LIP-11の概要

ここに、Lisk Researchに関する別のLIPの新しい記事があります。今回は、LIP-5で説明されているデータベースコンポーネントにExtended Data Mapper(拡張データマッパー)パターンを使用することを提案するLIP-11を扱います。 LIP-11の作成者は、Oliver BeddowsとAndreas Kendziorraのサポートを受けたNazar Hussainです。彼らは、Lisk Coreの永続化レイヤーを拡張および維持するのに役立つ、普遍的で理解しやすい構造化モデルを提案します。 開発者は、現在のLisk Coreモデルでは、データの永続性を担うロジックがコードのさまざまな部分に不規則に広まっていると説明しました。そのような配布は、同等の機能のための余分なインターフェイスが存在することを意味し、これによりコードを長期にわたって維持および拡張することが困難になります。さらに、これらすべてのインターフェース間で統一された設計はないため、どのモジュールでどのインターフェースを使用するかを決定することは困難です。 現在のLisk Core実装のロジック分布を上の図に示します。重複のために、適切なインターフェイスを選択する際の前述の困難に気付くことができます。また、この写真は、たとえば、データベースからアカウントを取得するために使用可能ないくつかのインターフェースがあることも示しています。さらに、インターフェースは現在、Lisk Coreで使用されているデータベースソリューションであるPostgreSQL RDBMSと強力にリンクされています。 LIP-5(この記事で説明)は、永続レイヤーからデータを取得する目的で、すべてのモジュール間でインターフェイスを共有することを意味します。これは、どのネームスペースをモジュール間で共有するかを決定することが難しい複雑な状況に移行します。開発者によって提案されたモデルは、LIP-5の要件を満たす永続ロジックの明確な抽象化レイヤーによってこの問題に直面しています。 新しい設計パターンは、次のように特徴付けられる必要があります。 システムを介したデータベース同等のコードエンティティのマップ。 新しい特殊なエンティティを作成するために、エンティティを広げる簡単な方法を提供します。 複数のデータベーステーブルにわたるエンティティ属性のマッピングをサポートします。 インターフェイスおよび外部モジュールの公開された読み取り専用インスタンスへのアクセス制限を許可することにより、データアクセスレイヤーを保護します。 他のモジュールがモジュール固有のエンティティにアクセスできないように、エンティティの実装を分離します。 開発者は、前述のニーズを満たすことができるソフトウェア業界で使用される3つの設計パターンを提案します。 アクティブレコード:中規模のプロジェクトに適していますが、数百万のデータオブジェクトがあるLiskの場合には適していません。さらに、このパターンは、複数のデータベーステーブル間でエンティティ属性をマッピングする要件を満たしていないため、実装できません。 データマッパー:パフォーマンスを向上させるためにネイティブJSONオブジェクトに基づいており、JSONからデータベースへの双方向のシリアル化をサポートしています。また、複数のデータベーステーブルにまたがるエンティティ属性のマッピングもサポートしていますが、すべてのエンティティにCRUDインターフェイスのみを持つように制限されています。 リポジトリ:その柔軟性により、さまざまな方法で実装できます。ただし、標準やガイドラインがないため、インターフェイスや動作全体に一貫性を実装するために使用することはできません。 結論として、開発者によって提案されたソリューションは、標準のCRUD操作と柔軟なインターフェイスの両方をサポートするために、データマッパーパターンとリポジトリパターンの結合にあります。新しいパターンには「Extended Data Mapper(拡張データマッパー)」という名前が付けられ、そのアーキテクチャを説明する図を以下に示します。 トピックについて詳しく知りたい場合は、GitHubのLIPページで各LIPの説明を読むことができます。 _________________________________ Lisk MagazineはLisk Italian...

Lisk Research – LIP-10の簡単な概要

Lisk Magazineは引き続きLisk ResearchおよびLIPsの普及に取り組みます。この記事では、Liskブロックチェーンのセキュリティを強化するために、ブロックの新しいタイプのブロックIDを提案するLIP-10の概要を簡単に紹介します。 LIP-10はAndreas Kendziorraによって作成され(Oliver Beddowsのサポートのもと)、セキュリティを向上させるために、ブロックヘッダーのSHA3-256ハッシュをブロックIDとして使用することを推奨しています。 開発者は、現在、Liskプロトコルでは、ブロックIDはブロックヘッダーのSHA-256ダイジェストの8バイトで構成されていると説明しました。この長さはサイズが小さくいくつかの利点(保存データが少なく、小さなディスプレイでの視覚化に優れている)がありますが、攻撃に対する耐性が低いなどの欠点もあります。たとえば、攻撃者はブロックチェーン内の特定のブロックに対して同じブロックIDを持つ別のブロックを発見する可能性があります。この場合、攻撃されたチェーンは他のコミュニテメンバーには変更がされていないように見える場合があります。ただし、開発者は、このタイプの攻撃はDeelegateに限定されており、現時点では経済的な理由からメリットはないとされています。とにかく、彼らはこのタイプのアタッチを将来防ぐためにブロックIDの長さを増やすことを提案しています。 2つのプロトコルをさらに詳しく比較してみましょう。現在のプロトコルでは、データブロックはSHA-256の入力テキストとして使用され、出力の最初の8バイトが反転されてブロックIDとして使用されます。提案されたプロトコルでは、署名ブロックのヘッダーデータブロックが仕様に従って生成されます(現在のプロトコルと同じ)。次に、データブロックはSHA3​​-256の入力として使用され、その出力は256ビットのブロックIDになります。 ブロックIDの長さに関しては、256ビットを推奨します。これは推奨を超えても高いセキュリティレベルを保証するためです。実際に彼らは、NISTが2030年以降も稼働する予定のアプリケーションの最低限のセキュリティレベルとして128ビットを提案していることを説明しました(この出版物を参照)。推奨される長さにより、ブロックチェーンのサイズが最大50 Mb(ブロックIDが文字配列に16進表記で書き込まれている場合は最大100 Mb)増加します。これは、チェーンの合計サイズと比較して無視できる値です。さらに、ブロックIDはユーザーによって管理されることはまれなので、追加の長さはユーザーに大きな不利益をもたらしません。 開発者は、SHA-3ハッシュ関数、特にKECCAK関数を選択したことも説明しました。セキュリティ、パフォーマンス、柔軟性の面で、NIST hash function competitionの勝者に選ばれたからです。代替機能の中で、現在のSHA-256とBLAKE2を示しています。ただし、SHA-256はその構造(前述)のために弱点があり、後者はSHA-3レビュープロセス全体を行っていないため、彼らはKECCAKを好みます。 トピックについて詳しく知りたい場合は、GitHubの特定のページで各LIPの完全な説明を読むことができます。 _________________________________ Lisk MagazineはLisk Italian GroupとEliteXによってサポートされているプロジェクトです。 私達の仕事をサポートし、Lisk Magazineに投票してください。 この記事はLisk Japanによって翻訳されました。

Lisk Directory BlockchainはPoC Lisk Sidechainへ

Moostyグループは最新の作成物であるLisk Directory Blockchainのホワイトペーパーを公開しました。この記事では、プロジェクトの概要と、その目的と構造について説明します。 Lisk Directory Blockchainは、Lisk SDKを使用して構築されたProof of Concept Sidechainであり、Delegateのスキルと動機を簡単に確認できるようにすることを目的としており、新しいチェーンのDelegateを選択することや、特定のネットワークのDelegateに投票するシステムを提供します。これは、透明性の促進とスキルを証明するために、Proof of Motivationプロトコルに基づいています。 Lisk Directory Blockchainは、Lisk SDKのリリース後に発生した新しい課題の1つ(この記事で説明されています)と結果として生じるサイドチェーン、つまり新しいネットワークの信頼性とセキュリティを満たすよう設計されています。この新しいツールを使用すると、Delegate候補者はブロックチェーン上に共有したい情報を登録できます。一方のコミュニティメンバーは、利用可能なDelegateをナビゲートしたり、選択することができます。 Moostyグループは、Delegateが将来のビジョンに沿っているかどうかを判断する分散型および信頼できるシステムを持っていないなど、コミュニティメンバーやサイドチェーン開発者に影響を与えるいくつかの問題を強調しました。問題点を簡単に要約すると次の通りです。1) Delegateの選択基準の欠如。 2) スタートアップや目標を支援するためのDelegateの意欲に関する情報の欠如。 3) 新しいブロックチェーン/コミュニティで適切なスキルを持つ人々を引き付けるシステムの欠如。 4) サイドチェーン上のDelegateが別のチェーン上のDelegateに関係しているかどうかを確認するための、透明かつ信頼できる方法の欠如。 Lisk Directoryは上記のすべての問題に対するソリューションであり、Delegateに関する情報を取得するための「マーケットプレイス」を提供します。これは次の4つのカテゴリの情報に基づいています。1) 情報のアクセシビリティの委任。 2) 知識とスキルのレベル。 3) 動機。 4) 一般的なコミュニティの知識。 暗号化されたメッセージを使用して検証できるこのタイプの情報は、Delegateの宣伝。スキルと知識の開示。およびプロジェクトの立ち上げを支援するための意欲に関する情報を提供するのに役立ちます。透明性は誰もが特定の情報の有効性を検証できるという事実によって保証されます。 より技術的な側面として、Lisk...

Lisk Reserch – LIP-9 の概要

ここに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によって翻訳されました。

Lisk Development Update June 2019

The Lisk Team has recently published a blog post with the June Development Updates. As usual, here it is our quick recap of the latest news, which in particular concern: SDK, UI and Lisk...