filefilego
v1.4.3
بروتوكول FileFilego هو شبكة تخزين وتبادل البيانات من نظير إلى نظير مصممة لعصر Web3 ، مع آلية الحوافز ، والبحث عن النص الكامل ومحرك تخزين. تمكن بنية اللامركزية للمستخدمين من تخزين البيانات ومشاركتها دون رقابة أو نقطة فشل واحدة. من خلال الاستفادة من مفاهيم نظرية اللعبة ، يحفز FileFilego المشاركة ويضمن توفر البيانات مع تحقيق التسامح مع الأخطاء والحفاظ على الخصوصية.
FileFilego هو مشروع مجتمعي مفتوح المصدر ، مع عدم وجود سيطرة أو ملكية مركزية. تم تصميم توزيع العملة المعدنية ليكون عادلاً ، مع انبعاث 40 FFG لكل كتلة تنخفض بمقدار نصف كل 24 شهرًا. يتم إطلاق البروتوكول بدون ICO/STO/IEO أو قبل Mine ، بالاعتماد على دليل على خوارزمية إجماع السلطة التي ستنتقل في النهاية إلى إثبات الحصة للسماح لمزيد من أصحاب المصلحة بالمشاركة.
من خلال دعم FileFilego ، يمكن للمستخدمين المساعدة في تعزيز الحقوق الرقمية والخصوصية وحرية المعلومات والحياد الصافي. نحن نشجع المساهمات والأفكار المبتكرة لضمان أن الإنترنت لا يزال منصة مفتوحة وغير مركزية.
دعنا نفترض أن node_1 يحتاج إلى تنزيل بعض data_x ، المملوكة لـ node_2 ، ودفع الرسوم المطلوبة بواسطة node_2 . ماذا يحدث في حالة العقد الصدع البيزنطية؟ كيف نتحقق من نقل البيانات الناجح إلى العقد المقصد ومنع الحالات الخبيثة التالية:
node_1 هي عقدة غير شريفة تقارير data_x على أنها غير صالحة ، لتجنب دفع الرسوم.node_2 هي عقدة غير شريفة تخدم data_y إلى node_1 وتزعم أنها data_x . يمكن للشبكة أن تقاوم أخطاء البيزنطية إذا تمكنت node_x من بث (نظير إلى نظير) قيمة x ، وتلبية ما يلي:
node_x عقدة صادقة ، فإن جميع العقد الصادقة تتفق على القيمة x. تتناول آلية إثبات النقل المشكلات المذكورة أعلاه من خلال تمكين العقد الصادقة في الشبكة من التحقق من الإجماع والوصول إلى الإجماع على النقل الناجح data_x من node_2 إلى node_1 . يتم تحقيق ذلك من خلال استخدام التحقق ، المسؤولون عن تحدي العقد المشاركة. على الرغم من أن النهج المباشر سيتضمن إرسال البيانات المطلوبة إلى التحقق ومن ثم إعادة توجيهها إلى عقدة الوجهة ، فإن هذه الطريقة يمكن أن تؤدي إلى اختناقات النطاق الترددي والتخزين ، مما يقلل من إنتاجية الشبكة الإجمالية. لذلك ، تم تصميم حل دليل النقل لتقليل متطلبات النطاق الترددي ومتطلبات التخزين/الذاكرة المرتبطة بهذه العملية.
┌───────────┐
┌────────►[verifiers]◄─────────┐
│ └───────────┘ │
┌────┴───┐ ┌────┴───┐
│ │ │ │
│ node_1 ◄─────────────────────► node_2 │
│ │ │ │
└────────┘ ├────────┤
│ data_x │
└────────┘
يترك
قسّم محتوى الملف
احسب تجزئة شجرة Merkle من الأجزاء: دع
خلط الأجزاء: دع
تشفير 1 في المئة من الأجزاء المخلوط: دع
فك تشفير الأجزاء المشفرة: لكل من
استعادة الترتيب المخلل: نظرًا لأن الأجزاء تم خلطها أثناء عملية التشفير ، فيجب استعادتها إلى ترتيبها الأصلي باستخدام التقليب العكسي
حساب تجزئة شجرة Merkle: إعادة حساب تجزئة شجرة Merkle من الأجزاء التي تم فك تشفيرها بالترتيب المستعاد. قم ببناء شجرة التجزئة بشكل مشابه للبناء الأصلي ، ولكن استخدم الأجزاء التي تم فك تشفيرها
أخيرًا ، تجزئة جذر Merkle الأصلي المشتق
يتم تحقيق الإجماع إذا كان تجزئة جذر Merkle المشتقة يطابق تجزئة جذر Merkle الأصلي.
النظر في سيناريو يتضمن ملفًا يحتوي على المحتوى اللاحق:
FileFileGo_Network
عند تحميل ملف إلى مزود تخزين ، يتم حساب تجزئة جذر Merkle للملف من خلال تجزئة محتواه إلى قطاعات بيانات مميزة.
يصور التوضيح الذي تلا ذلك مظهرًا مبسطًا لترتيب الملف على وسط التخزين. يرمز كل مربع فردي داخل الرسم التوضيحي إلى 1 بايت من البيانات.
┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┐
│ F │ i │ l │ e │ F │ i │ l │ e │ G │ o │ _ │ N │ e │ t │ w │ o │ r │ k │
└───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┘
للعثور على تجزئة جذر Merkle لهذا الملف ، نقوم بتقسيم الملف إلى أجزاء أصغر. على سبيل المثال ، دعنا نقسم الملف إلى تسعة أقسام ، وسيكون لكل جزء بايتان فقط.
0 1 2 3 4 5 6 7 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ F i │ l e │ F i │ l e │ G o │ _ N │ e t │ w o │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
الآن نأخذ تجزئة كل مقطع:
segment 0: hash("Fi"), denoted by h0
segment 1: hash("le"), denoted by h1
segment 2: hash("Fi"), denoted by h2
segment 3: hash("le"), denoted by h3
segment 4: hash("Go"), denoted by h4
segment 5: hash("_N"), denoted by h5
segment 6: hash("et"), denoted by h6
segment 7: hash("wo"), denoted by h7
segment 8: hash("rk"), denoted by h8
ثم نحسب تجزئة جذر Merkle للملف عن طريق تطبيق الخوارزمية.
إليك مثال على كيفية عمل هذه الخوارزمية:
┌───┬───┬───┬───┬───┬───┬───┬───┐
Data Blocks:│ a │ b │ c │ d │ e │ f │ g │ h │
└───┴───┴───┴───┴───┴───┴───┴───┘
0 1 2 3 4 5 6 7
│ │ │ │ │ │ │ │
└───┘ └───┘ └───┘ └───┘
h01 h23 h45 h67
│ │ │ │
└───────┘ └───────┘
h(h01+h23) h(h45+h67)
│ │
│ │
└───────────────┘
Merkle root: h(h(h01+h23)+h(h45+h67))
الآن ، لدينا تجزئة جذر Merkle للملف ، ممثلة باسم MT (F) ، والتي هي أساسا قيمة التجزئة الأخرى.
عندما يصل طلب لاسترداد البيانات إلى موفر تخزين ، يقوم الموفر بإعادة ترتيب شرائح البيانات بترتيب عشوائي. على سبيل المثال ، ضع في اعتبارك تسلسل شرائح البيانات:
random segments [ 1, 5, 2, 4, 7, 6, 3, 0, 8 ] ، والتي تترجم إلى الترتيب التالي:
1 5 2 4 7 6 3 0 8
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ G o │ w o │ e t │ l e │ F i │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
بعد ذلك ، يقوم المزود بإنشاء مفتاح متماثل ومتجه تهيئة (IV) لتشفير جزء من هذه الأجزاء. في هذا التوضيح ، سنختار تشفير 25 ٪ من القطاعات ، والتي تعادل قطاعين. علاوة على ذلك ، سنقوم بتشفير كل 4 قطاعات ، مما يعني ضمناً أننا سنشفر الجزءين من 0 و 4:
25% Segment Encryption = 2 segments
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ l e │ _ N │ F i │ * * │ w o │ e t │ l e │ * * │ r k │
└───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘
الآن ، سيتم توفير البيانات المذكورة أعلاه إلى طلب البيانات. في نفس الوقت ، يتم إرسال المفتاح/الرابع ، والترتيب العشوائي للقطاعات ، ومحتويات الأجزاء 0 و 4 إلى data verifier . من المهم أن يسلط الضوء على أن التنزيل يمتلك Zero-Knowledge فيما يتعلق بترتيب القطاعات داخل الملف ومفتاح التشفير/IV.
قد تكون قلقًا بشأن إمكانية إنشاء شخص ما لمحاولة مجموعات مختلفة من الأجزاء لتحديد الترتيب الأصلي ، مما قد يؤدي إلى ثغرة أمنية وهجوم محتمل.
لتوفير مزيد من البصيرة ، ضع في اعتبارك أن ملفًا مقسومًا إلى ما يقرب من 1024 قطعة (أو أقل قليلاً) في سيناريو في العالم الحقيقي ، ثم يتم اختيار هذه الأجزاء العشوائية. لكي يقوم المهاجم بإعادة بناء ترتيب القطاع الأصلي ، سيحتاجون إلى تنفيذ "التقليب دون تكرار". يتم تقديم العدد الكلي للطرق لترتيب مقاطع الملفات هذه بواسطة N! (عازف) ، والذي يصل إلى 1024! في هذه الحالة. (https://coolconversion.com/math/factorial/what-is-the-factorial-of_1024_٪3f)
تتضمن الخطوة اللاحقة للمهاجم محاولة الحصول على المفتاح والرابع المستخدمين في تشفير الجزءين. ومع ذلك ، تجدر الإشارة إلى أن هذه المهمة تعتبر حاليًا مستحيلة بناءً على نقاط الضعف الحالية في هذا المجال.
باتباع ذلك ، يجب على تنزيل الملف أن يطلب مفتاح التشفير/IV والترتيب العشوائي لقطاعات الملفات من data verifier مخصصة داخل الشبكة.
يرسل تنزيل البيانات طلبًا إلى Verifier Data ، ويبحث عن مفتاح التشفير/IV والشرائح العشوائية. يرافق هذا الطلب تجزئة القطاع للملف الذي تم تنزيله ، والذي يتم تقديمه على النحو التالي:
h1
h5
h2
h(enc(4))
h7
h6
h3
h(enc(0))
h8
يتعهد data verifier بالتشفير والتجزئة للقطاعات 0 و 4 ، مما يؤدي إلى قيم التجزئة التالية:
h1
h5
h2
h4
h7
h6
h3
h0
h8
أخيرًا ، يعيد data verifier تنظيم الأجزاء وفقًا للترتيب العشوائي الذي تم إنشاؤه بواسطة Hoster الملف أثناء نقل البيانات إلى الطالب. تعطي هذه العملية التسلسل الأصلي لتجزئة القطاع:
h0
h1
h2
h3
h4
h5
h6
h7
h8
في نهاية المطاف ، من خلال تنفيذ حساب تجزئة الجذر Merkle ، يستنتج التحقق من البيانات تجزئة جذر Merkle الأصلي دون الحاجة إلى الوصول المحلي الكامل إلى محتوى الملف بأكمله.
عند التأكيد على أن تجزئة جذر Merkle المشتقة تتطابق مع النسخة الأصلية ، أنشأنا بشكل فعال دليلًا رياضيًا على أن تنزيل البيانات يمتلك جميع البيانات المطلوبة. بعد ذلك ، يقوم Verifier Data بنقل مفتاح التشفير/IV وتطلب الأجزاء العشوائية إلى تنزيل البيانات ، مما يؤدي إلى الإصدار التلقائي للرسوم إلى Hoster.
في هذا القسم ، يتم توضيح دورة الحياة الكاملة للتحقق من نقل البيانات.
1. Data Query Request
┌───────┐
┌───────────────►[nodes]├───────────────┐
│ └───────┘ │
┌───┴────┐ ┌────▼───┐
│ │ │ │
│ node_1 │ │ node_2 │
│ │ │ │
└───▲────┘ └───┬────┘
│ 2. Data Query Response │
└──────────────────────────────────────┘
Data Query Response على جميع المعلومات اللازمة لإعداد معاملة العقد الذكي. ثم يتم بث هذه المعاملة إلى الشبكة التي يتم تحديدها بعد ذلك بواسطة التحقق. ┌──────────────────────────────────────┐
│ TRANSACTION │
├──────────────────────────────────────┤
│ Data : │
│ - Data query response │
│ - Remote node signature │
│ Value: │
│ - Fees required by node │
│ │
│ Fees : │
│ - Fees collected by verifier │
│ │
│ To : │
│ - Network verifier │
└──────────────────────────────────────┘
v1 ) مع العقد المشاركة ويولد تحديًا للعقدة التي تستضيف البيانات ( node_2 ). يتكون التحدي من الخطوات التالية:node_2 بإنشاء شجرة Merkle التي تتطابق مع جذر Merkle الأصلي لـ data_x تم تحميله في المقام الأول.v1 الترتيب وعدد الكتل/نطاقات البيانات المراد إرسالها إلى node_1 بواسطة node_2 . لا نريد الكشف عن ترتيب الكتل إلى node_1 حتى الآن.v1 node_2 عن نطاق ثابت من البيانات ، والذي سيتم تشفيره باستخدام مفتاح عشوائي k1 كـ data_enc بواسطة v1 وإرساله إلى node_1 . في هذه المرحلة ، تمتلك node_1 بعض data_z و data_enc ولكنها تفتقر إلى معرفة كيفية الجمع بينها للحصول على الملف الأصلي. يمكن لـ Verifier ، V1 ، التحقق من سلامة البيانات المنقولة إلى node_1 ، وإذا كانت تتطابق مع هوية Merkle Tree الأصلية ، يتم توفير مفتاح فك التشفير K1 إلى node_1 . بالإضافة إلى ذلك ، يتم إرسال ترتيب الكتلة إلى node_1 ، مما يتيح إعادة تجميع جميع الأجزاء لتشكيل البيانات الأصلية. بمجرد اكتمال هذه العملية ، تصدر V1 الرسوم إلى node_2 .
يمكّن استخدام هذه الخوارزمية من التحصيل المتزامن لإثبات النقل وإثبات حيازة البيانات.
اتبع الإرشادات لتجميع وتثبيت FileFilego
https://filefilego.com/documentation/docs/installation.html#prerequisites
FileFilego هي شبكة لا مركزية تتضمن متانة blockchain/cryptocurrency ، DHT ، وتكنولوجيا BitTorrent المبتكرة لتشكيل بنية تحتية لا يمكن إجراؤها.
لتحقيق وقت كتلة من 10 ثوان ، تتطلب FileFilego خوارزمية الإجماع التي تكون فعالة في معالجة حجم كبير من المعاملات ويحفظ قوة المعالجة. بالنسبة للمرحلة الأولية ، اخترنا إثبات السلطة (POA) كخوارزمية إجماعنا. في المستقبل ، ستحل آلية إثبات الحصة (POS) محل الخوارزمية الحالية.
إن استخدام الخوارزميات المستندة إلى POW لـ Blockchains الجديدة يشكل خطرًا ، حيث توجد بالفعل تجمعات كبيرة من قوة الحوسبة المتاحة التي يمكن استخدامها في هجمات 51 ٪. لذلك ، اخترنا POA ، وهو آمن حسب التصميم ويوفر الكفاءة اللازمة لدعم متطلبات حجم المعاملات العالية.
يتم ترميز هويات المدققين في blockchain ويمكن التحقق منها من خلال فحص معاملة Coinbase الخاصة بكتلة Genesis. يمكن للعقد المشاركة التحقق من صحة هذه الهويات بسهولة عن طريق التحقق من توقيعات الكتلة.
مع تقدمنا للأمام ، سيتم استبدال آلية POA الحالية بإثبات التمكين لتمكين أطراف متعددة من المشاركة في عملية تعدين الكتلة. هدفنا في حوكمة blockchain هو تشجيع المزيد من الأحزاب والمطورين على المشاركة وزيادة مشاركة أصحاب المصلحة. أحد الحوافز لتحقيق هذا الهدف هو آلية إثبات الرصاص.
لتبسيط المعاملة وطفرة الحالة ، يتبنى FileFilego نهجًا مختلفًا عن الهياكل التي تشبه UTXO. بدلاً من استخدام مثل هذه الهياكل ، نقوم بتخزين المحاسبة والبيانات الوصفية كصفوف قاعدة بيانات منتظمة ، مع الحفاظ على الكتل الأولية بتنسيقها الأصلي داخل قاعدة البيانات. هذا النهج يساعد على القضاء على التعقيد غير الضروري.
في هذا القسم ، سنقدم نظرة عامة على المصطلحات والمفاهيم الفنية المستخدمة في FileFileGo.
تمكن القنوات في FileFilego المستخدمين من تنظيم وتجميع البيانات في دلاء أو مجلدات مميزة. على سبيل المثال ، يمكن وضع جميع المحتوى على ubuntu.com في قناة تدعى "Ubuntu Official." يتلقى المستخدم الذي ينشئ قناة جميع الأذونات اللازمة للتحديثات والعمليات الأخرى المتعلقة بالقنوات.
يتم تنظيم القنوات بتنسيق سلسلة العقدة ويمكن تحديدها على أنها عقدة بدون ParentHash .
مفهوم القناة الفرعية هو أن تكون قادرًا على تصنيف البيانات بشكل أكبر. على سبيل المثال ، المستندات أو الصور أو الموسيقى.
في FileFilego ، يمثل Entry منشورًا أو جزءًا من البيانات التي تحتوي على مزيد من المعلومات حول الإدخال نفسه بدلاً من التصنيف/الطلب. يمكن وضع File Directory في Entry .
Storage Engine هو طبقة التخزين التي تتبع البيانات الثنائية ، والتي تستخدمها مؤشرات التجزئة داخل blockchain للإشارة إلى جزء من البيانات. يحتوي بنية NodeItem على حقل يسمى FileHash والذي يشير إلى التجزئة الثنائية وهو في شكل "{HASH_ALGORITHM}:>{DATA_HASH}" . نود الاحتفاظ بالبيانات الوصفية لخوارزمية التجزئة المستخدمة كما قد تكون مفيدة في المستقبل.
في FileFilego ، تعتبر دقة البحث والمرونة بنفس القدر من الأهمية كوظيفة blockchain الأساسية. نهدف إلى تمكين المستخدمين من بناء استعلامات معقدة ، بما في ذلك عمليات البحث الثنائية ، باستخدام لغة استعلام محددة. على سبيل المثال ، يجب أن تكون استفسارات الأنواع التالية ممكنة:
يعد تطوير لغة استعلام تدعم مثل هذه الاستعلامات المعقدة أداة قوية يمكن أن تعزز دقة محرك البحث بشكل كبير.
من الممكن أيضًا تمكين وظيفة فهرسة النص الكامل للعقدة باستخدام علامة CLI --search .
تقوم طبقة التخزين بتتبع الملفات الثنائية وتستخدم تجزئة لتمثيل جزء من المعلومات داخل blockchain. يمكن تشغيل هذه الميزة باستخدام الأعلام التالية:
... --storage --storage_dir="/somewhere/to/store/data" --storage_token="somelongtokenhere" --storage_fees_byte="10000" ...
-يجب أن يكون --storage_dir دليلًا موجودًا مع أذونات القراءة/الكتابة المناسبة. يرجى ملاحظة أن العقد الكاملة يمكن أن تعمل بدون هذه الآلية. storage_token هو رمز يمنح حقوق المسؤول لرمز رمز حتى يتمكن من إنشاء رموز أخرى باستخدام API HTTP. يكون هذا مفيدًا عند الحاجة إلى الوصول إلى اليمين بواسطة تطبيقات الويب أو المستخدمين المتميزين و --storage_fees_byte="10000" هي الرسوم التي يتم شحنها لكل بايت من البيانات.
| وحدة | قيمة |
|---|---|
| ffgone | 1 |
| KFFG | 1.000 |
| MFFG | 1.000.000 |
| GFFG | 1.000.000.000 |
| microffg | 1.000.000.000.000 |
| ميليفج | 1.000.000.000.000.000 |
| FFG (الوحدة الافتراضية) | 1.000.000.000.000.000.000 |
| ZFFG | 1.000.000.000.000.000.000.000 |
إجمالي العرض: 500 مليون مكافأة/مكافأة FFG: 40 FFG لكل كتلة انخفاض المعدل: قسمة على 2 كل 24 شهرًا
