الأوراق البيضاء مقالات الأشكال مسرد المصطلحات رسم بياني بحث

Optimism 技術文書

بقلم Optimism Collective · 2021

وضع فردي community.optimism.io

لا تمتلك Optimism ورقةً بيضاءَ تقليديةً. بوصفها rollup تفاؤلياً من الطبقة الثانية لـ Ethereum، يُوثَّق تصميمها ومواصفاتها من خلال الوثائق التقنية ومواصفات OP Stack ومنشورات البحث، بدلاً من ورقة أكاديمية رسمية واحدة.

🇺🇸 English (النص الأصلي)
🇯🇵 日本語 (الترجمة)

خلاصة

تتناول هذه الورقة مشكلة قابلية التوسع في blockchains اللامركزية من خلال تحليل المفاضلة بين إنتاجية المعاملات ومتطلبات الأجهزة لتشغيل العقدة. يتم تقديم عمليات التجميع، أي تقنيات التحقق من الكتل المنفذة خارج السلسلة على السلسلة، في شكل أدلة خطأ أو صحة. نحن نقارن بين مجموعات متفائلة ومجموعات صلاحية فيما يتعلق بوقت السحب، وتكاليف المعاملات، وتقنيات التحسين، والتوافق مع النظام البيئي Ethereum. يكشف تحليلنا أن Optimism Bedrock لديه حاليًا معدل ضغط غاز يبلغ حوالي 20:1، بينما يحقق StarkNet معدل ضغط تكلفة كتابة تخزين يبلغ حوالي 24:1. نناقش أيضًا تقنيات تحسين هذه الأسعار بشكل أكبر، مثل استخدام عقود التخزين المؤقت ومرشحات Bloom. في نهاية المطاف، تسلط استنتاجاتنا الضوء على المفاضلات بين التعقيد وخفة الحركة في الاختيار بين مجموعة التفاؤل والصلاحية. الكلمات الرئيسية Blockchain، قابلية التوسع، التجميعية 1. مقدمة اكتسبت تقنية Blockchain اهتمامًا كبيرًا نظرًا لقدرتها على إحداث ثورة في مختلف الصناعات. ومع ذلك، لا تزال قابلية التوسع تمثل تحديًا كبيرًا، حيث تواجه معظم blockchain مقايضة بين قابلية التوسع واللامركزية والأمن، والتي يشار إليها عادةً باسم ثلاثية قابلية التوسع [1، 2]. لزيادة إنتاجية blockchain، الحل البسيط هو زيادة حجم الكتلة الخاصة بها. في سياق Ethereum، هذا يعني زيادة الحد الأقصى لكمية الغاز التي يمكن أن تحتويها الكتلة. نظرًا لأن كل عقدة كاملة يجب أن تتحقق من صحة كل معاملة لكل كتلة، ومع زيادة الإنتاجية، تزداد أيضًا متطلبات الأجهزة، مما يؤدي إلى مركزية أكبر للشبكة. تعمل بعض blockchain، مثل Bitcoin وEthereum، على تحسين تصميمها لتحقيق أقصى قدر من اللامركزية المعمارية، في حين تم تصميم البعض الآخر، مثل Binance Smart Chain وSolana، لتكون سريعة ورخيصة قدر الإمكان. تعمل الشبكات اللامركزية على الحد بشكل مصطنع من إنتاجية blockchain لتقليل متطلبات الأجهزة للمشاركة في الشبكة. على مر السنين، جرت محاولات لإيجاد حل للثلاثية، مثل القنوات الحكومية [3] والبلازما [4، 5]. تتميز هذه الحلول بخاصية نقل بعض الأنشطة خارج السلسلة، وربط النشاط الموجود على السلسلة بالنشاط خارج السلسلة باستخدام smart contracts، والتحقق من DLT 2023: ورشة العمل الخامسة لتكنولوجيا دفتر الأستاذ الموزع، 25-26 مايو 2023، بولونيا، إيطاليا $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 حقوق الطبع والنشر لهذه الورقة من قبل مؤلفيها. الاستخدام مسموح به بموجب ترخيص Creative Commons Attribution 4.0 International (CC BY 4.0). إجراءات ورشة عمل CEUR http://ceur-ws.org ISSN 1613-0073 إجراءات ورشة عمل CEUR (CEUR-WS.org) على السلسلة ما يحدث خارج السلسلة. ومع ذلك، فإن قنوات البلازما والقنوات الحكومية محدودة في دعمها للقنوات العامة smart contract. المجموعات المجمعة هي blockchains (تسمى Layer 2 أو L2) تنشر كتلها على blockchain أخرى (Layer 1 أو L1) وبالتالي ترث خصائص الإجماع وتوافر البيانات والأمان. وهي، على عكس الحلول الأخرى، تدعم الحساب التعسفي. تحتوي المجموعات المجمعة على ثلاثة مكونات رئيسية: • أجهزة التسلسل: العقد التي تتلقى معاملات التجميع من المستخدمين ودمجها في كتلة يتم إرسالها إلى Layer 1. تتكون الكتلة على الأقل من جذر الحالة (على سبيل المثال، جذر Merkle) والبيانات اللازمة لإعادة بناء الحالة والتحقق من صحتها. يحدد Layer 1...

概要

この論文では、トランザクション スループットとノードを実行するためのハードウェア要件との間のトレードオフを分析することで、分散型 blockchain のスケーラビリティの問題に対処しています。ロールアップ、つまりオフチェーンで実行されるブロックをオンチェーンで検証するテクノロジーは、障害証明または有効性証明の形式で提供されます。出金時間、取引コスト、最適化手法、Ethereum エコシステムとの互換性に関して、オプティミスティック ロールアップと有効性ロールアップを比較します。私たちの分析により、Optimism Bedrock の現在のガス圧縮率は約 20:1 であるのに対し、StarkNet は約 24:1 のストレージ書き込みコスト圧縮率を達成していることがわかりました。また、キャッシュ コントラクトやブルーム フィルターの使用など、これらのレートをさらに最適化する手法についても説明します。最終的に、私たちの結論は、楽観的ロールアップと妥当性ロールアップの選択における複雑さと機敏性の間のトレードオフを浮き彫りにします。キーワード ブロックチェーン、スケーラビリティ、ロールアップ 1. はじめに ブロックチェーン技術は、さまざまな業界に革命を起こす可能性があるため、大きな注目を集めています。ただし、ほとんどの blockchain は、一般にスケーラビリティのトリレンマと呼ばれる、スケーラビリティ、分散化、セキュリティの間のトレードオフに直面しているため、スケーラビリティは依然として大きな課題です。 blockchain のスループットを向上させる簡単な解決策は、ブロック サイズを増やすことです。 Ethereum のコンテキストでは、これはブロックが保持できるガスの最大量を増やすことを意味します。各フルノードはすべてのブロックのすべてのトランザクションを検証する必要があるため、スループットが増加するにつれてハードウェア要件も増加し、ネットワークの集中化が進みます。 Bitcoin や Ethereum などの一部の blockchain は、アーキテクチャの分散化を最大化するために設計を最適化しますが、Binance Smart Chain や Solana などの他のものは、可能な限り高速かつ安価になるように設計されています。分散型ネットワークは、blockchain のスループットを人為的に制限して、ネットワークに参加するためのハードウェア要件を下げます。長年にわたり、状態チャネル [3] やプラズマ [4、5] など、トリレンマの解決策を見つける試みが行われてきました。これらのソリューションには、一部のアクティビティをオフチェーンに移動し、smart contracts を使用してオンチェーンのアクティビティをオフチェーンのアクティビティにリンクし、DLT 2023 を検証するという特徴があります: 第 5 回分散台帳技術ワークショップ、2023 年 5 月 25 ～ 26 日、イタリア、ボローニャ $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 この論文の著作権は著者にあります。クリエイティブ コモンズ ライセンス表示 4.0 インターナショナル (CC BY 4.0) に基づいて使用が許可されています。 CEUR ワークショップ議事録 http://ceur-ws.org ISSN 1613-0073 CEUR ワークショップ議事録 (CEUR-WS.org) オンチェーンとオフチェーンで何が起こっているか。ただし、プラズマ チャネルと状態チャネルの両方は、一般的な smart contract のサポートに制限があります。ロールアップは、ブロックを別の blockchain (Layer 1 または L1) に公開する blockchain (Layer 2 または L2 と呼ばれます) であり、そのため、そのコンセンサス、データの可用性、およびセキュリティのプロパティを継承します。他のソリューションとは異なり、これらは任意の計算をサポートします。ロールアップには 3 つの主なコンポーネントがあります。 • シーケンサー: ユーザーからロールアップ トランザクションを受け取り、それらを Layer 1 に送信されるブロックに結合するノード。ブロックは、少なくとも状態ルート (マークル ルートなど) と、状態を再構築して検証するために必要なデータで構成されます。 Layer 1 は...を定義します。

مقدمة

  1. مقدمة لقد اكتسبت تقنية Blockchain اهتمامًا كبيرًا نظرًا لقدرتها على إحداث ثورة الصناعات المختلفة. ومع ذلك، تظل قابلية التوسع تحديًا كبيرًا، كما يواجه معظم blockchains وهي مقايضة بين قابلية التوسع واللامركزية والأمن، والتي يشار إليها عادة باسم معضلة قابلية التوسع [1، 2]. لزيادة إنتاجية blockchain، الحل التافه هو لزيادة حجم الكتلة الخاصة به. في سياق Ethereum، هذا يعني زيادة الحد الأقصى كمية الغاز التي يمكن أن تحتويها الكتلة. حيث يجب على كل عقدة كاملة التحقق من صحة كل معاملة لكل عقدة كتلة، مع زيادة الإنتاجية، تزداد أيضًا متطلبات الأجهزة، مما يؤدي إلى زيادة مركزية الشبكة. تعمل بعض blockchains، مثل Bitcoin وEthereum على تحسين التصميم لتحقيق أقصى قدر من اللامركزية المعمارية، في حين أن البعض الآخر، مثل Binance Smart تم تصميم Chain وSolana ليكونا سريعين ورخيصين قدر الإمكان. الشبكات اللامركزية الحد بشكل مصطنع من إنتاجية blockchain لخفض متطلبات الأجهزة المشاركة في الشبكة. على مر السنين، جرت محاولات لإيجاد حل للثلاثية، مثل الدولة القنوات [3] والبلازما [4، 5]. وتتميز هذه الحلول بخاصية تحريك بعض النشاط خارج السلسلة، وربط النشاط الموجود على السلسلة بالنشاط خارج السلسلة باستخدام smart contracts، والتحقق DLT 2023: ورشة العمل الخامسة لتكنولوجيا دفتر الأستاذ الموزع، 25-26 مايو 2023، بولونيا، إيطاليا $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (ل. دونو) 0000-0001-9221-3529 (ل. دونو) © 2023 حقوق الطبع والنشر لهذه الورقة من قبل مؤلفيها. الاستخدام مسموح به بموجب ترخيص Creative Commons Attribution 4.0 International (CC BY 4.0). CEUR ورشة عمل الإجراءات http://ceur-ws.org ISSN 1613-0073 وقائع ورشة عمل CEUR (CEUR-WS.org)على السلسلة ما يحدث خارج السلسلة. ومع ذلك، فإن قنوات البلازما وقنوات الدولة محدودة دعمهم لـ smart contracts العامة. المجموعات المجمعة هي blockchains (تسمى Layer 2 أو L2) تنشر كتلها على blockchain آخر (Layer 1 أو L1) وبالتالي ترث خصائص الإجماع وتوافر البيانات والأمان الخاصة بها. هم، على عكس الحلول الأخرى، دعم الحساب التعسفي. تحتوي المجموعات المجمعة على ثلاثة مكونات رئيسية: • التسلسل: العقد التي تتلقى المعاملات المجمعة من المستخدمين ودمجها في ملف الكتلة التي يتم إرسالها إلى Layer 1. تتكون الكتلة من جذر الحالة على الأقل (على سبيل المثال Merkle root) والبيانات اللازمة لإعادة بناء الحالة والتحقق من صحتها. يحدد Layer 1 الكنسي blockchain للL2 من خلال تحديد ترتيب البيانات المنشورة. • العقد المجمعة الكاملة: العقد التي تحصل على الكتل المجمعة وتعالجها وتتحقق من صحتها من الطبقة 1 عن طريق التحقق من صحة الجذر. إذا كانت الكتلة تحتوي على معاملات غير صالحة، فهذا هو الحال تم تجاهلها، مما يمنع أجهزة التسلسل من إنشاء كتل صالحة تتضمن غير صالحة المعاملات. • العقد الخفيفة التراكمية: العقد التي تحصل على الكتل التراكمية من Layer 1 ولكنها لا تقوم بالحساب الدولة الجديدة نفسها. يتحققون من أن جذر الحالة الجديد صالح باستخدام التقنيات مثل إثبات الخطأ أو الصحة. تحقق المجموعات المجمعة قابلية التوسع من خلال تقليل التكلفة المطفأة للمعاملات كعدد من المستخدمين يزيد. وذلك لأن تكلفة ضمان صلاحية blockchain تنمو بشكل خطي فرعي فيما يتعلق بتكلفة التحقق من المعاملات بشكل فردي. تختلف المجموعات حسب الآلية التي يتم من خلالها التأكد من صحة تنفيذ المعاملة في العقد الخفيفة: في يتم ضمان التراكمات المتفائلة من خلال النموذج الاقتصادي وإثباتات الخطأ، أثناء الصلاحية يتم ضمان المجموعات المجمعة بشكل مشفر باستخدام أدلة الصلاحية. يمكن تنفيذ العقد الخفيفة كـ smart contracts على Layer 1. يقبلون جذر حالة جديدة والتحقق من الصلاحية أو إثبات الأخطاء: لذلك تسمى هذه التحديثات بالعقد الذكي مجموعات. إذا كانت العقد الضوئية مستقلة، فإنها تسمى مجموعة Sovereign Rollups [6]. ميزة إن استخدام مجموعة العقود الذكية هو القدرة على بناء جسر ثقة بين الاثنين blockchains: بما أنه تم إثبات صحة حالة L2 إلى L1، فإن نظام المعاملات من يمكن تنفيذ L2 إلى L1، مما يسمح بالسحب. العيب هو أن تكلفة تعتمد المعاملات على تكلفة التحقق من الحالة على L1: إذا كانت الطبقة الأساسية مشبعة والأنشطة الأخرى، فإن تكلفة المعاملات في مجموعة التحديثات تزيد أيضًا. طبقات البيانات والإجماع هي التي تحدد أمان النظام فهي تحدد ترتيب المعاملات، وتمنع الهجمات، وتتيح البيانات لإثبات الحالة صلاحية. المساهمة الورقية في هذا البحث، قمنا بدراسة مجموعتي التفاؤل والصدق، وهما مبتكران حلول ثلاثية قابلية التوسع، مع التركيز على التطبيقات البارزة، مثل Optimism Bedrock وStarkNet. تتضمن مساهماتنا مقارنة شاملة لهذه الحلول وتحليل أوقات السحب ومناقشة الهجوم المحتمل على Optimism حجر الأساس. بالإضافة إلى ذلك، نقوم بحساب نسب ضغط الغاز الخاصة بها، وتوفير تحسينات خاصة بالتطبيقات، وتقديم مزايا وعيوب الابتعاد عن Ethereum الجهاز الظاهري (EVM).

هيكل الورق يتم تنظيم الورقة على النحو التالي. في القسم 2 التراكمية المتفائلة هي تم تقديمه من خلال تحليل Optimism حجر الأساس. في القسم 3، يتم تقديم مجموعات الصلاحية بواسطة تحليل StarkNet. في القسم 4 نقارن بين الحلين. وأخيرا، في القسم 5 نرسم بعض الاستنتاجات.

導入

  1. はじめに ブロックチェーン技術は革命を起こす可能性があるため大きな注目を集めています さまざまな業界。ただし、ほとんどの blockchain が直面しているように、スケーラビリティは依然として大きな課題です。 スケーラビリティ、分散化、セキュリティの間のトレードオフ。一般に スケーラビリティのトリレンマ [1、2]。 blockchain のスループットを向上させるための簡単な解決策は次のとおりです。 ブロックサイズを大きくします。 Ethereum のコンテキストでは、これは最大値を増やすことを意味します。 ブロックが保持できるガスの量。各フルノードはすべてのトランザクションを検証する必要があるため、 ブロックのスループットが増加すると、ハードウェア要件も増加し、 ネットワークの一元化。 Bitcoin や Ethereum などの一部の blockchain は、 アーキテクチャの分散化を最大限に高めるように設計されている一方で、Binance Smart などの他の製品は Chain と Solana は、できるだけ速く、そして安価になるように設計されています。分散型ネットワーク blockchain のスループットを人為的に制限して、ハードウェア要件を下げる ネットワークに参加します。 長年にわたり、トリレンマの解決策を見つける試みがなされてきました。 チャネル [3] およびプラズマ [4、5]。これらのソリューションには、何らかのアクティビティを移動するという特徴があります。 オフチェーン、smart contracts を使用してオンチェーン アクティビティをオフチェーン アクティビティにリンクし、検証する DLT 2023: 第 5 回分散台帳テクノロジー ワークショップ、2023 年 5 月 25 ～ 26 日、イタリア、ボローニャ $ [email protected] (L. ドノ) https://lucadonnoh.github.io/ (L. ドノ) 0000-0001-9221-3529 (L. ドンノ) © 2023 この論文の著作権は著者にあります。クリエイティブ コモンズ ライセンス表示 4.0 インターナショナル (CC BY 4.0) に基づいて使用が許可されています。 クール ワークショップ 議事録 http://ceur-ws.org ISSN 1613-0073 CEUR ワークショップ議事録 (CEUR-WS.org)オフチェーンで起こっていることをオンチェーンで。ただし、プラズマ チャネルと状態チャネルの両方が制限されています。 一般的な smart contract のサポート。 ロールアップは、別の blockchain でブロックを公開する blockchain (Layer 2 または L2 と呼ばれます) です。 (Layer 1 または L1) なので、そのコンセンサス、データの可用性、およびセキュリティのプロパティを継承します。彼らは、 他のソリューションとは異なり、任意の計算をサポートします。ロールアップには 3 つの主要なコンポーネントがあります。 • シーケンサー: ユーザーからロールアップ トランザクションを受け取り、それらを結合してトランザクションを作成するノード。 Layer 1 に送信されるブロック。ブロックは少なくとも状態ルート (マークルなど) で構成されます。 root) と、状態を再構築して検証するために必要なデータ。 Layer 1 は、 公開されたデータの順序を確立することにより、L2 の正規 blockchain を取得します。 • ロールアップフルノード: レイヤーからロールアップブロックを取得、処理、検証するノード 1 ルートが正しいことを確認します。ブロックに無効なトランザクションが含まれている場合、 破棄され、シーケンサーが無効なブロックを含む有効なブロックを作成できなくなります。 取引。 • ロールアップ ライト ノード: Layer 1 からロールアップ ブロックを取得しますが、計算は行わないノード 新しい状態そのもの。彼らは、新しい状態のルートが有効であることを技術を使用して検証します。 欠陥証明や有効性証明など。 ロールアップは、トランザクションの償却コストを数値として削減することでスケーラビリティを実現します。 ユーザー数が増加します。これは、blockchain の有効性を確保するコストが非線形的に増加するためです。 取引を個別に検証するコストに関して。ロールアップは次のように異なります。 ライトノードでのトランザクション実行の正当性を保証するメカニズム: 楽観的なロールアップは、有効期間中、経済モデルとフォールトプルーフによって保証されます。 ロールアップは、有効性証明を使用して暗号的に保証されます。 ライト ノードは、Layer 1 上の smart contract として実装できます。彼らはその根を受け入れます 新しい状態を確認し、有効性または障害の証明を検証します。したがって、これらのロールアップはスマート コントラクトと呼ばれます。 ロールアップ。ライト ノードが独立している場合、それらはソブリン ロールアップ [6] と呼ばれます。の利点 スマート コントラクト ロールアップを使用すると、両者の間に信頼を最小限に抑えたブリッジを構築できるようになります。 blockchains: L2 状態の正当性が L1 に証明されたため、L1 からのトランザクションのシステムが L2からL1まで実装可能で引き出しも可能です。デメリットとしては、費用がかかることです トランザクションは、L1 の状態を検証するコストに依存します。ベース層が飽和している場合、 他のアクティビティに伴い、ロールアップのトランザクションのコストも増加します。 データ層とコンセンサス層は、システムのセキュリティを決定するものです。 トランザクションの順序を定義し、攻撃を防ぎ、状態を証明するためにデータを利用できるようにします。 有効性。 論文寄稿 このペーパーでは、2 つの革新的なオプティミスティック ロールアップと妥当性ロールアップについて研究します。 Optimism Bedrock や StarkNet などの注目すべき実装に焦点を当てた、スケーラビリティのトリレンマに対するソリューション。私たちの貢献には、これらの包括的な比較が含まれます 解決策、引き出し時間の分析、Optimism に対する攻撃の可能性についての議論 岩盤。さらに、ガス圧縮比を計算し、アプリケーション固有の最適化を提供し、Ethereum からの移行の長所と短所を示します。 仮想マシン (EVM)。

紙の構造 論文は以下のように構成されている。セクション 2 では、楽観的なロールアップについて説明します。 Optimism 岩盤を分析することで導入されました。セクション 3 では、有効性ロールアップが導入されています。 StarkNet を分析しています。セクション 4 では、2 つのソリューションを比較します。最後に、セクション 5 で描画します。 いくつかの結論。

التراكمات المتفائلة

  1. مجموعات متفائلة إن فكرة القبول المتفائل لمخرجات الكتل دون التحقق من تنفيذها هي موجودة بالفعل في Bitcoin المستند التقني [7]، الذي يناقش العقد الضوئية. هذه العقد تتبع فقط سلسلة الرأس عن طريق التحقق من قاعدة الإجماع، مما يجعلها عرضة لقبول الكتل تحتوي على معاملات غير صالحة في حالة حدوث هجوم بنسبة 51%. يقترح ناكاموتو حل هذه المشكلة حل المشكلة باستخدام نظام "تنبيه" لتحذير العقد الخفيفة من أن الكتلة تحتوي على معاملات غير صالحة. هذه الآلية يطبقها لأول مرة البسام وسونينو وبوتيرين [8] فيها خطأ يتم استخدام نظام إثبات يعتمد على رموز تصحيح الأخطاء [9]. من أجل تمكين إنشاء إثباتات الأخطاء، من الضروري أن تكون البيانات من جميع الكتل، بما في ذلك الكتل غير الصالحة، متاحة لـ الشبكة: وهي مشكلة توفر البيانات، والتي يتم حلها باستخدام البيانات الاحتمالية آلية أخذ العينات. أول تصميم متفائل تم تقديمه بواسطة جون أدلر و Mikerah Quintyne-Collins في عام 2019 [10]، حيث يتم نشر الكتل على blockchain آخر الذي يحدد إجماعهم على الطلب. 2.1. Optimism حجر الأساس Bedrock [11] هو أحدث إصدار من Optimism، مجموعة العقود الذكية. الإصدار السابق، تتطلب الآلة الافتراضية المتفائلة (OVM) مترجمًا مخصصًا لتجميع Solidity في نظامها رمز البايت الخاص: في المقابل، فإن Bedrock يعادل تمامًا EVM من حيث محرك التنفيذ يتبع Ethereum مواصفات الورق الأصفر [12]. 2.1.1. الودائع يمكن للمستخدمين إيداع المعاملات من خلال عقد على Ethereum، بوابة Optimism، عن طريق استدعاء وظيفة الإيداع. عند تنفيذ المعاملة، أ يتم إطلاق حدث TransactionDeposited، والذي تستمع إليه كل عقدة في مجموعة التحديثات لمعالجته الودائع. المعاملة المودعة هي معاملة L2 مشتقة من L1. إذا كان المتصل الوظيفة عقد، يتم تحويل العنوان بإضافة قيمة ثابتة إليه: وهذا يمنع الهجمات التي يكون فيها العقد الموجود على L1 له نفس عنوان العقد الموجود على L2 ولكن برمز مختلف. يتم ضمان التضمين في L2 للمعاملة المودعة من خلال المواصفات ضمن التسلسل نافذة. المعاملات المودعة هي نوع معاملة جديد متوافق مع EIP-2718 [13] مع البادئة 0x7E، حيث تكون الحقول المشفرة بـ rlp: • bytes32 sourceHash: hash الذي يحدد مصدر المعاملة بشكل فريد. • العنوان من : عنوان المرسل . • العنوان إلى: عنوان المستلم، أو العنوان الصفري إذا كانت المعاملة المودعة هي a إنشاء العقد.• uint256 mint: القيمة التي سيتم إنشاؤها على L2. • قيمة uint256: القيمة التي سيتم إرسالها إلى المستلم. • بايتات البيانات: بيانات الإدخال. • BytesgasLimit: حد الغاز للمعاملة. يتم حساب sourceHash باعتباره keccak256 hash للكتلة L1 hash وسجل L1 مؤشر، يحدد بشكل فريد حدثًا في الكتلة. نظرًا لأن المعاملات المودعة تبدأ على L1 ويتم تنفيذها على L2، فإن النظام يحتاج إلى آلية الدفع على L1 مقابل الغاز الذي يتم إنفاقه على L2. أحد الحلول هو إرسال ETH عبر البوابة، ولكن هذا يعني أنه يجب وضع علامة على كل متصل (حتى المتصلين غير المباشرين) على أنه مستحق الدفع، وهذا هو الحال غير ممكن للعديد من المشاريع القائمة. البديل هو حرق الغاز المقابل على L1. يسمى الغاز 𝑔المخصص للمعاملة المودعة بالغاز المضمون. سعر الغاز L2 لا تتم مزامنة L1 تلقائيًا ولكن يتم تقديره باستخدام آلية مشابهة لـ EIP-1559 [14]. الحد الأقصى لكمية الغاز المضمونة لكل كتلة Ethereum هي 8 ملايين، مع وجود هدف من 2 مليون. الكمية 𝑐‏ من ETH المطلوبة لدفع ثمن الغاز على L2 هي 𝑐= 𝑔𝑏L2 حيث 𝑏L2 هو رسوم الأساس على L2. العقد على L1 يحرق كمية من الغاز تساوي 𝑐/𝑏L2. قضى الغاز للاتصال يتم تعويض معاملة الإيداع على L2: إذا كان هذا المبلغ أكبر من الغاز المضمون، لا يتم حرق الغاز. المعاملة الأولى لكتلة rollup هي معاملة مودعة لسمات L1، تُستخدم للتسجيل على L2، قم بالنشر المسبق لسمات الكتل Ethereum. السمات التي يوفرها النشر المسبق الوصول إليها هو رقم الكتلة والطابع الزمني والرسوم الأساسية والكتلة hash والتسلسل الرقم، وهو رقم كتلة L2 بالنسبة إلى كتلة L1 المرتبطة (وتسمى أيضًا العصر)؛ تتم إعادة تعيين هذا الرقم عند بدء حقبة جديدة. 2.1.2. التسلسل تستمد العقد المجمعة سلسلة Optimism بالكامل من Ethereum. هذه السلسلة ممتدة في كل مرة يتم نشر معاملات جديدة على L1، ويتم إعادة تنظيم كتلها في كل مرة تمت إعادة تنظيم كتل Ethereum. يتم تقسيم مجموعة التحديثات blockchain إلى فترات. لكل 𝑛 رقم الكتلة Ethereum، هناك 𝑛epoch مناظر. كل عصر يحتوي على واحد على الأقل كتلة، وكل كتلة في حقبة تحتوي على معاملة L1 المودعة. الكتلة الأولى في عصر ما يحتوي على جميع المعاملات المودعة من خلال البوابة. قد يتم أيضًا حظر Layer 2 تحتوي على معاملات متسلسلة، أي المعاملات المرسلة مباشرة إلى جهاز التسلسل. يقبل جهاز التسلسل المعاملات من المستخدمين ويبني الكتل. لكل كتلة، فإنه يبني دفعة سيتم نشرها في Ethereum. يمكن نشر عدة دفعات بشكل مضغوط، أخذ اسم القناة. يمكن تقسيم القناة إلى عدة إطارات، إذا كانت كبيرة جدًا معاملة واحدة. يتم تعريف القناة على أنها الضغط باستخدام ZLIB [15] لـ rlp المشفر دفعات. حقول الدُفعة هي رقم العصر، العصر hash، الأصل hash، الطابع الزمني وقائمة المعاملات. تحتوي نافذة التسلسل، التي يتم تحديدها بواسطة عصر ما، على رقم ثابت 𝑤من L1 المتتالي الكتل التي تأخذها خطوة الاشتقاق كمدخل لإنشاء عدد متغير من كتل L2. ل في العصر 𝑛، تتضمن نافذة التسلسل 𝑛 الكتل [𝑛، 𝑛+𝑤). وهذا يعني أن الترتيب لا يتم إصلاح معاملات L2 والكتل داخل نافذة التسلسل حتى تنتهي النافذة. تُسمى المعاملة rollup بأنها آمنة إذا تم تأكيد الدفعة التي تحتوي عليها على L1. إطاراتتتم قراءتها من كتل L1 لإعادة بناء الدُفعات. التنفيذ الحالي لا يسمح يبدأ ضغط القناة حتى يتم استقبال جميع الإطارات المقابلة. غير صالح يتم تجاهل الدفعات. يتم الحصول على معاملات الكتلة الفردية من الدُفعات يستخدمه محرك التنفيذ لتطبيق انتقالات الحالة والحصول على حالة الإظهار. 2.1.3. عمليات السحب من أجل معالجة عمليات السحب، يتم تطبيق نظام المراسلة من L2 إلى L1. Ethereum يحتاج إلى معرفة حالة L2 لقبول عمليات السحب، ويتم ذلك عن طريق النشر في Oracle Output L2 smart contract على L1 جذر الحالة لكل كتلة L2. هذه الجذور يتم قبولها بشكل متفائل على أنها صالحة (أو نهائية) إذا لم يتم إجراء إثبات خطأ أثناء فترة النزاع. يمكن فقط للعناوين المعينة كمقترحين نشر جذور المخرجات. الصلاحية يتم تحفيز جذور الإنتاج من خلال مطالبة مقدمي العروض بإيداع حصة يتم قطعها إذا قاموا بذلك تبين أنه اقترح جذرًا غير صالح. تبدأ المعاملات عن طريق استدعاء الدالة قم ببدء السحب عند النشر المسبق على L2 ثم تم الانتهاء منه على L1 عن طريق استدعاء الوظيفة FinalizeWithdrawalTransaction على بوابة Optimism المذكورة سابقًا. يتم الحصول على جذر الإخراج المقابل لكتلة L2 من L2 Output Oracle؛ إنه كذلك التحقق من أنه تم الانتهاء منه، أي أن فترة النزاع قد انقضت؛ تم التحقق من أن الإخراج يتطابق إثبات الجذر مع Oracle Proof؛ تم التحقق من تضمين hash الخاص بالسحب فيه باستخدام إثبات السحب؛ وأن الانسحاب لم يتم الانتهاء منه بالفعل؛ ومن ثم يتم تنفيذ الاتصال بالعنوان المستهدف، مع حد الغاز المحدد وكمية الأثير والبيانات. 2.1.4. المدفع: نظام إثبات الخطأ إذا اكتشفت عقدة التجميع الكاملة ذلك، من خلال تنفيذ الدفعات والمعاملات المودعة محليًا الحالة Layer 2 لا تتطابق مع جذر الحالة المنشور على السلسلة بواسطة مقدم العرض، ويمكن تنفيذها دليل خطأ على L1 لإثبات أن نتيجة انتقال الكتلة غير صحيحة. بسبب بشكل عام، تعد معالجة كتلة القيمة المحتسبة بالكامل على L1 مكلفة للغاية. تم تنفيذ الحل بواسطة Bedrock هو تنفيذ التعليمات الأولى للخلاف في minigeth على السلسلة فقط، تجميعها في بنية MIPS التي يتم تنفيذها على مترجم على السلسلة ونشرها على L1. minigeth هو نسخة مبسطة من geth 1 حيث يتم تضمين الإجماع وRPC وقاعدة البيانات تمت إزالتها. للعثور على تعليمات الخلاف الأولى، يتم إجراء بحث ثنائي تفاعلي بين الشخص الذي بدأ إثبات الخطأ والذي نشر جذر الإخراج. عندما يكون الدليل يبدأ كلا الطرفين بنشر جذر حالة الذاكرة MIPS في منتصف عملية التنفيذ الحظر في عقد التحدي: إذا كان hash يتطابق فهذا يعني أن الطرفين يتفقان على النصف الأول من التنفيذ وبذلك ينشر جذر نصف النصف الثاني، وإلا النصف يتم نشر النصف الأول وهكذا. إن القيام بذلك يحقق التعليمات الأولى للخلاف في عدد لوغاريتمي من الخطوات مقارنة بالتنفيذ الأصلي. فإذا توقف أحد الأمرين التفاعل، في نهاية فترة النزاع، يفوز المشارك الآخر تلقائيًا. لمعالجة التعليمات، يحتاج المترجم MIPS إلى الوصول إلى ذاكرته: نظرًا لأن الجذر هو المتاحة، يمكن نشر خلايا الذاكرة اللازمة عن طريق إثبات إدراجها. للوصول حالة EVM، يتم استخدام Preimage Oracle: بالنظر إلى hash للكتلة التي يتم إرجاعها 1https://geth.ethereum.org/docs

رأس الكتلة، والذي يمكن من خلاله الحصول على hash من الكتلة السابقة والعودة إلى chain، أو احصل على hash للحالة والسجلات التي يمكن من خلالها الحصول على الصورة الأولية. oracle يتم تنفيذه بواسطة Minigeth ويحل محل قاعدة البيانات. يتم إجراء الاستعلامات إلى العقد الأخرى ل الحصول على الصور الأولية.

楽観的なロールアップ

  1. 楽観的なロールアップ ブロックの実行を検証せずに、ブロックの出力を楽観的に受け入れるというアイデアは次のとおりです。 ライト ノードについて説明している Bitcoin ホワイトペーパー [7] にすでに記載されています。これらのノードは後続するだけです コンセンサス ルールを検証してヘッダー チェーンをブロックし、ブロックを受け入れやすくする 51% 攻撃が発生した場合に無効なトランザクションが含まれる。ナカモトはこれを解決することを提案します 「アラート」システムを使用して、ブロックに無効なトランザクションが含まれていることをライトノードに警告することで、この問題を解決します。 このメカニズムは、Al-Bassam、Sonnino、Buterin [8] によって最初に実装されました。 誤り訂正符号[9]に基づく証明システムが使用されます。の作成を可能にするために、 フォールトプルーフのためには、無効なブロックを含むすべてのブロックのデータが利用可能である必要があります。 ネットワーク: これはデータ可用性問題であり、確率的データを使用して解決されます。 サンプリング機構。最初のオプティミスティック ロールアップ デザインは、ジョン アドラーと 2019 年 [10] の Mikerah Quintyne-Collins、ブロックは別の blockchain で公開されています それが注文に関する彼らの合意を定義します。 2.1. Optimism 岩盤 Bedrock [11] は、スマート コントラクト ロールアップである Optimism の最新バージョンです。以前のバージョンでは、 Optimistic Virtual Machine (OVM) では、Solidity をコンパイルするためにアドホック コンパイラーが必要でした。 独自のバイトコード: 対照的に、Bedrock は実行エンジンという点で EVM と完全に同等です。 Ethereum イエロー ペーパー仕様 [12] に従います。 2.1.1.預金 ユーザーは、depositTransaction 関数を呼び出すことで、Ethereum、Optimism ポータル上のコントラクトを通じてトランザクションをデポジットできます。 トランザクションが実行されると、 TransactionDeposited イベントが発行され、ロールアップ内の各ノードが処理をリッスンします。 預金。入金されたトランザクションは、L1 から派生した L2 トランザクションです。の発信者が 関数がコントラクトである場合、アドレスはそれに定数値を追加することによって変換されます。これにより、 L1 のコントラクトが L2 のコントラクトと同じアドレスを持つが、コードが異なる攻撃。 入金されたトランザクションが L2 に含まれることは、シーケンス内の仕様によって保証されます。 窓。 入金されたトランザクションは、プレフィックス 0x7E を持つ新しい EIP-2718 互換トランザクション タイプ [13] です。 ここで、rlp エンコードされたフィールドは次のとおりです。 • bytes32 sourceHash: トランザクションのソースを一意に識別する hash。 • address from: 送信者のアドレス。 • address to: 受信者のアドレス、または入金されたトランザクションが 契約書の作成。• uint256 mint: L2 で作成される値。 • uint256 値: 受信者に送信される値。 • バイトデータ: 入力データ。 • バイトの GasLimit: トランザクションのガス制限。 sourceHash は、L1 ブロック hash および L1 ログの keccak256 hash として計算されます。 インデックス。ブロック内のイベントを一意に識別します。 入金されたトランザクションは L1 で開始されますが、L2 で実行されるため、システムには L2 で消費されたガスの対価を L1 で支払うメカニズム。解決策の 1 つは、ポータル経由で ETH を送信することです。 しかしこれは、すべての呼び出し元 (間接的な呼び出し元も含む) が支払い可能としてマークされなければならないことを意味します。 多くの既存プロジェクトでは不可能です。別の方法は、L1 で対応するガスを燃焼させることです。 入金されたトランザクションに割り当てられるガス𝑔を保証ガスと呼びます。 L2ガスの価格は L1 は自動的には同期されませんが、EIP-1559 と同様のメカニズムを使用して推定されます。 [14]。 Ethereum ブロックごとに保証されるガスの最大量は 800 万であり、目標は 200万の。 L2 でガスの支払いに必要な ETH の量 𝑐 は 𝑐= 𝑔𝑏L2 です。ここで、𝑏L2 は L2 の基本料金。 L1 のコントラクトでは、𝑐/𝑏L2 に等しい量のガスが燃焼します。通話に費やしたガソリン デポジットトランザクションは L2 で払い戻されます。この金額が保証されたガスより大きい場合、 ガスは燃焼しません。 rollup ブロックの最初のトランザクションは、L1 属性が登録されたトランザクションであり、登録に使用されます。 L2 では、Ethereum ブロックの属性を事前展開します。事前デプロイによって与えられる属性 アクセスできるのは、ブロック番号、タイムスタンプ、基本料金、ブロック hash、およびシーケンスです。 番号。これは、関連する L1 ブロックに対する相対的な L2 のブロック番号 (エポックとも呼ばれます)。 この番号は、新しいエポックが開始されるとリセットされます。 2.1.2.シーケンス ロールアップ ノードは、Optimism チェーンを完全に Ethereum から派生させます。このチェーンは延長されます 新しいトランザクションが L1 で公開されるたびに、そのブロックはそのたびに再編成されます Ethereum ブロックが再編成されます。ロールアップ blockchain はエポックに分割されています。 𝑛ごとに ブロック番号 Ethereum には、対応する 𝑛エポックがあります。各エポックには少なくとも 1 つが含まれます ブロックであり、エポック内の各ブロックには、L1 属性がデポジットされたトランザクションが含まれます。最初のブロック エポックには、ポータルを通じて入金されたすべてのトランザクションが含まれます。 Layer 2 ブロックは、 シーケンスされたトランザクション、つまりシーケンサーに直接送信されるトランザクションが含まれていました。 シーケンサーはユーザーからトランザクションを受け入れ、ブロックを構築します。ブロックごとに、 Ethereum に公開されるバッチ。複数のバッチを圧縮して公開できます。 名前チャンネルを取得します。チャネルが大きすぎる場合に備えて、チャネルを複数のフレームに分割できます。 単一のトランザクション。チャネルは、rlp エンコードされた ZLIB [15] による圧縮として定義されます。 バッチ。バッチのフィールドは、エポック番号、エポック hash、親 hash、 タイムスタンプとトランザクションリスト。 エポックによって識別されるシーケンス ウィンドウには、連続する L1 の固定数 𝑤 が含まれます。 導出ステップが可変数の L2 ブロックを構築するために入力として受け取るブロック。のために エポック 𝑛 では、シーケンス ウィンドウ 𝑛 にはブロック [𝑛, 𝑛+𝑤) が含まれます。これは、順序付けが シーケンス ウィンドウ内の L2 トランザクションとブロックの数は、ウィンドウが終了するまで修正されません。 rollup トランザクションは、それを含むバッチが L1 で確認された場合、安全であると呼ばれます。フレームバッチを再構築するために L1 ブロックから読み取られます。現在の実装では許可されていません 対応するすべてのフレームが受信されるまで、チャネルの圧縮解除が開始されます。無効です バッチは無視されます。個々のブロック トランザクションはバッチから取得されます。 状態遷移を適用し、ロールアップ状態を取得するために実行エンジンによって使用されます。 2.1.3.出金 出金を処理するために、L2-to-L1 メッセージング システムが実装されています。 Ethereum 出金を受け入れるためには L2 の状態を知る必要があり、これはパブリッシングによって行われます。 L2 の出力 Oracle smart contract L1 の各 L2 ブロックのステート ルート。これらの根 実行中にフォールトプルーフが実行されなければ、有効（または確定）として楽観的に受け入れられます。 争議期間。プロポーザとして指定されたアドレスのみが出力ルートを公開できます。有効性 提案者に賭け金を預けてもらうことで、出力ルートの割合が奨励されます。 無効なルートを提案したことが示されています。トランザクションは関数を呼び出すことで開始されます L2 での事前デプロイでのInitialWithdrawal と、関数の呼び出しによる L1 での終了 前述の Optimism ポータルでのfinalizeWithdrawalTransaction。 L2 ブロックに対応する出力ルートは、L2 Output Oracle から取得されます。それはです それが最終決定されたこと、つまり紛争期間が経過したことを確認しました。出力が検証される Root Proof は Oracle Proof と一致します。出金のhashが含まれていることを確認します その中で引き出し証明を使用します。撤退がまだ完了していないこと。そして、 指定されたガス制限、イーサの量、およびデータを使用して、ターゲット アドレスへの呼び出しが実行されます。 2.1.4.大砲: 故障防止システム ロールアップ フル ノードがバッチとデポジットされたトランザクションをローカルで実行することによって、次のことを発見した場合 Layer 2 状態は、プロポーザーによってオンチェーンで公開された状態ルートと一致しないため、実行できます ブロック遷移の結果が正しくないことを証明するための L1 のフォールトプルーフ。のせいで オーバーヘッドのため、L1 でロールアップ ブロック全体を処理するのにコストがかかりすぎます。実装されたソリューション Bedrock によると、minigeth の不一致の最初の命令のみがオンチェーンで実行されます。 それを MIPS アーキテクチャにコンパイルし、オンチェーン インタプリタ上で実行して公開します。 L1で。 minigeth は、コンセンサス、RPC、およびデータベースを備えた geth 1 の簡易バージョンです。 は削除されています。 不一致の最初の命令を見つけるために、対話型バイナリ検索が次の間で実行されます。 フォールトプルーフを開始した者と出力ルートを公開した者です。証明のとき が開始されると、両方の当事者が実行の途中で MIPS メモリ状態のルートを公開します。 チャレンジ契約のブロック: hash が一致する場合、両当事者が 実行の前半は、後半の半分のルートを公開し、それ以外の場合は半分を公開します。 前半部分などを公開します。そうすることで、意見の不一致の最初の指示が達成されます 元の実行と比較して、対数的なステップ数で実行されます。 2台のうちどちらかが止まったら 対話すると、紛争期間の終了時に他の参加者が自動的に勝ちます。 命令を処理するには、MIPS インタプリタはそのメモリにアクセスする必要があります。 必要なメモリセルが利用可能であれば、そのメモリセルが含まれていることを証明することで公開できます。アクセスするには EVM の状態では、Preimage Oracle が使用されます。返されるブロックの hash が与えられると、 1https://geth.ethereum.org/docs

ブロックヘッダー。そこから前のブロックの hash を取得して、そのブロックに戻ることができます。 チェーンするか、プリイメージを取得できる状態とログの hash を取得します。 oracle minigeth によって実装され、データベースを置き換えます。他のノードに対してクエリが実行され、 プリイメージを取得します。

تراكمات الصلاحية

  1. مجموعات الصلاحية الهدف من مجموعة الصلاحية هو إثبات صحة انتقال الحالة بشكل مشفر نظرا لتسلسل المعاملات مع برهان قصير يمكن التحقق منه خطيا مقارنة إلى وقت الحسابات الأصلية. يُطلق على هذا النوع من الشهادات اسم إثباتات التكامل الحسابي ويتم تنفيذها عمليًا باستخدام SNARKs (وسيطة المعرفة غير التفاعلية المختصرة)، والتي تستخدم العمليات الحسابية الدوائر كنموذج حسابي لها. تختلف تطبيقات SNARK المختلفة في وقت الإثبات، وقت التحقق، والحاجة إلى إعداد موثوق به ومقاومة كمية [16، 17]. ستاركس (قابلة للتطوير حجة المعرفة الشفافة) [18] هي نوع من SNARKs التي لا تتطلب وسيطًا موثوقًا به الإعداد ومقاومة الكم، مع التخلي عن بعض الكفاءة في الإثبات والتحقق مقارنة بالحلول الأخرى. 3.1. StarkNet StarkNet عبارة عن مجموعة من صلاحية العقد الذكي تم تطويرها بواسطة StarkWare والتي تستخدم STARK نظام إثبات للتحقق من صحة حالته إلى Ethereum. لتسهيل بناء أدلة الصحة، أ يتم استخدام جهاز افتراضي مختلف عن EVM، ولغته عالية المستوى هي القاهرة. 3.1.1. الودائع يمكن للمستخدمين إيداع المعاملات عبر عقد على Ethereum عن طريق الاتصال بـ sendMessageToL2 وظيفة. يتم تسجيل الرسالة عن طريق حساب hash وزيادة العداد. التسلسل استمع إلى حدث LogMessageToL2 وقم بتشفير المعلومات في معاملة StarkNet يستدعي وظيفة العقد الذي يحتوي على ديكور l1_handler. وفي نهاية التنفيذ، عندما يتم إنتاج إثبات انتقال الحالة، يتم إرفاق استهلاك الرسالة به ويتم حذفه بتقليل عداده. إن إدراج المعاملات المودعة ليس مطلوبًا بموجب مواصفات StarkNet، لذا فهو غاز هناك حاجة إلى السوق لتحفيز التسلسلات لنشرها على L2. في الإصدار الحالي، لأن يتم التحكم في جهاز التسلسل بشكل مركزي وإدارته بواسطة StarkWare، وهي تكلفة المعاملات المودعة يتم تحديده فقط من خلال تكلفة تنفيذ الإيداع. يتم دفع هذه التكلفة عن طريق إرسال ETH إلى sendMessageToL2. تظل هذه الإثيرات مقفلة على L1 ويتم نقلها إلى جهاز التسلسل L1، عندما يتم تضمين المعاملة المودعة في انتقال الحالة. مبلغ ETH المرسل، إذا يتم تضمين المعاملة المودعة، وإنفاقها بالكامل، بغض النظر عن كمية الغاز المستهلكة على L2. لا يحتوي StarkNet على نظام يجعل سمات كتلة L1 متاحة تلقائيًا. وبدلاً من ذلك، فإن Fossil هو بروتوكول تم تطويره بواسطة Oiler Network 2 والذي يسمح، بالنظر إلى hash من منع أي معلومات يمكن الحصول عليها من Ethereum عن طريق نشر الصور الأولية. 2https://www.oiler.network/3.1.2. التسلسل يمكن اشتقاق الحالة الحالية لـ StarkNet بالكامل من Ethereum. أي اختلاف الدولة يتم نشر بين التحولات على L1 كبيانات الاتصال. يتم نشر الاختلافات لكل عقد ويتم حفظها كـ uint256[] بالتشفير التالي: • عدد الحقول المتعلقة بعمليات نشر العقد. • لكل عقد منشور: – عنوان العقد المنشور. – hash للعقد المنشور. – عدد حجج منشئ العقد.
  2. قائمة وسيطات المنشئ • عدد العقود التي تم تعديل تخزينها. • لكل عقد تم تعديله: – عنوان العقد المعدل. – عدد تحديثات التخزين.
  3. أزواج القيمة الرئيسية لعناوين التخزين مع القيم الجديدة. يتم نشر اختلافات الحالة بالترتيب، لذلك يكفي قراءتها بالتسلسل إعادة بناء الدولة. 3.1.3. عمليات السحب لإرسال رسالة من L2 إلى L1، يتم استخدام syscall send_message_to_L1. الرسالة هي تم نشره إلى L1 عن طريق زيادة عداد hash مع الدليل وتم الانتهاء منه عن طريق استدعاء الدالة ConsumerMessageFromL2 على StarkGate smart contract على L1، مما يتناقص العداد. يمكن لأي شخص وضع اللمسات الأخيرة على أي انسحاب. 3.1.4. إثباتات الصلاحية تم تصميم جهاز القاهرة الافتراضي [19] لتسهيل إنشاء براهين ستارك. تسمح لغة القاهرة بوصف العمليات الحسابية ببرمجة عالية المستوى اللغة، وليس مباشرة كدائرة. يتم تحقيق ذلك من خلال نظام المعادلات متعددة الحدود 3 يمثل حسابًا واحدًا: دورة FDE لهندسة فون نيومان. الرقم وبالتالي فإن القيود ثابتة ومستقلة عن نوع الحساب، مما يسمح بواحد فقط برنامج التحقق لكل برنامج يحتاج إلى إثبات حسابه. يقوم StarkNet بتجميع معاملات متعددة في دليل STARK واحد باستخدام مُثبت مشترك اسمه شارب. يتم إرسال البراهين إلى smart contract على Ethereum، والذي يتحقق من صحتها ويقوم بتحديث جذر Merkle المطابق للحالة الجديدة. التكلفة الخطية الفرعية للتحقق أ يسمح إثبات الصلاحية بإطفاء تكلفته على معاملات متعددة. 3 يسمى التمثيل الجبري المتوسط ​​(AIR)

有効性ロールアップ

  1. 有効性ロールアップ Validity Rollup の目的は、状態遷移の有効性を暗号的に証明することです。 準線形的に比較できる検証可能な短い証明を伴うトランザクションのシーケンスが与えられたとします。 元の計算の時点まで。 この種の証明書は計算整合性証明と呼ばれ、実際には算術演算を使用する SNARK (Succint Non-interactive ARgument of Knowledge) で実装されます。 回路を計算モデルとして使用します。 SNARK 実装が異なれば証明時間も異なります。 検証時間、信頼できるセットアップの必要性、および量子耐性 [16、17]。 STARK (スケーラブル) 透明な知識引数) [18] は、信頼できる認証を必要としない SNARK の一種です。 証明と検証の効率をある程度犠牲にする一方で、量子耐性を備えています。 他のソリューションと比較して。 3.1. StarkNet StarkNet は、Starkware によって開発された、STARK を使用するスマート コントラクト有効性ロールアップです。 Ethereum までの状態を検証する証明システム。有効性証明の構築を容易にするために、 EVM とは異なる仮想マシンが使用されており、その高級言語は Cairo です。 3.1.1.預金 ユーザーは、sendMessageToL2 を呼び出すことで、Ethereum のコントラクトを介してトランザクションを入金できます。 機能。メッセージは、hash を計算し、カウンターを増やすことによって記録されます。シーケンサー LogMessageToL2 イベントをリッスンし、StarkNet トランザクションで情報をエンコードします。 l1_handler デコレータを持つコントラクトの関数を呼び出します。実行の最後に、 状態遷移の証明が生成されると、メッセージの消費がそれに添付されます そしてカウンターを減らすことで削除されます。 StarkNet 仕様では、入金されたトランザクションを含めることは必須ではないため、 シーケンサーが L2 で公開するよう奨励するには、市場が必要です。現在のバージョンでは、 シーケンサーは StarkWare によって集中管理され、入金されたトランザクションのコストは はデポジットの実行コストによってのみ決定されます。この費用はETHを送金することで支払われます。 L2 にメッセージを送信します。これらのイーサは L1 でロックされたままになり、L1 でシーケンサに転送されます。 L1、入金されたトランザクションが状態遷移に含まれる場合。送金されたETHの量（場合） ガスの消費量に関係なく、入金されたトランザクションは含まれており、全額使用されます。 L2で。 StarkNet には、L1 ブロック属性を自動的に使用可能にするシステムがありません。 また、Fossil は、Oiler Network 2 によって開発されたプロトコルであり、hash を指定すると、 ブロック、プレイメージを公開することによって Ethereum から取得される情報。 2https://www.oiler.network/3.1.2.シーケンス StarkNet の現在の状態は、すべて Ethereum から派生できます。あらゆる状態の違い トランジション間はコールデータとして L1 に公開されます。差異は契約ごとに公開されます 次のエンコードを使用して uint256[] として保存されます。 • 契約展開に関するフィールドの数。 • 公開された各契約について: – 公開された契約書の住所。 – 公開された契約の hash。 – コントラクト コンストラクターの引数の数。 – コンストラクター引数のリスト • ストレージが変更された契約の数。 • 変更された各契約について: – 変更された契約の住所。 – ストレージ更新の数。 – 新しい値を含むストレージ アドレスのキーと値のペア。 状態の違いは順番に公開されているため、順番に読んでいけば十分です。 状態を再構築します。 3.1.3.出金 L2 から L1 にメッセージを送信するには、syscall send_message_to_L1 を使用します。メッセージは 証明とともに hash カウンタを増やすことで L1 に公開され、 L1 の StarkGate smart contract の関数 ConsumerMessageFromL2 (デクリメント) カウンター。誰でも出金を完了できます。 3.1.4.有効性の証明 Cairo 仮想マシン [19] は、STARK 証明の構築を容易にするように設計されています。 Cairo 言語を使用すると、高レベルのプログラミングで計算を記述することができます。 言語であり、直接回路としてではありません。これは多項方程式系によって実現されます。 図３は、単一の計算、すなわちフォン・ノイマン・アーキテクチャのＦＤＥサイクルを表す。番号 したがって、制約の数は固定され、計算の種類に依存せず、1 つだけが許可されます。 計算を証明する必要があるすべてのプログラムの検証プログラム。 StarkNet は、共有証明者を使用して複数のトランザクションを単一の STARK 証明に集約します シャープという名前。証明は Ethereum の smart contract に送信され、その有効性が検証されます。 そして、新しい状態に対応するマークル ルートを更新します。検証にかかるサブリニアコスト 有効性の証明により、そのコストを複数のトランザクションにわたって償却することができます。 3代数中間表現 (AIR) と呼ばれる

مقارنة

  1. المقارنة 4.1. وقت الانسحاب الجانب الأكثر أهمية الذي يميز مجموعات التفاؤل عن مجموعات الصلاحية هو الوقت المنقضي بين بدء عملية الانسحاب ووضع اللمسات النهائية عليها. في كلتا الحالتين، تتم تهيئة عمليات السحب على L2 والانتهاء منها على L1. في StarkNet، يمكن الانتهاء من ذلك بمجرد قبول إثبات صحة جذر الحالة الجديد في Ethereum: من الناحية النظرية، فهو كذلك من الممكن سحب الأموال في المجموعة الأولى من L1 بعد التهيئة. في الممارسة العملية، تردد إرسال إثباتات الصلاحية على Ethereum عبارة عن مفاضلة بين سرعة البلوك وضع اللمسات النهائية وتجميع الأدلة. يوفر StarkNet حاليًا أدلة صحة للتحقق كل 10 ساعات 4، ولكن المقصود أن تنخفض مع زيادة نشاط المعاملات. في Optimism Bedrock من الممكن إنهاء الانسحاب فقط في نهاية النزاع (حاليًا 7 أيام)، وبعدها يعتبر الجذر صالحًا تلقائيًا. طول يتم تحديد هذه الفترة بشكل أساسي من خلال حقيقة أنه يمكن فرض الرقابة على أدلة الأخطاء على Ethereum حتى نهايتها. تتناقص احتمالية نجاح هذا النوع من الهجمات بشكل كبير مع مرور الوقت: ه[القيمة المطروحة] = 𝑉𝑝𝑛 حيث 𝑛 هو عدد الكتل في الفترة، و𝑉 هو مقدار الأموال التي يمكن طرحها عن طريق نشر جذر غير صالح، و𝑝 هو احتمال إجراء الرقابة بنجاح الهجوم في كتلة واحدة. لنفترض أن هذا الاحتمال هو 99%، أن القيمة مؤمنة في التراكمي هو مليون إيثر، وأن الكتل في فترة زمنية هي 1800 (6 ساعات من الكتل مع 12 الفاصل الزمني للثواني): القيمة المتوقعة هي حوالي 0.01391 إيثر. أصبح النظام آمنًا بواسطة مطالبة مقدمي العروض بالحصول على كمية أكبر بكثير من الأثير من القيمة المتوقعة. وينزر وآخرون. أظهر كيفية تنفيذ هجوم الرقابة باستخدام smart contract بسيط يضمن عدم تغيير مناطق معينة من الذاكرة في الحالة [20]. نمذجة الهجوم باعتبارها لعبة ماركوف، توضح الورقة أن الرقابة هي الإستراتيجية السائدة للعقلانية منتج الكتلة إذا حصل على تعويض أكبر من تضمين المعاملة التي تتغير الذاكرة. يمكن اعتبار قيمة 𝑝‏ التي تمت مناقشتها أعلاه كنسبة مئوية من الكتلة النسبية المنتجين في الشبكة، حيث "العقلاني" لا يأخذ بعين الاعتبار احتمال معاقبة العوامل الخارجية، مثل انخفاض الثقة في blockchain مما يقلل من قيمة العملة المشفرة الخاصة بها. يقدم الكود التالي smart contract الذي يمكن استخدامه لتنفيذ هجوم الرقابة على حجر الأساس. يستغل الهجوم حوافز منتجي الكتل من خلال تقديم رشوة لهم فرض رقابة على المعاملات التي من شأنها تعديل أجزاء معينة من الدولة. العقد الرئيسي تسمح وظيفة "المطالبة بالرشوة" لمنتجي الكتل بالمطالبة بالرشوة إذا نجحوا في فرض الرقابة المعاملة المستهدفة عن طريق التحقق من عدم لمس جذر الإخراج غير الصالح. وظيفة المطالبةBribe (بايت تخزين الذاكرة) خارجي { require(!claimed[block.number], "تم المطالبة بالرشوة بالفعل"); تيار الذاكرة OutputProposal = StorageOracle.getStorage(L2_ORACLE, block.number, SLOT, إثبات التخزين)؛ يتطلب (invalidOutputRoot == current.outputRoot، "فشل الهجوم")؛ ادعى[block.number] = صحيح؛ (تم إرسال المنطق،) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4يتطلب (أرسل، "فشل في إرسال الأثير")؛ } القائمة 1: مثال على عقد يحفز هجوم الرقابة على Bedrock. يجب أن يأخذ طول فترة النزاع أيضًا في الاعتبار حقيقة وجود دليل على الخطأ دليل تفاعلي وبالتالي يجب توفير الوقت الكافي للمشاركين للتفاعل وأن أي تفاعل يمكن أن يخضع للرقابة. إذا حدثت الخطوة الأخيرة في وقت قريب جدًا من وفي نهاية فترة النزاع، تكون تكلفة الرقابة أقل بكثير. على الرغم من أن الرقابة هي الإستراتيجية المهيمنة، فإن احتمالية النجاح أقل لأن عقد الرقابة معرضة للخطر هجمات رفض الخدمة: يمكن للمهاجم إنشاء معاملات معقدة للغاية تنتهي بـ نشر إثبات الخطأ دون أي تكلفة، حيث لن يتم دفع أي رسوم. وفي الحالات القصوى، تسمح فترة النزاع الطويلة بالتنسيق في حالة نجاحه هجوم الرقابة لتنظيم شوكة واستبعاد منتجي الكتلة المهاجمين. آخر يتمثل الهجوم المحتمل في نشر مقترحات لجذر الدولة أكثر مما يستطيع المتنازعون التحقق منه، والتي يمكن تجنبها باستخدام حد التردد. 4.1.1. انسحابات متفائلة سريعة نظرًا لأنه يمكن التحقق من صحة مجموعة التحديثات المتفائلة في أي وقت بواسطة أي عقدة كاملة، أ يمكن استخدام oracle الموثوق به لمعرفة ما إذا كان من الممكن إنهاء السحب بأمان على L1. هذا تم اقتراح الآلية لأول مرة بواسطة Maker [21]: يتحقق oracle من السحب، وينشر النتيجة على L1 حيث يتم تعيين قرض بفائدة للمستخدم، والذي يتم تلقائيًا يتم إغلاقه في نهاية 7 أيام، أي عندما يمكن الانتهاء من السحب فعليًا. هذا الحل يقدم افتراض الثقة، ولكن في حالة Maker يتم تصغيره نظرًا لأن عامل التشغيل oracle تتم إدارته من قبل نفس المنظمة التي تتحمل المخاطر من خلال تقديم القرض. 4.2. تكاليف المعاملات يتم تحديد تكلفة معاملات المستوى الثاني في الغالب من خلال التفاعل مع المستوى الأول. في كلا الحلين التكلفة الحسابية للمعاملات رخيصة جدًا حيث يتم تنفيذها بالكامل خارج السلسلة. Optimism ينشر بيانات استدعاء معاملات L2 كبيانات استدعاء ونادرًا (أو لا ينفذ أبدًا) الخطأ البراهين، وبالتالي فإن بيانات الاتصال هي المورد الأكثر تكلفة. في 12 يناير 2022 شبكة بيدروك تم إطلاقه على شبكة اختبار Goerli الخاصة بـ Ethereum. يمكن حساب معدل ضغط الغاز من خلال تتبع كمية الغاز المستخدمة في حجر الأساس في فترة معينة ومقارنتها مع كمية الغاز المستهلكة على L1 للكتل المقابلة. باستخدام هذه الطريقة ضغط الغاز تم العثور على معدل ∼20 : 1، ولكن هذا الرقم قد يختلف مع النشاط الحقيقي على الشبكة الرئيسية. StarkNet ينشر في Ethereum كل تغيير في حالة L2 كبيانات اتصال، وبالتالي فإن التخزين أغلى الموارد. نظرًا لأن الشبكة لا تستخدم EVM، فستكون تكلفة المعاملة لا يمكن تقدير الضغط بشكل تافه. من خلال افتراض تكلفة التنفيذ وبيانات الاتصال تكون ضئيلة، فمن الممكن لحساب نسبة ضغط الكتابة التخزين مقارنة L1. بافتراض عدم نشر أي عقد و10 خلايا لم يتم الوصول إليها مسبقًا على StarkNet تم تعديله، وتم العثور على معدل ضغط تكلفة كتابة التخزين يبلغ ∼ 24: 1. إذا تم الكتابة فوق الخلية 𝑛مرات بين عمليات نشر البيانات، ستكون تكلفة كل عملية كتابة 1/𝑛مقارنة بالتكلفة من كتابة واحدة، حيث يتم نشر آخر واحد فقط. يمكن تقليل التكلفة بشكل أكبر من خلالضغط القيم المستخدمة بشكل متكرر. وتنقسم تكلفة التحقق من صحة إثبات بين المعاملات التي يشير إليها: على سبيل المثال، StarkNet الكتلة 4779 تحتوي على 200 معاملة و إثبات الصلاحية يستهلك 267830 وحدة غاز، أو 1339.15 غاز لكل معاملة. 4.2.1. تحسين بيانات الاتصال: عقد ذاكرة التخزين المؤقت الموضح أدناه هو smart contract الذي يقوم بتنفيذ ذاكرة تخزين مؤقت للعناوين للاستخدام المتكرر العناوين من خلال الاستفادة من حقيقة أن التخزين والتنفيذ أقل تكلفة بكثير الموارد، إلى جانب عقد الأصدقاء الذي يوضح استخدامه. هذا الأخير يتتبع "أصدقاء" لعنوان يمكن تسجيله عن طريق استدعاء وظيفة addFriend. إذا كان عنوان تم استخدامه بالفعل مرة واحدة على الأقل، ويمكن إضافته عن طريق استدعاء addFriendWithCache الوظيفة: مؤشرات ذاكرة التخزين المؤقت هي أعداد صحيحة مكونة من 4 بايت بينما يتم تمثيل العناوين بـ 20 بايت، لذلك هناك توفير بنسبة 5:1 في وسيطة الوظيفة. يمكن استخدام نفس المنطق للبيانات الأخرى أنواع مثل الأعداد الصحيحة أو البايتات بشكل عام. العقد AddressCache { تعيين (عنوان => uint32) عنوان عام 2key؛ العنوان[] المفتاح العام2عنوان; وظيفة ذاكرة التخزين المؤقت (العنوان _address) العوائد الداخلية (uint32) { require(key2address.length < type(uint32).max, "AddressCache: ذاكرة التخزين المؤقت ممتلئة"); require(address2key[_address] == 0, "AddressCache: العنوان مخبأ بالفعل"); // يجب أن تبدأ المفاتيح من 1 لأن 0 يعني "لم يتم العثور عليها" مفتاح uint32 = uint32(key2address.length + 1); Address2key[_address] = key; key2address.push(_address); مفتاح العودة؛ } وظيفة ذاكرة التخزين المؤقت قراءة (uint32 _key) إرجاع العرض العام (العنوان) { require(_key <= key2address. length && _key > 0, "AddressCache: لم يتم العثور على المفتاح"); إرجاع عنوان المفتاح2[_key - 1]; } } القائمة 2: عنوان عقد التخزين المؤقت. أصدقاء العقد هو AddressCache { تعيين (العنوان => العنوان []) الأصدقاء العامين؛ وظيفة addFriend(address _friend) عامة { friends[msg.sender].push(_friend); ذاكرة التخزين المؤقت(_friend); } وظيفة addFriendWithCache(uint32 _friendKey) عامة { friends[msg.sender].push(cacheRead(_friendKey)); } وظيفة getFriends () إرجاع العرض العام (العنوان [] الذاكرة) { عودة الأصدقاء[msg.sender]؛} } القائمة 3: مثال على عقد يرث ذاكرة التخزين المؤقت للعنوان. يدعم العقد في ذاكرة التخزين المؤقت حوالي 4 مليارات (232) عنوانًا، ويعطي إضافة بايت واحد حوالي 1 تريليون (240). 4.2.2. تحسين التخزين: مرشحات بلوم يوجد في StarkNet العديد من الأساليب لتقليل استخدام مساحة التخزين. إذا لم يكن من الضروري أن ضمان توافر البيانات الأصلية، فيكفي حفظها على السلسلة hash: هذا هي الآلية المستخدمة لحفظ البيانات لـ ERC-721 (NFT) [22]، أي رابط IPFS الذي يحل المشكلة hash من البيانات إذا كانت متوفرة. بالنسبة للبيانات التي يتم تخزينها عدة مرات، فمن الممكن استخدام البحث جدول مشابه لنظام التخزين المؤقت المقدم لـ Optimism، والذي يتطلب حفظ جميع القيم فيه مرة واحدة على الأقل. بالنسبة لبعض التطبيقات، يمكن تجنب حفظ كافة القيم باستخدام مرشح بلوم [23، 24، 25]، أي بنية بيانات احتمالية تسمح للمرء أن يعرف على وجه اليقين ما إذا كان لا ينتمي العنصر إلى مجموعة ولكنه يعترف باحتمالية خطأ صغيرة ولكن لا يمكن إهمالها إيجابيات. تتم تهيئة مرشح Bloom كمصفوفة مكونة من 𝑚bits عند الصفر. لإضافة عنصر، استخدم الدالة 𝑘hash مع توزيع عشوائي موحد، يتم تعيين كل منها إلى جزء صغير من المصفوفة التي تم تعيينها إلى 1. للتحقق مما إذا كان العنصر ينتمي إلى المجموعة نقوم بتشغيل الوظائف 𝑘hash والتحقق أن قيمة 𝑘bits مضبوطة على 1. في مرشح بلوم البسيط، لا توجد طريقة للتمييز ما إذا كان ينتمي العنصر فعليًا إلى المجموعة أو يكون نتيجة إيجابية كاذبة، وهو احتمال ينمو كرقم من الإدخالات يزيد. بعد إدخال 𝑛العناصر: ف[إيجابية كاذبة] = (︃ 1 - [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 بافتراض استقلالية احتمالية كل مجموعة بت. إذا كان عدد 𝑛 من العناصر (ذات حجم عشوائي!) موجودًا من المتوقع أن يتم تضمينها، واحتمال وجود نتيجة إيجابية كاذبة مسموح بها هو 𝑝، وهو حجم المصفوفة يمكن حسابها على النحو التالي: 𝑚= −𝑛ln 𝑝 (في 2)2 بينما العدد الأمثل لوظائف hash هو: 𝑘= 𝑚 𝑛ln 2 إذا افترضنا إدراج 1000 عنصر بتفاوت 1% فإن حجم المصفوفة هو 9585 بت مع 𝑘= 6، بينما في حالة التسامح بنسبة 0.1% يصبح 14377 بت مع 𝑘= 9. إذا كان مليون عنصر ومن المتوقع إدراجها، يصبح حجم المصفوفة حوالي 1170 كيلو بايت لـ 1% و1775 كيلو بايت لـ 0.1%، بنفس قيم 𝑘، لأنها تعتمد فقط على 𝑝[26]. في لعبة لا يجب فيها تعيين اللاعبين إلى خصم سبق لهم تحديه، بدلاً من حفظ قائمة الخصوم السابقين في مساحة التخزين لكل لاعب، يمكن للمرء استخدام بلوم مرشح. غالبًا ما تكون مخاطرة عدم تحدي بعض اللاعبين مقبولة، ويمكن إعادة ضبط عامل التصفية بشكل دوري.4.3. Ethereum التوافق الميزة الرئيسية للتوافق مع EVM وEthereum هي إعادة استخدام كل ما هو متاح أدوات. Ethereum smart contracts يمكن نشرها على Optimism دون أي تعديل أو عمليات التدقيق الجديدة. تظل المحافظ متوافقة وأدوات التطوير والتحليل الثابت والتحليل العام الأدوات وأدوات الفهرسة وoracles. Ethereum و Solidity لها تاريخ طويل من الدراسة الجيدة الثغرات الأمنية، مثل هجمات إعادة الدخول، والتجاوزات والتجاوزات، والقروض السريعة، وoracle التلاعب. ولهذا السبب، تمكن Optimism من الحصول على قدر كبير من القيمة في وقت قصير الوقت. إن اختيار استخدام جهاز افتراضي مختلف يعني الحاجة إلى إعادة بناء النظام البيئي بأكمله، مع ميزة حرية تنفيذ أكبر. StarkNet ينفذ الحساب أصلاً التجريد، وهو آلية حيث يكون كل حساب smart contract يمكن تنفيذه المنطق التعسفي طالما أنه يتوافق مع واجهة (ومن هنا جاء مصطلح التجريد): وهذا يسمح استخدام أنظمة التوقيع الرقمي المختلفة، والقدرة على تغيير المفتاح الخاص باستخدام نفس العنوان، أو استخدم multisig. اقترح مجتمع Ethereum تقديم هذا آلية مع EIP-2938 في عام 2020، لكن الاقتراح ظل قديمًا لأكثر من عام تم إعطاء التحديثات الأخرى أولوية أكبر [27]. هناك فائدة أخرى مهمة يتم اكتسابها من التوافق وهي إعادة استخدام العملاء الحاليين: Optimism يستخدم نسخة من geth للعقدة الخاصة به مع اختلاف ∼ 800 سطر فقط، وهو ما كان تم تطويره واختباره وصيانته منذ عام 2014. إن وجود عميل قوي أمر بالغ الأهمية كما هو محدد ما هو مقبول على أنه صالح أم لا في الشبكة. خطأ في تنفيذ دليل على الخطأ قد يتسبب النظام في قبول دليل غير صحيح على أنه صحيح أو دليل صحيح على غير صالح ليتم قبول الكتلة على أنها غير صحيحة، مما يعرض النظام للخطر. احتمالية هذا النوع من يمكن أن يقتصر الهجوم على نطاق أوسع من العملاء: Optimism يمكن إعادة استخدامه بالإضافة إلى الحصول على عملاء Ethereum الآخرين الذين تمت صيانتهم بالفعل، ويتم تطوير عميل آخر قائم على Erigon جارية بالفعل. في عام 2016، تم استغلال مشكلة في إدارة الذاكرة في برنامج geth كان هجوم DoS وخط الدفاع الأول هو التوصية باستخدام التكافؤ، والثاني أكثر العميل المستخدم في ذلك الوقت 5. StarkNet يواجه نفس المشكلة مع إثباتات الصلاحية، لكن العملاء يجب كتابتها من الصفر، ونظام الإثبات أكثر تعقيدًا، وبالتالي بل هو أيضًا أكثر تعقيدًا لضمان الصحة.

比較

  1. 比較 4.1.出金時間 楽観的ロールアップと妥当性ロールアップを区別する最も重要な側面は、 出金の開始から完了までに経過する時間。どちらの場合も、 出金は L2 で初期化され、L1 で完了します。 StarkNet では、次のようにファイナライズが可能です 新しい状態ルートの有効性証明が Ethereum で受け入れられ次第、理論的には次のようになります。 初期化後の L1 の最初のブロックで資金を引き出すことが可能です。実際には、 Ethereum で有効性証明を送信する頻度は、ブロックの速度とのトレードオフです ファイナライゼーションと証明の集約。現在、StarkNet は検証のための有効性証明を提供しています 10 時間ごと 4 ですが、トランザクション アクティビティが増加するにつれて減少することが意図されています。 Optimism Bedrock では、紛争の終了時にのみ撤回を完了することができます。 期間 (現在は 7 日) が経過すると、ルートは自動的に有効とみなされます。長さ この期間は主に、Ethereum に欠陥証明が検閲されるまでの期間によって決定されます。 その終わり。このタイプの攻撃の成功確率は、時間の経過とともに指数関数的に減少します。 E[減算値] = 𝑉𝑝𝑛 ここで、𝑛は間隔内のブロック数、𝑉は差し引くことができる資金の量です 無効なルートを公開することによって、𝑝は検閲が正常に実行される確率です 単一ブロックで攻撃します。この確率が 99% で、値がロールアップにロックされていると仮定します。 は 100 万イーサ、間隔内のブロックは 1800 (12 個のブロックで 6 時間) 秒間隔): 期待値は約 0.01391 Ether です。システムの安全性は次のとおりです。 提案者に、期待値よりもはるかに大量のイーサをステーキングするよう求めます。 ウィンザーら。単純な smart contract を使用して検閲攻撃を実行する方法を示しました。 これにより、状態内のメモリの特定の領域が [20] 変更されないことが保証されます。攻撃のモデル化 この論文は、マルコフゲームとして、検閲が合理的なアプローチの支配的な戦略であることを示しています。 変更を伴うトランザクションを含めるよりも多くの報酬を受け取った場合、プロデューサーをブロックする 記憶。上で説明した 𝑝 値は、有理ブロックのパーセンテージとして見ることができます。 ネットワーク内のプロデューサー。「合理的」とは、ペナルティを与える可能性を考慮していない blockchain に対する信頼が低下し、暗号通貨の価値が低下するなどの外部性。 次のコードは、検閲攻撃の実行に使用できる smart contract を示しています。 岩盤の上。この攻撃は、ブロックプロデューサーに賄賂を提供することで、ブロックプロデューサーのインセンティブを悪用します。 州の特定の部分を変更する取引を検閲するため。契約の主な内容 関数、claimBribe を使用すると、ブロックプロデューサーが検閲に成功した場合に賄賂を請求できるようになります。 無効な出力ルートが触れられていないことを確認して、ターゲットのトランザクションを処理します。 functionclaimBribe(バイトメモリ storageProof) 外部 { require(!claimed[block.number], "賄賂はすでに請求されています"); OutputProposal メモリの現在 = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, ストレージプルーフ); require(invalidOutputRoot == current.outputRoot, "攻撃は失敗しました"); 主張[ブロック番号] = true; (ブール送信、 ) = block.coinbase.call{値: 賄賂金額}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(sent, "イー​​サの送信に失敗しました"); } リスト 1: Bedrock に対する検閲攻撃を奨励する契約の例。 紛争期間の長さには、過失の証明が不十分であるという事実も考慮する必要があります。 インタラクティブな証明であるため、参加者が対話するのに十分な時間を提供する必要があります そして、あらゆるやり取りが検閲される可能性があるということです。最後の移動が直前に行われた場合、 紛争期間が終了すると、検閲のコストは大幅に減少します。検閲はあるものの、 ドミナント戦略では、検閲ノードが次の攻撃に対して脆弱であるため、成功の可能性は低くなります。 サービス拒否攻撃: 攻撃者は、次のような非常に複雑なトランザクションを生成する可能性があります。 手数料は支払われないため、欠陥証明の発行は無料で行われます。 極端な場合には、紛争期間が長ければ、解決に成功した場合の調整が可能になります。 フォークを組織し、攻撃しているブロックプロデューサーを排除するための検閲攻撃。もう一つ 攻撃の可能性としては、議論者が検証できる以上に多くのステートルート提案を公開することが挙げられます。 これは周波数制限を使用することで回避できます。 4.1.1.素早い楽観的な出金 オプティミスティック ロールアップの有効性はフル ノードでいつでも検証できるため、 信頼できる oracle を使用すると、出金が安全に完了できるかどうかを L1 で知ることができます。これ このメカニズムは Maker [21] によって最初に提案されました。oracle は引き出しを検証し、 ユーザーに有利子ローンが割り当てられる L1 の結果。これは自動的に実行されます。 7 日間の終わり、つまり実際に出金が完了した時点で締め切りとなります。この解決策 信頼の仮定が導入されていますが、Maker の場合、oracle 演算子があるため最小化されています。 は、融資を提供することでリスクを引き受けるのと同じ組織によって管理されます。 4.2.取引コスト L2 トランザクションのコストは、主に L1 との対話によって決まります。どちらのソリューションでも トランザクションは完全にオフチェーンで実行されるため、トランザクションの計算コストは非常に安価です。 Optimism は、L2 トランザクションの呼び出しデータを呼び出しデータとして公開し、フォルトをほとんど (またはまったく) 実行しません。 したがって、calldata は最も高価なリソースです。 2022 年 1 月 12 日、Bedrock ネットワーク Ethereum の Goerli テストネットで開始されました。ガスの圧縮率を計算できます 一定期間に岩盤上で使用されたガスの量を追跡し、それを過去のガスの量と比較することによって、 対応するブロックの L1 で費やされるガスの量。この方法を使用してガス圧縮 〜20 : 1 の割合が見つかりますが、この数値はメインネット上の実際のアクティビティとは異なる可能性があります。 StarkNet は、L2 状態のすべての変更を呼び出しデータとして Ethereum に公開するため、ストレージは 最も高価なリソース。ネットワークは EVM を使用しないため、トランザクション コストは 圧縮率を自明に見積もることはできません。実行コストと呼び出しデータを想定すると、 無視できるほど、ストレージ書き込みの圧縮率を計算することができます。 L1。コントラクトが展開されておらず、StarkNet で以前にアクセスされていない 10 個のセルが存在すると仮定します。 変更すると、ストレージ書き込みコスト圧縮率は約 24:1 であることがわかります。セルが上書きされた場合 データ公開間の𝑛回、各書き込みのコストは、以前のコストと比較して 1/𝑛 になります。 最後の書き込みのみが公開されるため、1 回の書き込みで済みます。コストをさらに抑えることができるのは、頻繁に使用される値を圧縮します。有効性証明検証の費用は次のとおりに分割されます。 参照するトランザクション: たとえば、StarkNet ブロック 4779 には 200 個のトランザクションが含まれており、その 有効性証明には 267830 ユニットのガス、つまりトランザクションごとに 1339.15 ガスが消費されます。 4.2.1.コールデータの最適化: キャッシュ コントラクト 以下に示すのは、頻繁に使用されるアドレス キャッシュを実装する smart contract です。 ストレージと実行のコストがはるかに低いという事実を利用して対処します リソースとその使用法を示す Friends 契約。後者は、 addFriend関数を呼び出すことで登録できるアドレスの「友達」。住所の場合 すでに少なくとも 1 回使用されている場合は、addFriendWithCache を呼び出すことで追加できます。 機能: キャッシュ インデックスは 4 バイトの整数ですが、アドレスは 20 バイトで表されます。 したがって、関数の引数は 5:1 で節約されます。同じロジックを他のデータにも使用できます 整数やより一般的にはバイトなどの型。 コントラクト AddressCache { マッピング(アドレス => uint32) パブリックアドレス2キー; アドレス[]公開鍵2アドレス; 関数cacheWrite(address _address)内部戻り値(uint32) { require(key2address.length < type(uint32).max, "AddressCache: キャッシュがいっぱいです"); require(address2key[_address] == 0, "AddressCache: アドレスはすでにキャッシュされています"); // 0 は「見つからない」ことを意味するため、キーは 1 から開始する必要があります uint32 キー = uint32(key2address.length + 1); address2key[_address] = キー; key2address.push(_address); リターンキー; } 関数cacheRead(uint32 _key)パブリックビューは(アドレス)を返します{ require(_key <= key2address.length && _key > 0, "アドレスキャッシュ: キーが見つかりません"); キー 2 アドレスを返します [_key - 1]; } } リスト 2: アドレス キャッシュ コントラクト。 コントラクトフレンドはAddressCache { マッピング(アドレス => アドレス[]) 公開友達; 関数 addFriend(アドレス _friend) public { friends[msg.sender].push(_friend); キャッシュ書き込み(_friend); } 関数 addFriendWithCache(uint32 _friendKey) public { friends[msg.sender].push(cacheRead(_friendKey)); } function getFriends() public view returns (address[]memory) { 友達を返す[msg.sender];} } リスト 3: アドレス キャッシュを継承するコントラクトの例。 この契約はキャッシュ内で約 40 億 (232) のアドレスをサポートしており、1 バイトを追加すると次のようになります。 約1兆（240）個。 4.2.2.ストレージの最適化: Bloom のフィルター StarkNet には、ストレージの使用量を最小限に抑えるための手法がいくつかあります。必要がない場合は、 元のデータの可用性を保証する場合は、その hash をオンチェーンに保存するだけで十分です。 ERC-721 (NFT) [22] のデータを保存するために使用されるメカニズムです。つまり、 利用可能な場合はデータの hash。複数回保存されたデータの場合は、ルックアップを使用できます。 Optimism に導入されたキャッシュ システムに似たテーブル。すべての値を次の場所に保存する必要があります。 少なくとも一度は。一部のアプリケーションでは、ブルーム フィルターを使用することですべての値の保存を回避できます。 [23, 24, 25]、つまり、次のことを確実に知ることができる確率的データ構造。 要素はセットに属していませんが、小さいながらも無視できない false の確率を許容します。 ポジティブ。 ブルーム フィルターは、ゼロの 𝑚 ビットの配列として初期化されます。要素を追加するには、𝑘hash 関数を使用します 一様なランダム分布を持つものが使用され、それぞれが設定された配列のビットにマッピングされます。 要素がセットに属しているかどうかを確認するには、𝑘hash 関数を実行して検証します。 単純なブルームフィルターでは、𝑘ビットが1に設定されているかどうかを区別する方法はありません。 要素が実際にセットに属しているか、偽陽性であるか、その確率は数に応じて増加します。 エントリ数が増加します。 𝑛要素を挿入した後: P[偽陽性] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 各ビットセットの確率が独立していると仮定します。 𝑛要素 (任意のサイズ!) が が含まれることが期待され、許容される偽陽性の確率は配列のサイズ 𝑝 です。 は次のように計算できます。 𝑚= −𝑛ln 𝑝 (ln 2)2 hash 関数の最適な数は次のとおりです。 𝑘= 𝑚 𝑛ln 2 許容誤差 1% で 1000 個の要素を挿入すると仮定すると、配列のサイズは 9585 ビットになります。 𝑘= 6 の場合、0.1% の許容誤差の場合、𝑘= 9 では 14377 ビットになります。要素が 100 万個の場合 が挿入されることが予想される場合、配列のサイズは 1% の場合は約 1170 KB、1% の場合は 1775 KB になります。 𝑝[26] のみに依存するため、𝑘 の値が同じ場合は 0.1%。 すでに挑戦した相手にプレイヤーを割り当ててはいけないゲームでは、 各プレイヤーの過去の対戦相手のリストをストレージに保存する代わりに、ブルームを使用できます。 フィルター。一部のプレイヤーに挑戦しないリスクは多くの場合許容され、フィルターはリセットできます。 定期的に。4.3. Ethereum 互換性 EVM および Ethereum と互換性があることの主な利点は、利用可能なすべてのコンポーネントを再利用できることです。 ツール。 Ethereum smart contract は、変更を加えずに Optimism で公開できます。 新しい監査。ウォレットの互換性維持、開発および静的分析ツール、一般的な分析 ツール、インデックス作成ツール、oracle。 Ethereum と Solidity には、十分に研究されてきた長い歴史があります。 再入攻撃、オーバーフローとアンダーフロー、フラッシュ ローン、oracle などの脆弱性 操作。このため、Optimism は短期間で大量の価値を獲得することができました。 時間。 別の仮想マシンを採用するという選択は、エコシステム全体を再構築する必要があることを意味します。 実装の自由度が高まるという利点があります。 StarkNet アカウントをネイティブに実装します 抽象化。各アカウントを smart contract として実装できるメカニズムです。 インターフェイスに準拠している限り、任意のロジック (したがって抽象化という用語が使われます): これにより、 さまざまなデジタル署名スキームの使用、秘密キーを使用して秘密キーを変更する機能 同じアドレスを使用するか、マルチシグを使用します。 Ethereum コミュニティがこれの導入を提案しました 2020 年に EIP-2938 のメカニズムが確立されましたが、この提案は 1 年以上古いままでした。 他の更新には、[27] の方が優先されます。 互換性から得られるもう 1 つの重要な利点は、既存のクライアントの再利用です: Optimism は、わずか約 800 行の違いがある独自のノードに geth のバージョンを使用します。 2014 年以来、開発、テスト、保守が行われています。堅牢なクライアントを持つことが重要です。 ネットワーク内で何が有効か無効として受け入れられるか。フォールトプルーフの実装におけるバグ システムにより、間違った証明が正しい証明として受け入れられたり、無効な証明が正しい証明として受け入れられたりする可能性があります。 ブロックが不正なものとして受け入れられ、システムが危険にさらされる可能性があります。このタイプの可能性は より幅広いクライアントの多様性により攻撃を制限できます: Optimism は取得に加えて再利用できます。 他の Ethereum クライアントはすでに保守されており、別の Erigon ベースのクライアントの開発が行われています。 すでに進行中です。 2016 年に、geth のメモリ管理の問題が悪用されました。 DoS 攻撃と防御の第一線は、2 番目に多いパリティの使用を推奨することでした。 当時使用されていたクライアント 5. StarkNet は有効性証明に関して同じ問題に直面していますが、クライアントは スクラッチから作成する必要があり、証明システムははるかに複雑になり、その結果、 また、正確性を保証するのははるかに複雑です。

خاتمة

  1. الاستنتاج تعد المجموعات المجمعة هي الحل الواعد المتاح اليوم لحل مشكلة قابلية التوسع في اللامركزية blockchains، مما يمهد الطريق لعصر blockchains المعيارية بدلاً من متجانسة blockchains. يظهر بشكل أساسي اختيار تطوير مجموعة متفائلة أو مجموعة صلاحية كمفاضلة بين التعقيد وخفة الحركة. يتمتع StarkNet بالعديد من المزايا مثل السرعة عمليات السحب، وعدم القدرة الهيكلية على التحولات غير الصالحة للحالة، وانخفاض تكلفة المعاملات في حساب فترة تطوير أطول وعدم التوافق مع EVM، بينما Optimism لديه استفادت من اقتصاد الشبكة للحصول بسرعة على حصة كبيرة من السوق. Optimism ومع ذلك، يمتلك Bedrock تصميمًا معياريًا يسمح له بأن يصبح صالحًا 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

مجموعة التحديثات في المستقبل: يستخدم Cannon حاليًا برنامج minigeth المترجم إلى MIPS لإثبات الأخطاء النظام، ولكن يمكن استخدام نفس البنية للحصول على دائرة وإنتاج إثباتات الصلاحية. يؤدي تجميع جهاز معقد مثل EVM للهندسة المعمارية الدقيقة إلى عملية أبسط الدائرة التي لا تحتاج إلى تعديل وإعادة التحقق منها في حالة الترقية. RISC صفر هو بنية دقيقة يمكن التحقق منها مع أدلة STARK قيد التطوير بالفعل بناءً على RISC-V ذلك يمكن استخدامه لهذا الغرض كبديل لـ MIPS [28]. أحد الجوانب التي لا ينبغي الاستهانة بها هو التعقيد في فهم كيفية تعمل التكنولوجيا. تتمثل قوة blockchains التقليدية في القدرة على التحقق من حالة blockchain دون الثقة في أي كيان خارجي. ومع ذلك، في حالة StarkNet، فهو كذلك من الضروري الثقة في التنفيذ عندما لا يكون من الممكن التحقق من المكونات المختلفة على أساس التشفير والرياضيات المتقدمة. قد يؤدي هذا في البداية إلى خلق احتكاك لـ اعتماد التكنولوجيا، ولكن مع تقدم الأدوات واستخدام البراهين النزاهة خارج الحقل blockchain نأمل أن يتم حل هذه المشكلة.

結論

  1. 結論 ロールアップは、スケーラビリティの問題を解決するために現在利用できる最も有望なソリューションです。 分散型 blockchain は、モジュール型 blockchain の時代への道を開きます。 モノリシックblockchain。 主に、楽観的ロールアップまたは妥当性ロールアップのどちらを開発するかの選択が示されています。 複雑さと機敏性の間のトレードオフとして。 StarkNet には、高速などの多くの利点があります。 引き出し、無効な状態遷移が構造的に不可能であること、取引コストが低いこと 開発期間が長くなり、EVM との互換性がないため、Optimism は ネットワーク経済を活用して、市場で急速に大きなシェアを獲得しました。 Optimism ただし、Bedrock は、Validity になることを可能にするモジュラー設計を備えています。 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

将来のロールアップ: Cannon は現在、フォールトプルーフのために MIPS にコンパイルされた minigeth を使用しています システムですが、同じアーキテクチャを使用して回路を取得し、有効性証明を作成することができます。 EVM などの複雑なマシンをマイクロアーキテクチャ用にコンパイルすると、より単純になります。 アップグレードの場合に回路を変更したり再検証したりする必要がありません。 RISCゼロは、 RISC-V に基づいてすでに開発中の STARK 証明を備えた検証可能なマイクロアーキテクチャ MIPS [28] の代わりに、この目的に使用できます。 過小評価すべきではない側面の 1 つは、どのようにして、 テクノロジーは機能します。従来の blockchain の強みは、状態を確認できることです。 第三者エンティティを信頼せずに blockchain を実行します。ただし、StarkNet の場合は、 さまざまなコンポーネントを検証できない場合に実装を信頼する必要がある 暗号化と高度な数学に基づいています。これにより、最初は摩擦が生じる可能性があります。 テクノロジーの導入は進んでいますが、完全性証明のツールと使用法が進歩するにつれて、 blockchain フィールドの外では、この問題は解決されることが期待されます。