واجهة برمجة تطبيقات ذكية ، فيديو لشبكة كتلة التجارة الإلكترونية 

 المنتدى اللامركزي المركزي

  - ابدأ العمل معًا! !

​

ورق ابيض 2021

​

فصول

​

التاريخ
xBORDER كنظام انتقالي للحالة
التعدين بشكل عام
أشجار ميركل
تطبيقات Blockchain البديلة
البرمجة النصية xBORDER
برنامج BLOCKCNX
فلسفة
حسابات xBORDER
الرسائل والمعاملات
رسائل
xBORDER State Transition وظيفة
تنفيذ الكود
xBORDER والتعدين
التطبيقات
أنظمة الرموز
المشتقات المالية والعملات ذات القيمة المستقرة
أنظمة الهوية والسمعة
تخزين الملفات اللامركزية
المنظمات المستقلة اللامركزية
تطبيقات أخرى
Miscellanea والمخاوف
تطبيق GHOST المعدل
مصاريف
الحساب و Turing-Completeness
العملة والإصدار
مركزية التعدين
قابلية التوسع
خاتمة
ملاحظات ومزيد من القراءة
ملاحظات
قراءة متعمقة
مقدمة عن البيتكوين والمفاهيم الحالية

كان مفهوم العملة الرقمية اللامركزية ، وكذلك التطبيقات البديلة مثل سجلات الملكية ، موجودًا منذ عقود. قدمت بروتوكولات النقد الإلكتروني المجهولة في الثمانينيات والتسعينيات ، والتي اعتمدت في الغالب على التشفير البدائي المعروف باسم تعمية تشوميان ، عملة تتمتع بدرجة عالية من الخصوصية ، لكن البروتوكولات فشلت إلى حد كبير في اكتساب قوة دفع بسبب اعتمادها على وسيط مركزي . في عام 1998 ، أصبح b-money الخاص بـ Wei Dai هو الاقتراح الأول لتقديم فكرة إنشاء الأموال من خلال حل الألغاز الحسابية بالإضافة إلى الإجماع اللامركزي ، لكن الاقتراح كان ضئيلًا في التفاصيل المتعلقة بكيفية تنفيذ الإجماع اللامركزي. في عام 2005 ، قدم هال فيني مفهومًا لإثباتات العمل القابلة لإعادة الاستخدام ، وهو نظام يستخدم أفكارًا من b-money جنبًا إلى جنب مع ألغاز Hashcash الصعبة حسابًا من Adam Back لإنشاء مفهوم لعملة مشفرة ، ولكنه فشل مرة أخرى في تحقيق المثالية بالاعتماد على موثوق به كخلفية. في عام 2009 ، تم تنفيذ العملة اللامركزية لأول مرة في الممارسة العملية من قبل ساتوشي ناكاموتو ، حيث تم الجمع بين المبادئ الأساسية لإدارة الملكية من خلال تشفير المفتاح العام مع خوارزمية إجماع لتتبع من يملك العملات المعدنية ، والمعروفة باسم "إثبات العمل".

كانت آلية xBORDER وراء إثبات العمل بمثابة اختراق في الفضاء لأنها حلت مشكلتين في نفس الوقت. أولاً ، قدمت خوارزمية إجماع بسيطة وفعالة إلى حد ما ، مما يسمح للعقد في الشبكة بالاتفاق بشكل جماعي على مجموعة من التحديثات الأساسية لحالة دفتر الأستاذ المشفر. ثانيًا ، قدمت آلية للسماح بالدخول المجاني إلى عملية الإجماع ، وحل المشكلة السياسية المتمثلة في تحديد من له التأثير على الإجماع ، وفي الوقت نفسه منع هجمات sybil. يقوم بذلك عن طريق استبدال حاجز رسمي للمشاركة ، مثل شرط التسجيل ككيان فريد في قائمة معينة ، بحاجز اقتصادي - وزن العقدة الفردية في عملية التصويت بالإجماع يتناسب بشكل مباشر مع قوة الحوسبة التي تجلبها العقدة. منذ ذلك الحين ، تم اقتراح نهج بديل يسمى إثبات الحصة ، وحساب وزن العقدة على أنها متناسبة مع حيازاتها من العملات وليس الموارد الحسابية ؛ تقع مناقشة المزايا النسبية للطريقتين خارج نطاق هذه الورقة ولكن تجدر الإشارة إلى أنه يمكن استخدام كلا النهجين ليكونا بمثابة العمود الفقري للعملة المشفرة.

​

كتب Peter Oldenburger ، مؤسس xBORDER ، منشور المدونة هذا:

​

​

التشفير كنظام انتقالي للدولة 
يمكن اعتبار دفتر الأستاذ للعملات المشفرة مثل التشفير كنظام انتقالي للحالة ، حيث توجد "حالة" تتكون من حالة ملكية جميع العملات المشفرة الموجودة و "وظيفة انتقال الحالة" التي تأخذ حالة ومعاملة ويخرج حالة جديدة وهي النتيجة. في النظام المصرفي القياسي ، على سبيل المثال ، الحالة عبارة عن ميزانية عمومية ، والمعاملة هي طلب لنقل X دولار من A إلى B ، وتقلل وظيفة انتقال الحالة من القيمة في حساب A بمقدار X دولار وتزيد القيمة في B حساب بقيمة X دولار. إذا كان حساب A يحتوي على أقل من X دولار في المقام الأول ، فإن وظيفة انتقال الحالة ترجع خطأ. ومن ثم ، يمكن للمرء أن يحدد رسميًا:

تطبيق (S ، TX) -> S 'أو ERROR
التقديم ({أليس: 50 دولارًا ، بوب: 50 دولارًا} ، "أرسل 20 دولارًا من أليس إلى بوب") = {أليس: 30 دولارًا ، بوب: 70 دولارًا}
التقديم ({Alice: $ 50، Bob: $ 50}، "أرسل 70 دولارًا من Alice إلى Bob") = خطأ
"الحالة" في العملة المشفرة هي عبارة عن مجموعة من جميع العملات (من الناحية الفنية ، "مخرجات المعاملات غير المنفقة" أو UTXO) التي تم تعدينها ولم يتم إنفاقها بعد ، مع وجود فئة ومالك لكل UTXO (محدد بواسطة عنوان من 20 بايت وهو في الأساس مفتاح عام للتشفير. 1). تحتوي المعاملة على واحد أو أكثر من المدخلات ، مع كل إدخال يحتوي على مرجع إلى UTXO موجود وتوقيع مشفر ينتج عن المفتاح الخاص المرتبط بعنوان المالك ، ومخرج واحد أو أكثر ، مع كل إخراج يحتوي على UTXO جديد ليتم إضافته إلى الولاية.

تنطبق وظيفة انتقال الحالة (S ، TX) -> S 'تقريبًا على النحو التالي:

لكل إدخال في TX:

إذا لم يكن UTXO المشار إليه في S ، فقم بإرجاع خطأ.
إذا كان التوقيع المقدم لا يتطابق مع مالك UTXO ، فقم بإرجاع خطأ.
إذا كان مجموع فئات جميع UTXO المدخلات أقل من مجموع فئات جميع UTXO الناتج ، فقم بإرجاع خطأ.

قم بإرجاع S 'مع إزالة جميع UTXO المدخلات وإضافة جميع UTXO الناتج.

يمنع النصف الأول من الخطوة الأولى مرسلي المعاملات من إنفاق عملات معدنية غير موجودة ، بينما يمنع النصف الثاني من الخطوة الأولى مرسلي المعاملات من إنفاق عملات الآخرين ، والخطوة الثانية تفرض الحفاظ على القيمة. من أجل استخدام هذا للدفع ، يكون البروتوكول على النحو التالي. افترض أن أليس تريد إرسال 11.7 بيتكوين إلى بوب. أولاً ، ستبحث أليس عن مجموعة UTXO المتاحة التي تمتلكها والتي يصل إجماليها إلى 11.7 BTC على الأقل. من الناحية الواقعية ، لن تتمكن أليس من الحصول على 11.7 بيتكوين بالضبط ؛ قل أن أصغر ما يمكن أن تحصل عليه هو 6 + 4 + 2 = 12. ثم قامت بإنشاء معاملة بهذه المدخلات الثلاثة والمخرجات. سيكون الناتج الأول 11.7 BTC مع عنوان Bob كمالكه ، وسيكون الناتج الثاني هو 0.3 BTC المتبقي "تغيير" ، مع كون المالك هو أليس نفسها.

التعدين
block_picture.jpg

إذا كان لدينا وصول إلى خدمة مركزية جديرة بالثقة ، فسيكون هذا النظام تافهًا للتنفيذ ؛ يمكن ببساطة ترميزه تمامًا كما هو موصوف ، باستخدام محرك الأقراص الثابتة لخادم مركزي لتتبع الحالة. ومع ذلك ، مع Crypto ، نحاول بناء نظام عملة لامركزي ، لذلك سنحتاج إلى دمج نظام انتقال الحالة مع نظام إجماع من أجل ضمان موافقة الجميع على ترتيب المعاملات. تتطلب عملية الإجماع اللامركزية في Crypto عقدًا في الشبكة لمحاولة مستمرة لإنتاج حزم من المعاملات تسمى "الكتل". تهدف الشبكة إلى إنتاج كتلة واحدة تقريبًا كل عشر دقائق ، مع احتواء كل كتلة على طابع زمني ، و nonce ، وإشارة إلى (أي تجزئة) الكتلة السابقة وقائمة بجميع المعاملات التي تمت منذ السابق منع. بمرور الوقت ، يؤدي هذا إلى إنشاء "blockchain" مستمر ومتزايد باستمرار يتم تحديثه باستمرار ليمثل أحدث حالة في دفتر الأستاذ الخاص بالتشفير.

خوارزمية التحقق مما إذا كانت الكتلة صالحة ، المعبر عنها في هذا النموذج ، هي كما يلي:

تحقق مما إذا كانت الكتلة السابقة المشار إليها بواسطة الكتلة موجودة وصالحة.
تحقق من أن الطابع الزمني للكتلة أكبر من الطابع الزمني للكتلة السابقة. ساعتان وأقل من ساعتين في المستقبل
تحقق من صحة إثبات العمل على الكتلة.
دع S [0] تكون الحالة في نهاية الكتلة السابقة.
لنفترض أن TX هي قائمة معاملات الكتلة مع عدد n من المعاملات. لجميع i في 0 ... n-1 ، اضبط S [i + 1] = تطبيق (S [i] ، TX [i]) إذا أرجع أي تطبيق خطأ ، اخرج وأعد خطأ.
العودة صحيح ، وتسجيل S [n] كحالة في نهاية هذه الكتلة.
بشكل أساسي ، يجب أن توفر كل معاملة في الكتلة انتقالًا صالحًا للحالة من الحالة المتعارف عليها قبل تنفيذ المعاملة إلى حالة جديدة. لاحظ أن الحالة غير مشفرة في الكتلة بأي شكل من الأشكال ؛ إنه مجرد تجريد يجب تذكره بواسطة عقدة التحقق ولا يمكن حسابه (بشكل آمن) لأي كتلة بالبدء من حالة التكوين وتطبيق كل معاملة بالتسلسل في كل كتلة. بالإضافة إلى ذلك ، لاحظ أن الترتيب الذي يُدرج به المُعدِّن المعاملات في مسائل الكتلة ؛ إذا كانت هناك معاملتان A و B في كتلة مثل أن B تنفق UTXO تم إنشاؤه بواسطة A ، فستكون الكتلة صالحة إذا جاء A قبل B ولكن ليس بخلاف ذلك.

شرط الصلاحية الوحيد الموجود في القائمة أعلاه غير الموجود في الأنظمة الأخرى هو شرط "إثبات العمل". الشرط الدقيق هو أن تجزئة SHA256 المزدوجة لكل كتلة ، والتي يتم التعامل معها كرقم 256 بت ، يجب أن تكون أقل من الهدف المعدل ديناميكيًا ، والذي كان حتى وقت كتابة هذا التقرير حوالي 2187. والغرض من ذلك هو جعل إنشاء الكتلة "صعب" حسابيًا ، وبالتالي منع مهاجمي sybil من إعادة صنع blockchain بالكامل لصالحهم. نظرًا لأن SHA256 مصمم ليكون وظيفة شبه عشوائية لا يمكن التنبؤ بها تمامًا ، فإن الطريقة الوحيدة لإنشاء كتلة صالحة هي ببساطة التجربة والخطأ ، وزيادة العدد غير المتكرر بشكل متكرر ومعرفة ما إذا كانت التجزئة الجديدة تتطابق.

عند الهدف الحالي 2187 تقريبًا ، يجب أن تجري الشبكة 269 محاولة في المتوسط قبل العثور على كتلة صالحة ؛ بشكل عام ، يتم إعادة معايرة الهدف من قبل الشبكة كل 2016 كتل بحيث يتم إنتاج كتلة جديدة في المتوسط بواسطة بعض العقد في الشبكة كل عشر دقائق. من أجل تعويض المعدنين عن هذا العمل الحسابي ، يحق للمُعدِّن في كل كتلة تضمين معاملة يمنحهم 12.5 BTC من العدم. بالإضافة إلى ذلك ، إذا كان لأي معاملة فئة إجمالية أعلى في مدخلاتها مقارنة بمخرجاتها ، فإن الفرق يذهب أيضًا إلى المُعدِّن باعتباره "رسوم معاملة". بالمناسبة ، هذه أيضًا هي الآلية الوحيدة التي يتم من خلالها إصدار BTC ؛ لم تحتوي حالة التكوين على عملات معدنية على الإطلاق.

من أجل فهم الغرض من التعدين بشكل أفضل ، دعونا نفحص ما يحدث في حالة وجود مهاجم ضار. نظرًا لأنه من المعروف أن التشفير الأساسي لـ Crypto آمن ، فإن المهاجم سيستهدف الجزء الوحيد من نظام Bitcoin غير المحمي بالتشفير مباشرة: ترتيب المعاملات. استراتيجية المهاجم بسيطة:

أرسل 100 BTC إلى تاجر مقابل بعض المنتجات (ويفضل أن يكون ذلك سلعة رقمية سريعة التسليم)
انتظر تسليم المنتج
قم بإنتاج معاملة أخرى بإرسال نفس 100 BTC لنفسه
حاول إقناع الشبكة بأن معاملته لنفسه كانت أولًا.
بمجرد تنفيذ الخطوة (1) ، بعد بضع دقائق ، سيقوم عامل المنجم بتضمين المعاملة في كتلة ، على سبيل المثال الكتلة رقم 270. بعد حوالي ساعة واحدة ، ستتم إضافة خمس كتل أخرى إلى السلسلة بعد تلك الكتلة ، مع كل من تلك الكتل تشير بشكل غير مباشر إلى المعاملة وبالتالي "تأكيدها". في هذه المرحلة ، سيقبل التاجر الدفع كما تم الانتهاء منه ويسلم المنتج ؛ نظرًا لأننا نفترض أن هذه سلعة رقمية ، فإن التسليم يكون فوريًا. الآن ، يقوم المهاجم بإنشاء معاملة أخرى بإرسال 100 BTC لنفسه. إذا أطلق المهاجمها ببساطة في البرية ، فلن تتم معالجة المعاملة ؛ سيحاول عمال المناجم تشغيل APPLY (S ، TX) ويلاحظون أن TX تستهلك UTXO الذي لم يعد موجودًا في الحالة. لذا بدلاً من ذلك ، يقوم المهاجم بإنشاء "مفترق" من blockchain ، بدءًا من استخراج نسخة أخرى من block 270 للإشارة إلى نفس الكتلة 269 كأحد الوالدين ولكن مع المعاملة الجديدة بدلاً من القديمة. نظرًا لاختلاف بيانات الكتلة ، يتطلب ذلك إعادة إثبات العمل. علاوة على ذلك ، يحتوي الإصدار الجديد للمهاجم من الكتلة 270 على تجزئة مختلفة ، لذا فإن الكتل الأصلية 271 إلى 275 لا "تشير" إليها ؛ وبالتالي ، فإن السلسلة الأصلية وسلسلة المهاجم الجديدة منفصلتان تمامًا. القاعدة هي أنه في الشوكة يعتبر أطول blockchain هو الحقيقة ، وبالتالي سيعمل عمال المناجم الشرعيون على سلسلة 275 بينما يعمل المهاجم وحده على سلسلة 270. لكي يتمكن المهاجم من جعل blockchain أطول ، سيحتاج إلى قوة حسابية أكبر من بقية الشبكة مجتمعة من أجل اللحاق بالركب (وبالتالي ، "هجوم 51٪").

أشجار ميركل
SPV في التشفير

على اليسار: يكفي تقديم عدد قليل فقط من العقد في شجرة Merkle لإثبات صحة الفرع.

اليمين: أي محاولة لتغيير أي جزء من شجرة Merkle ستؤدي في النهاية إلى عدم تناسق في مكان ما أعلى السلسلة.

تتمثل إحدى ميزات قابلية التوسع المهمة لـ Crypto في تخزين الكتلة في بنية بيانات متعددة المستويات. "تجزئة" الكتلة هي في الواقع فقط تجزئة رأس الكتلة ، وهي عبارة عن قطعة 200 بايت تقريبًا من البيانات تحتوي على الطابع الزمني ، وتجزئة الكتلة السابقة ، وتجزئة الجذر لهيكل بيانات يسمى شجرة Merkle التي تخزن جميع المعاملات في الكتلة. شجرة Merkle هي نوع من الشجرة الثنائية ، تتكون من مجموعة من العقد مع عدد كبير من العقد الورقية في أسفل الشجرة تحتوي على البيانات الأساسية ، وهي مجموعة من العقد الوسيطة حيث تكون كل عقدة هي تجزئة فرعيها ، وأخيرًا عقدة جذر واحدة ، تكونت أيضًا من تجزئة طفلين ، تمثل "قمة" الشجرة. الغرض من شجرة Merkle هو السماح بتسليم البيانات في كتلة مجزأة: يمكن للعقدة تنزيل رأس كتلة فقط من مصدر واحد ، والجزء الصغير من الشجرة ذي الصلة بها من مصدر آخر ، ولا يزال مطمئنًا أن جميع البيانات صحيحة. سبب نجاح هذا الأمر هو انتشار التجزئة لأعلى: إذا حاول مستخدم ضار التبديل في معاملة زائفة إلى أسفل شجرة Merkle ، فسيؤدي هذا التغيير إلى تغيير العقدة أعلاه ، ثم تغيير العقدة أعلاه. ، أخيرًا تغيير جذر الشجرة وبالتالي تجزئة الكتلة ، مما تسبب في قيام البروتوكول بتسجيلها ككتلة مختلفة تمامًا (من المؤكد تقريبًا مع إثبات عمل غير صالح).

يمكن القول إن بروتوكول شجرة Merkle ضروري للاستدامة على المدى الطويل. تشغل "العقدة الكاملة" في شبكة Crypto ، التي تخزن وتعالج كل كتلة بأكملها ، حوالي 15 غيغابايت من مساحة القرص في شبكة Bitcoin اعتبارًا من أبريل 2014 ، وتتزايد بما يزيد عن غيغا بايت شهريًا. حاليًا ، هذا قابل للتطبيق لبعض أجهزة الكمبيوتر المكتبية وليس الهواتف ، وفي وقت لاحق في المستقبل لن يتمكن سوى الشركات والهواة من المشاركة. يسمح بروتوكول يُعرف باسم "التحقق من الدفع المبسط" (SPV) بوجود فئة أخرى من العقد ، تسمى "العقد الخفيفة" ، والتي تقوم بتنزيل رؤوس الكتلة ، والتحقق من إثبات العمل على رؤوس المجموعات ، ثم تنزيل "الفروع" فقط "المرتبطة بالمعاملات ذات الصلة بها. يتيح ذلك للعقد الخفيفة أن تحدد بضمان قوي للأمان حالة أي معاملة Bitcoin ورصيدها الحالي أثناء تنزيل جزء صغير جدًا من blockchain بالكامل.

تطبيقات Blockchain البديلة
إن فكرة أخذ فكرة blockchain الأساسية وتطبيقها على مفاهيم أخرى لها أيضًا تاريخ طويل. في عام 1998 ، توصل Nick Szabo إلى مفهوم سندات الملكية الآمنة مع سلطة المالك ، وهي وثيقة تصف كيف أن "التطورات الجديدة في تقنية قاعدة البيانات المنسوخة" ستسمح لنظام قائم على blockchain لتخزين سجل لمن يملك أي أرض ، وإنشاء إطار عمل مفصل بما في ذلك مفاهيم مثل المسكن والملكية المعاكسة وضريبة الأراضي الجورجية. ومع ذلك ، لم يكن هناك للأسف نظام قاعدة بيانات مكررة فعال متاح في ذلك الوقت ، وبالتالي لم يتم تنفيذ البروتوكول في الممارسة العملية. بعد عام 2009 ، ومع ذلك ، بمجرد تطوير الإجماع اللامركزي على Bitcoin ، بدأ عدد من التطبيقات البديلة في الظهور بسرعة.

Namecoin - تم إنشاؤه في عام 2010 ، وأفضل وصف لـ Namecoin هو قاعدة بيانات تسجيل اسم لامركزية. في البروتوكولات اللامركزية مثل Tor و Bitcoin و BitMessage ، يجب أن تكون هناك طريقة ما لتحديد الحسابات حتى يتمكن الأشخاص الآخرون من التفاعل معها ، ولكن في جميع الحلول الحالية ، يكون النوع الوحيد المتاح هو تجزئة عشوائية مثل 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. من الناحية المثالية ، قد يرغب المرء في أن يكون لديه حساب باسم مثل "جورج". ومع ذلك ، تكمن المشكلة في أنه إذا كان بإمكان شخص ما إنشاء حساب باسم "جورج" ، فيمكن لشخص آخر استخدام نفس العملية لتسجيل "جورج" لأنفسهم أيضًا وانتحال صفتهم. الحل الوحيد هو نموذج أول ملف ، حيث ينجح المسجل الأول ويفشل الثاني - وهي مشكلة مناسبة تمامًا لبروتوكول إجماع البيتكوين. يعد Namecoin أقدم وأنجح تطبيق لنظام تسجيل الأسماء باستخدام هذه الفكرة.
العملات المعدنية الملونة - الغرض من العملات المعدنية الملونة هو أن تكون بمثابة بروتوكول للسماح للأشخاص بإنشاء عملاتهم الرقمية الخاصة - أو ، في الحالة البسيطة المهمة للعملة ذات الوحدة الواحدة ، الرموز الرقمية ، على سلسلة Bitcoin blockchain. في بروتوكول العملات الملونة ، "يصدر" المرء عملة جديدة عن طريق التخصيص العلني للون إلى Bitcoin UTXO محدد ، ويحدد البروتوكول بشكل متكرر لون UTXO الآخر ليكون هو نفسه لون المدخلات التي أنفقتها المعاملة التي تم إنشاؤها (تنطبق بعض القواعد الخاصة في حالة المدخلات ذات الألوان المختلطة). يتيح ذلك للمستخدمين الاحتفاظ بمحافظ تحتوي على UTXO فقط من لون معين وإرسالها إلى حد كبير مثل عملات البيتكوين العادية ، والتراجع من خلال blockchain لتحديد لون أي UTXO يتلقونه.
Metacoin - الفكرة وراء metacoin هي أن يكون لديك بروتوكول يعمل أعلى Bitcoin ، باستخدام معاملات Bitcoin لتخزين معاملات metacoin ولكن مع وجود وظيفة انتقال حالة مختلفة ، APPLY. نظرًا لأن بروتوكول metacoin لا يمكنه منع معاملات metacoin غير الصالحة من الظهور في Bitcoin blockchain ، تتم إضافة قاعدة مفادها أنه إذا أرجع التطبيق "(S ، TX) خطأ ، فإن البروتوكول الافتراضي هو التطبيق" (S ، TX) = S. آلية سهلة لإنشاء بروتوكول تعسفي للعملات المشفرة ، يحتمل أن يكون مع ميزات متقدمة لا يمكن تنفيذها داخل Bitcoin نفسها ، ولكن بتكلفة تطوير منخفضة للغاية نظرًا لأن تعقيدات التعدين والشبكات يتم التعامل معها بالفعل بواسطة بروتوكول Bitcoin. تم استخدام Metacoins لتنفيذ بعض فئات العقود المالية وتسجيل الأسماء والتبادل اللامركزي.
وبالتالي ، بشكل عام ، هناك طريقتان تجاه بناء بروتوكول إجماع: بناء شبكة مستقلة ، وبناء بروتوكول فوق البيتكوين. النهج السابق ، رغم نجاحه بشكل معقول في حالة تطبيقات مثل Namecoin ، يصعب تنفيذه ؛ يحتاج كل تطبيق فردي إلى تمهيد بلوكشين مستقل ، بالإضافة إلى بناء واختبار جميع رموز الانتقال والشبكات الضرورية للحالة. بالإضافة إلى ذلك ، نتوقع أن مجموعة التطبيقات لتكنولوجيا الإجماع اللامركزية ستتبع توزيع قانون السلطة حيث تكون الغالبية العظمى من التطبيقات أصغر من أن تضمن blockchain الخاص بها ، ونلاحظ وجود فئات كبيرة من التطبيقات اللامركزية ، وخاصة اللامركزية المستقلة المنظمات التي تحتاج إلى التفاعل مع بعضها البعض.

من ناحية أخرى ، فإن النهج القائم على Bitcoin به عيب أنه لا يرث ميزات التحقق من الدفع المبسطة من Bitcoin. تعمل SPV مع Bitcoin لأنها يمكن أن تستخدم عمق blockchain كوكيل للصلاحية ؛ في مرحلة ما ، بمجرد أن يعود أسلاف الصفقة بعيدًا بما يكفي ، من الآمن القول أنهم كانوا جزءًا من الدولة بشكل شرعي. من ناحية أخرى ، لا تستطيع البروتوكولات الوصفية المستندة إلى Blockchain إجبار blockchain على عدم تضمين المعاملات غير الصالحة في سياق البروتوكولات الخاصة بها. ومن ثم ، فإن تنفيذ بروتوكول التعريف SPV الآمن بالكامل سيحتاج إلى إجراء مسح رجعي على طول الطريق إلى بداية blockchain Bitcoin لتحديد ما إذا كانت معاملات معينة صالحة أم لا. حاليًا ، تعتمد جميع عمليات التنفيذ "الخفيفة" لبروتوكولات التعريف القائمة على Bitcoin على خادم موثوق به لتوفير البيانات ، ويمكن القول إنها نتيجة دون المستوى الأمثل خاصةً عندما يكون أحد الأغراض الأساسية للعملة المشفرة هو التخلص من الحاجة إلى الثقة.