diff --git a/ar-AR/TechnicalWhitePaper.md b/ar-AR/TechnicalWhitePaper.md new file mode 100644 index 00000000..b0e62e0a --- /dev/null +++ b/ar-AR/TechnicalWhitePaper.md @@ -0,0 +1,482 @@ +
+ +# الورقة البيضاء التقنية لـEOSIO الإصدار الثاني + +**١٦ مارس ٢٠١٨** + +**نُبذة:** +تقدم برمجيات EOSIO بنية جديدة للبلوكتشين مصممة لتمكين التوسّع الرأسي والأفقي للتطبيقات اللامركزية (vertical and horizontal scaling). ويتحقق ذلك بواسطة إنشاء بنية شبيهة بنظام التشغيل يمكن بناء التطبيقات عليها. يوفر البرنامج ما يلي من حسابات ومصادقة وقواعد بيانات واتصالات غير متزامنة (accounts, authentication, databases, asynchronous communication) وجدولة للتطبيقات عبر العديد من مراكز أو وحدات المعالجة المركزية. التقنية الناتجة عن هذا هي بنية للبلوكتشين التي يمكنها التوسع لتصل في النهاية إلى ملايين المعاملات في الثانية، وكذلك يمكنها إلغاء رسوم المستخدم كما تسمح بالتطوير السريع والسهل وصيانة التطبيقات اللامركزية، وكل هذا يأتي في سياق بلوكتشين خاضع للحوكمة. + +**يٌرجى ملاحظة التالي: الرموز المشفرة المشار إليها في هذه الورقة البيضاء تشير إلى الرموز المشفرة على بلوكتشين سبق إطلاقه بالفعل ويتبنى برنامج EOS.IO. ولا تشير إلى الرموز المميزة ERC-20 التي تُوزع على بلوكتشين الإيثريوم فيما يتصل بتوزيع رموز EOS.** + +حقوق الطبع والنشر © 2018 block.one + +يجوز لأي شخص - بدون إذن- استخدام أي مواد في هذه الورقة البيضاء أو إعادة إنتاجها أو توزيعها للاستخدام غير التجاري والتعليمي (أي بدون رسوم أو دون الاستخدام لأغراض تجارية) شريطة ذكر المصدر الأصلي وإشعار حقوق الطبع والنشر المعمول بهما. + + +**إخلاء مسؤولية::** هذا الإصدار الثاني من الورقة البيضاء التقنية عن برنامج EOS.IO لأغراض المعلومات فقط. لا تضمن "Block.One" الدقة أو الاستنتاجات المتوصل إليها في هذه الورقة البيضاء، وتُقدّم هذه الورقة البيضاء "كما هي". لا تقدم "Block.One" أي تعهدات أو ضمانات صريحة أو ضمنية أو قانونية أو غير ذلك وتؤكد عدم مسئوليتها، على سبيل المثال لا الحصر: (1) ضمانات صلاحية العرض في السوق أو الملاءمة لغرض معين أو مناسبتها أو استعمالها أو ملكيتها أو عدم الانتهاك؛ (2) أن محتويات هذه الورقة البيضاء خالية من الخطأ؛ و (3) أن هذه المحتويات لن تنتهك حقوق الأطراف الثالثة. لا تتحمل شركة "block.one" والشركات التابعة لها أي مسئولية عن الأضرار من أي نوع تنشأ عن الاستخدام أو الإشارة إلى أو الاعتماد على هذه الورقة البيضاء أو أي من المحتويات الواردة في هذه الوثيقة ، حتى لو سبق إبلاغها باحتمال وقوع مثل هذه الأضرار. لا تتحمل شركة "block.one" أو جهة تابعة له بأي حال من الأحوال المسئولية تجاه أي شخص أو جهة عن أي أضرار أو خسائر أو التزامات أو تكاليف أو نفقات من أي نوع سواء كانت مباشرة أو غير مباشرة أو تبعية أو تعويضية أو عرضية أو فعلية أو نموذجية أو تأديبية أو خاصة لاستخدام ما أو الإشارة إلى أو الاعتماد على هذه الورقة البيضاء أو أي من المحتويات الواردة هنا، بما في ذلك دون حصر: أي خسارة في الأعمال التجارية والإيرادات والأرباح والبيانات والاستخدام والسمعة التجارية أو غيرها من الخسائر غير الملموسة. + + + + + +- [الخلفية (Background)](#الخلفية-background) +- [متطلبات تطبيقات البلوكتشين (Requirements for Blockchain Application)](#متطلبات-تطبيقات-البلوكتشين-requirements-for-blockchain-applications) + * [دعم الملايين من المستخدمين (Support Millions of Users)](#دعم-الملايين-من-المستخدمين-support-millions-of-users) + * [الاستخدام المجاني (Free Usage)](#الاستخدام-المجاني-free-usage) + * [سهولة الترقيات ومعالجة الأخطاء (Easy upgrades and Bug Recovery)](#سهولة-في-الترقيات-ومعالجة-الأخطاء-easy-upgrades-and-bug-recovery) + * [التأخر المنخفض (Low Latency)](#التأخر-المنخفض-low-latency) + * [الأداء المتسلسل (Sequential Performance)](#الأداء-المتسلسل-sequential-performance) + * [الأداء والمعالجة المتوازية (Parallel Performance)](#المعالجة-المتوازية-parallel-performance) +- [خوارزمية الإجماع \(BFT-DPOS\) (DPOS) (Consensus Algorithm)](#خوارزمية-الإجماع-consensus-algorithm-bft-dpos) + * [تأكيد المعاملة (Transaction Confirmation)](#تأكيد-المعاملة-transaction-confirmation) + * [إثبات الحصة بالمعاملة \(TaPoS\) (Transaction as Proof of Stake, TaPoS)](#إثبات-الحصة-بالمعاملة-transaction-as-proof-of-stake-tapos) +- [الحسابات (Accounts)](#الحسابات-accounts) + * [الإجراءات والمناولة (Messages & Handlers)](#الإجراءات-والمناولة-actions--handlers) + * [إدارة الأذونات وفقًا للأدوار (Role Based Permission Management)](#إدارة-الأذونات-وفقًا-للأدوار-role-based-permission-management) + + [مستويات الأذونات المدرجة (Named Permission Levels)](#مستويات-الأذونات-المُدرجة-named-permission-levels) + + [تخطيط الأذونات (Permission Mapping)](#تخطيط-الأذونات-permission-mapping) + + [تقييم الأذونات (Evaluating Permissions)](#تقييم-الأذونات-evaluating-permissions) + - [مجموعات الأذونات الافتراضية (Default Permission Groups)](#مجموعات-الأذونات-الافتراضية-default-permission-groups) + - [التقييم الموازي للأذونات (Parallel Evaluation of Permissions)](#التقييم-الموازي-للأذونات-parallel-evaluation-of-permissions) + * [الإجراءات ذات التأخير الإلزامي (Actions with Mandatory Delay)](#الإجراءات-ذات-التأخير-الإلزامي-actions-with-mandatory-delay) + * [الاسترجاع من المفاتيح المسروقة (Recovery from Stolen Keys)](#الاسترجاع-للمفاتيح-المسروقة-recovery-from-stolen-keys) +- [التنفيذ الحتمي المتوازي للتطبيقات (Deterministic Parallel Execution of Applications)](#التنفيذ-الحتمي-المتوازي-للتطبيقات-تقليل-تأخر-الاتصالات-deterministic-parallel-execution-of-applications) + * [تقليل تأخر الاتصالات (Minimizing Communication Latency)](#تقليل-تأخر-الاتصالات-minimizing-communication-latency) + * [مُناوِلات الإجراء ذات خاصية القراءة فقط (Read-Only Action Handlers)](#مُناوِلات-الإجراء-ذات-خاصية-القراءة-فقط-read-only-action-handlers) + * [المعاملات الذرية مع حسابات متعددة (Atomic Transactions with Multiple Accounts)](#المعاملات-الذرية-مع-حسابات-متعددة-atomic-transactions-with-multiple-accounts) + * [التقييم الجزئي لحالة البلوكتشين (Partial Evaluation of Blockchain State)](#التقييم-الجزئي-لحالة-البلوكتشين-partial-evaluation-of-blockchain-state) + * [الجدولة الذاتية وفقًا لأفضل جهد (Subjective Best Effort Scheduling)](#الجدولة-الذاتية-وفقًا-لأفضل-جهد-subjective-best-effort-scheduling) + * [المعاملات المؤجلة (Deferred Transactions)](#المعاملات-المؤجلة-deferred-transactions) + * [إجراءات حرة السياق (Context Free Actions)](#إجراءات-حرة-السياق-context-free-actions) +- [نموذج الرمز واستخدام الموارد (Token Model and Resource Usage)](#نموذج-الرمز-واستخدام-الموارد-token-model-and-resource-usage) + * [القياسات الموضوعية والذاتية (Objective and Subjective Measurements)](#القياسات-الموضوعية-والشخصية-objective-and-subjective-measurements) + * [الدفع بواسطة المتلقي (Receiver Pays)](#الدفع-بواسطة-المتلقي-receiver-pays) + * [تفويض القدرات (Delegating Capacity)](#تفويض-الموارد-delegating-capacity) + * [فصل تكاليف المعاملة عن قيمة الرمز (Separating Transaction costs from Token Value)](#فصل-تكاليف-المعاملة-عن-قيمة-الرمز-separating-transaction-costs-from-token-value) + * [تكاليف تخزين الحالة (State Storage Costs)](#تكاليف-تخزين-الحالة-state-storage-costs) + * [مكافئات الكتلة (Block Rewards)](#مكافئات-الكتلة-block-rewards) + * [نظام اقتراح العمال (Worker Proposal System)](#نظام-اقتراح-العمال-worker-proposal-system) +- [الحوكمة (Governance)](#الحوكمة-governance) + * [تجميد الحسابات (Freezing Accounts)](#تجميد-الحسابات-freezing-accounts) + * [تغيير رمز الحساب (Changing Account Code)](#تغيير-رمز-الحساب-changing-account-code) + * [الدستور (Constitution)](#الدستور-constitution) + * [ترقية البروتوكول والدستور (Upgrading the Protocol & Constitution)](#ترقية-البروتوكول-والدستور-upgrading-the-protocol--constitution) + + [التغييرات الطارئة (Emergency Changes)](#التغييرات-الطارئة-emergency-changes) +- [المخطوطات والحواسيب الافتراضية (Scripts & Virtual Machines)](#المخطوطات-والحواسيب-الافتراضية-scripts--virtual-machines) + * [الإجراءات المُحددة بواسطة المخطط (Schema Defined Actions)](#الإجراءات-المُحددة-بواسطة-المخطط-schema-defined-actions) + * [قاعدة البيانات المُحددة بواسطة المخطط (Schema Defined Database)](#قاعدة-البيانات-المُحددة-بواسطة-المخطط-schema-defined-database) + * [قاعدة بيانات عامة متعددة الفهرسة API (Generic Multi Index Database API)](#قاعدة-بيانات-عامة-متعددة-الفهرسة--api-generic-multi-index-database-api) + * [فصل المصادقة عن التطبيق (Separating Authentication from Application)](#فصل-المصادقة-عن-التطبيق-separating-authentication-from-application) +- [الاتصالات عبر البلوكتشين (Inter Blockchain Communication)](#الاتصالات-عبر-البلوكتشين-inter-blockchain-communication) + * [أدلة ميركل للتحقق الخفيف من العميل \(LCV\) (Merkle Proofs for Light Client Validation (LCV))](#أدلة-ميركل-للتحقق-الخفيف-من-العميل-merkle-proofs-for-light-client-validation-lcv) + * [تأخر الاتصالات عبر البلوكتشين (Latency of Interchain Communicatio)](#تأخر-الاتصالات-عبر-البلوكتشين-latency-of-interchain-communication) + * [دليل الاكتمال (Proof of Completeness)](#دليل-الاكتمال-proof-of-completeness) + * [الشاهد المنفصل (Segregated Witness)](#الشاهد-المنفصل-segregated-witness) +- [الاستنتاج (Conclusion)](#الاستنتاج-conclusion) + + + +# الخلفية (Background) + +طلقت تقنية البلوكتشين في عام 2008 مع إطلاق عملة البيتكوين "Bitcoin"، ومنذ ذلك الحين حاول رواد الأعمال والمطورون تعميم هذه التقنية لتمكينها من دعم نطاق أوسع من التطبيقات على منصة بلوكتشين واحدة. + +في حين واجهت العديد من منصات البلوكتشين صعوبات في دعم التطبيقات اللامركزية الوظيفية، وأصبحت شبكات البلوكتشين محددة التطبيق مثل BitShares للتداول اللامركزي (2014) ومنصة Steem للتواصل الاجتماعي (2016) من البلوكتشين التي تُستخدم استخدامًا ضخمًا في ظل وجود عشرات الآلاف من المستخدمين النشطين يوميا. وقد تمكنا من تحقيق ذلك عبر زيادة الأداء إلى آلاف المعاملات في الثانية الواحدة، والحد من زمن التأخر إلى ثانية ونصف (1.5)، وإلغاء الرسوم لكل معاملة وتقديم تجربة مستخدم مماثلة لتلك التي توفرها حاليًا الخدمات المركزية القائمة. + +تعاني منصات البلوكتشين القائمة من الرسوم الكبيرة وقدرة الحوسبة المحدودة التي تمنع اعتماد البلوكتشين على نطاق واسع. + +# متطلبات تطبيقات البلوكتشين (Requirements for Blockchain Applications) + +لغرض تحقيق استخدام واسع النطاق، تتطلب التطبيقات على البلوكتشين وجود منصة مرنة بما يكفي لتلبية المتطلبات التالية: + +## دعم الملايين من المستخدمين (Support Millions of Users) + +يتطلب التنافس مع شركات مثل إيباي "eBay" وأوبر "Uber" وإير بي أن بي "AirBnB" وفيسبوك "Facebook" وجود تقنية بلوكتشين قادرة على التعامل مع عشرات الملايين من المستخدمين النشطين يوميًا. في بعض الحالات المخصوصة، قد لا يعمل التطبيق بدون الوصول إلى كتلة حرجة من المستخدمين، وبالتالي فإن وجود منصة يمكنها التعامل مع عدد كبير جدًا من المستخدمين أمرٌ بالغ الأهمية. + +## الاستخدام المجاني (Free Usage) + +يحتاج مطورو التطبيقات إلى المرونة ليمكنهم تقديم خدمات مجانية للمستخدمين؛ لا ينبغي على المستخدمين الدفع مقابل استخدام المنصة أو الاستفادة من خدماتها. فمن المرجح أن تحظى منصة بلوكتشين مجانية على إقبال أكثر من المستخدمين. ويمكن حينها للمطورين والشركات إنشاء استراتيجيات فعالة لتحقيق الدخل. + +## سهولة في الترقيات ومعالجة الأخطاء (Easy Upgrades and Bug Recovery) + +تحتاج الشركات التي تٌنشئ تطبيقات معتمدة على البلوكتشين إلى المرونة لتتمكن من تعزيز تطبيقاتها بميزات جديدة. يجب أن تدعم المنصة خاصية ترقيات البرمجيات (البرامج) والعقود الذكية. + +تتعرض جميع البرامج المعقدة للأعطاب، حتى مع أكثر طرق التحقق الرسمي صرامة. يجب أن تكون المنصة قوية بما يكفي لإصلاح الأخطاء الحتمية عندما تحدث. + +## التأخر المنخفض (Low Latency) + +للحصول على تجربة مستخدم جيدة؛ يتطلب الأمر الحصول على تعقيبات موثوقة ذات تأخير لا يزيد عن بضع ثوانٍ. يؤدي التأخير الطويل إلى إحباط المستخدمين وجعل التطبيقات المبنية على البلوكتشين أقل تنافسية مع البدائل الحالية بعيدًا عن تقنية البلوكتشين. يجب أن تدعم المنصة إجراء المعاملات بتأخرٍ منخفض. + +## الأداء المتسلسل (Sequential Performance) + +توجد بعض التطبيقات التي لا يمكن تنفيذها بواسطة الخوارزميات المتوازية؛ وذلك نتيجة وجود خطوات تعتمد على التسلسل. تحتاج بعض التطبيقات مثل منصات التداول إلى أداء تسلسلي كافٍ لمعالجة الكميات الكبيرة. لذلك، يجب أن تدعم المنصة الأداء المتسلسل السريع. + +## المعالجة المتوازية (Parallel Performance) + +تحتاج التطبيقات كبيرة الحجم إلى تقسيم أحمال العمل عبر وحدات المعالجة مركزية (CPU) وحواسيب متعددة. + +# خوارزمية الإجماع Consensus Algorithm (BFT-DPOS) + +تستخدم برمجيات EOS.IO خوارزمية الإجماع اللامركزي الوحيدة التي اثبتت قدرتها على الوفاء بمتطلبات الأداء للتطبيقات على البلوكتشين، إثبات الحصة بالتفويض والمعروف اختصارًا ب(DPOS). في ظل هذه الخوارزمية، يمكن لحاملي الرموز على البلوكتشين الذي يستخدم برنامج EOS.IO بتحديد المنتجين من خلال نظام الموافقة بالتصويت المستمر. قد يختار أي شخص المشاركة في إنتاج الكتل وسيُمنح فرصة لإنتاجها؛ شريطة أن يتمكن من إقناع حاملي الرموز بالتصويت له. + +يُمكّن برنامج EOS.IO من إنتاج الكتل كل 0.5 ثانية؛ ويسمح لمنتج واحد تحديدًا بإنتاج كتلة في أي وقت من الأوقات. إذا لم تُنتج الكتلة في الوقت المحدد وفقًا للجدول، فستُتخطى هذه الكتلة الخاصة بهذا الوقت المحدد. عند تخطي كتلة واحدة أو أكثر، يكون هناك فجوة زمنية قدرها نصف ثانية (0.5) أو أكثر في البلوكتشين. + +باستخدام برنامج EOS.IO؛ يجري إنتاج الكتل في جولات من 126 كتلة (6 كتل لكل منتج مضروبة في عدد 21 منتجًا). في بداية كل جولة؛ يختار أصحاب الرموز عبر التصويت 21 من منتجي الكتل المختلفين. يُجدوَّل المنتجون المختارون بترتيب متفق عليه من قبل 15 منتجًا أو أكثر. + +إذا لم يلحق المُنتج بالكتلة ولم ينتج أي كتلة خلال ال 24 ساعة الماضية؛ لا يؤخذ هذا المنتج بالاعتبار إلى أن يُخطر البلوكتشين برغبته ببدء إنتاج الكتل مرة أخرى. وهذا من شانه ضمانة تشغيل الشبكة بسلاسة عن طريق تقليل عدد الكتل الفائتة؛ وذلك بعدم جدولة المنتجين الذين ثبت أنهم غير موثوق بهم. + +في ظل الظروف العادية، لا يتعرض البلوكتشين من نوع إثبات الحصة بالتفويض "DPOS" لأي انقسام "fork"، لأن منتجي الكتل يتعاونون على إنتاج الكتل بدلًا من التنافس. في حالة وجود انقسام، سيتحول الإجماع تلقائيًا إلى أطول سلسلة. تعمل هذه الطريقة لأن المعدل الذي تُضاف به الكتل إلى انقسام البلوكتشين "fork" يرتبط ارتباطًا مباشرًا بالنسبة المئوية لمنتجي الكتل المشاركين بنفس الإجماع. وبعبارة أخرى، فإن انقسام البلوكتشين الذي به المزيد من المنتجين سينمو في الطول نموًا أسرع من بلوكتشين آخر به عدد أقل من المنتجين، لأن التشعيب الذي به المزيد من المنتجين سيشهد عددًا أقل من الكتل المفقودة. + +علاوة على ذلك، لا ينبغي لمنتج الكتل الإنتاج عبر طرفي تشعب الانقسام في نفس الوقت. من المرجح التصويت باستبعاد المنتج الذي يُضبط بهذا الفعل. يمكن أيضًا استخدام دليل تشفير لمثل هذا الإنتاج المزدوج لإزالة المعتدين تلقائيًا. + +تُضاف سماحية الخطأ البيزنطية (BFT) إلى نظام إثبات الحصة بالتفويض "DPOS" التقليدي من خلال السماح لجميع المنتجين بالتوقيع على جميع الكتل طالما لم يوقع أي منتج على كتلتين بنفس الطابع الزمني أو بنفس ارتفاع الكتلة. وبمجرد توقيع 15 منتجًا على الكتلة تُعتبر هذه الكتلة في حالة اللارجعة. يتعيّن على أي منتج بيزنطي أن يولّد دليلا مشفرًا على خداعه بتوقيع كتلتين بنفس الطابع الزمني أو ارتفاع الكتلة. في إطار هذا النموذج، يجب الوصول إلى إجماع اللارجعة خلال ثانية واحدة. + +## تأكيد المعاملة (Transaction Confirmation) + +يحتوي البلوكتشين النموذجي من نوع إثبات الحصة بالتفويض "DPOS" على مشاركة بنسبة 100٪ من منتجي الكتل. يمكن اعتبار المعاملة مؤكدة بنسبة 99.9٪ بعد متوسط 0.25 ثانية من وقت البث. + +بالإضافة إلى إثبات الحصة بالتفويض "DPOS"، يضيف EOS.IO سماحية خطأ بيزنطية لا متزامنة (aBFT) لسرعة تحقيق حالة اللارجعة. توفر خوارزمية سماحية الخطأ البيزنطية اللامتزامنة "aBFT" تأكيدًا نسبته 100٪ على حالة اللارجعة في غضون ثانية واحدة. + +## إثبات الحصة بالمعاملة Transaction as Proof of Stake (TaPoS) + +يتطلب برنامج EOS.IO أن تتضمن كل معاملة جزءً من الهاش "hash" الخاصة برأس كتلة حديثة. تخدم هذه الهاش غرضين اثنين وهما: + +1. منع إعادة تشغيل المعاملة على الإنقسامات التي لا تتضمن الكتلة المشار إليها؛ وتنبيه الشبكة أن مستخدمًا معينًا وحصته موجودان على تشعّب محدد للإنقسام.; و +2. بمرور الوقت ينتهي الأمر بجميع المستخدمين بتأكيدهم المباشرة للبلوكتشين؛ مما يجعل من الصعب تشكيل سلاسل مزيفة لأن التزييف لن يكون قادراً على ترحيل المعاملات من السلسلة الشرعية. + +وبمرور الوقت ينتهي الأمر بجميع المستخدمين بتأكيدهم المباشرة للبلوكتشين؛ مما يجعل من الصعب تشكيل سلاسل مزيفة لأن التزييف لن يكون قادراً على ترحيل المعاملات من السلسلة الشرعية. + +# الحسابات (Accounts) + +يسمح برنامج EOS.IO بالإشارة إلى جميع الحسابات من خلال اسم فريد قابل للقراءة من قبل الإنسان يصل إلى 12 حرفًا. يختار منشئ الحساب هذا الاسم. يجب أن يحتفظ منشئ الحساب بالذاكرة المطلوبة (RAM) لتخزين الحساب الجديد إلى أن يجمع الحساب الجديد الرموز "Tokens" لحفظ ذاكرته الخاصة به عليها. + +في سياق لامركزي، يدفع مطورو التطبيقات التكلفة الاسمية لإنشاء الحساب لتسجيل مستخدم جديد. تنفق الشركات التقليدية بالفعل مبالغًا كبيرة من المال لكل عميل تحصل عليه؛ وذلك على هيئة إعلانات وخدمات مجانية وما إلى ذلك. وبالتالي فإن تكلفة تمويل حساب بلوكتشين جديد غير ذات أهمية بالمقارنة. لحسن الحظ، ليست هناك حاجة لإنشاء حسابات جديدة للمستخدمين الذين اشتركوا بالفعل عبر تطبيق آخر. + +## الإجراءات والمناولة (Actions & Handlers) + +يمكن لكل حساب إرسال إجراءات منظمة إلى حسابات أخرى، ويمكنه تعريف البرامج النصية للتعامل مع الإجراءات وقت استلامها. يمنح برنامج EOS.IO كل حساب قاعدة بيانات خاصة به والتي لا يمكن الوصول إليها إلا من خلال مناولات الإجراءات الخاصة به. يمكن أيضًا للنصوص البرمجية المتعاملة مع الإجراءات إرسال إجراءات إلى حسابات أخرى. يستخدم EOS.IO الجمع بين الإجراءات ومُناوِلات الإجراءات التلقائية "automated action handlers" كوسيلة لتعريف العقود الذكية. + +لدعم التنفيذ المتوازي، يمكن لكل حساب أيضًا تحديد أي عدد من النطاقات داخل قاعدة بياناته. سيجدّول منتجو الكتل المعاملات بطريقة لا تسبب تضاربًا بخصوص وصول الذاكرة إلى النطاقات وبالتالي يمكن تنفيذ هذه المعاملات بالتوازي. + +## إدارة الأذونات وفقًا للأدوار (Role Based Permission Management) + +تتضمن إدارة الأذونات تحديد ما إذا كان الإجراء مصرحًا به أم لا. إن أبسط شكل من أشكال إدارة الأذونات هو التحقق من أن المعاملة بها التوقيعات المطلوبة، ولكن هذا يعني ضمناً أن التوقيعات المطلوبة معروفة بالفعل. بشكل عام، فالصلاحية مقيدة بأفراد أو مجموعات من الأفراد وغالباً ما تكون مجزئة. يوفر برنامج EOS.IO نظام إدارة أذونات تقريري يوفر مراقبة دقيقة ومرتفعة للحسابات بخصوص من يمكنه فعل شيء ما ومتى يمكنه ذلك. + +من الأهمية بمكان أن تكون المصادقة وإدارة الأذونات موحدة ومفصولة عن منطق الأعمال الخاص بالتطبيق. يتيح ذلك تطوير أدوات لإدارة الأذونات تطويرًا عامًا وتوفير فرص كبيرة لتحقيق الأداء الأمثل. + +يمكن التحكم في كل حساب من خلال أي مجموعة ترجيح مكونة من الحسابات والمفاتيح الخاصة الأخرى. يؤدي هذا إلى إنشاء بنية هرمية للصلاحية تعكس كيفية تنظيم الأذونات في الواقع؛ مما يسهل التحكم من المستخدمين المتعددين مقارنة بأي وقت مضى. إن التحكم بواسطة مستخدمين متعددين هو أكبر العوامل المساهمة في تحقيق الأمن، وعند استخدامه استخدامًا صحيحًا فإن بإمكانه الحد بصورة كبيرة من خطر السرقة بسبب القرصنة. + +يسمح برنامج EOS.IO للحسابات بتحديد مجموعة المفاتيح والحسابات أو أيهما التي يمكنها إرسال نوع إجراء معين إلى حساب آخر. على سبيل المثال، من الممكن أن يكون لديك مفتاح واحد للحساب الخاص بالوسائط الاجتماعية وآخر للوصول إلى البورصة. من الممكن أيضًا منح حسابات أخرى الإذن بالتصرف نيابةً عن حساب المستخدم دون تعيين مفاتيح له. + +### مستويات الأذونات المُدرجة (Named Permission Levels) + +
+ +
+ +باستخدام برامج EOS.IO؛ يمكن للحسابات تحديد مستويات الأذونات المعينة التي يمكن اشتقاق كل منها من أذونات معينة أخرى على مستوى أعلى. يحدد كل مستوى إذن مُعين صلاحية ما؛ هذه الصلاحية هي عتبة للتحقق من التوقيعات المتعددة وتتكون من مفاتيح ومستويات أذونات معينة للحسابات الأخرى أو أيهما. على سبيل المثال، يمكن تعيين مستوى إذن من نوع "صديق" لحساب ما؛ وذلك لإجراء متعلق بالحساب ليُتحكم فيه بالتساوي من قبل أي من أصدقاء الحساب. + +بلوكتشين Steem مثال آخر؛ حيث بها ثلاثة مستويات معينة للأذونات هي: مالك ونشط وناشر(owner, active, and posting). لا يمكن لإذن النشر سوى تنفيذ الإجراءات الاجتماعية مثل التصويت والنشر، في حين أن الإذن النشط يمكن أن يفعل كل شيء باستثناء تغيير المالك. أما إذن المالك فمخصص للمخزن البارد وهو مٌخوّل بفعل كل شيء. يُعمم برنامج EOS.IO هذا المفهوم من خلال السماح لكل صاحب حساب بتحديد التسلسل الهرمي الخاص به؛ بالإضافة إلى تجميع الإجراءات. + +### تخطيط الأذونات (Permission Mapping) + +يسمح برنامج EOS.IO لكل حساب بتحديد التخطيط "mapping" بين العقد أو الإجراء أو عقد لأي حساب آخر وكذلك المستوى المعيين الخاص به. على سبيل المثال، يمكن لصاحب الحساب تخطيط وربط تطبيق وسائل التواصل الاجتماعي لمالك الحساب مع مجموعة أذونات "صديق" الخاصة بمالك الحساب. باستخدام هذا التخطيط؛ يمكن لأي صديق أن ينشر تحت اسم صاحب الحساب على الوسائط الاجتماعية الخاصة به. على الرغم من أنهم قد ينشرون بصفتهم أصحاب الحساب، إلا أنهم سيظلون يستخدمون مفاتيحهم الخاصة للتوقيع على الإجراء. ويعني هذا أنه من الممكن دائمًا تحديد الأصدقاء الذين استخدموا الحساب كما يمكن تحديد طريقة هذا الاستخدام. + +### تقييم الأذونات (Evaluating Permissions) + +عند تسليم إجراء من نوع "**Action**", من **@alice** إلى **@bob** يتحقق برنامج EOS.IO أولاً لمعرفة ما إذا كانت **@alice** قد حددت تخطيطًا للأذونات ل **@bob.groupa.subgroup.Action**. إذا لم يُعثر على أي شيء بخصوص **@bob.groupa.subgroup** فسيُتحقق من مسار **@bob.groupa**, وفي الاخير **@bob** إذا لم يُعثر على تطابق آخر، فسيكون التخطيط المفترض لمجموعة الإذن المعينة هو **@alice.active**. + +بمجرد تحديد التخطيط، يجري التحقق من صلاحية التوقيع باستخدام عملية عتبة التوقيع المتعدد والصلاحية المرتبطة بالإذن المعيين. إذا فشل ذلك، فإنه ينتقل إلى الإذن الأب وفي النهاية إلى إذن المالك . **@alice.owner**. + +
+ +
+ +#### مجموعات الأذونات الافتراضية (Default Permission Groups) + +كما تتيح تقنية EOS.IO لجميع الحسابات أن يكون لديها مجموعة "مالك" يمكنها القيام بكل شيء، ومجموعة "نشط" يمكنها القيام بكل شيء ما عدا تغيير مجموعة المالك. تُشتق كل مجموعات الأذونات الأخرى من المجموعة "نشط". + +#### التقييم الموازي للأذونات (Parallel Evaluation of Permissions) + +عملية تقييم الأذونات هي "للقراءة فقط" ولا تسري التغييرات المجراة على الأذونات بواسطة المعاملات إلا في نهاية الكتلة. وهذا يعني أنه يمكن تنفيذ جميع التقييمات للمفاتيح والأذونات لجميع المعاملات بالتوازي. وعلاوة على ذلك، فإن هذا يعني إمكانية التحقق السريع من الإذن دون البدء باستعادة مكلفة لمنطق التطبيق. وأخيرًا، فهذا يعني أنه يمكن تقييم أذونات المعاملات وقت استلام المعاملات المعلقة؛ ولا يلزم إعادة تقييمها عند تطبيقها. + +وبأخذ جميع الأمور في الاعتبار؛ يمثل التحقق من الإذن نسبة مئوية كبيرة من الحوسبة المطلوبة للتحقق من صحة المعاملات. تتحقق زيادة هائلة في الأداء عبر جعل هذه العملية "قراءة فقط" وإمكان إجراؤها توازيًا بسهولة. + +عند إعادة تشغيل البلوكتشين لتجديد الحالة الحتمية من سجل الإجراءات؛ فلا توجد حاجة لتقييم الأذونات مرة أخرى. فحقيقة أن المعاملة تقع ضمن كتلة جيدة ومعروفة تجعله كافيًا لتخطي هذه الخطوة. وهذا يقلل بدوره من الحمل الحوسبي المرتبط بإعادة استخدام البلوكتشين متزايد الحجم. + +## الإجراءات ذات التأخير الإلزامي (Actions with Mandatory Delay) + +الوقت عنصر حاسم لضمان الأمان. في معظم الحالات؛ لا يمكن معرفة ما إذا كان المفتاح الخاص قد سُرق إلى أن يستخدم. يُعد الأمان المستند إلى الوقت أكثر أهمية عندما يكون لدى الأشخاص تطبيقات تتطلب مفاتيح محتفظ بها على الحواسيب المتصلة بالإنترنت للاستخدام اليومي. يُمكّن برنامج EOS.IO مطوري التطبيقات من الإشارة إلى أن إجراءات معينة يجب أن تنتظر فترة زمنية قصيرة بعد تضمينها في كتلة قبل تطبيقها. خلال هذا الوقت، يمكن إلغاؤها. + +يمكن للمستخدمين بعد ذلك تلقي إشعار عبر البريد الإلكتروني أو رسالة نصية عند بث أحد هذه الإجراءات. إذا لم يعطوا تصريحًا بذلك، فيمكنهم استخدام عملية استرداد الحساب لاسترداد حساباتهم وسحب الإجراء. + +يعتمد التأخير المطلوب على مدى حساسية العملية. قد يكون دفع مقابل كوب من القهوة بلا تأخير ولا يمكن التراجع عنه خلال ثوانٍ، بينما قد يتطلب شراء منزل فترة 72 ساعة للإنفاذ. قد يستغرق نقل حساب بالكامل إلى عنصر تحكم جديد ما يصل إلى 30 يومًا. تُختار مدد التأخير المحددة بواسطة مطوري التطبيقات والمستخدمين. + +## الاسترجاع للمفاتيح المسروقة (Recovery from Stolen Keys) + +يُوفر برنامج EOS.IO للمستخدمين طريقة لاستعادة السيطرة على حساباتهم عند سرقة المفاتيح. يمكن لمالك الحساب استخدام أي مفتاحِ للمالك شريطة أن يكون نشطًا خلال آخر 30 يومًا؛ إلى جانب الموافقة من الشريك المُعيين لاسترداد الحساب على إعادة تعيين مفتاح حساب المالك. لا يمكن لشريك استرداد الحساب إعادة ضبط التحكم في الحساب بدون مساعدة المالك. + +ليس هناك ما يمكن أن يكتسبه القرصان من خلال محاولة اجتياز عملية الاسترداد نظرًا لأنهم "يتحكمون" بالفعل في الحساب. علاوة على ذلك؛ إذا ما بدأت العملية فمن المنتظر أن يطلب شريك الاسترداد تحديد الهوية والمصادقة متعددة العوامل (الهاتف والبريد الإلكتروني). من المنتظر أن يؤدي هذا إلى إفشال عملية الاختراق أو عدم حصول القرصان على شيء يُذكر في هذه العملية. + +تختلف هذه العملية أيضًا اختلافًا كبيرًا عن الاتفاقات البسيطة متعددة التوقيعات. مع وجود معاملة متعددة التوقيعات؛ يُنشأ كيان آخر بوصفه طرفًا في كل معاملة تُنفذ. على النقيض من ذلك، يكون شريك الاسترداد طرفًا في عملية الاسترداد فقط وليس لديه القدرة على إجراء المعاملات اليومية. يقلل هذا التكاليف والالتزامات القانونية لجميع المعنيين إقلالًا ملحوظًا. + + +# التنفيذ الحتمي المتوازي للتطبيقات تقليل تأخر الاتصالات (Deterministic Parallel Execution of Applications) + +يعتمد إجماع البلوكتشين على السلوك الحتمي (القابلية للاستنساخ). وهذا يعني أن التنفيذ المتوازي بأكمله يجب أن يكون خاليًا من استخدام كائنات المزامنة "Mutexes" أو الأقفال الأولية الأخرى. بدون الأقفال يجب إيجاد طريقة أخرى لضمان أن المعاملات التي تنفذ على التوازي لا تؤدي إلى نتائج غير حتمية. + + + +سيعمل إصدار EOS.IO يونيو 2018 على أساس أحادي الخيط؛ ولكنه يحتوي على بنية البيانات الضرورية من أجل التنفيذ المتوازي متعدد الخيوط في المستقبل. + +بمجرد تمكين التشغيل المتوازي في البلوكتشين القائم على برمجيات EOS.IO؛ سيكون من مهمة منتجي الكتل تنظيم تسليم الإجراءات في صورة قطع مستقلة بحيث يمكن تقييمها بالتوازي. الجدول عبارة عن مُخرَج لمنتج الكتلة وسيُنفذ تنفيذَا حتميًا، ولكن لا تحتاج عملية إنشاء الجدول إلى أن تكون حتمية. ويعني هذا أن منتجي الكتل يمكنهم استخدام الخوارزميات المتوازية لجدولة المعاملات. + +جزء مما يعنيه التنفيذ المتوازي أنه عند إنشاء البرنامج النصي لإجراء جديد؛ فإنه لا يٌسلّم على الفور. بل من المقرر تسليمه في الدورة التالية. والسبب في عدم إمكانية التسليم الفوري هو أن المتلقي قد يُعدّل حالته تعديلًا نشطًا في جزء آخر. + + +## تقليل تأخر الاتصالات (Minimizing Communication Latency) + +وقت الاستجابة هو الوقت الذي يستغرقه حساب واحد لإرسال إجراء إلى حساب آخر ثم تلقي استجابة. الهدف هو تمكين حسابين من تبادل الإجراءات ذهابًا وإيابًا داخل كتلة واحدة دون الحاجة إلى الانتظار 0.5 ثانية بين كل إجراء. لتمكين هذا، يُقسّم برنامج EOS.IO كل كتلة إلى دورات. تنقسم كل دورة إلى أجزاء، ويحتوي كل جزء على قائمة بالمعاملات. تحتوي كل معاملة على مجموعة من الإجراءات من المنتظر تسليمها. يمكن تصور هذه البنية كشجرة؛ حيث تُعالج الطبقات المتعاقبة بالتتابع وبالتوازي. + + الكتلة + + المنطقة + + دورات (متسلسلة) + + الأجزاء (موازية) + + المعاملات (متسلسلة) + + الإجراءات (متسلسلة) + + المتلقي والحسابات المُشعرة (متوازي) + +يمكن تسليم المعاملات الناتجة من دورة واحدة في أي دورة أو كتلة لاحقة. سيستمر منتجو الكتل في إضافة دورات إلى الكتلة حتى يمر الحد الأقصى لساعة الحائط(maximum wall clock time)؛ أو في حالة عدم إنتاج معاملات جديدة. + +من الممكن استخدام التحليل الثابت للكتلة للتحقق من عدم وجود جزئين يحتويان على معاملات تجري تعديلات على نفس الحساب خلال دورة معينة. وطالما تم الحفاظ على هذا الثابت؛ فيمكن معالجة الكتلة من خلال تشغيل جميع الأجزاء "shards" تشغيلًا متوازيًا + + +## مُناوِلات الإجراء ذات خاصية القراءة فقط (Read-Only Action Handlers) + +قد تتمكن بعض الحسابات من معالجة إجراء على أساس النجاح/الفشل دون تعديل حالتها الداخلية. في هذه هي الحالة يمكن تنفيذ هذه المناولات بالتوازي طالما كانت مُناوِلات الإجراءات ذات خاصية القراءة فقط لحساب معين ضمن جزء "shard" أو أكثر من الأجزاء داخل دورة معينة. + +## المعاملات الذرية مع حسابات متعددة (Atomic Transactions with Multiple Accounts) + +في بعض الأحيان يكون من المرغوب فيه التأكد من أن الإجراءات قد سُلمت إلى واستُلِمت من حسابات متعددة. في هذه الحالة، يوضع كلا الإجراءين في معاملة واحدة وسيخصص نفس الجزء "shard" لكل من الحسابين، بينما تطبق الإجراءات بالتسلسل. + +## التقييم الجزئي لحالة البلوكتشين (Partial Evaluation of Blockchain State) + +تتطلب تقنية البلوكتشين القابل للتوسع أن تكون المكونات من وحدات متماثلة. يجب ألا يضطر الجميع إلى تشغيل كل شيء، خاصةً إذا كانوا بحاجة فقط إلى استخدام مجموعة فرعية صغيرة من التطبيقات. + +يُشغّل مطور تطبيق التبادل عُقدًا كاملة "Nodes" لغرض عرض حالة التبادل لمستخدميها. لا يحتاج تطبيق التبادل هذا إلى أي حالة مرتبطة بتطبيقات وسائل التواصل الاجتماعية. يسمح برنامج EOS.IO لأي عقدة كاملة باختيار أي مجموعة فرعية من التطبيقات لتشغيلها. يجري تجاهل الإجراءات المرسلة إلى تطبيقات أخرى بأمان؛ إذا كان تطبيقك لا يعتمد أبداً على حالة عقد آخر. + + +## الجدولة الذاتية وفقًا لأفضل جهد (Subjective Best Effort Scheduling) + +لا يمكن لبرنامج EOS.IO إلزام منتجي الكتل بتسليم أي إجراء إلى أي حساب آخر. يجري كل منتِج كتلة قياساته الذاتية لمدى التعقيد الحوسبي والوقت اللازم لمعالجة المعاملة. ينطبق هذا على المعاملات التي أُنشئت بواسطة مستخدم أو تلقائيًا بموجب عقد ذكي. + +في حالة تشغيل البلوكتشين باستخدام برنامج EOS.IO، تُحاسب جميع المعاملات على مستوى الشبكة على تكلفة عرض النطاق الحوسبي استنادًا إلى عدد تعليمات تقنية الويب أسيمبلي المنفذة "WASM". ومع ذلك، قد يحسب كل منتج كتل من مستخدمي البرنامج استخدام الموارد؛ وذلك باستخدام الخوارزميات والقياسات الخاصة به. عندما يستنتج منتج الكتلة أن المعاملة أو الحساب قد استهلك كمية غير متناسبة من القدرة الحوسبية، فإنه ببساطة يرفض الصفقة عند إنتاجه للكتلة الخاصة به؛ ومع ذلك فإنه سيستمر في معالجة المعاملة إذا اعتبرها منتجو الكتل الأخرى صالحة. + +عامة، طالما اعتبر أحد منتجي الكتل أن المعاملة صالحة وتقع تحت حدود استخدام الموارد، فإن جميع منتجي الكتل الأخرى سيقبلونها أيضًا، ولكن قد يستغرق الأمر ما يصل إلى دقيقة واحدة كي تعثر المعاملة على ذلك المنتج. + +في بعض الحالات، قد يُنشئ المنتج كتلة تحتوي على معاملات ذات حجم كبير خارج النطاقات المقبولة. في هذه الحالة، قد يختار منتج الكتلة التالي رفض الكتلة وسيُكسر التعادل من قبل المنتج الثالث. هذا لا يختلف عما قد يحدث إذا تسببت كتلة كبيرة في تأخير انتشار الشبكة. سيلاحظ المجتمع نمطًا من إساءة الاستخدام وبالتالي يسحب الأصوات من المنتج المحتال. + +هذا التقييم الذاتي للتكلفة الحوسبية يحرر كتلة البلوكتشين من حمل الاضطرار إلى القياس الدقيق والحتمي لطول المدة التي يستغرقها تشغيل شيء ما. مع هذا التصميم لا توجد حاجة إلى حساب عدد التعليمات بدقة؛ وهي تزيد زيادة كبيرة من فرص التحسين دون كسر توافق الآراء. + +## المعاملات المؤجلة (Deferred Transactions) + +يدعم برنامج EOS.IO العمليات المؤجلة التي جُدولت لتُنفذ في المستقبل. يتيح ذلك انتقال الحوسبة إلى أجزاء "shards" مختلفة و/أو إنشاء عمليات طويلة الأمد تُجري جدولة مستمرة لمعاملة مستمرة. + +## إجراءات حرة السياق (Context Free Actions) + +يتضمن الإجراء حر السياق "Context free Action" عمليات حوسبة تعتمد فقط على بيانات المعاملات وليس على حالة البلوكتشين. على سبيل المثال؛ فالتحقق من صحة التوقيع عبارة عن عمليات حسابية تتطلب فقط بيانات المعاملة وتوقيعًا لتحديد المفتاح العمومي الذي وقع هذه المعاملة. وهذه واحدة من الحوسبات الفردية الأكثر تكلفة التي يجب أن يجريها البلوكتشين، ولكن لأن هذه الحوسبة حرة السياق “Context free" فيمكن إجراؤها بالتوازي. + +تعتبر "الإجراءات حرة السياق" مثل إجراءات المستخدم الأخرى، إلا أنها تفتقر إلى الوصول إلى حالة البلوكتشين لإجراء عملية التحقق من الصحة. ولا يؤدي ذلك فقط إلى تمكين EOS.IO من معالجة جميع الإجراءات حرة السياق مثل التحقق المتوازي من التوقيع؛ ولكن الأهم أن هذا يتيح التحقق العام من التوقيع. + +مع توفير الدعم للإجراءات حرة السياق؛ فإن تقنيات التوسع مثل التجزئة "Sharding" ورايدن "Raiden" وبلازما "Plasma" وقنوات الحالة "State Channels" وغيرها تصبح عمليةً أكثر ويسهل إجراؤها بالتوازي. يُمكّن هذا التطوير من التواصل الفعال عبر البلوكتشين وبالتالي تحقيق إمكانية تطوير غير محدودة. + +# نموذج الرمز واستخدام الموارد (Token Model and Resource Usage) + +**رجى ملاحظة التالي: الرموز المشفرة المشار إليها في هذه الورقة البيضاء تشير إلى الرموز المشفرة على بلوكتشين سبق إطلاقه بالفعل ويتبنى برنامج EOS.IO. ولا تشير إلى الرموز المميزة ERC-20 التي تُوزع على بلوكتشين الإيثريوم فيما يتصل بتوزيع رموز EOS.** + +جميع أنظمة البلوكتشين مقيدة بالموارد وتتطلب نظام لمنع سوء الاستخدام. توجد مع البلوكتشين الذي يستخدم برنامج EOS.IO ثلاث فئات واسعة من الموارد التي تستهلكها التطبيقات: + +1. عرض النطاق وتخزين السجل "Bandwidth and Log Storage" (القرص "Disk") ; +2. الحوسبة والسجل الحوسبي الخلفي "Computation and Computational Backlog" (CPU) ; و +3. تخزين الحالة "State Storage" (RAM) . + +يوجد مكونان لدى عرض النطاق والحوسبة، الاستخدام الفوري والاستخدام على المدى الطويل. يحتفظ البلوكتشين بسجل يحتوي على جميع الإجراءات؛ ويُحفظ هذا السجل ويُنزّل في نهاية المطاف بواسطة جميع العقد الكاملة. وبواسطة سجل الإجراءات من الممكن إعادة بناء الحالة لكافة التطبيقات. + +الدَين الحوسبي "computational debt" عبارة عن عمليات حسابية يجب تنفيذها لإعادة توليد الحالة من خلال سجل الإجراءات. إذا كان الدَين الحوسبي ينمو نموًا كبيرًا؛ يصبح من الضروري أخذ لقطات من حالة البلوكتشين وتجاهل تاريخ البلوكتشين. إذا زادت الديون الحوسبية زيادة كبيرة؛ فقد يستغرق الأمر 6 أشهر لإعادة عرض التعاملات الخاصة بسنة واحدة. لذلك فإدارة الدين الحوسبي بعناية أمر شديد الأهمية. + +"تخزين حالة البلوكتشين" عبارة عن المعلومات التي يمكن لمنطق التطبيق الوصول إليها. ويشمل معلومات مثل سجلات الأوامر وأرصدة الحسابات. إذا لم يقرأ التطبيق الحالة من قبل فلا ينبغي تخزينها. على سبيل المثال، لا يقرأ منطق التطبيقات محتوى مشاركات المدونة والتعليقات، لذلك لا يجب تخزينها في حالة البلوكتشين. ومن ناحية أخرى؛ فإن وجود منشور أو تعليق وكذلك عدد الأصوات وخصائص أخرى يجري تخزينها بوصفها جزءً من حالة البلوكتشين. + +ينشر منتجو الكتل قدراتهم المتاحة بخصوص عرض النطاق والحوسبة والحالة. يسمح برنامج EOS.IO لكل حساب باستهلاك نسبة مئوية من السعة المتاحة بما يتناسب مع كمية الرموز المحتفظ بها في عَقد محاصصة لمدة 3 أيام. على سبيل المثال، إذا أُطلق بلوكتشين قائم على برنامج EOS.IO واحتفظ أحد الحسابات بنسبة 1٪ من إجمالي الرموز "Tokens" القابلة للتوزيع وفقًا لهذا البلوكتشين فسيكون لهذا الحساب إمكانية استخدام 1٪ من سعة تخزين الحالة. + +إن استخدام برنامج EOS.IO للبلوكتشين الذي أطلق يعني تخصيص عرض النطاق والقدرة الحوسبية يتم على أساس احتياطي نسبي، وذلك لأنها مؤقتة (لا يمكن حفظ السعة غير المستخدمة للاستخدام لاحقًا). تشبه الخوارزمية المستخدمة بواسطة برنامج EOS.IO تلك الخوارزمية المستخدمة من قبل منصة Steem للاستخدام المحدود لمعدلات عرض النطاق. + +## القياسات الموضوعية والشخصية (Objective and Subjective Measurements) + +كما ذكرنا سابقًا، فإن استخدام القدرة الحوسبية له تأثير كبير على الأداء والتحسين؛ لذلك تكون جميع قيود استخدام الموارد شخصية " Subjective " في النهاية، وتُنفذ هذه القيود بواسطة منتجي الكتل وفقًا لخوارزمياتهم الفردية وتقديراتهم. عادة ما يُنفذ هذا بواسطة منتجي الكتل عن طريق كتابة ملحق "plugin" مخصَصَ. + +ومع ذلك، فهناك أشياء لا تحتاج للقياس الموضوعي نظرًا لبساطتها. من الأرخص إجراء القياس الموضوعي لعدد الإجراءات المُسلّمة وحجم البيانات المخزنة في قاعدة البيانات الداخلية. يُمكّن برنامج EOS.IO منتجي الكتل من تطبيق نفس الخوارزمية على هذه المقاييس الموضوعية ولكنهم قد يختارون تطبيق خوارزميات ذاتية أكثر صرامة على القياسات الشخصية. + +## الدفع بواسطة المتلقي (Receiver Pays) + +تقليديًا، النشاط التجاري يدفع تكاليف المساحة المكتبية، القدرات الحوسبية وغيرها من التكاليف اللازمة لإدارة الأعمال. يشتري العميل منتجات معينة من هذا النشاط وتُستخدم الإيرادات الناتجة من مبيعات المنتجات هذه لتغطية تكاليف التشغيل. وبالمثل، لا يُلزم أي موقع ويب زائريه بإجراء عمليات دفع مصغرة مقابل زيارة الموقع على الويب لتغطية تكاليف الاستضافة. لذلك، يجب ألا تُجبر التطبيقات اللامركزية عملاءها على الدفع بالبلوكتشين مباشرة نظير استخدام البلوكتشين. + +لا يتطلب البلوكتشين المبني على برنامج EOS.IO من مستخدميه الدفع لإستخدام البلوكتشين مباشرة، وبالتالي لا يمنع أو يعيق الشركات من تحديد استراتيجية تحقيق الربح لمنتجاتها. + +وعلى الرغم من قدرة المتلقي على الدفع؛ فإن EOS.IO يُمكّن المرسل من الدفع مقابل عرض النطاق والحوسبة والتخزين. يُمكّن هذا مطوري التطبيقات من اختيار الطريقة الأفضل لتطبيقاتهم. في العديد من الحالات، يقلل الدفع بواسطة المُرسل من التعقيدات الخاصة بمطوري التطبيقات؛ الذين لا يرغبون في تطبيق نظامهم الخاص "rationing system". يمكن لمطوري التطبيقات تفويض "تحصيص" عرض النطاق والحوسبة لمستخدميهم، ثم السماح لنموذج “sender pays” بإنفاذ الاستخدام. من منظور المستخدم النهائي فالأمر مجاني، ولكن من منظور البلوكتشين فالأمر بنظام الدفع بواسطة المرسل. + +## تفويض الموارد (Delegating Capacity) + +إن حاملي الرموز على البلوكتشين الذي أُطلق اعتمادًا على برنامج EOS.IO الذي قد لا يكون بحاجة فورية إلى استهلاك عرض النطاق " bandwidth" المتوفر بأكمله أو جزء منه؛ يمكنه تفويض عرض النطاق غير المستهلك أو تأجيره للآخرين؛ سيلحظ منتجو الكتل الذين يشغلون برنامج EOS.IO على هذا البلوكتشين هذا التفويض في السعة وسيخصصون عرض النطاق وفقًا لذلك. + +## فصل تكاليف المعاملة عن قيمة الرمز (Separating Transaction costs from Token Value) + +تتمثل إحدى المزايا الرئيسية لبرنامج EOS.IO في أن مقدار عرض النطاق "bandwidth" المتاح لتطبيق ما مستقل تمامًا عن أي سعر للرموز. إذا كان مالك التطبيق يحمل عددًا مناسبًا من الرموز على البلوكتشين الذي يستخدم برنامج EOS.IO، فيمكن تشغيل التطبيق إلى أجل غير مسمى ضمن استخدام محدد للموارد وعرض النطاق. في هذه الحالة، لا يتأثر المطورون والمستخدمون بأي تقلبات في سعر سوق الرموز، وبالتالي لا يهتمون بأخبار الأسعار الواردة "Price Feed". وبعبارة أخرى، فإن البلوكتشين الذي يستخدم برنامج EOS.IO يُمكّن منتجي الكتل من تحقيق زيادة طبيعية لعرض النطاق والحوسبة والتخزين المتاحين لكل رمز دون النظر لقيمة هذا الرمز. + +كما يمنح البلوكتشين الذي يستخدم برنامج EOS.IO رموزًا لمنتجي الكتل في كل مرة ينتجون فيها كتلة. ستؤثر قيمة الرموز على مقدار عرض النطاق والتخزين والحوسبة التي يمكن للمنتج تحمل نفقات شراءها؛ هذا النموذج يعزز بدوره زيادة قيمة الرموز لزيادة أداء الشبكة. + +## تكاليف تخزين الحالة (State Storage Costs) + +في حين يمكن تفويض "تحصيص" عرض النطاق والحوسبة، سيتطلب تخزين حالة التطبيق أن يحتفظ مطور تطبيق برموز إلى أن تُحذف هذه الحالة. إذا لم تُحذف الحالة أبدًا، فستُزال الرموز من التداول. + +## مكافئات الكتلة (Block Rewards) + +ستمنح البلوكتشين الذي يستخدم برنامج EOS.IO رموزًا جديدة لمنتج الكتل في كل مرة تنتج فيها كتلة. في هذه الظروف، تُحدد عدد الرموز التي أُنشئت بواسطة حساب متوسط المقابل المادي المطلوب المُعلن من قبل جميع منتجي الكتل. قد يكون برنامج EOS.IO مهيئًا بطريقة تفرض سقفًا على جوائز المنتجين؛ بحيث لا يتجاوز إجمالي الزيادة السنوية في إجمالي عدد الرموز نسبة 5٪. + +## نظام اقتراح العمال (Worker Proposal System) + +بالإضافة إلى انتخاب منتجي الكتل، وفقًا للبلوكتشين المستند إلى برنامج EOS.IO؛ يمكن لحاملي الرموز اختيار عدد من مقترحات العمال المصممة لمنفعة المجتمع. ستحصل المقترحات الفائزة على رموز تصل إلى نسبة مئوية معدة مسبقًا من تضخم الرموز مطروحًا منها تلك الرموز التي دُفعت بالفعل إلى منتجي الكتل. ستتلقى هذه المقترحات رموزاً تتناسب مع الأصوات التي تلقاها كل تطبيق من حاملي الرموز، وصولاً إلى الكمية الذي يطلبونها لتنفيذ عملهم. يمكن استبدال المقترحات المنتخبة بالمقترحات المنتخبة حديثًا من قبل أصحاب الرموز. + +قد لا تكون عقود النظام التي تنفذ مقترحات العمال متاحةً عند الإطلاق الأولي في يونيو 2018، ولكن آلية التمويل ستكون متاحة. وسوف تبدأ في تجميع الأموال في نفس الوقت بدء جوائز منتجي الكتل. وبما أن نظام تقديم عروض العمل سيُنفذ في تقنية WebAssembly "WASM"، فيمكن إضافته في وقت لاحق دون وجود انقسام. + + +# الحوكمة (Governance) + +الحوكمة هي العملية التي يقوم فيها الأفراد في المجتمع بأداء ما يلي: + +1. التوصل إلى توافق في الآراء بشأن المسائل الذاتية للعمل الجماعي التي لا يمكن التقاطها بالكامل بواسطة خوارزميات البرمجيات؛ +2. تنفيذ القرارات التي توصلوا إليها؛ وتغيير قواعد الحوكمة نفسها من خلال التعديلات الدستورية; و +3. تغيير الحكم يحكم أنفسهم من خلال التعديلات الدستورية. + +يطبق نظام البلوكتشين القائم على برنامج EOS.IO عملية حوكمة تعمل على التوجيه الكفؤ للتأثير القائم لمنتجي الكتل. في غياب عملية إدارة محددة ، اعتمدت البلوكتشين السابقة على عمليات حوكمة مخصصة وغير رسمية وغالباً ما كانت مثيرة للجدل، مما أدى إلى وقوع نتائج غير متوقعة. + +يُدرك البلوكتشين الذي يستخدم برنامج EOS.IO أن السلطة تنشأ من أصحاب الرموز الذين يفوضون هذه السلطة لمنتجي الكتل. يُمنح منتجو الكتل سلطة محدودة ومحددة لتجميد الحسابات وتحديث التطبيقات المعيبة واقتراح ان تعديلات تقتضي انقسامات "hard fork" جديد لإجراء التعديلات على البروتوكول الأساسي. + +نظام انتخاب منتجي الكتل مُدمج في برنامج EOS.IO. تلزم موافقة منتجي الكتل قبل إجراء أي تغيير على البلوكتشين. إذا رفض منتجو الكتل إجراء تغييرات مطلوبة من قبل حاملي الرموز، فيمكنهم التصويت باستبعادهم. إذا أجرى منتجو الكتل تغييرات دون الحصول على إذن من حاملي الرموز، فحينئذٍ سيرفض المتحققون من صلاحية العُقد الكاملة غير المُنتجين " non-producing full-node validators " (مثل منصات التداول وغيرها) هذا التغيير. + +## تجميد الحسابات (Freezing Accounts) + +في بعض الأحيان يتصرف العقد الذكي تصرفًا شاذًا أو لا يمكن التنبؤ به ويفشل في الأداء على النحو المنشود؛ وفي أحيان أخرى قد يكتشف التطبيق أو الحساب إساءة استغلال يمكن من خلالها استهلاك كمية غير معقولة من الموارد. عندما تحدث مثل هذه الأمور الحتمية، يتمتع منتجو الكتل بالسلطة اللازمة لتصحيح مثل هذه المواقف. + +يتمتع منتجو الكتل في جميع أنواع البلوكتشين بالقدرة على اختيار المعاملات التي تُضمّن في الكتل؛ مما يمنحهم القدرة على تجميد الحسابات. يضفي البلوكتشين المستخدم لبرنامج EOS.IO طابعًا رسميًا على هذه السلطة من خلال إخضاع عملية تجميد الحسابات إلى تصويت بنسبة 15 من أصل 21 من أصوات المنتجين النشطين. إذا أساء المنتجون استخدام السلطة؛ فيمكن وقتها التصويت على استبعادهم وسيُلغى تجميد الحساب. + +## تغيير رمز الحساب (Changing Account Code) + +عندما يفشل كل شيء آخر ويعمل "تطبيق لا يمكن إيقافه" على نحو لا يمكن التنبؤ بها؛ فإن البلوكتشين باستخدام برنامج EOS.IO يسمح لمنتجي الكتل باستبدال رمز الحساب "Code" دون أن التسبب في انقسام للبلوكتشين بأكمله. على غرار عملية تجميد الحساب، يتطلب هذا التغيير للرمز تصويتًا بالموافقة بنسبة 15 من أصل 21 من منتجي الكتل المنتخبين. + +## الدستور (Constitution) + +يمكّن برنامج EOS.IO البلوكتشين من إنشاء اتفاقية شروط خدمة النظير إلى النظير "peer-to-peer" أو عقدًا ملزمًا بين المستخدمين الذين يوقعون عليه، ويُشار إليهم بـ "الدستور". يحدد محتوى هذا الدستور الالتزامات بين المستخدمين التي لا يمكن إنفاذها بالكامل عن طريق رمز البرمجة "Code"؛ كما يسهل حل النزاعات من خلال تحديد الاختصاص واختيار القانون إلى جانب القواعد الأخرى المقبولة قبولًا متبادلًا. يجب أن تتضمن كل عملية تبث على الشبكة الهاش "Hash" من الدستور كجزء من التوقيع وبالتالي تربط صراحة بين المُوقِّع والعقد. + +كما يحدد الدستور الغرض البشري المقروء من بروتوكول الشفرة المصدرية. يتم استخدام هذه الغرض لتحديد الفرق بين الخطأ البرمجي "bug" والميزة عند حدوث الأخطاء وإرشاد المجتمع بخصوص الإصلاحات المناسبة أو غير المناسبة. + +## ترقية البروتوكول والدستور (Upgrading the Protocol & Constitution) + +يحدد برنامج EOS.IO العملية التالية التي يمكن من خلالها تحديث البروتوكول كما هو محدد بواسطة الشفرة المصدرية الأساسية ودستورها: + +1. يقترح منتجو الكتل تغييرًا في الدستور ويحصلون على تصويت بالموافقة بنسبة 15 من أصل 21 صوتًا. +2. يحتفظ منتجو الكتل بنسبة موافقة على **لدستور** الجديد تبلغ 15 من أصل 21 لمدة 30 يومًا متتالية. +3. يُطلب من جميع المستخدمين الإشارة إلى قبولهم الدستور الجديد شرطًا لمعالجة المعاملات المستقبلية. +4. يتبنى منتجو الكتل تغييرات في الشفرة المصدرية لتجسّد التغيير في الدستور؛ ويقترحونها على البلوكتشين باستخدام هاش"hash" الدستور الجديد. +5. يحتفظ منتجو الكتل بنسبة موافقة على **الكود** الجديد في 30 يوم متتالية. +6. تسري التغييرات التي أُجريت على الشفرة بعد 7 أيام، مما يعطي جميع العُقد الكاملة غير المنتجة " non-producing full nodes " أسبوعًا واحدًا للترقية بعد التصديق على شفرة المصدر. +7. تُغلق تلقائيًا كافة العُقد التي لم تُرقَ إلى الشفرة الجديدة. + +وفق التكوين الافتراضي لبرنامج EOS.IO، تستغرق عملية تحديث البلوكتشين لإضافة ميزات جديدة من شهرين إلى 3 أشهر، بينما تستغرق التحديثات لإصلاح الأعطاب غير الحرجة التي لا تتطلب تغييرات في الدستور فترة تتراوح من شهر إلى شهرين. + +### التغييرات الطارئة (Emergency Changes) + +قد يُسرع منتجو الكتل بعملية التغيير إذا كان تغيير البرنامج مطلوبًا لإصلاح خلل ضار أو ثغرة أمان تضر المستخدمين بالفعل. عمومًا يمكن أن يكون إدخال ميزات جديدة أو إصلاح الخلل غير الضار بواسطة التحديثات المُعجلة أمرًا مخالفًا للدستور. + +# المخطوطات والحواسيب الافتراضية (Scripts & Virtual Machines) + +EOS.IO ستكون المنصة الأولى والسبّاقة لتنسيق تسليم الرسائل الموثوقة (تُسمى الإجراءات) إلى الحسابات. إن تفاصيل لغة البرمجة النصية والجهاز الافتراضي عبارة عن تفاصيل خاصة بالتنفيذ وغالبًا ما تكون مستقلة عن تصميم تقنية EOS.IO. يمكن دمج أي لغة أو VM مع الـAPI الخاص بـEOS.IO. + +## الإجراءات المُحددة بواسطة المخطط (Schema Defined Actions) + +تُحدد جميع الإجراءات المرسلة بين الحسابات من خلال مخطط يمثل جزءً من حالة الإجماع الخاصة بالبلوكتشين. يتيح هذا المخطط التحويل السلس بين التمثيل الثنائي "Binary" والتمثيل بلغة الجافا "JSON" للإجراءات. + +## قاعدة البيانات المُحددة بواسطة المخطط (Schema Defined Database) + +كما تُحدد حالة قاعدة البيانات أيضًا باستخدام مخطط مشابه. يضمن ذلك أن تكون جميع البيانات المخزنة من قبل جميع التطبيقات في صيغة يمكن تفسيرها على أنها لغة جافا مقروءة للبشر "JSON" ولكنها تُخزّن ويتُحكم بها عبر كفاءة اللغة الثنائية "inaryB". + +## قاعدة بيانات عامة متعددة الفهرسة API (Generic Multi Index Database API) + +يتطلب تطوير العقود الذكية قاعدة بيانات مُحددة بواسطة المخطط؛ وذلك بهدف تتبع البيانات وتخزينها والبحث عنها. عادة ما يحتاج المطورون إلى نفس البيانات التي نُظِمت أو فُهرست من خلال حقول متعددة؛ بالإضافة إلى المحافظة على التناسق بين جميع الفهارس. + +## فصل المصادقة عن التطبيق (Separating Authentication from Application) + +لتعظيم فرص الموازاة وتقليل الدين الحوسبي "computational debt" المصاحب لتجديد حالة التطبيق من سجل المعاملات؛ يُقسّم برنامج EOS.IO منطق التحقق من الصحة إلى ثلاثة أقسام: + +1. التحقق من اتساق الإجراء داخليًا; +2. التحقق من صحة جميع الشروط المسبقة ; و +3. التحقق من صحة جميع الشروط المسبقة + +التحقق من التناسق الداخلي "للإجراء" يتم عبر القراءة فقط ولا يتطلب الوصول إلى حالة البلوكتشين. وهذا يعني أنه إمكانية إجراؤه بأقصى قدر من التوازي. التحقق من الشروط المسبقة، مثل الرصيد المطلوب، وكونه للقراءة فقط وبالتالي يمكن أيضا الاستفادة من التوازي. يتطلب تعديل حالة التطبيق فقط إمكانية الكتابة ويجب معالجته بالتسلسل لكل تطبيق. + +المصادقة عملية قراءة فقط؛ شأنها التحقق من إمكانية تطبيق الإجراء. التطبيق في الواقع القيام بالعمل نفسه. يلزم إجراء كلا الحسابين آنيًا، ولكن بمجرد أن تضمين المعاملة في البلوكتشين لن يكون من الضروري إجراء عمليات المصادقة. + +# الاتصالات عبر البلوكتشين (Inter Blockchain Communication) + +صُمم برنامج EOS.IO لتسهيل الاتصال بين شبكات البلوكتشين. يتحقق ذلك من خلال تسهيل إنشاء دليل على وجود الإجراء ودليل تسلسل الإجراء. هذه الأدلة جنبًا إلى جنب مع بنية التطبيق المصممة حول تمرير الإجراءات؛ تُمكن من إخفاء تفاصيل الاتصال بين البلوكتشين وإثبات صحة الدليل عن مطوري التطبيقات، مما يتيح تقديم مستويات أعلى من التجريد للمطورين. + +
+ +
+ +
+ +## أدلة ميركل للتحقق الخفيف من العميل (Merkle Proofs for Light Client Validation (LCV)) + +التكامل مع أنواع البلوكتشين الأخرى أسهل بكثير إذا لم يكن العملاء بحاجة إلى معالجة جميع المعاملات. في النهاية لا تهتم منصات التداول إلا بالحوالات داخلها وخارجها وليس أكثر من ذلك. وسيكون من المثالي أيضًا أن تستخدم سلسلة التبادل أدلة ميركل الخفيفة للإيداع بدلاً من الاضطرار إلى الوثوق تمامًا بمنتجيها للكتل. على أقل تقدير، يرغب منتجو الكتل بالسلسلة في الحفاظ على أصغر مقدار ممكن من الأحمال عند المزامنة مع بلوكتشين آخر. + +الهدف من أدلة ميركل للتحقق الخفيف من العميل "LCV" هو تمكين إنتاج دليل خفيف الوزن نسبياً يمكن التحقق منه بواسطة أي شخص يتتبع مجموعة بيانات خفيفة الوزن نسبياً. في هذه الحالة، الهدف هو إثبات أن معاملة معينة مُضمّنة بالفعل في كتلة وأن هذه الكتلة مُضمّنة في التاريخ المتحقق منه من بلوكتشين معين. + +يدعم البيتكوين التحقق من صحة المعاملات؛ وذلك بافتراض أن جميع العُقد يمكنها الوصول إلى السجل الكامل لرؤوس الكتل التي تبلغ 4 ميجابايت من رؤوس الكتل في السنة. عند معدل 10 معاملات في الثانية، يتطلب الإثبات الصالح حوالي 512 بايت. يعمل هذا جيدًا مع البلوكتشين الذي به فاصل للكتلة يبلغ 10 دقائق، ولكن لم يعد "خفيفًا" للبلوكتشين الذي به فاصل كتلة يبلغ 0.5 ثانية. + +يُمكّن برنامج EOS.IO الأدلة خفيفة الوزن لأي شخص لديه رأس كتلة لا رجعة فيها بعد النقطة التي تم تضمين المعاملة فيها. باستخدام الهيكل المرتبط بالهاش "Hash"، يمكن إثبات وجود أي معاملة باستخدام دليل حجمه أقل من 1024 بايت. + +شريطة أن يكون مُعرّف الكتلة لأي كتلة في البلوكتشين وكذلك رؤوس الكتلة موثوق بها ولا رجعة فيها. من الممكن إثبات أن الكتلة موجودة في البلوكتشين. هذا الدليل يستعمل خلاصات الدالة:ceil(log2(N) لمساره، حيث "N" هو عدد الكتل في السلسلة. وبمعرفة طريقة هضم "SHA256"؛ يمكنك إثبات وجود أي كتلة في سلسلة تحتوي على 100 مليون كتلة في 864 بايت. + +هناك زيادة طفيفة في الحِمل المرتبط بإنتاج الكتل ذات الربط الصحيح بالهاش "hash linking" لتمكين هذه الأدلة؛ مما يعني أنه لا يوجد سبب لعدم إنتاج الكتل بهذه الطريقة. + +عندما يحين وقت التحقق من صحة الأدلة على السلاسل الأخرى؛ فهناك مجموعة واسعة من التحسينات التي يمكن إجراؤها على الوقت والمساحة وعرض النطاق. سيحافظ تتبع جميع رؤوس الكتل (420 ميجابايت/السنة) على صغر حجم الأدلة. يمكن أن يوفر تتبع الرؤوس الحديثة فقط موازنة بين الحد الأدنى من التخزين طويل الأجل وحجم الدليل. بدلًا من ذلك، يمكن للبلوكتشين استخدام نهج تقييمٍ متراخٍ حيث يتذكر الهاش "hash" المتوسطة من الأدلة السابقة. يتعين على الأدلة الجديدة فقط أن تتضمن روابطًا لشجرة التفرق المعروفة "ٍsparse tree". يعتمد النهج الدقيق المستخدم بالضرورة على النسبة المئوية للكتل الأجنبية التي تتضمن معاملات مشار إليها بواسطة ادلة ميركل. + +بعد كثافة معينة من الترابط يصبح من الأكثر كفاءة أن تحتوي سلسلة واحدة فقط على تاريخ الكتلة بأكمله لسلسلة أخرى؛ وإزالة الحاجة إلى الأدلة بالكامل. لأسباب تتعلق بالأداء، فمن المثالي تقليل تكرارية الأدلة بين السلاسل "inter-chain proofs". + + +## تأخر الاتصالات عبر البلوكتشين (Latency of Interchain Communication) + +عند التواصل مع بلوكتشين خارجي آخر، يجب على منتجي الكتل الانتظار حتى يجري التأكد بنسبة 100 ٪ من أن المعاملة تأكدت تأكيدًا لا رجعة فيه من قبل البلوكتشين الآخر؛ وذلك قبل قبوله بوصفه مُدخلًا صالحًا. باستخدام بلوكتشين معتمد على برنامج EOS.IO وإثبات الحصة بالتفويض "DPOS" مع كتل 0.5 ثانية وإضافة إلى اللارجعة وفق سماحية الخطأ البيزنطية، يستغرق هذا حوالي 0.5 ثانية. إذا لم ينتظر منتجو الكتل لأي سلسلة حالة اللارجعة، فسيكون الأمر مثل التبادل الذي يعيد إيداعًا عُكس لاحقًا؛ ويمكن أن يؤثر هذا على صحة الإجماع الخاص بالبلوكتشين. يستخدم برنامج EOS.IO كلاً من إثبات الحصة بالتفويض "DPOS" وسماحية خطأ بيزنطية لا متزامنة "aBFT" لتوفير اللارجعة سريعًا. + +## دليل الاكتمال (Proof of Completeness) + +عند استخدام أدلة ميركل من شبكات البلوكتشين الخارجية الأخرى، هناك اختلاف كبير بين معرفة أن جميع المعاملات التي تمت معالجتها صحيحة ومعرفة أنه لم يجري تخطي أو حذف أي معاملة. في حين أنه من المستحيل إثبات أن جميع المعاملات الأخيرة معروفة، فمن الممكن إثبات عدم وجود ثغرات في تاريخ المعاملة. يُسهّل برنامج EOS.IO ذلك من خلال تعيين رقم تسلسلي لكل إجراء سُلِّم لكل حساب. يمكن للمستخدم استخدام أرقام التسلسل هذه لإثبات أن جميع الإجراءات المخصصة لحساب معين قد جرى معالجتها وأن ذلك قد تم بالترتيب. + +## الشاهد المنفصل (Segregated Witness) + +إن مفهوم الشاهد المنفصل (SegWit) يعني أن توقيعات المعاملة تصبح غير ذات صلة بعد أن تم تضمين المعاملة في البلوكتشين تضمينًا لا يمكن تغييره. وبمجرد أن تصبح غير قابلة للتغيير؛ يمكن استقطاع بيانات التوقيع ويستطيع أي شخص آخر اشتقاق الحالة الراهنة. وحيث تُمثل التوقيعات نسبة كبيرة من معظم المعاملات، فإن الشاهد "SegWit" يُحقق وفرة كبيرة في استخدام القرص وكذلك وقت المزامنة. + +هذا المفهوم نفسه يمكن أن ينطبق على أدلة ميركل المستخدمة للاتصال بين البلوكتشين. بمجرد قبول الدليل وتسجيله تسجيلًا لا رجعة فيه في البلوكتشين، فإن الهاش الخاص بـ "sha256" الذي حجمه 2 كيلوبايت ويُستخدم من قِبل الدليل؛ لم يعد لازمًا لاشتقاق الحالة المناسبة للبلوكتشين. في حالة التواصل بين البلوكتشين، هذه الوفورات هي أكبر بمقدار 32 مرة من الوفورات المتحققة للتوقيعات العادية. + +تمثل منشورات مدونة منصة "Steem" مثالًا آخر على استخدام الشاهد المنفصل "SegWit". في إطار هذا النموذج، ستحتوي المشاركة فقط على "sha256" (محتوى المدونة) وسيكون محتوى المدونة موجودًا في بيانات الشاهد المنفصل. يتحقق منتج الكتل من وجود المحتوى وأن له الهاش "Hash" المخصص له، لكن محتوى المدونة لن يحتاج إلى تخزينه من أجل استعادة الحالة الحالية من سجل البلوكتشين. وهذا يُمكّن من إثبات أن المحتوى كان معروفًا من قبل؛ وذلك دون الحاجة إلى تخزين المحتوى المذكور إلى الأبد. + +# الاستنتاج (Conclusion) + +صُمم برنامج EOS.IO من خلال خبرة بالمفاهيم المجربة وأفضل الممارسات، ويمثل التطورات الأساسية في تقنية البلوكتشين. يعتبر البرنامج جزءً من مخطط شامل لمجتمع بلوكتشين قابل للتوسع عالمياً؛ حيث يمكن نشر التطبيقات اللامركزية وحوكمتها بسهولة. +